PowerShell Logging: Como identificar atividade suspeita

Registo Operacional do PowerShell

O tópico 'Registo Operacional do PowerShell' é uma parte central do trabalho sobre PowerShell Logging. É recomendado dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para a justificar. Estas perguntas impedem o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote o Event 4104 Script Block Logging, o Event 4103 Module Logging, o canal operacional, a linha de comando e o processo pai, o contexto AMSI/EDR, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Script Block e Registo de Módulos

Nesta fase, define-se quais as provas necessárias para responder à questão de investigação. Para o PowerShell Logging, os pontos base são o Event ID e o Provider, o Computador, o Utilizador e o Logon ID, o Processo, o Pai e a Linha de Comando, o IP de Origem, a Estação de Trabalho e o Tipo de Logon. Para cada fonte, são registados o proprietário, o período de retenção, o fuso horário, o atraso de ingestão e os campos que podem estar em falta.

A qualidade da recolha não é medida pelo facto de o registo 'chegar'. É necessário verificar a Completude, a Latência, a Análise, os Eventos Duplicados e a Sincronização de Tempo. Um teste Canary ou um evento de laboratório conhecido permite verificar se a ação apareceu na origem, passou pelo Pipeline e pode ser pesquisada nos campos corretos.

Transcrição e 4688/Sysmon

O tópico 'Transcrição e 4688/Sysmon' é uma parte central do trabalho sobre PowerShell Logging. É recomendado dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para a justificar. Estas perguntas impedem o uso automático de uma ferramenta sem entender o objetivo.

Na prática, anote o Event 4104 Script Block Logging, o Event 4103 Module Logging, o canal operacional, a linha de comando e o processo pai, o contexto AMSI/EDR, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Padrões de Investigação

A investigação de PowerShell Logging começa com a formulação de uma Hipótese: que comportamento explica a descoberta, e que provas a confirmarão ou refutarão. Em seguida, expande-se a janela de tempo, verificam-se as entidades e procura-se uma sequência antes e depois do evento.

Uma boa correlação combina pelo menos dois tipos de informação de Event 4104 Script Block Logging, Event 4103 Module Logging, canal operacional, linha de comando e processo pai, contexto AMSI/EDR. Para cada descoberta, indica-se o que ela prova, o que não prova e qual é o próximo passo. Se os dados forem insuficientes, marca-se como Desconhecido e não se transforma a ausência de provas em prova de ausência.

Otimização para atividade de administrador

A melhoria do PowerShell Logging deve começar com um Baseline. Medem-se o volume, a taxa de casos úteis, o tempo de investigação, as fontes em falta e a razão para o fecho. Uma alteração que reduz os Alertas, mas oculta a atividade real, não é um sucesso.

As opções de Otimização incluem limiar, janela de tempo, Allowlist direcionada, Contexto do ativo, Supressão e exceção baseada num processo aprovado. Cada exceção deve ter um proprietário, validade e condições de cancelamento. Após a alteração, executa-se um Test corpus e compara-se antes/depois.

Focos de Teste Exclusivos

Neste tópico, é recomendável construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: Event 4104 Script Block Logging, Event 4103 Module Logging, canal operacional, linha de comando e processo pai, contexto AMSI/EDR. A lista não é uma Checklist automática; cada item é selecionado porque pode ligar uma entidade, ação e tempo, ou explicar um comportamento legítimo.

• Event 4104 Script Block Logging: Defina qual o valor esperado, o que será considerado uma exceção e qual a fonte adicional que verificará a descoberta.
• Event 4103 Module Logging: Defina qual o valor esperado, o que será considerado uma exceção e qual a fonte adicional que verificará a descoberta.
• Canal operacional: Defina qual o valor esperado, o que será considerado uma exceção e qual a fonte adicional que verificará a descoberta.
• Linha de comando e processo pai: Defina qual o valor esperado, o que será considerado uma exceção e qual a fonte adicional que verificará a descoberta.
• Contexto AMSI/EDR: Defina qual o valor esperado, o que será considerado uma exceção e qual a fonte adicional que verificará a descoberta.

Quando um dos focos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o identificador de Processo não for estável, pode-se usar o tempo, Host, Utilizador e Pai; se o Payload estiver encriptado, usam-se Metadados, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

1. Defina o Scope e uma questão de trabalho sobre PowerShell Logging.
2. Registe as fontes de dados e as provas necessárias: Event 4104 Script Block Logging, Event 4103 Module Logging, canal operacional, linha de comando e processo pai.
3. Crie uma Baseline curta de comportamento normal ou resultado esperado.
4. Realize o teste mínimo num ambiente de laboratório e guarde o tempo, a entrada e a saída.
5. Crie uma Timeline ou tabela de comparação e separe facto de interpretação.
6. Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
7. Resuma a decisão, as limitações, a ação recomendada e o critério de Retest.

Cenário Prático

O cenário escolhido é a investigação de um script simulado que descarrega um ficheiro num laboratório. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que outro analista ou avaliador possa criticar: uma captura de ecrã ou exportação da evidência, uma Timeline curta, uma suposição inicial, uma evidência de confirmação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Checklist Prático

• ✓Verificar e documentar: Event ID e o Provider.
• ✓Verificar e documentar: Computador, Utilizador e Logon ID.
• ✓Verificar e documentar: Processo, Pai e Linha de Comando.
• ✓Verificar e documentar: IP de Origem, Estação de Trabalho e Tipo de Logon.
• ✓Verificar e documentar: Alterações de Grupo/Privilégios.
• ✓Verificar e documentar: Sysmon ProcessGuid ou SessionGuid.
• ✓Indicar Time zone, versão da ferramenta e hora da recolha.
• ✓Guardar os dados brutos antes da filtragem ou alteração.
• ✓Escrever o que a descoberta prova e o que ainda é desconhecido.
• ✓Definir proprietário e ação de acompanhamento com prazo.

Erros Comuns

• Confiar apenas no Event ID sem os campos.
• Confundir Logon com a fonte do ataque.
• Ignorar o Tipo de Logon.
• Ligar Processos apenas por PID.
• Assumir que todo o PowerShell é malicioso.
• Fechar um evento sem verificar o Domain Controller.

Resumo e CTA

PowerShell Logging: Como identificar atividade suspeita é um tema que combina conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e verificada novamente.

No programa Cybersecurity & AI da HPI, estes princípios são praticados através de sistemas, registos e laboratórios. O próximo passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes