Para nós, profissionais de segurança. essa última sexta-feira 10/12 foi, realmente, a "sexta-feira da maldade". Logo no início do dia todos estavam falando sobre uma nova vulnerabilidade que permite a execução remota de código num componente que provavelmente poucas pessoas sabiam que existiam, mas todo mundo usa: "o tal de Log4j".
RESUMO DA HISTÓRIA: entre os dias 10 e 28/12, foram descobertas 5 vulnerabilidades na biblioteca Log4j 2, com 4 atualizações sendo lançadas no período. É necessário atualizar para a versão mais recente, a 2.17.1.
Essa vulnerabilidade específica do Log4j 2, publicada em 10/12 e identificada como CVE-2021-44228 (*), também passou a ser conhecida como "Log4Shell" em vários blogs e relatórios. Na véspera, dia 09/12, foi divulgado um exploit 0-Day para ela, e assim começou o pânico geral.
(*) e tem também o CVE-2021-45046, o CVE-2021-45105 e o CVE-2021-44832!!!
Atualmente, você sabe que um problema é sério quando surge uma quantidade gigantesca de memes sobre o assunto!
A vulnerabilidade "Log4Shell" permite a exploração remota de um servidor, executando código remotamente a partir de uma simples requisição HTTP. Ela atinge a biblioteca "Log4j 2" da Apache Software Foundation (ASF), um componente open source muito popular e utilizado para processar logs em aplicativos corporativos, soluções de mercado e serviços em nuvem.
Conforme descrito sucintamente no CVE-2021-44228, as versões do Apache Log4j 2 abaixo de 2.14.1 utilizam o JNDI (Java Naming and Directory Interface) para registrar configurações, mensagens de log e parâmetros, mas mensagens de log com parâmetros específicos podem executar o código recebido a partir de outros endpoints com o JNDI ativo, via LDAP, quando a resolução de nomes das mensagens estiver habilitada. A partir da versão Log4j 2.15.0 esse comportamento é desabilitado or default.
OBS: Conforme explicado no CVE-2021-45046, divulgado em 14/12, somente a versão 2.16.0 do Log4j 2 mitiga corretamente essa vulnerabilidade. Veja a transcrição parcial do CVE sobre isso: "It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack".
OBS 2: Devido a uma nova vulnerabilidade, a CVE-2021-45105 (publicado em 18/12) que causa recursão infinita no processo de resolução (lookup), é necessário fazer o upgrade para a versão 2.17.0 (veja aqui a página de download da versão mais recente).
OBS 3: Em 28/12 foi divulgado o CVE-2021-44832 e lançada a versão 2.17.1.
OBS 4: Não custa lembrar que as versões 1.x do Log4j não são mais suportadas desde 05/08/2015, quando foi anunciado seu "end-of'life".
OBS 5: Eu não dei destaque aqui no blog, mas vale a pena lembrar que em 14/12 foi divulgada também uma vulnerabilidade de RCE na versão 1.2 do Log4j, a CVE-2021-4104.
Segundo o NIST, essa vulnerabilidade CVE-2021-44228 tem um Score CVSS nota 10.0 (o máximo possível), calculada com base nesses atributos: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H". Em termos leigos, isso é o equivalente a dizer "Corram, fujam para as montanhas!".
A vulnerabilidade da versão 2.15.0 no Log4j 2, o CVE-2021-45046 tinha originalmente um score CVSS de 3.7 (baixo), mas em 17/12 descobriu-se que ela poderia causar um RCE, e o score subiu para 9.0.
A versão 2.16.0, lançada em 13/12, também tinha uma vulnerabilidade, que causava recursão infinita no lookup, o CVE-2021-45105, com score CVSS de 7,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Em 28/12 foi divulgado mais uma vulnerabilidade o CVE-2021-44832 com CVSS score de 6,6 (médio). Nesse caso, o Log4j até a versão 2.17.0 (exceto 2.3.2. e 2.12.4) é vulnerável a um RCE quando o atacante tem permissão de modificar o arquivo de configuração local e incluir um parâmetro malicioso chamando uma URI JNDI para executar o código remoto.
Parece que tivemos muitas atualizações em pouco tempo, não é? Sim, tivemos! Nos últimos anos, em geral o Log4j teve no máximo 4 atualizações por ano! Por causa do Log4Shell, foram lançadas 3 versões novas em praticamente uma semana !!!
Além de ser uma vulnerabilidade muito fácil de reproduzir, o principal problema do Log4Shell é que a biblioteca Log4j 2 é muito utilizada por muita gente, desenvolvedores e fabricantes dos mais diversos produtos e soluções.
Essa vulnerabilidade foi descoberta no final de Novembro, reportada para a Apache em 24/11, que já começou a trabalhar em uma correção. Apesar da primeira correção ter sido liberada em 06/12 e do CVE ter se tornado público em 10/12, a Cloudflare e a CISCO identificaram as primeiras explorações da Log4Shell em 01 e 02/12, respectivamente.
O diagrama abaixo, criado pelo CERT da Suiça, mostra como a vulnerabilidade pode ser explorada:
A string para explorar a vulnerabilidade ficou bem conhecida, rapidamente:
O atacante tem que fazer uma requisição ao servidor que vai ser atacado e que possa gerar uma entrada no log, através da biblioteca Log4j 2. Graças a vulnerabilidade, o componente JNDI (Java Naming and Directory Interface) vai fazer uma requisição ao site indicado na string, executando o payload que baixar dele. A string acima contém o comando “jndi”, que indica a chamada ao Java Naming and Directory Interface, seguido pela indicação do protocolo a ser utilizado, como “ldap”, “ldaps”, “rmi”, “dns”, “iiop”, ou “http”, indicando que requisição deve ser feita ao endereço do site controlado pelo atacante.
Como identificar a vulnerabilidade:
- O CERT/CC lançou um scanner para a vulnerabilidade do Log4j: https://github.com/CERTCC/CVE-2021-44228_scanner
- A Trend Micro criou uma página para testar se o seu servidor está vulnerável: https://log4j-tester.trendmicro.com
- Indicadores de comprometimento (IOCs):
E agora, o que fazer? Tem duas ótimas referências sobre isso, do NCSC e do CIS. O National Cyber Security Centre (NCSC, do Reino Unido) deu um passo-a-passo muito objetivo e útil, que vale a leitura. Resumidamente:
- Instale o update mais recente (a versão 2.17.1) em todos os lugares que você sabe que o Log4j é usado, tanto os servidores expostos na Internet quanto os servidores internos na organização;
- Comece a procurar por todas as instâncias e usos desconhecidos do Log4j em sua empresa. Suas aplicações em Java podem incluir a biblioteca do Log4j. A NCSC sugere alguns comandos para ajudar nessa busca:
- Procure no seu filesystem:
find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null - Veja nos seus pacotes:
dpkg -l | grep log4j - No Windows, eles sugerem esse comando no Powershell:
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path - Ajustes suas ferramentas de monitoramento, detecção e bloqueio.
O pessoal do Center for Internet Security (CIS) criou um guia bem completo sobre as vulnerabilidades no Log4j e como corrigir. Vale muito a pena a leitura. Veja o diagrama que eles criaram para orientar as empresas sobre como agir nesse momento:
Como evitar a vulnerabilidade do Log4Shell:
- Antes de mais nada: bloquear as conexões de saída para a Internet a partir dos seus servidores, exceto quando for realmente necessário e atualize suas ferramentas de segurança para identificar e bloquear ataques que explorem essa vulnerabilidade;
- Fazer o upgrade imediatamente para a versão
2.15.0-rc-2 ou posterioratual, a versão 2.17.1; - Lembre-se que pode ser necessário atualizar algumas dependências para realizar o upgrade;
- Caso não seja possível fazer o update, há algumas formas de mitigar a falha, mas segundo o CVE-2021-45046, essas recomendações não conseguem impedir algumas formas de ataque. Logo, a melhor solução é mesmo fazer o upgrade para a versão 2.17.1.
- Nas versões acima de 2.10, ajuste o parâmetro log4j2.formatMsgNoLookups para true; (veja o CVE-2021-45046 para cuidados adicionais, indicado abaixo no 4o bullet)
- Nas versões 2.0 até 2.10.0, você deve remover a classe LDAP do Log4j executando esse comando: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Segundo o CVE-2021-45046, nas versões anteriores a 2.16.0 também é necessário remover a classe JndiLookup do classpath (por exemplo: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
OBS 1: Ao contrário do que diz o meme acima, eu vi um site aonde diz que aparentemente já existe uma forma de explorar a vulnerabilidade na versão 1 do Log4j.
OBS 2: Descobriu-se que mesmo a versão 2.15.0 é vulnerável e pode causar um ataque de DoS. Também que pode ser usada para exfiltração de dados e, o que é pior, também está vulnerável a ataque de Remote Code Execution (RCE). Portanto, a recomendação inicial de atualizar para a versão 2.15.0-rc-2 não é suficiente. Por isso, a única solução é atualizar o seu Log4j 2 para a nova versão 2.16.0, conforme descrito no CVE-2021-45046. Como a versão 2.16.0 também tem uma vulnerabilidade, que permite a negação do serviço através de uma string que força o processo de resolução entrar em loop, e a versão 2.17.0 tem uma vulnerabilidade que pode permitir a execução remota de código, a única solução é atualizar o seu Log4j 2 para a nova versão 2.17.1.
OBS 3: A Cyberreason criou o Logout4Shell, para explorar a vulnerabilidade do Log4Shell para corrigí-la! (eu achei interessante citar essa iniciativa, mas sugiro que seja avaliado com cuidado antes de usar)
As vulnerabilidades que permitem a execução remota de código ("remote code execution" ou RCE, em inglês) são o sonho dos atacantes e pesadelo dos profissionais de segurança. Elas permitem que um atacante rode comandos na máquina de destino, alvo do ciber ataque, causando o seu comprometimento rapidamente.
Segundo a HackerOne, até 16/12 eles já tinham recebido 1.350 reports da vulnerabilidade do Log4j 2 nos programas de bug bounty (veja o gráfico abaixo). Até então, 75 reports tinham sido confirmados e resultaram no pagamento de, ao todo, USD 142.250 em recompensas (média de $1.896 pago por report).
De fato, algumas empresas começaram a incluir explicitamente a Log4Shell em seus programas de bug bounty.
Além do mais, essa vulnerabilidade pode ser explorada em servidores de produção de diversas formas, praticamente em qualquer tipo de entrada de dados. Como, por exemplo, inseridas na informação de user-agente para explorar um servidor web, inserindo a string no campo de assunto (subject) de um e-mail, etc.
Esse foi mais um bom motivo para a galera perder a sexta-feira e o final de semana corrigindo esse problema :(
Como nada que é ruim pode piorar mais um pouco, em 14/12 já surgiram relatos de operadores de ransomware explorando a vulnerabilidade do Log4j 2.
Para piorar, em 15/12 surgiu um relato sobre uma forma para bypassar a proteção contra o Log4Shell no WAF da AWS:
E, na sexta-feira 17/12, uma semana após a divulgação da vulnerabilidade do Log4j, ficamos sabendo que o problema na versão 2.15.0 era mais grave do que imaginado inicialmente (permitindo vazamento de dados, execução de código remota e localmente), e surgiram rumores de que a versão 2.16.0 ainda permite exploração (*)! De fato, esses rumores foram confirmados, e segundo a página de segurança do Log4j, essa vulnerabilidade foi batizada de CVE-2021-45105 e deu origem a versão 2.17.0.
(*) Esse problema está descrito em um report de bug no Jira da Apache, indicando que algumas strings podem provocar uma recursão infinita no processo de resolução do Log4j.
Ou seja, ao que tudo indica, essa treta ainda não acabou e temos que torcer para que lancem uma nova versão ASAP.
Praticamente 10 dias após a disponibilização da versão 2.17.0, foi lançada uma nova versão, 2.17.1 corrigindo um caso específico que pode causar um RCE, conforme descrito no CVE-2021-44832.
Quer acompanhar o andamento dessa treta? Veja o Live Log4J worldwide threat tracker da CrowdSec:
Por fim, o pessoal do SANS Institute fez uma live para discutir a vulnerabilidade Log4Shell, disponível no YouTube:
Resumindo, esse final de ano não está nem um pouco fácil para os times de segurança, que tiveram que encarar 4 vulnerabilidades e 4 atualizações distintas no Log4j 2.
Para concluir...
- 24/11: A vulnerabilidade Log4Shell é descoberta pelo Chen Zhaojun do Alibaba Cloud Security Team e reportada para a Apache
- 26/11: Reservado o CVE-2021-44228 pela Apache
- 01/12: Primeiras explorações da Log4Shell identificadas pela Cloudflare
- 02/12: A CISCO também identifica explorações da Log4Shell
- 06/12: Lançada a versão 2.15.0 do Log4j
- 09/12: Foi divulgado um exploit 0-Day para a vulnerabilidade do Log4j. O artigo do LunaSec é uma das primeiras referências sobre o assunto.
- 10/12: Publicado o CVE-2021-44228 (CVSS score de 10.0 / Crítico)
- 13/12: Lançada a versão 2.16.0 do Log4j
- 13/12: Segundo a Bitdefender, várias botnets estão explorando o Log4Shell desde 10/12;
- 14/12: Publicado o CVE-2021-45046 (CVSS score de 3.7 / Moderado)
- 14/12: Divulgado uma RCE na versão 1.2 do Log4j: CVE-2021-4104 (CVSS score de 7,5 / Alto)
- 15/12: Segundo a Microsoft identificou que servidores Minecraft estão sendo invadidos pelo ransomware Khonsari, através do Log4Shell
- 17/12: Revisada a criticidade do CVE-2021-45046 (CVSS score de 9.0 / Crítico)
- 17/12: Descoberto que o Ransomwae Conti também explora o Log4Shell
- 18/12: Lançada a versão 2.17.0 do Log4j
- 18/12: Publicado o CVE-2021-45105 (CVSS score de 7,5 / Alto)
- 20/12: O Ransomware Dridex também está explorando a vul no Log4J
- 28/12: Divulgado o CVE-2021-44832 (CVSS score de 6,6 / Médio)
- 28/12: Lançada a versão 2.17.1
Veja também uma pequena coletânea com algumas estatísticas e estimativas relacionadas a vulnerabilidade do Log4j 2 (adicionado em 20/12):
- 35.863 pacotes Java foram impactados (Google);
- mais de 800 mil ataques foram identificados nas primeiras 72 horas (Checkpoint);
- Mais de 60% das redes corporativas no Brasil foram atingidas pela falha (Checkpoint);
- 1.350 reports da vulnerabilidade do Log4j 2 recebidos nos programas de bug bounty da HackerOne até 16/12 (HackerOne).
- 154.098 tentativas de ataque por meio da vulnerabilidade Log4J de 9 de dezembro a 24 de Janeiro de 2022 (Kaspersky)
- 52% dos profissionais gastaram semanas ou mais de um mês para aplicar as correções do Log4j, e 48% tiveram que trabalhar em feriados e finais de semana ((ISC)2)
Hum, você está sem tempo de ler muitas referências? Não tem problema, foque nesses sites aqui:
- Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild
- Alert: Apache Log4j vulnerability (CVE-2021-44228) (NCSC)
- Ótimo material do CIS: Log4j Zero-Day Vulnerability Response
- Artigo da Microsoft: Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation
- BlueTeam CheatSheet * Log4Shell*
- Log4Shell Initial Exploitation and Mitigation Recommendations
- Vulnerabilidade “Log4Shell” no Apache Log4j (artigo em Português)
- Lista bem completa de referências: Awesome Log4Shell
- A história se repete com o “Log4Shell”?
- Lista de softwares impactados: log4j-affected-db
- Alerta muito completo e detalhado lançado, em conjunto, pela CISA, FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC e NCSC-UK: Alert (AA21-356A) - Mitigating Log4Shell and Other Log4j-Related Vulnerabilities (CISA)
Para saber mais:
- CVE-2021-44228
- CVE-2021-45046
- CVE-2021-45105
- CVE-2021-44832
- CVE-2021-4104
- CVE-2021-44228 Detail (NIST)
- CVE-2021-45046 Detail (NIST)
- CVE-2021-44832 Detail (NIST)
- CVE-2021-4104 (NIST)
- Páginas oficiais do projeto Log4j 2:
- Página oficial, no site da Apache
- Apache Log4j Security Vulnerabilities
- Download das versões mais recentes
- Apache projects affected by log4j CVE-2021-44228
- Página do Log4Shell na Wikipedia (em inglês) (aqui, em Português)
- Material da CISA:
- Apache Log4j Vulnerability Guidance (CISA)
- Lista de softwares impactados: log4j-affected-db
- Scanner para o Log4Shell: log4j-scanner
- Alert (AA21-356A) - Mitigating Log4Shell and Other Log4j-Related Vulnerabilities
- Recomendações publicados pelo CTIR.gov:
- RECOMENDAÇÃO 12/2021 - 10/12/2021 - Atualização do Log4j (CTIR)
- RECOMENDAÇÃO 13/2021 - 14/12/2021 - Vulnerabilidade na biblioteca Log4j (atualização)
- RECOMENDAÇÃO 14/2021 - 17/12/2021 - Vulnerabilidade na biblioteca Log4j (atualização)
- RECOMENDAÇÃO 15/2021 - 17/12/2021 - Mitigação da vulnerabilidade do Apache Log4j para o VMWARE VCenter
- RECOMENDAÇÃO 16/2021 - 18/12/2021 - Vulnerabilidade na biblioteca Log4j (atualização)
- RECOMENDAÇÃO 18/2021 - 22/12/2021 - Vulnerabilidades na biblioteca Log4j (atualização)
- Log4j Zero-Day Vulnerability Response
- Zero-Day Exploit Targeting Popular Java Library Log4j (GovCERT.ch)
- Alert: Apache Log4j vulnerability (CVE-2021-44228) (NCSC)
- Lista bem completa de referências: Awesome Log4Shell
- Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package (LunaSec)
- Log4Shell Update: Severity Upgraded 3.7 -> 9.0 for Second log4j Vulnerability (CVE-2021-45046) (LunaSec)
- Post bem completo da CISCO: Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild
- Microsoft’s Response to CVE-2021-44228 Apache Log4j 2
- Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation (Microsoft)
- Update for Apache Log4j2 Issue (CVE-2021-44228) (AWS)
- Patch Now: Apache Log4j Vulnerability Called Log4Shell Actively Exploited (Trendmicro)
- Log4jShell: Entenda a Falha e Veja Como Se Proteger (Trendmicro)
- CVE-2021-44228 - Log4j RCE 0-day mitigation (Cloudflare)
- Log4j zero-day “Log4Shell” arrives just in time to ruin your weekend (MalwareBytes)
- Log4Shell Initial Exploitation and Mitigation Recommendations (Mandiant)
- Criaram uma lista com os Security Advisories por fabricante: BlueTeam CheatSheet * Log4Shell*
- Log4j Hunting & Indicators
- IOCs do Log4j 2 no ThreatFox Database
- log4j RCE Exploitation Detection
- Log4Shell Tools and Resources for Defenders - Continuously Updated
- Vídeo que viralizou com o POC da vulnerabilidade explorada num servidor Minecraft:
- How Do I Find My Servers With the Log4j Vulnerability?
- Para os fans do Burp Suite, já tem profile para testar o Log4Shell!
- First Log4Shell attacks spreading ransomware have been spotted
- Excelente artigo da iBliss, uma ótima referência em português: Vulnerabilidade “Log4Shell” no Apache Log4j
- Posts legais do pessoal da Kaspersky, mas estão desatualizados e não incluem a recomendação de migrar para a versão 2.16.0:
- Vulnerabilidade crítica na biblioteca Apache Log4j (Kaspersky)
- CVE-2021-44228 vulnerability in Apache Log4j library (Securelist)
- Posts relevantes no Sans Internet Storm Center (ISC):
- RCE in log4j, Log4Shell, or how things can get bad quickly
- Log4j / Log4Shell Followup: What we see and how to defend (and how to access our data)
- Log4Shell exploited to implant coin miners
- Log4j: Getting ready for the long haul (CVE-2021-44228)
- Log4j 2.15.0 and previously suggested mitigations may not be enough
- Brecha no log Log4j provoca um caos sem igual na Segurança da Informação
- Máquinas com Log4j-2 vulnerável se tornam alvo do dia
- Hackers varrem 40% das redes em busca de Log4J
- Hackers Exploit Log4j Vulnerability to Infect Computers with Khonsari Ransomware
- Não deixe de ver: log4jmemes.com
- Como funciona um ataque na vida real explorando o Log4j
- Log4j Vulnerability Activity on the HackerOne Platform
- CVE-2021-44228_scanner (CERT/CC)
- Hackers Begin Exploiting Second Log4j Vulnerability as a Third Flaw Emerges
- Log4j 2.15.0 stills allows for exfiltration of sensitive data
- The Log4J Vulnerability Will Haunt the Internet for Years
- Reflexão do professor Nelson Brito: A história se repete com o “Log4Shell”?
- Log4shell: vulnerabilidade crítica afeta biblioteca log4j (URGENTE) (Morphus Labs)
- Live Log4J worldwide threat tracker
- Apache Issues 3rd Patch to Fix New High-Severity Log4j Vulnerability
- Microsoft confirms new ransomware family deployed via Log4j vulnerability
- Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild
- CVE-2021-45105: Denial of Service via Uncontrolled Recursion in Log4j StrSubstitutor (Zero Day Initiative)
- New Local Attack Vector Expands the Attack Surface of Log4j Vulnerability - resumão dos CVEs
- Google: More than 35,000 Java packages impacted by Log4j vulnerabilities
- Conti ransomware group adopts Log4Shell exploit
- Log4J: falha atingiu mais de 60% das redes corporativas no Brasil
- A Detailed Guide on Log4J Penetration Testing
- Timelines do Log4Shell:
- timeline log4j - CVE-2019-17571 CVE-2021-4104 CVE-2021-44228 (log4shell) CVE-2021-45105 CVE-2021-45046
- Log4j vulnerability timeline: Patches, Log4shell Cyberattacks, and CISA status updates
- Artigos da Cloud Security Alliance (CSA):
- Dealing with log4shell aka CVE-2021-44228 aka the log4j version 2
- Keeping up with log4shell aka CVE-2021-44228 aka the log4j version 2
- How we ended up with #log4shell aka CVE-2021-44228
- O Security Zines criou um flyer:
- O Loïc Castel criou alguns mapas metais (mindamp) sobre o Log4Shell
- Log4j vulnerability now used to install Dridex banking malware
- Apache Log4j bug: China’s industry ministry pulls support from Alibaba Cloud for not reporting flaw to government first
- CISA releases Apache Log4j scanner to find vulnerable apps
- Artigo no meu perfil no LinkedIn: Timeline do Log4Shell
- Segurança da Informação: Mais de 800 mil ataques em 72 horas na brecha Log4j
- NASA Denies It Used the Doomed Log4j in Its Mars Ingenuity Helicopter
- Critical Log4j flaw exploited a week before disclosure
- Olha só a treta... Log4j: Belgian Defense Ministry Reports It Was 'Paralyzed'
- CISA, FBI and NSA Publish Joint Advisory and Scanner for Log4j Vulnerabilities (Alert AA21-356A)
- Exploitation of Log4j CVE-2021-44228 before public disclosure and evolution of evasion and exfiltration (Cloudflare)
- Chinese APT Hackers Used Log4Shell Exploit to Target Academic Institution
- Crypto Platform Suffers Log4j-Related Ransomware Attack
- Microsoft Warns of Continued Attacks Exploiting Apache Log4j Vulnerabilities
- Iranian Hackers Exploit Log4j Vulnerability to Deploy PowerShell Backdoor
- Night Sky Ransomware Distributed via Log4j Exploits
- How the Pentagon enlisted ethical hackers amid the Log4j crisis
- New Log4j attacks target SolarWinds, ZyXEL devices
- Exploração do Log4Shell: mais de 30 mil varreduras em janeiro
- (ISC)2 study finds long remediation times for Log4Shell
- Iranian Hackers Targeting VMware Horizon Log4j Flaws to Deploy Ransomware
- Log4Shell já responde por um terço das infecções por malware (NOVO)
- Chinese Hackers Target VMware Horizon Servers with Log4Shell to Deploy Rootkit (NOVO)
