The Nimbus Account Compromise

Determine whether the m.reed account was behaving as expected on nh-wks-it-01 and, if not, reconstruct how the account was accessed, what the operator did once inside, and whether anything left the environment.

Corporate endpoint and identity telemetry queried via Microsoft Defender for Endpoint Advanced Hunting (DeviceLogonEvents, DeviceProcessEvents, and DeviceFileEvents) across the subject workstation (nh-wks-it-01) and the HR file server (NH-FS-01).

The hunt started from a single anomalous logon and was worked forward hypothesis by hypothesis: who is behind the account, how did they get in, what did they do once inside, and whether anything left the building. Each answer below was pulled directly from Defender Advanced Hunting, not inferred.

1. Step 01

   Operator finds m.reed's public professional profile and pivots to a personal email address.

2. Step 02

   Personal email cross-referenced against breach data: a reused corporate-equivalent credential is identified.

3. Step 03

   Low-volume, targeted credential-guessing burst (3 failures, 1 success) against the remote support endpoint.

4. Step 04

   Successful RDP (RemoteInteractive) logon from the first external IP.

5. Step 05

   Initial reconnaissance: whoami, hostname, ipconfig /all, whoami /groups.

6. Step 06

   File server share enumeration (net view \\NH-FS-01) and HR group enumeration (net group "NH-HR-Users" /domain).

7. Step 07

   Roughly 10-minute session gap, then the operator reconnects from a second external IP.

8. Step 08

   RDP channel check (net view \\tsclient) confirms the mapped client-drive path.

9. Step 09

   HR data staged locally and compressed into an archive.

10. Step 10

    Archive exfiltrated via the mapped RDP client drive.

11. Step 11

    No malware or persistence mechanisms were deployed at any point.

The account's public professional profile listed a personal address, mason.reed@hotmail.com. That address cross-referenced against the Synthient Credential Stuffing Threat Data breach set, which held plaintext credentials from a prior, unrelated breach reused verbatim against the corporate remote-support endpoint (135.237.163.62). Logon telemetry shows a short, targeted guessing burst (3 failures, 1 success) from 116.45.242.115, followed by a successful RemoteInteractive (RDP) logon. That low-volume, immediately-successful pattern points to credential reuse, not brute force.

Post-logon process telemetry shows textbook reconnaissance (whoami, hostname, ipconfig /all, whoami /groups), followed by share enumeration (net view \\NH-FS-01) and HR group enumeration (net group "NH-HR-Users" /domain). After a roughly 10-minute session gap, the operator reconnected from a second external IP (45.131.194.61) and continued: a channel check (net view \\tsclient) confirmed the RDP mapped-drive path was reachable, HR data (access_request_queue_20260526.csv) was staged in C:\Users\m.reed\Documents\SupportReview\, compressed to support_review_202605.zip, and moved out through the RDP client drive to \\tsclient\G\Temp\NimbusSupport\. Checks for scheduled tasks, new services, and autorun entries turned up nothing beyond legitimate Windows/OneDrive housekeeping. No persistence was established, and the account never touched NH-FS-01 with an interactive logon.

First containment: disable or suspend m.reed and terminate all active sessions. A password reset alone isn't enough while the attacker is operating through an already-authenticated, live session, since existing tokens and mapped connections can outlive a password change. Because the exfiltrated file contained employee personal data (HR access-request records), the finding was escalated as a data-breach and privacy matter subject to breach-notification review.

Credential reuse from a public breach was enough to fully compromise a corporate account with no malware and no persistence. Detection has to catch the behavior itself (an unfamiliar RemoteInteractive source IP, a share-enumeration command, a client-drive file transfer), because there was no payload to catch. Correlating a single new source IP against a low-and-slow guessing pattern, instead of watching only for high-volume brute force, would have surfaced this several steps earlier in the chain.