Digital Forensic Investigation Report — Case SRL-2018: Stark Research Labs Network Compromise

YARA memory scanning detected multiple distinct signature families in the Domain Controller's memory dump, indicating the presence of sophisticated implant code.

STRONGEST MATCHES (specific, low false-positive risk):

1. Codoso_CustomTCP_4 — Matches at clustered offsets 0x6c6e4c87-0x6c6e4ce3 (within ~92 bytes), indicating a contiguous loaded binary module. The string "varus_service_x86.dll" is a specific malware DLL name associated with Codoso tooling, not a generic Windows string. Supporting strings: "net start %%1", "net stop %%1", "ping 127.1 > nul" — service manipulation commands.

2. DeepPanda_htran_exe — Matches at offsets 0x6657872a-0x665787b ("slave ", "[+] OK! I Closed The Two Socket."). These are htran's exact usage strings — highly specific to this proxy/port-forwarding tool used for network pivoting.

3. IMPLANT_5_v3 — Matches a specific mathematical instruction byte sequence at 0x10ebe323a (0F AF C0 69 C0 07 00 00 00...) — less specific than named tool matches but distinctive.

MODERATE MATCHES (partially specific):

1. Codoso_Gh0st_1 — The COM elevation moniker ($x3: "Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}") appears at multiple offsets. While the Elevation:Administrator pattern IS used by legitimate Windows UAC, the specific CLSID combined with Kaspersky AV process detection strings (kavsvc.exe, kav.exe, avp.exe) suggests anti-AV evasion capability. These AV process names appear frequently in Windows memory (from AV databases, etc.) but their presence IN COMBINATION with the elevation moniker raises weight.

2. Tofu_Backdoor — "Cookies: Sym1.0" at 0x8d5faa02 with specific byte pattern.

ATTRIBUTION LIMITATION (Q-CA5):
Without vadyarascan for per-process attribution, we cannot determine which process hosts this implant code. The Codoso_CustomTCP_4 match at 0x6c6e4c and the htran match at 0x6657 are at DIFFERENT memory regions, suggesting separate tools/modules. The YARA rule names suggest APT19/Codoso attribution, but YARA rule naming reflects the rule author's assessment, not independent confirmation. The evidence supports the PRESENCE of implant code matching known Codoso/htran signatures, but single-tool attribution to a specific threat actor requires corroboration from additional evidence types (filesystem, C2 infrastructure, TTP alignment).

CROSS-FINDING CORROBORATION:
The DC was independently confirmed as compromised via the spsql/WinRM/ntdsutil IFM attack chain (f_a9a97ab2). The YARA matches suggest ADDITIONAL implant presence beyond the spsql-based credential theft — potentially a more persistent backdoor deployed prior to the August 2018 attack window.

The spsql service account (SID S-1-5-21-3445421715-2530590580-3149308974-1193) executed ntdsutil.exe via WinRM PowerShell Remoting (wsmprovhost.exe -Embedding) to attempt extraction of the Active Directory database (NTDS.dit).

Exact command sequence captured in PowerShell Operational Event 4103 at 2018-09-05T12:26:28.3568308 UTC:

1. ntdsutil.exe: ac i ntds → "Active instance set to "ntds"."
2. ntdsutil.exe: ifm
3. ifm: create full c:\windows\temp\perfmon" q q → "Error parsing Input - Invalid Syntax."

The attacker attempted to use the ntdsutil IFM (Install From Media) feature to create a full dump of the Active Directory database to c:\windows\temp\perfmon - a path disguised to look like legitimate performance monitoring data. The command failed due to a syntax error (misplaced quote character in the path).

A second ntdsutil.exe invocation was recorded at 2018-09-05T12:27:01.8670270 (28 seconds later), indicating a persistent attempt to extract the database.

Attack chain context:
- The execution was REMOTE - "Host Name: ServerRemoteHost" confirms WinRM access
- The Connected User is "shieldbase\spsql" - a SQL service account, NOT a domain admin
- Process creation (4688) at 12:05:18 shows spsql executing processes via wsmprovhost.exe
- This constitutes SERVICE ACCOUNT ABUSE: a SQL service account performing domain admin operations

Impact: If successful, the ntdsutil IFM dump would have produced a copy of the NTDS.dit file and the SYSTEM registry hive, together enabling offline extraction of ALL domain user password hashes using tools like secretsdump.py or DSInternals.

This finding directly answers Investigation Q1 (DC compromise/credential theft) and Q8 (privilege escalation) affirmatively.

Affected Systems: evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational, evtx.windows_system32_winevt_logs_security

The evidence labeled as "base-wkstn-01" contains memory data from TWO distinct systems, acquired via F-Response during the incident response on September 6, 2018. They represent different systems at different stages of compromise:

MEMORY DUMP 1: BASE-RD-01 (172.16.6.11) — Active Post-Exploitation Stage
- Boot time: 2018-08-30 13:51:58 UTC
- Primary user: tdungan (Stark Research Labs researcher)
- IP: 172.16.6.11
- F-Response agent (subject_srv.exe PID 1096) deployed 2018-09-06 18:28:30

Key attack artifacts:
- WmiPrvSE.exe(2876) → powershell.exe(8712) → powershell.exe(5848, 32-bit) → p.exe(8260) — full C2 chain active
- p.exe running continuously since Aug 30 22:15:18 (~7 days), with 481 RWX pages and WININET/WS2_32/crypto DLLs
- 9 rundll32.exe fork-and-run processes spawned (Aug 30-Sep 6) for post-exploitation modules
- ESTABLISHED connections to 172.16.7.15:445 (Kerberoasting source), 172.16.4.5:445 (file server)
- SendSpace exfiltration URLs (Sep 5 14:14-14:21 UTC)
- spsql account profile with carbonadium-info.LNK (data access Aug 28)
- McAfee running but not detecting the implant

This system represents the ACTIVE COMPROMISE PHASE — the attacker's primary pivot point for domain-wide operations including Kerberoasting, WinRM lateral movement to the DC, and data exfiltration.

MEMORY DUMP 2: base-rd-02 (172.16.6.12 / 10.10.150.180) — Persistent Implant Stage
- Boot time: 2018-08-19 06:22:43 UTC (11 days earlier)
- IPs: 172.16.6.12 (corporate), 10.10.150.180 (secondary network)
- F-Response agent (subject_srv.exe PID 1204) deployed 2018-09-06 19:03:45

Key attack artifacts:
- msadvapi2_64.exe (PID 2328) and msadvapi2_32.exe (PID 2292) — custom C2 implant disguised as "Microsoft Advanced API", installed May 2018, running as services under services.exe
- AMQP/RabbitMQ C2 channel: 10.10.150.180 → 10.10.200.207:5672 and 10.10.254.1:61613
- perfmon-k keylogger suite (operational since Aug 2017)
- java.exe (PID 2976) from prunsrv.exe — Apache/Tomcat service
- ruby.exe (PID 2396), rubyw.exe (PID 6080) — Ruby application services
- chromedriver_w (PID 2716) — automated browser (possibly for web app testing or credential harvesting)
- PowerShell (PID 6524, 32-bit) spawned Sep 6 17:10:55
- Same WMI→PowerShell→p.exe attack chain present (identical PIDs to Dump 1 overlap area)
- spsql account lateral movement from BASE-RD-01 and BASE-RD-04

This system represents the PERSISTENT INFRASTRUCTURE STAGE — a longer-term compromise with established C2 through enterprise message queuing, persistent keylogger, and service-based implants dating back to May 2018 or earlier.

TIMELINE COMPARISON:
| Aspect | BASE-RD-01 (Dump 1) | base-rd-02 (Dump 2) |
|--------|---------------------|---------------------|
| First compromise evidence | 2018-08-28 (spsql data access) | 2017-08 (keylogger installed) |
| Active implant installed | 2018-08-30 (p.exe) | 2018-05-08 (msadvapi2) |
| C2 protocol | HTTP/HTTPS (WININET.dll) | AMQP/RabbitMQ (enterprise MQ) |
| Persistence method | WMI-spawned process chain | Windows service registration |
| Boot at capture | 2018-08-30 (7 days up) | 2018-08-19 (18 days up) |
| Network role | Pivot point for AD attacks | Infrastructure with message queue C2 |

CONCLUSION:
The two systems show different stages of the same campaign. base-rd-02 was compromised FIRST (at least May 2018, possibly August 2017 with the keylogger), providing the attacker with a persistent foothold using enterprise-grade C2. BASE-RD-01 was compromised LATER (August 30, 2018) as the attacker expanded operations to target tdungan's research data and launch domain-level attacks (Kerberoasting, ntdsutil IFM). The common elements — spsql account abuse, WMI execution chains, the "perfmon" naming convention, and the WindowsServerBackup staging pattern — link both compromises to the same threat actor.

Affected Systems: registry.system, tsk.filelist, volatility.cmdline, volatility.netscan, volatility.psscan, volatility.pstree, yara.memory

The attacker-controlled directory C:\Windows\Temp\perfmon\ on base-wkstn-05 contains extensive staged sensitive business data organized for exfiltration:

research/Rare-Earth Elements/M&A Targets/ - Merger and acquisition intelligence:
- Orocobre/Annual Reports/ — 8+ annual reports (2008-2017) for Orocobre lithium mining company
- Orocobre/Technical Reports/ — NI 43-101 resource reports for Olaroz, Cauchari, Salinas Grandes lithium projects (June 2018 being most recent)
- Tronox/Annual Reports/ — 8+ annual reports (2008-2018) for Tronox Holdings (titanium minerals)
- Tronox/2018 Results/ — Q2 2018 financial results
- Tronox/Tronox Background/ — FTC complaint response and European Commission acquisition approval documents for Cristal Acquisition

research/Rare-Earth Elements/M&A Targets.zip — Complete ZIP archive of the M&A research directory, indicating preparation for bulk exfiltration.

sp/c/ — Additional research materials:
- Carbon nanotube research papers
- Cabonadium-CalTech.pdf
- Project_800724_WireTransferInfo.docx — Wire transfer instructions (financial)
- Kenichi's research seminar.ppt
- Multiple IMG photos with Zone.Identifier ADS

sp/m/ — Mixed content including:
- CONFIDENTIAL - Project Mayhem.pptx — Explicitly labeled confidential document
- Carbon-14 research, schedule.docx, shopping list.docx

All PDFs contain Zone.Identifier alternate data streams, confirming they were downloaded from external sources (likely from corporate repositories or intranet). The staging location (Windows\Temp\perfmon) deliberately mimics a Windows performance monitoring tool to avoid detection.

This represents targeted economic espionage focused on rare-earth elements, lithium mining, and M&A target intelligence in the minerals sector.

The compromised spsql service account (SID S-1-5-21-3445421715-2530590580-3149308974-1193) was used as the primary attack vehicle across at minimum 5 systems in the SHIELDBASE.LAN domain, with evidence from independent sources corroborating each step.

CROSS-SYSTEM EVIDENCE CONVERGENCE:

