Cibersegurança e segurança da informação

Escrita de uma primeira regra YARA para identificar um ficheiro suspeito

6 min de leituraPublicado: 5 de agosto de 2026
Ilustração visual profissional sobre a escrita de regras YARA na área de Resposta a Incidentes e DFIR
Resposta rápida

A escrita de regras YARA é um processo controlado que equilibra a contenção de danos com a preservação de provas. Documente a fonte, o tempo e as ferramentas, guarde o Hash, construa uma Linha do Tempo e separe factos, interpretações e decisões.

A Resposta a Incidentes (Incident Response) e o DFIR (Digital Forensics and Incident Response) exigem um equilíbrio entre velocidade, preservação de provas, continuidade de negócios e documentação. Uma ação correta é uma ação que pode ser explicada, reproduzida e revista após o incidente. Este artigo foca-se na escrita de regras YARA e destina-se a estudantes de Malware e Deteção. O objetivo é fornecer uma metodologia de trabalho que possa ser aplicada na prática, em entrevistas profissionais e em ambientes de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados são quase sempre parciais. Os metadados da regra, as strings e a condição podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos a verificação em torno de uma questão de investigação, provas necessárias e um critério claro para a conclusão.

O cenário prático neste artigo é: uma regra YARA para identificar um ficheiro de laboratório com marcadores únicos. Todas as amostras são dados de laboratório ou descrições de processos. No caso de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de interromper o teste.

Estrutura da Regra

Os campos importantes não são necessariamente os que aparecem no topo do ecrã. Na escrita de regras YARA, é necessário identificar identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis são metadados da regra, strings, condição, modificadores wide/ascii, corpus de teste de falsos positivos, controlo de versão. O objetivo é permitir a Correlação entre registos e não apenas a leitura de um único Evento.

Recomenda-se criar um pequeno dicionário de dados: nome do campo, significado, formato, origem, valores Nulos esperados e se é fiável para ligação. Desta forma, é possível distinguir entre um campo de exibição e um identificador investigativo, e identificar quando um Conector ou versão alterou o Schema.

Strings e os seus tipos

O tópico 'Strings e os seus tipos' é uma parte central do trabalho na escrita de regras YARA. Recomenda-se dividi-lo em três questões: qual é a entrada, que decisão se pretende tomar e que prova é suficiente para a justificar. Estas questões evitam o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe os metadados da regra, strings, condição, modificadores wide/ascii, corpus de teste de falsos positivos, 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.

Condições

O tópico 'Condições' é uma parte central do trabalho na escrita de regras YARA. Recomenda-se dividi-lo em três questões: qual é a entrada, que decisão se pretende tomar e que prova é suficiente para a justificar. Estas questões evitam o uso automático da ferramenta sem compreender o objetivo.

Na prática, registe os metadados da regra, strings, condição, modificadores wide/ascii, corpus de teste de falsos positivos, 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.

Testes e Falsos Positivos

Um teste profissional para a escrita de regras YARA começa com condições de sucesso e condições de falha. Define-se um Caso positivo, um Caso negativo, um Caso limite e uma atividade legítima semelhante. Desta forma, é possível identificar tanto Falsos Negativos quanto Falsos Positivos.

Num ambiente autorizado, utiliza-se a ação mínima que prova a alegação sem causar danos. Guardam-se a Entrada, a Saída, o tempo e a versão, e após a correção, realiza-se um Reteste no mesmo cenário e verifica-se também a Regressão em funções adjacentes.

Versionamento e Documentação

A documentação da escrita de regras YARA deve permitir que uma pessoa que não participou no trabalho compreenda o que aconteceu e reproduza a conclusão. Separam-se factos, interpretações, suposições e decisões, e associa-se cada afirmação a uma prova, consulta ou captura de ecrã.

Uma estrutura útil inclui Resumo, Âmbito, Linha do Tempo, Provas, Impacto, Ações, Limitações e Próximos Passos. Num relatório de PT, adiciona-se Remediação e Reteste; numa investigação, adiciona-se Contenção, Recuperação e Lições Aprendidas.

Pontos de verificação únicos

Neste tópico, é recomendável construir um mapa de provas focado antecipadamente. Os principais pontos de verificação são: metadados da regra, strings, condição, modificadores wide/ascii, corpus de teste de falsos positivos, controlo de versão. A lista não é uma Lista de Verificação automática; cada item é selecionado porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

  • Metadados da regra: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional confirmará a descoberta.
  • Strings: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional confirmará a descoberta.
  • Condição: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional confirmará a descoberta.
  • Modificadores wide/ascii: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional confirmará a descoberta.
  • Corpus de teste de falsos positivos: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional confirmará a descoberta.
  • Controlo de versão: Defina qual é o valor esperado, o que será considerado excecional e qual fonte adicional confirmará a descoberta.

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

