{"id":5150,"date":"2023-05-23T16:32:34","date_gmt":"2023-05-23T19:32:34","guid":{"rendered":"https:\/\/base4sec.com\/nao-categorizado\/hipotesis-en-el-campo-de-la-deteccion-de-ciberamenazas\/"},"modified":"2024-12-12T18:16:51","modified_gmt":"2024-12-12T21:16:51","slug":"hipotesis-en-el-campo-de-la-deteccion-de-ciberamenazas","status":"publish","type":"post","link":"https:\/\/base4sec.com\/pt-br\/pesquisar\/hipotesis-en-el-campo-de-la-deteccion-de-ciberamenazas\/2023\/05\/23\/","title":{"rendered":"Hip\u00f3teses no campo da detec\u00e7\u00e3o de amea\u00e7as cibern\u00e9ticas"},"content":{"rendered":"

A detec\u00e7\u00e3o de amea\u00e7as \u00e9 a principal etapa das defesas cibern\u00e9ticas de uma organiza\u00e7\u00e3o, \u00e9 como alimentamos claramente nossos sistemas de prote\u00e7\u00e3o e resposta. \u00c9 somente encontrando essa amea\u00e7a ativa que podemos agir,\u00a0isolar<\/b>,\u00a0eliminar<\/b>,\u00a0enganar<\/b>\u00a0ou melhorar\u00a0os modelos de amea\u00e7as cibern\u00e9ticas<\/b>.<\/p>\n

Explorando alguns exemplos da afirma\u00e7\u00e3o acima, percebemos que h\u00e1 muitos casos em que \u00e9 poss\u00edvel agir a nosso favor sem a necessidade de ter feito qualquer tipo de detec\u00e7\u00e3o, por exemplo, ativando um firewall, implantando uma solu\u00e7\u00e3o antimalware ou usando uma senha complexa. Isso n\u00e3o \u00e9 totalmente verdade, pois todas as a\u00e7\u00f5es de prote\u00e7\u00e3o que aplicamos (sejam preventivas ou reativas) baseiam-se em um entendimento das amea\u00e7as que foram modeladas anteriormente, como no caso de estrat\u00e9gias mais abrangentes, como o Princ\u00edpio do Menor Privil\u00e9gio (PoLP), a boa e velha defesa em profundidade ou o modelo Zero Trust.<\/p>\n

\u00c9 com isso em mente que agora nos concentraremos no\u00a0comportamento<\/b>\u00a0dos atacantes cibern\u00e9ticos e em como \u00e9 poss\u00edvel destilar\u00a0regras de detec\u00e7\u00e3o\u00a0<\/b>utiliz\u00e1veis a partir de um conjunto de hip\u00f3teses. Nesta postagem, analisaremos a l\u00f3gica por tr\u00e1s da detec\u00e7\u00e3o comportamental, algumas linguagens para a gera\u00e7\u00e3o de regras export\u00e1veis e um modelo de detec\u00e7\u00e3o din\u00e2mica conhecido como \u201cDetec\u00e7\u00e3o como c\u00f3digo<\/b>\u201d.<\/p>\n

Da t\u00e9cnica \u00e0 detec\u00e7\u00e3o<\/span><\/p>\n

Tomaremos algumas t\u00e9cnicas comumente usadas numa cadeia de ataques cibern\u00e9ticos para analis\u00e1-las. Nesse caso, usaremos como refer\u00eancia a matriz MITRE ATT&CK no contexto da ca\u00e7a a amea\u00e7as (voc\u00ea pode ler sobre ela em nosso\u00a0post anterior<\/a>).<\/p>\n

T1087.004 – Account Discovery: Cloud Account<\/span><\/p>\n

Vamos come\u00e7ar adiantando um pouco os est\u00e1gios de um ataque cibern\u00e9tico e tomar como refer\u00eancia a t\u00e9cnica de enumera\u00e7\u00e3o “Account Discovery” em sua variante “Cloud Accounts”. Essa t\u00e9cnica, como a maioria das t\u00e9cnicas\u00a0de enumera\u00e7\u00e3o<\/b>baseia-se na premissa de que o invasor cibern\u00e9tico pode tentar coletar uma lista de itens adicionais que lhe permitam\u00a0expandir seu ataque<\/b>,Para essa t\u00e9cnica espec\u00edfica, os dados descobertos podem ser usu\u00e1rios e fun\u00e7\u00f5es em um servi\u00e7o de nuvem (Azure AD, Google Workspace, IaaS, Office 365, SaaS).<\/p>\n

\n

<\/center><\/p>\n

\n

Reconhecendo esse\u00a0comportamento<\/b>, analisamos a maneira espec\u00edfica pela qual um atacante cibern\u00e9tico poderia realiz\u00e1-lo na pr\u00e1tica. Para sermos espec\u00edficos em nosso exemplo, vamos nos concentrar na interface de comando do Azure (AZ CLI). A MITRE ATT&CK prop\u00f5e o comando “az ad user list” como exemplo. Uma poss\u00edvel sa\u00edda desse comando com alguns par\u00e2metros forneceria dados espec\u00edficos do usu\u00e1rio.<\/p>\n

<\/center>
Exemplo de sa\u00edda de “az ad user list”.<\/center><\/p>\n

\n

Uma\u00a0hip\u00f3tese<\/b>, ent\u00e3o, para come\u00e7ar com “nosso destilado por detec\u00e7\u00e3o” poderia ser:<\/p>\n

“Se o comando ‘AZ AD USER LIST’ for executado, um advers\u00e1rio estar\u00e1 realizando uma DESCOBERTA”.<\/b><\/center><\/p>\n

Do ponto de vista da “detec\u00e7\u00e3o”, podemos ver que o grau de\u00a0precis\u00e3o<\/b>\u00a0dessa afirma\u00e7\u00e3o \u00e9 baixo, pois podemos encontrar v\u00e1rios casos em que encontramos esse comportamento e n\u00e3o se trata de um invasor. Por exemplo, na implementa\u00e7\u00e3o de algum tipo de solu\u00e7\u00e3o por um administrador de nuvem, at\u00e9 mesmo algum software de gerenciamento de identidade que realiza consultas por meio da mesma API. Precisamos\u00a0refinar nossa hip\u00f3tese<\/b>\u00a0aqui para melhorar a precis\u00e3o, por exemplo:<\/p>\n

“Se o comando ‘AZ AD USER LIST’ for executado de um terminal desconhecido, um advers\u00e1rio estar\u00e1 realizando uma DESCOBERTA”.<\/b><\/center><\/p>\n

\n

Essa nova defini\u00e7\u00e3o aumenta o\u00a0grau de precis\u00e3o<\/b>, , embora, por outro lado, limite o\u00a0escopo<\/b>, pois s\u00f3 podemos detectar esse comportamento se o terminal de origem for desconhecido (o que nem sempre \u00e9 o caso).<\/p>\n

<\/center><\/p>\n

A detec\u00e7\u00e3o precisa nos aproximar da base da pir\u00e2mide. A detec\u00e7\u00e3o exaustiva nos aproxima do topo. N\u00e3o h\u00e1 respostas certas, combinamos constantemente as duas estrat\u00e9gias (Assinaturas + Heur\u00edstica<\/b>).<\/p>\n

<\/center><\/p>\n

O tamanho certo depender\u00e1 de\u00a0nossos objetivos de detec\u00e7\u00e3o<\/b>\u00a0e dos riscos associados ao ativo que queremos proteger.<\/p>\n

Por outro lado, avan\u00e7ando com a implementa\u00e7\u00e3o pr\u00e1tica desta detec\u00e7\u00e3o e a partir da perspectiva dos ‘requisitos’ para realiz\u00e1-la, o elemento disparador poderia ser um monitoramento cont\u00ednuo dos comandos executados atrav\u00e9s da interface ‘Azure CLI’. Esta fonte de detec\u00e7\u00e3o n\u00e3o \u00e9 trivial, como um registro de auditoria pr\u00e9-configurado, por isso precisamos moldar a detec\u00e7\u00e3o a partir de outros elementos observ\u00e1veis de acordo com as tecnologias que temos. \u00c9 necess\u00e1rio encontrar alternativas, como focar nos terminais que poderiam executar comandos no Azure CLI e monitorar o hist\u00f3rico de execu\u00e7\u00e3o no PowerShell, ou outros tipos de estrat\u00e9gias para cobrir tamb\u00e9m as execu\u00e7\u00f5es a partir do Azure Cloud Shell, por exemplo.<\/p>\n

T0878 – Alarm Suppression<\/span><\/p>\n

Vamos agora para um ambiente diferente e analisar as t\u00e1ticas que est\u00e3o mais relacionadas a algum tipo de impacto em\u00a0ambientes industriais<\/b>. A “supress\u00e3o de alarme” \u00e9 uma t\u00e9cnica que se enquadra na t\u00e1tica “Inibi\u00e7\u00e3o da fun\u00e7\u00e3o de resposta” espec\u00edfica da matriz MITRE para ICS ou sistemas de controle industrial (voc\u00ea pode se aprofundar em ICS ou OT nesta\u00a0publica\u00e7\u00e3o<\/a>\u00a0ou ficar do lado do invasor nesta\u00a0publica\u00e7\u00e3o<\/a>).<\/p>\n

Essa t\u00e9cnica envolve a inibi\u00e7\u00e3o de uma fun\u00e7\u00e3o de alarme que visa a alertar um operador sobre uma situa\u00e7\u00e3o cr\u00edtica no sistema. Esse tipo de t\u00e9cnica, ao contr\u00e1rio da anterior, concentra-se em dispositivos espec\u00edficos de redes industriais (por exemplo, sistemas PLC \/ Scada).<\/p>\n

<\/center><\/p>\n

Essa t\u00e9cnica geralmente \u00e9 aplicada, por exemplo, modificando ou suprimindo um sistema de avisos e mensagens de relat\u00f3rio, ou mesmo alterando os dados exibidos em uma interface do tipo HMI. H\u00e1 v\u00e1rias maneiras de abordar essa t\u00e9cnica, dependendo dos tipos de alarmes e dos dispositivos envolvidos na opera\u00e7\u00e3o, mas podemos dar alguns exemplos hipot\u00e9ticos:<\/p>\n

\n

Se uma comunica\u00e7\u00e3o ASSOCIADA AOS PROTOCOLOS DE UM SISTEMA DE ALERTA for perdida, um advers\u00e1rio est\u00e1 realizando uma INIBI\u00c7\u00c3O DE FUN\u00c7\u00d5ES DE RESPOSTA”.<\/b><\/center><\/p>\n

\n

<\/center><\/p>\n

Essa hip\u00f3tese exigir\u00e1 como “fontes de dados”, algum tipo de monitoramento de tr\u00e1fego de rede ou monitoramento de integridade dos programas envolvidos nos dispositivos, por exemplo.<\/p>\n

\n

<\/center>
MITRE ATT&CK – Poss\u00edveis fontes de dados para a detec\u00e7\u00e3o de T0878<\/center><\/p>\n

\n

A tradu\u00e7\u00e3o dessas hip\u00f3teses em uma linguagem oper\u00e1vel na forma de regras l\u00f3gicas ser\u00e1 nossa pr\u00f3xima etapa para, em seguida, implementar diferentes casos de uso em nossa infraestrutura. Sempre considerando os fatores acima, poderemos ajustar a precis\u00e3o de cada um deles.<\/p>\n

Sobre regras de detec\u00e7\u00e3o<\/span><\/p>\n

A\u00a0detec\u00e7\u00e3o em larga escala<\/b>de atividades mal-intencionadas na infraestrutura se torna complexa se quisermos usar as t\u00e9cnicas uma a uma e defini-las para cada uma de suas variantes espec\u00edficas. Consumir regras de detec\u00e7\u00e3o da comunidade, de um fornecedor ou de outras organiza\u00e7\u00f5es traz a dificuldade de que cada uma delas t\u00eam diferentes solu\u00e7\u00f5es de detec\u00e7\u00e3o, tipos de registro e estrat\u00e9gias para definir sua prote\u00e7\u00e3o. Cada SIEM tem at\u00e9 mesmo suas pr\u00f3prias linguagens de consulta.<\/p>\n

O que s\u00e3o as regras SIGMA?<\/span><\/p>\n

As regras SIGMA\u00a0<\/b>s\u00e3o um formato de assinatura de c\u00f3digo aberto que permite escrever regras de detec\u00e7\u00e3o considerando qualquer registro de entrada e em um formato padronizado. Elas t\u00eam uma sintaxe yaml e podem ser convertidas (ou\u00a0traduzidas<\/b>, como eu gosto de dizer) para a sintaxe do nosso SIEM preferido ou de qualquer plataforma usada na organiza\u00e7\u00e3o.<\/p>\n

Tomamos como exemplo uma regra sigma de um reposit\u00f3rio da comunidade encontrado em uma biblioteca de projetos SigmaHQ (aqui<\/a>), Nessa regra, o comportamento a ser detectado \u00e9 a conex\u00e3o de um poss\u00edvel invasor de um sistema afetado a um servi\u00e7o externo de “Comando e Controle<\/b>\u201d(C&C TA0011) por meio da rede onion (Multi-hop Proxy T1090.003). A t\u00e9cnica espec\u00edfica faz uso do navegador TOR para cumprir sua miss\u00e3o; essa \u00e9 a regra de detec\u00e7\u00e3o:<\/p>\n

<\/center><\/p>\n

Podemos interpretar, neste exemplo, que a detec\u00e7\u00e3o \u00e9, em princ\u00edpio, baseada nos nomes e locais dos bin\u00e1rios executados, especificamente para ambientes Windows. O leitor atento saber\u00e1 que essas regras precisam ser\u00a0refinadas para melhorar sua precis\u00e3o.<\/b>.<\/p>\n

Um guia para entender a sintaxe<\/b>\u00a0desse tipo de regra para a cria\u00e7\u00e3o de novas regras pode ser encontrado aqui\u00a0aqui<\/a>.<\/p>\n

Em seguida, para usar essa regra sigma, podemos\u00a0convert\u00ea-la\u00a0<\/b>em um formato compreens\u00edvel pela nossa solu\u00e7\u00e3o de detec\u00e7\u00e3o preferida, um SIEM como o QRADAR da IBM, o que nos deixa com uma consulta no seguinte formato:<\/p>\n

<\/center><\/p>\n

Essa convers\u00e3o pode ser feita manualmente, compreendendo a sintaxe de ambas as pseudo-linguagens, ou podemos usar as ferramentas dispon\u00edveis, como o tradutor\u00a0undercoder.io<\/a>.<\/p>\n

<\/center><\/p>\n

\n

As regras Sigma s\u00e3o apenas um exemplo de um formato para executar decis\u00f5es de triagem, que tamb\u00e9m podem ser encontradas em diferentes aplicativos e escopos:<\/p>\n