Case 2026-02-18 18:40:01

Findings
None – no suspicious entries present.

IOC Status

• redpetya.exe → Not Observed.
• PsExec → Not Observed.

Data Gaps

• Only one timestamp (2023-09-24T14:57:27.211781) is represented; no Run/RunOnce data exists for the 4-month window between this date and the 12 Feb 2024 ransomware discovery, so any persistence added in that interval is invisible here.
• Username field is empty for every record, preventing attribution to a specific account.
• No visibility into RunOnce keys (artifact name implies they should be included but none appear), so one-time launchers could be missed.
• Deduplication removed 2 rows; original IDs/timestamps of those removed records are unavailable, limiting verification of whether short-lived malicious entries were discarded.
• Complement with a timeline of all registry writes (e.g., from regtrans-backup or hives’ slack space) and a full volatility/autoruns scan to cover gaps.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Attack-supplied task "Enterpries backup" created on 2024-02-06T21:49:21.961830+00:00 immediately before the 12 Feb ransom-note appearance.
• Evidence: rowref 4-6, taskpath \Enterpries backup, date 2024-02-06T21:49:21.961830+00:00, user "admin", run_level "HighestAvailable".
• Why it matters: Same-day creation gives the adversary a built-in lateral-movement/persistence mechanism that executes PsExec with hard-coded admin credentials.
• Alternative explanation: None – task name is intentionally misspelled, arguments contain plaintext password and a custom binary "rename.exe".
• Verify: Pull the task XML from C:\Windows\System32\Tasks\Enterpries backup to confirm triggers/schedule and retrieve rename.exe.

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] PsExec invocation embedded in the malicious task targeting six workstations with admin credential "letmein".
• Evidence: row_ref 5, command C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe, arguments -accept-eula \\Desktop-001...-006 -c -d -u admin -p letmein -realtime C:\Users\admin\Desktop\rename.exe.
• Why it matters: Confirms PsExec was pre-positioned and scripted for mass execution, satisfying the investigative suspicion.
• Alternative explanation: None – legitimate scripts do not hard-code passwords or push unknown binaries to every desktop.
• Verify: Check C:\Users\admin\Downloads\SysinternalsSuite\ for PsExec.exe hash and verify rename.exe payload on admin desktop.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Task runs with "HighestAvailable" privilege under compromised "admin" account, enabling credential theft or system-wide encryption.
• Evidence: rowref 4, userid "admin", run_level "HighestAvailable".
• Why it matters: Elevated context allows the scheduled payload to bypass UAC and tamper with critical services/files.
• Alternative explanation: None – local admin explicitly chosen with highest privilege.
• Verify: Correlate with Security event logs for 4672/4674 elevations around 2024-02-06T21:49Z.

IOC Status

• PsExec → Observed. Evidence: row_ref 5, command line C:\Users\admin\Downloads\SysinternalsSuite\PsExec.exe with full lateral-movement syntax.
• redpetya.exe → Not Observed. File name does not appear in any task command or argument.

Data Gaps

• No trigger schedule is recorded (missing "Triggers" field) – cannot tell when or how often the malicious task will fire; retrieve the task XML to obtain trigger details.
• No enabled/disabled status or last-run timestamp – cannot confirm if the task has already executed.
• 123 duplicate rows removed; original event IDs/timestamps lost – possible time-stomping or replay attacks cannot be ruled out.
• Tasks prior to 2005-06-23 are absent – no insight into historic persistence mechanisms.
• No hash or file-size metadata for binaries referenced – requires disk forensic image to validate rename.exe and PsExec.exe.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] npcap kernel driver installed – common attacker packet-capture toolkit now loaded at boot.

– Evidence: 2024-02-05T23:42:42.600456, name=npcap, imagepath=\SystemRoot\system32\DRIVERS\npcap.sys, start=System (1), row 305.
– Why it matters: gives adversary passive sniffing/ARP-spoof capability on every reboot; often packaged with PsExec/Metasploit toolsets.
– Alternative explanation: legitimate admin installed Wireshark/nmap, but no ticket or change record supplied.
– Verify: check install path, file hash, and uninstall registry entries for nmap/Npcap installer.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Background Intelligent Transfer Service (BITS) created/updated 2024-02-06 – frequently abused for file pull-down and persistence.

– Evidence: 2024-02-06T04:43:24.915457, name=BITS, servicedll=%SystemRoot%\System32\qmgr.dll, start=Manual (3), row 48.
– Why it matters: attackers use BITS jobs to download second-stage tools or exfil data with built-in Windows component.
– Alternative explanation: Windows update activity, but date is outside normal Patch-Tuesday window.
– Verify: enumerate active BITS jobs with bitsadmin /list or PowerShell Get-BitsTransfer on live image.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Multiple per-user “2a2ba346” & “81ec50” service entries registered 2024-01-22 & 2024-02-05 – template used by StorSvc, PrintWorkflow, Clipboard, etc.

