Your Next Job Applicant Could Be Hacking Your AWS Account

As if hiring programmers and getting hired as a programmer wasn’t screwed up enough right now.

Imagine you are hiring for a mid-level developer position, and you ask for code samples, perhaps you even offer up a specific challenge. You get a couple of hundred submissions, and a small fraction of that actually follow your instructions to submit the code challenge.

You then go about evaluating each of these submitted code solutions until you get to one that has a bytearray in it. It seems odd, but you go ahead and run it to see what it does….

What you don’t know is that a malicious party posing as a job candidate just got you to run a malicious payload on your computer. That is exactly what is happening right now.

This tactic of obfuscating malicious code with something like a byte array is NOT anything new.

I can remember reading about how this is done with PHP as early as 2008, and have encountered it plenty of times in the wild, most commonly with JavaScript for an in-browser attack.

What I had not seen until now is using this attack while posting as a potential job candidate.

I actually could see a vector of attack using something like this to grant the malicious party access to the hiring party’s AWS account.

Let’s say the engineer in charge of evaluating the maliciously submitted code sample downloads and attempts to run the malicious code locally. Perhaps they don’t bother to sandbox it with something like Docker. Why go through the trouble right (I am being sarcastic, you 100% should sandbox it)?

This means that any code run on their system, not sandboxed, could access the ~/.aws/credentials file and could make calls on the evaluating engineer’s behalf to the hiring business's AWS account.

All the malicious party would need to do is send that credentials file to an endpoint they have on the web, and they would have access to your account as if you were the engineer tasked to evaluate the maliciously submitted code.

What can you do?

Be careful when running code submitted by 3rd parties. Just because someone is applying for a job does not mean they are not a malicious party, especially in the modern, remote work world we live in.

Before running the code, look to see if there is any obfuscated code. If there is either don’t run it or un-obfuscate the code so you know what it is. In reality, know what all the code does before running it, obfuscated or not.

If you are going to run it, find a way to sandbox it, don't give it local filesystem access, probably don’t give it internet access.

Use tools like IAM Identity Center to make sure your IAM creds have a TTL, so if they are leaked, they will be rendered unusable within a few hours.

This vector of attack is even more sad because it makes it tougher for people hiring developers, and therefore makes it tougher to get hired as a developer.

If you employ software developers and want to avoid issues like this, you should check out the Schematical Group Coaching Community, where you can get coached on the best practices for evaluating your potential hires’ skillset.