The greatest driver of business value in security are feedback loops. However, the true value of the successful completion of one such loop can be difficult to assess. Traditional KPIs are retrospective and fail to capture the systemic value of these complex “wins” that security feedback loops deliver.
One way to communicate the complex value of these loops is through a simple story. What follows is a conversation between the Highland Defense founders, Stuart & Will, about a successful feedback loop that Stuart navigated with a Fortune 500 company.
————————————-
Stuart: A recurring problem we were seeing was phishing attacks that were coming into the company and used PowerShell commands from malicious Word docs or Excel files to infect computers. We knew that the chasing phishing emails alone was not going to be enough. So we looked how we could potentially stop the initial call-out.
Will: What do you mean by that?
Stuart: When a user opens a malicious attachment, it usually fires a command that calls out to the Internet to download additional files or information to infect and attack. This technique works because the email itself is very “light” and difficult to identify based on the email signature alone. Most of the attacks at the time were using PowerShell to do the call-out. There was also a growth in the spread of Living Off the Land or Lol-bins (living off the land binaries). These were Microsoft executables that let you call the Internet and allow you to download malware as well. An example of this is msi.exe, a common Microsoft installer file. We were seeing an increasing number of attacks using either of these techniques.
Will: To summarize the attack, it is a system executable, with a generic name, that runs when a user opens a malicious attachment. At the time the attachment is opened, the executable infects the user’s machine with whatever payload it is programed to retrieve from somewhere in the Internet.
Stuart: Yes. The whole point was to leverage the computer to download the malware as a way to avoid any security controls.
Will: Initiated by PowerShell – the command line interface – or some other .exe installer?
Stuart: Correct. In the old days, it used to be visual basic scripts. As we saw attacks evolving, they switched to JavaScript. There they were leveraging JavaScript in documents to download malware as well. Knowing this, we took some examples and wrote a couple of attacks ourselves to run on a test machine and see if we could find a choke point. Where was there a security control that we could evoke to prevent malicious use of these executables, but still allow business or authorized use of the “good” files.
Will: As a result of this you narrowed down the point of compromise to the call out to the internet to download the malicious target payload.
Stuart: We wanted to focus on the call out because then the computer was less damaged; catch it early and prevent other changes to the computer. At the time we had an antivirus product that also had a local/host based firewall. Which gave us an idea – what if we could prevent the call-out with the firewall? This would be great, but there's a lot of different firewalls and all are rather limited in what they can do, especially on an endpoint.
With the firewalls on the users workstations, you have three choices of action:
1) Block by filename
2) Block by port
3) Block by filehash
We looked at all three.
If you blocked by port, you’d essentially block all Web traffic, which is an obvious non-starter. We can't block by an IP or destination because we don't know where they are going to download the malware from. That left file hash and file name. The challenge with Filehashes is they vary widely, depending on what version of PowerShell you have installed, patches you have added, the version of Windows OS running, etc. We ended up with such a large inventory of file hashes and knew it was going to be difficult to maintain.
Will: The filehash method is not very repeatable or scalable. The variances are so constant that it makes it a fragile detection?
Stuart: Correct. It's fragile. We were left only with Filenames. Now, bad actors can rename executables to get around a filename block, but we noticed that we were intervening so early in the attack that they didn't have time to rename the file. They almost always rename it later to cover their tracks and have a back door. Again, we were seeing it early enough and could observe the base executables were not being renamed or copied to another location with another name. We put in a firewall block for the big ones - powershell.exe, powershell_ice.exe. The result was an immediately stop to those phishing attacks running on workstations.
Then we added c-script.exe, w-script.exe. Those two actually prevented any VB script or JavaScript attacks from happening. Also important to note, that these blocking controls had a very minimal impact on the business. Most people didn't even know that we put it in. We deployed the control out to twenty thousand endpoints and had were seven users that called about an issue when we put the exclusion in for them. They were heavy PowerShell users who download modules from the Internet. We worked with them to create an exclusion to allow call-outs to certain web sites that we knew were good.
Overall, it was a rather invisible control to end users. When we pulled the numbers, we dropped our infection rate on phishing emails by almost 80 percent, just by putting in this one control.
Will: How is the file name identification less fragile than the hash? Why can't they just rename the files before getting caught - like you mentioned before?
Stuart: You have to remember, they don't have control of your workstation yet. Anything they do on that workstation prior to getting control has to be in the script that they sent to you in the phish.
One of the big things that Endpoint controls monitor is if you're copying and renaming system executables. That’s really easy to catch because nothing should be doing that.
Will: That makes sense. And if the executable doesn’t have a generic or a benign name, then the system is going to catch it as malware off the endpoint control.
Stuart: Yes, they have to avoid strange or coded filenames. They have to hide in plain sight essentially.
That's what attackers have relied on for the last five years, leveraging known good executables to use them in a malicious way. And that's what this takes advantage of. It augments what else you're doing on your endpoint to really close-out how infections get installed on the workstation.
Will: So at the end of the day, it was an endpoint firewall config?
Stuart: Yes. We used our antivirus to deploy it, but you can also do the exact same configuration in the Windows host firewall and deploy it using active directory. There are a lot of options and most host based firewalls have the same options to configure.
The other key was we blocked executables going to out to public IP addresses. That's what minimize the business impact, if it's a public IP address range, block it.
What that does is still allow you to use PowerShell to connect to other computers within your company to manage them, monitor them or query them. While at the same time preventing PowerShell from being abused and hitting the open internet.
Will: Simple, specific, and effective, with almost no negative impacts on business operations. Sounds like a win-win-win.
Stuart: There’s one more thing. When we put in this firewall rule, we started logging whenever it was hit by a workstation. Those logs flowed into Splunk and we used that data to write alerts and enrich our RBA data. Splunk could tell us “Hey, this workstation attempted to reach out to the Internet with a script. It was ‘malicous_script_z’”. With that information we could track down where the potential malware came from, what e-mail it was, who else might have been hit by the same phish. It allowed us to correlate and coordinate a response across the entire company in near real time.
Will: Of course – that is brilliant. Knowing the one potential compromise or near compromise lets you spread that across all objects of interest throughout the entire network. You immediately say “We know this is bad and in our network. We stopped it once, where else do we see it so we can stop those too?”
Stuart: Exactly. What it gives away is the IP address that it was attempting to reach out to on the Internet. You can see if the attack centered around one IP address or multiple IPs. Then you can say “Hey, if I know this IP address was bad, I’m going to check the rest of my events to find out who else reached out to it.” Even if your firewall control is on 50% of your machines, you can pivot off of the known bad IP to see and block other machines that are calling out to it.
Will: The attackers would have to constantly vary that IP, which isn’t that hard to do, if they wanted to have a successful attack at that company?
Stuart: Correct, but then all it takes is for them to hit one of the machines with a rule that has a block on, the log file gets created and sent to Splunk, and the new IP is know bad. It’s a loop that’s always checking.
Will: A truly anti-fragile security control.