Grey bar Blue bar
Share this:

Mon, 22 Apr 2013

Windows Domain Privilege Escalation : Implementing PSLoggedOn in Metasploit (+ a bonus history module)

There are multiple paths one could take to getting Domain Admin on a Microsoft Windows Active Directory Domain. One common method for achieving this is to start by finding a system where a privileged domain account, such as a domain admin, is logged into or has recently been logged into. Once access to this system has been gained, either stealing their security tokens (ala Incognito or pass-the-hash attacks) or querying Digest Authentication (with Mimikatz/WCE) to get their clear-text password. The problem is finding out where these user's are logged in.


I've often seen nmap and the smb-enum-sessions script (http://nmap.org/nsedoc/scripts/smb-enum-sessions.html) used to retrieve all the user sessions on the network. This (not so grep'pable) output is then grep'ed to find the hosts where our target user is logged in. The process of smb-enum-sessions and subsequent analysis can be quite time consuming and clumsy. On a recent assessment, multiple tunnels in, where uploading nmap wasn't a great idea, we realised that there has to be a better way of doing this. While searching for an alternative solution we came across PsLoggedOn (SysInternals Suite) which, with a single binary, allows you search the network for locations where a user is logged in. The downside with this is that it doesn't cleanly run via psexec or other remote shells and you need graphical logon to a system on the domain, and you need to upload another binary (the PsLoggedOn executable) to the target system. Examining how PsLoggedOn worked we figured out that it was simply using the Windows NetSessionEnum API. Having a look at the API I figured that it should be possible to write a simple post exploit module for Metasploit using the railgun.


After some trial and error, we now present enum_domain_user.rb a simple Metasploit post exploit module capable of finding network sessions for a specific user. Below is a screenshot of the module in action.



To use the module,


1.) Download and copy it to:
<msfinstall>/modules/post/windows/gather/
(we'll send a pull request to metasploit-framework's github shortly).


2.) In MSF:
use post/windows/gather/enum_domain_user


3.) Set the USER and SESSION variables.


4.) Then simply run it with "exploit".


The module can also be used directly from meterpreter with:
run post/windows/gather/enum_domain_user USER=username


Warning, this doesn't seem to work with x64 meterpreter yet mostly likely due to some memory pointer stuff I haven't worked out. Hopefully this will get updated shortly, or even better, one of you smart people out there can fix my horrible Ruby.

Bonus


As an added extra I've included a Metapsloit history plugin. This plugin will simply allow you to view all the commands executed since the module was loaded and then execute them "bash style".


Typing "history" will give display the last 10 commands executed. If you wish to see more commands, type history <numberof entries>


To run a command from the history list type:
history !<command number>


Below is an action shot of the history module.



To install:


1.) Download and Copy history.rb to the plugins folder: <msf install>/plugins/
2.) In msfconsole type: load history
3.) For usage info type: help history


Both modules are available for download on Github, and I'll submit a pull request to metasploit-framework shortly. Please feel free to fork and be merry. Any updates/fixes/comments are welcome.
Github: https://github.com/sensepost/metasploit

Sat, 2 Mar 2013

IT Network Packet Wrangler


As we grow and operate on a number of continents, so does our dependence on a rock-solid IT infrastructure. We are expanding our repertoire to include a greater collection of Linux/Open Source/Windows and OS X products. With this, we are on the look-out for a rock star to wrangle control of our internal networks, external cloud infrastructure and help us us utilise technology in a way to make us even better.


Job Title: IT Network Packet Wrangling Penguin Master


Salary Range: Industry standard, commensurate with experience


Location: Johannesburg/Pretoria, South Africa


Real Responsibilities:


  • Managing a growing internal network, both in ZA and UK and increased cloud-based infrastructure

  • Championing the adoption of new technologies, ways of working and being incredibly excited about security. Yes, we like that type of person who scoffs at the idea of using a plain-text protocol


