InfoSec Context

🪲 Bug Bounty умирает?
Два удара, которые могут поставить крест на охоте за багами, и это не обычные новости, а уже тенденция.

Мы привыкли воспринимать bug bounty как отличный открытый способ компаниям заявить о зрелости своего продукта, а исследователям получить пищу для творчества и деньги, все в выигрыше. Но сейчас эта модель взаимоотношений трещит по швам.

Удар первый: экономика не сходится.
Google отчитался о рекордных выплатах за 2025 год: $17,1 млн более чем 700 исследователям, рост на 40% год к году 😱. Казалось бы, вот оно, процветание. Но Google одновременно снизил стандартные награды за уязвимости в Chrome. Причина в том, что ИИ-инструменты сделали производство «подробных, но бесполезных» отчётов дешёвым и массовым. Компания теперь платит не за объём, а за реальную эксплуатируемость и глубокий анализ.

Параллельно Internet Bug Bounty (IBB) — программа, покрывавшая критический open-source софт, — приостановила приём отчётов. Curl убил свою bounty-программу на HackerOne ещё в январе 2026-го, так как доля валидных отчётов рухнула с ~15% до менее 5% 😤. Intel приостановил свою программу с максимальной наградой $100k. Apple ввёл лимиты на количество отчётов и 30-дневный cooldown — и реальные zero-day теперь стоят в очереди за AI-мусором.

Удар второй: ИИ наводнил отчётами, проверять их уже не успевают.
Вот некоторые сводки этого вала:
🔹 В Linux kernel количество CVE за версию выросло с ~500 (6.x) до почти 2000. Мейнтейнеры говорят прямо: «мы захлебнулись».
🔹 Google OSS VRP приостановлен минимум до Q1 2027. Причина — «значительный рост автоматизированных отправок, подавляющее большинство которых невалидны».
🔹 В Glasswing (CSA) за первый месяц ИИ-сканирования найдено 10 000+ высоких и критических уязвимостей, из которых 97 реально запатчены (около 6%).

Стоимость генерации отчёта упала до нуля, стоимость верификации осталась прежней. Волонтёры и небольшие команды мейнтейнеров вынуждены разгребать чужой спам.

Bug bounty как «демократичный способ подзаработать на поиске багов» переживает самый большой кризис. Выживут, скорее всего, только:
1️⃣ Крупные корпоративные программы с выделенным триажем (Google может себе позволить фильтровать, малый проект — нет).
2️⃣ Приватные приглашения и live-хакинг-события типа bugSWAT, где Google платит $1,6 млн за 130 отчётов на четырёхдневном ивенте.
3️⃣ Задачи с репутационным весом, где исследователь дорожит аккаунтом.

Для open-source это уже вызвало кризис, и если мейнтейнеры не могут позволить себе триаж, они скорее просто закроют программы. При этом уязвимости не исчезают — они уйдут к атакующим.

💬 Думаю, мы наблюдаем не смерть bug bounty, а некий отбор. Эпоха «отправил сканер — получил деньги» закончилась. Останутся те, кто умеет доказывать эксплуатируемость и решать проблемы, которые ИИ пока не щёлкает как орешки.

📖 InfoSec Context | TG | Max | Web

🍕 На очереди «Додо Пицца»
Помните, мы следим за инцидентом с туроператором Tez Tour? Теперь та же самая группировка DataSuckers 👽 заявила об атаке на известную пиццерию.

По информации от злоумышленников, подготовка к атаке началась 26 сентября, а уже на следующий день они получили полный контроль над базами данных компании и выкачали несколько терабайт данных 🚰: 68 млн. записей уникальных клиентов и весь массив заказов за все 15 лет существования сети — вплоть до истории покупок и деталей о составе заказов 😳.

Служба безопасности «Додо» подтвердила факт кибератаки. Представители компании сообщили, что доступ злоумышленников к системе оперативно заблокирован, однако предупредили: в руках атакующих могла оказаться информация клиентов (имена, адреса, email, телефоны, даты рождения и история заказов).

При этом подчеркивается, что платежные данные в безопасности, поскольку компания их в открытом виде не хранит. Дополнительно в целях безопасности пользователей массово разлогинивают из приложений и личных кабинетов.

🤔 Что в итоге?
Классическое начало громкого слива: хакеры заявляют о тотальной компрометации «всего и вся», а бизнес говорит о локализации и частичной утечке. Однако даже если правда где-то посередине, масштабы впечатляют❗️. Связка «телефон + ФИО + история реальных заказов с адресами» — это идеальный инструмент для киберпреступников, которые моментально поставят эти данные на поток для многоуровневых фишинговых атак и персонализированной социальной инженерии.

Тут, конечно, не затронуты «продающие» каналы компании, но репутационный ущерб налицо.

💬 Если вы активно пользовались этой доставкой, настоятельно рекомендую в ближайшие недели относиться с удвоенным скепсисом к любым звонкам и сообщениям от неизвестных. А я теперь и за этим громким инцидентом послежу 🍿.

📖InfoSec Context | TG | Max | Web

🚧 Две недели в офлайне
В продолжение прошлого поста подведём промежуточные итоги и обсудим, почему расследование ИБ-инцидента — это не про «переустановить винду» 🌅.

Сайт компании Tez tour недоступен уже практически две недели. Напомню: речь идёт не о визитке с контактами, а об одном из основных источников продаж и выручки, так как через него работают и туристические брокеры. Для бизнеса 14 дней простоя канала, который генерирует продажи, — это прямые финансовые потери и репутационный удар.

Обычно в такие моменты у руководства и бизнеса возникает логичный и очень эмоциональный запрос к ИТ и ИБ: «Почему так долго? Накатите бэкап и включайте обратно!»

Но в реальности всё работает совершенно иначе. Полная проверка, локализация и очистка инфраструктуры после серьёзного инцидента — это физически небыстрый процесс, и вот почему:
⏺Если просто развернуть вчерашний бэкап, злоумышленники или их автоскрипты вернутся в систему через пару минут. Закрепление в инфраструктуре могло произойти недели или даже месяцы назад, а значит, и сами бэкапы уже могут содержать закладки 🚰.
⏺Нужно собрать и проанализировать огромные массивы логов (если они вообще велись и сохранились), проверить точки входа, учётные записи, цепочки горизонтального перемещения.
⏺Безопасное восстановление сервиса потребует пересборки окружения, ротации всех ключей, сертификатов, паролей и токенов, а также закрытия конкретных уязвимостей, через которые пролезли атакующие.

Если инфраструктура сложная, а видимости и нормального логирования до инцидента не было — расследование превращается в археологические раскопки. И ускорить их без риска повторного взлома невозможно. А если для проведения расследования потребуется изъятие физического оборудования, то ситуация существенно усложняется.

