Forwarded from purple shift
Чтобы сделать вредоносные файлы невидимыми для систем защиты, атакующие используют различные техники. Самые известные — это руткиты и буткиты. Но иногда достаточно и более простых механизмов. Недавно мы наткнулись на технику маскировки процессов в Linux через
Когда утилита для монтирования файловых систем
Атакующий с root-доступом может использовать это для маскировки процессов.
Например, процесс с PID 1234 можно спрятать через mount:
После этого содержимое настоящего
Иногда делают еще аккуратнее: поверх
Как ловить атаку?
Проверка mount-таблицы помогает обнаружить сокрытие процесса. Утилиты
С точки зрения правил обнаружения для SOC, отслеживаем запуски утилиты mount с соответствующими аргументами: "--bind", "-B", "-o bind" и "/proc")
Также имеет смысл мониторить системный вызов mount на уровне ядра. Например, для
В файле
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.Forwarded from Cybred
Bluehammer
Парень с ником ChaoticEсlipse0 просто взял и дропнул на всех 0day с повышением привилегий через Defender. Он не объяснил своих действий, но vx-undeground со ссылкой на Xitter подтвердил, что эксплоит рабочий.
По словам исследователя, скоро будет еще один
Парень с ником ChaoticEсlipse0 просто взял и дропнул на всех 0day с повышением привилегий через Defender. Он не объяснил своих действий, но vx-undeground со ссылкой на Xitter подтвердил, что эксплоит рабочий.
По словам исследователя, скоро будет еще один
Another 0day unpatched LPE will be released soon.
www.opennet.ru
Атака GPUBreach, позволяющая получить root-доступ через выполнение CUDA-кода на GPU NVIDIA
Группа исследователей из университета Торонто разработала технику атаки GPUBreach, которая аналогично анонсированным на днях атакам GDDRHammer и GeForge использует технику RowHammer для искажения битов видеопамяти GDDR и повреждения таблицы страниц памяти…
🔗Ссылка:
https://www.opennet.ru/65159/
https://www.opennet.ru/65159/
Trufflesecurity
Google API Keys Weren't Secrets. But then Gemini Changed the Rules. ◆ Truffle Security Co.
Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true.
Forwarded from Whitehat Lab
XSSNow
XSSNow - XSS Payloads & CSP Bypass Tools
Free XSS payload database and CSP bypass finder with 346+ JSONP gadgets for penetration testing.
Please open Telegram to view this post
VIEW IN TELEGRAM
www.opennet.ru
Уязвимость во Flatpak, позволяющая выполнить код вне изолированного окружения
В опубликованном несколько часов назад корректирующем выпуске системы самодостаточных пакетов Flatpak 1.16.4, а также в экспериментальном выпуске 1.17.4, устранена уязвимость (CVE-2026-34078), позволяющая вредоносному или скомпрометированному приложению в…
🔗Ссылка:
https://www.opennet.ru/65170/
https://www.opennet.ru/65170/
Forwarded from purple shift
Если вы занимаетесь пентестом беспроводных сетей, то наверняка встречали инфраструктуры на основе 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 и едём дальше!
Единственный рабочий вариант, который существовал до недавнего времени — использование однопоточного 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 и едём дальше!