When it comes to reviewing some real-life breaches, there are five are specific scenarios I want to address, and one is a general analysis of a type of breach we’ve seen a lot lately.
These examples prove that a little thought and awareness can go a long way to protect your data.
1. POS Malware Attack
We all know about the Target breach. And the Home Depot Breach, Neiman Marcus, Hilton, Arby’s, you get the point. These all involved massive credit card breaches. But, do you know how it happened? In the Target example, it was a third-party. The hackers sent phishing emails to a Target HVAC vendor. The phishing emails worked, and, once they had compromised the vendor, the attackers could log into Target’s vendor portal. From that location, they could pivot throughout the network and install point-of-sale (POS) malware on practically every Target POS device. POS malware sits in memory and waits until it sees 16 characters (i.e. a credit card number). Once it sees those characters, it grabs, stores, and transmits them to the attackers.
And, that’s exactly what happened. Let’s consider a few facts at play in this breach:
- Target unintentionally put itself at risk. Before it happened, Microsoft had published case studies about Target that explained the technical details of their environment. We don’t know for sure that the hackers read these case studies, but they did seem to know how to attack the environment. So, if your company is publishing case studies about your clients, or if you have had case studies published about your own organization—make sure the information included doesn’t reveal anything attackers could use to aid their efforts.
- Multi-factor authentication (MFA) would have helped. It may not have stopped the breach altogether, but it would have helped from a vendor perspective. There were multiple aspects of the attack that MFA may have stopped the attackers.
- Segmentation is crucial. Environments that store credit card information should be segmented from other networks into a CDE (Cardholder Data Environment). That way, if the network is compromised, the credit card information is stored safely in its own section, uncompromised. Target obviously did not have good segmentation in place, because the attackers could jump from the vendor portal onto POS devices.
- Default credentials were still in place on some applications. Once the attackers figured that out, all they had to do was use those credentials.
- The credit card numbers left Target’s network in clear text. Properly configured egress filtering on outbound ports would have likely stopped this. Beyond that, the numbers were sent using FTP, in clear text, that most any Data Loss Prevention (DLP) technologies at the perimeter would have easily detected.
- Target was alerted about this and ignored it. In their SOC report, they had an alert from a POS device that essentially said: “There’s some strange software running over here. What do you want us to do?” And, they did…nothing.
This brings up an important (and frustrating) point about most of the credit card breaches we see. They’re the same thing: POS malware that sits and waits for credit card numbers. Companies must pay attention to the applications running on POS devices—because there shouldn’t be many…and they shouldn’t change. If something on a POS device does change, it’s likely an indication something is wrong that warrants investigation.
2. Third-Party Vendor Attack
This was technically the same type of breach as #1, but it’s worse from a vendor perspective, so it provides a good learning opportunity. This was a POS support vendor to some major restaurant franchises as well as a few hotel chains and other retailers.
The POS vendor used LogMeIn to access the POS devices they supported. That way, they could gain control of the device from a remote location and fix the problem without having to go on-site. This was okay…until the vendor got phished. When the attacker landed on a machine, they were able to get the username and password the company was using to connect to POS devices.
And here’s the kicker: The vendor appeared to be using the same login information on all POS devices for all its customers. So, once the attacker logged in, they had access to every single POS device the company supported. Then, they installed POS malware on those devices. There are a few things that would have stopped this. Most of them are incredibly simple.
- Multi-Factor Authentication. Multi-factor authentication would have prevented the attacker from getting into LogMeIn.
- Don’t use the same login credentials for all customers. No matter what kind of company you are—use different login credentials for the different systems you use.
- Compliance is a huge deal. The company in question was not PCI compliant, because they weren’t large enough for a full PCI assessment to instruct: “Hey, you need to do this.” But, the fact is—a PCI consultation or gap assessment would have highlighted (and ideally fixed) most of the issues leading to this breach.
- Use point-to-point encryption (P2PE), if possible. The reason POS malware works is because credit cards numbers are decrypted in memory on POS systems. But, with P2PE, credit card numbers are encrypted from the swipe all the way to the acquiring bank. In those situations, POS malware doesn’t work. Most (if not all) of the credit card breaches we hear about would not happen if those companies had P2PE installed. For example, in this scenario, one of the stores the vendor supported was using P2PE. And guess what? They didn’t have to disclose the breach for that location because the credit card information was encrypted the entire way from the swipe to the bank. The challenge with P2PE is that it’s expensive. But, the fact remains, it effectively renders POS malware attacks useless.
3. Web Application Attack
If your company offers a web application to customers, you must understand this: Your web application is your brand. It’s the first touch people have with your company, and people’s perception of your company is likely colored by their use of the application.
In general, companies do a bad job of leveraging web app vulnerability scans and penetration tests to identify security issues. This attack is no exception. I don’t know if it would have happened if the company had been performing vulnerability scans. In short—the company in question lost the credit card information for pretty much every U.S. citizen. I’d call this The Data Breach Apocalypse.
So, how did it happen?
First, it exploited a vulnerability that was identified in March 2017. The company, however, didn’t realize it had a breach until May 2017—two months later. That might sound like a short period of time to you, but it’s a very long time to have an open, known vulnerability on your website.
Second, the company hadn’t performed a thorough vulnerability scan. If they had, they would have recognized there was an issue, which brings me to my third point.
Finally—I’m not sure the company even knew they were running the vulnerable software. Unfortunately, this isn’t uncommon. When you have things that have been in place for years, it’s easy to forget about them.
Here’s what the company could have done to fix these issues.
- They should have been running vulnerability scans on a regular basis. That would have identified the issue before it could be exploited.
- They should have stayed up-to-date on available threat intelligence. If you frequent sites, subscribe to newsletters, and do whatever you must do to get real-time, accurate information about current threats—you’re less likely to let a vulnerability like this slip by.
- They shouldn’t have placed the responsibility of security on one person. The company’s CEO placed a huge burden of blame for this breach on one single person. But, that’s not fair. Because, if you rely on one person for your entire information security infrastructure…what happens when that person goes on vacation?
- They should have done proper asset management. There’s no easy way around it. It’s hard work, and it’s not easy to maintain, but the fact is: You can’t secure something if you don’t know you have it.
4. Business Email Compromise Attack
This is a classic phishing attack. An attorney at a law firm had her email hacked, but this wasn’t any old law firm. They were responsible for handling large real estate transactions (i.e. large amounts of money). The phishing email had an “encrypted document” attachment. When she went to open it, it prompted her to put in her username and password for Outlook365. Naturally, she did—but it was a fake Outlook365. At that point, the hacker got her information and logged into her real Outlook365 account and set up rules to look for wire transfer information. When that information was identified, it would alert the hacker, who would then log in and change the routing information to transfer that money to a different bank than the intended one.
This single incident caused the company to lose $1.1 million. And, don’t assume this is limited to one company. This is a huge problem. Business email compromises are the primary incident we’re working against right now. The good news is that these are simple attacks, which means they’re easy to stop—if you know how to do it.
Here are some ways this attack could have been avoided:
- Use multi-factor authentication. Are you seeing a trend here?
- Enable the right Outlook365 controls. Outlook365 is equipped with multiple features that can identify and prevent these sorts of attacks:
- You can geoblock foreign countries from logging into an account.
- You can get alerted when someone sets up a rule on your account (e.g. a rule to forward an email to a third-party address).
- You can enable a rule called “Impossible Travel”, which can prevent a login if an account logs in from multiple, substantially geographically-separated IP addresses within a short period of time.
- Leverage Microsoft’s Secure Score to perform a risk assessment against your O365 environment to determine how you measure up and to determine what controls you need to implement.
- Enable Mailbox Logging. It was not in place in this situation, and it could have provided an alert that something phishy (sorry) was happening. More details on 0365 logging can be found here.
- Use phishing assessments with your team to help them learn to identify phishing threats.
5. Ransomware Attacks
There were a lot of these. For this one, I won’t talk about a specific event, but rather the general nature of the attacks we’ve handled. Healthcare companies are often targeted because they’re willing to pay more (because patient data and lives are on the line). In my tenure of a decade working in Healthcare IT, we referred to this as “patient on table”.
There are generally two ways this type of attack is carried out.
- Phishing. Most of the time, this starts with a phishing attack including an email attachment (like example #4). When the recipient opens the email, it says something like: “Hey, you need to enable active content in this document.” Once you do that, it downloads ransomware from a hostile web server, encrypts the files on the local device, then encrypts the files on every server that device is connected to.
- Remote desktop services. For convenience purposes, administrators often set up remote desktop services to allow them to remotely access the network. If those remote desktop services don’t have multi-factor authentication installed, a hacker could brute force attack a password login until it works as the local administrator account cannot be locked out by default. Once they’re logged in, they’ll manually install the ransomware and send an email demanding payment.
So, how can you fix this problem? At face value, it’s simple. Restore from backups.
But, this can be tough in real-life. Consider this scenario:
There’s ransomware in your network, and a hacker is demanding payment to unlock your files. You know you can restore from a backup to fix the immediate issue, but there’s a problem—it’s 3:00 PM. You’ve been treating patients and logging their information all day. But, the last time your system ran a backup was 11:00 PM the night before. That’s 16 hours of patient data you don’t have backed up and can’t afford to lose. At that point, the problem isn’t knowing what to do, it’s facing the reality that you can’t sacrifice all that patient information to save money. In other situations, the attacker has been on the network long enough to find and destroy the backups…So, you pay the hacker.
But, how can this sort of attack be prevented?
First, regular backups are key. Losing 16 hours of logged patient information is much different than losing 1 hour or even 30 minutes of logged patient info.
Second, perform external penetration tests regularly to identify areas where hackers may be able to log into remote desktops. Then, either remove that access altogether or implement the right controls to secure it.
Finally (and, this is a repeat from #4), perform phishing assessments to help your team identify and report malicious emails.
6. Nation State Attacks
Not all hackers want your money. Some, like China, want your intellectual property. But, we don’t often hear about it when China hacks into our systems or learns valuable information about us, for two reasons.
First, because defense contractors do not have to disclose breaches to the public unless personally identifiable information (PII) was comprised. (That’s the only reason we hear about most breaches involving China.)
Second, because we’re in a precarious financial situation with China (read: we owe them a lot of money), we don’t have much leverage to hold them accountable for their actions. And the current “trade war” with China isn’t helping much.
So, what exactly happened here?
The Office of Personnel Management (OPM) joined networks with another company who had already been compromised. That’s a big deal because OPM holds the clearance data of every U.S. citizen who has had a clearance in the past 20 years. That’s some of the most sensitive information you can get about a person. And, China allegedly wanted to use it for blackmail—to turn people into insider threats to steal information for them. They installed remote access tools (RATs) on the network that looked like legitimate software. (Spoiler alert: It wasn’t).
Because they use tactics like this, China can be in a network for months or years before they are detected. In this instance, someone was looking at network traffic and saw something “odd”. After further investigation, it was found that China had registered a domain (it looked like a military domain) that the malware was beaconing to. That’s how they were keeping their foothold in the network. They were even able to compromise the jump box used to get into the sensitive systems housing the clearance information that was segmented onto another network.
So, what could have been done to prevent this?
Again, multi-factor authentication. If you haven’t noticed yet, this is an incredibly valuable control to prevent against most attacks.
Second, look for typo squatting. For example: If your website is “lbmcinformationsecurity.com” with an “L,” your Spidey senses should tingle if you see a site with a domain like “1bmcinformationsecurity.com,” with a “1” (as in the number “one” — just to be crystal clear). That’s likely an indication someone is trying to get into your network…or is already in.
Beyond that, there are a few very important things to understand:
Not all malware is created equal. When they swept this network, they found about 4,000 malware infections, but the only one they needed to worry about was the RAT found on the jumpboxes.
Not all systems are created equal, either. In this situation, the jump box was the most important system on the network. Without compromising it, the attackers could not get access to the sensitive information. So, if it had never been compromised, this would have been a much different scenario.