So, the United Nations environment program recently had a fairly significant breach with over a hundred thousand employee records being accessed. 

In this video, I want to talk about exactly what took place, how the hackers were able to gain access to these records and why. And I also want to evaluate the attack over the MITRE ATT&CK framework so that we can analyze exactly what happened and where the vulnerabilities and individual exploits took place. 

What actually happened during the United Nations Data Breach?

Well, this attack was conducted by the ethical hacking group Sakura Samurai and they were able to take over a number of databases internal systems and also gain access to private password-protected git repositories. They did this because the UN has a vulnerability disclosure program and also a hall of fame. 

Now I find this attack interesting for a number of reasons. One, it didn't use complicated and expensive infrastructure to launch the attack and also didn't come with a high level of sophistication in terms of how the exploits were conducted.

But had this been a malevolent actor or a bad actor using this, well, the results could have been really quite severe. 

What were the different phases during the Environment Program Data Breach?

Well, the first thing that the attackers did was they set up a perimeter containing all of the domains that were covered under the vulnerability disclosure program.

The UN has a large number of organizations within it, so identifying this perimeter was the first step. 

They then start fuzzing each and every one of these domains to try and identify subdomains and any root-level directories that they could gain access to. They were able to access a .get repository on one of the subdomains belonging to ilo.org, the international labor organization. Using a tool called git dumper, they were able to download the entire contents of this git repository and scan for vulnerabilities. They were able to identify hard-coded credentials that were used in this, that gave them access and allowed them to take over a MySQL database belonging to a WordPress application and also an internal survey management platform. 

Now, these in itself are really quite big vulnerabilities and could have large ramifications in this exact attack though this is perhaps some of the more less interesting items that were discovered. 

Following on from this they were able to enumerate each and all the other endpoints that were identified before ultimately being able to find a GitHub access token in one of the subdomains. 

Now anyone that's worked in large organizations will know that git repositories, particularly private git repositories, contain a huge amount of sensitive information, so these are very high-value targets for attackers and this was no exception. In this case, the attackers were able to find seven sets of credentials gaining them access to multiple different databases. They also found backups of these databases within the repository itself. Once they identified that these backups contained a lot of PII, Personal Identifiable Information, they decided to stop the exploit. 

This is because they had already discovered the vulnerability and showed that in the end they can use it to find sensitive information and there was no point continuing on. 

What's interesting though is that this exploit could have continued on, in a number of different ways. They could have used the PII to do phishing campaigns or create accounts. They could have accessed the databases, elevated privileges, changed accounts, deleted data, or they could have just remained hidden and squatted in the git repository transferring information or even trying to insert malicious segments of code, depending on how the git repository was set up. 

So you can see that a malicious actor could have really continued this attack and gained significant lateral movement deeper into the UN organization. So although the outcome of this wasn't terribly bad the implications of it really could have been. 

Looking at The United Nations breach through the MITRE ATT&CK framework

So what I want to do now, is look at how this attack unfolded through the MITRE ATT&CK framework. Now if you're not familiar with the MITRE ATT&CK framework. It's a fantastic tool that we can use to really analyze what happened after an attack took place. So ATT&CK is actually an acronym: Adversarial Tactics Techniques & Common Knowledge. I feel like they really nailed it with that acronym. 

But let's go through from start to finish at how this exploit took place. So we can see here, in this very first segment, reconnaissance, well, really this is something that the attackers were quite active. They did active scanning, they gathered victim host information, they gave victim identity information, they gathered the victim organization information, they searched for technical databases that were open, search for open websites and domains and search for victim-owned websites. So really you can see that they did a good job in the reconnaissance. 

Here really understanding how the UN structure was put together and where everything was so resource developed. How did the attack, how did the attackers kind of develop resources along the way?  Well, as I said during explaining this, it was a pretty low-cost attack in the sense that they didn't need to really acquire infrastructure to perform it. Yes, they compromised accounts. It didn't really compromise infrastructure. You could argue that they could have or perhaps the databases that were but I want to say no, for this, they didn't really develop any additional capabilities that they had. But they did establish accounts and what was the initial access. 

Now, this is kind of where the exploit really started to gain traction and we're going to see this a lot as we go through this framework. At this point here, initial access, they had valid accounts. It's really hard to detect something that's properly authenticated. Now, I don't mean to say that there's no way that you could have prevented this after they gathered credentials. Of course there is, but this is going to be the telling story of this. They had valid accounts, they gained access to valid accounts. Now execution, this doesn't really fit into this. I mean you could kind of make it fit into some of this. I guess you could say that git is a software deployment tool and therefore... But because the attack was stopped I really don't feel like any of these actually fit, although of course, we could argue that if the exploit continued there's a number of execution techniques the attackers could have done. 

Persistence and this here is going to be telling too. So what clever systems did they use to persist the attack, to go undetected? Well, they had bound accounts. That's really the only one that really really fits into this. Of course, they could have created some accounts and here we can see they could have done account manipulation.They could have done a whole number of things. They didn't really partly because it didn't need to, partly because they didn't want to extend the exploit longer than it needed. But persistence, oh they had valid accounts privilege and escalation. Really the same thing again, could have created accounts, could have modified stuff but they didn't need to because they had valid accounts. They were correctly authenticated within the systems that they were using. 

