jt0dd/binary obfuscation

## binary obfuscation
Binary obfuscation employed thoroughly. It is prevalent to note the distinction between preventing reverse engineering and preventing fingerprinting. A tool that makes software incredibly difficult to reverse-engineer often involves binary obfuscation structures that would be trivial to fingerprint.


Employ memory and data scraping prevention. If a program saves a string in memory, ensure it is represented in a randomized, encoded manner to avoid behaving as a signature via memory scraper. If the original executable contains any image or alternate data, ensure this is obfuscated randomly and effectively before delivery to the target.


Evade AV emulation (pre-execution) detection products via black box attacks. See AVLeak, Blackthorne et al (video presentation if preferred, Blackhat 2016).


Evade EDR (post-execution) solutions by masking I/O behavior through obfuscation (combined with the payload not doing anything obviously malicious).


Decoy logic outnumbering the malicious logic instructions 100-1000:1.


Decoy system calls outnumber malicious system calls 10-100:1.


Malicious system calls are creatively achieved in as many randomized alternative ways as possible.


All statistical usage (patterns: CPU, memory, storage, power) is randomized, evading machine-learning based resource usage pattern detection demonstrated in research.


Most of the instructions are encoded as image data or other "soft-edged" data formats (sound, video, vector, GeoJSON, etc.) that can pass through a network as benign traffic and store encoded passenger data without serious distortion. This can be non-trivial as it is desirable to download from a plausible external source in order to appear as genuine traffic, and the most popular public image repositories such as social media services re-encode image and video data, requiring the engineer to account for the encoding algorithm in order to effectively read the hidden data at the target site.


Some, most, or all malicious instructions are encoded as previously described and downloaded from the command-control server to be decoded and executed only when needed.


Write or Execute (W^X) Policy requires something like Microsoft's VirtualProtect to be called to make that dynamically loaded data executable. A defender can use this fact to raise a red flag when a program downloading an image file then makes data read from that location executable.  Attacks must use clever I/O and register obfuscation to mask this activity. For attackers operating in kernel mode W^X does not apply. This is worth noting regardless, as it is sometimes preferable to perform some operations through user-mode, especially with code re-use attacks against user-mode applications.


JavaScript, Python, AutoHotkey, AutoIt, PowerShell, Bash, and other benign scripting languages must be options to deliver payloads when attackers require such attack vectors.


Each of these methods is reapplied randomly (or left out, if possible, to avoid any one obfuscation signature being a reliable analysis target) to an original payload binary each time (or hundredth time) the payload is delivered to a new target, causing every or most instances of the attacking payload to differ dramatically. It is possible or even likely that predictability in this randomness would create an attack surface for cryptography experts to reverse engineer and discover some pattern that can be leveraged to detect payloads obfuscated with the tool. For this reason, the random number generation involved in such code must be cryptographically secure.


Optionally the payload includes code to re-randomize the above obfuscation passes on the program polymorphically in-place on the target machine every hour or day. This must be limited to some behavior signature of known benign programs so as to not serve as a signature behavior in itself. For example, a program auto-updating, or downloading initial installation assets from a remote server.


Forced branching traps: If the attacker is detecting the emulation / VM and behaving innocently, the defender must either make the VM more believable (an unreliable game of cat and mouse) or force alternate branching. To counter this, before the payload branches toward downloading the malicious code, the program must progress past trapped branches that have a 50% pseudo random chance of executing. This forces the attacker not to discount them as decoy code, force the branch to execute, and after enough of these branches are forced, each calling more code from the command-control server, the command-control server can see that the odds of so many of these 50% chance branches all executing naturally is extremely low. It then withholds the malicious payload by sending a final benign code-set which will not call for any further code. Later when the program is run on the true target without branch forcing, the payload will be sent instead.


