Okay, hi everyone, Today we have another breach that I really want to unpack and discuss. This time it involves the Indian government and I don't mean one organization within the Indian government, I'm talking about really a huge breach that spans across multiple different state-owned entities. 

So in this video what I really want to do is just first of all outline just exactly what happened, what was discovered and the vulnerabilities that were reported. I then want to go through the step-by-step play that the attackers took and at the end of that I want to take a step back and just look at it high level, because the high level information we can use and translate that into our own organization. And then the last step I just want to talk about prevention. I'm not going to go into huge detail because cybersecurity prevention I can talk about for hours but let's just tackle some tools and some methods that we can use to prevent this particular attack and attack path. 

So let's get stuck in.

What actually happened during the Indian Government breach?

Well, this is another white hat attack from the group Sakura Samurai. Now this attack was spurred on because of the responsible vulnerability disclosure program that the Indian government has. This is called the NCIIPC. Now using this responsible vulnerability disclosure program they were able to legally attack and try and breach the Indian government, which they were able to do. 

In total a lot of information was found, including 35 separate sets of exposed credential pairs, three instances of very sensitive fil disclosure, five exposed private RSA keys, 13 000 PII records, dozens of sensitive police reports and forensic reports, discovered remote code execution on a financial server and then at the end a session hijacking of an application running on that financial server. 

So, a lot to unpack. So let's just start by looking at the initial step. 

Step One - Establishing a perimeter

Now the responsible vulnerability disclosure program that the Indian government had, outlined a list of domains that were covered under this. So using this they established their first list of targets. You know, their perimeter. 

Step two - Enrichment

Now the next step is to try and enrich this and really discover as much sub-domains as possible. So to do this, they use two tools namely Chaos and Subfinder and this really allowed them to enumerate each of these domains and find all the possible sub-domains that were listed under this. This gives us the widest possible perimeter. This led us to the first interesting information that we actually discovered and this is the police and forensics reports that were discovered in an open file directory on a subdomain that belonged to the Satara police department. Now I would still call this very much the reconnaissance stage of the attack. So finding sensitive information in this stage really kind of shows that it's probably going to be some interesting stuff that we're going to find as we go through the next steps. 

Okay, so the second step that they took, well they began to search their newly established perimeter including all the subdomains for assets. What we're really trying to do here is map out just the list of targets. To do this there's a number of freely available tools used. First one being Amass, this is to try and identify a lot of kind of assets and map that out. We use Nuclei which was to try and identify any vulnerabilities, particularly in infrastructure. Dir search and then Rust scan for some port scanning. So using these tools we can really transition from our perimeter into our kind of map of our assets that is going to be targeted in. 

Step three - Identify low-hanging fruits

This takes us on to the next step. What's the next step of the attack, well, this is to identify low-hanging fruits. What I'm calling low-hanging fruit, so if we take all the assets that we just mapped out. One easy way to try and penetrate a foothold into the organization, make that significant initial access, get lateral movement in, is to try and discover if there's any secrets exposed within this perimeter. So what are secrets? These are things like credentials API keys, security certificates, really anything that's going to provide me access into a system service or infrastructure. 

Now in this step the attackers found quite a large number of sensitive information. So we're gonna run through this really quick. But I won't go into too much detail. So first what they found was ten git directories that were accessible remotely but on the client-side that had hard-coded credentials within them. These belong to a number of different organizations within the Indian government. They were also able to find 23 exposed env files. .env files are environment variables. These are very regularly used to set up the environment of an application so often contain sensitive information. These make them a very high-value target for attackers. It's something that they would know to look out for. .env files, in this case, 23 exposed env files belong to a large number of different state-owned organizations. 

Moving along we find our first lot of PII. Now, this was actually exposed in an SQL dump. Now, SQL dump is essentially a backup of a MySQL database and this particular SQL dump was from the West Bengals Medical Service corporation application. This is a web application and the SQL dump comes from anyone that submitted a contact form on this application. So quite sensitive information.

