Will Any of This Fire?
Palo Alto Unit 42 Threat Research: Tracking TamperedChef Clusters via Certificate and Code Reuse
Your manager forwards a threat report and wants to find out whether any detections would catch this campaign. You've found some that you think might fire and you're curious if there are community rules that could help. This post walks through answering these questions with the site search and assumes you've read the report.
The short version of the report: financially motivated clusters distribute trojanized productivity apps (PDF editors, calendar tools, ZIP utilities) through malvertising. Every first-stage binary carries a valid OV/EV code-signing certificate bought through shell companies. The apps install as 7-Zip self-extracting archives, profile the host, persist via scheduled tasks or registry Run keys, sleep for weeks, then fetch second-stage payloads (stealers, adware, proxyware) from per-campaign domains.
The method
Decompose the report into discrete behaviors, then run each behavior up the ladder. Each step answers a different question.
- Technique check: technique:T1053.005. What rules exist for Windows scheduled tasks?
- Predicate-leaf check: technique:T1053.005 indicator:=. What indicators are checked?
- Structural and telemetry pivots:
uses:,excludes:,with:,correlation:,has:. Given how this campaign executes, and given the telemetry you collect, would the rules fire?
The technique tag flatters you
Step one:
technique:T1053.005 returns 110 rules with all query languages represented. Scheduled task persistence coverage looks good.technique:T1053.005
Step two:
technique:T1053.005 indicator:*=* shows where those rules anchor. The top indicator is Image ends_with \schtasks.exe with 26 contributing Sigma rules, followed by OriginalFileName=schtasks.exe and process_name=schtasks.exe variants. There's about 100 indicator results and skimming quickly suggests many of these rules rely on schtasks.exe execution or the command-line, which would work on some clusters of the malware: the Trend Micro post referenced in the Unit 42 post does capture a literal cmd.exe /c schtasks /Create command.technique:T1053.005 indicator:*=*
However, there are other ways to register a scheduled task that don't involve the schtasks.exe process or command-line execution. You could use the PowerShell function Register-ScheduledTask (yes, it's a function, not a cmdlet) which invokes CIM/WMI > COM > RPC > the Task Scheduler service. value:Register-ScheduledTask matches 2 rules that use the PowerShell function. Additionally, while this isn't cited in the Unit 42 post, there is a G DATA analysis of the AppSuite PDF Editor that indicates another approach where tasks are registered with the Task Scheduler COM API.value:Register-ScheduledTask
Step three:
uses:TaskContent (rules that inspect Event ID 4698: A scheduled task was created task XML) matches 10 rules. This event fires regardless of registration method.uses:TaskContent
The lesson is to decompose a technique by the predicates that rules match on.
Telemetry decides whether anything fires
At install time, TamperedChef collects system version, hostname, active browsers, and in some intrusions patch levels, user and domain details, geolocation, and screen size.
technique:T1082,T1016,T1033,T1518 (System Information Discovery, System Network Configuration Discovery, System Owner/User Discovery, Software Discovery) returns 155 rules across all query languages.technique:T1082,T1016,T1033,T1518
Further investigation of the indicators behind those rules show a reliance on spawned discovery processes: Image=\systeminfo.exe, process_name=tasklist.exe, CommandLine substrings, PowerShell cmdlets. value:systeminfo alone returns 41 rules plus 10 indicators.value:systeminfo
Whether any of it fires depends on how the malware performs discovery and this isn't covered in the Unit 42 post. However, the G DATA post shows in-process collection through the app's bundled native module (get_sid(), GetPsList()) that probably doesn't use LOLBINs like tasklist.exe. This is a telemetry boundary rather than a detection gap. The Trend Micro post covers a cluster that shells out to powershell.exe running Get-WmiObject Win32_Process to find browser processes and inspects the registry for security products' uninstall strings.
value:Get-WmiObject returns 20 rules and 3 indicators anchored on ScriptBlockText and CommandLine, while the registry recon isn't covered in any rules (value:UninstallString, value:KasperskyLabSetup, etc).value:Get-WmiObjectvalue:UninstallString
Structural operators can help refine your query. technique:T1053.005 uses:CommandLine returns 55 of the 110 scheduled-task rules; technique:T1053.005 -uses:CommandLine returns the complementary 55. A shop without command-line auditing loses half that surface, and technique:T1053.005 uses:ParentImage shows only 9 rules survive without Sysmon parent attribution. The uses: / -uses: operators are a telemetry-dependency audit you can run per technique.technique:T1053.005 uses:CommandLineT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled Tasktechnique:T1053.005 -uses:CommandLineT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled Tasktechnique:T1053.005 uses:ParentImageT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled TaskT1053.005 Scheduled Task/Job: Scheduled Task
Run keys and browser hijack
There's mention of registry Run key persistence.
technique:T1547.001 (Boot or Logon Autostart Execution) has 84 resultstechnique:T1547.001T1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup FolderT1547.001 Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
value:CurrentVersion\Run shows 24 rules and 11 indicatorsvalue:CurrentVersion\Run
I'm not sure if there are other community rules that would be useful for this threat report. G Data's analysis shows browser hijacking by sending Chromium's Preferences and Secure Preferences files over C2, obtaining modified versions and writing them back - value:*Secure*Preferences* doesn't have any results.value:*Secure*Preferences*
Closing thoughts
The advanced search functionality is very useful to all sorts of teams: detection engineers, SOC analysts, incident responders, even red teams (for understanding the body of community rules and where coverage gaps may exist). If you found it helpful, I encourage you to contribute a novel detection to a public rule repo.
I built the event and rule catalogs because the existing sources of documentation were very fragmented and limited. There are maybe 300 events documented on Microsoft Learn in significant detail, with several hundred more documented on Ultimate Windows Security. There are as many as 965 events are recommended for collection by various sources and many of them are only documented in blog posts. I struggled to evaluate their importance for detections, and the large number of public rules and their distribution across different query languages made it harder. I hope this work helps make threat detection more tractable for practitioners.
The site is part of a larger personal effort to drive public information sharing and community collaboration. Aside from the catalogs and reference information, there are also free KQL labs with adversary emulation logs. There are two motivations behind building those labs: making this type of content available for free in a time when so much of it is gated behind paywalls, and coaxing folks into sharing interesting logs for community collaboration on detections.
Threat actors are armed with modern tools and moving faster than ever after gaining initial access. My ultimate goal is to convince folks to publish logs with their threat research posts like they do with file hashes. This will help defenders write, validate, and deploy detections in hours instead of days to weeks. I need your help to do this. If you agree its important, talk to decision makers in your org. This will engender goodwill among customers, prospective customers, and prospective talent.
My next major project will involve analysis of modern tools and publication of execution logs (and packet captures when relevant). It is inspired by the JPCERT/CC Tool Analysis Result Sheet and will include new telemetry sources.
Thanks for reading.
References
Palo Alto Unit 42 - Tracking TamperedChef Clusters via Certificate and Code Reuse
Trend Micro - EvilAI Operators Use AI-Generated Code and Fake Apps for Far-Reaching Attacks
G DATA - AppSuite PDF Editor Backdoor: A Detailed Technical Analysis
Jonathan Johnson - WMI Internals Part 2