Sandworm interrompe energia na Ucrânia usando um novo ataque contra tecnologia operacional

No final de 2022, a Mandiant respondeu a um incidente ciberfísico perturbador no qual o ator ameaçador Sandworm, ligado à Rússia, teve como alvo uma organização ucraniana de infraestrutura crítica. Este incidente foi um ataque cibernético multieventos que aproveitou uma nova técnica para impactar sistemas de controle industrial (ICS)/tecnologia operacional (TO). O ator usou pela primeira vez técnicas de vida fora da terra (LotL) de nível OT para provavelmente desarmar os disjuntores da subestação da vítima, causando uma queda de energia não planejada que coincidiu com ataques em massa de mísseis contra infraestruturas críticas em toda a Ucrânia. Posteriormente, o Sandworm conduziu um segundo evento perturbador ao implantar uma nova variante do CADDYWIPER no ambiente de TI da vítima.

Este ataque representa a mais recente evolução na capacidade de ataque físico cibernético da Rússia, que tem sido cada vez mais visível desde a invasão da Ucrânia pela Rússia. As técnicas utilizadas durante o incidente sugerem uma maturidade crescente do arsenal ofensivo de TO da Rússia, incluindo a capacidade de reconhecer novos vetores de ameaças de TO, desenvolver novas capacidades e aproveitar diferentes tipos de infraestrutura de TO para executar ataques. Ao usar técnicas LotL, o ator provavelmente diminuiu o tempo e os recursos necessários para conduzir seu ataque físico cibernético. Embora a Mandiant não tenha conseguido determinar o ponto inicial de intrusão, nossa análise sugere que o componente OT deste ataque pode ter sido desenvolvido em apenas dois meses. Isso indica que o ator da ameaça provavelmente será capaz de desenvolver rapidamente capacidades semelhantes contra outros sistemas TO de diferentes fabricantes de equipamentos originais (OEMs) aproveitados em todo o mundo.

Inicialmente rastreamos essa atividade como  UNC3810 antes de fundir o cluster com o Sandworm. Sandworm é um ator de ameaça de amplo espectro que realizou operações de espionagem, influência e ataque em apoio à Diretoria Principal de Inteligência (GRU) da Rússia desde pelo menos 2009. O foco central de longa data do grupo tem sido a Ucrânia, onde realizou um campanha de ataques disruptivos e destrutivos na última década usando malware de limpeza, inclusive durante a reinvasão da Rússia em 2022. Além da Ucrânia, o grupo continua a sustentar operações de espionagem de escopo global e ilustrativas das ambições e interesses de longo alcance dos militares russos em outras regiões. Acusações governamentais vincularam o grupo ao Centro Principal de Tecnologias Especiais (também conhecido como GTsST e Unidade Militar 74455). Dada a atividade de ameaça global da Sandworm e os novos recursos de TO, instamos os proprietários de ativos de TO a tomar medidas para mitigar esta ameaça. Incluímos uma série de detecções, orientações de caça e proteção, mapeamentos MITRE ATT&CK e muito mais nos apêndices desta postagem do blog.

Se precisar de suporte para responder a atividades relacionadas, entre em contato com  a Mandiant Consulting. Análises mais detalhadas da atividade de ameaças do Sandworm estão disponíveis como parte do  Mandiant Advantage Threat Intelligence.

Resumo do Incidente

Com base em nossa análise, a intrusão começou em junho de 2022 ou antes e culminou em dois eventos perturbadores em 10 e 12 de outubro de 2022. Embora não tenhamos conseguido identificar o vetor de acesso inicial ao ambiente de TI, o Sandworm obteve acesso ao Ambiente TO por meio de um hipervisor que hospedava uma instância de gerenciamento de controle de supervisão e aquisição de dados (SCADA) para o ambiente da subestação da vítima. Com base na evidência de movimento lateral, o invasor potencialmente teve acesso ao sistema SCADA por até três meses.

Em 10 de outubro, o ator aproveitou uma imagem de disco óptico (ISO) chamada “a.iso” para executar um binário MicroSCADA nativo em uma provável tentativa de executar comandos de controle maliciosos para desligar subestações. O arquivo ISO continha pelo menos o seguinte:

• “lun.vbs”, que executa n.bat
• “n.bat”, que provavelmente executa o utilitário nativo scilc.exe
• “s1.txt”, que provavelmente contém comandos MicroSCADA não autorizados

