PowerView (part of the PowerSploit framework) was loaded and executed on the domain controller BASE-DC on 2018-08-31 between 22:16 and 22:52 UTC. The PowerShell Operational event log (Event ID 4104 - ScriptBlock logging) captured the full script content, which includes the following PowerView functions:

• Invoke-UserHunter: Finds logged-in users across the domain
• Invoke-ShareFinder: Enumerates accessible network shares
• Invoke-CheckLocalAdminAccess: Checks local admin access on domain hosts
• Get-NetDomain/Get-NetForest: Domain and forest enumeration
• Invoke-MapDomainTrust: Domain trust mapping
• Get-ForeignGroup: Cross-domain group enumeration
• Get-DNSRecord/Get-DNSZone: DNS record enumeration
• Invoke-EnumerateLocalAdmin: Local admin enumeration across domain
• Find-LocalAdminAccess: Automated local admin access discovery
• Get-Keystrokes: Keystroke logging capability

The script was executed under user SID S-1-5-21-3445421715-2530590580-3149308974-1193 (spsql) on host base-file.shieldbase.lan. The PowerShell host application was C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. References to both Metasploit and PowerShell Empire GitHub repositories were present in the script code, confirming the offensive tooling origin.

This represents full AD reconnaissance from a compromised domain controller using a service account (spsql), consistent with post-exploitation lateral movement and domain enumeration.

A multi-stage attack chain was detected on the file server (BASE-FILE, 172.16.4.5) involving remote WMI execution leading to PowerShell C2 activity and massive rundll32.exe spawning, consistent with a post-exploitation framework (e.g., Cobalt Strike, Empire, Metasploit).

Stage 1 - Remote WMI Execution:
- WmiPrvSE.exe (PID 1196) spawned powershell.exe (PID 4072)
- PID 4072: 64-bit, started 2018-08-28 22:08:25
- WMI remote execution indicates lateral movement from another host

Stage 2 - PowerShell Architecture Downgrade:
- PID 4072 spawned powershell.exe (PID 3164), 32-bit (Wow64=True), started 2018-08-28 22:08:26
- 32-bit PowerShell on a 64-bit host is a red flag commonly used by exploitation frameworks for shellcode compatibility
- Running under user shieldbase\spsql (service account)

Stage 3 - Rundll32 Process Spawning:
- PID 3164 spawned 30+ rundll32.exe child processes between 2018-08-30 and 2018-09-06
- Observed PIDs include: 3548 (08-30 02:52), 3260 (08-30 18:40), 300 (08-30 03:23), and many more
- Rundll32 spawning is a classic technique for code injection / reflective DLL loading

Network C2:
- Both PowerShell processes (PID 4072 and PID 3164) connected to 172.16.4.10:8080 (ESTABLISHED)
- 172.16.4.10 appears to be a web proxy; C2 traffic likely tunneled through the proxy

PowerShell Script Logging (Event ID 4104):
- Scripts executed by shieldbase\spsql included Win32_ShadowCopy manipulation and NetFirewallRule commands
- Host Application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

A multi-stage attack chain was established on base-rd-02 (172.16.6.11) via WMI, mirroring the pattern observed on the DC and file server.

Full Process Tree:
1. WmiPrvSE.exe (PID 2876, Session 0) → powershell.exe (PID 8712, 64-bit, started 2018-08-30 16:43:36, no visible command-line args)
2. PID 8712 → powershell.exe (PID 5848, 32-bit/SysWOW64, started 2018-08-30 16:43:42, args: "-Version 5.1 -s -NoLogo -NoProfile")
3. PID 5848 spawned multiple rundll32.exe processes for code injection:
- PID 6768: 2018-08-30 18:31:04 – 18:31:35 (SysWOW64)
- PID 5452: 2018-08-30 21:40:18 – 21:40:23
- PID 5588: 2018-08-30 21:40:42 – 21:40:54
- PID 2216: 2018-08-30 22:31:57 – 22:32:19 (SysWOW64)
- PID 4108: 2018-08-30 22:45:25 – 22:45:30
- PID 8148: 2018-08-31 00:56:14 – 00:56:30 (SysWOW64)
4. PID 5848 also spawned cmd.exe (PID 5948) which executed c:\windows\temp\perfmon\p.exe (PID 8260) at 2018-08-30 22:15:18

Second-Stage Implant (p.exe):
- p.exe (PID 8260) spawned its own rundll32.exe instances days later:
- PID 5768: 2018-09-05 12:01:32 – 12:01:40
- PID 1424: 2018-09-06 14:58:41 – 14:58:45
- PID 7552: 2018-09-06 17:26:32 – 17:26:35
- p.exe had a malfind hit: VadS PAGE_EXECUTE_READWRITE, CommitCharge=481 (large RWX allocation consistent with injected shellcode)
- The file at c:\windows\temp\perfmon\p.exe was not found in MFT, suggesting deletion after deployment

Malfind Detections:
- powershell.exe PID 8712: 3 VadS regions with PAGE_EXECUTE_READWRITE (injected code)
- p.exe PID 8260: VadS with PAGE_EXECUTE_READWRITE, 481 commit charge

Key Indicators:
- WMI-initiated execution in Session 0 (non-interactive, remote origin)
- 32-bit PowerShell downgrade on 64-bit OS (framework shellcode compatibility)
- No visible command-line args on initial PowerShell (anti-forensics)
- Stealth flags: -s -NoLogo -NoProfile on child PowerShell
- Short-lived rundll32.exe child processes spanning Aug 30 – Sep 6 (8+ days of sustained access)

This attack chain is identical to the one on the file server (BASE-FILE) and DC, confirming base-rd-02 was compromised via the same campaign using the same Metasploit/Cobalt Strike-style post-exploitation framework.

Affected Systems: ez.mft, registry.system, volatility.cmdline, volatility.dlllist, volatility.malfind, volatility.pstree

Three parallel WMI-initiated PowerShell attack chains were established on base-wkstn-05 (172.16.7.15, user: mhill) within a 17-minute window on 2018-08-31, matching the exact pattern observed on other compromised systems (base-rd-02, file server, DC).

Attack Chain Details (from psscan source_id 232):

Chain 1: WmiPrvSE.exe (PID 2676, Session 0) → powershell.exe (PID 4328, 64-bit, 01:14:44) → powershell.exe (PID 1124, WoW64/32-bit, 01:14:45)

Chain 2: WmiPrvSE.exe (PID 2676) → powershell.exe (PID 4064, 64-bit, 01:23:24) → powershell.exe (PID 4072, WoW64/32-bit, 01:23:25)

Chain 3: WmiPrvSE.exe (PID 2676) → powershell.exe (PID 3920, 64-bit, 01:31:24) → powershell.exe (PID 1332, WoW64/32-bit, 01:31:25)

All three chains follow the identical pattern:
1. WMI Provider Host (Session 0, non-interactive) spawns 64-bit PowerShell
2. 64-bit PowerShell immediately spawns 32-bit (WoW64) child for shellcode compatibility
3. No visible command-line args on the 64-bit parent (anti-forensics)

Chain 3 was the active C2 session: PID 1332 (32-bit PowerShell) spawned 5+ rundll32.exe code injection targets:
- PID 5300: 2018-08-31 01:31:44 – 01:31:46 (2 sec)
- PID 3720: 2018-08-31 21:07:21 – 21:07:28 (7 sec)
- PID 5056: 2018-08-31 20:23:08 – 20:23:29 (21 sec)
- PID 4240: 2018-08-31 20:23:17 – 20:23:35 (18 sec)
- PID 1972: 2018-08-31 20:23:52 – 20:23:56 (4 sec)

A persistent rundll32.exe (PID 7100, PPID 7148) was still running at memory capture time with 5 threads and 337 handles, suggesting a long-running implant module.

Three simultaneous chains (vs one on other systems) suggests the attacker experienced connectivity issues or the first two stagers failed to fully initialize, requiring retry attempts.

System context:
- System boot: 2018-08-30 05:14:12
- User mhill connected via RDP (rdpclip.exe PID 4232 in Session 5)
- Active applications: Outlook, Chrome, GROOVE.EXE (OneDrive/SharePoint)
- Sysmon64.exe (PID 1892) was running but did not prevent the compromise
- McAfee AV suite fully deployed (masvc, mfefire, mcshield, HipMgmt)

Affected Systems: volatility.psscan

Affected Systems: volatility.netscan, volatility.psscan

COUNTER-ANALYSIS CORRECTIONS applied to comprehensive timeline:

IP Correction: BASE-DC is 172.16.4.4, not 172.16.4.1 as previously stated.

DMZ-FTP Reclassified: DMZ-FTP (172.16.10.12) is downgraded from "confirmed compromised" to "unconfirmed." The primary evidence (sub-win-x64_base-hunt_5682_3262.exe) has been re-assessed as likely an F-Response subject agent binary (see finding f_bec07e91). FTP brute force attempts all failed. FTP log deletion is suspicious but insufficient alone. No memory dump was available for this system, preventing WMI/PowerShell chain confirmation.

IR Activity Separation: subject_srv.exe deployments across all systems are F-Response forensic tooling deployed by incident responders starting ~2018-09-06, not attacker persistence. Autorunsc.exe execution on 2018-08-15 is consistent with IR triage rather than attacker activity.

CORRECTED Attack Timeline (Aug-Sep 2018):

1. Pre-Existing Access (June+ 2018):
2. msadvapi2 backdoor services deployed on 3+ systems (BASE-DC 172.16.4.4, base-wkstn-03 172.16.6.13, 172.16.6.15)

3. Persistent packet capture capability via wpcap.dll

4. Possible Early IR Triage (August 15, 2018):

5. cbarton-a remote PowerShell reconnaissance on base-rd-02 (could be legitimate admin activity)

6. Autorunsc.exe execution on 172.16.6.15

7. Active Offensive Operations (August 27-September 6, 2018):

8. WMI-based remote code execution deploying Metasploit PowerShell stagers across 7+ systems
9. C2 tunneled through organizational web proxy at 172.16.4.10:8080
10. PowerView AD reconnaissance from file server using spsql service account (Aug 31)
11. Data staging via Rar.exe on BASE-FILE (Sep 5)

12. WinRM lateral movement converging on 172.16.5.21

13. Confirmed Compromised Systems (7):

14. BASE-FILE (172.16.4.5), BASE-DC (172.16.4.4), base-rd-02 (172.16.6.11), base-wkstn-04 (172.16.6.14), base-wkstn-05 (172.16.7.15), base-wkstn-03 (172.16.6.13), 172.16.6.15

15. Likely Compromised (insufficient evidence for full confirmation):

16. base-wkstn-01 (172.16.7.11) — WMI chain observed but limited corroboration

17. base-rd-06 (172.16.6.13) — msadvapi2 + C2 proxy connection

