Slim Spider is a financially motivated threat actor that has targeted Brazilian financial institutions since at least March 2026. In one intrusion observed in late March, the group reportedly extracted temporary cloud credentials through instance metadata, searched a cloud credential manager for secrets, and exfiltrated digital asset custody material.
The attackers later used Azure DevOps pipelines to deploy implants across a managed Kubernetes environment. The campaign shows how cloud identities, CI/CD automation, and crypto custody secrets can form one connected attack path.
Organizations should restrict metadata access, reduce pipeline permissions, replace long-lived credentials with managed identities, and monitor cloud and DevOps activity. Hexnode UEM and Hexnode XDR can complement these controls by strengthening device posture and helping security teams investigate and contain suspicious activity on managed endpoints.
Introduction
A compromised cloud identity can expose far more than one application or server.
In late March 2026, Slim Spider reportedly breached a Brazilian financial institution and targeted its cryptocurrency assets and instant payment accounts. The attackers used custom scripts to obtain temporary cloud credentials, extract crypto custody secrets, and expand their access through cloud containers and Azure DevOps.
The incident demonstrates how a cloud metadata attack can progress from stolen workload credentials to sensitive financial infrastructure. It also shows how securing endpoints, cloud identities, secret stores, and DevOps pipelines separately creates risk.
❓ Who is Slim Spider?
Slim Spider is a financially motivated cybercrime group that has targeted Brazilian financial institutions since at least March 2026. The activity cluster appears to operate from Brazil and shows detailed knowledge of the country’s financial infrastructure, including Pix, digital asset platforms, and financial-sector cloud environments.
The group’s objective is financial gain. Its known tooling includes MikeDor, a custom cross-compiled backdoor written in Go that can collect information and monitor activity on compromised systems.
Researchers have not publicly verified any aliases for Slim Spider. Although other criminal groups also target Brazilian payment systems, researchers should not link them to the same operation without evidence connecting their infrastructure or operators. CrowdStrike’s adversary profile identifies Slim Spider as a distinct eCrime actor.
What happened?
The observed intrusion combined cloud credential theft, secret discovery, container access, and Azure DevOps pipeline abuse.
Attack detail
Observed activity
Time period
Slim Spider has targeted Brazilian financial institutions since at least March 2026. The detailed intrusion occurred in late March 2026.
Target
A Brazilian financial institution and its cryptocurrency assets and instant payment accounts.
Initial access
The publicly available reporting does not specify how the attackers first entered the organization.
Cloud metadata attack
Custom Bash scripts queried cloud instance metadata over socket connections to obtain temporary cloud credentials.
Secret discovery
After accessing the cloud environment, the attackers enumerated secrets stored in the organization’s cloud credential manager.
Crypto custody impact
The attackers exfiltrated digital asset custody secrets, including a private key. They used the cast utility from the Foundry Ethereum toolkit to derive the wallet address associated with that key.
Cryptographic activity
The malicious Bash scripts used OpenSSL to perform cryptographic signing without relying on additional third-party libraries.
Container access
Slim Spider established access to nodes in a managed cloud container cluster.
Persistence and concealment
Backdoors were deployed with names resembling legitimate infrastructure binaries. The exact persistence mechanisms were not publicly detailed.
Azure DevOps abuse
The attackers likely used compromised credentials to run malicious Azure DevOps pipelines and deploy implants across a managed Kubernetes cluster.
Deception
One implant was named spi, apparently to resemble SPI, the infrastructure supporting Brazil’s Pix payment system. This was camouflage, not a confirmed false-flag operation.
MFA impact
No MFA bypass, interception, or manipulation method was disclosed.
Social engineering
No social engineering technique was identified in the reported intrusion.
Ransomware or extortion
No ransomware deployment, encryption, or extortion attempt was reported.
The case confirms that attackers exfiltrated digital asset custody material. However, public reports do not confirm whether they used the stolen private key to transfer cryptocurrency or successfully moved funds from the institution’s Pix accounts.
Separate infrastructure associated with Slim Spider included panels for scanning financial APIs, searching compromised Microsoft 365 mailboxes, and processing unauthorized Pix transfers. An exposed command-and-control panel also displayed hosts associated with multiple Brazilian banks and fintech organizations. These findings indicate broader targeting, but they do not confirm that every displayed organization suffered financial theft. The disclosed campaign details support this distinction.
User sentiment: Why listening to employees is key for DEX
Combine employee sentiment with telemetry to uncover hidden friction and improve digital experiences.
Why this matters
Crypto custody security depends on more than protecting a wallet application. Private keys, signing services, deployment pipelines, workload identities, secret managers, and administrator devices can all influence who controls a transaction.
Temporary cloud credentials also remain powerful until they expire. If a workload can request credentials from an instance metadata service, an attacker who gains execution in that workload may be able to request the same credentials. Excessive permissions can then turn a single compromised identity into access across secret stores, containers, and deployment systems.
Traditional endpoint controls alone cannot cover this path. Financial institutions need coordinated visibility across endpoints, cloud audit logs, identity events, Kubernetes activity, and CI/CD pipelines. They should also restrict metadata access, apply least privilege to workload identities, protect pipeline changes, and require strong approval controls for custody-related operations.
How Hexnode can help
Hexnode UEM: Strengthen devices used for privileged access
Hexnode UEM can help organizations establish a consistent security baseline for managed devices used by developers, administrators, and financial operations teams.
IT teams can enforce password and encryption policies, manage OS and application updates, distribute approved applications, and blocklist or allowlist software on supported platforms. These controls reduce the likelihood that an unmanaged application, outdated endpoint, or weak configuration becomes an entry point for cloud credential theft.
Organizations should apply these UEM baseline checks to workstations used by engineers who configure Azure DevOps projects and CI/CD pipelines. Hardening these privileged endpoints helps prevent attackers from harvesting Azure DevOps credentials, access tokens, and pipeline secrets at the source.
Hexnode can also provide device compliance data to Microsoft Entra ID for Conditional Access on Android, iOS, and macOS 11 or later. Where Azure DevOps and the applicable Conditional Access policy support device-based controls, organizations can require users to access Azure DevOps resources from enrolled, compliant devices. Where the target resource and access policy support it, organizations can require an enrolled, compliant device before granting access. This capability does not currently extend Hexnode compliance reporting to Windows or Linux devices. Hexnode’s Conditional Access documentation defines this platform scope.
Hexnode XDR: Investigate and contain endpoint activity
Hexnode XDR can provide security teams with visibility into threats and endpoint activity across managed Windows and macOS environments. This is relevant when attackers use an administrator or developer workstation to obtain credentials, run malicious processes, or prepare access to cloud and DevOps systems.
Teams can use endpoint telemetry and threat-hunting queries to investigate suspicious behavior. Response actions include isolating an affected device, terminating a malicious process, quarantining a file, and running a deep scan.
While Hexnode XDR secures Windows and macOS administrator workstations where cloud credentials or repository keys might originate, it does not extend to Linux container nodes or cloud-native runtimes. Cloud workload protection platforms (CWPPs) and cloud audit logging remain essential for container-level detection and response.
Hexnode XDR should complement cloud-native monitoring rather than replace it. Azure DevOps audit logs, cloud identity events, secret-manager access logs, and Kubernetes telemetry remain necessary for detecting activity that occurs directly within those services.
Feature Resource
Hexnode Quick Start Guide: How to set up Hexnode for your business
Gain valuable insights into how you can set up Hexnode UEM for your business.
Slim Spider demonstrates how attackers can move through the same cloud and automation services that financial institutions use for legitimate operations. In this case, temporary cloud credentials provided access to secrets, container infrastructure, and Azure DevOps pipelines connected to high-value financial systems.
Security teams should restrict access to instance metadata, scope workload identities to the minimum required permissions, and monitor all secret retrieval. Azure DevOps service connections and pipeline changes should require limited roles, protected branches, independent approvals, and detailed audit logging. Crypto custody operations should also separate key access, transaction creation, and transaction approval.
Hexnode UEM can strengthen the devices used to access these environments, while Hexnode XDR can support endpoint investigation and containment on Windows and macOS. These controls must operate alongside cloud, Kubernetes, DevOps, and custody-specific security measures.
Start by identifying every endpoint, identity, pipeline, and workload that can reach a custody secret—and remove any access that is not operationally necessary.
Try Hexnode Free for 14 Days
Sign up for Hexnode to strengthen endpoint security and reduce credential-based attack risks.
I’m a technical content writer at Hexnode who loves simplifying tech. I break down complex ideas, remove the fluff, and help readers clearly understand our product for what it actually is: simple, reliable, and built to solve real problems.