– Evidence: rows 63-592 (e.g. CaptureService_2a2ba346 2024-02-05T23:05:27.742237).
– Why it matters: matches pattern of service-hijack or DLL-sideloading bugs abused for privilege-escalation (e.g., RogueWin32Provider).
– Alternative explanation: Windows user-profile service duplication after update; still worth validating.
– Verify: compare servicedll paths and hashes between base and “2a2ba346”/“81ec50” variants.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] RemoteRegistry service set to Auto Start – gives remote attacker ability to read/modify registry without dropping tools.

– Evidence: 2023-09-24T14:57:31.484438, name=RemoteRegistry, start=Auto Start (2), row 375.
– Why it matters: enables lateral-movement techniques such as remote credential harvesting or service configuration edits.
– Alternative explanation: some monitoring tools require it, but usually disabled by default on modern servers.
– Verify: check firewall rules (port 445/139) and recent remote registry API events.

• [SEVERITY: LOW] [CONFIDENCE: LOW] Microsoft Edge elevation service updated twice since Jan – possible vector for UAC bypass, but no overt malicious signs.

– Evidence: rows 242 & 1422, timestamps 2024-01-19 & 2024-02-07.
– Why it matters: UAC bypass exploits sometimes target elevation services.
– Alternative explanation: normal browser auto-update.
– Verify: inspect elevation_service.exe hash and digital signature.

IOC Status

• redpetya.exe → Not Observed (no service imagepath references this file).
• psexec → Not Observed (no service creation pointing to psexesvc.exe or PsExec binary).

Data Gaps

• Service creation/modification events before 2023-09-24 are absent – cannot determine if persistence existed earlier.
• No EventLog service start-type history – can’t see if logging was disabled (cleared logs would not show here).
• Service account, failure-actions, and registry “DependOnService” fields not provided – needed to spot hijacks.
• Image hashes & version info missing – can’t confirm if binaries are malicious or trojanised.
• Timestamps reflect config snapshots, not runtime – services could have been started/stopped without changing these records.
• Recommend cross-checking with Windows System & Security event logs (EventIDs 7045, 4697) and SRUM or AmCache for actual service executable launches.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] WMI repository is completely empty – no event filters, consumers, or bindings exist in the supplied extract.
• Evidence: “Records: 0 | Time range: N/A to N/A” and “Full Data (CSV): No columns available.”
• Why it matters: Attackers often remove WMI objects to erase fileless persistence; absence could conceal prior back-doors used in the Red Petya intrusion.
• Alternative explanation: Collection tool failure or analyst pulled wrong namespace.
• Verify: Re-acquire ROOT\SUBSCRIPTION and ROOT\DEFAULT namespaces with wbemtest or PowerShell Get-WmiObject -Namespace ROOT\DEFAULT -Class __EventFilter, etc.

IOC Status

• redpetya.exe → Not Assessable. No file or command-line references present.
• PsExec → Not Assessable. No process, service, or WMI record contains “psexec”, “psexesvc”, or related artifacts.

Data Gaps

• No timestamp coverage; impossible to tell whether WMI objects existed before 12 Feb 2024.
• No schema or column data provided – cannot verify collection scope or completeness.
• Absence of objects may indicate deliberate clearing; compare against VSS or backup copies of OBJECTS.DATA to detect deletion.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] PsExec execution confirmed on 2024-02-05 at 23:25:15 UTC.
• Evidence: row 8, path \10.44.24.9\admin$\PSEXESVC.exe, last_modified 2024-02-05T23:25:15.663250+00:00.
• Why it matters: Matches investigative suspicion of PsExec use; service binary dropped via ADMIN$ share indicates lateral movement.
• Alternative explanation: None – PsExec service binary is not present by default.
• Verify: Cross-check Windows event logs (Sysmon EID 1 / Security EID 4697) for service creation and source IP.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Multiple Sysinternals tools staged in C:\Users\admin\Downloads\SysinternalsSuite\ on 2024-02-05 ~23:14 UTC.
• Evidence: rows 19-143, last_modified 2024-02-05T23:14:3x.
• Why it matters: Concentration of LOLBAS/LOLBins (PsExec, ProcDump, Autoruns, etc.) immediately before PsExec service appearance suggests attacker toolkit deployment.
• Alternative explanation: Legitimate admin troubleshooting – but timing and breadth of tools is atypical.
• Verify: Check SHA-256 hashes of these files against official Sysinternals signatures; review user-agent / download logs.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Nmap presence on disk (rows 98, 100) last_modified 2022-09-01T22:36:0x.
• Evidence: C:\Program Files (x86)\Nmap\nmap.exe & zenmap.exe.
• Why it matters: Reconnaissance tool outside normal server software baseline; could indicate pre-attack scanning.
• Alternative explanation: Installed by admin for network diagnostics.
• Verify: Review Add/Remove Programs history and Prefetch to see execution frequency.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Several dismhost.exe executions from user temp directories dated 2021-05-08 (rows 1,2,13,14,85,168-223, …).
• Evidence: repeated last_modified 2021-05-08T08:14:39.423861+00:00 across GUID-named folders.
• Why it matters: Pattern consistent with WMI/DISM abuse for payload staging or evasion, but timestamp is >2 yrs old.
• Alternative explanation: Routine Windows feature-install activity.
• Verify: Correlate with WMI-Activity/Windows Setup events from same day to confirm benign use.