1. base-rd-02 (172.16.6.12) — Keylogger (perfmon-k) operational since Aug 2017 captured credentials. spsql network logons from BASE-RD-04 (172.16.6.14) on Aug 25 21:03 and from BASE-RD-01 on Aug 28 22:16. 462 spsql events in the Security log. Interactive profile with INetCache modified Aug 31 21:54. This addresses Q3: the spsql password was likely captured by the perfmon-k keylogger on base-rd-02 which had been operational for over a year.

2. BASE-RD-01 (172.16.6.11) — spsql user profile with Office\Recent\carbonadium-info.LNK created Aug 28 21:45:57 (data access). spsql INetCache modified Aug 31 21:54. WMI→PowerShell→p.exe attack chain active since Aug 30. ESTABLISHED SMB to 172.16.7.15:445 (Kerberoasting source).

3. BASE-FILE (172.16.4.5) — PowerView/PowerSploit executed under spsql (PID 5992) on Aug 31 22:16-22:52. AD reconnaissance functions including Find-LocalAdminAccess and password hunting in user descriptions.

4. BASE-DC (172.16.4.4) — spsql authenticated from BASE-RD-01 (172.16.6.11) via Kerberos at Sep 5 11:51:52 (after failed pre-auth at 11:50:56). Granted full Domain Admin privileges. ntdsutil IFM executed at 12:26:28 via WinRM (wsmprovhost.exe).

5. BASE-RD-04 (172.16.6.14) — Authenticated spsql to base-rd-02 on Aug 25 21:03:15 with administrative privileges. Has an ESTABLISHED SMB connection to BASE-RD-01 (172.16.6.11:445) at time of capture. This answers Q4: BASE-RD-04 is another compromised workstation in the lateral movement chain.

ATTACK CHAIN COHERENCE:
The spsql account trajectory forms a coherent kill chain:
- Credential capture via keylogger (base-rd-02, 2017-2018)
- Initial data access (BASE-RD-01, Aug 28)
- AD reconnaissance (BASE-FILE, Aug 31)
- Kerberoasting for additional credentials (from 172.16.7.15, Sep 4-6)
- Domain Controller credential theft attempt (BASE-DC, Sep 5)
- Data exfiltration via SendSpace (BASE-RD-01, Sep 5)

Each step logically enables the next, and the same account (spsql) is confirmed by independent evidence sources (EVTX, MFT, memory forensics, bulk_extractor) at each stage.

Evidence from 4 independent systems converges to show a coordinated data staging and exfiltration pipeline targeting proprietary research and M&A intelligence in the rare-earth/minerals sector.

CONVERGENCE OF INDEPENDENT SOURCES:

1. Data Access (BASE-RD-01, MFT): spsql opened carbonadium-info.doc on Aug 28 21:45:57 (Office\Recent\carbonadium-info.LNK). Original research files by tdungan: Cabonadium-CalTech.pdf (5.9MB) and carbonadium-info.doc (OneDrive - Stark Research Labs).

2. Data Staging (BASE-RD-01, TSK filelist): c:\windows\temp\perfmon\ directory contains:

3. research/Rare-Earth Elements/M&A Targets/ — Annual reports for Orocobre (lithium) and Tronox (titanium minerals)
4. research/Rare-Earth Elements/M&A Targets.zip — Complete ZIP archive for bulk exfiltration
5. sp/m/CONFIDENTIAL - Project Mayhem.pptx

6. sp/c/Cabonadium-CalTech.pdf, Project_800724_WireTransferInfo.docx

7. Cross-Server Staging (BASE-FILE, MFT): Windows\Logs\WindowsServerBackup\6.12\Metal Alloys\Carbonadium directory created Sep 5 13:20:55 — attacker-created path disguised within backup logs. Shares\shieldbase-share\Management\Prospect Analysis\Project Carbonadium folder created Aug 31.

8. Cross-Server Staging (BASE-MAIL 172.16.4.6, Registry): \\172.16.4.6\c$\Windows\Logs\WindowsServerBackup\7.15\csrss.exe accessed Aug 31 19:59:34 — same WindowsServerBackup staging pattern on a different server. This answers Q7: the attacker used WindowsServerBackup directories as staging areas on at least BASE-MAIL (7.15/) and BASE-FILE (6.12/).

9. Exfiltration (BASE-RD-01, bulk_extractor): Five SendSpace upload sessions (fs04u-fs13u.sendspace.com) within 7 minutes on Sep 5 14:14-14:21 UTC. MAX_FILE_SIZE=314572800 (300MB) × 5 = ~1.5GB theoretical capacity. Shared session fingerprint 907909DE.

Q5 ANSWER: While we cannot confirm exactly what was uploaded without PCAP, the temporal correlation is compelling: the SendSpace uploads (Sep 5 14:14-14:21) occurred while p.exe C2 was active, approximately 1 hour after the failed ntdsutil IFM attempt (Sep 5 12:26), and on the same day the WindowsServerBackup staging directory for Carbonadium was created on BASE-FILE (Sep 5 13:20). The M&A Targets.zip archive in the perfmon staging directory was ready for exfiltration. The 1.5GB capacity matches the volume of staged M&A research (8+ annual reports, technical reports, financial results).

ECONOMIC ESPIONAGE ASSESSMENT: The targeted data — rare-earth elements research, lithium mining M&A targets (Orocobre, Tronox), wire transfer documents, and confidential project files — represents strategic economic intelligence in the minerals/mining sector.

Multiple Kerberos service ticket requests (Event ID 4769) with RC4-HMAC encryption (TicketEncryptionType: 0x17) were detected, consistent with Kerberoasting attacks to extract service account password hashes for offline cracking.

Targeted accounts and service principal names:
- nfury@SHIELDBASE.LAN requesting service ticket for SPN "spcontent" (SID: S-1-5-21-3445421715-2530590580-3149308974-1196)
- Source IPs: 172.16.7.15 (multiple ports: 64600, 52498, 54130, 55830)
- Times: 2018-09-04T21:52:31, 2018-09-05T17:28:02, 2018-09-06T03:09:47, 2018-09-06T13:01:45
- All Status: KDC_ERR_NONE (0x0) - successful ticket issuance

• spfarm@SHIELDBASE.LAN requesting service ticket for SPN "spservices" (SID: S-1-5-21-3445421715-2530590580-3149308974-1197)
• Source IP: 172.16.4.7
• Times: 2018-09-04T15:11:48, 2018-09-05T04:00:01, 2018-09-05T12:35:19, 2018-09-05T17:28:18
• Pattern: Initial request with TicketEncryptionType 0x40810000 fails (Status 0x1B KDC_ERR_MUST_USE_USER2USER), followed by successful AES256 (0x12) ticket

The RC4-HMAC (0x17) encrypted tickets for nfury from 172.16.7.15 are the strongest Kerberoasting indicators, as RC4-HMAC is the weakest encryption type and specifically targeted by Kerberoasting tools. The spfarm requests show a different pattern (initial failure then AES256 success) which may indicate legitimate service ticket requests with SPN misconfiguration rather than Kerberoasting.

14 total RC4-HMAC matches found across the investigation window. The recurring pattern across multiple days from the same source IP (172.16.7.15) targeting the same service account suggests sustained credential harvesting activity rather than a one-time event.

PowerShell Script Block Logging (Event 4104, Warning level) on base-file.shieldbase.lan at 2018-08-31T22:52:08 UTC captured the execution of PowerView, a well-known Active Directory reconnaissance and exploitation toolkit from the PowerSploit framework.

Identified PowerView functions in the script block (ScriptBlockId: 15be767e-b86e-4b16-b7bd-31b8251c46ed):
- Add-NetGroupUser - Adds users to domain or local groups
- Get-NetDomain - Enumerates domain information
- User creation via WinNT provider and DirectoryServices.AccountManagement
- Output patterns: "[*] User $UserName successfully created" and "[!] Account already exists!" - characteristic PowerView formatting

Execution context:
- Host: base-file.shieldbase.lan (FILE SERVER, not the DC)
- User SID: S-1-5-21-3445421715-2530590580-3149308974-1193 (spsql account)
- PID: 3580, PPID: 3308
- Logged as Event 4104 Warning (suspicious script detected)

Attack chain significance:
PowerView is step 1 of the observed attack chain:
1. Aug 31: PowerView loaded on file server by spsql for AD reconnaissance
2. Sep 4-6: Kerberoasting attacks from 172.16.7.15 targeting service accounts
3. Sep 5: spsql pivots via WinRM to DC, attempts ntdsutil IFM dump
4. Sep 6: subject_srv.exe malicious service deployed on DC

PowerView capabilities include Invoke-Kerberoast (correlates with the Kerberoasting findings), domain enumeration, trust mapping, and group manipulation. The spsql service account's use of this toolkit confirms the account was compromised and used as the primary attack vehicle.

Affected Systems: evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational

A suspicious binary p.exe (PID 8260) was discovered running on workstation 172.16.6.11 (user: tdungan) from the path c:\windows\temp\perfmon\p.exe. The process was launched through a highly suspicious execution chain consistent with post-exploitation frameworks:

EXECUTION CHAIN (from pstree):
1. WmiPrvSE.exe (PID 2876, PPID 868/svchost DcomLaunch) — WMI provider, likely remotely triggered
2. → powershell.exe (PID 8712) — spawned by WMI at 2018-08-30 16:43:36
3. → powershell.exe (PID 5848, 32-bit SysWOW64) — hidden child at 2018-08-30 16:43:42, args: -Version 5.1 -s -NoLogo -NoProfile
4. → cmd.exe (PID 5948) — at 2018-08-30 22:15:18, runs: cmd.exe /C c:\windows\temp\perfmon\p.exe
5. → p.exe (PID 8260) — at 2018-08-30 22:15:18, still running at memory capture (~7 days later)

SUSPICIOUS INDICATORS:
- WMI-spawned PowerShell: WmiPrvSE→PowerShell is a classic remote code execution pattern (T1047)
- 32-bit PowerShell from SysWOW64: The -s -NoLogo -NoProfile flags indicate a hidden, non-interactive session — consistent with Empire/Cobalt Strike PowerShell agents
- Staging directory: c:\windows\temp\perfmon\ — uses a legitimate-looking folder name in a temp location
- The "perfmon" directory name: matches the path used in the failed ntdsutil IFM attempt on the DC (C:\Windows\Temp\Perfmon) — linking this workstation to the Domain Controller attack activity
- Long-running process: p.exe was active for ~7 days (Aug 30 → Sep 6), suggesting C2 implant persistence
- Malfind RWX allocation: 481 committed pages of PAGE_EXECUTE_READWRITE memory — significant for code injection

NETWORK-CAPABLE DLLs (from dlllist):
- WININET.dll — HTTP/FTP communication
- WS2_32.dll — Windows Sockets
- DNSAPI.dll — DNS resolution
- IPHLPAPI.DLL — IP Helper (network enumeration)
- Secur32.dll, SSPICLI.DLL — Security/authentication
- CRYPTSP.dll, rsaenh.dll, bcrypt.dll — Cryptographic operations

CHILD PROCESSES:
- p.exe spawned 3 short-lived rundll32.exe processes (PIDs 5768, 7552, 1424) on Sep 5-6
- powershell.exe (PID 5848) spawned 6 short-lived rundll32.exe processes on Aug 30-31
- Short-lived rundll32.exe spawning is consistent with Cobalt Strike's fork-and-run pattern for post-exploitation modules