Processo de trabalho recomendado

  1. Defina o Âmbito e uma questão de trabalho sobre a escrita de regras YARA.
  2. Registe as fontes de dados e as provas necessárias: metadados da regra, strings, condição, modificadores wide/ascii.
  3. Crie uma Linha de Base 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. Construa uma Linha do Tempo ou tabela de comparação e separe os factos da interpretação.
  6. Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
  7. Resuma a decisão, limitações, ação recomendada e critério de Reteste.

Cenário prático

O cenário escolhido é uma regra YARA para identificar um ficheiro de laboratório com marcadores únicos. 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 fictícios, uma janela de tempo e um resultado esperado.

No final do exercício, deve-se apresentar um produto que outro analista ou testador possa rever: uma captura de ecrã ou Exportação da prova, uma breve Linha do Tempo, uma suposição inicial, uma prova de validação, uma limitação e uma recomendação. Quando não há provas suficientes, a conclusão correta é que o cenário não foi provado.

FaseO que é realizadoProduto
PreparaçãoDefina o Âmbito, tempo e objetivo. Registe quais campos ou provas dos metadados da regra, strings, condição são esperados.Plano de teste curto
Criação de dadosExecute uma ação segura e simulada relacionada com a escrita de regras YARA, sem informações reais ou impacto num sistema de produção.Evento/Pedido/Fluxo controlado
RecolhaRecolha a prova bruta e o contexto de uma fonte adicional. Verifique o fuso horário, identificadores e integridade.Duas provas ligadas
AnáliseEscreva o que cada prova demonstra, o que não demonstra e qual é a explicação legítima possível.Conclusão intermédia
ConclusãoEscolha fechar, escalar, Encontrar ou Ajustar; adicione uma recomendação e Reteste.Produto documentado

Lista de Verificação Prática

  • Verifique e documente: Fonte da prova.
  • Verifique e documente: Hora de recolha e fuso horário.
  • Verifique e documente: Hash e Cadeia de Custódia.
  • Verifique e documente: Ferramenta e versão.
  • Verifique e documente: Ações de resposta realizadas.
  • Verifique e documente: Linha do tempo e suposições de trabalho.
  • Indique o fuso horário, a versão da ferramenta e a hora de recolha.
  • Guarde os dados brutos antes da filtragem ou modificação.
  • Escreva o que a descoberta prova e o que ainda é desconhecido.
  • Defina um proprietário e uma ação de acompanhamento com prazo.

Erros Comuns

  • Alterar o sistema antes de preservar as provas.
  • Não documentar o fuso horário.
  • Não calcular o Hash.
  • Misturar factos e suposições.
  • Não documentar quem deteve a prova.
  • Preferir a integridade teórica em detrimento da contenção imediata de danos.

Resumo e CTA

A escrita de uma primeira regra YARA para identificar um ficheiro suspeito é um tópico que combina conhecimento técnico com disciplina de trabalho. Comece com uma pergunta, recolha apenas provas relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e revista.

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

Perguntas frequentes

A escrita de uma regra YARA por si só prova um ataque ou vulnerabilidade?

Não. Ela fornece um sinal ou uma descoberta que precisa de contexto, validação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de provas e na sua conformidade com o comportamento esperado.

O que fazer quando alguns dados estão em falta?

Documentar a ausência, verificar uma fonte alternativa e reduzir o nível de confiança. Não se devem completar campos por suposição nem apresentar o Desconhecido como válido.

Quanto tempo devem ser guardadas as provas?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir previamente a Retenção, a retenção legal (Legal hold) e a capacidade de exportar provas num formato que possa ser verificado.

Como praticar sem comprometer um sistema real?

Utilizar máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, definir o Âmbito, as condições de paragem e um backup antes de iniciar o trabalho.

Quer verificar se este percurso é para si?

Deixe os seus dados e um consultor da HPI ligará para uma breve conversa de adequação, sem compromisso.

Os seus dados são armazenados em segurança.

Para estudos SOC e cibersegurança no programa Cybersecurity & AI

Quer os detalhes do programa? Deixe os seus dados e entraremos em contacto.

Artigos relacionados