During many of our penetration tests, we gather domain password hashes (with permission of the client) for offline cracking and analysis. This blog is a quick summary of the hashes that we attempted to crack in the second quarter of 2014 (and so far for this year). The plan is to continue doing this each quarter for the rest of the year to see how we did overall for the year. Please keep in mind that this is not an all encompassing sample. We do not collect domain hashes during every single penetration test, as some clients do not want us to.
The sample for this quarter included three sets of domain hashes that added up to 23,898 hashes. All three sets had some LM hashes stored along with the NTLM hashes, but none of the LM stored passwords were that complicated, so it wasn’t a huge advantage. Of the hashes, 8,277 were duplicates, leaving 15,621 unique hashes. Of the 23,898 hashes, we were able to crack 21,465 (89.82%).
Cracked Password Length Breakdown:
As you can see, the cracked passwords peak at the eight character length. This is pretty common for a minimum password length, so it’s not a big surprise that this is the most common length cracked.
Some interesting finds:
Most Common Password (820 instances): Changem3
Longest Password: 20 characters
Most Common Length (10,897 instances): 8 characters
Instances of “password” (case-insensitive): 1,541
Instances of “spring2014” (case-insensitive): 111
Instances of “spring14” (case-insensitive): 93
Instances of “summer2014” (case-insensitive): 84
Instances of “summer14” (case-insensitive): 59
So far this year, we’ve collected 33,950 hashes to crack. Of those, we’ve been able to crack 29,077 (85.65%).
Some more interesting finds:
Most Common Password (1274 instances): Password1
Longest Passwords: 20 characters – Two passwords based off of the name of the business group using them
Most Common Length (14,339 instances): 8 characters
Instances of “password” (case-insensitive): 2,675
Instances of “winter2014” (case-insensitive): 23
Instances of “winter14” (case-insensitive): 18
Instances of “spring2014” (case-insensitive): 102
Instances of “spring14” (case-insensitive): 91
I put together an hcmask file (to use with oclHashcat ) of our top forty password patterns that were identified for this quarter. Additionally, I put together one for everything that we’ve cracked for the first half of the year. You can download the files here: Top40_Q2 and Top40 Q1 and Q2. I plan on keeping up with this each quarter, so check back in next quarter to see how this mask files have changed and to see how well we’ve done across the three quarters.
For more information on how we built our GPU-enhanced password cracking box, check out our slides
For a general outline of our password cracking methodology check out this post
In this blog, we will go through proxying an iOS application which uses native web sockets to interact with a web server. The blog will help penetration testers who are trying to intercept sensitive data that is being sent by an iOS application in a non-trivial manner over the network because some applications do not respect the iOS proxy settings.
During a recent iOS application penetration test, I encountered an iOS application that was sending data to port 20xx on a web server. This application traffic could not be proxied by changing the iOS manual proxy settings located at (Settings -> Wi-Fi -> HTTP Proxy -> Manual) and forwarding the iDevice traffic to the proxy. One of the reasons that the normal proxying method might be failing is because it might be using some native websockets to interact with the web server instead of the normal UIWebView class. For more technical details of how websockets in native iOS can be configured, check out this elabs blog post.
There is a workaround to fix this problem. We can perform DNS spoofing to forward all the HTTP traffic for all of the ports through a MitM proxy like Burp. The blog is divided into three main steps.
Sniff traffic using Wireshark to find out the port and IP of the webserver.
Spoof the DNS for the iDevice to send all data to laptop.
Start a proxy on the laptop to intercept traffic all traffic from iDevice after DNS spoofing.
Given below is a step by step approach to intercept Native Web Socket iOS application traffic.
Create a wireless hot spot with your machine and connect the iDevice to the hotspot. [Note the machine needs to be connected to Ethernet or some other route out to the internet as the Wi-Fi interface will be used for the hotspot. Refer here for information on how to create a hotspot on a windows machine]
Start a network sniffer (like Wireshark) and look for traffic going to any non-standard ports.
Filter the traffic to look at the traffic going to the destination server IP (ip.dst== ip.ip.ip.ip)
Note the port number where the traffic is being sent.
Fig 1: Finding the non-standard port number where application sends Traffic.
Start the Metasploit console to perform DNS spoofing and enter the following commands.
set SRVHOST = (IP address of laptop which is running the hotspot)
set SRVPORT = 53, set TARGETACTION = BYPASS, set TARGETDOMAIN = www.apple.com (Note: by setting TARGETDOMAIN= www.apple.com, all the traffic except the traffic coming from apple.com will be spoofed)
set targethost = (IP address of laptop which is running the hotspot)
Fig 2: Configuring DNS server on the laptop using fakedns module in Metasploit.
Configure Burp to listen on specific ports for the incoming traffic from iDevice and forward it to the appropriate port as follows:
Go to Proxy’Options’Add; set ‘bind port’ to the port where the traffic needs to be sent (note: this is the non-standard tcp port number recorded in Wireshark)
Listen on all interfaces
Click Request Handling’ Redirect to host: (Enter the domain name of the server)
Request Handling ‘ Redirect to port: (Enter the corresponding port number)
Click force use of SSL if the outgoing traffic is sent using https.
Click ok and repeat the above steps for all the ports that the iOS application is explicitly sending HTTP application traffic to. In other words, every port will require a separate Proxy listener to be configured in burp.
Fig 3: Configure incoming listener and redirect the iDevice traffic to appropriate IP and port to Server.
Configure Proxy settings in iDevice:
Click settings ‘ Wi-Fi ‘Click on hotspot ‘ DHCP and set DNS = (IP of Laptop)
Set HTTP Proxy to the IP address of the laptop and corresponding port in burp. (this is the normal setting to proxy standard HTTP traffic)
Fig 4: Configure IP and DNS forwarding settings in the IOS device.
Type “exploit” in the Metasploit console and you will see the application traffic been proxied for non-standard ports in burp.
This small tweak can be used to overcome the problem of proxying non-trivial iOS application traffic.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.