How a forged login token gave attackers admin access to every computer an IT provider managed

The Context

SimpleHelp is a remote monitoring and management (RMM) platform used by MSPs and enterprise IT teams to remotely access, troubleshoot, and control computers. An MSP might use a single SimpleHelp server to manage hundreds of client organizations simultaneously. That architecture is what makes RMM tools so efficient and what makes them so dangerous when compromised: one server is the gateway to all of them.

SimpleHelp had already attracted ransomware operators in early 2025, when three separate vulnerabilities were exploited in the wild. By June 2026, the number of SimpleHelp servers exposed to the public internet had grown from roughly 3,400 to nearly 14,000, expanding the attack surface faster than security posture kept pace.

The Attack, Phase by Phase

Phase 1: The Forged Token

The attacker identified an internet-facing SimpleHelp server configured to accept logins through an external identity provider using OIDC. In a correctly implemented system, SimpleHelp would verify the token's cryptographic signature before trusting any identity claims inside it. SimpleHelp did not do this. The signature check was missing entirely.

The attacker crafted a fake token, inserted claims identifying themselves as a privileged administrator, and submitted it directly to SimpleHelp's login endpoint. The server accepted it and issued a fully authenticated technician session.

The MFA bypass compounded the problem. Because SimpleHelp allows new technician accounts to register their own MFA device on first login, the attacker simply enrolled their own authenticator during account creation. Organizations that believed MFA was protecting them were not protected.

Phase 2: Trusted Channel as Attack Rail

Once inside, the attacker used SimpleHelp's own legitimate file transfer and remote execution capabilities to deliver their payload. This is what makes RMM compromise so effective: the attack traffic is indistinguishable from normal administrative work.

The attacker downloaded TaskWeaver, a heavily obfuscated loader written in Node.js and disguised as jquery.js, fetched from a temporary Cloudflare domain. TaskWeaver profiled the compromised host and established an encrypted command-and-control channel designed to look like Microsoft Dev Tunnels traffic. It then retrieved the second-stage payload: Djinn Stealer.

Phase 3: Developer Secret Harvesting

Djinn Stealer runs on Windows, macOS, and Linux. It performs a single-pass sweep of user home directories, collecting credentials from a broad target list: cloud provider keys (AWS, Azure, Google Cloud, Oracle Cloud, Okta, Cloudflare, DigitalOcean), source control tokens (GitHub, Git config, SSH keys), infrastructure-as-code tools (Terraform, Pulumi, HashiCorp Vault), package registry credentials (npm, PyPI, NuGet, Cargo, Maven), Docker and Helm authentication, and cryptocurrency wallets.

Djinn Stealer also targets AI development tool configurations, including local config files for Claude, Gemini, Codex, and other AI coding assistants. These files contain tokens that grant the AI agent access to source repositories, databases, cloud accounts, and internal APIs. Stealing them gives the attacker the same access the developer granted to their AI agent, without needing to compromise the AI service itself.

All collected data is packed into a TAR archive, compressed, encrypted with AES-256-GCM, and sent to attacker-controlled infrastructure.

Phase 4: Persistent Re-entry via Stolen Credentials

Patching SimpleHelp and isolating the compromised endpoint does not end the attacker's access. The harvested credentials—cloud keys, package publishing tokens, source-control sessions, SSH keys, and AI integration tokens—all remain valid. The attacker can re-enter through any of those trusted services without redeploying malware.

For MSP-hosted SimpleHelp instances, the blast radius extends further. A single compromised server may expose every downstream client the MSP manages. Blackpoint Cyber warned that the most damaging outcomes may arrive after the original endpoint is isolated, because stolen credentials operate independently of the RMM server that delivered them.

What Made This Possible

1. The signature check was skipped. SimpleHelp's OIDC callback handler accepted identity tokens without verifying the cryptographic signature that proves they came from a trusted provider. Delegating authentication to an external provider does not transfer the responsibility to verify the proof that provider issues. The application must still do that check independently.

2. MFA was self-defeating by design. Allowing new accounts to register their own MFA device on first login means MFA cannot protect against account creation. The control assumed the account was already legitimate before it applied.

3. RMM architecture is a force multiplier for attackers. A single authentication failure on an RMM server does not compromise one machine—it compromises every machine the platform manages, and for MSPs, every client organization simultaneously. The same efficiency that makes RMM tools valuable makes them catastrophic single points of failure.

What Should Have Stopped This

• Network segmentation for the RMM server. Placing SimpleHelp behind a VPN or restricting internet exposure would have removed it from the pool of approximately 14,000 publicly scannable targets. Attackers conducted opportunistic scans, not targeted operations. Removing the server from public view removes it from scan results.
• Monitoring for unexpected technician account creation. An alert on first-time account creation from an unknown IP would have flagged the rogue session before payload delivery. SimpleHelp itself advises administrators to watch for exactly this.
• Credential rotation as a post-patch requirement. Patching closes the entry point but does not revoke already-stolen credentials. Any organization that ran a vulnerable server should treat all secrets on managed machines as compromised and rotate them, regardless of whether active exploitation was confirmed.
• Restricting OIDC group-authenticated logins. The three configuration prerequisites for exploitation—OIDC enabled, a TechnicianGroup associated with the OIDC provider, and "Allow group authenticated logins" enabled—are all administrator-controlled. Disabling the last setting removes exploitability even on unpatched servers.

The Takeaway

This attack is the same class of failure as the Stryker Intune wipe: a privileged management tool weaponized against the organization it was built to protect. In the Stryker case, compromised credentials turned a device management platform into a mass-wipe tool. Here, a forged token turned a remote access platform into a credential harvesting rail. When the management layer is compromised, every system it touches is compromised simultaneously, and the attacker inherits the same trusted access the tool was designed to provide.

