Introduction
This is the story of a single workday that became one of the most intensive incident investigations I've ever worked through. It started with a SentinelOne alert at 8 AM, escalated into a multi-hour dispute with an enterprise MDR provider, and ultimately produced five independent malicious verdicts backed by sandbox detonation, a second victim confirmation, and over 1,000 telemetry events from Singularity Data Lake.
The endpoint was kept isolated the entire day. The machine was never reconnected. And by the end of it, what had been classified as a PUA false positive was confirmed as part of an active, multi-victim ransomware distribution campaign.
This post documents the full investigation — the methodology, the evidence, the pushback, and how I worked through it.
The Alert
At 08:04:27, SentinelOne flagged an executable on a domain-joined Windows 11 Pro workstation. The file had been downloaded by a user via Chrome and was sitting in the Downloads folder:
C:\Users\[user]\Downloads\KitchenCanvas_698090.exe
The publisher was listed as INSTALLERIM LLC — a signed, verified certificate. At first glance, this gave the file an air of legitimacy. But the S1 classification told a different story: Ransomware, Behavioral AI, Dynamic detection, 14 threat indicators. The engine that fired wasn't a signature scanner — it was behavioral analysis watching what the file actually did at runtime.
S1 killed the process and quarantined the file at 08:04:30 — three seconds after detection. By that point, it had already been running for several seconds.
14 Threat Indicators Flagged by S1 Behavioral AI
- Process Hollowing — injecting code into legitimate process memory
- Portable Executable Injection
- DLL Hijacking — matching legitimate DLL names for evasion
- Suspicious Registry Key Creation
- Data Encoding — obfuscating C2 communication
- Environmental Keying — payload decrypting based on host fingerprint
- System Binary Proxy Execution — using legit Windows binaries to run malicious code
- Anti-debug bypass attempt
Why the Valid Signature Didn't Matter
The first question anyone would ask: if it's signed by a legitimate LLC, how can it be malware? This is a documented and increasingly common technique. INSTALLERIM LLC is a mobile advertising SDK company — they make ad frameworks for mobile apps. They have no product called KitchenCanvas and no legitimate reason to be signing a Windows desktop installer.
The certificate was either stolen, purchased through a shell entity, or the signing company itself was compromised. Threat actors obtain valid code signing certificates specifically to bypass signature-based detection and create false confidence. A valid signature tells you the binary wasn't tampered with after signing. It tells you nothing about whether the code is malicious.
SentinelOne's behavioral engine caught it anyway — because it watched what the file did when it ran, not what it claimed to be.
Reading the Mitigation Timeline
After confirming the kill events, I pulled the full mitigation log. S1 reported two kill events and a quarantine at 08:04:27–08:04:30. That's three seconds from detection to containment. Impressive — but the timing raised an immediate question about what had already executed before the kill completed.
Crucially, I noticed the threat detail still showed 1 unmitigated threat even after the quarantine status updated. That flag was accurate — it just understated what was happening.
The Post-Mitigation Telemetry
This is where the investigation shifted from "S1 caught a file" to "we have an active incident." I queried Singularity Data Lake for endpoint activity in the window following the quarantine. What came back was not residual noise from a dead process. It was an ongoing execution chain.
Activity was recorded from 08:04:27 through 08:09:59 — five minutes and thirty-two seconds after S1 reported mitigation complete. The malware had dropped persistence mechanisms before S1's kill landed, and those mechanisms kept running.
What the Telemetry Showed
Registry key and value creates under DOMAIN\greta context. Driver Load events under NT AUTHORITY\SYSTEM — a kernel-mode driver executed. Scheduled task registered. The payload had already established persistence before S1 completed the kill.
Three HTTP POST events from the original process chain to external infrastructure. This is the initial C2 registration — the payload phoning home to confirm execution and receive instructions.
File quarantined. Process killed. Network isolation applied. But the scheduled tasks and kernel driver are already running independently.
Multiple new process chains spawn under both DOMAIN\greta and NT AUTHORITY\SYSTEM. File Creation → File Rename → File Deletion loops — the encryption pattern — run continuously. 40+ file deletions in under one second at 08:04:24 consistent with bulk programmatic deletion. Additional POST events at 08:07:10, 08:08:16, and 08:08:35.
Nearly three hours after the initial quarantine, telemetry confirms the beacon loop is still firing every ~500ms, new POST events are being generated, and a scheduled task trigger fires spawning new processes. The persistence mechanisms have survived the endpoint being isolated for hours.
In a single two-minute window, eight separate HTTP POST events fire from eight new process chains all following the same sequence: Process Creation → Behavioral Indicator → POST. The encryption-consistent file pattern is still running under SYSTEM. A new scheduled task fires under SYSTEM. 20+ process creations with registry modifications in under one second.
The Kernel Driver
One of the most significant individual findings in the telemetry was the Driver Load events under NT AUTHORITY\SYSTEM at 08:07:03–08:07:04. Four Driver Load events in rapid succession alongside cascading Registry Key and Value Creates.
A kernel-mode driver executing on a machine means standard EDR process termination and file quarantine is not sufficient. The driver can hook into the OS at a level below where most security tooling operates. Once a kernel driver runs, you cannot assume the integrity of the operating system. The machine required a full wipe regardless of what any subsequent scan reported.
The Disagreement
The MDR provider covering this customer had closed the case as resolved based on the S1 quarantine event — the same morning, before I'd completed my telemetry review. Their assessment: Potentially Unwanted Application (PUA), not ransomware. False positive. Recommend tuning S1 to ignore it.
They also stated that SentinelOne may have already corrected the hash as a false positive on their end.
I verified this immediately. SentinelOne's current classification of the hash: Suspicious. It had never been downgraded. The only status change made to the alert was by our team — escalating it to True Positive / Alert In Progress. The opposite of a false positive correction.
The dispute that followed covered every major finding. The key pushback points and my responses:
File Create/Rename/Delete = installer behavior
This pattern was still running under NT AUTHORITY\SYSTEM at 12:15 PM — over four hours after quarantine. Software installers do not continue executing file manipulation cycles hours after the originating executable has been killed and quarantined. They do not run under SYSTEM in a continuous loop. They do not survive quarantine.
HTTP POSTs = ordinary ad telemetry
INSTALLERIM LLC is a mobile advertising SDK company. This file presented itself as a Windows desktop kitchen design application. There is no ad telemetry framework for a kitchen design desktop app. In the 12:15–12:16 window alone — four hours post-quarantine — eight POST events fired from eight separate newly spawned process chains in under two minutes.
Ransomware is typically threat-actor executed, not user-executed
Drive-by download ransomware that auto-executes from a user-initiated download is a well-documented and increasingly common attack vector. The delivery mechanism does not determine the payload classification.
One workstation isn't impactful enough for ransomware
The machine was domain-joined. The user had network credentials and access to shared drives. The malware was attempting outbound connections every 500ms for four hours — isolation was the only thing preventing the next phase. The absence of confirmed lateral movement is a result of isolation working, not evidence that lateral movement wasn't intended. The initial foothold on one workstation is the entire point of stage one of a ransomware campaign.
Joe Sandbox — The C2 Infrastructure
The MDR provider had asked for specific C2 indicators: IPs, ports, DNS, protocol. I didn't have firewall log access to pull these from the live incident. So I submitted the delivery domain to Joe Sandbox for controlled detonation.
The sandbox confirmed every question that had been left unanswered:
| Indicator | Value | Status |
|---|---|---|
| C2 IP | 18.238.109.118 | MALICIOUS |
| C2 Domain | kitchen-canvas.com | MALICIOUS |
| Hosting | Amazon AWS US (ASN 16509) | — |
| Ports | 138, 443, 40708 | — |
| Additional infra | d2lw31zpx0jw2p.cloudfront.net | — |
Beyond the IOCs, the sandbox signatures answered the outstanding questions directly:
- Ransom note confirmed: "Writes a notice file (html or txt) to demand a ransom" — the direct answer to "where is the ransom note?"
- Process injection confirmed: "Creates a process in suspended mode (likely to inject code)" — independently corroborating S1's process hollowing detection
- Credential harvesting: "Searches for the Microsoft Outlook file path" — the payload was actively looking for email data
- COM Object hijacking — persistence and privilege escalation
- Drops PE files with non-matching extensions — active evasion, hiding executables inside mismatched file types
- Packed with WinRAR — explains the low static AV detection rate; payload unpacks at runtime
- Decoy redirect: sandbox captured the payload redirecting users to a fake WinRAR download page during execution to distract while the infection ran
The behavior graph showed the payload dropped multiple files, spawned Uninstall.exe as a child process (which alone created 141 registry values and 25 files), and connected to the confirmed malicious C2 infrastructure.
The Second Victim
While the dispute was still active, a completely separate customer of ours received an alert from Halcyon — a dedicated anti-ransomware agent — on a different endpoint entirely:
SHA256: 3c1dbc3f56e91cc79f0014850e773a7f12bbfef06680f08f883b2bf12873eccc
File: KitchenCanvas_898785.exe
Classification: InitialAccess
Notes: Evil/AI Download
The exact same SHA256 hash. A different organization, a different user, a different machine, a different filename — same payload. The polymorphic naming (KitchenCanvas_698090 vs KitchenCanvas_898785) is a campaign-level distribution technique: same binary, randomized suffix to evade filename-based detection.
Halcyon classified it as InitialAccess — the first foothold stage of a ransomware kill chain. Not PUA. Not a false positive. A second independent anti-ransomware platform calling it what it was.
This was no longer a single incident. This was a confirmed active campaign hitting multiple organizations on the same day with the same payload.
Five Independent Verdicts
By end of day, the evidence package was complete:
- SentinelOne Behavioral AI — Ransomware, 14 threat indicators, hash currently classified Suspicious
- Halcyon — InitialAccess, flagged on a second unrelated customer endpoint same day, identical hash
- TrendMicro (VirusTotal) — PUA.Win32.FoodFormula.A, known dropper distribution family
- Joe Sandbox — MALICIOUS, 100% confidence, ransom note confirmed, process injection confirmed, C2 IP confirmed
- Joe Sandbox AI Analysis — "primary goal is malware delivery, likely for credential theft or system compromise"
The delivery domain kitchen-canvas.com was newly registered infrastructure created specifically for this campaign, flagged malicious by security scanners, and confirmed active C2 by sandbox detonation.
Why Low VirusTotal Scores Don't Mean Clean
One argument raised during the dispute was that only 2 of 71 vendors flagged the hash on VirusTotal — and that SentinelOne's own static ML engine showed "Undetected" in VT. This was used to support a false positive argument.
But SentinelOne's VT detection is static ML. S1's original detection on the endpoint was Behavioral AI, Dynamic detection — it watched the file run, not just scanned the binary. VirusTotal doesn't execute files and observe runtime behavior. It runs static analysis. Of course the static engine shows undetected — the payload was designed to evade static detection. It's packed with WinRAR and contains environmental keying specifically to defeat static scanners.
A low VT score on a newly emerged ransomware payload is not evidence of legitimacy. It's evidence that the operators tested their payload against VT before deploying it and iterated until detection was low. That's a feature of the attack methodology, not exculpatory evidence.
The Outcome
The endpoint remained isolated for the entire day and was never reconnected. A technician was dispatched to physically retrieve the machine for forensic imaging before any rebuild. The wipe-and-rebuild decision was made on the basis of the kernel driver load alone — regardless of what any subsequent scan showed, the OS integrity could not be assumed after a kernel-mode driver had executed.
The credentials for the affected user account were flagged for forced reset given the Outlook file path enumeration behavior and the confirmed C2 POST events prior to isolation.
The hash was documented as an IOC and a hunt was initiated across all managed endpoints for the same SHA256 and the KitchenCanvas filename pattern.
Lessons From This Investigation
Behavioral detection is more reliable than signature detection for new threats. Every static scanner missed this file. The behavioral engine caught it. Don't let a low VT score undermine a behavioral AI verdict — they're measuring completely different things.
Mitigation ≠ remediation. "S1 quarantined the file" means the original executable is gone. It does not mean persistence mechanisms were removed, kernel drivers were unloaded, scheduled tasks were deleted, or registry run keys were cleaned. Post-mitigation telemetry review is essential for any Behavioral AI detection classified as ransomware.
A valid code signing certificate is not evidence of legitimacy. Threat actors routinely obtain valid certificates — through theft, shell companies, or compromising legitimate vendors — specifically to evade signature-based trust checks. Behavior overrides signature trust in modern security analysis.
Keep the machine isolated until you understand what survived the kill. The pressure to reconnect quickly is real, especially when an MDR provider calls it resolved. Document your findings, communicate clearly, and don't reconnect until you can account for all persistence mechanisms.
Sandbox detonation fills the gaps that live telemetry can't. I couldn't pull firewall logs to identify C2 destinations from the live incident. Joe Sandbox gave me the IP, the ports, the protocol, and the ransom note behavior — all from a controlled environment. When you're missing IOCs, detonate the delivery infrastructure.
One endpoint with confirmed C2 and persistence on a domain-joined machine is not a contained incident. The blast radius of a domain-joined workstation compromise is never limited to one machine. Treat it like it isn't until forensics proves otherwise.
Conclusion
This investigation ran from 8 AM to end of day. It involved raw telemetry analysis, multiple written dispute communications, sandbox detonation, cross-customer threat correlation, and a final five-source evidence package. The machine never came back online.
The most important takeaway isn't the specific tools or techniques — it's the posture. When the telemetry tells you something is wrong and the pressure is to call it resolved and move on, dig deeper. Pull the logs. Build the evidence chain. Don't let institutional inertia override what the data is showing you.
In this case, the data was right.