IOC Status

• redpetya.exe → Not Observed (no shimcache entry for this filename).
• psexec → Observed (PSEXESVC.exe, row 8).

Data Gaps

• Shimcache does not record execution time—only last-modified timestamp—so we cannot confirm PsExec or other tools actually ran versus were just copied.
• No hash or signature data in artifact; cannot verify binary integrity.
• Artifact ends 2024-02-07T10:22:21, five days before ransomware discovery on 2024-02-12; any activity after that date (including redpetya.exe deployment) is absent.
• No user context or command-line arguments; additional artifacts (Prefetch, EDR, EventID 4688/1, AmCache) required to confirm execution and attribution.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] PsExec binaries present on two user desktops, first-seen 2024-02-06/07.
• 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
– c:\users\administrator\downloads\sysinternalssuite\psexec64.exe row 72, mtime_regf 2024-02-07T21:00:11.248564

• Why it matters: Matches investigative suspicion; PsExec is a common lateral-movement / remote-code-execution utility abused by ransomware operators.
• Alternative explanation: Legitimate sys-admin use—needs corroboration with execution evidence.
• Verify: Cross-check Prefetch/Event logs/SRUM for actual process launch of PsExec around these timestamps.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Nmap suite (nmap.exe, ncat.exe, nping.exe, Zenmap GUI) installed 2024-02-06 on admin desktop.
• Evidence:

– nmap-7.93-setup.exe row 62, first-seen 2024-02-07T21:00:11.233940
– nmap.exe row 63, ncat.exe row 59, nping.exe row 69, Zenmap.exe row 129 all mtime_regf 2024-02-06T21:01:08.x

• Why it matters: Post-exploitation reconnaissance/port-scanning tools often deployed just before or after ransomware to map targets.
• Alternative explanation: Admin performing authorized network audit.
• Verify: Review authentication logs for concurrent RDP/console logins; check if scan traffic observed on network sensors.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Several small standalone utilities (dir.exe, rename.exe) dropped on admin desktop 2024-02-07 with no publisher metadata.
• Evidence:

– c:\users\admin\desktop\dir.exe row 13, size 0.77 MB, no publisher/hash, mtime_regf 2024-02-07T21:00:10.342958
– c:\users\admin\desktop\rename.exe row 80, size 0.22 MB, no publisher/hash, mtime_regf 2024-02-07T21:00:10.562542

• Why it matters: Possible lightweight backdoors, coin-miners, or staging payloads masquerading as common command names.
• Alternative explanation: Admin compiled legitimate helper scripts; metadata stripped.
• Verify: Retrieve files, compute SHA-256, submit to reputation/vault services; check Prefetch for execution.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Sysinternals Autologon64 & RamMap64 copied to Administrator downloads 2024-02-07.
• Evidence: autologon64.exe row 3, rammap64.exe row 77 (same folder as PsExec).
• Why it matters: Autologon can store plaintext credentials; combined with PsExec enables lateral movement with captured creds.
• Alternative explanation: Routine troubleshooting toolkit copy.
• Verify: Check registry for Autologon credential entries; review credential-theft detections.

IOC Status

• redpetya.exe → Not Observed (no record in this Amcache extract).
• psexec → Observed (three separate PsExec binaries recorded).

Data Gaps

• Amcache shows first-time file presence but does not confirm execution; need Prefetch/SRUM/Event IDs 4688/592 for launch confirmation.
• No hash values provided—cannot pivot to threat-intel or check against known Red-Petya samples.
• Time coverage ends 2024-02-09; ransomware exhibited 2024-02-12, leaving three-day blind spot.
• No USER/SID field—cannot distinguish whether “admin” vs “administrator” account activity indicates separate actors or same individual.
• Absence of redpetya.exe here does not rule out its existence (file may have been deleted, never executed, or placed outside Amcache-monitored locations).

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] PsExec (both 64-bit and 32-bit) executed from the admin user’s Downloads folder on 06 Feb and 09 Feb.
• Evidence: rowref 13 – PsExec64.exe at 2024-02-06T22:14:12.975912+00:00; rowref 23 – PsExec.exe at 2024-02-09T22:55:44.556122+00:00.
• Why it matters: Confirms lateral-movement tool was run inside the threat window and immediately before the ransom note appeared (12 Feb).
• Alternative explanation: legitimate admin use (unsupported – runs from Downloads, not Tools).
• Verify: correlate with Security 4624/5140 logs for remote logon tied to these times.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Nmap installer and Zenmap GUI executed on 05 Feb and 08 Feb.
• Evidence: rowref 15 – nmap-7.93-setup.exe 2024-02-05T23:43:02.682171+00:00; rowref 17 – zenmap.exe 2024-02-08T19:06:34.806301+00:00.
• Why it matters: Network scanner present on a server; common precursor for lateral-movement reconnaissance.
• Alternative explanation: admin performing authorized scan.
• Verify: check outbound scan traffic in firewall/PCAP for 08-09 Feb.

