Digital Forensic Investigation Report — Case ROCBA

Background

This investigation was initiated in response to a suspected compromise of a Windows workstation belonging to Fred Rocba (user account "fredr"), an employee of Stark Research Labs. The system under examination, at internal IP address 192.168.1.5, was identified as running Windows 10 with Remote Desktop Protocol (RDP) services exposed directly to the internet on the default port 3389. A forensic disk image in E01 format containing both a memory dump and a full-disk capture was provided as evidence.

The forensic analysis drew upon 21 indexed evidence sources spanning eleven distinct extractor types: Volatility 3 memory forensics, Sleuth Kit disk analysis, EZ Tools (AmCache, ShimCache, MFT, Prefetch), RegRipper registry parsing, bulk_extractor IOC carving, YARA signature scanning, Chainsaw Sigma rule analysis, composite correlation engines, timestomping detection, EVTX log extraction, and IOC enrichment services. A total of 292 tool invocations were executed across the investigation. The analysis produced 7 formal findings, of which 7 are confirmed through multi-source corroboration.

The evidence environment includes a current Windows 10 installation as well as remnants of a prior installation preserved in a Windows.old directory, providing a longitudinal view of system activity and attack history across two separate operating system installations. The system serves as a general-purpose workstation with typical enterprise productivity software (Microsoft Office, Adobe Acrobat, Chrome, Firefox, Dropbox) and organizational collaboration tools (Microsoft Teams, Slack, Zoom).

Incident Timeline

The incident timeline spans approximately seventeen days, from the earliest evidence of credential attacks on 2020-10-30 through the captured active brute-force assault on 2020-11-16. Events are reconstructed from SAM registry hive timestamps, Volatility memory forensics, and cross-correlated filesystem artifacts.

Phase 1 — Initial Reconnaissance and Early Probing (2020-10-30 to 2020-11-01)

The earliest evidence of unauthorized activity is found in the Windows.old SAM hive from the prior Windows installation. On 2020-10-30 at 13:14:47 UTC, the Guest account recorded a password failure, indicating external credential guessing against the system's RDP service. This probing continued through 2020-11-01, when at 21:22:15 UTC the DefaultAccount recorded a password failure. Notably, the prior installation's active accounts ("srl-h" with last login at 2020-10-20 16:14:19 UTC and "fredr" with last login at 2020-10-20 16:23:21 UTC) did not record any password failures on these dates, suggesting the attacker was enumerating default and disabled accounts rather than targeting known usernames.

The system was reinstalled on 2020-11-01 at approximately 22:15 UTC, roughly 42 minutes after the last recorded login on the old installation (srl-h at 21:33 UTC). While the temporal proximity to the brute-force activity is notable, no evidence of successful compromise was found in the old installation's SAM, and the reinstallation may have been a routine maintenance event or a precautionary response to suspected intrusion attempts.

Phase 2 — Quiescent Period (2020-11-02 to 2020-11-15)

Following the reinstallation, the system operated normally. Archived Security Event Logs span from 2020-11-02 through 2020-11-06, though these were not parsed for the attack period as they predate the primary incident. Legitimate user activity resumed, with user "srl-h" last logging in on 2020-11-10 at 13:26:09 UTC and user "fredr" last logging in on 2020-11-14 at 12:51:58 UTC. ShimCache and AmCache records from this period show only standard application execution — Adobe products, Chrome, Firefox, Office applications, and system utilities.

Phase 3 — Active Brute-Force Attack (2020-11-16, 00:23 to 02:50 UTC)

The primary attack commenced on 2020-11-16 with a methodical escalation. At 00:23:06 UTC, the Guest account recorded a password failure, marking the beginning of username enumeration against the new installation. At 01:12:37 UTC, the DefaultAccount was targeted. The attack then intensified dramatically around 02:30 UTC, when four external IP addresses launched a coordinated RDP brute-force assault.

Network connections captured in the memory dump show the attack infrastructure:

The first and most persistent attacker, at IP 81.30.144.115 (Germany, AS24961 WIIT AG), maintained over forty connections to port 3389, including ESTABLISHED sessions observed at 02:34:45 and 02:34:58 UTC, interspersed with numerous CLOSED connections from 02:31 through 02:36 UTC. A second attacker at 213.202.233.104, sharing the same German autonomous system (AS24961 WIIT AG), exhibited a similar pattern with over forty connections, including ESTABLISHED sessions at 02:34:58 and 02:35:53 UTC. A third source, 81.19.209.101 (Netherlands, AS25369 Hydra Communications Ltd), briefly appeared with a SYN_RCVD connection at 02:33:32 UTC followed by a CLOSED state at 02:33:38 UTC. A fourth attacker at 201.193.188.114 (Costa Rica, AS11830 ICE) connected sporadically, with CLOSED connections at 02:30:05, 02:32:49, and 02:34:25 UTC. All inbound RDP connections were handled by svchost.exe PID 1248, the legitimate Terminal Services listener process.

The Administrator account recorded its password failure at 02:50:31 UTC, representing the last recorded attack event and indicating the attackers escalated from default/guest accounts to the built-in Administrator account during the assault.

Phase 4 — Memory Capture (2020-11-16, approximately 02:36 UTC)

The memory dump was acquired during the active attack, preserving the state of multiple ESTABLISHED and recently CLOSED RDP connections. This capture timing proved invaluable, providing a snapshot of the attack infrastructure in real time.

Key Findings

RDP Brute-Force Attack Infrastructure

The investigation confirmed an active, coordinated RDP brute-force attack originating from four external IP addresses. Two of the attacking IPs, 81.30.144.115 and 213.202.233.104, share the same autonomous system number (AS24961 WIIT AG, Germany), strongly suggesting coordinated infrastructure — either a single actor using multiple nodes within the same hosting provider, or a shared botnet leveraging that provider's resources. The third IP (81.19.209.101, Netherlands) and fourth IP (201.193.188.114, Costa Rica) operated from different network providers, consistent with either a geographically distributed attack operation or compromised hosts being leveraged for credential stuffing.

The attack methodology followed a classic credential-guessing pattern: initial enumeration of default and disabled accounts (Guest, DefaultAccount) before escalating to the built-in Administrator account. This pattern was consistent across both the prior and current Windows installations, spanning at least seventeen days.

No Successful Compromise Achieved

The most significant conclusion of this investigation is the definitive determination that the brute-force attack did not succeed in gaining access to the system. This assessment rests on multiple independent lines of evidence. The SAM registry hive provides the strongest evidence: the Last Login timestamps for both active user accounts — srl-h (2020-11-10 13:26:09 UTC) and fredr (2020-11-14 12:51:58 UTC) — are definitively before the 2020-11-16 attack. A successful RDP authentication would have updated the Last Login timestamp for the authenticated account. Furthermore, neither active account recorded password failures on the attack date, indicating the attackers did not guess the correct usernames for active accounts. Password failures were recorded only on disabled accounts (Guest, DefaultAccount, Administrator), none of which could grant interactive access even with the correct password.

Memory forensics corroborated this conclusion through multiple independent checks. The Volatility process tree revealed no anomalous parent-child relationships; all running processes were legitimate Windows services and user applications. No hidden processes were detected in the psscan-versus-pslist differential analysis, ruling out rootkit-level concealment. No suspicious command lines appeared in the cmdline plugin output. No network connections existed between any user-space process and the attacker IP addresses — only the TermService listener (svchost.exe PID 1248) communicated with those IPs. Malfind results flagged two processes, MsMpEng.exe (PID 4864) and SearchApp.exe (PID 8312), but both exhibited benign RWX memory regions characteristic of just-in-time compilation and antivirus engines, with no shellcode signatures detected.