Com base no carimbo de data/hora “lun.vbs” de 23 de setembro, havia potencialmente um período de dois meses desde o momento em que o invasor obteve acesso inicial ao sistema SCADA até o momento em que desenvolveu o recurso OT. Embora não tenhamos conseguido recuperar totalmente a execução do comando ICS implementado pelo binário, estamos cientes de que o ataque resultou em uma queda de energia não programada. A Figura 1 contém uma visualização da cadeia de execução que resultou no evento disruptivo de TO.

Dois dias após o evento de OT, a Sandworm implantou uma nova variante do CADDYWIPER no ambiente de TI da vítima para causar mais interrupções e potencialmente remover artefatos forenses. No entanto, observamos que a implantação do limpador foi limitada ao ambiente de TI da vítima e não impactou o hipervisor ou a máquina virtual SCADA. Isto é incomum, uma vez que o autor da ameaça removeu outros artefatos forenses do sistema SCADA em uma possível tentativa de encobrir seus rastros, o que teria sido aprimorado pela atividade do limpador. Isto pode indicar uma falta de coordenação entre os diferentes indivíduos ou subequipas operacionais envolvidas no ataque.

Um mergulho mais profundo no ciclo de vida do ataque e na capacidade de TO pode ser encontrado na seção Análise Técnica da postagem do blog.

A atividade de ameaças do Sandworm revela insights sobre as capacidades cibernéticas ofensivas da Rússia

O ataque à subestação do Sandworm revela insights notáveis ​​sobre o investimento contínuo da Rússia em capacidades cibernéticas ofensivas orientadas para TO e a abordagem geral para atacar sistemas de TO. Este incidente e o incidente INDUSTROYER.V2 do ano passado mostram esforços para agilizar os recursos de ataque de TO por meio de recursos de implantação simplificados. Observámos os mesmos esforços na nossa análise de uma série de documentos que detalham os requisitos do projecto para melhorar as  capacidades cibernéticas ofensivas russas.

Da mesma forma, a evolução dos ataques OT suspeitos de serem patrocinados pelo GRU mostra uma diminuição no escopo de atividades disruptivas por ataque. Cada um dos eventos de apagão na Ucrânia de 2015 e 2016 apresentou vários eventos disruptivos discretos contra o ambiente OT (por exemplo, desativação de sistemas UPS, bloqueio de conversores serial para Ethernet, condução de um ataque DoS contra um relé SIPROTEC, limpeza de sistemas OT, etc.). Em comparação, os  incidentes do INDUSTROYER.V2 não possuíam muitos desses mesmos componentes perturbadores e o malware não apresentava o módulo limpador do INDUSTROYER original. Da mesma forma, a atividade do Sandworm na rede OT parece simplificada para executar apenas mensagens de comando ICS não autorizadas, com a atividade do limpador limitada ao ambiente de TI. Embora esta mudança provavelmente reflita o ritmo acelerado das operações cibernéticas em tempo de guerra, ela também revela os objetivos prioritários do GRU nos ataques de TO.

O uso pelo Sandworm de um  binário nativo Living off the Land (LotLBin) para interromper um ambiente de AT mostra uma mudança significativa nas técnicas. Usando ferramentas mais leves e genéricas do que aquelas observadas em incidentes anteriores de TO, o ator provavelmente diminuiu o tempo e os recursos necessários para conduzir um ataque físico cibernético. As técnicas LotLBin também dificultam a detecção de atividades de ameaças pelos defensores, pois eles precisam não apenas permanecer vigilantes em relação a novos arquivos introduzidos em seus ambientes, mas também a modificações em arquivos já presentes em seus aplicativos e serviços de TO instalados. Conforme descrito em uma pesquisa recente que detalha o  manual disruptivo do GRU, observamos o Sandworm adotando táticas LotL em suas operações mais amplas para aumentar de forma semelhante a velocidade e a escala em que pode operar, minimizando as chances de detecção.

Embora não tenhamos provas suficientes para avaliar uma possível ligação, notamos que o momento do ataque coincide com as operações cinéticas russas. O Sandworm desenvolveu potencialmente a capacidade disruptiva três semanas antes do evento OT, sugerindo que o invasor pode estar esperando por um momento específico para implantar a capacidade. A eventual execução do ataque  coincidiu com o início de uma série de ataques coordenados de vários dias com mísseis contra infra-estruturas críticas em  várias cidades ucranianas, incluindo a cidade onde a vítima estava localizada.

