🫡 Hellhounds остается одной из самых продвинутых группировок, атакующих компании на территории России

Про деятельность Hellhounds мы уже рассказывали в статьях «Операция Lahat» и «Операция Lahat. Часть 2».

В ходе расследования инцидента в IT-компании внимательный администратор заметил на одном из продакшн-серверов процесс, который коннектился к нехарактерному для инфраструктуры IP-адресу — 185.104.106.147.

udevd   24429 root    9u  IPv4         1081871629      0t0        TCP example.com:15777->185.104.106.147:9443 (ESTABLISHED)

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

Для снятия дампа мы выбрали утилиту AVML, а для анализа — модули linux.malfind.Malfind, linux.proc.Maps и linux.pslist.PsList. Нам удалось обнаружить регионы памяти, которые имеют права на выполнение кода, не маппятся на конкретный файл в системе и содержат исполняемый ELF-файл.

DEBUG    
volatility3.plugins.linux.malfind: Injections : processing PID 24429 : VMA Anonymous Mapping : 0x55cc7566b000-0x55cc75685000

24429   udevd   0x55cc7566b000  0x55cc75685000  r-x
7f 45 4c 46 02 01 01 00 .ELF....

Процесс udevd, вероятно, легитимен, но его область памяти была перезаписана и содержала код Decoy Dog (Pupy RAT). На момент анализа в файловой системе отсутствовали персисты и сами файлы бэкдора. Таким образом, Decoy Dog работал только в оперативной памяти.

В новой версии злоумышленники добавили скриплет dumbexec — простейший шелл, слушающий порт 39339.

Кроме того, в одном из конфигурационных файлов злоумышленники использовали порт 31337, что является очередной отсылкой к eleet:

{'debug': False, 'launcher': 'bind', 'launcher_args': ['-t', 'rsa', '0.0.0.0:31337'], 'delays': [(10, 5, 10), (50, 30, 50), (-1, 150, 300)]...

Интересно еще и то, что для генерации доменов (DGA) используются не только DDNS-сервисы, но и домен верхнего уровня .info. Применяется новый лончер l4beacon, который маскирует трафик под UDP (или под TCP, ICMP):

{'debug': False, 'launcher': 'l4beacon', 'launcher_args': ['-p', '161', '-s', 'udp', '--domain', [REDACTED], '-E', 'zzux.com,mooo.com,info'], 'delays': [(10, 5, 10), (50, 30, 50), (-1, 150, 300)]}

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

{'debug': False, 'cid': [REDACTED], 'bound': True, 'data': [REDACTED], 'tmpk': b'gFwpC9rCRmSNjHmvjs+3kB4HD22LGmFgs1BSSvc68fzMQiPcNXchPWYEpjQMYB56'}

Если установлен флаг bound, то в data находится остальная часть конфигурации, зашифрованная криптоалгоритмом ChaCha20, а ключ генерируется на основе идентификатора системы.

Кроме того, появился ключ tmpk, который используется для шифрования данных о системе, отправляемых скриплетом telemetry. Ранее для этого использовался тот же ключ, с помощью которого расшифровывался файл динамической конфигурации.

YARA-правило:

rule PTESC_apt_mem_ZZ_DecoyDog__Backdoor{
  strings:
      $p1 = "pupy://" 
      $p2 = "--pass-args"
      $p3 = "LZMA error"
      $p4 = "/__init__.pyo"
      $pupy = "pupy" 
  condition:
      all of ($p*) and #pupy >= 2
}

IoCs:

185.104.106.147:9443
0.0.0.0:31337
0.0.0.0:39339
mindly.social

*.zzux.com (DGA)
*.mooo.com (DGA)

#hunt #detect #dfir #hellhounds
@ptescalator

ℹ️ Эксфильтрация с помощью Powershell/C#

В процессе расследования инцидента при анализе журналов событий Windows на одном из скомпрометированных узлов мы обнаружили факт выполнения скрипта PowerShell, осуществляющего эксфильтрацию чувствительных файлов с сетевых папок на подконтрольный злоумышленникам сервер 🧐

Необходимая сетевая папка подключается командлетом New-SmbMapping, используются учетные данные, скомпрометированные на одном из предыдущих этапов атаки. После выполняется код на языке C#, определенный внутри PowerShell-скрипта и содержащий основную логику выгрузки файлов.

Программа на C# рекурсивно перебирает файлы, расположенные в заданной и во вложенных папках, и выгружает на подконтрольный веб-сервер те из них, для которых выполняются следующие условия:

• размер не превышает 750 000 байт.
• последняя модификация файла была не позже чем 130 дней назад.

📑 В процессе перебора информация записывается в %APPDATA%\tree.ini с указанием полного пути к файлам, их размеров в байтах, даты последней модификации и даты последнего доступа к ним.

Содержимое каждого из файлов, соответствующих описанным выше условиям, отправляется POST-запросом на веб-сервер злоумышленников в формате multipart/form-data частями по 16 384 байта.

В параметр filename передается идентификатор файла, который представляет собой закодированную Base64 строку формата:

fullpath&&last_write_time&&file_size&&host_name&&current_user&&drive_serial_number

После обработки и выгрузки всех файлов на сервер выгружается также и файл tree.ini, после чего удаляется из системы.

🔦 В обнаружении подобной активности может помочь анализ следующих событий журналов безопасности Windows:

1️⃣ Sysmon event ID 11: создание файлов в пользовательской папке %AppData% от имени процесса powershell.exe. В нашем случае создаются файлы с именами, определенными в коде: tree.ini, profiles_int.ini (БД, в которую записываются хеш-суммы MD5 идентификаторов файлов), sys_error.log и sys_error_ps.log (файлы журналов).

2️⃣ Sysmon event ID 3: сетевые соединения от имени процесса powershell.exe к узлам внутренней сети по порту 445 TCP.

3️⃣ Security event ID 4656, 4663: запрос дескриптора и получение доступа к файлам в сетевой папке процессом powershell.exe.

4️⃣ Windows PowerShell event ID 800 и Microsoft-Windows-PowerShell/Operational event ID 4103, 4104, содержащие характерные для скрипта строки. В частности, названия переменных и методов, определенных в коде:

C#: ___directoriesToUpload___, ___fileBase64Id___, ___WritePartInfo, ___SendTreeFileAndTryRemove

💡 Индикатором возможной вредоносной активности также служит наличие в сетевом трафике большого количества HTTP-запросов методом POST, URL которых содержат фрагменты, закодированные Base64.

👉 SIGMA-правило

IoC:

94.158.247.19

#detect #dfir #PowerShell #win
@ptescalator

☝️ Помимо журналов Windows, в расследовании активности, описанной в предыдущем посте, нам помог еще один интересный артефакт, предоставляемый популярным средством антивирусной защиты.

Этот артефакт представляет собой базу данных (reports.db), в которой хранятся сведения о работе приложений, в том числе о файлах и веб-ресурсах, с которыми взаимодействовал тот или иной процесс.

{"application.description":"Windows PowerShell","application.directory":"C:\\Windows\\System32\\WindowsPowerShell\\v1.0","application.name":"powershell.exe","eventId":154,"object.directory":"\\\\10.50.1.39\\E$\\Очень важные документы\\отчет.xlsx//","object.name":"encrypted","timestamp":"2024-05-06T15:44:15.305346Z","user.name":"COMPANY\\admin","user.type":1}

{"application.description":"Windows PowerShell","application.directory":"C:\\Windows\\System32\\WindowsPowerShell\\v1.0","application.name":"powershell.exe","eventId":154,"object.directory":"https://94.158.247.19/files/upload/4c3df659-4299-4f3d-a159-5cca5215f74f///WREQ//XFwxMC40MC4xMC4zNFxFJFzQntGH0LXQvdGMINCy0LDQttC90YvQtSDQtNC+0LrRg9C80LXQvdGC0Ytc0L7RgtGH0LXRgi54bHN4JiYyOC4wMi4yMDI0IDc6NDI6MTImJjM2NzQyJiZWTTAwMSYmYWRtaW4mJkRGNDUzNjI0//","object.name":"encrypted","timestamp":"2024-05-06T15:44:15.305346Z","user.name":"COMPANY\\admin","user.type":1}

Приведенные выше события, полученные после парсинга базы данных одним из наших инструментов, свидетельствуют о факте доступа процесса powershell.exe к документу в сетевой папке и к веб-странице.

🖥 URL, отраженный в поле object.directory, имеет следующий формат:

ip_address/files/upload/guid///WREQ//base64_id//

🧑‍💻 После декодирования из Base64 получим следующую строку:

\\10.40.10.34\E$\Очень важные документы\отчет.xlsx&&28.02.2024 7:42:12&&36742&&VM001&&admin&&DF453624

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

Таким образом, reports.db — прекрасный источник данных, в котором можно найти:

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

#detect #dfir #PowerShell #win
@ptescalator

Где искать сетевые индикаторы компрометации на Windows? Например, в кэше DNS 💡

Кэш DNS — механизм кэширования записей соответствия доменных имен IP-адресам (и не только). Он нужен для того, чтобы система каждый раз не обращалась к DNS-серверам за этой информацией. Посмотреть содержимое кэша можно с помощью команды ipconfig /displaydns, но не спешите это делать.

У каждой DNS-записи есть параметр TTL (time to live), который определяет, как долго запись остается действительной. По истечении TTL запись «протухает» — и система вновь вынуждена запрашивать данные у DNS-сервера.

Windows хранит перечень кэшированных доменов в виде связного списка, а запрос содержимого кэша состоит из двух этапов: на первом этапе с помощью системного вызова DnsGetCacheDataTable формируется полный список кэшированных доменов, затем для каждого домена из списка происходит резолв из кэша с помощью системного вызова DnsQuery с флагом DNS_QUERY_NO_WIRE_QUERY. Таким образом для каждого кэшированного домена из кэша извлекаются соответствующие ресурсные записи: A, AAAA, TXT и так далее.

😐 Здесь-то и кроется подвох. Если домен содержится в списке кэшированных, а его TTL истекло, то команда ipconfig /displaydns не только не покажет такой домен в списке, но и удалит его из списка кэшированных доменов, тем самым уничтожив потенциальные улики.

Чтобы получить полный список кэшированных доменов (даже «протухших»), можно использовать вызов DnsGetCacheDataTable. Ниже приведен скрипт для PowerShell, реализующий эту функцию:

Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;

namespace DnsCache
{
    [StructLayout(LayoutKind.Sequential)]
    public struct DnsCacheEntry
    {
        public IntPtr PNext;
        public IntPtr Name;
        public ushort Type;
        public ushort DataLength;
        public uint Flags;
    }

    public class Program
    {

        [DllImport("dnsapi.dll")]
        public static extern void DnsGetCacheDataTable(ref DnsCacheEntry entry);
        public static void GetCache()
        {
            DnsCacheEntry a = new DnsCacheEntry();
            DnsGetCacheDataTable(ref a);
            while (true)
            {
                Console.WriteLine("RR name: {0}", Marshal.PtrToStringAuto(a.Name));
                if (a.PNext == IntPtr.Zero) break;
                a = Marshal.PtrToStructure<DnsCacheEntry>(a.PNext);
            }

        }
    }
}
"@
[DnsCache.Program]::GetCache()

Попробуйте выполнить этот скрипт, а потом сравните с результатами вызова ipconfig /displaydns (именно в таком порядке).

Happy hunting!

#tips #hunting #win #dfir #dotnet #triage
@ptescalator