Análise Forense em Computadores: Buscando por Malware com Eventos do Windows Defender
Este artigo explora como os eventos do Windows Defender podem ser usados para identificar malware em investigações de segurança cibernética. Ele detalha a análise de artefatos, a descriptografia de arquivos e o uso de scripts para auxiliar na detecção de ameaças.
MundiX News·01 de maio de 2026·25 min de leitura·👁 1 views
Olá, leitores do MundiX! A equipe uFactor preparou este artigo para discutir uma técnica útil na busca por malware, que pode complementar a análise de sistemas de computadores durante investigações de incidentes de segurança da informação. Infelizmente, este método nem sempre é eficaz: os rastros de atividade do Windows Defender, que serão analisados a seguir, podem ser completamente apagados – por isso, este método só pode ser usado como um complemento ao método principal de investigação.
Muitos utilizam a análise de logs de eventos (Event ID 1116, Event ID 1117 Windows Defender), bem como entradas e arquivos da quarentena, em suas investigações. No entanto, neste artigo, focaremos nos eventos de varredura de arquivos do Windows Defender, que o usuário baixa ou que aparecem no sistema do computador por outros motivos. Os artefatos que indicam a varredura do Windows Defender são armazenados em arquivos, por exemplo: .\ProgramData\Microsoft\WindowsDefender\Scans\History\Results\Resource{8C9221F8-4026-473E-A0B6-3D6981F102F0}. No log Microsoft-Windows-WindowsDefender, você não verá eventos de varredura se o arquivo não tiver recebido o status de malware. Os nomes dos arquivos têm o formato UUID versão 4, de acordo com o padrão RFC 4122. Esses nomes não contêm informações úteis, ao contrário, por exemplo, dos nomes UUID versão 1 (analisados em nosso artigo "Análise Forense em Computadores. Carimbos de Data/Hora e Tunneling NTFS"). O conteúdo dos arquivos é criptografado com o algoritmo RC4 com a seguinte chave:
É uma história conhecida, mas vamos relembrar como descriptografar esses arquivos. O arquivo contém informações que podem ser úteis e é dividido em três blocos. A descriptografia, assim como a criptografia, ocorre por blocos. Primeiro, o primeiro bloco é descriptografado, e a partir dele, o processo obtém os comprimentos (tamanhos) para os outros dois blocos. Em seguida, os segundo e terceiro blocos são descriptografados.
Na Figura 1, é apresentado um fragmento do arquivo {5FB5EA10-7DFB-48BC-B1AA-4E7954F5F25F}, os dados nele estão criptografados. Em vermelho, o primeiro bloco é destacado. Seu tamanho é sempre de 60 bytes, os primeiros 48 bytes (D3–0F) e os últimos 4 bytes (3E10D35E) sempre têm o mesmo valor.
Vamos descriptografar o primeiro bloco. Para isso, usaremos, por exemplo, o recurso DevTools.
Na Figura 2, o primeiro bloco que estamos descriptografando é destacado em verde, e um fragmento da chave E87781B8DBAA844CE69702C0C78B786A3F623B738F5EDF9AF83530FB3FC54FAA21EB9CF1331FD0F0DA954F687CB9E18279697900E53FB317C9CBCE48E23D05371ECC15951B8F3649D7CA33ED68DC9047E82C9BAAD9799D0D458CB847CA9FFBE3C8A775233557DDE13A8B14087CC1BC8F10F6ECDD083A959CFF84A9D1D50755E3E191818AF23E2293558766D2C07E25712B2CA0B535ED8F6C56CE73D24BDD0291771861A54B4C285A9A3DB7ACA6D224AEACD621DB9F2A22ED1E9E11D75BED7DC0ECB0A8E68A2FF1263408DC808DFFD164B116774CD0B9B8D05411ED6262E429BA495676B8398DB2F35D3C1B9CED52636F2765E1A95CB7CA4C3DDABDDBFF38253 para descriptografia. Em vermelho, o resultado da descriptografia é indicado. Vamos analisá-lo em um editor hexadecimal.
Na Figura 3, o mais importante aqui são os tamanhos dos dois blocos subsequentes. Para cada bloco, um DWORD é alocado para indicar o tamanho (ver Figura 3):
Cor verde – tamanho do segundo bloco, na prática sempre 30 hex (48 dec), lido em little-endian, ou seja, 0x00000030. Obviamente, o início do segundo bloco é a partir do 61º byte.
Cor vermelha – tamanho do terceiro bloco, 2D5A hex (11610 dec), lido em little-endian, ou seja, 0x00002D5A. O início do terceiro bloco é a partir do 109º byte (61 + 48).
Voltando ao arquivo {5FB5EA10-7DFB-48BC-B1AA-4E7954F5F25F}: na Figura 4, o segundo bloco é destacado, copiamos seus bytes e descriptografamos usando o DevTools.
Na Figura 5, não acho que precisemos de explicações, pegaremos os dados descriptografados do segundo bloco (destacados em vermelho) e os colocaremos em um editor hexadecimal para facilitar a leitura.
Na Figura 6, o UUID do arquivo {5FB5EA10-7DFB-48BC-B1AA-4E7954F5F25F} é destacado em verde:
10EAB55F – 5FB5EA10 (little-endian);
FB7D – 7DFB (little-endian);
BC48 – 48BC (little-endian);
B1AA – a sequência é preservada;
4E7954F5F25F – a sequência é preservada.
Em preto, o carimbo de data/hora no formato Windows FILETIME: 396BD3B50B53DC01 – 01DC530BB5D36B39 (2025-11-11 13:04:27.454956). Aparentemente, este é o tempo de criação do arquivo e o término da varredura. Isso não nos ajudará mais.
Agora, vamos analisar o bloco final, um fragmento dele é apresentado na Figura 7.
Copiamos os bytes e descriptografamos.
Na Figura 8, acho que não há necessidade de comentar. Em seguida, abrimos o resultado obtido em um editor hexadecimal.
Na Figura 9, os carimbos de data/hora no formato Windows FILETIME são destacados em verde, o restante são alguns padrões. Vale ressaltar: se o Defender determinar que o arquivo é malware, informações – atribuição e caminho do arquivo – serão registradas nesta parte.
Na verdade, não há nada de útil para nós nesses arquivos, e em nossa investigação posterior, seu conteúdo não ajudará em nada. Na verdade, informações úteis, incluindo o caminho para o arquivo ao qual a varredura é aplicada, são armazenadas em outro arquivo: .\ProgramData\Microsoft\WindowsDefender\Scans\History\Store<filename
O arquivo também é criptografado, mas possui dois blocos. O primeiro bloco é semelhante ao que analisamos acima, mas contém apenas o comprimento do segundo bloco. Vamos recorrer ao arquivo com o nome C21B59DA7D4B3B5BD570A20BBB540353
Na Figura 10, o primeiro bloco descriptografado é destacado em verde. Em amarelo, o indicador do tamanho do segundo bloco, lemos ao contrário: 0x04AB = 1195 dec. Em seguida, vem o segundo bloco – como você pode ver, ele começa com o tamanho do próprio bloco (indicado em preto).
Na Figura 11, é apresentado um exemplo. O arquivo …rypt.exe foi extraído do arquivo, …rypt.exe:Zone.Identifier indica que o arquivo foi baixado da Internet por meio de um navegador e o WinRAR copiou a marca Zone.Identifier do arquivo para um arquivo potencialmente inseguro. O arquivo readme.txt também foi extraído do arquivo, mas não recebeu Zone.Identifier, pois o WinRAR considerou o arquivo de texto seguro. No final, vemos arquivos relacionados à varredura.
A combinação …Scans\History\Store e …Scans\History\Results\Resource é muito rara, por isso não nos concentramos nisso. No entanto, tenha em mente: se você vir essa combinação no MFT, e os arquivos anteriores não forem notáveis, então, muito provavelmente, o arquivo foi excluído. Nesse caso, você precisa descriptografar o arquivo de …Scans\History\Store e olhar as informações lá.
A seguir, um script para descriptografar arquivos: na entrada – uma pasta com arquivos criptografados, na saída – uma pasta para descriptografados.
[Código Python para descriptografia de arquivos, conforme fornecido no artigo original]
Vamos voltar ao tema principal. Também há problemas com os arquivos armazenados na pasta …Scans\History\Results\Resource: eles nem sempre são armazenados lá e, com o tempo, são completamente excluídos. Mas você pode ver um grande número de arquivos marcados no $MFT como não utilizados – é claro, com atributos salvos.
Além disso, há outro problema: o arquivo anterior ao evento de varredura foi excluído. Nesse caso, sem artefatos adicionais, não é possível entender qual arquivo o Defender reagiu.
Agora, vamos analisar como a linha do tempo no $MFT se parece com uma real comprometimento do sistema de computador. Nas Figuras 13, 14 e 15, são apresentados fragmentos do $MFT. Os arquivos destacados foram carregados pelo invasor usando malware.
A seguir, um script para pesquisar eventos relacionados à varredura de arquivos. O script funciona com um arquivo CSV extraído do $MFT usando o utilitário MFTECmd.exe (ferramentas de Eric Zimmerman). Os eventos são gravados em um arquivo JSON. Por padrão, os 5 eventos anteriores são gravados, essa quantidade pode ser alterada.
[Código Python para pesquisa de artefatos do Windows Defender, conforme fornecido no artigo original]
Para concluir, mais uma vez, observamos que a análise de eventos do Windows Defender pode ser uma ferramenta muito útil na investigação de incidentes de segurança da informação. Ao mesmo tempo, nem sempre permite obter novos dados – portanto, deve ser usado como uma ajuda para o método principal de investigação.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá, leitores do MundiX! A equipe uFactor preparou este artigo para discutir uma técnica útil na busca por malware, que pode complementar a análise de sistemas de computadores durante investigações de incidentes de segurança da informação. Infelizmente, este método nem sempre é eficaz: os rastros de atividade do Windows Defender, que serão analisados a seguir, podem ser completamente apagados – por isso, este método só pode ser usado como um complemento ao método principal de investigação.
Muitos utilizam a análise de logs de eventos (Event ID 1116, Event ID 1117 Windows Defender), bem como entradas e arquivos da quarentena, em suas investigações. No entanto, neste artigo, focaremos nos eventos de varredura de arquivos do Windows Defender, que o usuário baixa ou que aparecem no sistema do computador por outros motivos. Os artefatos que indicam a varredura do Windows Defender são armazenados em arquivos, por exemplo: .\ProgramData\Microsoft\WindowsDefender\Scans\History\Results\Resource{8C9221F8-4026-473E-A0B6-3D6981F102F0}. No log Microsoft-Windows-WindowsDefender, você não verá eventos de varredura se o arquivo não tiver recebido o status de malware. Os nomes dos arquivos têm o formato UUID versão 4, de acordo com o padrão RFC 4122. Esses nomes não contêm informações úteis, ao contrário, por exemplo, dos nomes UUID versão 1 (analisados em nosso artigo "Análise Forense em Computadores. Carimbos de Data/Hora e Tunneling NTFS"). O conteúdo dos arquivos é criptografado com o algoritmo RC4 com a seguinte chave:
É uma história conhecida, mas vamos relembrar como descriptografar esses arquivos. O arquivo contém informações que podem ser úteis e é dividido em três blocos. A descriptografia, assim como a criptografia, ocorre por blocos. Primeiro, o primeiro bloco é descriptografado, e a partir dele, o processo obtém os comprimentos (tamanhos) para os outros dois blocos. Em seguida, os segundo e terceiro blocos são descriptografados.
Na Figura 1, é apresentado um fragmento do arquivo {5FB5EA10-7DFB-48BC-B1AA-4E7954F5F25F}, os dados nele estão criptografados. Em vermelho, o primeiro bloco é destacado. Seu tamanho é sempre de 60 bytes, os primeiros 48 bytes (D3–0F) e os últimos 4 bytes (3E10D35E) sempre têm o mesmo valor.
Vamos descriptografar o primeiro bloco. Para isso, usaremos, por exemplo, o recurso DevTools.
Na Figura 2, o primeiro bloco que estamos descriptografando é destacado em verde, e um fragmento da chave E87781B8DBAA844CE69702C0C78B786A3F623B738F5EDF9AF83530FB3FC54FAA21EB9CF1331FD0F0DA954F687CB9E18279697900E53FB317C9CBCE48E23D05371ECC15951B8F3649D7CA33ED68DC9047E82C9BAAD9799D0D458CB847CA9FFBE3C8A775233557DDE13A8B14087CC1BC8F10F6ECDD083A959CFF84A9D1D50755E3E191818AF23E2293558766D2C07E25712B2CA0B535ED8F6C56CE73D24BDD0291771861A54B4C285A9A3DB7ACA6D224AEACD621DB9F2A22ED1E9E11D75BED7DC0ECB0A8E68A2FF1263408DC808DFFD164B116774CD0B9B8D05411ED6262E429BA495676B8398DB2F35D3C1B9CED52636F2765E1A95CB7CA4C3DDABDDBFF38253 para descriptografia. Em vermelho, o resultado da descriptografia é indicado. Vamos analisá-lo em um editor hexadecimal.
Na Figura 3, o mais importante aqui são os tamanhos dos dois blocos subsequentes. Para cada bloco, um DWORD é alocado para indicar o tamanho (ver Figura 3):
Cor verde – tamanho do segundo bloco, na prática sempre 30 hex (48 dec), lido em little-endian, ou seja, 0x00000030. Obviamente, o início do segundo bloco é a partir do 61º byte.
Cor vermelha – tamanho do terceiro bloco, 2D5A hex (11610 dec), lido em little-endian, ou seja, 0x00002D5A. O início do terceiro bloco é a partir do 109º byte (61 + 48).
Voltando ao arquivo {5FB5EA10-7DFB-48BC-B1AA-4E7954F5F25F}: na Figura 4, o segundo bloco é destacado, copiamos seus bytes e descriptografamos usando o DevTools.
Na Figura 5, não acho que precisemos de explicações, pegaremos os dados descriptografados do segundo bloco (destacados em vermelho) e os colocaremos em um editor hexadecimal para facilitar a leitura.
Na Figura 6, o UUID do arquivo {5FB5EA10-7DFB-48BC-B1AA-4E7954F5F25F} é destacado em verde:
10EAB55F – 5FB5EA10 (little-endian);
FB7D – 7DFB (little-endian);
BC48 – 48BC (little-endian);
B1AA – a sequência é preservada;
4E7954F5F25F – a sequência é preservada.
Em preto, o carimbo de data/hora no formato Windows FILETIME: 396BD3B50B53DC01 – 01DC530BB5D36B39 (2025-11-11 13:04:27.454956). Aparentemente, este é o tempo de criação do arquivo e o término da varredura. Isso não nos ajudará mais.
Agora, vamos analisar o bloco final, um fragmento dele é apresentado na Figura 7.
Copiamos os bytes e descriptografamos.
Na Figura 8, acho que não há necessidade de comentar. Em seguida, abrimos o resultado obtido em um editor hexadecimal.
Na Figura 9, os carimbos de data/hora no formato Windows FILETIME são destacados em verde, o restante são alguns padrões. Vale ressaltar: se o Defender determinar que o arquivo é malware, informações – atribuição e caminho do arquivo – serão registradas nesta parte.
Na verdade, não há nada de útil para nós nesses arquivos, e em nossa investigação posterior, seu conteúdo não ajudará em nada. Na verdade, informações úteis, incluindo o caminho para o arquivo ao qual a varredura é aplicada, são armazenadas em outro arquivo: .\ProgramData\Microsoft\WindowsDefender\Scans\History\Store<filename
O arquivo também é criptografado, mas possui dois blocos. O primeiro bloco é semelhante ao que analisamos acima, mas contém apenas o comprimento do segundo bloco. Vamos recorrer ao arquivo com o nome C21B59DA7D4B3B5BD570A20BBB540353
Na Figura 10, o primeiro bloco descriptografado é destacado em verde. Em amarelo, o indicador do tamanho do segundo bloco, lemos ao contrário: 0x04AB = 1195 dec. Em seguida, vem o segundo bloco – como você pode ver, ele começa com o tamanho do próprio bloco (indicado em preto).
Na Figura 11, é apresentado um exemplo. O arquivo …rypt.exe foi extraído do arquivo, …rypt.exe:Zone.Identifier indica que o arquivo foi baixado da Internet por meio de um navegador e o WinRAR copiou a marca Zone.Identifier do arquivo para um arquivo potencialmente inseguro. O arquivo readme.txt também foi extraído do arquivo, mas não recebeu Zone.Identifier, pois o WinRAR considerou o arquivo de texto seguro. No final, vemos arquivos relacionados à varredura.
A combinação …Scans\History\Store e …Scans\History\Results\Resource é muito rara, por isso não nos concentramos nisso. No entanto, tenha em mente: se você vir essa combinação no MFT, e os arquivos anteriores não forem notáveis, então, muito provavelmente, o arquivo foi excluído. Nesse caso, você precisa descriptografar o arquivo de …Scans\History\Store e olhar as informações lá.
A seguir, um script para descriptografar arquivos: na entrada – uma pasta com arquivos criptografados, na saída – uma pasta para descriptografados.
[Código Python para descriptografia de arquivos, conforme fornecido no artigo original]
Vamos voltar ao tema principal. Também há problemas com os arquivos armazenados na pasta …Scans\History\Results\Resource: eles nem sempre são armazenados lá e, com o tempo, são completamente excluídos. Mas você pode ver um grande número de arquivos marcados no $MFT como não utilizados – é claro, com atributos salvos.
Além disso, há outro problema: o arquivo anterior ao evento de varredura foi excluído. Nesse caso, sem artefatos adicionais, não é possível entender qual arquivo o Defender reagiu.
Agora, vamos analisar como a linha do tempo no $MFT se parece com uma real comprometimento do sistema de computador. Nas Figuras 13, 14 e 15, são apresentados fragmentos do $MFT. Os arquivos destacados foram carregados pelo invasor usando malware.
A seguir, um script para pesquisar eventos relacionados à varredura de arquivos. O script funciona com um arquivo CSV extraído do $MFT usando o utilitário MFTECmd.exe (ferramentas de Eric Zimmerman). Os eventos são gravados em um arquivo JSON. Por padrão, os 5 eventos anteriores são gravados, essa quantidade pode ser alterada.
[Código Python para pesquisa de artefatos do Windows Defender, conforme fornecido no artigo original]
Para concluir, mais uma vez, observamos que a análise de eventos do Windows Defender pode ser uma ferramenta muito útil na investigação de incidentes de segurança da informação. Ao mesmo tempo, nem sempre permite obter novos dados – portanto, deve ser usado como uma ajuda para o método principal de investigação.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
