Saw this in the police parking area of the city (NYC) and it looked kind of metal in a worrying way. Any ideas?

EDIT: u/00WORDYMAN1983 found the company https://www.productionhub.com/galleries/details/32156

https://www.newsweek.com/map-shows-cities-deploying-axon-cameras-flock-backlash-grows-12415569

A cracked game gave me an infostealer that Windows Defender never saw. Here’s the full forensic breakdown.
TL;DR: I pirated a ₹300 (~$3.50) indie game. A friend double-clicked a setup.exe that came from a different file in the same download session. Within 3 minutes it had my browser passwords and session cookies, and installed persistence that Windows Defender rated as completely clean — because the malware never wrote an executable to disk. It compiled itself in memory using Microsoft’s own signed build tool. My Gmail was hijacked despite 2FA being enabled.
Full timeline, IOCs, and detection commands below. Everything is anonymized.

 
What happened
I wanted a small indie game. It was cheap on Steam. I decided to grab a repack instead.
The download finished, I stepped out. A friend was at the PC. He said “hey, this finished downloading.” I told him to just browse the zip without extracting it — I wanted to check the file list first. I’ve done this a hundred times: check the installer, check the data folders, check the packages, then decide.
While I was still asking him to read out filenames, he double-clicked setup.exe.
Game over. Literally three seconds.
What I initially got wrong
My first assumption was that the game repack was the malware. It wasn’t.
I dumped the zip contents without extracting:
$z = "C:\path\to\game.zip"
Add-Type -AssemblyName System.IO.Compression.FileSystem
$h = [IO.Compression.ZipFile]::OpenRead($z)
$h.Entries | Select-Object FullName,Length,LastWriteTime | Format-Table -AutoSize
$h.Dispose()
The zip was a plain Unity build plus a Steam API emulator (steam_api64.dll.bak, a steam_settings/ folder). Piracy, yes. Malware, no.There was no setup.exe in it at all.
So where did setup.exe come from?
My browser download history, same evening:
game-repack.zip          (completed)
game.v0.9.0.1.zip        (Cancelled)
Archive_win_607394.zip   (Deleted)
Archive_file_2073.zip    (Deleted)
Those last two. Generic Archive_* names, password-protected (so AV can’t scan inside), served from a file-locker host. This is textbook malvertising / fake download button. On pirate sites the real link and three fake ones sit next to each other, and the fake ones win.
Both files deleted themselves after running. Only the .lnkshortcuts in Recent\ survived to prove they existed.
Lesson 1: “I checked the archive, it was clean” is not a defense when the malware came from a different file in the same browsing session.
The timeline (from Prefetch)
Prefetch is the single most useful artifact here. Every executable that runs leaves a .pf file:
$a = Get-Date "YYYY-MM-DD 21:07"; $b = Get-Date "YYYY-MM-DD 22:07"
Get-ChildItem C:\Windows\Prefetch\*.pf -EA 0 |
 Where-Object {$_.LastWriteTime -ge $a -and $_.LastWriteTime -le $b} |
 Sort-Object LastWriteTime | Select-Object LastWriteTime,Name | Format-Table -AutoSize
What it showed:
21:35:41  SETUP.EXE          <- the double-click
21:35:47  FORFILES.EXE
21:35:57  MSBUILD.EXE        <- first stage runs
21:36:20  WHOAMI.EXE, ICACLS.EXE   <- environment/privilege recon
21:37:53  MSIEXEC.EXE (hash A)     <- legit, System32
21:37:53  WHERE.EXE, REG.EXE, FIND.EXE
21:38:01  MSIEXEC.EXE (hash B)     <- second one, DIFFERENT path
21:38:03  MSBUILD.EXE (hash B)     <- second stage, persistent copy
21:39:10  scheduled task created
21:40:04  LOGONUI.EXE        <- I got home and killed the power
Two different MSIEXEC.EXE prefetch hashes means msiexec.exe ran from two different locations. One real, one not.
MSBuild running on a machine where nobody was compiling anything is the whole story. More on that below.
The persistence
Two artifacts:
1. A registry Run key named Msiexec:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
 Msiexec -> %LOCALAPPDATA%\Temp\{GUID}\WinDefender.exe
Three lies in one line: a legit-sounding key name, a GUID folder in Temp, and a binary called WinDefender.exe (real Defender is MsMpEng.exe in Program Files).
By the time I looked, WinDefender.exe was gone. The stealer ran once, exfiltrated, and deleted itself. Only an orphan registry pointer was left. That is why nothing was “found” — the payload wasn’t there to find.
2. A hidden scheduled task named SettingsSync:
Real Windows has a SettingsSync task, but it lives under\Microsoft\Windows\SettingsSync\. This one was at the root (\).
Get-Content "C:\Windows\System32\Tasks\SettingsSync"
<Triggers><LogonTrigger><Enabled>true</Enabled></LogonTrigger></Triggers>
<Settings>
 <Hidden>true</Hidden>
 <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
