yamato-security/enablewindowslogsettingsDocumentação e scripts para habilitar corretamente os logs de eventos do Windows.
Este é mais um guia sobre como configurar e monitorar adequadamente os logs de eventos do Windows, com ênfase no registro de eventos para as regras do sigma.
Este é um trabalho em andamento, então volte periodicamente para ver atualizações.
Zach Mathis (@yamatosecurity). Conforme eu fizer mais pesquisas e testes, pretendo atualizar este documento periodicamente, pois há muito espaço para melhorias (tanto na documentação quanto na criação de mais regras de detecção.) PRs são bem-vindos e terei prazer em adicioná-lo como colaborador. Se você encontrar algum erro nesta documentação, por favor me avise e corrigirei o mais rápido possível.
Se você achar isso útil, por favor dê uma estrela no GitHub, pois isso provavelmente me motivará a continuar atualizando este trabalho.
A maior parte das informações vem do FAQ de auditoria de segurança avançada da Microsoft, das regras do sigma, do Guia de registro de eventos do ACSC e das minhas próprias pesquisas/testes. Gostaria de agradecer especialmente à comunidade sigma por tornar a detecção de ameaças de código aberto e gratuita em benefício de todos os defensores.
Por padrão, o Windows não registrará muitos eventos necessários para detectar atividades maliciosas e realizar investigações forenses.
Além disso, o tamanho máximo padrão para arquivos de eventos é de apenas 20 MB para os logs de eventos clássicos (Security, System, Application), 15 MB para o PowerShell e apenas 1 MB para quase todos os outros logs, portanto há uma boa chance de que as evidências sejam sobrescritas com o tempo.
Um simples script em lote foi fornecido neste repositório para permitir que administradores de sistemas configurem facilmente suas máquinas Windows para que tenham os logs de que precisam quando um incidente ocorrer. Para redes grandes, você provavelmente vai querer usar este documento como referência e configurar seus endpoints com Política de Grupo e/ou InTune.
Eu recomendo fortemente melhorar as configurações padrão de log de eventos do Windows e faço o meu melhor para fornecer as informações mais precisas. No entanto, não me responsabilizo por quaisquer efeitos adversos de habilitar log em excesso ou pela precisão de qualquer coisa neste repositório. É sua responsabilidade entender e testar quaisquer alterações que você fizer em seus sistemas em máquinas de teste antes de implementá-las em produção. Recomendo ativar o máximo de log possível em máquinas de teste que imitem seu ambiente por pelo menos uma semana e, em seguida, confirmar se há eventos que estão gerando muito ruído ou se há eventos que você deseja, mas que não estão sendo gerados.
Você pode visualizar o número total e a porcentagem de IDs de evento em um arquivo evtx com o comando de métricas de IDs de evento do Hayabusa.
Exemplo: hayabusa.exe eid-metrics -f path/to/Security.evtx
Process Creation, que rastreia quais processos são executados em um sistema.
Atualmente, cerca de metade das regras de detecção do Sigma dependem desse evento.
Isso pode ser feito instalando o Sysmon (ID do evento 1) ou habilitando o ID do evento 4688 do log de Segurança integrado.
O Sysmon 1 fornecerá informações detalhadas, como hashes e metadados do executável, portanto é ideal, mas no caso de o Sysmon não poder ser instalado, é possível usar os logs integrados de Security 4688. No entanto, é importante que o log de linha de comando também seja habilitado, pois muitas regras de detecção dependem disso. Infelizmente, o Security 4688 não fornece informações tão detalhadas quanto os logs de criação de processo do Sysmon, portanto nem todas as regras de Process Creation funcionam com Security 4688.
Aproximadamente apenas 10~20% das regras sigma podem ser usadas com as configurações padrão de auditoria do Windows!
Isso não é prático para fazer em escala, mas a maneira mais fácil de habilitar/desabilitar logs e verificar e/ou configurar o tamanho máximo do arquivo é clicando com o botão direito no log no Visualizador de Eventos e abrindo Properties.
Você pode usar o comando integrado wevtutil.
Exemplo: wevtutil sl Security /ms:1073741824 para aumentar o tamanho máximo do arquivo do log de Segurança para 1 GB.
Exemplo:```powershell $sysmon = Get-WinEvent -ListLog Microsoft-Windows-Sysmon/Operational $sysmon.MaximumSizeInBytes = 2048000000 #2GB $sysmon.SaveChanges()
## Option 4: Group Policy
É simples aumentar o tamanho máximo de arquivo para os logs de eventos clássicos, como `Security`, `System` e `Application`; no entanto, infelizmente é necessário instalar os Modelos Administrativos e/ou modificar diretamente o registro para alterar o tamanho máximo de arquivo dos outros logs. Pode ser mais fácil simplesmente aumentar o tamanho do arquivo com um script em lote (batch) ou PowerShell na inicialização.
# Configuration script
Um script para aumentar o tamanho máximo do arquivo e habilitar os logs adequados foi fornecido aqui: [YamatoSecurityConfigureWinEventLogs.bat](https://github.com/yamato-security/enablewindowslogsettings/blob/main/YamatoSecurityConfigureWinEventLogs.bat)
# Configuring log settings
## Log do Sysmon (1382 regras sigma)
Arquivo: `Microsoft-Windows-Sysmon%4Operational.evtx`
Configurações padrão: `Não instalado`
Instalar e configurar o sysmon é a melhor coisa que você pode fazer para aumentar sua visibilidade nos endpoints Windows, mas exigirá planejamento, testes e manutenção.
Este é um tópico amplo por si só, portanto está fora do escopo deste documento no momento.
Por favor, consulte os seguintes recursos:
* [Guia da Comunidade Sysmon da TrustedSec](https://github.com/trustedsec/SysmonCommunityGuide)
* [Sysmon Modular](https://github.com/olafhartong/sysmon-modular)
* [fork atualizado de Florian Roth do arquivo de configuração do sysmon do Swift On Security](https://github.com/Neo23x0/sysmon-config)
* [fork atualizado de Ion-storm do arquivo de configuração do sysmon do Swift On Security](https://github.com/ion-storm/sysmon-config)
* [arquivo de configuração do sysmon de Cyb3rWard0g](https://github.com/OTRF/Blacksmith/blob/master/resources/configs/sysmon/sysmon.xml)
## Log de Segurança (1045 regras sigma (903 regras de criação de processos + 142 outras regras))
Arquivo: `Security.evtx`
Configurações padrão: `Parcialmente habilitado`
O log de Segurança é o mais complexo de configurar, então criei um documento separado para ele: [ConfiguringSecurityLogAuditPolicies.md](https://github.com/yamato-security/enablewindowslogsettings/blob/main/ConfiguringSecurityLogAuditPolicies.md)
## Logs do PowerShell (175 regras sigma)
Arquivo: `Microsoft-Windows-PowerShell%4Operational.evtx`
### Registro em log de módulos (30 regras sigma)
Ativar o registro em log de módulos habilitará o ID de evento `4103`.
O registro em log de módulos tem a vantagem de poder ser executado em sistemas operacionais e versões do PowerShell mais antigas: PowerShell 3.0 (Win 7+).
Outro benefício é que ele registra tanto o comando do PowerShell executado quanto os resultados.
A desvantagem é que ele criará um número extremamente alto de eventos.
Por exemplo, se um invasor executar o Mimikatz, ele criará 7 MB de logs com mais de 2000 eventos!
#### Como habilitar o registro em log de módulos
Configurações padrão: `Sem Auditoria`
##### Opção 1: Habilitando por meio da política de grupo
No editor de Política de Grupo (`gpedit.msc`), abra `Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell` e habilite `Turn on Module Logging`.
No painel `Options`, clique no botão `Show...` para configurar quais módulos serão registrados.
Digite `*` na caixa de texto `Value` para registrar todos os módulos.
##### Opção 2: Habilitando por meio do registro```
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames → * = *
Configurações padrão: No Win 10/2016+, se um script do PowerShell for sinalizado como suspeito pelo AMSI, ele será registrado com um nível de Warning.
Ativar o Script Block logging habilitará o ID de evento 4104. Se você habilitar Log script block invocation start / stop events, os EIDs 4105 e 4106 também serão habilitados, no entanto, isso não é recomendado, pois apenas criará ruído.
O Script Block logging é suportado por padrão no PowerShell 5.0+ (Win 10+), no entanto, você pode habilitá-lo em sistemas operacionais mais antigos (Win 7+) se instalar o .NET 4.5 e o WMF 4.0+.
Infelizmente, o tamanho máximo de um único log de eventos do Windows é de 32 KB, portanto, qualquer script do PowerShell maior que isso será fragmentado em blocos de 32 KB.
Se você tiver o arquivo PowerShell Operational.evtx original, poderá usar a ferramenta block-parser para desfragmentar esses logs em um único arquivo de texto facilmente legível.
Uma coisa boa sobre o Script Block logging é que, mesmo que um script malicioso seja ofuscado com XOR, Base 64, ROT13, etc..., o script decodificado será registrado, tornando a análise muito mais fácil.
Os logs são mais razoáveis de trabalhar do que o registro de módulo, pois, se um atacante executar o Mimikatz, apenas 5 MB e 100 eventos serão gerados, em comparação com os 7 MB e mais de 2000 eventos.
No entanto, a saída dos comandos não é registrada com o Script Block logging.
No editor de Política de Grupo, abra Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell e habilite Turn on PowerShell Script Block Logging.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1
Configurações padrão: No Auditing
Também é possível salvar logs do PowerShell em arquivos de texto no computador local com os logs de transcrição. Embora um atacante normalmente possa excluir facilmente os logs de transcrição para antiforense, pode haver cenários em que o atacante limpa todos os logs de eventos, mas não procura logs de transcrição para excluir. Portanto, é recomendável também habilitar os logs de transcrição, se possível. Por padrão, eles são salvos na pasta de documentos do usuário. Idealmente, os logs de transcrição devem ser salvos em um compartilhamento de rede somente gravação, no entanto, isso pode ser difícil de implementar na prática. Um benefício dos logs de transcrição é que eles incluem o timestamp e os metadados de cada comando e são muito eficientes em armazenamento, com menos de 6 KB para a execução do Mimikatz. A desvantagem é que os logs de transcrição registram apenas o que aparece no terminal do PowerShell.
No editor de Política de Grupo, abra Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell e habilite Turn on PowerShell Transcription.
Em seguida, especifique o diretório de saída.
HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1 HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)
### Referências
* [Blog da Mandiant: Maior visibilidade por meio do log do PowerShell](https://www.mandiant.com/resources/blog/greater-visibilityt)
## Log do Sistema (55 regras sigma)
Arquivo: `System.evtx`
Configurações padrão: `Enabled. 20 MB`
Configurações recomendadas: `Enabled. 128 MB+`
O malware frequentemente instala serviços para persistência, escalada local de privilégios, etc... que podem ser encontrados neste log.
Também é possível detectar diversas vulnerabilidades sendo exploradas aqui.
> **Nota: Um ponto específico a observar no log do Sistema é que os parâmetros nos campos às vezes são traduzidos para o idioma local, portanto assinaturas que usam apenas inglês podem não detectar em sistemas não ingleses. Por exemplo, em um sistema em inglês, nos parâmetros do EID 7045, será registrado `Enabled`, enquanto em japonês pode registrar `有効`.**
> **Nota: Assim como no log `Application`, vários provedores registram no mesmo ID de evento, então você pode precisar filtrar também pelo nome do provedor, além do canal. Um exemplo é o ID de evento `1`, que é usado por vários provedores para eventos diferentes.**
IDs de Evento Importantes:
| ID do Evento | Descrição | Regras Sigma | Regras Hayabusa | Nível | Notas |
| :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | Suspensão/Hibernação do Sistema | 0 | Ainda não. | Info | Provedor: `Power-Troubleshooter` |
| 1 | Horário do Sistema Alterado | 0 | Ainda não. | Info | Provedor: `Kernel-General` |
| 12 | Inicialização do SO | 0 | Ainda não. | Info | |
| 13 | Desligamento do SO | 0 | Ainda não. | Info | |
| 16 | Histórico de Acesso ao Hive do Registro Limpo | 2 | Ainda não. | High~Crit | Ferramentas de extração de senhas podem limpar o histórico de acesso após extrair hashes de senhas da chave de registro SAM. Isso também acontece normalmente, então é preciso filtrar os FPs. |
| 55 | Sistema de Arquivos NTFS Corrompido | 1 | Não | High | Pode detectar ataques contra vulnerabilidades do NTFS. |
| 104 | Log de Eventos do Sistema Limpo | 1 | Sim | Med | |
| 6005 | Serviço de Log de Eventos Iniciado | 0 | Sim | Info | |
| 6006 | Serviço de Log de Eventos Parado | 0 | Sim | Info | |
| 6008 | Desligamento Inesperado | 0 | Sim | Info | |
| 6038 | NTLMv1 Foi Usado | 1 | Não | Low | |
| 7031 | Falha do Serviço | 0 | Sim | Low | |
| 7034 | Falha do Serviço | 0 | Sim | Low | |
| 7036 | Serviço Iniciado/Parado | 2 | Sim | Info~High | Pode ser usado para detectar alguém parando o Defender, etc... |
| 7040 | Tipo de Inicialização do Serviço Alterado | 0 | Sim | Info | Pode indicar que um atacante desativou um serviço. |
| 7045 | Instalação de Serviço | 37 | Sim | Info~Crit | Este é o ID de evento do Sistema mais importante, pois o malware frequentemente se instala como um serviço ou abusa de serviços. |
| 20001 | Novo Dispositivo PNP | 0 | Sim | Info~? | O nível dependerá de se dispositivos USB são permitidos ou não. Registra apenas a primeira vez que um dispositivo foi conectado. Eventos de dispositivos PNP não-USB são muito ruidosos, então provavelmente devem ser filtrados. |
## Log do Aplicativo (16 regras sigma)
Este log é majoritariamente ruído, mas você pode encontrar algumas evidências importantes aqui.
Alguns softwares antivírus de terceiros registram aqui.
Um ponto de atenção com o log do Application é que diferentes fornecedores usam os mesmos IDs de evento para eventos diferentes, então você deve filtrar não apenas por IDs de evento, mas também por nomes de provedor.
Arquivo: `Application.evtx`
Configurações padrão: `Enabled. 20 MB`
Configurações recomendadas: `Enabled. 128 MB+`
IDs de Evento Importantes:
| ID do Evento | Provedor | Descrição | Regras Sigma | Regras Hayabusa | Nível | Notas |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | `Audit-CVE`, `Microsoft-Windows-Audit-CVE` | Tentativa de Exploração de Vulnerabilidade Conhecida (CVE) | 1 | Não | Critical | Detecta eventos gerados por aplicativos em modo de usuário quando eles chamam a API CveEventWrite quando uma vulnerabilidade conhecida está sendo explorada. A Microsoft começou a usar este log em 2020/01 com o CVE-2020-0601 (uma vulnerabilidade do Windows CryptoAPI). Infelizmente, esse é praticamente o único caso de CVEs gravadas neste log. |
| 325 | `ESENT` | Banco de Dados ESE Criado | 2 | Não | Info~Crit | Detecta quando um processo cria um banco de dados ESE. Isso é usado por diversas coisas, como Exchange, AD, Serviços de Certificados, SRUM, etc... O banco de dados ESE mais importante para a segurança é o NTDS.dit, o arquivo com os hashes de senhas de todos os usuários do domínio, localizado nos controladores de domínio. Existem duas regras sigma para detectar a extração do NTDS.dit; no entanto, pode ser um falso positivo se um administrador usar o ntdsutil para backups ou quando cópias de sombra são criadas. |
| 326 | `ESENT` | Banco de Dados ESE Anexado | 1 | Não | Info~Crit | Pode ser capaz de detectar acesso ao NTDS.dit. |
| 1000, 1001 | `Application Error`, `Windows Error Reporting` | Erro de Aplicativo | 1 | Não | Info~High | |
| 1034, 11724 | `MsiInstaller` | Aplicativo Desinstalado | 1 | Não | Info~Low | |
| 1040 | `MsiInstaller` | Instalação de Aplicativo | 1 | Não | Info~Med | |
| 33205 | `MSSQLSERVER` | Evento de Auditoria SQL | 6 | Não | Info~High | Pode detectar backdoors do MSSQL, injeção de SQL/comandos, etc... |
## Log Operacional do Windows Defender (10 regras sigma)
Arquivo: `Microsoft-Windows-Windows Defender%4Operational.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Você pode detectar não apenas alertas do Windows Defender (que são importantes de monitorar), mas também exclusões sendo adicionadas, proteção contra adulteração sendo desabilitada, histórico excluído, etc...
## Log Operacional do Bits-Client (6 regras sigma)
Arquivo: `Microsoft-Windows-Bits-Client%4Operational.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
O Bitsadmin.exe é um [lolbin](https://lolbas-project.github.io/lolbas/Binaries/Bitsadmin/) popular que atacantes abusam para baixar e executar malware.
Você pode encontrar evidências disso neste log, embora haja muitos falsos positivos para observar.
## Log do Firewall (6 regras sigma)
Arquivo: `Microsoft-Windows-Windows Firewall With Advanced Security%4Firewall.evtx`
Configurações padrão: `Enabled? 1 MB`
Configurações recomendadas: `Enabled. 256 MB+`
Você pode encontrar evidências de regras de firewall sendo adicionadas/modificadas/excluídas aqui.
O malware frequentemente adiciona regras de firewall para garantir que possa se comunicar com o servidor C2, adiciona regras de proxy para movimento lateral, etc...
## Log Operacional do NTLM (3 regras sigma)
Arquivo: `Microsoft-Windows-NTLM%4Operational.evtx`
Configurações padrão: `Enabled but Auditing is disabled. 1 MB`
Este log é recomendado para habilitar se você quiser desabilitar a autenticação NTLM.
Desabilitar o NTLM provavelmente quebrará alguma comunicação, então você pode monitorar este log nos DCs e em outros servidores para ver quem ainda está usando NTLM e desabilitar o NTLM gradualmente, começando por esses usuários, antes de desabilitá-lo globalmente.
É possível detectar o NTLM sendo usado para conexões de entrada em eventos de logon, como o 4624, mas você precisa habilitar este log se quiser monitorar quem está fazendo conexões NTLM de saída.
Para habilitar a auditoria, no Group Policy abra `Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options` e configure as várias opções adequadas de `Network security: Restrict NTLM:`.
Referência: [Farewell NTLM](https://www.scip.ch/en/?labs.20210909)
## Logs do Security-Mitigations KernelMode e UserMode (2 regras sigma)
Arquivos: `Microsoft-Windows-Security-Mitigations%4KernelMode.evtx`, `Microsoft-Windows-Security-Mitigations%4UserMode.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
No momento, existem apenas 2 regras sigma para esses logs, mas você provavelmente deveria coletar e monitorar todos os logs de Exploit Protection, Network Protection, Controlled Folder Access e Attack Surface Reduction (cerca de 40+ IDs de evento).
Infelizmente, os logs de Attack Surface Reduction (anteriormente WDEG (Windows Defender Exploit Guard) e EMET) estão distribuídos em vários logs e exigem consultas XML complexas para pesquisá-los.
Detalhes: [Entenda e use os recursos de redução de superfície de ataque](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/overview-attack-surface-reduction?view=o365-worldwide)
## Logs do PrintService (2 regras sigma)
Recomenda-se habilitar também o log Operational para detectar atacantes do Print Spooler. (Ex: PrintNightmare, etc...)
### Admin (1 regra sigma)
Arquivo: `Microsoft-Windows-PrintService%4Admin.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
### Operational (1 regra sigma)
Arquivo: `Microsoft-Windows-PrintService%4Operational.evtx`
Configurações padrão: `Disabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
## Log de Segurança do SMBClient (2 regras sigma)
Arquivo: `Microsoft-Windows-SmbClient%4Security.evtx`
Configurações padrão: `Enabled. 8 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Usado para tentar detectar o PrintNightmare (Suspicious Rejected SMB Guest Logon From IP) e usuários montando compartilhamentos ocultos.
## Logs do AppLocker (1 regra sigma)
Arquivos: `Microsoft-Windows-AppLocker%4MSI and Script.evtx`, `Microsoft-Windows-AppLocker%4EXE and DLL.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx`, `Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx`
Configurações padrão: `Enabled if AppLocker is enabled? 1 MB`
Configurações recomendadas: `Enabled. 256 MB+`
É importante garantir que esteja habilitado e monitorado se você estiver usando o AppLocker.
## Log Operacional do CodeIntegrity (1 regra sigma)
Arquivo: `Microsoft-Windows-CodeIntegrity%4Operational.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Verifique este log para detectar eventos de carregamento de drivers bloqueados pelas verificações de integridade de código do Windows, o que pode indicar um driver malicioso que falhou ao carregar.
## Log Operacional do Diagnosis-Scripted (1 regra sigma)
Arquivo: `Microsoft-Windows-Diagnosis-Scripted%4Operational.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Evidências de pacotes diagcab sendo usados para exploração podem ser encontradas aqui.
## Log Operacional do DriverFrameworks-UserMode (1 regra sigma)
Arquivos: `Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx`
Configurações padrão: `No Auditing. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Detecta dispositivos USB conectados.
## Log Operacional do WMI-Activity (1 regra sigma)
Arquivo: `Microsoft-Windows-WMI-Activity%4Operational.evtx`
Configurações padrão: `Enabled on Win10/2016+. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
É importante monitorar, pois atacantes frequentemente exploram o WMI para persistência e movimento lateral.
## Log Operacional do TerminalServices-LocalSessionManager (1 regra sigma)
Arquivo: `Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx`
Configurações padrão: `Enabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Detecta quando o ngrok, uma ferramenta de proxy reverso, encaminha tráfego para a porta RDP local para contornar firewalls.
Link: [Contornando Restrições de Rede por meio de Tunelamento RDP](https://www.mandiant.com/resources/blog/bypassing-network-restrictions-through-rdp-tunneling)
## Log Operacional do TaskScheduler (1 regra sigma)
Arquivo: `Microsoft-Windows-TaskScheduler%4Operational.evtx`
Configurações padrão: `Disabled. 1 MB`
Configurações recomendadas: `Enabled. 128 MB+`
Atacantes frequentemente abusam de tarefas para persistência e movimento lateral, portanto isso deve ser habilitado.