Tracking the proxy: a canary-based approach to locate users from Adversary-in-the-Middle Phishing

As we step through a busy season of ransomware, financial scams involving deepfake, and sophisticated phishing campaigns, we continue to witness campaigns targeting enterprise users with Adversary-in-the-Middle (AiTM) attacks. As discussed in our previous blog post[1], AiTM leverages proxy-based toolkits such as Evilginx and EvilProxy. This technique has proven extremely effective, even in our red team assignments, in capturing credentials, and authenticated sessions.

In this article, we explore a use case in Microsoft 365, in which a feature has allowed opportunities to build a canary-based detection mechanism in an unconventional way. Inspired by the effectiveness of bug bounty programs in identifying vulnerabilities, this strategy aims to locate and mitigate the risks associated with AiTM attacks.

Understanding Adversary-in-the-Middle Attacks

Traditionally, in combating phishing and scams, our approach to protecting accounts in Microsoft 365 has revolved around the use of strong credentials and multi-factor authentication (MFA). These proved mostly effective against password brute-force and credential harvesting with fake phishing sites. Coupling this with new solutions such as Microsoft’s Intune or Mobile Device Management (MDM) applications, threat actors need to explore new ways of gaining access to their victims’ Microsoft 365.

AiTM attacks have proven to be extremely effective choice of technique leveraged by cybercriminals. We have previously covered use cases observed in phishing campaigns targeting our clients in Hong Kong, Macau, and in the region. This is because, unlike traditional phishing techniques, AiTM captures both the victims’ passwords, as well as valid login sessions cookie – another form of valid credentials. Threat actors have also explored new ways of using the compromised identities, not just to access confidential data from the victim’s mailbox, but also the data files on OneDrive and SharePoint.

From a defender’s perspective, it is difficult to identify individuals who has fallen victim to this kind of technique as, unlike traditional phishing, the victim is engaged in an interactive flow, supplying both credentials and any multi-factor authentication. The phishing site acts as an intermediatory internet reverse proxy, completing the authentication on the victim’s behalf and, capturing the materials in between. The diagram below illustrates a complete flow of how a threat actor can compromise the victim’s account.

Figure 1: Typical compromise flow of an AiTM attack

In general, detection of a compromised user account would require heuristics approaches (e.g. Microsoft’s Risky IP Address, or Impossible Travel) or detection of specific threat-actor activities (e.g. New-InboxRule). These are very effective in identifying anomalies in interactions with the mailbox, prompting additional investigations and mitigations with the downside being, in our experience, a late detection where the threat actor might have taken actions or information with the victim’s account.

The Canary-Based Approach to Detection

For those experienced in cyber defense, canaries are a familiar tool used to provide detection opportunities against specific behaviors. They act like tripwires or indicators which are designed to stand out in attack scenarios. A prime example is “honey accounts” in Active Directory environment, where a failed attempt to log in to this decoy account should warrant immediate attention to identify the source for potential behavior in the environment.

How can we do the same in our use case in M365? Going back to our drawing board, the authentication process in both normal and AiTM attack scenario involves interaction with the official Azure login page. Earlier this year, security researchers at IronPeak identified a feature in Azure called “Company Branding” which can enable such a detection mechanism.

The reader can follow the original blog post here.[2]

Company Branding is a feature that allows Azure administrators to apply branding to their login page by setting company logos, brand colors, and more through customising a cascading style sheets (CSS) file. A user browsing the login page will load the corresponding components referencing the style sheets. It is then possible, by introducing a single-pixel web-beacon as a CSS component, to capture referred request to the beacon, and identify if a user is falling victim to a phishing site.

Figure 2: Canary-based detection via CSS component

Setting up canary-URL for detecting AiTM

The section below outlines sample steps to configure a canary-based detection for AiTM attack on Microsoft 365 platform. This is based on the research conducted by IronPeak team.

To begin, download a copy of the template CSS file available from Microsoft.[3] Add the custom reference canary URL to the CSS file template and upload to the sign-in page.

Figure 3: Addition of custom reference canary URL to CSS template

Access the “Company Branding” section of Microsoft Entra admin center. Click “Edit” for the default sign-in, or corresponding sign-in pages.

Figure 4: Edit Company Branding in Microsoft Entra admin center

Select the “Layout” tab and upload the customised CSS file under the “Custom CSS” section.