CORRELATION TO DC ATTACK:
The c:\windows\temp\perfmon path on this workstation matches the ntdsutil IFM target path on the Domain Controller, suggesting this workstation was the attacker's pivot point for the AD credential harvesting campaign.

Multiple SendSpace file upload API endpoints were found in the workstation memory (172.16.6.11, user tdungan), indicating potential data exfiltration on September 5, 2018. Five distinct upload sessions were identified, all within a 7-minute window:

UPLOAD SESSIONS (from bulk_extractor URL carving on workstation memory):
1. https://fs13u.sendspace.com/upload?SPEED_LIMIT=0&MAX_FILE_SIZE=314572800&UPLOAD_IDENTIFIER=1214817751.1536159293.907909DE.26.0
2. https://fs09u.sendspace.com/upload?SPEED_LIMIT=0&MAX_FILE_SIZE=314572800&UPLOAD_IDENTIFIER=1615365183.1536159647.907909DE.23.0
3. https://fs04u.sendspace.com/upload?SPEED_LIMIT=0&MAX_FILE_SIZE=314572800&UPLOAD_IDENTIFIER=995630117.1536159435.907909DE.16.0
4. https://fs07u.sendspace.com/upload?SPEED_LIMIT=0&MAX_FILE_SIZE=314572800&UPLOAD_IDENTIFIER=1081460126.1536159373.907909DE.21.0
5. https://fs06u.sendspace.com/upload?...UPLOAD_IDENTIFIER=995630117.1536159435.907909DE...

TEMPORAL ANALYSIS:
The UPLOAD_IDENTIFIER timestamps (Unix epoch, second field) decode to:
- 1536159293 = 2018-09-05 ~14:14:53 UTC
- 1536159373 = 2018-09-05 ~14:16:13 UTC
- 1536159435 = 2018-09-05 ~14:17:15 UTC
- 1536159647 = 2018-09-05 ~14:20:47 UTC

All sessions occurred within a 7-minute window on September 5, 2018. The shared session fingerprint "907909DE" across all identifiers indicates the same browser/session.

EXFILTRATION CAPACITY:
- MAX_FILE_SIZE=314572800 bytes (300 MB) per upload
- 5 distinct upload server endpoints (fs04u, fs06u, fs07u, fs09u, fs13u) suggest multiple files were uploaded in parallel
- Theoretical maximum exfiltration: ~1.5 GB

CORRELATION TO ATTACK CHAIN:
- The SendSpace uploads on Sep 5 occurred while p.exe (C2 implant) was actively running on the same workstation (started Aug 30)
- p.exe loaded USER32.dll and GDI32.dll on Sep 5 at 12:14:36 UTC — approximately 2 hours before the SendSpace uploads
- The failed ntdsutil IFM (NTDS.dit extraction) attempt on the DC also used the c:\windows\temp\perfmon path — the same staging path as p.exe on this workstation
- SendSpace is a free file hosting service that does not require authentication — ideal for exfiltration

ASSESSMENT:
While we cannot confirm the exact files uploaded (no PCAP available), the combination of: (a) an active C2 implant on this workstation, (b) multiple rapid-fire upload sessions to a free file hosting service, and (c) correlation with the AD credential harvesting campaign strongly suggests intentional data exfiltration. The proximity to the Kerberoasting and NTDS.dit extraction attempts raises the possibility that harvested credentials or AD data were exfiltrated via SendSpace.

NOTE: Confidence is "inference" because bulk_extractor URL carving proves the upload page was rendered with valid session identifiers, but cannot definitively confirm files completed uploading without network capture or server-side logs.

Workstation BASE-RD-01 (172.16.6.11, user: tdungan) was compromised via WMI remote execution. The full attack chain from process tree, network connections, and URL evidence paints a picture of an actively controlled workstation used as a pivot point in the SHIELDBASE.LAN domain compromise.

INITIAL ACCESS VIA WMI (T1047):
WmiPrvSE.exe (PID 2876) spawned powershell.exe (PID 8712) at 2018-08-30 16:43:36 — WMI provider spawning PowerShell is the hallmark of remote WMI execution (Invoke-WmiMethod, wmic process call create). The attacker then:
- Spawned a 32-bit hidden PowerShell (PID 5848) at 16:43:42 with -s -NoLogo -NoProfile — consistent with PowerShell Empire or Cobalt Strike stagers
- Deployed p.exe to c:\windows\temp\perfmon\ and executed via cmd.exe at 22:15:18

WORKSTATION NETWORK STATE (from netscan):
Active ESTABLISHED connections:
- 172.16.6.11:59352 → 172.16.7.15:445 (SMB — file server access or lateral movement)
- 172.16.6.11:49763 → 172.16.4.5:445 (SMB to BASE-FILE file server)
- 172.16.6.11:445 ← 172.16.6.14:65368 (inbound SMB — another host connecting to this workstation)
- 172.16.6.11:3262 ← 172.16.5.50:39372 (F-Response — legitimate IR)
- Multiple connections to 172.16.4.10:8080 (McAfee ePO — legitimate management)

Closed connections of interest:
- 6+ RDP sessions to 172.16.4.5:3389 (BASE-FILE) — extensive RDP to file server
- 172.16.6.11 → 172.16.5.21:5985 (WinRM) — remote management/lateral movement
- 172.16.6.11 → 172.16.4.4:389 (LDAP to Domain Controller) — AD queries
- 172.16.6.11 → 52.16.55.11:443 (external HTTPS) — potential C2 or cloud service

WinRM ENABLED:
Port 5985 is LISTENING on this workstation (System process), confirming WinRM is enabled. This is the likely vector through which the attacker remotely executed WMI commands to establish the PowerShell → p.exe chain.

ATTACK TIMELINE CORRELATION:
- 2018-08-30 16:43: WMI-spawned PowerShell chain initiated (attacker gains execution)
- 2018-08-30 22:15: p.exe deployed and executed (C2 implant established)
- 2018-08-30 → 2018-09-06: p.exe continuously running, spawning rundll32 for post-exploitation
- 2018-09-05 ~14:14-14:21 UTC: SendSpace file uploads (potential data exfiltration)
- 2018-09-05 15:15: F-Response installer staged (IR team becomes active)
- 2018-09-06 18:28: F-Response deployed to this workstation (IR collection)

The workstation was actively compromised for approximately 6-7 days before the IR team deployed F-Response to acquire memory. The "perfmon" staging directory name matches the ntdsutil IFM target on the DC, linking this workstation to the Domain Controller credential harvesting campaign.

