What's the point with that Code-Execution model, one might ask? Just a backstory as to why OpenEDR was developed. Almost 4 years ago, I started a small squad of Test-&-Evaluation engineers. We were figuring out how to evaluate COTS "security" products. During our malware sandbox evaluation, I noticed this fetish for EXEs which got me asking: "are you sure that this is the only way to run malicious codes?". That got me looking at AppLocker (or any App-Whitelisting) evasion, which was the pre-cursor to what is known as Living-off-the-Land that we often see today.
So when I read reports like https://www.bleepingcomputer.com/news/security/fbi-conti-ransomware-attacked-16-us-healthcare-first-responder-orgs/. First thing first is to take the malware name, then append " technical analysis" to the name & GOOGLE. You will likely find CarbonBlack or Vipre's analysis as the first two results. From the latter, you see that there is a conti.exe in one of their screenshots. At this point, I will not be bothered & can confidently conclude that OpenEDR will disrupt this attack-flow without spending so much time into the details, unless the report states possibility of remotely injection without touching the disks.
This is the benefit of such a mental model, it saves you time & energy to zoom into the pertinent details.
OpenEDR blocks the execution of Type 1 files e.g. executable/dll files. This is shown when I tried to run an executable file on the Windows VM:
Below are my attempts to bypass this app control method:
*Side note: I am using 7-Zip.exe for my attempts.
Step 1: Change the file extension from .exe to .notexe
Step 2: Run the file using cmd