18. Not Compromised:

19. 172.16.5.25 (base-hunt) — Forensic workstation
20. 172.16.5.26 — Admin workstation
21. 172.16.7.16 (base-wkstn-02) — No compromise indicators

Two malicious executables disguised as "Microsoft Advanced API" are running as persistent services on at least two compromised systems (memory captures with boot times 2018-06-04, 2018-08-17, and 2018-09-06):

• msadvapi2_32.exe (PIDs 1072/2020, WoW64 32-bit) at "C:\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe"
• msadvapi2_64.exe (PIDs 1240/1256, 64-bit) at "C:\Program Files (x86)\Microsoft Advanced API 64\msadvapi2_64.exe"

Both processes run under services.exe (Session 0) as system services, indicating service-based persistence. The malware persists across reboots, confirmed by its presence in three separate memory captures spanning June through September 2018. Malfind detected PAGE_EXECUTE_READWRITE memory regions in msadvapi2_32.exe (PID 1072), indicating possible code injection or runtime unpacking. DLL analysis shows the malware loads wpcap.dll (WinPcap), IPHLPAPI.DLL, and network-related libraries, consistent with network packet capture or traffic manipulation capabilities.

The "Microsoft Advanced API" naming is a deliberate deception technique to blend with legitimate Microsoft software. There is no legitimate Microsoft product by this name. The installation under "Program Files (x86)" and registration as a Windows service demonstrates sophisticated persistence by the threat actor.

Memory forensics of base-wkstn-03 (172.16.7.14, dual-homed 10.10.150.181) reveals multiple concurrent compromise mechanisms. System boot time: 2018-06-04 20:18:58.

1. WMI-Based Lateral Movement (T1047):
EVTX PowerShell operational logs captured the attacker executing Invoke-WmiMethod with ComputerName="BASE-WKSTN-03" and Class="win32_process" at 2018-09-06 17:01:50, confirming WMI remote code execution targeting this host.

2. Metasploit PowerShell Stager Chain:
- WmiPrvSE.exe (PID 3308, born 2018-06-04 20:19:47) spawned powershell.exe (PID 4340, born 2018-09-06 17:24:47) running: powershell.exe -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIA...
- Decoded payload: $s=New-Object IO.MemoryStream(,[Convert]::FromBase64String("H4sI..."));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s,[IO.Compression.CompressionMode]::Decompress))).ReadToEnd();
- Architecture downgrade: PID 4340 (64-bit) spawned PID 1288 (32-bit SysWOW64 powershell.exe, born 2018-09-06 17:24:49) for Metasploit shellcode compatibility

3. msadvapi2 Backdoor (Persistent Services):
- msadvapi2_32.exe (PID 2240, WoW64, born 2018-06-04 20:19:38) at "C:\Program Files (x86)\Microsoft Advanced API 32\"
- msadvapi2_64.exe (PID 2248, born 2018-06-04 20:19:38) at "C:\Program Files (x86)\Microsoft Advanced API 64\"
- Both run as children of services.exe (PID 736), indicating persistent service registration since system boot
- Backdoor has been present since at least 2018-06-04 (3+ months before incident response)

4. LARIAT Framework:
- prunsrv.exe (PID 2268) → java.exe (PID 324) running Lincoln Lab LARIAT c2 client
- LARIAT java connections to external IPs (closed state)

5. Network Indicators:
- SMB from file server: 172.16.4.5:59071 → 172.16.7.14:445 ESTABLISHED (2018-09-06 17:24:47)
- WinRM outbound: 172.16.7.14:54302 → 172.16.5.21:5985 CLOSED (2018-09-06 21:02:43)
- Puppet/MCO: 10.10.150.181:54120 → 10.10.254.1:61613 ESTABLISHED
- F-Response: subject_srv.exe (PID 6556) deployed 2018-09-06 20:55:26

6. Security Tools Deployed but Bypassed:
- McAfee VirusScan Enterprise, Host Intrusion Prevention, Agent
- SecurityHealthService (Windows Defender)
- Neither detected the msadvapi2 backdoor or PowerShell stager

Memory forensics of base-wkstn-04 (172.16.6.14, boot 2018-08-06 16:38:49) reveals two distinct, concurrent attack chains operating in different security contexts.

Attack Chain 1 — Interactive User Session (Session 11):
PowerShell PID 2664 was launched from explorer.exe (PID 8392) in the user's interactive desktop session at 2018-08-27 21:25:58. This PowerShell process spawned 20+ short-lived rundll32.exe injection targets over a 3-day period:
- 2018-08-27: PIDs 9644, 4476, 6260, 2508, 9756, 12496, 6720, 1000, 12692 (9 instances, 2-4 second lifetimes each)
- 2018-08-28: PIDs 7696, 9476, 7680, 12208, 6320, 3816, 9784, 10196, 9292, 9824, 12328 (11 instances)
- 2018-08-30: PID 8436 (1 instance)
Additionally, PID 2664 spawned child PowerShell processes: PID 3924 (exited 08-30 04:55:24), PID 6804 (exited 09-06 17:40:12), PID 4520 (still running at capture time). PID 2664 maintained active network connections to C2 proxy at 172.16.4.10:8080 (ports 51278, 52483 CLOSED).

A long-running rundll32.exe PID 8856 (spawned by PID 8448 at 2018-08-27 23:39:56) was still running at memory capture — 10+ days of persistent execution, indicating a persistent implant module.

PID 2664 also opened a local listener on port 18278 (127.0.0.1:18278), consistent with a local C2 relay or socks proxy used by post-exploitation frameworks.

Attack Chain 2 — WMI Remote Execution (Session 0):
On 2018-09-06 17:43:45, WmiPrvSE.exe (PID 3156) spawned powershell.exe PID 4896 with encoded Metasploit stager: "powershell.exe -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIA..." decoding to the standard GZip-compressed shellcode loader ($s=New-Object IO.MemoryStream). PID 4896 spawned 32-bit child powershell.exe PID 5452 (WoW64 architecture downgrade). Malfind confirmed Metasploit shellcode (fc e8 04 00 00 00 — CLD; CALL $+4 decoder stub) in PID 5452's memory.

SearchUI.exe Injection (PID 9316):
SearchUI.exe contained injected x64 shellcode (PAGE_EXECUTE_READWRITE) and maintained 7+ CLOSE_WAIT connections to 172.16.4.10:8080 (ports 55897-55903, 49320-49323), establishing persistent C2 from 2018-08-29 22:01 through 2018-09-06.

Network Summary:
- 30+ connections to C2 proxy 172.16.4.10:8080 (via SearchUI.exe, powershell.exe, svchost.exe, ngen.exe, LogonUI.exe, MicrosoftEdge, software_reporter)
- 8+ WinRM sessions to 172.16.5.21:5985 (lateral movement pivot)
- SMB to file server (172.16.4.5:445), DC (172.16.4.4:445/49670), Exchange (172.16.4.6:443)
- Inbound SMB from file server: 172.16.4.5:59106 → 172.16.6.14:445 (timed with WMI stager delivery at 17:43:46)
- F-Response (subject_srv.exe PID 7140) deployed 2018-09-06 19:05:20

Significance:
Unlike other compromised systems that show only WMI-based remote attack chains, base-wkstn-04 had an INTERACTIVE PowerShell C2 session running from the user's own desktop (Session 11) for 10+ days. This suggests the attacker either had direct desktop access (RDP) or the initial compromise occurred through a user-initiated action (phishing, malicious link).

Affected Systems: volatility.cmdline, volatility.malfind, volatility.netscan, volatility.pslist, volatility.pstree

COUNTER-ANALYSIS NOTE: IP correction — the original finding listed "BASE-DC (172.16.4.1)" but the domain controller is at 172.16.4.4.

Cross-system correlation reveals a uniform attack chain deployed across at least 7 confirmed hosts in the shieldbase.lan environment: WmiPrvSE.exe spawns 64-bit PowerShell with encoded command (-nop -w hidden -encodedcommand), which spawns 32-bit PowerShell (SysWOW64) performing a second stage decode, which injects into rundll32.exe via process hollowing.

Confirmed systems with this chain:
- base-wkstn-04 (172.16.6.14) — Interactive + WMI chains
- base-wkstn-05 (172.16.7.15) — 3 parallel WMI chains
- base-wkstn-03 (172.16.6.13) — WMI chain + msadvapi2
- base-rd-02 (172.16.6.11) — WMI chain + p.exe stager
- BASE-FILE (172.16.4.5) — WMI chain + data staging
- 172.16.6.15 — Encoded PowerShell stager
- base-wkstn-01 (172.16.7.11) — WMI chain

The uniformity of this chain—identical process hierarchy, identical PowerShell flags, identical 64→32-bit downgrade, identical rundll32 injection target—indicates automated deployment via WMI, consistent with a Metasploit-style framework. Multiple rundll32 instances per host (up to 20+ on base-wkstn-04) indicate repeated C2 callback injection.

LARIAT Consideration: The LARIAT (Lincoln Lab) testing framework is present on several affected systems but runs as Java processes under prunsrv.exe, completely distinct from the WMI→PowerShell→rundll32 chain. LARIAT cannot account for these artifacts.

Convergence: This finding is corroborated by independent sources—Volatility pstree (parent-child chains), cmdline (encoded commands), malfind (injected code in rundll32), and netscan (C2 connections from rundll32 PIDs).

COUNTER-ANALYSIS NOTE: The proxy connections must be interpreted carefully. 172.16.4.10:8080 is the organizational web proxy used by ALL systems on this network for internet access. Systems connecting to this proxy include:
- Confirmed-clean forensic workstation (172.16.5.25) with 15+ connections
- Confirmed-clean admin workstation (172.16.5.26)
- Legitimate user workstations for web browsing

C2 Distinction:
Proxy connections alone do NOT prove C2. What distinguishes attacker C2 from legitimate browsing is the SOURCE PROCESS:
- SearchUI.exe (PID 9316 on 172.16.6.14) connecting to the proxy IS anomalous — Windows Search UI does not normally make HTTP proxy requests
- Injected PowerShell processes (with confirmed malfind shellcode) connecting to the proxy IS C2
- Chrome.exe, Edge, or svchost.exe connecting to the proxy is EXPECTED behavior

Corrected System List (confirmed C2 via process attribution):
- 172.16.6.11 (base-rd-02): PowerShell C2 chain with confirmed malfind
- 172.16.6.14 (base-wkstn-04): SearchUI.exe injection + 30+ connections
- 172.16.7.15 (base-wkstn-05): PowerShell C2 chain with confirmed malfind
- 172.16.4.5 (BASE-FILE): PowerShell PIDs 4072/3164 with confirmed C2 chain
- 172.16.6.13 (base-rd-06): CLOSE_WAIT connection + msadvapi2 present

