SecOps professionals have historically focused on two types of people: insiders and outsiders. With the advent of what some call the “Gig (or flex) Economy,” however, we increasingly have to deal with a third type of person: the contractor.
The security risks posed by contractors are escalating for three primary reasons:
- Growing use of contractors. Business leaders are trying to optimize their agility in the face of market volatility by using freelance workers on a temporary basis, rather than onboarding full-time employees. The current hiring shortage has exacerbated this problem. An Oxford Economics study recently reported that 83 percent of executives worldwide who were surveyed reported increasing use of contingent, seasonal, and contract employees.
- Less rigorous controls. Organizations rarely put their contractors through the same kind of security training as their employees, nor can they always put the same restrictions on contractor behavior (e.g., insisting that devices used for access to company resources not be used for other purposes). Also, most organizations don’t vet their contractors as thoroughly as they do their employees – with fewer background checks happening during the onboarding of contractors.
- Immediate direct access. When a company hires a contractor, it usually needs them to be productive right away. In a digital world, this immediate productivity almost always requires immediate provisioning of direct access to one or more enterprise systems. And as your organization uses more contractors in more different roles, those contractors will be given rapid access to more systems.
Contractor access, in other words, is no longer an exception to the rule. It has become a new rule. Or to put it more precisely, a new set of rules that we all need to learn to play by.
A (Problematic) Case in Point
As part of the Secureworks Counter Threat Unit™, and more specifically the Secureworks Adversarial Group (SwAG), I recently had a direct confrontation with the contractor conundrum when the SwAG team was engaged by a large wholesale distributor. The distributor was using a large number of contractors and was rightly concerned about the risks associated with giving so many non-employees access to its internal applications and data.
We actually started the pentest from a system on a segment used by corporate employees, where we found several high-severity issues such as weak passwords and Active Directory misconfigurations that led to organization-wide compromise. Basically, we were able to get password hashes from a domain controller—and then crack about 70% of those hashes using a Secureworks tool affectionately known as with “The Kraken.” Read more about that beast here.
With hundreds of cracked credentials in hand, we scanned the distributor’s Active Directory for groups containing the keyword “contractor” keyword. And voilà! All of the contractors were members of a group named "Dematic Server Local Admin."
But here’s the worst part: Every member of that contractor group had been granted local administrative access to a shared virtual machine. Yikes!
The next step was to use credentials from one of those contractor accounts to jump onto the shared VM. That VM was running some security in the form of antivirus and EDR—but neither of those measures blocked us when we ran a memory dump. And that memory dump yielded the password hash of a local account named "nt_admin."
We tested this “nt_admin” account against the distributor’s other systems and discovered that it was being used all over the place—including their crown jewels (otherwise known as their domain controllers).
Bingo! Within about twenty minutes, we had compromised every domain-joined asset across the distributor’s entire environment via a contractor account.
In other words, the distributor’s worst nightmare was also a reality.
Lessons Learned
There are three sets of lessons we can learn from this example about staying safe in the “flex economy.”
The first set of lessons are the specific errors that the distributor made—and that we all should avoid. These include:
- Never give users (contractors or otherwise) local administrative access, especially not to a shared system.
- Never re-use passwords for local admin accounts. In fact, you should specifically disable those passwords to ensure that no one accidentally re-uses them.
- Utilize multi-factor authentication on security-critical systems such as domain controllers to ensure that they can’t be compromised with a mere password/credential exploit.
- Enact identity controls for contractors and ensure that your security solutions are capturing telemetry from contractor endpoints.
The second set of lessons are more general. They entail the need to rigorously apply the full range of cybersecurity best practices to contractor authentication and access control, despite the temptation to cut corners due to common rationalizations such as “We’re only giving them access to Salesforce and Slack” or “I get grief if we can’t on-board a new contractor within the same business day.”
There is literally no good reason to expose your entire organization to an existential cybersecurity risk. So don’t do it no matter what.
The third set of lessons boil down to one core principle: Good cyber defense requires great cyberoffense. If you don’t test your cybersecurity assumptions against a skilled adversary, by choosing the right penetration testing partner, you’ll never know how vulnerable you really are. It doesn’t matter how much money you’ve spent and how smart you think you are. There’s no rational reason for you to be confident in your security posture if you haven’t tested it against our SwAG team. Plus, you can use the lessons you learn from an adversarial engagement with us to make your organization even stronger and more attack-resistant.
And in today’s gig economy—where a breach can cost your company revenue, customers, damage to its brand value, and even regulatory consequences—that’s not just a nice-to-have. It’s an absolute must.