Introduction
As we have witnessed in recent weeks with the MGM and Caesars Entertainment breaches, helpdesks are prime attack surfaces that are seeing a surge in exploitation. Although much of the press surrounding these most recent events alludes to helpdesk operators’ roles in the exploits, this type of vulnerability actually is a technology and process problem rather than a people problem. The most effective way to defend against this type of attack is to understand the adversarial perspective. That is, consider how the attackers approach each hurdle they encounter when contacting a helpdesk, and refine your organization’s process and technology to mitigate any weaknesses. This blog covers common Tactics, Techniques & Procedures (TTPs) that many Red Teams, including ours, use to compromise high value assets through exploitation of helpdesk procedures.
The Attack Surface
To state the obvious, the purpose of helpdesk is to be helpful. This mission, along with the excessive privileges helpdesk operators often wield, can be a recipe for major security incidents. Attackers are able to exploit the process and technology weaknesses in light of helpdesk operators’ need to do their job. We will delve more deeply into this during our Enumeration section.
When considering a helpdesk organization as an attack surface to exploit, some aspects of the approach depends on the size and maturity of the company. Some companies have heroic small teams, and others have established well-formalized, global teams with a modern technology stack. However, regardless of size and complexity of the organization, almost all incorporate multiple ways in which to interact with helpdesk. Phone calls, emails, instant messaging apps, and “AI” bots all present a unique aspect of the company’s helpdesk attack surface.
The Attack Objectives
When targeting the helpdesk, an external attacker will have a goal in mind, which breaks down into two stages. The first goal–obtaining initial access–will be done in such a way as to enable the attacker to reset account authentication material and/or execute code. The path they choose for ingress, and what they elect to do once they have compromised the organization, stems directly from the second goal–disclosing sensitive information. Attack paths will vary based on whether they seek organization assets, employee information, or customer data.
This post focuses on how an attacker could undertake telephonic interactions with helpdesk operators (the attack surface), with the intention of compromising organizational assets (the attack objective) rather than the organization’s customers. The figure provides a visual map of this particular attack.
Figure: The attack elements involved in targeting helpdesk over the telephone.
Enumeration
Enumeration, or the information gathering phase of the attack lifecycle, answers three questions for us when we act as an adversary in a Red Team Exercise. First, how should I make contact? Next, once I do make contact, what information will helpdesk require during caller verification? Finally, what exceptions are in place that I can exploit?
Making Contact
An organization often publicly discloses their helpdesk information, so an attacker simply needs to know where to search. Some common methods we use to identify the relevant numbers include:
- Crawl the company’s websites–pay particular attention to login form “help” functionality
- Google dorks–‘site: acme.com “helpdesk”’
- Email signatures–send benign emails to typical helpdesk ticketing addresses and look for contact information in the auto-generated response signatures.
Outlining the Identity Verification Process
You know the drill: each time you interact with a support system, you must pass their verification process. This process differs from organization to organization, with no industry standard that we have observed. In order to outline the full process a target organization might require, we follow a simple yet time consuming sequence. We begin by calling helpdesk, then listen to the questions and stumble through guessing the answers until the process boots us out. We take careful notes along the way, and repeat the sequence until we have detailed the entire pool of verification questions. These often include:
- Caller’s name
- Business unit
- Manager’s name
- Location
- Start of employment date
We usually can find the answers to these verification questions through the spoofed user’s LinkedIn profile. An attacker most likely will obtain the relevant information for a pool of personas they intend to spoof.
Exploring Exceptions
Occasionally, we have found that offering an incorrect answer results in the operator suggesting the correct answer, as in the following exchange:
Caller: “My manager is Ted”
Operator: “That is incorrect”
Caller: “Ted is who I work with daily, so that is kinda odd. Who do you have listed out of curiosity?”
Operator: “We have your manager listed as Bob”
Caller: “Ahh Bob, we hardly interact with him these days, but that must be correct, thanks!”
Exploring the exceptions, purposefully providing incorrect data, and determining alternate validation options always is worth the effort. In some cases, the helpdesk operator can verify a caller’s identity by receiving an email from their manager, which we can spoof from what we claim is our manager’s “personal email.” Other times, the operator has prompted us with a multiple choice question that we can keep coming back to on follow-up calls after each failed attempt.
In a few instances, operators have not requested verification information at all, despite each previous call to helpdesk having maintained a hard line on identity validation. From an attacker’s perspective, it pays to just keep dialing. Think of that NSFW speech from The Wolf of Wall Street.
Resetting Authentication Material
From the reconnaissance phase, an attacker may have identified Internet exposed Citrix portals that require username, password and RSA token as MFA. When they want to gain access to this account and resource, they pick up the phone and leverage the valid persona’s they have enumerated to execute against the goal of resetting authentication material.
Resetting Passwords
On our calls with helpdesk, we immediately request a password change. In most cases, we have to complete the verification process, but this is no longer a barrier. If we are lucky, the operator will update the password on our behalf and issue the new temporary password. That’s an easy win.
Other times, we encounter more hoops to jump through, as in the following exchange:
Operator: “We will email your manager your new password”
Caller: “But my manager is out of office, what other options are there?”
Operator: “We can email another employee?”
Caller: “Hmm, what if my manager emailed you saying it’s fine to reset my password and to tell it to me over the phone”
After the above exchange, we, acting as an attacker, would proceed to send such an email from a throw-away account. The key theme is to explore the exceptions and present ideas favorable to us as the attacker. Ultimately, our goal is to see if the company implements these procedures via technical control, or if operators can bypass the procedures at their discretion.
Resetting MFA
So, in our scenario we now have a valid username and password, but the company did good–they require MFA. An attacker could undertake a number of actions to facilitate bypassing this secondary control with assistance from helpdesk, including the following:
- Temporarily disable MFA for the account
- Remove MFA for the account and require a new MFA enrolment after the next successful login
- Issue an “emergency” one-time-code
- Send the MFA material to an external email address
Depending on the MFA mechanism, the details of our approach will vary, but the basic strategy remains consistent. In the case of RSA softtokens, our teams have had multiple successes with claiming their token stopped working, and requesting helpdesk send the softtoken to a phony email address (along the lines of ‘legit@notlegit.com’). For push-based MFA (tut tut), we find success with, “I’ve just upgraded my phone but now I don’t get login prompts. Can you disable MFA and I will re-enroll this phone.” We try mixing up our preferred option across various calls, so we can further enumerate the options and exceptions they provide.
Regardless of which approach worked, now that we (or an attacker) have valid login credentials and the ability to side-step MFA, we can login to that external Citrix gateway.
Obtaining Malicious Code Execution:
Exploiting helpdesk for credentials is highly effective, but it also is an attack surface that is vulnerable to code execution. From an attacker’s perspective, this is especially true when there are no viable remote login services to target. Furthermore, helpdesk operators usually have higher privileges than typical employees, which can make pursuing code execution a particularly attractive objective.
The business nature of the target organization will determine the most viable approaches, but common themes exist. Some of Praetorian Red Team’s favorite approaches include the following:
Stubborn File
We will pretend to be an employee who is attempting to open a file that a key customer has provided. This customer of ours is a pain, and our manager is a hard-ass. We need help, or else our kids will not have a Christmas. We explain that we just need helpdesk to figure out how to open the file and tell us the invoice price and PO. They can save Christmas!
Praetorian crafts a payload, which could range from a maldoc to a zipped up binary with DLL, and provides the file to the helpdesk to open on our behalf. Our explanation for the odd extension is a baffled statement of, “Uh I think it’s a PDF but it has some silly add-on that is always a pain.”
The Trap Virtual Machine
We create a Windows virtual machine (VM) with a keylogger running, then call helpdesk to have an exchange like the following:
Caller: “Having trouble installing Citrix Reciever and I have a client that needs me to action something asap. Can you remotely connect to troubleshoot, please.”
The target takes control of our VM and installs the request application.
Caller: “Ahh that’s great, thanks, let me just try and login quickly. Oh, it doesn’t seem to be working.”
Operator: “Let me check the status of your account.”
Caller: “Oh no! My call is in 20 minutes, the client is expecting the work to be done, and my boss is going to go crazy.”
Operator: “The system is showing you have entered incorrect login details.”
Caller: “Can you reset it for me quickly, please?”
Operator: “We can send the new password to your manager.”
Caller: “My manager is onsite with the client, and doesn’t play nice.”
[…]: “Before I disturb them, can you triple check that it’s my account and not my system?”
[…]: “Maybe try to login with your own creds, please, from my system, just to make sure it’s not an account issue?”
Operator “Hmm okay, let me try that to help you”
The attack then proceeds along these steps:
- The operator logs-in to Citrix from our trap Virtual Machine using their own privileged credentials.
- We capture the entered login credentials, and also pause the VM.
- We gracefully exit the call, stating the laptop battery died but that their Citrix session has logged out.
- We then resume the paused VM and continue to access Citrix using the existing authenticated session established by the helpdesk operator.
- Having access to Citrix, we are now able to pivot access to the internal environment as a privileged user.
Common Conversation Styles
Every interaction is different, and various operators respond to different stimuli, but the underlying strategy is to exert pressure on the operator’s desire to help so that we can identify and exploit the weaknesses in the processes and technology. Common approaches our Red Team has used include the following:
- Tech-a-phobe with no idea of what they are doing
- An employee with a HR complaint about their manager, to tease out procedural exceptions
- An employee on vacation abroad
- An employee on maternity leave
- An employee with anger issues
- An employee who is super nice
Recommendations
The helpdesk attack surface is not, at its core, a people problem. Companies need their helpdesk operators to want to be helpful; they have to facilitate the business’ objectives. In fact, as we walked through a call-based attack in this post, our goal was to emphasize that the actual vulnerabilities we target are in the processes and technology. Therefore, companies that want to minimize the helpdesk attack surface need to focus on curtailing exceptions in their processes and closing gaps in their technology.
Codify Identity Verification Processes
Codifying your verification process is a good first step. Do not rely on policy, procedures, or training to eliminate exceptions. Instead, implement technical controls as restrictions so that your operators are not in a position where an attacker could take advantage of their desire to help. This is as simple as requiring operators to enter the identity validation information provided by the caller, and not displaying the correct answer to the operator. The operators cannot provide information that they do not have.
You also can require a codified workflow to prevent operators from directly modifying users and AD. An implementation tool such as SailPoint IdentifyIQ can help facilitate these codifications for your helpdesk. More broadly, restricting helpdesk operators’ permissions can help eliminate the possibility of exceptions being used for impactful breaches.
You also can make the verification questions themselves a more difficult obstacle to surmount by presenting them in the same order every time, and presenting the same verification question over again until a caller answers it correctly. Doing so will significantly complicate the enumeration stage for an attacker.
Limit Disposition of Sensitive Materials and Monitor Requests
Part of closing gaps in processes is limiting the ways people can communicate sensitive information, and monitoring requests for it. Set up your secure email gateway layer to prevent employees from sending sensitive authentication material (passwords, soft tokens) to external email addresses. This complicates the exploitation phase for an attacker, as obtaining access to an existing employee mailbox is far more difficult than establishing a throwaway external account.
Likewise, monitor requests for actions that are related to access and privilege. Log sensitive action requests to a SIEM to engineer detection logic. This will notify your security team when an “employee” just tried to reset his password 7 times and failed 20 verification attempts, for example. In a similar vein, keep a log of all helpdesk calls to assist in auditing, IR, and operator training.
Conclusion
Real-world threat actors are focusing on helpdesk to gain initial access to organizational assets, employee information, and customer data. In this post, we outlined some of the approaches our Praetorian Red Team engineers have used during offensive security engagements, to help our clients understand their attackers’ perspective. Viewing your attack surface–in this case, the telephone approach to helpdesk–through an adversarial lens is the most effective way to truly expose critical gaps in your processes and technology so you can implement practical solutions for remediation.
Praetorian is a cybersecurity company with over a decade of experience in Red Teaming, Attack Path Mapping, and the related social engineering. To talk with one of our experts about how to secure your helpdesk or broader organization against this type of attack, please contact us.