The compromised spsql service account accessed sensitive proprietary research data on BASE-RD-01 (172.16.6.11, user tdungan's workstation). MFT evidence shows:

Targeted Research Data:
- Users\tdungan\Documents\Research\Carbonadium\Cabonadium-CalTech.pdf (5.9 MB, created 2018-07-18 15:12:10) — CalTech research paper
- Users\tdungan\OneDrive - Stark Research Labs\Research\carbonadium-info.doc (54 KB, created 2018-07-26 04:01:16) — synced to corporate OneDrive

Attacker Access Evidence:
- Users\spsql\AppData\Roaming\Microsoft\Office\Recent\carbonadium-info.LNK (1,309 bytes, created 2018-08-28 21:45:57) — proves spsql opened carbonadium-info.doc via Microsoft Office on this workstation. LNK files in Office\Recent are created when a user opens a document.

Data Staging/Movement Timeline:
- 2018-07-18: tdungan creates original research (CalTech PDF)
- 2018-07-26: carbonadium-info.doc created in OneDrive sync folder
- 2018-08-28 21:43: Both research files' last access timestamps updated (last access on CalTech PDF and carbonadium-info.doc)
- 2018-08-28 21:45:57: spsql opens carbonadium-info.doc (LNK created)
- 2018-08-31: Shares\shieldbase-share\Management\Prospect Analysis\Project Carbonadium folder created on file server — research data moved to share
- 2018-09-05 13:20:55: Windows\Logs\WindowsServerBackup\6.12\Metal Alloys\Carbonadium directory created on file server — suspicious staging path disguised within backup logs
- 2018-09-06 21:37:19: Users\tdungan\AppData\Roaming\Microsoft\Windows\Recent\Carbonadium.lnk — user tdungan accessed the Carbonadium folder

Significance:
The spsql account is a SQL service account that was compromised and used for PowerView reconnaissance (Aug 31) and ntdsutil IFM attempts (Sep 5). Its access to carbonadium-info.doc on Aug 28 predates the publicly visible attack activity, suggesting the attacker had access to the spsql account earlier than the reconnaissance phase. The combination of research document access with subsequent data exfiltration via SendSpace (Sep 5) raises concerns that proprietary research data may have been stolen.

The Windows\Logs\WindowsServerBackup\6.12\Metal Alloys\Carbonadium path on the file server is particularly suspicious — legitimate Windows Server Backup does not create "Metal Alloys" subdirectories. This appears to be attacker-created data staging disguised within system log directories.

Network connections from BASE-RD-01 (172.16.6.11) captured in the memory dump (Volatility netscan) reveal extensive communication with multiple domain systems, consistent with the workstation being used as a pivot point for lateral movement.

ESTABLISHED Connections at Time of Capture:
1. 172.16.6.11:59352 → 172.16.7.15:445 (SMB) — 172.16.7.15 is the source IP of Kerberoasting attacks (Event ID 4769 with RC4-HMAC encryption). This ESTABLISHED SMB connection links base-rd-01 directly to the Kerberoasting source.
2. 172.16.6.11:49763 → 172.16.4.5:445 (SMB to BASE-FILE) — connection to file server where PowerView was executed and sensitive shares are hosted
3. 172.16.6.11:445 ← 172.16.6.14:65368 (Inbound SMB) — another system connecting TO this workstation, potentially another compromised host or the attacker's pivot chain
4. Multiple connections to 172.16.4.10:8080 (ESTABLISHED and CLOSE_WAIT) — McAfee ePO management server (legitimate)

CLOSED Connections (Recent Activity):
5. 172.16.6.11 → 172.16.4.5:3389 (6+ RDP sessions to BASE-FILE) — extensive Remote Desktop access to the file server, with multiple source ports indicating repeated sessions
6. 172.16.6.11 → 172.16.5.21:5985 (WinRM) — remote management to 172.16.5.21 (IP associated with rsydow-a admin account)
7. 172.16.6.11 → 172.16.4.4:389 (LDAP to Domain Controller) — Active Directory queries
8. 172.16.6.11 → 13.89.220.65:443 (External HTTPS) — Microsoft Azure IP
9. 172.16.6.11 → 52.16.55.11:443 (External HTTPS) — potential cloud/CDN

LISTENING Services:
- Port 3389 (RDP) — Remote Desktop enabled
- Port 5985 (WinRM) — Windows Remote Management enabled (unusual for a workstation)
- Port 445 (SMB) — Standard file sharing
- Port 3262 (F-Response) — Forensic collection agent

Key Correlation:
The ESTABLISHED SMB connection from base-rd-01 to 172.16.7.15:445 is forensically significant because 172.16.7.15 is the source IP of Kerberoasting attacks targeting the nfury service account (SPN: spcontent) on Sep 4-6. The spsql account authenticated from 172.16.6.11 (base-rd-01) to the DC at 2018-09-05 11:51:52. Together, these connections position base-rd-01 as the central pivot point: compromised via WMI on Aug 30, used for Kerberoasting (via 172.16.7.15), AD reconnaissance, and ultimately the ntdsutil IFM attack against the DC.

A custom command-and-control implant was identified on base-rd-02, masquerading as a Microsoft component under the directory name "Microsoft Advanced API 32/64" in Program Files (x86). The implant consists of:

Installed components (Program Files (x86)/Microsoft Advanced API 64/):
- msadvapi2_64.exe — the main 64-bit implant executable
- rabbitmq.4.dll — RabbitMQ AMQP client library
- SimpleAmqpClient.2.dll — AMQP client library
- libcryptoMD.dll, libsslMD.dll — OpenSSL crypto/TLS libraries
- ca_certificate.pem — CA certificate for TLS communication
- winpcap-nmap-4.13.exe — Nmap WinPcap packet capture installer
- vc_redist.x64.exe — Visual C++ redistributable dependency
- unins000.exe/dat — uninstaller

A parallel 32-bit version exists in "Microsoft Advanced API 32/" with winpcap-nmap-4.13.exe.

Staging and deployment evidence (ProgramData/staging/install_wormhole/):
- install_msadvapi2_32.exe (inode 6446) — 32-bit installer
- install_msadvapi2_64.exe (inode 6402) — 64-bit installer
- Registry (Amcache) records execution of install_msadvapi2_32.exe at 2018-05-08T21:07:43Z

Active in memory (Volatility psscan):
- msadvapi2_64.exe (PID 2328, PPID 760/services.exe) — created 2018-08-19T06:23:13Z, Session 0
- msadvapi2_32.exe (PID 2292, PPID 760/services.exe) — created 2018-08-19T06:23:13Z, Session 0, Wow64=True

C2 network activity (Volatility netscan):
- 10.10.150.180 → 10.10.200.207:5672 ESTABLISHED (AMQP/RabbitMQ — confirmed C2 channel)
- 10.10.150.180 → 10.10.254.1:61613 ESTABLISHED (ActiveMQ STOMP — secondary message queue)

The implant communicates via enterprise message queuing protocols (AMQP/RabbitMQ on port 5672, STOMP on port 61613) to blend with legitimate infrastructure. Both processes run as services under services.exe in Session 0, indicating persistence via Windows service registration. The deceptive naming ("Microsoft Advanced API") is designed to evade casual inspection.

The staging directory also contains 7za.exe (7-Zip CLI), suspicious certificate files (NotVerisign.cer, NewNotVeriSign.cer, lariatca.cer), and Lariat-9.4.1-install.exe — suggesting additional tools were deployed through this staging area.

A keylogger suite was identified at ProgramData/perfmon-k/ on base-rd-02, disguised as a Windows Performance Monitor component. The naming convention of the component files strongly indicates keyboard capture functionality:

Files identified (ProgramData/perfmon-k/):
- perfmon-khk.dll (inode 148036) — "khk" likely keyboard hook DLL
- perfmon-ki.dll (inode 148042) — "ki" likely keyboard input interceptor
- perfmon-kr.exe (inode 148043) — "kr" likely key recorder executable
- perfmon-kvw.exe (inode 148040) — "kvw" likely key viewer/writer
- perfmon-kwb.dll (inode 148041) — "kwb" likely key write-back DLL
- pkl.bin (inode 3134) — likely pickled/stored keystroke data
- web.dt (inode 120226) — web data capture file
- opt.dat (inode 120972) — configuration options
- install.bin (inode 148050-alt) — binary installer data
- install.log (inode 148050) — installation log

MFT timestamps (ez.mft):
- web.dt created: 2017-08-31T17:33:47Z
- web.dt last modified: 2018-08-31T21:42:47Z (SI timestamps)
- web.dt $FN modified: 2018-08-31T21:44:36Z

The web.dt file was actively being written to on 2018-08-31, during the known attack window, confirming the keylogger was operational. The keylogger installation dates back to at least 2017-08-31, indicating long-term persistent credential harvesting. This is a dedicated credential theft tool likely used to capture passwords for lateral movement across the environment.

Memory forensics (Volatility psscan) reveals a multi-stage attack chain initiated via WMI on base-rd-02:

Process chain (2018-08-30):
1. WmiPrvSE.exe (PID 2876) — WMI Provider Host, started the chain
2. → powershell.exe (PID 8712, PPID 2876) — Created 2018-08-30T16:43:36Z, Session 0
3. → powershell.exe (PID 5848, PPID 8712) — Created 2018-08-30T16:43:42Z, Session 0, Wow64=True (32-bit on 64-bit system)
4. → cmd.exe (PID 5948, PPID 5848) + conhost.exe (PID 1740, PPID 5848)
5. → p.exe (PID 8260, PPID 5848) — Created 2018-08-30T22:15:18Z — single-letter executable, highly suspicious

Suspicious child processes spawned by PID 5848 (32-bit PowerShell):
- rundll32.exe (PID 6768) at 18:31:04 (exited 18:31:35)
- rundll32.exe (PID 5452) at 21:40:18 (exited 21:40:23)
- rundll32.exe (PID 5588) at 21:40:42 (exited 21:40:54)
- rundll32.exe (PID 2216) at 22:31:57 (exited 22:32:19) — Wow64=True
- rundll32.exe (PID 4108) at 22:45:25 (exited 22:45:30)
- rundll32.exe (PID 8148) at 2018-08-31T00:56:14 (exited 00:56:30) — Wow64=True

Key indicators:
- WMI-initiated remote execution (T1047)
- 32-bit PowerShell on 64-bit system (common technique to avoid AMSI/constrained language mode)
- Six separate rundll32.exe spawns over ~6 hours, each running briefly (seconds to minutes) — consistent with reflective DLL injection or payload staging
- Single-letter executable "p.exe" — often used for attacker post-exploitation tools
- All running in Session 0 (system context, not interactive)

The attack activity spans from 16:43 to at least 00:56 the next day, indicating sustained post-exploitation operations. The pattern of short-lived rundll32.exe processes is consistent with in-memory payload execution via DLL injection.

Multiple indicators of lateral movement were identified on base-rd-02, including the presence of the compromised spsql user account and extensive outbound RDP/WinRM/SMB connections.

Compromised account activity:
- spsql user profile exists at Users/spsql/ with full interactive session artifacts (Documents, INetCache, INetCookies, Start Menu, Vault)
- spsql profile contains image files (.jpg) in Documents folder with MFT timestamps showing access on 2018-08-31 (~00:18) during the attack window
- INetCache entries modified on 2018-08-31 (21:10, 21:54) indicate the spsql user was interactively browsing during the attack
- PowerShell transcripts from BASE-FILE and BASE-RD-01 found in spsql's Documents, indicating remote PS sessions were established from other compromised hosts
- rsydow-a profile also present with PowerShell transcripts from BASE-DC and BASE-FILE

Outbound RDP connections (netscan, from 172.16.6.11):
- Multiple CLOSED connections to 172.16.4.5:3389 (source ports: 63823, 63826, 63828, 63834, 63835, 63841, 63848, 63958) — extensive RDP usage to file server

WinRM connections:
- 172.16.6.11 → 172.16.5.21:5985 CLOSED (WinRM)
- 172.16.6.12 → 172.16.5.21:5985 CLOSED (WinRM)
- 172.16.7.11 → 172.16.5.21:5985 ESTABLISHED (WinRM — active at capture time)
- System LISTENING on port 5985 and 47001 — WinRM enabled inbound

SMB connections:
- 172.16.6.11 → 172.16.7.15:445 ESTABLISHED (outbound SMB)
- 172.16.6.11 → 172.16.4.5:445 ESTABLISHED (outbound SMB to file server)
- 172.16.6.14 → 172.16.6.11:445 ESTABLISHED (inbound SMB)
- 172.16.6.12 → 172.16.6.11:139 CLOSED (inter-NIC SMB)

Other connections:
- 172.16.6.11 → 172.16.4.4:389 LDAP (domain controller queries)
- 172.16.6.11 → 13.89.220.65:443 and 52.16.55.11:443 (external HTTPS)

The combination of compromised account presence, extensive RDP to the file server (8+ sessions), active WinRM to 172.16.5.21, and SMB connectivity demonstrates this host was used as a lateral movement pivot point.

Security EVTX analysis reveals the domain account shieldbase\spsql (SID: S-1-5-21-3445421715-2530590580-3149308974-1193) was used extensively for network logons (LogonType 3) to base-rd-02, originating from multiple compromised systems. The account had administrative privileges on every logon.

Confirmed spsql network logon events (Event ID 4624, LogonType 3):
- 2018-08-25T21:03:15Z — Source: BASE-RD-04 (172.16.6.14), LogonId: 0xBC356DF
- 2018-08-25T21:08:24Z — Source: 172.16.6.14, followed by Event 4672 administrative logon
- 2018-08-28T22:16:14Z — Source: BASE-RD-01 (172.16.6.11), LogonId: 0x11796F74, followed by Event 4672 administrative logon
- 2018-08-30T23:55:59Z — Source: BASE-RD-01 (172.16.6.11)
- Total spsql-related events: 462 matches across the Security log

Administrative privilege assignment (Event ID 4672) for spsql includes:
SeImpersonatePrivilege, SeDelegateSessionUserImpersonatePrivilege, SeLoadDriverPrivilege, SeBackupPrivilege, SeRestorePrivilege — full administrative access

Authentication failure context (Q-CA10):
974 Event ID 4625 (failed logon) events were found in the Security log. COUNTER-ANALYSIS NOTE: In a SharePoint environment, service account authentication failures are common due to Kerberos delegation, application pool recycling, and SPN misconfiguration. The 858 Event ID 4648 (explicit credential logon) events similarly include legitimate SharePoint/SQL service account credential delegation. These failure counts alone do NOT confirm brute-force activity — the primary evidence for spsql compromise is the SUCCESSFUL administrative logons from non-SharePoint systems (BASE-RD-01, BASE-RD-04) outside the SharePoint infrastructure, combined with the attacker's use of this same account for PowerView execution and ntdsutil IFM attempts.

Lateral movement source systems:
- BASE-RD-01 (172.16.6.11) — confirmed as a source of spsql logons to base-rd-02
- BASE-RD-04 (172.16.6.14) — confirmed as a source of spsql logons to base-rd-02

Registry execution evidence (amcache/shimcache) on the workstation records execution of a csrss.exe binary at the highly suspicious UNC path:

\\172.16.4.6\c$\Windows\Logs\WindowsServerBackup\7.15\csrss.exe
- Execution timestamp: 2018-08-31 19:59:34 UTC
- Host 172.16.4.6 corresponds to BASE-MAIL in the SHIELDBASE.LAN domain

Why this is suspicious:
1. csrss.exe (Client/Server Runtime Subsystem) is a critical Windows system process that legitimately exists ONLY at C:\Windows\System32\csrss.exe. Any csrss.exe outside System32 is a strong indicator of masquerading malware.
2. The path Windows\Logs\WindowsServerBackup\7.15\ is not a standard Windows Server Backup directory structure. The "7.15" subdirectory appears attacker-created.
3. This path pattern matches other attacker staging paths found in this investigation: Windows\Logs\WindowsServerBackup\6.12\Metal Alloys\Carbonadium\ (used for data staging on the file server, per finding f_878b93c8).
4. The binary was accessed via SMB administrative share (c$) from the workstation, indicating lateral movement/remote file access.
5. The timestamp (Aug 31) falls within the active attack window (Aug 30 WMI compromise through Sep 6 IR response).

Correlation:
- BASE-RD-01 (172.16.6.11) had an ESTABLISHED SMB connection to BASE-FILE (172.16.4.5:445) and multiple RDP sessions
- The attacker's use of WindowsServerBackup directories for staging is a recurring pattern across at least two systems (BASE-MAIL 172.16.4.6 and BASE-FILE 172.16.4.5)
- This suggests BASE-MAIL may also have been compromised and used for malware/tool staging

The registry records this as program execution evidence, meaning the binary was either executed on the workstation or tracked via ShimCache as a file existence indicator. Either way, the presence of a csrss.exe binary at this non-standard path on BASE-MAIL is a confirmed indicator of compromise.

The dedicated EZ Tools for prefetch, amcache, and shimcache extraction all failed during processing of base-wkstn-01 evidence. However, registry.system sources (parsed via RegRipper across multiple systems) contain equivalent execution evidence that corroborates the attack timeline:

Attacker Tools Confirmed in Registry Execution Records:

1. c:\windows\temp\perfmon\p.exe — First execution: 2018-08-30 22:14:02 (registry.system source_id 117)

2. Confirms p.exe was executed on this date, correlating with the Volatility process tree showing p.exe (PID 8260) created at 22:15:18

3. Windows\Temp\perfmon\PerfView.exe — Build timestamp: 2009-07-14 01:16:21 (registry.system source_id 130)

4. PerfView is a legitimate Microsoft .NET performance profiling tool
5. Its presence in the same staging directory as p.exe suggests the attacker either:
   a) Used PerfView as a cover story for the "perfmon" directory name
   b) Used PerfView's legitimate functionality for profiling/reconnaissance

