Ameaças Explicadas
Explicações em linguagem simples das técnicas de ataque que a Cyber Crucible foi criada para impedir - malware sem arquivo, ataques em memória, automação de hackers, infostealers e roubo de tokens de sessão.
- A Cyber Crucible consegue impedir o movimento lateral de atacantes?
- A Whitelisting de Aplicações funciona?
- O que é Application Whitelisting (Lista de Permissões de Aplicações)?
- Como Posso Saber O Que Teria Sido Suspenso Não Fosse o Comportamento Personalizado
- Como Gerenciar Comportamentos Personalizados
- O que é um ataque sem arquivo (em memória)?
- O que é a automação de hackers e por que ela quebra as defesas tradicionais?
- Por que os ataques automatizados visam os mesmos locais em todos os computadores?
- O que é um infostealer, e por que o roubo de tokens de sessão é tão perigoso?
- O que são ataques Living-off-the-Land (LotL) e por que a listagem de aplicações permitidas (whitelisting) falha contra eles?
- O que é um ataque em memória a DLLs do System32?
- Por que o malware nem sempre é ativado em um laboratório de testes de segurança?
A Cyber Crucible consegue impedir o movimento lateral de atacantes?
O mecanismo comportamental do produto e as metodologias de Zero Trust reúnem, de forma eficaz, evidências de movimento lateral.
Isso pode ser evidência de movimento lateral de processo para processo na própria máquina, ou pode ser a descoberta do ponto de entrada de um atacante no sistema a partir de um sistema remoto, durante a realização de uma Análise de Causa Raiz.
Programas e seus argumentos associados a métodos de injeção de processo e a processos “living off the land” que abrem outros processos são capturados e enviados à Cyber Crucible.
Devido à análise comportamental de processos em nível de kernel, não há processos com privilégios excessivos para observação e relato pela Cyber Crucible (incluindo outros drivers de kernel, ou até mesmo outras ferramentas de segurança de endpoint).
Respostas automatizadas de contra-extorsão ocorrem quando ações de extorsão de dados ou de criptografia de ransomware são iniciadas.
Por exemplo, aqui está um vídeo demonstrando o movimento lateral em uma máquina, utilizando técnicas em memória, e a exploração do Log4J. Observe que a suspensão automatizada do(s) processo(s) afetado(s) ocorreu após o início dos comportamentos de roubo de dados e de ransomware.
Outro exemplo dessa dinâmica demonstra o uso, por um atacante, para abrir um shell do Windows. A observação capturou todas as evidências, mas a atividade foi suspensa assim que o shell do Windows começou a tentar atividades de extorsão de dados (neste caso, roubo de dados)
Por fim, a migração a partir de um navegador explorado também é observada, e, neste caso, o atacante nunca conseguiu se mover com sucesso a partir do navegador Chrome explorado, devido ao monitoramento do estado de memória do navegador:
A Whitelisting de Aplicações funciona?
O Que É a Whitelisting de Aplicações?
A whitelisting de aplicações é um conceito no qual existe uma lista de programas autorizados a funcionar, e tudo o resto não tem permissão para funcionar.
As tecnologias de whitelisting de aplicações mais avançadas combinam algum tipo de lógica de origem e destino. Por exemplo, uma whitelist de aplicações pode determinar: "O Bloco de Notas do Windows tem permissão para aceder à pasta Impostos no meu ambiente de trabalho, mas o Microsoft Word não tem."
Analisaremos isto com mais detalhe, mas, de forma genérica, as estratégias defensivas de whitelisting de aplicações dependem fortemente destas duas variáveis:
Os atacantes concordam em seguir as regras que definiu para eles no que diz respeito à sua ferramenta de cibersegurança de whitelisting de aplicações.
O seu ambiente é muito pequeno, com poucas aplicações que permanecem bastante estáveis e sem explorações (exploits).
Desvantagens das Tecnologias de Whitelisting de Aplicações
Complexidade
As Redes de TI São Como Organismos Complexos
Mesmo as pequenas redes de TI são entidades em constante mudança, com uma miríade de comportamentos. As aplicações são constantemente adicionadas e removidas pelos utilizadores. Os módulos dentro das aplicações são constantemente adicionados e removidos pelos criadores dos programas, especialmente aquando de atualizações. Por último, os comportamentos das aplicações, além das alterações no código que resultam em alterações de comportamento, são utilizados de formas diferentes por diferentes utilizadores em diferentes momentos. Agora imagine a equipa que teria de acompanhar isso constantemente, e os pedidos de suporte de TI que teriam de chegar continuamente.
Realisticamente, o único ambiente de TI estável é aquele orientado por quiosques, no qual os programas são instalados sem possibilidade de atualização, adição ou remoção, e os utilizadores estão estritamente limitados a executar apenas uma ou duas funções. Talvez um quiosque para impressão de fotografias, ou algo semelhante. Nesse caso, a whitelisting de aplicações só precisaria de ser atualizada sempre que o terminal do quiosque fosse atualizado, talvez duas vezes por ano.
Whitelists de Aplicações Mais Avançadas Significam Mais Complexidade
As whitelists de aplicações mais simples têm apenas listas de programas autorizados a existir no sistema de um utilizador.
Isto, por si só, pode ser difícil de gerir, mas conduz a uma série de melhorias potenciais.
Por exemplo, só porque o departamento de processamento de salários tem uma aplicação para interagir com o sistema de salários da empresa, não deveria existir um conjunto separado de regras para a equipa do armazém, que utiliza aplicações diferentes (não relacionadas com salários)?
Assim, as melhorias relacionadas com quais divisões ou utilizadores podem executar quais aplicações constituem uma melhoria óbvia. Uma melhoria que, agora, criou complexidade adicional, além de apenas acompanhar o número, tipo e versões dos programas existentes na sua rede.
Agora, digamos que precisamos de outro conjunto de melhorias - precisamos de decidir qual utilizador tem acesso a qual aplicação, para qual conjunto de dados.
Isso também faz todo o sentido, certo? Não quer que a sua equipa de armazém tenha acesso aos registos de Recursos Humanos, e a equipa de Recursos Humanos provavelmente não precisa de acesso aos dados operacionais da equipa de entregas do armazém.
Trata-se de um conjunto de combinações absurdamente complexo de acompanhar, agora que a localização dos dados foi acrescentada como variável.
Assim - com cada melhoria necessária para tornar as tecnologias de whitelisting de aplicações eficazes, a gestão, configuração e o suporte contínuo (poder-se-ia dizer, interminável e sempre crescente) necessário para as manter funcionais torna a tecnologia impraticável. O resultado é, normalmente, que grandes grupos de utilizadores recebem acesso a grandes grupos de aplicações e, provavelmente, a quase todos os dados. Ou seja - uma configuração praticamente inútil da tecnologia, porque nenhuma empresa dispõe dos recursos necessários para a manter devidamente gerida.
As Aplicações Interagem Entre Si
É comum, nos sistemas operativos modernos, que as aplicações interajam com outras aplicações. Por vezes, a interação deve-se a uma integração entre duas aplicações que melhora a experiência do utilizador - como um documento do Word que abre o Microsoft Photos. Noutras ocasiões (o que é muito comum), existem chamadas entre programas que são efetuadas de uma forma tipicamente invisível para o utilizador final.
O que é Application Whitelisting (Lista de Permissões de Aplicações)?
Introdução
Application whitelisting, no contexto da Cyber Crucible, consiste em conceder a uma aplicação permissão para executar uma determinada ação que, de outra forma, poderia ser considerada suspeita ou maliciosa.
A tecnologia de application whitelisting é tipicamente encontrada em técnicas defensivas de análise comportamental, embora alguns atacantes também a utilizem (não abordado aqui) nas suas operações.
Pense nisto como na escola, onde os alunos normalmente não tinham permissão para circular pelos corredores durante as aulas. No entanto, se lhes fosse dada uma “autorização de saída” de alguma forma por uma figura de autoridade, os alunos não eram levados de volta à sala de aula nem enviados ao gabinete do diretor.
Tipos de Application Whitelisting - uma descrição não técnica
Se continuarmos com a analogia da “autorização de saída”, existem diferentes técnicas que os responsáveis escolares aprenderam, que ajudaram a formalizar os comportamentos que alguns alunos (definitivamente não o nosso CEO Dennis) poderiam ter tentado utilizar em seu proveito. Todas estas têm uma correlação direta com as operações de segurança.
A Autorização Óbvia e Incômoda (algo positivo)
Lembra-se de alguma vez ter recebido uma autorização de saída, ou uma chave para alguma sala, que era incrivelmente grande e óbvia?
Havia algumas boas razões para isso:
Para não se perder.
Para reduzir o tempo e o esforço investidos por uma figura de autoridade, na verificação rápida das atividades aprovadas do aluno.
Um bom software não vai “perder” uma lista de permissões, mas o software de application whitelist deve permitir uma validação rápida e eficiente em termos de recursos de que a aplicação foi inspecionada.
A Autorização Genérica (provavelmente não é algo positivo)
Esta é provavelmente a menos útil tanto para a monitorização de aplicações como para as escolas, mas é a que requer menos gestão ou especialização.
Neste caso, o aluno tem permissão para realizar o seu recado no corredor. O professor pode saber, por exemplo, mas não há validação por parte dos monitores do corredor quanto ao que o aluno está a fazer. Além disso, se houver uma tentativa de validação, existem dois níveis de investimento considerável de recursos:
o nível de esforço para abordar o aluno e questioná-lo sobre os seus comportamentos e intenções
o nível de esforço para garantir que o aluno está a ser honesto, de forma a validar a explicação do aluno
Com as aplicações, isto é mais frequentemente observado quando um programa é adicionado a uma lista de permissões, sem que exista qualquer validação adicional dos comportamentos ou atividades permitidas. Infelizmente, a capacidade de obter contexto sobre os comportamentos de uma aplicação normalmente não está disponível para aquisição, a menos que seja acompanhada externamente por alguma outra estrutura.
A Autorização Genericamente Específica
Não confundir com “avança, Aplicação, faz o que quiseres!”
Voltemos à autorização de ida à casa de banho, porque é muito apropriada aqui. Dada a visibilidade da autorização, é relativamente fácil avaliar o que o aluno deveria estar a fazer. Comportamentos flagrantemente fora do esperado para “ir à casa de banho” podem ser identificados sem grande dificuldade.
O application whitelisting com limites genéricos de atividades é o mais comum, embora, em muitos casos, esses limites equivalham a permitir que um aluno com uma autorização para a casa de banho brinque no recreio.
A Autorização Específica-Específica
Não confundir com a autorização “genericamente específica”!
Embora, com a autorização genericamente específica, saibamos que o aluno está a usar a casa de banho - numa escola grande, não sabemos
1. Quem deu permissão ao aluno
2. De onde é que ele veio.
3. Qual casa de banho a figura de autoridade tinha em mente quando deu a aprovação.
4. Há quanto tempo o aluno está “fora e por aí”.
Isto exigiu mais trabalho por parte da estrutura de autoridade da escola.
Voltando ao application whitelisting, a análise comportamental é mais precisa quanto mais variáveis forem adicionadas a qualquer capacidade de tomada de decisão.
Além disso, ao investigar uma autorização de saída que foi emitida, normalmente não é necessário rastrear uma cadeia de 5 professores até chegar à origem. Também se pode quase sempre confiar que o professor não era algum tipo de “mau professor” a incitar os alunos a comportarem-se de forma imprópria. O application whitelisting, num exemplo de lista de permissões específica-específica, requer trabalhar ao contrário, examinando todas as aplicações “pai” ou “ancestrais” que abriram a aplicação seguinte. Por exemplo, um malware pode ter aberto um utilitário legítimo do Windows.
As seguintes perguntas são aproximadamente equivalentes à “autorização de saída do aluno” acima mencionada:
Para que foi iniciada a aplicação, ou o que lhe foi ordenado fazer? Precisamos de conhecer o comportamento pretendido.
Quem iniciou a aplicação? Normalmente, é outro programa.
Que programas “pai” ou “ancestrais” resultaram na abertura deste programa? O que é que cada um deles estava a fazer, ou pretendia fazer?
A Aplicação Comprometida
Lembra-se, em várias obras de ficção científica, ou de literatura e filmes de terror, quando um impostor de alguma forma toma
o controlo do comportamento de uma personagem? Nas escolas, não há muita probabilidade de um professor ser dominado por alienígenas.
A tomada de controlo de aplicações é uma técnica favorita dos atacantes porque, tal como nos filmes, a maioria dos observadores não repara em nada de errado até ser tarde demais.
Neste caso, um atacante toma um programa em execução, que está atualmente carregado na memória. Assim, o programa totalmente intacto no sistema de ficheiros é ignorado. O programa na memória é editado para incluir o código do atacante. Tal como um alienígena dentro do corpo de um humano. O atacante realiza os seus comportamentos criminosos e, quando o programa termina a execução, a maior parte das provas desaparece. Quando o programa legítimo é executado novamente, se o atacante não editar novamente o código, tudo funciona exatamente como os programadores legítimos originais previram. Talvez uma analogia melhor, neste caso, fosse a de um lobisomem?
Uma lista de permissões de aplicações, então, precisa de trabalho adicional para garantir que o programa, e quaisquer programas ancestrais ou pai, permanecem intactos, sem que um hacker edite os programas enquanto estão em execução.
Em Resumo - Perguntas a Fazer ao Investigar uma Capacidade de Application Whitelist
Certifique-se de compreender os limites que uma lista de permissões permite, ao discutir application whitelisting com a sua equipa de tecnologia ou fornecedor.
Esta capacidade examina e monitoriza o que um programa deveria fazer, e compara o comportamento esperado com o observado?
Quanto detalhe é que a capacidade de whitelist capta na sua tomada de decisão? Mais, ou menos, do que uma autorização de saída de aluno detalhada?
A capacidade de whitelist monitoriza e investiga programas pai e ancestrais quanto a maliciosidade? (Programa A abre B, abre C, abre D – muito comum)
A capacidade de whitelist valida que o programa em execução não foi adulterado?
Leitura Aprofundada do National Institute of Standards & Technology (NIST)
Uma publicação de referência que não é para leitura casual, mas é muito descritiva.
Embora não cubra todos os cenários, e os detalhes não sejam atualizados com frequência suficiente para acompanhar todos os cenários, as descrições são suficientemente estratégicas para serem valiosas na maioria das circunstâncias.
A equipa da Cyber Crucible valoriza sempre os conhecimentos das publicações do NIST, e reserva tempo em conformidade.
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-167.pdf
Como Posso Saber O Que Teria Sido Suspenso Não Fosse o Comportamento Personalizado
Os usuários podem ver quais respostas de extorsão teriam sido suspensas se um comportamento personalizado não existisse, acessando primeiro a página Respostas de Extorsão, encontrada na aba Operações na barra lateral.
A coluna Excluído mostra se uma resposta de extorsão foi excluída ou não, e o filtro de coluna padrão exibe respostas não excluídas e não silenciosas.
Para exibir as respostas excluídas, abra o filtro da coluna Excluído e selecione apenas Excluído.
Após clicar em Aplicar, a grade exibirá as respostas de extorsão excluídas que teriam sido suspensas se o comportamento personalizado não existisse.
Para ver qual comportamento personalizado foi aplicado a uma resposta, clique primeiro na seta na coluna Número de Incidentes da linha específica. Na grade interna que se revela após clicar na seta, a coluna Regra de Ocultação mostrará o nome do comportamento personalizado que foi aplicado à resposta.
Como Gerenciar Comportamentos Personalizados
A página de Comportamentos Personalizados pode ser encontrada na aba Operações na barra lateral. Observe que os usuários devem ter a permissão “Visualizar Comportamentos Personalizados” para um grupo para poder ver os comportamentos personalizados do grupo nesta página
Como Criar um Comportamento Personalizado
Após navegar até a página de Comportamentos Personalizados, clique no ícone de excluir processo acima desta grade.
Ao clicar neste ícone, abrirá um modal para criar o comportamento personalizado.
Os usuários têm a opção de especificar um programa pai com a exceção
Insira restrições adicionais para aplicar
Os usuários agora têm a opção de limitar a exceção a gatilhos específicos de acesso a arquivos; todos os gatilhos de acesso a arquivos são incluídos por padrão. Observe que apenas agentes na versão 4.4.6.2 ou superior possuem essa capacidade de gatilho de acesso a arquivos.
Os usuários também têm a capacidade de criar comportamentos temporários, veja mais na próxima seção
Como Criar e Editar Comportamentos Personalizados Temporários
Os usuários podem criar um comportamento personalizado temporário seguindo o processo normal para criar um comportamento, conforme explicado acima, e depois ativando a opção “Tornar Este Comportamento Personalizado Temporário”. Os usuários podem então inserir as horas até que o comportamento temporário deva expirar (até um máximo de uma semana).
A data de expiração do Comportamento pode ser vista na coluna Data de Expiração na grade.
Para editar um comportamento temporário e estender a data de expiração, tornar um comportamento temporário permanente, ou tornar um comportamento permanente temporário, clique no ícone de edição no comportamento desejado na coluna Data de Expiração.
Ao clicar neste ícone, abrirá um modal onde os usuários podem editar a data de expiração do comportamento conforme desejado
Como Excluir Comportamentos Personalizados
Para excluir um comportamento, ou vários comportamentos ao mesmo tempo, primeiro selecione o(s) comportamento(s) a excluir na grade e clique no ícone de lixeira acima da grade.
Em seguida, digite “delete” e clique no botão Excluir.
Como Copiar Comportamentos Personalizados para um Grupo Diferente
Para copiar um comportamento (ou vários comportamentos ao mesmo tempo) para outro grupo, selecione o(s) comportamento(s) a copiar na grade e clique no ícone de cópia acima da grade.
Ao clicar neste ícone, abrirá um modal onde você pode selecionar o grupo para o qual o(s) comportamento(s) deve(m) ser copiado(s).
Este modal também tem uma opção para excluir os comportamentos existentes no grupo selecionado (exceto comportamentos gerados automaticamente), e conter apenas os comportamentos copiados no grupo selecionado após enviar a solicitação.
Após enviar a solicitação, os comportamentos copiados agora aparecerão para o grupo selecionado.
Criando um Comportamento Personalizado a partir da Página de Resposta a Extorsão
Os usuários têm a capacidade de criar comportamentos personalizados a partir da página de Respostas a Extorsão.
Primeiro, clique na seta na linha de resposta a extorsão desejada, na coluna Número de Incidentes, para revelar a grade interna.
Em seguida, clique no ícone de excluir resposta na coluna Nome da Resposta, o que abrirá um modal para criar o comportamento personalizado.
Neste modal, você pode criar comportamentos usando os caminhos de executáveis sugeridos ou enviar a resposta para revisão caso não encontre o que precisa nos caminhos sugeridos.
Você também pode clicar no botão Ir para a Página de Comportamentos Personalizados, que o redirecionará para a página de Comportamentos Personalizados e preencherá automaticamente o modal de criação de comportamento com o mesmo grupo, caminho e argumentos do programa a partir da resposta.
Observe que, por padrão, a opção Limitar Exceção ao Programa + Programa Pai está desativada. O caminho do programa pai e os argumentos da resposta a extorsão também serão preenchidos automaticamente se você ativar essa configuração.
A Exclusão de Comportamento Personalizado após clicar em Criar com a configuração Limitar Exceção ao Programa + Programa Pai ativada:
O que é um ataque sem arquivo (em memória)?
Resposta curta: Um ataque sem arquivo é aquele que nunca grava um programa em disco. O atacante injeta código malicioso diretamente na memória de um processo legítimo e confiável e constrói sua carga maliciosa (payload) ali. Como nenhum arquivo chega a ser criado, as ferramentas de segurança que analisam arquivos — incluindo a maioria dos EDR — não têm nada a encontrar.
Por que derrota as ferramentas baseadas em arquivos
A proteção tradicional de endpoint é construída sobre uma suposição simples: malware é um arquivo, portanto inspecione arquivos. As técnicas sem arquivo eliminam completamente o arquivo.
Em uma implantação real, uma empresa de serviços financeiros utilizava três produtos EDR líderes do setor (Microsoft, CrowdStrike e Sophos) juntamente com um SOC gerenciado Top-50. Os atacantes comprometeram uma ferramenta confiável de monitoramento remoto, injetaram código nos processos de gerenciamento do Microsoft SQL Server e compilaram seu ransomware e malware de roubo de dados diretamente na memória do servidor. Como nada tocou o disco rígido, os três EDRs, o MDR e o SOC ficaram completamente cegos. O Cyber Crucible interceptou de forma autônoma quase 10.000 processos maliciosos — 98% deles na farm de servidores SQL — sem um único alerta da pilha de ferramentas legadas.
Como o Cyber Crucible enxerga isso
O Cyber Crucible observa comportamento e intenção no nível do kernel, em vez de analisar arquivos. Um processo que age de forma maliciosa é interrompido em menos de 200 milissegundos, tenha um arquivo sido gravado ou não.
O que é a automação de hackers e por que ela quebra as defesas tradicionais?
Resposta curta: A automação de hackers é o uso de scripts, IA e automação robótica de processos para executar todas as fases de um ataque à velocidade da máquina. Um ataque automatizado pode infiltrar-se numa máquina, roubar dados e eliminar as suas próprias ferramentas em memória em segundos — muito mais rápido do que qualquer analista humano consegue responder.
O que é automatizado
- Reconhecimento: ferramentas analisam a internet em busca de sistemas vulneráveis e mapeiam uma rede-alvo em segundos, além de gerar phishing convincente em grande escala.
- Exploração: assim que uma vulnerabilidade é encontrada, os frameworks implantam o exploit imediatamente — um zero-day pode ser utilizado em milhões de máquinas antes de um humano registar o alerta.
- "Smash and grab": o malware moderno não avalia quais ficheiros são valiosos. Ele encripta ou exfiltra tudo o que consegue alcançar, tão rapidamente quanto possível.
Por que os humanos não conseguem vencer esta corrida
O limite não é a qualidade da equipa nem o número de colaboradores. É a biologia. O tempo necessário para uma pessoa ver um alerta, processá-lo e agir é maior do que o tempo que o ataque leva para se concluir. O encaminhamento da telemetria para um servidor na nuvem para análise e o respetivo retorno acrescentam ainda mais atraso.
A única resposta viável é uma defesa que decida e atue de forma autónoma, no endpoint, em milissegundos.
Por que os ataques automatizados visam os mesmos locais em todos os computadores?
Resposta curta: os atacantes não sabem nada sobre o seu ambiente específico, então a automação deles é escrita para locais que existem em praticamente todas as máquinas — pastas de perfil de usuário, letras de unidade e diretórios de dados de aplicativos. Essa previsibilidade é uma fraqueza que os defensores podem explorar.
Os alvos previsíveis
- Perfis de usuário e áreas de trabalho: no Windows,
C:\Users\[Username]costuma conter dados valiosos de forma confiável. Um script percorre todos os diretórios de usuário sem precisar entender o sistema. - Letras de unidade: ferramentas automatizadas enumeram
C:\,D:\e além para encontrar compartilhamentos de rede, unidades externas e partições montadas para criptografar. - Pastas de dados de aplicativos: todo sistema operacional mantém credenciais, cookies e configurações em caminhos conhecidos — alvos privilegiados para roubo de credenciais.
Transformando a previsibilidade contra o atacante
O padrão de ataque não é ponderado; é uma varredura direta de locais bem conhecidos. A Cyber Crucible monitora exatamente esses pontos de entrada conhecidos para roubo de identidade e roubo de dados. Qualquer programa que tente acessar dados nesses locais — junto com seus processos pai e filho e bibliotecas associadas — tem sua intenção avaliada em uma fração de segundo, e é interceptado caso essa intenção seja maliciosa.
O que é um infostealer, e por que o roubo de tokens de sessão é tão perigoso?
Resposta curta: Um infostealer é um malware criado para capturar material de identidade digital — senhas, tokens de sessão, chaves de API e credenciais VPN — e exfiltrá-lo rapidamente. Um token de sessão roubado é perigoso porque muitas vezes contorna completamente as senhas e a autenticação multifator, permitindo que um invasor faça login como um usuário legítimo.
Por que os invasores agora roubam identidade em vez de permanecer residentes
Os invasores modernos evitam cada vez mais permanecer dentro de uma rede. Permanecer no ambiente aumenta as chances de detecção. Em vez disso, eles pegam o material de identidade e saem, o que lhes proporciona duas vantagens:
- Menor risco — analisam o que roubaram a partir de um ambiente seguro, no seu próprio tempo.
- Retorno fácil — com um token de sessão, senha ou chave VPN válidos, podem voltar sempre que quiserem, parecendo totalmente legítimos para o sistema de autenticação.
Por que a velocidade é todo o problema
Essas ferramentas passam da infiltração à autoexclusão em segundos — mais rápido do que um alerta na nuvem consegue sair do prédio. A Cyber Crucible interpreta a intenção no momento do acesso aos dados de identidade e suspende o processo em menos de 200 milissegundos, antes que a exfiltração comece.
O que são ataques Living-off-the-Land (LotL) e por que a listagem de aplicações permitidas (whitelisting) falha contra eles?
Resposta breve: Os ataques Living-off-the-Land utilizam software que já está instalado e já é confiável — utilitários do sistema, ferramentas administrativas, navegadores — em vez de introduzir novos ficheiros maliciosos. A listagem de aplicações permitidas (whitelisting) falha porque o atacante está a operar dentro de programas que a lista de permissões autoriza explicitamente.
A lista de permissões torna-se uma lista de alvos
A listagem de aplicações permitidas responde a uma única pergunta: "este ficheiro tem permissão para ser executado?" As técnicas modernas de ataque tornam essa pergunta irrelevante. Se os atacantes ocultarem código malicioso na memória de um processo aprovado, a lista de permissões já disse que sim. Na prática, uma lista de permissões indica ao atacante, com precisão, quais são os processos mais seguros para se ocultar.
A pergunta certa
Uma defesa eficaz tem de passar de "este ficheiro tem permissão?" para "o que é que este código está realmente a fazer neste momento?" Isso exige a inspeção do comportamento e da memória ao nível do kernel, onde a atividade real é visível — e não ao nível do ficheiro, que o atacante já contornou.
O que é um ataque em memória a DLLs do System32?
Resposta curta: Trata-se de um ataque que infecta as bibliotecas de código essenciais do Windows (DLLs do System32) enquanto estas estão em execução na memória. Como praticamente todas as aplicações e ferramentas de segurança dependem dessas bibliotecas para funcionar, comprometê-las confere a um atacante controlo quase total do endpoint, deixando muito pouco rasto.
Por que razão isto é o expoente máximo da tradecraft de endpoint
As DLLs do System32 fornecem as operações fundamentais das quais o Windows e as suas aplicações dependem — alocação de memória, criptografia, redes. Foram concebidas para velocidade e fiabilidade, nunca para serem corrigidas ou interceptadas ("hooked") em tempo real em ambiente de produção.
Um atacante que consiga alterá-las em memória obtém o poder de inspecionar, criar, alterar ou destruir dados e programas no sistema, com um nível de furtividade quase impossível de rastrear.
Por que razão a maioria das ferramentas não consegue detetá-lo
Os produtos de segurança que dependem de dados de sensores fornecidos pela Microsoft estão, por definição, a confiar precisamente nas bibliotecas que estão a ser atacadas. Os sensores necessários para detetar esta classe de ataque simplesmente não existem nos conjuntos de ferramentas padrão — pelo que a ferramenta fica silenciosa enquanto reporta que está tudo em ordem.
O Cyber Crucible foi deliberadamente concebido para ser independente das bibliotecas do Windows, de modo a que um sistema operativo comprometido não o possa cegar ou desativar.
Por que o malware nem sempre é ativado em um laboratório de testes de segurança?
Resposta curta: Os invasores projetam o malware para permanecer inativo, a menos que receba um sinal de validação de um servidor de comando e controle (C2) ativo que eles controlam. Quando uma amostra chega a um banco de dados de malware, a infraestrutura de C2 geralmente já foi movida — então os pesquisadores costumam estar testando uma amostra órfã que não faz nada.
Por que os invasores incorporam a inatividade
- Minimização de inteligência: o malware inativo não executa nenhuma ação maliciosa observável, dando aos analistas menos informações para documentar e aos fornecedores menos elementos para criar assinaturas.
- Prevenção de sequestro: exigir um aperto de mão secreto garante que um rival ou pesquisador que se apodere do servidor C2 não possa simplesmente direcionar o malware e coletar os dados roubados.
O que isso significa para a avaliação de ferramentas de segurança
Um teste de laboratório contra uma amostra desconectada mede muito pouco. A pergunta relevante não é se uma ferramenta reage a um malware inativo e parado, mas se ela impede ataques ativos e rápidos enquanto eles acontecem. O Cyber Crucible foi criado para isso: ele monitora os pontos de entrada de roubo de identidade e de dados visados por ataques reais, avalia a intenção em menos de 200 milissegundos e impede o roubo antes que ele seja concluído.