Security operations · 4 MIN READ · ANDREW BENTLE · NOV 9, 2022 · TAGS: MDR
TL;DR:
- Credential phishing is an established attack mode, but multi-factor authentication (MFA) made it much harder on hackers.
- A new tactic–called “attacker-in-the-middle”–can be effective at end-running MFA defenses.
- This case examines a recent AitM attack on one of our customers and provides useful advice on how to detect it in your own environment.
Credential phishing is nothing new–fooling users into giving away their logins and passwords has been hackers’ bread and butter forever. But until recently the effects of credential phishing could be mitigated by using multi-factor authentication. The attacker might get a password, but the second factor is a lot more difficult.
Also not new: attackers finding techniques to bypass security measures. One popular way around MFA is known as attacker-in-the-middle (AitM), where the user is tricked into accepting a bogus MFA prompt.
What happened?
AitM techniques look identical to regular credential phishing at first. Typically, an email directs the user to a fake login page, which steals credentials when the user attempts to sign in. With normal credential phishing, this fake login page has served its purpose–it stores the credentials and the attacker will attempt to use them at a later time. AitM phishing does something different, though; it automatically proxies credentials to the real login page, and if the account requires MFA users get prompted. When they complete the MFA, the web page completes the login session and steals the session cookie. As long as the cookie is active, the attacker now has a session under the victim’s account.
Our SOC recently saw this technique used to bypass MFA and detection in a customer’s environment. The attackers harvested a user’s credentials and login session into their organization’s Microsoft 365 portal using AitM techniques. The attacker evaded detection for 24 days until a suspicious Outlook rule was made in the compromised user’s inbox.
Our analysts identified the source IP as a hosting provider and noticed that no login events were seen from the IP address. They followed the related session ID to its earliest date and found that the session originated from another IP address, 137[.]220[.]38[.]57, nearly a month before. This address is related to a hosting provider (Vultr Holdings) and was anomalous for the user account.
But something stranger was going on: not only was MFA satisfied from this login, but it was also supported by the Active Directory (AD) agent on the user’s host. This didn’t make sense–how could a login from a random hosting provider IP address use the AD agent tied to the user’s managed host?
This is something we might see when a user logs in while using a VPN or proxy, but our analyst’s OSINT research and Expel’s automatic IP enrichment didn’t connect this address with a VPN provider, so we kept digging.
We checked logs from their Palo Alto firewall and DNS requests from the host in Darktrace and found DNS requests to rnechcollc[.]com with DNS A records pointing to 137[.]220[.]38[.]57, the same IP the first login was from. The rnechcollc[.]com site hosted an AitM credential harvesting page that proxied the credentials (and even the AD agent authentication from the user’s on-premises host through the Vultr Holdings infrastructure and onto the organization’s Microsoft 365 portal). The page then recorded the session cookie and the attacker continued the active session from a VPN provider for the next 24 days.
Confirming AitM in your environment
AitM can be tricky to confirm, especially without network logs. But there are a few ways to investigate if a compromise originated from an AITM credential harvesting page.
Investigating using only cloud logs: this is the worst-case scenario. All you have are the logs from the cloud providers, be it Okta, Microsoft 365, or any number of other platforms, and the goal will be to determine the initial login IP address by following the session ID back to its earliest point. The initial login will likely, but not necessarily, be from an IP address associated with a hosting provider.
Check passive DNS entries associated with the IP address (VirusTotal and PassiveTotal are good tools for this). Check the reputation on the recent DNS entries related to the IP address through OSINT–it may be a known indicator of AitM, as was the case with the rnechcollc[.]com domain.
Investigating using network and cloud logs: like the above method, you’ll need to identify the initial login IP address through cloud logs. Follow the session ID back to the initial login and take note of the IP address. Check your firewall logs for URLs associated with the IP address. Confirming connections from within your environment to phishing domains associated with the initial login IP address is a strong indicator of AitM methodology.
Investigating using EDR and cloud logs: again, identify the initial login IP address through the cloud logs. Follow the session ID back to the initial login and take note of the IP address for the initial login. Check EDR logs for network connections to the IP address. Some EDRs, like CrowdStrike and Defender for Endpoint, will record domain names related to IP connections. Confirming connections from within your environment to phishing domains associated with the initial login IP address is a strong indicator of AitM methodology.
Things you can do to keep your org safe
Don’t discount the effectiveness of MFA– still one of the single most effective security tools that can be implemented in your organization. While AitM can bypass MFA, it represents a small portion of the credential phishing we’ve seen in the wild to date.
Consider implementing policies to shorten the time that session tokens can remain active; if attackers lose their sessions, they’ll need to re-phish the user to get it back, or at least get them to accept another MFA prompt.
Implement conditional access policies to prevent logins from unwanted countries, noncompliant devices, or untrusted IP spaces.
Additionally, services like our Managed Phishing can identify malicious credential harvesting emails and inform your team of campaigns in your organization and help block attacks before they succeed.
