Published on by

As if you needed more reasons not to trust CrowdStrike after that Falcon fiasco which crashed 8.5 millions of Windoows PCs worldwide due to shoddy QA processes and having a poorly written script interpreter in a Windows kernel-mode driver, right?

Yesterday I wrote about "Security" vendors to avoid in 2025 after my tool ME3Buyer got flagged as malicious by several less than reputable "security" vendors due to their over-reliance on AI/ML heuristic analysis.

Today I am going to write about CrowdStrike's scanner, and their "analysis" of my tool which at the time of this writing is also flagging it as grayware with threat score of 55/100 — you are in for a deep dive into why AI/ML and other heuristic "analysis" used by CrowdStrike and possibly those other vendors is actually just fearmongering and why those results are anything but reliable.

Anti-Detection/Stealthyness

Contains ability to impersonate access tokens (API string)
Found reference to API "OpenProcessToken" (Indicator: "OpenProcessToken"; File: "ME3Buyer.exe")

The reason why this indicator is useless without context is that it can only be used for impersonation if you open a different process token, not your own.

Contains ability to load/free library (API string)
Found reference to API "LoadLibraryA" (Indicator: "LoadLibrary"; File: "ME3Buyer.exe")

This indicator is even more useless, as almost every Windows executable contains this call.

Anti-Reverse Engineering

PE file contains zero-size sections
Raw size of "UPX0" is zero

This indicator is as useless as previous ones. UPX packer is a well-known tool and its compression is fully reversible.

Cryptographic Related

Sample file has high entropy (likely encrypted/compressed content)
Sample file "sample.bin" has high entropy 7.852839850308484

No shit Sherlock, it's compressed with UPX, of course it has high entropy.

Shows ability to obfuscate file or information
The analysis contains indicators for cyrpto or data obfuscation(base64/decrypt) which can hide information. Matched sigs: Sample file has high entropy (likely encrypted/compressed content)

Neither base64 nor any other form of encryption is used in the code so this is a false flag.

Environment Awareness

Able to identify virtual environment by using user activity (API string)
Found string "GetCommandLineA" (Indicator: "GetCommandLine"; Source: "00000000-00003372-00000C2A-3253035874")
Found string "GetCommandLineW" (Indicator: "GetCommandLine"; Source: "00000000-00003372-00000C2A-3253035903")

Yeah, and if you checked the PE header and saw it's a console application of course it is using the command line... idiots.

Able to visualize and control listed components (API string)
Found reference to API "FindWindowW" (Indicator: "findwindow"; Source: "00000000-00003372-00000C2A-3253112167")
Found reference to API "PostMessageW" (Indicator: "postmessage"; Source: "00000000-00003372-00000C2A-3253112914")

Again analysis of individual APIs bundled together without context. FindWindow is used to find the game window, but PostMessage is used to send messages to its own overlay window. They aren't used together.

Calls an API typically used to get system version information
"ME3Buyer.exe" called "RtlGetVersion" with parameter 140100000a000000000000005d5800000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (UID: 00000000-00003372)

No, my executable didn't call that API -- it's not even in the IAT (iimport address table). They can't even separate who did what and we should trust their "analysis"?

Calls an APIs used to retrieve process information
Observed import api "OpenProcessToken" which can be "used to retrieve process information" [Source: ME3Buyer.exe]

Same as indicator 01, and equally useless. Yes, a process can get information about itself. Brilliant "analysis" really.

Contains ability to read software policies
"ME3Buyer.exe" (Path: "HKLM\SOFTWARE\POLICIES\MICROSOFT\WINDOWS\SAFER\CODEIDENTIFIERS"; Key: "TRANSPARENTENABLED")

Now this is an outright lie, as the following Microsoft documentation about SRP (Software Restriction Policies) will tell you:

- The user-mode Windows CreateProcess function in %SystemRoot%\System32\Kernel32.dll enforces it for executable images
- The DLL loading code of Ntdll (%SystemRoot%\System32\Ntdll.dll) enforces it for DLLs
- The Windows command prompt (%SystemRoot%\System32\Cmd.exe) enforces it for batch file execution
- Windows Scripting Host components that start scripts—%SystemRoot%\System32\Cscript.exe (for command-line scripts), %SystemRoot%\System32\Wscript.exe (for UI scripts), and %SystemRoot%\System32\Scrobj.dll (for script objects)—enforce it for script execution

Each of these components determines whether the restriction policies are enabled by reading the registry value HKEY_LOCAL_MACHINE\Software\Microsoft\Policies\Windows\Safer\CodeIdentifiers\TransparentEnabled, which if set to 1 indicates that policies are in effect.

So basically they are flagging my executable for registry key access done by the OS loader itself, retards.

General

Calls an API typically used to load libraries
"ME3Buyer.exe" called "LoadLibrary" with a parameter api-ms-win-core-synch-l1-2-0 (UID: 00000000-00003372)
... (long irrelevant list od DLLs goes here)

First, no it didn't -- the UPX unpacking code called it as it was resolving imported libraries.

Second, all Windows programs use standard Windows libraries listed -- they literally couldn't work without them.