Defense, defense evasion. So guess what, guess what's happening in this one. This is a huge list because there's a lot of very clever ways that attackers sometimes need to go through to evade being detected but in this case, they had valid accounts. They did use alternative authentication material when they were kind of moving laterally and going into the git accounts. But there wasn't enough setup on the UN where they had to really try and hide them. There wasn't any two-factor authentication on the accounts that were compromised. There wasn't any isolation of IPs and locations so there wasn't really any need to go through any of this sophisticated defense evasion because they had valid accounts credential access. 

So this obviously is the big part of the exploit. How did they get access to those credentials? Well, they got credentials from password stores because there were passwords being stored on root directories. But ultimately it all comes down to unsecured credentials. This is the big part of this attack. It allowed them to gain access to valid accounts which is where this exploit completely pretty much took place.

Now, let's move over to discovery. Well, obviously they did some account discovery. We talked about this in reconnaissance. That they were able to use fuzzing techniques. Kind of discover accounts. I'm going to call cloud services. Get that, git in this case, using GitHub. So, they're able to discover cloud services files and directories systems and some services discovery. So they did discover quite a lot of different aspects in this remote system. Discovery I guess you could call too.

What would have been interesting is if this had been a malicious actor and it continues. I say interesting, not that I would have wished that it was but just that I would have been curious. 

Lateral movement. Obviously, this played a big part in this exploit but again didn't really need to use sophisticated aspects of lateral movements. And kind of trying to hijack or doing internal fishing, they were able to really use alternative authentication material that was kind of the GitHub credentials that we found from one repository to the other. 

And the data collection. Obviously here we archived some data. From here we had data from information repositories. Didn't need to kind of do a prolonged attack. In here you can see things like a man in the middle or man in the browser attacks. None of that needed to happen to obtain this data. They're able to pretty much gain access to the root repository so therefore able to access a trove of personal and sensitive information, command and control.  That wasn't too much taking over systems. 

Yes, I know they took over the MySQL database in that first instant but they decided not to for the second instance of the attack. So I think I’m just going to go down here and say that they had web services that they took over. But again this could have been a whole lot more interesting had this attack been prolonged. 

And exfiltration, let's just say that they did automatically exfiltration. Here more talking about that get dumps and stuff but not so interesting. We could have set up some scheduled transfers so this could have been really interesting. Particularly, if the attackers could have remained within the git repository for a prolonged period of time. 

And then, the impact. Now I'm not going to highlight anything in the impact as to what it was. The impact was that they got some data. It wasn't particularly bad in this case but it could have been. 

What could they have done? Well, I mean, we could say that they could have done anything, right? So no point talking about it too much but definitely could they have done some account removal. I'd suspect so particularly in the databases because they've destroyed data.  Yes, there were backups in the repositories but once they gained access to the MySQL databases they could have destroyed more. They could have encrypted it, they could have manipulated it, defaced it, wiped it. A lot of impacts that they could have done with the data here and ultimately potentially could have shut down some services. 

We'll never really know and the attackers didn't provide much more information on what they could have done. So I think we'll just leave this one to our imagination. 

So what can we learn from running through this attack?

On the mind on this framework well,  one thing that's for sure is that this wasn't an attack that required a huge amount of sophistication and a huge amount of resources. Essentially investing heavily in that recognizance phase and being able to exploit credentials when they're being found, really enable them to carry out this exploit with as few resources as possible. 

This actually makes it quite difficult to detect because other areas where you would definitely detect that something is going on: elevated traffic, unknown IP addresses coming in, ways that we can detect when an attack might be happening. 

Well, because there's such a low level of sophistication we really found it quite hard to be able to detect this. 

The other area is that they were correctly authenticated. They had valid accounts. This is the part that keeps coming up. 

So how could the United Nations breach have been stopped?

Well, it could have been stopped at the very first point of trying of not having any credentials in public view. So we need to implement something here, along the lines of credential scanning and all the git repositories. And making sure that there, we don't have any unwanted public repositories. 

But as you can see here, that when someone does get access to private repositories well it can contain a heap of sensitive information. So we want to also make sure we don't have sensitive information in our private repositories. So definitely we need to implement some credential scanning in here. Both public and private repositories and we need to set up a perimeter that we can regularly scan for these just like the attackers did. 

The other area is that we probably want to implement some much better credential management hygiene. So we had old git tokens, GitHub tokens that allowed us to gain access to private repositories. Well, we need to make sure that our GitHub tokens are regularly refreshed with good and correct management and hygiene of these. So that if one does end up on the loose, which we should not accept, but if one does hopefully, it expires in a short period of time and prevents the lateral movement that we saw in this exploit. 

Another area is some zero trust. We probably want to set up two-factor authentication. It is a must. Maybe if we can do some whitelisting on IPs and really sandboxing some systems could have helped prevent this or at least identified it. 

So these are some of the areas that we could set up. None of this is really that complicated. We're not talking about expensive security infrastructure and management tools to be able to detect this. We're really talking about making sure that we have visibility over where our credentials are, making sure that we have management practices in place to prevent it if they do get loose from causing trouble. 

So again white hat hack for this one nothing malicious was done but it makes you wonder had a malicious actor discovered this what could they have done. What could they have done or did a malicious actor discover this and just remain hidden in the systems?

Well, we're not going to know so if you agree or disagree with this analysis of the attack let me know. I'd love to have a discussion about what you think were the areas that needed to be protected or how you would have displayed on the attack matrix and I look forward to hearing from you.