A Dor da Resposta: Como os Processos de Segurança da Informação Afetam a Investigação de Incidentes
Este artigo explora como a falta de processos de segurança da informação bem estabelecidos pode prejudicar a investigação de incidentes de segurança cibernética. Ele aborda problemas em várias fases da investigação, desde a preparação até a análise pós-incidente, destacando a importância de uma abordagem sistemática e a necessidade de seguir as recomendações para evitar futuras comprometimentos.
MundiX News·01 de junho de 2026·15 min de leitura·👁 15 views
A investigação de incidentes é um sub-processo crítico do gerenciamento de incidentes de segurança da informação, com o objetivo de identificar o vetor de comprometimento inicial, minimizar danos e prevenir incidentes semelhantes no futuro. A eficácia da investigação depende de três fatores-chave: a competência da equipe de resposta, a disponibilidade de ferramentas para análise e coleta de dados e a consistência dos processos de segurança da informação da organização cliente como um todo.
Este último fator tem um impacto significativo no curso da investigação, incluindo a precisão, integridade e confiabilidade dos resultados finais da investigação. Em particular, a ausência de processos de segurança da informação bem estabelecidos pode levar à alteração de artefatos-chave, dificultar a identificação da fonte de intrusão e reduzir a probabilidade de detecção de novos Indicadores de Comprometimento (IOCs).
Ao longo de inúmeras investigações, a equipe Solar 4RAYS se deparou com tais "obstáculos". Após analisá-los, decidimos descrever os problemas que surgem em um determinado processo de segurança da informação que afetam negativamente a investigação de incidentes.
Quando os problemas surgem
Modelos clássicos de investigação dividem o processo de resposta em seis estágios: preparação, detecção, contenção, erradicação, recuperação e lições aprendidas.
Na realidade, a interação entre os estágios pode não ser linear, portanto, no âmbito deste artigo, consideraremos os problemas em três estágios condicionais da investigação:
Antes da investigação do incidente.
Durante a investigação.
Após a investigação.
Antes da investigação do incidente
Sim, aceitamos os riscos
Cada organização tem um processo cíclico conhecido como gerenciamento de riscos de segurança da informação. Ele visa identificar, avaliar, priorizar e mitigar os riscos associados a potenciais incidentes. Existem várias estratégias de gerenciamento para este processo, uma das quais é a "Aceitação de Risco".
A "Aceitação de Risco" é uma estratégia que implica a ignorância consciente de medidas para reduzir a probabilidade de um risco ser acionado ou eliminar uma ameaça. Essa abordagem pode ser devido a fatores econômicos, ou seja, pode ser aplicada se os danos esperados da realização da ameaça forem menores que os custos de sua prevenção. No entanto, no âmbito dos riscos de segurança da informação, vemos uma distorção dessa estratégia. Muitas vezes, é acompanhada por um consenso mental: "Por que gastar dinheiro com algo que pode não acontecer?"
Essa abordagem inevitavelmente leva a uma situação em que o risco "aceito" é acionado, um incidente ocorre e a organização se encontra totalmente despreparada para ele. As consequências de tal despreparo, especialmente nas realidades modernas do cenário de ameaças cibernéticas, levam a inevitáveis custos econômicos e de reputação. Ao mesmo tempo, os custos na maioria dos casos excedem todas as expectativas da organização.
Na prática, isso se manifesta na forma de ignorar avisos confiáveis. Na Solar 4RAYS, monitoramos a atividade de grupos conhecidos e, quando vemos sinais de um ataque, alertamos a organização atacada sobre o comprometimento de sua infraestrutura. No entanto, esses alertas geralmente permanecem sem resposta. Às vezes, eles pedem para fornecer indicadores de comprometimento em resposta, mas nenhuma investigação adicional é conduzida. Muitas vezes, essa inação levou ao desenvolvimento do incidente e à sua divulgação pública.
Ao mesmo tempo, a estratégia de "Aceitação" não é um erro em si. No entanto, sua aplicação deve ser uma decisão consciente, baseada em uma análise honesta dos possíveis danos em caso de incidente. E não apenas a suposição de que o incidente pode não acontecer. A prática de nossas investigações mostra que qualquer organização pode se tornar o alvo de um ataque de um grupo profissional.
O quê? Onde? Quando?
A equipe Solar 4RAYS se deparou com situações em que, em caso de incidente, o cliente não sabia exatamente do que sua própria infraestrutura era composta. Isso geralmente ocorre devido a um processo de gerenciamento e inventário de ativos mal estabelecido. Problemas semelhantes surgem com o controle de acesso e a administração de contas. Como resultado, ocorre uma situação em que a vítima, juntamente com a equipe de investigação, realiza um inventário em andamento, essencialmente realizando uma auditoria ao vivo, com a peculiaridade de uma infraestrutura parcialmente desligada.
A falta de informações sobre os segmentos de infraestrutura tem um impacto negativo no processo de investigação. Em particular:
Cria a necessidade de conduzir uma auditoria ao vivo.
Na ausência de informações atuais sobre a infraestrutura, a equipe de Resposta a Incidentes (IR), em vez da própria investigação, tem que identificar servidores web, controladores de domínio, contas com privilégios, etc. Isso leva tempo, que os investigadores podem não ter. Por exemplo, no caso em que os invasores ainda mantêm presença na infraestrutura e podem causar danos.
Leva à falta de consistência no isolamento.
A equipe de resposta pode enfrentar uma situação em que o que é "isolado" não é o que é necessário, devido à falta de conhecimento sobre a infraestrutura.
Por mais óbvio que isso possa parecer, a única maneira de saber do que sua infraestrutura é composta é ter um processo de gerenciamento e inventário de ativos bem estabelecido. Esta é uma boa prática fora do contexto da investigação de incidentes cibernéticos, mas em caso de ataque cibernético, aumenta seriamente a eficiência e a velocidade das atividades dos investigadores.
É extremamente importante que, em caso de incidente, não aconteça que o invasor conheça sua infraestrutura melhor do que você.
Exemplo de um caso real
Os invasores descobriram na infraestrutura da vítima um controlador de domínio desatualizado que, embora tenha sido desativado, manteve uma conexão com outros componentes da rede. Ao se conectar inicialmente, os invasores colocaram 3proxy no sistema, o que lhes permitiu tunelar o tráfego. Em seguida, os invasores carregaram o ProcDump para despejar os processos de memória - em particular, lsass.exe.
No futuro, os invasores usaram o controlador de domínio como um nó intermediário para o movimento lateral em toda a infraestrutura. Para o cliente, essa "descoberta" foi uma surpresa.
Se eu não vejo - então não existe?
A infraestrutura de rede de qualquer organização é um sistema complexo e dinâmico que requer atenção constante, tanto do ponto de vista técnico quanto do ponto de vista da segurança. Devido ao crescimento constante do número de ataques, é impossível manter a segurança da infraestrutura sem um processo de monitoramento bem estabelecido.
A essência do processo de monitoramento não é apenas coletar dados, mas analisá-los constantemente com o uso de ferramentas adicionais. O objetivo de todo o processo é identificar anomalias que indiquem potencial atividade maliciosa antes que ocorram danos reais. O resultado da análise é uma notificação de um evento suspeito, que, por sua vez, é avaliado diretamente pelo destinatário da notificação (o cliente).
Infelizmente, existem sérios riscos nesse processo. Mesmo com notificações confiáveis, o destinatário da notificação pode ignorá-las, avaliá-las incorretamente ou interpretá-las incorretamente (falso positivo). Como resultado - consequências catastróficas na forma de criptografia ou vazamento de dados.
Na verdade, ignorar uma notificação ou avaliá-la incorretamente devido à negligência ou falta de conhecimento não apenas não protege a organização, mas também cria uma falsa impressão de segurança. Uma opinião é formada: "Alguns eventos estão acontecendo, o processo está estabelecido, o que significa que estou seguro e não preciso fazer nada".
Outro risco é a cobertura incompleta dos principais segmentos de infraestrutura por meio de monitoramento, o que cria zonas cegas para o serviço de monitoramento.
As consequências dos riscos acima afetam o processo de investigação, a saber:
Um atraso significativo entre a notificação e a resposta pode levar à perda de artefatos críticos: logs de eventos, rastros de atividade, arquivos temporários.
A presença de zonas cegas pode retardar a determinação dos sistemas infectados e o monitoramento de IOCs.
Em caso de destruição da infraestrutura (por exemplo, como resultado da criptografia), a investigação começa a depender da disponibilidade de backups e logs de monitoramento. A ausência de monitoramento (e, consequentemente, seus logs) pode afetar negativamente a eficácia da investigação.
A única maneira de eliminar esses riscos é uma abordagem responsável ao monitoramento. É importante escalar a atividade claramente maliciosa para a pessoa responsável, mesmo que esta última tenha afirmado anteriormente que a atividade é "legítima". Se o evento for um falso positivo, as consequências de tal escalada são mínimas, enquanto ignorar uma ameaça real pode resultar em enormes perdas de recursos e tempo.
Por sua vez, a pessoa que recebeu a notificação deve ter experiência. Para isso, é importante que ela se familiarize regularmente com os relatórios recentes sobre as atividades de grupos de hackers, imagine como a aplicação de certas táticas e técnicas de ataque se parece.
É importante cobrir os principais segmentos de infraestrutura para a organização com monitoramento, a saber: o segmento do servidor, com servidores web, bancos de dados, etc., a zona desmilitarizada (DMZ), que conecta o segmento de rede interno ao externo e outros. A presença de zonas cinzentas pode permitir que os invasores se escondam nelas.
A mesma lógica se aplica a outros meios de proteção: WAF, EDR, AVPO. Ignorar seus alertas também é um erro.
Viu, assustou, excluiu
Imagine que um funcionário da organização detectou atividade anormal em seu sistema. Por exemplo, um diretório incomum na área de trabalho que não estava lá antes, ou um arquivo executável com um nome ou localização suspeitos. Com uma avaliação rápida de tal atividade, o usuário entende que este é um malware e simplesmente exclui o objeto suspeito, acreditando que, ao fazer isso, ele impediu o incidente. Na melhor das hipóteses, após isso, ele iniciará uma verificação com a ajuda do AVPO. No entanto, como mostra a prática, tais ações não impedem o incidente, mas só podem atrasá-lo.
Chamamos essa abordagem de "Viu, assustou, excluiu". Em essência, é errado não tanto no próprio procedimento de exclusão, mas na ausência de uma abordagem sistemática para responder a tais eventos. Ao mesmo tempo, o maior perigo é causado não pela tentativa de resolver o incidente por conta própria, mas pela ausência de escalonamento da detecção para um especialista relevante.
Para o grupo de investigação, essa abordagem acarreta os seguintes riscos:
Ao excluir um arquivo suspeito, uma amostra de malware e/ou um novo C2 dos invasores pode ser permanentemente perdida. Ao mesmo tempo, restaurar o arquivo devido a várias circunstâncias geralmente é impossível.
Do momento "Viu, assustou, excluiu" ao momento "Chame a equipe de resposta", pode levar tempo suficiente para a rotação de vários artefatos. Tudo isso afeta negativamente a velocidade e a precisão da análise dos eventos que ocorreram no sistema.
O usuário pode esquecer ou intencionalmente ocultar (por exemplo, por medo de receber uma sanção disciplinar) que algo suspeito estava acontecendo no sistema e, durante a investigação, não relatará "descobertas interessantes".
A solução para este problema requer uma abordagem abrangente, que consiste em duas partes. Primeiro, a introdução do monitoramento obrigatório evitará a ignorância do incidente ou a não preservação do fato do evento. Em segundo lugar, treinar os funcionários, pelo menos, nos fundamentos da segurança da informação permite a introdução de uma abordagem significativa para a detecção de ameaças.
O cenário ideal para o comportamento de um funcionário nos casos acima pode ser as seguintes ações:
O mais importante é escalar o que aconteceu para um especialista relevante. Ocultar o que aconteceu pode levar a consequências catastróficas.
Após a escalada, você não precisa tomar nenhuma ação por conta própria. Eles podem interferir no estabelecimento da causa do incidente.
Em outras palavras, "Viu, assustou, excluiu" deve se transformar em "Viu, relatou ao SI, seguiu as instruções dos especialistas".
Separatamente, vale a pena mencionar o cenário em que a organização escolhe a resposta independente. Com ele, é necessário registrar em detalhes os artefatos detectados de atividade maliciosa. No futuro, ao investigar novos incidentes, a base de conhecimento "histórico" ajudará a rastrear o desenvolvimento do antigo incidente e entender onde as medidas de proteção tomadas falharam, ou estabelecer que as atividades não estão de forma alguma relacionadas e não perder tempo em um ramo sem saída da investigação.
Um relatório detalhado sobre a resposta independente ajudará não apenas você, mas também uma equipe de resposta de terceiros, se houver necessidade de atraí-la.
Casos em que o cliente ou seu funcionário excluíram rastros de infecção com base no princípio "Viu, assustou, excluiu" são encontrados com bastante frequência na prática da equipe Solar 4RAYS. Em um caso típico, o administrador ou qualquer outro funcionário vê uma notificação do AVPO indicando o fato da infecção. Agindo de acordo com o cenário acima, eles não salvam nenhum dado sobre o evento e o ambiente do evento. Excluir uma amostra de malware, via de regra, não limita de forma alguma as capacidades dos invasores, e um incidente mais sério, do qual o malware excluído pelo funcionário fazia parte, mais cedo ou mais tarde ocorre.
Os chefes da organização se perguntam: "Como o sistema foi infectado?" - e decidem realizar uma análise do sistema. Como resultado da autogestão, parte dos dados é destruída pelas forças dos funcionários da organização, e o especialista em investigação de incidentes só pode apresentar hipóteses, com base em fatos dispersos, sobre como os invasores entraram na rede.
Separatamente, observamos os casos em que, em incidentes, o grupo APT usa malware que existe apenas na memória operacional do sistema. E o cliente, após ser informado de que os sistemas estão infectados, simplesmente desliga toda a infraestrutura com urgência. Como resultado, após ligar o sistema, ele já está limpo de malware e simplesmente não há nada para analisar. Mas isso não significa que o grupo não tenha mantido o acesso à infraestrutura.
Durante a investigação
Gerenciamento de incidentes
Às vezes, nos estágios iniciais das investigações, nossa equipe se deparou com o problema da falta de preparação do cliente para responder a um incidente. Fomos testemunhas de como o cliente se dividia em pedaços, tentando ao mesmo tempo encontrar o responsável pela infraestrutura, começar a nos ajudar na investigação e começar a restaurar a infraestrutura.
A consistência das ações em caso de incidente é um fenômeno bastante raro, e só é observado naquelas organizações onde há um plano de resposta pré-desenvolvido.
O desenvolvimento de tal plano não é apenas uma conformidade formal com os requisitos. Este é um cenário prático passo a passo de interação entre os principais participantes do processo (de especialistas técnicos à gerência), que será muito útil em uma situação em que parece que tudo está perdido. A base de tal plano é a política de gerenciamento de incidentes de segurança da informação, que define responsabilidades, o procedimento de notificação, a classificação de incidentes e outras ações.
Ao mesmo tempo, é necessário trabalhar separadamente no plano de interação com equipes de investigação externas. Essas equipes podem dar recomendações sobre certas ações com sua infraestrutura para ajudar a restaurá-la e preservar artefatos significativos para investigação. A ausência de um plano de interação inevitavelmente leva a problemas no processo de investigação.
Vamos dar um exemplo característico:
Durante a investigação do incidente, foi encontrado um rastreamento que leva a um sistema comprometido. Mas, para os dados solicitados, o cliente envia um triage/imagem limpa com um sistema recém-reinstalado. Pedimos mais sistemas e recebemos exatamente os mesmos. Descobriu-se que o cliente já havia restaurado parcialmente os sistemas da imagem dourada, sem sequer pensar em nos avisar sobre sua intenção.
Em modo de thread único
Normalmente, do lado do cliente, uma equipe muito pequena é alocada para comunicação com a equipe de resposta. Muitas vezes, apenas um funcionário - o administrador do sistema - se torna o executor direto das instruções operacionais da equipe de investigação. Ele tem todos os direitos necessários para coletar dados e também possui informações mais detalhadas sobre a infraestrutura "no local".
Isso gera alguns problemas. Na maioria das organizações, o número de administradores é limitado. Sua principal responsabilidade após o incidente é restaurar a infraestrutura, atualizar o acesso, alterar as configurações, e eles nem sempre podem alocar tempo de forma eficaz entre a coleta de dados para especialistas em resposta e seus deveres diretos.
Para não sobrecarregar o funcionário, a melhor prática é alocar um curto período de tempo para que ele resolva as tarefas da equipe de investigação. Muitas das tarefas definidas estão frequentemente relacionadas à coleta de dados, ou seja, executar utilitários ou executar comandos específicos. Depois disso, o funcionário pode estar livre até a conclusão da coleta de dados.
Por sua vez, a equipe de investigação é obrigada a definir tarefas específicas e, ao mesmo tempo, explicar como realizar uma determinada ação para facilitar o trabalho do administrador.
Tudo é mantido trancado!
Nossa equipe se deparou com casos em que o fornecimento de dados para pesquisa foi complicado pelo medo do cliente de sua possível perda ou vazamento. Às vezes, havia tentativas de excluir alguns artefatos dos dados coletados. No entanto, em nossa opinião, tais medos são excessivos. Além disso, tentar excluir quaisquer dados coletados pode afetar os resultados da investigação.
Em primeiro lugar, o serviço de investigação e resposta a incidentes implica que as partes assinem um acordo de confidencialidade (NDA), que especifica todas as obrigações e condições necessárias. Além disso, o acordo de confidencialidade especifica os termos de armazenamento dos dados do incidente.
Do ponto de vista técnico, a equipe Solar 4RAYS armazena todos os dados transferidos pelo cliente exclusivamente em repositórios protegidos com um sistema de controle de acesso de vários níveis baseado no princípio de privilégios mínimos. O acesso aos dados é fornecido ao especialista por um tempo limitado, e todas as ações com os arquivos são salvas no log de auditoria.
Como resultado, a transferência e o processamento de dados no âmbito da investigação são totalmente seguros. E as "dúvidas" do cliente podem afetar negativamente o processo de investigação.
Após a investigação do incidente
Quem precisa de suas recomendações...
As recomendações são a quintessência dos resultados da investigação do incidente. Eles sistematizam ações específicas justificadas necessárias para eliminar as consequências do comprometimento, restaurar a integridade da infraestrutura e reduzir o risco de reinfecção. Eles incluem não apenas instruções técnicas, mas também recomendações organizacionais para fortalecer a segurança geral. Atenção especial é dada aos indicadores de comprometimento que precisam ser rastreados após o incidente.
A prática mostra que, às vezes, as recomendações não recebem a devida atenção, ou são completamente ignoradas. Tais "omissões" não apenas reduzem a eficácia da investigação, mas contribuem diretamente para a re-comprometimento.
E, por mais óbvio que isso possa parecer, a maneira mais eficaz de evitar incidentes repetidos é seguir estritamente as recomendações. Eles não são uma formalidade. Cada uma das ações especificadas nas recomendações é devido à análise de ameaças, às ações dos invasores e aos resultados da investigação. Cada etapa é parte de uma cadeia consistente, cuja violação pode deixar o sistema vulnerável a ataques semelhantes ou semelhantes.
Vamos dar um exemplo da prática de investigação de incidentes:
O cliente pediu para conduzir uma investigação de incidente limitada em número de sistemas. No processo, foram encontrados múltiplos rastros de atividade do grupo APT.
Como resultado, demos uma série de recomendações: o que fazer com a infraestrutura, quais indicadores de comprometimento rastrear e como. No entanto, em breve, o mesmo cliente veio até nós - durante o monitoramento, seus especialistas detectaram apelos ao C2 dos invasores, especificados em nosso relatório.
Descobriu-se que as recomendações foram implementadas apenas seis meses após a investigação. Durante esse tempo, os invasores continuaram a infectar a infraestrutura ramificada e começaram a usar um novo C2.
Conclusões
Os problemas acima, individualmente, nem sempre impedem a investigação, mas, no agregado, podem impedi-la ou distorcer os resultados finais.
Nas condições modernas de alto nível de ameaças cibernéticas, uma abordagem sistemática para os processos de segurança da informação não é uma recomendação, mas uma necessidade severa.
Cada organização, independentemente da escala e do setor, deve ter um plano de ação claro em caso de incidente de segurança da informação. Além do plano, os processos de gerenciamento de ativos, treinamento de funcionários nos fundamentos da segurança da informação e monitoramento devem ser estabelecidos.
Atenção especial deve ser dada ao princípio de preservar rastros digitais relacionados ao incidente. Os rastros deixados pelos invasores são as principais evidências de atividade maliciosa. Sua alteração ou perda pode dificultar o processo de pesquisa e impedir a precisão dos resultados.
Tudo isso reduzirá significativamente o risco de um incidente e, no caso de sua ocorrência, os processos construídos ajudarão a realizar uma investigação de alta qualidade no menor tempo possível.
Outros artigos sobre investigação e resposta a ataques cibernéticos, bem como pesquisas de ameaças cibernéticas (incluindo indicadores de comprometimento) podem ser encontrados em nosso
blog
.
A equipe do centro de pesquisa de ameaças cibernéticas
Solar 4RAYS
🛡️⚡
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
A investigação de incidentes é um sub-processo crítico do gerenciamento de incidentes de segurança da informação, com o objetivo de identificar o vetor de comprometimento inicial, minimizar danos e prevenir incidentes semelhantes no futuro. A eficácia da investigação depende de três fatores-chave: a competência da equipe de resposta, a disponibilidade de ferramentas para análise e coleta de dados e a consistência dos processos de segurança da informação da organização cliente como um todo.
Este último fator tem um impacto significativo no curso da investigação, incluindo a precisão, integridade e confiabilidade dos resultados finais da investigação. Em particular, a ausência de processos de segurança da informação bem estabelecidos pode levar à alteração de artefatos-chave, dificultar a identificação da fonte de intrusão e reduzir a probabilidade de detecção de novos Indicadores de Comprometimento (IOCs).
Ao longo de inúmeras investigações, a equipe Solar 4RAYS se deparou com tais "obstáculos". Após analisá-los, decidimos descrever os problemas que surgem em um determinado processo de segurança da informação que afetam negativamente a investigação de incidentes.
Quando os problemas surgem
Modelos clássicos de investigação dividem o processo de resposta em seis estágios: preparação, detecção, contenção, erradicação, recuperação e lições aprendidas.
Na realidade, a interação entre os estágios pode não ser linear, portanto, no âmbito deste artigo, consideraremos os problemas em três estágios condicionais da investigação:
Antes da investigação do incidente.
Durante a investigação.
Após a investigação.
Antes da investigação do incidente
Sim, aceitamos os riscos
Cada organização tem um processo cíclico conhecido como gerenciamento de riscos de segurança da informação. Ele visa identificar, avaliar, priorizar e mitigar os riscos associados a potenciais incidentes. Existem várias estratégias de gerenciamento para este processo, uma das quais é a "Aceitação de Risco".
A "Aceitação de Risco" é uma estratégia que implica a ignorância consciente de medidas para reduzir a probabilidade de um risco ser acionado ou eliminar uma ameaça. Essa abordagem pode ser devido a fatores econômicos, ou seja, pode ser aplicada se os danos esperados da realização da ameaça forem menores que os custos de sua prevenção. No entanto, no âmbito dos riscos de segurança da informação, vemos uma distorção dessa estratégia. Muitas vezes, é acompanhada por um consenso mental: "Por que gastar dinheiro com algo que pode não acontecer?"
Essa abordagem inevitavelmente leva a uma situação em que o risco "aceito" é acionado, um incidente ocorre e a organização se encontra totalmente despreparada para ele. As consequências de tal despreparo, especialmente nas realidades modernas do cenário de ameaças cibernéticas, levam a inevitáveis custos econômicos e de reputação. Ao mesmo tempo, os custos na maioria dos casos excedem todas as expectativas da organização.
Na prática, isso se manifesta na forma de ignorar avisos confiáveis. Na Solar 4RAYS, monitoramos a atividade de grupos conhecidos e, quando vemos sinais de um ataque, alertamos a organização atacada sobre o comprometimento de sua infraestrutura. No entanto, esses alertas geralmente permanecem sem resposta. Às vezes, eles pedem para fornecer indicadores de comprometimento em resposta, mas nenhuma investigação adicional é conduzida. Muitas vezes, essa inação levou ao desenvolvimento do incidente e à sua divulgação pública.
Ao mesmo tempo, a estratégia de "Aceitação" não é um erro em si. No entanto, sua aplicação deve ser uma decisão consciente, baseada em uma análise honesta dos possíveis danos em caso de incidente. E não apenas a suposição de que o incidente pode não acontecer. A prática de nossas investigações mostra que qualquer organização pode se tornar o alvo de um ataque de um grupo profissional.
O quê? Onde? Quando?
A equipe Solar 4RAYS se deparou com situações em que, em caso de incidente, o cliente não sabia exatamente do que sua própria infraestrutura era composta. Isso geralmente ocorre devido a um processo de gerenciamento e inventário de ativos mal estabelecido. Problemas semelhantes surgem com o controle de acesso e a administração de contas. Como resultado, ocorre uma situação em que a vítima, juntamente com a equipe de investigação, realiza um inventário em andamento, essencialmente realizando uma auditoria ao vivo, com a peculiaridade de uma infraestrutura parcialmente desligada.
A falta de informações sobre os segmentos de infraestrutura tem um impacto negativo no processo de investigação. Em particular:
Cria a necessidade de conduzir uma auditoria ao vivo.
Na ausência de informações atuais sobre a infraestrutura, a equipe de Resposta a Incidentes (IR), em vez da própria investigação, tem que identificar servidores web, controladores de domínio, contas com privilégios, etc. Isso leva tempo, que os investigadores podem não ter. Por exemplo, no caso em que os invasores ainda mantêm presença na infraestrutura e podem causar danos.
Leva à falta de consistência no isolamento.
A equipe de resposta pode enfrentar uma situação em que o que é "isolado" não é o que é necessário, devido à falta de conhecimento sobre a infraestrutura.
Por mais óbvio que isso possa parecer, a única maneira de saber do que sua infraestrutura é composta é ter um processo de gerenciamento e inventário de ativos bem estabelecido. Esta é uma boa prática fora do contexto da investigação de incidentes cibernéticos, mas em caso de ataque cibernético, aumenta seriamente a eficiência e a velocidade das atividades dos investigadores.
É extremamente importante que, em caso de incidente, não aconteça que o invasor conheça sua infraestrutura melhor do que você.
Exemplo de um caso real
Os invasores descobriram na infraestrutura da vítima um controlador de domínio desatualizado que, embora tenha sido desativado, manteve uma conexão com outros componentes da rede. Ao se conectar inicialmente, os invasores colocaram 3proxy no sistema, o que lhes permitiu tunelar o tráfego. Em seguida, os invasores carregaram o ProcDump para despejar os processos de memória - em particular, lsass.exe.
No futuro, os invasores usaram o controlador de domínio como um nó intermediário para o movimento lateral em toda a infraestrutura. Para o cliente, essa "descoberta" foi uma surpresa.
Se eu não vejo - então não existe?
A infraestrutura de rede de qualquer organização é um sistema complexo e dinâmico que requer atenção constante, tanto do ponto de vista técnico quanto do ponto de vista da segurança. Devido ao crescimento constante do número de ataques, é impossível manter a segurança da infraestrutura sem um processo de monitoramento bem estabelecido.
A essência do processo de monitoramento não é apenas coletar dados, mas analisá-los constantemente com o uso de ferramentas adicionais. O objetivo de todo o processo é identificar anomalias que indiquem potencial atividade maliciosa antes que ocorram danos reais. O resultado da análise é uma notificação de um evento suspeito, que, por sua vez, é avaliado diretamente pelo destinatário da notificação (o cliente).
Infelizmente, existem sérios riscos nesse processo. Mesmo com notificações confiáveis, o destinatário da notificação pode ignorá-las, avaliá-las incorretamente ou interpretá-las incorretamente (falso positivo). Como resultado - consequências catastróficas na forma de criptografia ou vazamento de dados.
Na verdade, ignorar uma notificação ou avaliá-la incorretamente devido à negligência ou falta de conhecimento não apenas não protege a organização, mas também cria uma falsa impressão de segurança. Uma opinião é formada: "Alguns eventos estão acontecendo, o processo está estabelecido, o que significa que estou seguro e não preciso fazer nada".
Outro risco é a cobertura incompleta dos principais segmentos de infraestrutura por meio de monitoramento, o que cria zonas cegas para o serviço de monitoramento.
As consequências dos riscos acima afetam o processo de investigação, a saber:
Um atraso significativo entre a notificação e a resposta pode levar à perda de artefatos críticos: logs de eventos, rastros de atividade, arquivos temporários.
A presença de zonas cegas pode retardar a determinação dos sistemas infectados e o monitoramento de IOCs.
Em caso de destruição da infraestrutura (por exemplo, como resultado da criptografia), a investigação começa a depender da disponibilidade de backups e logs de monitoramento. A ausência de monitoramento (e, consequentemente, seus logs) pode afetar negativamente a eficácia da investigação.
A única maneira de eliminar esses riscos é uma abordagem responsável ao monitoramento. É importante escalar a atividade claramente maliciosa para a pessoa responsável, mesmo que esta última tenha afirmado anteriormente que a atividade é "legítima". Se o evento for um falso positivo, as consequências de tal escalada são mínimas, enquanto ignorar uma ameaça real pode resultar em enormes perdas de recursos e tempo.
Por sua vez, a pessoa que recebeu a notificação deve ter experiência. Para isso, é importante que ela se familiarize regularmente com os relatórios recentes sobre as atividades de grupos de hackers, imagine como a aplicação de certas táticas e técnicas de ataque se parece.
É importante cobrir os principais segmentos de infraestrutura para a organização com monitoramento, a saber: o segmento do servidor, com servidores web, bancos de dados, etc., a zona desmilitarizada (DMZ), que conecta o segmento de rede interno ao externo e outros. A presença de zonas cinzentas pode permitir que os invasores se escondam nelas.
A mesma lógica se aplica a outros meios de proteção: WAF, EDR, AVPO. Ignorar seus alertas também é um erro.
Viu, assustou, excluiu
Imagine que um funcionário da organização detectou atividade anormal em seu sistema. Por exemplo, um diretório incomum na área de trabalho que não estava lá antes, ou um arquivo executável com um nome ou localização suspeitos. Com uma avaliação rápida de tal atividade, o usuário entende que este é um malware e simplesmente exclui o objeto suspeito, acreditando que, ao fazer isso, ele impediu o incidente. Na melhor das hipóteses, após isso, ele iniciará uma verificação com a ajuda do AVPO. No entanto, como mostra a prática, tais ações não impedem o incidente, mas só podem atrasá-lo.
Chamamos essa abordagem de "Viu, assustou, excluiu". Em essência, é errado não tanto no próprio procedimento de exclusão, mas na ausência de uma abordagem sistemática para responder a tais eventos. Ao mesmo tempo, o maior perigo é causado não pela tentativa de resolver o incidente por conta própria, mas pela ausência de escalonamento da detecção para um especialista relevante.
Para o grupo de investigação, essa abordagem acarreta os seguintes riscos:
Ao excluir um arquivo suspeito, uma amostra de malware e/ou um novo C2 dos invasores pode ser permanentemente perdida. Ao mesmo tempo, restaurar o arquivo devido a várias circunstâncias geralmente é impossível.
Do momento "Viu, assustou, excluiu" ao momento "Chame a equipe de resposta", pode levar tempo suficiente para a rotação de vários artefatos. Tudo isso afeta negativamente a velocidade e a precisão da análise dos eventos que ocorreram no sistema.
O usuário pode esquecer ou intencionalmente ocultar (por exemplo, por medo de receber uma sanção disciplinar) que algo suspeito estava acontecendo no sistema e, durante a investigação, não relatará "descobertas interessantes".
A solução para este problema requer uma abordagem abrangente, que consiste em duas partes. Primeiro, a introdução do monitoramento obrigatório evitará a ignorância do incidente ou a não preservação do fato do evento. Em segundo lugar, treinar os funcionários, pelo menos, nos fundamentos da segurança da informação permite a introdução de uma abordagem significativa para a detecção de ameaças.
O cenário ideal para o comportamento de um funcionário nos casos acima pode ser as seguintes ações:
O mais importante é escalar o que aconteceu para um especialista relevante. Ocultar o que aconteceu pode levar a consequências catastróficas.
Após a escalada, você não precisa tomar nenhuma ação por conta própria. Eles podem interferir no estabelecimento da causa do incidente.
Em outras palavras, "Viu, assustou, excluiu" deve se transformar em "Viu, relatou ao SI, seguiu as instruções dos especialistas".
Separatamente, vale a pena mencionar o cenário em que a organização escolhe a resposta independente. Com ele, é necessário registrar em detalhes os artefatos detectados de atividade maliciosa. No futuro, ao investigar novos incidentes, a base de conhecimento "histórico" ajudará a rastrear o desenvolvimento do antigo incidente e entender onde as medidas de proteção tomadas falharam, ou estabelecer que as atividades não estão de forma alguma relacionadas e não perder tempo em um ramo sem saída da investigação.
Um relatório detalhado sobre a resposta independente ajudará não apenas você, mas também uma equipe de resposta de terceiros, se houver necessidade de atraí-la.
Casos em que o cliente ou seu funcionário excluíram rastros de infecção com base no princípio "Viu, assustou, excluiu" são encontrados com bastante frequência na prática da equipe Solar 4RAYS. Em um caso típico, o administrador ou qualquer outro funcionário vê uma notificação do AVPO indicando o fato da infecção. Agindo de acordo com o cenário acima, eles não salvam nenhum dado sobre o evento e o ambiente do evento. Excluir uma amostra de malware, via de regra, não limita de forma alguma as capacidades dos invasores, e um incidente mais sério, do qual o malware excluído pelo funcionário fazia parte, mais cedo ou mais tarde ocorre.
Os chefes da organização se perguntam: "Como o sistema foi infectado?" - e decidem realizar uma análise do sistema. Como resultado da autogestão, parte dos dados é destruída pelas forças dos funcionários da organização, e o especialista em investigação de incidentes só pode apresentar hipóteses, com base em fatos dispersos, sobre como os invasores entraram na rede.
Separatamente, observamos os casos em que, em incidentes, o grupo APT usa malware que existe apenas na memória operacional do sistema. E o cliente, após ser informado de que os sistemas estão infectados, simplesmente desliga toda a infraestrutura com urgência. Como resultado, após ligar o sistema, ele já está limpo de malware e simplesmente não há nada para analisar. Mas isso não significa que o grupo não tenha mantido o acesso à infraestrutura.
Durante a investigação
Gerenciamento de incidentes
Às vezes, nos estágios iniciais das investigações, nossa equipe se deparou com o problema da falta de preparação do cliente para responder a um incidente. Fomos testemunhas de como o cliente se dividia em pedaços, tentando ao mesmo tempo encontrar o responsável pela infraestrutura, começar a nos ajudar na investigação e começar a restaurar a infraestrutura.
A consistência das ações em caso de incidente é um fenômeno bastante raro, e só é observado naquelas organizações onde há um plano de resposta pré-desenvolvido.
O desenvolvimento de tal plano não é apenas uma conformidade formal com os requisitos. Este é um cenário prático passo a passo de interação entre os principais participantes do processo (de especialistas técnicos à gerência), que será muito útil em uma situação em que parece que tudo está perdido. A base de tal plano é a política de gerenciamento de incidentes de segurança da informação, que define responsabilidades, o procedimento de notificação, a classificação de incidentes e outras ações.
Ao mesmo tempo, é necessário trabalhar separadamente no plano de interação com equipes de investigação externas. Essas equipes podem dar recomendações sobre certas ações com sua infraestrutura para ajudar a restaurá-la e preservar artefatos significativos para investigação. A ausência de um plano de interação inevitavelmente leva a problemas no processo de investigação.
Vamos dar um exemplo característico:
Durante a investigação do incidente, foi encontrado um rastreamento que leva a um sistema comprometido. Mas, para os dados solicitados, o cliente envia um triage/imagem limpa com um sistema recém-reinstalado. Pedimos mais sistemas e recebemos exatamente os mesmos. Descobriu-se que o cliente já havia restaurado parcialmente os sistemas da imagem dourada, sem sequer pensar em nos avisar sobre sua intenção.
Em modo de thread único
Normalmente, do lado do cliente, uma equipe muito pequena é alocada para comunicação com a equipe de resposta. Muitas vezes, apenas um funcionário - o administrador do sistema - se torna o executor direto das instruções operacionais da equipe de investigação. Ele tem todos os direitos necessários para coletar dados e também possui informações mais detalhadas sobre a infraestrutura "no local".
Isso gera alguns problemas. Na maioria das organizações, o número de administradores é limitado. Sua principal responsabilidade após o incidente é restaurar a infraestrutura, atualizar o acesso, alterar as configurações, e eles nem sempre podem alocar tempo de forma eficaz entre a coleta de dados para especialistas em resposta e seus deveres diretos.
Para não sobrecarregar o funcionário, a melhor prática é alocar um curto período de tempo para que ele resolva as tarefas da equipe de investigação. Muitas das tarefas definidas estão frequentemente relacionadas à coleta de dados, ou seja, executar utilitários ou executar comandos específicos. Depois disso, o funcionário pode estar livre até a conclusão da coleta de dados.
Por sua vez, a equipe de investigação é obrigada a definir tarefas específicas e, ao mesmo tempo, explicar como realizar uma determinada ação para facilitar o trabalho do administrador.
Tudo é mantido trancado!
Nossa equipe se deparou com casos em que o fornecimento de dados para pesquisa foi complicado pelo medo do cliente de sua possível perda ou vazamento. Às vezes, havia tentativas de excluir alguns artefatos dos dados coletados. No entanto, em nossa opinião, tais medos são excessivos. Além disso, tentar excluir quaisquer dados coletados pode afetar os resultados da investigação.
Em primeiro lugar, o serviço de investigação e resposta a incidentes implica que as partes assinem um acordo de confidencialidade (NDA), que especifica todas as obrigações e condições necessárias. Além disso, o acordo de confidencialidade especifica os termos de armazenamento dos dados do incidente.
Do ponto de vista técnico, a equipe Solar 4RAYS armazena todos os dados transferidos pelo cliente exclusivamente em repositórios protegidos com um sistema de controle de acesso de vários níveis baseado no princípio de privilégios mínimos. O acesso aos dados é fornecido ao especialista por um tempo limitado, e todas as ações com os arquivos são salvas no log de auditoria.
Como resultado, a transferência e o processamento de dados no âmbito da investigação são totalmente seguros. E as "dúvidas" do cliente podem afetar negativamente o processo de investigação.
Após a investigação do incidente
Quem precisa de suas recomendações...
As recomendações são a quintessência dos resultados da investigação do incidente. Eles sistematizam ações específicas justificadas necessárias para eliminar as consequências do comprometimento, restaurar a integridade da infraestrutura e reduzir o risco de reinfecção. Eles incluem não apenas instruções técnicas, mas também recomendações organizacionais para fortalecer a segurança geral. Atenção especial é dada aos indicadores de comprometimento que precisam ser rastreados após o incidente.
A prática mostra que, às vezes, as recomendações não recebem a devida atenção, ou são completamente ignoradas. Tais "omissões" não apenas reduzem a eficácia da investigação, mas contribuem diretamente para a re-comprometimento.
E, por mais óbvio que isso possa parecer, a maneira mais eficaz de evitar incidentes repetidos é seguir estritamente as recomendações. Eles não são uma formalidade. Cada uma das ações especificadas nas recomendações é devido à análise de ameaças, às ações dos invasores e aos resultados da investigação. Cada etapa é parte de uma cadeia consistente, cuja violação pode deixar o sistema vulnerável a ataques semelhantes ou semelhantes.
Vamos dar um exemplo da prática de investigação de incidentes:
O cliente pediu para conduzir uma investigação de incidente limitada em número de sistemas. No processo, foram encontrados múltiplos rastros de atividade do grupo APT.
Como resultado, demos uma série de recomendações: o que fazer com a infraestrutura, quais indicadores de comprometimento rastrear e como. No entanto, em breve, o mesmo cliente veio até nós - durante o monitoramento, seus especialistas detectaram apelos ao C2 dos invasores, especificados em nosso relatório.
Descobriu-se que as recomendações foram implementadas apenas seis meses após a investigação. Durante esse tempo, os invasores continuaram a infectar a infraestrutura ramificada e começaram a usar um novo C2.
Conclusões
Os problemas acima, individualmente, nem sempre impedem a investigação, mas, no agregado, podem impedi-la ou distorcer os resultados finais.
Nas condições modernas de alto nível de ameaças cibernéticas, uma abordagem sistemática para os processos de segurança da informação não é uma recomendação, mas uma necessidade severa.
Cada organização, independentemente da escala e do setor, deve ter um plano de ação claro em caso de incidente de segurança da informação. Além do plano, os processos de gerenciamento de ativos, treinamento de funcionários nos fundamentos da segurança da informação e monitoramento devem ser estabelecidos.
Atenção especial deve ser dada ao princípio de preservar rastros digitais relacionados ao incidente. Os rastros deixados pelos invasores são as principais evidências de atividade maliciosa. Sua alteração ou perda pode dificultar o processo de pesquisa e impedir a precisão dos resultados.
Tudo isso reduzirá significativamente o risco de um incidente e, no caso de sua ocorrência, os processos construídos ajudarão a realizar uma investigação de alta qualidade no menor tempo possível.
Outros artigos sobre investigação e resposta a ataques cibernéticos, bem como pesquisas de ameaças cibernéticas (incluindo indicadores de comprometimento) podem ser encontrados em nosso
blog
.
A equipe do centro de pesquisa de ameaças cibernéticas
Solar 4RAYS
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