• [SEVERITY: LOW] [CONFIDENCE: HIGH] Rundll32 recorded late in timeline (09 Feb 20:59) without corresponding DLL command line.
• Evidence: row_ref 18 – rundll32.exe 2024-02-09T20:59:30.651415+00:00.
• Why it matters: rundll32 is routinely abused to launch malicious DLLs; timing close to PsExec re-run.
• Alternative explanation: legitimate shell extension or Windows maintenance.
• Verify: retrieve command-line from SRUM / AmCache / EventID 4688.

IOC Status

• redpetya.exe → Not Observed (no entry in BAM paths).
• PsExec → Observed (both 64- and 32-bit versions executed).

Data Gaps

• BAM only records executables that produced a window; console-only or short-lived payloads may be missing.
• No command-line, parent process, or user SID stored – can’t confirm remote target or privilege level.
• Artifact stops 09 Feb 22:55; no visibility into 10-12 Feb when ransom note surfaced – possible log-clearing or system offline.
• redpetya.exe never launched on this host (or was cleared) – check Prefetch / AmCache / $MFT for binary presence.
• Missing expected DAM entries for service-mode PsExec execution – verify with 4697/7045 service-creation events.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Both 32-bit and 64-bit PsExec executed from Downloads\SysinternalsSuite by admin account on 2024-02-06.
• Evidence: rowref 14 (PsExec64.exe, ts 2024-02-06T22:14:12.356998+00:00, 1 exec) and rowref 27 (PsExec.exe, ts 2024-02-06T22:14:10.115000+00:00, 1 exec).
• Why it matters: Confirms lateral-movement tool usage two days before the 12 Feb ransomware discovery, consistent with initial suspicion.
• Alternative explanation: legitimate admin task (no corresponding service install logs here).
• Verify: cross-check System/Security event logs for Service Control Manager events around 22:14 on 6 Feb.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] PsShutdown64.exe launched from a temp folder created by a Zip archive on 2024-02-05.
• Evidence: rowref 12 (C:\Users\admin\AppData\Local\Temp\3\Temp1SysinternalsSuite.zip\psshutdown64.exe, ts 2024-02-05T23:14:20.084999+00:00, 1 exec).
• Why it matters: Remote-shutdown utility executed one day after PsExec and one week before outage; could be used to force reboot to trigger ransomware or erase evidence.
• Alternative explanation: admin testing power options.
• Verify: look for corresponding shutdown/restart entries in System log 23:14 ±5 min.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Nmap network scanner installed and GUI executed on 2024-02-06.
• Evidence: rowref 19 (zenmap.exe, ts 2024-02-06T21:09:13.195999+00:00, 2 exec) preceded by setup files (rowref 16-18).
• Why it matters: Reconnaissance activity hours before PsExec usage suggests staged attack.
• Alternative explanation: routine network audit.
• Verify: check for nmap scan logs or unusual outbound connection attempts.

• [SEVERITY: LOW] [CONFIDENCE: HIGH] Heavy interactive use of built-in admin accounts (Administrator & admin) during the intrusion window.
• Evidence: 50 & 49 distinct records respectively, with multiple console (cmd), AD, GPO and Task Scheduler launches 5-9 Feb.
• Why it matters: Consistent with manual attacker activity; also complicates attribution between legitimate admin and intruder.
• Alternative explanation: normal administrative work.
• Verify: correlate with RDP/Console logon events to confirm if sessions came from unfamiliar IPs.

IOC Status

• redpetya.exe → Not Observed (no reference in UserAssist).
• psexec → Observed (both 32/64-bit versions executed). Evidence: row_ref 14 & 27.

Data Gaps

