In order to get past emulation engines undetected, you have a couple of options.
You could try to identify APIs,
which are not frequently used, and attempt to call
them prior to running your stager.
If those API calls fail because the emulator doesn't handle
them correctly or returns unexpected values,
you can force the application to exit,
which will ensure your stager doesn't get emulated.
As explained in the antivirus and EDR modules,
emulators usually have a termination condition.
This is to avoid performance issues by limiting CPU and
memory consumption on the computer, which might impact user productivity.
As an attacker,
we can take advantage of this by executing many bogus
instructions in a loop prior to executing the stager,
which will make the emulator spin its wheels and eventually exit
for the sake of performance and productivity.
Another way of identifying if your stager is being emulated is
checking the environment through anomalies.
If, for example,
you add code to check the file name of your executable file at
runtime and it doesn't match the original file name,
or if you perform an HTTP request for a fake URL and get an HTTP 200 response,
it might suggest that your code is being run in an emulator,
in which case you can exit the process to ensure
the stager doesn't get emulated.
Another way of identifying if an emulator is in use is
checking CPU register values before and after function
calls and check for discrepancies.
Anti‑sandboxing techniques are similar in concept to anti‑emulation.
The approach, which is usually chosen,
consists of checking various artifacts on the machine to try
and figure out if the code is being run on the real user's
computer and not inside a sandbox.
The approach we covered in anti‑emulation, which consisted of exhausting
the emulator using a loop of bogus instructions, will not be as effective
here since resource consumption isn't a problem in cloud‑based solutions.
We do have some alternatives.
We can check if the computer is joined to the correct Windows
domain that you're trying to attack or if the logged‑on user
name corresponds to the person you're trying to socially
engineer into launching your stager.
These approaches are very effective.
They are unfortunately not very feasible and require a
lot of information about the target, which isn't always available to an attacker.
Alternative techniques consist of checking if the code is being
run on a virtual machine since most sandboxes are virtualized. A
technique we mentioned previously,
which consists of checking for successful responses to
HTTP requests which should fail,
are also a good indicator that code is running in the sandbox.
In the case you were unsuccessful at detecting the sandbox,
your stager will execute,
and in some cases will connect to a handler to retrieve the payload,
which will be sent to the sandbox.
If this is the case, there is a good chance that you will get caught.
One option, which is very effective at preventing this,
but tricky to implement,
is identifying the public IP addresses used by your victim and
only allowing those to connect to your handler.
This will ensure your payload isn't being sent to
cloud‑based sandboxes for analysis.
Most solutions will only send executables into a sandbox for
analysis when it is unsure if it is safe or not.
If our executable looks benign on disk,
we reduce the likelihood that it will be sent for a sandbox analysis.
In some cases,
if the antivirus is unable to get reputation information about the file,
it will automatically get uploaded for analysis.
There are many resources on the internet,
which documents techniques for bypassing dynamic
analysis inside sandboxes and emulators.
One document, which I recommend, is the following,
which can be found on WikiLeaks.
The author documented various techniques,
which he was able to use successfully to get around antivirus solutions.
If we scroll down,
we can see that the document focuses on emulation and sandboxes.
Scrolling down even further will reveal various code samples,
which the author was able to use to bypass emulators and sandboxes.
Some involved allocating large amounts of memory and filling it with data.
Others leverage a technique we discussed previously,
which consists of exhausting the emulator using loops.
The document also demonstrates another example,
which we discussed,
which consists of checking the logged‑on username and check for discrepancies,
as well as checking the file name at runtime.
In the upcoming demo,
we will be using one of these techniques to exhaust the
emulator and bypass Windows Defender.