Learning from Financial Fraud Series Episode 8: Payment Server Breach

Announcer  00:04

Welcome to the Treasury Update Podcast presented by Strategic Treasurer, your source for interesting treasury news, analysis, and insights in your car, at the gym or wherever you decide to tune in.

Jonathan Jeffery  00:18

Welcome back to the Learning from Financial Fraud Series on the Treasury Update Podcast. In this series, we’ll explore multiple major financial fraud cases. We’ll discuss how each one occurred and was kept hidden for a period of time. We’ll dissect how it was eventually discovered, and get insight and guidance on how to prevent this type of situation from happening to you and your organization. I’m Jonathan media production specialist at Strategic Treasurer, and I’m here with Craig Jeffery, managing partner. Welcome back to the show, Craig.

Craig Jeffery  00:46

It’s good to be back. So we’re gonna do some dissection today.

Jonathan Jeffery  00:49

Yes, this is our eighth episode of this series, and today we’ll be talking about a case of payment server breach. Do you want to run us through this situation? What happened to this company?

Craig Jeffery  00:59

Yeah, I always like going through when, when fraud occurs, especially if it’s a different type of fraud, or a new, new case or a situation that we’ve seen what what occurred. It was a very large multinational company. They had a bunch of trade activity, including confirmations of of their trades. And they found out that certain things were not being sent. They were enacting transactions. They weren’t getting confirmations. They found out that activity was not not occurring. And so they went and said, Well, what’s going on? So this was with a messaging server used and connected through swift for sending some of those messages. And they found out that the messaging application, the Swift program, was turned off. And so why was it turned off? It’s really the whole purpose of the program is to monitor and move messages and confirmations back and forth. And so as they looked at it, so why is this turned off? What’s going on? They found other programs running, particularly one program that was a Bitcoin mining program. So this is a program that just runs, runs on the server to determine, through all the algorithms, if they can create a new Bitcoin which would have significant value. And so that’s certainly been all the rage at different times. But it was using all the computer resources up to just mine for bitcoins to run the algorithms and run hot. And so seemed clear that the criminals wanted to steal the computing power of the server to run it to make something that would have some value, and they didn’t want this other program that was used for messaging, including financial messaging, to move money. They shut that down because it was taking up time. And so that’s kind of ironic in a lot of ways, because they were stealing resources to run a program that would eventually generate money, but they had gained control of the messaging server for financial messages.

Jonathan Jeffery  02:57

I’m interested to hear how they separate to those two types of crime, one, you might be stealing someone’s money. That one, you’re coming in and using resources that they didn’t even notice were being used for a long time.

Craig Jeffery  03:09

You know, I always assumed that the criminals who were stealing the the time didn’t realize that they were sitting on a messaging server that moved funds. That may not be the case. It may be. Who’s going to pursue trying to find somebody in some other location that had cracked into your server and did it just because they stole computing power, probably ran up a little more electricity or generated some extra heat. I doubt there’s any follow up for that. Now, if they’ve come and stolen millions of dollars, you know, millions or 10s of millions of dollars, then there probably would have been a greater level of enforcement action taken taking place in that and who knows, that could have been in the mind of the criminal? I don’t know, because I wasn’t the one who did it, but I always I like that idea of somebody who’s just like trying to mine bitcoins, finds the basically the banking and messaging server, but just uses it to to run their program on it.

Jonathan Jeffery  04:07

There’s, there’s no gleaning of the fields rule for servers, right?

Craig Jeffery  04:11

No, like, if there’s a extra computing capacity laying around, you mean that that anybody can just pick it up? I don’t, I don’t know if they followed that, that model.

Jonathan Jeffery  04:22

Okay, so how did they, how did they actually implement this attack?

Craig Jeffery  04:26

So there’s, I’m going to describe it in a particular way. I have close knowledge. There’s, there’s two ways that they could have come in and penetrated the server. They could have done it through brute force attacks just to gain access to that particular server, or they could have done it through compromised credentials, if they had stolen them from a person. But it looked, it looked, and appeared to be a brute force attack that compromised some credentials into the company, and then they were able to use those permissions to expand laterally, in other words, Grant. Additional permissions to get to the server where they installed the activity and then shut the other processing function down. And that really led to quite a bit of, I call it soul searching, and access searching on the part of this company, which we’ve seen over and over again as a real issue when it was pursued to see what had been compromised, the issue of what are the rights and accesses that were granted to servers to different functions. And as soon as it started being explored, it was who has access to this, this server, oh, all of these, all of these IDs and permissions. Many, many IDs, and some of those IDs and permissions were group permissions, and some of those group permissions had group permissions under them, and some of those group permissions had group permissions under them. And so finding and unwinding all of the permissions, like who all in the company could do whichever functions was like this Gordian knot to UN unwind it. And so with a lot of effort, they pulled and tried to simplify that activity, but they also knew that it was going to take over a year to unwind the mess of all of their servers everywhere and the credentials and permission granting activities. So they took a they took a different route which provided security in the short term while they worked on the overall credentialing through the entire organization.

