Run/RunOnce Keys Analysis

No suspicious entries are present in the Run/RunOnce registry keys. Both entries are legitimate Windows/VirtualBox components.

---

IOC Status

DFIR Default Checks (Run/RunOnce scope)

---

Data Gaps

1. Temporal mismatch. The Run key data is timestamped 2023-09-24, approximately 4.5 months before the incident date of 2024-02-12. Run key timestamps typically reflect the last-modified time of the parent registry key, not individual value writes. If the attacker added and later removed a persistence entry, or if the image was parsed at a point where the key was already cleaned, this artifact would not capture it. The absence of malicious entries does not rule out prior persistence via Run keys.

1. No RunOnce entries present. RunOnce keys are single-execution and self-deleting — a common choice for ransomware detonation. Their absence here is expected post-execution but means we cannot confirm or deny their use.

1. Username field is empty for both records, limiting attribution to a specific user context (SYSTEM vs. interactive user).

1. VBoxTray (row 2) confirms the system is a VirtualBox virtual machine. This is contextually useful (e.g., snapshot availability, potential sandbox evasion by malware) but is not itself suspicious. [CONFIDENCE: HIGH]

1. Recommended corroborating artifacts:

• Shimcache / Amcache — to check for evidence of redpetya.exe or psexec.exe execution.
• Prefetch — for execution history of both IOCs.
• **SYSTEM registry Services key** — PsExec creates a PSEXESVC service; this is the primary persistence/execution artifact for PsExec.
• Event logs (System, Security) — Service creation events (7045), logon events (4624 type 3) for lateral movement.
• MFT / $UsnJrnl — to look for file creation/deletion of redpetya.exe on this host.
• NTFS $MFT timestamps around 2024-02-12 — for timeline of the attack.

Scheduled Tasks Analysis

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Malicious scheduled task "Enterpries backup" configured to deploy ransomware across multiple workstations via PsExec.
• Evidence: Row 4–6. Task path C:\Windows\system32\tasks\Enterpries backup, created 2024-02-06T21:49:21.961830+00:00, user_id admin, run_level HighestAvailable. Command: C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe. Arguments: -accept-eula \\Desktop-001,Desktop-002,Desktop-003,Desktop-004,Desktop-005,Desktop-006 -c -d -u admin -p letmein -realtime C:\Users\admin\Desktop\rename.exe.
• Why it matters: This is the primary attack mechanism — a scheduled task designed to use PsExec to push and execute a payload (rename.exe) across six named workstations, constituting lateral movement and ransomware deployment via scheduled task persistence. The task was created 6 days before the ransomware was discovered on 12 Feb 2024.
• Multiple additional red flags in this single task:
• Credential exposure: Plaintext credentials embedded in the arguments (-u admin -p letmein). This confirms the attacker had (or set) the password letmein for the admin account.
• Deliberate naming deception: The task name "Enterpries backup" (note: misspelled "Enterprises") is designed to blend in as a legitimate backup job — a defense evasion technique (T1036 – Masquerading).
• **-accept-eula flag**: Auto-accepts the PsExec EULA, suppressing any interactive prompt — standard for automated/malicious use.
• **-c flag**: Copies the executable (rename.exe) to the remote systems before execution, confirming the payload was staged from this server.
• **-d flag**: Non-interactive mode; PsExec does not wait for the process to terminate, enabling rapid parallel deployment.
• **-realtime flag**: Executes the payload at REALTIME process priority, which is consistent with ransomware wanting to encrypt as fast as possible before detection.
• Renamed payload: The binary is called rename.exe (at C:\Users\admin\Desktop\rename.exe), which is almost certainly the ransomware binary renamed from redpetya.exe to evade filename-based detection — another defense evasion indicator.
• Targeted hosts: Six specific workstations are named (Desktop-001 through Desktop-006), scoping the blast radius of the attack.
• Alternative explanation: None plausible. No legitimate enterprise backup would use PsExec with plaintext credentials to push an executable named rename.exe at REALTIME priority to six desktops.
• Verify: (1) Examine C:\Users\admin\Desktop\rename.exe — hash it and compare to redpetya.exe found on the other server. (2) Check all six Desktop machines for compromise. (3) Determine if the admin account password is/was actually letmein. (4) Check event logs for Task Scheduler event IDs 106/140/200/201 to determine if/when this task actually executed. (5) Examine PsExec binary at C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe for version/hash.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Attacker operated from a user-space location with privileged access, not a standard admin workflow.
• Evidence: Row 4. Task created under user_id admin (not a well-known SID or domain admin format), with HighestAvailable run_level. PsExec path is C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe, payload at C:\Users\admin\Desktop\rename.exe.
• Why it matters: The attacker had access to the admin user profile and was operating from the Downloads folder (typical of a web download or lateral-movement drop point) and Desktop (staging area). The use of a local admin account (not BRANCHOFFICE\Administrator) may indicate a compromised local account or a deliberately created one.
• Alternative explanation: An actual administrator could have downloaded Sysinternals legitimately, but the context of the task eliminates this.
• Verify: Check user account creation/modification logs for the admin account. Review browser history and download logs for how PsExec was obtained. Check if admin differs from BRANCHOFFICE\Administrator (row 1).

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Npcap presence may indicate network sniffing/reconnaissance tooling.
• Evidence: Row 14–16. Task npcapwatchdog, command C:\Program Files\Npcap\CheckStatus.bat, user_id S-1-5-18 (SYSTEM).
• Why it matters: Npcap is the packet capture library used by Wireshark and Nmap. While it has legitimate uses, its presence on a server that was subsequently hit by ransomware may indicate the attacker installed network sniffing or scanning tools for reconnaissance (T1046 – Network Service Discovery) prior to deploying the ransomware.
• Alternative explanation: Npcap could have been installed by IT staff for legitimate network diagnostics or monitoring.
• Verify: Check Npcap installation timestamp and whether Wireshark/Nmap binaries are present. Correlate with software installation logs and admin activity records.

---

IOC Status

---

Data Gaps

• Task execution history is absent. Scheduled task definitions show what was configured, but not whether/when tasks actually ran. Task Scheduler operational logs (Microsoft-Windows-TaskScheduler/Operational) with Event IDs 106 (registered), 140 (updated), 200 (action started), 201 (action completed) are needed to determine execution times.
• No trigger details visible. The CSV does not include trigger type, start boundary, repetition interval, or enabled/disabled status. We cannot determine if the "Enterpries backup" task was set for one-time execution, recurring, or triggered by logon/event.
• Time gap between task creation and incident. The task was created on 2024-02-06; the incident was discovered on 2024-02-12. What happened in those 6 days cannot be determined from this artifact alone.
• No file hashes or file metadata. Cannot confirm rename.exe = redpetya.exe from this data alone. File system analysis (MFT, hash comparison) is required.
• Credential-access / Mimikatz-like behavior: Not Assessable from scheduled task definitions. Requires memory analysis, process execution logs, or prefetch data.
• Exfiltration: Not Assessable from this artifact. No tasks suggest data staging or exfiltration, but network logs and process execution data are needed.
• Other persistence mechanisms: Only scheduled tasks are visible here. Registry Run keys, services, WMI subscriptions, and startup folder items should also be examined.
• Additional artifacts needed: Windows Event Logs (Security, System, TaskScheduler), Prefetch files, NTFS $MFT (for rename.exe and redpetya.exe timestamps/hashes), Amcache/Shimcache, PowerShell logs, and network connection logs.

Services Artifact Analysis

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Windows Defender (WdBoot, WdFilter) demoted from Boot-start to Manual-start, and WinDefend demoted from Auto Start to Manual, shortly before the ransomware incident.
• Evidence: WdBoot changed from Boot (0) at 2023-09-25T23:03:17 (row 1725) to Manual (3) at 2024-02-06T21:31:54 (row 557). WdFilter changed from Boot (0) at 2023-09-25T23:03:25 (row 1727) to Manual (3) at 2024-02-06T21:31:57 (row 559). WinDefend changed from Auto Start (2) at 2023-12-07T18:10:57 (row 1740) to Manual (3) at 2024-02-06T21:31:53 (row 572).
• Why it matters: Disabling/demoting Defender components is a common pre-ransomware defense-evasion technique; the timing (~6 days before the Feb 12 incident) aligns with attack preparation.
• Alternative explanation: An administrator or update process could have changed these, though demoting all three Defender components simultaneously from auto/boot to manual is unusual.
• Verify: Check Security/System event logs around 2024-02-06T21:31 for Defender tamper events (Event IDs 5001, 5010, 5012) and identify what process/user made the registry changes.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Npcap driver installed shortly before the incident, indicating potential network sniffing capability.
• Evidence: npcap service, imagepath \SystemRoot\system32\DRIVERS\npcap.sys, start type System (1), timestamp 2024-02-05T23:42:42 (row 305). This driver does not appear in the baseline OS service set from 2023-09-24.
• Why it matters: Npcap is the packet capture driver used by tools like Wireshark and Nmap. Its installation on a Domain Controller ~6 days before ransomware deployment may indicate reconnaissance or credential sniffing.
• Alternative explanation: An administrator may have installed Wireshark/Nmap for legitimate troubleshooting.
• Verify: Check software installation logs, Prefetch for Wireshark/Nmap/tcpdump, and who installed the npcap driver around 2024-02-05T23:42.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] RemoteRegistry service set to Auto Start, which is atypical for hardened servers and facilitates remote access to the registry.
• Evidence: RemoteRegistry service, start type Auto Start (2), timestamp 2023-09-24T14:57:31 (row 375).
• Why it matters: RemoteRegistry is often exploited during lateral movement for remote configuration changes; it is typically disabled on hardened DCs.
• Alternative explanation: This may be the default or an intentional organizational policy setting.
• Verify: Confirm if RemoteRegistry Auto Start is the organization's baseline and check for remote registry access in Security logs.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] WinRM service set to Auto Start, enabling remote management—a potential lateral movement vector.
• Evidence: WinRM service, start type Auto Start (2), timestamp 2023-09-24T14:57:31 (row 579).
• Why it matters: WinRM provides PowerShell Remoting capability which attackers use for lateral movement on Domain Controllers.
• Alternative explanation: WinRM Auto Start is common in managed enterprise environments for legitimate administration.
• Verify: Review WinRM connection logs (Microsoft-Windows-WinRM/Operational) for suspicious remote sessions around the incident timeframe.

IOC Status

Data Gaps

• PsExec service likely cleaned up. PsExec creates a transient service (PSEXESVC) that is deleted after use. The services registry artifact would only capture it if the registry hive was imaged while the service existed or if cleanup failed. System event logs (Event ID 7045) are needed to detect service creation/deletion events.
• No service account information. The data lacks the ObjectName/ServiceAccount field, so we cannot determine if any service runs under a suspicious or compromised account.
• Data ends 2024-02-07, incident is 2024-02-12. The artifact's time range ends ~5 days before the ransomware discovery. Any services created between Feb 7–12 (including a potential ransomware deployment service) are not captured.
• No service named for redpetya.exe, but Petya-family ransomware may overwrite the MBR directly without registering a persistent service, so this artifact type may not capture the execution mechanism.
• Recommended additional artifacts: System event log (service install events 7045/7036), Prefetch files, NTFS MFT timeline, Amcache/ShimCache for evidence of redpetya.exe and psexec execution, and SAM/Security logs for account activity.

