Друзья, с праздником!

📖 InfoSec Context

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

В условиях стремительного развития ИТ и оптимизации бюджетов ИБ, крайне важно учитывать, что:
⏺Приоритизация важнее количества
Уязвимостей много, но эксплуатируются лишь некоторые 📉. Поэтому важно первоначально фокусироваться на тех, которые уже используются в атаках, а возможно и соответствуют тактикам конкретных групп.
⏺Какие угрозы реальны
Безопасность должна строиться вокруг реальных угроз (групп атакующих, их инструментов и методов), а не абстрактных рисков (как в рекламе КАСКО, где на машину падает спутник 🛰).
⏺Необходимо продумывать возможные связки
Нужно учитывать, какие уязвимости есть в системе 🚰, какими техниками они могут быть реализованы и как они комбинируются в реальных сценариях атак.
⏺Важен контекст
Одна и та же уязвимость/система может быть критичной для одной компании, но совершенно незначимой для другой.
⏺Киберразведка помогает предвидеть
Она дает информацию об актуальных угрозах и средствах злоумышленников, предсказывать возможные атаки и быстрее реагировать на инциденты.

💬 Эффективная защита — это не «залатать всё подряд», а анализировать реальные сценарии атак и закрывать те слабые места, которые злоумышленники действительно используют.

📖 InfoSec Context

🙂 9 мая
Праздник, посвящённый Дню Победы, символизирует победу над фашизмом и имеет глубокое историческое значение.

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

С праздником!

📖 InfoSec Context

🔐 Защита учетных данных в среде Windows.
Различные уязвимые конфигурации ПК/Сервера позволяют злоумышленнику украсть учетные данные и развить атаку.

Какие варианты харденинга возможны для снижения рисков:
1️⃣Отключить WDigest. Этот старый механизм аутентификации Windows 🌅может хранить пароль пользователя в памяти почти в открытом виде.
2️⃣Защитить LSASS (Local Security Authority Subsystem Service) — службу подсистемы локальной безопасности в операционной системе Windows. Необходимо включать RunAsPPL для защиты процесса LSASS 🤖. Это не абсолютная защита, но резко повышает сложность атаки.
3️⃣Использовать Credential Guard. Данная функция защищает от атаки типа Pass-the-Hash (PtH) и Pass-the-Ticket (PtT), при которых злоумышленники пытаются получить хэши паролей 🔐 или билеты Kerberos для дальнейшего проникновения в сеть.
4️⃣Убрать лишние привилегии у пользователей и разделить полномочия администраторов. Не должно быть администраторов с полным набором полномочий и доступов 👹.
5️⃣Настроить лимиты для RDP‑сессий. RDP используется администраторами, и настройка принудительного завершения неактивных сеансов предотвращает их сохранение на сервере. Это сокращает время доступности учетных данных администратора после завершения работы.
6️⃣Защитить механизмы аутентификации: отказ от NTLM, отключить старое RC4 шифрование в Kerberos, включение администраторов в группу Protected Users (настройка может усложнить их работу) 🤩.
7️⃣Осуществлять управление локальными и сервисными учетными записями. Необходимо применять LAPS (обеспечивает уникальный пароль локального администратора на каждом устройстве) и gMSA (пароль автоматически генерируется и регулярно ротируется средствами AD).
8️⃣Мониторинг и внедрение наложенных средств защиты 🛰.

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

📖 InfoSec Context

Vulners
Управление уязвимостями в ландшафте сложно представить без получения информации об их наличии и оценки особенностей воспроизводства. Для этих целей всегда можно использовать специализированное ПО анализа, но зачастую у небольших предприятий такого нет или же ИБ хочется получить больше контекста по уязвимости 😎.

В данном случае нам на помощь может прийти ресурс https://vulners.com/ (не знаю как у вас, но мне доступен с VPN). Ресурс является большой БД 💽 уязвимостей и агрегирует данные из более чем 2️⃣0️⃣0️⃣ источников, включая популярные другие БД уязвимостей, вендорские бюллетени, эксплойты, публикации на тематических ресурсах и данные из программ bug bounty.

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