Jonathan Jeffery  06:30

Interesting going back to brute force attack real quick. What are some examples of what that might look like? Is that like phishing emails being opened and accessing the servers through that, or what does that look like?

Craig Jeffery  06:44

So phishing emails, an email trying to get someone to give up credentials, would be, you know, some type of spoofing attack, or someone standing in the way, pretending there’s someone they’re not. So you give up credentials. That’s a different type brute forces. I access, I access a server, and I use a program to run. Usually, I try to find out what the IDs are. Sometimes those are discoverable. I try to find out the IDs, and then I have a program that runs and throws all of these password combinations through one after another. Usually, it’s using these giant lists of all the credentials have been compromised by all these heists, all these cyber breaches, all those credentials are out there. And so instead of using the whatever the 100 quintillion possible password combinations, they usually load the ones that have been found and have actually been used the the 10s of millions of those, and they’ll run those through and just start running through the system as quickly as they can. That sounds like it would be really difficult or be easy, but if you if your system does not block after five or eight false attempts to log in, doesn’t freeze it or allow for delays. They can run millions through per night. And so if it’s not creating a pause or some kind of delay or blocking an IP address that tries too many of these, the kernels can just continue for a really, really long time before locking up. And then sometimes, when they gained access to one particular system, the permissions sometimes they’re not quite as severe when they’re coming from within the organization as they move laterally. But we had that multiple years ago, when we did our external pen tests, we found that there was some of our external systems, not financial, not client systems, thankfully, that like websites, domains didn’t have all the settings to block if someone’s trying to brute force. So you want to have the process to block the brute force attack. They can’t just keep throwing millions in there. They’ll eventually get through, given enough time. You also want to make it so that the credentials aren’t discoverable. So if you know, if it’s John, it shouldn’t be John, you know, whatever, they shouldn’t be able to find that that there’s John and Craig and and whomever, and that’s the code. They should have to also try to figure out what those the base credentials are, not just the passwords. That way, the combination becomes almost impossible to crack if you have a sufficient level of complexity of your passwords, and however else you log in, the ability to shut it down, and then they don’t know what the they don’t know the initial credential or password. It’s efficiently complex, and you block it. That makes it extraordinarily difficult to get through. You know, one of the examples that we had when we when we first did that, just from some of the websites. They’re like, well, we couldn’t, we couldn’t crack it, but we had made attempts to do it. We and they would run the program our the people that were pen testing us. They would run the program after people had left the office that say, let’s do it after 630 at night, and let’s stop it at 730 in the morning so that there’s. Away. Someone would come in and go, Why is? Why is the system running more slowly? And so when they said, I think one of one of them, they said, Well, we ran 4 million times on that. We’d run we’d run it constantly. It’s like, 4 million times, and this is during the pendes period. It’s like, I didn’t tell them how long our passwords were, even for web servers, but it was. It would have taken a while, but that was, that was pretty eye opening. And so then we, of course, built in the Tools others. There’s tools for websites, there’s obviously tools built in for software as a service, programs that you can make it so it blocks things you can also make, make sure it puts some of the IP addresses on lockdown once they try it, and it’ll start extinguishing those. So we’ve, we’ve added those services, and it’s surprising how many, how many temps are, and many of these criminals continue to use varying IP addresses as they make their attacks. And so, you know, it’s a whole, not cat and mouse, but it’s a whole, you know, process of providing defenses for that.

Jonathan Jeffery  11:07

So it’s not a error of an employee or client clicking something they shouldn’t, or giving access to someone they shouldn’t. But you didn’t know to set up these, these blockers.

Craig Jeffery  11:21

Yeah, if I can get you to get the information, great. If I can get my system to penetrate your system by just, you know, brute force running, just running a routine until it gets through, like it keeps running these passwords through, they’re gonna get through. And why wouldn’t they try both?

Jonathan Jeffery  11:37

Yeah, it’ll get through. So once they got through and started putting their their software on the servers, what kind of loss did this company have?

Craig Jeffery  11:46

Now, this was this was surprising to me. They had no financial loss. The criminals did not steal any funds. Didn’t cause any harm or damage. It was my view, they didn’t know. They gained access to a swift messaging server for payment, transfers, confirmation, all of that, so there’s no financial loss. The only loss was all the time spent making sure that they would get blocked, and then setting up a more secure process for payments. And then, you know, re engineering how they granted permissions, the principle of least privilege and the principle of specific accountability became extremely important in the organization, and it took them a while to lock everything out but to manage what they did with the servers related to messaging for the payment server breach. You know, they blocked access to the server, they locked the initial access points in, limited how you could get to it from within the network, and they put in much better security protocols, and then they removed blanket group ID access to it and became specific to a person, it was because it was very limited. They didn’t have, didn’t have to have groups like, you know, a support group, one support group two, user group one user group two. And then people’s access groups get put into that. That’s, that’s where some of the problems can come into is people get added to group after group, and the nesting of groups within groups makes it really hard to find out who had access, so that that mattered. But how we fix that? We work with them to establish a cut out process while they didn’t feel they had absolute control over all of their internal networks with the credentials, because it couldn’t just like, eliminate all of the credentials right away, because nobody could access anything. So we established a cutout process using a third party file transfer and validation process, so payment instructions moved into an environment that nobody in the company could control other than through through the third party. So there’s a very nice segregation of duties between those two, and then the messaging could not be interrupted from that point to and from banks for moving funds, and then there’d be a passing of information back at that point. So most of it was masked from somebody would just have access who may have compromised the internal systems. It was masked from that you’d have to compromise the company and the third party to be able to create problems.