WMI Persistence Analysis

No suspicious findings can be identified from this artifact — the dataset contains zero records.

---

IOC Status

---

Data Gaps

Recommended follow-up:

1. Verify WMI repository integrity — Check whether C:\Windows\System32\wbem\Repository\ files exist on the disk image and whether they are intact or corrupted (consistent with ransomware disk-level damage).
2. Re-parse with alternative tooling — Attempt recovery with python-cim or WMI_Forensics.py directly against the raw repository files to rule out a parsing failure.
3. Compensating artifacts — Review SYSMON Event ID 19/20/21 (WMI activity), Microsoft-Windows-WMI-Activity/Operational event log, and Autoruns output to detect WMI persistence through alternate evidence sources.
4. Assess anti-forensic activity — Cross-reference with MBR/disk analysis; if Red Petya overwrote the MBR/MFT, repository corruption would be expected and the empty result is explained by ransomware damage rather than deliberate WMI cleanup.

Shimcache Analysis Report

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] PSEXESVC.exe accessed via remote admin$ share from IP 10.44.24.9, consistent with PsExec lateral movement.
• Evidence: Row 8 — \10.44.24.9\admin$\PSEXESVC.exe, last_modified 2024-02-05T23:25:15.663250+00:00.
• Why it matters: PSEXESVC.exe is the server-side service binary deployed by PsExec when executing commands remotely. Its presence on a UNC path from 10.44.24.9 via the admin$ share directly corroborates the suspected PsExec-based lateral movement vector used to deploy the Red Petya ransomware. The timestamp (Feb 5, ~23:25 UTC) is approximately 6 days before the ransomware was discovered on Feb 12.
• Alternative explanation: Legitimate administrative use of PsExec from 10.44.24.9 is possible but unlikely given the ransomware context.
• Verify: Examine 10.44.24.9 for evidence of PsExec execution, check Windows Event Logs (Security 4624/4648, System 7045 for PSEXESVC service creation), and correlate with network logs for SMB connections from that IP around this timestamp.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Multiple executables accessed from the remote admin$ share on 10.44.24.9, indicating sustained remote access or reconnaissance over an extended period.
• Evidence: Rows 3–12 — 10 distinct binaries accessed via \10.44.24.9\admin$\, spanning from 2019-12-06 to 2024-02-05. Recent entries include:
• \10.44.24.9\admin$\PSEXESVC.exe — 2024-02-05T23:25:15 (row 8)
• \10.44.24.9\admin$\explorer.exe — 2024-01-09T22:57:19 (row 11)
• \10.44.24.9\admin$\HelpPane.exe — 2024-01-09T22:58:00 (row 10)
• \10.44.24.9\admin$\notepad.exe — 2023-11-16T12:13:19 (row 7)
• \10.44.24.9\admin$\regedit.exe — 2023-11-16T12:11:09 (row 5)
• \10.44.24.9\admin$\splwow64.exe — 2023-11-16T12:03:42 (row 6)
• \10.44.24.9\admin$\bfsvc.exe — 2023-11-16T12:03:29 (row 12)
• Why it matters: Accessing binaries like explorer.exe, regedit.exe, and notepad.exe from a remote admin$ share is abnormal. These are typically local system binaries. This pattern may indicate the attacker had persistent access to 10.44.24.9 and was staging or executing tools remotely, or the compromised server was mapping the remote share. The cluster of activity on Nov 16, 2023 suggests a distinct earlier access event.
• Alternative explanation: An unusual administrative configuration where this server maps executables from a remote share; however, accessing standard Windows binaries this way is not normal.
• Verify: Investigate 10.44.24.9 as a potential attacker staging point or compromised host. Check mapped drives, net use commands, and authentication logs between these two systems.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] PsExec.exe and PsExec64.exe downloaded to the admin user's Downloads folder as part of the full Sysinternals Suite, shortly before PSEXESVC.exe appeared on the remote share.
• Evidence: Row 120 — C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe, last_modified 2024-02-05T23:14:39.491949. Row 122 — C:\Users\admin\Downloads\SysinternalsSuite\PsExec64.exe, last_modified 2024-02-05T23:14:39.522984.
• Why it matters: PsExec was downloaded at ~23:14 UTC and PSEXESVC.exe appeared on the remote share at ~23:25 UTC — approximately 11 minutes later. This tight timeline strongly suggests PsExec was downloaded to this server and then used to push PSEXESVC.exe to 10.44.24.9 (or vice versa). Combined with the ransomware incident, this establishes the likely attack tool delivery chain.
• Alternative explanation: The entire Sysinternals Suite was downloaded (60+ tools appear with the same ~23:14 timestamp), which could be legitimate admin activity. However, the temporal proximity to PSEXESVC.exe deployment is highly suspicious.
• Verify: Check browser history, download logs, and proxy logs for the Sysinternals download source. Determine whether the admin user account was compromised.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Sysinternals Suite extracted from a ZIP file, with initial extraction starting slightly before the bulk file timestamps.
• Evidence: Row 143 — C:\Users\admin\AppData\Local\Temp\3\Temp1_SysinternalsSuite.zip\psshutdown64.exe, last_modified 2024-02-05T23:14:19.546619.
• Why it matters: This confirms the Sysinternals Suite was delivered as a ZIP archive and extracted by the admin user. The extraction timestamp (~23:14) is the earliest activity in the attack timeline on Feb 5, preceding the bulk Sysinternals file appearance and the PSEXESVC.exe deployment by ~11 minutes.
• Alternative explanation: Legitimate admin downloading diagnostic tools.
• Verify: Recover the ZIP file or its hash; check if it was downloaded from the official Microsoft site or a suspicious source.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Nmap network scanner installed on a domain controller / server, with a fresh re-installation on Feb 5, 2024.
• Evidence: Row 98 — C:\Program Files (x86)\Nmap\nmap.exe, last_modified 2022-09-01T22:36:02. Row 100 — C:\Program Files (x86)\Nmap\zenmap.exe, last_modified 2022-09-01T22:36:06. Row 115 — C:\Users\admin\Downloads\nmap-7.93-setup.exe, last_modified 2024-02-05T23:41:37.445576. Row 106 — C:\Program Files\Npcap\NPFInstall.exe, last_modified 2022-08-19T19:09:18.
• Why it matters: Nmap is a powerful network reconnaissance tool. Its re-installation on Feb 5 (the same day as PsExec activity) strongly suggests network reconnaissance was conducted as part of the attack chain — likely to identify additional targets for ransomware deployment. The server appears to be an Active Directory domain controller (DNS, ADWS, DFSR, DFS services present in rows 354, 357–359), making Nmap presence even more concerning.
• Alternative explanation: Nmap was already installed since 2022, suggesting it may have been a legitimate admin tool. The Feb 5 re-install could be a version upgrade.
• Verify: Check if Nmap was actually executed (Prefetch, event logs). Examine network traffic from this server for scanning activity on Feb 5–6.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Suspicious executables on the admin user's Desktop with anomalous old timestamps.
• Evidence: Row 87 — C:\Users\admin\Desktop\rename.exe, last_modified 2016-03-24T00:00:00. Row 88 — C:\Users\admin\Desktop\dir.exe, last_modified 2016-04-01T00:00:00.
• Why it matters: rename.exe and dir.exe are not standard standalone Windows executables (the built-in rename and dir are internal cmd.exe commands, not separate EXEs). Custom executables with these names on the Desktop may indicate renamed malicious tools or attacker utilities. The 2016 compile/modified timestamps with exact midnight values are also suspicious and may indicate timestomping or custom-compiled tools.
• Alternative explanation: These could be legitimate custom utilities or batch-to-exe conversions created by an administrator.
• Verify: Recover these binaries and analyze them (hash, PE metadata, VirusTotal). Check if they are related to the ransomware deployment.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Credential-access and reconnaissance tools from SysinternalsSuite present in shimcache on Feb 5.
• Evidence: Multiple tools with dual-use potential appeared at 2024-02-05T23:14:*:
• procdump.exe / procdump64.exe (rows 62, 70) — commonly used for LSASS memory dumping
• PsLoggedon.exe / PsLoggedon64.exe (rows 46, 49) — enumerates logged-on users
• logonsessions.exe / logonsessions64.exe (rows 20, 21) — lists active logon sessions
• PsInfo.exe / PsInfo64.exe (rows 48, 53) — system enumeration
• ADExplorer.exe / ADExplorer64.exe (rows 138, 139) — Active Directory browsing
• ADInsight.exe / ADInsight64.exe (rows 125, 126) — AD traffic monitoring
• accesschk.exe / accesschk64.exe (rows 141, 142) — permission enumeration
• Why it matters: While shimcache presence does not prove execution, these tools in combination with confirmed PsExec usage and Nmap installation on the same day create a comprehensive attack toolkit for credential theft, domain reconnaissance, and lateral movement on a domain controller.
• Alternative explanation: These arrived as part of the full Sysinternals Suite ZIP extraction; shimcache may have recorded them during extraction without execution.
• Verify: Check Prefetch files for execution evidence of procdump, logonsessions, ADExplorer. Check for LSASS dump files.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Certutil.exe present in shimcache — potential dual-use for file download or decoding.
• Evidence: Row 107 — C:\Windows\SysWOW64\certutil.exe, 2023-07-07T21:21:32. Row 108 — C:\Windows\SYSTEM32\certutil.exe, 2023-07-07T21:21:32.
• Why it matters: Certutil is commonly abused to download payloads or decode Base64-encoded files. The timestamp predates the attack but should be checked.
• Alternative explanation: Certutil is a standard Windows binary; the timestamp aligns with a general OS activity period.
• Verify: Check command-line logging for certutil invocations with -urlcache or -decode flags.

IOC Status

Data Gaps

1. No evidence of redpetya.exe execution. Shimcache is written to the registry on shutdown/reboot. If the ransomware was deployed after the last clean shutdown (and the ransomware-induced reboot corrupted or did not properly flush the cache), the execution would not appear here. Prefetch, MFT, USN Journal, and NTFS $I30 entries are needed to confirm redpetya.exe presence and execution on this host.

1. Shimcache does not prove execution. Entries indicate the OS "observed" these files (e.g., during directory listing, file copy, or execution). Prefetch, Amcache, or event logs are required to confirm actual execution of PsExec, Nmap, procdump, or any other tool.

1. No command-line arguments available. Shimcache does not record command-line parameters. This is CRITICAL for determining what PsExec was used for (e.g., psexec \\target -c redpetya.exe). Process creation logs (Sysmon Event ID 1, Security Event ID 4688) are essential.

