Три громких утечки, которые ловились одной командой в терминале

Capital One — избыточные привилегии IAM-роли. Майнинг криптовалюты на сайте Los Angeles Times — S3-бакет с ACL public-read-write. Вредоносный код в Twilio SDK — снова открытый бакет. Три инцидента на миллионы долларов, три мисконфигурации, которые ловятся одним проходом checkov -d . по Terraform-шаблону. Но только если сканирование вообще настроено.

NSA в отчёте Mitigating Cloud Vulnerabilities прямо называет мисконфигурации наиболее распространённой уязвимостью облачных сред. А по данным IBM, среднее время обнаружения такого инцидента часто превышает шесть месяцев. В pipeline та же проблема находится за секунды. Разница — в точке, где вы проверяете.

🔍 Тысячи правил в IaC-сканерах сводятся к пяти категориям мисконфигураций:

• Публичный доступ к ресурсам — открытые бакеты, базы данных с publicly_accessible = true, сервисы без ограничения source IP
• Избыточные IAM-привилегии — политики с "Action": "*" и "Resource": "*", дающие полный контроль над аккаунтом
• Отсутствие шифрования — EBS-тома, RDS, S3 без encryption, HTTP без TLS
• Отключённое логирование — CloudTrail не во всех регионах, VPC Flow Logs не настроены, Kubernetes audit logging выключен
• Избыточный сетевой доступ — Security Group с 0.0.0.0/0 на порт 22 или 3389

Каждая категория — прямой enabler для конкретных тактик MITRE ATT&CK. Открытый бакет — это T1580 (Cloud Infrastructure Discovery). Wildcard-роль — T1078.004 (Cloud Accounts). Пробел в логировании — T1562.008 (Disable Cloud Logs), и атакующему даже не нужно ничего отключать, потому что вы сами не включили.

⚙️ Отдельная боль — выбор между сканированием HCL-кода напрямую и сканированием Terraform Plan. Первый подход быстрый, не требует credentials, ставится как pre-commit hook. Но он не видит результат интерполяции переменных. Если значение ACL приходит из var.bucket_acl с дефолтом private, а при деплое кто-то передаёт public-read-write через флаг -var — сканер этого не увидит.

Сканирование Plan JSON решает эту проблему: все переменные уже разрешены, вы видите реальные значения. Но нужен доступ к state backend и cloud API. Оптимальная стратегия — оба подхода последовательно: HCL-сканирование на pre-commit, Plan-сканирование в CI перед apply.

🛡 И ключевой момент: параллельно с preventive-сканированием стоит строить detection-правила в SIEM. Алерт на PutBucketAcl с публичными параметрами, на AttachRolePolicy с wildcard, на AuthorizeSecurityGroupIngress с CIDR 0.0.0.0/0 — это ваша страховка на случай, когда pipeline обошли.

В полной статье — готовые примеры Terraform-кода с мисконфигурациями, маппинг на MITRE ATT&CK и конкретные detection-правила для каждой категории.

https://codeby.net/threads/bezopasnost-infrastructure-as-code-ot-miskonfiguratsii-v-terraform-do-detection-pravila-v-siem.92969/

Шеллкод внутри музыки: почему EDR не слышит малварь в WAV-файлах

Трёхминутный стерео-WAV при 44.1 кГц весит около 30 МБ и содержит порядка 15.8 миллионов сэмплов. Каждый сэмпл — 16-битное число. Замени младший бит в каждом из них — и получишь почти 2 МБ скрытой ёмкости. Амплитуда сдвинется на 1/65536 от полного диапазона. Ухо не заметит. EDR не заметит. Файл звучит как обычная музыка.

Именно так работает LSB-стеганография — самый распространённый способ спрятать payload в аудио. И это не теория из CTF-задач.

🔊 В 2019 году Symantec зафиксировала, что группировка Turla использовала WAV-файлы для доставки кода на заражённые хосты. Параллельно исследователи Cylance нашли криптомайнеры и Metasploit-шеллы внутри аудио. Файлы воспроизводились без щелчков, без артефактов — чистый звук. С тех пор техника только развивается, а детект в большинстве организаций стоит на нуле.

Почему атакующим это удобно:

• Межсетевые экраны и DLP считают аудио безопасным медиаконтентом. GET-запрос на .wav с публичного CDN — для фильтра это «пользователь слушает музыку».
• EDR реагирует на исполняемые файлы и скрипты, а WAV сам по себе не исполняется. Payload извлекает отдельный загрузчик, уже сидящий на хосте.
• Атакующий может обновлять шеллкод, не трогая ничего на эндпоинте — просто заменил WAV на CDN, и бот тянет свежий payload.

🛡 Что с обнаружением? Ни CrowdStrike Falcon, ни Microsoft Defender for Endpoint, ни SentinelOne не инспектируют содержимое аудиофайлов. Поведенческий анализ сработает только на этапе исполнения извлечённого кода. Сам WAV проходит незамеченным.

Но слабые места у техники есть. LSB-стеганография уязвима к статистическому анализу — тест хи-квадрат может выявить аномальное распределение младших битов. Правда, в реальных кампаниях payload шифруют перед встраиванием, и простые статистические тесты перестают работать. Ещё одно ограничение: метод не переживает lossy-сжатие. Если WAV прогнать через MP3-транскодер — шеллкод разрушится. Атакующий привязан к lossless-каналам.

Помимо LSB существуют и другие подходы. Фазовое кодирование прячет данные в фазовых разностях сегментов — устойчивее к обработке, но ёмкость ниже. Спектральное встраивание помещает биты в частоты выше 14–16 кГц, где слух наименее чувствителен. А в той же кампании 2019 года Cylance обнаружила загрузчики на основе rand() с фиксированным seed — WAV звучал как белый шум, но после PRNG-декодирования превращался в полноценный PE-файл.

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

https://codeby.net/threads/steganografiya-v-audiofailakh-kak-malvar-pryachut-vnutri-wav-i-kak-eto-obnaruzhit.92973/

19 дней от фишингового письма до терминала SWIFT: как устроены атаки на банки

На одном red team проекте для банка из топ-30 команда прошла путь от spear-phishing письма до операторского АРМ SWIFT за 19 дней. Два файрвола, выделенный VLAN, формально изолированная secure zone — всё это обнулил один сервисный аккаунт с правами на обе зоны. Сегментация превратилась в декорацию.

И это не уникальный случай. Тот же сценарий — почти покадрово — использовала Lazarus Group при взломе Bangladesh Bank ($81 млн украденных средств) и группировка Cobalt в атаке на российский «Глобэкс».

🔑 Главный инсайт: ни одна крупная атака на SWIFT не эксплуатировала уязвимость в самом протоколе. Каждый раз это многонедельная APT-операция через людей и корпоративную сеть вокруг secure zone.

Как выглядит kill chain на практике:

• Initial Access — таргетированное письмо оператору банка. Вложение замаскировано под платёжное поручение или запрос регулятора. PDF с макросами, иногда заражённая USB-флешка. Цель — закрепиться на любой рабочей станции в офисном сегменте.

• Lateral Movement — самая долгая фаза. Атакующий перехватывает пароли через кейлоггер, снимает скриншоты рабочих столов, чтобы понять бизнес-процессы и вычислить операторов SWIFT. Среднее время от проникновения до вывода средств — 3–4 недели. Всё это время сигнатурные детекты молчат: аутентификация идёт под легитимными учётками.

• Финал — формирование поддельных SWIFT-сообщений (MT103 для клиентских переводов, MT202 для межбанковских), модификация серверного ПО Alliance Access, чтобы подавить печать подтверждений и стереть записи из базы транзакций.

⚠️ Отдельный вектор, о котором мало говорят: в России до 2018 года ряд банков работал со SWIFT через сервис-бюро — посредников с доступом к IP-адресам и критической инфраструктуре клиентов. Компрометация одного такого посредника открывала путь сразу к десяткам банков. По сути — supply chain attack на финансовый сектор целой страны.

Что реально помогает защититься:

• EDR-агенты на каждом эндпоинте secure zone (а не только в офисном сегменте) — legacy-системы на Windows Server 2008/2012 часто остаются без покрытия вообще
• Поведенческий анализ аутентификаций — валидные учётки не ловятся сигнатурами
• Жёсткая ревизия сервисных аккаунтов с кросс-зонными правами — именно они превращают сегментацию в фикцию

📌 В полной статье — маппинг каждого шага на MITRE ATT&CK, разбор реальных инцидентов и готовые Sigma-правила для детекта.

https://codeby.net/threads/ataki-na-swift-i-mezhbankovskiye-sistemy-kill-chain-ot-fishinga-do-vyvoda-sredstv.92972/