Systems where proxy connections may be benign browsing:
- 172.16.5.25 (base-hunt): Forensic workstation — NOT compromised
- 172.16.5.26: Admin workstation — NOT compromised
- 172.16.5.20: Chrome browser — ambiguous without process injection evidence

The finding's core conclusion (C2 tunneled through legitimate proxy) remains valid for confirmed-compromised hosts where the connecting processes are attacker-controlled.

COUNTER-ANALYSIS NOTE: IP address corrections applied. The original finding referenced "BASE-DC (172.16.4.1)" but the domain controller is at 172.16.4.4 per all other findings. Additionally, the claim of msadvapi2 on "base-wkstn-01 (172.16.7.16)" contains a hostname/IP mismatch — base-wkstn-01 is 172.16.7.11 in other findings, while 172.16.7.16 is identified as base-wkstn-02 in finding f_1c084ed7 (which shows NO msadvapi2 and NO compromise indicators).

Corrected Assessment:
Cross-system analysis reveals two distinct but potentially related intrusion campaigns:

Campaign 1 — msadvapi2 Backdoor (Pre-August 2018):
The msadvapi2_32.exe and msadvapi2_64.exe binaries (masquerading as "Microsoft Advanced API") deployed as Windows services across at least 3 confirmed systems:
- BASE-DC (172.16.4.4) — PID 1072, present since at least June 2018
- base-wkstn-03/base-rd-06 (172.16.6.13) — PIDs 2288/2304, since 2018-08-17 boot
- 172.16.6.15 — msadvapi2_64.exe running as service

DLL analysis shows wpcap.dll (packet capture) loading, consistent with network interception.

Campaign 2 — Metasploit/PowerShell (August-September 2018):
WMI→PowerShell→rundll32 attack chains deployed across 8+ systems using encoded commands with 64→32-bit process downgrade.

Assessment:
The co-existence on shared hosts suggests either a single actor with evolving TTPs, or a coordinated handoff. The msadvapi2 backdoor predates the Metasploit operations by 2+ months, establishing a persistent foothold before the more aggressive August-September lateral movement campaign.

Rar.exe (PID 2524) was observed executing on the file server (BASE-FILE) in a pattern consistent with data staging for exfiltration.

Process Details (from snapshot5 - earlier capture):
- PID 2524, PPID 6352 (cmd.exe, spawned from explorer.exe - interactive session)
- Started 2018-09-05 14:43:11
- 67 active threads in snapshot5, indicating active compression

Process Details (from base-file-memory - later capture):
- Same PID 2524, now showing ExitTime 2018-09-05 14:52:56
- Total runtime: approximately 10 minutes of compression activity

Context:
- The cmd.exe parent (PID 6352) was spawned from explorer.exe (PID 6452), indicating interactive user action during a logged-on session
- 10 minutes of active compression suggests a significant volume of data being archived
- File server contains substantial business data as evidenced by SMB connections from multiple hosts in the environment

This activity occurred within the broader attack timeline (Aug 28 - Sep 6, 2018) during which the PowerShell C2 chain and subject_srv.exe were active.

Affected Systems: ez.mft, volatility.psscan

The domain service account 'spsql' (SID S-1-5-21-3445421715-2530590580-3149308974-1193) was used to execute PowerView/PowerSploit reconnaissance scripts from base-file.shieldbase.lan on 2018-08-31.

Evidence of account compromise:
1. PowerShell Operational Event Log (Event ID 4104) shows ScriptBlock logging under spsql's SID executing PowerView functions including:
- Invoke-UserHunter (locating logged-in domain admins)
- Invoke-ShareFinder (enumerating accessible shares)
- Invoke-CheckLocalAdminAccess (identifying admin access on remote systems)
- Get-NetDomain, Get-NetForest (domain/forest enumeration)
- Invoke-MapDomainTrust, Get-ForeignGroup (trust mapping)
- Get-DNSRecord, Invoke-EnumerateLocalAdmin
- Invoke-ACLScanner (scanning for modifiable ACLs)

1. MFT entries show Users\spsql profile directories being created/modified on 2018-08-31 21:54:13, contemporaneous with the PowerView execution (22:16-22:52)

2. The spsql account is a SQL service account (suggested by name convention), which was weaponized for lateral reconnaissance — typical of attackers leveraging highly-privileged service accounts.

3. Execution originated from base-file.shieldbase.lan, not the DC itself, indicating the attacker moved laterally to the file server and used the spsql account for domain-wide enumeration.

COUNTER-ANALYSIS ASSESSMENT: The Codoso/Deep Panda YARA matches warrant careful evaluation. The "inference" confidence level is APPROPRIATE and should NOT be elevated to "confirmed."

Credible Detections (retained at inference):

Codoso_CustomTCP_4:
- "varus_service_x86.dll" at offset 0x6c6e4ce3 — a specific malware component name not found in legitimate software
- "net start %%1" / "net stop %%1" — service manipulation commands
- "ping 127.1 > nul" (3 instances) — delay technique
- Strings in close memory proximity suggest a single binary

DeepPanda_htran_exe:
- "-slave " — specific to htran tool syntax
- "[+] OK! I Closed The Two Socket." — htran-specific debug message

Why "inference" is correct, not "confirmed":
1. Attribution rests on a SINGLE detection tool (YARA) — no independent corroboration from network IOCs, domain registrations, or TTP-based attribution
2. htran is a publicly available tool used by multiple threat groups, not exclusively Codoso/Deep Panda
3. varus_service_x86.dll is more specific but a single string match doesn't constitute group attribution
4. The Tofu_Backdoor and IMPLANT_5_v3 matches lack detailed analysis of the matched byte sequences
5. No C2 domain or external IP has been linked to known Codoso/Deep Panda infrastructure

Assessment:
The YARA signatures confirm the PRESENCE of specific offensive tools (htran, a varus-named service DLL) in DC memory. These tools have historically been associated with Chinese APT groups including Codoso/Deep Panda. However, tool presence ≠ group attribution. The evidence supports "tools consistent with Codoso/Deep Panda TTPs" but falls short of confirmed attribution to that specific group.

The co-existence of msadvapi2 (persistent backdoor since June) + Metasploit (August-September operations) is consistent with known APT operational patterns (establishing persistent access, then conducting operations), but this pattern is not unique to any single group.

Network analysis of the base-rd-02 memory dump (IP: 172.16.6.11) reveals extensive C2 communications and lateral movement activity.

C2 Proxy Connections to 172.16.4.10:8080 (14+ connections):
ESTABLISHED:
- 172.16.6.11:49788 → 172.16.4.10:8080
- 172.16.6.11:49787 → 172.16.4.10:8080
- 172.16.6.11:49786 → 172.16.4.10:8080

CLOSE_WAIT (7 connections — indicating sustained C2 session teardowns):
- Ports 52703, 50253, 50263, 50259, 49774, 50257, 50254, 50258

CLOSED:
- Ports 63931, 49790, 49735

172.16.4.10:8080 is the same C2 proxy observed in the DC and file server compromises, confirming base-rd-02 is part of the same intrusion campaign.

RDP Outbound to File Server (172.16.4.5:3389) — 7 CLOSED connections:
- Ports 63826, 63834, 63958, 63848, 63823, 63841, 63835
- All CLOSED status, indicating multiple completed RDP sessions from base-rd-02 to the file server

SMB/445 Activity:
- 172.16.6.11:49763 → 172.16.4.5:445 ESTABLISHED (file server)
- 172.16.6.11:59352 → 172.16.7.15:445 ESTABLISHED
- Inbound: 172.16.6.14:65368 → 172.16.6.11:445 ESTABLISHED

WinRM/5985 Outbound:
- 172.16.6.11:49791 → 172.16.5.21:5985 CLOSED (remote PowerShell execution)

LDAP to Domain Controller:
- 172.16.6.11:56345 → 172.16.4.4:389 CLOSED

subject_srv.exe (F-Response forensic tool, port 3262):
- Listening on 0.0.0.0:3262 (PID 1096)
- 172.16.6.11:3262 → 172.16.5.50:39372 ESTABLISHED (forensic collection session)

External Connections:
- 172.16.6.11:49782 → 13.89.220.65:443 CLOSED (Microsoft Azure IP)
- 172.16.6.11:49360 → 52.16.55.11:443 CLOSED (Microsoft/cloud IP)

The 14+ connections to 172.16.4.10:8080, combined with the multiple RDP sessions to the file server and WinRM to 172.16.5.21, demonstrate that base-rd-02 was used as an active lateral movement pivot point in the attack campaign.

Affected Systems: bulk.httplogs, volatility.netscan, volatility.psscan

Multiple attacker staging directories were identified on base-rd-01 containing malicious tools:

1. c:\windows\temp\perfmon\ — Active Attack Staging Directory:
The primary implant p.exe (PID 8260) was deployed at c:\windows\temp\perfmon\p.exe, confirmed by cmdline output from volatility. An additional tool reference "c:\windows\temp\perfmon\sd." was found in ShimCache entries across multiple registry.system sources (source_ids 182, 202), confirming additional attacker tools were present in this directory. The "sd" filename is consistent with a service deployment tool (e.g., sd.exe for service management or lateral movement).

ShimCache evidence (from registry.system windows 625700 and 634542):
- c:\windows\temp\perfmon\sd. (truncated entry)
- Appears alongside system utilities like ipconfig.exe, systeminfo.exe, wmic.exe, taskkill.exe in the ShimCache ordering

2. C:\ProgramData\staging\install_wormhole\ — Software Deployment Staging:
An executable named install_msadvapi2_32.exe (14,183,796 bytes / ~14MB) was found at ProgramData\staging\install_wormhole\ in the MFT:
- Created: 2017-12-20 14:52:51
- Modified: 2018-05-08 21:07:43
- The file name "msadvapi2" mimics the legitimate Windows advapi32.dll
- ShimCache records show execution on 2018-05-08 21:07:43
- A related "Microsoft Advanced API 64" entry in ShimCache at C:\Program Files (x86)\Microsoft Advanced API 64\unins000.exe (2018-05-08 21:07:27) suggests this installs under a pseudo-legitimate directory name

The attacker used directories designed to blend with legitimate Windows components (perfmon = Performance Monitor, staging/install_wormhole = software deployment).

Base-wkstn-01 (IP 172.16.7.11) established 7 TCP connections to the known C2 proxy at 172.16.4.10:8080. All connections were in CLOSED state at memory capture time, indicating completed communication sessions. Source ports: 60085, 59703, 59511, 60121, 60001, 60167, 60117. This is the same C2 proxy address used across multiple compromised systems in the domain (file server, base-rd-02), confirming base-wkstn-01 was part of the same intrusion campaign. The connection pattern (multiple high ephemeral ports to a single destination on port 8080) is consistent with a reverse HTTPS or HTTP proxy used for command-and-control.