1. Timeline gap between Feb 7 and Feb 12. The most recent shimcache entry is 2024-02-07T10:22:21 (Edge update, row 16). The ransomware was discovered Feb 12. Any activity between Feb 7–12 is not captured in this artifact, which is the most CRITICAL window. This gap likely means the system was not cleanly shut down between Feb 7 and the ransomware incident, or the ransomware prevented a proper cache flush.

1. No user attribution. Shimcache does not record which user account executed a binary. The admin and Administrator user profiles are both active on this system. Authentication logs are needed to determine if the admin account was compromised or if a different account was used.

1. Source IP 10.44.24.9 not fully characterized. The remote share paths confirm network communication with this IP, but we cannot determine from shimcache alone whether this IP is the attacker's origin, a pivot host, or the victim server itself. Network logs and investigation of that host are required.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] PsExec present on the system under two separate user profiles, confirming lateral movement tool availability.
• Evidence: c:\users\admin\downloads\sysinternalssuite\psexec.exe (row 71, mtime_regf 2024-02-06T22:14:12.373672), c:\users\admin\downloads\sysinternalssuite\psexec64.exe (row 73, mtime_regf 2024-02-06T22:14:14.995445), and c:\users\administrator\downloads\sysinternalssuite\psexec64.exe (row 72, mtime_regf 2024-02-07T21:00:11.248564). Product name: "sysinternals psexec", version 2.43.
• Why it matters: PsExec is the suspected delivery mechanism for the Red Petya ransomware; its presence on this Domain Controller under two accounts ("admin" and "administrator") indicates it was available for remote code execution/lateral movement.
• Alternative explanation: Legitimate Sysinternals Suite usage by administrators. However, the timing (Feb 6–7, days before the Feb 12 ransomware incident) is highly suspicious.
• Verify: Check Windows Event Logs (System log for PSEXESVC service creation events, Event ID 7045), and examine network connections from this host to other servers around 2024-02-06 22:14 UTC.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious unknown binaries on the "admin" user desktop with no publisher, version, or product metadata.
• Evidence: c:\users\admin\desktop\dir.exe (row 13, mtime_regf 2024-02-07T21:00:10.342958, size 0.77 MB, publisher/version/product all blank) and c:\users\admin\desktop\rename.exe (row 80, mtime_regf 2024-02-07T21:00:10.562542, size 0.22 MB, publisher/version/product all blank).
• Why it matters: Binaries named after common Windows commands (dir, rename) but placed on a user's desktop as standalone executables with no publisher or metadata is a classic indicator of renamed/custom malicious tools or utilities used during an attack. These could be the ransomware payload itself, credential harvesters, or file enumeration/encryption tools used in preparation for or execution of the Red Petya attack.
• Alternative explanation: Custom admin scripts compiled into executables. The lack of any metadata makes this unlikely for legitimate software.
• Verify: Immediately hash these files (SHA256) and submit to VirusTotal/sandbox. Compare hashes with the known redpetya.exe binary found on the other server. Examine prefetch, $MFT, and USN journal for execution evidence and original filenames.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Network reconnaissance tooling (Nmap suite) installed on the server shortly before the ransomware incident.
• Evidence: Nmap 7.93 installer at c:\users\admin\downloads\nmap-7.93-setup.exe (row 62, mtime_regf 2024-02-07T21:00:11.233940); installed binaries: c:\program files (x86)\nmap\nmap.exe (row 63, 2024-02-06T21:01:08.501123), c:\program files (x86)\nmap\ncat.exe (row 59, 2024-02-06T21:01:08.309662), c:\program files (x86)\nmap\nping.exe (row 69, 2024-02-06T21:01:08.547724), c:\program files (x86)\nmap\zenmap.exe (row 129, 2024-02-06T20:14:15.370394), plus Npcap driver (npcap.sys, row 67).
• Why it matters: Nmap/Ncat on a Domain Controller is a strong indicator of network reconnaissance and potential pivoting during an attack. Ncat in particular provides arbitrary network connections (reverse shells, data exfiltration). Installation on 2024-02-06, six days before the ransomware detonation, suggests active attack staging.
• Alternative explanation: Legitimate network troubleshooting by admins. However, installing a full Nmap suite on a production DC is atypical.
• Verify: Check for Nmap scan output files on disk, review firewall/IDS logs for scanning activity from this host around Feb 6, and check Ncat usage in command-line history or process execution logs.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Activity concentrated under a non-default "admin" account on a Domain Controller, appearing for the first time around the attack timeframe.
• Evidence: The "administrator" profile has entries dating back to 2023-09-24 (system build). The "admin" profile only appears starting 2024-02-06–2024-02-07 (rows 13, 62, 71, 73, 80, and multiple Start Menu .lnk entries like rows 544, 550, 554, 555, 563, 576, 577, 582, 590, 609, 610). All tool installations (PsExec, Nmap, dir.exe, rename.exe) are under this account.
• Why it matters: This may represent an attacker-created or attacker-compromised account used to stage the attack. All offensive tooling is under this profile.
• Alternative explanation: Could be a legitimate admin account whose profile was created when they first logged in interactively.
• Verify: Check SAM/AD for when the "admin" account was created, review Security event logs for logon events (4624/4625) for this account, and determine whether this is an authorized account.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Sysinternals Autologon tool present, potentially indicating persistence setup.
• Evidence: c:\users\administrator\downloads\sysinternalssuite\autologon64.exe (row 3, mtime_regf 2024-02-07T21:00:10.951519, publisher "sysinternals", product "sysinternals autologon").
• Why it matters: Autologon stores credentials in the registry (or LSA secrets) and enables automatic logon — an attacker could use this to ensure persistent access or to ensure a reboot (e.g., after ransomware MBR overwrite) logs in automatically.
• Alternative explanation: Part of the downloaded Sysinternals Suite; mere presence doesn't confirm execution.
• Verify: Check registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon for DefaultUserName/DefaultPassword/AutoAdminLogon values. Check Prefetch for evidence of autologon64.exe execution.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] This system is a Domain Controller.
• Evidence: Active Directory administrative shortcuts present in Amcache (rows 539–543, 546, 558, 560, 564): "Active Directory Domains and Trusts", "Active Directory Users and Computers", "DHCP", "DNS", "Group Policy Management", etc.
• Why it matters: A compromised DC means full domain compromise — the attacker had access to the most CRITICAL server in the environment, enabling credential theft, GPO manipulation, and mass lateral movement (consistent with PsExec + ransomware deployment).
• Alternative explanation: N/A — this is contextual rather than suspicious.
• Verify: Review NTDS.dit for evidence of DCSync/extraction, and check for GPO modifications around the attack timeframe.

---

IOC Status

Default DFIR Checks

---

Data Gaps

1. No SHA256 hashes in the projected data. Amcache typically stores file hashes — the column was not included in the projection. This prevents direct comparison of dir.exe, rename.exe, or any other binary against the known redpetya.exe hash. This is the single most CRITICAL gap for this investigation.

1. No compile timestamps. Amcache often records PE compile times (link_date), which would help identify suspicious binaries (e.g., recently compiled dir.exe/rename.exe). Not present in projected columns.

1. Amcache time range ends 2024-02-09 — three days before the Feb 12 discovery. Any binaries first seen between Feb 9–12 (including redpetya.exe itself if executed then) would not appear. This is a significant gap that may explain why the ransomware binary is not observed.

1. Execution confirmation is limited. Amcache records file inventory/first-seen, not direct execution proof. Prefetch, ShimCache, SRUM, and Windows Event Logs are needed to confirm actual execution of PsExec, dir.exe, rename.exe, Nmap, and Ncat.

1. No PSEXESVC.exe entry. When PsExec is used to execute on a remote machine, it deploys PSEXESVC.exe to the target. Its absence here may mean this server was the source of PsExec commands rather than the target — or it was cleaned up, or fell outside the Amcache time window.

1. Recommended additional artifacts: Prefetch files, $MFT/USN Journal (for file creation timestamps of dir.exe/rename.exe/redpetya.exe), Windows Security & System Event Logs (logon events for "admin" account, service creation for PSEXESVC), ShimCache, SRUM, and registry hives (for Autologon persistence and any Run key modifications).

BAM/DAM Artifact Analysis

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] PsExec executed from user Downloads folder — both 32-bit and 64-bit variants — in the hours before ransomware discovery.
• Evidence: PsExec64.exe at 2024-02-06T22:14:12.975912 (row 13, path \Users\admin\Downloads\SysinternalsSuite\PsExec64.exe); PsExec.exe at 2024-02-09T22:55:44.556122 (row 23, path \Users\admin\Downloads\SysinternalsSuite\PsExec.exe). The 32-bit execution on Feb 9 at 22:55 is the last recorded BAM entry before the ransomware was discovered on Feb 12.
• Why it matters: PsExec is a known lateral-movement tool frequently used to deploy ransomware (including Petya variants) to remote hosts. Execution from a user's Downloads folder under the admin account is consistent with an attacker staging tools. The Feb 9 execution is temporally the closest activity to the ransomware event.
• Alternative explanation: A legitimate administrator may have downloaded Sysinternals for troubleshooting. However, two variants being used across separate days, combined with a ransomware event days later, makes this highly suspicious.
• Verify: Examine Prefetch for PsExec/PsExec64, check SYSTEM event logs for the PsExec service (PSEXESVC) installation on this and remote hosts, and review network connections around these timestamps.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Nmap network scanner downloaded, installed, and executed — consistent with pre-attack reconnaissance.
• Evidence: nmap-7.93-setup.exe at 2024-02-05T23:43:02.682171 (row 15, path \Users\admin\Downloads\); NPFInstall.exe (Npcap packet capture driver) at 2024-02-05T23:42:44.420574 (row 16); zenmap.exe (Nmap GUI) at 2024-02-08T19:06:34.806301 (row 17).
• Why it matters: Installing a network scanner on a server is a strong indicator of network reconnaissance, typically preceding lateral movement. The timeline fits: recon (Feb 5) → PsExec lateral movement (Feb 6, Feb 9) → ransomware (discovered Feb 12).
• Alternative explanation: Legitimate network troubleshooting by an admin. However, installing Nmap on a production server (rather than a workstation) is unusual.
• Verify: Check browser history/Edge download records for the Nmap installer source URL. Review any Nmap scan output files on disk. Correlate with network logs for port-scanning activity originating from this host.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] cmd.exe, conhost.exe, rundll32.exe, and mmc.exe cluster on Feb 9 — final hours of recorded activity before ransomware.
• Evidence: cmd.exe at 2024-02-09T22:53:10 (row 12); conhost.exe at 2024-02-09T22:54:36 (row 29); mmc.exe at 2024-02-09T22:54:29 (row 7); rundll32.exe at 2024-02-09T20:59:30 (row 18, deduplicated from 5 records indicating repeated execution); PsExec.exe at 2024-02-09T22:55:44 (row 23). All within the admin user context.
• Why it matters: This burst of command-line and administrative tool activity immediately preceding the final PsExec execution suggests active hands-on-keyboard operations. rundll32.exe with 5 deduplicated entries may indicate DLL-based payload execution. conhost.exe supports cmd.exe/PsExec console sessions.
• Alternative explanation: Routine admin console work. The rundll32.exe repeated execution is the most concerning element.
• Verify: Check Prefetch for rundll32.exe to identify which DLLs were loaded. Review command-line auditing (Security Event 4688) and PowerShell logs for this timeframe.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] mstsc.exe (Remote Desktop Client) executed on Feb 8 — potential lateral movement via RDP.
• Evidence: mstsc.exe at 2024-02-08T19:03:33.683090 (row 28).
• Why it matters: RDP client execution from a compromised server indicates the attacker may have used this host as a pivot point to access other systems, in addition to PsExec-based lateral movement.
• Alternative explanation: Legitimate admin RDP session.
• Verify: Check RDP bitmap cache, Recent Connections in NTUSER.DAT\Software\Microsoft\Terminal Server Client, and network logs for outbound RDP (3389) connections.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Rapid system diagnostic tool usage on Feb 6 — possible situational awareness gathering.
• Evidence: msinfo32.exe at 2024-02-06T22:22:49 (row 24); msconfig.exe at 2024-02-06T22:23:04 (row 25); Taskmgr.exe at 2024-02-06T22:23:44 (row 26); notepad.exe at 2024-02-06T21:35:29 (row 20). All within ~1 hour, same session as the first PsExec64 execution (22:14).
• Why it matters: Running system info, config, and task manager in rapid succession is consistent with an attacker performing host reconnaissance before or after deploying tools. Notepad may have been used to view configuration files or credentials.
• Alternative explanation: Normal admin troubleshooting.
• Verify: Review Prefetch for these tools and correlate with any files opened (RecentDocs, JumpLists).

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] No BAM activity recorded between Feb 9 22:55 and the ransomware discovery on Feb 12.
• Evidence: Last BAM timestamp is 2024-02-09T22:55:44 (row 23, PsExec.exe). Ransomware discovered Feb 12.
• Why it matters: A ~2.5 day gap may indicate the ransomware was deployed shortly after the last PsExec execution, rendering the system non-functional (consistent with Petya-style MBR/bootloader encryption which prevents normal OS boot).
• Verify: Check MFT timestamps, $LogFile, and event logs for any activity between Feb 10–12. Examine MBR/VBR for overwrite timestamps.