Next, we have exposed client bash file. So the bash or command line, people often don't think that this is actually something that might, a record might be created of. Again high-value targets for attackers that they know to look out for. So in this case there was three instances of the bash history files that were discovered. Two of which contained hard-coded credentials into micro SQL databases. 

Next, we have five exposed RSA keys and these keys were giving access to servers. So again, very critical that these are private. These belong to five different organizations within the government and would have granted significant access for attackers to penetrate deeper into the infrastructure into the organizations. 

Almost getting to the end. We have another SQL dump. This time of 13 000 personal records on here. This one from the government's youth, the Indian youth employment program and finally there was one instance of an exposed wp underscore admin.php file. This is a WordPress application file. So could have led to takeover of our government's own website.

 So I want to point out now that I've come to the end of all this low-hanging fruit information. That we've discovered the idea behind this attack was not to penetrate as far as they can, to access as many possible systems as they can. The idea is to establish an attack path, identify the vulnerabilities of that attack path and then report back to the Indian government. 

Because of this, all of these low-hanging fruits, the majority of them weren't actually used. They didn't access into the databases they found the PII from SQL dumps, but they didn't find it from actually going into the databases themselves. So obviously we don't need to use too much imagination to know that if this is a malicious actor. 

Step 4 - Scan assets for vulnerabilities

Okay, now we have a huge number of different attack paths spanning from the low-hanging fruit. We can encrypt data and use it for ransom, we can launch spear efficient campaigns, we can squat inside systems, we can try and penetrate deeper into infrastructure, we can try and exploit some applications. A lot of different paths for this, for the purpose of this not necessary. 

Now, this brings us to the next step of the attack. Step four, which is to scan our assets for vulnerabilities. Particularly, we're looking for infrastructure vulnerabilities and to do this the attackers used a tool called Nuclei which was discussed previously and they identified a number of interesting assets that were potentially vulnerable to an exploit, but they decided to focus their attention on one such asset, that was of particular and kind of significance, which was a financial server prolonging to the government of Kerala. So needless to say that having a financial server with vulnerabilities is very compelling to attackers, to say the least. So the attention was then moved to try and exploit this and again prove their methodology more than anything else. 

So how do they do this? Well, this particular server was running a vulnerable version of a tomcat Apache server and this was actually vulnerable to a known exploit that allowed remote code execution. So being able to just download that exploit which had been disclosed, they ran it and successfully were able to see that they could execute code remotely on this financial server. Obviously a significant win for the attackers.

Final step - Transition from infrastructure to an application

After they had successfully proven this, we moved on to the final step of this attack. This final step is to try and transition from infrastructure to an application. Now again, they've limited their focus as narrowly as possible, again just to prove the methodology and this was to target the main application running on this financial server. To do this they were able to really access deep into the server and find a list of authenticated users and their session IDs. 

The application in question was a java application and java applications very commonly use a Jsession ID cookie to authenticate users because they had access into the server and were able to see a list of authenticated users. The attackers randomly selected a user, took their ID and created a new session cookie, a Jsession ID cookie. After creating this cookie they were simply able to access the web application as if they were a correctly authenticated user and be able to perform all the tasks that any successfully authenticated user could do within the panel. Now, if this was a real attack then you would probably want to try and find specific users with the highest level right, super admins and access their session IDs. In this case, they just selected a random person because again the purpose was to prove methodology and not actually cause damage but they were able to take over and perform all the tasks that any authenticated user could do, which is the final step of the attack. 

Okay, so we've come to the end and as you can see there was a huge amount of vulnerabilities within this. That's partly because we're looking at such a wide perimeter but I think in total there was a 34-page report with vulnerabilities that was presented to the Indian government. But if we take just a step back here, what we can really see is a very clear path that the attackers took and this is interesting because we can take this exact same path on our own organizations.

Summary of the methodology used by the Sakura Samurai group

We can see how we would have held up against this exact attack by Sakura Samurai. So let's just take a look at that without all the information what was the methodology used. 