Figure 5: Add Custom CSS

The configuration will take effect during new login against M365 at the login page (e.g. https://login.microsoftonline.com).

Figure 6: Sample implementation of custom reference canary URL via CSS template

As a website is created in the detection site, a web server can be configured to capture the full request, including header values such as “Referrer”. Note that the existence of the requested file does not matter as we just needed the web service to capture the request. A sample set of logs is shown below.

47.39.x.x - - [03/Apr/2024:03:43:56 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"

174.102.x.x - - [03/Apr/2024:03:47:30 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://totally-not-phishing.site/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"

185.240.x.x - - [03/Apr/2024:03:47:30 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"

The key point here is that the canary-URL is triggered when the user key in the email address i.e. the log is not indicative of an access session or credentials compromise. However, we can take steps to determine if an AiTM attack has taken place:

  • Determine if the URL specified in the “Referrer” field above exhibits behavior of an AiTM phishing portal
  • Review the Microsoft 365 logs to identify the actual user behind the IP address  
  • If a successful authentication has matched the logs, we can determine that the user account has been compromised : perform the necessary mitigations e.g. revoke sessions, credentials reset, inbox rule cleanup, etc.

Faring against advance phishing kits

While this canary URL is effective against open-source, proxy-based phishing framework (e.g. Evilginx), there are other phishing toolkits which take a different approach in displaying contents to the victim. One example is the more advanced Phishing-as-a-Service (PhaaS) platforms, such as “Caffeine” or “Tycoon 2FA”.

In our research, these phishing kits are well-designed to hide from public scanners behind Cloudflare or other anti-DDoS pages. During interaction, they also behave differently by displaying pre-loaded components and styles from the official Microsoft 365 login pages to the user, while leveraging embedded JavaScript as the API engine with Microsoft 365 in authentication. In other words, the victim is not interacting directly with the official Microsoft 365 login page and thus, the custom CSS files as well as the canary-URL will not be triggered.

An example of such a page is shown below.

Figure 7: Sample phishing site with pre-loaded components and styles, and embedded JavaScript

This seems like a bypass of the canary-URL detection, but not all hope is lost.

Since we are using canary-URL to collect data for every access to the official Microsoft 365, the resulting data set can be compared against the Azure sign-in log. The analysis of data will still allow isolation of IP addresses in login records that security analysts should further conduct review.

Figure 8: Sample detection via canary-URL

Conclusion

In an era of increasingly sophisticated cyber threats, the detection of AiTM attacks is of paramount importance. The canary-based approach presents a proactive strategy to identifying victims in AiTM attacks. By combining dynamic canary URL and behavioral analysis, organisations can enhance their security posture and protect sensitive data from falling into the wrong hands.

Canary-based approach uses triggers to create new opportunities in attack detection. The Canary URL above targets anomalies as early as the authentication process, reduces the time-to-detect duration in AiTM attack, and allows for prompt response and mitigation.

This technique has proven effective in combating phishing toolkits such as Evilginx. As cybercriminals up their game with additional Phishing-as-a-Service frameworks, we shall continuously evaluate the limitations in our detection tricks and explore additional techniques or data-centric approaches to identify anomalies.

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Watch Out for the Adversary-in-the-Middle: Multi-Stage AiTM Phishing and Business Email Compromise Campaign

PwC’s Dark Lab recently responded to a Business Email Compromise incident, leading to the discovery of an opportunistic multi-stage Adversary-in-the-Middle campaign.

Business Email Compromise (BEC) attacks persist as one of the most popular scam strategies among opportunistic cybercriminals. BEC attacks refer to a form of social engineering whereby malicious actors attempt to defraud organisations by hacking into legitimate business email accounts and impersonating employees and third parties for direct monetary gains.

Though these attacks have existed since the dawn of the Internet, they continue to be a highly lucrative avenue for attackers given the ability to scale operations target multiple victims simultaneously at a low setup cost. Furthermore, as organisations have heavily prioritised efforts to mature their cyber postures over the last few years, we observe a significant shift away from malware towards identity-based attacks as attackers leverage valid credentials to disguise their activities. In the past few years, an increasingly common strategy is to leverage phishing toolkits to steal valid credentials as well as login sessions, bypassing multi-factor authentication (MFA).

In this two-part series, we showcase two classic Adversary-in-the-Middle (AiTM) campaigns targeting Hong Kong-based victims. In part one, we shared our technical analysis on the ongoing campaign leveraging the Evil QR tool to hijack Hong Kong and Macau-based victims’ WhatsApp accounts.[1] This blog piece provides a technical analysis on our incident response experience with a multi-stage Adversary-in-the-Middle (AiTM) phishing and BEC attack, which led to the discovery of a wide-scale, opportunistic campaign weaponising a sophisticated phishing toolkit, Evilginx and EvilProxy.  

Initial Access

The attack initiated via the delivery of a phishing email from joingreatlife[.]com, with a lure masquerading as a DocuSign notification for document review and signature.

Figure 1: Screenshot of phishing email

The phishing emails originated from the joingreatlife[.]com sender domain, which we assessed to be a legitimate business based on the WHOIS records indicating the domain was registered in 2013, and multiple linked social media accounts, including an actively updated Facebook account, and no malicious flagging by security solutions.[2],[3],[4],[5] Due to their lack of valid SPF, DKIM, or DMARC record as at the time of investigation[6], we hypothesise that the legitimate business was likely spoofed or compromised to deliver phishing emails.

Figure 2: Flagged malicious joingreatlife[.]com sub-domains

Through further review of the victim’s mailbox, it was observed that the victim was repeatedly targeted by multiple phishing emails from senders such as ‘cv@service[.]bosszhipin[.]com’ between March 2022 and June 2023. Pivoting on the email address, we discovered that cv@service[.]bosszhipin[.]com has been historically flagged for sending spam and phishing emails.[7] Consistent with observations of the joingreatlife[.]com domain, we validated the bosszhipin[.]com domain to be serving legitimate business content[8], and was likely spoofed by malicious actors as a result of the lack of valid DKIM or DMARC record.[9]

Upon clicking on the ‘Review Document’ button within the phishing email, the victim was redirected to a Ticketmaster domain (engage.ticketmaster.com) before redirecting to the actual phishing URL hosted on an online coding sandbox website (hx5g6s.codesandbox[.]io), which then further redirected the user to their phishing site hosted at IP address 134.209.186[.]170. We hypothesise that the multi-redirect approach initiated via the legitimate intermediate domains was employed to evade detection, confuse security analysis and blocking by the victim organisation’s spam filters.

Investigation into 134.209.186[.]170 revealed the IP address to be flagged as malicious and reported in multiple occasions in July 2023.[10] Furthermore, the same IP address (134.209.186[.]170) was noted to be historically hosting a phishing site resembling a OAuth-based login portal – a matching indicators of a credentials- or session-harvesting site leveraging the AiTM attack.[11]

Figure 3: 134.209.186[.]170 flagged malicious, hosting OAuth phishing site

The phishing site served as a proxy between the victim and the legitimate Microsoft login page. As the victim performed a legitimate login with multi-factor authentication (MFA), the attacker operated as an adversary-in-the-middle, using the captured OAuth access token to bypass MFA and obtain the victim’s valid logon session, resulting in a successful impersonation with the victim’s identity to the legitimate resources on M365, including Outlook, SharePoint, or other applications as accessible by the victim.[12]

Persistence and Defense Evasion

Subsequent to logging into the victim’s mailbox, the attacker (85.209.176[.]200) registered a new MFA authentication method and attempted to access the victim’s mailbox via a legitimate, external application (PerfectData Software) to establish persistent access. To maintain stealth, the attacker (147.124.209[.]237) modified mailbox rules to reroute emails to the victim’s RSS Subscriptions folder, altered email folder arrangements, and accessed two SharePoint files. As observed at each stage of their attack,  the threat actor was logged using a different IP address  for each activity to conceal their identity and location, and further evade detection.

Impact

Leveraging the compromised email account, the attacker (104.254.90[.]195) impersonated the victim’s identity to send two phishing emails. The first email was sent to an external contact, containing no contents. The second email was sent to an internal employee containing a fraudulent transaction invoice attachment, indicating an attempt to facilitate unauthorised fund transfers. At this stage, the victim organisation detected and blocked the fraudulent fund request attempt and proceeded to conduct containment measures to reset the compromised credentials and revoke the unauthorised login sessions. Based on our observations, we assessed that the malicious actor conducted the AiTM attack to perform the email account takeover for financially-motivated intent.

Uncovering the wide-scale AiTM campaign

Pivoting on the phishing email subject title “Completed: Complete Doc viaSign: #2,” we identified over 50 files uploaded between 3 July and 18 July 2023[13] which contained redirects to the same embedded URL (http://links[.]engage[.]ticketmaster[.]com). Paired with the observed existence of the phishing email structure since December 2021, this indicated that the victim was phished as a part of an ongoing opportunistic campaign which researchers have reported as a multi-stage AiTM phishing and business email compromise (BEC) campaign.

Potential Use of the Caffeine Phishing Toolkit

Pivoting on the malicious link, we assessed that the link was likely launched from a phishing toolkit to steal valid sessions. We observed that the malicious link leveraged the Ticketmaster domain to obfuscate the malicious payload to bypass mail detection rules and deliver malicious payloads via browser redirects to codesandbox.io.[14] Further  pivoting on the Ticketmaster domain, we observed potential relations to a Phishing-as-a-Service (PhaaS) platform “Caffeine”, which provides subscribers phishing email templates with legitimate URLs to contain malicious payloads that operate to steal credentials (e.g. passwords, session tokens) through third-party sites such as codesandbox.io to evade detection.[15] [16] This is consistent with the observations in this phishing campaign and corresponding telemetry, as evidenced in Figure 4.

Figure 4: Phishing email redirects leveraging legitimate services to redirect to payloads hosted on codesandbox.io

Weaponising Evilginx and EvilProxy

Through deeper inspection, we discovered that the IP (134.209.186[.]170) address associated with the attackers were involved with several other phishing submissions submitted by other users. These submissions revealed that the domains used by the attackers serve pages that are consistent with our observed victim’s sessions stealing activities. The user emails passed in the web request were also observed to be consistent with other relevant schemes. Through these observations, we assessed with high confidence that the threat actors leveraged Evilginx and EvilProxy as a means to bypass two-factor authentication (2FA) and that these session stealing methods were the initial foothold that enabled the threat actor to gain access to the victim’s corporate resources.

Evilginx is an advanced AiTM attack framework capable of bypassing 2FA and intercepting legitimate session cookies.[17] This is a significant capability for attackers who can consequently conduct their phishing campaigns without capturing credentials, as attackers can impersonate victims without password knowledge to gain unauthorised access.

EvilProxy is a Phishing-as-a-Service (PhaaS) toolkit operating as a powerful proxy tool, redirecting victims’ web traffic through attacker-controlled servers.[18] The tool enables attackers to not only capture login credentials but also manipulate web content in real-time, presenting victims with malicious payloads or further deceptive content.

Conclusion

Based on our findings, we assessed with high confidence that the victim was compromised as part of a wide-scale, opportunistic social engineering campaign utilising Evilginx and EvilProxy to bypass MFA and subsequently perform a BEC attack via internal spear phishing. Due to the lack of information and reporting on the specific IOCs collected during the incident, and the use of widely adopted techniques and toolkits, we did not derive conclusive evidence to ascertain the specific threat actor responsible for the attack.

The two campaigns explored in this two-part blog series are just two of the many case studies supporting our observations that the cyber threat landscape is rapidly evolving, with threat actors increasingly shifting towards-identity based attacks. As organisations worldwide have prioritised efforts to harden their cybersecurity posture, we observe threat actors adapt by weaponising valid credentials to bypass defences under the guise of trusted identities. Furthermore, in both cases, we observed that threat actors are not only targeting passwords, but valid sessions to maintain persistent, elusive access to victim environments.

Whilst identity-based attacks are by no means novel, they continue to pose a significant threat to organisations given the complexity of distinguishing between legitimate and malicious use of authorised access. To effectively protect against identity-based attacks, it is vital that organisations and individuals enforce a layered defence strategy combining robust preventative measures with behavioural-based detection.  

Join us on November 7 2023 for PwC’s annual Hack A Day Conference: Register Here

Recommendations

Preventive

  • Implement sender authentication measures including Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication (DMARC) to reduce susceptibility to phishing and spoofing attacks.
  • Review existing Microsoft 365 configuration and update their security solutions and network devices (including external firewall, web proxies). For example, enforcing spam filters configurations to ensure all inbound emails are processed by spam filtering policies prior to delivery, reviewing email forwarding rules to identify any potential external malicious email forwarding, and restricting O365 access via geo-fencing to prevent authorised access or account brute-force over O365.
  • While this incident highlighted how threat actors can potentially bypass multi-factor authentication (MFA), MFA remains a critical layer of protection against credential-abuse attacks. Best practices include:
    • Ensuring MFA solutions restrict the number of failed authentication attempts, login attempts are monitored and alerted for anomalous activity, and enforcing strong password policy requirements.
    • Leveraging features such as conditional access to setup session timeouts or block sign-ins from illegitimate access to the resources by third party devices, or overseas where applicable, in combination with features such as Mobile Device Management (MDM).
  • Enhance business security controls by establishing procedures for financial transactions and their respective handling procedures. For example, automatic bank notifications for outbound transaction verifications and mandatory out-of-band verifications of bank account changes.
  • Regularly conduct user awareness training to educate employees on the latest social engineering techniques deployed, indicators to identify potentially malicious activity, and process for reporting suspicious activity.
  • Organisations should conduct young domain monitoring to proactively uncover potential phishing campaigns targeting, or likely to target, your organisation.

Detective

  • Monitor user account activity for email forwarding, excessive document downloads or deletions and excessive file sharing. Depending on the user (e.g. users operating within functions more likely to be targeted in phishing attacks, such as HR, Finance, C-Suite personnel), setup monitoring for specific activities, such as monitoring for the creation of mail rules that involve moving to folders to RSS.
  • Establish behavioural-based detection rules that will expire tokens and disable sign in when suspicious account behaviour is detected. Indicators of suspicious behaviour could include access from abnormal geolocations and accessing servers not typically accessed by the user identity. Further, leverage features such as “risky sign-in” to receive notifications of suspicious authentication attempts and respond in-time to threats.
  • We further advise organisations to establish an O365 mailbox rule to detect and block inbound/outbound traffic from the malicious IPs listed in our Indicators of Compromise (IoC) section.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques from the campaign:

  • T1589.002 – Gather Victim Identity Information: Email Addresses Resource Development
  • T1584.004 – Compromise Infrastructure: Server
  • T1588.002 – Obtain Capabilities: Tool
  • T1566.002 – Phishing: Spear Phishing Link
  • T1189 – Drive-by Compromise
  • T1204.001 – User Execution: Malicious Link
  • T1098.005 – Account Manipulation: Device Registration

Indicators of Compromise (IoCs)

We include the observed IoCs:

IoCTypeDescription
brad.hansen[@]joingreatlife[.]comEmail SenderEmail Sender of phishing email
Completed: Complete Doc viaSign: #2Email SenderEmail Sender of phishing email
hx5g6s.codesandbox[.]ioDomainOnline coding sandbox website
lmo-halbacea.halbacea[.]comDomainDomain associated with phishing web server
lmolmoworked-inc-docs-signedservices.remmellsp.]comDomainDomain associated with phishing web server
134.209.186[.]170IP AddressIP Address of OAuth phishing web server, threat actor logon
85.209.176[.]200IP AddressIP Address of threat actor logon, deliver phishing email, register Authenticator App and attempt to connection to external application “PerfectData Software”
147.124.209[.]237IP AddressIP Address of threat actor logon, create new inbox rule
51.195.198[.]33IP AddressIP Address of threat actor logon, access SharePoint files
104.254.90[.]195IP AddressIP Address of threat actor logon, deliver phishing email, create new inbox rule

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.

Phishing for Profit: Business Email Compromises

There are plenty of phish in the sea and they’re back with new tricks! Dark Lab responds to multiple business email compromise campaigns targeting Hong Kong. We outline two recent incidents, sharing the Tactics, Techniques, and Procedures (TTPs) observed, and recommendations on how to prevent, detect, and respond to a phishing attack.

Business email compromise (BEC) is a social engineering attack which broadly refers to a malicious threat actor attempting to defraud organisations by hacking into their email accounts and impersonating employees and third parties. These phishing attacks have existed for many years, though remain prevalent due to their ability to continuously illicit emotional reactions of victims, thereby triggering an unintended response such as performing actions that lead to undesirable consequences. This is further exacerbated by the fact that BEC attacks typically yield a high return on investment given the low cost of setup and ability to scale operations globally.

The impact of BEC attacks are most evident in the amount of reported losses. The Federal Bureau of Investigation (FBI) reported that BEC attacks amounted to a staggering US$43 billion financial loss globally between 2016 to 2021.[1] Meanwhile, the Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) reportedly handled 3,737 phishing incidents in 2021, which represented almost half of the total reportedly handled incidents and was up 7 percent from 2020, rising for the fourth consecutive year.[2]

PwC’s Dark Lab also responded to an increased number of BEC campaigns in 2022. Two particular incidents stood out for their automated “spray and pray” approach to achieve initial access, followed by performing calculated and stealthy manual actions to persist in the Microsoft 365 environment to facilitate ongoing reconnaissance with the aim of effectively impersonating their victim to convince other staff members to approve fund transfers to the threat actor’s bank account. We elaborate the tactics, techniques and procedures (TTPs) that these threat actors leveraged and provide our recommendations on how to prevent, detect, and respond to BEC attacks should they befall your organisation. We further examine the rising trend of phishing kits in large scale phishing operations, enabling low-skilled threat actors to develop compelling phishing campaigns and bypass multi-factor authentication.

Case Study: Global Campaign by Opportunistic Cybercriminal of Unknown Origin

PwC’s Dark Lab responded to an incident in 2Q 2022 that involved a local property investment, management, and development company. The victim’s Microsoft Office 365 account was compromised via a phishing email from the sender domain macopas[.]com, with a link re-directing the victim to a fake Outlook login portal developed and hosted by the threat actor. To convince the victim to provide their password, the Outlook page pre-populated their email address. Given the victim’s mailbox did not have multi-factor authentication (MFA) enabled, the threat actor could obtain full access to the mailbox with a valid password.

The threat actor proceeded to perform three (3) manual actions to persist in the environment and gain more insights on the business operations while remaining hidden. First, the threat actor created various mail rules for moving and/or deleting emails with keywords associated with the threat actor’s access activities. Second, the malicious billing email was sent directly from the victim’s mailbox to various internal staff. Third, a malicious Azure enterprise application named “Newsletter Software SuperMailer” was created by the victim’s account for persisted access; this was particularly useful as the threat actor successfully performed re-logon to the compromised account even after the password was updated. The threat actor was only denied re-entry after MFA for the victim’s mailbox was enforced.

Through review of the available logs, we were able to observe through email trace that the attacker-controlled IP address delivered the same phishing emails to over three hundred (300) addresses of the victim organisation in alphabetical order. Meanwhile, we discovered through open-source information that similar emails had been sent to at least twenty (20) additional organisations globally. Combined with the fact that the threat actor was observed to only perform the first login two days after the password was inputted suggested they spent time to retrieve, study, and utilise their haul of phished credentials. These indicators and behaviour are more reflective of an opportunistic “spray and pray” campaign given the lack of urgency to quickly establish persistence. This is also evident in the end-to-end incident period lasting just under ten (10) days.

Case Study: Nigerian Cybercriminals Exploit Trusted Relationships with Hong Kong Branch Employee to Commit Cyber Fraud

PwC’s Dark Lab responded to a second BEC incident in 3Q 2022 involving a Chinese e-payment terminal solutions service provider with global operations. Similar to the case above, MFA was not enabled, and the threat actor was observed to host phishing domains imitating the Outlook login portal, enabling the threat actor to obtain initial access with valid credentials. This case left a lasting impression for three reasons.

First, the threat actor spent up to three (3) weeks familiarising themselves with ongoing operations by logging in remotely from multiple geolocations (including United States, Australia, Germany, and Nigeria) and modifying various mail rules and contact lists before executing their attack. The inbox rules hide emails specific to the transaction being targeted (e.g. emails from the legitimate parties, emails with transaction references numbers or bank accounts in the body). The emails are moved to a lesser viewed “RSS Feeds” folder with “Mark as Read” enabled in attempt to hide legitimate emails from the victim’s sight.

Second, the threat actor registered a new domain to impersonate the victim in Hong Kong to send emails to European counterparts . Notably, the threat actor embedded their phishing emails within existing conversations – an evasive tactic to exhibit legitimacy by using conversations with established trust. One of the seven (7) phishing emails contained a malicious link (secure[.]membra[.]co[.]uk) that appeared “clean” as it had not been reported as suspicious. However, through deeper inspection we observed the underlying IP address (45[.]153[.]240[.]153) was reported to be malicious, previously associated with other subdomains mimicking as the Microsoft O365 login page, likely used for global phishing campaigns.

Associated domains – likely past phishing campaigns
login-mso[.]cscsteelsusa[.]com
ogin-mso[.]cscsteelsusa[.]com
wwwoffice[.]cscsteelsusa[.]com
login[.]cscsteelsusa[.]com
Live Screenshot (as of 6/10/22) of login-mso[.]cscsteelsusa.com

Third, the threat actor practiced poor operational security including the inconsistent use of a virtual private network (VPN); as a result, they may have potentially disclosed that they operate out of Nigeria. While none of the Nigerian IP addresses were reported as malicious across various open-source security tools, Nigeria has been widely reported by security researchers to be a hotspot for cybercrime activity related to business email compromise attacks.[1] Overall, based on the investigation on open-source platforms leveraging the indicators of compromise from the incident, we conclude with high confidence that the incident was part of a larger-scale mass phishing campaign that opportunistic cybercriminals – likely out of Nigeria – conducted without the intention to target a specific sector or country, and with the motivation of transferring illicit funds to fraudulent bank accounts for financial gain.

Nigerian IP addresses
41[.]184[.]152[.]104
41[.]217[.]70[.]163
154[.]118[.]65[.]105

Phishing Kits bypass MFA

PwC’s Dark Lab observe the prevalent development of phishing kits (also known as adversary-in-the-middle (AiTM)), with over 10,000 organisations targeted by phishing kit attacks since September 2021. AiTMs provide a phishing toolkit as a service for attackers with low technical skills to execute a convincing phishing attack. AiTM phishing kits are easily accessible for attackers on the dark web with various open-source phishing kits available, including prominent providers Evilginx2[4], Modlishka[5], and Muarena[6].

AiTM phishing sites exercise a strong capability, as they enable attackers to deploy a proxy server between a target user and the website the user is attempting to visit – intercepting the connection by redirecting to the attacker’s phishing site. By targeting the authentication token, rather than raw credentials and/or MFA tokens, the phishing kit enables the attacker to steal a fully authenticated session from the victim, effectively bypassing MFA.[7]

As the trend of MFA enforcement by organisations and individuals continue to rise, it is expected that phishing campaigns will move away from traditional phishing methods towards the use of AiTM to overcome the barrier that MFA presents. As threat actors evolve to find innovative ways to circumvent controls and lower the barriers to entry, it becomes even more important for defenders to keep pace with these trends and understand how to prevent, detect, respond, and recover from such attacks.

Conclusion

As evidenced in both case studies, threat actors orchestrating large scale phishing campaigns pose a significant challenge for targeted victims. This can be observed in the actors’ willingness to wait up to three (3) to four (4) weeks before taking action, using the buffer period to build a strong understanding of the victim’s processes to effectively imitate their victim and evade suspicion.

In both cases, we observed oversights in the victim organisations’ security stance which ultimately resulted in their exposure to a BEC attack. In both cases, if multi-factor authentication (MFA) had been enabled, this could have prevented the threat actor from gaining access. Similarly, had the second victim organisation established rules to detect abnormal logins, such as flagging an IP address for suspicious activity if observed to have multiple geolocations over the span of a week, the organisation could have detected the suspicious activity at an earlier stage and prevented further action.

To effectively protect against phishing and BEC attacks, it is vital that organisations enforce a layered defense strategy – combining robust preventative measures with intuitive detective protocols.

Recommendations

While phishing legitimate brands and business email compromises will remain a problem, companies can take action to mitigate and prevent the threat they pose.

  • Enhance security controls by establishing procedures in defining “significant” financial transactions and their respective handling procedures, for example automatic bank notifications for outbound transaction verifications and mandatory out-of-band verifications of bank account changes.
  • Develop and exercise a layered defense strategy, incorporating well-defined preventative and detective measures.
  • Organisations should review their Microsoft 365 configuration and update their email security solutions and network devices (including external firewall, web proxies).
  • Implement conditional access rules configuring with Geo-location/IP address restriction to reduce the risk of unauthorised overseas access to O365. For example, a regular review of authentication records for key financial staff members (i.e. Chief Financial Officer, Financial Controller, etc.)
  • Organisations should establish rules to restrict unauthorised devices from accessing company resources. For example, enforcing limitations on what devices can access company resources and creating onboarding procedures to enrol authorised devices, such as an employee’s personal mobile phone, before they are able to access company resources.
  • Enforce strong multi-factor authentication (MFA), such as number matching, for all users.
  • To protect against AiTM attacks, it is advised that organisation implement a layered defense strategy that incorporates MFA in conjunction with various preventative and defensive measures. This includes implementing MFA that supports Fast ID Online (FIDO) v2.0 and certificate-based authentication, enabling conditional access policies, and continuous monitoring for abnormal activities.
  • Implement periodic checking process to detect suspicious behaviour such as abnormal logins, mailbox rules, email forwarding rules, and application consent activities.
  • Organisations should conduct young domains monitoring and alert against potentially suspicious domains for further action (e.g., domain takedown). This task is typically conducted by our Security Operations Centre for subscription clients, and supported by our Cyber Threat Operations function which includes the Threat Intelligence and Incident Response pillars.
  • Conduct regular awareness training to educate the workforce on how to detect suspicious activity, highlighting new TTPs and clear warning signs, and provide clear instructions on the steps to take if they believe they have been targeted by a phishing email. Awareness training can also be completed in the form of phishing simulations to test employees’ susceptibility to phishing emails and fraud (i.e. simulate a sudden change of bank account information to determine if the relevant team detects the unusual behaviour and responds accordingly).
  • Users should remain wary of the legitimacy of webpages and their branding, and access websites via the global webpage as opposed to the URL shortened link if in doubt. BEC-impacted companies should issue circulars and alerts as necessary when impersonation attempts are detected .
  • We further advise organisations to establish a O365 mailbox rule to detect inbound/outbound traffic from the malicious IP listed in our Indicators of Compromise (IoC) section.

MITRE ATT&CK TTPs Leveraged

We include the observed MITRE ATT&CK tactics and techniques elaborated from the incident.

  • Acquire Infrastructure: Domains – T1583.001
  • Virtual Private Server – T1583.003
  • Botnet – T1583.005
  • Compromise Email Accounts – T1586.002
  • Phishing – T1566
  • Spear Phishing Link – T1566.001
  • Trusted Relationship – T1199
  • Email Hiding Rules – T1564.008
  • SharePoint – T1213.002
  • Remote Email Collection – T1114.002

Indicators of Compromise (IoCs)

IndicatorType
www[.]yinqsite[.]comKnown bad domains
login-microsoftonnex-mso[.]yinqsite[.]comKnown bad domains
yinqsite[.]comKnown bad domains
ogin-mso[.]wonjiinco[.]coKnown bad domains
glprop-okta-2f0bc4a0[.]wonjiinco[.]comKnown bad domains
stscn-lenovo-c9b8a5aa[.]wonjiinco[.]comKnown bad domains
msaauth-msasafety-95cce817[.]wonjiinco[.]comKnown bad domains
sts-glb-nokia-a6db40b3[.]wonjiinco[.]comKnown bad domains
sts-posteitaliane-694c6373[.]wonjiinco[.]comKnown bad domains
gas-mcd-37816100[.]wonjiinco[.]comKnown bad domains
login-mso[.]wonjiinco[.]comKnown bad domains
wonjiinco[.]comKnown bad domains
ogin-mso[.]cscsteelsusa[.]comKnown bad domains
wwwoffice[.]cscsteelsusa[.]comKnown bad domains
login[.]cscsteelsusa[.]comKnown bad domains
sts01-nestle-382a43f3[.]cscsteelsusa[.]comKnown bad domains
stscn-lenovo-a3ae4e78[.]cscsteelsusa[.]comKnown bad domains
fs-ncoc-a241b101[.]cscsteelsusa[.]comKnown bad domains
login-mso[.]cscsteelsusa[.]comKnown bad domains
www[.]cscsteelsusa[.]comKnown bad domains
kolroff[.]comKnown bad domains
xsbrane[.]comKnown bad domains
cscsteelsusa[.]comKnown bad domains
belasting-betalen[.]financeKnown bad domains
domain macopas[.]comKnown bad domains
95[.]216[.]126[.]229IP address
15.204.25.141IP address
Newsletter Software SuperMailerEnterprise application created by threat actor
45[.]153[.]240[.]153IP address
185[.]54[.]228[.]88IP address
185[.]202[.]175[.]6IP address
103.231[.]89[.]230IP address
41[.]184[.]152[.]104IP address
155[.]94[.]141[.]30IP address

Further information

Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.