---

IOC Status

---

Data Gaps

UserAssist Artifact Analysis

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] PsExec executed by "admin" user — both 32-bit and 64-bit variants within 2 seconds.
• Evidence: Row 27 — C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe, 1 execution, last run 2024-02-06T22:14:10.115000. Row 14 — C:\Users\admin\Downloads\SysinternalsSuite\PsExec64.exe, 1 execution, last run 2024-02-06T22:14:12.356998. Both under user admin.
• Why it matters: PsExec is the suspected lateral movement / ransomware deployment vector. Both architectures were tried within ~2 seconds, consistent with an operator testing which binary works, potentially to push redpetya.exe to remote hosts. This is 6 days before the ransomware incident on 2024-02-12.
• Alternative explanation: Legitimate administrator testing PsExec for systems management purposes.
• Verify: Examine Prefetch for PSEXEC.EXE/PSEXEC64.EXE, Windows Event Logs (Security 4648/4688, System 7045 for PSEXESVC), and network logs for SMB connections around 2024-02-06 22:14 UTC.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Network reconnaissance tool (Nmap/Zenmap) installed and executed by "admin" — consistent with pre-attack enumeration.
• Evidence: Row 16 — C:\Users\admin\Downloads\nmap-7.93-setup.exe (installer present, ts null). Row 19 — zenmap.exe, 2 executions, last run 2024-02-06T21:09:13. Row 41 — Zenmap GUI shortcut, 1 execution, 2024-02-05T23:43:16. Row 44 — Desktop shortcut Nmap - Zenmap GUI.lnk, 1 execution, 2024-02-06T21:09:13.
• Why it matters: Network scanning approximately 1 hour before PsExec execution on 2024-02-06 suggests target discovery/enumeration as a precursor to lateral movement. The Npcap driver was also installed (row 17–18).
• Alternative explanation: Legitimate network troubleshooting by an admin.
• Verify: Check Nmap scan logs/output files in admin's profile, Prefetch for nmap.exe/zenmap.exe, and firewall logs for port scanning activity.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Sysinternals PsShutdown64 executed directly from a temp-extracted ZIP — suggests tooling was deployed ad-hoc, not from a managed installation.
• Evidence: Row 12 — C:\Users\admin\AppData\Local\Temp\3\Temp1_SysinternalsSuite.zip\psshutdown64.exe, 1 execution, 2024-02-05T23:14:20. This is the earliest Sysinternals tool execution by the admin user.
• Why it matters: PsShutdown can remotely reboot/shutdown systems. Execution from a temp-extracted ZIP indicates the suite was first used without formal extraction, then later extracted to Downloads\SysinternalsSuite\. This tool can facilitate ransomware deployment by forcing reboots post-infection (relevant to Petya which requires a reboot to activate its MBR payload).
• Alternative explanation: Admin testing remote shutdown capability for maintenance.
• Verify: Check if PsShutdown was run with remote target arguments via command-line auditing (Event ID 4688) or Prefetch.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Concentrated burst of attack-chain activity by "admin" account between 2024-02-05 and 2024-02-09.
• Evidence: The admin user account shows no activity before 2024-02-05T23:03:51 (row 2), then intense activity through 2024-02-09T22:53:05 (row 13/40). Timeline:
• Feb 5 ~23:00: First activity — Snipping Tool, Paint, PsShutdown from ZIP, Edge browser, Zenmap shortcut.
• Feb 6 ~20:00–22:32: Control Panel, DNS console (row 43), Zenmap (row 19), Group Policy Management (row 45), Windows Security (row 25), Notepad, PsExec.exe + PsExec64.exe (rows 27, 14), msinfo32, msconfig, Settings.
• Feb 7 ~16:50: WordPad (row 10).
• Feb 8 ~19:02: Remote Desktop Connection (row 33/50).
• Feb 9 ~19:48–22:53: AD Users & Computers (row 6), File Explorer, Task Scheduler (row 47, 3 executions), cmd.exe (row 13, 7 executions — the last recorded activity).
• Why it matters: This pattern shows a multi-day intrusion lifecycle: reconnaissance (Nmap, DNS, AD), tool staging (Sysinternals ZIP extraction), lateral movement tool execution (PsExec), remote access (RDP), and persistence/scheduling (Task Scheduler) — all leading up to the ransomware detonation on Feb 12.
• Alternative explanation: A new admin account performing legitimate server administration. However, the combination and sequence of tools is highly suspicious.
• Verify: Validate when the admin account was created (SAM/AD logs). Determine if this is a known/authorized account vs. an attacker-created account.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Task Scheduler accessed 3 times on 2024-02-09 — potential persistence mechanism.
• Evidence: Row 47 — Task Scheduler.lnk, 3 executions, last run 2024-02-09T22:52:31. Row 26 — Microsoft.AutoGenerated.{C1C6F8AC-40A3-0F5C-146F-65A9DC70BBB4}, 3 executions, last run 2024-02-09T22:52:31 (same timestamp, likely the same application launch).
• Why it matters: Task Scheduler is commonly used by ransomware operators to create scheduled tasks for payload execution or persistence. Three accesses less than 3 days before the ransomware detonation on Feb 12 is concerning. Petya variants have historically used scheduled tasks.
• Alternative explanation: Routine administrative task scheduling.
• Verify: Examine C:\Windows\System32\Tasks\ for newly created tasks, and Event IDs 4698/4699/4702 in Security logs around this timestamp.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Remote Desktop Connection launched by "admin" on 2024-02-08 — potential lateral movement.
• Evidence: Row 33 — Microsoft.Windows.RemoteDesktop, 1 execution, 2024-02-08T19:02:36. Row 50 — corresponding shortcut, same timestamp.
• Why it matters: RDP is a common lateral movement vector. Used between PsExec execution (Feb 6) and Task Scheduler activity (Feb 9), this may indicate the attacker accessed additional systems.
• Alternative explanation: Legitimate remote administration.
• Verify: Check RDP-related event logs (TerminalServices-LocalSessionManager, Security 4624 type 10), Default.rdp file for target IPs, and network flow data.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] PsExec64.exe also present in the Administrator profile — earlier staging.
• Evidence: Row 81 — C:\Users\Administrator\Downloads\SysinternalsSuite\PsExec64.exe, 0 executions, timestamp 2023-11-04T21:56:50. Other Sysinternals tools in same profile: Autologon64 (row 79), Bginfo64 (row 80), RAMMap64 (row 82) — all timestamped 2023-11-04.
• Why it matters: The Sysinternals Suite was downloaded to the Administrator account on Nov 4, 2023 — months before the attack. The run count of 0 with a non-null timestamp means it was tracked by UserAssist but the focus counter wasn't incremented (may indicate it was opened but not interactively "focused," or this is a UAC-related artifact). The presence on both accounts is notable.
• Alternative explanation: The Administrator legitimately downloaded Sysinternals for administrative tasks. The admin account may have been created later and re-downloaded/used them for the attack.
• Verify: Determine the relationship between Administrator and admin accounts. Check if the same Sysinternals ZIP was reused or separately downloaded.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] cmd.exe is the last recorded UserAssist activity before the ransomware incident — 7 executions, last at 2024-02-09 22:53:05.
• Evidence: Row 13 — cmd.exe, 7 executions, 2024-02-09T22:53:05.400000, user admin.
• Why it matters: Heavy command-line usage is the last observable GUI activity, ~2.5 days before the ransomware screen was discovered on Feb 12. Command prompt is commonly used to execute PsExec and deploy payloads.
• Alternative explanation: Routine administration.
• Verify: Command-line audit logs, PowerShell transcription logs, console host history (ConsoleHost_history.txt).

---

IOC Status

---