Calls an API typically used to retrieve function addresses
"ME3Buyer.exe" called "GetProcAddress" with a parameter InitializeCriticalSectionEx (UID: 00000000-00003372)
... (long irrelevant list od APIs goes here)

Another wrong attribution of behavior of the UPX unpacker to the packed executable itself.

Contains ability to dynamically determine API calls
Found GetProcAddress() and LoadLibraryA() in an import section (Source: ME3Buyer.exe)

Again, part of UPX unpacking code and irrelevant to the analyzed executable code itself.

Contains ability to execute Windows APIs
Found reference to API (Indicator: "OpenProcessToken"; File: "ME3Buyer.exe")
... (long irrelevant list od APIs goes here)

A program built for Windows platform contains ability to execute Windows APIs? You don't say!

This "indicator" is so retarded that it doesn't deserve any further comments.

Contains ability to retrieve/open a process (API string)
Found reference to API "OpenProcessToken" (Indicator: "OpenProcess"; File: "ME3Buyer.exe")

Another repeat of indicators 01 and 09 — if you repeat a lie enough times then it might just become true?

File contains dynamic base/NX flags
"ME3Buyer.exe" has flags like IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA
IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
IMAGE_DLLCHARACTERISTICS_NX_COMPAT
IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE

And this is bad how? Those are standard flags that are added to INCREASE code security.

Loads modules at runtime
"ME3Buyer.exe" loaded module "API-MS-WIN-CORE-SYNCH-L1-2-0" at base 7ffc6cc30000
... (long irrelevant list od DLLs goes here)

And? Find me one Windows application, console or otherwise which doesn't. I dare you, I double-dare you, motherfuckers!

Loads the RPC (Remote Procedure Call) module DLL
"ME3Buyer.exe" loaded module "%WINDIR%\System32\rpcrt4.dll" at 6EA90000

RPCRT4.dll is not even in the IAT (iimport address table) of my executable! It must have been injected by some other process running in a sandbox, most likely by some vendor's "security" software. If you take a look at the list of modules loaded there is this entry:

"ME3Buyer.exe" loaded module "%WINDIR%\TEMP\VXOLE64.DLL" at base 7ffc47f20000

It's not a module my tool was linked against so it is likely injected by the OS or the scanner / sandbox environment itself and I can bet that it's the one bringing RPCRT4.dll in — OLE stands for Object Linking and Embedding Automation which is pretty much a definition of inter-process communication which would rely on remote procedure calls. Again, they can't even tell who did what. How do you even begin to trust such "analysis"?

Matched Compiler/Packer signature (DIE)
"ME3Buyer.exe" was detected as "UPX" and name: "Packer"

Well perhaps you could use that information to unpack it since upx is fully reversible and then scan it? Nah, that would be too much work — easier to just claim that every packed executable is suspicious.

Possibly uses system binaries (Windows LOLbins)
Observed system executable string:"\Device\HarddiskVolume3\Windows\System32\conhost.exe" [Source: 00000000-00003372-00000BC0-3251731136]

Again, not in my code. Not even in UPX code. Atrociously inaccurate analysis.

The input sample is signed with a certificate
The input sample is signed with a certificate issued by "CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US" (SHA1: 95:B5:F0:2E:48:58:8F:8D:6A:42:6F:AC:5C:85:F8:6B:9D:BD:22:72; see report for more information)
The input sample is signed with a certificate issued by "CN=SSL.com Code Signing Intermediate CA ECC R2, O=SSL Corp, L=Houston, ST=Texas, C=US" (SHA1: 67:BF:EC:D3:2A:46:97:9B:0A:6F:69:E4:91:4D:D5:CC:CF:B3:3E:63; see report for more information)
The input sample is signed with a valid certificate
The entire certificate chain of the input sample was validated successfully.

So now it's bad to sign your code with a valid certificate? Pathetic fearmongering.

Installation/Persistence

Contains ability to load modules (API string)
Found reference to API "LoadLibraryA" (Indicator: "LoadLibrary"; File: "ME3Buyer.exe")

A repeat of indicator 02, again on it's own isn't a proof of any wrongdoing.

Opens registry keys
"ME3Buyer.exe" (Access type: "OPEN"; Path: "HKLM\SYSTEM\CONTROLSET001\CONTROL\NLS\CODEPAGE"; Key: ""; Value: "")
... (Long list of irrelevant REG keys goes here)

Another misatribution of behavior, this time of the OS loader which is reading those keys on EVERY process launch, to the executable being run.

Queries basic information of the specified process
"ME3Buyer.exe" queries basic process information of the "C:\ME3Buyer.exe" (UID: 3372)

Yes it does, and? It's a common practice to check for elevation if your tool needs admin privileges to run.

Shows ability to use execution guardrails
The analysis shows indicators which can be used as execution guardrails to ensure that payload only executes against intended targets/system. Matched sigs: Able to identify virtual environment by using user activity (API string)

This isn't elaborated upon at all with any concrete evidence so it's unclear what it means. Yes, many programs have the ability to check for some pre-requisites before they continue to run in order not to crash.