The Djinn Stealer's targeting of AI agent configuration files adds a new dimension. As developers grant AI coding assistants access to production infrastructure and cloud tenants, those agent credentials become as valuable as the infrastructure itself. Stealing them does not require compromising the AI service—it requires compromising the developer's machine, which is exactly what an RMM breach provides.

Pattern to remember: Delegating authentication to a trusted identity provider does not transfer the responsibility to verify the proof that provider issues. The application must independently check the cryptographic signature, or the entire trust model collapses at the point where the check was skipped.

What changed: AI agent credentials have become a new class of master key. Stealing the configuration file that authorizes an AI coding assistant grants the attacker the same delegated access the developer extended to the agent—reaching cloud accounts, source repositories, and internal APIs without touching the AI service itself.

The Technical Mechanism

CVE-2026-48558 is an authentication bypass in SimpleHelp's OpenID Connect (OIDC) callback handler. The root cause is the complete absence of JSON Web Token (JWT) signature verification during the OIDC authentication flow.

In a correctly implemented OIDC relying party, the application must:

1. Receive the identity token (JWT) from the identity provider's callback
2. Fetch the identity provider's public key from its JWKS (JSON Web Key Set) endpoint
3. Cryptographically verify the JWT signature against that public key
4. Only then accept the identity claims (subject, groups, email) contained in the token payload

SimpleHelp's OIDC callback handler performs step 1 and step 4 but skips steps 2 and 3 entirely. The server parses the JWT payload and acts on the identity claims without verifying that the token was signed by a trusted identity provider.

An unauthenticated attacker can construct a JWT with an arbitrary payload, including a groups claim mapping to a configured TechnicianGroup, and POST it directly to the OIDC callback endpoint. The server issues a fully authenticated technician session in response.

MFA bypass mechanism: SimpleHelp's MFA enforcement applies to existing accounts at login time. For new accounts, the platform allows first-login MFA self-registration, where the technician enrolls their own authenticator device. Because the forged token creates a new technician account, the attacker reaches the self-registration flow before MFA enforcement applies, enrolling their own device and satisfying the MFA requirement for all subsequent logins.

Exploitation prerequisites (all three must be present):

• OIDC authentication enabled on the SimpleHelp server
• A TechnicianGroup associated with the OIDC provider configuration
• "Allow group authenticated logins" enabled on that group

Horizon3.ai found the second and third conditions common in assessed customer deployments. The flaw affects both generic OIDC and Azure AD OIDC integrations.

CWE classification: CWE-347 (Improper Verification of Cryptographic Signature).

CVSS score: 10.0 (Critical).

Patched versions: SimpleHelp v5.5.16 (stable) and v6.0 RC2 (pre-release), released May 26, 2026.

TaskWeaver and Djinn Stealer technical linkage: TaskWeaver is a Node.js loader that implements an encrypted, reusable payload delivery channel. It uses a custom obfuscation framework and embeds an RSA-2048 public key to protect the AES-256-GCM encrypted payload channel. Djinn Stealer reuses the identical obfuscation framework and embeds the same RSA-2048 public key, cryptographically linking the two tools to a common developer or operation. TaskWeaver's C2 masquerades as Microsoft Dev Tunnels traffic; the exfiltration user agent is crafted to resemble Microsoft telemetry.

CVE and Advisories

• CVE-2026-48558: SimpleHelp OIDC authentication bypass via missing JWT signature verification. CVSS 10.0 (Critical).
• SimpleHelp Security Update 2026-05: Vendor advisory confirming the vulnerability and patched versions.
• CISA KEV Catalog Entry, June 29, 2026: Added under BOD 26-04 with a July 7, 2026 federal patch deadline and mandatory forensic triage requirement.

MITRE ATT&CK Mapping

Indicators of Compromise

SimpleHelp advises administrators to review server logs for the following:

• Unexpected technician account creation events, particularly from IP addresses not associated with known staff
• New technician logins from unrecognized IP addresses or geographic locations
• Unexpected remote sessions initiated from newly created accounts
• Tool execution or file transfer activity from accounts with no prior history

Network Indicators

C2 traffic masquerading as Microsoft Dev Tunnels (devtunnels.ms domains). Exfiltration user agent strings crafted to resemble Microsoft telemetry. Initial TaskWeaver download from temporary Cloudflare-hosted domains.

File Indicators

jquery.js (TaskWeaver loader) present in unexpected directories on managed endpoints. Node.js process execution in contexts where it would not normally appear.

Detection difficulty: Because the attacker operates through SimpleHelp's own trusted administrative channel using a legitimate technician session, network-level detection is unreliable. Log-based detection of anomalous account creation is the most reliable signal. Blackpoint Cyber's APG noted that the campaign was assessed as opportunistic, suggesting additional undetected victims are likely.

Attribution

Unattributed. Blackpoint Cyber's threat intelligence engineer Sam Decker stated the company could not attribute the intrusion to a specific threat actor and assessed the campaign as opportunistic scanning for exposed vulnerable instances rather than targeted operations. Decker described the operation as reflecting "a capable, deliberate operation focused on discovering and collecting high value secrets." CISA has not attributed the activity to a specific nation-state group. A lower-tier source (Windows News) reported that CISA's analysis tentatively linked the activity to initial access broker tradecraft with overlapping techniques observed in campaigns feeding Black Basta and LockBit ransomware affiliates; this claim has not been confirmed by any Tier 1 source and should be treated as unverified.

Primary Sources