The devil is in the details

This is a post about how going the extra mile in creating a phishing campaign is very likely to pay dividends.

We are referring to actions in a phishing campaign which are often overlooked or do not seem as important to the red team, as these are sometimes considered to not directly affect the end goal of the campaign (most often submission of login information or malware execution). However, an essential objective of a red-team-oriented phishing campaign is to also avoid suspicion and fly under the radar.

Apart from carefully choosing and configuring the offensive infrastructure; choosing the phishing domains, giving a legitimate look to the landing pages, the email communication, the type of malware and coming up with a credible pretext, it is also equally crucial for the red team to put victim users at ease after inducing an action.

The credential stealing attack greatly relies on the successful cloning of the impersonated portal and a plausible, legitimate pretext.

[Reminder] Always assess whether email spoofing is possible, as the credential stealer, among, other spear-phishing attacks, work best when seemed to originate from the inside of the organisation. Naturally, internal origin in general adds significantly more credibility, urgency and an official look to any pretext.

Regardless of the delivery, it is very important to define how the web server is tasked with handling the submission requests.

First of all, if the red team is cloning a page which belongs to the target organisation, every component should behave and look as closely as possible to the original system. It helps that all static content is served not from the cloned site (e.g. JavaScript and CSS files) but fetched and loaded from the red team’s domains. Not only, having the CSS hosted locally allows the red team to quickly create and customize additional content should the situation ask for it, but most importantly, loading web resources cross-domain (from the lookalike domain to the legitimate one) is discouraged as it can trivially give away the cloning attack and lead to escalation much faster.

Post-Execution Actions

Another important factor is the post action. Usually, after submitting credentials we want to redirect the user to the legitimate portal so that if the end-user re-enters their credentials, authentication is successful. This way the attack is likely to discourage suspicion as the first attempt will be overlooked as a mistake by the victim user.

The above is a simple excerpt of JavaScript that is used for the purpose of redirecting the user back to the legitimate system after capturing their credentials.

Sending a link to a malicious file or application to victim users normally falls outside their norms and patterns of expected communication. For both credential stealing and malware execution attacks, it is prudent to put together a post-action (often “thank you/acknowledged” page), something that will put the victims at ease or will give them the reassurance they need. This is often a key factor for avoiding reports or even spreading of the pretext within members of staff and hence, increase chances of mass interaction with the campaign. The following is an example of a “thank you” page used in an actual engagement.

This next example is from a malicious HTA file which loads a cloned gallery page upon execution to demonstrate the success of a company event to the target users.

The cloned page which is triggered by the HTA contains images and custom text relevant to the company event which adds to the overall credibility of the pretext.

Build rapport

Nothing increases a red team’s chances of success like using users’ replies against them.

Out of office automated replies often contain names of other members of staff for escalation purposes which can be used in subsequent phishing attempts so as to provide a sense of familiarity. Thus, the email can seem to reach a user after a referral by another employee and not as unexpectedly.

Often, users interact with a campaign with replies about the received content or simply acknowledging receipt. These interactions should also be leveraged to the best of the red team’s ability with the creation of additional content tailored to the response. It is logical for any follow-up email/payload, that is sent as a reply to a user’s response, to have higher chances of successful interaction compared to an unanticipated approach.

Trackers

Finally, since a lot of things can go wrong in a phishing exercise, depending on the security controls we are facing, it is essential that we have sufficient trackers, preferably one in each step of the execution flow. Trackers are mechanisms to identify which steps in the execution flow were completed successfully and give the red team visibility of where user interaction was disrupted/ended or where the malware failed to perform.

Let us assume we have the following phishing campaign where we have introduced the following trackers:

1. Hidden tracking image in email
2. Landing page link
3. Office-based malware download link
4. Link to an image in a footer/header to indicate the document was opened
5. Request to a remote resource after macros have been enabled
6. Request to another resource to indicate the target host belongs to the right AD domain
7. Requests to remotely-hosted encrypted shellcode/ fetch the decryption key etc.

Each request received on the server-side and logged by the red team indicates another step of the execution flow is completed.

The information the red team can obtain from the above can be paramount to their success as it not only allows for understanding what went wrong (e.g. web proxy blocking all requests to the domain, macros disabled by default, application whitelisting, etc.) but also helps the red team calibrate any subsequent campaigns accordingly and finally, report more accurately about the phishing phase of the engagement.