Пока главный вывод, как всегда, в том, что к такому инциденту нужно готовиться заранее, в мирное время.
💬 Готовьте планы восстановления. Бизнес должен заранее понимать, каков допустимый уровень простоя (RTO/RPO) и как поддерживать продажи, пока основной сайт «лежит».
💬Периодически тестируйте восстановления и проводите учения с бизнесом.

Если у вас нет настроенных средств защиты (SIEM/NTA/EDR) и централизованного сбора / анализа логов, то период простоя кратно увеличивается, и это нужно учитывать.

💬 В современном мире ИИ и вабкодинга инциденты будут происходить постоянно. Вопрос давно не в «взломают ли?», а «когда?» и «как?» взломают.

📖InfoSec Context | TG | Max | Web

📱 Внутри суперприложений
Сегодня стандартом современной мобильной разработки является экосистемный подход. Мессенджеры и экосистемные платформы давно перестали быть просто чатами — это полноценные «суперприложения» (super-apps), внутри которых живут сотни мини-приложений (mini-apps): от заказа еды и такси до банковских сервисов и игр 🎮.

Удобно ли это? Для меня спорно, но тренд есть тренд. Пользователю не нужно ставить десяток отдельных приложений, а владелец продвигает свои сервисы.

🏗 Для обычного приложения/суперприложения из Google Play или App Store ОС смартфона изолирует его в «песочнице». Приложения физически не могут просто так залезть в оперативную память, локальное хранилище или сетевой трафик друг друга 🔒.

Но с мини-приложениями всё устроено совершенно иначе. Большинство мини-аппов запускаются не как самостоятельный нативный код, а внутри WebView — встроенного браузерного компонента основного приложения (хозяина платформы).

С точки зрения ОС и само суперприложение, и запущенный внутри него мини-сервис — это единый процесс. Операционная система просто не может выстроить между ними такую же жесткую стену изоляции, как между двумя отдельно установленными программами.

Из этой архитектурной модели и вытекают возможности хоста (владельца платформы):
1️⃣Платформа имеет полный доступ к выполнению кода внутри мини-приложения, может менять логику интерфейса или отслеживать события ввода.
2️⃣ Полный доступ к локальному хранилищу (токены авторизации, ключи API, кэш и пользовательские данные).
3️⃣ Весь трафик мини-аппа идет через сетевой стек хоста.
4️⃣ Хост способен обращаться к системным функциям ОС и делать снимки экрана или элементов интерфейса в момент ввода данных.

Недавно вышло практическое исследование на примере платформы 🌆 MAX, в рамках которого исследователи проверили мини-приложения из самых разных сфер — от финансов и связи до госуслуг и медицины.

Они обнаружили ровно то, о чем я писал выше, а именно возможность:
🔹 Захвата интерфейса ввода.
🔷 Чтения данных в хранилище.
🔷 Маршрутизации трафика.

Исследователи подняли очень правильный вопрос про доверие основной платформе. И, конечно, использовали самый для них "безопасный" пример, где будет минимум хейта от аудитории.

❗️Но они отметили, что это не специальный бэкдор, а возможности любой платформы, которыми может пользоваться хост. Точно такие же возможности технически заложены в любое суперприложение мира, будь то Telegram, WeChat и др. А вот будут ли владельцы этим пользоваться в очередном обновлении? 🤔

💬 Итого: владелец платформы — это абсолютный владелец среды выполнения. Если вы доверяете хозяину приложения, вы автоматически доверяете ему всё, что происходит и вводится внутри каждого встроенного мини-аппа.

📖InfoSec Context | TG | Max | Web

✈️ Начинаем разбирать инцидент с Tez Tour

Вчера, 15 сентября, появилась новость: один из крупнейших игроков туристического рынка, Tez Tour, подвергся кибератаке 🧐.

Группировка DataSuckers заявила о компрометации инфраструктуры, дефейсе главной страницы и сливе/удалении 🚰 множества данных — от бронирований до персональных данных клиентов (хакеры заявляли о цифрах вплоть до 400 млн. строк). Сама компания масштаб отрицает и заверяет, что критичных утечек нет, но так делают все 😉

Очередной классический инцидент, который заставляет вспомнить грабли веб-безопасности. Давайте кратко попробуем разобрать то, что сейчас известно.

Для подобного бизнеса веб-сайт и клиентский портал — это не просто «визитка в интернете». Он один из важнейших источников привлечения клиентов и получения данных о них:
1️⃣Через портал идут бронирования и оплаты.
2️⃣Точка входа для паспортных данных туристов, телефонов, email-адресов, истории поездок и токены авторизации.
3️⃣Архитектура портала может быть разной, но она все равно выводит в сложную сеть интеграций, и достаточно одной уязвимости в устаревшем плагине или слабой учетки админа, чтобы злоумышленники провалились внутрь инфраструктуры.

На данный момент хакеры заявили о захвате серверов, зачистке дисков и уничтожении колоссального массива информации (сотни миллионов записей о бронях, логистике и клиентах). На сайте красовалась «заглушка» о том, что компания прекратила существование. И они очень красочно описывают сам kill chain.

Tez Tour заявляют, что атака действительно затронула сайт, но критических признаков утечки персональных данных клиентов и партнеров нет, а ситуация находится под контролем 🧐.

Истина, возможно, где-то посередине. Но точно видно, что злоумышленники смогли вывесить дефейс сайта и он не работает уже больше суток. Обычно, если затронута только морда портала, то его возврат занимает очень мало времени. Сейчас Tez tour заявляет о необходимости дополнительных проверок, поэтому восстановление затягивается.

Какие начальные выводы можно сделать:
🟢Первичный вход заявляется через сервис загрузки файлов, который позволил загрузить файл с php-кодом. Такая ошибка относится к трем самым популярным веб уязвимостям в OWASP TOP 10, и удивительно, что ее не нашли ранее при проверке сайта 😡.
🟢Не выполнена должная изоляция сегментов. Веб-сервер, смотрящий в публичную сеть, не должен сам иметь доверенного доступа во внутреннюю сеть компании и к базам данных.
🟢 Резервное копирование с защитой от удаления. То, что хакеры заявляют об уничтожении бэкапов или баз данных — стандартная практика вымогателей. Изолированные, неизменяемые бэкапы — наш щит в подобных ситуациях.

💬 Я продолжу следить за развитием ситуации с Tez Tour и посмотрим, какие выводы можно будет сделать по завершении этого кейса. Будем учится на чужих граблях 😉

📖InfoSec Context | TG | Max | Web

