Security Magic

TL;DR elevate.exe is an open-source UAC helper commonly bundled with Windows installers and Electron builds — usually legitimate, but sometimes recompiled/signed and abused by threat actors (observed in recent EvilAI, TamperedChef, and BaoLoader campaigns). I was reading through an article by TRUESEC , and one thing that struck myself and my peers was the elevate.exe file that exists in the samples that were analyzed. I mentioned to my peer that I see this file in many electron apps I've analyzed this year. We kicked around the idea of how to build detection for this, but we needed to understand what it is. Firstly, as pointed out by TRUESEC, elevate.exe is a tool by Johannes Passing, found on the github repo . The tool can be shipped/packaged with windows executables which, on their own do not elevate privileges, this helper will invoke UAC to elevate privileges of the designated application. Initially, after readi...

 Looking at sample: da3c6ec20a006ec4b289a90488f824f0f72098a2f5c2d3f37d7a2d4a83b344a0 AppSuites-PDF-1.0.28 Specifically looking at the malicious JS file loaded. pdfeditor.js (b3ef2e11c855f4812e64230632f125db5e7da1df3e9e34fdb2f088ebe5e16603). Once this is deobfuscated using  https://obf-io.deobfuscate.io/  I can launch this using node.exe --inspect-brk, then launch edge://inspect to step through the JS. This write-up is a work-in-progress of findings as I go. Here are some of the interesting screenshots so far:  _0x279589 is populated by iterating through and decoding the variables below it. After running through these, here is a list of strings extracted for this sample: A4FDDP7: "ew-key" A6C2XCU: "id" A6C7C7N: "add" A43AUWU: "0.0.0.0" A64CEBI: "usid" A6882RQ: "Url" B4CB2TX: "split" B5D13XX: "https://sdk.appsuites.ai" B5D95P7: "Item2" B5E9U50: "api/s3/event" B40DLY6: "process" ...

UPDATE: September 18, 2025  Another variant of what I've been looking at over the past week caught my eye today. Just wanted to give a real quick review of this, showing the POST encoding/decoding process. OpenMyManual.exe (9f948215b9ee7e7496ce3bc9e46fda56b50cc8905b88535225c7651007f660d5) Drops a copy of node.exe as well as a malicious JS file (2cd68ea7f02e8cfaded52d64c2cb71b64560b3799c948960db37e827618ff22d) Like in my last post, you can run this through a js deobfuscato, make a couple quick edits, and the run node.exe with the --insert-brk to set breakpoints and step through the program: What you eventually get is the C2 (api.evil.com/nss), the POST data, and how that POST data is being encoded and sent out to the C2. The 16 byte buffer is the XOR key, the 176 byte buffer is what becomes the Base64 (shown here as _0xda4df9).  To date, I have not got a response back from any of these C2's. I've looked at several of these, they all so far have a pattern like ^api.[a-zA-...

  **Update** After a bit of analysis, it looks like I can force the deobfuscated code to run by "patching" following bit: "return (await _0x324dc7(_0x26c49f.HKLM, "Software\\Microsoft\\Cryptography", "MachineGuid")).value;" Once that done, I can use --inspect-brk, use dev view and set a breakpoint at the end, on the eval. In Process Hacker I can see the POST. The Payload can be decoded in cyberchef, it's Base64 decode, send to HEX, use the first 16 bytes as an XOR key, then take the remaining HEX, (From HEX) and apply the XOR key. You will get something like: {"Event":"heartbeat","MachineId":"f4f34c43-9bc1-4a9a-b55f-1d4dd97e0e88","SessionId":"125cc3b3-bc56-474d-817b-badc96d07202","Version":"0.0.2","OSVersion":"10.0.26100","args":""} Since Args doesn't return anything, it's likely not weaponized yet. The deobfuscated...