Monday, 26 September 2011

SID de-duplication

On the 3rd November 2009, Sysinternals retired ‘NewSID’, a utility that changes a computers machine Security Identifier (machine SID), but why? I still see people cloning virtual machines as a stardard task, but does it really need to be done?

What is a SID?

A Security Identifier (commonly abbreviated to SID) is a unique name (an alphanumeric character string) which is assigned by a Windows Domain controller during the log on process that is used to identify a subject, such as a user or a group of users in a network of NT/2000 systems.

How are duplicate SIDs created?

For those who are unfamiliar with the concept, when machines are cloned using imaged systems the new machine will contain the same SID as the original. If two machines have the same machine SID, then accounts or groups on those systems might have the same SID.

Common sense in de-duplication?

As most IT professionals who work with virtual technologies will attest, when creating virtual machines from templates, conventional wisdom dictates that the new machine’s SID must be changed as the clone retains a facsimile of the parent’s. However, Mark Russinovic (Microsoft Fellow, OS Guru and creator of ‘NewSID’)and Microsoft have delved deeper into this idea and concluded that changing the SID of machines that contain facsimile entries is unnecessary. This came to light when Mark was investigating bugs with NewSID in windows Vista, he realised that he could not conceive of a scenario where duplicate SIDs could cause a security risk / vulnerability. Mark took this concept to Microsoft’s Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue – further investigation by Microsoft is yet to find such a risk. Food for thought next time you clone a machine.

To view the entire article, please see Mark’s blog:

PHUKDs - An Oldie but a Goodie!

A topic I’ve wanted to blog about for a while is the use of PHUKDs as an attack vector in Penetration testing. Firstly, I’d like to discuss the background of how these devices work and why they have come into being.

A PHUKD is a USB device, which is configured in such a way that it is presented to the victim machine as a USB Keyboard/mouse. The reason this has been developed is so that even when the autorun.inf and U3s are disabled on a machine, malicious inputs can be delivered to the victim quickly, accurately and in an automated fashion. Therefore, the key benefits of these devices as delivery systems are that it cannot be blocked by U3 and autorun process blocking and keystrokes can be precompiled and run quickly on the target machine.

The key benefits to a pen tester:

  • Extremely fast keystrokes, without errors. This is important when physical access time to the target is limited.
  • Works even if U3 autorun is turned off.
  • Draws less attention than sitting down in front of the terminal would. The target turns their head for a minute, the pen-tester plugs in the PHUKD.
  • The HID can also be set as a logic or time-bomb.
  • It is possible to embed a hub and a flash drive in your package so that you have storage and the programmable USB HID into a single package.
  • Embed your device in a USB toy or peripheral and give it to your target as a 'gift'. Packaging that looks like a normal thumb drive is also an option.
  • After your Trojan USB device is in place, program it to "wake up", mount on-board storage, run a program that fakes an error to cover what it is doing (fake BSOD for example).
I still think that these are completely relevant devices and really effective if you can penetrate the boarders of an organisation on a test.

A detailed guide on creating PHUKDs is available on the link provided above to irongeek’s blog post and a really interesting video from an old DefCON talk is included below. It’s also worth noting that it’s possible to integrate this attack using Metasploit. The full details of their Teensy USB HID Attack Vector are available here.

Friday, 23 September 2011

Real-life Challenges in Social Engineering as a Penetration Tester


Recently, I’ve been lucky enough to get to work with some interesting clients who’ve wanted some quite openly scoped social engineering tests. It’s not something I do on a really regular basis, but it’s always been a big area of interest and it’s something I enjoy and have hopefully improved at over the last two-and-a-half years.

That said, I’m no guru and neither do I profess that I’m doing anything super-new or revolutionary, I just hope that this helps some other testers out there who’re facing similar challenges and opens the door to a few discussions and interesting comments. Any feedbacks or shouts of ‘n00b’ will be eagerly met with an open ear. However, I digress. The following posts are a bit of a ‘brain-spuzz’ discussing how I’ve constructed some of the testing pretexts, discussing what works (and more importantly what doesn’t) when trying to launch a successful Social Engineering campaign. This is a particularly effective way of attacking organisations where they have effective Network perimeter controls.

However, in the money-centric world of IT, it’s often hard to get buy-in to the idea that testing this sort of attack vector is a.) fair or b.) representative of what’s happening (especially in the context of large or public sector organisations) in the wild. It can often be very difficult in pre-sales meetings to ‘tack-on’ a few extra days to conduct social engineering, let alone scope a comprehensive engagement as many info sec managers are quite old-school (or constrained by budget) and prefer to leave this out of scope. One technique to encourage inclusion, is to make social engineering implicit in your testing methodology by presenting a scope where social engineering is intertwined with other areas of assessment. This can be either technical (such as creating website clones) or processual (such as spoofing a phone call to a service desk to persuade them to give you password reset information) – I’m not saying these are the only areas of social engineering, but it’s one way to split things out quite generally without thinking too deeply about specific attacks. Blended, rather than staged modular attacks, are (in my humble opinion) much more effective and better value for clients.