Panorama

Este ataque representa uma ameaça imediata aos ambientes de infraestrutura crítica ucraniana que utilizam o sistema de controle de supervisão MicroSCADA. Dada a atividade global de ameaças da Sandworm e a implantação mundial de produtos MicroSCADA, os proprietários de ativos em todo o mundo devem tomar medidas para mitigar suas táticas, técnicas e procedimentos contra sistemas de TI e TO. Além disso, a nossa análise da actividade sugere que a Rússia seria capaz de desenvolver capacidades semelhantes contra outros sistemas SCADA e linguagens de programação além do MicroSCADA e SCIL. Instamos os proprietários de ativos a rever e implementar as seguintes recomendações para mitigar e detetar esta atividade.

Reconhecimentos

Esta pesquisa foi possível graças ao trabalho árduo de muitas pessoas não listadas na assinatura. A Mandiant gostaria de agradecer ao Serviço de Segurança da Ucrânia (SBU) pela sua parceria contínua e contribuições para este relatório, bem como pela sua colaboração contínua. Este compromisso de resposta a incidentes foi financiado através do Programa Cibernético da Ucrânia do Reino Unido (Fundo intergovernamental para Conflitos, Estabilidade e Segurança) e entregue pelo Gabinete de Relações Exteriores, Commonwealth e Desenvolvimento do Reino Unido.

Análise Técnica: Ataque Sandworm Contra Subestações Ucranianas

Compromisso inicial e manutenção da presença

Neste momento, não se sabe como o Sandworm obteve acesso inicial à vítima. Sandworm foi observado pela primeira vez no ambiente da vítima em junho de 2022, quando o ator implantou o  webshell Neo-REGEORG em um servidor voltado para a Internet. Isto é consistente com a atividade anterior do grupo, verificando e explorando servidores voltados para a Internet para acesso inicial. Cerca de um mês depois, o Sandworm implantou o GOGETTER, que é um tunelizador escrito em Golang que faz proxy das comunicações para seu servidor de comando e controle (C2) usando a biblioteca de código aberto Yamux sobre TLS.

Ao aproveitar o GOGETTER, o Sandworm utilizou uma unidade de serviço Systemd para manter a persistência nos sistemas. Uma unidade de serviço Systemd permite que um programa seja executado sob certas condições e, neste caso, foi usada para executar o binário GOGETTER na reinicialização.

O arquivo de configuração Systemd aproveitado pelo Sandworm permitiu ao grupo manter a persistência nos sistemas. O valor “WantedBy” define quando o programa deve ser executado; na configuração usada pelo Sandworm, a configuração “multi-user.target” significa que o programa será executado quando o host atingir um estado em que aceitará o login de usuários, por exemplo, após a inicialização bem-sucedida. Isso permite que o GOGETTER mantenha a persistência durante as reinicializações. O valor “ExecStart” especifica o caminho do programa a ser executado, que neste caso foi GOGETTER.

Ao implantar o GOGETTER, a Mandiant observou que o Sandworm aproveita unidades de serviço Systemd projetadas para se disfarçar como serviços legítimos ou aparentemente legítimos.

Movimento lateral para hipervisor SCADA e execução de ataque OT

O Sandworm utilizou uma nova técnica para impactar o ambiente OT, executando código dentro de um sistema de controle MicroSCADA de fim de vida (EOL) e emitindo comandos que impactaram as subestações conectadas da vítima. A Tabela 1 resume os arquivos maliciosos que contêm o novo recurso de TO. Observamos que, devido ao uso de técnicas antiforenses pelo invasor, não conseguimos recuperar todos os artefatos da intrusão.

Para impactar os sistemas TO, o Sandworm acessou o hipervisor que hospedava uma instância de gerenciamento SCADA para o ambiente da subestação da vítima e aproveitou uma imagem ISO chamada “a.iso” como um CD-ROM virtual. O sistema foi configurado para permitir a execução automática de CD-ROMs inseridos. O arquivo ISO, no mínimo, continha os seguintes arquivos: “lun.vbs” e “n.bat”, pois ambos os arquivos são referenciados no volume D e, portanto, contidos em “a.iso”. O ISO inserido levou à execução de pelo menos as seguintes linhas de comando:

