Nimbus RAT: How Threat Actors Are Abusing Microsoft Teams and Google Drive to Deploy a Java RAT

What did we find?

In early April 2026, eSentire's Threat Response Unit (TRU) identified an intrusion targeting a customer in the legal industry. Threat actors used Microsoft Teams voice phishing (vishing) to deceive the victim into granting remote access via Quick Assist, then deployed a Java-based remote access trojan (RAT).

TRU tracks this malware as Nimbus RAT, which Rapid7 previously documented in connection with BlackSuit affiliate activity following Black Basta's internal conflict in early 2025. Nimbus RAT is a self-contained implant that uses Google Drive and Google Sheets for command-and-control (C2), helping its network traffic appear benign.

The intrusion followed a well-established vishing kill chain: the targeted user's mailbox was flooded with hundreds of subscription confirmation emails; an actor-controlled Microsoft Teams account posing as IT helpdesk reached out to the user offering assistance, and the user was walked through launching Quick Assist and downloading a payload from a compromised Microsoft 365 tenant. From initial Teams contact to RAT execution, the attack took less than 20 minutes.

TRU also analyzed over a year's worth of external Teams messaging telemetry across our customer base and identified 1,540 similar events targeting 172 distinct customer environments, with a sharp surge in activity between December 2025 and March 2026.

The data reveals consistent infrastructure patterns, including the heavy use of throwaway Microsoft 365 tenants, freshly registered .top domains, and hosting-provider source IPs, that help defenders distinguish malicious Teams external messages from legitimate vendor traffic.

Initial Access

In recent months, TRU has observed a sharp uptick in adversaries abusing using the intrusion pattern: mailbox bombing, Microsoft Teams vishing, Quick Assist (or another remote support tool), then hands-on-keyboard activity. The case behind this TRU Positive followed exactly that sequence and ultimately led to the deployment of Nimbus RAT, covered in the Analysis section below.

To better understand how prevalent and structured this Teams-based initial access vector has become, TRU pulled and enriched roughly one year's worth of external-Teams-message detections from our customer base. The dataset covers 1,540 detection events across 172 distinct customer environments from May 2025 to May 2026.

A Volume Surge in Early 2026

External Microsoft Teams messaging from suspicious tenants ran at a relatively steady rate through mid-to-late 2025 before climbing sharply at the end of the year. December 2025 through March 2026 accounted for roughly 57% of the full year's volume, with February 2026 alone generating 408 events – nearly 8x the monthly baseline.

This timing aligns with publicly reported Storm-1811 and 3AM ransomware activity, as well as broader Black Basta-derived crews continuing to lean on the Teams vector following the original Black Basta chat leaks.

Sender Accounts Impersonate IT and Helpdesk

Roughly 49% of sender accounts (758 of 1,540) used an email username designed to impersonate internal IT, helpdesk, or security functions. The most common patterns included helpdesk, helpdeskmanager, itsupport, it_assistance, it.support, admin, cloudsupport, and service.

A secondary cluster used plausible human names - such as michaelturner, danielfoster, and jamescollins, consistent with the second-stage persona an operator may adopt once the victim has engaged with the initial helpdesk outreach.

The Federation Brand Name displayed in Teams (what the targeted user actually sees) reinforced the same impersonation theme. Display names included IT Support, ITProtectionDepartment, infratechopsdesk, advcloudopshelp, operationshelpcenter, aispserviceopsdesk, and IT Trust LLC.

In at least one case, a phone-number string was used as the brand name to mimic a callback number in the Teams interface.

Throwaway Tenants Dominate Delivery

995 of 1,540 events (65%) originated from *.onmicrosoft.com sender domains – Microsoft's trial tenant domains, assigned at account creation and requiring no domain purchase or DNS setup.

TRU observed 235 unique throwaway tenants in the dataset. Many followed templated naming schemes that telegraphed the social-engineering pretext, including infratechopsdesk, advcloudopshelp, aispserviceopsdesk, helpsupportinfra, and itprotectiondepartment.