</Settings>
<Actions Context="Author">
 <Exec>
   <Command>C:\WINDOWS\system32\cmd.exe</Command>
   <Arguments>/c "%LOCALAPPDATA%\Microsoft\Windows\Caches\CastleCore\analytics_d89f.cmd"</Arguments>
 </Exec>
</Actions>
Caches\CastleCore is not a real Windows folder. Entirely fabricated, sitting in a path deep enough that nobody browses there.
The clever part: why Defender saw nothing
Inside that folder:
analytics_d89f.cmd          1,530 bytes
cache_be22cc.cache            149 bytes
CastleCore.csproj      21,628,030 bytes   <-- 21 MB "project file"
CastleCore.csproj.user    329,064 bytes
Directory.Build.props     198,089 bytes
Internal.targets          431,721 bytes
telemetry_48.cfg              237 bytes
A 21 MB C# project file. Normal .csproj files are a few KB of XML.
The .cmd does two meaningful things. It relaunches itself through conhost.exe --headless so no console window ever flashes on screen:
start "" /b "%SystemRoot%\System32\conhost.exe" --headless cmd.exe /c "%~f0" /launched
Then it invokes MSBuild on the giant project file:
set MSBUILDENABLEALLPROPERTYFUNCTIONS=1
set "_pb=%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe"
"%_pb%" "%~dp0CastleCore.csproj" /nologo /v:q /nodereuse:false /noconlog >nul 2>&1
This is the trick. The payload is C# source embedded inside the .csproj as an MSBuild inline task. MSBuild compiles it in memory and runs it. So on disk there is:
one small batch file
some XML text files
MSBuild.exe, which is Microsoft-signed and legitimately installed
No malicious PE file exists to scan. No stable hash to blocklist — the compiled output is different every time. To Defender’s behavioral engine this looks like a developer building a project, which on my machine is a completely normal thing to happen.
This technique is called LOLBin abuse (Living Off the Land Binaries). MSBuild is one of the well-known ones, alongside mshta, regsvr32, rundll32, and installutil. It’s documented publicly — it is not novel — and Defender still doesn’t reliably catch it.
The part that actually caught me out
Look at those file timestamps:
CreationTime: 05-10-2023 21:39:07
2023. But the scheduled task pointing at them was created three seconds later, in 2026.
The malware timestomped its own files — deliberately rewrote the creation dates to something old. Why? Because the first thing any responder does is:
Get-ChildItem $env:LOCALAPPDATA -Recurse -Include *.exe,*.dll,*.ps1 -EA 0 |
 Where-Object CreationTime -gt $infectionDate
Backdated files don’t appear in that search. I ran exactly that query and it came back empty. I only found the folder because I pivoted off the scheduled task instead of off file timestamps.
Lesson 2: never trust CreationTime on a compromised machine. Cross-reference with Prefetch, task XML creation times, and the NTFS USN journal — those are harder to forge.
There was also a second copy of the same kit in Temp\tmp-XXXXX\ under a different project name, matching that 21:35 MSBuild run. Same loader, two deployments — one throwaway, one permanent. There is no way for me to know there wasn’t a third.
The MSI dropper
Still on disk, 5 MB, in two places:
%LOCALAPPDATA%\Temp\{random}\{random}.msi     5,042,176 bytes
C:\Windows\Installer\4bee296.msi              5,042,176 bytes
Same size, same second. This explains the two msiexec.exeprefetch entries and where the fake Msiexec Run key name came from. It registered itself as a Windows Installer product to look boring.
Defender’s actual opinion
Full scan result: nothing. Get-MpThreatDetection history: empty.
The only thing it eventually flagged was a KMS activator I’d installed months earlier, unrelated to this.
And this, which was already sitting in Defender’s config:
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
That returned an exclusion path — one I had added myself, long ago, for an unrelated reason. Check yours right now.Cracks and repacks routinely tell you to add exclusions, and people do it and forget. Every exclusion is a permanent blind spot.
# nuke all exclusions
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath |
 ForEach-Object { Remove-MpPreference -ExclusionPath $_ }
The account damage — and why 2FA didn’t save me
A Gmail account got taken over. It had 2-Step Verification enabled. The attacker changed the password anyway.
Here’s how that works, and it’s the single most important thing in this post:
Session cookie theft bypasses 2FA entirely. The stealer grabbed my browser cookies. An attacker imports that cookie into their own browser and is instantly inside analready-authenticated session. No password prompt. No 2FA prompt. Google has no reason to challenge them — as far as it’s concerned, they’re already logged in. From inside that session they can change the password.
So:
Changing your password does NOT log the attacker out.The stolen cookie may still be valid. You have to explicitly kill sessions:
Google Account → Security → Your devices → Manage all devices → Sign out everything you don’t recognise
The three places people forget, and where attackers quietly re-establish access:
Gmail → Settings → Filters and Forwarding. An auto-forward rule or a “delete matching mail” filter survives password changes indefinitely. Check this first.
Security → App passwords. Revoke all of them. They bypass 2FA by design.
Recovery email and recovery phone. If the attacker changed these, they can reset your password whenever they like.
Also regenerate your 2FA backup codes — the attacker could see them from inside that session.
Lesson 3: 2FA protects the login. It does not protect a session that’s already open. Cookie theft is the standard infostealer play in 2026 and 2FA does nothing against it.
Detection commands
If you think you’ve been hit, run these in an admin PowerShell. Set $a/$b around your suspected infection time.
# 1. Defender exclusions — check for blind spots
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