A suspicious executable named p.exe was dropped to c:\windows\temp\perfmon\ and executed on base-wkstn-01. Evidence from two independent sources:

1. Volatility cmdline (memory): cmd.exe (PID 5948) executing "C:\WINDOWS\system32\cmd.exe /C c:\windows\temp\perfmon\p.exe" with child process p.exe (PID 8260) running.

2. Registry ShimCache: Entry for "c:\windows\temp\perfmon\p.exe" with timestamp 2018-08-30 22:14:02, confirming file existence and execution on the filesystem.

The file location (Windows\Temp subdirectory), single-character filename, and execution via cmd.exe /C are consistent with attacker-dropped tools. The perfmon subdirectory name appears designed to blend with legitimate Windows Performance Monitor paths. The file was not found in the TSK file listing, suggesting it may have been deleted after use (anti-forensics).

A GZip-compressed PowerShell stager was delivered to base-wkstn-01 (172.16.7.11) via WinRM remoting at 2018-09-06 17:13:57. Evidence from PowerShell Operational Event Log (Event ID 4103):

The encoded command targeted -ComputerName 172.16.7.11 with a UTF-16LE encoded payload (PowerShell -EncodedCommand). Decoded payload:

$s=New-Object IO.MemoryStream(,[Convert]::FromBase64String("H4sIAAAAAAAAA..."))

The "H4sI" prefix identifies GZip-compressed data. This is the classic pattern used by post-exploitation frameworks (Metasploit, Empire, Cobalt Strike) to deliver compressed shellcode or scripts: Base64 decode → GZip decompress → Execute decompressed script via IEX.

The ScriptBlockId was 70ccb2b2-3c03-4d83-8a9c-e04f90151437. Additionally, earlier WinRM access was identified at 2018-08-22 04:50:38 from 172.16.5.25 (HTTP POST /wsman?PSVersion=5.1.14393.1944).

Memory forensics reveals a WMI-based remote code execution chain on base-wkstn-01:

1. WmiPrvSE.exe (PID 8840): Running from C:\WINDOWS\sysWOW64\wbem\wmiprvse.exe with "-Embedding" flag. The use of the 32-bit (SysWOW64) WMI provider is suspicious since the system is 64-bit. Additionally, PID 4936 and PID 11948 WmiPrvSE instances were running from the 64-bit path.

2. PowerShell spawned by WMI: PID 5848 powershell.exe running from c:\windows\syswow64\windowspowershell\v1.0\powershell.exe with flags "-Version 5.1 -s -NoLogo -NoProfile". The NoProfile and NoLogo flags are standard post-exploitation framework indicators (avoid loading user profiles, reduce output).

3. rundll32 spawned by PowerShell: PID 6768 rundll32.exe (empty cmdline) is a child of the PowerShell process, representing shellcode injection.

This WmiPrvSE → PowerShell → rundll32 chain is the canonical execution pattern for WMI-based lateral movement used by Metasploit's wmi_exec and Cobalt Strike's WMI execution methods.

Base-wkstn-01 (172.16.7.11) had an active ESTABLISHED WinRM connection to 172.16.5.21:5985 (port 56150) at the time of memory capture. Three additional CLOSED WinRM connections to the same destination were also present (ports 56149, 56137, 56148), indicating sustained WinRM session activity.

Additionally, inbound WinRM access from 172.16.5.25 was captured:
- 2018-08-22 04:50:38: HTTP POST /wsman?PSVersion=5.1.14393.1944 from 172.16.5.25:52783 to 172.16.7.11:5985

The workstation was both a recipient of WinRM-based attacks (receiving encoded PowerShell commands) AND an origin point for outbound WinRM lateral movement to 172.16.5.21. An RPC connection to the domain controller (172.16.4.4:135) was also observed (port 56133, CLOSED).

PowerShell Operational logs (Event ID 4103) captured PowerView reconnaissance script execution at 2018-08-31 22:16:12. The logged script blocks contain PowerView function signatures including:

• "SearchTerm, Term to search for, default of 'pass'" - searching user descriptions for passwords
• "SearchField, User field to search, default of 'description'" - targeting AD user description fields
• "ADSpath, The LDAP source to search through, e.g. 'LDAP://OU=secret,DC=testlab,DC=local'" - LDAP enumeration

This is PowerView's Find-UserField function from the PowerSploit framework, commonly used by attackers to search Active Directory user account description fields for plaintext passwords - a common misconfiguration where administrators store passwords in the description field.

The timestamp (2018-08-31 22:16:12) falls within the attack window when multiple systems were compromised via WMI and WinRM lateral movement. This reconnaissance activity was captured across multiple PowerShell log sources (source IDs 74, 75, 81, 82, 86), confirming it was logged on multiple systems in the domain.

The active C2 PowerShell session (PID 1332, WoW64/32-bit) on base-wkstn-05 spawned multiple short-lived rundll32.exe processes consistent with Metasploit/Cobalt Strike process migration and module injection.

Short-lived rundll32.exe instances spawned by PowerShell PID 1332:
- PID 5300: 2018-08-31 01:31:44 – 01:31:46 (2 seconds lifetime)
- PID 5056: 2018-08-31 20:23:08 – 20:23:29 (21 seconds)
- PID 4240: 2018-08-31 20:23:17 – 20:23:35 (18 seconds)
- PID 1972: 2018-08-31 20:23:52 – 20:23:56 (4 seconds)
- PID 3720: 2018-08-31 21:07:21 – 21:07:28 (7 seconds)

Long-running persistent rundll32.exe:
- PID 7100 (PPID 7148): Started 2018-08-31 18:43:50, NO exit time — still running at memory capture. 5 threads, 337 handles.

The short-lived rundll32.exe instances (2-21 seconds) are characteristic of Metasploit's process injection technique where rundll32.exe is spawned as a sacrificial process, shellcode is injected into its address space, and it either completes its task or fails and exits. The long-running PID 7100 with 337 handles suggests a persistent implant module (e.g., keylogger, screenshot capture, or lateral movement module) that maintained execution throughout the investigation period.

This pattern — PowerShell downgrade → rundll32 injection — matches the Metasploit post/multi/manage/shell_to_meterpreter module behavior observed on other systems in this investigation.

Affected Systems: volatility.cmdline, volatility.psscan

HTTP logs on the DMZ FTP server (172.16.10.12) show WebDAV access from internal workstation 172.16.5.26 to administrative shares, indicating lateral movement or administrative file operations.

WebDAV Access Events:
1. 2018-09-07 02:46:37 - OPTIONS /c$ from 172.16.5.26 via Microsoft-WebDAV-MiniRedir/10.0.16299 (Windows 10 Fall Creators Update)
2. 2018-09-07 05:21:52 - OPTIONS /srl-ftp from 172.16.5.26 via Microsoft-WebDAV-MiniRedir/10.0.16299

Significance:
- The /c$ path is the hidden administrative share mapping to the C: drive, requiring administrator-level credentials
- WebDAV access to admin shares provides full filesystem access to the server from a remote machine
- The User-Agent string identifies a Windows 10 workstation (build 16299/Fall Creators Update)
- The srl-ftp directory contains the suspected Cobalt Strike stager (sub-win-x64_base-hunt_5682_3262.exe) and forensic response tools

Context: The same internal IP (172.16.5.26) also authenticated via FTP as dblake and performed RETR operations on /Users/ paths on 2018-08-07. This workstation appears to have been used for both legitimate FTP access and administrative operations against the DMZ FTP server.

Network analysis of the 172.16.5.21 memory dump reveals this system was the convergence point for WinRM-based lateral movement from ALL compromised hosts in the environment. Inbound WinRM (port 5985) connections were observed from:

Active ESTABLISHED WinRM sessions at capture time:
- 172.16.7.11:55308 → 172.16.5.21:5985 (base-wkstn-01)
- 172.16.4.4:57252 → 172.16.5.21:5985 (Domain Controller)
- 172.16.4.5:61707 → 172.16.5.21:5985 (File Server / BASE-FILE)

CLOSED WinRM sessions (completed):
- 172.16.7.16:57202 → 172.16.5.21:5985
- 172.16.6.14:55115 → 172.16.5.21:5985
- 172.16.7.15:61537 → 172.16.5.21:5985 (base-wkstn-05)

Other network activity:
- subject_srv.exe (F-Response, PID 9908) listening on port 3262, deployed 2018-09-07 19:35:23
- 172.16.5.21:3262 → 172.16.5.50:51490 ESTABLISHED (F-Response evidence collection)
- 172.16.5.21:53384 → 172.16.4.5:445 ESTABLISHED (SMB to file server)
- 172.16.5.21:52018 → 172.16.5.20:443 CLOSED

Significance:
All six source IPs connecting via WinRM to this system are confirmed compromised hosts (base-wkstn-01, base-wkstn-05, DC, file server) or are in subnets with confirmed compromised systems (172.16.6.14, 172.16.7.16). The attacker used WinRM from every compromised pivot point to access 172.16.5.21, making it a primary target or management host in the attack campaign. The cbarton-a account was also observed conducting remote PowerShell reconnaissance against this system on 2018-08-15 17:00-17:07 via wsmprovhost.exe -Embedding.

A previously unreported compromised system at 172.16.6.15 was discovered during continued analysis. The system shows the identical Metasploit/post-exploitation attack pattern observed across other compromised hosts in the shieldbase.lan domain.

Compromise Evidence:
- powershell.exe (PID 20780) spawned by PID 17016 at 2018-08-31 01:00:30
- Running from SysWOW64 (32-bit architecture downgrade, T1059.001)
- Command: powershell.exe -nop -w hidden -encodedcommand [base64]
- Decoded payload follows Metasploit stager pattern: $s=New-Object IO.MemoryStream(,[Convert]::FromBase64String("H4sI...")); IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s,[IO.Compression.CompressionMode]::Decompress))).ReadToEnd()
- This is the EXACT same GZip-compressed, base64-encoded PowerShell stager seen on other compromised systems (BASE-FILE, base-wkstn-01, base-wkstn-05, base-rd-02)

System Profile (172.16.6.15):
- Windows Server (boot: 2018-06-04 20:19:20)
- McAfee endpoint protection deployed (VirusScan Enterprise, Host Intrusion Prevention, ePO Agent)
- Puppet Labs agent (mcollective) communicating with 10.10.254.1:61613
- Nagios NCPA monitoring agent
- LARIAT (Lincoln Lab) java application with external connections (24.59.13.39, 104.96.34.39)
- RDP enabled (port 3389)
- Autorunsc.exe was run on 2018-08-15 (possible forensic triage)

