Готовим аналитический отчёт про атаки, которые наш SOC отбивал весь 2023 год.

Атакующие продолжают активно применять легитимные утилиты (LOLbins): их использование мы наблюдали в каждом десятом инциденте прошлого года. А если брать инциденты высокой критичности – почти в каждом третьем. Самые популярные LOLbins – это powershell.exe и rundll32.exe: они замечены в 12% критичных инцидентов. Поэтому адаптация детектирующей логики под выявление нецелевого использования этих утилит в ваших сетях должна стать приоритетной задачей команды мониторинга.

Плохая новость в том, что обнаружение LOLbins связано с большим количеством ложных срабатываний. И всё же ряд хрестоматийных активностей атакующих можно вылавливать по таким командам:

`rundll32.exe  C:\windows\System32\comsvcs.dll, MiniDump <...>`

В случае powershell задача посложней. Плохие запуски хорошо видны аналитическому взору, но их много:

`powershell.exe" -NonInteractive -Enc "...OQA5ACIA...KQA=`
`powershell.exe -NoP -NoL -sta -NonI -W Hidden -Exec Bypass -Enc ...AZg...AbwA=`
`powershell.exe clear-eventlog security,application,system`
`powershell.exe -nop -w hidden -noni -c "if([IntPtr]::Size -eq 4)<...>$s=New-Object System.Diagnostics.ProcessStartInfo;<...>')-f''k'',''p'',''B''); <...> 7}m{''''9''''}i{5}''''t''''i''''{''''6}''+''{9}'')-f''y'',''S'',''M'',''g'',''u'',''U'',''l'',''A'',''o'',''s'')); if <...>
`powershell.exe -command "&{reg.exe save hklm\sam C:\programdata\Microsoft\drm\sam.save; reg.exe save hklm\system C:\programdata\Microsoft\drm\system.save; reg.exe save hklm\security C:\programdata\Microsoft\drm\security.save}"`

Как научить аналитиков SOC ловить такие запуски? Пусть ваша offensive-команда соберёт варианты использования powershell в вашей организации – и запускает тестовые атаки в похожей форме, чтоб выглядело как легитимная активность.

Если ваша красная команда ищет неординарные способы сбора информации о целевых системах, или прикидывает, откуда начать поиск следующего preauth-зиродея в Windows-инфраструктуре, можно обратиться к знаниям предков и вспомнить про MSRPC и Null-session.

Хотя пик популярности атак с использованием нулевой сессии миновал более 20 лет назад, недра удалённого вызова процедур все ещё скрывают в себе множество интересных интерфейсов взаимодействия. А значит, есть и соответствующая поверхность атаки. Пример на скриншоте – информация о домене, собранная без авторизации с использованием MSRPC-интерфейсов.

А теперь представьте, что с использованием таких интерфейсов возможно проводить перебор доменных пользователей – и делается это гораздо менее заметно, чем при той же преаутентификации в Kerberos.

В мае мы планируем подробно рассказать о том, как анализировать MSRPC-интерфейсы, какие атаки можно осуществлять с их помощью, и как их детектировать. А пока проверьте, на всех ли ваших хостах отключена нулевая сессия!

Продолжаем полезные советы на основе анализа достижений атакующих, выявленных нашим SOC’ом в 2023 году.

Многие критические инциденты связаны с повышением привилегий (TA0004) после первоначального доступа (TA0001). Очень часто это обнаруживается как добавление учётных записей в различные привилегированные группы (Domain Admins, Enterprise Admins, …). Понятно, что ложных срабатываний здесь тоже бывает много.

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

Вот простой пример. Многие изменения, выявляемые нашими аналитиками у заказчиков, выглядят так:

`% net user <...> /add` 
`% net {local}group <...> /add`

На практике такие детекты часто оказываются ложноположительными. Что вполне естественно, ведь команда net –нативный механизм работы с пользователями в Windows.

Однако существует утилита-двойник net1.exe, которая появилась в Windows NT и Windows 2000 как временный костыль для решения «ошибки Y2K» при работе утилиты net. И хотя сама «ошибка Y2K» давно исправлена, утилита net1 осталась в более поздних версиях Windows для обеспечения совместимости со старыми компонентами ОС. И при вызове net следом всегда вызывается net1 – по сути, Windows проксирует выполнение в эту команду.

При этом вызовы net, как уже сказано, часто бывают легитимными. Но когда утилиту-двойника net1 вызывают напрямую, ручками – это очень подозрительно. А если вместе с добавлением пользователя (любым способом) ещё и проводили разведку, типа:

query  session /server:<DomainContollerFQDN>  
qwinsta.exe" /server:<DomainContollerFQDN>  
net или net1  group "domain admins" /domain
net или net1  user <...> /domain  
nltest  /domain_trusts

...то в этом случае пора «вентилировать вопросик» с ответственными админами и службой ИБ о легитимности данной активности.

Инструменты Advanced IP Scanner и SoftPerfect Network Scanner – самые распространённые сетевые сканеры, которые используются в подавляющем большинстве атак на этапе Discovery. В момент использования этих утилит атакующие уже имеют доступ в инфраструктуру, но до ущерба пострадавшей организации ещё есть время для реагирования.

Основная сложность с такими сканерами – статус легального ПО: их нельзя автоматически блокировать как вредоносы, иначе вы заблокируете и легитимное использование сотрудниками. Наша рекомендация: любое использование этих инструментов должно рассматриваться как инцидент и приводить к соответствующему реагированию. Но нужно особо обращать внимание на такие детали:

– Нерабочее время: ночь, выходные и праздники.

– Подозрительный путь запуска: например, \ProgramData\x64\netscan.exe

– Учётная запись, от имени которой запущен сканер. Рядовой сотрудник не должен сканировать сеть. Использование локального админа, а не доменной учётки, тоже кажется подозрительным (атакующие ещё не поднялись до домен-админа и начали сканировать сеть).

– Система/сервер, где был зафиксирован запуск. Обращайте внимание на сервера, которые могут быть потенциально начальной точкой компрометации, опубликованные сервера (Exchange, терминальные сервера, IIS, ...), а также контроллеры домена.

– Запуск сканера в контексте терминальной сессии (RDP, AnyDesk, ...) c одной внутренней системы (и из удалённых сессий – VPN) на другую внутреннюю систему.

Больше про использование легитимного софта атакующими расскажем в ежегодном отчёте нашей команды Incident Response. Скоро опубликуем!

Будни расследований инцидентов напомнили отличный сценарий первоначального доступа в инфраструктуру для ваших упражнений команды обнаружения и реагирования.

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

Способ утилизации иногда бесполезных доменных учёток: в удалёнку им нельзя или 2FA, а вот на почту вход свободен. Сложно только договориться на подобный сценарий в рамках упражнений (пентесты, симуляции и эмуляции атак): этому может помешать запрет на нарушение тайны переписки.

Что касается вредоносной нагрузки: это офисный документ с макросом, последующим дропом тушек и коннектами наружу. Звучит и есть 100% адверсариальненько.

Продолжаем наблюдать множество атак через подрядчиков (Trusted relationship attacks). Причина понятна: подрядными организациям зачастую становятся небольшие компании, у которых не всегда хорошо с безопасностью.

Вот классическая схема, которую мы встречали во многих инцидентах 2023-2024 годов. После взлома сети подрядчика атакующие находят учётки для подключения к VPN (или другим формам удалённого доступа) клиентов этого подрядчика. Далее закрепление на атакованных системах через утилиту для туннелирования ngrok. Иногда её запускают как сервис, передавая ей конфигурационный файл, содержащий токен и порт для подключения:

ngrok.exe service run --config ngrok.yml

Либо злоумышленники руками добавляют токен для подключения и запускают утилиту:

ngrok.exe config add-authtoken <TOKEN> 
ngrok.exe tcp 3389

При наличии такого туннеля у атакующего уже нет необходимости подключения через VPN. При этом ngrok является легитимной утилитой и не подлежит уничтожению за зловредность.

Кроме того, использование ngrok не оставляет на системе IP-адрес источника подключения. При обычном подключении по RDP в журнале Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx мы увидим событие подключения (21) или переподключения (25), а в поле источника подключения будет IP-адрес злоумышленника, внешний или внутренний.

Если же подключение происходит через ngrok, то в качестве источника будет указано значение ::%16777216, которое не несёт информации об источнике подключения. Но в большинстве случаев такой артефакт окажется признаком подключения через утилиту туннелирования.

Подробнее о разных вариантах атак через подрядчиков расскажем позже – в отдельном большом материале!

Расследовали интересный инцидент с использованием билдера шифровальщика LockBit 3.0. Атакующие получили учётку админа и собрали свою версию шифровальщика, которая при помощи этой учётки смогла распространиться по сети, отключить Windows Defender и удалить журналы событий Windows после первичного заражения, чтобы зашифровать данные и замести следы.

Однако при горизонтальном распространении по сети зловред генерировал новые логи создания удалённых служб – и уже не удалял их за собой. На скриншоте выше показаны найденные на одном хосте записи о создании удалённой службы PsExec с аутентификацией, выполненной с нескольких заражённых хостов. Такие записи помогли проанализировать распространение зловреда внутри инфраструктуры, выявить скомпрометированные учётки и изолировать заражённые системы.

Подробности расследования:
https://securelist.ru/lockbit-3-0-based-custom-targeted-ransomware/109332/

И снова страшилки про подрядчиков-аутсорсеров, через которых атакующим так удобно проникать в инфраструктуры крупных компаний-клиентов. Атакующим-то удобно! А вот для тех, кто расследует инциденты, здесь возникает ряд проблем.

Во-первых, проблемы юридические. Подрядчик – это ведь не ваш заказчик. Это сторонняя компания, она может не дать вам доступов для расследования. При этом понятно, что если подрядчика ломанули, то наверняка добрались и до других его клиентов. И все эти кейсы стоило бы оперативно расследовать. Но подрядчик боится репутационных рисков! И даже если он дал вам расследовать свой кейс, он вовсе не поспешит сообщать о проблеме всем остальным пострадавшим (хотя бывают приятные исключения).

А вот ещё одна популярная схема атаки, из инцидентов 2023-2024 годов. Мы уже рассказывали, как после компрометации подрядчика атакующие проникают в сети его клиентов по RDP и закрепляются там с помощью туннеля ngrok. Другой типичный вариант – запуск утилиты для удалённого подключения AnyDesk. Которая тоже вполне легитимна и не блокируется EPP (антивирусами).

Однако данная утилита создаёт собственные журналы. А значит, вы можете собрать со своих сенсоров нужные индикаторы атаки. Наиболее полезными окажутся connection_trace.txt и ad.trace/ad_svc.trace (имена приведены для Windows).

Журнал connection_trace.txt позволит быстро определить факты подключения к анализируемой системе и их тип (User, Token, Password). Если AnyDesk использовался злоумышленником, и в указанном журнале встретится тип подключения Token и Password – это будет означать, что атакующий настроил автоматическое подключение в AnyDesk по паролю, и при запущенном AnyDesk сможет подключиться к системе в любой момент.

А в журнале ad.trace/ad_svc.trace, содержащем отладочную информацию, часто будет возможность определить IP-адрес, с которого производилось подключение.

Но в случае, если злоумышленник удалил журналы AnyDesk, обнаружить следы подключений через данное ПО практически невозможно. Остаётся лишь внимательно анализировать события в окрестностях периода активности через утилиту удалённого подключения, обращая внимание на появление подозрительных файлов в файловой системе, подключений по RDP и т.д.

Мы только недавно открыли этот канал, а нам уже все дают полезные советы. Мало, говорят, у вас весёлых картинок. И котиков совсем нет!

И действительно. Вот рассказали мы вам, как выявлять использование хакерами легитимных утилит powershell.exe и rundll32.exe. И как замечать подозрительный запуск сканеров Advanced IP Scanner и SoftPerfect Network Scanner. Но весёлых иллюстраций в этих постах не было – и мы получили всего лишь десяток лайков от читателей.

А ведь это были данные из годовых аналитических отчётов наших команд MDR и IR. В этих отчётах ещё много интересной статистики и рекомендаций по защите от самых современных атак. И теперь это всё – с клёвыми картиночками! Там даже котик есть. Кто не верит, посмотрите сами:

Managed Detection and Response 2023
https://media.kasperskycontenthub.com/wp-content/uploads/sites/58/2024/05/03181545/mdr-analytical-report-2023-RU.pdf

Incident Response 2023
https://media.kasperskycontenthub.com/wp-content/uploads/sites/58/2024/04/18155218/ir-analytical-report-2023.pdf

Во фреймворке для описания хакерских атак MITRE ATT&CK завели новую технику T1090.003 (Multi-hop Proxy) после расследования, проведённого нашими экспертами. В общем случае техника состоит в использовании цепочки множественных прокси для того, чтобы скрыть источник вредоносного трафика. А в том конкретном кейсе, который расследовали наши аналитики, малвара использовала технологию NKN (New Kind of Network). Это децентрализованная P2P-сеть на основе блокчейн-протокола.

Разобранный имплант NKAbuse создаёт в сети NKN новый аккаунт и нового мульти-клиента. Это позволяет передавать сообщения через разных клиентов, и таким образом обеспечивать устойчивую связь с C2. Наличие NKN-протокола в сети вашей организации должно быть подсказкой.

Хронология добавления техники в MITRE:
– 4 месяца от запроса до публикации,
– отказ упоминания компании в контрибуторах,
– автора оставили: Eduardo Chavarro Ovalle.

Подробности: https://securelist.com/unveiling-nkabuse/111512/

Техника атаки Pass the Ticket не нова, однако всё ещё популярна для горизонтального перемещения внутри домена. Одним из способов получения билета чужого пользователя является кража билета из-под соседней LUID-сессии с последующем кэшированием для текущей активной сессии атакующего. Существует множество инструментов, позволяющих это осуществить: Rubeus, TGSThief, kekeo и т.д.

Детектировать подобную активность можно, например, через просмотр всех закэшированных билетов для текущей сессии пользователя – командой klist. Если имя пользователя в билете не совпадает с именем пользователя активной сессии, такая активность подозрительна.

Но на практике даже легитимный пользователь может применять несколько дополнительных учёток для администрирования. Конечно, подобную активность можно отфильтровать вручную, однако придётся это делать снова и снова, с приходом каждого нового пользователя. Поэтому для решения проблемы можно задействовать машинное обучение (ML).

Рассмотрим на примере нашей агрегации (скриншот выше). Здесь видно, что пользователи petrov и sidorov имеют дополнительные учётки, билеты которых хранятся у них в закэшированном виде. Данная активность постоянная, что можно понять по общему количеству срабатываний правила. А вот пользователь bob имеет три разных закэшированных билета, и ранее подобная активность не наблюдалась. Это может свидетельствовать о том, что данная учётка могла быть скомпрометирована.

ML-cистемы поведенческого анализа могут выявлять схожие аномалии в телеметрии и определять возможные украденные kerberos-билеты из-под сессии пользователей. Подробнее о кейсах с использованием ML в работе SOC будем говорить на грядущем PHDays 23-26 мая. Ищите в программе конференции наш трек «Восстание машин: возможно ли заменить аналитика SOC искусственным интеллектом?».

Архитектура Windows позволяет неплохо противодействовать установке и использованию неизвестных, неподписанных, а стало быть, потенциально опасных драйверов. Но наличие уязвимостей даже в легитимных драйверах перечеркивает все изобретенные митигации и дарует нам атаку Bring Your Own Vulnerable Driver (BYOVD).

Множество софта, написанного за долгую историю доминирования Windows на пользовательском рынке, создаёт колоссальную поверхность атаки с минимальными возможностями предсказания, где и как будут проведены такие атаки. Жирным бонусом от эксплуатации уязвимостей в kernel-драйверах является получение привилегий уровня ядра ОС. А это даёт возможность отключить (либо изящно обойти) практически любой механизм защиты и мониторинга, установить руткит, бэкдор, или даже поиграться с заражением BIOS/UEFI.

Пример подобной атаки через уязвимый драйвер описали наши эксперты в детальном разборе TTP группировки вымогателей CUBA. Вот показательный кусочек кода из bat-скрипта, используемого этой группировкой:

sc.exe create aswSP_ArPot2 binPath= C: \windows\temp\aswArPot.sys type= kernel
sc.exe start aswSP_ArPot2

Здесь aswArPot.sys – это легальный антируткит-драйвер Avast, содержащий две уязвимости: CVE-2022-26522 и CVE-2022-26523. Они позволяют создать и запустить службу уровня ядра от имени пользователя с ограниченными правами. Цель – завершить процессы EDR-агентов (в конфиге ВПО был целый список с наиболее «любимыми» ею EDR-процессами) и совершенно незаметно приступить к следующей стадии деплоя рансомвары.

Что делать защите? Вот парочка полезных опенсорсных проектов-репозиториев, где собирается инфа про уязвимые драйвера: LOLDrivers (www.loldrivers.io) и Kernel Driver Utility (github.com/hfiref0x/KDU). Настраиваем фиды к себе в SIEM – и простым правилом помечаем любой чих со стороны тех сомнительных драйверов, с которыми приходится уживаться в силу невозможности обновления.

Распознавание лица для организации физического контроля доступа – это удобно. Если вчера опух, то можно показать свою (или чужую) фотографию. А можно просто надеть футболку со специальным QR- кодом, и биометрический сканер тебя пропустит.

Если покопаться внутри устройства, то открываются новые просторы для атак. Не только доступ в помещение, которое «охранял» взломанный сканер, но и закрепление на устройстве без мониторинга, для последующего развития атаки.

Рассказываем подробности анализа защищённости биометрического считывателя крупной международной компании на докладе Георгия Кигурадзе «Без лица: предъявите вашу кавычку», который начнётся 23 мая в 11:00 на конференции PHDays.

В апреле мы показывали вам годовые аналитические отчёты наших команд MDR и IR. Там были красивые картинки с котиками, а также много интересной статистики по инцидентам прошедшего года. Одновременно наши коллеги Сергей Солдатов и Константин Сапронов провели вебинар «Сезон киберохоты», где комментировали эту статистику и отвечали на вопросы.

Но вопросов было много, ответить на все за время вебинара не успели. Зато ответили после! Весь Q&A можно найти по ссылке. Спасибо за хорошие вопросы, вытянувшие из наших экспертов такие знания:

– Да, зиродеи – это плохо. Но большая часть атак проводится с использованием хорошо известных уязвимостей с публичными эксплоитами (1-day).
– На реальных инцидентах lsass дампят 1001 способом, включая довольно «свежие» (например, LSA Whisperer)
– Да, нужно читать угрозные отчеты (TI) и писать на их основании правила обнаружения. Но все отчёты не прочитать, все угрозы не покрыть, все правила не написать: приоритизация очень важна и считается отдельной дисциплиной – угрозный аналитик (CTI analyst). Не забывайте использовать тесты в любом BAS для проверки пула своих детектирующих правил.

И лучший вопрос с лучшим ответом:

Q: По вашим наблюдениям, существует ли феномен "фишингового вторника": преобладание начала фишинговых атак во вторник?
A: По нашим наблюдениям, существует феномен обращений за расследованием инцидентов в пятницу вечером! Даже если инцидент случился в понедельник, вечер пятницы – это самое частое время обращений за услугой.

В полном файле Q&A отмечены три лучших вопроса, которые выбрали наши эксперты, проводившие вебинар. Авторы этих вопросов могут получить подарки от экспертов, если напишут по адресу rub2b@kaspersky.com.

Представьте, что вы проводите Red Teaming, и уже получили сетевой доступ к контроллеру домена. Для развития атаки можно посмотреть в сторону доменных учётных записей со слабыми паролями. Но как их выявить, не привлекая внимания санитаров специалистов SOC?

Вы можете точечно проверить отдельные дефолтные аккаунты, такие как test или it-admin. Однако устроить перебор всех возможных доменных пользователей не так просто. Можно попробовать преаутентификацию в Kerberos – но это слишком шумно, и вас точно засекут.

Есть менее заметный метод. Давайте обратимся к древнему интерфейсу MS-NRPC, используя уровень доступа RPC_C_AUTHN_LEVEL_NONE (то есть без авторизации). А затем вызовем функцию Opnum 34 (DsrGetDcNameEx2) – которая проводит проверку существования указанного аккаунта в домене. Скормив этой функции дефолтный список всевозможных имён, получим список существующих доменных аккаунтов. Обнаружить такую активность совсем непросто, поскольку она не оставляет какого-либо специального типа события в журнале безопасности Windows.

Дальше остаётся только устроить перебор паролей (password spraying) по полученному списку аккаунтов. Наверняка хоть кто-нибудь использовал P@$$w0rd или May_2024.

Более подробный анализ безопасности MSRPC-интерфейсов – в исследовании Хайдара Кабибо.

Автор исследования также написал утилиту для демонстрации описанных возможностей:
https://github.com/klsecservices/NauthNRPC

Новые-старые подходы вымогателей: использование BitLocker. Это встроенное в Windows средство шифрования по идее должно защищать пользовательские данные от кражи – но может с таким же успехом защитить компьютер от его владельца! Наши эксперты проанализировали новую атаку, где злоумышленники научились ещё лучше прятать ключи криптозащиты и затруднять работу реагирования на инцидент.

Интересно, что перед шифрованием хакеры конфигурируют машину в очень безопасное состояние. Примерно так и нужно конфигурировать компьютер для защиты… а здесь это делают атакующие, чтобы "защитить" захваченную машину:

fDenyTSConnections = 1: отключает удалённый доступ по RDP
scforceoption = 1: требует аутентификацию по смарт-карте
UseAdvancedStartup = 1: требует BitLocker PIN для перезагрузки
UsePIN = 2: требует стартовый PIN с доверенным модулем (TPM)
... и так далее.

Отсюда удивительный совет для защитников: ловите изменения в реестре, которые выглядят как слишком хороший харденинг. Особенно подозрительно, если после такой безопасной конфигурации с компьютера перестала приходить телеметрия.

Подробности работы трояна-шифровальщика на основе BitLocker:
https://securelist.ru/ransomware-abuses-bitlocker/109591/

Мы уже пугали вас атаками через подрядчиков-аутсорсеров – когда рассказывали, как хакеры закрепляются в инфраструктуре жертв, используя ngrok или AnyDesk. И эти страшилки неслучайны: по данным нашей IR-команды, в 2023 году атаки через «доверительные отношения» вошли в тройку самых популярных векторов.

А теперь коллеги выкатили подробный инструктаж на эту тему: как чаще всего организован доступ между целевой организацией и поставщиком услуг, какими способами злоумышленники получают доступ в сеть поставщика и как развивают атаку в сторону его клиентов. И главное – что делать, чтобы такого не случилось у вас.

Один из интересных фактов этого исследования: обычно злоумышленники остаются необнаруженными в инфраструктуре целевой организации до трёх месяцев, прежде чем развивать атаку (например, шифровать данные). По идее, этого времени достаточно, чтобы ИБ-служба выявила инцидент и отреагировала на него до того, как настанут критические последствия. При этом в подавляющем большинстве инцидентов антивирусные решения детектировали подозрительную активность – просто вердикты антивирусов не получали должного внимания.

Полный текст исследования "Trusted Relationship Attack: доверяй, но проверяй":
https://securelist.ru/trusted-relationship-attack/109620/

Уязвимость CVE-2024-21378 позволяет выполнить произвольный код в системе, где установлен MS Outlook. А всё потому, что Exchange и Outlook, общаясь по протоколу MAPI, могут пересылать друг другу всякое разное и вообще немыслимое.

Например, можно создать собственный тип сообщения и указать клиенту Outlook, что для отрисовки этого сообщения следует использовать некую особую форму. И эту форму тоже можно передать адресату: такому сообщению соответствует класс IPM.Microsoft.FolderDesign.FormsDenoscription. А сама форма представляет собой DLL-библиотеку, которая хранится как вложение в сообщении.

Чтобы эксплуатировать уязвимость, злоумышленник отправляет жертве форму, которая открывает определённый класс сообщений. А затем отправляет письмо-триггер, принадлежащее к этому классу сообщений. В результате Outlook загружает вредоносную форму (см. скриншот).

Наш эксперт Александр Родченко проанализировал процесс эксплуатации этой уязвимости и написал утилиту, которая сканирует скрытые сообщения и выявляет попытки атаки. Подробности – в статье по ссылке.

Некоторые умельцы до сих пор используют старую уязвимость Windows, связанную с групповыми политиками. Механизм Group Policy Preferences (GPP) позволяет админам добавлять новых локальных пользователей на каждый хост в домене. Пароли при этом шифруются, но их можно найти и расшифровать (подтехника T1552.006). Невзирая на патч MS14-025, инциденты по-прежнему случаются.

Наша рекомендация по детекту: создайте учётку-ловушку, подложив её данные в xml-файл на SYSVOL. И мониторьте использование этой учётки. Подробности – в статье Глеба Иванова.