Jonathan Jeffery  14:31

Yeah, what a way to learn it’s like someone breaking into your house and sleeping in your bed, and then you realize, hey, my locks aren’t working. They didn’t steal anything, but my locks aren’t working. Now. I need to put locks on my doors.

Craig Jeffery  14:44

And more like they they were sleeping on the floor, and you’re like, there’s a nice bed right there, and then they didn’t realize that. But, yeah, it’s one of those situations like, okay, you’ve got to make it so that it’s no longer an issue. You know, I think some of. Learning from this, John was this really helped me to become much more vocal about the principle of least privilege, restricting access and having specific accountability, and this limiting access to systems and data, limiting to just those people and those credentials and those IDs that have a need to know or need to access, it becomes so crucial, and any changes to that information has to be reported and tracked, especially in the areas where the company’s Crown Jewels are or the access To payment transfers are. Anybody makes a change to credentials that could see or intercept the payment file, for example, or stop a confirmation file from coming back, there has to be an alert that additional permissions have been granted, not just somebody approved it, but there’s some broader message that goes out that that shows that something has changed beyond the alert. Is this authorized? Yes, is this not authorized? No, that can’t be for every directory in the company or every server, but there’s certain areas where you have to make sure they’re really locked down. And so the principle of least privilege for valuable items really, really matters. Additional learning points for the company. I think that all of us who are talking about this, or listening on this topic, is so they had a full payment security assessment from the start to the finish to identify all the points of exposure all the controls, and identify areas where the control standards weren’t up to at least a minimum standard, and maybe even where they had a gap from, you know, leading class or world class practices, and then identified, what are those specific things that they could do to up it to at least a minimum or maybe a leading practice that was relevant for what they did that proved vital for them? I think that’s a key area for most companies to to do. If you haven’t done that in the last year, if in them last two years, that needs to be done. If it’s not been done in the last year, it’s it’s certainly worth thinking about, depending how many, how many have, how how much you’re looking at these processes. The other really helpful thing to learn through this was they put in quite a few monitoring and reporting processes for the changes in permission. You know this the idea of the principle of least privilege. You want to make sure when someone else is granted privilege to these particularly sensitive areas that multiple people know and see, that has to be very limited areas, because otherwise it’s going to be too many false alerts all these changes. This grants the whole area the ability to see something, someone or some credential is now, now has access to a particular area. Why is that the case? Does this make sense? Is it a new person that’s being hired? Or is this, you know, something that’s nefarious or a criminal, criminal adding that activity and the other, the other learning point was they wanted to expand the growth of their cyber defense and payment security defense throughout the organization. So there was a greater focus on, you know, their organizational structure from an IT perspective. So security became a bigger issue. There’s, there’s some new roles that were put in place there. In terms of cyber security training. They added cyber security training. They also added training for payment security, you know, reviewing how payment processes work, what criminals do, how you can defend against those really a focus on the payment side, which is one of the most crucial areas. So general cybersecurity training, plus payment security training, and then some some new reporting and new roles for the organization, new new jobs, new professionals coming in.

Jonathan Jeffery  18:58

Well, thanks for sharing all this info. There’s a lot we can learn from someone else’s not mistake, but someone else’s encounter.

Craig Jeffery  19:07

Yeah. How often do you think it is that someone breaches the system and doesn’t do any harm other than use resources? I don’t think that’s very common. That’s That’s pretty fortunate, but it it provides all the same learning. And the company was sufficiently scared and concerned, based on how far the activity had gone and the fact that they hadn’t, hadn’t had their stuff shut down, they hadn’t had their data stolen, all they did was, have, you know, server server use issues, they got that huge warning and alert without having the massive amount of pain that comes from financial loss or having all of your customer data exfiltrated.

Jonathan Jeffery  19:48

Yeah, that’s crazy. If you guys enjoyed this episode, there’s seven other ones that have already been posted from the learning from financial fraud series, so I will put a link to those down in the show notes. Thank you all for listening.

Announcer  20:03

You’ve reached the end of another episode of the Treasury Update Podcast. Be sure to follow Strategic Treasurer on LinkedIn. Just search for Strategic Treasurer. This podcast is provided for informational purposes only, and statements made by Strategic Treasurer LLC on this podcast are not intended as legal, business, consulting, or tax advice. For more information, visit and bookmark StrategicTreasurer.com.