Одним из плюсов ресурса является представление данных в виде графа 🧛‍♂️ связанных и скоррелированных между собой, что позволяет проводить всесторонний анализ уязвимостей с учётом дополнительных метрик и доп. информации. База не заменяет сканеры уязвимостей, а неплохо дополняет их.

💬 С учётом взрывного роста атакующих ИИ-инструментов 🤖 и ускорения использования опубликованных уязвимостей не грех пользоваться дополнительным бесплатным источником.

📖 InfoSec Context

🤪 Кибербезопасность детей
Дети по-прежнему входят в группу повышенного риска среди жертв интернет-мошенников.

Почти каждый пятый ребёнок (18%) в возрасте 5–17 лет уже сталкивался с мошенническими схемами или оказывался в потенциально опасных ситуациях в цифровой среде.
Несмотря на то, что современное поколение легко осваивает гаджеты и приложения, недостаток жизненного опыта делает детей уязвимыми: их проще ввести в заблуждение, запугать или манипулировать ими в интересах злоумышленников.

Топ-3 угрозы для детей в 2026 году:
1️⃣Обман в игровых сервисах (лидирующая схема)
Мошенники предлагают выгодную покупку внутриигровой валюты, скинов или аккаунтов. Ребёнок оплачивает «товар», но ничего не получает — деньги уходят безвозвратно.
2️⃣Кражи «чужими руками» (~25% всех инцидентов)
Злоумышленники психологически давят на ребёнка: угрожают, что его родителям грозит уголовное дело (например, за «финансирование терроризма»). Испуганный ребёнок, желая защитить близких, выполняет указания: передаёт ключи, показывает места хранения ценностей или даже участвует в хищении.
3️⃣Вербовка в схемы «дропперов»
Под предлогом «простого заработка» школьников уговаривают переводить сомнительные суммы на другие карты или зарубежные кошельки. По данным ЦБ РФ, каждый пятый дроппер — несовершеннолетний.

Последствия успешной атаки могут быть серьёзнее, чем кажется:
⏺Потеря денег
⏺ Уголовная ответственность — если ребёнку уже исполнилось 14 лет и он стал соучастником мошеннической операции, закон может привлечь его к ответу.

Как защитить ребёнка?
✅ Открытый разговор — обсуждайте с детьми примеры мошенничества, учите распознавать подозрительные ситуации.
✅ Кибергигиена — простые правила: не переходить по сомнительным ссылкам, не сообщать личные данные, проверять информацию.
✅Доверие — дайте ребёнку понять: если он попал в беду, вы поможете, а не осудите.

💬 Профилактика — надёжнее любого антивируса.

📖 InfoSec Context

👨‍💻 Опять разработчики...
Уровень автоматизации, замена людей ИИ и массовые увольнения разработчиков не прошли бесследно. В последнее время стали часто появляться новости об их ошибках по опубликованию того, что не должно было публиковаться.

И вот новый факап в отношении движка Chromium: инженеры Google 📡случайно раскрыли детали критической уязвимости, которая оставалась без исправления почти четыре года. Речь идёт о баге, позволяющем запускать JavaScript-код в фоновом режиме — даже после закрытия браузера, а в отдельных случаях и после перезагрузки устройства 😳.

Предыстория
Проблему выявили ещё в конце 2022 года. Техника позволяет превратить браузер жертвы в «постоянного участника JS-ботнета». Да, JavaScript не получает прямого доступа к файловой системе, почте или операционной системе. Однако он может выполнять всё, что разрешено браузеру: проксировать трафик, участвовать в DDoS-атаках, автоматически открывать сайты, майнить криптовалюту 💰 или отслеживать активность пользователя.

Особенно тревожно ситуация выглядит в Microsoft 🌅 Edge: если раньше при эксплуатации уязвимости хотя бы появлялось всплывающее окно загрузок, то в новых версиях браузера этот индикатор исчез. В итоге вредоносный скрипт работает практически незаметно, не выдавая своего присутствия.

Самое удивительное в этой истории — временной масштаб. Ошибка оставалась без патча более 42 месяцев. Видимо, так как баг не нарушает классические границы безопасности браузера и не даёт прямого доступа к системе, то в Google могли недооценить его реальную опасность.