Data Gaps

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Sysinternals Suite downloaded and then deleted by the admin user ~6 days before the ransomware incident.
• Evidence: C:\Users\admin\Downloads\SysinternalsSuite.zip (50.6 MB), deleted 2024-02-05T23:14:49 UTC (row 2), user admin.
• Why it matters: The Sysinternals Suite contains PsExec, the suspected lateral-movement/execution tool. Downloading the full suite and then deleting the ZIP is consistent with an attacker staging tools, extracting what is needed, and cleaning up the delivery archive.
• Alternative explanation: A legitimate administrator downloaded Sysinternals for troubleshooting and cleaned up after extracting. However, the proximity to the ransomware event and the specific suspicion of PsExec use elevates this significantly.
• Verify: Check the admin user's profile for an extracted SysinternalsSuite folder or any remaining PsExec*.exe binaries; examine Prefetch for PSEXEC.EXE-*.pf; review browser history for the download URL; check ShimCache/AmCache for PsExec execution evidence.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Large archive share.zip (0.65 GB) created on the Desktop and then deleted, potentially indicating data staging/exfiltration or payload delivery.
• Evidence: C:\Users\admin\Desktop\share.zip (0.65 GB), deleted 2024-02-06T22:14:44 UTC (row 1), user admin.
• Why it matters: A 650 MB ZIP named "share" on the Desktop could represent staged data for exfiltration (collected files compressed before transfer) or a payload/toolkit archive distributed across the network. Its deletion ~5.5 days before the ransomware detonation suggests cleanup during the intrusion's operational phase.
• Alternative explanation: Routine file sharing by an administrator (e.g., compressing a network share's contents for backup or transfer).
• Verify: Examine VSS snapshots or forensic carving for the contents of share.zip; review SMB/network logs for outbound transfers of this file; check if "share" correlates with any mapped network share names; review $MFT for creation timestamp of the file.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Both deletions occur within a ~23-hour window (Feb 5–6), well before the Feb 12 ransomware detonation, suggesting a deliberate cleanup phase during an active intrusion.
• Evidence: Row 2 deleted 2024-02-05T23:14:49; Row 1 deleted 2024-02-06T22:14:44. Ransomware discovered 2024-02-12.
• Why it matters: Attackers commonly stage tools and data, then delete artifacts days before deploying ransomware to reduce forensic footprint. The gap between cleanup (Feb 5–6) and detonation (Feb 12) is consistent with a multi-day intrusion lifecycle.
• Verify: Correlate with $MFT, USN Journal, and event logs for the Feb 5–6 window to identify additional file creation, tool execution, or lateral movement activity.

---

IOC Status

---

Data Gaps

• Only 2 records spanning Feb 5–6. The Recycle Bin on this system contains no entries between Feb 7–12 (the period leading up to and including ransomware detonation). This could mean no further files were deleted to the Recycle Bin, or the Recycle Bin was partially cleared, or ransomware execution corrupted later $I files.
• No file contents or hashes. Cannot confirm whether share.zip contained exfiltrated data or SysinternalsSuite.zip was the legitimate Microsoft distribution vs. a trojanized version.
• Execution not provable from this artifact. Recycle Bin only shows download and deletion of the Sysinternals archive, not whether PsExec was actually executed. Prefetch, AmCache, ShimCache, and Windows Event Logs (Security 4688, System 7045 for PSEXESVC) are required to confirm execution.
• **No visibility into redpetya.exe lifecycle.** Need $MFT, Prefetch, AmCache, and USN Journal to determine if it was present on this host.
• **admin account context unknown.** Cannot determine from this artifact alone whether the admin account was used legitimately or was compromised. Authentication logs (Event ID 4624/4625) are needed.

Browser History Forensic Analysis

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Data exfiltration to external FTP server with directory matching internal domain naming.
• Evidence: Row 50 — 2024-02-07T16:57:31.964310 — ftp://185.239.106.67/branchoffice.example.com/ (visit_count=9, user=admin). Row 51 — 2024-02-07T16:57:05.940533 — ftp://185.239.106.67/ (visit_count=2, user=admin).
• Why it matters: An external IP hosting a directory named after an internal domain (branchoffice.example.com) with 9 visits is a strong indicator of data staging/exfiltration. This occurs on 2024-02-07, five days before ransomware detonation on 2024-02-12, consistent with a "steal-then-encrypt" double-extortion playbook.
• Alternative explanation: None plausible. Legitimate FTP servers used by an organization would typically be referenced by hostname, not bare IP, and the directory name matching an internal domain convention strongly suggests attacker infrastructure collecting stolen data.
• Verify: Check firewall/proxy logs for all traffic to 185.239.106.67. Image the admin user's profile for FTP client artifacts, cached credentials, and transferred file lists. Run threat intel lookup on this IP. Check for FTP command-line history or WinSCP/FileZilla artifacts.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Ryuk ransomware ransom note opened on the server.
• Evidence: Row 48 — 2024-02-06T20:53:29.889280 — file:///C:/Users/admin/Desktop/RyukReadMe.txt (visit_count=1, user=admin).
• Why it matters: RyukReadMe.txt is the canonical ransom note filename for Ryuk ransomware. Combined with the Red Petya ransomware noted in the investigation context, this suggests multiple ransomware families were present or tested on this server. This may indicate a multi-payload attack or an attacker testing different ransomware variants before final deployment on 2024-02-12.
• Alternative explanation: Extremely unlikely to be benign. A security researcher might store such a file for reference, but on a compromised production server this is virtually certain to be malicious.
• Verify: Recover C:\Users\admin\Desktop\RyukReadMe.txt from the disk image. Check for Ryuk IOCs (executables, registry keys, scheduled tasks). Determine if Ryuk actually executed or if only the note was staged.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Credential-bearing file accessed by attacker-controlled account prior to attack chain.
• Evidence: Row 46 — 2024-02-05T23:09:16.723713 — file:///C:/share/Clark.Nicholson/Documents/account_password.xlsx (user=admin). Row 47 — 2024-02-05T23:09:40.203115 — file:///C:/share/Clark.Nicholson/Documents/account_edit.docx (user=admin).
• Why it matters: The admin account accessed another user's (Clark.Nicholson) file explicitly named account_password.xlsx at 23:09 on Feb 5, right at the start of the attack session. This is credential harvesting from a file share — a common lateral movement enabler. The account_edit.docx file accessed 24 seconds later may contain account modification instructions or additional credentials.
• Alternative explanation: A legitimate admin might access user files for support, but the filename account_password.xlsx and the timing (immediately before tool downloads) make this highly suspicious.
• Verify: Recover both files from the disk image. Determine whose credentials were stored and whether those accounts were subsequently compromised. Check authentication logs for Clark.Nicholson's account for unauthorized use.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Network reconnaissance tool (Nmap) downloaded during the attack session.
• Evidence: Rows 12–20 — 2024-02-05T23:40:22 through 2024-02-05T23:41:31 — user admin searched "download nmap," navigated to Softonic, reached the post-download page (Download Nmap 7.93 - free - latest version), and the support/installation help page.
• Why it matters: Nmap is a network scanning tool. Downloading it to a server (not a pentester's workstation) during an active intrusion session is consistent with internal network reconnaissance to identify additional targets for lateral movement before ransomware deployment.
• Alternative explanation: Legitimate admin use is possible but unlikely given the surrounding context (same session as credential access, Sysinternals download, and suspicious file activity).
• Verify: Check for nmap.exe or Nmap installation artifacts on disk. Review Windows Firewall logs or network captures for scanning activity originating from this server. Check C:\Users\admin\Downloads\ for the installer.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Sysinternals Suite downloaded twice by two accounts — second download by attacker aligns with PsExec acquisition.
• Evidence: Row 57 — 2023-11-04T15:26:31.564228 — file:///C:/Users/Administrator/Downloads/SysinternalsSuite.zip (Administrator). Row 43 — 2024-02-05T23:13:45.314323 — file:///C:/Users/admin/Downloads/SysinternalsSuite.zip (admin), preceded by search and download at rows 8–11 starting 2024-02-05T23:13:17.
• Why it matters: PsExec is part of the Sysinternals Suite. The admin account downloaded the suite on the evening of Feb 5 — the same session where credentials were harvested and Nmap was downloaded. This is the most likely vector by which PsExec was obtained, directly supporting the investigation hypothesis. The November download by Administrator may represent legitimate admin activity; the February download by admin is part of the attack chain.
• Alternative explanation: The November download by Administrator appears routine (preceded by BBC News browsing). The February download timing and context make it suspicious.
• Verify: Check for PsExec execution artifacts (Prefetch, Event Logs for service installation PSEXESVC, named pipes). Examine both extracted Sysinternals directories.

• **[SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Suspicious archive file share.zip staged on attacker's desktop.**
• Evidence: Row 44 — 2024-02-05T23:36:07.148302 — file:///C:/Users/admin/Desktop/share.zip (user=admin).
• Why it matters: This file was accessed between the Sysinternals download (23:13) and the Nmap download (23:40) during the attack session. The name share.zip strongly suggests the contents of C:\share\ (the file share containing user documents and credentials) were compressed for exfiltration. This aligns with the FTP exfiltration observed on Feb 7.
• Alternative explanation: Could be an unrelated archive, but the name and timing are highly suggestive.
• Verify: Recover C:\Users\admin\Desktop\share.zip or its remnants from the disk image. Compare file size to the share contents. Check if this file was transferred to 185.239.106.67.

• **[SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Suspicious archive important.zip on attacker's desktop.**
• Evidence: Row 49 — 2024-02-06T20:09:32.974691 — file:///C:/Users/admin/Desktop/important.zip (user=admin).
• Why it matters: Accessed the day after the initial compromise session and 44 minutes before the Ryuk ransom note was opened. May contain additional stolen data or attack tools.
• Alternative explanation: Could be a legitimate file.
• Verify: Recover this file from disk. Check creation timestamp and contents.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Active Directory user import CSV accessed during attack — potential user enumeration.
• Evidence: Row 45 — 2024-02-07T16:50:47.014515 — file:///C:/scripts/activeDirectory_user_import.csv (visit_count=2, user=admin).
• Why it matters: This file likely contains AD usernames and possibly other attributes. Accessed on Feb 7 — the same day as FTP exfiltration activity — it may have been used for user enumeration to support lateral movement or was itself exfiltrated.
• Alternative explanation: Admin maintenance is plausible, but combined with the attack timeline this is suspicious.
• Verify: Review contents of the CSV. Check if it was transferred to the external FTP server.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Date/time settings accessed during attack window — possible anti-forensics or timestamp manipulation.
• Evidence: Row 41 — 2024-02-06T22:32:48.615803 — ms-settings:dateandtime (user=admin).
• Why it matters: Attackers sometimes modify system time to confuse forensic timelines or manipulate certificate validation. This was accessed during the active compromise window.
• Alternative explanation: Legitimate timezone correction or time sync check by an admin.
• Verify: Check Windows Event Logs (Event ID 4616 — system time change) around this timestamp. Compare BIOS time to network time at acquisition.

• **[SEVERITY: LOW] [CONFIDENCE: MEDIUM] New admin account appeared suddenly with intense activity — possible attacker-created account.**
• Evidence: The Administrator account is active from 2023-11-04 through 2024-01-16. The admin account appears for the first time on 2024-02-05 and performs all suspicious activity (credential access, tool downloads, exfiltration, ransom note viewing).
• Why it matters: The admin account may have been created by the attacker to avoid using the built-in Administrator account. Its sudden appearance coinciding with the start of the attack chain is notable.
• Alternative explanation: Could be a pre-existing service or secondary admin account that simply didn't generate browser history before Feb 5.
• Verify: Check SAM/AD for account creation date of admin. Review Security Event Logs for Event ID 4720 (account creation).

---

Attack Timeline Reconstruction (from browser history)

---

IOC Status

Additional IOCs Identified in This Artifact

---

Data Gaps

• No download completion records: Browser history shows navigation to download pages but does not confirm successful downloads. Need Prefetch, file system timeline, or Downloads folder analysis to confirm Nmap and Sysinternals installation.
• No browser history from Feb 8–12: There is a complete gap between the last record (Feb 7) and ransomware detonation (Feb 12). This could indicate the attacker stopped using the browser, used other tools, or browser data was partially destroyed.
• No typed URLs vs. clicked URLs distinction: Cannot determine if the FTP URL was typed manually or accessed via a bookmark/script.
• No data on actual PsExec execution: Browser history can only show the Sysinternals download. Need Windows Event Logs (Event ID 7045 for PSEXESVC service installation), Prefetch files, and NTFS artifacts to confirm PsExec usage.
• No data on redpetya.exe: Browser history is not the expected artifact for this IOC. Need filesystem, Prefetch, Amcache, or ShimCache analysis.
• FTP transfer contents unknown: Browser history records FTP URL visits but not what was uploaded/downloaded. FTP client logs, packet captures, or proxy logs are needed.
• Missing artifacts needed: Prefetch files, Windows Event Logs (Security, System, PowerShell), MFT timeline, Registry (SAM, SYSTEM), Amcache/ShimCache, and network logs are CRITICAL to corroborate these findings.

Browser Downloads Analysis

Findings

• **[SEVERITY: HIGH] [CONFIDENCE: HIGH] Sysinternals Suite downloaded by the admin user ~7 days before the ransomware incident, consistent with attacker staging PsExec for lateral movement.**
• Evidence: Row 1 — 2024-02-05T23:13:32 UTC, SysinternalsSuite.zip downloaded to C:\Users\admin\Downloads\, state complete. PsExec is included in the Sysinternals Suite.
• Why it matters: This download is the most probable delivery vector for PsExec onto this server. PsExec is a suspected lateral-movement tool in this incident, and it was downloaded just ~6 days before the ransomware detonation on 12 Feb 2024.
• Alternative explanation: Legitimate sysadmin troubleshooting, though the timing and subsequent ransomware event make this unlikely to be benign.
• Verify: Examine filesystem artifacts for extraction of PsExec.exe or PsExec64.exe from the ZIP; check Prefetch, ShimCache, and AmCache for PsExec execution evidence; correlate with event logs for remote service creation (Event ID 7045).

• **[SEVERITY: HIGH] [CONFIDENCE: HIGH] Nmap network scanner downloaded by the admin user ~28 minutes after the Sysinternals download, indicating active reconnaissance.**
• Evidence: Row 2 — 2024-02-05T23:41:28 UTC, nmap-7.93-setup.exe (27.8 MB) downloaded from gsf-fl.softonic.com (Softonic CDN) to C:\Users\admin\Downloads\, state complete.
• Why it matters: Nmap is a network scanning/reconnaissance tool. Downloaded the same session as Sysinternals, this strongly suggests an attacker enumerating the network to identify targets for lateral movement and ransomware deployment. Downloading from Softonic rather than the official nmap.org site may also indicate urgency or an attempt to avoid direct attribution, and introduces supply-chain risk (trojanized binary).
• Alternative explanation: Legitimate admin network troubleshooting, though downloading from a third-party redistributor (Softonic) rather than nmap.org is atypical for an enterprise administrator.
• Verify: Check Prefetch/AmCache for nmap.exe execution; review firewall/IDS logs for scanning activity originating from this host on or after 2024-02-05; verify the hash of nmap-7.93-setup.exe against the official Nmap release to rule out a trojanized binary.

• **[SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Earlier Sysinternals download by the Administrator account ~3 months prior may indicate initial compromise or earlier access.**
• Evidence: Rows 3–4 — 2023-11-04T15:25:24 UTC and 15:25:50 UTC, SysinternalsSuite.zip downloaded twice (one completed, one cancelled) under C:\Users\Administrator\Downloads\.
• Why it matters: If the same threat actor had access to the Administrator account in November 2023, this could represent an earlier stage of compromise or persistent access. The duplicate/cancelled download may indicate an interrupted session.
• Alternative explanation: Routine admin activity in November 2023 unrelated to the February 2024 incident. Sysinternals is a common legitimate admin toolkit.
• Verify: Correlate November 2023 logon events for the Administrator account (source IP, logon type); check whether the admin and Administrator accounts are used by the same person; examine timeline for November 2023 suspicious activity.

• **[SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Two distinct user accounts (admin and Administrator) used on what appears to be a server, suggesting possible unauthorized account usage.**
• Evidence: Rows 1–2 use admin; Rows 3–4 use Administrator. Both profiles have browser download histories on a server that experienced a ransomware attack.
• Why it matters: Interactive browsing on a server under two accounts may indicate an attacker using a compromised or newly created admin account alongside the built-in Administrator.
• Alternative explanation: Both accounts may be legitimately used by operations staff.
• Verify: Check SAM/AD for the admin account creation date and properties; review logon events for both accounts around 2024-02-05 for source IPs and logon types.

---

IOC Status

---

Data Gaps

• Only 4 download records across ~3 months. Browser history may have been cleared between November 2023 and February 2024. The gap from 2023-11-04 to 2024-02-05 is notable — investigate whether download history was deleted.
• **No download record for redpetya.exe.** The ransomware binary was likely delivered via a non-browser vector (PsExec remote copy, SMB share, or other tool). File system timeline, Prefetch, and MFT analysis are needed.
• No execution evidence in this artifact. Browser downloads show acquisition, not execution. Prefetch, ShimCache, AmCache, and Windows Event Logs (especially Event ID 7045 for PsExec service installation) are essential to confirm tool usage.
• No source IP / logon context. Cannot determine whether these downloads were from a local console session or an RDP session. RDP/logon event logs are needed to identify the attacker's origin.
• Cannot assess: credential access/Mimikatz, persistence mechanisms, privilege escalation, or exfiltration from this artifact alone. These require process execution, registry, scheduled task, and network flow artifacts.
• Nmap binary integrity unknown. The download came from a third-party CDN (Softonic), not the official source. The file hash should be compared against the known-good Nmap 7.93 release hash to rule out a trojanized installer.

Analysis: Activities Cache

The Activities Cache artifact contains zero records. The CSV attachment is empty with no columns or data present.

---

IOC Status

• redpetya.exe → Not Assessable. The Activities Cache contains no records to evaluate.
• PsExec → Not Assessable. The Activities Cache contains no records to evaluate.

---

Data Gaps

• Empty artifact — potential evidence of tampering. The Activities Cache (ActivitiesCache.db) is expected to contain user activity records on any actively used Windows system. A completely empty cache on a server that was operational until 12 Feb 2024 is notable. Possible explanations:
• Deliberate clearing: Ransomware operators (or the Red Petya payload itself) may have wiped user activity artifacts as part of anti-forensics. This should be correlated with other signs of log/artifact destruction (e.g., cleared Event Logs, deleted prefetch files, USN journal gaps).
• Server role: If this is a headless server with minimal interactive logon, the Activities Cache may legitimately have limited or no entries, especially if the Windows Timeline feature was disabled by policy.
• Database destruction: The ransomware's disk-level encryption (consistent with Petya-family behavior, which overwrites the MBR/MFT) may have corrupted or destroyed the ActivitiesCache.db file, rendering it unrecoverable.

• Cannot assess any DFIR checks from this artifact alone: privilege escalation, credential access, malicious execution, persistence, lateral movement, and exfiltration are all Not Assessable here.

• Recommended follow-up artifacts to compensate:
• Prefetch files — to check for execution of redpetya.exe, psexec.exe, or other suspicious binaries.
• Windows Event Logs (Security, System, PowerShell) — logon events (Event ID 4624 type 3/10), service installation (Event ID 7045 for PSEXESVC), and any log-clearing events (Event ID 1102).
• NTFS artifacts ($MFT, $UsnJrnl) — file creation timestamps for redpetya.exe, evidence of dropped tools.
• Registry hives (SYSTEM, SAM, NTUSER.DAT) — service entries for PSEXESVC, persistence mechanisms, evidence of credential dumping.
• ShimCache / AmCache — independent evidence of binary execution.
• MBR / VBR analysis — Petya-family ransomware typically overwrites the Master Boot Record; raw disk examination can confirm the variant.

SRUM Network Data Analysis

Findings

No findings — the artifact contains zero records and no columns. There is no data to analyze.

IOC Status

Data Gaps

• Empty artifact. The SRUM Network Data table contains 0 records, 0 columns, and no time range. This means no per-application network usage information is available from this source.

• Possible reasons for absence:
• The SRUM database (SRUDB.dat) may not have been collected or was corrupted.
• The ransomware (Red Petya) may have destroyed or encrypted the SRUM database as part of its disk-level encryption activity (Petya variants typically overwrite the MBR and encrypt the MFT, which could render SRUM data unrecoverable).
• The SRUM database may have been intentionally cleared as an anti-forensic measure prior to or during the attack.
• The absence itself is noteworthy — on a functioning Windows 8+ system, SRUM should contain network telemetry going back up to 30–60 days. A completely empty result warrants investigation into whether the database was tampered with or destroyed. [MEDIUM CONFIDENCE]

• What cannot be determined from this artifact:
• Whether redpetya.exe or psexec.exe / PSEXESVC.exe consumed network bandwidth.
• Any lateral movement, exfiltration, or C2 communication patterns.
• Timeline of network-active applications leading up to 12 Feb 2024.
• All default DFIR checks (credential access, privilege escalation, persistence, evasion, lateral movement, exfiltration) are Not Assessable from this artifact.

• Recommended compensating artifacts:
• Windows Event Logs (Security, System, PowerShell) — look for PsExec service installation (Event ID 7045 for PSEXESVC), logon events (4624 type 3/10), and process creation (4688).
• Prefetch files — check for REDPETYA.EXE-*.pf and PSEXESVC.EXE-*.pf.
• MFT / $LogFile / $UsnJrnl — file creation timestamps for both IOCs.
• Network logs (firewall, proxy, NetFlow) — SMB (445) connections from other hosts around the time of compromise.
• SRUM Application Data / Energy Usage tables — if those were separately parsed and are non-empty, they may still contain process execution evidence even if the network table is empty.
• Raw SRUDB.dat — verify whether the file exists on disk, its size, and whether it is intact or zeroed/encrypted.

SRUM Application Resource Usage Analysis

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious unknown executable "rename.exe" run from user's Desktop shortly before ransomware incident.
• Evidence: Row 73965, timestamp 2024-02-09T22:56:00, app \Device\HarddiskVolume2\Users\admin\Desktop\rename.exe, user S-1-5-21-...-2611, foregroundcycletime 13284139184 (~13.3 billion cycles, indicating substantial interactive/CPU use). No dedup comment — single record.
• Why it matters: An unknown binary named "rename.exe" on a user's Desktop, executed ~2.5 days before ransomware discovery (Feb 12), is highly suspicious. The name is consistent with a file-encrypting/renaming payload. Given the investigation context of Red Petya ransomware, this may be the ransomware binary itself (possibly redpetya.exe renamed to rename.exe to evade detection). The significant foreground cycle time suggests it was actively running with user interaction or heavy processing.
• Alternative explanation: A legitimate renaming utility. However, placement on the Desktop and timing before the incident make this unlikely.
• Verify: Hash rename.exe from the disk image and compare against redpetya.exe hash from the other server. Submit to malware sandbox. Check MFT for creation/modification timestamps and $FILENAME entries.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Nmap network scanner downloaded, installed, and extensively used by user account -2611 shortly before the attack.
• Evidence: Row 66925 — \Users\admin\Downloads\nmap-7.93-setup.exe, foregroundcycletime 37987545588 (~38B cycles). Row 66926 — \Program Files (x86)\Nmap\zenmap.exe, foregroundcycletime 227183733421 (~227B cycles, deduplicated across 67 records). Row 66927 — \Program Files (x86)\Nmap\nmap.exe, foregroundcycletime 221269249429 (~221B cycles, deduplicated across 2 records). All first appear at 2024-02-06T00:06:00, user S-1-5-21-...-2611.
• Why it matters: Nmap is a network reconnaissance tool commonly used in the discovery/lateral-movement phase of ransomware attacks. The extremely HIGH cycle times for both nmap.exe and zenmap.exe indicate extensive network scanning. This occurred ~6 days before the ransomware incident, consistent with pre-attack reconnaissance to identify targets for lateral movement (potentially via PsExec).
• Alternative explanation: Legitimate admin network auditing. However, on a Domain Controller nearing a ransomware event, this is a strong indicator of attacker reconnaissance.
• Verify: Review Nmap scan logs, browser download history for the source URL, and network flow logs for scan patterns from this host. Correlate with the admin (SID -2611) account's authentication events.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] New user account (SID -2611, "admin") appeared and became the primary interactive user starting ~2024-02-06, replacing the built-in Administrator (SID -500).
• Evidence: SID S-1-5-21-1057484085-1795310446-2370380301-2611 first appears at row 66899 (2024-02-06T00:06:00) with a full interactive session (explorer.exe, rdpclip.exe, sihost.exe, cmd.exe, mmc.exe, etc.). Prior to this date, all interactive activity was under SID -500 (built-in Administrator). SID -2611 accounts for 43 of 231 records, all from 2024-02-06 onward.
• Why it matters: The sudden appearance of a new domain account with RID 2611 ("admin") taking over interactive sessions on a Domain Controller days before ransomware deployment may indicate an attacker-created account. The RDP clipboard utility (rdpclip.exe, row 66907) confirms RDP-based remote access under this account.
• Alternative explanation: Legitimate creation of a named admin account to replace use of the built-in Administrator.
• Verify: Check SAM/AD for the creation timestamp and creator of the RID 2611 account. Review Security event logs for Event ID 4720 (user creation) and 4624 (logon events) for this SID.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] cmd.exe and mstsc.exe (Remote Desktop client) usage by the suspicious "admin" account indicates potential lateral movement.
• Evidence: Row 66923 — cmd.exe under SID -2611, foregroundcycletime 1486794981, deduplicated across 6 records (sustained command-line usage). Row 72016 — mstsc.exe under SID -2611 at 2024-02-08T20:00:00, foregroundcycletime 2907504339.
• Why it matters: Command shell and outbound RDP from a DC under a potentially attacker-controlled account 4 days before the ransomware event are consistent with lateral movement to other servers (where redpetya.exe was later found).
• Alternative explanation: Routine administration.
• Verify: Check RDP Bitmap Cache, terminal services logs, and network connections for mstsc.exe destination hosts.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] PowerShell executed under SYSTEM context with significant resource consumption.
• Evidence: Row 33 — \Windows\System32\WindowsPowerShell\v1.0\powershell.exe, user S-1-5-18 (SYSTEM), foregroundcycletime 25120791860 (~25B cycles), deduplicated across 11 records.
• Why it matters: SYSTEM-level PowerShell with HIGH cycle time across multiple time slices may indicate scheduled-task-based or service-based malicious scripting (common for initial access, persistence, or payload delivery in ransomware campaigns).
• Alternative explanation: Windows Update or DSC configuration scripts running as SYSTEM.
• Verify: Review PowerShell transcription/script-block logs, scheduled tasks, and ConsoleHost_history files.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] sethc.exe (Sticky Keys) execution under SYSTEM on 2023-12-12.
• Evidence: Row 638 — sethc.exe, user S-1-5-18, timestamp 2023-12-12T10:01:00, foregroundcycletime 320635024, deduplicated across 42 records.
• Why it matters: sethc.exe running as SYSTEM with persistence across 42 SRUM intervals is unusual. Sticky Keys binary replacement is a classic backdoor technique (Image File Execution Options hijack). However, this could also be normal accessibility feature activation.
• Alternative explanation: Normal accessibility feature triggered at logon screen.
• Verify: Compare hash of sethc.exe on disk against known-good Microsoft hash. Check IFEO registry keys for debugger redirects.

IOC Status

DFIR Check Summary

Data Gaps

1. SRUM data ends 2024-02-09T22:56:00 — there is a ~2.5 day gap before the Feb 12 ransomware discovery. The ransomware execution itself (Feb 10–12) is not captured. This may indicate the SRUM database was not updated after the system was encrypted, or the last write was at that boundary.
2. No network usage columns — SRUM network resource usage (bytes sent/received per app) would reveal data exfiltration and Nmap scan volumes but was not included in this projection.
3. PsExec as a push tool — If PsExec was used from this DC to deploy ransomware to other hosts, the PSEXESVC.exe service would appear on the target, not necessarily here. The cmd.exe usage under the -2611 account may have hosted PsExec invocations, but SRUM records the shell, not the child processes.
4. No process command-line or parent-process information — SRUM records application identity only, not arguments. Cannot determine what powershell.exe, cmd.exe, rundll32.exe, or rename.exe were actually doing.
5. Recommended corroborating artifacts: Prefetch files (for rename.exe, psexec.exe, nmap.exe execution counts/timestamps), Windows Event Logs (Security 4720/4624/4688, PowerShell ScriptBlock), MFT timeline, Amcache/Shimcache, browser history for download sources, and the rename.exe binary itself for hash comparison with redpetya.exe.

Shellbags Forensic Analysis

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Extensive lateral movement via administrative shares (C$) across five internal hosts by the "admin" account.
• Evidence: The "admin" user browsed C$\Users on five distinct hosts via UNC paths: 10.44.24.8 (rows 3–14, mtime up to 2024-02-08T08:39:20), 10.44.24.1 (rows 16–19, mtime 2024-02-08T08:22:12), 10.44.24.6 (rows 21–24, mtime 2024-02-08T08:16:56), 10.44.24.7 (rows 26–29, mtime 2024-02-08T08:29:48), 10.44.24.9 (rows 31–34, mtime 2024-02-08T08:33:14). All five \Users folders were accessed on 2024-02-08 within a ~22-minute window (08:16–08:39 UTC), suggesting systematic enumeration.
• Why it matters: Browsing the administrative C$ share across multiple hosts is a hallmark of lateral movement and reconnaissance; this occurred 4 days before the ransomware detonation on Feb 12, consistent with pre-deployment staging.
• Alternative explanation: A legitimate sysadmin performing maintenance, but the systematic single-session sweep of user profile folders across five hosts is unusual.
• Verify: Correlate with Windows Security Event Logs (logon type 3, Event IDs 4624/4648) for the "admin" account on 2024-02-08 across all five IPs; check for file copy/drop activity (e.g., redpetya.exe placement) on those hosts.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Access to ADMIN$ share on 10.44.24.9 — classic PsExec indicator.
• Evidence: Row 35 — Network\<USERS_PROPERTY_VIEW {999534523}>\10.44.24.9\admin$ under the "admin" user (no timestamp preserved for the NETWORK entry itself).
• Why it matters: PsExec by default copies its service executable to the ADMIN$ share on the target. The investigation context specifically suspects PsExec usage. Browsing or interacting with admin$ via Explorer is highly atypical for normal operations.
• Alternative explanation: Direct manual browsing of admin$ for troubleshooting, but this is rare and coincides with other lateral movement evidence.
• Verify: Check 10.44.24.9 for PSEXESVC.exe in C:\Windows, look for Event ID 7045 (service install) in System logs on that host, and examine Prefetch for psexec execution on the source server.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Access to ADMIN$ share on "desktop-005" — second PsExec-consistent target.
• Evidence: Row 66 — Network\<USERS_PROPERTY_VIEW {999534523}>\desktop-005\admin$ under the "admin" user.
• Why it matters: A second host's ADMIN$ share was browsed, indicating lateral movement to at least two targets via administrative shares. This further supports PsExec or similar remote execution tool usage.
• Alternative explanation: Same as above — manual admin troubleshooting, but the pattern of multiple admin$ accesses is suspicious.
• Verify: Identify "desktop-005" by hostname/IP, image it, and check for PSEXESVC.exe, ransomware artifacts, and service installation logs.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Sysinternals Suite downloaded and extracted by "admin" account days before ransomware detonation.
• Evidence: Row 60 — My Computer\{088e3905-0323-4b02-9826-5d99428e115f}\SysinternalsSuite.zip (mtime 2024-02-05T23:13:42); Row 61 — My Computer\{088e3905-0323-4b02-9826-5d99428e115f}\SysinternalsSuite (mtime 2024-02-05T23:14:42). Both under the "admin" user, accessed via the Downloads folder GUID.
• Why it matters: Sysinternals Suite contains PsExec. The download and extraction occurred on 2024-02-05, exactly 7 days before ransomware detonation. This is the likely source of the PsExec tool used for lateral movement/deployment.
• Alternative explanation: Sysinternals tools are legitimate admin utilities, but downloading them to a server 7 days before a ransomware incident, combined with ADMIN$ access evidence, is strongly indicative of attack tooling preparation.
• Verify: Check browser history, Prefetch, and Zone.Identifier ADS on SysinternalsSuite.zip to confirm download source/URL; check Prefetch for PsExec.exe execution timestamps.

• [SEVERITY: HIGH] [CONFIDENCE: MEDIUM] Sysinternals Suite also present under "Administrator" profile from earlier date.
• Evidence: Row 203 — My Computer\{088e3905-0323-4b02-9826-5d99428e115f}\SysinternalsSuite (mtime 2023-11-04T15:33:16) under the "Administrator" user.
• Why it matters: The Sysinternals folder was accessed under a different account months earlier, potentially indicating either a long-term compromise or that the attacker leveraged pre-existing tools. The "admin" account then re-downloaded/re-accessed a fresh copy on Feb 5.
• Alternative explanation: Legitimate prior admin use of Sysinternals tools.
• Verify: Determine if "admin" and "Administrator" are the same person or different accounts; check if the earlier Sysinternals access was authorized.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Systematic browsing of user profile Documents folders across multiple remote hosts — potential data reconnaissance/exfiltration staging.
• Evidence: The "admin" account browsed into individual user Documents folders on remote hosts via C$: Alika.Solis\Documents on 10.44.24.8 (row 7), Emerson.Howe\Documents on 10.44.24.8 (row 9), Kyla.Dorsey\Documents on 10.44.24.8 (row 14), Drew.Giles\Documents on 10.44.24.1 (row 19), Charity.Hurst\Documents on 10.44.24.6 (row 24), Glenna.Jennings\Documents on 10.44.24.7 (row 29), Christian.Henry\Documents on 10.44.24.9 (row 34). Timestamps range from 2023-11-13 through 2024-01-25.
• Why it matters: Browsing individual users' Documents folders on remote systems via C$ is consistent with data theft/exfiltration reconnaissance, which often precedes ransomware deployment (double-extortion model).
• Alternative explanation: Backup verification or help-desk file recovery, but the scope and number of distinct users across different hosts argues against routine support.
• Verify: Check for large file copies, archive creation, or network exfiltration (e.g., SMB traffic volume, outbound data transfers) in NetFlow/firewall logs.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] "important.zip" file on Desktop accessed close to incident date.
• Evidence: Row 63 — My Computer\Desktop\important.zip (mtime 2024-02-07T04:04:00) under the "admin" user.
• Why it matters: A zip file named "important.zip" was present on the Desktop 5 days before ransomware detonation. This could be a staging archive for exfiltrated data or a payload container.
• Alternative explanation: Legitimate file archive for routine work.
• Verify: Recover important.zip from disk image or shadow copies; examine contents and check for Zone.Identifier ADS to determine origin.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] "admin" account browsed C:\Windows\System32 close to incident date.
• Evidence: Row 58 — My Computer\C:\Windows\System32 (mtime 2024-02-05T23:42:36) under the "admin" user.
• Why it matters: Browsing System32 on the same evening as the Sysinternals download may indicate tool placement, DLL sideloading preparation, or exploration of system binaries.
• Alternative explanation: Routine system administration.
• Verify: Check MFT/USN journal for file creation/modification in System32 around 2024-02-05T23:42.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Windows Firewall settings accessed by "Administrator" account.
• Evidence: Rows 118–119 — Control Panel\System and Security\Windows Firewall and associated property view under "Administrator."
• Why it matters: Firewall modification is a common defensive evasion technique to allow lateral movement traffic or disable host-based protections before ransomware deployment.
• Alternative explanation: Routine firewall configuration.
• Verify: Check Windows Firewall log and registry (HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy) for rule changes; correlate with event log entries.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Extensive browsing of local share user folders by "Administrator" — ~30 distinct user profiles enumerated.
• Evidence: Rows 130–191 — The "Administrator" account browsed C:\share\<username> and \Documents or \Downloads for approximately 30 individual users between 2023-09-24 and 2024-01-15.
• Why it matters: While this may be normal file server administration, the breadth of access could indicate pre-attack data survey.
• Alternative explanation: Routine file server management, home directory provisioning.
• Verify: Determine if this server's intended role is a file server; check if this level of access is normal for the Administrator account.

---

IOC Status

---

Data Gaps

• No file-level visibility. Shellbags record folder navigation only. We cannot confirm whether redpetya.exe, PsExec.exe, or any other specific file was opened, copied, or executed from this data alone. Required: Prefetch, Amcache, MFT, USN Journal, NTFS $LogFile.
• No tsatime or tsbtime populated. All access and creation timestamps are empty across all 157 records, which limits timeline precision to mtime only.
• No activity after 2024-02-08. The latest timestamps are from Feb 8, four days before the Feb 12 ransomware discovery. Either the attacker did not use Explorer-based browsing after Feb 8, or shellbags were not updated due to non-interactive sessions (consistent with PsExec-based deployment). Required: Event logs, Prefetch, and MFT for Feb 9–12 activity.
• Two user profiles present ("admin" and "Administrator"). It is unclear if these represent two distinct accounts or the same person with different logon contexts. Required: SAM registry hive or Active Directory account records.
• No exfiltration confirmation. The Documents/Downloads folder browsing across remote hosts is suggestive but shellbags cannot show what files were copied. Required: SMB session logs, firewall/proxy logs, USN Journal on source and destination hosts.
• ADMIN$ access entries lack timestamps. The NETWORK-type entries for admin$ shares (rows 35, 66) have no mtime, so we cannot definitively place them in the attack timeline. Required: Correlate with Windows Security logs (Event ID 5140/5145) for share access times.
• "desktop-005" not resolved. This hostname appears in ADMIN$ access but its IP and role in the environment are unknown from this data alone.

MUIcache Analysis

Findings

No suspicious or non-standard executables were identified in this MUIcache dataset. All entries reference legitimate Windows system binaries, built-in administrative tools, or standard Windows Server role components. No third-party, unsigned, or anomalous binaries are present.

However, the following observations are contextually relevant to the investigation:

• [LOW] [MEDIUM] PowerShell and PowerShell ISE executed under the Administrator account. While legitimate on a server, these are common post-exploitation tools and could have been used to stage or execute the ransomware payload.
• Evidence: Row 37 — powershell_ise.exe under Administrator; Row 39 — powershell.exe under Administrator.
• Why it matters: PowerShell is a primary execution vector for ransomware deployment and lateral movement. In the context of a Red Petya incident, this warrants timeline correlation.
• Alternative explanation: Routine administrative use on a Windows Server (domain controller, based on AD DS tools present).
• Verify: Examine PowerShell event logs (Microsoft-Windows-PowerShell/Operational, ScriptBlock logging) and ConsoleHost_history.txt for both Administrator and admin profiles.

• [LOW] [MEDIUM] Registry Editor executed under Administrator account.
• Evidence: Row 41 — C:\Windows\regedit.exe, username Administrator.
• Why it matters: Regedit can be used to modify security settings, disable defenses, or establish persistence. Petya variants are known to modify the MBR/boot record, and registry changes may support that chain.
• Alternative explanation: Routine administrative use.
• Verify: Examine Registry transaction logs and USN journal for registry hive modifications around the incident timeframe.

IOC Status

Default DFIR Checks

Data Gaps

1. MUIcache does not record timestamps. No temporal correlation with the 12 Feb 2024 incident is possible from this artifact alone.
2. MUIcache only captures shell-launched executables. Binaries executed via services (PsExec/PSEXESVC), scheduled tasks, command-line only, or non-interactive sessions will not appear. This is the most likely reason both redpetya.exe and PsExec are absent — their absence does not rule out execution.
3. This system is a Domain Controller (evidenced by AD DS, KDC, DNS Server, NTDS, Netlogon services — rows 368, 395, 423, etc.). Compromise of this host is CRITICAL — it implies potential domain-wide credential exposure.
4. **Two user profiles present: admin (237 records) and Administrator (318 records).** The admin account is non-default and should be investigated for legitimacy and whether it was created by the threat actor.
5. Recommended corroborating artifacts: Prefetch, Shimcache/Amcache (for redpetya.exe and PSEXESVC.exe execution evidence), Windows Event Logs (Security 4688 process creation, System 7045 service install for PsExec), NTFS $MFT/USN journal, and MBR/VBR for Petya bootloader modification.

SAM Users – Artifact Analysis

No suspicious findings were identified in the SAM user data. The four accounts present (Administrator RID 500, Guest RID 501, DefaultAccount RID 503, WDAGUtilityAccount RID 504) are all default Windows accounts with sequential, expected RIDs. No rogue or attacker-created local accounts are evident.

---

IOC Status

---

Noteworthy Observations

• All timestamp fields (lastlogin, lastpasswordset, lastincorrectlogin) are null (epoch 1601-01-01). This applies to every account including the built-in Administrator (row 1). On a server that was actively in use until 12 Feb 2024, one would expect the Administrator account to show a non-null lastlogin and lastpasswordset. Confidence: MEDIUM.
• Possible explanations: (1) The server is domain-joined and all interactive/service logons used domain accounts (domain logons do not update the local SAM login timestamps). (2) The SAM hive was reset or corrupted—potentially by the Red Petya ransomware overwriting the MBR/disk structures. (3) The parsing tool did not resolve these fields correctly.
• Verify: Check whether the machine is domain-joined (examine SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain or SYSTEM\CurrentControlSet\Control\ComputerName). Cross-reference with Security Event Logs (Event IDs 4624/4625) for actual logon activity.

• No non-default local accounts exist. RIDs jump from 500→501→503→504 with no RID ≥ 1000 entries. This means no attacker-created local user accounts are present in the SAM.

---

DFIR Check Status

---

Data Gaps

Defender Quarantine Analysis

No suspicious findings are present in this artifact because it contains zero records.

---

IOC Status

---

Data Gaps

• Empty quarantine store is itself a significant finding.
• Given that a ransomware incident occurred on this server (Red Petya displayed on screen), the complete absence of Defender quarantine records is notable. This may indicate one or more of the following:

1. Defender was disabled or tampered with prior to/during the attack. Many ransomware operators (including Petya variants) actively disable Windows Defender via registry, Group Policy, or service manipulation as a pre-encryption step. This is the most concerning interpretation given the investigation context. (MEDIUM confidence)
2. Defender signatures did not detect the threat, so nothing was quarantined.
3. Quarantine data was destroyed as part of the ransomware's disk-level encryption (Petya variants overwrite the MBR/MFT, which could render quarantine files unrecoverable).
4. Defender was not the active AV on this server (a third-party product may have been in use).

• Cannot assess any default DFIR checks (privilege escalation, credential access/Mimikatz, persistence, lateral movement, exfiltration) from this artifact — no data is available.

• Recommended follow-up artifacts to compensate:
• Windows Event Logs — Look for Event ID 5001 (Defender real-time protection disabled), Event IDs 1116/1117 (detection/action), and gaps in the Microsoft-Windows-Windows Defender/Operational log around 12 Feb 2024.
• Registry hives — Check HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\DisableAntiSpyware and Real-Time Protection keys for evidence of Defender being forcibly disabled.
• MFT / filesystem timeline — Look for the creation/execution of redpetya.exe and any PsExec-related artifacts (PSEXESVC.exe, named pipes).
• Prefetch / AmCache / ShimCache — To confirm execution of redpetya.exe, psexec.exe, or PSEXESVC.exe.
• SYSTEM event logs — Service installation events (Event ID 7045) for PSEXESVC service, which is the hallmark of PsExec lateral movement.