Hunting through Chrome Incognito: SRUM and DNS logs on a malvertising case

Written March 2026, from an enterprise incident I worked. Published here September 2026.
Anonymized Organization, sector, roles, dates and the legitimate third-party site are generalized. Attacker infrastructure and hashes are shown as observed.
Outcome No compromise. Delivery vector proven.

The alert

The flag was straightforward: Chrome had downloaded a file called MealFormula.exe and executed it. On its face, that is bad. An unknown executable pulled down by a browser and immediately run is textbook malware delivery.

I pulled the file and sent it to a sandbox. The results were anticlimactic. MealFormula.exe was a renamed copy of the legitimate WinRAR installer, with a valid EV code-signing certificate from win.rar GmbH. Sandbox score 5/10, and every flagged behaviour was normal installer work: writing to Program Files, creating registry keys, requesting elevation.

SHA-256 CFCA124C2141B4171CEBAD48CC286751910B408AEC69767DB2BC3AF38F277A06. A clean, signed WinRAR installer. Not malware.

Severity downgraded. It looked like a false positive: a user downloaded WinRAR with a weird filename, the endpoint agent flagged it, case closed. Except I could not figure out where it came from.

The dead ends

This is the part that felt like hitting walls for hours. One question: how did MealFormula.exe get onto this machine?

Chrome browser history: 0 bytes of records. The History SQLite database existed but was empty. I confirmed it directly:

import sqlite3
conn = sqlite3.connect('History')
cursor = conn.execute("SELECT url, title, last_visit_time FROM urls ORDER BY last_visit_time DESC LIMIT 20")
rows = cursor.fetchall()
print(f"Total rows: {len(rows)}")
# Total rows: 0

Zero rows. No downloads table entries either. The database was essentially freshly initialized.

Edge browser history: nothing relevant. The user was not using Edge for this.

Zone.Identifier (Mark of the Web): no alternate data stream on the file. A normal browser download should have stamped it with a Zone.Identifier ADS carrying the referrer and download URL. Nothing.

USB history: no evidence of any removable storage device.

Network shares: the file was not present on any mapped drive or accessible share.

Every delivery vector eliminated. The endpoint agent's trajectory confirmed Chrome downloaded the file, but Chrome's own records had been wiped clean. Something was not adding up.

SRUM: the breakthrough

If Chrome's history was empty but the endpoint agent saw Chrome downloading the file, what if the user was running Chrome in Incognito mode?

Incognito does not write to the History database. It does not save downloads or create cookies on disk. From a browser-forensics perspective it is a black hole. But Incognito cannot hide from the operating system.

The System Resource Usage Monitor (SRUM) is a Windows telemetry database at C:\Windows\System32\sru\srudb.dat. It tracks per-application resource usage in time-bucketed records: CPU time, network bytes sent and received, foreground time. It does not care whether Chrome is in Incognito. It just sees chrome.exe moving bytes.

I pulled the SRUM database via VSS and parsed it two ways: SrumECmd for a quick look, then Python against the parsed CSV for custom queries.

import csv
with open('SrumECmd_NetworkUsage_Output.csv', 'r') as f:
    reader = csv.DictReader(f)
    chrome_rows = [r for r in reader if 'chrome' in r['ExeInfo'].lower()]
for row in chrome_rows:
    print(f"{row['Timestamp']}  Sent: {row['BytesSent']}  Recv: {row['BytesRecvd']}")

Chrome had been running with heavy network usage despite the empty profile, daily, for at least two months. Daily totals around the download day (D):

Those upload ratios caught my attention immediately: sends consistently exceeding receives by nearly 2x. That is unusual for browsing, where you normally receive far more than you send. Was data being exfiltrated?

But SRUM only tells you how much data moved, not where it went. I needed DNS.

Network DNS logs: the full picture

The environment runs a cloud DNS-security service, which means every DNS query from every machine is logged. Incognito does not encrypt DNS (absent DoH, which this machine was not using). Every site the user visited in Incognito still generated a lookup the resolver captured.

I pulled the DNS log for the workstation on day D. Here is the attack chain reconstructed from query timestamps:

There it was. The user, whose job involves meal planning, was reading a legitimate recipe blog. That makes complete sense for their role. An ad served through the blog's ad network carried a malicious creative that loaded content from embed.filekitcdn[.]com, which redirected the browser to meal-formula[.]com. That domain served MealFormula.exe.