Suspicious Binary:
- msadvapi2_64.exe running from C:\Program Files (x86)\Microsoft Advanced API 64\ as a service (child of services.exe PID 664)
- "Microsoft Advanced API" is NOT a legitimate Microsoft product name
- The binary name mimics Windows advapi32.dll (Advanced Windows 32 Base API)
- This warrants further malware analysis

Network Context:
- java.exe (PID 1736) connections to external IPs 24.59.13.39 and 104.96.34.39 (CLOSED state)
- McAfee management on port 8081
- No observed connection to C2 proxy 172.16.4.10:8080 in netscan data

On the system at 172.16.6.14, SearchUI.exe (PID 9316) contains injected shellcode in a PAGE_EXECUTE_READWRITE memory region (VadS). The injected code contains x64 assembly prologue bytes (H\x89T$\x10H\x89L$\x08) and what appears to be a Metasploit-style shellcode decoder stub (\xfc\xe8\x04\x00\x00\x00), which is characteristic of the CLD; CALL $+4 pattern used by Metasploit's block_api and reverse_tcp payloads.

Network analysis confirms SearchUI.exe had an active connection to 172.16.4.10:8080 in CLOSE_WAIT state, consistent with a completed C2 communication session. This IP:port combination (172.16.4.10:8080) has been identified as C2/proxy infrastructure across multiple compromised systems in this investigation.

SearchUI.exe is a legitimate Windows Search UI process that should never contain executable shellcode or connect to internal web proxy infrastructure. The combination of malfind shellcode detection and active C2 network connection confirms process injection was used to establish a covert communication channel.

On the system at 172.16.6.14, in addition to the SearchUI.exe shellcode injection (separate finding), powershell.exe (PID 5452) contains injected Metasploit shellcode. Malfind analysis (source_id 398) shows the process has a VadS region with PAGE_EXECUTE_READWRITE protection containing the bytes: \xfc\xe8\x04\x00\x00\x00 - the classic Metasploit block_api shellcode prologue (CLD followed by CALL $+4 to find the return address on the stack).

The complete disassembly pattern shows: fc (CLD), e8 04 00 00 00 (CALL +4), 2c 95 (SUB AL, 0x95), 33 99 (XOR EBX, [ECX]), eb 27 (JMP +0x27), 5f (POP EDI) - this is a known Metasploit encoded payload decoder stub.

This confirms that the threat actor deployed Metasploit payloads on this system, injecting into both SearchUI.exe (PID 9316, with C2 to 172.16.4.10:8080) and PowerShell (PID 5452). The dual injection across processes suggests the attacker maintained redundant access channels.

Network analysis of BASE-FILE (172.16.4.5, source_id 7) reveals an outbound WinRM connection from 172.16.4.5:56281 to 172.16.5.21:5985 (CLOSED state), initiated by svchost.exe (PID 928). This demonstrates that the previously compromised BASE-FILE server was used as a pivot point to access the msadvapi2-infected system via Windows Remote Management.

This connection chain establishes lateral movement between the compromised file server infrastructure and the msadvapi2 backdoor system:
- BASE-FILE (172.16.4.5) → WinRM (5985) → 172.16.5.21 (msadvapi2 system)

Additionally, the msadvapi2 system (172.16.5.21) also received inbound WinRM from 172.16.7.16 (separate finding), indicating multiple systems were used to access this machine remotely.

BASE-FILE also shows SMB connections to multiple systems (172.16.5.20, 172.16.6.11, 172.16.7.12), consistent with its role in the attacker's lateral movement infrastructure. The WinRM-based lateral movement is consistent with the WMI/PowerShell attack patterns observed across this campaign.

Affected Systems: volatility.netscan, volatility.pslist

The system identified as base-rd-06 (IP 172.16.6.13, R&D subnet) shows confirmed compromise with multiple indicators:

Backdoor Installation:
- msadvapi2_32.exe (PID 2288) running as a service under services.exe (PID 764) since 2018-08-17 13:46:31 from C:\Program Files (x86)\Microsoft Advanced API 32\
- msadvapi2_64.exe (PID 2304) running as a service under services.exe (PID 764) since 2018-08-17 13:46:31 from C:\Program Files (x86)\Microsoft Advanced API 64\
- Both are masquerading as "Microsoft Advanced API" — a fabricated name designed to blend with legitimate Microsoft binaries

C2 Communication:
- CLOSE_WAIT connection from 172.16.6.13:50093 → 172.16.4.10:8080 (organizational web proxy used as C2 relay)
- This matches the same C2 infrastructure observed across other compromised systems

Lateral Movement Evidence:
- RDP connection FROM 172.16.6.14:50663 → 172.16.6.13:3389 (CLOSED) — the attacker moved between R&D systems
- SMB connection to BASE-FILE server: 172.16.6.13:49889 → 172.16.4.5:445 (ESTABLISHED) — possible data access/staging
- WinRM listening on port 5985 — enabled for remote management

System Context:
- Windows 10 VM (VMware Tools present), boot time 2018-08-17 13:46:17
- McAfee endpoint security suite running (AV did not detect the msadvapi2 backdoor)
- LARIAT test framework (Lincoln Lab) present: prunsrv.exe PID 2136 → java.exe PID 2844
- Puppet configuration management agent running
- F-Response forensic agent deployed 2018-09-06 19:03:59

System Identification Note: This system is identified as base-rd-06 based on its location in the R&D subnet (172.16.6.x), being one of the four target memory dumps, and the F-Response deployment for the same investigation. The hostname was not directly confirmed in indexed evidence.

COUNTER-ANALYSIS NOTE: The cbarton-a remote PowerShell session on 2018-08-15 should be evaluated in the context of concurrent IR indicators.

Evidence of Concurrent IR Activity on 2018-08-15:
- Autorunsc.exe was executed on 172.16.6.15 on the same date (2018-08-15), consistent with Sysinternals-based IR triage
- The commands executed by cbarton-a (process enumeration via WMI, network adapter info, directory listing) are exactly what an incident responder would run during initial triage
- cbarton-a is referenced in Kerberos principals alongside other admin accounts (VPN infrastructure), suggesting a legitimate admin role

Commands Executed (all consistent with IR triage):
- Get-ChildItem -Force -Path "C:\WINDOWS\..." (directory enumeration — checking for suspicious files)
- WMI queries against \\BASE-RD-01\root\cimv2:Win32_Process (process listing — checking for malicious processes)
- Add-Member operations querying Username and NT AUTHORITY\SYSTEM processes (identifying process owners)
- Network adapter information gathering about 172.16.6.11 (network configuration review)

Assessment:
The most likely interpretation is that cbarton-a is an IT administrator who conducted initial IR triage on 2018-08-15, approximately two weeks before the main Metasploit deployment wave (Aug 27-31). The alignment with Autorunsc execution and the nature of the commands strongly favor the "legitimate admin" interpretation over "attacker using compromised credentials." However, this cannot be confirmed without access to HR/IT records identifying cbarton-a's role.

If cbarton-a IS a legitimate admin, this suggests the organization was aware of potential compromise by August 15 — before the main offensive operations escalated in late August.

The primary user account on base-rd-01 is shieldbase\tdungan, who maintained an active interactive session during the entire attack period. The following user accounts were observed interacting with base-rd-01:

1. shieldbase\tdungan (Primary User):
- Active desktop session with rich application set: Outlook (PID 8128), OneDrive, Chrome, Dashlane password manager
- RDP sessions were LOCAL logons (console access)
- User profile paths confirm as primary workstation user
- The attack ran silently in Session 0 via WMI while tdungan's interactive session continued in a separate session — the user likely had no visibility into the compromise

2. shieldbase\Administrator:
- Multiple LOCAL RDP sessions recorded in Terminal Services logs
- Used for system administration tasks

3. shieldbase\cbarton-a:
- Remote PowerShell session via WinRM on 2018-08-15 16:32-16:36 UTC
- Performed system reconnaissance (process enumeration, directory listing, network info)
- User profile (MFT record 154919) exists with AppData under Users\cbarton-a
- This admin account warrants investigation for potential compromise

4. shieldbase\jpallen:
- Profile referenced in ShimCache entries (C:\Users\jpallen\AppData\Local\Microsoft...)
- Appears to be an additional user account that previously logged into this system

No evidence of unauthorized account creation was found in the indexed event logs. The Windows Security event log was not indexed for base-rd-01, limiting visibility into authentication events (logon type 3/10 from remote systems).

The DMZ FTP server (IIS FTPSVC2 on 172.16.10.12, port 21) was targeted by brute force credential attacks from multiple external IP addresses. All attempts resulted in 530 (authentication failure) responses.

Attacker IPs and Targeted Accounts:
- 221.151.127.218: Targeted "administrator" account - multiple 530 failures
- 95.47.155.87: Targeted "stark-r" account - multiple 530 failures
- 138.197.213.41: Targeted "rsydow-a" account on 2018-08-16 04:19-04:20 - rapid-fire brute force with dozens of attempts in seconds
- 146.185.222.48: FTP scanning on multiple dates
- 185.255.31.2: FTP scanning on 2018-08-31
- 58.62.55.130, 60.212.42.56, 164.52.24.165, 61.153.54.38: Additional brute force/scanning sources on 2018-08-08 through 2018-08-10

Pattern Analysis: The attack on 138.197.213.41 showed the most aggressive pattern - rapid repeated USER/PASS sequences targeting the rsydow-a account with sub-second intervals, characteristic of automated credential stuffing tools. The targeting of "stark-r" and specific user accounts suggests pre-enumeration of usernames.

Failed Internal Authentication: 172.16.7.11 attempted and failed to authenticate as "dblake" on 2018-08-08 13:24:09 (530 failure), which may indicate lateral movement attempts from a compromised internal host.

None of the external brute force attempts appear to have succeeded based on the available evidence.

Two IIS FTP log files from the FTPSVC2 service on DMZ-FTP (172.16.10.12) were deleted, as identified by TSK file listing (deleted entries marked with *):

Deleted Logs:
- u_ex180805.log (August 5, 2018) - deleted, inode marked with * prefix
- u_ex180823.log (August 23, 2018) - deleted, inode marked with * prefix

Context: The FTP log directory (inetpub/logs/LogFiles/FTPSVC2/) contains daily logs spanning from u_ex180728.log through u_ex180907.log. The two deleted files create gaps in the logging timeline:
- Gap 1: August 5, 2018 - during the early investigation period
- Gap 2: August 23, 2018 - mid-incident window

All other daily log files in the sequence are intact. The selective deletion of only two log files, rather than all logs, suggests intentional evidence destruction targeting specific dates of interest rather than routine log rotation. IIS log rotation typically does not delete old files; it creates new ones daily.

These deleted logs may have contained evidence of unauthorized access or data exfiltration during the deleted time periods. The dates fall within the active brute force and scanning window (August 2018).

