The interesting thing to me is that the techniques you are talking about get lit up like a Christmas tree by some modern endpoint protection products, whereas a backdoored Electron app is squeaky clean on Virustotal...

This is untrue. A "backdoored" native app (i.e. an app where an executable or DLL was modified) would also be squeaky clean.

No, if you embedded malicious code (say a full blown RAT, like this tool gives you) into an exe, modern av models will do static analysis of that code and flag it as potentially malicious. Because none of the JavaScript code in this backdoored electron app is even looked at by any engine(none of the engines on virustotal do analysis of JavaScript) the binary features are indistinguishable from the legitimate version.

Backdoored ccleaner flagged as malicious by multiple ml based products: https://www.virustotal.com/gui/file/6f7840c77f99049d788155c1...

Backdoored xmanager flagged by multiple ml based products: https://www.virustotal.com/gui/file/d484b9b8c44558c18ef6147c...

Countless other examples.

True, but those are backdoored apps whose signatures has been identified and stored in some AV database. The solution is (provably) impossible to generalize with static analysis. Clearly, it's also reactive (people need to report the backdoored application before you know its signature). There are also fairly well-documented ways to get around this signature-approach to AV (polymorphism comes to mind).

No, signatures have nothing to do with this. The ml models embedded in those products (and what is evaluated on Virustotal) can flag legit software that has had a RAT executable inserted in it by modifying the binary. The ml models are trained on thousands of features, and are pretty good at classifying malware. USCYBERCOM has been tweeting APT malware that was not seen by these models or anyone in the public, and yet was still flagged. https://twitter.com/CNMF_VirusAlert . That would be completely impossible if these products were relying on signatures. Regardless, the entire point I was making in my original comment is that this article is far from clickbait nonsense, because you have a chance, significant from what I've seen, of flagging something like the backdoored pieces of software I linked or never before seen malware like in the tweets above because the malware exists as compiled code. JavaScript is currently not evaluated whatsoever by ANY software security product, so the chances of it being flagged and blocked is 0. Signatures and polymorphism are 10 years ago quite frankly. Backdoored Slack exfilling data in steganographic images over https to giphy.com and instagram and twitter and shit is one future realm of malware. Both the binary and the network traffic are completely indistinguishable from legitimate usage.

The claim is it's easier to bypass some app integrity protection mechanisms when the target is an Electron app.

"easier" than what? and is it particularly noteworthy? if malicious code has write access to any given app's constituent files, there's effectively no app that's hard to subvert.

Easier than apps that are better covered by system app integrity protection? I'm not sure what's unclear about this, it's right in the writeup.

If you're talking about installing apps, every installed app needs to be signed (unless you ignore Windows/macOS warnings). If you're talking about injection or modifying program files (be them executables, DLLs, or ASARs) post-install, every app is equally-vulnerable. There is no functional difference between a native app or an Electron app in that regard, so maybe you can clarify what you mean by "system app integrity protection."

I wasn't trying to be snippy, I genuinely didn't understand what you meant since the term "system app integrity protection" isn't anywhere in the original blog post. Also, just to clarify, by "functionally equivalent" I meant "exactly the same."