🧠 Доверяй, но проверяй!
Периодически в своей деятельности использую различные ИИ-инструменты для получения выжимки информации в виде компиляции из источников или для написания кода. В обоих случаях ИИ уже не доверяю, и этому есть веская причина.

Вчера в очередной раз вспоминал нормативку по ИБ 📖, а конкретно — случаи обязательного применения сертифицированных СЗИ 🔐 для защиты ИСПДн в коммерции. Не подтвердил однозначно свои выводы и решил позвать на помощь ИИ. И тут началось самое интересное.

На все мои запросы ИИ давал однозначный ответ в необходимости применения сертифицированных СЗИ и приводил цитаты из 21 приказа ФСТЭК. Причем в самом приказе такого текста просто не было.

Я использовал несколько нейронок, и они все давали свои ответы в схожем ключе, приводя разные выдуманные нормы документов 🤬.

Сразу вспомнился случай, когда у криптана украли более $2,2 млн через фишинговый сайт, который ChatGPT 🎑выдавал в качестве ответа на вопрос, где обменять $FLR.

Или уж совсем удивительный случай безалаберности юристов — Верховный суд РФ признал неуважением к правосудию бездумное использование документов, сгенерированных нейросетью. Юристы должны нести ответственность за ложь и ошибки ИИ.

Поэтому давайте не будем забывать, что ИИ — это не панацея и замена работнику, а только инструмент. В работе ИБ такие ошибки теперь будут встречаться все чаще и чаще, например:
⏺Фантомные зависимости. Нейросеть может порекомендовать для вашего проекта несуществующую библиотеку. Злоумышленники мониторят популярные паттерны запросов к LLM и заблаговременно регистрируют такие пакеты в публичных репозиториях с внедренным вредоносным полезным нагрузками.
⏺Иллюзия безопасности в коде. Скрипты автоматизации, правила для фаерволов и др., написанные ИИ, часто содержат скрытые дефекты — жестко зашитые секреты, устаревшие криптографические алгоритмы или избыточные привилегии, которые модель подает как хороший вариант.
⏺Вымышленные эксплойты и CVE. При реверс-инжиниринге или поиске векторов атак модель способна сгенерировать красивый, но полностью фальшивый номер CVE или описать несуществующую уязвимость функции, уводя вас по ложному следу во время инцидента.
⏺Галлюцинации при разборе логов. Загружая дампы трафика, дампы памяти или выгрузки из SIEM-систем на анализ в LLM, легко столкнуться с тем, что модель пропускает критическую аномалию или, напротив, принимает легитимный системный сбой за целенаправленную атаку.

При этом для некоторых задач ее галлюцинации нам и не важны. Например, при генерации картинок (как в этом посте) и видео, где постоянно попадаются то пятая нога у животного, то что-то выдуманное. Но для непрофессионального использования «сойдет».

Нейросети всегда идут по пути наименьшего сопротивления, если им не указать что-то конкретное в промте. Поэтому доверять им что-то ответственное без перепроверки — это лотерея, где на кону стоит ваша безопасность и репутация. LLM оптимизированы под правдоподобность текста, а не под фактическую истину. Они не «знают» матчасть, а прогнозируют статистически вероятные цепочки токенов, из-за чего формулируют опасные ошибки с абсолютной, железобетонной уверенностью.

💬 ИИ — это эффективный ко-пилот, ускоряющий рутину, но финальная ответственность остается на человеке. Готовьте ИИ правильно!

📖 InfoSec Context | TG | Max | Web

👮‍♂️Как вам приручить MITRE ATT&CK
Фреймворк MITRE ATT&CK давно стал стандартом де-факто в мире кибербезопасности, но многие компании до сих пор воспринимают его как сложную «таблицу с кучей квадратиков». На деле это единый словарь и карта, описывающая поведение реальных злоумышленников. Чтобы понять её суть, предлагаю попробовать кратко в ней разобраться на живых примерах.

Фреймворк MITRE ATT&CK делится на три ключевых понятия:
⏺Верхний уровень — Тактика (Tactic) — зачем злоумышленник это делает (цель). Например: Initial Access (Получение доступа) или Execution (Выполнение кода).
⏺Подуровень — Техника (Technique) — как он это делает (метод). Например: Phishing (T1566) или Command and Scripting Interpreter: PowerShell (T1059.001).
⏺Процедура (Procedure) — конкретная реализация в инфраструктуре. Например: хакеры прислали бухгалтеру письмо с вредоносным файлом .iso на корпоративную почту.

Как внедрить применение матрицы у себя:
1️⃣Инвентаризация и маппинг.
Сопоставьте текущие правила детектирования в вашем SIEM, EDR и сетевых экранах с матрицей ATT&CK. Определите, какие именно техники вы реально отслеживаете, а где у вас «слепые зоны». Для визуализации и разметки покрытия удобно использовать инструмент ATT&CK Navigator.
Пример: Вы видите, что у вас настроен детект на запуск PowerShell с подозрительными ключами (техника T1059.001). Значит, этот элемент в матрице ATT&CK у вас «закрыт». А вот техники обхода сетевых экранов могут быть слепой зоной. Для наглядности такой разметки удобно использовать инструмент ATT&CK Navigator.

2️⃣ Фокус на релевантных угрозах
Не пытайтесь закрыть все 600+ техник сразу — это тупик и вам не хватит ресурсов. Изучите отчеты Threat Intelligence по вашей отрасли (финансы, ритейл, промышленность).
Пример: Если на ваш сектор чаще всего нападают через фишинг с вредоносными вложениями и компрометацию учетных записей VPN, сфокусируйтесь в первую очередь на техниках T1566 (Phishing) и T1078 (Valid Accounts).

3️⃣ Постоянное улучшение
Превратите матрицу в рабочий чек-лист ИБ-отдела. По итогам каждого аудита или инцидента пишите новые правила корреляции, закрывающие конкретные пробелы.

4️⃣ Проверяйте
Если у вас есть ресурсы, то организуйте совместные тренировки атакующих и защищающихся.
Пример: Пускай условный атакующий 🧐имитирует технику Lateral Movement через протокол RDP (T1021.001), заходя с рабочей станции рядового сотрудника на сервер. Задача — зафиксировать это средствами ИБ 😎 и проверить, сработало ли оно и выдало ли нужное событие.

Сама матрица все время прирастает новыми процедурами и техниками и действительно сложно читается. Поэтому для лучшего ее понимания можно применить документ Best Practices от CISA. Также PT ведут у себя русскоязычный ее вариант, да с упором на свои СЗИ, но все же ее может быть удобнее использовать.