Текущая ситуация
Разработчики случайно пометили проблему как исправленную ещё в феврале 2026 года, однако патч так и не был выпущен. Из-за этого через 14 недель система Chromium Issue Tracker автоматически сняла ограничения и сделала отчёт об уязвимости публичным — вместе с рабочим PoC-эксплоитом. Вскоре запись снова скрыли, но то, что появилось в сети уже остается в ней 😄.

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

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

📖 InfoSec Context

🌇 Android теперь распознаёт фейковые звонки
Вам может позвонить «руководитель» и голос будет один в один, но это мошенник 👽. Звучит как будто сюжет триллера, но это наша новая реальность. С развитием и доступностью ИИ злоумышленники научились легко клонировать голоса, и если им удается подделать входящий номер, то не составит труда выманивать деньги у своей цели.

02.06.2026 📡 Google заявил, что для борьбы с подобным запускает защиту от поддельных звонков на телефонах Android, которая помогает распознать мошенников в реальном времени.

В чём проблема?
Мошенничество с имперсонацией (выдача себя за другое лицо, действие под именем или личностью другого человека без его разрешения) уже входит в перечень главных источников финансовых потерь (Интерпол заявляет о 400+ млрд. $ убытков в мире).

Стандартно злоумышленники комбинируют два приёма:
⏺Спуфинг номера — звонок отображается как от вашего контакта;
⏺ИИ-дипфейк голоса — голос звучит как у близкого человека или коллеги. Современные аудио-дипфейки практически неотличимы от настоящего голоса.

Что может новая защита?
На данный момент функция включена и работает по умолчанию в приложении Phone by Google следующим образом:
1️⃣Когда вам звонят, устройства отправляют друг другу зашифрованное сообщение подтверждения через технологию RCS. Это как «цифровое рукопожатие»: если звонок настоящий — устройства «узнают» друг друга.
2️⃣Если подтверждение не прошло, то телефон выдаст сообщение: «Возможно, это мошенник. Рекомендуется завершить вызов».

Как заявляется, всё происходит в реальном времени и со сквозным шифрованием. Понятно, что компетентные органы будут иметь свой корневой сертификат 😄.
Соответственно, функция работает, когда оба контакта используют приложение Phone by Google. Требуется Android 12+ и установленные приложения: Phone by Google, Contacts, Google Messages.

Функция построена на открытом стандарте RCS, поэтому другие производители и разработчики тоже смогут внедрить эту защиту. Ну а пока пользователи также могут использовать Phone by Google из Play Market.

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

📖 InfoSec Context

👨‍💻 «Меня почти взломали на собеседовании»
В прошлом году разработчик опубликовал в сети свою историю, которая должна насторожить каждого. Как он заявляет: «Я был в 30 секундах от того, чтобы запустить малварь на своём компьютере». Данная история показывает, что даже опытные специалисты не застрахованы от изощрённых атак.

Для автора все началось с сообщения от компании Symfa (реальная компания, реальный профиль, 1000+ контактов). Сообщение было в профессиональном тоне 💼 с чётким предложением на частичную занятость.
Перед интервью «рекрутер» прислал ссылку на «тестовое задание»: Bitbucket-репозиторий с тестовым проектом (React + Node.js):
⏺Чистая структура, грамотный README, документация;
⏺Даже корпоративное фото «в тему» — всё как у настоящих компаний;
⏺Дедлайн: 30 минут на ознакомление.

Так как возникла намеренная срочность, то автор решил быстро «пощупать» код — без песочницы, без Docker. Но перед запуском автор спохватился и задал простой вопрос своему AI-ассистенту (Cursor): «Проверь этот код на подозрительные активности: чтение файлов, доступ к криптокошелькам и т. п.»

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