A recurring "scan" username family (e.g., scaninfratechops, scansupadvtcloudops, scanappsecopshelp) suggests a scanning or security-check pretext. Auto-generated teams00XXXX patterns (teams000977, teams002781) indicate bulk tenant creation.

The most reused throwaway tenants appeared across multiple distinct eSentire customer environments, with the highest-volume tenant reaching 10 separate customers. This level of reuse across unrelated organizations is strong evidence of shared actor infrastructure.

A Fast-Burning .top Domain Cluster

In parallel with the throwaway tenants, TRU observed a tightly scoped cluster of .top domains registered through PDR Ltd / PublicDomainRegistry, with most used to send Teams messages within 24 to 72 hours of domain registration. Among non-onmicrosoft.com sender domains with available WHOIS data, 37% were seven days old or less at the time of the attack.

Domain naming leaned on IT, helpdesk, and security pretexts - for example system-clean[.]top, helpdock[.]top, info-secure[.]top, serviceprohub[.]top, and a recurring "scan" family including scanseq[.]top, scan-security[.]top, and updt-scansecurity[.]top. Deliberate misspellings such as sequrityupdate and scansequrity are consistent with bulk registrations intended to evade keyword and reputation-based domain checks.

Sender Infrastructure is Overwhelmingly Hosted

Legitimate Microsoft Teams traffic typically originates from Microsoft's own IP space or corporate ISPs. In this dataset, 80% of events (1,229 of 1,540) originated from hosting and datacenter ASNs.

The same ASNs appeared repeatedly across unrelated customer environments: NKtelecom INC (US), WorkTitans B.V. (DE), GLOBAL CONNECTIVITY SOLUTIONS LLP (DE), GTHost (US), GWY IT PTY LTD (NL), M247 Europe SRL, IPTP LTD (SG), NovoServe B.V. (NL), tzulo inc., and Miranda-Media Ltd (UA).

66 unique source IPs appeared across two or more customer environments, with 6 IPs reaching 10 or more customers each. Additional anonymization flags were present in 221 events (VPN) and 74 events (TOR). The geographic distribution (US, DE, NL, RU, SG, FR, UA) reflects datacenter locations rather than operator locations.

Compromised Legitimate Tenants as a Higher-Trust Variant

A smaller subset of the activity originated from legitimate, long-established organizational tenants (including schools, small businesses, and NGOs) whose Microsoft 365 environments had been compromised and then abused to send external Microsoft Teams messages on the operator's behalf.

From the targeted user's perspective, these messages are more dangerous than throwaway-tenant variants: the sender tenant is real, the domain has years of registration history, and there is nothing visually suspicious in the Microsoft Teams external-user banner.

How the Access Plays Out

Once a target accepts the Teams chat or call, the social-engineering pattern is consistent: the helpdesk persona references the recent flood of spam in the user's inbox, offers to help clean it up, and walks the user into launching Quick Assist. Once a remote session is established, the operator deploys post-exploitation tool. In this incident, that tooling was Nimbus RAT.

Analysis

The incident behind this TRU Positive involved a customer in the legal industry. TRU reconstructed the full kill chain using Microsoft Defender for Endpoint process telemetry, browser download history, Microsoft 365 mail-flow records, and static analysis of the recovered Java archive. The attack progressed from email flooding to Quick Assist access and RAT execution in under 2 hours.

Stage 1: Inbox Flooding

Between 16:00 and 17:30 UTC on April 6, 2026, the mailbox received 282 emails in 90 minutes, peaking at 26 emails per minute. The emails originated from 116 unique sender domains and 98 unique sender IPs. Subjects appeared in English, German, Dutch, Spanish, Japanese, French, and Polish, and the email content mimicked legitimate subscription services, e-commerce platforms, government portals, and SaaS account-confirmation flows.

The senders were not spoofed, and the emails were not malicious on their own. They were legitimate transactional messages generated when the operator entered the victim's address into hundreds of public forms in rapid succession.

The goal is operational rather than technical: to overwhelm the inbox and create a credible pretext for the victim to accept "help" when "IT support" reaches out.

Stage 2: Microsoft Teams Vishing