💬 Внедрение у себя MITRE ATT&CK переводит безопасность из абстрактного «мы ставим антивирус» в измеримый процесс управления рисками. Начните с малого: возьмите один типичный сценарий атаки на вашу компанию и разберите его по косточкам с помощью этой матрицы.

📖 InfoSec Context | TG | Max | Web

🛡 VPN: главный защитник или «черный ход» для злоумышленника?
По свежей аналитике BI.ZONE, 93% компаний используют VPN для удаленного доступа. Кажется, что при отключении прямых доступов к ресурсам и переходе к VPN мы существенно повышаем безопасность. Но на практике плохо сконфигурированный корпоративный VPN часто превращается в главную мишень для хакеров, открывая им прямую дорогу внутрь периметра.

Какие ошибки я бы выделил в топ-3:
⏺Отсутствие MFA (многофакторной аутентификации). Парольная защита в чистом виде сегодня мертва. Если для входа в корпоративную сеть нужен только логин и пароль, злоумышленники легко подберут пароль или возьмут его из базы утечек.
⏺Исключения из правил для удобства. Администраторы для себя, сервисных учетных записей или внешних подрядчиков отключают MFA «для удобства». Для атакующего это идеальная лазейка с максимальными привилегиями.
⏺Избыточные права доступа. Если при подключении пользователя к VPN ему видна вся внутренняя инфраструктура, то хакеру даже не нужно будет повышать привилегии: он будет просто перемещаться внутри всей сети.

Узнали себя 😵‍💫, но все еще думаете, что «Мы слишком маленькие, кому мы нужны?» или «Зачем хакерам домашняя сеть?» — это опасные заблуждения. Частных лиц и малый бизнес чаще всего атакуют автоматизированные скрипты и боты. Если у вас поднят простенький VPN со слабым паролем, вы станете легкой добычей.

Пойдя от обратного, давайте тогда перечислим, чем нам защититься:
⏺Старайтесь дома и на работе везде внедрять MFA. VPN, почта, мессенджеры, личные кабинеты, облака — везде должен быть второй фактор (лучше через приложения-аутентификаторы или аппаратные ключи, а не SMS).
⏺Никаких исключений. Если введена политика MFA, она обязана действовать для всех, включая владельца бизнеса, топ-менеджеров и сисадминов. Один незащищенный «привилегированный» аккаунт обнуляет всю вашу безопасность.
⏺Осторожнее с личными VPN-сервисами. Бесплатные или сомнительные могут собирать и сливать ваш трафик. Для личных задач используйте проверенные коммерческие решения или разворачивайте собственные частные серверы, но с жестким контролем доступа к ним.
⏺Переходить на концепцию наименьших привилегий и давать VPN доступ только к тем конкретным ресурсам, которые необходимы сотруднику.

Это базовый набор, но если позволяют ресурсы и возможности, то можно добавить:
⏺Проверку безопасности самого подключаемого к сети устройства (наличие обновлений, антивируса) перед его допуском в сеть.
⏺По возможности вести мониторинг различных аномалий в поведении пользователя: сканирование сети, обращение к нетипичным ресурсам и т. п.

💬 Закрывайте периметр правильно, и это позволит существенно снизить вероятность и поверхность возможной атаки.🔒

📖 InfoSec Context | TG | Max | Web

🤖 Искусственный интеллект на службе у карманников.
Информационная безопасность давно вышла за рамки классического вредоносного софта. Последние исследования SOCRadar показали, что злоумышленники поставили на поток комбинированные атаки, объединяющие уличные кражи, фишинг и ИИ-агентов для обхода защиты мобильных устройств.

Злоумышленникам в таких атаках помогает AnonyMousKIT — экосистема в модели PhaaS (Phishing-as-a-Service), которая функционирует как минимум с начала 2024 года. Ее главная специализация — помощь преступникам в обходе блокировки активации (Activation Lock) на украденных устройствах Apple и угоне учетных записей Apple ID.

Как устроена схема такой комбинированной атаки?
1️⃣ После кражи злоумышленники извлекают контактные данные владельца украденного iPhone, указанные в режиме пропажи (Lost Mode) или доступные через сервисы геолокации.

2️⃣ Далее жертве приходит фишинговое сообщение якобы от техподдержки Apple со ссылкой на поддельную страницу Find My, которая достоверно имитирует настоящий интерфейс (включая карту с «местоположением» телефона).

3️⃣ Также для убедительности инфраструктура сервиса предоставляет голосовых ИИ-агентов (например, бот «Элис из поддержки Apple», работающий на платформе Vapi на нескольких языках). Бот звонит владельцу, вежливо и убедительно имитируя саппорт, и выманивает код разблокировки устройства, пароль от Apple ID и код двухфакторной аутентификации (2FA).

Автоматизация процесса дает неплохую экономию: по данным исследователей, 200 таких звонков обошлись злоумышленникам всего в $19.24 (около 9,6 цента за попытку). Инфраструктура насчитывает сотни доменов и десятки реселлеров по всему миру.

⚠️ Почему угон аккаунта опасен не только окончательной потерей устройства, с чем пользователь уже смирился? Компрометация учетной записи открывает атакующим доступ к:
⏺Резервным копиям iCloud, где могут храниться сканы документов, личные переписки и пароли.
⏺Связке ключей (iCloud Keychain), содержащей доступы к банковским сервисам, личным и даже рабочим ресурсам.
⏺Корпоративной почте и мессенджерам, если на устройстве была настроена синхронизация.

Какие тут могут быть рекомендации:
⏺Знайте сами и сообщайте своим работникам, что никому и никогда нельзя сообщать коды. Настоящая техподдержка Apple никогда не звонит пользователям лично и не требует назвать код разблокировки устройства, пароль или 2FA-код.
⏺Критически оценивайте любые сообщения и особенно о «найденном» телефоне. Если устройство украдено, не вводите свои учетные данные на сторонних ресурсах по ссылкам из SMS, мессенджеров или писем. Для блокировки и стирания данных используйте только официальный сайт icloud.com.
⏺При активации Lost Mode указывайте альтернативный номер телефона (например, доверенного лица), а не основной номер, привязанный к вашему банку и мессенджерам.
⏺Если сотрудники используют личные смартфоны для работы (доступ к корпоративной почте, CRM, облачным хранилищам компании), компрометация личного Apple ID автоматически превращается в корпоративную угрозу. Используйте решения Mobile Device Management для изоляции рабочей среды от личного пространства сотрудника и возможности удаленной очистки корпоративных данных.

💬 Хотя пока нет информации о работе такого сервиса в РФ, но будьте бдительны, защищайте свои данные🔒 и соблюдайте цифровую гигиену.

📖 InfoSec Context | TG | Max | Web