💬 Данная история нам напоминает, что в цифровой среде опасность может быть где угодно. Используйте эти правила, они не будут лишними:
1️⃣ Всегда используйте песочницу. Docker, VM, WSL - любой изолированный запуск. Никогда не тестируйте чужой код на основной машине.
2️⃣ Сканируйте код перед запуском. Даже 30-секундный запрос к AI-ассистенту («Есть ли здесь подозрительные паттерны?») может спасти ваши данные.
3️⃣ Верифицируйте всё. Реальный профиль ≠ реальный человек. Реальная компания ≠ реальное предложение. Проверяйте домены, почту, контакты.
4️⃣ Доверяйте интуиции. Если вас торопят, давят дедлайном или просят «просто запустить и посмотреть» — это красный флаг 🚩
5️⃣ Обфускация — признак угрозы. Массивы байтов, eval(), new Function(), динамические импорты без явной необходимости — повод остановить и перепроверить.

📖 InfoSec Context

🇷🇺 Поздравляю вас с Днем России!
Это праздник нашей свободы и единства. Но пока вся страна видит привычные сервисы и работающие системы, именно ИТ и ИБ знает, сколько труда стоит за их стабильностью, безопасностью и доступностью.

Поэтому пусть ваш фаервол будет крепким, код — чистым, а угрозы — предотвращенными!

📖 InfoSec Context

💬 Как часто утекают ваши данные
У многих есть тот самый пароль, который они используют ВЕЗДЕ. Иногда это что-то простое, ну, вы знаете: день рождения кота, кличка собаки, "123456" или "qwerty". Иногда что-то особо сложное, но сильно постоянное. Сегодня хочу напомнить вам о ресурсе, который расскажет, насколько это была плохая идея.😁

Кто не знал, то знакомьтесь, возможно, это будущий источник ваших волнений — Have I Been Pwned

Что это и зачем оно нужно? Это самый известный в мире сервис, который покажет, утекли ли ваши личные данные и в каком сливе они засветились.
Как им пользоваться?
⏺Почта. Вбиваете свой email, и сайт выдает список всех сервисов, которые когда-либо «теряли» вашу почту. Спойлер: если вы в интернете больше пары лет, вы «засветились» минимум в десятке утечек (привет, LinkedIn, Adobe, Canva и другие).
⏺Проверка пароля. Вкладка покажет, сколько раз ваш "гениальный и очень сложный" пароль уже гулял по даркнету. (Хотя авторы и говорят, что все безопасно и поиск идет по хэшу, так что сам ваш пароль создатели не видят, но подозреваю, что такие хэши могут собираться в "радужные таблицы").
⏺Режим «Уведомить меня». Можно параноить и подписаться на уведомления (Create Alert). Как только хакеры сольют базу очередного сервиса, в котором вы зарегистрированы, вам на почту придет письмо.

💬Главная польза сервиса в том, что он лучше любых нравоучений мотивирует наконец-то перестать использовать один и тот же пароль для рабочей почты, Госуслуг и форума любителей хомяков. Делитесь в комментариях, в скольких утечках вы оказались! У кого самый «богатый» список? 👇

📖 InfoSec Context

🌇 Android: «Отображение поверх других окон»
Бывает такое, что после скачивания игры/калькулятора/фонарика (подчеркни нужное) из Google Play 📱через некоторое время с банковской карты исчезают деньги...

Магазин приложений Google Play 📱 нельзя считать полностью безопасным. Контент, конечно, проверяется, но в нем можно найти множество приложений-пустышек: «ускорители телефона»🚀, фонарики 🔦, читалки и пр. В самом приложении нет вредоносного кода, и проверка антивируса магазина проходит без проблем, но после установки приложение тихо скачивает себе нужные дополнения, которые и являются вредоносными.👽

При установке у таких «приложений» следует внимательно рассматривать запрашиваемые разрешения. Например, при установке приложение запросило разрешение «Отображение поверх других окон»? Звучит невинно и обыденно. Но именно это разрешение делает приложение опасным🤖

Приложение, находясь в фоне, немедленно активируется при открытии приложения банка, и за долю секунды поверх настоящего экрана приложения появляется его точная копия. Вы вводите свой пароль, уверенные, что находитесь в безопасном приложении банка, а он сразу оказывается у мошенников. Попутно им также перехватываются SMS или push-уведомления от банка.