• wscript.exe “d:\pack\lun.vbs”
• cmd /c “D:\pack\n.bat”

Com base na análise forense, acreditamos que os conteúdos “lun.vbs” são os seguintes (Figura 6):

O conteúdo da Figura 6 indica que “lun.vbs” executa “n.bat”. Fragmentos adicionais recuperados incluem texto consistente com a execução da linha de comando do Windows (Figura 7). Este fragmento foi identificado através da análise de imagens do hospedeiro. A reconstrução dos logs antivírus do host indica que “lun.vbs” e “n.bat” foram executados em grande proximidade. Por causa disso e da referência ao caminho da pasta ISO do invasor, acreditamos que o fragmento de comando na Figura 7 é provavelmente o conteúdo de “n.bat”.

A sintaxe do fragmento de comando inclui “scilc.exe”, um utilitário nativo que faz parte do conjunto de software MicroSCADA. O utilitário está localizado na pasta “\sc\prog\exec” dentro do diretório de instalação do MicroSCADA, entre outros utilitários, bibliotecas e recursos utilizados pelo MicroSCADA. O sistema MicroSCADA afetado estava executando uma versão de software EOL que permitia acesso padrão à API SCIL. O sinalizador “-do” especifica um arquivo de programa SCIL a ser executado (Figura 8). Por último, o comando fornece um arquivo chamado “s1.txt” na pasta “pack\scil\” da ISO do invasor. Avaliamos que “pack\scil\s1.txt” é provavelmente um arquivo contendo comandos SCIL que os invasores executaram no MicroSCADA. Este arquivo estava irrecuperável no momento da análise.

De acordo com a documentação da Hitachi Energy, SCIL é uma linguagem de programação de alto nível projetada para sistemas de controle MicroSCADA e pode operar o sistema e seus recursos (Figura 9). Os programas SCIL são geralmente instruções baseadas em texto que podem ser compostas de comandos, objetos, variáveis, chamadas para funções predefinidas e expressões. Existem vários métodos pelos quais os programas SCIL podem ser executados, como um engenheiro/operador clicando em um botão ou imagem dentro do sistema MicroSCADA, alterações programadas ou derivadas do processo ou, neste caso, execução manual.

Embora não tenhamos conseguido identificar os comandos SCIL executados, acreditamos que provavelmente eram comandos para abrir disjuntores nos ambientes da subestação da vítima. Os comandos SCIL teriam feito com que o servidor MicroSCADA retransmitisse os comandos para as UTRs da subestação através do protocolo IEC-60870-5-104 para conexões TCP/IP ou do protocolo IEC-60870-5-101 para conexões seriais.

Sandworm implantou nova variante CADDYWIPER para perturbar ainda mais o ambiente de TI da vítima

Dois dias após a atividade de TO, a Sandworm implantou uma nova variante do CADDYWIPER em todo o ambiente de TI. Esta variante CADDYWIPER, compilada em outubro de 2022, contém algumas pequenas melhorias de funcionalidade que permitem aos agentes da ameaça resolver funções em tempo de execução. Observamos o CADDYWIPER implantado em vários setores verticais na Ucrânia, incluindo os setores governamental e financeiro, durante a invasão da Ucrânia pela Rússia.

CADDYWIPER é um limpador disruptivo escrito em C que tem como objetivo tornar os dados irrecuperáveis ​​e causar o máximo de danos em um ambiente. CADDYWIPER tentará limpar todos os arquivos antes de prosseguir com a limpeza de quaisquer unidades mapeadas. Em seguida, ele tentará limpar a partição da unidade física. Notavelmente, o CADDYWIPER tem sido a ferramenta disruptiva utilizada com mais frequência contra entidades ucranianas durante a guerra e tem sido utilizada operacionalmente de forma consistente desde março de 2022, com base em relatórios públicos. Observamos o Sandworm utilizar o CADDYWIPER em operações disruptivas em múltiplas invasões.

O Sandworm implantou o CADDYWIPER nesta operação por meio de dois objetos de política de grupo (GPO) de um controlador de domínio usando TANKTRAP. TANKTRAP é um utilitário escrito em PowerShell que utiliza a política de grupo do Windows para espalhar e iniciar um limpador. Observamos o TANKTRAP sendo usado com outras ferramentas disruptivas, incluindo NEARMISS, SDELETE, PARTYTICKET e CADDYWIPER. Essas políticas de grupo continham instruções para copiar um arquivo de um servidor para o disco rígido local e agendar uma tarefa para executar o arquivo copiado em um horário específico.

