🔗Ссылка:
https://www.securitylab.ru/news/571235.php

🔗Ссылка:
https://www.securitylab.ru/news/571234.php

Чтобы сделать вредоносные файлы невидимыми для систем защиты, атакующие используют различные техники. Самые известные — это руткиты и буткиты. Но иногда достаточно и более простых механизмов. Недавно мы наткнулись на технику маскировки процессов в Linux через bind mount поверх /proc.

Когда утилита для монтирования файловых систем mount запускается с флагом bind, это позволяет "приклеить" одну директорию или файл в другую точку файловой системы. При этом исходные данные в целевой точке становятся невидимыми; фактически, они перекрываются содержимым примонтированного пути.

Атакующий с root-доступом может использовать это для маскировки процессов.

Например, процесс с PID 1234 можно спрятать через mount:

mount --bind /tmp/empty /proc/1234 

После этого содержимое настоящего /proc/1234 перекрывается пустой директорией. Утилиты вроде ps, top или htop читают данные именно из /proc, поэтому для них процесс как будто исчезает. При этом сам процесс продолжает работать: слушает порты, выполняет код, держит соединения.

Иногда делают еще аккуратнее: поверх /proc/<pid>/exe или /proc/<pid>/cmdline монтируют другой файл. Тогда процесс вроде бы виден, но его бинарь или аргументы подменены.

Как ловить атаку?

Проверка mount-таблицы помогает обнаружить сокрытие процесса. Утилиты mount или findmnt покажут bind mounts внутри /proc. В нормальной системе их там почти не бывает.

С точки зрения правил обнаружения для SOC, отслеживаем запуски утилиты mount с соответствующими аргументами: "--bind", "-B", "-o bind" и "/proc")

Также имеет смысл мониторить системный вызов mount на уровне ядра. Например, для auditd простейшее правило аудита может выглядеть так:

auditctl -a always,exit -F arch=b64 -S mount -k mount_monitor 

В файле /var/log/audit/audit.log будут фиксироваться события монтирования, включая bind mounts. При анализе стоит обращать внимание на операции, где точкой монтирования выступают пути внутри /proc.

🔗Ссылка:
https://www.opennet.ru/65159/

🔗Ссылка:
https://github.com/j3h4ck/PoisonKiller

🔗Ссылка:
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

🔗Ссылка:
https://www.securitylab.ru/news/571296.php

🔗Ссылка:
https://github.com/sooryathejas/METATRON

🔗Ссылка:
https://www.opennet.ru/65170/

🔗Ссылка:
https://github.com/synacktiv/GroupPolicyBackdoor

🔗Ссылка:
https://ptsecurity.com/research/pt-esc-threat-intelligence/an-alarm-you-can-t-ignore-how-capfix-attacks-russian-organizations/

🔗Ссылка:
https://www.securitylab.ru/blog/personal/LifeHack/359773.php

🔗Ссылка:
https://github.com/crytic/slither

🔗Ссылка:
https://www.securitylab.ru/news/571265.php

Если вы занимаетесь пентестом беспроводных сетей, то наверняка встречали инфраструктуры на основе 802.11r (Fast BSS Transition) — это стандарт быстрого роуминга, который активно используется в корпоративных сетях, на производстве, в складских комплексах и т.д. Но вот незадача: ни HashCat, ни John the Ripper такие хэши не поддерживали.

Единственный рабочий вариант, который существовал до недавнего времени — использование однопоточного python-скрипта, который к тому же поддерживает только EAPOL и не умеет работать с PMKID. Это лучше, чем ничего, и такой вариант можно было использовать в качестве PoC и подбора по словарю из пары тысяч паролей. Но о каких-либо серьезных атаках по подбору пароля на GPU говорить не приходилось.

Причина в том, что криптографическая схема в случае 802.11r несколько отличается от классического WPA-PSK. Ключ PMK считается так же — через PBKDF2-HMAC-SHA1, но дальше начинается своя кухня: цепочка из трёх шагов на HMAC-SHA256, плюс финальный MIC через AES-128-CMAC. И всё это с дополнительными параметрами (MDID, R0KH-ID, R1KH-ID), специфичными для конкретной беспроводной сети.

Именно это пришлось реализовать нашим специалистам, когда они столкнулись с 802.11r на одном из проектов по анализу защищённости. И в итоге получился новый модуль для HashCat, с поддержкой обоих типов хэшей, PMKID и EAPOL для FT-PSK:
https://github.com/hashcat/hashcat/pull/4645

Так что если на очередном пентесте вам попадётся сеть с 802.11r — больше не нужно довольствоваться однопоточным скриптом. Скармливаем пойманные хэши в HashCat и едём дальше!

Tutorial: Adaptix C2 with ShellcodePack and MacroPack

Original post by Emeric

The article explains how to integrate the Adaptix C2 framework with BallisKit tools ShellcodePack and MacroPack to create stealthy payloads for red-team operations. Adaptix is an open-source command-and-control platform used for post-exploitation and adversarial emulation. The tutorial walks through setting up an Adaptix server on Linux and compiling the GUI client…

https://core-jmp.org/2026/04/tutorial-adaptix-c2-with-shellcodepack-and-macropack/

Иногда бывает нужно быстро посмотреть какие беспроводные сети вокруг, и совсем не обязательно для этого каждый раз переключаться в режим монитора, ведь сканирование эфира это штатный функционал любой сетевой карты. На Linux просмотр беспроводных сетей можно производить с помощью встроенной утилиты iw, дающий очень много информации про каждую точку доступа, что не очень удобно для быстрого просмотра.

Я написал небольшой скрипт обёртку над утилитой iw для сканирования Wi-Fi.
https://github.com/s0i37/wifi/blob/main/scan.sh
Скрипт можно запускать на любой сетевой карте, даже при активном подключении.
Удобно использовать для простой разведки, особенно на устройствах без монитор режима (Android). Результаты выводятся в waterfall форме, подходящей для просмотра на небольших экранах, в отличие от непрерывно меняющихся airodump, bettercap, kismet.