Evolutions in Offensive Toolkits: Phishing

Phishing – you’ve heard of it, know of it, and hopefully haven’t fallen victim to one of those nasty links yourself. Social Engineering is an attack vector that will never truly go away and continues to have a large sprawl as technology evolves. This continues to be ever true this year as we have seen different advancements in software realms like AI and Automation. For us here at Binary Defense, we have observed a specific tactic picking up speed – the use of automations to speed up Phishing attacks and lead to a compromise just moments away from a click.

Enter Phishing’s New Best Friend – Toolkits

A Phishing Toolkit is a collection of pre-packaged software and resources that malicious actors will use to quickly configure attack paths to obtain compromised user credentials. These typically include masquerading web pages designed to look like a legitimate service, e-mail templates that are providing some urgency or free item, and most recently automations to help scale operations outwards. The most important thing for these kits is they need to be efficient and capable of processing web requests to extract important information. Comparative to attacks of old where stolen credentials would be used days later – these automations can hijack a legitimate session live to compromise a user near-instantaneously.

For these types of kits, the core of the requirements is the ability to consistently utilize APIs and captures authentication information from the session itself. There’s a few different packages that have been utilized for this in the past, such as python-requests, powershell, Resty, go HTTP client – but within the industry there has significantly been an upsurgence in use of the Axios library. Axios differs from a lot of the other options available due to it’s ability to intercept data responses that typically are not as quick or complete as other clients. With this ability available to cybercriminals, there has been an insurgence of attacks focused on taking the abused credentials from a phishing URL to bypass or hijack MFA & conditional access policies. This means that even thought your organization might have protections in place – attackers are already finding ways to circumvent them.

A Brief Analysis of a Brief Takeover

Unfortunately, these attacks do occur in our ecosystem as well. Binary Defense was alerted last week to an incident where we observed a risk event for an Entra ID user authenticating into their environment. What we observed was a bit of a strange authenticate chain for this user – we saw an established session within the environment as normal performing their daily duties. Suddenly, a few hours in we saw some additional authentications into the environment – with one failure due to no MFA devices being configured. Then, a secondary authentication attempt occurred just one minute later from the same IP – with a new MFA device registered. The authentication still failed due to an established Conditional Access policy; but just moments later a successful login occurred with the same device within an appropriate location.

Within moments the session established from this secondary IP began to attempt to wreak havoc – removing any other MFA devices, resetting passwords, and enumerating the available different applications within the Office tenant. Thankfully MFA is not the only defense against malicious actors – and this organization had established Least Privilege for their accounts properly. The end user did not have access to any administrative groups or applications meaning that the actor did not have much to go on for additional routes. It was at this point that Binary Defense reached out to the customer and appropriate actions were taken to disable the account and reset credentials.

Attack Chain

If we break this attack pattern down to the barebones grease, there’s a few items to pay attention to for what happened to this user:

1. Reviewing the user’s activity before the secondary authentications, we were able to verify there was some e-mail activity occurring – including the receipt of a suspicious e-mail with an embedded link. While we could not procure logs specifically referencing a click the assumption is likely that the user did navigate to the link and submit their data. It’s likely that the device used to provide this was not a company managed device, like a personal phone.
2. If the user clicked the link – it’s likely true that their credentials were provided to a fake login for Microsoft. It may have sent them to a legitimate website after they were entered – but during that passthrough a token was captured.
3. The attacker then took this token and attempted to authenticate with the session; while they may have failed to do so, they were able to hijack the request and register a new MFA device.
4. The attacker then switched to a country with a VPN that the Conditional Access policy allowed – and bingo. They’re inside and free to do whatever they like.

Finding Opportunities

From the lens of a Detection Engineer – we need to review what’s available to us and say “where can I nail this guy”. It’s kind of like being a web detective if you think about it enough. Our goal as Defenders is to prevent malicious behavior as high in the chain as possible so we can make sure nothing catastrophic occurs.

Stepping back and reviewing this attack, there are some truths we can find within the logs:

1. We do not have a Email Security alert for this URL. This is due to the event not being flagged and is likely due to the indicators provided within the email. However – not every e-mail will be flagged as expected; which is why having Phishing Training for employees is still a key part of any security program.
2. We also do not have any Forward Proxy or Traffic logs for this event. Again – this is likely due to the device being used was not managed by the organization which can be true for many organizations. What is also true for every organization is that we don’t have budget for everyone to have a company phone so it’s not unrealistic to expect we won’t have this.
3. We do have something interesting – the authentication from the malicious actor. In this case we reviewed the authentication log and found something interesting within the User Agent: "userAgent": "axios/1.13.2". This is not typical of any normal user authentication as axios (as mentioned earlier) is a Javascript library typically used for automations. Potentially – an automation for a Phishing Toolkit.

So – knowing what we know now about our attack path, a Detection Opportunity arises. Enter a new Detection within our own DE Toolkit – Authentications from Programmatic User Agents. This is a fairly novel detection in most situations, as the only users who would ever login to their own account with a program legitimately are developers trying to create a new internal script or application.

Detection Opportunities

Each of the opportunities below are still relevant to have protections around in your organization in related to automated Phishing Toolkits:

• Malicious Email Not Remediated – review and contain any malicious e-mails sent to your organization to ensure no user attempts to use them.
• Phishing Link Clicked – if an e-mail is flagged and is acted upon, ensure to review all clicks to such links. This can help put together a timeline and help understand what was within the webpage navigated to.
• Authentication from Non-US Country – review authentications to user accounts from countries that are atypical for legitimate users within the business (where applicable).
• Authentication followed by 2FA Reset – review any authentications that have an MFA adjustment or deletion right after the attempt. This can be a clear indicator of an account takeover occurring in real time.
• Creation of Suspicious Inbox Rules – While not specifically related to our attack chain – consider this a bonus! Typically, malicious actors will try to linger in compromised accounts in order to obtain additional information, credentials, and potentially money. This is critical for any phishing defense within any organization.

Containment and Mitigation

• Immediate Containment
  • Block offending IPs, rotate credentials, and force logouts of all active sessions in order to ensure the attackers cannot access the user.
  • In privileged user scenarios – disable the user account immediately. This will prevent additional logins and mitigate any other activity the actor may be trying to perform.
• Post-Incident Cleanup
  • Delete any new 2FA methods that were added during the time of compromise, if applicable.
  • Purge the offending e-mail from the user’s inbox. Don’t forget to purge it from any other recipients within the organization.
• Establish a strong Conditional Access Policy
  • While geolocation may not have fully prevented our scenario – making stronger policies certainly can. Outside of just location, look to prevent authentications from non-managed devices within the organization. It may also make sense to prohibit certain applications from being accessed outside of the business.
• Phishing Education
  • Ensure to provide yearly (or more often) phishing exercises for your organization. The “Human Element” will always be present within any technology flow and the only way to protect them is to educate them. Run simulations and trainings as necessary.

Conclusion

So – all this to say that Phishing is still a novel threat vector within any environment. However, it’s important to understand that cybercriminals are always looking to improve which means we need to as well.

Here at Binary Defense, we’re always keeping an eye out and looking to improve. Looking for new Detection Techniques within any scenario can lead to real results that help us protect against the next attempt.