FTP logs show data retrieval operations targeting user profile directories on the DMZ FTP server (172.16.10.12) from internal workstation 172.16.5.26.

Evidence from carved FTP logs:
- 2018-08-07 23:30:07 - RETR /Users/ operations from 172.16.5.26 with data channel activity (DataChannelOpened)
- Multiple DataChannel operations around 23:30-23:36 on 2018-08-07
- 2018-08-07 23:32:23 - dblake authenticated successfully (PASS *** 230) from 172.16.5.26
- Additional FTP operations continued through 23:36

Carved Email Reference: ftp--dblake@ftp.stark-research-labs.com-Users-nfury-Asg... suggests FTP path access into the Users/nfury/ directory structure, indicating user nfury's files were accessed.

Related Activity: The dblake account was also used from Azure IP 40.121.0.91 on 2018-08-10 for FTP operations (TYPE A, PORT commands).

Concern: The RETR operations on /Users/ directories, particularly targeting nfury's profile, indicate file downloads from user directories. This is consistent with either legitimate file retrieval or data staging/exfiltration, depending on whether these operations were authorized. The activity from an internal workstation during late evening hours (23:30 UTC) warrants investigation.

FTP logs reveal that user rsydow-f authenticated to the DMZ FTP server (172.16.10.12) from two external IP addresses, with the password captured in cleartext in the logs.

Authentication Events:
1. 2018-07-16 21:08 - rsydow-f authenticated from 108.79.235.64 with password "mprsydow@mail.com" (230 success)
- Followed by PORT and data channel operations at 21:09
- Password visible in cleartext in carved FTP log entry

1. 2018-09-03 18:20:25 - Activity from 165.227.50.129 with password "asdfa" (response code in log)
2. SYST command executed (215 response)

3. Additional PORT and DataChannel operations at 18:21:35

4. 2018-09-05 16:37:28-18:47:48 - rsydow-f authenticated from 165.227.50.129 as DMZ-FTP\rsydow-f

5. Active data channel operations (DataChannelOpened/Closed)
6. Session persisted for over 2 hours

User Profile: The rsydow-a user profile exists on the server at Users/rsydow-a/ with Downloads directory created 2018-08-07T19:05:25 and PowerShell ModuleAnalysisCache present (MFT entry 33601), indicating interactive logon activity.

Security Concern: The FTP password (mprsydow@mail.com) is logged in cleartext, violating credential protection best practices. The use of an email address as a password represents poor credential hygiene. The rsydow account accessed the server from multiple external IPs across multiple dates.

The rsydow-a user account has an interactive local profile on the DMZ FTP server (172.16.10.12) with evidence of active system usage, suggesting interactive logon access beyond FTP.

User Profile Evidence (from tsk.filelist and ez.mft):
- Full user profile directory at Users/rsydow-a/ with standard AppData structure
- rsydow-a Downloads directory created: 2018-08-07T19:05:25 (MFT)
- PowerShell ModuleAnalysisCache present (MFT entry 33601) - generated only when PowerShell runs interactively
- AppData/Roaming/Microsoft/Protect/CREDHIST file present - credential protection history, populated during interactive logon
- Network Connections phonebook (rasphone.pbk) present

External FTP Access by rsydow Account:
- rsydow-f authenticated successfully from 108.79.235.64 on 2018-07-16 (password: mprsydow@mail.com)
- rsydow-f authenticated from 165.227.50.129 on 2018-09-03 through 2018-09-05
- 138.197.213.41 attempted brute force against rsydow-a on 2018-08-16 (all failed)

Significance: The presence of an interactive user profile (PowerShell cache, CREDHIST) for rsydow-a indicates this account was used for RDP, console, or other interactive logon sessions, not merely FTP access. The rsydow-a/rsydow-f accounts appear related (possibly the same person using different account names for local vs FTP access). The Downloads directory creation date (2018-08-07) aligns with the period of active attacker interest in this server.

Bulk_extractor carved data reveals a SoftEther VPN Server running on 172.16.1.20, providing external remote access to the shieldbase.lan network. Multiple external IP addresses connected via VPN:

External VPN connections identified:
- 108.79.235.64: Connected via MSRASV5.20, associated with account rsydow-f (same IP used for FTP access to DMZ-FTP server)
- 144.121.9.222: Connected to SoftEther VPN Server
- 65.114.90.19: SoftEther VPN connection
- 107.107.185.201: SoftEther VPN connection
- 166.172.120.210: MSRASV connection
- 40.121.0.91: Azure IP associated with dblake FTP access (from DMZ FTP finding)

VPN User Accounts:
- NFury: VPN account (referenced as "NFury" in VPN logs at 172.16.1.20)
- rsydow: VPN account
- cbarton: Kerberos principal cbarton@SHIELDBASE.LAN

Security Implications:
The SoftEther VPN provides a legitimate pathway for external access that the attacker could leverage. The rsydow-f account accessing both FTP and VPN services from 108.79.235.64 suggests this may be a legitimate remote worker. However, the VPN infrastructure provides external entry that could have been used for initial access if credentials were compromised. The FTP brute force attempts against rsydow-a from 138.197.213.41 (separate from the VPN IP) suggest the attacker was aware of this account's existence.

Network Context:
The VPN server at 172.16.1.20 bridges external users into the 172.16.x.x corporate network, providing a potential initial access vector if VPN credentials were compromised through phishing, credential stuffing, or reuse from the FTP password exposure (mprsydow@mail.com).

On the base-mail Exchange server (172.16.4.6, boot 2018-08-30 21:27:22), a long-running rundll32.exe process (PID 15116) was identified running in Session 0 (system context) since 2018-08-31 19:47:10. The process runs as WoW64 (32-bit on 64-bit OS) and was spawned by an unknown parent (PPID 15896, which has exited).

DLL analysis (source_id 407) shows PID 15116 loads network-related libraries including rsaenh.dll (RSA encryption), napinsp.dll, mswsock.dll, GDI32.dll, and win32u.dll. This DLL combination is unusual for a legitimate rundll32.exe invocation. The command line for this process was not captured in the cmdline output, which may indicate it was launched with cleared command-line arguments.

Timeline context: This rundll32.exe started approximately 24 minutes after an RDP session began (2018-08-31 19:23:54, Session 2). The RDP session includes rdpclip.exe, explorer.exe, iexplore.exe, ServerManager, and PowerShell (PID 5144). The close temporal proximity suggests the rundll32.exe may have been deployed during this RDP session.

While base-mail does not show direct C2 connections to 172.16.4.10:8080, the pattern of a long-running Session 0 rundll32.exe with no visible command line is consistent with post-exploitation implant behavior seen on other compromised systems in this investigation.

COUNTER-ANALYSIS NOTE: This finding requires cautious interpretation.

Chrome.exe C2 Connections — Ambiguous:
Chrome.exe (PID 7300) connecting to 172.16.4.10:8080 and :80 is EXPECTED behavior on this network. The 172.16.4.10 system is the organizational web proxy used by ALL systems in the environment (including the confirmed-clean forensic workstation at 172.16.5.25 and admin workstation at 172.16.5.26). Chrome browser traffic through a web proxy is normal, not inherently a C2 indicator. Without evidence of Chrome being injected with malicious code or generating unusual traffic patterns (beaconing intervals, encoded payloads), Chrome's proxy connection alone does not confirm C2.

Malfind Detections — Require Scrutiny:
- MsDtsSrvr.exe (PID 1208): SQL Server Integration Services runtime. SSIS executes .NET code including dynamic compilation, which can legitimately produce RWX memory regions for JIT compilation. This detection is LIKELY a false positive without examination of the actual memory content.
- sqlceip.exe (PID 2184): SQL Server Customer Experience Improvement Program telemetry. .NET-based process with expected JIT RWX regions.
- explorer.exe (PID 1396): This detection is more concerning as explorer.exe does not typically require large RWX regions. However, without examining the hex dump for shellcode patterns (NOP sleds, call stubs), this remains ambiguous.

Assessment:
The finding remains at "inference" confidence. The Chrome proxy connection is NOT evidence of C2 by itself. The explorer.exe malfind is the strongest indicator but lacks corroboration from other sources (no PowerShell stager, no WMI chain observed on this system). This finding is individually weak but is noted as part of the broader pattern — the system is on the same subnet as confirmed compromised systems and had SMB connectivity from BASE-FILE.

Memory forensics of base-sp (172.16.4.7) reveals a Microsoft SharePoint Server with potentially suspicious PowerShell activity.

SharePoint Server Identification:
- IP: 172.16.4.7
- SharePoint service ports: 808 (SharePoint app server) and 22233 (SharePoint Search service) with multiple active local connections
- Multiple self-referential connections (172.16.4.7:808 ↔ 172.16.4.7:50xxx) are normal SharePoint inter-component communication
- plasrv.exe (PID 12636) running on port 58661 (Performance Logs & Alerts)

Suspicious PowerShell Activity:
- powershell.exe (PID 7520) created 2018-08-02 05:04:03 with active UDP connections (both IPv4 and IPv6)
- This PowerShell process was actively creating network connections, which could indicate:
a) Legitimate SharePoint administration via PowerShell
b) Post-exploitation activity (Metasploit/Empire stager)
- The timestamp (2018-08-02 05:04 UTC, early morning) warrants investigation for authorized activity

Network Exposure:
- WinRM (port 5985) LISTENING - accessible for remote management
- SMB (port 445) LISTENING
- No direct C2 connections to 172.16.4.10:8080 observed in available netscan data
- The server is on the same subnet (172.16.4.x) as the compromised file server (172.16.4.5), domain controller (172.16.4.4), and Exchange server (172.16.4.6)

Context:
- Admin workstation 172.16.5.26 RDP'd to "base-sp" at 2018-08-25 23:25:36 (from finding f_4cb0d525)
- Being on the 172.16.4.x server subnet, base-sp was within direct reach of the attacker who had compromised the DC and file server
- Without indexed EVTX Security logs from this server, authentication events and potential lateral movement TO this system cannot be fully assessed

Assessment:
The PowerShell process (PID 7520) on the SharePoint server at 2018-08-02 05:04 UTC is suspicious but without additional context (cmdline not captured, no EVTX), it cannot be confirmed as malicious. The server's WinRM exposure and subnet placement make it a high-value lateral movement target.

COUNTER-ANALYSIS CORRECTION: The filename components strongly suggest this is an F-Response forensic tool binary, not a Cobalt Strike stager.

F-Response Interpretation (PREFERRED):
- "sub" = F-Response "Subject" agent (the subject_srv.exe binary deployed on target systems)
- "win-x64" = Windows x64 platform variant
- "base-hunt" = The F-Response management workstation hostname (confirmed at 172.16.5.25, running license_ctrl.exe on port 5682)
- "5682" = F-Response license controller port (confirmed: PID 1716 on base-hunt listening on port 5682)
- "3262" = F-Response subject agent port (confirmed: subject_srv.exe listens on port 3262 across all deployed systems)