Ambos os GPOs TANKTRAP implantaram o CADDYWIPER de um diretório preparado para sistemas como msserver.exe. O CADDYWIPER foi então executado como uma tarefa agendada em um horário pré-determinado.

Apêndice A: Orientação para descoberta e endurecimento

Neste incidente, o invasor aproveitou uma versão EOL do sistema de controle supervisório MicroSCADA. A interface SCIL-API no MicroSCADA foi desabilitada por padrão desde o lançamento do MicroSCADA 9.4 em 2014. Se necessário para continuar usando a interface, os proprietários de ativos podem consultar a Diretriz de implantação de segurança cibernética MRK511518 MicroSCADA X sobre como fortalecer o MicroSCADA. Entre em contato com a equipe de suporte do Hitachi Energy MicroSCADA para obter a documentação.

Observamos que o sistema de controle MicroSCADA tornou-se um produto da Hitachi Energy em 2022 após um desinvestimento da ABB. Os proprietários de ativos devem consultar ambos os fornecedores em inventários de ativos e inspeções manuais de ativos para determinar se o produto está presente em algum ambiente de TO.

Harden MicroSCADA e outros hosts de gerenciamento SCADA:

• Atualize o MicroSCADA para versões suportadas.
• Configure o MicroSCADA para exigir autenticação e estabelecer um design de privilégio mínimo para permissões de usuário.
• Estabeleça uma segmentação de rede robusta entre hosts MicroSCADA e redes de TI.
• Habilite o registro robusto de aplicativos para MicroSCADA e agregue registros em um local central.
• Se/quando possível, configure o sistema base no modo “somente leitura” e certifique-se de que nenhum programa SCIL-API externo (como scilc.exe) seja permitido.
• Consulte os OEMs sobre o software SCADA instalado para identificar métodos semelhantes de execução de código em seu software e para obter orientação sobre mitigações.

Monitore sistemas MicroSCADA e outros sistemas de gerenciamento SCADA para:

• Execução de linha de comando do binário MicroSCADA “Scilc.exe” e outros binários nativos do MicroSCADA que podem ser aproveitados para executar programas/comandos SCIL não autorizados.
• Tráfego de rede e telemetria relacionada ao processo de/para host(s) que operam o software MicroSCADA. Investigue atividades anômalas e correlacione as descobertas com a telemetria do processo.
• Arquivos transferidos ou movidos para hosts MicroSCADA.
• Arquivos recém-criados com referências de linguagem de programação MicroSCADA ou SCIL.
• Alterações não autorizadas na configuração e nos dados do sistema MicroSCADA.

Apêndice B: Indicadores de Compromisso (IOCs)

Apêndice C: Regras YARA

rule M_Methodology_MicroSCADA_SCILC_Strings {      meta:           author = "Mandiant"           date = "2023-02-13"           description = "Searching for files containing strings associated with the MicroSCADA Supervisory Control Implementation Language (SCIL) scilc.exe binary."            disclaimer = "This rule is for hunting purposes only and has not been tested to run in a production environment."        strings:           $s1 = "scilc.exe" ascii wide           $s2 = "Scilc.exe" ascii wide           $s3 = "SCILC.exe" ascii wide           $s4 = "SCILC.EXE" ascii wide        condition:           filesize < 1MB and           any of them }

rule M_Hunting_MicroSCADA_SCILC_Program_Execution_Strings {      meta:           author = "Mandiant"           date = "2023-02-13"           description = "Searching for files containing strings associated with execution of the MicroSCADA Supervisory Control Implementation Language (SCIL) scilc.exe binary."            disclaimer = "This rule is for hunting purposes only and has not been tested to run in a production environment."        strings:           $s = "scilc.exe -do" nocase ascii wide        condition:           filesize < 1MB and            all of them }

rule M_Methodology_MicroSCADA_Path_Strings {      meta:           author = "Mandiant"           date = "2023-02-27"           description = "Searching for files containing references to MicroSCADA filesystem path containing native MicroSCADA binaries and resources."            disclaimer = "This rule is for hunting purposes only and has not been tested to run in a production environment."        strings:           $s1 = "sc\\prog\\exec" nocase ascii wide        condition:           filesize < 1MB and           $s1 }