6. The 2009 compile date matches the original Microsoft release

7. C:\ProgramData\staging\install_wormhole\install_msadvapi2_32.exe — Executed: 2018-05-08 21:07:43 (registry.system sources 144, 228)

8. Confirmed across TWO registry system hives from different systems
9. Second timestamp: 2018-05-08 21:13:21 (source_id 228 — different system)

10. This is the installer for the custom msadvapi2 C2 implant on base-rd-02

11. C:\Program Files (x86)\Microsoft Advanced API 32\winpcap-nmap-4.13.exe — Executed: 2018-02-26 22:47:31 (registry.system source_id 214)

12. WinPcap/Nmap packet capture driver installed via the "Microsoft Advanced API" masquerading directory

13. C:\Program Files (x86)\Microsoft Advanced API 64\winpcap-nmap-4.13.exe — Executed: 2018-02-26 22:47:31 (registry.system source_id 178)

14. Both 32-bit and 64-bit versions installed on the same date

15. Reconnaissance Tools in Registry:

16. findstr.exe, systeminfo.exe, schtasks.exe, nslookup.exe, netsh.exe — all with execution timestamps in the investigation window
17. These are standard Windows utilities commonly used in post-exploitation reconnaissance

MFT Corroboration:
The ez.mft source confirms the install_msadvapi2_32.exe file metadata:
- MFT entry inode cluster at source_id 105, created 2017-12-20 14:52:51
- Size: 14,183,796 bytes (~14 MB)
- Archive attribute, Windows format
- Modified timestamp aligns with registry execution date (2018-05-08)

This registry evidence compensates for the failed EZ Tools extraction and provides a comprehensive picture of attacker tool execution across both workstations.

A multi-stage attack chain was executed on base-wkstn-05 (172.16.6.11, user: tdungan) beginning 2018-08-30. The chain is:

1. WmiPrvSE.exe (PID 2876) spawned PowerShell (PID 8712) at 2018-08-30 16:43:36 — classic WMI remote execution pattern indicating the attacker used WMI from another host to execute code.

2. PowerShell PID 8712 (64-bit) spawned a 32-bit PowerShell (PID 5848) with flags "-Version 5.1 -s -NoLogo -NoProfile" — the -s (stdin) flag and -NoProfile indicate a scripted/automated session, not interactive use.

3. PowerShell PID 5848 spawned cmd.exe (PID 5948) which launched "c:\windows\temp\perfmon\p.exe" (PID 8260) at 2018-08-30 22:15:18.

4. p.exe (PID 8260) and PowerShell (PID 5848) subsequently spawned multiple rundll32.exe instances over the period 2018-08-30 through 2018-09-06, indicating persistent malicious activity.

The executable p.exe is a single-character-named binary staged in a deceptively named directory (perfmon — mimicking the Windows Performance Monitor). Volatility malfind identifies p.exe (PID 8260) with a VadS region having PAGE_EXECUTE_READWRITE protection and 481 commit charge, indicating code injection or unpacking behavior. PowerShell PID 8712 also has 3 VadS regions with RWX permissions.

This chain is confirmed by three independent Volatility plugins: pstree (parent-child relationships), cmdline (command arguments), and malfind (code injection detection).

Network connections from base-wkstn-05 (172.16.6.11) show extensive lateral movement to multiple internal hosts:

RDP to 172.16.4.5 (7 connections):
- Ports 63823, 63828, 63834, 63835, 63841, 63848, 63958 → 172.16.4.5:3389 (all CLOSED)
Multiple sequential RDP connections indicate interactive remote desktop sessions, likely for hands-on-keyboard operations on the target host.

SMB to 172.16.4.5:
- 172.16.6.11:49763 → 172.16.4.5:445 ESTABLISHED (active at capture time)
Concurrent SMB and RDP to the same host suggests file transfer alongside remote desktop access.

WinRM to 172.16.5.21:
- 172.16.6.11:49791 → 172.16.5.21:5985 CLOSED
WinRM (Windows Remote Management) enables remote command execution via PowerShell remoting.

LDAP to Domain Controller 172.16.4.4:
- 172.16.6.11:56345 → 172.16.4.4:389 CLOSED
LDAP query to the domain controller, consistent with Active Directory reconnaissance.

Inbound SMB from 172.16.6.14:
- 172.16.6.14:65368 → 172.16.6.11:445 ESTABLISHED (active at capture time)
Another host (172.16.6.14) has an active SMB connection into wkstn-05, indicating this workstation was also accessed from other compromised systems.

This pattern demonstrates a hub-and-spoke lateral movement architecture with base-wkstn-05 serving as both a pivot point (reaching 172.16.4.5, 172.16.5.21) and a target (from 172.16.6.14).

Affected Systems: volatility.netscan

Volatility malfind detected suspicious memory regions in the attacker's processes on base-wkstn-05:

p.exe (PID 8260):
- VadS region with PAGE_EXECUTE_READWRITE protection and 481 commit charge
- This is a large RWX memory allocation indicating code injection, unpacking, or reflective loading behavior
- The process loaded standard Windows API DLLs (ADVAPI32, sechost, RPCRT4) at 2018-08-30 22:15:19, confirming execution timing
- Running from c:\windows\temp\perfmon\p.exe — the attacker's staging directory

PowerShell (PID 8712):
- 3 separate VadS regions with PAGE_EXECUTE_READWRITE protection
- This is the initial WMI-spawned PowerShell instance that established the attack chain
- Multiple RWX regions in a scripted PowerShell session (-s -NoLogo -NoProfile) suggest in-memory payload loading, likely download-execute cradles

Code injection in both the initial access tool (PowerShell) and the dropped malware (p.exe) indicates a multi-stage attack with in-memory-only payloads designed to evade disk-based detection.

Note: YARA memory scanning results indexed in this case (yara.memory) are from base-dc-memory, not base-wkstn-05-memory. YARA scanning of the wkstn-05 memory dump was not indexed, so signature-based malware identification for p.exe is not available from this source.

Internal IP 172.16.5.26 conducted extensive FTP file transfer operations on the DMZ-FTP server (172.16.10.12) on 2018-08-07, using multiple accounts in rapid succession:

1. Anonymous access (23:30:07): Used USER anonymous / PASS IEUser@ (Internet Explorer default anonymous credentials), retrieved files from /Users/ directory (RETR /Users/), navigated to /Users/n
2. nfury account (23:30:56): Authenticated as DMZ-FTP
   fury (230 success), performed SIZE, MDTM (timestamp check), RETR /Users/ file operations, LIST directory listings, navigated /Users/n directories
3. dblake account (23:32:23): Authenticated as DMZ-FTP\dblake (230 success), performed SIZE, MDTM, RETR /Users/ file operations, multiple LIST commands
4. dblake re-authentication (23:36:25-23:36:45): First failed (530) then re-authenticated (230), performed LIST -l (detailed listing) then QUIT
5. dblake third session (23:37:21): Another successful authentication, more SIZE and RETR operations
6. Anonymous re-access (23:40:30): Further RETR /Users/ operations from anonymous access

The pattern shows systematic enumeration and retrieval of files from user directories using three different access methods (anonymous, nfury, dblake) within a 10-minute window. This is consistent with automated data collection or lateral movement from another internal host. The IP 172.16.5.26 is on the corporate VLAN (172.16.5.0/24), not the DMZ.

Affected Systems: bulk.domain

On 2018-09-07, internal IP 172.16.5.26 made WebDAV requests to the DMZ-FTP server (172.16.10.12) targeting administrative shares:

1. OPTIONS /c$ - WebDAV capability probe against the C$ administrative share (full drive access)
2. OPTIONS /srl-ftp - WebDAV probe against what appears to be a custom FTP share

The use of WebDAV OPTIONS requests against the C$ administrative share represents an attempt to access the entire C: drive of the DMZ-FTP server via the web. If successful, this would grant full filesystem access. The C$ share is a Windows administrative share that should only be accessible to administrators, and its exposure via WebDAV indicates either misconfiguration or the use of valid administrator credentials.

This activity from 172.16.5.26 (which also performed the multi-account FTP file retrieval on 2018-08-07) suggests this internal host was used for persistent lateral movement activities targeting the DMZ-FTP server across multiple weeks.

Affected Systems: bulk.httplogs

The DMZ-FTP server (172.16.10.12) was targeted through multiple vectors during the investigation period:

PHASE 1 - Normal Operations / Initial Exposure (May-Jul 2018):
- FTP service (IIS FTPSVC2) operational with logs beginning May 2018
- 2018-07-16: External IP 108.79.235.64 performed RETR test.txt operation - appears associated with VPN/Remote Access activity based on SoftEther VPN records in carved data

PHASE 2 - External Scanning and Brute-Force (Aug 2018):
- 2018-08-07 23:30-23:40: Internal IP 172.16.5.26 conducted systematic file retrieval using multiple accounts (anonymous, nfury, dblake) within 10 minutes
- 2018-08-07 23:57: External IP 112.91.58.238 attempted USER root login (530 failure)
- 2018-08-15: External IP 138.197.213.41 probed port 21 with HTTP HEAD/POST
- 2018-08-27 03:05: External IP 185.128.26.19 browsed /Users/n directory

