Investigation Dashboard
The attack timeline spans 2009-12-05 to 2012-04-06. The earliest activity was Domain Controller Running Multiple Internet-Facing Services — Critical Attack Surface (2009-12-05). The investigation subsequently uncovered Classified Data Accessed Across Multiple Systems — Potential Exfiltration Staging; Coordinated Multi-System APT Campaign Across SHIELDBASE Domain — Single Threat Actor Kill Chain; Cross-System Credential Reuse: Vibranium Account Used from Both Compromised Workstations to Domain Controller. The most recent activity was Anomalous svchost.exe Spawned by explorer.exe on XP System (10.3.58.7) (2012-04-06).
- Snake/Uroburos APT Malware Detected on nromanoff Workstation Disk
- Cross-System Credential Reuse: Vibranium Account Used from Both Compromised Workstations to Domain Controller
- Coordinated Multi-System APT Campaign Across SHIELDBASE Domain — Single Threat Actor Kill Chain
- Classified Data Accessed Across Multiple Systems — Potential Exfiltration Staging
-
Snake/Uroburos APT Malware Detected on nromanoff Workstation Disk
2012-03-09T23:29:52
-
Cross-System Credential Reuse: Vibranium Account Used from Both Compromised Workstations to Domain Controller
2012-04-04T15:34:48 — 2012-04-04T16:37:53
-
Coordinated Multi-System APT Campaign Across SHIELDBASE Domain — Single Threat Actor Kill Chain
2012-03-15T03:09:18 — 2012-04-06T19:07:16
-
Classified Data Accessed Across Multiple Systems — Potential Exfiltration Staging
2012-03-09T23:29:52 — 2012-04-04T15:42:58
| Case ID | SRL-2015 |
| Evidence Root | /evidence |
| Report Generated | 2026-06-05T21:57:06 |
| Investigation Start | 2026-06-05T04:08:02 |
| Investigation End | 2026-06-05T06:16:51 |
| Total Processing | 5371.7s |
| Audit Log | /Volumes/exdr/cases/SRL-2015/SRL-2015.audit.jsonl |
Evidence Hashes
sha256sum <file>| File | SHA-256 | Size |
|---|---|---|
| win2008R2-controller-c-drive.E01 | 389ea6b4969cc132ac9a3f28fa572ffc588442ca25ec04bea059b52fd6db4e7e | 13.4 GB |
| win2008R2-controller-memory-raw.001 | 0980b543e6f659091ff4645c2b92771ede45c664e56dc754d420beeeae770edd | 2.5 GB |
| win7-32-nromanoff-c-drive.E01 | f92662135db8d1a5eb33de5b391186c1242b59641db1ba96b3e4ff52a5a1e5b6 | 9.0 GB |
| win7-32-nromanoff-memory-raw.001 | f40af394587fe1f6e6ed6b48e4840a4d4b5927c5d73d8e243d9d31225517d728 | 2.0 GB |
| win7-64-nfury-c-drive.E01 | a5df0b38ec699656e8c9925ffa515945288aaa32cd29c284fb519cf06d1589c7 | 11.2 GB |
| win7-64-nfury-memory-raw.001 | 0b53c16973774007244b82d6e777f669ee17224e8aa8c5fc98954196a27c9f5b | 2.0 GB |
| xp-tdungan-c-drive.E01 | 117511847d05cf3a52397b6800015b98d77fa3c8a31088a2592709825e402eb0 | 6.6 GB |
| xp-tdungan-memory-raw.001 | bf5c4740cbc71fb10946596f55226240c0bd2553993eebf8e9d38f5c9b9775cc | 2.0 GB |
Investigation Report
Forensic Investigation Report — Case SRL-2015: Stark Research Labs Network Intrusion
Background
This investigation was initiated in response to a suspected advanced persistent threat (APT) intrusion targeting the Stark Research Labs (SRL) network within the SHIELDBASE Active Directory domain. Forensic evidence was collected from four systems on the internal network: a Windows Server 2008 R2 domain controller (Controller.shieldbase.local, 10.3.58.4/10.3.58.9), a Windows 7 32-bit workstation assigned to user nromanoff (10.3.58.5), a Windows 7 64-bit workstation assigned to user nfury (WKS-WIN764BITB, 10.3.58.6), and a Windows XP 32-bit workstation assigned to user tdungan (WKS-WINXP32BIT, 10.3.58.7). Evidence artifacts included memory dumps and disk images from each system, collected via F-Response forensic acquisition agents.
The investigation leveraged 22 indexed evidence sources spanning memory forensics (Volatility 3), disk forensics (Sleuth Kit, EZ Tools), registry analysis (RegRipper), event log parsing (EVTX), network artifact carving (bulk_extractor), YARA signature scanning, Chainsaw Sigma rule analysis, and MFT/ShimCache/Prefetch execution timeline reconstruction. A total of 611 forensic tool invocations were executed. The analysis produced 29 forensic findings, of which 24 were corroborated by multiple independent evidence sources and 5 were assessed as analytically sound inferences from single-source evidence. No findings were ruled out as false positives (0 negative findings). The findings mapped to 39 distinct MITRE ATT&CK techniques.
The SRL environment presented an unusually high-risk architecture. The Windows 2008 R2 domain controller served simultaneously as the organization's Active Directory server, public-facing web server (IIS on ports 80/443), Apache/Tomcat host for McAfee ePO management, SMTP/POP3 email server (hMailServer for the stark-research-labs.com domain), DNS server, FTP server, Telnet server, SNMP agent, and Microsoft SQL Server instance. This consolidation of internet-facing services onto the domain controller — which holds the AD database (ntds.dit), Kerberos keys, and all domain credentials — created a critically expanded attack surface that was actively exploited by both external scanners and the threat actor.
Incident Timeline
The incident timeline spans from initial infrastructure compromise through sustained command-and-control operations, reconstructed from seven independent evidence sources across three compromised systems.
Phase 1 — Environment Preparation and Initial Compromise (pre-March 2012)
The earliest indicators of the threat actor's presence trace to the nromanoff workstation (10.3.58.5), where YARA rule APT_MAL_RU_WIN_Snake_Malware_May23_1 matched at fourteen or more distinct disk offsets spanning a wide address range (0x243b5ba3 to 0x23ba42cdd). The matched strings include Snake's characteristic internal component naming convention — sequentially numbered format strings %s#1 through %s#4 — alongside the malware's kernel driver queue file extensions (.tmp, .sav, .upd). The breadth and specificity of these matches across multiple string patterns are consistent with Snake's modular architecture, which deploys a kernel rootkit, usermode component, and encrypted virtual filesystem. The precise date of initial Snake deployment could not be determined, but the nromanoff workstation's classified documents were created as early as 2012-03-09, establishing that the system was in active use by that date.
Concurrently, the domain controller's internet-facing services attracted external reconnaissance. Search engine crawlers from Google (66.249.x.x), Baidu (180.76.x.x, 220.181.x.x), Yandex (95.108.x.x), and Facebook (69.171.x.x) indexed the web server, confirming its public accessibility. External IP 188.138.11.56 attempted to download a file from freetunel.com/cgi-bin.txt — a likely web shell retrieval attempt. IP 132.248.31.82 probed administrative paths (/webadmin/setup.php, /sqlweb/scr). Multiple IPs attempted unauthorized WebDAV access. YARA scanning of the domain controller's memory identified five distinct web shell families deployed across the server's web stack: CmdAsp (ASP), cmdjsp (JSP), connectback2 (Perl), sql_php from rst.void.ru (PHP), and RemCom (remote command execution). The web shell languages precisely correspond to the server platforms running on the controller — IIS serves ASP, Apache serves PHP/Perl, and Tomcat serves JSP — a correspondence that would be unlikely if these signatures originated solely from McAfee's in-memory antivirus pattern store rather than from actual deployed web shells.
Phase 2 — Tool Deployment and Credential Staging (2012-04-03 to 2012-04-04 12:41)
On the evening of April 3, 2012, the threat actor began deploying offensive tooling under the domain account "vibranium" (SID: S-1-5-21-2036804247-3058324640-2116585241-1673). Three PyInstaller-packaged Python 2.5 executables were sequentially extracted to the vibranium user's temporary directory on the domain controller: _MEI138842 at 23:09:16 UTC, _MEI57722 at 00:01:44 UTC on April 4, and _MEI111242 at 00:06:40 UTC. These bundles contained python25.dll, _ctypes.pyd, unicodedata.pyd, kernel32.dll, MSVCR71.dll, and bz2.pyd — the runtime components of standalone Python tools. The deployment under a user-context temporary path (AppData\Local\Temp) rather than a service account path, combined with the use of the already-outdated Python 2.5 runtime, is inconsistent with McAfee ePO management components and consistent with offensive Python tooling.
On the XP workstation (10.3.58.7), the threat actor deployed a command-and-control toolkit to the system32 directory. ShimCache analysis records spinlock.exe at C:\WINDOWS\system32\spinlock.exe with a LastModified timestamp of 2012-04-04 17:06:37. Two companion binaries were deployed with deliberate timestamp manipulation: pe.exe at C:\WINDOWS\system32\pe.exe and svchost.exe at C:\WINDOWS\system32\dllhost\svchost.exe both had their LastModified timestamps backdated to 2008-04-14 00:12:36, matching the Windows XP SP3 build date. This timestomping caused the attacker's binaries to blend visually with legitimate operating system files in directory listings.
Also on April 4, the SRL-Helpdesk local administrator account on the XP system experienced a password failure at 12:25:14 UTC, followed by a password reset at 12:41:33 UTC. This timing coincides with the attacker's operational window and may represent credential manipulation to facilitate subsequent RDP access.
Phase 3 — Lateral Movement and Credential Reuse (2012-04-04 15:15 to 16:37)
The afternoon of April 4 saw the definitive lateral movement phase. At 15:34:48 UTC, the vibranium domain account authenticated from the Snake-compromised nromanoff workstation (10.3.58.5) to the domain controller via Kerberos (Event ID 4624, LogonType 3, port 49896). The account received extensive administrative privileges including SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, and SeImpersonatePrivilege.
Within minutes of authentication, vibranium accessed sensitive data on the domain controller. At 15:42:01 UTC, the account opened "Credit-Card-Numbers-For-Research" (evidenced by a Recent folder LNK file). At 15:42:58 UTC, vibranium accessed "Agents-List-CLASSIFIED-TOP-SECRET" — the same classified agents directory whose contents (Undercover-Agents-List-For-United-Kingdom.xls, Undercover-Agents-List-For-Australia.xls) were also present on the nromanoff workstation with Zone.Identifier alternate data streams confirming internet download origin.
Sixty-three minutes later, at 16:37:53 UTC, the same vibranium account authenticated from the XP workstation (10.3.58.7) to the domain controller, again via Kerberos with full administrative privileges including SeDebugPrivilege. This cross-system credential reuse from two different user workstations — neither of which is a management station — constitutes the strongest evidence that the Snake malware on the nromanoff system and the C2 tools on the XP system were operated by the same threat actor. The vibranium account is not a local account on the XP system (confirmed by SAM registry enumeration), meaning the credential was harvested and transported between systems.
Active SMB connections confirmed the lateral movement pathway. Volatility netscan of the domain controller memory captured an ESTABLISHED TCP connection from 10.3.58.5:49805 (nromanoff) to 10.3.58.9:445 (controller SMB), owned by the System process (PID 4). Snake malware commonly uses SMB and named pipes for C2 relay and lateral movement.
Phase 4 — Sustained Command and Control (2012-04-05 to 2012-04-06)
On April 5, the threat actor established persistent C2 on the XP system. An initial spinlock.exe instance (PID 11640, PPID 12236) began execution at 17:16:01 UTC and ran continuously for over 25 hours until 18:58:17 UTC on April 6. The process exhibited a multi-layered execution chain: cmd.exe (PID 5872) spawned spinlock.exe (PID 12244) at 13:25:00 UTC on April 6, which spawned a child spinlock.exe (PID 3648) one second later at 13:25:01 UTC. This child then spawned cmd.exe (PID 7416) at 13:39:58 UTC, which executed pe.exe (PID 10384) from 13:43:20 to 13:59:57 UTC. A second cmd.exe (PID 9448) was spawned at 18:55:48 UTC. This parent-child pattern — C2 tool spawning command shells that execute subsidiary tools — is consistent with interactive remote access.
Also on April 5, the domain account "nromanoff" (SID: S-1-5-21-2036804247-3058324640-2116585241-1109) was created on the domain controller at approximately 07:44:28 UTC (Event ID 4720), with the subject LogonId 0x0 indicating system-level creation. The account subsequently authenticated via both Kerberos and NTLM from multiple addresses. This account creation, combined with its elevated RID (1109) and immediate network logon activity, is consistent with attacker-created persistence.
Phase 5 — Final Observed Activity (2012-04-06 19:06 to 19:07)
The final observed threat actor activity occurred on the evening of April 6. At 19:06:37 UTC, the SRL-Helpdesk local administrator account logged into the XP system (login count: 4), initiating an RDP session evidenced by rdpclip.exe (PID 2284) at 19:06:44 UTC and explorer.exe (PID 1900) at 19:06:47 UTC. Twenty-nine seconds after the RDP session began, at 19:07:16 UTC, svchost.exe (PID 3296) was spawned as a child of explorer.exe (PID 1900). All legitimate svchost.exe instances on this system have services.exe (PID 1044) as their parent. This anomalous svchost.exe likely originates from the masquerading path C:\WINDOWS\system32\dllhost\svchost.exe identified in ShimCache, representing the execution of an attacker binary through compromised helpdesk credentials.
Key Findings
Snake/Uroburos APT Malware (nromanoff workstation, 10.3.58.5)
YARA rule APT_MAL_RU_WIN_Snake_Malware_May23_1, from a reputable detection ruleset, matched the nromanoff workstation disk image at fourteen or more distinct offsets. Snake (also known as Uroburos or Turla) is a sophisticated malware framework with kernel-mode rootkit capabilities, encrypted virtual filesystems for data storage, and advanced C2 communication channels. The match quality is strong: the format strings %s#1 through %s#4 represent Snake's characteristic internal component naming convention, and the file extensions .tmp, .sav, and .upd correspond to Snake's kernel driver queue files and component storage formats. Multiple offset matches across different string patterns compound the statistical significance. No corroborating Snake-specific behavioral artifacts were identified through memory analysis, though this may reflect the rootkit's kernel-level stealth capabilities or the timing of capture relative to rootkit activation. Confidence in the Snake identification remains at "inference" due to reliance on a single detection engine.
Multi-Family Web Shell Deployment (Domain Controller)
Five distinct web shell families were detected in the domain controller's memory through YARA scanning: RemCom (remote command execution via named pipes), CmdAsp (ASP command shell), connectback2 (Perl reverse shell), sql_php from rst.void.ru (Russian PHP SQL shell), and cmdjsp (JSP command shell with matches at three separate memory offsets). The language diversity of these web shells precisely maps to the web server stack running on the controller — IIS serves ASP, Apache serves PHP and Perl, Tomcat serves JSP. A counter-analysis considered whether these matches could originate from McAfee ePO's in-memory antivirus signature database, as the AV management platform runs on the same server. This hypothesis was evaluated and found less probable: the matched strings are full plaintext content (author names, URLs, domain names) rather than binary signature patterns, and the language-to-server correspondence would be coincidental if sourced from AV definitions.
Command-and-Control Infrastructure (XP workstation, 10.3.58.7)
The XP system hosted a complete C2 toolkit consisting of spinlock.exe, pe.exe, and a masquerading svchost.exe in C:\WINDOWS\system32\dllhost. spinlock.exe is not a legitimate Windows binary. Its placement in system32, combined with its process behavior — spawning child instances and command shells in a layered execution chain — confirms its role as a remote access tool. The 25-hour continuous session (PID 11640) demonstrates persistent attacker access. The companion pe.exe served as a subsidiary execution tool launched from spinlock's command shells. Both pe.exe and the dllhost\svchost.exe binary were timestomped to 2008-04-14, the Windows XP SP3 build date, as a defense evasion technique.
Cross-System Credential Abuse (vibranium account)
The vibranium domain account (RID 1673) serves as the connective tissue linking the compromise across all three affected systems. The account authenticated from the nromanoff workstation to the domain controller at 15:34:48 UTC on April 4, and from the XP workstation to the same controller at 16:37:53 UTC — a 63-minute gap between authentications from two different end-user machines. This usage pattern is inconsistent with legitimate IT administration, which would typically originate from a dedicated management workstation. The vibranium account received full domain administrator privileges at each authentication, accessed classified and financial documents within minutes of its first authentication, and deployed PyInstaller-packaged offensive tools to the controller's filesystem. The cross-system credential reuse is the strongest evidence that the compromises on the nromanoff and XP systems were conducted by the same threat actor.
Classified Data Access and Potential Exfiltration Staging
The threat actor systematically targeted classified information. On the nromanoff workstation, the directory "Undercover Agent-List-Classified/Agents-List-CLASSIFIED-TOP-SECRET" contained files including Undercover-Agents-List-For-United-Kingdom.xls (113,152 bytes, created 2012-03-09) and Undercover-Agents-List-For-Australia.xls. Zone.Identifier alternate data streams on these files confirm they were downloaded from the internet. A Recent folder LNK file (2012-03-12 20:58:18) confirms user interaction. On the domain controller, the vibranium account accessed the same "Agents-List-CLASSIFIED-TOP-SECRET" directory (LNK created 2012-04-04 15:42:58) and additionally accessed "Credit-Card-Numbers-For-Research" (LNK created 2012-04-04 15:42:01). No direct evidence of outbound data transfer of these specific files was identified in available network artifacts; however, Snake's encrypted C2 channels would not be visible in standard network captures, and the XP system's Dropbox installation (ShimCache: 2012-02-14) could provide a legitimate-appearing exfiltration channel.
Defense Evasion Techniques
The threat actor employed consistent defense evasion techniques across multiple systems. On the XP system, pe.exe and dllhost\svchost.exe were timestomped to match the OS build date, while spinlock.exe was placed in system32 to masquerade as a system binary. The svchost.exe placement inside a fabricated "dllhost" subdirectory used two real Windows process names to construct a plausible-looking but non-standard path. Process hiding was observed on both the domain controller (PID 56 svchost.exe absent from pslist but present in psscan) and the XP system (spinlock.exe PID 12244 visible only through psscan pool tag scanning). The consistency of these techniques across systems further supports single-operator attribution.
Independent External Threat: SMTP Brute-Force (91.207.6.58)
An independent, opportunistic SMTP brute-force attack was identified from 91.207.6.58 (geolocated to Russia, Sakha Republic, ASN AS43634) against the domain controller's hMailServer. This attack was determined to be unrelated to the internal APT campaign based on multiple factors: the SMTP brute-force used automated credential cycling at 4-5 second intervals, a fundamentally different TTP from the APT actor's precise credential usage; the IP address does not appear in any internal system artifact; and the APT actor already possessed valid domain credentials, making email brute-forcing unnecessary and counterproductive. All observed authentication attempts returned "535 Authentication failed." While independent, this attack confirms the controller's internet exposure and validates the excessive attack surface finding.
Negative Finding: nfury System (10.3.58.6) Clean
Comprehensive analysis of the nfury workstation revealed no indicators of compromise. All 37 running processes were legitimate, no YARA matches were detected on memory or disk, no suspicious network connections were observed, no hidden processes were found, and no anomalous files were identified. The system's console was at the login screen with no interactive user session at the time of capture. The absence of compromise on nfury — positioned on the same network segment as two heavily compromised systems — supports the assessment that the intrusion was targeted rather than opportunistic.
Threat Intelligence and Attribution
The evidence supports attribution to the Snake/Uroburos malware ecosystem, which has been historically associated with Russian state-sponsored cyber operations. The YARA detection on the nromanoff workstation matched a rule specifically designed for the Snake malware family, with fourteen or more distinct offset matches across characteristic format strings and file extensions. The Russian-language web resource rst.void.ru, found in one of the PHP web shells on the domain controller, provides a corroborating — though not independently conclusive — indicator of Russian-language tooling.
Attribution to a specific threat group requires caution. The YARA match confirms the presence of the Snake malware family but does not, by itself, identify the operating unit. Snake tooling has been associated with the Turla group (also known as Venomous Bear, Waterbug, or Group 88), which multiple government agencies have linked to Russia's Federal Security Service (FSB). The behavioral TTPs observed in this investigation — multi-system lateral movement using harvested credentials, deployment of web shells across multiple web server platforms, use of timestomping and process masquerading for defense evasion, targeting of classified intelligence documents (undercover agent lists), and sustained multi-day C2 operations — are consistent with the operational patterns historically attributed to state-sponsored espionage actors rather than financially motivated cybercriminals or hacktivists.
The targeting profile further supports an espionage-motivated threat actor. The accessed documents — classified undercover agent lists for specific countries and financial research data — represent intelligence of value to a nation-state adversary. The methodical progression from initial access through credential harvesting, lateral movement, and data access reflects a deliberate intelligence collection operation rather than opportunistic exploitation.
However, independent corroboration from network infrastructure analysis, command-and-control domain registration records, or malware sample comparison with known Turla campaigns was not possible within the scope of this forensic investigation. The attribution assessment is therefore stated as: the observed activity is consistent with, and overlaps with, known TTPs of the Turla/Snake threat group, but definitive attribution to a specific state entity cannot be established solely from the available forensic evidence.
Impact Assessment
The investigation confirmed compromise of three of four examined systems within the SHIELDBASE domain, with the domain controller itself among the compromised hosts. The scope and severity of this incident are assessed as critical.
The domain controller compromise is particularly severe. As the Active Directory server, it holds the ntds.dit database containing all domain password hashes, Kerberos ticket-granting keys, and domain trust relationships. The threat actor demonstrated domain administrator-level access through the vibranium account, with full privileges including SeDebugPrivilege (enabling credential extraction from process memory). The web shell deployment across IIS, Apache, and Tomcat provides multiple independent persistence mechanisms on this critical server.
Credential exposure is extensive. The vibranium domain account with full administrative privileges was used across multiple systems, and the threat actor demonstrated the ability to create new domain accounts (nromanoff, SID-1109). The SRL-Helpdesk local administrator account on the XP system showed signs of credential manipulation (password failure followed by reset during the operational window). The domain administrator account rsydow authenticated from FALCONIII (10.3.16.5) with full privileges, though this activity appeared consistent with legitimate administration. All domain credentials should be considered potentially compromised given the domain controller's confirmed compromise.
Classified data was confirmed accessed. The threat actor opened "Agents-List-CLASSIFIED-TOP-SECRET" (undercover agent lists for the United Kingdom and Australia) and "Credit-Card-Numbers-For-Research" from the domain controller using the vibranium account. The same classified documents were present on the Snake-compromised nromanoff workstation. While direct evidence of completed exfiltration was not identified in available artifacts, the combination of Snake's encrypted C2 capabilities, the 25-hour spinlock.exe C2 session, and the availability of Dropbox on the XP system all represent viable exfiltration channels whose traffic would not necessarily be captured by the available forensic evidence.
Anti-forensic tool availability further complicates the damage assessment. SysInternals SDelete was present on the domain controller alongside the broader SysInternals toolkit (deployed 2009-12-05), and 11,973 deleted files were identified across the controller's disk image. While SDelete was likely deployed for legitimate administration, its availability to an attacker with shell access means some evidence may have been irrecoverably destroyed.
Forensic visibility gaps exist. The nfury system's Security.evtx was only 8 KB (active log), limiting local event analysis. YARA scanning was not performed on the XP system's memory dump or disk image, leaving a potential gap in malware identification. The nromanoff workstation's memory dump did not reveal Snake-specific rootkit behavior through standard Volatility plugins, consistent with kernel-level stealth but preventing definitive process-level attribution.
Immediate Tactical Containment
The following actions should be executed immediately to halt active threat actor access:
-
Isolate compromised systems from the network: Disconnect the domain controller (10.3.58.4/10.3.58.9), nromanoff workstation (10.3.58.5), and XP workstation (10.3.58.7) from all network connectivity. Do not power off — preserve volatile evidence.
-
Block external attacker IPs at the perimeter firewall: Block inbound and outbound traffic to 91.207.6.58 (SMTP brute-force source), 188.138.11.56 (web shell download attempt), 132.248.31.82 (web admin scanning), 86.105.68.176, 188.255.86.142 (external SMTP sources), and 96.255.98.154 (suspicious high-port connection on port 29932). Investigate 96.255.98.154 for legitimate remote administration before permanent blocking.
-
Disable compromised domain accounts: Immediately disable the vibranium account (SID: S-1-5-21-2036804247-3058324640-2116585241-1673) and the nromanoff account (SID: S-1-5-21-2036804247-3058324640-2116585241-1109) in Active Directory. Reset the password for the SRL-Helpdesk local account (RID 1004) on the XP system.
-
Terminate malicious processes on the XP system (10.3.58.7): Kill spinlock.exe processes (PIDs 12244, 3648, 11640), pe.exe (PID 10384), the anomalous svchost.exe (PID 3296 — spawned by explorer.exe, not services.exe), and associated cmd.exe processes (PIDs 5872, 7416, 9448).
-
Block attacker binary hashes at endpoint protection: Add the following file paths to blocklists: C:\WINDOWS\system32\spinlock.exe, C:\WINDOWS\system32\pe.exe, C:\WINDOWS\system32\dllhost\svchost.exe. Extract SHA-256 hashes from the disk image for hash-based blocking across the enterprise.
-
Disable internet-facing services on the domain controller: Immediately stop IIS (w3wp.exe, inetinfo.exe), Apache (Apache.exe), Tomcat (tomcat5.exe), hMailServer (hMailServer.exe), Telnet (tlntsvr.exe), FTP (ftpsvc), and SNMP (snmp.exe) services. These services provide the threat actor with web shell access and re-entry vectors.
-
Initiate domain-wide credential reset: Reset the KRBTGT account password twice (with 12-hour interval) to invalidate all Kerberos tickets. Force password resets for all domain accounts, prioritizing accounts with administrative privileges (rsydow, vibranium, nromanoff, Administrator).
Strategic Remediation
The domain controller's dual role as both the AD authority and a public-facing web/email/FTP server (Finding f_63f7df4c) was the foundational architectural failure that enabled this intrusion. The threat actor exploited internet-facing IIS, Apache, and Tomcat services to deploy five web shell families directly onto the server holding all domain credentials. Remediating this requires migrating all internet-facing services — web hosting, email (hMailServer), FTP, Telnet, and McAfee ePO — to dedicated, non-domain-controller servers in a DMZ network segment with strict firewall rules permitting only necessary traffic flows. Telnet should be decommissioned entirely and replaced with SSH or RDP with network-level authentication.
The organization's credential management practices failed to prevent lateral movement via the vibranium account (Finding f_03b04202). A single domain account with full administrative privileges was used to authenticate from two separate user workstations (10.3.58.5 and 10.3.58.7) to the domain controller within a 63-minute window, accessing classified data with no apparent alerting or access control challenge. Implementing privileged access workstations (PAWs) for domain administration — restricting domain admin credentials to designated hardened systems — would have prevented the use of harvested credentials from compromised endpoints. Additionally, implementing tiered administration with separate accounts for workstation, server, and domain administration would limit the blast radius of credential compromise on any single tier.
The absence of application whitelisting on the XP workstation (Finding f_1bed34fc) allowed the threat actor to deploy and execute spinlock.exe, pe.exe, and a masquerading svchost.exe from C:\WINDOWS\system32\dllhost. These non-standard binaries executed without restriction from the system32 directory. Deploying application control policies (e.g., AppLocker or Software Restriction Policies) that enforce execution only from approved paths and with verified publisher signatures would have blocked execution of the unsigned attacker binaries, regardless of their filesystem location.
The SRL-Helpdesk local administrator account on the XP system (Finding f_ab4be984) had its password reset during the incident window (2012-04-04 12:41:33) and was subsequently used for RDP access that launched a masquerading svchost.exe within 29 seconds. The account's login count of only 4 and its local administrator membership with no evident multi-factor authentication enabled the attacker to establish interactive access using potentially compromised credentials. Enforcing multi-factor authentication for all remote access (RDP, VPN) and implementing account lockout policies after failed authentication attempts would have disrupted this access vector.
The threat actor's timestomping of pe.exe and dllhost\svchost.exe to the XP SP3 build date (2008-04-14) went undetected (Finding f_58e61000), indicating the absence of file integrity monitoring on critical system directories. Deploying file integrity monitoring on system32 and other sensitive directories with alerts on new binary creation or timestamp anomalies (where $STANDARD_INFORMATION timestamps deviate significantly from $FILE_NAME timestamps) would have provided early detection of the tool deployment phase before the C2 infrastructure became operational.
The presence of SDelete on the domain controller (Finding f_5fbcd843), combined with 11,973 deleted files and confirmed attacker access via web shells and the vibranium account, created conditions where forensic evidence may have been irrecoverably destroyed. While SDelete was deployed as part of a legitimate SysInternals toolkit, its availability on a server with confirmed compromise impaired evidence recovery. Restricting availability of secure-deletion and other dual-use tools on critical servers — or monitoring their execution through command-line logging and SIEM alerting — would preserve forensic evidence integrity in the event of compromise.
Conclusion
Q1. What systems were compromised? Three of four examined systems were confirmed compromised: the domain controller (Controller.shieldbase.local, 10.3.58.4/10.3.58.9) hosted five web shell families and was accessed by the attacker via the vibranium account with full administrative privileges; the nromanoff workstation (10.3.58.5) contained Snake/Uroburos APT malware confirmed by YARA at fourteen or more distinct disk offsets; and the XP workstation (WKS-WINXP32BIT, 10.3.58.7) hosted a complete C2 toolkit (spinlock.exe, pe.exe, masquerading svchost.exe) with active 25-hour sessions. The nfury workstation (10.3.58.6) showed no indicators of compromise across all forensic analysis methods applied.
Q2. How did the attacker gain initial access? The precise initial access vector could not be definitively determined. Two probable vectors were identified: exploitation of the domain controller's internet-facing web services (IIS, Apache, Tomcat) leading to web shell deployment (T1190), and the Snake/Uroburos malware on the nromanoff workstation whose delivery mechanism predates the available evidence window. The web shell deployment across multiple server platforms on the domain controller represents the earliest confirmed access to the infrastructure that houses domain credentials.
Q3. What lateral movement occurred? Extensive lateral movement was confirmed. The vibranium domain account authenticated from the nromanoff workstation (10.3.58.5) to the domain controller at 15:34:48 UTC on April 4, and from the XP workstation (10.3.58.7) to the domain controller at 16:37:53 UTC — using harvested credentials across two different endpoints within 63 minutes (T1021.002, T1078.002). An active SMB connection from the Snake-compromised nromanoff workstation to the controller (port 445) was captured in memory. The nromanoff account was created on the domain controller and authenticated via both Kerberos and NTLM. RDP access to the XP system via the SRL-Helpdesk account provided interactive access (T1021.001).
Q4. What persistence mechanisms were installed? Multiple persistence mechanisms were identified: five web shell families on the domain controller providing HTTP-based access across IIS, Apache, and Tomcat (T1505.003); the Snake/Uroburos rootkit on the nromanoff workstation with kernel-level persistence capabilities (T1547.006, T1014); spinlock.exe C2 tool in the XP system's system32 directory (T1036.005); and the nromanoff domain account created for sustained access (T1136.002). The web shells provide persistence that survives system restarts, while Snake's kernel rootkit provides stealth persistence at the operating system level.
Q5. Was data exfiltrated, and if so, what and how much? Classified data was confirmed accessed but completed exfiltration could not be definitively proven. The vibranium account accessed "Agents-List-CLASSIFIED-TOP-SECRET" (undercover agent lists for the United Kingdom and Australia) and "Credit-Card-Numbers-For-Research" on the domain controller on April 4 at 15:42 UTC. The same classified documents were present on the Snake-compromised nromanoff workstation. Multiple exfiltration channels were available: Snake's encrypted C2 communications, the 25-hour spinlock.exe session, and Dropbox on the XP system. The absence of direct exfiltration evidence in available artifacts does not preclude its occurrence, as Snake's encrypted C2 would not be captured in standard network artifacts and SDelete on the domain controller could have destroyed staging evidence.
Q6. What is the full timeline of the incident? The incident spans from pre-March 2012 (Snake deployment and web shell installation) through April 6, 2012 19:07 UTC (final observed activity). The primary operational phase occurred April 3-6, 2012: tool deployment under vibranium on April 3-4, credential-based lateral movement on April 4, classified data access on April 4, C2 establishment on the XP system on April 4-5, sustained 25-hour C2 sessions on April 5-6, and a final RDP-based access on April 6.
Q7. What is the total scope and business impact? The scope encompasses three compromised systems, full domain administrator access, confirmed access to classified intelligence material (undercover agent identities for two nations), and access to financial data (credit card numbers). The domain controller compromise means all domain credentials should be considered exposed. The business impact is critical: if undercover agent lists were exfiltrated, the consequences extend beyond the organization to national security implications for the affected countries. The Snake/Uroburos malware's presence indicates a sophisticated, persistent threat that may have maintained access for an extended period prior to detection.
Q8. What are the recommended remediation actions? Six specific remediation actions are recommended, each tied to a root cause identified in this investigation: (1) migrate all internet-facing services off the domain controller to dedicated DMZ servers, eliminating the critical attack surface that enabled web shell deployment; (2) implement tiered administration with privileged access workstations to prevent credential reuse across security boundaries; (3) deploy application whitelisting on all endpoints to block execution of unauthorized binaries; (4) enforce multi-factor authentication for all remote access methods; (5) implement file integrity monitoring on system directories to detect timestomping and unauthorized binary deployment; and (6) restrict dual-use tools and implement command-line logging on critical servers to preserve forensic evidence. Additionally, a complete domain rebuild should be considered given the depth of compromise, including fresh AD deployment with new KRBTGT keys, new trust relationships, and reimaged systems from known-clean media.
Attack Timeline
Findings
YARA rule APT_MAL_RU_WIN_Snake_Malware_May23_1 matched the nromanoff workstation disk image (win7-32-nromanoff-c-drive.E01) at multiple offsets. Snake (also known as Uroburos or Turla) is a sophisticated malware framework attributed to Russian state-sponsored threat actors (FSB/Turla Group).
Matched strings and offsets:
- $a (%s#1): 0x40185acb, 0x19bde4af4
- $b (%s#2): 0xcf4d7eb5, 0x21f3dd4f4, 0x23858697b
- $c (%s#3): 0x9fe213c0, 0xbc2aec88
- $d (%s#4): 0x1cf5077ee
- $e (.tmp): 0x1318dbe09
- $g (.sav): 0x7cce4d5f, 0xbe8db769, 0xe393815d, 0x1f2a86bf5
- $h (.upd): 0x243b5ba3, 0xe1b3df6f, 0x23ba42cdd
YARA Match Quality Assessment (Q8): The match quality is strong and inconsistent with a single false positive. The format strings %s#1 through %s#4 are Snake's characteristic internal component naming convention — a sequentially numbered pattern unlikely to appear in unrelated software. The file extensions .tmp, .sav, and .upd are Snake's kernel driver queue files and component storage formats. Critically, matches occur at 14+ distinct disk offsets spanning a wide range (0x243b5ba3 to 0x23ba42cdd), suggesting multiple copies or components consistent with Snake's modular architecture (kernel rootkit, usermode component, encrypted virtual filesystem). Multiple offset matches across different string patterns compound the statistical significance — each independent match reduces false positive probability.
However, confidence remains "inference" because: (1) this is a single YARA rule from one detection engine, and (2) no corroborating Snake-specific behavioral artifacts (e.g., Snake kernel driver, encrypted VFS containers) were identified through memory analysis of this system. The nromanoff system was a 32-bit Windows 7 machine whose memory dump was analyzed with Volatility but did not reveal Snake-specific rootkit behavior — possibly because Snake's rootkit operates at kernel level and may not be visible through standard Volatility plugins, or because the rootkit was not active at time of capture.
Snake malware typically deploys a kernel-mode rootkit for stealth, uses encrypted virtual filesystems for data storage, and implements sophisticated C2 communication channels. The presence on the nromanoff workstation (10.3.58.5) combined with the active SMB connection from this host to the domain controller supports possible lateral movement or command relay through the compromised workstation.
Evidence Chain
The domain account 'vibranium' (SID: S-1-5-21-2036804247-3058324640-2116585241-1673) was used to authenticate to the domain controller (10.3.58.4) from TWO different compromised workstations on the same day, establishing a definitive link between the intrusions on the nromanoff system and the XP system:
From nromanoff workstation (10.3.58.5) — Snake/Uroburos compromised:
- 2012-04-04 15:34:48 UTC — Event ID 4624, LogonType 3, Kerberos authentication from IpAddress 10.3.58.5 port 49896
- vibranium received full administrative privileges (SeDebugPrivilege, SeBackupPrivilege, etc.)
From XP workstation (10.3.58.7) — spinlock.exe/pe.exe compromised:
- 2012-04-04 16:37:53 UTC — Event ID 4624, LogonType 3, Kerberos authentication from IpAddress 10.3.58.7
- vibranium again received full administrative privileges including SeDebugPrivilege
Counter-analysis note (Q2/Q6 challenges): The hypothesis that vibranium is a legitimate shared IT administration account was evaluated. The 63-minute gap between authentications from two DIFFERENT user workstations (nromanoff's machine at 15:34 and tdungan's XP machine at 16:37) is the strongest evidence against this hypothesis. Even if vibranium were a legitimate shared admin account: (1) it would typically authenticate from a management workstation, not from end-user machines belonging to different people; (2) vibranium is NOT a local account on the XP system (confirmed by SAM registry — only Administrator, Guest, HelpAssistant, SUPPORT_388945a0, and SRL-Helpdesk exist locally); (3) the same vibranium account accessed classified documents ("Agents-List-CLASSIFIED-TOP-SECRET") and financial data ("Credit-Card-Numbers-For-Research") on the DC within minutes of the nromanoff authentication; (4) vibranium's RID (1673) is high, suggesting it was not among the original domain accounts.
This cross-system credential reuse is the strongest evidence that the Snake malware on nromanoff and the C2 tools on the XP system are operated by the SAME threat actor, not independent intrusions.
Evidence Chain
Cross-system correlation establishes a coherent attack kill chain spanning three systems operated by a single threat actor, likely Russian state-sponsored (Turla/FSB):
PHASE 1 — Initial Access and Persistence (pre-March 2012):
- Snake/Uroburos APT malware deployed on nromanoff workstation (10.3.58.5) — YARA-confirmed at 7+ disk offsets with Snake-specific format strings (%s#1 through %s#4) and characteristic extensions (.sav, .upd, .tmp) (T1014, T1547.006)
- Domain controller (10.3.58.4) exposed internet-facing services (IIS, Apache, Tomcat, hMailServer, Telnet) creating multiple attack vectors (T1190)
- Five web shell families (CmdAsp, cmdjsp, connectback2, sql_php from rst.void.ru, RemCom) detected in DC memory — language diversity matches the web server stack (T1505.003)
PHASE 2 — Credential Harvesting and Tool Deployment (2012-04-03 to 2012-04-04):
- PyInstaller-packaged Python 2.5 tools deployed under vibranium account on DC: _MEI138842 (23:09), _MEI57722 (00:01), _MEI111242 (00:06) — McAfee ePO hypothesis dismissed (user-context temp path, wrong Python framework) (T1059.006)
- spinlock.exe C2 tool deployed to C:\WINDOWS\system32\spinlock.exe on XP system (10.3.58.7) with pe.exe as secondary tool — timestomped to 2008-04-14 to blend with XP system files (T1036.005)
- Masquerading svchost.exe placed in C:\WINDOWS\system32\dllhost\ on XP — also timestomped to XP SP3 build date (T1036.004)
PHASE 3 — Lateral Movement via Shared Credentials (2012-04-04):
- vibranium account authenticates from nromanoff (10.3.58.5) to DC at 15:34:48 UTC
- vibranium account authenticates from XP (10.3.58.7) to DC at 16:37:53 UTC — SAME domain credentials from TWO different user workstations (not management stations) confirms single operator (63-minute gap, Q6)
- Active SMB connection from nromanoff to DC (10.3.58.9:445) at time of memory capture (T1021.002)
- vibranium not a local account on XP system (SAM confirmed) — credential must have been harvested and transported
PHASE 4 — Data Access (2012-04-04 15:42):
- vibranium accessed "Credit-Card-Numbers-For-Research" at 15:42:01 UTC
- vibranium accessed "Agents-List-CLASSIFIED-TOP-SECRET" at 15:42:58 UTC
- Same classified agents list present on Snake-compromised nromanoff workstation (Zone.Identifier ADS confirms internet download)
PHASE 5 — Sustained C2 and Persistence (2012-04-05 to 2012-04-06):
- spinlock.exe on XP ran 25+ hour session (PID 11640: 2012-04-05 17:16 to 2012-04-06 18:58)
- Multi-layer process chain: cmd to spinlock to spinlock to cmd to pe.exe providing interactive shell access
- Anomalous svchost.exe (PID 3296) spawned by explorer.exe 29 seconds after RDP login on XP
CONVERGENT EVIDENCE ASSESSMENT (Q7): Seven independent evidence sources (YARA signatures, event logs, memory forensics, MFT timestamps, ShimCache, registry, and file system listings) from three systems (nromanoff, DC, XP) converge on a single coordinated intrusion. To dismiss this chain would require simultaneously explaining: (1) Snake YARA as false positive at 7+ offsets, (2) web shell matches as AV signatures coincidentally matching the DC's web stack, (3) vibranium as a legitimate account coincidentally authenticating from two different compromised machines, (4) PyInstaller tools as legitimate despite user-context deployment, (5) timestomping to OS build dates as coincidental, (6) spinlock.exe/pe.exe as legitimate despite process chain behavior, and (7) classified data access as authorized. The combined dismissal is far less plausible than the coherent APT narrative. The nfury system (10.3.58.6) showing zero compromise indicators alongside two heavily compromised adjacent systems supports targeted rather than opportunistic compromise (Q12).
F-Response artifact review (Q11): F-Response forensic acquisition processes (f-response-ent, f-response-lm-monitor) and their network connections (iSCSI to 10.3.16.5, connection to 10.3.58.4:5681) were verified as forensic collection artifacts. No F-Response activity was misattributed as attack indicators in any finding.
Attribution: Snake/Turla attribution rests on the YARA rule match (APT_MAL_RU_WIN_Snake_Malware_May23_1) with Snake-specific internal format strings. While this is a strong indicator from a reputable rule, attribution to a specific state actor should be qualified — the YARA match confirms the Snake malware FAMILY but not necessarily the operating unit. The rst.void.ru Russian-language web shell is a corroborating but not independent attribution indicator.
Evidence Chain
Cross-system correlation reveals the same classified documents were accessed from multiple compromised systems, indicating systematic data targeting:
nromanoff Workstation (10.3.58.5) — Snake/Uroburos compromised:
- Users/nromanoff/Documents/Undercover Agent-List-Classified/Agents-List-CLASSIFIED-TOP-SECRET/Undercover-Agents-List-For-United-Kingdom.xls (113,152 bytes, created 2012-03-09, modified 2012-03-12)
- Undercover-Agents-List-For-Australia.xls (Zone.Identifier ADS confirms internet download, 2012-03-09)
- LNK file in Recent folder (2012-03-12 20:58:18) confirms user opened the files
Domain Controller (10.3.58.4) — via vibranium account:
- Users/vibranium/AppData/Roaming/Microsoft/Windows/Recent/Agents-List-CLASSIFIED-TOP-SECRET.lnk (2012-04-04 15:42:58) — the SAME classified agents list directory
- Users/vibranium/AppData/Roaming/Microsoft/Office/Recent/Credit-Card-Numbers-For-Research.LNK (2012-04-04 15:42:01) — additional PII data access
XP System (10.3.58.7) — spinlock.exe compromised:
- Dropbox installed (C:\Documents and Settings\tdungan\Application Data\Dropbox\bin\Dropbox.exe, ShimCache 2012-02-14) — potential cloud exfiltration vector on the same network
- Active C2 (spinlock.exe) with 25-hour session providing data transfer capability
Exfiltration Assessment:
- The classified documents on nromanoff existed on a system with Snake malware, which has built-in encrypted C2 communication channels capable of data exfiltration
- The vibranium account accessed the same documents on the DC, suggesting data was located/staged across network shares
- No direct evidence of outbound data transfer of these specific files was found in available network artifacts, but Snake's encrypted C2 would not be visible in standard network captures
- The Dropbox client on the XP system could provide a legitimate-appearing exfiltration channel
The cross-system access pattern (same classified files accessed from Snake-compromised nromanoff AND from the DC via stolen vibranium credentials) strongly suggests targeted intelligence collection rather than random file access.
Affected Systems: evtx.windows_system32_winevt_logs_security, ez.mft, ez.shimcache, tsk.filelist
Evidence Chain
YARA scanning of the domain controller memory dump identified signatures for five distinct web shell and remote access tools deployed across the multiple web server platforms (IIS, Apache, Tomcat):
- RemCom_RemoteCommandExecution (offset 0x88d88b6) — matched named pipe pattern
\\\\.\\pipe\\%s%s%dcharacteristic of RemCom, an open-source PsExec alternative for remote command execution. - CmdAsp_asp (offset 0x290db360) — matched "CmdAsp.asp" by maceo @ dogmile.com, a well-known ASP command shell.
- connectback2_pl (offset 0x27203372) — matched "ConnectBack Backdoor", a Perl-based reverse shell.
- sql_php_php (offset 0x294e7b6a) — matched "http://rst.void.ru", a Russian PHP SQL query shell.
- cmdjsp_jsp (offsets 0x29064742, 0x28ddc270, 0x290647b8) — matched "cmdjsp.jsp" JSP command shell.
Counter-analysis note (Q1 challenge): McAfee ePO with Apache/Tomcat runs on this domain controller, and AV signature databases contain patterns for known web shells. The YARA matches could theoretically originate from McAfee's in-memory signature store rather than from actual deployed web shells. However, the deployed web shell interpretation is favored for three reasons: (1) the web shell languages (ASP, PHP, Perl, JSP) exactly correspond to the web server stack running on the DC (IIS serves ASP, Apache serves PHP/Perl, Tomcat serves JSP) — a coincidence unlikely if these were merely AV signatures; (2) the matched strings are full plaintext content (author names, URLs like rst.void.ru, domain names like michaeldaw.org), not binary signature patterns; (3) the DC is confirmed internet-exposed with active web exploitation attempts from external IPs. Without process-level YARA (vadyarascan), definitive attribution to a specific process is not possible. Confidence remains "inference" to reflect this ambiguity.
The Russian-language web resource (rst.void.ru) in the PHP shell is consistent with the Snake/Turla attribution identified on the nromanoff workstation.
Evidence Chain
The Windows 2008 R2 domain controller (Controller.shieldbase.local, 10.3.58.4/10.3.58.9) is running numerous internet-facing services that significantly expand its attack surface:
Internet-Accessible Services (confirmed by process list and network connections):
- IIS Web Server (w3wp.exe, inetinfo.exe) — ports 80 and 443, receiving connections from internet crawlers (Googlebot, Baiduspider, Yandex) and external IPs
- hMailServer (hMailServer.exe) — SMTP/POP3 email server, actively receiving connections from external IPs including brute-force attacks
- McAfee ePO (Apache.exe, tomcat5.exe) — web management console on HTTP/HTTPS
- Telnet Server (tlntsvr.exe) — insecure cleartext remote access service
- DNS Server (dns.exe) — externally resolvable
- Microsoft SQL Server (sqlservr.exe, instance EPOSERVER) — database server for McAfee ePO
- FTP Server (svchost.exe -k ftpsvc) — FTP service
- SNMP (snmp.exe) — network management protocol
Search engine crawling evidence confirms internet exposure:
- Google (66.249.x.x), Baidu (180.76.x.x, 220.181.x.x), Yandex (95.108.x.x), Facebook (69.171.x.x) all crawled the web server
- External IPs accessing web content on port 80
Running these services on a domain controller violates security best practices. A domain controller holds the AD database (ntds.dit), Kerberos keys, and all domain credentials. Any vulnerability in these internet-facing services provides a direct path to full domain compromise.
Evidence Chain
Volatility netscan of the domain controller memory reveals an ESTABLISHED SMB (TCP port 445) connection from the nromanoff workstation (10.3.58.5:49805) to the controller (10.3.58.9:445), owned by the System process (PID 4). The controller's address 10.3.58.9 appears to be a secondary interface on the controller server (primary: 10.3.58.4).
This active SMB session is significant because:
1. The nromanoff workstation is confirmed compromised with Snake/Uroburos APT malware (YARA detection on disk)
2. Snake malware commonly uses SMB/named pipes for lateral movement and C2 relay
3. The nromanoff user account is confirmed authenticating to the controller via Kerberos (Event ID 4624, LogonType 3) and also via NTLM (LogonProcessName: NtLmSsp, WorkstationName: CONTROLLER) - the NTLM authentication from a workstation named "CONTROLLER" is unusual
4. Security event logs show successful logon from nromanoff with LogonType 3 (network) at 2012-04-05 07:44:28
The SMB connection could facilitate file access, credential relay, or lateral movement from the compromised workstation to the domain controller.
Evidence Chain
Security event logs from the domain controller show authentication activity from the nromanoff workstation (10.3.58.5) to the controller using multiple user accounts:
- nromanoff account (SID: S-1-5-21-2036804247-3058324640-2116585241-1109):
- Event ID 4624, LogonType 3 (network), via Kerberos at 2012-04-05 07:44:28
-
Also authenticated via NTLM (LogonProcessName: NtLmSsp) with WorkstationName: CONTROLLER - unusual for a network logon originating from the nromanoff workstation
-
vibranium account (SID: S-1-5-21-2036804247-3058324640-2116585241-1673):
- Authenticated from IpAddress 10.3.58.5 (nromanoff workstation) at 2012-04-04 15:34:48, LogonType 3
- vibranium user has files in AppData\Local\Temp_MEI111242 containing python25.dll on the controller, characteristic of PyInstaller-packaged tools
-
Also had RDP sessions and administrative logons with SeDebugPrivilege
-
Additional users authenticated from 10.3.58.7 (WKS-WINXP32BIT$):
- Machine account WKS-WINXP32BIT$ authenticated via Kerberos at 2012-04-05 07:44:28
The use of multiple domain accounts from the Snake-compromised nromanoff workstation suggests either legitimate multi-user activity or attacker use of harvested credentials for lateral movement.
Evidence Chain
Multiple PyInstaller-packaged executables were extracted and run under the vibranium user account (SID: S-1-5-21-2036804247-3058324640-2116585241-1673) on the domain controller between 2012-04-03 23:09 and 2012-04-04 00:06. PyInstaller bundles Python interpreters and scripts into standalone executables that auto-extract to temporary directories at runtime.
Evidence from MFT and file listing:
- Users/vibranium/AppData/Local/Temp/_MEI138842/ (created 2012-04-03 23:09:16): Contains _ctypes.pyd
- Users/vibranium/AppData/Local/Temp/_MEI57722/ (created 2012-04-04 00:01:44): Contains unicodedata.pyd
- Users/vibranium/AppData/Local/Temp/_MEI111242/ (created 2012-04-04 00:06:40): Contains python25.dll (2.1MB)
- Users/vibranium/AppData/Local/Temp/_MEI39242/: Contains python25.dll, kernel32.dll, MSVCR71.dll, bz2.pyd, spin...
All bundles use Python 2.5 runtime. PyInstaller is frequently used by attackers to package offensive Python tools (such as Impacket, credential dumpers, or custom C2 agents) into portable executables that don't require Python installation on the target.
Counter-analysis note (Q3 challenge): The hypothesis that these are McAfee ePO management components was evaluated and dismissed. McAfee ePO historically used Java/Jython for its management console, not CPython PyInstaller bundles. Critically, these files are extracted under the vibranium USER profile's AppData\Local\Temp directory — McAfee ePO service components would execute under the ePO service account, not a domain user's temp path. Python 2.5 was already outdated by 2012, making it an unlikely ePO dependency. The rapid sequential deployment of three distinct bundles within ~57 minutes is consistent with automated tool deployment rather than legitimate software operation.
Additionally, the vibranium user's Recent folder shows access to a file named "Agents-List-CLASSIFIED-TOP-SECRET.lnk" (MFT created: 2012-04-04 15:42:58), suggesting access to classified/sensitive documents from this account.
Evidence Chain
The Windows XP workstation (WKS-WINXP32BIT, 10.3.58.7, user tdungan) shows evidence of a multi-stage malicious execution chain involving spinlock.exe. ShimCache analysis places spinlock.exe at position 0 (most recently cached entry): C:\WINDOWS\system32\spinlock.exe with LastModified 2012-04-04 17:06:37. Memory forensics (psscan) reveals three spinlock.exe instances forming a parent-child execution chain:
- cmd.exe (PID 5872, PPID 1488) created 2012-04-06 13:25:00
- spinlock.exe (PID 12244, PPID 5872) created 2012-04-06 13:25:00
- spinlock.exe (PID 3648, PPID 12244) created 2012-04-06 13:25:01
- cmd.exe (PID 7416, PPID 3648) created 2012-04-06 13:39:58
- pe.exe (PID 10384, PPID 7416) created 2012-04-06 13:43:20 (exited 13:59:57)
- cmd.exe (PID 9448, PPID 3648) created 2012-04-06 18:55:48
An earlier spinlock.exe instance (PID 11640, PPID 12236) ran from 2012-04-05 17:16:01 to 2012-04-06 18:58:17, spanning over 25 hours. The pattern of spinlock.exe spawning child spinlock.exe processes, then spawning cmd.exe children that execute pe.exe, is consistent with a command-and-control tool providing interactive shell access. This binary is not a standard Windows executable and was placed in the system32 directory to blend in with legitimate system files.
Affected Systems: ez.shimcache, tsk.filelist, volatility.psscan
Evidence Chain
ShimCache analysis of the XP system's SYSTEM hive reveals a suspicious binary at position 49: C:\WINDOWS\system32\dllhost\svchost.exe (LastModified 2008-04-14 00:12:36). This is highly anomalous - svchost.exe should only exist at C:\WINDOWS\system32\svchost.exe. The placement inside a 'dllhost' subdirectory within system32 is a masquerading technique: both 'dllhost' and 'svchost' are legitimate Windows process names, making this path appear plausible on cursory inspection while actually being a non-standard location. The timestamp matches the XP SP3 build date (2008-04-14), indicating deliberate timestomping to blend in with legitimate system files. This binary was likely deployed alongside spinlock.exe (LastModified 2012-04-04 17:06:37) and pe.exe (also timestomped to 2008-04-14) as part of the coordinated toolset on the XP system. The anomalous svchost.exe (PID 3296) spawned by explorer.exe during the RDP session (finding f_fe53cf9f) may be this binary.
Evidence Chain
Memory forensics of the XP system reveals svchost.exe (PID 3296) with parent process explorer.exe (PID 1900, PPID 2436), created at 2012-04-06 19:07:16. This is an abnormal parent-child relationship: legitimate svchost.exe instances are spawned by services.exe (PID 1044 on this system). All other svchost.exe processes on this system correctly show PPID 1044 (services.exe): PIDs 1732, 1308, 1236, 1472, 1636, 1936. The anomalous svchost.exe (PID 3296) was created shortly after an RDP login session (rdpclip.exe PID 2284 at 19:06:44, explorer.exe PID 1900 at 19:06:47), suggesting it was executed by the user who connected via RDP. This may be the svchost.exe from the C:\WINDOWS\system32\dllhost\ directory identified in ShimCache, or another masquerading binary launched by the interactive user.
Evidence Chain
The threat actor employed consistent defense evasion techniques across multiple compromised systems, demonstrating operational sophistication:
Timestomping (T1070.006) — XP System (10.3.58.7):
- pe.exe at C:\WINDOWS\system32\pe.exe: LastModified set to 2008-04-14 00:12:36 (XP SP3 build date)
- svchost.exe at C:\WINDOWS\system32\dllhost\svchost.exe: LastModified also 2008-04-14 00:12:36
- Both attacker binaries had their timestamps backdated to match legitimate OS files, making them blend into the system32 directory. Only spinlock.exe retained a realistic timestamp (2012-04-04 17:06:37), possibly because it was replaced/updated more recently.
Binary Masquerading (T1036.005) — XP System:
- spinlock.exe placed in C:\WINDOWS\system32\ — not a real Windows component but the system32 path suggests legitimacy
- pe.exe placed in C:\WINDOWS\system32\ — generic name blends with system utilities
- svchost.exe placed in C:\WINDOWS\system32\dllhost\ — uses two real Windows process names (svchost + dllhost) in a fabricated path
Process Hiding (T1014) — Both DC and XP:
- DC: Hidden svchost.exe (PID 56) absent from pslist but present in psscan — potential DKOM rootkit technique. Created 2012-03-15, three weeks before main attack phase.
- XP: spinlock.exe (PID 12244) present in psscan but not pslist — the C2 tool itself appears unlinked from the process list
- XP: 6 additional hidden PIDs detected by composite defense evasion scan across both systems
Cross-System Pattern: The use of consistent evasion techniques (timestomping to OS build dates, masquerading as system processes, process hiding) across both the XP system and the domain controller indicates a single operator with a developed tradecraft toolkit, not opportunistic compromise.
Affected Systems: composite.defense_evasion, ez.shimcache, forensic.timestomping, volatility.psscan
Evidence Chain
Windows Security Event ID 4720 recorded the creation of a new domain account "nromanoff" in the SHIELDBASE domain on 2012-04-05 at approximately 07:44:28 UTC.
Account Details:
- Username: nromanoff
- Domain: SHIELDBASE
- SID: S-1-5-21-2036804247-3058324640-2116585241-1109
- Subject LogonId: 0x0 (system-level creation)
Post-Creation Activity:
- 257 matching events in the Security log showing nromanoff activity
- Network logons (Type 3) authenticated via Kerberos from both 10.3.58.4 (local) and 10.3.58.5
- The account was actively used for network resource access after creation
This account creation warrants investigation to determine whether it was authorized. The creation by a subject with LogonId 0x0 and subsequent Kerberos network logons from multiple internal addresses could indicate either legitimate provisioning or an attacker-created persistence account. Context from the organization's HR or IT onboarding records would be needed to confirm legitimacy.
Evidence Chain
Network analysis and bulk_extractor data reveal an established outbound TCP connection from the domain controller to an external IP on a high port:
Connection Details (from Volatility netscan):
- Source: 10.3.58.4:58497 (domain controller)
- Destination: 96.255.98.154:29932
- State: ESTABLISHED
- Protocol: TCPv4
Windows Firewall Log Confirmation (from bulk_extractor):
- "ALLOW TCP 10.3.58.4 96.255.98.154 52619 29932" — firewall permitted the connection
- Multiple firewall ALLOW entries for connections to this IP on port 29932
Context from Other Evidence:
- 96.255.98.154 also appears as an HTTP visitor to the IIS web server on port 80, with User-Agent "Mozilla/5.0+(Wi..." (Windows browser)
- The IP is associated with Yahoo email activity (sender: mhill.shield@yahoo.com) in carved data
- Port 29932 is non-standard and not associated with any common service
Assessment: The high port number (29932) is atypical for legitimate services. However, the same IP also shows legitimate web browsing activity and Yahoo email association, which could indicate this is a remote administrator's home IP using a legitimate remote management tool. The connection requires further investigation to determine if it represents authorized remote access or a command-and-control channel.
Evidence Chain
Bulk extractor carved web server logs reveal multiple external IP addresses performing web vulnerability scanning and exploitation attempts against the domain controller's IIS web server:
- Attempted download from suspicious domain: freetunel.com/cgi-bin.txt (from 188.138.11.56) - likely web shell or exploit download attempt
- Web admin panel scanning from 132.248.31.82: probing /webadmin/setup.php, /sqlweb/scr, and similar paths (all returning 404)
- Unauthorized WebDAV access attempts: multiple requests to /p_/webdav/ from various IPs
- Web crawlers from Baidu (180.76.5.x), Yandex (yandex.com/bots), and other search engines indexing the controller - confirming internet exposure
- External SMTP connections from multiple IPs besides the brute-forcing 91.207.6.58, including 86.105.68.176, 188.255.86.142, and others interacting with the hMailServer
The domain controller hosts the organizational email domain stark-research-labs.com with confirmed mailboxes for:
- nromanoff@stark-research-labs.com
- nfury@stark-research-labs.com
- tdungan@stark-research-labs.com
The controller is directly internet-accessible and receiving web traffic from search engine crawlers and external attackers, confirming its exposure as a public-facing server while serving as the Active Directory domain controller.
Evidence Chain
Memory forensics of the XP system shows an active RDP session at time of memory acquisition. Key evidence:
- rdpclip.exe (PID 2284, PPID 1000 winlogon.exe) created 2012-04-06 19:06:44 - RDP clipboard service indicating active remote desktop connection
- explorer.exe (PID 1900, PPID 2436) created 2012-04-06 19:06:47 - Interactive desktop shell for the RDP session
Local SAM registry analysis shows the SRL-Helpdesk local account (RID 1004) with:
- Account Type: Default Admin User (local administrator)
- Last Login: 2012-04-06 19:06:37Z (matching the RDP session start)
- Login Count: 4
- Password Reset: 2012-04-04 12:41:33Z
- Password Fail Date: 2012-04-04 12:25:14Z
The Remote Desktop Users group includes two domain SIDs (-1106, -1108). The SRL-Helpdesk account is a member of the local Administrators group. Notably, the anomalous svchost.exe (PID 3296) was spawned by this RDP session's explorer.exe (PID 1900) at 19:07:16, just 29 seconds after the RDP login.
Counter-analysis note (Q5 challenge): SRL-Helpdesk is explicitly named as an IT support account, and the RDP session could represent a legitimate helpdesk technician performing system diagnostics. However, the svchost.exe (PID 3296) spawned 29 seconds after login is abnormal — legitimate svchost.exe instances are spawned by services.exe, not by explorer.exe during an interactive session. This binary likely originates from the masquerading path C:\WINDOWS\system32\dllhost\svchost.exe identified in ShimCache. While the RDP session itself may be legitimate, the execution of the masquerading svchost.exe from it is consistent with an attacker using compromised helpdesk credentials to execute pre-staged tools.
Evidence Chain
The composite recovery assessment and ShimCache analysis confirm SysInternals SDelete (sdelete.exe) is present in C:\Tools\SysInternals\ on the domain controller (10.3.58.4), deployed alongside the broader SysInternals toolkit on 2009-12-05 22:16:53. SDelete performs secure deletion by overwriting file contents before deletion, making forensic recovery of deleted files impossible for overwritten data.
The recovery assessment identified 11,973 deleted files across the disk image and flagged SDelete as an anti-forensic concern: "Secure delete tools detected -- some deleted files may be unrecoverable." While SDelete was deployed as part of the full SysInternals toolkit (likely for legitimate administration), its availability on a domain controller with confirmed web shell compromise and attacker activity means an attacker with shell access could use it to:
1. Destroy evidence of accessed files (e.g., classified document copies)
2. Remove downloaded tools or exfiltrated archives after use
3. Clean up web shell files or other persistence mechanisms
This finding is assessed at medium severity because while the tool's presence is confirmed, there is no direct evidence of attacker-initiated use of SDelete. However, the combination of SDelete availability + 11,973 deleted files + active attacker presence creates a forensic integrity concern — some evidence may be irrecoverably destroyed.
Evidence Chain
Cross-system correlation analysis establishes that the sustained SMTP brute-force attack from 91.207.6.58 against the hMailServer is a separate, independent attack from the internal APT campaign:
Evidence of Independence:
1. The SMTP attack targets email authentication on the hMailServer — a distinct attack vector from the Snake/Uroburos malware deployment and web shell access used by the internal attacker
2. No IP address 91.207.6.58 appears in ANY internal system artifact: not in volatility netscan connections on any host, not in event log source IPs, not in the process tree or command lines
3. The brute-force uses automated credential cycling with rapid sequential attempts (every 4-5 seconds) — a fundamentally different TTP from the APT actor's precise credential usage (vibranium account with full admin privileges)
4. The APT actor already had valid domain credentials and web shell access — brute-forcing SMTP authentication would be unnecessary and counterproductive (increased detection risk)
5. 91.207.6.58 is geolocated to Russia (Sakha Republic, ASN AS43634) while the Snake/Uroburos deployment suggests a state-sponsored actor operating through compromised internal systems, not through direct internet-facing brute-force
Assessment: The SMTP attack represents an independent opportunistic threat exploiting the domain controller's exposed hMailServer. No evidence of successful authentication was found (all observed attempts returned "535 Authentication failed"). The primary risk remains the APT campaign which achieved full domain compromise through more sophisticated means.
Impact on Investigation: While these are independent threats, the SMTP attack confirms that the domain controller is internet-accessible and actively targeted by external adversaries, corroborating the excessive attack surface finding.
Affected Systems: bulk.domain, volatility.netscan
Evidence Chain
A comprehensive SysInternals toolkit has been deployed at C:\Tools\SysInternals\ on the domain controller. ShimCache (AppCompatCache) and registry entries confirm the presence of these tools:
High-Risk Tools Present:
- PsExec.exe — Remote execution tool, commonly abused for lateral movement (ShimCache timestamp: 2009-12-05 22:16:54)
- procdump.exe — Process memory dumping tool, commonly used for credential harvesting from lsass.exe (ShimCache timestamp: 2009-12-05 22:16:53)
- RootkitRevealer.exe — Rootkit detection tool (indicating security concerns existed)
Other SysInternals Tools in C:\Tools\SysInternals\:
- movefile.exe, ntfsinfo.exe, pendmoves.exe, portmon.exe, Cacheset.exe, Autologon.exe, ctrl2cap.exe, ProcFeatures.exe, and many more
ShimCache Evidence:
- ShimCache entries show timestamps of 2009-12-05 22:16:53-54 for most tools, indicating they were deployed on that date
- PsExec.exe has a separate MFT entry confirming file existence with creation time 2009-12-05
Risk Assessment:
While SysInternals tools are legitimate system administration utilities, PsExec and procdump are among the most commonly abused tools in post-exploitation scenarios:
- PsExec enables remote command execution across the domain (T1570)
- Procdump can dump lsass.exe process memory to extract plaintext credentials (T1003.001)
- Their presence on a domain controller provides an attacker with pre-staged tools for lateral movement and credential theft
Evidence Chain
Comparison of Volatility pslist (linked list traversal) against psscan (pool tag scanning) reveals three processes present in memory but not in the active process list:
1. PID 56 — svchost.exe (Ambiguous)
- Parent PID: Not listed (no parent entry visible)
- Created: 2012-03-15 03:09:18 UTC
- Threads: 10, Handles: 363
- Session: 0, WoW64: False
- This svchost.exe instance lacks a parent PID in the psscan output and is absent from pslist. The anomalously low PID (56) suggests early boot creation. Most likely explanation: a terminated service host process whose pool tag persists in memory. Less likely: a deliberately DKOM-unlinked process. Without additional indicators (unusual DLLs, network connections, or command line), the benign interpretation is favored.
2. PID 2400 — mfeann.exe (Benign)
- Parent PID: 1472 (VsTskMgr.exe — McAfee Task Manager)
- Created: 2012-03-15 03:10:59 UTC
- McAfee Announcement process — terminated and restarted during AV updates
3. PID 142048 — naPrdMgr.exe (Benign)
- Parent PID: 720
- Created: 2012-04-05 03:20:44 UTC
- McAfee NAI Product Manager — McAfee auto-update process
Counter-analysis note: PID 56 svchost.exe was evaluated with anti-evasion awareness. While the finding initially noted rootkit as a possibility (T1014), the evidence is more consistent with a normally terminated process. The 10 threads and 363 handles are within normal ranges for a legitimate svchost.exe. The PID 56 was created at system boot time (03:09:18, moments after the System process), which is consistent with a legitimate early-boot service host that was later terminated and replaced. No malfind hits, no unusual network connections, and no anomalous DLLs were found associated with this PID. Severity maintained at low; this is an isolated observation without corroborating indicators.
Evidence Chain
Nfury (WKS-WIN764BITB, 10.3.58.6) maintained active domain authentication with the controller (10.3.58.4) as a member of the SHIELDBASE domain. Evidence from the controller's Security event log shows:
-
ANONYMOUS LOGON: Event 4624, 2012-04-04 15:21:44, LogonType 3 from WKS-WIN764BITB (10.3.58.6), Target: NT AUTHORITY\ANONYMOUS LOGON. Null session access which enables network resource enumeration.
-
NTLM V1 Authentication: Event 4624, 2012-04-04 15:33:44, from 10.3.58.6 port 56659 using insecure NTLM V1 protocol (KeyLength 128).
-
Regular Kerberos Logons: Multiple successful Kerberos-based network logons (LogonType 3) throughout the monitoring period, indicating normal domain trust authentication.
-
No connections to nromanoff (10.3.58.5): Nfury's memory netscan shows zero active or closed connections to 10.3.58.5. There is no direct network relationship between nfury and the compromised nromanoff workstation at time of capture.
-
F-Response connection to controller: Nfury had an F-Response forensic agent connection to 10.3.58.4:5681 (CLOSED state) and an active iSCSI session to 10.3.16.5:48769, both related to the forensic acquisition process.
Cross-system risk assessment: While nfury itself shows no compromise indicators, its domain membership and NTLM V1 usage on the same network as the compromised nromanoff system means its credentials could theoretically be targeted via pass-the-hash or credential relay attacks. However, no evidence of such attacks against nfury was observed.
Affected Systems: evtx.windows_system32_winevt_logs_security, volatility.netscan
Evidence Chain
Windows Security event logs show the domain administrator account "rsydow" (SID: S-1-5-21-2036804247-3058324640-2116585241-1114) authenticating to the domain controller from the FALCONIII workstation (IP: 10.3.16.5) using Network Logon (Type 3).
Key Events:
- 2012-04-04 15:15:04 UTC — rsydow successful logon, Type 3, Kerberos auth
- 2012-04-04 19:59:48 UTC — rsydow successful logon from FALCONIII, Type 3
- 2012-04-05 14:04:41 UTC — rsydow successful logon from FALCONIII, Type 3
- 17 total FALCONIII events found in the Security log
Elevated Privileges Assigned:
SeSecurityPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, SeDebugPrivilege, SeSystemEnvironmentPrivilege, SeLoadDriverPrivilege, SeImpersonatePrivilege, SeEnableDelegationPrivilege
Assessment: The rsydow account has full domain administrator privileges. The logon pattern from FALCONIII shows regular administrative access. While this is likely legitimate administration, the privilege level warrants review to confirm all access was authorized. Any compromise of this account would grant complete domain control.
Evidence Chain
Comprehensive forensic analysis of win7-64-nfury (WKS-WIN764BITB, 10.3.58.6) reveals no indicators of compromise or malicious activity. This stands in contrast to the compromised nromanoff system where Snake/Uroburos malware was detected.
Process Analysis: All 37 running processes are legitimate Windows 7 system processes, McAfee AV suite (FireSvc, McSACore, FrameworkService, VsTskMgr, mfevtps, mcshield, mfeann, mfefire), VMwareService, and the F-Response forensic agent (PID 328). No interactive user session was active at time of capture (only LogonUI.exe present, no explorer.exe). The psscan-vs-pslist comparison shows no unlinked/hidden processes — the only difference is FireTray.exe PID 1352 which had exited normally.
Network Connections: Only legitimate connections found: SMB listener on port 139, F-Response iSCSI connection to 10.3.16.5:48769, F-Response connection to controller 10.3.58.4:5681, and McAfee management listeners on ports 8081/8082. No connections to external IPs, no connections to nromanoff (10.3.58.5), and no suspicious listening services.
Memory Injection (Malfind): All PAGE_EXECUTE_READWRITE regions belong to legitimate software — McAfee FrameworkService (PID 1472), mfevtps.exe (PID 1568), LogonUI.exe (PID 812, mostly null bytes), and F-Response (PID 328). No true code injection detected.
YARA/Sigma: Zero YARA hits on both memory and disk. No Hayabusa or Chainsaw Sigma alerts specific to nfury.
Timestomping: No evidence of malicious timestamp manipulation. Only root directory entries with standard Windows 7 RTM date patterns detected (benign false positives).
Filesystem: No attacker tools, suspicious executables, or classified/sensitive documents found beyond normal business files (Alloy Research documents). The nfury user has Chrome, Skype, and standard applications installed.
Evidence Chain
The nfury system (10.3.58.6) has a single primary user profile: Users/nfury/. The user nfury@stark-research-labs.com has an email mailbox hosted on the controller's hMailServer instance (Program Files (x86)/hMailServer/Data/stark-research-labs.com/nfury/), with email messages stored across multiple subdirectories. Many email files in this mailbox show deleted status (marked with * in TSK), consistent with normal email management rather than evidence destruction.
The nfury user profile contains:
- Google Chrome browser (version 18.0.1025.142) with full profile data
- Skype application with database files (queue.db)
- Documents/Alloy Research/ folder containing research files: "Metal Alloy List Research.xlsx" and "Researched Sub-Atomic Particles.xlsx" (these are Zone.Identifier tagged, indicating they were downloaded from the internet)
- Standard Windows application data (no sensitive/classified files found, unlike nromanoff's "Undercover Agent List" documents)
Additional user accounts found on the controller (which hosts all domain user profiles for file sharing): Administrator, rsydow (with PKI certificates on desktop), vibranium (with McAfee data), and tdungan (with PowerShell pinned to taskbar). These are domain accounts that may have accessed nfury or the broader Stark Research Labs network.
No interactive user session was active on nfury at the time of memory capture — only LogonUI.exe was running (Session 1), indicating the console was at the login screen with no user logged in.
Evidence Chain
The nfury system's active Security.evtx log file is only 8 KB, and System.evtx is only 10 KB. The PowerShell Operational log is 0 KB (empty). These extremely small active log sizes significantly limit forensic visibility into authentication events, service changes, and PowerShell activity that occurred on nfury itself.
However, archive Security log files exist spanning 2012-03-13 to 2012-04-07 (each approximately 4 MB), indicating the system was generating security events that rolled over into archives. The very small active log files suggest either: (1) the active logs were recently rotated and very few events accumulated since the last rollover, or (2) security audit policy is minimal on this workstation.
The Windows PowerShell.evtx file is 32 KB (non-empty), suggesting some PowerShell usage occurred on the system. The nfury system also has an NTLM Operational log (1.2 MB), TerminalServices-RemoteConnectionManager Operational (1.2 MB), and an unusually large IpHlpSvc Operational log (51.8 MB).
Impact: Without indexed Security events from nfury itself, we cannot verify whether logon events, privilege escalations, or account modifications occurred locally. All authentication evidence for nfury comes from the controller's Security log (which records inbound logons from nfury), not from nfury's own perspective. This is a gap in forensic coverage, though no evidence of log clearing or anti-forensic activity was detected.
Evidence Chain
Analysis of the XP system's Master Boot Record (MBR) image shows standard, unmodified boot sector content. Binwalk scan detected no embedded files, hidden code, or anomalous structures. Strings extraction produced only the three standard MBR error messages: "Invalid partition table", "Error loading operating system", "Missing operating system". These are the expected strings for a standard Windows XP MBR. No evidence of MBR-level rootkits, bootkits, or modifications was found.
Evidence Chain
Local SAM analysis of the XP system (WKS-WINXP32BIT, 10.3.58.7) reveals the following local accounts:
- Administrator (RID 500): Created 2010-11-10, Never logged in, Password does not expire
- Guest (RID 501): Disabled
- HelpAssistant (RID 1000): Disabled
- SUPPORT_388945a0 (RID 1002): Disabled (MS vendor support account)
- SRL-Helpdesk (RID 1004): Created 2012-03-13, Local Admin, Last Login 2012-04-06 19:06:37, Login Count 4, Pwd Fail 2012-04-04 12:25:14
Notably:
1. The SRL-Helpdesk account experienced a password failure on 2012-04-04 12:25:14, followed by a password reset on 2012-04-04 12:41:33 - this timing coincides with attacker activity (spinlock.exe crashed on 2012-04-04, vibranium lateral movement on 2012-04-04 16:37).
2. The Administrators group includes domain SID -1107 (tdungan's domain account) and -1004 (SRL-Helpdesk local).
3. Domain SIDs -1106 and -1108 are in the Remote Desktop Users group.
4. No 'vibranium' account exists locally - it is a domain account used for lateral movement FROM this system.
Evidence Chain
Review of all indexed evidence sources confirms that no YARA scanning results exist for the XP system (10.3.58.7). YARA memory scans (yara.memory) were only performed against the domain controller memory (win2008R2-controller-memory-raw.001), and YARA file scans (yara.files) were only performed against the nromanoff disk image. The XP system's memory dump (xp-tdungan-memory-raw.001) and disk image (xp-tdungan-c-drive.E01) were not scanned with YARA rules. Despite this gap, the attacker tooling (spinlock.exe, pe.exe, dllhost\svchost.exe) was identified through ShimCache, memory forensics (psscan), and MFT analysis. YARA scanning of the XP artifacts could potentially identify additional malware signatures or confirm attribution to known threat actor toolsets.
Evidence Chain
MITRE ATT&CK Coverage
Indicators of Compromise
| Type | Value | Enrichment | Context | Actions |
|---|---|---|---|---|
| Internal IP | 10.3.58.4 |
Domain Controller Running Multiple Internet-Facing Services — Critical Attack Su | VT | |
| Internal IP | 10.3.58.9 |
Domain Controller Running Multiple Internet-Facing Services — Critical Attack Su | VT | |
| Port | TCP 80 |
Domain Controller Running Multiple Internet-Facing Services — Critical Attack Su | ||
| Internal IP | 10.3.58.5 |
New Domain Account "nromanoff" Created on Domain Controller | VT | |
| Port | TCP 58497 |
Suspicious Outbound Connection to High Port — 10.3.58.4 → 96.255.98.154:29932 | ||
| External IP | 96.255.98.154 |
Suspicious Outbound Connection to High Port — 10.3.58.4 → 96.255.98.154:29932 | VT | |
| Port | TCP 29932 |
Suspicious Outbound Connection to High Port — 10.3.58.4 → 96.255.98.154:29932 | ||
| Port | TCP 49805 |
Active SMB Connection from Compromised nromanoff Workstation to Domain Controlle | ||
| Port | TCP 445 |
Active SMB Connection from Compromised nromanoff Workstation to Domain Controlle | ||
| Internal IP | 10.3.58.7 |
Cross-System Authentication from Compromised nromanoff to Controller as Multiple | VT | |
| External IP | 188.138.11.56 |
Web Exploitation Attempts and External Scanning Against Domain Controller | VT | |
| External IP | 132.248.31.82 |
Web Exploitation Attempts and External Scanning Against Domain Controller | VT | |
| External IP | 91.207.6.58 |
Web Exploitation Attempts and External Scanning Against Domain Controller | VT | |
| External IP | 86.105.68.176 |
Web Exploitation Attempts and External Scanning Against Domain Controller | VT | |
| External IP | 188.255.86.142 |
Web Exploitation Attempts and External Scanning Against Domain Controller | VT | |
| Port | TCP 49896 |
Cross-System Credential Reuse: Vibranium Account Used from Both Compromised Work |
| Type | Value | Enrichment | Context | Actions |
|---|---|---|---|---|
| Path | C:\WINDOWS\system32\spinlock.exe |
Malicious spinlock.exe Execution Chain on XP System (10.3.58.7) | ||
| Path | C:\WINDOWS\system32\dllhost\svchost.exe |
Masquerading svchost.exe in dllhost Subdirectory on XP System (10.3.58.7) | ||
| Path | C:\WINDOWS\system32\svchost.exe |
Masquerading svchost.exe in dllhost Subdirectory on XP System (10.3.58.7) | ||
| Path | C:\WINDOWS\system32\dllhost\ |
Anomalous svchost.exe Spawned by explorer.exe on XP System (10.3.58.7) | ||
| Path | C:\Tools\SysInternals\ |
Anti-Forensic Tool (SDelete) Present on Domain Controller — Evidence Recovery Im | ||
| Path | C:\WINDOWS\system32\pe.exe |
Environment-Wide Defense Evasion: Timestomping and Process Hiding Across Multipl | ||
| Path | C:\WINDOWS\system32\ |
Environment-Wide Defense Evasion: Timestomping and Process Hiding Across Multipl | ||
| Path | /Windows/Recent/Agents-List-CLASSIFIED-TOP-SECRET.lnk |
Classified Data Accessed Across Multiple Systems — Potential Exfiltration Stagin | ||
| Path | C:\Documents |
Classified Data Accessed Across Multiple Systems — Potential Exfiltration Stagin |
| Type | Value | Enrichment | Context | Actions |
|---|---|---|---|---|
mhill.shield@yahoo.com |
Suspicious Outbound Connection to High Port — 10.3.58.4 → 96.255.98.154:29932 | |||
nromanoff@stark-research-labs.com |
Web Exploitation Attempts and External Scanning Against Domain Controller | |||
nfury@stark-research-labs.com |
Web Exploitation Attempts and External Scanning Against Domain Controller | |||
tdungan@stark-research-labs.com |
Web Exploitation Attempts and External Scanning Against Domain Controller |
Evidence Browser
Evidence Sources
| Source Name | Extractor | Lines | Hash | Referenced By |
|---|---|---|---|---|
| volatility.pslist | volatility3 | 111 | blake2b:dea6349a... |
3 findings |
| volatility.pstree | volatility3 | 111 | blake2b:19086427... |
— |
| tsk.filelist | sleuthkit | 204884 | blake2b:acd05ffd... |
5 findings |
| volatility.cmdline | volatility3 | 111 | blake2b:0461047f... |
1 finding |
| volatility.netscan | volatility3 | 2825 | blake2b:bd1663dc... |
7 findings |
| volatility.malfind | volatility3 | 26 | blake2b:f1e47f13... |
1 finding |
| volatility.psscan | volatility3 | 112 | blake2b:4c226060... |
8 findings |
| volatility.dlllist | volatility3 | 4920 | blake2b:79de59a9... |
— |
| volatility.svcscan | volatility3 | 703 | blake2b:35f5eae8... |
— |
| tsk.filelist | sleuthkit | 137689 | blake2b:a8c13962... |
5 findings |
| bulk.domain | bulk_extractor | 3753807 | blake2b:ea69eaac... |
4 findings |
| yara.memory | yara | 14 | blake2b:dff69c17... |
3 findings |
| ez.shimcache | eztools | 964 | blake2b:b20b4f89... |
7 findings |
| evtx.manifest | evtx-extract | 251 | blake2b:f28ebc8c... |
1 finding |
| registry.system | regripper | 106 | blake2b:4ce31964... |
1 finding |
| registry.system | regripper | 7 | blake2b:e4c6f012... |
1 finding |
| registry.system | regripper | 7 | blake2b:e4c6f012... |
1 finding |
| registry.system | regripper | 69 | blake2b:0c4ee575... |
1 finding |
| registry.system | regripper | 8 | blake2b:3c5e87f4... |
1 finding |
| registry.system | regripper | 8 | blake2b:3c5e87f4... |
1 finding |
| registry.system | regripper | 31884 | blake2b:0c9c5514... |
1 finding |
| registry.system | regripper | 283 | blake2b:b51e2558... |
1 finding |
| registry.system | regripper | 283 | blake2b:24a41d9e... |
1 finding |
| registry.system | regripper | 6194 | blake2b:8d5c13b2... |
1 finding |
| registry.system | regripper | 199 | blake2b:c336d053... |
1 finding |
| registry.system | regripper | 199 | blake2b:f5c9bc86... |
1 finding |
| yara.memory | yara | 14 | blake2b:dff69c17... |
3 findings |
| registry.system | regripper | 381 | blake2b:24349982... |
1 finding |
| registry.system | regripper | 255 | blake2b:0d77cf74... |
1 finding |
| registry.system | regripper | 255 | blake2b:0d77cf74... |
1 finding |
| registry.system | regripper | 106 | blake2b:3bedafb3... |
1 finding |
| registry.system | regripper | 7 | blake2b:e4c6f012... |
1 finding |
| registry.system | regripper | 7 | blake2b:e4c6f012... |
1 finding |
| registry.system | regripper | 69 | blake2b:0c4ee575... |
1 finding |
| registry.system | regripper | 8 | blake2b:3c5e87f4... |
1 finding |
| registry.system | regripper | 8 | blake2b:3c5e87f4... |
1 finding |
| registry.system | regripper | 283 | blake2b:47d8e5fc... |
1 finding |
| registry.system | regripper | 283 | blake2b:5479f196... |
1 finding |
| registry.system | regripper | 6194 | blake2b:276c040b... |
1 finding |
| registry.system | regripper | 199 | blake2b:c336d053... |
1 finding |
| registry.system | regripper | 199 | blake2b:f5c9bc86... |
1 finding |
| registry.system | regripper | 381 | blake2b:24349982... |
1 finding |
| registry.system | regripper | 255 | blake2b:0d77cf74... |
1 finding |
| registry.system | regripper | 255 | blake2b:0d77cf74... |
1 finding |
| registry.system | regripper | 31884 | blake2b:2da63ebb... |
1 finding |
| chainsaw.hunt | chainsaw | 2 | blake2b:6382cec4... |
— |
| ez.mft | eztools | 196498 | blake2b:19249f73... |
3 findings |
| bulk.domain | bulk_extractor | 920260 | blake2b:99767d8a... |
4 findings |
| bulk.email | bulk_extractor | 74342 | blake2b:37f397a7... |
1 finding |
| bulk.ether | bulk_extractor | 883 | blake2b:ae202d4d... |
— |
| bulk.ip | bulk_extractor | 1007 | blake2b:5d507011... |
— |
| bulk.packets | bulk_extractor | 2254 | blake2b:59af1b5e... |
— |
| bulk.rfc822 | bulk_extractor | 10677 | blake2b:0bdb9512... |
— |
| bulk.tcp | bulk_extractor | 503 | blake2b:63fde8f2... |
— |
| bulk.url | bulk_extractor | 745973 | blake2b:a8f32d95... |
— |
| bulk.url_facebook-address | bulk_extractor | 41 | blake2b:9f68d782... |
— |
| bulk.url_facebook-id | bulk_extractor | 17 | blake2b:72b92437... |
— |
| bulk.url_searches | bulk_extractor | 381 | blake2b:00cc80f6... |
— |
| bulk.url_services | bulk_extractor | 5150 | blake2b:3c09914b... |
— |
| chainsaw.hunt | chainsaw | 2 | blake2b:82d33460... |
— |
| ez.mft | eztools | 133660 | blake2b:e95beeb5... |
3 findings |
| evtx.windows_system32_winevt_logs_security | eztools | 67566 | blake2b:d2b1fac7... |
8 findings |
| evtx.manifest | evtx-extract | 252 | blake2b:27e0c060... |
1 finding |
| evtx.windows_system32_winevt_logs_application | eztools | 13173 | blake2b:d0cf10f0... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 11 | blake2b:54fa5d9c... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 11 | blake2b:54fa5d9c... |
— |
| composite.persistence | composite | 4879 | blake2b:ed80abf0... |
— |
| yara.files | yara | 18 | blake2b:e9a648fe... |
3 findings |
| evtx.windows_system32_winevt_logs_system | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-windows-firewall-with-advanced-security4connectionsecurity | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_application | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 2 | blake2b:a4a04fb8... |
— |
| forensic.timestomping | timestomp_detector | 2 | blake2b:0928eff5... |
2 findings |
| composite.persistence | composite | 4879 | blake2b:4cec91d2... |
— |
| forensic.timestomping | timestomp_detector | 2 | blake2b:0928eff5... |
2 findings |
| composite.exfil | composite | 37278 | blake2b:1169146d... |
— |
| enrichment.iocs | enrichment | 34 | blake2b:56946a45... |
— |
| evtx.windows_system32_winevt_logs_system | eztools | 2 | blake2b:a4a04fb8... |
— |
| volatility.pslist | volatility3 | 37 | blake2b:19d3c348... |
3 findings |
| volatility.pstree | volatility3 | 37 | blake2b:5b61f226... |
— |
| tsk.filelist | sleuthkit | 178738 | blake2b:b7922a04... |
5 findings |
| volatility.cmdline | volatility3 | 37 | blake2b:c88261d9... |
1 finding |
| volatility.netscan | volatility3 | 69 | blake2b:65a309c4... |
7 findings |
| yara.memory | yara | 14 | blake2b:dff69c17... |
3 findings |
| volatility.malfind | volatility3 | 6 | blake2b:d7d5fbe8... |
1 finding |
| volatility.psscan | volatility3 | 39 | blake2b:ae03a28c... |
8 findings |
| volatility.dlllist | volatility3 | 1800 | blake2b:8afa50d2... |
— |
| volatility.svcscan | volatility3 | 847 | blake2b:a348aca5... |
— |
| bulk.domain | bulk_extractor | 763737 | blake2b:77b564d1... |
4 findings |
| bulk.email | bulk_extractor | 22643 | blake2b:972bf3ab... |
1 finding |
| bulk.ether | bulk_extractor | 813 | blake2b:2aca0eed... |
— |
| bulk.ip | bulk_extractor | 951 | blake2b:3063584e... |
— |
| bulk.packets | bulk_extractor | 3334 | blake2b:3ffe77c9... |
— |
| bulk.rfc822 | bulk_extractor | 32841 | blake2b:5fa71f00... |
— |
| bulk.tcp | bulk_extractor | 471 | blake2b:0a4e51a8... |
— |
| bulk.url | bulk_extractor | 731854 | blake2b:350fd35d... |
— |
| bulk.url_facebook-address | bulk_extractor | 24 | blake2b:ab14c411... |
— |
| bulk.url_facebook-id | bulk_extractor | 11 | blake2b:4167c42c... |
— |
| bulk.url_searches | bulk_extractor | 202 | blake2b:2d83ea12... |
— |
| bulk.url_services | bulk_extractor | 5500 | blake2b:68f7edd0... |
— |
| ez.mft | eztools | 172668 | blake2b:f6b6142f... |
3 findings |
| evtx.manifest | evtx-extract | 414 | blake2b:84ddd48c... |
1 finding |
| binwalk.scan | binwalk | 0 | blake2b:empty... |
1 finding |
| strings.output | strings | 5 | blake2b:e1531611... |
1 finding |
| tsk.filelist | sleuthkit | 56016 | blake2b:66ad4c7c... |
5 findings |
| volatility.psscan | volatility3 | 56 | blake2b:4dce9cca... |
8 findings |
| yara.memory | yara | 14 | blake2b:dff69c17... |
3 findings |
| volatility.modscan | volatility3 | 130 | blake2b:ed89c3f1... |
— |
| bulk.domain | bulk_extractor | 242475 | blake2b:582e2207... |
4 findings |
| bulk.email | bulk_extractor | 7309 | blake2b:11dae78a... |
1 finding |
| bulk.ether | bulk_extractor | 20 | blake2b:d8797f9f... |
— |
| bulk.httplogs | bulk_extractor | 6 | blake2b:4c804a4c... |
— |
| bulk.ip | bulk_extractor | 33 | blake2b:cae1f2b1... |
— |
| bulk.packets | bulk_extractor | 34 | blake2b:9eb235ba... |
— |
| bulk.rfc822 | bulk_extractor | 23579 | blake2b:9f81130b... |
— |
| bulk.tcp | bulk_extractor | 13 | blake2b:8ace8511... |
— |
| bulk.url | bulk_extractor | 276247 | blake2b:9a8e6ab5... |
— |
| bulk.url_facebook-address | bulk_extractor | 65 | blake2b:0b1e6756... |
— |
| bulk.url_facebook-id | bulk_extractor | 14 | blake2b:2fb7e784... |
— |
| bulk.url_searches | bulk_extractor | 172 | blake2b:32788516... |
— |
| bulk.url_services | bulk_extractor | 5057 | blake2b:a43c5dfe... |
— |
| chainsaw.hunt | chainsaw | 2 | blake2b:919dee9a... |
— |
| ez.mft | eztools | 52230 | blake2b:3cb43deb... |
3 findings |
| tsk.timeline | sleuthkit | 212389 | blake2b:2c5723ae... |
— |
| ez.shimcache | eztools | 194 | blake2b:234166e5... |
7 findings |
| registry.default | regripper | 415 | blake2b:9f352495... |
— |
| registry.default | regripper | 403 | blake2b:13e7da1e... |
— |
| registry.sam | regripper | 140 | blake2b:28635769... |
3 findings |
| registry.sam | regripper | 7 | blake2b:e4c6f012... |
3 findings |
| registry.security | regripper | 19 | blake2b:7fef33f8... |
— |
| registry.security | regripper | 8 | blake2b:3c5e87f4... |
— |
| registry.software | regripper | 13742 | blake2b:b3e03e03... |
— |
| registry.software | regripper | 283 | blake2b:213570ff... |
— |
| registry.software | regripper | 283 | blake2b:75285f64... |
— |
| registry.software | regripper | 486 | blake2b:62ecf44c... |
— |
| registry.system | regripper | 3657 | blake2b:ee6ed961... |
1 finding |
| registry.system | regripper | 199 | blake2b:a0dd4b8d... |
1 finding |
| registry.system | regripper | 199 | blake2b:510d7840... |
1 finding |
| evtx.windows_system32_winevt_logs_microsoft-windows-windows-firewall-with-advanced-security4connectionsecurity | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_application | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 2 | blake2b:a4a04fb8... |
— |
| evtx.windows_system32_winevt_logs_microsoft-windows-powershell4operational | eztools | 2 | blake2b:a4a04fb8... |
— |
| forensic.timestomping | timestomp_detector | 3 | blake2b:e843e5da... |
2 findings |
| composite.correlation | composite | 1 | blake2b:d70a3eac... |
— |
| composite.correlation | composite | 1 | blake2b:e0e3e8c7... |
— |
| composite.correlation | composite | 1 | blake2b:f1055e0c... |
— |
| composite.suspicious_processes | composite | 156 | blake2b:3a9e0070... |
— |
| composite.execution | composite | 462 | blake2b:ac56e060... |
— |
| composite.timeline | composite | 594 | blake2b:817ed263... |
— |
| composite.exfil | composite | 48571 | blake2b:2ea6588b... |
— |
| composite.file_staging | composite | 3176 | blake2b:08f73063... |
— |
| composite.persistence | composite | 5809 | blake2b:b24b3bed... |
— |
| composite.defense_evasion | composite | 38 | blake2b:fc4c43b2... |
1 finding |
| composite.recovery | composite | 22 | blake2b:72a746e9... |
1 finding |
| composite.correlation | composite | 1 | blake2b:91c979a6... |
— |
| composite.correlation | composite | 1 | blake2b:93a60d02... |
— |
| composite.correlation | composite | 1 | blake2b:2525f8ab... |
— |
Investigation Performance
| Input Tokens | 112,477 |
| Output Tokens | 199,019 |
| Total Tokens | 311,496 |
| Per-Model Breakdown | |
| claude-opus-4-6 | 311,496 |
Audit Trail
| ID | Tool | Duration | Timestamp | Actions |
|---|---|---|---|---|
| tc_9d51764b | scan_evidence | 74131ms | 2026-06-05T04:08:02 | |
| tc_b4c7cb09 | list_sources | 7ms | 2026-06-05T04:08:07 | |
| tc_ca81a583 | get_source_stats | 6ms | 2026-06-05T04:08:07 | |
| tc_08537233 | scan_evidence | 73ms | 2026-06-05T04:08:42 | |
| tc_c1c4c91b | scan_evidence | 57ms | 2026-06-05T04:08:43 | |
| tc_56778502 | open_case | 13ms | 2026-06-05T04:08:47 | |
| tc_23d5b01a | open_case | 13ms | 2026-06-05T04:08:53 | |
| tc_76fd587b | open_case | 15ms | 2026-06-05T04:09:36 | |
| tc_dedd42a5 | open_case | 14ms | 2026-06-05T04:09:44 | |
| tc_7acf281f | start_extraction_batch | 25ms | 2026-06-05T04:09:45 | |
| tc_be439a3d | run_mmls | 0ms | 2026-06-05T04:09:45 | |
| tc_9f009fb5 | extract_archive | 13209ms | 2026-06-05T04:10:02 | |
| tc_9a339e77 | run_fls | 49629ms | 2026-06-05T04:10:35 | |
| tc_dab3d843 | run_volatility_batch | 243315ms | 2026-06-05T04:13:48 | |
| tc_4f735065 | start_extraction_batch | 55ms | 2026-06-05T04:15:14 | |
| tc_7868f140 | run_mmls | 0ms | 2026-06-05T04:15:14 | |
| tc_dc163c2c | run_volatility_batch | 14661ms | 2026-06-05T04:15:29 | |
| tc_e5b00ff6 | run_volatility_batch | 27020ms | 2026-06-05T04:15:41 | |
| tc_db23c11c | run_fls | 30854ms | 2026-06-05T04:15:45 | |
| tc_1e3d0cc4 | scan_evidence | 150ms | 2026-06-05T04:48:53 | |
| tc_b9da1fa0 | list_sources | 6ms | 2026-06-05T04:49:02 | |
| tc_b790ef0c | get_source_stats | 1486ms | 2026-06-05T04:49:03 | |
| tc_e41614aa | scan_evidence | 62ms | 2026-06-05T04:49:37 | |
| tc_facd6cb2 | open_case | 14ms | 2026-06-05T04:49:49 | |
| tc_da3aab9f | scan_evidence | 67ms | 2026-06-05T04:49:53 | |
| tc_07b1c66c | open_case | 12ms | 2026-06-05T04:50:12 | |
| tc_86f2c1f9 | scan_evidence | 44ms | 2026-06-05T04:50:36 | |
| tc_8a2cf659 | open_case | 17ms | 2026-06-05T04:50:42 | |
| tc_8da6fd2c | start_extraction_batch | 19ms | 2026-06-05T04:50:52 | |
| tc_c5795913 | run_mmls | 0ms | 2026-06-05T04:50:52 | |
| tc_8123393f | open_case | 6ms | 2026-06-05T04:51:10 | |
| tc_dfe82942 | extract_archive | 2ms | 2026-06-05T04:51:16 | |
| tc_60c8b8cd | extract_archive | 9ms | 2026-06-05T04:51:16 | |
| tc_530e75b0 | run_mmls | 0ms | 2026-06-05T04:51:22 | |
| tc_7211ccaa | start_extraction_batch | 17ms | 2026-06-05T04:51:29 | |
| tc_26f8cded | start_extraction_batch | 6ms | 2026-06-05T04:51:36 | |
| tc_2884194a | run_volatility_batch | 19284ms | 2026-06-05T04:51:48 | |
| tc_0501919d | run_volatility_batch | 30941ms | 2026-06-05T04:52:00 | |
| tc_5e83eee6 | yara_scan_memory | 76677ms | 2026-06-05T04:52:09 | |
| tc_cbce4254 | get_completed_results | 0ms | 2026-06-05T04:52:14 | |
| tc_5a811164 | start_extraction_batch | 64ms | 2026-06-05T04:57:26 | |
| tc_2a13fef3 | run_amcache_parser | 3892ms | 2026-06-05T04:57:30 | |
| tc_4533a2da | run_shimcache_parser | 19517ms | 2026-06-05T04:57:46 | |
| tc_e2dbbd0a | run_hayabusa | 23261ms | 2026-06-05T04:57:50 | |
| tc_73c83372 | run_evtx_parser | 23327ms | 2026-06-05T04:57:50 | |
| tc_2f505333 | yara_scan_memory | 93535ms | 2026-06-05T04:58:10 | |
| tc_358cf114 | run_registry_parser | 106867ms | 2026-06-05T04:59:13 | |
| tc_5ad131bb | run_chainsaw | 37ms | 2026-06-05T05:00:16 | |
| tc_8fceddfa | run_prefetch_parser | 12786ms | 2026-06-05T05:00:29 | |
| tc_9c73a8cc | run_mft_parser | 41298ms | 2026-06-05T05:00:58 | |
| tc_9c2f7ba8 | yara_scan_files | 134269ms | 2026-06-05T05:02:30 | |
| tc_d9206d37 | get_completed_results | 0ms | 2026-06-05T05:02:36 | |
| tc_206cb910 | run_prefetch_parser | 7333ms | 2026-06-05T05:02:50 | |
| tc_9f05b636 | run_amcache_parser | 1026ms | 2026-06-05T05:02:51 | |
| tc_7dba1985 | open_case | 13ms | 2026-06-05T05:03:27 | |
| tc_bd5bc8bb | get_investigation_summary | 7ms | 2026-06-05T05:03:32 | |
| tc_9eb9606a | get_source_stats | 1990ms | 2026-06-05T05:03:35 | |
| tc_8d405847 | list_processes_from_memory | 3ms | 2026-06-05T05:03:35 | |
| tc_a7e7c23c | get_process_tree | 2ms | 2026-06-05T05:03:35 | |
| tc_927ce374 | get_raw_output | 2127ms | 2026-06-05T05:03:47 | |
| tc_20a09ea0 | get_raw_output | 2210ms | 2026-06-05T05:03:49 | |
| tc_217bf5eb | get_raw_output | 62ms | 2026-06-05T05:03:49 | |
| tc_25754c17 | get_raw_output | 584ms | 2026-06-05T05:03:53 | |
| tc_6b1737ea | get_raw_output | 471ms | 2026-06-05T05:03:53 | |
| tc_e358f397 | get_raw_output | 506ms | 2026-06-05T05:03:54 | |
| tc_bda45a7f | get_raw_output | 1836ms | 2026-06-05T05:04:17 | |
| tc_e44f563e | get_raw_output | 633ms | 2026-06-05T05:04:20 | |
| tc_6b84f014 | search | 63ms | 2026-06-05T05:04:22 | |
| tc_f50efa9b | scan_hidden_processes | 3ms | 2026-06-05T05:04:22 | |
| tc_e3b94f07 | search | 36ms | 2026-06-05T05:04:36 | |
| tc_1f497f95 | search | 165ms | 2026-06-05T05:04:38 | |
| tc_fb7e6fa3 | search | 126ms | 2026-06-05T05:04:39 | |
| tc_59b7b8e6 | get_raw_output | 1734ms | 2026-06-05T05:04:41 | |
| tc_2b597b1c | run_bulk_extractor | 793194ms | 2026-06-05T05:04:42 | |
| tc_596abbc8 | wait_all | 485056ms | 2026-06-05T05:04:46 | |
| tc_436d938d | get_completed_results | 0ms | 2026-06-05T05:04:52 | |
| tc_ce94d13c | get_completed_results | 0ms | 2026-06-05T05:04:52 | |
| tc_02c81b26 | start_extraction_batch | 25ms | 2026-06-05T05:05:03 | |
| tc_d8137da7 | run_chainsaw | 50ms | 2026-06-05T05:05:03 | |
| tc_80c6bde7 | run_amcache_parser | 4842ms | 2026-06-05T05:05:08 | |
| tc_9eacd87f | run_hayabusa | 11ms | 2026-06-05T05:05:08 | |
| tc_7fc4c9c6 | run_prefetch_parser | 13968ms | 2026-06-05T05:05:17 | |
| tc_7f9e9bf6 | run_shimcache_parser | 16123ms | 2026-06-05T05:05:19 | |
| tc_37f9fd5d | run_evtx_parser | 34615ms | 2026-06-05T05:05:38 | |
| tc_c43881d9 | run_mft_parser | 41470ms | 2026-06-05T05:05:45 | |
| tc_b1fd31ee | index_evtx_file | 65439ms | 2026-06-05T05:06:03 | |
| tc_582cc5b7 | search | 53ms | 2026-06-05T05:06:03 | |
| tc_38986aac | search | 19ms | 2026-06-05T05:06:03 | |
| tc_ce9e341f | find_persistence_mechanisms._query(registry.system) | 340ms | 2026-06-05T05:06:04 | |
| tc_7f1a647d | find_persistence_mechanisms._query(registry.software) | 47ms | 2026-06-05T05:06:04 | |
| tc_dc0602ec | find_persistence_mechanisms._query(volatility.svcscan) | 50ms | 2026-06-05T05:06:04 | |
| tc_3ce285cb | find_persistence_mechanisms._search(all) | 31ms | 2026-06-05T05:06:04 | |
| tc_33caca8e | find_persistence_mechanisms._search(all) | 11ms | 2026-06-05T05:06:04 | |
| tc_656f7d93 | find_persistence_mechanisms._query(ez.shimcache) | 48ms | 2026-06-05T05:06:04 | |
| tc_5ef94a38 | find_persistence_mechanisms._search(all) | 19ms | 2026-06-05T05:06:04 | |
| tc_05f38466 | find_persistence_mechanisms._query(tsk.filelist) | 330ms | 2026-06-05T05:06:04 | |
| tc_46b6bbd5 | find_persistence_mechanisms | 944ms | 2026-06-05T05:06:04 | |
| tc_2dff9477 | run_registry_parser | 61569ms | 2026-06-05T05:06:05 | |
| tc_24650e16 | search | 24ms | 2026-06-05T05:06:17 | |
| tc_fc7a21b3 | search | 28ms | 2026-06-05T05:06:18 | |
| tc_01f8c7d3 | search | 564ms | 2026-06-05T05:06:19 | |
| tc_9cbabd13 | search | 543ms | 2026-06-05T05:06:20 | |
| tc_f49144d2 | yara_scan_files | 91003ms | 2026-06-05T05:06:34 | |
| tc_e696bed7 | get_completed_results | 0ms | 2026-06-05T05:06:40 | |
| tc_3537a329 | start_extraction_batch | 4ms | 2026-06-05T05:06:42 | |
| tc_b3850ed1 | run_amcache_parser | 2089ms | 2026-06-05T05:06:44 | |
| tc_936e2f1e | search | 818ms | 2026-06-05T05:06:51 | |
| tc_ff098fce | run_prefetch_parser | 8840ms | 2026-06-05T05:06:51 | |
| tc_d7072b05 | search | 111ms | 2026-06-05T05:06:51 | |
| tc_081736e3 | run_shimcache_parser | 10243ms | 2026-06-05T05:06:52 | |
| tc_cb87bd9e | search | 780ms | 2026-06-05T05:06:52 | |
| tc_c2e0da11 | start_extraction_batch | 4ms | 2026-06-05T05:07:04 | |
| tc_d45d4de1 | index_evtx_file | 408ms | 2026-06-05T05:07:04 | |
| tc_492e3cbb | index_evtx_file | 499ms | 2026-06-05T05:07:04 | |
| tc_9beb504d | index_evtx_file | 1525ms | 2026-06-05T05:07:05 | |
| tc_b4354e17 | get_completed_results | 0ms | 2026-06-05T05:07:12 | |
| tc_613b26b5 | submit_finding | 14ms | 2026-06-05T05:07:31 | |
| tc_f497e37f | submit_finding | 17ms | 2026-06-05T05:07:42 | |
| tc_60d666bf | open_case | 16ms | 2026-06-05T05:07:46 | |
| tc_047213fa | get_investigation_summary | 21ms | 2026-06-05T05:07:51 | |
| tc_5419fe30 | submit_finding | 20ms | 2026-06-05T05:07:53 | |
| tc_db59b0d1 | get_source_stats | 5498ms | 2026-06-05T05:07:56 | |
| tc_5178abad | list_sources | 4ms | 2026-06-05T05:07:56 | |
| tc_05146e64 | get_findings | 6ms | 2026-06-05T05:08:09 | |
| tc_68c02d5b | get_process_tree | 8ms | 2026-06-05T05:08:10 | |
| tc_6500902a | get_raw_output | 5489ms | 2026-06-05T05:08:16 | |
| tc_a2de6d4e | get_raw_output | 5402ms | 2026-06-05T05:08:21 | |
| tc_6bee11c0 | get_raw_output | 5423ms | 2026-06-05T05:08:27 | |
| tc_0928f0c9 | search | 34ms | 2026-06-05T05:08:40 | |
| tc_0360ead5 | search | 22ms | 2026-06-05T05:08:42 | |
| tc_10d4c2ff | get_raw_output | 5399ms | 2026-06-05T05:08:48 | |
| tc_c9868a74 | search | 270ms | 2026-06-05T05:08:50 | |
| tc_05889582 | get_raw_output | 5338ms | 2026-06-05T05:08:56 | |
| tc_5c7a2a99 | search | 563ms | 2026-06-05T05:09:10 | |
| tc_0d8f793d | search | 68ms | 2026-06-05T05:09:11 | |
| tc_c375140b | search | 16ms | 2026-06-05T05:09:11 | |
| tc_69a6f520 | search | 35ms | 2026-06-05T05:09:14 | |
| tc_bc9ff3e3 | get_raw_output | 5056ms | 2026-06-05T05:09:19 | |
| tc_8361dd7f | search | 1299ms | 2026-06-05T05:09:35 | |
| tc_c89b8d1f | scan_hidden_processes | 8ms | 2026-06-05T05:09:35 | |
| tc_a0ce135c | detect_timestomping | 1438ms | 2026-06-05T05:09:36 | |
| tc_9c4a7c58 | search | 559ms | 2026-06-05T05:09:37 | |
| tc_090b0255 | find_persistence_mechanisms._query(registry.system) | 113ms | 2026-06-05T05:09:37 | |
| tc_56b7791a | find_persistence_mechanisms._query(registry.software) | 43ms | 2026-06-05T05:09:37 | |
| tc_7f6d3a46 | find_persistence_mechanisms._query(volatility.svcscan) | 36ms | 2026-06-05T05:09:37 | |
| tc_1273b71f | find_persistence_mechanisms._search(all) | 24ms | 2026-06-05T05:09:37 | |
| tc_ebe585e1 | find_persistence_mechanisms._search(all) | 19ms | 2026-06-05T05:09:37 | |
| tc_cee9e4a8 | find_persistence_mechanisms._query(ez.shimcache) | 43ms | 2026-06-05T05:09:37 | |
| tc_3e3a1069 | find_persistence_mechanisms._search(all) | 26ms | 2026-06-05T05:09:37 | |
| tc_08553da7 | find_persistence_mechanisms._query(tsk.filelist) | 196ms | 2026-06-05T05:09:37 | |
| tc_08f82f0d | find_persistence_mechanisms | 568ms | 2026-06-05T05:09:37 | |
| tc_19bc3e88 | get_raw_output | 4185ms | 2026-06-05T05:09:59 | |
| tc_65457a15 | search | 111ms | 2026-06-05T05:09:59 | |
| tc_e5e02b86 | search | 347ms | 2026-06-05T05:09:59 | |
| tc_f016bd96 | get_raw_output | 69ms | 2026-06-05T05:10:00 | |
| tc_cfd6c9b3 | search | 28ms | 2026-06-05T05:10:00 | |
| tc_b2e0d36a | search | 15ms | 2026-06-05T05:10:01 | |
| tc_46f32b22 | search | 47ms | 2026-06-05T05:10:02 | |
| tc_6d4eba37 | search | 18ms | 2026-06-05T05:10:02 | |
| tc_6c52314e | search | 23ms | 2026-06-05T05:10:10 | |
| tc_410280bd | search | 27ms | 2026-06-05T05:10:10 | |
| tc_2d403c97 | search | 34ms | 2026-06-05T05:10:11 | |
| tc_11404ee6 | search | 184ms | 2026-06-05T05:10:23 | |
| tc_ecc9e3b6 | search | 66ms | 2026-06-05T05:10:24 | |
| tc_5507dd92 | search | 519ms | 2026-06-05T05:10:25 | |
| tc_996bf9a5 | submit_finding | 16ms | 2026-06-05T05:10:36 | |
| tc_26e579df | submit_finding | 19ms | 2026-06-05T05:10:45 | |
| tc_d8185893 | submit_finding | 15ms | 2026-06-05T05:10:56 | |
| tc_b8fe35b8 | search | 83ms | 2026-06-05T05:11:04 | |
| tc_e2845ffe | search | 83ms | 2026-06-05T05:11:06 | |
| tc_c8af241c | detect_timestomping | 1114ms | 2026-06-05T05:11:07 | |
| tc_275d441d | get_raw_output | 4029ms | 2026-06-05T05:11:18 | |
| tc_498d5dcc | scan_hidden_processes | 16ms | 2026-06-05T05:11:18 | |
| tc_8a547874 | search | 193ms | 2026-06-05T05:11:18 | |
| tc_198e097f | get_raw_output | 923ms | 2026-06-05T05:11:42 | |
| tc_6653c450 | find_data_exfiltration_indicators._query(bulk.url) | 1156ms | 2026-06-05T05:11:43 | |
| tc_24edd1d0 | find_data_exfiltration_indicators._query(bulk.email) | 269ms | 2026-06-05T05:11:44 | |
| tc_7ca8581e | find_data_exfiltration_indicators._query(bulk.domain) | 1317ms | 2026-06-05T05:11:46 | |
| tc_29eb49d9 | find_data_exfiltration_indicators._query(volatility.netscan) | 67ms | 2026-06-05T05:11:47 | |
| tc_5a9f36e6 | find_data_exfiltration_indicators._search(all) | 39ms | 2026-06-05T05:11:47 | |
| tc_64c9cede | find_data_exfiltration_indicators | 4973ms | 2026-06-05T05:11:47 | |
| tc_3bbb7c32 | enrich_iocs | 391ms | 2026-06-05T05:12:19 | |
| tc_044e25a8 | get_raw_output | 1599ms | 2026-06-05T05:12:19 | |
| tc_f6d4e50d | search | 44ms | 2026-06-05T05:12:19 | |
| tc_27f7cd7c | search | 19ms | 2026-06-05T05:12:19 | |
| tc_ee1c02bf | search | 45ms | 2026-06-05T05:12:20 | |
| tc_63834dd2 | get_raw_output | 913ms | 2026-06-05T05:12:30 | |
| tc_61e6f538 | search | 21ms | 2026-06-05T05:12:30 | |
| tc_83c1de94 | search | 51ms | 2026-06-05T05:12:31 | |
| tc_42e1f175 | update_finding | 19ms | 2026-06-05T05:12:40 | |
| tc_b3661893 | get_raw_output | 73ms | 2026-06-05T05:12:44 | |
| tc_6c944df9 | search | 45ms | 2026-06-05T05:12:44 | |
| tc_6d1870e8 | search | 260ms | 2026-06-05T05:12:45 | |
| tc_e371f3b1 | submit_finding | 6ms | 2026-06-05T05:12:52 | |
| tc_ce79f5e7 | submit_finding | 18ms | 2026-06-05T05:13:04 | |
| tc_dbeb1375 | submit_finding | 16ms | 2026-06-05T05:13:19 | |
| tc_d171dca8 | submit_finding | 18ms | 2026-06-05T05:13:23 | |
| tc_505aa033 | search | 33ms | 2026-06-05T05:13:23 | |
| tc_b90186fe | submit_finding | 16ms | 2026-06-05T05:13:33 | |
| tc_dfc70b14 | search | 22ms | 2026-06-05T05:13:33 | |
| tc_52f7f07a | search | 126ms | 2026-06-05T05:13:35 | |
| tc_42d84a0b | index_evtx_file | 399ms | 2026-06-05T05:13:36 | |
| tc_e4f0fd77 | search | 32ms | 2026-06-05T05:13:38 | |
| tc_88b377f4 | search | 42ms | 2026-06-05T05:13:38 | |
| tc_51700ea3 | search | 38ms | 2026-06-05T05:13:43 | |
| tc_c8aa0f90 | search | 521ms | 2026-06-05T05:13:44 | |
| tc_86aacb12 | get_raw_output | 1560ms | 2026-06-05T05:13:45 | |
| tc_15f21ebd | search | 28ms | 2026-06-05T05:13:45 | |
| tc_28ac6c3d | search | 22ms | 2026-06-05T05:13:58 | |
| tc_af73c654 | search | 59ms | 2026-06-05T05:13:59 | |
| tc_a0fec080 | search | 24ms | 2026-06-05T05:13:59 | |
| tc_1b299b56 | submit_finding | 18ms | 2026-06-05T05:14:02 | |
| tc_0a1abd96 | search | 172ms | 2026-06-05T05:14:11 | |
| tc_3a11a971 | search | 44ms | 2026-06-05T05:14:12 | |
| tc_93980f9f | submit_finding | 14ms | 2026-06-05T05:14:12 | |
| tc_e6b51116 | search | 26ms | 2026-06-05T05:14:12 | |
| tc_76b93123 | search | 63ms | 2026-06-05T05:14:17 | |
| tc_88b54fd0 | search | 56ms | 2026-06-05T05:14:18 | |
| tc_c9454afe | search | 25ms | 2026-06-05T05:14:26 | |
| tc_027490e9 | search | 144ms | 2026-06-05T05:14:28 | |
| tc_09b2beaa | get_ioc_summary | 1842ms | 2026-06-05T05:14:31 | |
| tc_c69fbf3b | get_findings | 27ms | 2026-06-05T05:14:34 | |
| tc_e535bb46 | submit_finding | 16ms | 2026-06-05T05:14:55 | |
| tc_4821d0ab | submit_finding | 15ms | 2026-06-05T05:15:04 | |
| tc_6d7d1c08 | search | 228ms | 2026-06-05T05:15:11 | |
| tc_ea52da80 | search | 766ms | 2026-06-05T05:15:12 | |
| tc_6957fdbb | search | 15ms | 2026-06-05T05:15:12 | |
| tc_f2dda34f | submit_finding | 16ms | 2026-06-05T05:15:36 | |
| tc_7a09b612 | search | 52ms | 2026-06-05T05:15:41 | |
| tc_95d2f714 | search | 48ms | 2026-06-05T05:15:42 | |
| tc_932f016f | track_progress | 15ms | 2026-06-05T05:15:43 | |
| tc_107b39a8 | get_investigation_summary | 10ms | 2026-06-05T05:16:05 | |
| tc_cd818b2a | submit_finding | 8ms | 2026-06-05T05:16:07 | |
| tc_e0f12bf9 | search | 167ms | 2026-06-05T05:16:13 | |
| tc_194ced20 | search | 140ms | 2026-06-05T05:16:13 | |
| tc_ecb397d6 | scan_evidence | 63ms | 2026-06-05T05:16:27 | |
| tc_be241a2b | submit_finding | 16ms | 2026-06-05T05:16:34 | |
| tc_bcf514dc | open_case | 18ms | 2026-06-05T05:16:39 | |
| tc_4a6ddd5f | search | 73ms | 2026-06-05T05:16:40 | |
| tc_9312ce29 | get_ioc_summary | 1677ms | 2026-06-05T05:16:42 | |
| tc_ebfebb13 | list_sources | 26ms | 2026-06-05T05:16:43 | |
| tc_aca5a853 | search | 48ms | 2026-06-05T05:16:54 | |
| tc_8940e07d | search | 68ms | 2026-06-05T05:16:55 | |
| tc_1e669e75 | submit_finding | 15ms | 2026-06-05T05:17:18 | |
| tc_2d8523bf | submit_finding | 16ms | 2026-06-05T05:17:34 | |
| tc_cebb9756 | open_case | 17ms | 2026-06-05T05:17:43 | |
| tc_c87a2184 | start_extraction_batch | 18ms | 2026-06-05T05:17:54 | |
| tc_2e991079 | run_mmls | 0ms | 2026-06-05T05:17:54 | |
| tc_c0ddf2b2 | submit_finding | 15ms | 2026-06-05T05:18:02 | |
| tc_6193039f | run_fls | 44779ms | 2026-06-05T05:18:39 | |
| tc_9b900ae8 | yara_scan_memory | 100658ms | 2026-06-05T05:19:35 | |
| tc_4d47ce9a | run_volatility_batch | 187485ms | 2026-06-05T05:21:02 | |
| tc_6063b718 | get_findings | 21ms | 2026-06-05T05:23:10 | |
| tc_99347cb3 | track_progress | 19ms | 2026-06-05T05:26:23 | |
| tc_eb40e2d7 | get_investigation_summary | 11ms | 2026-06-05T05:26:45 | |
| tc_b0fc4881 | scan_evidence | 60ms | 2026-06-05T05:27:38 | |
| tc_c12ee8ae | open_case | 21ms | 2026-06-05T05:27:49 | |
| tc_5c7d5103 | list_sources | 8ms | 2026-06-05T05:27:53 | |
| tc_7d004b91 | run_bulk_extractor | 605957ms | 2026-06-05T05:28:05 | |
| tc_de56057b | get_completed_results | 0ms | 2026-06-05T05:28:09 | |
| tc_97dae562 | start_extraction_batch | 38ms | 2026-06-05T05:28:19 | |
| tc_b65012e0 | run_amcache_parser | 12104ms | 2026-06-05T05:28:32 | |
| tc_3c4ee4eb | run_prefetch_parser | 32682ms | 2026-06-05T05:28:52 | |
| tc_3569eab6 | run_shimcache_parser | 41083ms | 2026-06-05T05:29:01 | |
| tc_db5d19e1 | run_mft_parser | 45670ms | 2026-06-05T05:29:05 | |
| tc_6a3810b6 | run_evtx_parser | 45709ms | 2026-06-05T05:29:05 | |
| tc_6a75f744 | open_case | 13ms | 2026-06-05T05:29:27 | |
| tc_354254e7 | extract_archive | 3ms | 2026-06-05T05:29:33 | |
| tc_1eefac34 | extract_archive | 9051ms | 2026-06-05T05:29:42 | |
| tc_5810d37e | start_extraction_batch | 25ms | 2026-06-05T05:29:54 | |
| tc_453beca4 | run_mmls | 0ms | 2026-06-05T05:29:56 | |
| tc_549d6925 | run_binwalk | 284ms | 2026-06-05T05:29:56 | |
| tc_5e4dbafb | run_strings | 693ms | 2026-06-05T05:29:56 | |
| tc_c2a5b062 | run_fls | 16591ms | 2026-06-05T05:30:10 | |
| tc_946492e9 | run_registry_parser | 116322ms | 2026-06-05T05:30:16 | |
| tc_2dd0b681 | yara_scan_files | 136987ms | 2026-06-05T05:30:36 | |
| tc_20ffabce | get_completed_results | 0ms | 2026-06-05T05:30:41 | |
| tc_df6f79e5 | run_volatility_batch | 65298ms | 2026-06-05T05:30:59 | |
| tc_d352a162 | start_extraction_batch | 33ms | 2026-06-05T05:31:46 | |
| tc_db0e17b4 | run_hayabusa | 50ms | 2026-06-05T05:31:46 | |
| tc_85c24bd4 | yara_scan_memory | 111936ms | 2026-06-05T05:31:48 | |
| tc_770e6926 | get_completed_results | 0ms | 2026-06-05T05:32:24 | |
| tc_e624a01e | open_case | 27ms | 2026-06-05T05:32:48 | |
| tc_e2cd05a2 | wait_all | 0ms | 2026-06-05T05:32:52 | |
| tc_910e4631 | run_volatility_batch | 182684ms | 2026-06-05T05:32:56 | |
| tc_f4ba122c | open_case | 13ms | 2026-06-05T05:33:15 | |
| tc_2efc9b1f | get_investigation_summary | 12ms | 2026-06-05T05:33:20 | |
| tc_292279bf | list_sources | 2ms | 2026-06-05T05:33:20 | |
| tc_ba38f396 | run_bulk_extractor | 208018ms | 2026-06-05T05:33:22 | |
| tc_a20b8052 | get_completed_results | 0ms | 2026-06-05T05:33:28 | |
| tc_64382faa | start_extraction_batch | 47ms | 2026-06-05T05:33:38 | |
| tc_e105e986 | run_chainsaw | 121ms | 2026-06-05T05:33:38 | |
| tc_24d6c313 | get_raw_output | 11051ms | 2026-06-05T05:33:46 | |
| tc_b1566b97 | get_raw_output | 264ms | 2026-06-05T05:33:47 | |
| tc_98cbbd83 | run_mft_parser | 21100ms | 2026-06-05T05:33:59 | |
| tc_e4b78d5e | get_raw_output | 10781ms | 2026-06-05T05:34:00 | |
| tc_cf8d8462 | get_raw_output | 9418ms | 2026-06-05T05:34:10 | |
| tc_60bb53c9 | run_mactime | 43611ms | 2026-06-05T05:34:21 | |
| tc_850405ed | search | 1124ms | 2026-06-05T05:34:39 | |
| tc_7192ccde | run_prefetch_parser | 69216ms | 2026-06-05T05:34:47 | |
| tc_a778c20f | get_raw_output | 8669ms | 2026-06-05T05:34:48 | |
| tc_1774c43c | get_findings | 15ms | 2026-06-05T05:34:48 | |
| tc_e5d83487 | run_shimcache_parser | 88142ms | 2026-06-05T05:35:06 | |
| tc_b3f31759 | get_raw_output | 3430ms | 2026-06-05T05:35:10 | |
| tc_71c7a9c1 | search | 438ms | 2026-06-05T05:35:10 | |
| tc_f63a625f | search | 210ms | 2026-06-05T05:35:11 | |
| tc_e9d3b3d4 | search | 19ms | 2026-06-05T05:35:11 | |
| tc_8f9b2336 | get_raw_output | 469ms | 2026-06-05T05:35:27 | |
| tc_915b6b7a | search | 596ms | 2026-06-05T05:35:28 | |
| tc_15277550 | search | 190ms | 2026-06-05T05:35:28 | |
| tc_6f214466 | search | 225ms | 2026-06-05T05:35:57 | |
| tc_ac1225c4 | search | 266ms | 2026-06-05T05:35:58 | |
| tc_a145e9d1 | search | 344ms | 2026-06-05T05:35:58 | |
| tc_5fc873b2 | run_registry_parser | 166032ms | 2026-06-05T05:36:24 | |
| tc_16b4e2e0 | get_completed_results | 0ms | 2026-06-05T05:36:29 | |
| tc_5b46d8bd | start_extraction_batch | 2ms | 2026-06-05T05:36:35 | |
| tc_2137bfd0 | run_prefetch_parser | 39924ms | 2026-06-05T05:37:15 | |
| tc_e954693f | open_case | 19ms | 2026-06-05T05:37:50 | |
| tc_3eb0e301 | get_investigation_summary | 25ms | 2026-06-05T05:37:55 | |
| tc_1d13727a | get_source_stats | 8691ms | 2026-06-05T05:38:04 | |
| tc_335070b4 | list_sources | 5ms | 2026-06-05T05:38:04 | |
| tc_3b31a4e4 | index_evtx_file | 1459ms | 2026-06-05T05:38:08 | |
| tc_64035726 | search | 238ms | 2026-06-05T05:38:08 | |
| tc_72deb117 | search | 349ms | 2026-06-05T05:38:09 | |
| tc_7aba565f | get_findings | 8ms | 2026-06-05T05:38:16 | |
| tc_4eefb7b7 | get_process_tree | 12ms | 2026-06-05T05:38:16 | |
| tc_151d7704 | list_processes_from_memory | 8ms | 2026-06-05T05:38:16 | |
| tc_dcfe78ac | search | 366ms | 2026-06-05T05:38:28 | |
| tc_f47fa73f | search | 1011ms | 2026-06-05T05:38:29 | |
| tc_4e615ac4 | search | 1531ms | 2026-06-05T05:38:31 | |
| tc_68a53417 | get_raw_output | 8453ms | 2026-06-05T05:38:36 | |
| tc_c60763a8 | search | 52ms | 2026-06-05T05:38:36 | |
| tc_88016c42 | search | 371ms | 2026-06-05T05:38:36 | |
| tc_2d52153c | get_raw_output | 839ms | 2026-06-05T05:38:47 | |
| tc_02e729b8 | get_raw_output | 718ms | 2026-06-05T05:38:48 | |
| tc_25145c13 | get_raw_output | 730ms | 2026-06-05T05:38:49 | |
| tc_f0e20320 | get_raw_output | 579ms | 2026-06-05T05:38:50 | |
| tc_865b5bd3 | get_raw_output | 675ms | 2026-06-05T05:38:50 | |
| tc_4e8a5d54 | search | 383ms | 2026-06-05T05:39:33 | |
| tc_cd880498 | search | 767ms | 2026-06-05T05:39:34 | |
| tc_7d590553 | search | 460ms | 2026-06-05T05:39:35 | |
| tc_b013dd07 | search | 171ms | 2026-06-05T05:39:38 | |
| tc_ecd009b9 | search | 279ms | 2026-06-05T05:39:39 | |
| tc_bb619f6c | get_raw_output | 2653ms | 2026-06-05T05:39:41 | |
| tc_e13c09ec | get_raw_output | 583ms | 2026-06-05T05:40:01 | |
| tc_a82293da | search | 756ms | 2026-06-05T05:40:02 | |
| tc_b0006d62 | search | 96ms | 2026-06-05T05:40:02 | |
| tc_1072ae63 | search | 39ms | 2026-06-05T05:40:36 | |
| tc_45edee69 | search | 32ms | 2026-06-05T05:40:36 | |
| tc_669e198a | get_raw_output | 431ms | 2026-06-05T05:40:36 | |
| tc_4c3255ff | search | 424ms | 2026-06-05T05:40:41 | |
| tc_6925602b | detect_timestomping | 2456ms | 2026-06-05T05:40:43 | |
| tc_4cd66745 | search | 764ms | 2026-06-05T05:40:44 | |
| tc_0f230598 | get_raw_output | 6628ms | 2026-06-05T05:41:03 | |
| tc_de9c05d9 | search | 287ms | 2026-06-05T05:41:04 | |
| tc_39359fa7 | get_raw_output | 345ms | 2026-06-05T05:41:04 | |
| tc_c97a03e1 | search | 765ms | 2026-06-05T05:41:12 | |
| tc_f2c8f9d9 | search | 86ms | 2026-06-05T05:41:12 | |
| tc_a002bcae | search | 44ms | 2026-06-05T05:41:13 | |
| tc_48592d86 | search | 41ms | 2026-06-05T05:41:13 | |
| tc_32395647 | search | 37ms | 2026-06-05T05:41:23 | |
| tc_131665ea | search | 39ms | 2026-06-05T05:41:24 | |
| tc_1b79d36a | search | 26ms | 2026-06-05T05:41:25 | |
| tc_b6c44ee4 | get_raw_output | 6615ms | 2026-06-05T05:41:32 | |
| tc_4d392a11 | submit_finding | 31ms | 2026-06-05T05:41:59 | |
| tc_99d12ba0 | submit_finding | 5ms | 2026-06-05T05:42:20 | |
| tc_d7a5b299 | submit_finding | 12ms | 2026-06-05T05:42:29 | |
| tc_4cf39139 | submit_finding | 12ms | 2026-06-05T05:42:49 | |
| tc_503c9e33 | submit_finding | 17ms | 2026-06-05T05:43:06 | |
| tc_0d2315a3 | submit_finding | 14ms | 2026-06-05T05:43:23 | |
| tc_b0a7ce30 | track_progress | 18ms | 2026-06-05T05:43:41 | |
| tc_56cdf6f9 | search | 47ms | 2026-06-05T05:43:50 | |
| tc_6cffcfa6 | search | 30ms | 2026-06-05T05:43:52 | |
| tc_fbbfe8d4 | get_raw_output | 4408ms | 2026-06-05T05:43:56 | |
| tc_e736852b | search | 23ms | 2026-06-05T05:43:56 | |
| tc_b0fec53f | list_sources | 7ms | 2026-06-05T05:44:10 | |
| tc_9ef46a45 | search | 31ms | 2026-06-05T05:44:13 | |
| tc_74bf6ffb | search | 57ms | 2026-06-05T05:44:13 | |
| tc_78ad7ba9 | get_investigation_summary | 15ms | 2026-06-05T05:44:23 | |
| tc_1c3c5597 | get_raw_output | 6767ms | 2026-06-05T05:44:49 | |
| tc_09ed32ad | get_raw_output | 6785ms | 2026-06-05T05:44:56 | |
| tc_095df2e2 | search | 83ms | 2026-06-05T05:44:56 | |
| tc_3690d201 | search | 13ms | 2026-06-05T05:44:56 | |
| tc_99e55d1e | get_raw_output | 160ms | 2026-06-05T05:45:29 | |
| tc_374d186c | get_raw_output | 276ms | 2026-06-05T05:45:30 | |
| tc_3b2c2592 | submit_finding | 17ms | 2026-06-05T05:46:13 | |
| tc_4f2eb02c | submit_finding | 15ms | 2026-06-05T05:46:19 | |
| tc_94dff4d5 | submit_finding | 13ms | 2026-06-05T05:46:25 | |
| tc_972d7ffd | submit_finding | 18ms | 2026-06-05T05:46:38 | |
| tc_6d9012f4 | submit_finding | 13ms | 2026-06-05T05:46:46 | |
| tc_47ae6495 | submit_finding | 17ms | 2026-06-05T05:46:56 | |
| tc_73a0c6ba | submit_finding | 18ms | 2026-06-05T05:47:08 | |
| tc_ddcefb37 | submit_finding | 16ms | 2026-06-05T05:47:13 | |
| tc_da821743 | submit_finding | 14ms | 2026-06-05T05:47:22 | |
| tc_dfb6cb6d | submit_finding | 13ms | 2026-06-05T05:47:38 | |
| tc_55c408bc | submit_finding | 17ms | 2026-06-05T05:47:44 | |
| tc_b47260b0 | track_progress | 15ms | 2026-06-05T05:47:58 | |
| tc_336a948c | get_investigation_summary | 18ms | 2026-06-05T05:48:33 | |
| tc_36a8f940 | open_case | 16ms | 2026-06-05T05:48:46 | |
| tc_2d3e8fdb | get_findings | 9ms | 2026-06-05T05:48:52 | |
| tc_60521f44 | get_investigation_summary | 14ms | 2026-06-05T05:48:55 | |
| tc_c133b341 | get_source_stats | 6895ms | 2026-06-05T05:49:02 | |
| tc_ea026789 | get_bookmarks | 2ms | 2026-06-05T05:49:02 | |
| tc_44c61293 | get_ioc_summary | 4944ms | 2026-06-05T05:49:07 | |
| tc_84bbbd7e | get_timeline | 507ms | 2026-06-05T05:49:28 | |
| tc_968301a3 | list_sources | 20ms | 2026-06-05T05:49:43 | |
| tc_257a39e4 | open_case | 19ms | 2026-06-05T05:51:33 | |
| tc_bcb02e15 | correlate_across_sources | 70ms | 2026-06-05T05:51:39 | |
| tc_9ed36bb6 | correlate_across_sources | 142ms | 2026-06-05T05:51:40 | |
| tc_21a3a1b5 | correlate_across_sources | 51ms | 2026-06-05T05:51:41 | |
| tc_57745e36 | find_lateral_movement_indicators._search(all) | 54ms | 2026-06-05T05:51:41 | |
| tc_0657d48d | find_lateral_movement_indicators._search(all) | 25ms | 2026-06-05T05:51:41 | |
| tc_479fb0e3 | find_lateral_movement_indicators._search(all) | 28ms | 2026-06-05T05:51:41 | |
| tc_cbb076b2 | find_lateral_movement_indicators._query(volatility.netscan) | 100ms | 2026-06-05T05:51:41 | |
| tc_e4865d97 | find_lateral_movement_indicators._search(all) | 20ms | 2026-06-05T05:51:41 | |
| tc_0fcc46ce | find_lateral_movement_indicators._search(all) | 15ms | 2026-06-05T05:51:41 | |
| tc_aa40edcc | find_lateral_movement_indicators._search(all) | 32ms | 2026-06-05T05:51:41 | |
| tc_3601b272 | find_lateral_movement_indicators | 283ms | 2026-06-05T05:51:41 | |
| tc_b62e3a12 | find_suspicious_processes._query(volatility.malfind) | 99ms | 2026-06-05T05:51:43 | |
| tc_e35d5278 | find_suspicious_processes._query(volatility.cmdline) | 79ms | 2026-06-05T05:51:43 | |
| tc_85f5bf55 | find_suspicious_processes._query(volatility.netscan) | 82ms | 2026-06-05T05:51:43 | |
| tc_fc5fcf7e | find_suspicious_processes._query(volatility.pstree) | 82ms | 2026-06-05T05:51:43 | |
| tc_cf9385e5 | find_suspicious_processes._query(volatility.psscan) | 81ms | 2026-06-05T05:51:43 | |
| tc_2532b7cf | find_suspicious_processes._query(volatility.pslist) | 72ms | 2026-06-05T05:51:43 | |
| tc_e1a47672 | find_suspicious_processes._query(volatility.dlllist) | 86ms | 2026-06-05T05:51:43 | |
| tc_b68a385a | find_suspicious_processes | 587ms | 2026-06-05T05:51:43 | |
| tc_13de3d07 | reconstruct_execution_chains._query(volatility.pstree) | 77ms | 2026-06-05T05:51:43 | |
| tc_dbd6956b | reconstruct_execution_chains._query(volatility.cmdline) | 74ms | 2026-06-05T05:51:43 | |
| tc_9e1bfaf1 | reconstruct_execution_chains._query(volatility.netscan) | 77ms | 2026-06-05T05:51:43 | |
| tc_896dc9ae | reconstruct_execution_chains._query(volatility.malfind) | 75ms | 2026-06-05T05:51:43 | |
| tc_05c54765 | reconstruct_execution_chains._query(volatility.dlllist) | 79ms | 2026-06-05T05:51:43 | |
| tc_f07c6fcb | reconstruct_execution_chains | 386ms | 2026-06-05T05:51:43 | |
| tc_e34666a6 | find_execution_evidence._query(ez.shimcache) | 80ms | 2026-06-05T05:51:44 | |
| tc_da020891 | find_execution_evidence._query(volatility.pstree) | 75ms | 2026-06-05T05:51:44 | |
| tc_5f151794 | find_execution_evidence | 157ms | 2026-06-05T05:51:44 | |
| tc_7b341fc6 | analyze_execution_timeline._query(ez.shimcache) | 91ms | 2026-06-05T05:51:47 | |
| tc_1b4bd842 | analyze_execution_timeline | 103ms | 2026-06-05T05:51:47 | |
| tc_b6488e52 | find_data_exfiltration_indicators._query(bulk.url) | 1579ms | 2026-06-05T05:51:48 | |
| tc_adf743bc | find_data_exfiltration_indicators._query(bulk.email) | 253ms | 2026-06-05T05:51:51 | |
| tc_4ff8fe5a | find_data_exfiltration_indicators._query(bulk.domain) | 1147ms | 2026-06-05T05:51:52 | |
| tc_8e4f5804 | find_data_exfiltration_indicators._query(volatility.netscan) | 97ms | 2026-06-05T05:51:54 | |
| tc_70c1572d | find_data_exfiltration_indicators._search(all) | 51ms | 2026-06-05T05:51:54 | |
| tc_c7db00ee | find_data_exfiltration_indicators | 7570ms | 2026-06-05T05:51:54 | |
| tc_36c47855 | find_file_staging._search(tsk.filelist) | 25ms | 2026-06-05T05:51:59 | |
| tc_c42db6cf | find_file_staging._search(ez.mft) | 11ms | 2026-06-05T05:51:59 | |
| tc_56e09b2b | find_file_staging._query(tsk.filelist) | 317ms | 2026-06-05T05:52:00 | |
| tc_200c1de5 | find_file_staging._query(ez.mft) | 969ms | 2026-06-05T05:52:01 | |
| tc_81451398 | find_file_staging._search(ez.mft) | 56ms | 2026-06-05T05:52:02 | |
| tc_8269ccf9 | find_file_staging._search(ez.mft) | 29ms | 2026-06-05T05:52:02 | |
| tc_fb556ecf | find_file_staging | 2929ms | 2026-06-05T05:52:02 | |
| tc_1a2eca9c | find_persistence_mechanisms._query(registry.system) | 164ms | 2026-06-05T05:52:05 | |
| tc_25927e7c | find_persistence_mechanisms._query(registry.software) | 91ms | 2026-06-05T05:52:06 | |
| tc_58bd4d79 | find_persistence_mechanisms._query(volatility.svcscan) | 79ms | 2026-06-05T05:52:06 | |
| tc_95ba02e9 | find_persistence_mechanisms._search(all) | 28ms | 2026-06-05T05:52:06 | |
| tc_1ad9a016 | find_persistence_mechanisms._search(all) | 24ms | 2026-06-05T05:52:06 | |
| tc_67a51965 | find_persistence_mechanisms._query(ez.shimcache) | 77ms | 2026-06-05T05:52:06 | |
| tc_47ae0440 | find_persistence_mechanisms._search(all) | 34ms | 2026-06-05T05:52:06 | |
| tc_813b4490 | find_persistence_mechanisms._query(tsk.filelist) | 275ms | 2026-06-05T05:52:06 | |
| tc_36ad5db5 | find_persistence_mechanisms | 865ms | 2026-06-05T05:52:06 | |
| tc_39019610 | find_defense_evasion._search(all) | 32ms | 2026-06-05T05:52:09 | |
| tc_c56d4d3e | find_defense_evasion._search(ez.mft) | 18ms | 2026-06-05T05:52:09 | |
| tc_1ec714e6 | find_defense_evasion._search(all) | 20ms | 2026-06-05T05:52:09 | |
| tc_41eb707c | find_defense_evasion._search(all) | 13ms | 2026-06-05T05:52:09 | |
| tc_d6cfd13f | find_defense_evasion._query(volatility.psscan) | 84ms | 2026-06-05T05:52:09 | |
| tc_1d12942c | find_defense_evasion._query(volatility.pslist) | 72ms | 2026-06-05T05:52:09 | |
| tc_d52daa62 | find_defense_evasion._search(all) | 21ms | 2026-06-05T05:52:09 | |
| tc_7bf7791c | find_defense_evasion._query(volatility.cmdline) | 73ms | 2026-06-05T05:52:10 | |
| tc_fa30b2d5 | find_defense_evasion | 339ms | 2026-06-05T05:52:10 | |
| tc_2dabe8a9 | assess_recovery._query(tsk.filelist) | 297ms | 2026-06-05T05:52:10 | |
| tc_1737a201 | assess_recovery._query(ez.shimcache) | 85ms | 2026-06-05T05:52:10 | |
| tc_be407fee | assess_recovery | 401ms | 2026-06-05T05:52:10 | |
| tc_787b7ade | open_case | 21ms | 2026-06-05T05:52:46 | |
| tc_7e6724a5 | get_investigation_summary | 21ms | 2026-06-05T05:52:52 | |
| tc_9969439d | get_findings | 7ms | 2026-06-05T05:52:58 | |
| tc_e3d81a83 | get_raw_output | 1993ms | 2026-06-05T05:53:03 | |
| tc_9e8f10a5 | get_raw_output | 1601ms | 2026-06-05T05:53:08 | |
| tc_b6d67dd1 | get_raw_output | 1557ms | 2026-06-05T05:53:09 | |
| tc_0a5facdd | get_raw_output | 1957ms | 2026-06-05T05:53:23 | |
| tc_4cdd4bfa | get_raw_output | 1525ms | 2026-06-05T05:53:24 | |
| tc_c89179bf | get_raw_output | 878ms | 2026-06-05T05:53:25 | |
| tc_0e5449f5 | get_raw_output | 1967ms | 2026-06-05T05:53:36 | |
| tc_4aa99997 | get_raw_output | 1569ms | 2026-06-05T05:53:38 | |
| tc_9eddb7b0 | get_raw_output | 1539ms | 2026-06-05T05:53:40 | |
| tc_d720c496 | get_raw_output | 1526ms | 2026-06-05T05:53:41 | |
| tc_40658c2a | search | 114ms | 2026-06-05T05:53:53 | |
| tc_731e8ea2 | search | 371ms | 2026-06-05T05:53:54 | |
| tc_87c03426 | search | 378ms | 2026-06-05T05:53:55 | |
| tc_20461ac6 | search | 31ms | 2026-06-05T05:54:10 | |
| tc_11747f47 | search | 52ms | 2026-06-05T05:54:10 | |
| tc_a51861bb | search | 34ms | 2026-06-05T05:54:11 | |
| tc_68685bbb | lookup_attack_technique | 215ms | 2026-06-05T05:54:22 | |
| tc_73269362 | lookup_attack_technique | 0ms | 2026-06-05T05:54:22 | |
| tc_e958a970 | lookup_attack_technique | 0ms | 2026-06-05T05:54:23 | |
| tc_ea485672 | get_ioc_summary | 3197ms | 2026-06-05T05:54:26 | |
| tc_51e7aeae | deduplicate_findings | 81ms | 2026-06-05T05:54:44 | |
| tc_81244d7b | deduplicate_findings | 103ms | 2026-06-05T05:54:50 | |
| tc_884cc5ec | delete_finding | 9ms | 2026-06-05T05:54:59 | |
| tc_15d253ab | delete_finding | 11ms | 2026-06-05T05:55:00 | |
| tc_1d3f0d5d | delete_finding | 10ms | 2026-06-05T05:55:00 | |
| tc_714da788 | delete_finding | 10ms | 2026-06-05T05:55:00 | |
| tc_2f71b3fa | submit_finding | 17ms | 2026-06-05T05:55:22 | |
| tc_1ae1f3b9 | submit_finding | 17ms | 2026-06-05T05:55:56 | |
| tc_d6523d33 | submit_finding | 11ms | 2026-06-05T05:56:12 | |
| tc_e5a7490f | submit_finding | 14ms | 2026-06-05T05:56:33 | |
| tc_4b4407c0 | submit_finding | 15ms | 2026-06-05T05:56:56 | |
| tc_ef97d154 | submit_finding | 18ms | 2026-06-05T05:57:16 | |
| tc_7b297bce | update_finding | 15ms | 2026-06-05T05:57:34 | |
| tc_9884b29b | update_finding | 19ms | 2026-06-05T05:57:35 | |
| tc_f1099534 | update_finding | 21ms | 2026-06-05T05:57:36 | |
| tc_7528edde | update_finding | 17ms | 2026-06-05T05:57:37 | |
| tc_9c76a86d | update_finding | 17ms | 2026-06-05T05:57:38 | |
| tc_b89bacfa | update_finding | 18ms | 2026-06-05T05:57:45 | |
| tc_09e75ebd | update_finding | 16ms | 2026-06-05T05:57:45 | |
| tc_f50f4540 | update_finding | 20ms | 2026-06-05T05:57:46 | |
| tc_a37e0d12 | update_finding | 17ms | 2026-06-05T05:57:47 | |
| tc_faaa59d0 | delete_finding | 13ms | 2026-06-05T05:57:47 | |
| tc_82c77c26 | update_finding | 18ms | 2026-06-05T05:57:55 | |
| tc_37d9a4c7 | update_finding | 6ms | 2026-06-05T05:57:56 | |
| tc_9d33e48e | update_finding | 15ms | 2026-06-05T05:57:57 | |
| tc_53443bbb | update_finding | 21ms | 2026-06-05T05:57:57 | |
| tc_2017b796 | get_findings | 8ms | 2026-06-05T05:58:02 | |
| tc_ef62d3d4 | track_progress | 15ms | 2026-06-05T05:58:32 | |
| tc_bc58a54a | get_investigation_summary | 13ms | 2026-06-05T05:58:57 | |
| tc_fd0c7abe | open_case | 18ms | 2026-06-05T05:59:14 | |
| tc_a5dada5c | get_findings | 13ms | 2026-06-05T05:59:20 | |
| tc_553924ee | get_investigation_summary | 18ms | 2026-06-05T05:59:23 | |
| tc_fd3b8e60 | list_sources | 4ms | 2026-06-05T05:59:23 | |
| tc_d1ba5f2d | get_source_stats | 2011ms | 2026-06-05T05:59:28 | |
| tc_eaa7d4c7 | get_timeline | 727ms | 2026-06-05T05:59:40 | |
| tc_09369b0b | open_case | 50ms | 2026-06-05T06:03:04 | |
| tc_8c7bb7d7 | search | 575ms | 2026-06-05T06:03:10 | |
| tc_529ac6e0 | search | 30ms | 2026-06-05T06:03:10 | |
| tc_7f0331a6 | search | 26ms | 2026-06-05T06:03:11 | |
| tc_e30d82f4 | search | 32ms | 2026-06-05T06:03:13 | |
| tc_d10cfb51 | search | 86ms | 2026-06-05T06:03:14 | |
| tc_22ca28b4 | search | 91ms | 2026-06-05T06:03:15 | |
| tc_9649c937 | search | 36ms | 2026-06-05T06:03:16 | |
| tc_ca83bf6e | search | 562ms | 2026-06-05T06:03:19 | |
| tc_f66d3668 | search | 18ms | 2026-06-05T06:03:19 | |
| tc_722531ff | search | 20ms | 2026-06-05T06:03:19 | |
| tc_79f57260 | search | 765ms | 2026-06-05T06:03:26 | |
| tc_065ecfe1 | search | 56ms | 2026-06-05T06:03:26 | |
| tc_6109872b | search | 62ms | 2026-06-05T06:03:27 | |
| tc_e1d70f44 | search | 57ms | 2026-06-05T06:03:27 | |
| tc_40d577b2 | search | 50ms | 2026-06-05T06:03:28 | |
| tc_f4d9bdd9 | search | 45ms | 2026-06-05T06:03:29 | |
| tc_d9d61096 | search | 51ms | 2026-06-05T06:03:29 | |
| tc_effa5ade | search | 48ms | 2026-06-05T06:03:30 | |
| tc_cd14dc23 | search | 51ms | 2026-06-05T06:03:32 | |
| tc_55fc67e3 | search | 46ms | 2026-06-05T06:03:32 | |
| tc_5b5fc14e | search | 30ms | 2026-06-05T06:03:39 | |
| tc_3ced7dc4 | search | 30ms | 2026-06-05T06:03:41 | |
| tc_ea9fd41a | search | 29ms | 2026-06-05T06:03:42 | |
| tc_de5f2d0d | search | 35ms | 2026-06-05T06:03:42 | |
| tc_898792c6 | search | 29ms | 2026-06-05T06:03:43 | |
| tc_a49bd5d3 | search | 17ms | 2026-06-05T06:03:43 | |
| tc_0e819901 | search | 37ms | 2026-06-05T06:03:45 | |
| tc_a5726c9d | correlate_across_sources | 53ms | 2026-06-05T06:03:46 | |
| tc_9e97919d | correlate_across_sources | 342ms | 2026-06-05T06:03:47 | |
| tc_e4a646a1 | correlate_across_sources | 24ms | 2026-06-05T06:03:47 | |
| tc_09087514 | audit_evidence_coverage | 5197ms | 2026-06-05T06:03:58 | |
| tc_15c382eb | audit_tool_coverage | 35ms | 2026-06-05T06:04:01 | |
| tc_4216eb27 | deduplicate_findings | 39ms | 2026-06-05T06:04:01 | |
| tc_c8de5a5a | check_finalize_readiness | 10ms | 2026-06-05T06:04:01 | |
| tc_8bb58ef9 | open_case | 20ms | 2026-06-05T06:04:46 | |
| tc_13d798b0 | get_findings | 14ms | 2026-06-05T06:04:50 | |
| tc_1ea55562 | get_investigation_summary | 14ms | 2026-06-05T06:04:50 | |
| tc_98428beb | get_findings | 13ms | 2026-06-05T06:04:58 | |
| tc_b4a97ef0 | search | 536ms | 2026-06-05T06:05:12 | |
| tc_058a4e08 | search | 98ms | 2026-06-05T06:05:12 | |
| tc_1784eb96 | search | 20ms | 2026-06-05T06:05:13 | |
| tc_1f6a8623 | search | 56ms | 2026-06-05T06:05:14 | |
| tc_92fbe0d1 | search | 13ms | 2026-06-05T06:05:23 | |
| tc_9ddd3604 | search | 576ms | 2026-06-05T06:05:24 | |
| tc_8c3bb1d1 | search | 98ms | 2026-06-05T06:05:25 | |
| tc_93e6b415 | search | 24ms | 2026-06-05T06:05:25 | |
| tc_2f5ddb70 | search | 44ms | 2026-06-05T06:05:32 | |
| tc_03cf80d7 | search | 30ms | 2026-06-05T06:05:33 | |
| tc_097acbcf | search | 20ms | 2026-06-05T06:05:33 | |
| tc_29d512b3 | get_raw_output | 1508ms | 2026-06-05T06:05:43 | |
| tc_5bdae54a | search | 80ms | 2026-06-05T06:05:43 | |
| tc_37a79713 | search | 22ms | 2026-06-05T06:05:43 | |
| tc_eed1072c | search | 78ms | 2026-06-05T06:06:20 | |
| tc_f7016b4b | search | 52ms | 2026-06-05T06:06:21 | |
| tc_cefaa764 | search | 26ms | 2026-06-05T06:06:21 | |
| tc_797a5cec | audit_evidence_coverage | 4934ms | 2026-06-05T06:07:19 | |
| tc_bc551b47 | audit_tool_coverage | 38ms | 2026-06-05T06:07:22 | |
| tc_ae6be72d | deduplicate_findings | 40ms | 2026-06-05T06:07:22 | |
| tc_fd21f242 | deduplicate_findings | 91ms | 2026-06-05T06:08:07 | |
| tc_849a9498 | update_finding | 19ms | 2026-06-05T06:08:31 | |
| tc_7b086d59 | update_finding | 18ms | 2026-06-05T06:08:45 | |
| tc_421a2ad3 | update_finding | 12ms | 2026-06-05T06:09:04 | |
| tc_d9e7ba5e | update_finding | 18ms | 2026-06-05T06:09:12 | |
| tc_78ddf3ab | update_finding | 16ms | 2026-06-05T06:09:13 | |
| tc_b9aff84c | update_finding | 17ms | 2026-06-05T06:09:34 | |
| tc_6bfa7f17 | update_finding | 19ms | 2026-06-05T06:10:10 | |
| tc_f504289c | update_finding | 24ms | 2026-06-05T06:10:36 | |
| tc_bb096ba6 | update_finding | 12ms | 2026-06-05T06:10:48 | |
| tc_0a2fce5e | check_finalize_readiness | 21ms | 2026-06-05T06:10:53 | |
| tc_0f2a707b | track_progress | 17ms | 2026-06-05T06:11:19 | |
| tc_25b81eda | get_investigation_summary | 13ms | 2026-06-05T06:11:49 | |
| tc_518858e0 | check_finalize_readiness | 9ms | 2026-06-05T06:11:49 | |
| tc_20fe993d | open_case | 18ms | 2026-06-05T06:12:04 | |
| tc_09a61511 | get_findings | 9ms | 2026-06-05T06:12:10 | |
| tc_1ae18b8b | get_investigation_summary | 17ms | 2026-06-05T06:12:12 | |
| tc_588e6fd3 | get_ioc_summary | 3216ms | 2026-06-05T06:12:16 | |
| tc_959fe49a | get_bookmarks | 40ms | 2026-06-05T06:12:19 | |
| tc_b0a02a67 | get_source_stats | 1608ms | 2026-06-05T06:12:20 | |
| tc_8c39a50f | submit_narrative | 16ms | 2026-06-05T06:16:31 | |
| tc_28d28226 | check_finalize_readiness | 24ms | 2026-06-05T06:16:38 | |
| tc_e2f9b713 | finalize_report | 8301ms | 2026-06-05T06:16:51 |
Each finding traces back to the specific tool calls that produced the supporting evidence.