• UserAssist only logs GUI-launched programs; console tools run directly (e.g., psexec \\target -s cmd) may be missed.
• No execution timestamps after 2024-02-09T22:53:05; cannot assess activity on 10-12 Feb (day of discovery).
• redpetya.exe launch would only appear here if started via Explorer/Shell; if run as a service or via PsExec console, no record expected.
• No presence of Mimikatz, credential-access, or common persistence binaries (no run keys, services, etc. logged here).
• 62 entries show 0 executions, indicating possible registry wiping or anti-forensic cleaning (standard Windows does not zero counts).
• Additional artifacts needed: Prefetch, ShimCache, SRUM, AmCache, Services, Scheduled Tasks, and Security/System logs to confirm full timeline and service creation events.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Two days before the ransomware splash-screen appeared, the “admin” user deleted a 50 MB archive named “SysinternalsSuite.zip” (the standard PsExec distribution bundle).
• Evidence: 2024-02-05T23:14:49.615999, path “C:\Users\admin\Downloads\SysinternalsSuite.zip”, row_ref 2.
• Why it matters: Shows the account most likely to have lateral-movement tools already had them locally and then removed them—classic post-action cleanup.
• Alternative explanation: Admin routinely cleans up downloaded utilities.
• Verify: Carve unallocated clusters for the ZIP or its extracted PsExec.exe; cross-check prefetch / AmCache for PsExec execution.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] One day later (2024-02-06T22:14:44.067999) the same “admin” account deleted a 0.65 GB archive “share.zip” from the Desktop.
• Evidence: row_ref 1.
• Why it matters: Large user-created archive erased hours before the victim server went offline could contain stolen data, second-stage tools, or ransomware payload staging.
• Alternative explanation: Legitimate file-share cleanup.
• Verify: Recover the ZIP from the recycle-bin copy or volume shadow; hash and inspect contents.

IOC Status

• redpetya.exe → Not Observed (no entry in this Recycle-Bin data set).
• psexec → Not Observed as an individual file, but the parent “SysinternalsSuite.zip” that contains it was deleted (see Finding 1).

Data Gaps

• Recycle-Bin only captures deletions; files copied or executed without deletion are invisible here.
• No shred/secure-delete indicators—actual file data may still reside in the $I/$R pairs or free space, but that content is not present in this metadata-only export.
• Time window stops 10 Feb 2024; no visibility into cleanup that may have occurred 11–12 Feb.
• User context limited to “admin”; cannot distinguish between different real persons or compromised service accounts using that profile.
• Correlation with prefetch, AMCache, event logs, or MFT would confirm whether PsExec or share.zip contents ever executed.

Findings

• [SEVERITY: CRITICAL] [CONFIDENCE: HIGH] Post-compromise staging: browser opened local ransom note “RyukReadMe.txt” on 2024-02-06 20:53:29 (row 48).
• Evidence: iexplore file:///C:/Users/admin/Desktop/RyukReadMe.txt, visit_count=1, username=admin.
• Why it matters: Confirms ransomware payload executed and attacker left ransom instruction file on this box, not just the “Red-Petya” screen seen elsewhere.
• Alternative explanation: None – file name is unique to Ryuk campaigns.
• Verify: Hash RyukReadMe.txt, check file creation time vs. browser launch to confirm sequence.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Interactive use of attacker-controlled FTP server 185.239.106.67 immediately before discovery window (2024-02-07 16:57:05 & 16:57:31, rows 50-51).
• Evidence: ftp://185.239.106.67/branchoffice.example.com/ (9 visits) and parent ftp://185.239.106.67/ (2 visits) from iexplore by admin.
• Why it matters: Live connection to external host during incident timeframe suggests data exfil, tool staging, or remote control channel.
• Alternative explanation: None – FTP URL is non-internal and coincides with ransomware event.
• Verify: Retrieve firewall/NAT logs for 185.239.106.67 traffic; check uploaded/downloaded files.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Download & local open of network-mapping tool Nmap on 2024-02-05 (rows 12-20) followed by opening of credential repositories (rows 45-47).
• Evidence: Bing search → softonic download → file open of C:/scripts/activeDirectoryuserimport.csv, accountpassword.xlsx, accountedit.docx (rows 45-47) all by admin.
• Why it matters: Recon for lateral movement; credential files accessed right after obtaining Nmap.
• Alternative explanation: Admin performing legitimate audit – timing adjacent to ransomware undermines that.
• Verify: Compare Nmap install date with CSV/Excel file last-access timestamps; look for subsequent scan logs.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Sysinternals Suite downloaded and archive opened on 2024-02-05 23:13 & 23:36 (rows 8-11, 43-44) – contains PsExec, one of the stated suspected tools.
• Evidence: Browser visit to Microsoft learn page, then file open of C:/Users/admin/Downloads/SysinternalsSuite.zip and C:/Users/admin/Desktop/share.zip.
• Why it matters: Directly supplies the utility suspected for lateral movement/execution.
• Alternative explanation: Routine admin use – but combined with subsequent events is suspicious.
• Verify: Check Prefetch/SRUM for PsExec execution; correlate with any 4624/7045 events.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Archive “important.zip” opened on desktop 2024-02-06 20:09 (row 49) minutes before Ryuk note was viewed.
• Evidence: iexplore file:///C:/Users/admin/Desktop/important.zip.
• Why it matters: Possible payload container; timing close to ransomware activation.
• Alternative explanation: Could be innocuous user file.
• Verify: Recover and hash zip contents; scan with AV/EDR.

IOC Status

• redpetya.exe → Not Observed (no reference in URLs or local file opens).
• PsExec → Not directly observed, but parent package Sysinternals Suite downloaded and extracted → Observed (rows 8-11, 43).