Старая надежность?
Участвуя в очередном аудите инфраструктуры в одной из организаций, опять столкнулся с устаревшими серверами на Windows 2000 🪟. Кажется, «О ужас!», это старые, не обновленные, дырявые ОС. Но предлагаю на это посмотреть немного с другой стороны.

В эпоху, когда современные ОС перегружены миллионами строк кода, облачными службами интеграции и постоянной телеметрией, то в геометрической прогрессии возрастает и поверхность атаки. На первый взгляд утверждение о том, что система двадцатилетней давности может быть даже безопаснее актуальных релизов, звучит как абсурд. Однако у классического ядра NT 5.0 есть фундаментальные преимущества.

Минимальная поверхность атаки и отсутствие экосистемного шума.
Современные ОС очень сложны. 🌅 Windows 10 или Windows 11 представляют собой целые экосистемы, тесно связанные с фоновыми сервисами синхронизации и постоянной телеметрией, а если им еще нужно работать со старыми историческими системами, то присутствуют еще и «костыли». Каждая из этих подсистем/связей создает потенциальный вектор для кибератаки. В Windows 2000 этого «шума» попросту не существовало.

Простота против изощренности вредоносного ПО.
Конечно, устаревшие версии лишены современных защитных механизмов, но парадокс заключается в другом: современное вредоносное ПО рассчитано на эксплуатацию инфраструктуры облачных служб, PowerShell-скриптов, межпроцессного взаимодействия со службами Windows и манипуляциями с токенами учетных записей. Все эти компоненты в Windows 2000 физически отсутствуют, что делает многие современные эксплойты абсолютно бесполезными для этой архитектуры.

В условиях жесткого контроля периметра старое ядро оказывается неуязвимым к целому классу комплексных сетевых атак, ориентированных на современную цифровую связанность.

💬Конечно же, я не призываю не обновлять старое наследие или начинать его по новой использовать. Тут прошлое нам повторяет урок: безопасность достигается не только набором актуальных заплаток/технологий, но и минимизацией переменных, способных выйти из-под контроля.

📖 InfoSec Context | TG | Max | Web

💲Хакеры скупают чужое прошлое за миллионы долларов
Свежий отчёт исследователей из Infoblox подсветил любопытную и опасную тенденцию: злоумышленники массово скупают просроченные домены вместе с их «чистой» репутацией, старыми бэклинками и остаточным трафиком.
Масштабы впечатляют: только одна группировка под названием Sable Squirrel вложила в покупку таких адресов около $7 млн. и сейчас контролирует более 10 000 доменов. Помимо них, аналитики фиксируют активность «родственных» банд — Stuffy Squirrel, Shady Squirrel и Swiping Squirrel.

Зачем это делается и как работает на практике?
⏺Домены с историей часто обходят защитные фильтры корпоративных систем безопасности, так как раньше они принадлежали легитимным организациям и имеют доверие (в сети группировки попадали даже бывшие адреса проектов General Electric, Procter & Gamble и Sony).
⏺Хакеры запускают на них пиратские ресурсы (например, спортивные трансляции для перенаправления на гемблинг) или используют как командные сервера (C2) для малвари — к инфраструктуре Sable Squirrel привязывали такие семплы, как Quasar RAT, AsyncRAT, DCRat, Remcos и njRAT.

При этом скорость развертывания также высока. 24% купленных доменов начинают работать в день регистрации, а 94% — в течение двух недель.

Для ИБ-специалистов и владельцев бизнеса это важный сигнал: домен с хорошей историей в руках злоумышленников мгновенно превращается в готовый инструмент для фишинга, распространения вредоносного ПО и обмана пользователей, паразитируя на авторитете прежнего бренда.

Что можно предложить в данной ситуации?
⏺Контролируйте жизненный цикл ИТ-активов. Своевременно продлевайте регистрацию всех корпоративных доменов (включая второстепенные лендинги и старые проекты), настраивайте автопродление и мониторинг сроков действия.
⏺Применяйте превентивную защиту и, по возможности, регистрируйте ключевые вариации, опечатки и альтернативные зоны своего бренда, чтобы исключить их перехват злоумышленниками и создание мошеннических копий ваших ресурсов.

💬 В одной из организаций я уже сталкивался с подобными видами мошенничества, и небольшие контрагенты без должных процедур финансового контроля теряли приличные деньги на предоплате.

📖 InfoSec Context | TG | Max | Web

Минцифры планирует «отключить» SMS-авторизацию детям
В новостях активно обсуждают новую инициативу Минцифры, которая может кардинально изменить цифровой ландшафт для 31 миллиона несовершеннолетних россиян. Речь идет о проекте поправок в «Правила оказания услуг телефонной связи», который предлагает запретить отправку SMS (включая авторизационные) на «детские» SIM-карты 🤦‍♂️.

Идея проста: если SIM-карта оформлена на ребенка (или родитель уведомил оператора, что картой пользуется несовершеннолетний), на этот номер перестают приходить любые SMS-рассылки, включая те, что нужны для регистрации в соцсетях, мессенджерах, почте и других сервисах. Исключение — только сообщения от ГИСов.

Какие проблемы вижу:
⏺Инициатива преподносится как мера борьбы с мошенничеством (антифрод). Однако по факту это создает барьер 🧱 для доступа к онлайн-сервисам, которые требуют двухфакторную аутентификацию (2FA) по номеру телефона, и, скорее всего, дети просто откажутся от 2FA, что снизит и без того слабую защиту многих из них.
⏺Как и с любым жестким ограничением, пользователи начнут искать обходные пути 👨‍💻. Скорее всего, дети массово перейдут на использование SIM-карт, оформленных на взрослых. С точки зрения ИБ это ухудшает ситуацию: родители теряют возможность их дополнительной защиты, а сервисы получают ложные данные о пользователях.
⏺Под удар попадают не только развлекательные площадки, но и образовательные платформы, электронные дневники, мессенджеры и любые сервисы, где требуется авторизация.

💬 Попытка решить вопрос безопасности путем простого «отключения» 😡 технологий — это путь в никуда. Вместо формирования культуры цифровой грамотности и развития гибких инструментов государственного/родительского контроля, мы рискуем получить поколение, которое будет вынуждено обходить ограничения, а оно уже это делает, используя менее защищенные и непрозрачные методы идентификации 😡.

📖 InfoSec Context

🚰 Хакеры взломали реестр бенефициаров в Лихтенштейне
Княжество Лихтенштейн столкнулось с беспрецедентной кибератакой. В ночь с 29 на 30 июля злоумышленники взломали государственный реестр бенефициарных владельцев и скопировали конфиденциальные данные о более чем 31 000 компаний, фондов и трастов 👽.

