Habilitamos a coleta de eventos sobre o lançamento de processos suspeitos no Windows e identificamos ameaças usando o Quest InTrust

Um dos tipos mais comuns de ataques é a geração de um processo malicioso em uma árvore sob processos bastante bons. O caminho para o arquivo executável pode causar suspeita: geralmente, o malware usa as pastas AppData ou Temp, o que é incomum para programas legítimos. É justo dizer que alguns utilitários de atualização automática são executados no AppData, então apenas verificar o local de inicialização não é suficiente para afirmar que o programa é malicioso.



Um fator adicional de legitimidade é a assinatura criptográfica: muitos programas originais são assinados pelo fornecedor. Você pode usar a ausência de assinatura como método para identificar itens de inicialização suspeitos. Mas, novamente, há malware que usa um certificado roubado para assinar a si mesmo.



Você também pode verificar o valor dos hashes criptográficos MD5 ou SHA256, que podem corresponder a algum malware detectado anteriormente. Você pode realizar uma análise estática observando as assinaturas no programa (usando as regras Yara ou produtos antivírus). E há a análise dinâmica (lançar um programa em algum ambiente seguro e rastrear suas ações) e a engenharia reversa.



Pode haver muitos sinais de um processo malicioso. Neste artigo, descreveremos como habilitar a auditoria dos eventos correspondentes no Windows, analisaremos os sinais dos quais a regra InTrust interna depende para identificar um processo suspeito. InTrust é uma plataforma CLM para coletar, analisar e armazenar dados não estruturados, que já contêm centenas de respostas predefinidas a vários tipos de ataques.



Quando um programa é iniciado, ele é carregado na memória do computador. O arquivo executável contém instruções do computador e bibliotecas auxiliares (por exemplo, * .dll). Quando um processo já está em execução, ele pode criar threads adicionais. Threads permitem que um processo execute diferentes conjuntos de instruções ao mesmo tempo. Existem muitas maneiras pelas quais o código malicioso pode penetrar na memória e iniciá-la, vamos examinar algumas delas.



A maneira mais fácil de iniciar um processo malicioso é forçar o usuário a iniciá-lo diretamente (por exemplo, de um anexo de e-mail) e, em seguida, usar a tecla RunOnce para iniciá-lo sempre que o computador for ligado. Isso também inclui malware "sem arquivo" que armazena scripts do PowerShell em chaves de registro que são acionadas. Nesse cenário, o script do PowerShell é um código malicioso.



O problema com a execução de software malicioso explicitamente é que é uma abordagem conhecida e é facilmente detectada. Alguns malwares fazem coisas mais sutis, como usar um processo diferente para começar a ser executado na memória. Portanto, um processo pode criar outro processo executando uma instrução de computador específica e especificando um arquivo executável (.exe) para ser executado.



O arquivo pode ser especificado usando um caminho completo (por exemplo, C: \ Windows \ system32 \ cmd.exe) ou um caminho incompleto (por exemplo, cmd.exe). Se o processo original não for seguro, ele permitirá que programas ilegítimos sejam executados. O ataque pode ter a seguinte aparência: o processo inicia cmd.exe sem especificar o caminho completo, o invasor coloca seu cmd.exe em um local para que o processo inicie antes do legítimo. Depois de lançar um programa malicioso, ele, por sua vez, pode lançar um programa legítimo (por exemplo, C: \ Windows \ system32 \ cmd.exe) para que o programa original continue funcionando corretamente.



Uma variação do ataque anterior é a injeção de DLL em um processo legítimo. Quando um processo é iniciado, ele encontra e carrega bibliotecas que estendem sua funcionalidade. Usando injeção de DLL, um invasor cria uma biblioteca maliciosa com o mesmo nome e API da legítima. O programa baixa uma biblioteca maliciosa e, por sua vez, baixa uma legítima e, se necessário, a chama para realizar as operações. A biblioteca maliciosa começa a agir como um proxy para a biblioteca boa.



Outra maneira de colocar um código malicioso na memória é inseri-lo em um processo não seguro que já está em execução. Os processos recebem entrada de várias fontes - eles leem da rede ou de arquivos. Eles geralmente verificam se a entrada é legítima. No entanto, alguns processos não são protegidos adequadamente ao executar as instruções. Nesse tipo de ataque, não há biblioteca no disco ou um arquivo executável com código malicioso. Tudo é armazenado na memória junto com o processo que está sendo explorado.



Agora vamos descobrir a metodologia para habilitar a coleta de tais eventos no Windows e com a regra no InTrust, que implementa proteção contra tais ameaças. Primeiro, nós o ativamos por meio do console de gerenciamento InTrust.







A regra usa os recursos de rastreamento de processo do Windows. Infelizmente, a inclusão da coleção de tais eventos está longe de ser óbvia. Existem 3 configurações de política de grupo diferentes para alterar:



Configuração do computador> Políticas> Configurações do Windows> Configurações de segurança> Políticas locais> Política de auditoria> Rastreamento de processo de auditoria







Configuração do computador> Políticas> Configurações do Windows> Configurações de segurança> Configuração avançada de política de auditoria> Políticas de auditoria> Rastreamento detalhado> Criação de processo de auditoria







Configuração do computador> Políticas> Modelos administrativos> Sistema> Criação de processo de auditoria> Incluir linha de comando em eventos de criação de processo







Uma vez habilitadas, as regras InTrust permitem detectar ameaças previamente desconhecidas,que exibem comportamento suspeito. Por exemplo, você pode identificaro malware Dridex descrito aqui . Graças ao projeto HP Bromium, sabemos como funciona essa ameaça.







Dridex usa schtasks.exe em sua cadeia de ações para criar uma tarefa agendada. Usar esse utilitário específico da linha de comando é considerado um comportamento muito suspeito, da mesma forma que inicia o svchost.exe com parâmetros que apontam para pastas do usuário ou com parâmetros semelhantes aos comandos "net view" ou "whoami". Aqui está um snippet da regra SIGMA correspondente :

detection:
    selection1:
        CommandLine: '*\svchost.exe C:\Users\\*\Desktop\\*'
    selection2:
        ParentImage: '*\svchost.exe*'
        CommandLine:
            - '*whoami.exe /all'
            - '*net.exe view'
    condition: 1 of them

No InTrust, todo comportamento suspeito é incluído em uma regra, porque a maioria dessas ações não é específica para uma ameaça específica, mas sim suspeita em um complexo e em 99% dos casos são usados ​​para fins não totalmente nobres. Esta lista de ações inclui, mas não está limitada a:

• Processos executados em locais incomuns, como pastas temporárias personalizadas.
• Processo de sistema conhecido com herança suspeita - algumas ameaças podem tentar usar o nome de processos do sistema para passar despercebidas.
• Execução suspeita de ferramentas administrativas como cmd ou PsExec quando usam credenciais do sistema local ou herança suspeita.
• — - , :
  
  
  
  — vssadmin.exe;
  
  — WMI.
• .
• , at.exe.
• net.exe.
• netsh.exe.
• ACL.
• BITS .
• WMI.
• .
• .

A regra combinada funciona muito bem para detectar ameaças como RUYK, LockerGoga e outros vírus ransomware, malware e kits de ferramentas para crimes cibernéticos. A regra foi verificada pelo fornecedor em ambientes de produção para minimizar falsos positivos. E graças ao projeto SIGMA, a maioria desses indicadores produz o número mínimo de eventos de ruído.



Porque no InTrust, esta é uma regra de monitoramento, você pode executar um script de resposta como uma reação a uma ameaça. Você pode usar um dos scripts integrados ou criar o seu próprio e o InTrust o distribuirá automaticamente.







Além disso, você pode verificar toda a telemetria relacionada ao evento: scripts do PowerShell, execução de processos, manipulação de tarefas agendadas, atividade administrativa WMI e usá-los para autópsias em caso de incidentes de segurança.







O InTrust tem centenas de outras regras, algumas das quais são:

• Identifique um ataque de downgrade do PowerShell - quando alguém usa deliberadamente uma versão mais antiga do PowerShell porque a versão mais antiga não tinha a capacidade de auditar o que estava acontecendo.
• Detecção de logon de alto privilégio - quando as contas que são membros de um determinado grupo privilegiado (como administradores de domínio) fazem logon interativamente nas estações de trabalho por acidente ou devido a incidentes de segurança.

O InTrust permite as melhores práticas de segurança na forma de detecção predefinida e regras de resposta. E se você acha que algo deveria funcionar de forma diferente, você pode fazer sua própria cópia da regra e configurá-la conforme necessário. Você pode enviar uma inscrição para um piloto ou receber distribuições com licenças temporárias por meio do formulário de feedback em nosso site.



Assine nossa página no Facebook , publicamos notas curtas e links interessantes lá.



Leia nossos outros artigos sobre o tópico de segurança da informação:



Como o InTrust pode ajudar a reduzir a frequência de tentativas de autorização malsucedidas via RDP Detectando um ataque de ransomware, obtendo



acesso a um controlador de domínio e tentando resistir a esses ataques



O que pode ser útil para extrair dos logs de uma estação de trabalho Windows (artigo popular)



Rastreando o ciclo de vida dos usuários sem alicate e fita



E quem fez isso? Automatizamos a auditoria de segurança da informação



Como reduzir o custo de propriedade de um sistema SIEM e por que você precisa do Gerenciamento Central de Log (CLM)