Data Gaps

• No browsing recorded between 2024-02-07 16:57:31 and 2024-02-12 (discovery date) – five-day gap could mask further C2 or staging activity; absence may also indicate private/incognito mode, history wipe, or profile change.
• URL-level detail truncated by Bing SafeLink wrappers; exact final destinations not shown, limiting full IOC matching.
• Visit_count field does not capture repeated refreshes or scripted reloads.
• No User-Agent or IP geolocation data to corroborate remote vs. local session.
• Complementary artifacts needed: Web-cache, Prefetch, SRUM, EventID 4624/4672, $MFT for exact file creation times of RyukReadMe.txt & archives, proxy/firewall logs for 185.239.106.67.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Two separate downloads of the official Sysinternals Suite on 04 Nov 2023 (rows 3 & 4) and a fresh download on 05 Feb 2024 23:13 UTC (row 1) – all three immediately before the ransomware screen appeared on 12 Feb 2024.
• Evidence: 2024-02-05T23:13:32 UTC, admin, C:\Users\admin\Downloads\SysinternalsSuite.zip, row 1; 2023-11-04T15:25:24 UTC, Administrator, same ZIP, rows 3-4.
• Why it matters: PsExec is inside this ZIP; its presence on disk within days of the infection supports the PsExec-lateral-movement hypothesis.
• Alternative explanation: legitimate admin troubleshooting.
• Verify: hash the downloaded ZIP and compare to official Sysinternals hash; check Prefetch/ShimCache for psexec.exe execution.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Nmap 7.93 installer downloaded 05 Feb 2024 23:41 UTC (row 2) – network-scanning tool obtained hours after the Sysinternals Suite.
• Evidence: 2024-02-05T23:41:28 UTC, admin, nmap-7.93-setup.exe, 27.8 MB, complete.
• Why it matters: Attackers often scan internal networks post-compromise to prioritise lateral-movement targets.
• Alternative explanation: admin performing authorised network audit.
• Verify: examine subsequent Nmap install/execution artifacts (Uninstall registry keys, Prefetch, UserAssist).

IOC Status

• redpetya.exe → Not Observed. No record of this filename in browser-download data.
• PsExec → Not Directly Observed (binary name absent), but container file SysinternalsSuite.zip downloaded three times.

Data Gaps

• Only four download events survive; no Edge history older than 04 Nov 2023 and nothing between 04 Nov 2023 and 05 Feb 2024 – cannot rule out deleted entries or history-wipe.
• Browser-download table lacks hash/referrer/URL-chain columns – cannot confirm file integrity or original download page.
• No visibility into whether the downloaded ZIP/EXE were ever executed; need Prefetch, ShimCache, AmCache, and process creation logs.
• No evidence of download staging directories or alternate browsers (Chrome, Firefox) – check those artifacts if available.

Findings
None – the Activities Cache database contains zero records, so no user-interaction events are available for inspection.

IOC Status

• redpetya.exe → Not Assessable (no data)
• psexec → Not Assessable (no data)

Data Gaps

• Entire artifact is empty; no time range, column headers, or rows are present.
• Cannot determine whether the cache was cleared, the database file is corrupted/missing, or the feature was disabled.
• Recommend verifying existence and integrity of “ActivitiesCache.db” on the suspect system and checking for evidence of manual deletion or tampering (e.g., $UsnJrnl, $LogFile, SRUM).

Findings
None – the SRUM network data set is empty.

IOC Status

• redpetya.exe → Not Assessable (no records).
• PsExec → Not Assessable (no records).

Data Gaps