Как такое предотвратить
Для начала не качать неизвестные приложения и проверять разрешения для имеющихся 🤪. Также поищите настройку по ключевому слову «поверх», и Android 🌇 сразу выдаст вам нужное меню. Обычно данная настройка скрывается в меню: Настройки ➜ Приложения ➜ Особый/специальный доступ/права ➜ "Отображение поверх других приложений".

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

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

📖 InfoSec Context

⚓️ Эффект якоря: как первая информация меняет наше восприятие реальности

Друзья, сегодня немного полезной теории. В психологии существует феномен, который называется «эффектом якоря». Он заключается в том, что первая информация, которую мы получаем, становится точкой отсчёта для всех последующих оценок и решений. Даже если эта информация случайна или недостоверна, она продолжает влиять на наше восприятие 😵‍💫.

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

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

Сначала человеку рисуют максимально серьёзные последствия: уголовное дело, многомиллионный ущерб, потерю всех накоплений. Это и есть якорь ⚓️ — точка отсчёта, искажающая восприятие. После этого любые действия мошенников кажутся логичными и единственно верными, так как улучшают ситуацию.

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

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

Именно поэтому мошенники боятся пауз, перепроверки и обращения к независимым источникам. Без якоря их сценарий теряет убедительность.

💬Проверьте на себе: увидев отличную распродажу в 70% и почувствовав желание получить выгоду, остановитесь и проверьте цену в других источниках. В 99% случаев вы найдете эту «распродажную» цену и без самой распродажи. Остерегайтесь мошенников!

📖 InfoSec Context

🗺 Интерактивная карта Kubernetes для обеспечения безопасности
Недавно я узнал о проекте, который предлагает интерактивную шпаргалку по безопасности в 👩‍💻 Kubernetes. Называется kubesec-diagram и позволяет наглядно понять и визуализировать аспекты безопасности в K8s-кластере.

Чем хорош инструмент:
🟢 Интерактивность: при клике на любой компонент (например, Cluster, Deployment, Ingress, Pod и другие) появляются конкретные советы по безопасности и чек-листы.
🟢Схема наглядно демонстрирует, как компоненты взаимодействуют друг с другом, где находятся границы доверия и какие уровни защиты нужно выстраивать.
🟢Позволяет систематизировать свои знания по безопасности Kubernetes.

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

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

📖 InfoSec Context

☁️ Как защитить облачную инфраструктуру: разбор главных ошибок и лучших практик
Облачные технологии - это удобно и сейчас, с ростом стоимости оборудования, становится популярно, но они сильно увеличивают поверхность атаки. Команда BI.ZONE выпустила очередной интересный гайд по защите облачных сред.
Сразу спойлер: главные риски связаны не с уязвимостями самих облачных платформ, а с ошибками конфигурации и человеческим фактором.

Ключевые направления защиты из статьи:
⏺Модель разделенной ответственности. Провайдер защищает «железо» и базовую платформу, а вот за настройку доступов, сетей и защиту данных отвечаете вы. И это касается всех моделей: IaaS, PaaS и SaaS.
⏺Ошибки в конфигурациях: Открытые бакеты (S3) и публичный доступ к ресурсам без реальной необходимости. Избыточно разрешающие сетевые правила (привет, 0.0.0.0/0)😄. Отсутствие сегментации сети и смешивание окружений (prod/dev/test). Размещение критичных сервисов в публичных подсетях.
⏺Проблемы с управлением доступами: Назначение прав администратора «на всякий случай» 🤪 и отказ от принципа наименьших привилегий. Использование root-аккаунтов в повседневных задачах. Долгоживущие токены и отсутствие многофакторной аутентификации (MFA).
⏺Отсутствие мониторинга. Без централизованного логирования вы просто не узнаете об атаке, утечке или аномальной активности, пока не станет слишком поздно.

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

📖 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

📝 Логи веб-серверов: где искать следы хакеров?
Когда речь заходит о расследовании атак, многие сразу вспоминают 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

🍗 Эффект домино в цепочках поставок: Как взлом логистики оставил Японию без фастфуда
Свежий инцидент, произошедший с крупнейшим оператором холодильной логистики Японии 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

⚠️ Угроза в доверенной среде: 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

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

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

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

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

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

📖 InfoSec Context

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

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

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

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

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

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

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

📖 InfoSec Context