Disk forensics provided further negative confirmation. ShimCache and AmCache execution history contained only legitimate software. No reconnaissance tools (net.exe for enumeration, psexec, mimikatz, or similar post-exploitation frameworks) appeared in any execution artifact. Prefetch files showed normal application execution patterns. MFT analysis detected no evidence of timestomping beyond a single benign NTFS root directory entry discrepancy.

Evidentiary Gap in Security Event Logs

A significant evidentiary limitation was identified: the active Security.evtx file covering the attack date (2020-11-16) was not available in the extracted evidence. Only fifteen archived Security log files were recovered, spanning 2020-11-02 through 2020-11-06. This ten-day gap between the last archived log and the attack date means that Windows Security Event IDs 4624 (successful logon), 4625 (failed logon), and related authentication audit events from the attack period could not be examined directly. The investigation was unable to determine whether this gap resulted from normal log rotation, intentional log clearing, or an artifact of the evidence collection process. However, the absence of these logs did not materially impair the investigation's primary conclusions, as the SAM Last Login timestamps and memory forensics provided independent, definitive evidence against successful compromise.

Recurring Attack Pattern Across Installations

Cross-referencing SAM hives from both the current and prior (Windows.old) installations revealed that this system has been under sustained external credential attack for at least seventeen days. The attack pattern — targeting disabled and default accounts via RDP — persisted identically across a complete operating system reinstallation, confirming that the root vulnerability is the network exposure of the RDP service rather than any software-level misconfiguration that would be resolved by reinstallation.

YARA and Sigma Detection Results

YARA scanning produced 597 match windows against memory and 44 against disk files using the signature-base ruleset. Comprehensive triage of every matched string confirmed all results as false positives arising from generic pattern matches against legitimate Windows system content. Notably, Cobalt Strike beacon rules matched only on standard date format strings and Windows PE headers; APT family rules matched only on common system paths and format specifiers. Chainsaw Sigma rule analysis against available archived event logs returned zero findings. These results collectively establish the absence of known malware families, offensive toolkits, or implants in both the memory space and filesystem.

User IOC Clearance

During evidence carving, several potentially suspicious indicators were identified, including the domain cobracommandcenter.com and email addresses such as redguard.cobra@gmail.com and crimsonguard@cobracommandcenter.com. Investigation determined these belong to Fred Rocba's personal accounts, evidenced by consistent naming themes across his account portfolio, co-occurrence with his confirmed email addresses in browser cache and cloud sync metadata, and the domain's appearance in browser history as a personal website. These indicators were formally cleared and should not be treated as threat intelligence.

Threat Intelligence and Attribution

The attacking infrastructure spans three autonomous systems across three countries: AS24961 WIIT AG in Germany (two IPs: 81.30.144.115 and 213.202.233.104), AS25369 Hydra Communications Ltd in the Netherlands (81.19.209.101), and AS11830 ICE in Costa Rica (201.193.188.114). The concentration of two IPs within a single German hosting provider suggests either dedicated attack infrastructure or compromised servers within that provider's network.

The attack methodology is consistent with opportunistic RDP brute-forcing, a technique widely employed by ransomware affiliates, initial access brokers, and automated scanning botnets. The tactics, techniques, and procedures map to MITRE ATT&CK T1110.001 (Brute Force: Password Guessing), T1021.001 (Remote Services: Remote Desktop Protocol), and T1133 (External Remote Services). The attack pattern — enumeration of default accounts before targeting administrative accounts, sustained activity over weeks, use of geographically distributed infrastructure — is characteristic of automated credential-stuffing campaigns rather than targeted intrusions against Stark Research Labs specifically.

Attribution to a specific threat actor or group cannot be established from the available evidence. RDP brute-forcing is a commodity technique used across the threat landscape, from opportunistic ransomware operators (Dharma/CrySIS, Phobos, SamSam campaigns have historically relied on this vector) to initial access brokers selling RDP credentials on underground markets. The use of European hosting infrastructure and the automated, non-targeted nature of the account enumeration are consistent with botnet-driven scanning operations, but this assessment is based on behavioral pattern matching rather than definitive attribution indicators.