The file resides in the srl-ftp directory alongside fresponse-agent.msi (the F-Response installer) and Mnemosyne.sys (a forensic driver), consistent with an IR tool staging location.

Remaining Concern — Timestamp Anomaly:
MFT analysis shows $SI Created (2013-08-22) predates $FN timestamps (2018-08-09) by 5 years. This could indicate:
a) Timestomping by an attacker who placed a malicious file alongside IR tools
b) The file was extracted from a signed/versioned installer package that preserved original build timestamps
c) Filesystem metadata inconsistency during file copy or extraction

At 4,246 bytes, the file size is consistent with both a small stager AND a minimal agent executable.

Assessment:
Given the strong filename correlation to F-Response port parameters (5682/3262 exactly match confirmed F-Response infrastructure), the co-location with other F-Response tools, and the absence of any evidence this file was executed maliciously, the Cobalt Strike interpretation is LESS likely than the F-Response interpretation. The timestamp anomaly prevents full dismissal but is not sufficient alone to override the naming evidence. Severity downgraded from high to low.

Original MITRE mappings removed: T1059.001 (no execution evidence), T1036.006, T1070.006 (timestamp anomaly preserved as a note).

Memory forensics of base-wkstn-02 (172.16.7.16, dual-homed 10.10.150.177) reveals an actively used Windows 10 workstation. System boot time: ~2018-09-03 13:51.

Legitimate User Activity:
- OUTLOOK.EXE (PID 3044): Multiple ESTABLISHED connections to Exchange server (172.16.4.6:80) - confirmed OWA/Exchange access
- firefox.exe (PID 3656): Active browser session with connections to 104.88.80.153:443 (SYN_SENT) and localhost loopback (port 7055, 49429)
- SMB to file server: 172.16.7.16:49236 → 172.16.4.5:445 ESTABLISHED

LARIAT Framework Present:
- java.exe (PID 1752/5040) running LARIAT with connections to 10.10.200.207:5672 (RabbitMQ AMQP)
- LARIAT java processes connected to multiple external IPs in CLOSED state: 24.139.91.27, 88.197.234.24, 104.201.158.26, 216.232.147.26, 248.86.12.27
- LARIAT ncpa_passive.exe (PID 2784) listening on localhost:49299

Infrastructure Services:
- McAfee Agent (masvc.exe PID 1824), macmnsvc.exe (PID 1744) on port 8081/8082
- Puppet Labs rubyw.exe (PID 5796) → 10.10.254.1:61613 ESTABLISHED
- subject_srv.exe (PID 488, F-Response) on port 3262 → 172.16.5.50:46980 ESTABLISHED

