Como achar processo suspeito no Windows com Get-Process

O PC está lento, a ventoinha não para e o Gerenciador de Tarefas mostra uma lista de nomes que parecem todos legítimos: svchost.exe aparece quinze vezes, e um deles pode ser um impostor. O Gerenciador mostra o nome, mas não responde o que importa: de onde esse executável veio, quem assinou e quem o iniciou. O Get-Process do PowerShell, combinado com mais dois cmdlets, responde as três perguntas em poucos minutos.

O que o Get-Process entrega

Segundo a documentação da Microsoft, o Get-Process lista os processos do computador local e devolve objetos System.Diagnostics.Process, com dezenas de propriedades. Funciona no Windows PowerShell 5.1 e no PowerShell 7. As que interessam para triagem:

• Id: o PID do processo.
• ProcessName: o nome, sem a extensão.
• Path: o caminho completo do executável.
• StartTime: quando o processo começou.
• CPU: tempo total de processador usado, em segundos (acumulado, não é o percentual atual).
• WorkingSet: memória em uso, em bytes.

Abra o PowerShell como administrador. Sem elevação, o Path de processos protegidos pode vir vazio, e a documentação lembra que os parâmetros -Module e -FileVersionInfo exigem execução como administrador para processos que não são seus.

Como ver os processos que mais consomem CPU no PowerShell?

Rode Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 para listar os dez processos com mais tempo de CPU acumulado.

Get-Process |
  Sort-Object CPU -Descending |
  Select-Object -First 10 Name, Id, CPU, StartTime,
    @{n='MB';e={[math]::Round($_.WorkingSet/1MB)}}, Path

Como o CPU é acumulado, um serviço antigo de sistema sempre aparece no topo. Olhe com atenção para o que é recente: compare o StartTime com o momento em que a lentidão começou. Um processo desconhecido, iniciado de madrugada e já com muito tempo de CPU, merece investigação.

Passo 1: de onde o executável está rodando?

Programas legítimos moram em C:\Windows ou C:\Program Files. Malware costuma rodar de pastas onde o usuário comum consegue gravar: AppData, Temp, Downloads, ProgramData. Este filtro mostra tudo que está fora dos dois lugares esperados:

Get-Process |
  Where-Object { $_.Path -and $_.Path -notmatch '^C:\\(Windows|Program Files)' } |
  Select-Object Name, Id, StartTime, Path |
  Sort-Object Path

O regex cobre Program Files e Program Files (x86). Muito programa legítimo aparece aqui, como Chrome, Discord e Teams, que se instalam em AppData. Por isso a lista é um ponto de partida, não um veredito. O sinal de alerta é um nome que imita um processo do sistema (svchost.exe, explorer.exe, lsass.exe) rodando fora de C:\Windows\System32.

Passo 2: o executável tem assinatura digital válida?

O Get-AuthenticodeSignature lê a assinatura Authenticode de um arquivo. Ele só existe em Windows, conforme a documentação, e quando o arquivo tem assinatura embutida e de catálogo, usa a de catálogo. Cruze com os processos:

Get-Process | Where-Object Path | Select-Object -Unique Path |
  ForEach-Object {
    $s = Get-AuthenticodeSignature -LiteralPath $_.Path
    [pscustomobject]@{
      Status = $s.Status
      Signer = $s.SignerCertificate.Subject
      Path   = $_.Path
    }
  } | Where-Object Status -ne 'Valid' | Format-Table -AutoSize

O resultado são os executáveis em memória sem assinatura válida (NotSigned, HashMismatch, NotTrusted). Software pequeno e ferramenta interna de empresa costumam ser sem assinatura, então nem tudo é malware. Mas um HashMismatch, que indica arquivo alterado depois de assinado, pede atenção imediata.

Um aviso importante: assinatura válida não significa arquivo seguro. Ela prova que o arquivo não foi alterado depois de assinado e que o certificado é confiável, nada além disso. Atacantes usam certificados roubados e abusam de binários legítimos da própria Microsoft. A assinatura serve para descartar o óbvio, não para dar o processo como inocente.

Passo 3: quem iniciou o processo?

O Get-Process não mostra o processo pai nem a linha de comando. Para isso, use a classe Win32_Process do WMI:

Get-CimInstance Win32_Process |
  Select-Object ProcessId, ParentProcessId, Name, CommandLine |
  Sort-Object ParentProcessId

Com o ParentProcessId você reconstrói a árvore. Algumas relações são normais e outras são suspeitas:

• Normal: o svchost.exe legítimo é iniciado pelo services.exe e roda de C:\Windows\System32.
• Suspeito: powershell.exe ou cmd.exe como filho de winword.exe, excel.exe ou do navegador. É o padrão clássico de macro maliciosa ou de documento que dispara um comando.
• Suspeito: CommandLine com -EncodedCommand, -WindowStyle Hidden ou download de URL.

Cuidado ao colar essa saída em chamado ou fórum: a linha de comando pode conter senhas e tokens passados como argumento.

Passo 4: o processo está falando com a internet?

Ligue o PID às conexões de rede com o Get-NetTCPConnection:

Get-NetTCPConnection -State Established |
  Select-Object RemoteAddress, RemotePort, OwningProcess,
    @{n='Processo';e={(Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName}} |
  Sort-Object Processo

Um processo que você não reconhece, com conexão estabelecida para um IP externo em porta incomum, fecha o quadro. O post sobre auditoria de portas abertas com Get-NetTCPConnection detalha esse cmdlet.

Achei algo estranho. E agora?

Antes de encerrar o processo, anote as evidências: o Path, o CommandLine e o hash do arquivo, que você gera com o Get-FileHash para consultar em um serviço de reputação como o VirusTotal. Depois, encerre:

Stop-Process -Id 1234 -Force

Matar o processo é só o primeiro passo. Se for malware, ele provavelmente tem como voltar: uma tarefa agendada, um serviço ou uma chave de inicialização. Se o processo reaparecer depois de encerrado, é sinal de persistência. Em máquina de trabalho, avise o time de segurança antes de mexer em mais coisa, e em PC pessoal considere desconectar da rede e rodar uma verificação completa com o Microsoft Defender.

Lição maior

Nome de processo não prova nada, porque qualquer um pode chamar um executável de svchost.exe. O que identifica de verdade é o conjunto: caminho, assinatura, pai e comportamento de rede. Para registrar esse tipo de atividade de forma permanente, configure os logs de auditoria do PowerShell e, se quiser aprofundar a rotina de triagem, siga para a revisão de tarefas agendadas e persistência.