Touches files
"ME3Buyer.exe" trying to touch file "%WINDIR%\System32\apphelp.dll"
... (long irrelevant list od files goes here)

Sigh... yet another misatribution of behavior of the execution environment itself to the executable being analyzed. At this point I am convinced that the whole "security" industry is one giant scam. First they scare you with "that's a nice executable you have there, it would be bad if something happened to it" and then they offer you "protection" by making everyone involved (users and developers alike) pay an extortion racket — users pay to be "protected" from those nasty developers, and developers pay to get whitelisted. It's a win-win scenario for "security" vendors and pretty much no one else and it's high time for someone to call them out on their bullshit.

Network related

Found potential URL in binary/memory
Pattern match: "http://www.ssl.com/repository/sslcom-rootca-ecc-384-r1.crt0"

Yeah, that 0 at the end shows they can't even get the zero-terminated strings right (hint: 0 is not part of that string). But a link to a root certificate in an executable signed by a commercial IV code signing certificate sure sounds dangerous, right? What a bunch of tools... no, fucktards. There are no words insulting enough that I can say to people working on producing this scam.

Possibly tries to communicate over SSL connection (HTTPS)
Found HTTPS url "https://www.ssl.com"
Found HTTPS url "https://levicki.net"

Possibly? Look, it either does or doesn't. What the hell does "possibly" even mean?

Those strings are part of a certificate bundle with which the executable is signed and SpcSpOpusInfo respectively used by SmartScreen so they aren't used to communicate but don't let that stop you from making false claims — after all, "corporations are people" who, apparently, can't be held liable for anything including defamation.

Spyware/Information Retrieval

Calls an API typically used for taking snapshot of the specified processes
"ME3Buyer.exe" called "CreateToolhelp32Snapshot" with parameters {"dwFlags": "4", "th32ProcessID": "0"}

No it doesn't as it's not in IAT, it's either UPX unpacker or the OS loader or an indirect call by Windows API. More unproven claims, and all of them LIES.

Contains ability to capture screen (API string)
Found reference to API "GetDC" (Indicator: "GetDC"; File: "ME3Buyer.exe")

Yes it does contain GetDC call -- it uses it to query LOGPIXELSY on a desktop DC so it can create a 14pt font at 72 DPI for using in an overlay window which shows operation progress. If the "security" scanner actually analyzed the code as they falsely claim to do it would see this:

const HDC hDC = GetDC(nullptr);
int Height = -MulDiv(14, GetDeviceCaps(hDC, LOGPIXELSY), 72);
ReleaseDC(nullptr, hDC);
g_hFont = CreateFont(Height, 0, 0, 0, FW_BOLD, FALSE, FALSE, FALSE, DEFAULT_CHARSET, OUT_TT_ONLY_PRECIS, CLIP_DEFAULT_PRECIS, CLEARTYPE_QUALITY, VARIABLE_PITCH, L"Arial");

So another useless "Indicator" taken out of context and more lies and false flags. But wait, there is more "malicious" code in my tool, and they didn't even see it:

HDC GameDC = GetWindowDC(GameWindow);
COLORREF Color = GetPixel(GameDC, value.pt.x, value.pt.y);
ReleaseDC(GameWindow, GameDC);

Oh my God! It's reading pixels from the game window! They flagged GetDC as potentially malicious for screen capture when it was only used to create a font for text output, but not GetWindowDC and GetPixel which I actually use to read game window content in order to automate lootbox purchasing. Good job, eh?

Contains ability to terminate a process (API string)
Found reference to API "ExitProcess" (Indicator: "ExitProcess"; File: "ME3Buyer.exe")

This one sounds like a LLM hallucination and if it wasn't sad it would be funny. EVERY executable linked against C runtime contains call to ExitProcess. You can only terminate your own process with it, not other processes. The fact that they include this as "indicator" shows how much their business model relies on scaring people into paying for their products.

Queries services related registry keys
"ME3Buyer.exe" (Access type: "QUERYVAL"; Path: "HKLM\SYSTEM\CONTROLSET001\SERVICES\BAM\STATE\USERSETTINGS\S-1-5-21-1271187874-1938232448-3812392235-1001"; Key: "\DEVICE\HARDDISKVOLUME3\WINDOWS\SYSTEM32\CONHOST.EXE"; Value: "")

Nope, it doesn't — it's another misatribution, this time from Microsoft Defender Boot Anti-Malware to the executable being scanned.

TL;DR — The analysis falsely flags common and harmless behaviors, such as standard API calls, UPX packing, and system-level operations, as malicious without proper context. It misattributes OS loader, unpacker, and even sandbox / scanner actions to the executable being scanned. Overall, the analysis overstates risks by failing to distinguish between routine program behavior and actual threats, resulting in an alarmist and inaccurate security assessment which highlighs flaws in the security industry’s automated scanning methods.

I am not going to address all the ridiculous "indicators" they show as "proof" that my tool is malicious. Next time you see CrowdStrike Falcon "detection" on VirusTotal unless it is corroborated by at least ESET and Windows Defender do yourself a favor and put it on the malicious "security" vendors list together with others I listed in my previous article.