WEBVTT

00:00:00.740 --> 00:00:04.870
An alternative to using encoders or encryptors to hide our stager on

00:00:04.870 --> 00:00:09.210
disk is to figure out which signatures are being used by antivirus and

00:00:09.210 --> 00:00:11.600
attempt to modify the stager's shellcode.

00:00:11.840 --> 00:00:13.960
While this technique is not very generic,

00:00:13.970 --> 00:00:17.260
since not all antivirus solutions will use the same signatures,

00:00:17.260 --> 00:00:20.910
it does have the added benefit of obfuscating the stager in

00:00:20.910 --> 00:00:23.030
memory once it has been de‑obfuscated,

00:00:23.030 --> 00:00:26.660
and well protected from certain types of in‑memory scans,

00:00:26.740 --> 00:00:29.730
it is also more complex and time consuming than simply

00:00:29.730 --> 00:00:32.479
passing in a ‑e flag to MSFvenom,

00:00:32.479 --> 00:00:35.390
since it will require a very good understanding of

00:00:35.390 --> 00:00:37.150
the assembly programming language.

00:00:38.340 --> 00:00:41.520
Let's now take a look at how we can modify our stager in an

00:00:41.520 --> 00:00:44.250
attempt to break signature‑based detections.

00:00:44.250 --> 00:00:51.310
To do so, we can open the reverse_http_x64.rb file.

00:00:51.410 --> 00:00:53.610
I have already opened two copies of the file.

00:00:53.620 --> 00:00:55.920
On the left‑hand side is my modified version,

00:00:55.920 --> 00:00:58.480
and on the right, we have the original file.

00:00:58.480 --> 00:01:01.120
As explained in the Meterpreter Deep Dive module,

00:01:01.120 --> 00:01:04.629
this file contains the Ruby code which generates the stager.

00:01:05.239 --> 00:01:05.880
At this point,

00:01:05.880 --> 00:01:08.680
there are a couple of options we can choose from to modify the

00:01:08.680 --> 00:01:11.360
code without altering its functionality.

00:01:11.640 --> 00:01:14.950
One technique is to add bogus instructions inside

00:01:14.950 --> 00:01:17.210
the stager at different locations.

00:01:17.430 --> 00:01:20.940
A good way of identifying where we can do this is to look for

00:01:20.940 --> 00:01:23.780
xor instructions involving a single register.

00:01:23.780 --> 00:01:28.860
When a register is xor'd with itself, the instruction will null out the register.

00:01:29.040 --> 00:01:32.690
We can take advantage of this and perform random operations with

00:01:32.690 --> 00:01:35.500
the register just after the xor instruction,

00:01:35.510 --> 00:01:38.590
as long as we remember to null out the register once we

00:01:38.590 --> 00:01:40.850
have finished adding the bogus code.

00:01:40.850 --> 00:01:43.990
Another technique which we can leverage is to compute the

00:01:43.990 --> 00:01:48.440
parameters which get passed to the APIs at runtime to avoid

00:01:48.440 --> 00:01:50.790
hard‑coded artifacts in our stager.

00:01:50.790 --> 00:01:53.690
Here is an example where instead of hard‑coding the

00:01:53.690 --> 00:01:57.370
WinINet string in the stager, I subtracted the value,

00:01:57.380 --> 00:02:03.370
ffff, from the hexadecimal values, which make up the WinINet ASCII string,

00:02:03.370 --> 00:02:05.320
and hard‑coded this value instead.

00:02:05.320 --> 00:02:08.490
At runtime, the stager will add the value,

00:02:08.490 --> 00:02:11.480
ffff, to the obfuscated WinINet string.

00:02:11.590 --> 00:02:15.260
This technique is obviously not as generic as using an encoder,

00:02:15.740 --> 00:02:18.860
but it does have the added benefit of protecting the stager

00:02:18.860 --> 00:02:21.180
from certain types of in‑memory scans.

00:02:21.490 --> 00:02:25.850
Finally, we can attempt to modify the pre‑computed ROT13 hashes,

00:02:25.850 --> 00:02:28.300
which are used to locate APIs.

00:02:28.300 --> 00:02:33.260
This can be done in the block_api.rb file.

00:02:33.540 --> 00:02:36.860
I chose to use the value 16 instead of 13.

00:02:37.240 --> 00:02:42.840
We also need to modify this value in the asm_block_api function,

00:02:42.850 --> 00:02:45.850
which we discussed in the Meterpreter Deep Dive module.

00:02:46.440 --> 00:02:53.490
This can be done in the block_api.x64.graphml file by

00:02:53.490 --> 00:02:56.800
changing some of the bytes corresponding to the ror r9d

00:02:56.800 --> 00:03:02.570
0x0D instruction with the value 10,

00:03:02.570 --> 00:03:07.150
which is the hexadecimal equivalent of 16 in decimal.

00:03:07.150 --> 00:03:10.110
At this point, if we generate a new stager,

00:03:10.120 --> 00:03:13.810
it will no longer have the well‑known ROT13 hash values,

00:03:13.810 --> 00:03:18.150
which are commonly used by antivirus to detect Meterpreter stages.

00:03:18.740 --> 00:03:21.800
We can confirm this by generating a raw stager,

00:03:21.800 --> 00:03:24.230
which we can disassemble using metasm,

00:03:24.230 --> 00:03:27.350
as we did in the Meterpreter Deep Dive module.

00:03:28.040 --> 00:03:31.470
If we now grep to the LoadLibraryA ROT13 hash,

00:03:31.470 --> 00:03:34.060
you will notice that it is no longer found.