WHITE PAPER
Identity Has Become the Prime Target
of Threat Actors
Footnotes
The State of the Identity Attack Surface Embrace proactive security with Zero Trust - Microsoft
Business Email Compromise and Tips to prevent it - Microsoft.
The sample includes about 100 AIG insureds from 20 countries and 18 industries over a two-year period that suffered a ransomware incident where AIG conducted a post-incident dialogue.
Implementing Least-Privilege Administrative Models - Microsoft
Multi-Factor Authentication Request Generation, Technique T1621 - Enterprise | MITRE ATT&CK®
SIM Swap Scams: How to Protect Yourself | Consumer Advice (ftc.gov)
Overcome the MFA Challenge With an Approach That Provides Full MFA Coverage
To overcome the MFA challenge presented in this paper, the client should consider an approach that aims to solve the challenges that a traditional MFA implementation fails to address. The approach should manage and integrate all cloud and on-premise identity providers (IdP) in the environment. Solving these issues for cloud alone leaves gaps that can be exploited for on-premise environments. The concept is to ensure that every authentication and access request is analyzed prior to granting or denying user access. Presuming some requests can’t or shouldn’t be analyzed leaves potential gaps. These gaps have led to events described in this paper. It is important to state that analyzing access requests and triggering MFA must be protocol agnostic, including those originating from legacy authentication protocols, command line, file share, and any other on-prem resources to guarantee full MFA coverage. This means that MFA can be extended to all resources that are traditionally beyond the scope of this type of protection.
1. Risk Analysis of Your Environment
Perform a risk analysis based on your resources and environment to assess the potential gaps and misconfigurations that could increase the risk of compromising your entire network.
2. Prioritize the Users That Need Protection
Compile a list of users – including service accounts – whose protection is a must-have. This should include all admin user at a minimum, but also any other users that have access to critical resources.
3. Choose an MFA Solution With Full Coverage
Don’t compromise on your MFA’s protection coverage. Ensure it applies to all resources and access methods with special emphasis on the unique needs of your environment.
4. Apply MFA Protection In a Non-Negotiable Manner
Configure MFA policies for all users who need it and ensure they understand it’s a nonnegotiable deal. Don’t exclude anyone from this protection either fully or partially. Remember that partial MFA protection is as good as zero protection.
5. Ensure MFA Implementation Is Phishing Resistant
Identify any applications that may use SMS or call back based MFA, with added emphasis on legacy applications, and ensure those methods are updated as soon as possible. For additional awareness and assistance, we recommend following the guidance provided by the Federal Trade Commission9 and Cybersecurity and Infrastructure Security Agency10.
Key Takeaways
Overcome the MFA Challenge With an Approach That Provides Full MFA Coverage
To overcome the MFA challenge presented in this paper, the client should consider an approach that aims to solve the challenges that a traditional MFA implementation fails to address. The approach should manage and integrate all cloud and on-premise identity providers (IdP) in the environment. Solving these issues for cloud alone leaves gaps that can be exploited for on-premise environments. The concept is to ensure that every authentication and access request is analyzed prior to granting or denying user access. Presuming some requests can’t or shouldn’t be analyzed leaves potential gaps. These gaps have led to events described in this paper. It is important to state that analyzing access requests and triggering MFA must be protocol agnostic, including those originating from legacy authentication protocols, command line, file share, and any other on-prem resources to guarantee full MFA coverage. This means that MFA can be extended to all resources that are traditionally beyond the scope of this type of protection
Overcome the MFA Challenge With an Approach That Provides Full MFA Coverage
To overcome the MFA challenge presented in this paper, the client should consider an approach that aims to solve the challenges that a traditional MFA implementation fails to address. The approach should manage and integrate all cloud and on-premise identity providers (IdP) in the environment. Solving these issues for cloud alone leaves gaps that can be exploited for on-premise environments. The concept is to ensure that every authentication and access request is analyzed prior to granting or denying user access. Presuming some requests can’t or shouldn’t be analyzed leaves potential gaps. These gaps have led to events described in this paper. It is important to state that analyzing access requests and triggering MFA must be protocol agnostic, including those originating from legacy authentication protocols, command line, file share, and any other on-prem resources to guarantee full MFA coverage. This means that MFA can be extended to all resources that are traditionally beyond the scope of this type of protection.
The ransomware landscape has seen a major escalation in the frequency and scope of attacks
in 20231. As cybercriminals have become more sophisticated, they are exploiting most organizations' critical gaps against identity threats – with over 83% already having experienced a breach involving compromised credentials2. Identity is also one of the key pillars of the zero-trust strategy,3 making it critical for organizations to review their Identity and Access Management strategy. Multi-Factor Authentication (MFA) has long been advocated as a robust measure to bolster an organization’s security posture, but misconfigurations and gaps in MFA coverage have proven that a more holistic and unified approach is needed to stem the tide of this dangerous trend in cybercrime.
What Is the Security Value of MFA?
MFA is an authentication mechanism where a user must verify their identity by presenting two or more pieces of evidence to gain access to a website, account, or application. This evidence includes 1) something the user knows (password, PIN, codes, etc.), 2) something the user possesses (keys, smart phones, smart cards, token devices, etc.), or 3) something the user is (facial recognition, retina scans, fingerprint scans, etc.). The authentication mechanism only grants access if each of the authentication factors are successfully verified. In this way, if user credentials (such as a username and password) have been compromised, a cybercriminal cannot automatically gain access to the account. MFA adds additional layers of security, making unauthorized access more difficult.
Now consider a typical ransomware scenario, which usually consists of three phases: 1) initial access and gaining a foothold within the target organization; 2) privilege escalation and lateral movement; and 3) data exfiltration and/or ransomware deployment and execution. Without MFA on external connections an attacker can leverage compromised credentials to infiltrate the internal network through VPN or any other remote connection. Within the internal network, an attacker could freely move laterally inside the domain and infect any domain-joined system with the ransomware payload. In this sense, backups should not be joined in the domain so that the recovery process is not also compromised.
Properly configured MFA is a proven security mechanism that can prevent malicious access with compromised credentials in real time.
Why Is MFA Crucial for Administrative Users?
Administrative users or privileged users can access all critical resources within the network environment.
From an attacker’s perspective, compromising a privileged user account is the single best strategy to deploy and execute the ransomware payload on every resource that the privileged user has access to. This makes protection of privileged users with MFA a top priority.
What Are the Challenges of Traditional MFA?
Technology Gap of Legacy Resources and Protocols
MFA as a technology has been around for a relatively long time, but it is not as widely used as you would expect. For applications or systems born in the cloud, MFA is natively integrated into modern web and SaaS app authentication protocols. This supports a reduction in BEC4 attacks using these platforms. However, it is important to note that this protection does not extend to the organization’s on-premises servers, workstations, databases, and apps. For many organizations, a significant portion of their critical infrastructure and access methods still reside in the on-premises environment.
Through the process of reviewing cyber insurance applications from potential policyholders,
AIG has learned that applicants have difficulty meeting the MFA requirements due to these challenges:
In versions prior to Windows 10, MFA does not come as a pre-configured, ready-to-deploy option as part of standard on-premises Microsoft Active Directory deployment.
Access to critical resources is done via native authentication protocols such as Windows New Technology LAN Manager (NTLM) or Kerberos. If compromised, the TA can take over the domain. Also, command-line access to workstations and servers, IT and networking infrastructure, old applications, and many more that don’t support MFA technology.
MFA Coverage Gaps Due To Installation Method
Traditional MFA installation methods rely on either installing an MFA agent on resources that need protection or placing a proxy in front of their network segment. Both methods introduce inherent coverage gaps.
Furthermore, many machines within the enterprise environment cannot sustain an MFA agent due to operability issues, such as service accounts. Service accounts in Active Directory (AD) are user accounts that are not owned or used by people and instead are dedicated to a specific application or system. These accounts are frequently configured to run a service on servers and/or workstations in an environment. Service accounts are typically granted privileged rights in the environment and are often added to highly privileged groups such as the Domain Admins group. This is frequently due to the recommended and supported installation model pushed by software vendors to avoid permission issues or functionality mishaps during installation and operation. In order for these accounts to work, the service account name and password must be stored locally on the system. Service accounts have a password that is set when created and rarely changed. If an attacker can guess or otherwise discover the password, including compromising a system where the service account is used, they would be able to extract and employ those service account credentials to exploit the environment.
Microsoft’s best practice guidance is that Domain Admins should not be used outside build/fix, and instead proper delegation and “least privilege” should be enforced, but our study shows this isn’t happening in practice – and ransomware actors are taking advantage.
In many of the over-privileged service accounts analyzed by AIG in cyber insurance applications submitted by potential policyholders, it was discovered that the elevated privileges were not necessary for the operation of the service account on servers or workstations. Service accounts6 rarely require the highest level of privilege to perform the function on a server or workstation. The risk of being compromised was very high due to the nature of those service accounts.
MFA Bypass Due To Telephony-Based Authentication Methods
Over the past year there has been an increase in MFA bypass as a defense evasion technique. As such, it is extremely important to give consideration during implementation and the approved methods allowed for MFA authentication. MFA Interception7 is one of the more common MFA bypass techniques used for Credential Access. Typically, MFA Interception is accomplished via one of the following methods: SIM Swapping against SMS-based MFA implementations, and eSIM number porting used against call back-based MFA implementations. Other methods of MFA bypass include social engineering to trick a user into providing the MFA code, the use of fake SSO sites to capture the code in real time, and the use of MFA Authentication Request Generation8 designed to cause MFA fatigue.
More than
66%
of organizations compromised by a ransomware attack saw ransomware deployment linked to the compromise of a highly privileged account on their Active Directory environment.
63%
of organizations
that stated they used MFA for protecting privileged access were still impacted by a ransomware event linked to coverage gaps in MFA configuration/installation method.5
AIG Study #1
A regular employee’s credentials used to log into the organization’s corporate resources were compromised. The remote access used by the employee was not configured with MFA. As such, the TA (Threat Actor) was able to connect to a Citrix gateway, used the valid employee’s credentials and compromised the organization’s external perimeter. From that point, the TA moved laterally across the network using Remote Desktop Protocol (RDP) connections. Then, they elevated privileges by compromising a privileged service account used for a backup service. Without risk mitigation controls in place, the TA used Group Policy (GPO) modifications to run LockBit ransomware malware and encrypted data across the virtual environment. (For more information on privileged Service Account compromise, refer to the topic “MFA Coverage Gaps Due to Installation Method” below.)
AIG Study #4:
AIG has conducted numerous incident dialogs where the use of SMS based MFA was identified as he root cause allowing the TA to gain initial access via SIM Swapping. Recently, AIG identified a case where MFA Interception occurred via eSIM number porting such that the MFA code provided during the call back was given directly to the TA.
AIG Study #3:
AIG has conducted numerous incident dialogs where an over-privileged service account was identified as the root cause behind a TA acquiring highly privileged credentials, thereby allowing them to elevate privileges and compromise all domain-joined systems. In many cases, applicants were unaware of the risk; in other cases the risk was ignored for fear of breaking the service by de-privileging the service account.
In one case, a service account was inadvertently added to the VPN profile, allowing the TA to use that account for remote access without MFA because MFA is virtually impossible to enforce on service accounts.
AIG Study #2:
We observed several organizations authorizing direct remote privileged user access through a remote access solution such as VPN. Even if MFA-enabled, organizations should authorize unprivileged remote access only if followed by a second step of privilege escalation from within the network. The privilege-escalation MFA should be a dedicated/separate security control.
WHITE PAPER
Identity Has Become the Prime Target
of Threat Actors
Footnotes
The State of the Identity Attack Surface Embrace proactive security with Zero Trust - Microsoft
Business Email Compromise and Tips to prevent it - Microsoft.
The sample includes about 100 AIG insureds from 20 countries and 18 industries over a two-year period that suffered a ransomware incident where AIG conducted a post-incident dialogue.
Implementing Least-Privilege Administrative Models - Microsoft
Multi-Factor Authentication Request Generation, Technique T1621 - Enterprise | MITRE ATT&CK®
SIM Swap Scams: How to Protect Yourself | Consumer Advice (ftc.gov)
Key Takeaways
1. Risk Analysis of Your Environment
Perform a risk analysis based on your resources and environment to assess the potential gaps and misconfigurations that could increase the risk of compromising your entire network.
2. Prioritize the Users That Need Protection
Compile a list of users – including service accounts – whose protection is a must-have. This should include all admin user at a minimum, but also any other users that have access to critical resources.
3. Choose an MFA Solution With Full Coverage
Don’t compromise on your MFA’s protection coverage. Ensure it applies to all resources and access methods with special emphasis on the unique needs of your environment.
4. Apply MFA Protection In a Non-Negotiable Manner
Configure MFA policies for all users who need it and ensure they understand it’s a nonnegotiable deal. Don’t exclude anyone from this protection either fully or partially. Remember that partial MFA protection is as good as zero protection.
5. Ensure MFA Implementation Is Phishing Resistant
Identify any applications that may use SMS or call back based MFA, with added emphasis on legacy applications, and ensure those methods are updated as soon as possible. For additional awareness and assistance, we recommend following the guidance provided by the Federal Trade Commission9 and Cybersecurity and Infrastructure Security Agency10.
Overcome the MFA Challenge With an Approach That Provides Full MFA Coverage
To overcome the MFA challenge presented in this paper, the client should consider an approach that aims to solve the challenges that a traditional MFA implementation fails to address. The approach should manage and integrate all cloud and on-premise identity providers (IdP) in the environment. Solving these issues for cloud alone leaves gaps that can be exploited for on-premise environments. The concept is to ensure that every authentication and access request is analyzed prior to granting or denying user access. Presuming some requests can’t or shouldn’t be analyzed leaves potential gaps. These gaps have led to events described in this paper. It is important to state that analyzing access requests and triggering MFA must be protocol agnostic, including those originating from legacy authentication protocols, command line, file share, and any other on-prem resources to guarantee full MFA coverage. This means that MFA can be extended to all resources that are traditionally beyond the scope of this type of protection.
AIG Study #4:
AIG has conducted numerous incident dialogs where the use of SMS based MFA was identified as he root cause allowing the TA to gain initial access via SIM Swapping. Recently, AIG identified a case where MFA Interception occurred via eSIM number porting such that the MFA code provided during the call back was given directly to the TA.
Furthermore, many machines within the enterprise environment cannot sustain an MFA agent due to operability issues, such as service accounts. Service accounts in Active Directory (AD) are user accounts that are not owned or used by people and instead are dedicated to a specific application or system. These accounts are frequently configured to run a service on servers and/or workstations in an environment. Service accounts are typically granted privileged rights in the environment and are often added to highly privileged groups such as the Domain Admins group. This is frequently due to the recommended and supported installation model pushed by software vendors to avoid permission issues or functionality mishaps during installation and operation. In order for these accounts to work, the service account name and password must be stored locally on the system. Service accounts have a password that is set when created and rarely changed. If an attacker can guess or otherwise discover the password, including compromising a system where the service account is used, they would be able to extract and employ those service account credentials to exploit the environment.
Microsoft’s best practice guidance is that Domain Admins should not be used outside build/fix, and instead proper delegation and “least privilege” should be enforced, but our study shows this isn’t happening in practice – and ransomware actors are taking advantage.
In many of the over-privileged service accounts analyzed by AIG in cyber insurance applications submitted by potential policyholders, it was discovered that the elevated privileges were not necessary for the operation of the service account on servers or workstations. Service accounts6 rarely require the highest level of privilege to perform the function on a server or workstation. The risk of being compromised was very high due to the nature of those service accounts.
We observed several organizations authorizing direct remote privileged user access through a remote access solution such as VPN. Even if MFA-enabled, organizations should authorize unprivileged remote access only if followed by a second step of privilege escalation from within the network. The privilege-escalation MFA should be a dedicated/separate security control.
AIG Study #2:
that stated they used MFA for protecting privileged access were still impacted by a ransomware event linked to coverage gaps in MFA configuration/installation method.5
63%
of organizations
What Are the Challenges of Traditional MFA?
Technology Gap of Legacy Resources and Protocols
MFA as a technology has been around for a relatively long time, but it is not as widely used as you would expect. For applications or systems born in the cloud, MFA is natively integrated into modern web and SaaS app authentication protocols. This supports a reduction in BEC4 attacks using these platforms. However, it is important to note that this protection does not extend to the organization’s on-premises servers, workstations, databases, and apps. For many organizations, a significant portion of their critical infrastructure and access methods still reside in the on-premises environment.
Through the process of reviewing cyber insurance applications from potential policyholders,
AIG has learned that applicants have difficulty meeting the MFA requirements due to these challenges:
In versions prior to Windows 10, MFA does not come as a pre-configured, ready-to-deploy option as part of standard on-premises Microsoft Active Directory deployment.
Access to critical resources is done via native authentication protocols such as Windows New Technology LAN Manager (NTLM) or Kerberos. If compromised, the TA can take over the domain. Also, command-line access to workstations and servers, IT and networking infrastructure, old applications, and many more that don’t support MFA technology.
AIG Study #1
A regular employee’s credentials used to log into the organization’s corporate resources were compromised. The remote access used by the employee was not configured with MFA. As such, the TA (Threat Actor) was able to connect to a Citrix gateway, used the valid employee’s credentials and compromised the organization’s external perimeter. From that point, the TA moved laterally across the network using Remote Desktop Protocol (RDP) connections. Then, they elevated privileges by compromising a privileged service account used for a backup service. Without risk mitigation controls in place, the TA used Group Policy (GPO) modifications to run LockBit ransomware malware and encrypted data across the virtual environment. (For more information on privileged Service Account compromise, refer to the topic “MFA Coverage Gaps Due to Installation Method” below.)
The ransomware landscape has seen a major escalation in the frequency and scope of attacks
in 20231. As cybercriminals have become more sophisticated, they are exploiting most organizations' critical gaps against identity threats – with over 83% already having experienced a breach involving compromised credentials2. Identity is also one of the key pillars of the zero-trust strategy,3 making it critical for organizations to review their Identity and Access Management strategy. Multi-Factor Authentication (MFA) has long been advocated as a robust measure to bolster an organization’s security posture, but misconfigurations and gaps in MFA coverage have proven that a more holistic and unified approach is needed to stem the tide of this dangerous trend in cybercrime.
What Is the Security Value of MFA?
MFA is an authentication mechanism where a user must verify their identity by presenting two or more pieces of evidence to gain access to a website, account, or application. This evidence includes 1) something the user knows (password, PIN, codes, etc.), 2) something the user possesses (keys, smart phones, smart cards, token devices, etc.), or 3) something the user is (facial recognition, retina scans, fingerprint scans, etc.). The authentication mechanism only grants access if each of the authentication factors are successfully verified. In this way, if user credentials (such as a username and password) have been compromised, a cybercriminal cannot automatically gain access to the account. MFA adds additional layers of security, making unauthorized access more difficult.
Now consider a typical ransomware scenario, which usually consists of three phases: 1) initial access and gaining a foothold within the target organization; 2) privilege escalation and lateral movement; and 3) data exfiltration and/or ransomware deployment and execution. Without MFA on external connections an attacker can leverage compromised credentials to infiltrate the internal network through VPN or any other remote connection. Within the internal network, an attacker could freely move laterally inside the domain and infect any domain-joined system with the ransomware payload. In this sense, backups should not be joined in the domain so that the recovery process is not also compromised.
Properly configured MFA is a proven security mechanism that can prevent malicious access with compromised credentials in real time.
Why Is MFA Crucial for Administrative Users?
Administrative users or privileged users can access all critical resources within the network environment.
From an attacker’s perspective, compromising a privileged user account is the single best strategy to deploy and execute the ransomware payload on every resource that the privileged user has access to. This makes protection of privileged users with MFA a top priority.
MFA Coverage Gaps Due To Installation Method
Traditional MFA installation methods rely on either installing an MFA agent on resources that need protection or placing a proxy in front of their network segment. Both methods introduce inherent coverage gaps.
More than
66%
of organizations compromised by a ransomware attack saw ransomware deployment linked to the compromise of a highly privileged account on their Active Directory environment.
In versions prior to Windows 10, MFA does not come as a pre-configured, ready-to-deploy option as part of standard on-premises Microsoft Active Directory deployment.
Access to critical resources is done via native authentication protocols such as Windows New Technology LAN Manager (NTLM) or Kerberos. If compromised, the TA can take over the domain. Also, command-line access to workstations and servers, IT and networking infrastructure, old applications, and many more that don’t support MFA technology.
MFA Coverage Gaps Due To Installation MethodTraditional MFA installation methods rely on either installing an MFA agent on resources that need protection or placing a proxy in front of their network segment. Both methods introduce inherent coverage gaps.
AIG Study #3:
AIG has conducted numerous incident dialogs where an over-privileged service account was identified as the root cause behind a TA acquiring highly privileged credentials, thereby allowing them to elevate privileges and compromise all domain-joined systems. In many cases, applicants were unaware of the risk; in other cases the risk was ignored for fear of breaking the service by de-privileging the service account.
In one case, a service account was inadvertently added to the VPN profile, allowing the TA to use that account for remote access without MFA because MFA is virtually impossible to enforce on service accounts.
MFA Bypass Due To Telephony-Based Authentication Methods
Over the past year there has been an increase in MFA bypass as a defense evasion technique. As such, it is extremely important to give consideration during implementation and the approved methods allowed for MFA authentication. MFA Interception7 is one of the more common MFA bypass techniques used for Credential Access. Typically, MFA Interception is accomplished via one of the following methods: SIM Swapping against SMS-based MFA implementations, and eSIM number porting used against call back-based MFA implementations. Other methods of MFA bypass include social engineering to trick a user into providing the MFA code, the use of fake SSO sites to capture the code in real time, and the use of MFA Authentication Request Generation8 designed to cause MFA fatigue.