Государство маленькое (41 тысяча человек), и записи явно не только граждан, что станет колоссальным ударом по финансовому сектору 🧐 страны.

Что известно на данный момент?
В руки хакеров попали данные реальных бенефициаров. По предварительным данным, следов модификации или уничтожения информации в системе не зафиксировано.

Правительство оперативно сформировало кризисный штаб под личным руководством 🇱🇮 премьер-министра Бригитты Хаас и министра юстиции Эмануэля Шедлера. Уровень представительства говорит сам за себя.
Сразу после обнаружения аномалии систему полностью отключили от сети 🔌 во избежание дальнейшего ущерба. По заявлениям Ассоциации банкиров Лихтенштейна, сами банковские системы и клиентские счета напрямую не пострадали.

Сейчас новой интересной информации пока нет, но будет интересно рассмотрение такого кейса. Лихтенштейн исторически является одним из ключевых мировых хабов для трастовой индустрии. Утечка такого массива данных ударит по доверию к юрисдикции и вызовет волну комплаенс-проверок, аудитов и исков от бенефициаров, чья конфиденциальность была нарушена.

Пока можно обратить внимание, почему атака может быть такой болезненной:
⏺Реестр бенефициаров создавался в рамках исполнения жестких международных норм по борьбе с отмыванием денег (AML). Сведение всех бенефициаров в единую централизованную базу неизбежно превращает ее в «лакомый кусочек» для киберпреступников.
⏺Изоляция контура (отключение реестра от сети) и привлечение высшего руководства страны к расследованию — абсолютно адекватные действия кризис-менеджмента. Однако главный вопрос остается открытым: каким был вектор первоначального проникновения и сколько времени злоумышленники находились внутри закрытого контура до момента выгрузки?

💬 Следим за развитием событий 🍔. Очевидно, что это происшествие спровоцирует определенный пересмотр стандартов ИБ для государственных реестров финансовой прозрачности по всей Европе.

📖 InfoSec Context

📱 Удалил данные с телефона при досмотре: преступление или защита приватности?
Недавно в поле зрения попал свежий кейс: мужчина при прохождении пограничного контроля в США 🇺🇸назвал сотрудникам спецслужб специальный код для GrapheneOS 🌇, который запустил полный вайп (необратимое удаление) всех данных на устройстве. Теперь местная прокуратура пытается вменить ему «умышленное уничтожение имущества, чтобы помешать конфискации».

В США инструменты противодействия расследованию работают жестко и стало интересно посмотреть как к подобным сценариям относится российская правовая система. ✍️

Зачем нужны «тревожные» функции?
Кастомные защищенные ОС вроде GrapheneOS позволяют увеличить приватность: функции auto-wipe (очистка после серии неверных входов) или duress PIN (специальный код принуждения, стирающий пользовательские данные) — стандарт де-факто для параноиков безопасности и людей, защищающих конфиденциальные данные.

Но что делать, если устройство требуют передать или разблокировать здесь и сейчас? В отличие от американской практики, где стирание улик может стать самостоятельной тяжелой статьей, в РФ 🇷🇺 подход строится на балансе процессуальных статусов и конституционных норм:
⏺Право на защиту и ст. 51 Конституции РФ. Если вы удаляете личные данные на своем собственном смартфоне (заранее, удаленно через облако или иным способом), самостоятельной уголовной или административной ответственности за это нет. Гражданин не обязан содействовать следствию в отношении самого себя, хранить компромат или предоставлять пароли от личного устройства.
⏺Грань с административным правонарушением (ст. 19.3 КоАП РФ). Ситуация меняется кардинально, если вы начинаете физически уничтожать телефон или экстренно стирать данные на глазах у сотрудников во время официального досмотра или обыска вопреки их прямому законному требованию. За это наступает ответственность за неповиновение законному распоряжению сотрудника (штраф либо арест до 15 суток).
⏺Корпоративные и чужие гаджеты. Если уничтожается не ваш личный аппарат, а рабочий (корпоративный) телефон или устройство другого лица, действия могут квалифицироваться как умышленная порча чужого имущества (ст. 167 УК РФ), если собственнику причинен значительный ущерб.

Резюмируя, можно сказать, что технологии защиты данных и функции экстренной очистки — это полезный инструмент цифровой гигиены. Российское законодательство прямо не запрещает гражданину защищать свою частную жизнь и не обязывает раскрывать пароли от личных устройств.🧐

💬 При этом основным выводом может быть: цифровая гигиена должна быть превентивной. Пытаться устроить «цифровой армагеддон» в руках у оперативных сотрудников в моменте — прямой путь к административному делу о неповиновении, тогда как заранее настроенные политики безопасности и удаленная очистка остаются законным инструментом защиты данных.

📖 InfoSec Context

🧠 Shadow AI уже здесь: как одна загрузка в ИИ стоит карьеры и миллионных выплат
Если посмотреть на свежие отчеты от подразделений ИБ, то очевиден тренд: средства ИБ в различных компаниях все чаще фиксируют обращения работников к внешним ИИ-сервисам 🎑.

Запросов множество, от безобидных: «напиши код» и «подготовь справку», до «сделай свод...», «проанализируй ТЗ». Казалось бы, сплошная оптимизация и рост продуктивности 📈, но на практике это превращается в один из главных каналов неконтролируемой утечки конфиденциальной информации (Shadow AI).
И пока многие продолжают жить с иллюзией «да кому нужны наши внутренние таблички», судебная практика уже не на их стороне.

Свежий случай прекрасно иллюстрирует масштабы бедствия. Директор по продажам крупной московской инженерной компании «ускоряла работу» с помощью популярной китайской нейросети🙂‍↕️ DeepSeek и загружала конфиденциальные корпоративные документы прямо в публичный ИИ-сервис. Работодатель выявил утечку через средства контроля, уволил руководителя за разглашение коммерческой тайны.

Итог судебного разбирательства максимально показателен:
⏺Суд встал на сторону компании. Никакой производственной необходимости переносить внутренние данные на сторонние ИИ-ресурсы у сотрудницы не было.
⏺Увольнение признано полностью законным, а все финансовые требования экс-директора отклонены.

Важно запомнить раз и навсегда — всё, что вы отправляете в публичный ИИ, перестает быть конфиденциальным. Эти данные уходят на чужие сервера, используются для дообучения моделей или становятся доступны третьим лицам от самого провайдера ИИ.

