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:
(we'll send a pull request to metasploit-framework's github shortly).
2.) In MSF:
3.) Set the USER and SESSION variables.
4.) Then simply run it with "
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.
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.
1.) Download and Copy history.rb to the plugins folder:
2.) In msfconsole type:
3.) For usage info type:
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.
A cloud storage service such as Microsoft SkyDrive requires building data centers as well as operational and maintenance costs. An alternative approach is based on distributed computing model which utilizes portion of the storage and processing resources of consumer level computers and SME NAS devices to form a peer to peer storage system. The members contribute some of their local storage space to the system and in return receive "online backup and data sharing" service. Providing data confidentiality, integrity and availability in such de-centerlized storage system is a big challenge to be addressed. As the cost of data storage devices declines, there is a debate that whether the P2P storage could really be cost saving or not. I leave this debate to the critics and instead I will look into a peer to peer storage system and study its security measures and possible issues. An overview of this system's architecture is shown in the following picture:
Each node in the storage cloud receives an amount of free online storage space which can be increased by the control server if the node agrees to "contribute" some of its local hard drive space to the system. File synchronisation and contribution agents that are running on every node interact with the cloud control server and other nodes as shown in the above picture. Folder/File synchronisation is performed in the following steps:
1) The node authenticates itself to the control server and sends file upload request with file meta data including SHA1 hash value, size, number of fragments and file name over HTTPS connection.
2) The control server replies with the AES encryption key for the relevant file/folder, a [IP Address]:[Port number] list of contributing nodes called "endpoints list" and a file ID.
3) The file is split into blocks each of which is encrypted with the above AES encryption key. The blocks are further split into 64 fragments and redundancy information also gets added to them.
4) The node then connects to the contribution agent on each endpoint address that was received in step 2 and uploads one fragment to each of them
Since the system nodes are not under full control of the control server, they fall offline any time or the stored file fragments may become damaged/modified intentionally. As such, the control server needs to monitor node and fragment health regularly so that it may move lost/damaged fragments to alternate nodes if need be. For this purpose, the contribution agent on each node maintains an HTTPS connection to the control server on which it receives the following "tasks":
a) Adjust settings : instructs the node to modify its upload/download limits , contribution size and etc
b) Block check : asks the node to connect to another contribution node and verify a fragment existence and hash value
c) Block Recovery : Assist the control server to recover a number of fragments
By delegating the above task, the control system has placed some degree of "trust" or at least "assumptions" about the availability and integrity of the agent software running on the storage cloud nodes. However, those agents can be manipulated by malicious nodes in order to disrupt cloud operations, attack other nodes or even gain unauthorised access to the distributed data. I limited the scope of my research to the synchronisation and contribution agent software of two storage nodes under my control - one of which was acting as a contribution node. I didn't include the analysis of the encryption or redundancy of the system in my preliminary research because it could affect the live system and should only be performed on a test environment which was not possible to set up, as the target system's control server was not publicly available. Within the contribution agent alone, I identified that not only did I have unauthorised access file storage (and download) on the cloud's nodes, but I had unauthorised access to the folder encryption keys as well.
a) Unauthorised file storage and download
The contribution agent created a TCP network listener that processed commands from the control server as well as requests from other nodes. The agent communicated over HTTP(s) with the control server and other nodes in the cloud. An example file fragment upload request from a remote node is shown below:
Uploading fragments with similar format to the above path name resulted in the "bad request" error from the agent. This indicated that the fragment name should be related to its content and this condition is checked by the contribution agent before accepting the PUT request. By decompiling the agent software code, it was found that the fragment name must have the following format to pass this validation:
<SHA1(uploaded content)>.<Fragment number>.<Global Folder Id>
I used the above file fragment format to upload notepad.exe to the remote node successfully as you can see in the following figure:
The download request (GET request) was also successful regardless of the validity of "Global Folder Id" and "Fragment Number". The uploaded file was accessible for about 24 hours, until it was purged automatically by the contribution agent, probably because it won't receive any "Block Check" requests for the control server for this fragment. Twenty four hours still is enough time for malicious users to abuse storage cloud nodes bandwidth and storage to serve their contents over the internet without victim's knowledge.
b) Unauthorised access to folder encryption keys
The network listener responded to GET requests from any remote node as mentioned above. This was intended to serve "Block Check" commands from the control server which instructs a node to fetch a number of fragments from other nodes (referred to as "endpoints") and verify their integrity but re-calculating the SHA1 hash and reporting back to the control server. This could be part of the cloud "health check" process to ensure that the distributed file fragments are accessible and not tampered with. The agent could also process "File Recovery" tasks from the control server but I didn't observe any such command from the control server during the dynamic analysis of the contribution agent, so I searched the decompiled code for clues on the file recovery process and found the following code snippet which could suggest that the agent is cable of retrieving encryption keys from the control server. This was something odd, considering that each node should only have access to its own folders encryption keys and it stores encrypted file fragments of other nodes.
While peer to peer storage systems have lower setup/maintenance costs, they face security threats from the storage nodes that are not under direct physical/remote control of the cloud controller system. Examples of such threats relate to the cloud's client agent software and the cloud server's authorisation control, as demonstrated in this post. While analysis of the data encryption and redundancy in the peer to peer storage system would be an interesting future research topic, we hope that the findings from this research can be used to improve the security of various distributed storage systems.
A few days ago, during one of those nights with the baby crying at 2:00 am and the only thing you can do is to read emails, I realised that Gmail shows the content of compressed files when reading them in Google Docs. As often is the case at SensePost, the "think evil (tm)" came to me and I started to ponder the possibilities of injecting HTML inside the file listing. The idea is actually rather simple. Looking at the file format of a .zip file we see the following:
Every file in the compressed file must have two entries; ZipFileRecord and ZipDirEntry. Both of these entries contain the filename, but only the first one contains the length of filename (it must match the actual length). Our first test case is obvious; if we could modify this name once the file was compressed, would Google sanitise it? Thankfully, the answer is, yes! (go Google!)
As you can see, Google shows the file name inside the compressed file but the tag is displayed with HTML entities. If we then try to see the contents of the file, Google responds by telling us it's not possible to read the content of the file (it's empty) and shows you the file "without formatting" after a few seconds:
Finally, the filename is shown but not sanitised:
Why this is possible?
Remember that the zip format has the name of the compressed files twice. Google uses the first one (ZipFileRecord) for displaying the file names, but in the vulnerable page it uses the second one (ZipDirEntry).
Possible attack vectors
Going back to the 'thinking evil (tm)' mindset, it is now possible to leave a "comprehensive" name in the first entry and inject the malicious payload in the second one. When I first discovered the possibility of doing this, I contacted Google, however, the XSS is in the googleusercontent.com domain, which Google's security team described as a "sandbox" domain (i.e. we aren't injecting into the DOM of google.com) and therefore not worthy of a bounty. Which I accept, if I had to prove usefulness this could be used as part of a simple social engineering attack, for example:
Leading the victim to my phishing site:
Which then proceeds to steals their Google session, or allows the attacker to use BeEF:
Granted, there are simpler ways of achieving the same result. I just wanted to demonstrate how you can use file meta-information for such an attack.
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:
Win XP 8
Win 7 32 3
Win 7 64 3
IE 8 8
IE 6 3
IE 7 1
IE 9 1
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
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).
At this year's 44Con conference (held in London) Daniel and I introduced a project we had been working on for the past few months. Snoopy, a distributed tracking and profiling framework, allowed us to perform some pretty interesting tracking and profiling of mobile users through the use of WiFi. The talk was well received (going on what people said afterwards) by those attending the conference and it was great to see so many others as excited about this as we have been.
In addition to the research, we both took a different approach to the presentation itself. A 'no bullet points' approach was decided upon, so the slides themselves won't be that revealing. Using Steve Jobs as our inspiration, we wanted to bring back the fun to technical conferences, and our presentation hopefully represented that. As I type this, I have been reliably informed that the DVD, and subsequent videos of the talk, is being mastered and will be ready shortly. Once we have it, we will update this blog post. In the meantime, below is a description of the project.
"Snoopy is a distributed tracking and profiling framework."
Below is a diagram of the Snoopy architecture, which I'll elaborate on:
Snoopy runs client side code on any Linux device that has support for wireless monitor mode / packet injection. We call these "drones" due to their optimal nature of being small, inconspicuous, and disposable. Examples of drones we used include the Nokia N900, Alfa R36 router, Sheeva plug, and the RaspberryPi. Numerous drones can be deployed over an area (say 50 all over London) and each device will upload its data to a central server.
A large number of people leave their WiFi on. Even security savvy folk; for example at BlackHat I observed >5,000 devices with their WiFi on. As per the RFC documentation (i.e. not down to individual vendors) client devices send out 'probe requests' looking for networks that the devices have previously connected to (and the user chose to save). The reason for this appears to be two fold; (i) to find hidden APs (not broadcasting beacons) and (ii) to aid quick transition when moving between APs with the same name (e.g. if you have 50 APs in your organisation with the same name). Fire up a terminal and bang out this command to see these probe requests:
tshark -n -i mon0 subtype probereq
(where mon0 is your wireless device, in monitor mode)
Each Snoopy drone collects every observed probe-request, and uploads it to a central server (timestamp, client MAC, SSID, GPS coordinates, and signal strength). On the server side client observations are grouped into 'proximity sessions' - i.e device 00:11:22:33:44:55 was sending probes from 11:15 until 11:45, and therefore we can infer was within proximity to that particular drone during that time.
We now know that this device (and therefore its human) were at a certain location at a certain time. Given enough monitoring stations running over enough time, we can track devices/humans based on this information.
3. Passive Profiling?
We can profile device owners via the network SSIDs in the captured probe requests. This can be done in two ways; simple analysis, and geo-locating.
Simple analysis could be along the lines of "Hmm, you've previously connected to hooters, mcdonalds_wifi, and elCheapoAirlines_wifi - you must be an average Joe" vs "Hmm, you've previously connected to "BA_firstclass, ExpensiveResataurant_wifi, etc - you must be a high roller".
Of more interest, we can potentially geo-locate network SSIDs to GPS coordinates via services like Wigle (whose database is populated via wardriving), and then from GPS coordinates to street address and street view photographs via Google. What's interesting here is that as security folk we've been telling users for years that picking unique SSIDs when using WPA is a "good thing" because the SSID is used as a salt. A side-effect of this is that geo-locating your unique networks becomes much easier. Also, we can typically instantly tell where you work and where you live based on the network name (e.g BTBusinessHub-AB12 vs BTHomeHub-FG12).
The result - you walk past a drone, and I get a street view photograph of where you live, work and play.
4. Rogue Access Points, Data Interception, MITM attacks?
Snoopy drones have the ability to bring up rogue access points. That is to say, if your device is probing for "Starbucks", we'll pretend to be Starbucks, and your device will connect. This is not new, and dates back to Karma in 2005. The attack may have been ahead of its time, due to the far fewer number of wireless devices. Given that every man and his dog now has a WiFi enabled smartphone the attack is much more relevant.
Snoopy differentiates itself with its rogue access points in the way data is routed. Your typical Pineapple, Silica, or various other products store all intercepted data locally, and mangles data locally too. Snoopy drones route all traffic via an OpenVPN connection to a central server. This has several implications:
(i) We can observe traffic from *all* drones in the field at one point on the server. (ii) Any traffic manipulation needs only be done on the server, and not once per drone. (iii) Since each Drone hands out its own DHCP range, when observing network traffic on the server we see the source IP address of the connected clients (resulting in a unique mapping of MAC <-> IP <-> network traffic). (iv) Due to the nature of the connection, the server can directly access the client devices. We could therefore run nmap, Metasploit, etc directly from the server, targeting the client devices. This is a much more desirable approach as compared to running such 'heavy' software on the Drone (like the Pineapple, pr Pwnphone/plug would). (v) Due to the Drone not storing data or malicious tools locally, there is little harm if the device is stolen, or captured by an adversary.
On the Snoopy server, the following is deployed with respect to web traffic:
(i) Transparent Squid server - logs IP, websites, domains, and cookies to a database (ii) sslstrip - transparently hijacks HTTP traffic and prevent HTTPS upgrade by watching for HTTPS links and redirecting. It then maps those links into either look-alike HTTP links or homograph-similar HTTPS links. All credentials are logged to the database (thanks Ian & Junaid). (iii) mitmproxy.py - allows for arbitary code injection, as well as the use of self-signed SSL certificates. By default we inject some JavaScipt which profiles the browser to discern the browser version, what plugins are installed, etc (thanks Willem).
Additionally, a traffic analysis component extracts and reassembles files. e.g. PDFs, VOiP calls, etc. (thanks Ian).
5. Higher Level Profiling? Given that we can intercept network traffic (and have clients' cookies/credentials/browsing habbits/etc) we can extract useful information via social media APIs. For example, we could retrieve all Facebook friends, or Twitter followers.
6. Data Visualization and Exploration? Snoopy has two interfaces on the server; a web interface (thanks Walter), and Maltego transforms.
-The Web Interface The web interface allows basic data exploration, as well as mapping. The mapping part is the most interesting - it displays the position of Snoopy Drones (and client devices within proximity) over time. This is depicted below:
-Maltego Maltego Radium has recently been released; and it is one awesome piece of kit for data exploration and visualisation.What's great about the Radium release is that you can combine multiple transforms together into 'machines'. A few example transformations were created, to demonstrate:
2. Devices at 44Con, pruned
Here we look at all devices and the SSIDs they probed for at 44Con. The pruning consisted of removing all SSIDs that only one client was looking for, or those for which more than 20 were probing for. This could reveal 'relationship' SSIDs. For example, if several people from the same company were attending- they could all be looking for their work SSID. In this case, we noticed the '44Con crew' network being quite popular. To further illustrate Snoopy we 'targeted' these poor chaps- figuring out where they live, as well as their Facebook friends (pulled from intercepted network traffic*).
The pi chart below depicts the proportion of observed devices per vendor, from the total sample of 77,498 devices. It is interesting to see Apple's dominance. pi_chart
The barchart below depicts my day sitting at King's Cross station. The horizontal axis depicts chunks of time per hour, and the vertical access number of unique device observations. We clearly see the rush hours.
Legal -Collecting anonymized statistics on thoroughfare. For example, Transport for London could deploy these devices at every London underground to get statistics on peak human traffic. This would allow them to deploy more staff, or open more pathways, etc. Such data over the period of months and years would likely be of use for future planning. -Penetration testers targeting clients to demonstrate the WiFi threat.
Borderline -This type of technology could likely appeal to advertisers. For example, a reseller of a certain brand of jeans may note that persons who prefer certain technologies (e.g. Apple) frequent certain locations. -Companies could deploy Drones in one of each of their establishments (supermarkets, nightclubs, etc) to monitor user preference. E.g. a observing a migration of customers from one establishment to another after the deployment of certain incentives (e.g. promotions, new layout). -Imagine the Government deploying hundreds of Drones all over a city, and then having field agents with mobile Drones in their pockets. This could be a novel way to track down or follow criminals. The other side of the coin of course being that they track all of us...
Illegal -Let's pretend we want to target David Beckham. We could attend several public events at which David is attending (Drone in pocket), ensuring we are within reasonable proximity to him. We would then look for overlap of commonly observed devices over time at all of these functions. Once we get down to one device observed via this intersection, we could assume the device belongs to David. Perhaps at this point we could bring up a rogue access point that only targets his device, and proceed maliciously from there. Or just satisfy ourselves by geolocating places he frequents. -Botnet infections, malware distribution. That doesn't sound very nice. Snoopy drones could be used to infect users' devices, either by injection malicious web traffic, or firing exploits from the Snoopy server at devices. -Unsolicited advertising. Imagine browsing the web, and an unscrupulous 3rd party injects viagra adverts at the top of every visited page?
Q. I use Apple/Android/Foobar - I'm safe! A. This attack is not dependent on device/manufacture. It's a function of the WiFi specification. The vast majority of observed devices were in fact Apple (>75%).
Q. How can I protect myself? A. Turn off your WiFi when you l leave home/work. Be cautions about using it in public places too - especially on open networks (like Starbucks). A. On Android and on your desktop/laptop you can selectively remove SSIDs from your saved list. As for iPhones there doesn't seem to be option - please correct me if I'm wrong? A. It'd be great to write an application for iPhone/Android that turns off probe-requests, and will only send them if a beacon from a known network name is received.
Q. Your research is dated and has been done before! A. Some of the individual components, perhaps. Having them strung together in our distributed configuration is new (AFAIK). Also, some original ideas where unfortunately published first; as often happens with these things.
Q. But I turn off WiFi, you'll never get me! A. It was interesting to note how many people actually leave WiFi on. e.g. 30,000 people at a single London station during one day. WiFi is only one avenue of attack, look out for the next release using Bluetooth, GSM, NFC, etc :P
Q. You're doing illegal things and you're going to jail! A. As mentioned earlier, the broadcast nature of probe-requests means no laws (in the UK) are being broken. Furthermore, I spoke to a BT Engineer at 44Con, and he told me that there's no copyright on SSID names - i.e. there's nothing illegal about pretending to be "BTOpenzone" or "SkyHome-AFA1". However, I suspect at the point where you start monitoring/modifying network traffic you may get in trouble. Interesting to note that in the USA a judge ruled that data interception on an open network is not illegal.
Q. But I run iOS 5/6 and they say this is fixed!! A. Mark Wuergler of Immunity, Inc did find a flaw whereby iOS devices leaked info about the last 3 networks they had connected to. The BSSID was included in ARP requests, which meant anyone sniffing the traffic originating from that device would be privy to the addresses. Snoopy only looks at broadcast SSIDs at this stage - and so this fix is unrelated. We haven't done any tests with the latest iOS, but will update the blog when we have done so.
Q. I want Snoopy! A. I'm working on it. Currently tidying up code, writing documentation, etc. Soon :-)