At approximately 17:45 UTC, roughly 45 minutes after the email-bombing peak, a Teams external contact reached out to the targeted user. This timing is consistent with the broader pattern TRU observed across the dataset: email bombing creates the problem, then the vishing call arrives shortly after to offer the solution.

The sender in this incident used an external Teams account consistent with the helpdesk impersonation patterns described in the Initial Access section. From TRU's telemetry analysis, sender accounts in this campaign family use IT-themed email username and Federation Brand Names designed to appear as the target organization's own helpdesk.

The threat actor's pretext was consistent with the documented Black Basta-derived playbook. They referenced the inbox flooding the user had just experienced and offered "help" to resolve it.

At 17:48 UTC, the targeted user launched Quick Assist from Windows Explorer, confirming the vishing call successfully convinced the user to grant remote access to the threat actor(s). Within four minutes of the Quick Assist session being established, the threat actor(s) executed LOLBins for reconnaissance purposes via Command Prompt. This activity is shown in the process tree below.

Stage 3: The Pastebin Instruction Sheet

Rather than typing commands directly into the Quick Assist session, the threat actor pasted a URL into the Teams chat: pastebin[.]com/G6jA0PLU. The user visited the URL at 17:53 UTC, confirmed by analysis of the user's browser history.

Its contents were not a script, nor obfuscated code, but rather were a literal four-line instruction checklist:

• Line 1 is the payload download URL.
• Line 3 is the persistence path.
• Line 5 is the extraction directory.
• Line 7 is the archive name.

The Pastebin allows the threat actor to narrate instructions over the call while the user follows along on screen, rather than visibly typing commands into the remote-control window. From the victim's perspective the interaction looks indistinguishable from guided IT support.

Pastebin is broadly trusted and almost never blocked at the network layer. The human-readable format of the checklist also suggests the same document is reused across multiple vishing calls, where only the download URL changes per campaign.

Stage 4: Payload Retrieval from a Compromised Tenant

The Pastebin pointed to a ZIP archive named InboxCorePro.zip (SHA-256: 9E5B1E10AD6904D3F5B48D38470CD57263974640A27D13CF793EF026D3D6B886), hosted in the personal OneDrive of arturolopez@<REDACTED>[.]com on <REDACTED>-my[.]sharepoint.com. This is a compromised, legitimate Microsoft 365 tenant used as a payload staging point - the same pattern described in the Initial Access section for tenant-relay delivery.

TRU previously observed this same SharePoint URL hosting a different configuration of the same malware family in a separate incident. Reuse of the same compromised staging account across multiple campaigns, weeks apart, suggests it is part of the threat actor(s) established infrastructure.

The archive extracts to a single Java payload, InboxCorePro.jar (SHA-256: 91E523A46F3BB860AC2E5800B7E1EC89D75A2408410B9CD25EEBC17C8D7A92BC). Alongside the JAR file, the threat actor(s) pre-staged a registry import file (InboxCorePro.reg) and a bundled OpenJDK 25.0.1 runtime.

The bundled JDK enables payload portability across Windows hosts regardless of whether Java is installed and allows the malware to control exactly which runtime executes the JAR. The download was flagged by Netskope as potentially malicious but still completed.

Stage 5: Nimbus RAT - Execution and Initialization

The user followed the Pastebin instructions: extracted the archive to C:\ProgramData\InboxCorePro\, imported InboxCorePro.reg via regedit.exe, and placed a launcher in the Startup folder.

The parent process in every javaw.exe invocation is explorer.exe, confirming user-initiated execution consistent with the Startup folder shortcut. The javaw.exe binary is the legitimate Oracle-signed OpenJDK Platform 25.0.1 build (SHA-256: 99813F3D0625E880158C68039C0E2FBF488DB0BE3DB77CD1CE6D382644193F0E), all malicious logic is contained within the JAR.

TRU performed static analysis of InboxCorePro.jar. The decompiled output revealed eight custom malware packages, all named using randomized English words as a deliberate obfuscation technique: BlackStatelessness, DomitianUndrapedEpigrammatize, EpitaphDunderhead, ExtricableSophisticated, Goferindubitably, sententiousness, Splendrousstile, and WorldlySiege.

