Phishing attacks are getting more sophisticated by the day. Their target audience is changing every day. In the past, high-profile individuals were targeted using CXO attacks. These days, the scope has broadened and is targeting the whole organization.
It is not just a rushed email from your CEO with links to a website that tries to steal your login credentials or make you download malicious software.
Attackers are getting way more creative to target people and who they are targeting. Very recently, I encountered an interesting approach to phish a Developer.
The Attack
The Developer was doing freelance work on the side, which was nothing uncommon. They got a request on a platform to help someone with a problem in a code base. After reviewing and accepting the job, they got access to the repository with instructions on getting it going and what error they would experience.
The developer went through the Readme, cloned the repo, installed the dependencies, and ran the setup commands. Nothing out of the ordinary and a very common approach. The developer ran into an error, tried a few things to fix it, and eventually dug deeper.
That’s when they discovered some obfuscated code that would run upon setup. If the developer didn’t use the latest version of the Language, they probably wouldn’t have noticed.
As they dug deeper into the codebase, they discovered it contained Malware. It would connect to a remote command and control (C2) server and upload the clipboard, browser data, and a lot more. I will go into more detail later.
The developer immediately took the machine off the network, informed the security team and changed all of their passwords. The blast radius on this was quite big. All credentials this person had access to needed to be rotated. All direct and adjacent systems must be checked for access, abnormal behavior, or anything unusual. It took the team significant time and work to cover all grounds. Which is quite normal with the complexity of things we tend to build.
The Reveal
The malicious actor found a very good way to target developers effectively. So effectively that they are operating at a 90% + success ratio. The attackers can make sure the code is run in the best possible environment without needing to scout. Essentially, they can write a full profile of what is required, and their victims come their way 🤯.
There is no need for fancy zero-day exploits or relying on other weaknesses within the target system. They can even get full root access by asking for it. Everything happens voluntarily and in plain sight.
The Shield
How do you protect yourself, your team, and your company from this kind of attack?
Education is the most effective and best prevention. Security always starts with the people. Technology is there to assist and aid them. A person not educated in or willing to follow security principles will not be saved by tooling (for the most part). If you and your teams don’t know how to identify and spot these kinds of threats, it is hard to protect yourself.
How could this have been avoided?
First, if something happens, ensure people can bring up when they think they got targeted or even hit by an attack. Do not push them into keeping it a secret by punishing them for wrongdoing. Be kind and empathic; don’t patronize. IT Security is intimidating and scary. Most people do-not like to make mistakes. Even fewer want to have to report that they made a mistake.
Have clear policies in place. What is allowed and what is not. Is it okay to do freelance work on the side? Can they do it on their workplace computer, or is this a strict no-go? All of this depends on the company, business, the risk appetite, and the culture. There is no one-size-fits-all set of policies.
It also helps to have some (technical) guardrails in place that protect, prevent, or reduce the impact:
- Ensure no admin access to the computers without passwords
- Use managed browser profiles to ensure passwords are not stored etc.
- Use single sign-on wherever possible, ensure everyone is using a password manager, and the second factor is not managed in the same password manager.
- Do not have permanent access to any live system, especially not with privileged accounts.
- Keep any application secret in a dedicated secret store like HashiCorp Vault etc.
- Have a good inventory of your secrets. This allows for faster rotation when required.
- If possible, have some intrusion detection and mobile device management systems in place
The Malware
What did the malware try to do?
In this case, it was a 3 part malware. The first part was a JavaScript script hiding in a test runner. It was obfuscated/minimized and hard to reverse engineer. From what we identified, it tried to contact a command and control server to download further instructions and invoke the second and third parts of the malware written in Python.
The second script would:
- Grab the contents of the clipboard.
- Get the browser history, sessions, and stored data (form and passwords).
- Look for password files, SSH keys, keyrings, and all kinds of files.
And upload all these files to a C2 server.
The third script would establish itself within the system for later use. All 3 scripts talked to different C2 servers.
The codebase was based on an open-source tooling that was modified. Variations of this attack can be found on GitHub in plain sight.
The TL;DR
A developer got tricked into cloning some code that included malware to steal credentials, crypto wallets, and more. They did the right thing to take the machine offline and inform their security team. The most important thing to prevent attacks like this to educate and teach your team, set out policies to prevent them, and put the right tooling into place to do damage control.
Need help with securing your Kubernetes deployments? Lets chat: andy@occamslabs.com
Andreas likes security, enabling teams to ship secure products and coffee.