Return Oriented Programming (ROP) can be used as part of the obfuscation to trick emulators to go off-course and misunderstand the true outcome of code. This must be done carefully, and the attacker should be wary of counter-strategy involving comparison of bare-metal and emulated results. A clever defender might reasonably guess that when their emulation deviates from the bare-metal behavior of instructions, foul play is involved.
	Binary obfuscation employed thoroughly. It is prevalent to note the distinction between preventing reverse engineering and preventing fingerprinting. A tool that makes software incredibly difficult to reverse-engineer often involves binary obfuscation structures that would be trivial to fingerprint.



	Employ memory and data scraping prevention. If a program saves a string in memory, ensure it is represented in a randomized, encoded manner to avoid behaving as a signature via memory scraper. If the original executable contains any image or alternate data, ensure this is obfuscated randomly and effectively before delivery to the target.



	Evade AV emulation (pre-execution) detection products via black box attacks. See AVLeak, Blackthorne et al (video presentation if preferred, Blackhat 2016).



	Evade EDR (post-execution) solutions by masking I/O behavior through obfuscation (combined with the payload not doing anything obviously malicious).



	Decoy logic outnumbering the malicious logic instructions 100-1000:1.



	Decoy system calls outnumber malicious system calls 10-100:1.



	Malicious system calls are creatively achieved in as many randomized alternative ways as possible.



	All statistical usage (patterns: CPU, memory, storage, power) is randomized, evading machine-learning based resource usage pattern detection demonstrated in research.



	Most of the instructions are encoded as image data or other "soft-edged" data formats (sound, video, vector, GeoJSON, etc.) that can pass through a network as benign traffic and store encoded passenger data without serious distortion. This can be non-trivial as it is desirable to download from a plausible external source in order to appear as genuine traffic, and the most popular public image repositories such as social media services re-encode image and video data, requiring the engineer to account for the encoding algorithm in order to effectively read the hidden data at the target site.



	Some, most, or all malicious instructions are encoded as previously described and downloaded from the command-control server to be decoded and executed only when needed.



	Write or Execute (W^X) Policy requires something like Microsoft's VirtualProtect to be called to make that dynamically loaded data executable. A defender can use this fact to raise a red flag when a program downloading an image file then makes data read from that location executable. Attacks must use clever I/O and register obfuscation to mask this activity. For attackers operating in kernel mode W^X does not apply. This is worth noting regardless, as it is sometimes preferable to perform some operations through user-mode, especially with code re-use attacks against user-mode applications.



	JavaScript, Python, AutoHotkey, AutoIt, PowerShell, Bash, and other benign scripting languages must be options to deliver payloads when attackers require such attack vectors.



	Each of these methods is reapplied randomly (or left out, if possible, to avoid any one obfuscation signature being a reliable analysis target) to an original payload binary each time (or hundredth time) the payload is delivered to a new target, causing every or most instances of the attacking payload to differ dramatically. It is possible or even likely that predictability in this randomness would create an attack surface for cryptography experts to reverse engineer and discover some pattern that can be leveraged to detect payloads obfuscated with the tool. For this reason, the random number generation involved in such code must be cryptographically secure.



	Optionally the payload includes code to re-randomize the above obfuscation passes on the program polymorphically in-place on the target machine every hour or day. This must be limited to some behavior signature of known benign programs so as to not serve as a signature behavior in itself. For example, a program auto-updating, or downloading initial installation assets from a remote server.



	Forced branching traps: If the attacker is detecting the emulation / VM and behaving innocently, the defender must either make the VM more believable (an unreliable game of cat and mouse) or force alternate branching. To counter this, before the payload branches toward downloading the malicious code, the program must progress past trapped branches that have a 50% pseudo random chance of executing. This forces the attacker not to discount them as decoy code, force the branch to execute, and after enough of these branches are forced, each calling more code from the command-control server, the command-control server can see that the odds of so many of these 50% chance branches all executing naturally is extremely low. It then withholds the malicious payload by sending a final benign code-set which will not call for any further code. Later when the program is run on the true target without branch forcing, the payload will be sent instead.



	Return Oriented Programming (ROP) can be used as part of the obfuscation to trick emulators to go off-course and misunderstand the true outcome of code. This must be done carefully, and the attacker should be wary of counter-strategy involving comparison of bare-metal and emulated results. A clever defender might reasonably guess that when their emulation deviates from the bare-metal behavior of instructions, foul play is involved.