The entire chain took 40 seconds from ad load to payload download. The user did not go looking for this file. They were reading a recipe and a malicious ad hijacked their browser.

Campaign attribution

meal-formula[.]com is part of a documented malvertising campaign variously called FoodFormula or RecipeLister. It specifically targets food-service and healthcare workers: people likely to be browsing recipe sites, nutrition resources and food-ordering portals during the workday.

Related infrastructure:

• foodformulasetup[.]com, alternate landing page
• recipelister[.]com, alternate landing page
• sync.p7cloud[.]net, tracking and analytics beacon
• embed.filekitcdn[.]com, payload CDN

The typical payload is a Node.js-based infostealer: it drops a bundled Node.js runtime, extracts via 7-Zip, and runs a JavaScript payload that harvests browser credentials, cookies and crypto-wallet data. Characteristic artifacts are System.dll, a 7z-out directory, and Node.js processes spawning from unusual paths.

But this machine got the legitimate WinRAR installer instead. My theory is that the campaign was in a setup or testing phase when this user hit it. Malvertising campaigns rotate payloads, and serving a clean binary early helps them avoid detection while they test the redirect chain.

Full IOC sweep

Even with a clean payload, I was not taking that on faith. I swept for every known indicator of the campaign:

• System.dll: not present anywhere on disk
• Node.js: no runtime installed or extracted
• 7z-out directory: not found
• Persistence: no new scheduled tasks, no Run/RunOnce keys, no startup-folder entries
• Campaign payload hash B179BEC73EFE194BFFB69EEEDC8C136B5E7506A10B3589D223B1E6F8A8FBFB53: not present
• Network: no connections to campaign infrastructure

Registry forensics

Remote registry exports answered the remaining questions.

BAM (Background Activity Moderator) tracks last execution time per program. It showed chrome.exe last run two days after the download. The user kept using Chrome in Incognito after the incident, consistent with their daily pattern.

MountedDevices and PortableDevices. I needed to definitively rule out USB. HKLM\SYSTEM\MountedDevices held two entries, the NVMe system drive and a DVD drive. Zero USB storage devices had ever been connected. The PortableDevices key was empty. No phones, no thumb drives, no external disks. Ever.

Registry forensics is underrated for IR. BAM gives you execution timestamps without prefetch or amcache. MountedDevices plus PortableDevices ruled out USB delivery in seconds, via remote export, with no imaging.

Explaining the upload ratios

Those SRUM numbers still needed an explanation before I could close this out. The DNS log answered that too. The user's Incognito session on day D included a social network with video and photo uploads, a video-streaming site, a personal webmail and cloud-drive account, plus two legitimate work systems: a vendor ordering portal and the timekeeping system.

The upload ratios came from video-streaming protocols and social-media activity, not exfiltration. Video generates significant upstream traffic for quality negotiation, telemetry and connection maintenance. Add photo uploads and cloud-drive sync and the numbers make sense.

The user was doing personal browsing in Incognito to keep it off their work browser history, mixed with some legitimate work tasks. That is a policy conversation, not a security incident.

Key takeaways

SRUM defeats Incognito. Chrome leaves zero disk artifacts in Incognito, but SRUM tracks per-process network bytes at the OS level. Collect srudb.dat early: esentutl /y /vss grabs it while the file is locked.

Network DNS logging is your shadow browser history. Incognito cannot hide from DNS. The full session, including the exact attack chain, was reconstructed from query logs alone.

Malvertising targets specific industries. This campaign aims at food-service and healthcare workers through recipe and food-related sites. Legitimate sites deliver malware through their ad supply chain.

Not every known-bad domain means compromise. meal-formula[.]com belongs to a documented infostealer campaign, but the payload delivered here was a clean installer. The domain hit alone would have justified a full wipe if we had not dug deeper.

Image first, ask questions later. On a related case around the same time, the machine was wiped before full evidence was collected. Get the forensic image before remediation starts, even when the case looks like a false positive.

IOCs

Tools Endpoint detection and trajectory API · SrumECmd (Eric Zimmerman) · network DNS-security logs · Python and sqlite3 · remote registry export · sandbox analysis

← All research · Next case: a RAT hidden in PNG pixels →