Форум информационной безопасности - Codeby.net
Статья Обход защиты BIOS: отключение Secure Boot на залоченных прошивках
На red team-проекте достался корпоративный ThinkPad с полностью залоченным BIOS. За три часа с программатором CH341A и UEFITool удалось сбросить пароль и обнаружить в прошивке подписанный Microsoft DXE-драйвер, позволяющий загрузку произвольного кода. Secure Boot формально включён — реальной защиты нет.CVE-2024-7344 (CVSS 8.2): Microsoft подписал UEFI-приложение с кастомным PE-загрузчиком вместо стандартных LoadImage/StartImage — грузит любой бинарь из cloak.dat, игнорируя Secure Boot. BootHole (CVE-2020-10713): переполнение в GRUB2 при парсинге grub.cfg — подпись валидирует бинарь, но не данные которые он парсит. SMM exploitation в Ring -2 невидим для любого software-based мониторинга.
CHIPSEC для аудита: common.spi_lock [FAILED] = прошивку можно перезаписать программно без вскрытия корпуса. Decision tree выбора вектора по условиям. Чеклист защиты из десяти пунктов.
Secure Boot без Intel Boot Guard + актуального dbx + мониторинга...Статья Эмуляция прошивок embedded Linux: QEMU, Firmadyne и динамический анализ без устройства
Три месяца назад получил прошивку промышленного роутера на MIPS — устройство стояло на закрытом объекте за двумя периметрами. Через 40 минут после binwalk -e работал lighttpd в QEMU user-mode, через два часа — command injection в CGI-обработчике. Физическое устройство не понадобилось.QEMU user-mode vs system-mode: когда chroot достаточно, а когда нужен полный стек. Firmadyne — автоматизированный пайплайн из пяти шагов: extractor.py → getArch.sh → makeImage.sh → inferNetwork.sh → run.sh. Где ломается: NVRAM-зависимости, вендорские модули ядра, привязка к MMIO-периферии SoC. Как чинить: заглушки через LD_PRELOAD, NOP проверок оборудования в Ghidra, nandsim для MTD-партиций.
Сравнительная таблица шести инструментов: QEMU, Firmadyne, FirmAE, Qiling, Renode — с границами применимости. Минилаб на прошивках D-Link DIR-822 и NetGear WN604.
Статический анализ закрывает 30% поверхности атаки. Остальные 70% — runtime-баги, которые видны только при...Статья Взлом медицинского оборудования: от fingerprinting до lateral movement через DICOM
Из 200 000 инфузионных насосов, проанализированных Unit 42, 75% содержали хотя бы одну известную уязвимость. 52% уязвимы к двум CVE с CVSS 9.8 — раскрытым в 2019 году. Шесть лет назад. На стенде картина та же: открытый текст, дефолтные пароли, прошивки без обновлений.Медицинская сеть — другая реальность: DICOM не требует аутентификации по дизайну, HL7 v2 передаёт клинические данные открытым текстом, плоские сети без сегментации, VxWorks вместо Windows. CVE-2019-12255 в TCP/IP стеке VxWorks (CVSS 9.8, EPSS Top 1%, EDB-47233) затрагивает МРТ, инфузионные насосы, мониторы пациентов — всё что работает на этой RTOS.
EDR не ставится на насосы и МРТ — несовместимая ОС. SIEM не парсит DICOM/HL7. Трафик на порту 104 воспринимается как нормальный. Чеклист пентеста из девяти шагов.
Вопрос не в том, обнаружит ли кто-то слабости — они давно каталогизированы. Вопрос — кто окажется в сети первым.Статья ML IDS обнаружение атак без сигнатур: слепые зоны поведенческого детектора
Isolation Forest с F1 0.97 на CICIDS 2017 пропустил DNS-туннель на 800 КБ: feature vector оставался в двух стандартных отклонениях от нормы. Модель с отличными метриками на датасете в продакшене оказалась слепой. После этого каждый ML-детектор проходит adversarial-тестирование до включения в боевую инфраструктуру.Mimicry-атака: fingerprinting baseline → адаптация C2-beacon под профиль легитимного трафика. Low-and-slow: exfiltration по 50 КБ раз в 10 минут через DNS, lateral movement 1–2 соединения в час, jitter 30–50% против LSTM-детекторов. Poisoning: «растягивание» границы нормы в период переобучения модели.
Decision table: какой сценарий какая модель ловит и что делать атакующему. Python-код детекции distribution shift через KS-тест для выявления poisoning. Ensemble-подход и adversarial validation как единственные работающие контрмеры.
Тихий оператор, настроивший C2 под baseline, проходит через большинство коммерческих...Статья Identity-based атаки APT 2026: как группировки уходят от эндпоинтов в облако и почту — Red Team и Detection гайд
APT29 вошли в Microsoft через password spraying тестового tenant без MFA. Два месяца читали почту руководства через OAuth-приложение с full_access_as_app к Exchange Online. EDR не выдал ни одного алерта: вся цепочка прошла в identity-плоскости, минуя эндпоинты. 75% вторжений — через valid credentials.Kill chain identity-атаки: password spray → MFA fatigue → Golden SAML через AD FS token-signing certificate → OAuth Application Access Token → Account Manipulation с client secret к Service Principal. Каждый этап маппирован на MITRE ATT&CK с конкретным detection-сигналом.
KQL-запросы для Sentinel: password spray через корреляцию ResultType + дедупликация UPN, MFA fatigue через join отклонённых push с успешным входом. Sigma-правила из SigmaHQ по T1078.
SOC строил detection вокруг эндпоинтов. APT сместились в плоскость, где этих сигналов просто нет по дизайну — один OAuth grant и месяцы тихого доступа.EM.Статья Consent phishing через OAuth: от фишинговой ссылки до контроля над Microsoft 365
Понедельник, 10:40 — зарегистрировано OAuth-приложение «HR Document Portal». 11:20 — первый сотрудник нажал «Принять». К полудню читалась переписка CFO и выгружались документы из SharePoint. MFA включена. Conditional Access настроен. Ни один алерт не сработал.Consent phishing работает на уровне authorization, а не authentication — MFA, passkeys и phishing-resistant authenticators его не останавливают. После выданного consent сброс пароля не отзывает OAuth-токены: доступ живёт до явного revoke — недели и месяцы. Три варианта атаки: классический illicit consent grant, device code phishing через first-party приложения Microsoft, ConsentFix с drag-and-drop authorization code.
KQL-запросы для Sentinel: мониторинг consent grants с Mail.Read/Files.ReadWrite, device code flow с аномальным IP. Чеклист харденинга из девяти пунктов с привязкой к закрываемому вектору.
Проблема не в технологиях — Token Protection и CAE существуют. Дефолтные настройки...Статья OAuth Device Code Flow атака: от фишинга до persistent-доступа в Azure AD
На red team проекте для финтех-компании с P2-лицензиями Entra ID и FIDO2-ключами для C-level — persistent-доступ к почте CFO за 12 минут. Без перебора паролей, без обхода MFA, без единого credential prompt на стороне жертвы. Один device code, введённый пользователем на легитимной странице microsoft.com/devicelogin.Device Code Flow проектировался для Smart TV и IoT — стал вектором initial access в Azure AD. MFA не спасает: пользователь сам проходит аутентификацию на легитимном портале Microsoft, токены уходят атакующему. Refresh-токен — до 90 дней. FOCI-ротация одного токена даёт доступ ко всему стеку M365: Azure CLI → Office → Teams → Outlook.
Генерация device code не создаёт Sign-In event в логах. KQL-запрос детекции: AuthenticationProtocol == "deviceCode". Ключевой вывод: политика блокировки Device Code Flow не входит в стандартные шаблоны security baseline Microsoft.
Отправьте тестовый запрос на /devicecode с Azure CLI client_id. Если получили...Статья OWASP MASVS v1.5.0: разбор обновлений глазами мобильного пентестера
Клиент прислал OWASP MASVS v1.5.0 и попросил «пройтись по всем пунктам». Треть чеклиста помечена N/A: часть контролей непроверяема без исходного кода, часть дублирует ASVS для бэкенда. Ситуация повторяется на каждом втором engagement — версия 1.5.0 не чеклист для black box.Маппинг восьми групп контролей на MITRE ATT&CK: STORAGE→T1552, CRYPTO→T1552.004, NETWORK→T1573, RESILIENCE→T1027. Frida-скрипт для перехвата Cipher.getInstance — если в логе DES или AES/ECB, контроль MASVS-CRYPTO не пройден. Decision tree уровней L1/L2/R: L1 для всех, L2 для финтеха, R для IP-защиты.
Что меняется в v2.0.0: MASVS-ARCH удалена, оверлапы с ASVS устранены, уровни L1/L2/R заменены на MAS Testing Profiles. Переход не решает главную проблему — клиент без threat model.
В scope-документе указывать версию явно: не «по OWASP MASVS», а «по OWASP MASVS v1.5.0».Статья OWASP MASVS v2.0.0: ключевые обновления стандарта безопасности мобильных приложений
Клиент запросил «проверку на L2 по MASVS» — открываю стандарт, а уровней L1, L2 и R там больше нет. OWASP убрал их в v2.0.0. Разговор о скоупе затянулся на два часа: клиент оперировал терминами из v1.5.0, а стандарт жил по другим правилам.Ключевые изменения v2.0.0: MASVS-ARCH с нетестируемыми архитектурными контролями удалён полностью. Уровни L1/L2/R заменены на Testing Profiles в MASTG. MASVS-STORAGE сведена с десятка контролей до двух. MASVS-AUTH разделена на клиентскую и серверную — серверная делегирована OWASP ASVS. MASVS-NETWORK однозначно требует certificate pinning.
Маппинг MASVS-групп на MITRE ATT&CK: STORAGE→T1552, CRYPTO→T1552.004, RESILIENCE→T1027. Три шага обновления пентест-процесса под актуальный стандарт. Добавление MASWE как промежуточного звена между MASVS и MASTG.
Добавьте колонку ATT&CK ID в следующий отчёт — документ понятный SOC-команде заказчика вместо формальной бумаги.Статья Пентест iOS приложений: от jailbreak до анализа бинарников и обхода биометрии
На пентесте финтех-приложения auth-токены вытащились из Keychain одной командой — разработчики выставили kSecAttrAccessibleAlways, и токены читались на заблокированном устройстве. Обход Face ID занял шесть строк Frida-кода. Ребята полагались на безопасность iOS и не закрепили её в архитектуре.Полный цикл: jailbreak через checkra1n/palera1n (decision tree по чипу и версии iOS), расшифровка FairPlay DRM через frida-ios-dump, проверка бинарных защит через otool (PIE, stack canaries, cryptid). SSL Pinning bypass через objection, дамп Keychain с поиском kSecAttrAccessibleAlways-элементов.
Механика обхода биометрии через хук LAContext.evaluatePolicy — почему boolean-флаг в userland всегда патчится. Где обход не работает: Keychain + kSecAccessControlBiometryAny с валидацией в Secure Enclave. Jailbreak detection bypass: от objection до кастомных Frida-скриптов.
Пока защита сводится к isJailbroken() и boolean от LAContext —...