• Zero rows returned; time range, column set, and all values are null.
• Cannot determine whether SRUM was disabled, the ETL file was cleared, or the artifact was never populated on this image.
• Collect SRUDB.dat or corresponding ETL files (e.g., \Windows\System32\sru\srudb.dat) and verify SRUM service start/stop events to confirm logging status.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Suspicious rename.exe executed on 2024-02-09T22:56:00+00:00 under HIGH-privilege SID S-1-5-21-1057484085-1795310446-2370380301-2611, one day before the ransomware discovery.
• Evidence: rowref 73965, app=\Device\HarddiskVolume2\Users\admin\Desktop\rename.exe, user=S-1-5-21-1057484085-1795310446-2370380301-2611, foregroundcycle_time=13284139184.
• Why it matters: Rename utilities are frequently dropped/renamed by ransomware to obfuscate payloads or prepare file-extension changes; timing places it immediately before the incident.
• Alternative explanation: legitimate administrator file-management task.
• Verify: hash the file, compare to “redpetya.exe” hash, check Prefetch/USN for original filename.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Nmap port-scan tools (nmap.exe, zenmap.exe) executed on 2024-02-06T00:06:00+00:00 under the same HIGH-privilege SID.
• Evidence: rowref 66927 (nmap.exe), 66926 (zenmap.exe), user=S-1-5-21-1057484085-1795310446-2370380301-2611, foregroundcycle_time 221269249429 / 227183733421.
• Why it matters: Attackers routinely run network reconnaissance before lateral movement/ransomware deployment; presence on a server is highly abnormal.
• Alternative explanation: none plausible—server roles do not justify interactive port-scanning tools.
• Verify: check command-line in SRUM_SHORT or EventID 4688, look for accompanying scan output files, correlate with any successful log-ons from that SID.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Persistent interactive logon sessions for privileged SID S-1-5-21-1057484085-1795310446-2370380301-2611 starting 2024-02-06T00:06:00+00:00 (32 identical time slices) – a new user context never seen in earlier data.
• Evidence: first appearance row_ref 66899-66926; continues through 2024-02-09T22:56:00+00:00.
• Why it matters: New admin-level account active immediately before ransomware hit indicates possible compromised or rogue credential use.
• Alternative explanation: newly created legitimate admin; still needs verification.
• Verify: compare Security.evtx for account creation / first log-on, check LAPS or ticket events.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] Multiple DismHost.exe invocations from user TEMP directories spanning 11 Dec 2023 – 9 Feb 2024, all under admin SIDs.
• Evidence: rows 64, 824, 1072, 1541, 1676, 1937, 41947, 43348, 44712, 46009, 46367, 54013, 57427, 57713, 61512, 65381, 65719, 68398, 70403, 70861, 72093 (examples).
• Why it matters: DismHost copied to user TEMP and repeatedly run is consistent with living-off-the-land or installer abuse to side-load code; overlaps attacker timeframe.
• Alternative explanation: Windows Update or DISM cleanup tasks; however path (user TEMP) is abnormal.
• Verify: check parent process, command line, and whether any of these spawned unexpected network/disk activity.

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] Windows Defender delta-patch installers present but no corresponding “MsMpEng” HIGH CPU after 2024-01-20; last patch 2024-01-20T18:11.
• Evidence: rowref 45748 (AMDeltaPatch1.403.2375.0.exe).
• Why it matters: Absence of continued signature updates after 20 Jan could indicate tampering or service disablement just before attack window.
• Alternative explanation: automatic updates paused or server offline.
• Verify: check WinDefend service start type and event logs for disable/enable events.

IOC Status

• redpetya.exe → Not Observed. Filename does not appear in any SRUM application record.
• PsExec → Not Observed. No record of psexec.exe, psexesvc.exe, or the typical Sysinternals path.

Data Gaps

• SRUM only logs processes that consume network or foreground cycles; short-lived console tools (e.g., PsExec with /c) may never appear.
• No command-line or parent-process columns—cannot confirm intent or injection chain.
• Coverage ends 2024-02-09T22:56; ransomware manifested 2024-02-12—three-day blind spot just before impact.
• Deduplication removed 73 k rows; if attacker spawned hundreds of brief processes they could be hidden.
• User SIDs resolved only to numbers—need to map SID S-1-5-21-…-2611 to actual account name via SAM hive or Security.evtx.
• Missing Expected Evidence: no Prefetch, AmCache, or EventID 4688 data provided to corroborate these findings.

Findings

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] Interactive browsing of every C$ share on five internal hosts (10.44.24.1,6,7,8,9) plus two branch-office systems during the 3-week window before the 12 Feb 2024 ransom-note discovery.
• Evidence: rows 3-34 (first seen 2023-11-13, last seen 2024-02-08).
• Why it matters: Mass share enumeration is a classic lateral-movement precursor; the same “admin” account later had local folders time-stamped on 2024-02-05/07.
• Alternative explanation: legitimate admin mapping for maintenance (but scope and timing still suspicious).
• Verify: correlate these mtimes with Windows Security log 4624/4648/5140 on the target IPs to confirm interactive logon vs scripted mapping.

• [SEVERITY: HIGH] [CONFIDENCE: HIGH] SysinternalsSuite.zip extracted and its folder browsed on 2024-02-05 23:13-23:14 UTC, three days before ransom screen disappeared.
• Evidence: rows 60-61 (mtimes 2024-02-05T23:13:42 & 23:14:42) by user “admin”.
• Why it matters: Suite contains PsExec, the very tool suspected for delivery; presence immediately prior to incident is strong corroboration.
• Alternative explanation: none plausible – intentional download by attacker or insider.
• Verify: hash the extracted files; check Prefetch / AmCache for psexec.exe execution.

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] New “important.zip” placed on the admin desktop at 2024-02-07 04:04 UTC, one day before ransom screen vanished.
• Evidence: row 63 (mtime 2024-02-07T04:04:00).
• Why it matters: Archives dropped shortly before impact often contain secondary tools or exfiltrated data.
• Alternative explanation: user archive; still needs inspection.
• Verify: recover the ZIP and inspect contents; scan for embedded payloads or stolen files.