Специалистам ИБ и ИТ важно не забывать:
💬 Настраивать DLP и сетевые шлюзы на мониторинг и блокировку запросов к популярным публичным ИИ-сервисам.
💬 Вводить в организации четкую политику использования ИИ и обучения пользователей.
💬 Если компании необходим ИИ для работы с закрытым контуром — разворачивайте локальные корпоративные LLM-модели или используйте защищенные корпоративные API-шлюзы с гарантией неиспользования данных для обучения.

💬 Как у вас, сотрудники до сих пор пытаются «скармливать» нейросетям исходники и внутреннюю отчетность или бизнес уже выстроил жесткие запреты?

📖 InfoSec Context

🥛 Как шифровальщики остановили молочный бизнес Coca-Cola
Не прошло и трех дней, как в копилку наших ИБ-кейсов добавился еще один показательный инцидент, на этот раз из производственного сектора. Кибератака парализовала выпуск молочной продукции бренда Fairlife (принадлежит Coca-Cola) на территории США.

В данном инциденте злоумышленники получили несанкционированный доступ к инфраструктуре компании 🚰, затронув ИТ-системы, напрямую связанные с производством. При этом, инцидент признается компанией настолько серьезным, что Coca-Cola оперативно уведомила о нем Комиссию по ценным бумагам и биржам США (SEC).

Сейчас компания временно остановила производство в США для сдерживания угрозы и восстановления. Показательно, что заводы в Канаде продолжают работать — это говорит о географической изоляции сетей. Активирован план реагирования, привлечены сторонние ИБ-криминалисты, уведомлены правоохранительные органы.

Производственные площадки — лакомый кусок для хакерских группировок. Чаще всего атака начинается в классическом офисном IT-сегменте (фишинг, уязвимость на VPN-шлюзе, скомпрометированные учетные данные). Затем злоумышленники совершают горизонтальное перемещение и проникают в святая святых — сеть АСУ ТП 🏭. Рекомендации для ИБ все те же, как и в предыдущем посте.

💬 Всегда разделяйте сети офиса и производства. Чем жестче правила разделения, тем меньше головной боли 🙄

📖 InfoSec Context

⚠️ Угроза в доверенной среде: ViPNet (ИнфоТеКС)
16.07.2026 от компании «ИнфоТеКС» появилось уведомление и технические детали нового вектора целевой атаки. Он оказался весьма изощренным: злоумышленники используют легитимные механизмы доставки обновлений для распространения вредоносной нагрузки. Проблема затрагивает ПК ViPNet Client 4 и узлы с ViPNet Administrator.

Атака реализуется через транспортный протокол MFTP. Ключевое условие для успешного вектора — предварительная компрометация узла с ViPNet Administrator в доверенной сети:
📩 Со скомпрометированного управляющего узла через межсетевое взаимодействие рассылается специально сформированный конверт. Он имитирует легитимное обновление ПО.
📦 Поддельный пакет содержит вредоносную нагрузку, которая эксплуатирует уязвимость обработки относительных путей.
🤖 Успешная эксплуатация приводит к нарушению целостности среды, локальному повышению привилегий (Privilege Escalation) и выполнению произвольного кода (RCE) на атакуемом узле.

Если в вашей инфраструктуре используются продукты ViPNet, реагировать нужно оперативно. Это особенно критично, если ваша сеть связана с другими защищенными сетями, за администрирование которых вы не отвечаете и не можете гарантировать их безопасность.

Что делать:
1. Необходимо обновить компоненты инфраструктуры до следующих версий:
⏺ViPNet Client 4 (Сертифицированная сборка): до версии 4.5.3 (сборка 65211) или выше.
⏺ViPNet Client 4 (Релизная сборка): до версии 4.5.5 (сборка 24733) или выше (вендор опубликует в ближайшее время).
⏺ViPNet Administrator: до версии 4.6.11.5113 или выше.
2. Обязательно убедитесь в отсутствии признаков заражения на ваших узлах:
⏺Проведите сканирование файлов с помощью YARA-правил, подготовленных вендором (используйте официальную «Инструкцию по применению подготовленных YARA-правил с использованием утилиты YARA»).
⏺Если YARA-сканирование дало положительный результат или вы зафиксировали подозрительную сетевую активность с узлов ViPNet на Координаторы и элементы инфраструктуры — незамедлительно обращайтесь в службу технического сопровождения «ИнфоТеКС».

💬 Доверенные межсетевые взаимодействия — это не гарантия безопасности, если скомпрометирован управляющий центр на стороне партнера. Проверяйте свои узлы, обновляйтесь и будьте начеку.

📖 InfoSec Context

🍗 Эффект домино в цепочках поставок: Как взлом логистики оставил Японию без фастфуда
Свежий инцидент, произошедший с крупнейшим оператором холодильной логистики Японии Nichirei Logistics Group, наглядно демонстрирует то, о чем мы постоянно говорим бизнесу: сегодня кибератака на одно B2B-звено способна положить на лопатки целые отрасли.

Кейс интересен не столько самим фактом взлома, сколько сокрушительным каскадным эффектом, который он вызвал.

13 июля компания Nichirei Logistics зафиксировала несанкционированный доступ к своим серверам. Реакция компании была классической: чтобы сдержать угрозу, они жестко отключили ключевые системы 🔌.

Бизнес-импакт оказался колоссальным:
⏺Остановлена работа 140 холодильных распределительных центров по всей Японии (а это 5000 корпоративных клиентов).
⏺KFC Japan заявили о риске закрытия 1300 ресторанов 🍴 из-за нехватки курицы для фирменного рецепта.
Пострадали другие сети: Hotto Motto, Kura Sushi, супермаркеты Aeon. Отгрузки просто встали.
⏺В довершение всего, Nichirei подтвердили, что на затронутых серверах хранились персональные данные, и сейчас они ждут подтверждения факта утечки.

Официальные технические детали атаки ожидаемо не раскрываются. Однако, исходя из общей картины, похоже на классический почерк Ransomware-атаки.

Логистика — идеальная мишень, так как у нее минимальная толерантность к простоям (RTO измеряется часами, а не днями). Претензии клиентов могут легко вынудить жертву быстрее заплатить выкуп.

Если ваш бизнес зависит от цепочек поставок, этот инцидент — отличный повод проверить свои процессы:
💬 Вы можете выстроить идеальную инфраструктуру, но вас потопит слабый подрядчик. KFC не были взломаны, но они остались без продукта. Внедряйте жесткие SLA по безопасности для критичных поставщиков, требуйте от них результатов аудита и наличия планов аварийного восстановления.
💬 Создавайте планы непрерывности. Нужна диверсификация и «ручные» сценарии работы.
💬 Сегментируйтесь. Если шифровальщик попал в один сегмент, он не должен иметь технической возможности перекинуться на системы управления складом или производством.
💬 У ИБ должны быть полномочия при реагировании на инцидент. Nichirei приняли смелое решение «рубануть рубильник». У ИБ-команды должен быть согласованный план и мандат на остановку бизнес-процессов для сдерживания заражения, пока не зашифровали бэкапы.