The remaining packages (com, io, javax, net, org) are bundled third-party dependencies including Google API client libraries, JNA, and Apache HttpClient. Figure 7 shows the decompiled package structure.

On launch, the malware entry point class Goferindubitably.Audiometric performs the following initialization steps:

• Creates a lock file at %TEMP%\java_app.lock to enforce single-instance execution.
• Registers a JVM shutdown hook to delete the lock file on exit.
• Verifies its embedded configuration blob using a hardcoded 4096-bit RSA public key. The config is signed by the operator with the corresponding private key, so the implant accepts only configurations the operator produced.
• Checks for the presence of license.txt in the JAR directory, if absent, it exits by calling System.exit(0). This file acts as a kill switch.
• Relaunches under javaw.exe (the windowless Java runtime) to suppress any visible console window.
• Enters the C2 polling loop, cycling through configured connections by priority.

The malware identifies itself internally as BackupBOX, with a campaign UUID of 1hc1his4gmto0q1 hardcoded in its configuration. All custom package and class names use randomized nonsense English words as a light obfuscation layer, e.g. Goferindubitably, SomewhatJerky, unrequitedlyWrathfulness, MutagenInchoateness. The JAR manifest declares the entry point as Goferindubitably.Audiometric.

Stage 6: Google-Based Command and Control

The most operationally significant characteristic of Nimbus RAT is its C2 channel. The malware uses Google Drive for command delivery and data exfiltration, making all network traffic appear as legitimate Google API calls. Three C2 channel types are implemented, selected, and prioritized from the decrypted configuration.

The Google Drive channels poll for a command file named entry_{campaignUUID} inside a configured Drive folder. Responses are written to exit_{campaignUUID}. Config updates are staged under the prefix newconfig_. The OAuth2 channel (Intervention) uses a DriveFactory that caches authenticated Drive instances in a ConcurrentHashMap and includes a Retryer with seven maximum attempts and exponential backoff with full jitter to handle Google API rate limiting transparently.

The direct TLS socket channel (phonemicsVandalism) disables certificate validation via a dummy X509TrustManager and communicates using length-prefixed RSA-encrypted byte messages. In this sample the socket channel was not configured, confirming Google Drive as the active C2 channel for this campaign.

A wakeup mode is confirmed: the threat actor can issue a command that decreases the polling interval from 45-75 seconds to 4-8 seconds across all active channels simultaneously for up to 10 minutes, allowing the threat actor to issue and receive commands with minimal delay during hands-on activity.

All C2 traffic is RSA-encrypted using a hardcoded 4096-bit public key embedded in the JAR. Large messages are split into fixed-size chunks and each chunk is processed through RSA independently. Commands sent to the implant are produced by the threat actor using the corresponding private key, ensuring the implant only processes configurations originating from the threat actor. Data sent by the implant is encrypted with the public key in fixed-size chunks, meaning only the threat actor holding the private key can decrypt the responses.

This C2 design is difficult to detect at the network layer. Blocking docs.google.com or googleapis.com is not viable in most environments where Google Workspace is in use.

Detection must rely on behavioral signals; for example, javaw.exe launching an unknown/suspicious JAR (i.e. not part of an approved Java application) and then making outbound requests to Google Drive API endpoints, or OAuth consent grants to an application named BackupBOX requesting Drive scopes in Google Workspace audit logs.

Nimbus RAT Capabilities

Once connected to the C2, the threat actor has the following confirmed capabilities, all dispatched through the command handler in Splendrousstile.SomewhatJerky with a 598-second command timeout:

The following table describes commands:

Credential Theft

Two distinct credential theft mechanisms are implemented and can be invoked independently:

• lf command (fake Swing dialog): Renders a Java Swing JFrame styled to resemble the native Windows Security credential prompt. Confirmed UI elements include the Windows Security title label, Sign in header, Enter your credentials prompt, a pre-populated username field in DOMAIN\username format, a password field, and a Remember my credentials checkbox. The dialog always collects two password attempts: the first submission triggers a fake Password is incorrect. Please try again. error while silently storing the input, and the second submission closes the dialog. Both attempts are returned to the threat actor. The dialog uses User32.AttachThreadInput and SetForegroundWindow to steal keyboard focus from the active window.
• cf command (native Windows credential prompt): Invokes the real Windows CredUIPromptForCredentialsW API directly via JNA binding to credui.dll. Confirmed dialog text: caption Login, message Enter your credentials. On first wrong entry, it calls MessageBoxA with Password is incorrect. Please try again.error code. It accepts one re-entry then closes. Auto-closes after approximately 10 minutes via User32.PostMessage(WM_CLOSE). Creates an invisible always-on-top JFrame to steal foreground window focus before invoking the native prompt.

In-Memory Second-Stage Code Execution

The jc and jcb commands implement a full in-memory Java plugin loader via DomitianUndrapedEpigrammatize.MutagenInchoateness. The threat actor sends Base64-encoded Java source code. Lines beginning with /// https:// at the top of the source identify dependency JAR URLs to download to %TEMP%\libs\ (reused on subsequent calls if already present).

The source is compiled using javax.tools.JavaCompiler with no files written to disk: compiled bytecode is captured in memory via a custom JavaClassObject, stored in a MemoryClassLoader backed by a HashMap, and the resulting class is instantiated via reflection by calling its start() method. jc blocks and returns the result; jcb runs in a background thread and returns immediately. This allows the operator to deploy arbitrary new capabilities post-compromise without dropping any files to disk.

Persistence

Nimbus RAT does not install persistence autonomously, rather it is a manual process invoked by the threat actor(s) using the previously described commands from the C2.

In this incident, the threat actor pre-staged persistence via the Pastebin checklist (Startup folder path) and the InboxCorePro.reg import. If the host is isolated before the threat actor issues persistence commands through C2, the infection does not survive a reboot.

However, the separation of persistence from the RAT binary also means persistence mechanisms can vary per campaign without modifying the JAR.

Attack Timeline

Post-Compromise: Second-Stage Tooling

TRU's enumeration of the threat actor's Google Drive infrastructure revealed evidence of a second-stage tool deployed after Nimbus RAT on at least one confirmed victim. A configuration file recovered from the threat actor's Drive contained the following:

The tool, which TRU identifies as InboxSetupPro (based on its install path C:\ProgramData\InboxSetupPro\), is distinct from Nimbus RAT and uses OneDrive rather than Google Drive for exfiltration.

local://C:/Users/<REDACTED>/AppData/roaming/signal/attachments.noindex/**

This pattern targets the Signal Desktop attachment store - the local cache of all files, images, and documents shared through Signal's encrypted messaging app - for a specific victim user. The recursive glob (/**) captures all attachments across all conversations.

TRU also observed a 1.13 GB ZIP archive from the same Drive folder named after the victim's email address, consistent with an exfiltrated Outlook OST (offline mailbox) file.

Taken together, the config file, targeting pattern, and recovered archive confirm the threat actor's post-compromise objectives extend well beyond initial access: communications data from both encrypted and traditional email channels were specifically targeted. This victim organization was separate from the legal sector customer in this TRU Positive.

What did we do?

• Our team of 24/7 SOC Cyber Analysts proactively isolated the affected host to contain the infection on the customer's behalf.
• We communicated what happened with the customer and helped them with remediation efforts.
• TRU is closely monitoring the Nimbus RAT campaign and developing up-to-date detection content for eSentire MDR for Endpoint, eSentire MDR for Log, and eSentire MDR for Network.

What can you learn from this TRU Positive?

