InfoSec Context
110 subscribers
155 photos
1 video
185 links
Канал о событиях в сфере ИБ, которые дадут больше контекста для личной безопасности и безопасности малого бизнеса.

Предлагаю присоединиться к созданию открытой библиотеки информационной безопасности: https://islib.ru
Download Telegram
⚓️ Эффект якоря: как первая информация меняет наше восприятие реальности

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

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

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

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

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

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
👍21
🗺 Интерактивная карта Kubernetes для обеспечения безопасности
Недавно я узнал о проекте, который предлагает интерактивную шпаргалку по безопасности в 👩‍💻 Kubernetes. Называется kubesec-diagram и позволяет наглядно понять и визуализировать аспекты безопасности в K8s-кластере.

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
1
☁️ Как защитить облачную инфраструктуру: разбор главных ошибок и лучших практик
Облачные технологии - это удобно и сейчас, с ростом стоимости оборудования, становится популярно, но они сильно увеличивают поверхность атаки. Команда BI.ZONE выпустила очередной интересный гайд по защите облачных сред.
Сразу спойлер: главные риски связаны не с уязвимостями самих облачных платформ, а с ошибками конфигурации и человеческим фактором.

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥1
Успеть до 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
📝 Логи веб-серверов: где искать следы хакеров?
Когда речь заходит о расследовании атак, многие сразу вспоминают 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🍗 Эффект домино в цепочках поставок: Как взлом логистики оставил Японию без фастфуда
Свежий инцидент, произошедший с крупнейшим оператором холодильной логистики Японии 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
⚠️ Угроза в доверенной среде: 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🥛 Как шифровальщики остановили молочный бизнес Coca-Cola
Не прошло и трех дней, как в копилку наших ИБ-кейсов добавился еще один показательный инцидент, на этот раз из производственного сектора. Кибератака парализовала выпуск молочной продукции бренда Fairlife (принадлежит Coca-Cola) на территории США.

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

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
🧠 Shadow AI уже здесь: как одна загрузка в ИИ стоит карьеры и миллионных выплат
Если посмотреть на свежие отчеты от подразделений ИБ, то очевиден тренд: средства ИБ в различных компаниях все чаще фиксируют обращения работников к внешним ИИ-сервисам 🎑.

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

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

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

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
📱 Удалил данные с телефона при досмотре: преступление или защита приватности?
Недавно в поле зрения попал свежий кейс: мужчина при прохождении пограничного контроля в США 🇺🇸назвал сотрудникам спецслужб специальный код для GrapheneOS 🌇, который запустил полный вайп (необратимое удаление) всех данных на устройстве. Теперь местная прокуратура пытается вменить ему «умышленное уничтожение имущества, чтобы помешать конфискации».

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

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

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
🚰 Хакеры взломали реестр бенефициаров в Лихтенштейне
Княжество Лихтенштейн столкнулось с беспрецедентной кибератакой. В ночь с 29 на 30 июля злоумышленники взломали государственный реестр бенефициарных владельцев и скопировали конфиденциальные данные о более чем 31 000 компаний, фондов и трастов 👽.

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

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

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

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Минцифры планирует «отключить» SMS-авторизацию детям
В новостях активно обсуждают новую инициативу Минцифры, которая может кардинально изменить цифровой ландшафт для 31 миллиона несовершеннолетних россиян. Речь идет о проекте поправок в «Правила оказания услуг телефонной связи», который предлагает запретить отправку SMS (включая авторизационные) на «детские» SIM-карты 🤦‍♂️.

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

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

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

📖 InfoSec Context
Please open Telegram to view this post
VIEW IN TELEGRAM
👀1🤪1
💲Хакеры скупают чужое прошлое за миллионы долларов
Свежий отчёт исследователей из 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Старая надежность?
Участвуя в очередном аудите инфраструктуры в одной из организаций, опять столкнулся с устаревшими серверами на Windows 2000 🪟. Кажется, «О ужас!», это старые, не обновленные, дырявые ОС. Но предлагаю на это посмотреть немного с другой стороны.

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

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

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

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

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

📖 InfoSec Context | TG | Max | Web
Please open Telegram to view this post
VIEW IN TELEGRAM
🤖 Искусственный интеллект на службе у карманников.
Информационная безопасность давно вышла за рамки классического вредоносного софта. Последние исследования 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
Please open Telegram to view this post
VIEW IN TELEGRAM