This is another attack executed by the white hat hacking group Sakura Samurai however what makes this breach in particular so interesting is the multiple state-owned organizations that were affected. In total, 26 different government departments and organizations were compromised. This post aims to provide a play-by-play breakdown of exactly how the attack unfolded, review the methodology the attackers implemented and the tools that were used throughout.
Exactly what happened
Sakura Samurai were attracted to the Indian government after it was discovered they have a responsible vulnerability disclosure program (RDVP) called the NCIIPC. This RDVP gave the group a list of domains where they could legally try to exploit.
In total what the attack uncovered was:
- 35 separate instances of exposed credential pairs (providing access to government systems)
- 3 instances of sensitive file disclosure
- 5 exposed private-key pairs for servers
- 13K+ PII records
- Dozens of exposed sensitive police reports
- Session hijacking chained via multiple vulnerabilities
- Remote code execution on a sensitive financial server
It should be noted that the goal of this attack was to establish an attack methodology and prove it can be effective. The vulnerabilities exposed through this attack are critical and attackers could have easily persisted however, Sakura Samurai stopped short of penetrating too deep within the government to prevent unnecessary data exposure or damage to infrastructure. However, It doesn’t take much imagination to be able to see the huge potential damage any malicious actors could have created, had they used the same attack path.
Play by Play
Let's break down this attack into steps so that we can get a clear understanding of the exact path the attackers took, including tools used.
Step 1: Established a Perimeter
The first step Sakura Samurai did was establish a perimeter using the domains listed in the RVDP, and that the group was legally able to test. Using the tools Chaos and SubFinder, the group began identifying subdomains within the perimeter to establish a full list of potential targets.
The first item of interest discovered by this method was a subdomain belonging to the Satara Police Department website. It was shown to have an exposed /files/ directories. This directory contained multiple police reports and even forensic reports that were highly sensitive.
Step 2: Searched perimeter for assets
The group then continued their subdomain enumeration on their perimeter using a variety of tools, namely asset identification with Amass, web application fuzzing with dirsearch, port scanning with RustScan, and vulnerability identification with Nuclei. Through these tools, the group was able to discover multiple .git directories on the client-side that allowed external access.
Step 3: Identified low hanging fruit vulnerabilities
After identifying multiple assets, the group began scanning these for low-hanging fruit vulnerabilities, namely secrets (such as database credentials or API keys). It is here where Sakura Samurai was able to find a huge number of vulnerabilities that were available for exploitation. This includes:
10 exposed .git directories that contained hardcoded credentials for multiple servers and applications including MYSQL, SMTP, PHPMailer, and Wordpress
Hardcoded credentials were discovered inside git directories belonging to:
- Government of Bihar
- Government of Tamil Nadu
- Government of Kerala
- Telangana State
- Maharashtra Housing and Development Authority
- Jharkhand Police Department
- Punjab Agro Industries Corporation Limited
23 environment (.env) files containing credentials for SMTP, MYSQL, REDIS, SMS Services, and Google Recaptcha keys belonging to a long list of government agencies.
Environment variable files with credentials discovered belonged to:
- Government of India, Ministry of Women and Child Development
- Government of West Bengal, West Bengal SC ST & OBC Development and Finance Corp.
- Government of Delhi, Department of Power GNCTD
- Government of India, Ministry of New and Renewable Energy
- Government of India, Department of Administrative Reforms & Public Grievances
- Government of Kerala, Office of the Commissioner for Entrance Examinations
- Government of Kerala, Stationery Department
- Government of Kerala, Chemical Laboratory Management System
- Government of Punjab, National Health Mission
- Government of Odisha, Office of the State Commissioner for Persons with Disabilities
- Government of Mizoram, State Portal
- Embassy of India, Bangkok, Thailand
- Embassy of India, Tehran
- Consulate General of India
An SQL dump from the Government of West Bengal’s Medical Services Corporation Application contained the personal information of anyone who filled out a contact us form.
There were three instances of exposed client-side .bash_history files that were discovered, two out of the three files exposed passwords for the local databases.
.bash_history files containing database credentials belonged to:
- Government of Kerala
- Government of Maharashtra
5 exposed instances of private RSA keys that provided access to multiple different servers.
Exposed RSA keys belonged to:
- Government of Kerala, Service and Payroll Administrative Repository
- Government of West Bengal, Directorate of Pension, Provident Fund & Group Insurance
- Government of India, Competition Commission of India
- Government of Chennai, The Greater Chennai Corporation
- Government of Goa, Captain of Ports Department
Another SQL file resulting in the dump of 13,000 PII records from the Government of India’s youth employment program.
Screenshot of exposed PII discovered
One additional set of database credentials were discovered via an exposed wp-config.php file on the client-side, affecting the Government of Manipur’s Department of Agriculture.
Now at this point, it is important to note that there was a huge amount of sensitive information found. As I said at the start, Sakura Samurai did not want to penetrate further into the systems beyond what was needed to prove the methodology. The group decided not to access most of the databases and applications credentials were discovered for as it was deemed outside of scope. But the amount of credentials they discovered alone, would have given them a huge amount of options to persist the attack and move deeper into the infrastructure. Had they been malicious there are multiple options, for data ransoms, account manipulation, account creation, exploitation through PII….. Really any number of possibilities.
Want to know what the most common file types expose sensitive data? Checkout our post File types that most commonly contain sensitive information.
Step 4: Scanned for known infrastructure vulnerabilities
Once they have identified assets, including infrastructure, then the next step Sakura Samurai took, was to find known exploits that could grant them access to infrastructure. The group identified multiple different attack vectors during their scanning, however, they specifically decided to focus on one of the most interesting in order to test their methodology, this was the Government of Kerala’s Local Self Government’s financial server.
In this case, the group discovered the server was running a vulnerable Apache Tomcat Server that had a known exploit available for remote code execution. After investigation, they were able to run an exploit that enabled them to successfully run commands remotely. It goes without saying that this level of control enables attackers multiple avenues to continue.
With the ability to execute code on the vulnerable server, they used local enumeration techniques to discover a backup folder containing archived financial records.
Step 5: Used known exploits to transition from infrastructure to applications
At this point, Sakura Samurai had proven their attack methodology and begun the reporting process. They did a final exploit to solidify the criticality of their attack which was to transition from infrastructure into a running application. While there were multiple options to penetrate deeper and infiltrate more sensitive systems, the group limited the scope to the main application running on the financial server, aiming for a user session takeover. With the server’s configuration containing the management credentials, they were able to use the credentials to find a list of active users for the application. The group executed an instance of session takeover by abusing a commonly used session cookie in the java web application, the JSESSIONID. This session cookie was created by selecting a random user's ID to successfully authenticate to the financial servers’ web application. While within the web application, they could see financial proceedings and even had the ability to submit or edit anything within the panel on behalf of the user’s account that was taken over.
Upon finishing the attack, Sakura Samurai presented the Indian government a 34-page report of vulnerabilities, with the help of the US government's own disclosure program.
Reviewing the methodology
Now… We have come to the end of the attack and I know this is a lot of information to process, even in an abbreviated format. But if you take a step back and strip all the information to find out just the absolute basics of what happened, we can really see the path that the attackers took.
- Step1: Establish a perimeter
- Step 2: Identify all assets within the perimeter
- Step 3: Scan for low hanging fruit such as credentials
- Step 4: Scan for known vulnerabilities on identified infrastructure
- Step 5: Exploit vulnerabilities to penetrate into infrastructure
- Step 6: Chain multiple vulnerabilities together to pivot from infrastructure into applications
- Step 7: Establish persistence and ability to perform further sensitive action
This isn’t an unusual path to take, in fact, this is an almost identical methodology that Sakura Samurai previously used to breach the UN. But this clearly shows key areas organizations can use to protect themselves against such attacks in the future.
When we discuss prevention in cyber-security we run the risk of entering into a black hole that can seem very daunting and ultimately outside the scope of this article to go into detail. But if we take just the key moments from this attack we can draw some interesting conclusions.
What is important to keep in mind is that while this attack was carried out extremely well, it quite low in sophistication, at least in terms of infrastructure attack vectors used. This means that this methodology or attack path is available to a very wide range of hackers.
Prevent external access to assets
The first foothold the attackers gained was through remotely accessible directories including .git and file directors. Client-side directories of value should not only prevent remote by allowing internal facing IP addresses where acceptable, access to them but should also contain multiple layers of authentication.
Scan your own perimeter for secrets
A key moment in this attack was then extensive discovery of secrets (credentials) the attackers were able to access. Many of which were hardcoded into source code and buried in git directories. This shows a clear need for organizations to adopt similar practices on their own perimeter to prevent secrets sprawl. Consider using GitGuardian on your perimeter to locate such secrets.Set up scanning on your perimeter
Regularly patch for known exploits
Patching regularly can seem so obvious that it is often overlooked. Keeping systems up to date takes away an easy path of exploitation for attackers. This should include infrastructure, applications and also application dependencies running in your applications. Consider implementing tools such as Snyk for detecting and updating dependency vulnerabilities.
This was a massive breach into the Indian government that spanned multiple different entities. However the attack itself followed a well-proven methodology that is of relatively low sophistication, this makes it accessible to the widest range of hackers. The attackers established a perimeter and then took additional steps to discover assets, vulnerabilities to exploit. Luckily there are multiple ways we can strengthen our defense to protect ourselves against such attacks including preventing external access to assets, scanning a companies perimeter for secrets, and patching infrastructure and applications regularly.