• The Microsoft Teams vishing kill chain is effective because it abuses trusted platforms at every stage: Microsoft Teams for initial contact, Microsoft SharePoint for payload delivery, Quick Assist for remote access, Pastebin for instruction delivery, and Google Drive for C2. None of these platforms are candidates for broad blocking; defenders need controls and visibility at each layer individually.
• Email bombing as a precursor is increasingly well-documented. The flooding phase in this incident ran for an hour before the vishing call arrived. An alert on anomalous mailbox volume, triggered before any Microsoft Teams message is received, provides a meaningful detection window that is absent at every later stage.
• The Pastebin instruction sheet is a revealing TTP. The checklist format suggests the operator is running a volume operation with standardized procedures, reusing the same four-line script across multiple targets and changing only the download URL.
• The Google Drive C2 design means network-layer detections for this malware family will not work without process-level context. A proxy log showing googleapis.com traffic looks identical whether it comes from a legitimate Google Workspace session or from Nimbus RAT. The distinguishing factor is always the process behind the connection, which requires endpoint telemetry correlated with network logs.
• The license.txt file found in the InboxCorePro directory acts as a kill switch: removing it prevents the RAT from relaunching after a reboot. However, this should not be treated as full remediation. Complete remediation requires terminating all running javaw.exe processes associated with the JAR, removing the full C:\ProgramData\InboxCorePro\ directory, and deleting any Startup folder entries pointing to the payload. A re-image is the most reliable way to ensure the system is fully clean, as the operator may have established additional persistence mechanisms through C2 commands that are not immediately visible.

Recommendations from the Threat Response Unit (TRU)

Microsoft Teams Configuration

• Restrict or disable external Microsoft Teams messaging from unrecognized tenants where business requirements allow. At minimum, configure Microsoft Teams to require explicit approval before accepting contacts from external organizations.
• Disable communication with trial Microsoft Teams tenants in the Microsoft Teams admin center. This single control would have blocked 65% of the malicious external Microsoft Teams messages observed in TRU's dataset.
• Disable Quick Assist, AnyDesk, and other remote support tools via policy on endpoints where they are not required for legitimate IT operations. If Quick Assist is needed, restrict it to pre-approved helpdesk accounts.
• Defenders who discover a Microsoft Teams vishing attempt should check browser history for Pastebin visits around the same time, as these may reveal payload URLs before any execution occurs.

Email Security

• Implement alerting on anomalous mailbox volume: a sudden spike of 20 or more emails per minute from diverse external senders is a reliable precursor signal for the vishing phase that follows.
• Apply newsletter unsubscribe and subscription-bombing detection rules at the mail gateway to throttle or quarantine high-volume account-confirmation waves before they reach the user's inbox.

Endpoint Detection

• Create detection rules for javaw.exe executed from non-standard paths (anything outside C:\Program Files\Java\ or equivalent) with -jar arguments, particularly when the parent process is explorer.exe.
• Alert on regedit.exe invocations where the command line specifies a .reg file path under C:\ProgramData, for example regedit.exe C:\ProgramData[folder][file].reg, especially when closely preceded or followed by javaw.exe execution from the same directory.
• Monitor for the creation of java_app.lock in the system temp directory as a host-based indicator of Nimbus RAT initialization.
• Block or alert on execution of javaw.exe from C:\ProgramData\ or user-writable directories via application control policy.

Network and Proxy Monitoring

• Enable process-level attribution in proxy and firewall logs. Log entries for googleapis.com or docs.google.com should include the initiating process name and path. Alerts on these domains from javaw.exe or from processes in C:\ProgramData\ are high-fidelity indicators.
• Monitor for OAuth application grants with the https://www.googleapis.com/auth/drive scope in Google Workspace audit logs. Grants to an application named BackupBOX should be treated as an immediate indicator of compromise.
• Block or alert on outbound HTTPS connections from endpoints to Pastebin during business hours where Pastebin is not an approved business application, particularly when the browser session follows a Teams external message.

User Awareness

• Train users to recognize that legitimate internal IT helpdesk will not initiate contact through Microsoft Teams from an external account. Any Microsoft Teams message from an account outside your organization's tenant claiming to be IT support should be treated as suspicious.
• Teach users that a sudden inbox flood followed by a helpdesk contact offering to resolve it is a well-documented social engineering pattern. If this happens, users should call their actual IT helpdesk on a known number before taking any action.
• Advise users never to download and execute files at the instruction of someone who contacted them, regardless of the platform used.

Indicators of Compromise

Indicators of Compromise can be found here.

References

• https://www.rapid7.com/blog/post/2025/06/10/blacksuit-continues-social-engineering-attacks-in-wake-of-black-bastas-internal-conflict/