Cyberattacks persistently target both systems and individuals. Among these, compromising user credentials stands out as a prevalent vulnerability. With the proliferation of cloud-based systems and the extensive storage of organizational data in the cloud, attackers find compromised credentials increasingly profitable. The confluence of the simplicity of credential compromise and the potential gains thereof has fueled a sharp rise in corporate credential compromises. This article will delve into a particularly aggressive form of credential compromise known as Adversary-in-the-Middle (AiTM).
Innocent clicks, the user confused, Credentials stolen, their trust abused.
Why has compromising credentials become so easy?
Adversary-in-the-Middle (AiTM) attacks present a variation of the conventional Man-in-the-Middle (MiTM) attack, with a distinct emphasis on compromising credentials. In this attack, the Threat Actor inserts themselves into a communication channel between two parties, whether it's two users, two devices, or a user and an application or server. Subsequently, the attacker intercepts data exchanged between the sender and recipient, thereby compromising identities of users who unwittingly used the malicious proxied connection.
In this scenario, a user on the left side receives a phishing email, becoming the victim. Upon clicking the phishing email, the user is directed to the attacker's fraudulent website, initiating step 1. At this stage, the user is prompted to input their credentials. Subsequently, in step 2, the Man-in-the-Middle phishing site forwards the captured credentials to the authentic web service Identity Provider (IDP), such as Microsoft Azure.
Depending on access policies, the user might also be prompted to enter Multi-Factor Authentication (MFA) information (Note: The user may not be prompted for MFA, and it is not necessary for credentials compromise). If applicable to MFA information also captured and relayed to the cloud service, depicted in steps 3, 4, 5, and 6.
Following this, in step 7, the cloud service returns a session cookie. The Man-in-the-Middle server seizes this session cookie and redirects the user to another site. Consequently, the attacker gains possession of the user's credentials, session cookie, and potentially MFA claim details. The session cookie serves as evidence for the web server that the user has been authenticated and is currently engaged in a session on the website. Since session cookies typically remain valid for an extended period of time, the attacker can leverage the user's valid session cookie by inserting it into their browser to bypass the authentication process, even if the target's MFA is enabled.
Automating the AiTM function is prevalent, often utilizing open-source phishing toolkits and various online resources. Among the most widespread platforms is Evilginx, named spin in reference to the well-known open-source web server package, Nginx. The Evilginx framework employs an Nginx HTTP server to proxy authentic login pages, enabling the capture of credentials and session cookies. https://github.com/kgretzky/evilginx2?tab=readme-ov-file
What are the Protection opportunities to stop these types of attacks?
To prevent phishing attacks, standard tradition prevention employs three main strategies: first, blocking phishing emails from reaching the user altogether. Secondly, if a user does receive a phishing email, training them not to click on any links within it and also not to enter their credentials. Lastly, if a user inadvertently clicks on a phishing email, preventing their system from connecting to the AiTM proxy.
Preventing Phishing Emails and stopping users from clicking them
This is primarily achieved through email security measures like SPF, DKIM, and DMARC, alongside the utilization of email security gateways or services provided by companies such as Proofpoint, Cisco, Microsoft, Mimecast, and others. Additionally, user training plays a crucial role in empowering individuals to recognize phishing emails and refrain from entering their credentials into suspicious websites.
Blocking Connection to Man-in-The-Middle Sites
Implementing mechanisms to prevent users from connecting to the Man-in-The-Middle site, even if they inadvertently click on the phishing link, constitutes another key defense strategy. This next tier of defense involves preventing the user's device from establishing a connection to the AiTM site upon clicking the phishing link. Such attempts can trigger alerts within Endpoint Detection and Response (EDR) systems, indicating a connection to an adversary-in-the-middle phishing site. These preventive measures rely on Cyber Threat Intelligence (CTI) integrated into EDR platforms, which maintain a roster of recognized AiTM proxies.
How have Threat Actors circumvented these traditional Preventions?
Attackers have devised ingenious methods to circumvent these fundamental security measures. One prominent tactic involves exploiting legitimate services to send emails, leveraging the redirect functionalities within these services. This allows attackers to manipulate users into clicking on links within seemingly authentic emails, redirecting them to the malicious Man-in-The-Middle sites. An online project is dedicated to monitoring the malicious utilization of trusted websites as a conduit for delivering phishing emails to unsuspecting victims.
Cyber threat actors are keenly aware that cybersecurity vendors gather Cyber Threat Intelligence (CTI) data on their established infrastructure. Consequently, attackers often exploit legitimate infrastructure, adapting it to host their Man-in-The-Middle (MitM) proxies. This is humorously illustrated as GPiTM ('Grandmas-PC-in-The-Middle'). Consequently, it's common to observe continuous chains in these attacks: once an organization's identity is compromised, phishing emails are then sent from that legitimate organization to compromise others.
Once the credentials are compromised what do the attackers typically do?
After compromising credentials, attackers typically engage in specific activities, the nature and timing of which can vary. Understanding these activities is crucial for identifying detection opportunities. Initially, attackers aim to gather additional information to advance their exploitation efforts. This involves reading through emails and attachments to discern the compromised victim's internal and external business relationships.
These relationships become targets for potential Business Email Compromise (BEC) for phishing attempts aimed at other company users or external organizations. For instance, attackers may insert themselves into email threads concerning invoice payments, informing the business partners that the victim's company has not received payment and provide altered bank routing numbers to complete payment. In certain instances, attackers may go as far as registering a phone number similar to that of the compromised user, complete with the same 1st 6 digits (in USA area code (NPA) and area code sub-region (NXX)). Consequently, if someone attempts to contact the compromised user via phone based on the number in the phishing email, their call will be routed to the attacker instead.
The attacker will also commonly pillage through data the user has access to such as corporate Sharepoint sites. A prevalent technique among Threat Actors is to scour SharePoint sites for files that store passwords, such as Excel spreadsheets containing password lists.
What are detection opportunities for user credential compromise?
Upon compromising an identity, attackers typically proceed to log into the victim's online corporate systems, but from disparate locations. Essentially, they access the victim's accounts from locations distinct from those typically used by the legitimate user of the account. These varied locations might also be where the attackers have established specialized hacking tools, such as Kali Linux, to facilitate their illicit activities. Attackers may also attempt to anonymize their remote access by utilizing anonymizer services such as TOR or VPNs like WireGuard. Cloud platforms such as Azure offer safeguards against alterations in the geographical locations of user remote logons. However, considering that business professionals often travel, a delicate balance must be struck between restricting all user logons from new geographical locations and permitting remote access for traveling workers.
Other actions attackers often take
Registering their own MFA
Azure and similar online systems employ Conditional Access Policies to manage such scenarios securely. These policies outline how the system should respond in situations like logging in from an unfamiliar geographical location. One common conditional access policy involves requiring users to utilize Multi-Factor Authentication (MFA) to verify their identity if attempting to log in from an unfamiliar geographical location.
Due to the widespread implementation of Multi-Factor Authentication (MFA) for numerous logons, attackers frequently incorporate their own MFA method into compromised accounts (Link to setup MFA on accounts mysignins.microsoft.com/securityinfo ). Threat Actors commonly utilize SMS-based MFA added to compromised accounts, leveraging the accessibility of non-attributable cell phones, such as burner phones. The inclusion of additional MFA controlled by the attacker in the victim's account enables them to access the account after session cookies expire and from various locations other than the real user's typical logon location. This circumvents any conditional access policies established by the organization that mandate MFA, thereby granting the attacker's unhindered access. To add insult to injury, attackers often use very nice mobile devices. Not only are they compromising your accounts, but they are also phone shaming you while doing it!
Abusing Online Apps
Given the proliferation of online applications capable of accessing data and executing tasks on behalf of users, attackers commonly exploit these apps for nefarious purposes. Many of these apps are legitimate, making them undetectable as malicious by standard tenant access policies. Hence, it becomes imperative for organizations to maintain a comprehensive list of approved apps, detailing their purposes and authorized users, to effectively manage and mitigate potential risks. An example of this activity includes the use of apps capable of downloading the contents of user email boxes offline, observed being utilized by Threat Actors. Some apps observed to be abused by attackers include "perfectdata," https://www.perfectdatasoftware.com/ and eM Client ( https://cybercorner.tech/malicious-usage-of-em-client-in-business-email-compromise/ ) Perfectdata software is designed for offline pulling of user email boxes for forensic analysis, has been identified in these instances. Darktrace has an excellent example of how this app was abused by Threat Actors here: https://darktrace.com/blog/how-abuse-of-perfectdata-software-may-create-a-perfect-storm-an-emerging-trend-in-account-takeovers
Email box rule manipulation
Attackers frequently establish email inbox rules to clandestinely send emails to other targets without arousing the victim's suspicion. For instance, a rule may be set up to automatically move all incoming emails from the inbox to the deleted or RSS folders, effectively concealing the email conversation from the victim's view, while granting full control to the attacker. These are most commonly server-side email box rules created from the Outlook web app. Ass server-side rules they still work even when the victims Outlook client is offline.
Additionally, attackers commonly devise these email inbox rules with inconspicuous names such as "-" or "." to evade detection by the target, hoping they will remain unnoticed amidst the clutter of inbox management.
What are the detection signals for this type of activity?
There are typically multiple indicators that can signal a compromised user account. One of the initial signs may be abnormal geolocation or instances of impossible travel as discussed earlier. This occurs when the legitimate user typically logs into the system from their home or office location, yet the attacker logs in from a different geographical location.
However, it's important to note that these alerts often generate false positives, primarily due to users traveling or utilizing different devices with varying geolocation IP ranges. For instance, a user may trigger abnormal geolocation alerts if they use a mobile device while on a train, causing the device to switch between IPs from different regions while the train is moving. Similarly, a user logging into their laptop from their home ISP and simultaneously accessing a wireless device connected to a different geo IP space provided by their wireless carrier could also trigger impossible travel alerts. In some cases, users are using an app that they typically don't log out from in one location. They then shut down their computer and travel to a different location. When they connect at the new location, the app they were using reconnects with the previously logged-in session ID for that app.
What are some indicators can help differentiate between anomalous logins, impossible travel false positives, and genuine attacks?
IP Address Reputation: Evaluate the reputation of the IP addresses associated with the logins. However, note that logins from non-malicious IP addresses do not guarantee safety, as attackers may use compromised yet legitimate systems.
Multiple Remote IP Addresses: Impossible travel scenarios usually involve two remote IP addresses, not multiple ones. Logins from more than two remote IP addresses should raise suspicion.
Geolocation of Remote Logon IP: Check if the remote login IP is located in a region where the user has no legitimate business, such as Russia.
User Agent String: Analyze the user agent string for the logins. Any deviation from the standard user agent string previously used by the user is a potential red flag.
Timing of Logins: Consider the timing of the logins. While some users may work odd hours, attackers often choose off-hours to minimize detection, especially if they are based in foreign countries.
Activity Patterns: Monitor the activity associated with the logins. Unusual actions like accessing SharePoint sites for passwords or registering new apps warrant investigation.
New MFA Method Registration: Check if a new Multi-Factor Authentication (MFA) method has been recently registered, as this could indicate attacker activity.
As Microsoft always says for many of these alerts, 'verify the activity with the real user'. Is he/she traveling?
Another significant detection method involves identifying suspicious email inbox rules. As previously discussed, manipulation of email inbox rules is a common tactic in email compromises, making the detection of such rules crucial in identifying potential identity compromises.
Responding to user identity compromise incidents
When investigating activity, it's crucial to ascertain three key pieces of information:
1. Origin: Where did the attack activity originate from?
2. Termination Point: Where did it cease?
3. Actions Taken in Between: What occurred during the intervening period?
To halt the spread of the compromise, immediate actions include:
Locking or resetting the user's account and terminating any active sessions.
Revoking open sessions to prevent the attacker from continue to exploiting them even if the users' credentials are changed.
Notifying the user of the incident and providing instructions for resetting their password.
Removing any bogus Multi-Factor Authentication (MFA) methods.
Deleting email inbox forwarding rules and uninstalling any malicious apps.
When dealing with stolen credentials and tokens, it's essential to understand the implications of a basic password reset. Although resetting the victim's credentials is a common response to lock the attacker out, it's important to note that many compromised sessions from web-based apps remain active even after a password reset. Therefore, alongside resetting the compromised user's credentials, it's imperative to revoke any session tokens associated with their account during the period of compromise. This action effectively bars the attacker from accessing any open sessions or apps they may have loaded onto their controlled devices using the victim's identity.
Microsoft has a set of recommendations for user account compromises here: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account?view=o365-worldwide
Additional defensive measures encompass:
Blocking the malicious IP address from accessing the organization's network.
Quarantining the device used by the compromised user.
Where did the attack activity originate from?
It is also crucial to trace the origin of the attack by identifying the initial vector, such as a phishing email. Determine who else within the organization received these phishing emails and whether anyone clicked on them or entered their credentials into the AiTM system. Finding and remedying (e.g., deleting them) these emails from the system is imperative. The way the victim was tricked can also serve as intelligence for user cyber security awareness training and additional advanced preventions.
Furthermore, it's essential to search within your tenant for any other Indicators of Compromise used by the attacker, such as IPs, user agent strings, apps, and MFA methods utilized by the Threat Actor.
Determining the attackers termination point and actions taken between
It's a frequent tactic for attackers to leverage other internal users or business connections using stolen user credentials. It's crucial to thoroughly examine all emails alongside the legitimate user to differentiate between those they sent and those sent by the Threat Actor. Your organization might inadvertently serve as the initial vector for compromising another organization or enabling Business Email Compromise (BEC). Additionally, assess which files were accessed or viewed during the compromise to ascertain if the information could be exploited further. This includes scrutinizing password files or documents containing sensitive business data or Personally Identifiable Information (PII).
Circling Back to Preventions
There are additional prevention measures for these types of attacks, but implementing them comes with administrative costs. As a result, many organizations either do not fully implement them or do not implement them at all. These additional prevention measures include:
Registering user devices
Using phishing-resistant MFA
Microsoft Security Service Edge (SSE)
Registering User Devices
When you establish requirements for device compliance, it also involves identifying the device. When you register or join a device in Entra ID, it will receive a certificate for identification purposes. If any type of Man-in-the-Middle device inserts itself in a TLS connection, it has to replace the end user's device certificate with its own certificate. If device enrollment is completed and conditional access policies are enforced, Microsoft will reject the proxied connection because the certificate will not match.
Using phishing resistant MFA
Surprisingly, the basic Microsoft Authenticator app One Time Password (OTP) is not phishing resistant. When you use the Microsoft Authenticator app, it generates a secure-value on your phone to unlock your account, which is protected by your phone's PIN or biometric lock. This secure-value is then used to verify your identity when signing in.
Phishing-resistant authentication methods cryptographically link the authentication session to the machine using public and private keys where the end device can prove it has the private key but never sends it. A common key based Phishing-resistant authentication method is using Fast Identity Online (FIDO) tokens like yubikey. Microsoft has recently supported passkey authentication in the Microsoft Authenticator app. The passkey stays on the user's client device and is not transmitted. The client locally to generates a unique cryptographic signature. The crypto signature proves to the server that it has been created with the client passkey.
Microsoft Security Service Edge (SSE)
Microsoft has a well-known security feature where organizations can configure globally secure access compliance locations. This feature basically identifies the IP addresses of office locations and says, "Its normal to see users logging into cloud resources from these locations." This works great for office users but becomes more difficult in organizations that have a lot of work from home and traveling users. Microsoft Security Service Edge (SSE) allows for a secure communication channel from the client through Microsoft's Global network to the desired online service.
Despite the added burdens of these extra security measures organizations should strive to implement them because of their effectiveness in stopping attacks like these.
Kommentarer