Device bait and switch: A case of device replacement
Duo’s AI and Security Research team takes on security cases from customers digging into telemetry data to find actionable anomalies that can be searched for, alerted on, and remediated sometimes with AI and machine learning.
A user picks up their phone and sees a Duo Push they didn’t request. They think this is strange and deny the Push request. Their account is safe now but unbeknownst to them, the attacker will discover another avenue of attack and successfully compromise their account. In this blog, we’ll explore what happened in a peculiar case of SMS compromise.
The case submission
Frequently, when the AI and Security Research Team receive a case, the customer requests to know more about how Duo products work or about follow-up actions and recommendations after an incident. In this case, a customer employee received a push to their mobile device, which they then denied. However, according to the customer, two successful authentication attempts followed, one of which used an SMS passcode.
The administrator requested that the user change their password and wanted to know how these authentications could have been successful after being denied by the user.
In the customer submission, a username was provided—this account was a service account that could have multiple devices tied to it. When service accounts are involved, the severity of the incident can go up drastically; there are increased permissions and therefore more opportunities for lateral movement into other accounts and systems. This case needed a closer eye to halt any further compromise.
The dive
Something notable occurred a month before the incident. According to logs, an administrator had unlocked the account after a few failed authentications, then added in a set of user authentication bypass policies.
When we looked back at the incident timeline, we saw that several new phone identifiers were created after the likely start of the incident. These new phone identifiers could be an attempt by an attacker to create a backup access method if their initial phone was removed from the account—an example of persistence.
Our first dive is to understand which devices authenticated to that account. Searching through phone models and versions, we learn that there are two associated devices with the same phone identifier. This is of note—two phone models associated with one identifier means that the account’s device was replaced in the self-service portal.
Finally, two separate locations with two different IPs were seen accessing the account, seemingly in tandem. This is where things get interesting...
A tale of two IPs
Recall that our user reported that they denied the initial 2FA prompts received. Therefore, looking for prompts that received a ‘user denied’ response may lead to the action that caused the compromise. Sure enough, there were several denied responses from the primary phone tied to the account. But shortly after those denied responses were a set of successes...on a different phone key, from a different IP in a different state.
Looking back at this new phone key, it appears it was created and left alone- no activity occurred using it for months after its creation. This device could be the initial access point used by the attacker, or it could've been added later if the attacker compromised the original device's phone number.
These IPs duel for about a day—a login was initiated from devices in one state, followed by the legitimate user’s denial. Finally, an authentication is initiated by the attacker and responded to by the dormant device on the account, likely controlled by the attacker— this granted the attacker access.
After the attacker gained full access to the user’s Duo account, they took steps to fortify their position. By changing the user’s default phone identifier to their own phone and adding several more phone identifiers, the attacker takes hold of the account.
Thankfully, there wasn’t any lateral movement off of the account—none of the associated phone identifiers had attempted to access any other user account.
The response, and a point of confusion
Some cleanup activity was seen after the authentications and phone changes above. An administrator removed one of the phones from the account but didn’t successfully remove the others. For this reason, the response to the customer included a recommendation to change the user password and remove all devices from the account—this should lock the attacker out for good.
Additionally, the user authentication bypasses were placed a month before the incident but never removed. When a Duo Bypass is put into place, the user is not required to use Duo two-factor authentication at log on and is not subject to any policy settings that restrict access.
While this bypass was still in place and didn’t have anything to do with the initial access to the account, it could have made the attacker’s takeover significantly easier if they had taken advantage of it.
We also recommended that the customer perform a regular audit of devices on Duo accounts and of bypasses placed on them and turn off lower-level factors (like SMS and phone calls) if feasible.
A takeaway on device management
In today’s day and age, the commonality of attacks on phone numbers and misconfigurations has drastically increased. The ‘SIM card swapping’ technique, in which attackers social engineer or bribe carriers into providing access to a phone number is used in a lot of attacks of varying complexity (including large-scale cybercriminal groups). Other attacks take advantage of user error, like those targeting common device vulnerabilities to find gaps in MFA.
Careful device management, including removal of stale/unused devices after a delay period, can remove the attack vector that becomes the downfall of your organization’s defenses.