From Account Spoofing to Anubis Ransomware
An account-renaming sequence on a domain controller lasted only seconds. By the time it ended, the intrusion had moved from the use of an existing domain account to authentication as Administrator. Within another 12 minutes, the attacker had created a new Domain Admin account. The next morning, files were being encrypted.
This case traces an intrusion involving activity consistent with noPac exploitation, an attacker-installed ScreenConnect service, PowerShell discovery, rclone execution, and ransomware bearing Anubis branding. The earliest recovered .anubis modification timestamps occurred approximately 14 hours and 55 minutes after the beginning of a concentrated authentication-failure burst.
The investigation also illustrates a recurring forensic problem: the evidence that establishes control of a system may be much stronger than the evidence that establishes what data was left in it. Here, rclone activity and a ransom demand supported concern about theft, but the available artifacts did not establish a transfer destination, volume, or file inventory.
Victim names, internal addresses, and identifying paths have been anonymized. DC01 and WS01 are aliases. Attacker-created account and tool names are retained where useful. Incident dates are expressed as relative days: Day 1 is the UTC calendar day of the first observed authentication burst, and each subsequent day begins at 00:00 UTC. Times of day and elapsed intervals are preserved. Selected event details below are normalized excerpts, not screenshots or complete raw records.
Key findings
Windows Security events recorded a computer account being renamed to the domain controller's name without its trailing dollar sign, a Kerberos ticket request, and a rename back. Administrator authentication followed seconds later.
The attacker created nva, added it to Domain Admins, used RDP, and installed ScreenConnect as an automatically starting LocalSystem service.
The recovered ScreenConnect client configuration suppressed several visible connection notifications. One executable returned an Authenticode HashMismatch result.
Defender real-time protection was disabled at 05:13:25 on Day 2. The earliest recovered .anubis modification timestamps followed at 05:16:31.
A workstation contained 47,160 .anubis files and 88 ransom notes. Authentication and file artifacts support encryption through remote SMB access; they do not require a local encryptor on that workstation.
SRUM recorded rclone activity across the overnight period. Successful exfiltration remains unconfirmed.
Case timeline
The starting point below is the first observed authentication burst, not a proven initial-compromise time.
Relative day and UTC time | Observed activity | Evidence |
Day 1, 14:21 to 14:41 | 377 failed logons across 46 accounts from a shared internal source address | Security 4625 |
Day 1, 14:58:30 to 14:58:37 | Machine-account creation, renaming, and Kerberos ticket activity consistent with noPac | Security 4741, 4781, 4768, 4769 |
Day 1, 14:58:49 | Administrator authenticates using Kerberos | Security 4624 |
Day 1, 15:10:12 to 15:10:24 | nva created and added to Domain Admins | Security 4720, 4728 |
Day 1, 15:11:57 | nva RDP session begins on DC01 | Terminal Services and Security logs |
Day 1, 15:16:49 | ScreenConnect service installed | System 7045 |
Day 1, 15:17 | PowerShell discovery and network-scanner activity | Preserved PowerShell logs and user artifacts |
Day 1, 15:23:04 | RDP session ends; ScreenConnect session activity follows | Terminal Services and Application logs |
Day 1, 16:04 through Day 2, 05:17 | SRUM samples attribute activity to rclone.exe | SRUM application-usage table |
Day 2, 05:13:25 | Defender real-time protection disabled | Defender 5001 |
Day 2, 05:16:31 to 05:16:46 | 219 .anubis files on DC01's C: volume have modification timestamps in this interval | Parsed NTFS MFT |
Day 2, 05:36:33 onward | nva network authentication from DC01 to WS01; ransom-note creation follows | WS01 Security log and file listing |
Day 2, 12:33 to 12:35 | Further ransom-note writes on DC01 | MFT analysis |
Day 2, approximately 12:46 | Last recorded attacker-associated interactive session ends | Terminal Services and ScreenConnect logs |
Day 2, approximately 15:06 | Responder snapshot still captures the established ScreenConnect connection | TCP and process snapshots |
Day 2, 16:11 | ScreenConnect service stopped and disabled | System log |
Authentication through a shared network address
The earliest concentrated activity was a burst of 377 failed authentications against 46 accounts over approximately 20 minutes. Its breadth is consistent with password spraying, although Windows logon events do not reveal the attempted passwords. Successful authentications involving several of the targeted accounts also appeared in the investigation timeline.
These events shared an internal source address. Separate artifacts from a legitimate remote user's VPN client installation, correlated with domain logons, supported identifying that address as the environment's VPN NAT path. That explains why traffic from different remote systems could appear under one address at the domain controller.
It does not, by itself, establish how the attacker obtained a VPN session. The reviewed evidence does not resolve whether password guessing occurred against the VPN login itself or against internal services after remote access had already been obtained. Nor does it establish the VPN's MFA configuration or an exploit of the VPN gateway. The original external source address and the first accepted remote-access authentication require gateway-side evidence.
For defenders, the distinction affects the investigation. A successful logon following failures at a shared NAT address needs to be correlated with the account, workstation field, session, and subsequent behavior. The source IP alone cannot identify a person or device.
Privilege escalation through noPac
The decisive escalation in this intrusion was a sequence strongly consistent with noPac, a chain combining CVE-2021-42278 and CVE-2021-42287 in Active Directory. It offers the best-supported explanation for how an attacker operating through an existing domain account reached Administrator-level access before creating a separate Domain Admin identity.
The two vulnerabilities
CVE-2021-42278 concerns computer-account naming. Active Directory computer accounts normally have a sAMAccountName ending in $, such as DC01$. The vulnerability allowed an attacker with the necessary control over a computer account to give it a name that omitted that suffix. Naming an attacker-controlled account DC01 created the conditions for confusion with the legitimate domain controller account, DC01$. Microsoft's fix adds validation of computer-account names and related account attributes. Microsoft SAM hardening guidance.
CVE-2021-42287 concerns Kerberos account resolution and ticket validation. The Key Distribution Center, or KDC, issues authentication tickets. On a vulnerable system, it could issue a service ticket with privileges exceeding those of the original requesting account. The fix binds the original requester more securely to subsequent ticket processing through information in the Privilege Attribute Certificate, or PAC. Microsoft Kerberos authentication guidance.
The link between the flaws is a rename between ticket requests. An attacker obtains a ticket-granting ticket while the controlled account carries the DC-like name, then renames that account away. When the vulnerable KDC subsequently cannot resolve the name in the ticket, its lookup behavior can append $ and resolve the real domain controller account. Combined, these weaknesses can allow impersonation of a privileged user. CERT-EU explanation of the vulnerability chain.
This is an authenticated escalation path: the attacker needs an initial domain foothold and sufficient rights over a computer account. The account-creation permission can make that foothold particularly dangerous. In this incident, the event log directly establishes that the initiating account successfully created the computer object; it does not establish the exact domain-wide machine-account quota or the complete permissions that allowed creation.
The escalation recorded in this incident
At 14:58:30 on Day 1, an existing domain account created WIN-90VN23CK7DE$. The account was then renamed to the domain controller's name without the normal trailing $. A successful Kerberos TGT request used that temporary name. The account was renamed, and a successful service-ticket event followed.
The following excerpt preserves the meaningful sequence while replacing the victim domain controller's name:
Day 1, UTC
14:58:30 4741 Computer account created: WIN-90VN23CK7DE$
14:58:35 4781 WIN-90VN23CK7DE$ -> DC01
14:58:36 4768 TGT request: DC01; status 0x0
14:58:37 4781 DC01 -> WIN-90VN23CK7DE$
14:58:37 4769 Account: DC01@<DOMAIN>; service: DC01$; status 0x0
14:58:49 4624 Administrator; Kerberos; network logonThe renamed object retained the same SID through the sequence. This is important: the events describe changes to one computer account, rather than unrelated objects with similar names.
The observed order is significant: the DC-like name was in place for the TGT request, then removed before the service-ticket event. Administrator authentication followed approximately 12 seconds later. This sequence provides much stronger evidence for the noPac assessment than a suspicious computer-account name alone. It matches the behavior described in Microsoft's analysis of the combined vulnerabilities.
The logs establish the directory changes, successful ticket events, and subsequent Administrator logon. They do not identify the exploit program, recover its command line, or expose every internal KDC decision. Accordingly, the assessment identifies the vulnerability chain with high confidence without claiming that a particular public noPac script was recovered.
A similar sequence involving WIN-9Y08DN4PTY7$ was documented later in the case analysis. At 15:10:12, Administrator created nva; 12 seconds later, that account became a member of Domain Admins. This gave the attacker a separate privileged identity for subsequent access.
The case notes also raised the possibility of DCSync because Administrator NTLM authentication followed the Kerberos activity. That is a reasonable investigative lead, but NTLM authentication does not identify how credentials were obtained. The reviewed evidence does not prove a DCSync operation, an NTDS database export, or theft of every domain password hash.
Closing the escalation path
Microsoft introduced fixes for these vulnerabilities in November 2021, with Kerberos enforcement changes following in later updates. Defenders should verify supported, current security updates across every domain controller, including read-only domain controllers. The historical PacRequestorEnforcement registry transition is not a substitute for patching; Microsoft states that the October 2022 enforcement phase deprecated that setting. Microsoft deployment and enforcement guidance.
For this case, patch verification should be paired with a review of who can create and modify computer accounts. Investigators should also correlate account creation and rename events by SID with Kerberos ticket activity and subsequent privileged logons. Checking only the final account name would miss the brief impersonation window shown here. The observed escalation does not, by itself, reconstruct the controller's complete patch history or establish its present remediation state.
ScreenConnect takes over from RDP
The nva account established an RDP session on DC01 at 15:11:57 on Day 1. During that session, an installer named ksex_patched_lite.msi installed ScreenConnect. System event 7045 recorded the service at 15:16:49.
Service: ScreenConnect Client (9963f404a99f0fc4)
Start type: Auto start
Account: LocalSystem
Relay: relay.tlsdprotect[.]pro
Port: 8041The RDP session ended at 15:23:04, followed by ScreenConnect session activity. Later interactive sessions overlapped with discovery, security-setting changes, and encryption artifacts.
The recovered installation provided additional context. Its configuration set ShowBalloonOnConnect, SupportShowUnderControlBanner, and AccessShowUnderControlBanner to false. Those settings reduced visible indications of remote control. The recovered ScreenConnect.WindowsClient.exe also returned HashMismatch during signature verification, indicating that its contents did not match the embedded signature. The exact binary modification was not determined.
A responder snapshot taken the following afternoon associated the ScreenConnect service process with an established connection to 83.143.112[.]178:8041. The matching port is consistent with the configured relay; no DNS resolution record tying the relay hostname to this address was reviewed. The snapshot also preserved ScreenConnect Backstage and command-shell processes.
ScreenConnect is legitimate administration software. In this case, the installation sequence, attacker-created account, relay destination, configuration, and subsequent activity establish its role. A product name alone would be a much weaker detection signal.
Discovery and access to business data
Preserved PowerShell logs recorded launches of p.ps1 on Day 1 and p2.ps1 on Day 2 from the nva desktop. Error records showed calls to Resolve-DnsName and Test-Connection involving WIN-9Y08DN4PTY7, the name associated with the second suspicious computer account.
The complete script bodies were not recovered in those logs. Their exact logic, therefore, remains unknown. Closely timed subnet-list artifacts and SoftPerfect Network Scanner activity support a discovery role, but do not establish every action those scripts performed.
Shellbags, recent-item artifacts, and browser artifacts also documented navigation to local data folders and remote administrative shares. The reviewed paths included business records, finance, personnel, and user-profile directories. On multiple systems, the attacker navigated through c$ paths.
These artifacts help establish where the operator browsed. They are not a complete record of file reads, and a folder appearing in a shellbag does not establish that every file inside it was opened or copied. Likewise, service-ticket requests identify targets of authentication activity without proving successful execution on every target.
Rclone activity and the limits of exfiltration evidence
The SRUM application-usage table contained repeated entries for:
C:\Users\nva\Desktop\rclone.exeThe parsed samples ran from Day 1 at 16:04 through Day 2 at 05:17 and associated the activity with SYSTEM. These are sampled usage records, not exact process start and stop events; they do not prove uninterrupted execution between samples.
The forensic analysis also identified rclone configuration artifacts under the SYSTEM profile, but did not recover a usable destination configuration. The latter volatile snapshot did not contain a rclone connection. The ransom note claimed data theft, which is an attacker's assertion rather than independent verification.
Taken together, the artifacts support suspected exfiltration activity. They do not establish that a transfer was completed, which remote service received it, how many bytes were moved, or which files were transferred. In particular, SRUM application CPU-cycle values must not be presented as network-byte counts.
This is a meaningful evidence gap, not a reason to dismiss the risk. It directs further work toward gateway and proxy telemetry, recoverable configuration, remote-service records where available, and earlier response collections.
Defender changes precede encryption
At 05:13:22 on Day 2, Defender configuration-change events (5007) recorded cloud reporting being turned off. At 05:13:25, event 5001 recorded real-time protection being disabled. Sample-submission consent was changed at 05:13:28.
The earliest recovered .anubis modification timestamp on DC01's C: volume was 05:16:31, three minutes and six seconds after the real-time protection event. The parsed MFT contained 219 .anubis files modified between 05:16:31 and 05:16:46. The wider MFT analysis also documented ransom-note creation in that interval.
SRUM first recorded C:\Users\nva\Desktop\ch.exe in its 05:17 sample. Its timing and later usage are consistent with a suspected encryptor. However, the binary and its hash were not recovered for this review, and process-creation auditing did not cover the attack window. The available evidence does not directly establish its full command line or behavior through malware analysis.
The .anubis extension and the recovered note's Anubis branding support the ransomware identification used here. They do not establish a particular affiliate's identity or prove the use of a wiping capability.
Remote encryption and later synchronization
On WS01, authentication records documented nva network logons from DC01 beginning at approximately 05:36:33 on Day 2. Ransom-note creation followed at 05:36:44. The workstation's collected file listing contained 47,160 .anubis files and 88 RESTORE FILES.html notes, with much of the affected content beneath a OneDrive-synchronized profile.
The source-host authentication, remote-share browsing, and note timing support encryption over SMB from DC01. No local encryptor was identified in the reviewed workstation artifacts. That absence is not proof that no local execution occurred, but the observed remote access provides a supported explanation for the impact.
Many encrypted-file write timestamps fell on Days 4 and 5, later than the initial ransom note creation. The case analysis correlated that period with OneDrive and remote support activity. Synchronization of already-encrypted content is a plausible explanation for the later writes; it remains an assessment pending OneDrive log and cloud-version corroboration.
For responders, file modification time alone is insufficient to declare a second ransomware run. Authentication, note creation, process artifacts, and synchronization records should be evaluated together. The 47,160-file count is also an inventory at collection time, not proof that all those files were encrypted during the first observed minute or hour.
What the early response preserved
The last recorded attacker-associated interactive session ended around 12:46 on Day 2. An early responder collection around 15:06 still captured the established ScreenConnect connection. The service was stopped and disabled around 16:11. An established connection demonstrates that the service retained connectivity; it does not prove an operator was actively watching during that interval.
Those early collections were especially valuable because they preserved PowerShell and volatile-state evidence that was no longer available in the same form in later live logs. Process-creation auditing was enabled at 19:49 on Day 2, after the principal observed attack activity. Consequently, a later search returning no malicious 4688 events cannot clear the earlier period.
The response history also contained evidence-collection commands targeting removable media. Their context distinguished responder collection from attacker staging. This is why an intrusion timeline needs a parallel record of responder actions: copying tools or user artifacts during collection can create new timestamps that otherwise look like adversary activity.
Detection opportunities
The following are suggested correlation patterns derived from this case, not tested production rules. They require tuning against normal administration and the fields retained by each logging platform.
Behavior | Telemetry and correlation | Investigation focus |
Broad authentication failures | Aggregate 4625 by source, distinct accounts, and time; correlate with 4624 and gateway sessions | Distinguish a shared NAT address from an individual host; investigate subsequent privilege use |
Suspicious computer-account rename | Join 4741 and 4781 by target SID; look for a new name matching a DC without $, followed by 4768/4769 and a rename back | Short-lived naming changes can be more revealing than the account name left behind |
New privileged identity | Correlate 4720 with 4728 for the same member SID and the Domain Admins group | Prioritize accounts promoted soon after creation, then used for interactive access |
Unapproved remote-control service | Review 7045, binary signatures, service account, relay settings, and egress | Compare the specific instance and relay with the approved remote-support infrastructure |
Defender disabled before file impact | Correlate Defender 5001/5007 with file changes, ransom notes, and administrative sessions | Investigate the operator and surrounding activity rather than the configuration event alone |
Encryption through remote shares | Join destination-host type-3 logons with source addresses and rapid file changes | Trace the source even when no encryptor is found on the destination |
Rclone from a user's desktop | Correlate process or SRUM evidence with configuration, identity, and outbound transfers | Establish destination and completion before estimating exfiltration scope |
MITRE ATT&CK mapping
These mappings describe the observed behavior or the explicitly qualified assessment. They do not imply that every tactic was independently proven.
Technique | Case basis |
Broad authentication failures consistent with spraying; attempted password values unavailable | |
Computer-account renaming, Kerberos ticket activity, and subsequent Administrator authentication are strongly consistent with the noPac vulnerability chain | |
Creation of the nva account | |
Addition of nva to Domain Admins | |
Initial nva RDP session on DC01 | |
Attacker-installed ScreenConnect service and session activity | |
Recorded launches of p.ps1 and p2.ps1 | |
Remote administrative-share navigation and network logons | |
Recorded Defender protection changes | |
.anubis files and ransom-note artifacts |
No confirmed DCSync or exfiltration technique is assigned because the reviewed evidence does not establish those actions sufficiently.
Indicators and investigative artifacts
Network indicators are defanged and reflect the incident period. They are historical leads; their current ownership or activity has not been checked. Legitimate tool names and short filenames require context.
Indicator | Context |
relay.tlsdprotect[.]pro | ScreenConnect relay configured in the attacker-installed service |
83.143.112[.]178:8041 | Established ScreenConnect connection in the early responder snapshot |
9963f404a99f0fc4 | ScreenConnect instance identifier |
ksex_patched_lite.msi | Installer name recorded in the case analysis |
d8bf534da9990c3ff38811907996d0013d02f8cb79c3386042040231ae728344 | SHA-256 of recovered ScreenConnect.WindowsClient.exe; signature verification returned HashMismatch |
WIN-90VN23CK7DE$, WIN-9Y08DN4PTY7$ | Computer accounts associated with the suspicious rename sequences |
nva | Attacker-created privileged account; a contextual lead, not a globally unique indicator |
p.ps1, p2.ps1, discovered_subnets.txt | Discovery-related artifacts |
rclone.exe, ch.exe | Names observed in SRUM; hashes unavailable |
.anubis, RESTORE FILES.html | Encryption extension and ransom-note filename |
Lessons for defenders
The most useful detection window preceded ransomware execution. A suspicious computer-account rename, rapid creation of a privileged user, and installation of an unfamiliar remote-control service each offered a point to investigate the intrusion before files were encrypted.
The case also shows why endpoint-only reasoning can miss impact. A compromised domain controller can access workstation files over administrative shares; an affected workstation may have no local ransomware process to find. Remote authentication and file telemetry need to be investigated together.
Finally, evidence quality should determine the strength of the conclusion. This case supports domain compromise, remote-control activity, defense changes, and encryption. It supports concerns about data theft while leaving its destination and scope unresolved. Preserving that distinction makes the report more useful to the defenders who must decide what to contain, what to recover, and what evidence to collect next.
