5 Cybersecurity Threats in 2023 (and How ITDR Can Help)
We’re seeing attacks on the identity layer rise to prominence amongst active cybersecurity threats in 2023. As the world of corporate IT has consolidated around access management, so too have attack techniques. Identity Threat Detection and Response (IDTR), a newly coined term from Gartner, aligns with the work that our algorithm research team focuses on.
Here at Duo, we’ve been very focused on these patterns as we work to secure our customers’ environments, meeting you where you’re at. We encourage you to follow best practices, including adopting FIDO2 wherever possible.
We also recognize that prevention is just one side of the coin, and that many security teams rely on strong detections to protect their environment. We know our customers have a lot of different environments and integrations, but all want to improve their defenses and visibility into the latest threats.
We’ve put together some discussions below about specific threats we’ve seen in the wild, along with some pseudo-code detectors that are environment-agnostic to use with your Duo logs and improve your security team’s operations.
1. Device Registration
This technique – which MITRE refers to as Account Manipulation: Device Registration (T1098.005) - is used by attackers to gain persistence after gaining initial access via another technique like MFA Fatigue. Persistence is often a critical piece of an attack chain as malicious actors work towards impact, such as ransomware, data exfiltration, or other harmful activities.
At Duo, we’ve prioritized the development of features to help detect it in your environment.
Authentication device registration happens significantly less frequently than authentication events. It’s also a high-impact situation: The trust you extend to all future authentication events from that device is predicated on it being controlled by the legitimate user. Due to the elevated risk from these rare events, we’ve spoken with several security teams who err on the side of recall (seeing all events that might indicate this threat type) over precision (seeing only those events that are definitely this threat type). We’ve spoken with some customers who manually review every registration event, and others who find this impossible.
Depending on where you fall in this spectrum, you may want to combine some of these detectors, implement them selectively, or add conditions unique to your environment. If you’re interested in getting access to the robust set of detections that our research team has developed, look into Registration Threat Detection within Trust Monitor.
Detector Logic
If a phone number has not been previously used by the user, alert.
If a user registers an authentication device with a laptop or device they have not used before, alert.
Pseudocode
#Alerting rule for a phone number that has not been used previously by a user
Function unknownphonenumber(user, phone):
if phone.number not in user.previous_numbers:
alert_siem()
#Alerting rule for a user using a different device or laptop
Function userchangesdevice(user, device):
if device.os not in user.previous_os:
alert_siem(user, device.os)
if device.browser not in user.previous_browser:
alert_siem(user, device.browser)
Duo Logs
Possible False Positive Causes
These two detections are relatively limited and based on the assumption that a user who upgrades their personal device will keep the same phone number and use the same computer to perform the registration that they’ve used previously. There are plenty of benign reasons to change one’s number or change phone platforms, all of which would produce false positives.
This month, we’re launching General Availability of Registration Threat Detection which takes a much broader and deeper look into known attacks, allowing us to create a much higher-fidelity alerting signal for this threat type.
2. Cookie Theft
The identity layer doesn’t exist in a vacuum - it works together with the endpoint, network, and cloud layers of your environment. We’ve seen examples in the wild of malware slipping past endpoint defenses and being used to target session cookies for exfiltration, allowing attackers to jump from a user’s endpoint to their cloud accounts. MITRE refers to these techniques as Steal Web Session Cookie (T1539).
If you’ve combined detectors from your XDR or MDM to use with your identity solutions, we’d love to talk with you.
Detector Logic
If an authentication cookie is used from an IP address that it was not issued to, alert.
Pseudocode
#Alerting rule for a remembered session changing IPs
def IPchangedwithin_session():
for txid:
if reason = ‘remembereddevice’ and ip not in historicuser_ips:
alert_siem()
Duo Logs
Possible False Positive Causes
Unfortunately, there are a huge number of benign reasons that a user’s IP address might change within a session. Employees work in and out of the office, ISPs regularly rotate IP ranges, routers are reset. We’ve gotten significant customer feedback that naively ending sessions based on this signal alone is too noisy for our customers.
This is one of the reasons that we’ve implemented techniques like Wi-Fi Fingerprint in Risk-Based Authentication, which is very difficult for attackers to mimic and give Duo a strong signal that the user is in the same location they’ve authenticated from before.
3. MFA Fatigue
MITRE refers to this technique as Multi-Factor Authentication Request Generation (T1621). However, you may have heard these attacks referred to by a couple of different names: MFA fatigue, push fatigue, push harassment, push grief, etc.
Whatever you call it, after primary credentials have been compromised, the attacker repeatedly prompts the legitimate account holder with authentication requests until they accept. We’ll focus on one way that this has presented itself in the wild, where an attacker is targeting one user in specific.
Detector Logic
If there are more than ten authentication attempt failures within ten minutes for a specific user, alert.
Pseudocode
#Alerting rule for a series of unsuccessful authentication attempts
def repeatedauthenticationfailures():
for txid:
if count(txidforuser) in range(timestamp, timestamp-10m) and result != success > 10:
alert_siem()
Duo Logs
Possible False Positive Causes
We’ve documented a number of benign situations that can trip some of these more-naive detectors. Sometimes a user is unaware that one of their applications has reset itself and engaged some auto-authentication protocol, either because it’s in the background or because the user is away from their workstation.
This is why we’ve implemented a broad set of detections, as well as sophisticated tamping mechanisms, into Risk-Based Authentication to improve its accuracy, reducing false positives while improving performance against known attack patterns.
4. Account Takeover
Account takeover, which MITRE refers to as Valid Accounts: Cloud Accounts (T108.004), can be a catch-all. It's used for some types of attacks that don’t fit nicely into one of the other MITRE techniques, or where attribution can’t be confirmed, or when forensic investigation hasn’t established what happened yet.
In our context, it can help to look at behaviors that are sometimes consistent with malicious account access. One of the simpler detections you can apply without referring to external sources is alerts for when a user is accessing from a new location.
Detector Logic
If an authentication occurs from a location that the user has not authenticated from before, alert.
Pseudocode
#Alerting rule for novel location
def novel_location():
for txid:
if accessdevice:location not in historicuser_locations:
alert_siem()
historicuserlocations.append(‘location’)
Duo Logs
Possible False Positive Causes
Users routinely travel for legitimate reasons, and this is a very context-dependent detector. Some environments imply that a user should be in a static location or IP range, while others expect end users to regularly jump to new locations.
Going a step further, we’ve had geo-improbable detectors implemented at scale for several years, and we’ve learned a lot about ways to implement these detections better in Trust Monitor. Some of the false positive alerts are caused by end users jumping onto and off of a VPN, or between a Wi-Fi network and a cellular network. Some are caused by ISPs rotating through their IP address ranges. And others fall into an assortment of other benign, routine reasons.
5. Disabling or Modifying MFA
Attacks on administrative controls have been around as long as administrative controls. MITRE refers to techniques that modify (or even eliminate) MFA requirements as Modify Authentication Process: Multi-Factor Authentication (T1556.006). Many professionals find that protecting these controls, such as limiting access to specific networks, devices, and accounts, is useful in a defense-in-depth strategy. Monitoring and establishing detection and response rules to this threat vector can improve your standing.
Detector Logic
If a new administrator account is created, alert.
If a bypass code is created for an end user, alert.
If an authentication policy is changed, alert.
Pseudocode
#Alerting rule for new administrator account
def new_admin():
for action in /admin/v1/logs/administrator:
if action = admincreate or action = adminupdate:
alert_siem()
#Alerting rule for bypass code creation
def new_bypass():
for action in /admin/v1/logs/administrator:
if action = bypass_create:
alert_siem()
#Alerting rule for policy changes
def new_policy():
for action in /admin/v1/logs/administrator:
if action = policydelete or action = policyupdate:
alert_siem()
Duo Logs
Possible False Positive Causes
There are a number of legitimate reasons that administrators need to modify authentication processes. Customers may prefer to audit some subsets of these actions due to their sensitivity.
Responding to these cyber threats
We’ve found that customers benefit from a variety of remediations. Some customers develop a specific ‘quarantine group’ within their environment, to which they can move users, which has limited or no access, while they investigate and remediate the situation. Others prefer to complete the entire remediation process out-of-band, directly through their directory.
We’d love to hear more about your experience and preferences as we work to improve your workflows.
Duo Logs
Duo's work continues
If you’re interested in these attack types and detection, we want to work with you. Many of our offerings - including Trust Monitor, with its new Registration Threat Detection, and Risk-Based Authentication, which is generally available as of this month - are based on these kinds of detections. We continue the work to research the most high-impact threats in the identity world and bring you solutions that work for your environment.
These detectors just scratch the surface of identity threats, and we want to continue the conversation. Do you have thoughts on how to apply detections across your stack? Do you have concerns you want us to address? Want to talk about Identity Threat Detection and Response?
Please reach out via the feedback form to the product team with your thoughts, requests, or feedback.