About this series
Last time, we covered a scenario in which a threat actor found leaked RSA private keys used by a TLS wildcard certificate for “Poor Corp.” By chaining the leaked private key with DNS misconfigurations, the attacker was able to impersonate a Poor Corp subdomain and use it to create highly effective phishing emails.
In this series, we will dissect not just what an attacker can do to get access to credentials, but also what they would do after getting that initial access. We will walk through a different threat scenario in each part of the series and tell stories of malicious hackers that are either true, based on a true incident, or reasonably theoretical.
Underestimating private git repositories
This time, we are exploring a real-world data breach that happened to another “Poor Corp.” This attack begins like many other breaches: with a successful phishing attack.
The threat actor in this scenario has been sending out phishing emails in a large campaign, and they’ve started to rack up a lot of credentials. As new credentials are coming in, the malicious hacker notices that they successfully phished someone at Poor Corp, a large, well-known company. The hacker does some OSINT (Open-Source INTelligence) gathering on the employee that they successfully phished, and they discover that they have the credentials of a Poor Corp software engineer.
The first thing the hacker does with the software engineer’s credentials is discovering which of Poor Corp’s services they can access. While masquerading as the software engineer, the malicious hacker discovers that their stolen credentials can log into Poor Corp’s GitHub organization. Poor Corp has several open-source repositories, but our hacker is more interested in what they couldn’t access before: private repositories.
To get a local copy of the codebase, the hacker clones all of Poor Corp’s private repos. Then, they use an open-source tool like Gitleaks on each repo to see if they could find any valid secrets. Unfortunately for Poor Corp, their software engineers hadn’t given their internal code as much scrutiny as their open-source code, and our hacker found AWS keys hard-coded in a few private repos.
AWS data exfiltration and extortion
With the AWS keys that were in Poor Corp’s code, our hacker was able to access a service that handled computing tasks for Poor Corp’s major SaaS (Software as a Service) offering. Inside that service was an archive of Poor Corp’s customer information – and not a small amount, either. The service contained the personal data of about 7 million of Poor Corp’s customers.
With this much personal information, the malicious hacker decided they could extort Poor Corp by stealing the data and blackmailing them. After copying all the data from the AWS archive, the hacker sent an email to Poor Corp. The email said that their customers’ data would be leaked unless Poor Corp paid the hacker. Luckily for the hacker, Poor Corp had a bad reputation for shady business practices, and they decided to buy the hacker’s silence for $100,000.
Poor Corp covered up the incident, and the hacker was able to get away with the extortion. It wasn’t until years later that the breach was finally disclosed publicly. By that point, our hacker was long gone, and all evidence was erased.
Lessons learned
The first takeaway from this real-world data breach is the importance of controls that provide resistance to phishing attacks. Phishing training programs can help, but it’s even more important to have technical controls in place that can limit the impact of a successful phish.
In this scenario, if Poor Corp’s software engineer had MFA (Multi-Factor Authentication) set up on their GitHub account, the hacker probably wouldn’t have been able to access Poor Corp’s private GitHub repos. Alerting on uncommon login properties (location, device, etc.) also could have tipped off Poor Corp that their software engineer’s account was taken over.
Phishing is the most common initial access vector for any data breach, and the harder you make it for attackers to take over your accounts, the sooner you can prevent or detect a breach.
The second takeaway from this attack is that private repos are just as important to secure as public repos. Poor Corp got lazy with their code hygiene in their private GitHub repos, and it was probably because they thought only their employees’ accounts could access them. But as soon as one of their software engineers was phished, that exposed their repos to someone outside of their organization with bad intentions.
Lastly, this scenario highlights the misconduct of Poor Corp in covering up the data breach. Even though they paid off the hacker to not leak the private data of their customers, Poor Corp still had no guarantees that the data wouldn’t be misused or leaked eventually, and their customers deserved to be warned.
It never reflects well on a company when a data breach like this happens, but it’s even worse when the company tries to cover it up and leaves its customers even more vulnerable. Luckily, government organizations are taking action to improve the state of data breach reporting. However, it ultimately falls on business leaders to recognize the importance of disclosing cyber-attacks and take action.
How can Poor Corp enhance its security posture?
It’s easy to think that it’s only important to scan for secrets in your public-facing repositories, but this real-world data breach proves that you need to treat all code the same from a security perspective. Malicious hackers can use open-source tools like Gitleaks and TruffleHog to quickly detect secrets in massive amounts of code*, without leaving a trace. As a defender, **it’s extremely important to have secret scans tightly integrated into your SDLC* (software development lifecycle) to reduce the risks of exposing them. GitGuardian offers secret scanning for private repositories in their Free, Business, and Enterprise plans.
GitGuardian has also recently introduced an open-source tool that defenders can add to their arsenal, ggcanary – the GitGuardian Canary Tokens. Security engineers should use it to plant fake AWS secrets in their internal perimeter (private repositories, CI pipelines, Jira tickets, etc.) to detect intrusion as soon as hackers attempt to exploit them.
Top comments (0)