As a system / network administrator your daily duties and responsibilities will include:

  • Providing day-to-day Desktop, Server and Network administration, including helping plakkers (the name we give to all who work at SensePost) with their devices

  • Be capable of using a variety of operating systems

  • Ensuring our disaster recovery plan is working as it should

  • Being the go to person to all those who require assistance with their IT

  • Maintaining and administer the telecommunications system

  • Administering the network to ensure that the systems in place run effectively and securely (we are, after all, a security company!)

  • A real passion for finding technology led solutions to problems.

  • Be excited about Unix firewalls, Cisco routers, wrangling network packets, VPN tunnelling and Wi-Fi

  • Able to hold a conversation and smile when mentioning SMTP/HTTP/IMAP/Python


Not essential, but bonus points for:

  • Actually getting a linux laptop to use an overhead projector, without resorting to swear words in Spanish and Afrikaans

  • Administering a Windows server without complaining, at all, not once, in fact, you actually kinda enjoy it.

  • Being really passionate about security and showing it doesn't have to get in the way of working productively.


If the above has got you thinking 'weird, it's like they are talking to me bru!' then we want to hear from you. Send us a carrier pigeon message or send us a mail

Wed, 16 Jan 2013

Client Side Fingerprinting in Prep for SE

On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.


First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn't find the exact IP they were being NAT'ed to. Not wanting to stop there, I tried out Vlad's Skype IP disclosure trick, which worked like a charm. What's cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don't even need to be "friends", you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.


Once I had that IP, I went on a hunt for web logs that had been indexed by a search engine, that contained hits from that IP. My thinking was that I run into indexed Apache or IIS logs fairly often when googling for IPs or the like, so maybe some of these contained the external NAT IP of the target organisation. It took a fair bit of search term fiddling, but in the end I found 14 unique hits from their organisation semi-complete with User Agent information (some were partially obscured).


This provided me with the following stats:









Operating System


Win XP 8


Win 7 32 3


Win 7 64 3

Browser


IE 8 8


IE 6 3


IE 7 1


IE 9 1

Combination


Win 7 IE 8 4


Win XP IE 8 4


Win XP IE 6 3


Win 7 IE 9 1


Win XP IE 7 1


Granted, it could be that the same machine was present in multiple logs and the stats are skewed, but they are a large enough organisation that I thought the chances were low, especially as most of the sites who's logs I found were pretty niche. As validation of these results, later, once we had penetrated through to the internal network, it was clear that they had a big user base in regional offices still on Win XP and IE6, and a big user base at corporate offices who had been migrated to Windows 7 with IE8.


Unfortunately, the UserAgent didn't make it clear whether they had Acrobat or Java or what versions they were at. We thought of using some JavaScript to do such detection, but were under a time constraint, and went with trying to pwn them instead, with the thinking that if it doesn't work, we could retarget and at least get some debugging information.


Anecdotally, and to give the story an ending, it turned out that BlackHole and Metasploit's Browser AutoPwn were a bust, even our customised stuff got nailed by Forefront when the stager tried to inject it's payload at runtime, but an internal tool we use for launching modified meterpreter payloads worked like a charm (although, periodically died on Win7 64bit, so I'd recommend using reverse-http, you can restart sessions, and firing up a backup session to restart the other with).

Mon, 26 Nov 2012

Skype Passive IP Disclosure Vulnerability

When performing spear phishing attacks, the more information you have at your disposal, the better. One tactic we thought useful was this Skype security flaw disclosed in the early days of 2012 (discovered by one of the Skype engineers much earlier).

For those who haven't heard of it - this vulnerability allows an attacker to passively disclose victims external, as well as internal, IP addresses in a matter of seconds, by viewing the victims VCard through an 'Add Contact' form.

Why is this useful?

1. Verifying the identity and the location of the target contact. Great when performing geo-targeted phishing attacks.

2. Checking whether your Skype account has not been used elsewhere :)

3. Spear phishing enumeration while Pen Testing.

4. Just out of plain curiosity.

To get this working, following these basic steps:

1. Download and install the patched version of Skype 5.5 from here (the patch enables the Skype client to save the logs in non obfuscated form)