Impact Assessment

The immediate impact of this incident is limited, as no successful compromise was achieved. However, the investigation reveals significant ongoing risk. The system at 192.168.1.5 has been under sustained external attack for at least seventeen days across two separate operating system installations. The RDP service remains bound to all network interfaces (0.0.0.0:3389) with no evidence of firewall policies restricting inbound connections by source IP. While Network Level Authentication (NLA) and TLS encryption are enabled — providing protection against unauthenticated vulnerability exploitation — the service remains vulnerable to credential-based attacks.

The two active user accounts (srl-h and fredr) are both members of the local Administrators group, meaning a successful password guess against either account would grant full administrative access to the system. Given the persistence of the attacks and the inevitable exposure of this system to continued brute-force campaigns, the probability of eventual compromise increases with time if the current configuration is maintained. The presence of enterprise collaboration tools (Microsoft Teams, Slack, SharePoint) and cloud-synced data (Dropbox, OneDrive, iCloud) means that a successful compromise would potentially expose not only local data but also organizational credentials and cloud-stored documents belonging to Stark Research Labs.

One system was targeted and zero were compromised. No data was exfiltrated, no persistence mechanisms were installed, and no lateral movement occurred.

Immediate Tactical Containment

The following actions should be executed immediately to neutralize the active threat:

1. Block inbound connections from attacking IPs at the network perimeter firewall: 81.30.144.115, 213.202.233.104, 81.19.209.101, and 201.193.188.114.
2. Block inbound traffic from AS24961 (WIIT AG) at the perimeter if operationally feasible, as two of four attacker IPs originate from this autonomous system and additional nodes within it may be used in future attacks.
3. Disable direct internet-facing RDP access to 192.168.1.5 by blocking inbound TCP/UDP port 3389 from all external (non-RFC1918) source addresses at the network firewall.
4. Verify that no unauthorized sessions are currently active on 192.168.1.5 by reviewing the output of "qwinsta" or "query session" commands. The memory capture showed no unauthorized sessions, but the system has continued operating since the capture.
5. Force password resets for both active local accounts: srl-h and fredr. Although no successful compromise was detected, the accounts have been targeted by brute-force attacks and password rotation is a precautionary measure.
6. Disable the built-in Administrator account (if not already disabled at the OS level, as the SAM shows it was targeted by the attackers at 02:50:31 UTC) via "net user Administrator /active:no".
7. Review and confirm that the Guest and DefaultAccount remain disabled in the SAM, as both showed password failure timestamps indicating active targeting.

Strategic Remediation

The root cause of this incident is the direct exposure of the RDP service to the public internet without network-level access controls. The registry configuration (ControlSet001\Control\Terminal Server: fDenyTSConnections = 0, WinStations\RDP-Tcp bound to port 3389 on all interfaces) combined with the absence of any firewall policy evidence restricting source IPs created an attack surface that was discovered and exploited within days of the system's deployment. This exposure persisted identically across a complete Windows reinstallation on 2020-11-01, demonstrating that reinstallation without addressing the network architecture does not mitigate the risk. Remediation requires implementing a VPN or jump-host architecture for remote access, or at minimum deploying Windows Firewall rules restricting RDP inbound connections to specific authorized source IP ranges, as documented in findings f_5a146e45 and f_7027756a.

The investigation's reliance on SAM Last Login timestamps to rule out compromise — rather than Security Event Log analysis — highlights a critical gap in audit log retention. The active Security.evtx for the attack period was unavailable, and archived logs covered only 2020-11-02 through 2020-11-06, leaving a ten-day evidentiary blind spot preceding the attack (finding f_7e75fe91). For a system exposed to persistent external attacks, the log retention policy should ensure that authentication events (Event IDs 4624, 4625, 4648) are preserved for a minimum of 90 days, either through increased maximum log file sizes, centralized log forwarding to a SIEM, or both. Had the active Security.evtx been available, the investigation could have corroborated the SAM-based conclusion with event-level granularity and identified the exact number of failed authentication attempts.