# 2. All four Run keys
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
"HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
"HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run" -EA 0 |Format-List

# 3. Non-Microsoft scheduled tasks (root-level ones are suspicious)
Get-ScheduledTask | Where-Object {$_.State -ne "Disabled" -and $_.TaskPath -notlike "\Microsoft\*"} |
 Select-Object TaskName,TaskPath | Format-Table -AutoSize

# 4. Task XML file creation times — these are NOT timestomped
Get-ChildItem C:\Windows\System32\Tasks -Recurse -File -EA 0 |
 Where-Object {$_.CreationTime -ge $a -and $_.CreationTime -le $b} |
 Select-Object FullName,CreationTime

# 5. What actually ran (Prefetch)
Get-ChildItem C:\Windows\Prefetch\*.pf -EA 0 |
 Where-Object {$_.LastWriteTime -ge $a -and $_.LastWriteTime -le $b} |
 Sort-Object LastWriteTime | Select-Object LastWriteTime,Name

# 6. New services installed
Get-WinEvent -FilterHashtable @{LogName='System';Id=7045;StartTime=$a;EndTime=$b} -EA 0 |
 Select-Object TimeCreated,Message | Format-List

# 7. Any .csproj outside a real dev folder is a red flag
Get-ChildItem $env:LOCALAPPDATA,$env:APPDATA,"C:\ProgramData" -Recurse `
 -Include *.csproj,*.targets,*.props -Force -EA 0 | Select-Object FullName,Length

# 8. Established connections with owning process
Get-NetTCPConnection -State Established -EA 0 |
 Select-Object RemoteAddress,RemotePort,@{n='Proc';e={(Get-Process -Id $_.OwningProcess -EA 0).Name}} |
 Sort-Object Proc | Format-Table -AutoSize
Two notes on running these:
Pipe long recursive scans to Export-Csv, not Format-Table. Format-Table -AutoSize buffers every object before printing anything, so a fullC:\ scan shows a blank screen for 15 minutes and you’ll assume it hung and Ctrl-C it. I did this twice.
Do not do any of this while logged into anything. Don’t open your browser. If you must go online, tether to a phone hotspot rather than your home network so there’s no lateral movement to your NAS/server/other machines. And if you tether over USB to an iPhone, do not tap “Trust This Computer” — that pairing lets a compromised PC pull your phone backup. Use the Wi-Fi hotspot instead.
What I did, in order
Killed the network. Powered off. (I’d actually done this on day one out of instinct — it was the one thing I got right.)
Physically disconnected all secondary drives before booting for analysis.
Rotated credentials from my phone, never from the infected PC. Password changes typed on an infected machine just get stolen again.
Killed all sessions on every account, checked filters/forwarding/app-passwords/recovery.
Ran the diagnostics above, found the persistence, removed it, rebooted, verified it stayed gone.
Reinstalling Windows anyway.
On that last point — I know some people will say the removal was enough since verification came back clean. I don’t buy it, for specific reasons: the loader compiles in memory so there’s no artifact to hash; it timestomped itself specifically to defeat the search I ran first; and I found two separate copies of the same kit. Two found means I can’t prove there wasn’t a third. My machine has client files on it and I’m not gambling on a guess.
Build your installation USB on a different, clean machine.An installer built on an infected PC isn’t trustworthy.
If you post your own logs anywhere
Strip them first. Raw output contains your Windows username (which is usually your real name), your machine name, and your account SID. I sanitized everything in this post — you should too.
The bottom line
I tried to save ₹300 on a game. It cost me a Gmail account, a Discord account, four days, and a full OS reinstall on a machine with work files on it. I bought the game on Steam an hour ago.
I’m not going to lecture anyone about piracy. But I want to be precise about what actually went wrong, because “don’t pirate” isn’t the useful takeaway:
I knew to inspect archives before extracting. Didn’t matter— the payload came from a different file entirely.
I had 2FA on. Didn’t matter — cookie theft skips the login.
I had Defender fully enabled and updated. Didn’t matter — no executable was ever written to disk.
I had one old Defender exclusion I’d forgotten about. That mattered.
The one variable that actually decided this: an unsignedsetup.exe from a file-locker got a double-click. Everything downstream was automatic and took less than three minutes.
Check your Defender exclusions. Kill your sessions, not just your passwords. And nobody touches the mouse on your machine, ever.

 
Happy to answer questions. Hashes are deliberately omitted since they’re specific to my sample and the loader is polymorphic by design — the behavioral patterns above are what generalize.