The Obsidian Threat Research team has determined an uptick in SaaS compromises where the initial access vector is social engineering of a helpdesk agent. Fortunately, threat actors tend to follow a predictable pattern when leveraging this attack technique.
In this blog post, we’ll unpack the distinct phases of these attacks, explain how they are reflected in SaaS logs, and provide measures your team can take to stay secure in the face of this emerging technique.
What is this technique?
This technique typically begins with the attacker identifying a key user within an organization’s IT team.
The attacker then calls the helpdesk, posing as the employee to request a new password and MFA deactivation for their account. Once successful, they can implement measures to ensure their own persistence and execute more damaging campaigns that have included data theft, ransomware, extortion, and other criminal activities.
What are the steps in executing this attack?
The attacks our team has observed follow a structure similar to this:
1. Identify the target.
The threat actor begins by looking for someone with elevated privileges within the target organization.
This might start with a simple Google search query:
(“Senior IT Administrator” OR “Network Architect” OR “Security Engineer”) AND “<target_organization_name>” site:linkedin.com
2. Make the call.
The threat actor locates the organization’s helpdesk phone number, which is oftentimes posted publicly on a Contact Us or Support page. They call and perform an attack with a script similar to this:
Threat Actor (TA): “Hello, This is John Smith calling in an issue with my account. Well, it’s not really an issue, I just don’t remember my password after coming back from vacation. Would you be able to reset my password for me? I have a P1 system outage that I need to get to ASAP.”
Help Desk (HD): “Certainly, I have temporarily changed your password to ‘ChangeMe123!’. When you log in, you will be prompted to enter in a new password.”
TA: “Excellent, thank you so much! Do you mind staying on the line while I do this? I really need to get to that outage and don’t want to have to call back.”
HD: “Of course!”
TA: “Oh no, I have another snag. On vacation, I dropped my phone off a boat while we were deep sea fishing. I didn’t have a chance to update my MFA to my new iPhone. Could you deactivate my MFA on my account so I can get that updated real quick? I am going to have to drop now to join the major incident call for this outage. Let me know when the MFA is deactivated and I will get mine added immediately.”
HD: “OK, your MFA has been deactivated. You will be prompted to add in your new device. Do you need any assistance adding it?”
TA: “No, I will be fine. Thanks so much for your help—I need to run to the other call!”
3. Execute the attack.
With complete control of the account, the threat actor moves quickly through the environment, knowing it’s only a matter of time until the real user attempts to login and discovers their password is no longer valid.
We observe the following activities being performed by these threat actors after gaining initial access:
- Application SSO burst of activity
- Deletion of security notification emails
- Access of infrastructure documentation
- Exfiltration of sensitive information (e.g., PII, PHI, card data, etc.)
- Searches for unsecured credentials
- Pivots to admin consoles, internal VPNs, and cloud environments
In the majority of our observed compromises, the attacker was able to complete their objective within hours of the initial compromise.
How do helpdesk employees handle these requests?
Typically a helpdesk will have a playbook for password resets that includes changing the user’s password to a basic, predefined phrase—in our example, “ChangeMe123!”—and then requiring the user to change this password on their next login. This will cause subsequent login attempts to fail due to an expired password, and is something we can see evidenced in logs from various systems.
What do the logs for this attack look like?
The following is an event sequence from a compromise we observed at a company utilizing Okta and Azure Active Directory.
Attack Stage: Logon
Log Event: app.ad.login.expired_password
Notes: This event is thrown if the helpdesk has marked the account “user must change password on next logon.”
Attack Stage: Deactivate MFA
Log Event: core.user.factor.deactivate or user.mfa.factor.reset_all
Notes: This event will show the helpdesk agent as the actor that deactivated the target user’s MFA.
Attack Stage: Add Malicious MFA
Log Event: core.user.factor.activate
Notes: The threat actor will add their own MFA device from their attacking IP.
If you pull Okta logs into Obsidian Security, you’re able to see the attack in this way:
Query: (app.ad.password.reset.success OR core.user.factor.deactivate OR core.user.factor.activate)
What can I do to detect and mitigate this attack?
Your approach to detecting the aforementioned sequence of events will depend on the tools you have at your disposal.
For Okta Console queries, you will need to craft queries such as the following and group them by timeframe and actor:
eventType eq “user.mfa.factor.activate” OR eventType eq “user.mfa.factor.deactivate” OR eventType eq “user.account.update_password”
Additionally, you can filter for events using Okta’s risk levels to identify new devices, locations, and IP addresses to help focus on possible threat actor activity. Below is an example JSON object from Okta indicating an anomalous device and location:
“logOnlySecurityData”:”{“risk”:{“reasons”:”Anomalous Device, Anomalous Location”,”level”:”HIGH”},”behaviors”:{“New Geo-Location”:”POSITIVE”,”New Device”:”POSITIVE”,”New IP”:”POSITIVE”,”New State”:”POSITIVE”,”New Country”:”NEGATIVE”,”Velocity”:”POSITIVE”,”New City”:”POSITIVE”}}”
If you are an Obsidian Security user, you will receive an alert for a suspicious MFA device activation:
Additionally, you can set up alerting to this activity with the following query:
(app.ad.password.reset.success OR core.user.factor.deactivate OR core.user.factor.activate)
To tune the alert, you can add additional filters such as target.account.is_privileged or ip.is_proxy.
Conclusion
The rise of helpdesk social engineering should serve as a driver for teams to review and discuss preventative measures such as identity verification. Taking an extra moment to confirm the identity of the caller when performing a password reset or MFA deactivation can make all the difference here—even a simple video call to compare user identity against a profile picture can help in these cases. Ultimately, your team will need to determine what is realistic and works best for your organization’s unique needs.