Well, step one, they established a perimeter. They did this using the responsible vulnerability disclosure program creating a list of domains but it's easy enough to do this for an organization. All the domains your organization knows it could be all your employees and their publicly accessible information maybe their git repositories. The first step is really establishing that perimeter and then using that to enrich it to find the most amount of information. We can talk about subdomains directories file, directories, anything that is exposed publicly. 

Now, once we have that mapped out we come to the second stage of the attack which is to try and identify all the assets we want to identify. Servers we want to identify. Our git repositories, really anything that we can focus our attention on. 

The next step is to identify the low-hanging fruit. How can I penetrate into the organization deeper with the least amount of sophistication? Well, a good way to do that is with credentials and if we have a wide perimeter and we've identified a lot of publicly accessible assets chances, are we're going to be able to find some credentials within this? That's going to give us some lateral movement. 

Next step, let's take our assets and scan them for vulnerabilities. Now, in this attack that we just presented, it was infrastructure that was really targeted and this will be true in any attack but we can also look at applications. We can look at the dependencies of those applications. Simple enough to discover what dependencies an application uses and if those dependencies in the current versions are vulnerable to any exploits. The last step is we want to transition. Our ultimate goal is to take over an application or get as high level as we can or authenticated within an organization. To do this we can move from infrastructure that we've compromised into applications and this gives us the most amount of control. If we can penetrate into an organization and take control over both their infrastructure and their applications well, then happy days if you're a bad guy.

Let's now talk about breach prevention

Now, the good news is that, well, a lot of this we can stop. We can clean up a lot of our perimeter to make sure that all that low-hanging fruit isn't available. Really reduce the number of attackers that would be able to penetrate the system to as close to zero as possible. Although we all know in cybersecurity, zero risks is not possible. 

But let's start by identifying our own perimeter. It's what the attackers did and that's what we should do within cybersecurity teams and organizations. Identify all the assets that we have and they start by doing that. We need to identify our perimeter, really have that we can use a couple of tools. 

For this, we can use the same tools that the attackers used. GitGuardian can also help establish a perimeter outside of your company so there are risks such as employees git repositories. We really want to make our perimeter as wide as possible and there are some cool tools that we can do that. 

Now the next step is to scan this perimeter for the low-hanging fruit. Things like credentials. GitGuardian is a great service, that's free for most teams that can identify credentials within your git repositories. But on top of that we also probably want to have in place some good credential management. If we find anything, consider using something like Hashicorp vault. It's infrastructure-heavy. It requires a bit of setup but there are other tools available if we're in a smaller team.

 We also want to make sure that we have a mitigation strategy in place. What happens when a credential leaks very often if it's in a git repository, it's deleted and forgotten about, but attackers know that the git history contains a drive of information, even the batch history was used in this case. So it's not good enough just to delete something and hope no one finds it, we need to really clean this out. 

So what's the mitigation strategy that we have in place if a credential is leaked. Well, it needs to be rotated. Who's the people that do that and who owns each credential or each secret, these are things that really we want to have mapped out as part of our message mitigation strategy and watch. 

The next one is patch vulnerabilities. I know it's simple and it's something that you'll hear forever. Patch regularly not just our applications but our infrastructure our dependencies. We can use great tools for this. Nuclei was used to discover vulnerabilities in this attack but consider Snyk, great tool, again free for most organizations. It can identify vulnerabilities in your application's dependencies. Really important steps to take. 

There's a number of other tools that we can use and runtime tools that we can use to try and identify these attacks but I don't want to go too much down a rabbit hole. 

But what I will say is that while if you're wondering how you should secure your application or organization or if you're wondering how it would stand up from an attack, well here's an attack path and a methodology that we've outlined. Why don't you consider using this exact methodology and the tools that we use to try and penetrate into your organization. See if you have any low-hanging fruit see if you have infrastructure vulnerabilities that can be exploited so you can move into your application. It's not the only way but I think it's a really clear way that you can make progress into trying to assess whether your organization or application is secure.

Well, that's it for today. If you want me to analyze another particular breach or go into detail about something else, let me know in the comments. I'm always happy to have a discussion or if you disagree with anything that I said here today then also let me know, I'll be fascinated to hear your thoughts.