No cenário atual da segurança da informação, um dos maiores desafios das organizações é encontrar o equilíbrio ideal entre a proteção dos ativos e a continuidade do negócio. Muitas vezes, políticas de segurança são vistas como barreiras que engessam a operação ou geram sobrecarga nas equipes de suporte. No entanto, existe uma vulnerabilidade de configuração silenciosa, presente na maioria das estações de trabalho Windows, que não traz nenhum benefício prático para o usuário comum, mas abre as portas para incidentes graves: o acesso livre e interativo ao Prompt de Comando (CMD) e ao PowerShell.
Manter essas ferramentas acessíveis para funcionários de áreas não técnicas (como Recursos Humanos, Financeiro ou Vendas) amplia desnecessariamente a superfície de ataque de uma empresa. Este artigo aborda os riscos técnicos dessa prática, a importância de focar na restrição do uso interativo e como os principais frameworks internacionais amparam essa decisão estratégica.
O fenômeno LOTL (living off the land) e o desafio da detecção
No passado, os cibercriminosos dependiam quase exclusivamente do download de arquivos maliciosos tradicionais (como executáveis .exe ou bibliotecas .dll) para infectar uma máquina. Hoje, com a evolução dos antivírus e das soluções de detecção em tempo real, essa abordagem se tornou arriscada para os atacantes. Para contornar essas defesas, consolidou-se a tática conhecida como Living off the Land (LOTL), ou “viver da terra”.
Conceito de LOTL: É o método em que os invasores utilizam ferramentas legítimas e utilitários nativos pré-instalados no próprio sistema operacional da vítima (os chamados LOLBins) para executar ações maliciosas, coletar dados e se mover pela rede.
O CMD e o PowerShell são os alvos preferenciais dessa estratégia devido a três fatores principais:
- Complexidade na Diferenciação de Tráfego: Como a execução parte de processos assinados e confiáveis da própria Microsoft, discernir o que é um comando administrativo legítimo de uma atividade cibercriminosa em andamento torna-se um desafio complexo para os analistas de segurança.
- Ataques em Memória (Fileless): O PowerShell permite que códigos sejam executados diretamente na memória RAM. Um exemplo clássico é o uso do script Invoke-Mimikatz, que carrega as funções de extração de credenciais diretamente na memória, evitando que um arquivo malicioso toque o disco rígido. Embora mecanismos modernos como o AMSI (Antimalware Scan Interface) e soluções de EDR aumentem significativamente a capacidade de detecção, os ataques fileless continuam desafiadores por reduzirem os indicadores tradicionais de infecção.
- Técnicas de Ofuscação e Evasão: O PowerShell possui uma flexibilidade de interpretação gigantesca. Atacantes utilizam recursos que vão muito além da simples codificação em Base64 (usando o parâmetro-EncodedCommand). Eles empregam compressão de dados, técnicas de reflection para manipular componentes internos do .NET, e mecanismos dinâmicos como Invoke-Expression (IEX) e download cradles para puxar instruções diretamente da internet para a memória do computador.
Se um usuário padrão tiver sua conta ou máquina comprometida através de um e-mail de phishing, por exemplo, o atacante herdará os privilégios daquela sessão. Se o console interativo estiver liberado, o invasor terá um ambiente extremamente favorável para iniciar a exploração interna da infraestrutura.
Uso interativo vs. execução em segundo plano
Um erro comum ao planejar essa restrição é assumir que o bloqueio do PowerShell precisa ser total e irrestrito. Bloquear completamente o executável powershell.exe em nível de sistema operacional pode quebrar componentes essenciais da infraestrutura moderna, como o Microsoft 365 Apps, Teams, OneDrive, agentes do Intune e scripts legítimos de inicialização.
A abordagem correta consiste em restringir o uso do console interativo (a interface onde o usuário digita comandos manualmente), mantendo as automações de segundo plano ativas.
[ Usuário Final ] ──( Bloqueado )──> [ Console Interativo (Interface de Comando) ]
[ Componentes do Sistema ] ──( Permitido )──> [ Execução Automatizada em Segundo Plano ]
Na maioria dos ambientes corporativos modernos, o funcionário médio executa suas tarefas diárias utilizando navegadores web, clientes de e-mail e sistemas ERP/CRM. Embora existam exceções (como scripts legados para mapeamento de impressoras), o usuário comum não necessita abrir um terminal preto ou azul para digitar linhas de código. Restringir esse acesso remove uma ferramenta de alto poder das mãos de um potencial invasor sem causar fricção no fluxo de trabalho diário da empresa.
O alinhamento com os frameworks de segurança (NIST e CIS Controls)
A recomendação de limitar o acesso a interpretadores de comandos é um pilar fundamental das boas práticas de governança e conformidade cibernética global.
1. NIST SP 800-53 (Revisão 5)
O framework do National Institute of Standards and Technology aborda esse cenário diretamente em duas frentes:
- Funcionalidade Mínima (CM-7): Estabelece que os sistemas devem ser configurados para oferecer apenas as capacidades operacionais essenciais, proibindo ou restringindo funções desnecessárias. Manter terminais interativos abertos para quem não depende deles para trabalhar contraria diretamente este princípio.
- Princípio do Menor Privilégio (AC-6): Determina que as contas de usuário devem possuir apenas os privilégios estritamente necessários para o desempenho de suas funções.
2. CIS Critical Security Controls (v8)
O Center for Internet Security destaca a importância do endurecimento (hardening) das estações de trabalho através dos controles de Configuração Segura (Control 4) e Gerenciamento de Contas (Control 5), recomendando explicitamente a limitação de ferramentas que possam ser abusadas para alterar o estado de segurança do sistema.
Do ponto de vista da governança, toda exceção a essa regra deve possuir uma justificativa de negócio formal e aprovada, garantindo que acessos diferenciados (como para desenvolvedores ou analistas de dados) sejam documentados e monitorados.
| Framework | Identificador do Controle | Objetivo Prático no Cenário Corporativo |
| NIST SP 800-53 | CM-7 (Least Functionality) | Desabilitar o acesso interativo a interpretadores de comandos que não possuam justificativa de negócio. |
| NIST SP 800-53 | AC-6 (Least Privilege) | Restringir o uso de ferramentas de administração técnica ao escopo das equipes de TI e Segurança. |
| CIS Controls v8 | Control 4.1 / 4.7 | Estabelecer um baseline seguro, controlando o uso de ferramentas nativas que podem ser abusadas (LOLBins). |
| CIS Controls v8 | Control 5.4 | Impedir que contas padrão invoquem ferramentas destinadas à gestão de sistemas operacionais. |
Estratégias técnicas para uma implementação segura
Para aplicar essas restrições de forma eficaz, sem deixar brechas para evasões simples, as equipes de segurança devem adotar uma estratégia de defesa em camadas:
A. Controle de aplicações avançado (WDAC e AppLocker)
A Microsoft recomenda o Windows Defender Application Control (WDAC) como a evolução do AppLocker. Bloqueios baseados apenas no nome do arquivo (como tentar impedir a execução do powershell.exe) são facilmente burlados. Atacantes experientes podem utilizar outras instâncias, como o PowerShell Core (pwsh.exe), ou abusar de outros LOLBins legítimos do Windows para executar códigos secundários, como mshta.exe, rundll32.exe, regsvr32.exe, cscript.exe ou wscript.exe. Por isso, o controle de aplicações deve ser estruturado com base em regras de Fornecedor (Publisher) e hashes, limitando o uso do terminal a grupos autorizados.
B. Constrained language mode (CLM) e assinatura de scripts
Se o PowerShell não puder ser totalmente restrito para o usuário devido a dependências operacionais específicas, a ativação do Constrained Language Mode (CLM) via Política de Grupo (GPO) é a alternativa recomendada. O CLM limita severamente as funções permitidas no terminal, impedindo chamadas diretas de classes .NET não assinadas e manipulações de memória. Isso reduz significativamente a capacidade de execução de scripts maliciosos complexos. Complementarmente, deve-se exigir políticas de Script Signing (como AllSigned), garantindo que apenas scripts homologados e assinados digitalmente pela empresa funcionem no ambiente.
C. Proteção do AMSI e desativação do PowerShell 2.0
O Antimalware Scan Interface (AMSI) permite que os scripts sejam inspecionados em tempo real pelas soluções de segurança antes de serem executados. Uma tática comum de evasão é forçar o downgrade do PowerShell para a versão 2.0, que não possui suporte aos recursos modernos de auditoria e ignora o AMSI. Remover o PowerShell 2.0 das estações de trabalho elimina essa superfície de ataque e retira do ambiente um software sem suporte oficial da Microsoft.
D. Regras de redução da superfície de ataque (ASR) e JEA
A implementação das Attack Surface Reduction (ASR) Rules ajuda a quebrar a cadeia de ataque antes que ela chegue ao console. Regras como “Block process creation from Office communication apps” impedem que um arquivo do Word ou Outlook invoque o CMD ou o PowerShell em segundo plano. Para os profissionais técnicos que realmente necessitam do terminal para gerenciamento, deve-se adotar o conceito de Just Enough Administration (JEA), garantindo que eles executem apenas os comandos específicos necessários para suas funções, reduzindo o risco de abuso de privilégios.
Conclusão
Melhorar a postura de cibersegurança de uma organização não exige necessariamente a aquisição de novas ferramentas de alto custo. Muitas vezes, os ganhos mais significativos vêm do hardening adequado dos recursos já existentes.
Restringir o acesso interativo ao PowerShell e ao CMD para os usuários finais é uma medida de alto impacto e baixo custo. Ela mitiga de forma direta a eficiência das táticas de Living off the Land, protege a integridade dos endpoints e alinha a infraestrutura da empresa com os padrões de conformidade internacionais mais respeitados do mercado.
Assine a nossa News e siga o Itshow nas redes sociais para ficar por dentro de todas as notícias do setor de TI e Cibersegurança!