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 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.


YJ's Findings

Running a Type 1 file (Foreign Compiled Files)

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:

By blocking Type 1 execution, it disrupts a majority of Execute-After-Write file-based malware problems, but without the pain of typical Application-Control/Whitelisting. This forces adversaries to use Type 2/Type 3 Code-Execution for payload delivery.

Below are my attempts to bypass this app control method:

*Side note: I am using 7-Zip.exe for my attempts.

Attempt 1: Run the executable file without exe extension using command prompt

Step 1: Change the file extension from .exe to .notexe

Step 2: Run the file using cmd