2. Save the lines below as a Skype_log_patch.reg reg file:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Skype\Phone\UI\General]
"LastLanguage"="en"
"Logging"="SkypeDebug2003"
"Logging2"="on"
Once saved, run it to enable the Skype Debug Log File.

4. Start Skype.

5. Search for any Skype contact and click on the 'Add a Skype Contact' button, but do not send the request, rather click on the user to view their VCard.

4. Open the log file (it should appear in the same folder as Skype executable e.g. debug-20121003-0150)

5. Look for the PresenceManager line - you should see something similar to this - >

In the above image you can spot my Skype name, external as well as internal IP addresses.

The log will include similar credentilas for everyone listed as a "contact" under your Skype account, as well as many other fresh, genuine and useful information received directly from your local Skype tracker.

Mon, 25 Jun 2012

Solution for the BlackHat Challenge

We had published a network protocol analysis challenge for free entry to our BlackHat 2012 Vegas training courses and received seven correct answers. We'd like to thank those who attempted this challenge and hope that they find it useful.

The winner, Peter Af Geijerstam managed to respond first, with the correct answer. As a result, he wins a free place on any of our Hacking By Numbers courses. Here is a brief solution for it:

If you start by running the client and server binaries provided in the challenge zip file, you'll observe the following output from the client:

And we can see the same challenge (177) and 16-byte response values in the network traffic:

So, this indicates that the client and server are running a simple challenge-response authentication protocol with a 3-digit random number (R) as the challenge and a 16-byte response value which should be calculated using the R and the shared secret value. We need to figure out the response calculation formula in order to fully understand this simple authentication protocol. This can be done by reading the provided source code. If the source code was not available then we'd have to use a disassembler, such as IDA Pro, in order to find out the formula. The following code snippet shows a function call to HMAC(char *msg, char *key,byte *mac) to calculate the response value:

And inside HMAC function we can see calls to Windows CryptoAPI to calculate MD5 hash value of (msg+secret):

Now, we can summarise the authentication protocol as below and work out our attack strategy:

Client->Server : HELLO Server->Client: R Client->Server: RESP (MD5(R+secret)) Server->Client: OK/Incorrect Response

The attacker had both R and MD5(R+secret) values from the network traffic capture file and he also knew something about the shared secret format (7 alphanumeric excluding uppercase characters). Therefore, he can run a brute force attack on the 16-byte MD5 hash value with a narrowed charset and known message format which would be [448][abcdefghijklmnopqrstuvwxyz0123456789]. There are several public hash cracking tools which support raw md5 hashes, such as hashcat. we can run hashcat with the following options:

cudaHashcat-plus32.exe --attack-mode 3 --custom-charset1 abcdefghijklmnopqrstuvwxyz0123456789 hash.txt 448?1?1?1?1?1?1?1

It would take about 43 minutes for a NVIDIA GeForce 405 graphic card to recover the shared secret:

And the shared secret value is: bm28lg1. In order to calculate the session key value (kc) we can simply set the R to 448 in authentication server source code instead of the random value and compile it. By running the client binary using the recovered secret key value (bm28lg1), we will get the session key:

And the session key value is : 07e0f7a7cbc2d8b3dba6b7d3b69c3236

I saw a similar solution (in Spanish) on the internet posted here . I also received a question not about the challenge itself, but the source code of the authentication client and why I'v set resp buffer size it to 128 bytes while the client response length is always 21 bytes (basically why I've wasted 107 bytes of 1MB default stack). The answer is that the server not only processes RESP messages from the client, but also need to receive and decrypt MSG messages (which is marked as not implemented in both source codes). MSG messages clearly have a bigger size than 21 bytes and in order to use the same RESP buffer for incoming data, I set its size to 128 bytes which is purely an arbitrary number in this case and should be changed to a more suitable size based on the encryption algorithm's block sizes which are not implemented in the current code.

If you have questions or recommendations regarding this challenge (or similar ones), please drop me an email to the address inside the challenge file.