Este artigo faz parte da série Fileless Malware. Todas as outras partes da série:
Nos últimos dois posts (
aqui e
aqui ), falamos sobre métodos de ataque sem arquivos, mas bastante inofensivos. Agora, finalmente, estamos prontos para enfrentar um verdadeiro malware sem arquivo. Um site de
análise híbrida (doravante denominado HA) é um recurso em que confio para encontrar essas "criaturas" maliciosas. Como regra, as informações que o HA fornece para cada amostra: chamadas do sistema, tráfego da Internet etc. - o suficiente para atender às necessidades típicas de segurança de TI. Sou inexoravelmente atraído a mergulhar em um desses exemplos de código muito confusos para ver o que realmente está acontecendo lá.
Se você deseja repetir comigo, recomendo que você faça isso na sandbox, por exemplo, no Amazon Web Services. E se você verificar isso no seu computador, não deixe de comentar as chamadas do sistema que iniciam o PowerShell.
Dentro do código VBA confuso
O malware que encontrei no site de análise híbrida é um script VBA incorporado em um documento do Word. Como mencionei na última vez, você precisará do
OfficeMalScanner de Frank Baldwin para ver o código real.
Após extrair o script, baixei o código na biblioteca de macros do MS Word e iniciei sua depuração passo a passo usando o depurador interno. Meu objetivo era entender melhor o que estava oculto por trás da ofuscação: reproduzir análises de IB e experimentar os sucessos e decepções associados a este trabalho.
Se você, como eu, decidiu fazer isso no depurador pela primeira vez, provavelmente provavelmente tomará mais de uma xícara de chá (ou café), percorrendo um código complexo alucinante ou observando, piscando, a variável L_JEK, à qual está atribuída a linha "77767E6C797A6F6" .
Trabalhando com esse script VBA confuso, percebi que apenas uma parte muito
pequena faz um trabalho útil. A maior parte do código existe apenas para desviá-lo.
No final, tirei uma captura de tela de uma pequena parte do código que faz todo o trabalho ruim de iniciar uma linha de comando do PowerShell, que finalmente é executada como uma macro VBA.
Tricky: basta pegar o valor hexadecimal e subtrair 7 para ASCII real.
É muito simples O código VBA contém em várias variáveis um registro da linha de comando final em notação hexadecimal e, em seguida, simplesmente o converte em uma sequência de caracteres. O único "truque" aqui foi que os valores hexadecimais foram compensados por 0x07. Portanto, por exemplo, a primeira parte da sequência hexadecimal é obtida de L_JEK, ao qual foi atribuído o valor "77767E6C797A6F6". Se você pegar 0x77 e subtrair 0x07, receberá hex 0x70. Faça o mesmo para 0x76 e você receberá hex 0x6F. Olhe para eles em qualquer tabela de códigos ASCII e você verá que ela corresponde às duas primeiras letras do “powershell”.
De fato, este não é o emaranhado mais difícil, mas não é necessário! Tudo que você precisa fazer é ignorar os scanners antivírus que estão procurando palavras-chave específicas ou suas representações na forma de sequências ASCII. Que esta amostra é boa o suficiente e faz. Por fim, após o script recriar a linha de comando, ele é executado através da função CreateProcess (veja abaixo):
Comente as chamadas do sistema ou defina um ponto de interrupção na frente delas.
Pense nisso por um segundo. Um documento do Word foi enviado a um funcionário em um email de phishing. Quando um documento é aberto, esse script do VBA inicia automaticamente uma sessão do PowerShell para iniciar a próxima fase do ataque. Nenhum arquivo executável e scripts ofuscados silenciosamente evitam antivírus e outros scanners.
Aqui está o mal!
Por uma questão de curiosidade, baixei outra macro do site de HA (abaixo) para ver o que mais acontece. Este segundo código faz aproximadamente a mesma coisa que o acima.
Código secreto incorporado no VBA.
Mas esse código é um pouco mais inventivo na maneira como restaura a linha de comando. Existe uma função de decodificação chamada “d” que filtra caracteres da cadeia de base, comparando-os com a segunda cadeia de controle. Essa já é uma idéia de nível de ensino médio e também faz um excelente trabalho: evita facilmente os scanners e engana os administradores que apenas olham brevemente nos logs para ações incomuns.
Próxima parada
Na minha primeira série de publicações sobre
ofuscação, mostrei que o log de eventos do Windows registra muitos detalhes das sessões do PowerShell, ou seja, se você habilitar as configurações apropriadas para poder realizar uma análise aprofundada após o
hacking .
Obviamente, isso também tem uma certa complexidade de ataques sem arquivos, já que é quase impossível determinar se o script do PowerShell está fazendo algo ruim, basta verificar os comandos lá enquanto visualiza os eventos de log de segurança.
Por que você pergunta?
Como as sessões do PowerShell são iniciadas o tempo todo, o código malicioso de uma sessão do PowerShell de um único hacker pode ser iniciado ao mesmo tempo que o código legítimo de um bom administrador de TI do PowerShell. Se você receber notificações sempre que o script PS baixar algo da Internet, muitos falsos positivos serão gerados.
A conclusão pode ser tirada da seguinte forma: vemos a incapacidade das ferramentas tradicionais de defesa de perímetro de interromper tais ataques, emails de phishing e malware do FUD, além de grandes perspectivas de
análises comportamentais .
Em resumo, esta é uma batalha deliberadamente perdida, tentando impedir que hackers entrem no perímetro. A melhor estratégia é identificar o acesso incomum e suspeito a arquivos e iniciar aplicativos e, em seguida, responder a eles desativando contas ou tomando outra medida em resposta a uma violação.
Na próxima parte, veremos os tipos mais avançados de ataques sem arquivos.