💬 Кибербезопасность уже давно вышла за пределы компьютеров — теперь она напрямую влияет на то, сможете ли вы купить обед.

📖 InfoSec Context

📝 Логи веб-серверов: где искать следы хакеров?
Когда речь заходит о расследовании атак, многие сразу вспоминают EDR, SIEM или сетевые дампы. Но один из самых ценных источников информации зачастую лежит буквально на поверхности — логи веб-сервера. Коллеги, признавайтесь, как часто вы реально разбираете access.log? 🤔

Каждый 🌐 HTTP-запрос оставляет след. И если научиться читать эти следы, можно обнаружить атаку еще до того, как она приведет к компрометации. Коллеги из BI.ZONE выпустили очередную техническую статью, где на практических примерах разбирают анализ логов nginx и IIS, показывают, как выглядят распространенные техники злоумышленников 👹 и на какие поля логов стоит обращать внимание в первую очередь. Материал подойдет всем, кто хочет увереннее работать с журналами веб-серверов.

Что стоит искать в первую очередь?
⏺Path Traversal — попытки получить доступ к файлам за пределами веб-каталога (../, URL-кодированные варианты и т. п.). Обращения к /.git, /.env, /admin — автоматические сканеры ищут, что бы слить или куда зайти.
⏺Фаззинг — большое количество запросов к различным URL с целью поиска скрытых страниц, API или уязвимостей.
⏺Подозрительные User-Agent — автоматизированные сканеры, утилиты или вовсе пустые значения.
⏺Всплески ошибок 404/403/500 — часто сопровождают разведку и подбор путей.
⏺Необычные HTTP-методы (PUT, DELETE, TRACE и др.), если они не используются вашим приложением.
⏺Повторяющиеся запросы с одного IP, аномальные параметры URL, длинные строки запроса и признаки инъекций.

Инструменты первичной аналитики (без тяжелого софта).
Когда под рукой только консоль и нет SIEM 👨‍💻 или времени ждать, пока отрисуются дашборды в SIEM, на помощь приходят классические bash-утилиты:

grep "IP_злодея" access.log

— трассируем конкретного нарушителя.

awk '{print $1}' access.log | sort | uniq -c | sort -nr

— находим самые "шумные" IP-адреса (привет, ботнеты и сканеры).

cut -d '"' -f 2 access.log | sort | uniq -c | sort -nr

— смотрим, какие точки атакуют чаще всего.

grep -E "500|502|503|504|404" access.log

— Позволяет быстро выбрать из лога все события с кодами ошибок: серверными (500, 502, 503, 504) и клиентскими (404).

Важно понимать, что каждый отдельный запрос может выглядеть безобидно. Но если смотреть на картину целиком 🔎 - последовательность действий, частоту запросов, коды ответов и поведение клиента — становится заметен сценарий атаки.
Именно поэтому анализ веб-логов остается одной из базовых ✍️ компетенций аналитика SOC. Это не только помогает расследовать уже произошедшие инциденты, но и позволяет своевременно обнаружить разведку, сканирование и первые этапы атаки.

💬 Веб-логи — это идеальный инструмент для ретроспективного анализа и расследования. Но не стоит пытаться использовать их как основной механизм блокировки атак в реальном времени. Для фильтрации SQLi, XSS и др. на лету нужен WAF. Логи помогают понять, что произошло, а WAF — не дать этому произойти.

📖 InfoSec Context

⏺Успеть до 6 июля. Российские сервисы массово отключают вход через Apple ID и Google
Многие из вас уже наверняка заметили странные пуш-уведомления от 📱 VK, 📱 Кинопоиска, Литреса и других популярных площадок. Сервисы просят в срочном порядке привязать номер телефона.

Что же происходит? С 6 июля вход на отечественные ресурсы через зарубежные аккаунты (Apple ID, Google, Facebook и др.) будет закрыт. Рынок готовился к этому еще с 2024 года, после внесения изменений в 149-ФЗ "Об информации, информационных технологиях и о защите информации" (пункт 8.10).
В июне Госдума приняла поправки в КоАП, а Президент их подписал. Теперь за авторизацию пользователей через иностранные сервисы владельцам сайтов грозят вполне реальные штрафы:
⏺ до 700 000 ₽ для юрлиц;
⏺ до 50 000 ₽ для должностных лиц;
⏺ до 20 000 ₽ для физлиц.
Важный нюанс: обычных пользователей штрафовать за вход через Google или Apple не будут. Закон бьет по владельцам площадок. Но бизнес, как известно, не любит штрафы, поэтому вход теперь часто возможен только по российскому номеру, через Госуслуги или Единую биометрическую систему.

Что это значит с точки зрения ИБ и приватности? Тут есть несколько серьезных рисков:
1️⃣ Конец относительной анонимности. Apple ID и Google позволяли использовать отдельные email-адреса без жесткой привязки к SIM-карте. Теперь номер телефона становится главным и единственным ключом от всех дверей.
2️⃣ Риск SIM-свопинга. Если ваш номер - это единственный фактор входа и восстановления, его угон (через уязвимости в салонах связи или социальную инженерию) означает мгновенную потерю всех ваших аккаунтов: от почты до банков.
3️⃣ Сквозная идентификация. Государство и операторы получают возможность легко связывать ваши действия в разных сервисах (от покупки книг до просмотра кино) с вашей реальной личностью через один и тот же номер телефона.

Что предлагаю делать:
✅ Привязать номер. Если вы не хотите потерять доступ к купленным фильмам, книгам, подпискам и сохранениям игр до 6 июля - сделайте то, что просят сервисы. Игнорировать нельзя, доступ действительно отрежут.
✅ Защитить сам номер. Поставьте запрет на действия с номером (замена SIM-карты, перевод на другого оператора, смена владельца). Это базовая защита от SIM-свопинга, но ее для большинства операторов можно подключить только по заявлению в салоне связи.
✅ Настроить 2FA. Везде, где это возможно, включите двухфакторную аутентификацию. Желательно не через SMS (их можно перехватить), а через приложение-аутентификатор.
✅ Разделить контексты (для параноиков). Если вы не хотите светить свой личный номер везде — заведите отдельную виртуальную сим-карту или eSIM исключительно для регистраций в сервисах.

💬 На всякий случай напомню, изменения не касаются аутентификации только на отечественных платформах. Как вам такие изменения? Уже привязали номера или пока ждете последнего дня?

📖 InfoSec Context