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!