Assessment:
- No Metasploit/Empire PowerShell stager detected
- No msadvapi2 backdoor present
- No C2 connections to 172.16.4.10:8080 observed
- No WMI→PowerShell attack chain observed
- No malfind code injection detections specific to this system
- Previous WinRM connection from this IP to 172.16.5.21:5985 was observed (CLOSED state in 172.16.5.21's memory), but this could have been initiated by the attacker using compromised credentials rather than indicating this workstation itself was compromised

This system appears to be a legitimate workstation that was accessible to the attacker via WinRM but does not show active compromise at the time of memory capture.

CORRECTION: subject_srv.exe has been identified as the F-Response Subject agent, a legitimate forensic remote acquisition tool — NOT malicious activity.

Conclusive Evidence:
The command line for subject_srv.exe (PID 1096 on base-rd-02, PID 6160 on file server) reads:
C:\windows\subject_srv.exe -s "base-hunt.shieldbase.lan:5682" -l 3262 -v "F-Response Subject" -k "155522845"

The "-v F-Response Subject" parameter identifies this as the F-Response forensic acquisition agent. F-Response is a commercial forensic tool that provides remote access to systems for evidence collection. The "base-hunt.shieldbase.lan" server name suggests a forensic investigation workstation.

Expected Behavior Explained:
- Installed in C:\windows\ — F-Response deploys its agent to the Windows directory
- Running as WoW64 (32-bit) — F-Response Subject agent is a 32-bit binary
- Listening on non-standard port 3262 — this is the F-Response access port specified by -l flag
- Outbound to 172.16.5.50 — the forensic examiner's workstation conducting evidence collection
- Running as a service from services.exe — F-Response installs as a Windows service for persistence during evidence collection
- Present since 2018-04-10 — consistent with a previously deployed forensic investigation capability or an earlier investigation

Assessment:
All indicators previously assessed as suspicious are consistent with legitimate F-Response deployment. This finding supersedes the original assessment. The YARA Codoso/Deep Panda matches previously associated with subject_srv.exe should be evaluated independently of this binary.

Previous MITRE ATT&CK mappings (T1543.003, T1036) are removed as this is legitimate software.

YARA memory scanning produced 233 windows of APT6_Malware_Sample_Gen matches across the memory dumps. Upon examination of the matched strings, these detections are assessed as FALSE POSITIVES rather than evidence of APT6 malware.

The matched strings are generic and commonly found in legitimate Windows binaries and system memory:
- "shellcode" - generic string found in many security tools and documentation
- "synflood", "udpflood" - networking terms found in system libraries
- "C:\WINDOWS\system32\" - common Windows system path prefix
- Other generic byte patterns common in system DLLs

These strings individually and collectively do not indicate the presence of APT6 malware. The YARA rule APT6_Malware_Sample_Gen appears to use overly broad signatures that match common system artifacts.

While the DC IS compromised (as evidenced by the C2 channel, PowerView execution, and Meterpreter-style code injection), the YARA matches do not provide attribution to APT6 or any specific threat actor. The attack TTPs (PowerView, WMI, Meterpreter, Rar.exe staging) are widely used across criminal and nation-state groups.

COUNTER-ANALYSIS CORRECTION: The Win32_ShadowCopy PowerShell activity originally characterized as "Shadow Copy Manipulation" and "ransomware preparation" has been re-assessed as shadow copy enumeration by an administrator or incident responder.

Corrected Evidence Analysis:
The PowerShell Operational Log (Event ID 4103, 2018-08-31 21:53:03) captures:
1. Get-CimInstance -ClassName win32_ShadowCopy — This is a READ/QUERY operation, NOT a deletion command. The Delete() method or Remove-CimInstance cmdlet are NOT present.
2. ForEach-Object { write "VSC created $($_.installdate) for host $($_.Servicemachine)" } — This simply DISPLAYS the creation date and service machine for each shadow copy. This is diagnostic output, not manipulation.
3. The user executing this was shieldbase\rsydow-a via WinRM (Host Application: wsmprovhost.exe -Embedding), NOT spsql as originally reported. rsydow-a appears to be an administrator or incident responder.

NetFirewallRule Module Loading:
The co-occurring NetFirewallRule module content (Export-ModuleMember for Show-NetFirewallRule, Rename-NetFirewallRule) is automatic PowerShell module loading, not explicit firewall manipulation.

Assessment:
This activity is consistent with routine administrative shadow copy auditing or incident response reconnaissance. The original T1490 (Inhibit System Recovery) mapping is removed as no evidence of shadow copy deletion exists. The original finding significantly overstated the threat level.

MITRE ATT&CK mapping removed: T1490 (no deletion evidence), T1562.004 (no firewall manipulation evidence). Retaining T1059.001 for PowerShell execution only.

COUNTER-ANALYSIS CORRECTION: The original finding framed subject_srv.exe deployment as the attacker "installing a persistent backdoor service" as a final step in the attack chain. This is INCORRECT — finding f_5bcb1c4e conclusively identifies subject_srv.exe as the F-Response forensic remote acquisition agent deployed by incident responders.

Corrected Timeline:
The deployment of subject_srv.exe between Snapshot5 (~2018-09-05 15:03) and Base-file-memory (~2018-09-06 19:25) represents the IR team deploying F-Response for forensic evidence collection, NOT an attacker establishing persistence.

Valid Observations (Retained):
- Snapshot5 captured active attacker operations: Rar.exe data staging (PID 2524), PowerShell C2 chain (PIDs 4072/3164)
- Base-file-memory captured post-IR-deployment state with F-Response active and attacker artifacts still resident in memory
- The PowerShell C2 chain remained active across both captures, confirming sustained attacker presence
- Rar.exe completed execution between captures (exited 2018-09-05 14:52:56)

Impact on Attack Timeline:
The subject_srv.exe deployment milestone should be removed from the attacker kill chain. The actual attacker timeline on BASE-FILE remains: WMI C2 initiation (Aug 28) → rundll32 injection (Aug 30-Sep 6) → data staging via Rar.exe (Sep 5).

MITRE mapping corrected: T1543.003 removed (subject_srv.exe is IR tooling, not attacker persistence). T1560.001 retained for Rar.exe staging.

Analysis of network connections from memory dumps and disk artifacts reveals the following IOCs and network architecture:

Compromised Hosts (10+ systems):
- 172.16.4.5 (BASE-FILE) - Active C2 implant, data staging, Rar.exe exfil prep
- 172.16.4.4 (BASE-DC) - Domain controller, YARA Codoso/Deep Panda tool signatures
- 172.16.5.21 - WinRM convergence point, msadvapi2 backdoor, cross-subnet pivot
- 172.16.5.20 - Web/DB server, Chrome C2 proxy connections, process injection
- 172.16.6.11 (base-rd-02) - Metasploit stager, p.exe implant, C2 via proxy
- 172.16.6.13 (base-wkstn-03/base-rd-06) - msadvapi2 + Metasploit dual compromise
- 172.16.6.14 (base-wkstn-04) - Interactive C2, SearchUI.exe injection, 30+ proxy connections
- 172.16.6.15 - msadvapi2_64 + Metasploit stager
- 172.16.7.15 (base-wkstn-05) - 3 WMI attack chains, rundll32 injection
- 172.16.7.16 (base-wkstn-01) - WMI stager, WinRM encoded command delivery

C2/Proxy Infrastructure:
- 172.16.4.10:8080 - Web proxy used for C2 tunneling (7+ compromised hosts connect)

Lateral Movement Hub:
- 172.16.5.21:5985 - WinRM convergence from all compromised subnets

Legitimate Infrastructure (Not Compromised):
- 172.16.5.25 (base-hunt) - F-Response forensic workstation
- 172.16.5.50 - F-Response evidence collection endpoint
- 172.16.5.26 (admin workstation) - SSH/RDP admin access, no compromise indicators
- 172.16.4.6 (base-mail) - Exchange server, suspicious rundll32 but no confirmed C2
- 172.16.4.7 (base-sp) - SharePoint, suspicious PowerShell but unconfirmed

External IOCs:
- 108.79.235.64 - rsydow-f FTP/VPN access (likely legitimate remote worker)
- 138.197.213.41 - Aggressive brute force against rsydow-a FTP account
- 221.151.127.218, 95.47.155.87, 146.185.222.48, 185.255.31.2 - FTP scanning/brute force
- 172.16.1.20 - SoftEther VPN server (external access gateway)

Analysis of $STANDARD_INFORMATION vs $FILE_NAME timestamps in the MFT data detected only 2 timestomping entries across both disk images. Both were root directory entries (likely OS installation artifacts) and showed no indicators of malicious timestamp manipulation.

Forensic Note:
Despite the absence of timestomping detections, the attacker used other defense evasion techniques:
- Placing subject_srv.exe in C:\windows\ to blend with legitimate system files
- Using legitimate tools (PowerShell, rundll32, WMI) for attack operations (Living off the Land)
- Tunneling C2 traffic through the web proxy at 172.16.4.10:8080
- Shadow Copy manipulation to prevent recovery

The lack of timestomping may indicate that the attacker did not attempt to modify file timestamps, or that the tools used (which are primarily memory-resident) didn't require timestamp manipulation for persistence.

YARA scanning of the base-rd-02 disk image (base-rd-02-cdrive.E01) produced a single rule match: APT_MAL_RU_WIN_Snake_Malware_May23_1. Upon examination of the matched strings, this detection is assessed as a FALSE POSITIVE.

Matched Strings:
- $a: 25 73 23 31 → hex for "%s#1" (a generic format specifier)
- $b: 25 73 23 32 → hex for "%s#2" (a generic format specifier)

Multiple offset matches were found across the disk image at various locations. These format strings ("%s#1", "%s#2") are extremely common in Windows binaries and are used for string formatting operations. They do not indicate the presence of Snake/Uroburos malware.

Context:
- The same false positive occurred on the base-rd-01 disk image with identical matched strings
- No other YARA rules triggered on the base-rd-02 disk image
- The real compromise on base-rd-02 was identified through memory forensics (PowerShell C2 chain, p.exe implant, malfind hits) rather than disk-based signatures
- The attacker's tools on base-rd-02 were primarily memory-resident, explaining the limited disk-based signature matches

Assessment:
The Snake Malware YARA rule uses overly broad format string signatures that match common Windows binary patterns. No evidence of Snake/Uroburos malware was found on base-rd-02.

The DMZ FTP server is identified as:

System Identity:
- Hostname: DMZ-FTP
- IP Address: 172.16.10.12
- Domain: shieldbase.lan (Stark Research Labs)
- Operating System: Windows Server 2012 R2 (kernel version 6.3.x per MFT entries)

FTP Service Configuration:
- Software: Microsoft IIS FTP Service (FTPSVC2, version 8.5.0.0 per carved package data)
- Log Directory: inetpub/logs/LogFiles/FTPSVC2/
- FTP Logs: Daily rotation files from u_ex180728.log through u_ex180907.log
- IIS HTTP (W3SVC1): Also running with logs at inetpub/logs/LogFiles/W3SVC1/
- Web Root: inetpub/wwwroot/ with default IIS content (iisstart.htm, iis-85.png)

FTP User Accounts Identified:
- dblake (DMZ-FTP\dblake): Legitimate user, accessed from Azure (40.121.0.91) and internal (172.16.5.26)
- rsydow-f (DMZ-FTP\rsydow-f): External user, accessed from 108.79.235.64 and 165.227.50.129
- rsydow-a: User profile exists at Users/rsydow-a/ with interactive session evidence (PowerShell cache, Downloads directory created 2018-08-07)
- anonymous: Attempted from 172.16.5.26, authentication failed

FTP Content Directory (srl-ftp):
- fresponse-agent.msi: Forensic response tool, created 2018-09-07T20:57:23
- Mnemosyne.sys: Likely forensic driver/tool
- sub-win-x64_base-hunt_5682_3262.exe: Suspicious executable (see separate finding)
- test.txt: Test file

Network Exposure: The FTP server on port 21 was accessible from external internet addresses, with brute force attempts observed from multiple countries.

The DMZ FTP server disk image contains Windows Event Log files that were not extracted or indexed during the initial processing phase. This creates an analysis gap for several investigation questions.

Event Logs Present on Disk (from TSK file listing):
- Archive-Security-2018-08-08-08-57-05-737.evtx
- Archive-Security-2018-08-20-00-56-16-595.evtx
- Archive-Security-2018-08-23-23-18-50-784.evtx
- Additional Security archive files
- Microsoft-Windows-TaskScheduler%4Operational.evtx
- Multiple other Microsoft-Windows-* operational and admin logs
- PowerShell operational logs

Impact on Investigation:
Without these logs indexed, the following questions cannot be fully answered for the DMZ FTP server:
- Unauthorized account creation or privilege escalation
- Detailed authentication events (logon types, source workstation names)
- Event log clearing/tampering (Event IDs 1102, 104)
- Scheduled task creation or modification (persistence)
- PowerShell execution history
- Service installation events

Recommendation: Run EVTX extraction (run_evtx_parser) on /evidence/dmz-ftp-cdrive.E01 and index the Security, System, PowerShell, and TaskScheduler logs to complete the investigation.

Memory analysis confirms 172.16.5.25 is the forensic investigation workstation "base-hunt.shieldbase.lan", running the F-Response management suite and AccessData FTK Imager. However, the system shows 15+ connections to the C2 proxy at 172.16.4.10:8080 which warrant documentation.

Forensic Tool Processes:
- license_ctrl.exe (PID 1716): F-Response license controller, listening on port 5682
- subject_ctrl.exe (PID 7076): F-Response subject controller
- connector_ctrl.exe (PID 6868): F-Response connector controller
- imager_ctrl.exe (PID 3324): F-Response imager controller
- license_monitor (PID 4272): F-Response license monitor
- main_console.exe (PID 6960): F-Response main console
- FTK Imager.exe (PID 928): AccessData forensic imager, started 2018-09-06 18:48:20
- ftusbsrvc.exe (PID 4916): FTK USB service on port 33001
- ruby.exe (PIDs 2240, 6780, 8116): F-Response backend (Ruby-based)

Network Connections to C2 Proxy 172.16.4.10:8080:
6 CLOSE_WAIT connections (ports 63084, 63082, 63039, 63036, 64358, 62946)
3 CLOSED connections (ports 58926, 58928, 58917, 58927, 58932, 58937, 58938, 58939, 58940)
Total: 15+ connections

External Connection:
- 172.16.5.25:64720 → 108.79.235.64:33000 ESTABLISHED

Assessment:
While the C2 proxy connections COULD represent legitimate web browsing through the organizational proxy by the forensic examiner, the CLOSE_WAIT state on 6 connections is notable (indicating the remote side closed but local cleanup didn't complete). The connection to 108.79.235.64:33000 is likely related to the F-Response USB service (port 33001 vs 33000) or remote evidence collection. Given this is the forensic workstation, these connections are assessed as likely benign but should be verified with the incident response team.

A Microsoft Exchange Server at 172.16.4.6 was captured in memory during the investigation. While no direct C2 indicators (connections to 172.16.4.10:8080) or WMI→PowerShell attack chains were found, the server is on the same subnet as compromised systems and accessible to the attacker.

Exchange Server Configuration:
- IP: 172.16.4.6 (also 10.10.4.6 dual-homed)
- Services: MSExchangeFrontend, EdgeTransport, MSExchangeSubmission, MSExchangeDelivery, MSExchangeMailboxAssistants, MSExchangeRepl, MSExchangeHMHost, MSExchangeHMWorker, ForefrontActive (anti-spam)
- Multiple w3wp.exe IIS worker processes serving OWA/EWS
- noderunner.exe (Exchange search indexing)
- hostcontroller process
- Boot time: 2018-08-30 21:27:31

Network Connections:
- Multiple LDAP connections to DC (172.16.4.4:389 and :3268) - expected Exchange behavior
- SMB connection to DC (172.16.4.4:445) - expected
- HTTP (port 80) ESTABLISHED from 172.16.7.16 - OWA web access
- powershell.exe (PID 5144) connected to DC LDAP and localhost:890 - likely Exchange Management Shell
- subject_srv.exe (F-Response, PID 17880) on port 3262 → 172.16.5.50 (forensic collection)

Assessment:
The Exchange server does not show the characteristic WMI→PowerShell→rundll32 attack chain or C2 proxy connections observed on other compromised systems. However, with domain admin credentials compromised and the attacker having full AD control, the Exchange server's email contents would have been accessible. The powershell.exe process (PID 5144) warrants further investigation but may be legitimate Exchange Management Shell. No Security EVTX logs were indexed for this system.

Memory forensics of base-wkstn-06 (172.16.5.26, boot 2018-07-29 12:55:18) identifies a Windows 10 administrative workstation in the 172.16.5.x management subnet. Despite extensive access to critical infrastructure, no indicators of compromise were found.

System Profile:
- Active user session with PuTTY SSH sessions to multiple infrastructure hosts:
- @base-elk (ELK stack), @onion-master (3 sessions), @proxy, @dmz-smtp, @dmz-dns
- RDP sessions via mstsc.exe to:
- /v:"base-sp" (SharePoint server, 2018-08-25 23:25:36)
- /v:"base-dc" (Domain Controller, 2018-09-01 17:23:44)
- Puppet configuration management agent (rubyw.exe PID 3800 → 10.10.254.1:61613 ActiveMQ)
- SMB to file server 172.16.4.5:445 ESTABLISHED (since 2018-08-09)
- notepad++ and MicrosoftEdge present in process tree

Negative Findings (No Compromise):
- No Metasploit/Empire PowerShell stagers or encoded commands detected
- No msadvapi2 backdoor present
- No WMI → PowerShell → rundll32 attack chain observed
- No connections to C2 proxy 172.16.4.10:8080
- No malfind code injection detections
- No suspicious rundll32.exe processes with empty command lines

WebDAV Activity to DMZ FTP Server:
Previously documented (finding f_954b7adf): this IP accessed /c$ and /srl-ftp via WebDAV on DMZ-FTP (172.16.10.12) on 2018-09-07. The dblake account from this IP also performed FTP operations including file retrieval from /Users/ directories.

Assessment:
base-wkstn-06 is a legitimate IT administrator workstation with broad infrastructure access (DC, ELK, DNS, SMTP, proxy, SharePoint) that was NOT compromised during the attack campaign. Its proximity to compromised systems in the domain and its elevated access privileges would have made it a high-value target. The absence of compromise indicators, despite the attacker having domain admin access and the ability to deploy WMI/WinRM attacks to any system, may indicate the attacker either did not target this specific workstation or had not yet reached it before incident response began.