Spear Phishing – Part 1 – OSINT and Pretexting

Firstly, as I’m sure most testers, IT security folks and Wikipedophiles are aware, Spear Phishing is a way of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication which is specifically tailored to entice a user to perform an action that will compromise their data and/or client machine. Information specific to the individual(s) targeted, is gathered and used to elicit a specific response desired by the attacker, for example opening a PDF or clicking on a link.

The idea for these posts came after a recent engagement with a client, which called specifically for a tailored Spear Phishing attack, with no prior information pertaining to the targets, apart from a company name and website. Although this seems fairly contrived, when given a short time-scale it may be best to agree a single attack vector with the client as it will set some boundaries but also keep you on track and stop the ‘magpie effect’, which I know a lot of testers suffer from. The downside of this approach is that it will remove a lot of creativity, which can often spawn the best attacks.

With very little information provided, the obvious place to start is footprinting (or OSINT gathering) as is fairly standard (when looking at methodologies such as the rather bloated OSTMM and new kid on the block PTES). The first tool I always reach for in this scenario is FOCA. I have moved away from Maltego somewhat after annoying licencing issues with transforms, impossible to obtain API keys and their development effort seeming to push towards visualisation of data structures. However, a great presentation of the latest release by Roelof at 44Con may persuade me to try again.

FOCA is an amazing tool, it has many interesting functions (some only available in the pro version), but the part that will be of most interest is document grabbing and metadata extraction. It is possible to point FOCA at a URL and for it to locate and then download (if instructed) all the files on the site and extract all the metadata from the documents. If you’re not familiar with the type of information contained within the metadata of office documents and PDFs, you will probably be surprised at the things you can find (e.g. usernames, software versions, internal paths and email addresses). The main value of this, is that it provides reams of data pertaining to the internal workings of the organisation you’re targeting. Information such as usernames can help you work out the naming convention they’re using for AD for example. Moreover, cross-referencing the usernames with machine names and email addresses means that you can start building up individual profiles of your targets, which can then be combined with more generic social media and Google searches to create detailed anthologies of your targets. If there is more time at this stage, I would recommend using Maltego with some of the information gathered, as this sort of cross-referencing is what the tool is good at. In terms of information gathering a really good tool for storing all the raw information in is ‘BasKet’; those of you who’ve read ‘Social Engineering: The Art of Human Hacking’ by Chris Hadnagy will already be familiar with this tool. However, if your base OS is Windows, OneNote in MS Office is also great as an informational dumping ground and note-taking muse.

Once the profiling is completely, or more importantly, the time you have allocated for this phase of testing is, it’s a good time to start conceiving of a pretext for the attack (if you haven’t already). Pretexting, as defined by Hadnagy, is “the act of creating an invented scenario to persuade a targeted victim to release information or perform some action”. To invent a believable pretext is often more tricky than it sounds, but it’s key to eliciting the desired response from the target. This is the point at which all the scraps information you have gathered becomes important, as a pretext that is directly related to your targets that is straightforward, is more likely to work. A goldmine of information I have found useful is the LinkedIn search using the ‘updates’ filter. Organisations are using LinkedIn more and more and you’d be surprised at some of the internal discussions that happen on public forums. Obviously, this is no substitute for solid Googling techniques, Twitter traipsing and Bing bashing, but it’s a good starting place and my ‘top tip’. Once you have done this a few times, the right subjects tend to jump out at you.

When you have found something suitably ‘buzzy’ or controversial that will tweak people’s interest enough to invoke a response, it’s time to start thinking about logically combining a PDF or a malicious URL to the pretext. Key questions to ask yourself are:

Who would send information pertaining to this pretext, based on my research?
Who would receive this email?
What would motivate the targets to open the email / attachment?

An example of a good pretext I have used was created using LinkedIn. I saw that the organisation had upset quite a few people over a new policy change that would affect a lot of people in the industry and the public. The inner decision making process was exposed by staff discussions in attack and defence of the organisation. These types of people are great targets as they’re obviously vocal on the topic, so the appearance of an email from someone high up in the company (perhaps with a fake email chain below saying ‘<insertname> has some great ideas on this’) will be too enticing to miss; Even if it’s been blocked by a third party email filter and held in quarantine!

With those questions answered, you’re in a good place to create a plan of attack and start addressing technical aspects of the test (which I’m sure most testers will have been doing all along). I think that’s enough for part one of this mini-series; part two will be a lot more technical and discuss the selection of a delivery method (Gmail, SendMail  or another form of open relay), payload (reverse shells etc.), avoiding detection (encoding etc) and the effectiveness of MSF and SET frameworks against in-depth protection. I hope this isn't boring people already!

Thursday, 22 September 2011

Welcome to

Hello, and welcome to I have finally gotten around to writing a few blog posts and shall be slowly unleashing them upon the world. Any comments welcome and feedback positive or negative always enjoyed. Also, anyone who wants to guest post is welcome to, just tweet me @pentesticles.

Lawrence (and Ben)