PHASE 3 - Active Compromise via External IP (Sep 3-5, 2018):
- 2018-09-03 18:20: External IP 165.227.50.129 authenticated, performed LIST, CWD directory traversal
- 2018-09-04 17:38: Nmap NSE scan from DMZ host 172.16.10.13
- 2018-09-04 18:26: 165.227.50.129 returned with PORT and DataChannel operations
- 2018-09-05 16:37: 165.227.50.129 authenticated as DMZ-FTP\rsydow-f (230 success)
- 2018-09-05 18:47: 165.227.50.129 accessed PowerShell directory via CWD

PHASE 4 - Lateral Movement Attempt (Sep 7, 2018):
- 2018-09-07: 172.16.5.26 attempted WebDAV access to C$ administrative share and /srl-ftp share

KEY OBSERVATIONS:
1. The rsydow-f account credentials were compromised and used by external IP 165.227.50.129
2. Internal host 172.16.5.26 was likely compromised and used for both FTP data theft and WebDAV access attempts
3. DMZ host 172.16.10.13 was used for internal reconnaissance of the FTP server
4. The FTP server was exposed to the internet, receiving ongoing brute-force and scanning attempts

Affected Systems: bulk.domain, bulk.httplogs, tsk.filelist

Timestamp correlation and directory co-location provide strong circumstantial evidence that the attacker abused the Puppet configuration management infrastructure to deploy the msadvapi2 implant to base-rd-02 and potentially other managed hosts.

EVIDENCE CONVERGENCE FROM 3 SOURCES:

1. Filesystem (tsk.filelist on base-rd-02): ProgramData/PuppetLabs/ contains extensive Puppet infrastructure with client catalogs, clientbucket content hashes, SSL certificates (including base-rd-01.pem), and MCollective agent packages (mcollective_agents/*.zip in ProgramData/staging/). The staging directory contains BOTH Puppet/MCollective packages AND the msadvapi2 installers side-by-side.

2. MFT Timestamps (ez.mft): install_msadvapi2_32.exe was:

3. Created: 2017-12-20 14:52:51 (initial staging)

4. Modified/Executed: 2018-05-08 21:07:43 (deployment)
   Puppet cache entries were updated at 2018-05-08 21:07-21:13 — overlapping PRECISELY with msadvapi2 deployment within a 6-minute window.

5. Registry Execution Records (registry.system): install_msadvapi2_32.exe execution confirmed at 2018-05-08 21:07:43 across TWO independent registry hives from different systems (source_ids 144 and 228), proving deployment occurred on multiple hosts.

PUPPET INFRASTRUCTURE SCOPE:
- Puppet SSL directory contains certificates for base-rd-01 and base-rd-02, confirming both workstations were Puppet-managed
- MCollective agent packages in the staging directory suggest the attacker could have used MCollective's orchestration capabilities to push installers to all managed nodes
- The "install_wormhole" subdirectory name explicitly references worm-like propagation

Q8 ANSWER: The timestamp correlation (Puppet cache updates at 21:07-21:13, msadvapi2 installation at 21:07:43) is too precise to be coincidental. The co-location of MCollective packages with msadvapi2 installers in ProgramData/staging/ further supports this. Puppet managed at least BASE-RD-01 and base-rd-02 based on SSL certificates. The 7za.exe (7-Zip CLI) in the staging directory was likely used to package and distribute the installers. However, without Puppet server logs or catalog definitions, we cannot confirm the exact deployment mechanism with certainty.

Affected Systems: ez.mft, registry.system, tsk.filelist

The external FTP compromise (165.227.50.129 authenticating as rsydow-f to DMZ-FTP 172.16.10.12) represents a SEPARATE attack vector from the internal spsql-based attack chain, but evidence suggests the same threat actor.

EVIDENCE FOR SAME ACTOR:
1. Temporal Overlap: External FTP activity (Sep 3-5) coincides precisely with the internal Kerberoasting (Sep 4-6) and ntdsutil IFM attempt (Sep 5 12:26)
2. Operational Security Pattern: Both attack vectors use legitimate credentials rather than exploits — rsydow-f for FTP, spsql for internal operations
3. Reconnaissance Focus: The FTP attacker navigated to the "PowerShell" directory (Sep 5 18:47:57), which aligns with the internal attacker's extensive PowerShell-based operations
4. Internal Correlate: Internal host 172.16.5.26 also accessed the FTP server using multiple accounts (anonymous, nfury, dblake) on Aug 7 and attempted WebDAV C$ access on Sep 7 — this may be the same actor operating from inside

EVIDENCE FOR INDEPENDENT COMPROMISE:
1. Different Network Segment: The FTP server (172.16.10.12) is in the DMZ (172.16.10.0/24), while the internal attack operates in the corporate network (172.16.4.x, 172.16.6.x, 172.16.7.x)
2. Different Account Families: rsydow-f is a local FTP account, distinct from the domain spsql service account
3. Different Infrastructure: 165.227.50.129 is a DigitalOcean VPS, while the internal C2 uses enterprise AMQP/RabbitMQ

Q9 ASSESSMENT: Most likely the SAME threat actor operating through two parallel attack vectors — internal (spsql/PowerView/Kerberoasting from compromised workstations) and external (FTP via compromised rsydow-f credentials from a VPS). The temporal synchronization of activity on Sep 3-5 and the consistent use of credential-based access (rather than exploits) across both vectors supports a single actor with multiple access paths. The internal host 172.16.5.26 may represent a previously compromised system bridging the DMZ and corporate networks.

Additional Context: The Cobalt Strike reference (www.cobaltstrike.com URL found in bulk_extractor) and the Nmap scan from DMZ host 172.16.10.13 on Sep 4 suggest the attacker had tools and access in the DMZ network as well.

Affected Systems: bulk.domain, bulk.httplogs, tsk.filelist

Cross-referencing Kerberoasting source IP 172.16.7.15 with BASE-RD-01 (172.16.6.11) network connections reveals a direct ESTABLISHED SMB connection, answering Q2 about their relationship.

CONVERGENCE FROM 3 INDEPENDENT SOURCES:

1. DC Security EVTX: 14 Kerberos service ticket requests (Event ID 4769) with RC4-HMAC encryption (0x17) from 172.16.7.15 targeting nfury@SHIELDBASE.LAN for SPN "spcontent" across Sep 4-6. RC4-HMAC downgrade is the signature of Kerberoasting tools (Invoke-Kerberoast, Rubeus).

2. BASE-RD-01 Memory (Volatility netscan): ESTABLISHED TCP connection 172.16.6.11:59352 → 172.16.7.15:445 (SMB). This workstation also has connections from 172.16.6.14 (BASE-RD-04) inbound and shows multiple IPs in its netscan output.

3. BASE-RD-01 Memory (Volatility netscan, subject_srv.exe): subject_srv.exe listening on MULTIPLE interfaces: 172.16.6.11:3262, 172.16.6.12:3262, and 172.16.7.11:3262. The presence of 172.16.7.11 (different /24 subnet from 172.16.7.15) suggests this system has network interfaces on multiple VLANs.

Q2 ANSWER: 172.16.7.15 is most likely a SEPARATE HOST that BASE-RD-01 has an active SMB connection to (not a second NIC on BASE-RD-01 itself, since BASE-RD-01's own IPs appear to be 172.16.6.11 and potentially 172.16.7.11). The ESTABLISHED SMB connection from BASE-RD-01 to 172.16.7.15 suggests the attacker used this host as a Kerberoasting launch point, possibly by mounting a share or executing commands remotely via SMB. Alternatively, 172.16.7.15 may be another compromised workstation in the 172.16.7.0/24 subnet from which the attacker ran Kerberoasting tools while maintaining an SMB channel back to their primary pivot (BASE-RD-01).

The multi-VLAN footprint (172.16.6.x, 172.16.7.x) increases the attacker's reach and makes network segmentation-based detection more difficult.

The file server (base-file.shieldbase.lan) hosts multiple network shares containing sensitive corporate data accessible to domain users:

1. Shares/shieldbase-share/ - Main company share containing:
2. Case Files/Project P.E.G.A.S.U.S/ - Project files including Tesseract Overview_MH.pptx
3. Management/Board Presentations/ - Board-level documents
4. Management/Scrapped HQ Site/ - HQ site images
5. R&D/Mayhem/ - Contains CONFIDENTIAL - Project Mayhem.pptx (temp file ~$ prefix was DELETED)

6. Public/Company Events/ - Photos (some deleted/reallocated)

7. Shares/Installers/ - Software repository containing:

8. SysInternals/SysinternalsSuite/ - Full Sysinternals suite including PsExec.exe
9. Office/setup.exe - Office installer
10. Proxy/Asgard CA Cert/ca.crt - CA certificate

11. SysInternals/Sysmon/ - Sysmon executables

12. Shares/SRL-Admin/ - Administrative tools for AD including Google ADMX templates

Notable deleted files on the shares include:
- ~$CONFIDENTIAL - Project Mayhem.pptx (deleted temp file, indicating document was recently opened)
- ~$collaborationSpreadSheetDoc1741378862225908156.xlsx (deleted)
- Various reallocated image files in Public/Company Events/

The presence of PsExec.exe on the share, combined with the PowerView reconnaissance activity from the spsql account, means an attacker with spsql credentials could access these offensive tools and sensitive corporate documents.

The Security event log contains 9,456 matches for LogonType 10 (RemoteInteractive/RDP) events on the domain controller BASE-DC during the investigation window. The primary RDP source is:

• 172.16.4.6: RDP logon starting at 2018-09-04T13:05:06 UTC with administrator credentials

While RDP to domain controllers may be expected for legitimate administration, the volume of RDP sessions is notable. The first observed RDP logon from 172.16.4.6 was at 2018-09-04T13:05:06 UTC with elevated privilege assignment (SeSecurityPrivilege, SeDebugPrivilege, SeBackupPrivilege, etc.) confirmed by concurrent Event ID 4672.

Additionally, multiple cmd.exe processes observed in the memory dump show chains of command-line activity that may have been performed through RDP sessions:
- cmd.exe PID 1036 (PPID 908) spawning further cmd.exe processes at 2018-09-06T17:47:38
- cmd.exe chain: PID 3380 (PPID 908) → PID 6572 (PPID 3380) at 2018-09-06T18:17:46
- cmd.exe chain: PID 6628 → PIDs 7260/8220/5728 at 2018-09-06T22:53:58

RDP is a known attack vector for lateral movement to domain controllers (MITRE T1021.001). Combined with the malware findings in memory, this access pattern warrants investigation of whether these sessions represent legitimate administration or attacker lateral movement.

The DC memory dump (psscan) reveals numerous cmd.exe processes that started and exited within the same second, spread across multiple days from 2018-09-01 through 2018-09-06. This pattern is consistent with automated command execution typical of management agents, post-exploitation frameworks, or remote administration tools.

Key process chains observed:
- PID 908 (ManagementAgent — McAfee masvc.exe/macmnsvc.exe) spawned PID 1036 (cmd.exe at 17:47:38), which spawned PIDs 6940, 2308, 4648 (all cmd.exe, all exited within 1s) — 2018-09-06
- PID 908 spawned PID 3380 (cmd.exe at 18:17:46), which spawned PID 6572 (cmd.exe, exited same second) — 2018-09-06
- PID 6628 spawned PIDs 7260, 8220 (both cmd.exe at 22:53:58, exited same second) — 2018-09-06
- PID 5604 spawned PID 4980 (findstr.exe at 11:14:39) — enumeration activity
- PID 8096 spawned PID 7284 (tasklist.exe at 19:58:33) — process enumeration

COUNTER-ANALYSIS NOTE: The cmd.exe processes spawned by PID 908 (ManagementAgent/McAfee) are LIKELY legitimate McAfee management agent operations — McAfee agents routinely spawn cmd.exe for script execution, update checks, and policy enforcement. These should be distinguished from potentially malicious cmd.exe processes spawned by unknown parents. The findstr.exe and tasklist.exe activity could be either management agent reconnaissance or attacker enumeration — without cmdline data, specific commands cannot be confirmed. Severity maintained at medium due to the presence of unexplained parent processes and the known compromise of this system via YARA-detected implant code.

Without Volatility cmdline data (not indexed for DC), specific commands cannot be confirmed.

BASE-RD-01 (172.16.6.11) was running a full McAfee endpoint protection suite at the time of compromise, yet the p.exe implant operated undetected for approximately 7 days (2018-08-30 to 2018-09-06).

McAfee Components Running (from process tree and service scan):
- masvc.exe — McAfee Agent Service
- macmnsvc.exe — McAfee Agent Common Service
- mfefire.exe — McAfee Firewall Core Service
- mcshield.exe — McAfee On-Access Scanner
- UpdaterUI.exe (PID 6036) — McAfee Update UI
- mfevtps.exe — McAfee Validation Trust Protection Service
- FireTray.exe — McAfee Host Intrusion Prevention (in ShimCache, 2018-03-16)

Defense Evasion Indicators:
1. p.exe ran from c:\windows\temp\perfmon\ — a path designed to blend with legitimate Windows performance monitoring files
2. The process chain used WMI→PowerShell→cmd.exe→p.exe — each stage using legitimate Windows processes
3. p.exe spawned rundll32.exe for post-exploitation modules — the "fork-and-run" pattern minimizes time that malicious code resides in process memory
4. 32-bit PowerShell (SysWOW64) with -s -NoLogo -NoProfile flags — silent, non-interactive execution
5. PerfView.exe also staged in the same directory (ShimCache: Windows\Temp\perfmon\PerfView.exe, build date 2009-07-14) — PerfView is a legitimate Microsoft .NET profiling tool, suggesting the attacker may have used it as a cover story or supplementary tool

WinRM Service Running:
- WinRM (service order 584) is SERVICE_RUNNING on BASE-RD-01, enabled as SERVICE_AUTO_START
- Port 5985 is LISTENING (confirmed in netscan)
- WinRM enabled on a workstation is unusual and may have facilitated the initial WMI remote execution

Assessment:
The attacker successfully evaded McAfee's real-time protection through:
- Process injection/memory-only execution (481 RWX pages in p.exe)
- Living-off-the-land binaries (WMI, PowerShell, rundll32, cmd.exe)
- Staging in a trusted-looking directory path
- Potentially using an unknown or custom implant not covered by McAfee signatures

The malfind analysis shows UpdaterUI.exe (McAfee's own process) had a RWX memory region, but this was assessed as a false positive (zero-filled allocation). No McAfee process showed signs of being disabled or tampered with — the AV was running but simply did not detect the threat.

Three distinct user accounts have profile evidence on BASE-RD-01 (172.16.6.11), each with different roles in the compromise timeline:

1. tdungan — Primary User (Victim):
- Active user workstation with Dashlane password manager (v6.3.0-6.4.0), Outlook, OneDrive ("Stark Research Labs" organization), Internet Explorer, Google Chrome
- Research activity: Documents\Research\Carbonadium\ containing CalTech PDF (5.9 MB)
- OneDrive sync: carbonadium-info.doc synced to "OneDrive - Stark Research Labs\Research\"
- Recent files show normal business activity (Office documents, browser history)
- No evidence tdungan was complicit — the workstation was compromised remotely via WMI

2. spsql — Compromised Service Account (Attacker):
- SQL service account with Domain Admin-level privileges (SID S-1-5-21-3445421715-2530590580-3149308974-1193)
- Profile artifacts on base-rd-01 from MFT:
- Users\spsql\AppData\Local\Microsoft\Windows\INetCache (internet cache present, 2018-08-31 21:54:13)
- Users\spsql\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy (Settings app accessed)
- Users\spsql\AppData\Roaming\Microsoft\Office\Recent\carbonadium-info.LNK (2018-08-28 21:45:57) — opened research doc
- The spsql account was used interactively on this workstation (INetCache, Settings access, Office document access)
- This is the same account that executed PowerView on the file server (Aug 31) and ntdsutil IFM on the DC (Sep 5)

3. rsydow-a — IR Administrator:
- Administrative account (SID S-1-5-21-...-1183) with the "-a" suffix convention for admin accounts
- Profile found primarily on the DC (Group Policy History, INetCache)
- On the DC: PowerShell activity including VSC management, Invoke-Command remote administration
- Deployed F-Response forensic tools from BASE-HUNT starting Sep 5-6
- PowerShell transcription logs found at Users/rsydow-a/Documents/20180830/ — IR activity began Aug 30

Significance:
The spsql account's interactive profile on base-rd-01 proves the attacker had direct access to this workstation, not just remote execution through WMI. The internet cache and Settings app access suggest the attacker may have used RDP or an interactive session under the spsql account. The carbonadium-info.LNK confirms targeted data access to proprietary research.

The Windows registry shimcache on base-wkstn-05 contains an entry for C:\Windows\Temp\perfmon\PerfView.exe with a timestamp of 2009-07-14 01:16:21. This timestamp predates the system's deployment (2016) and the attack (August 2018), strongly suggesting the file's timestamps were manipulated (timestomped) to match the original Windows 7 base image date, making it appear as a legitimate OS component.

PerfView.exe resides in the same attacker-controlled staging directory (C:\Windows\Temp\perfmon) as:
- p.exe (confirmed malicious - PID 8260, code injection detected by malfind)
- Staged sensitive M&A research documents and ZIP archives
- sp/ subdirectory with additional exfiltrated documents

The directory name "perfmon" is designed to mimic Windows Performance Monitor (perfmon.exe), and "PerfView" mimics the legitimate Microsoft PerfView profiling tool. Both naming choices are deliberate defense evasion through masquerading.

The shimcache entry confirms PerfView.exe existed on disk and was likely executed. Combined with the p.exe execution chain (WmiPrvSE → PowerShell → cmd → p.exe), this represents at least two attacker tools deployed to this workstation.

On 2018-08-27 at approximately 03:05, external IP 185.128.26.19 connected to the DMZ-FTP server (172.16.10.12) and performed directory enumeration of user content:

• 03:05:09: Connected, issued QUIT and then reconnected
• 03:05:32: Established new session
• 03:05:46: Executed TYPE I (binary mode), CWD /Users/n (navigated to user directory starting with 'n', likely nfury's), SIZE /Users/ (checked file sizes)

The FTP log data does not show explicit authentication (230 response) for this session, suggesting either anonymous access was enabled and allowed directory browsing, or the authentication occurred in a portion of the logs not captured in the carved evidence.

This activity represents external reconnaissance of the FTP server's user directory structure, which could provide user account enumeration intelligence to the attacker.

PowerShell Invoke-Command by rsydow-a on the DC targeting multiple systems (Get-CimInstance disk space enumeration). This activity is consistent with the IR administrator's role — rsydow-a deployed F-Response, conducted forensic collection, and these Invoke-Command sessions are routine administrative enumeration. Severity downgraded from medium to low. The spsql PowerView activity on the same day (Aug 31) remains high severity as a separate finding.

PowerShell Volume Shadow Copy management by rsydow-a (SID S-1-5-21-...-1183). Given that rsydow-a has been identified as the IR administrator who deployed F-Response and conducted forensic collection (PowerShell transcripts at Users/rsydow-a/Documents/20180830/), VSC management is more likely an IR activity (creating VSCs for forensic preservation) than attacker behavior. Severity downgraded from medium to low. However, the possibility of the attacker abusing rsydow-a credentials for VSC-based NTDS.dit extraction (as an alternative to the failed ntdsutil IFM) cannot be fully excluded without reviewing the specific VSC commands.

CORRECTED: subject_srv.exe is F-Response Subject Agent — a legitimate forensic tool, NOT malware.

subject_srv.exe (PID 5128 on DC, PID 1096 on workstation) is the F-Response Subject agent, a commercial digital forensics collection tool. The command line from the workstation memory dump confirms:

C:\windows\subject_srv.exe -s "base-hunt.shieldbase.lan:5682" -l 3262 -v "F-Response Subject" -k "155522845"

• -s "base-hunt.shieldbase.lan:5682" = connects to F-Response controller on BASE-HUNT
• -l 3262 = local listening port for forensic data collection
• -v "F-Response Subject" = F-Response product identifier
• -k "155522845" = authentication key

The 'mnemosyne' kernel driver installed via Event ID 4697 at 2018-09-06 22:11:15 is F-Response's kernel-mode memory access driver, used to enable remote memory acquisition for forensic analysis. Mnemosyne.sys (26,248 bytes at C:\Windows\Mnemosyne.sys) is confirmed in the kernel module scan (modscan).

CORROBORATING EVIDENCE:
1. F-Response-Installer-7.0.4.4.exe found on file server at Shares/SRL-Admin/Security/F-Response/ (MFT created 2018-09-05 15:15:00)
2. bulk_extractor found www.f-response.com URL and support@f-response.com email in the binary's digital certificate chain
3. Volatility netscan confirms subject_srv.exe (PID 1096) listening on port 3262 with an ESTABLISHED connection from 172.16.5.50:39372

The deployment from BASE-HUNT via NTLM at 2018-09-06 22:11:15 represents legitimate incident response deployment, not attacker lateral movement. BASE-HUNT appears to be the forensic workstation used by the IR team.

CORRECTED: subject_srv.exe is the F-Response Subject forensic agent, a legitimate commercial forensic tool.

The SeDebugPrivilege and other elevated privileges granted to subject_srv.exe (PID 5128 on DC) are EXPECTED for a forensic memory acquisition tool. F-Response requires kernel-level access to perform live memory imaging and disk access for forensic evidence collection.

The 32-bit (Wow64) architecture is normal for F-Response Subject, which ships as a 32-bit binary for compatibility. The file size (1,173,936 bytes) and SHA256 hash (87c8fa606729ed63cb9d59f6b731338f8b06addbb3ef91e99b773eac2f2c524d) should be verified against known F-Response 7.0.4.4 binaries for final confirmation.

This finding has been downgraded from HIGH to INFORMATIONAL as it represents expected incident response tooling.

Failed authentication attempts for BASE-HUNT$ machine account. BASE-HUNT has been identified as the IR team's forensic workstation (F-Response controller at base-hunt.shieldbase.lan:5682). The failed authentications are consistent with an IR workstation that was not initially domain-joined but was subsequently used to deploy F-Response agents across the network. Severity downgraded to informational.

A thorough search of the Security event log for Event ID 1102 (audit log was cleared) returned no matches containing actual log clearing events. The "1102" substring appeared only as a coincidental match in other event fields (e.g., event sequence numbers), not as an Event ID indicating log tampering.

This is an informational finding indicating that security audit logs were NOT cleared during the investigation window. The Security event log contains 186,972 indexed windows with 311,141 lines spanning the investigation period, providing good coverage.

Note: The System event log was not separately indexed for Event ID 104 (System log cleared), so clearing of non-security logs cannot be ruled out.

CORRECTED: The SMB session from BASE-HUNT (172.16.5.50) to the DC at 2018-09-06 22:11:15 was F-Response forensic tool deployment, NOT attacker lateral movement.

The NTLM Type 3 authentication from BASE-HUNT to the DC was part of the IR team deploying F-Response Subject Agent (subject_srv.exe) and its kernel driver (Mnemosyne.sys) for live memory acquisition. Evidence:

1. The F-Response controller on BASE-HUNT connects to subject_srv.exe listening on port 3262 (confirmed in volatility.netscan: ESTABLISHED 172.16.6.11:3262 ← 172.16.5.50:39372)
2. F-Response-Installer-7.0.4.4.exe was staged at Shares/SRL-Admin/Security/F-Response/ (MFT created 2018-09-05 15:15:00)
3. The Mnemosyne kernel driver service installation (Event ID 4697) immediately preceded memory acquisition

The account used (rsydow-a) appears to be an admin account used by the IR team. This connection should not be treated as lateral movement or compromise activity.

NOTE: While the BASE-HUNT connection is legitimate IR activity, the underlying incident (PowerView reconnaissance, Kerberoasting, NTDS.dit extraction attempts) that triggered the IR response remains valid. Other lateral movement indicators from the attacker (distinct from IR activity) should be evaluated independently.

No evidence of deliberate timestamp manipulation on the malicious files was found. The MFT timestamps for both subject_srv.exe (Created 2018-09-06 19:25:36) and Mnemosyne.sys (Created 2018-09-06 19:25:37) show consistent timestamps with no anomalous backdating. The attacker did not attempt to blend malicious files with legitimate system files through timestamp falsification.

The detect_timestomping analysis found only 2 entries on the root NTFS directory which are known false positives from Windows installation.

YARA scanning of the DC memory dump produced 466 windows of results. The APT6_Malware_Sample_Gen rule triggered on multiple process memory regions. However, inspection of the matched strings reveals they are generic indicators present in legitimate Windows binaries:

Matched strings included: 'shellcode', 'synflood', 'udpflood', 'ServiceMain', 'sysprep', 'file://' — all of which are common strings found in Windows Defender antivirus definition databases, Windows SDK headers, and system utilities. The 'ServiceMain' string is a standard Windows service entry point function name present in all service executables.

The rule's signature appears to match on a combination of commonly occurring strings rather than specific malware byte sequences. Without the actual APT6 malware binary being present (no matching file hash or unique code pattern), these hits represent rule over-matching on legitimate system memory content.

No additional YARA rule families matched the memory scan, which would be expected if genuine APT6 malware were present — real infections typically trigger multiple distinct detection rules.

The SHIELDBASE.LAN Active Directory domain comprises the following systems identified from Security EVTX authentication events, Volatility psscan, and registry network profiles:

DOMAIN SYSTEMS:
- base-dc (172.16.4.4): Domain Controller, DNS server, DFS
- base-file (172.16.4.5): File Server with network shares
- BASE-MAIL (172.16.4.6): Mail server (Exchange)
- base-sp (172.16.4.7): SharePoint server (frequent Kerberos ticket requests for spfarm/spservices)
- BASE-HUNT (172.16.?.?): Workstation — origin of malicious service installation
- BASE-WKSTN-02 (172.16.7.12): Workstation — multiple logon events after service install
- base-hunt.shieldbase.lan: Referenced in VSC (Volume Shadow Copy) records
- 172.16.5.21: IP that authenticated as rsydow-a (admin account)
- 172.16.7.15: Additional network logon source

SERVICE ACCOUNTS:
- rsydow-a (S-1-5-...-1183): Domain administrator account
- spsql (S-1-5-...-1193): SharePoint SQL service account (compromised — used for PowerView)
- spfarm: SharePoint farm account
- spservices (S-1-5-...-1197): SharePoint services account (persistent Kerberos SPN errors)

NETWORK CONFIGURATION: Registry shows wired network connections with DefaultGatewayMac A2-C6-C7-00-07-02, last connected 2018-09-07. System shutdown time: 2018-09-07 20:25:33.

F-Response Enterprise 7.0.4.4 was deployed across the SHIELDBASE.LAN network as part of the incident response effort. Evidence confirms this is a legitimate forensic tool, not attacker activity:

DEPLOYMENT EVIDENCE:
- F-Response installer (F-Response-Installer-7.0.4.4.exe) staged on file server at Shares/SRL-Admin/Security/F-Response/ (MFT created 2018-09-05 15:15:00)
- subject_srv.exe deployed to Domain Controller (PID 5128) and workstation 172.16.6.11 (PID 1096)
- Mnemosyne.sys kernel driver (26,248 bytes) loaded on both systems for memory acquisition
- F-Response controller running on BASE-HUNT (172.16.5.50, port 5682)

NETWORK ARCHITECTURE:
- F-Response Controller: BASE-HUNT (172.16.5.50:5682)
- Subject Agent on workstation: 172.16.6.11:3262 (LISTENING, ESTABLISHED from 172.16.5.50:39372)
- Service installation events (Event ID 4697) at 2018-09-06 22:11:15 correspond to F-Response deployment

CONFIRMATION OF LEGITIMACY:
1. Command line: subject_srv.exe -s "base-hunt.shieldbase.lan:5682" -l 3262 -v "F-Response Subject" -k "155522845"
2. Digital certificate chain: www.f-response.com, support@f-response.com found in bulk_extractor
3. F-Response installer on designated security tools share
4. Mnemosyne.sys confirmed as F-Response kernel driver in modscan

INVESTIGATOR CONTEXT:
The IR team (using account rsydow-a) deployed F-Response to acquire live memory and disk images from compromised systems. The memory dumps analyzed in this investigation were likely captured using F-Response. PowerShell transcription logs found at Users/rsydow-a/Documents/20180830/ further confirm the IR team's activity timeline beginning August 30, 2018.

NOTE: Three previous findings (f_b764dfda, f_bf5e5d63, f_6cd0e861) have been updated to INFORMATIONAL severity to reflect that subject_srv.exe and Mnemosyne.sys are F-Response components, not malicious artifacts.

YARA scanning of the BASE-RD-01 disk image (base-rd-01-cdrive.E01) triggered the APT_MAL_RU_WIN_Snake_Malware_May23_1 rule. Upon inspection, the matched strings are generic format strings and file extensions that commonly occur in legitimate Windows binaries:

Matched Strings:
- %s#1, %s#2, %s#3, %s#4 — standard C format specifiers with numeric identifiers
- .tmp — common temporary file extension
- .sav — save file extension
- .upd — update file extension

Assessment:
These strings are too generic to indicate the presence of Snake/Uroburos malware. The format specifiers (%s#N) are commonly used in error handling, logging, and resource management code across many legitimate Windows applications. The file extensions (.tmp, .sav, .upd) are standard Windows conventions found in numerous system components.

Snake/Uroburos is a sophisticated Russian cyberespionage toolkit attributed to Turla/FSB. A genuine Snake infection would typically present with:
- Specific encrypted configuration blocks
- Named pipe patterns (e.g., \.\pipe)
- Kernel-mode rootkit components
- Unique mutex names
- Distinctive network protocol markers

None of these were found in the BASE-RD-01 evidence. The YARA memory scan of this workstation also returned no Snake-related hits.

Conclusion: This is a false positive caused by the rule matching on common format strings present in the raw disk image. The actual compromise of BASE-RD-01 involved a different toolset (WMI/PowerShell-based with p.exe implant and rundll32 fork-and-run pattern).

CORRECTED via counter-analysis: subject_srv.exe on base-rd-02 is the F-Response Subject forensic agent, NOT a persistent backdoor.

The same F-Response deployment identified in findings f_b764dfda, f_bf5e5d63, and f_b22156d2 also deployed subject_srv.exe to base-rd-02. Evidence:

1. subject_srv.exe PID 1096 (PPID 740) on base-rd-02 mirrors PID 1096 (PPID 740) on BASE-RD-01 — identical deployment pattern
2. Port 3262 is the standard F-Response Subject listening port, confirmed by command-line on BASE-RD-01: -l 3262
3. ESTABLISHED connections from 172.16.5.50 are from BASE-HUNT, the IR team's forensic workstation running the F-Response controller at port 5682
4. Multiple subject_srv.exe PIDs (1096, 1204, 5128, 12528) across systems represent iterative F-Response deployments during the IR response window (Sep 6)
5. The file at Windows/subject_srv.exe matches the deployment path on other systems

The original finding's characterization as a "persistent backdoor" was incorrect — all indicators (port 3262, connections from 172.16.5.50, services.exe parent, multiple boot contexts during IR) are consistent with F-Response forensic collection, not adversary activity.

NOTE: The genuine persistent backdoor on base-rd-02 is msadvapi2_64.exe/msadvapi2_32.exe (finding f_2834e454), not subject_srv.exe.

The DMZ-FTP system (IP 172.16.10.12) runs Microsoft IIS FTP Service (FTPSVC2) on Windows Server. Evidence from the disk image file listing shows FTP log files stored in inetpub/logs/LogFiles/FTPSVC2/ with daily W3C-format logs (u_exYYMMDD.log) from May through September 2018. The web root at inetpub/wwwroot contains default IIS 8.5 files (iis-85.png, iisstart.htm), confirming the server runs IIS 8.5 on Windows Server 2012 R2.

Three local FTP user accounts were identified from the FTP log entries: DMZ-FTP\dblake, DMZ-FTP
fury, and DMZ-FTP\rsydow-f. All three accounts authenticated successfully (230 response codes) at various times.

IIS configuration history exists with 7 versions stored in inetpub/history/CFGHISTORY_0000000001-7/applicationHost.config, indicating the FTP configuration was modified multiple times.

The FTP root directory is located at inetpub/ftproot, and the service exposes the /Users/ directory path allowing access to user home directories via FTP.

Analysis of the DMZ-FTP filesystem did not reveal webshells, backdoors, or other malicious files in the IIS web root directories:

• inetpub/wwwroot: Contains only default IIS 8.5 files (iis-85.png, iisstart.htm)
• inetpub/ftproot: FTP root directory with no anomalous files detected in the file listing
• No suspicious .aspx, .asp, .php, or other script files were found outside of standard Windows/.NET framework locations

While the FTP server was accessed by the external attacker (165.227.50.129) and the attacker navigated to the PowerShell directory, no webshells or persistent backdoor files were identified in the web-accessible directories. This does not rule out the possibility of malicious files in non-web directories, encrypted content, or files that were deployed and subsequently removed.

The primary attack vector on this system appears to have been credential-based FTP access rather than web-based exploitation.