• [SEVERITY: MEDIUM] [CONFIDENCE: MEDIUM] Rapid, same-second creation of 24 user folders under C:\share on 20 Nov 2023 (all mtimes 13:49:44-13:52:02).
• Evidence: rows 46-165 cluster.
• Why it matters: Bulk folder creation can stage data for collection or indicate scripted staging prior to later exfil/encryption.
• Alternative explanation: bulk account creation / folder-redirection setup.
• Verify: match against AD account-creation logs; check whether files ever resided in those folders.

IOC Status

• redpetya.exe → Not Observed (no shellbag path contains that filename).
• PsExec → Not directly observed by name, but the containing SysinternalsSuite folder was browsed 3 days pre-incident (HIGH confidence proxy observation).

Data Gaps

• Shellbags only prove that Explorer “saw” a path, not that any file was executed or even present; no SHA-1/MD5 or size recorded.
• tsatime & tsbtime columns are empty – cannot tell last access or birth time.
• No user SID or session info – cannot distinguish simultaneous users both named “Administrator” or “admin”.
• Time-stamps stop at 2024-02-08; activity between 2024-02-09 and 2024-02-12 (day of discovery) is missing – possible gap or bag-cleaning.
• No visibility into deleted folders after 12 Feb – would need Volume Shadow Copies or $UsnJrnl to confirm cleanup.

Findings

• [SEVERITY: LOW] [CONFIDENCE: MEDIUM] No record for redpetya.exe or any PsExec variant (psexec.exe, psexesvc.exe, psexec64.exe, etc.) in the 596 MUIcache entries.
• Evidence: full CSV search – zero matches.
• Why it matters: absence means the GUI shell never cached display strings for these binaries, so they were either never launched interactively, launched from a non-explorer context (e.g., service, PsExec remote), or executed from a path whose resource strings are not cached.
• Alternative explanation: MUIcache only populates when a process is launched through the shell; command-line or service launches often leave no entry.
• Verify: cross-check AmCache, Prefetch, ShimCache, and SRUM for execution artifacts; review event logs for process-create events.

IOC Status

• redpetya.exe → Not Observed.
• PsExec (any variant) → Not Observed.

Data Gaps

• No timestamps provided; cannot place any activity relative to 12 Feb 2024.
• MUIcache does not record execution time, command line, or parent process—only cached display strings once per user/binary.
• Absence of an entry does not prove absence of execution; non-interactive or service launches are frequently missed.
• Additional artifacts needed: AmCache.hve (installation timestamp), Prefetch files (run count & last run time), Event ID 4688/1 process creation logs, SRUM (network & process usage), and scheduled-task/job cache to assess lateral-movement launch vectors.

Findings

• [SEVERITY: MEDIUM] [CONFIDENCE: HIGH] All four accounts show identical “never-used” timestamps (1601-01-01) for last login, password set, and failed login.
• Evidence: Every row, every *_login column = 1601-01-01T00:00:00+00:00.
• Why it matters: Suggests the SAM hive was extracted from an offline image or rebuilt; could mask prior account misuse.
• Alternative explanation: Normal for a freshly-built, never-logged-on template image.
• Verify: Check SYSTEM registry hive for the same date range – if last shutdown time is also 1601-01-01, confirms offline extraction.

• [SEVERITY: LOW] [CONFIDENCE: HIGH] No user-created local accounts present; only built-in RIDs 500-504 visible.
• Evidence: RIDs 500, 501, 503, 504 listed; no RID ≥ 1000.
• Why it matters: Eliminates one common persistence vector (new local account) but does not rule out account takeover of existing ones.
• Alternative explanation: Clean baseline or attacker removed added accounts.
• Verify: Cross-check against Security-Audit event logs for account creation events (4720/4722).

IOC Status

• redpetya.exe → Not Observed (no filename or hash in SAM).
• PsExec → Not Observed (no service or account creation artifacts in SAM).

Data Gaps

• SAM snapshot is static; no historical view to detect added/deleted accounts outside this 2-second window.
• Lacking group membership (e.g., local Administrators) – cannot confirm privilege escalation.
• No password hash or account flags (disabled/locked) – cannot assess credential strength or brute-force indicators.
• Absence of any logged-on activity prevents correlation with lateral-movement timelines.
• Recommend Security.evtx, SYSTEM hive, and Scheduled Tasks artifacts to fill gaps.

Findings
None – the quarantine table is empty.

IOC Status

• redpetya.exe → Not Observed (no quarantine record for this file)
• PsExec → Not Observed (no quarantine record for PsExec or variants)

Data Gaps

• No time range is available, so we cannot tell whether Defender was running or simply saw nothing to quarantine during the incident window.
• Absence of quarantine entries does not prove the files were never present; they may have been whitelisted, excluded, executed with Defender disabled, or cleaned by another tool.
• Complement with Defender operational logs (Event-ID 1116/1117), MpThreatDetections, and the protected-system registry flag to confirm real-time protection status at the time of the ransomware deployment.