Nas últimas semanas venho reproduzindo, em VMs (máquinas virtuais) locais, alguns laboratórios de Segurança da Informação. Em um deles apareceu este comando:

Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled

Anos de linguagens convencionais me fizeram ler o | como OR. Não é. E, para entender o porquê, vale voltar um pouco no tempo.

Um pouco de história

No início dos anos 2000, administrar Windows era, basicamente, clicar. O Unix já tinha um shell maduro, mas suas ferramentas trocavam texto entre si, e o Windows era construído sobre APIs e objetos (COM, WMI, .NET). Ferramentas baseadas em texto não encaixavam.

Em 2002, Jeffrey Snover publicou o Monad Manifesto, propondo um shell em que os comandos trocassem objetos, não texto. O projeto Monad virou o Windows PowerShell 1.0 em 2006, passou a vir instalado por padrão a partir do Windows 7 e, em 2016, tornou-se open source e multiplataforma.

O paradigma por trás do |

O PowerShell é multiparadigma: imperativo, orientado a objetos e com traços funcionais. Mas o pipeline segue a programação orientada a fluxo de dados (dataflow), materializada no estilo arquitetural pipes and filters.

Em linguagens como C, Java ou C#, o | é um operador: recebe dois valores e devolve um resultado. No PowerShell, é um conector: liga a saída de um comando à entrada do próximo. Em vez de aninhar chamadas, como g(f(x)), você encadeia etapas: f | g. E o que trafega são objetos .NET, com tipo e propriedades, processados um a um.

Onde entra a segurança

A consequência prática do Manifesto foi que tudo o que se faz pela interface gráfica passou a poder ser feito pela linha de comando.

Para administração, isso é automação. Para um atacante, é o cenário ideal: uma ferramenta assinada pela Microsoft, presente em todo Windows, com acesso a .NET, WMI e às APIs do sistema. É a base da técnica conhecida como Living off the Land: usar o que já existe na máquina em vez de levar um malware que o antivírus detectaria.

O comando do início ilustra bem: em uma linha, um invasor descobre se o Defender está ativo. Não à toa, o MITRE ATT&CK cataloga o PowerShell como técnica própria (T1059.001), presente em reconhecimento, execução em memória, comandos ofuscados com -EncodedCommand e movimentação lateral.

Do lado defensivo, a resposta veio com o tempo: Script Block Logging (evento 4104), AMSI para inspecionar scripts antes da execução e Constrained Language Mode. E um lembrete importante: Execution Policy não é barreira de segurança.

Entender o paradigma de uma ferramenta não é só curiosidade acadêmica. Quem lê um pipeline como fluxo de objetos entende o que um script está fazendo, e, em segurança, entender é o primeiro passo para detectar.