One of the most frustrating rules of cybersecurity is that no matter the investments organizations make in their technology or how sophisticated their architecture is, it is usually easier to hack a person or a process than it is to break a technology. Multi-factor authentication (MFA) is so effective that attackers don’t bother attacking it directly: instead, they’re finding ways to evade MFA and target other business layers or users to gain a foothold in an environment.
When evading MFA, cybercriminals use scam emails, texts, and notifications supposedly from “a help desk email account” to target users in prompt bombing and MFA fatigue attacks. But what happens when hackers evolve their tactics and go after the help desk itself?
It’s not just a theoretical question. Caesars Entertainment reportedly paid $15 million after a cybercrime group “managed to infiltrate and disrupt its systems.” The organization reported that the breach began in part when “a social engineering attack on an outsourced IT support vendor.” Last year, LAPSUS$ called an “organization’s help desk and attempted to convince the support personnel to reset a privileged account’s credentials.
The attack on Caesars Entertainment demonstrates why organizations need to harden their help desks. But talk is easy—developing security-first operations requires leadership support, technical and employee investment, training, and more. Importantly, while some of the more recent attacks targeted help desks specifically, it’s not that help desks are particularly susceptible to attacks, insecure, or high-risk. Quite the contrary: organizations need to bring security-first principles to every business process. They’re all at risk.
That said, Scattered Spider and ALPHV/BlackCat have put help desks in the spotlight recently. So let’s review some of the best practices that security teams and help desks can take and the questions they should ask to develop a Zero-Trust help desk.
Help desks (or service desks) are a standard part of the IT landscape in most companies. They serve a variety of functions, but oftentimes they’re the first point of contact for someone who can’t login to their computer or is having trouble accessing resources. To resolve those issues, the help desk may be able to perform some pretty high-risk actions, including:
- Resetting passwords
- Removing MFA for locked-out users
- Creating a new account
That’s just the start: help desk staff might be the entry point to perform some even riskier actions, like creating administrative accounts or temporarily removing MFA entirely to help deal with a system-wide issue. Even if help desk staff can’t take those actions directly, they may be able to open tickets for other groups that can.
It’s those actions that can make the help desk such an attractive target for an attacker: a help desk can suspend or circumvent security policies. Moreover, because organizations want their users and customers to remain connected, productive, and happy, it’s going to be easy for threat actors to find help desk contact information.
The good news is that, while help desk can represent significant risks, security teams can minimize those dangers by prioritizing identity, process documentation, automation, and developing defense-in-depth.
Start by getting to know your help desk: who staffs it? What do they typically do? What could they do? What do they have access to, and why do they need that access?
Every organization should ask how much access their help desk has to their environment. Security teams will need to review that answer regularly against the concept of least privilege. To get closer to zero trust, your help desk should only have access to the functions that they need to do their jobs when they need them. Wide-ranging administrative access for help desk personnel is a no-no.
A good arbiter of this is the help desk’s service catalog: support personnel should have the access required to execute those services and those services only. The security team should review whether help desk staff has more entitlements than they need, particularly for actions that could adjust a user’s identity security settings—and if they do, ensure proper controls around those entitlements.
Once you have a sense of what the help desk typically does and what they could do, ask to see their runbooks and process documentation. If they don’t have any, it’s time to write some, and review them for good security practices—including identity verification.
While you are at it, Security Teams should also emphasize that higher-risk identity actions should follow standard change management processes: actions like adding a new federation or a new tenant to your directory should follow stricter processes. If someone tries to begin those higher-risk actions outside of a normal process, then your security system should detect the attempt, alert security, and block it.
And don’t stop with the help desk team. While help desks can have a lot of latitude to assist users, sometimes they need to bring in another group to complete complex or risky tasks. If you have more than one group working together, make sure that every team knows what tasks require more than one function, who is verifying the request, and how to document it.
Cybercriminals will exploit any assumptions you make about which team is responsible for which action. If a VIP says it’s hired a new manager who needs admin requests immediately, how does the help desk receive that request, verify it, and coordinate with other teams? You need to check all assumptions to make sure that the request is coming from within your organization—and that you’re not helping out the bad guys.
Help desk employees need to hear from their leadership and security teams that they need to follow established processes, require documentation, and verify users—especially for exceptional requests—to maintain a secure practice.
Your help desk should know that the security and leadership teams have their back. It’s not just a technical or operational change—it’s a cultural value that leadership has to cultivate throughout an organization. Because it’s just as likely that high-risk requests will come from internal leaders, external VIPs, or threat actors who might contact your Customer Support team with an ‘urgent’ request to resolve an issue or gain some access.
In those situations, a help desk employee can’t always say “No.” Instead, cultivate the technology, process, and culture that will let them say: “Yes, and here’s what I need you to do to get that done.” Having those steps scripted ahead of time—and knowing that the leadership and security team will stand by the help desk when additional steps are required—might make the difference in preventing a breach.
It’s not just a top-down process, though: organizations should use automation when it makes sense to limit your exposure to manual processes or VIP pressure. Automation won’t be a silver bullet: your help desk may still need to respond to calls that ask for exceptions and either refer callers back to the automation or have an escalation procedure that requires trusted approvals.
Let’s say you’ve taken all the steps above: you’ve met with your help desks, understand what they can do, catalogued the higher-risk actions to prioritize, created documentation, and your leadership team routinely explains that your organization will always err on the side of security, even if it means inconveniencing a user.
The next question you need to answer is how your help desk or Customer Support team will verify identity? Authenticating the user’s identity is absolutely critical, because as well-designed or documented as your support security might be, it’s ineffective if someone on your team works to fulfill a request that a user is not entitled to.
Recently, visual verification has been nominated as one way of addressing phishing concerns. Organizations can review NIST 800.63A to see if the capabilities needed for “Superior” strength verification make sense for their situation. Given the technical requirements needed to get to independent visual verification and the training that your help desk need to implement this mechanism, this should be done with caution. Visual verification could still be susceptible to deepfakes, which are becoming easier to accomplish, if we are talking about a remote help desk that does not know the person making the request. Because of these challenges, I’m skeptical that visual verification will be implemented effectively in most situations.
Instead, organizations can use a traditional defense-in-depth approach and MFA to verify someone is who they claim to be. A well-formed request and verification method may begin with a single initial trust vector—such as a defined e-mail or login to a support portal—but should also integrate additional factors such as an out-of-band contact using a second trusted system. Methods to utilize an out-of-band contact could include:
- Manager approval: systematically verify the manager approves the access request in your ticketing system.
- Call the manager (for employee) or contact on file (customer) to have them verify whether the request is valid. A manager will generally have an out-of-band method to contact their employees.
- Have a conference call starting with the service desk employee and the user making the request. Then ask a third person to join the call—like a manager or team member—to visually verify the user and their request.
- To expedite approval, you could also substitute a peer or assistant pulled from the corporate directory to verify the request.
Any verification system can be broken, but combining some unrelated elements to validate identity before servicing a high risk request can help ensure that your help desk is hardened to most phishing attempts. In the examples given, consider how close or far in the technical landscape the elements are – for example, if you are a Microsoft shop using Active Directory, M365 for e-mail and Teams you may not want to combine those elements that are intertwined if you want the strongest MFA approach.
Another way to harden your help desk and other business operations against social engineering attacks like this is through identity proofing. We’ll have more on identity proofing soon—watch this space.