rule M_Hunting_VBS_Batch_Launcher_Strings {      meta:           author = "Mandiant"           date = "2023-02-13"           description = "Searching for VBS files used to launch a batch script."           disclaimer = "This rule is for hunting purposes only and has not been tested to run in a production environment."        strings:           $s1 = "CreateObject(\"WScript.Shell\")" ascii           $s2 = "WshShell.Run chr(34) &" ascii           $s3 = "& Chr(34), 0" ascii           $s4 = "Set WshShell = Nothing" ascii           $s5 = ".bat" ascii           condition:           filesize < 400 and            all of them }

rule M_Hunting_APT_Webshell_PHP_NEOREGEORG  {      meta:           author = "Mandiant"           description = "Searching for REGEORG webshells."           disclaimer = "This rule is for hunting purposes only and has not been tested to run in a production environment."        strings:           $php = "<?php" nocase           $regeorg1 = {24 72 61 77 50 6f 73 74 44 61 74 61 20 3d 20 66 69 6c 65 5f 67 65 74 5f 63 6f 6e 74 65 6e 74 73 28 22 70 68 70 3a 2f 2f 69 6e 70 75 74 22 29 3b}           $regeorg2 = {20 24 77 72 69 74 65 42 75 66 66 20 3d 20 24 5f 53 45 53 53 49 4f 4e 5b 24 77 72 69 74 65 62 75 66 5d 3b}           $regeorg3 = {20 75 73 6c 65 65 70 28 35 30 30 30 30 29 3b}           $regeorg4 = {20 24 61 72 68 5f 6b 65 79 20 3d 20 70 72 65 67 5f 72 65 70 6c 61 63 65 28 24 72 78 5f 68 74 74 70 2c 20 27 27 2c 20 24 6b 65 79 29 3b}           $regeorg5 = {20 24 72 75 6e 6e 69 6e 67 20 3d 20 24 5f 53 45 53 53 49 4f 4e 5b 24 72 75 6e 5d 3b}           $regeorg6 = {20 24 72 78 5f 68 74 74 70 20 3d 20 27 2f 5c 41 48 54 54 50 5f 2f 27 3b}        condition:           (5 of ($regeorg*)) and           $php }

rule M_Hunting_GOGETTER_SystemdConfiguration_1 {      meta:           author = "Mandiant"           description = "Searching for Systemd Unit Configuration Files but with some known filenames observed with GOGETTER"           disclaimer = "This rule is for hunting purposes only and has not been tested to run in a production environment."        strings:           $a1 = "[Install]" ascii fullword           $a2 = "[Service]" ascii fullword           $a3 = "[Unit]" ascii fullword           $v1 = "Description=" ascii            $v2 = "ExecStart=" ascii            $v3 = "Restart=" ascii            $v4 = "RestartSec=" ascii            $v5 = "WantedBy=" ascii            $f1 = "fail2ban-settings" ascii fullword           $f2 = "system-sockets" ascii fullword           $f3 = "oratredb" ascii fullword           $f4 = "cloud-online" ascii fullword      condition:           filesize < 1MB and (3 of ($a*)) and (3 of ($v*)) and (1 of ($f*)) }

Apêndice D: Regras SIGMA e YARA-L

title: MicroSCADA SCILC Command Execution description: Identification of Events or Host Commands that are related to the MicroSCADA SCILC programming language and specifically command execution author: Mandiant date: 2023/02/27 logsource:     product: windows     service: security detection:     selection:         NewProcessName|endswith:             - \scilc.exe         CommandLine|contains:             - -do     condition: selection falsepositives:     - Red Team level: High tags:     - attack.execution     - attack.T1059

rule M_YARAL_Methodology_ProcessExec_SCILC_Do_1 {     meta:         author = "Mandiant"         description = "YARA-L rule hunting for instances of process execution of the scilc.exe process with -do parameters. This is intended to be a hunting rule. Analysts would need to verify the legitimacy of the file passed in the -do parameter."         severity = "Low"         reference = " https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-overview"       events:         $e.metadata.event_type = "PROCESS_LAUNCH"         $e.target.process.command_line = /\s+\-do\s+[^\-\s]+/ nocase         $e.target.process.file.full_path = /scilc\.exe$/ nocase     condition:         $e }

Apêndice E: MITRE ATT&CK para mapeamento ICS

Apêndice F: Conteúdo de Validação