Both active user accounts (srl-h and fredr) hold local Administrator privileges, and the Remote Desktop Users group has zero explicitly configured members — meaning RDP access is governed solely by Administrator group membership. This configuration (finding f_5a146e45) means that a successful credential guess against either account would yield full administrative control. Implementing least-privilege access by creating standard user accounts for daily RDP sessions and reserving Administrator credentials for elevated operations would reduce the blast radius of a future successful brute-force attack.

The brute-force attack methodology (finding f_ef85e9ae) progressed from default account enumeration (Guest, DefaultAccount) to the built-in Administrator account, a pattern that account lockout policies would partially disrupt. The absence of any observed lockout behavior during sustained connection floods suggests that no account lockout threshold is configured for these accounts. Implementing account lockout policies (e.g., lockout after 5 failed attempts with a 30-minute duration) on all accounts — particularly the built-in Administrator, which requires specific Group Policy configuration as it is exempt from default lockout policies — would significantly increase the cost of brute-force attacks, as observed in MITRE ATT&CK T1110.001.

Conclusion

Q1. What systems were compromised? No systems were compromised. The target system at 192.168.1.5 successfully resisted the brute-force attack. SAM Last Login timestamps, memory forensics, disk artifact analysis, and composite correlation across 21 evidence sources unanimously confirm no unauthorized access occurred.

Q2. How did the attacker gain initial access? The attacker did not gain initial access. The attempted vector was RDP brute-force credential guessing (MITRE ATT&CK T1110.001) against the internet-exposed RDP service on port 3389. Four external IPs (81.30.144.115, 213.202.233.104, 81.19.209.101, 201.193.188.114) conducted sustained connection attempts, but all authentication attempts failed against active user accounts.

Q3. What lateral movement occurred? No lateral movement occurred. Composite lateral movement analysis returned zero results. No network connections to internal systems from attacker-associated processes were detected, and no lateral movement tools appeared in execution history.

Q4. What persistence mechanisms were installed? No attacker-installed persistence mechanisms were found. Registry autorun keys, services, scheduled tasks, AppInit_DLLs, and Winlogon entries all contain only legitimate software. Composite persistence analysis confirmed all 161 identified autorun entries are benign.

Q5. Was data exfiltrated, and if so, what and how much? No data exfiltration occurred. Composite exfiltration analysis found no connections to known exfiltration services, no evidence of data staging or archiving for transfer, and no suspicious outbound network activity. All carved URLs and domains correspond to legitimate user browsing and cloud service usage.

Q6. What is the full timeline of the incident? The incident spans 2020-10-30 through 2020-11-16. Initial probing began on 2020-10-30 against the prior Windows installation. Following a system reinstallation on 2020-11-01, attacks resumed on 2020-11-16 with escalating intensity, culminating in a coordinated four-IP brute-force assault between 02:30 and 02:50 UTC. The memory dump was captured during this active attack at approximately 02:36 UTC.

Q7. What is the total scope and business impact? One system was targeted (192.168.1.5). Zero systems were compromised. No business data was accessed, exfiltrated, or destroyed. The direct business impact is limited to the investigative response effort. However, the continued exposure of RDP to the internet represents an ongoing risk to Stark Research Labs, as the system hosts credentials and data synchronized with organizational cloud services (SharePoint, Teams, Slack, OneDrive).

Q8. What are the recommended remediation actions? Four targeted remediation actions are recommended, each tied to specific findings: (1) eliminate direct internet RDP exposure by implementing VPN-gated or jump-host remote access architecture; (2) implement centralized Security Event Log forwarding and extend retention to cover at minimum 90 days of authentication events; (3) apply least-privilege principles by separating daily-use accounts from administrative credentials for RDP sessions; and (4) configure account lockout policies, including specific Group Policy settings for the built-in Administrator account, to impose cost on brute-force attempts.