Thoughts on Grizzly Steppe
post by: Moses Frost
Update for 12/31/2016: Robert M Lee, also has a great critique on his blog. I think he is trying to help and progress and build bridges which, in all fairness this post was not designed to do that, it was more of a collection of my thoughts.
tl;dr? Something isn’t right with this thing, in more ways than one. One of the most glaring omission? Inventory your DATA.
This morning I found my inbox slammed with the words ‘Grizzly Steppe’. My first thought, must be another spy agent operation, because who else would name these things? If you’re curious about what I’m referring to, the U.S. Government declassified some of their documents on the DNC breach. I decide to give it a once over and here are my thoughts surrounding the subject after looking at this PDF. I have a few questions; maybe someone can help by discussing below.
APT APT APT
Like it or not, the APT definition for these threat actors will continue, but its a running joke in the industry that we make fun of the fact it’s called APT. It is somewhat confusing until you read this thoroughly. The US Government is referring to the Operation as a whole as ‘Grizzly Steppe.’ It’s interesting to note the timing here; APT29 is supposedly shown to be in ahead of APT28 in this particular attack timeline. I found this interesting because from what I gather, APT28 not only was found in the wild first (28 before 29), but their TTP’s (Tools, Techniques, and Procedures) seem to be of an older generation attack style (more on this later).
The entire Grizzly Steppe PDF on page 3 appears to dictate that most of the intrusion initiated through a Spear Phishing campaign. It does not, however, line up with the recommendations that appear at the end. It is not clear what other methods the attackers used, but it gets confusing as you read further down what the recommended actions are.
First question, which is always fun, where do these ‘names’ originate? It appears that all of this information is already available to the public, which makes this release rather interesting. This document does not break any new ground other than validating what private/public research has theorized. I’m going to cherry pick three or so of these names provided on page 4 as an example of how you can come up with this conclusion. There seems to be at least one mistake in this one, or maybe I do not understand what the ‘alternative names mean, but how is someone supposed to link this to ‘Powershell backdoor’? Most of the names come from a few different research groups, although commonly it would appear FireEye/Mandiant, Symantec, Kaspersky, FSecure, and Crowdstrike have been where I’ve seen these names originally publicly published.
- Seaduke: Mentioned in 2015 by Symantec as a new variant of the Duke malware family. It has been theorized this was state-sponsored hacking; confirmation may have come from this JAR Document. Interesting that Symantec, F-Secure, and a few others mention ‘Nemesis Gemina’ as the framework that is used for generating all the payloads for the malware family, but the JAR omits that.
Links to Nemesis Gemina Blackhat, Kaspersky SecureList I recommend the second link that talks about what tools found on some of the compromised servers. The tools seem to be commodity off-the-shelf tools.
CHOPSTICK: Linked directly to APT28 report from Mandiant. It appears all the capitalized names belong to classifications that Fireeye/Mandiant uses for their internal reports.
X-Tunnel: X-Tunnel and X-Agent show up in the Crowdstrike report. One of the more interesting things here on APT 28 is that they are using a more traditional concept of using an agent and tunnel connection, while APT29 seems to be using more evolved TTP’s like PowerShell and implant like technology.
One of the other things I wanted to mention between APT28 and APT29 was the leap from older to newer technology and tactics. Notice that the implant/command channel is simpler and uses rotating encryption. It would appear that it may be custom or commodity tooling similar to Powershell Empire. It’s important because Powershell tends to be more difficult to find and it’s also more ephemeral in nature. Take some time and re-read the Crowdstrike report that talked about how they inserted their implants using rundll32 techniques as an example. Which is interesting as Joff Thyer described the same old school method used to bypass Cylance.
Either way, the techniques between the APT Groups seem to show different ‘individuals,’ I argue this could still all be from the same organization just with different operational models that are evolving. What is also interesting is that while the internal vectors are changing, the initial vector is still constant in this report. Spearphishing is still the way in, and in my opinion, we will not completely stop this with training. If a human is all it takes to protect the gates, we have already lost that battle. History has proven that.
IOC’s and Technical Details
The biggest problem I have with this report was the Technical Details section because it didn’t quite line up with what has been stated in the report itself. Here are some examples:
There is a loosely defined Yara signature for the PAS_TOOL_PHP_WEBKIT that provided. If you read the signature itself, this particular rule may false positive against various other web shells. They are looking for a couple of variables being set and a web shell that is 20K to 22K in length. Here is the bigger question, why release a Yara signature for a web back door when most of the report doesn’t talk about a Web Backdoor at all? Matter of fact, the only reference that this report makes to the Web is that APT28 was using ‘fake webmail domains’ on Page 2. Are we to infer that Web Shells were used in the attack? Should we be looking at vendor research for this information?
Actions to take
In this report, SQL Injection flaws are listed on page 6. What servers where SQL Injected? Why was there such a focus on Spearphishing in the initial introduction but no mention of SQL Injection, XSS, or Server side vulnerabilities? It notes that the IP addresses listed in the accompanying set of IOC’s may be legitimate. This may confuse practitioners that are just looking at the static list of entries. Why not list the ones that are very ‘well known’ versus those are either benign or harmful. In other words, if you are going to include IP addresses for properties that are in the Alexa Top 1000, why not declare those up front?
I understand that Facebook, Twitter, or Github may have been used as a command channel in some of the attacks, although this report doesn’t mention it. A random set of IP addresses with no context doesn’t add value in my opinion; the analyst has to cross reference all of these addresses which will be a time-consuming exercise.
On page 8 there is talk against of protection against SQL Injection vulnerabilities. Most notably, the number 1 piece of advice, for SQL Injection, Firewalling. This seems to be rather a weak piece of advice. If you ask me, the number 1 protection against SQL injection is to fix the code you can fix. In other words, firewalling should only be used when you cannot fix the system. The advice may be better suited if it read: ‘Make sure your database server cannot make outbound requests.’ If you’re a Network or Systems Focused Practitioner, firewalling may be your easiest and best option as it is something you understand and control.
They also go on to mention to Disable harmful Stores Procedures, which I guess would mean disable xp_cmdshell, which can be reimplemented if you have an ‘sa’ equivalent account in Microsoft SQL Server. If you want to give Stored Procedure advice, advice that proper controls over what account the application is using are a more important control here.
I’m not sure what these recommendations are designed to do, but this doesn’t appear to line up with the report. It’s almost as if two different reports were glued together that are not coherent at all. Here is a better list of recommendations, just redirect people here Bobby Tables and OWASP SQL Injection Prevention Cheat Sheet.
I could go on, but this is not a comprehensive list of actions here, there are plenty of other sections of this report that I question. While some of the recommendations are valid, the order in which they appear, the areas that they look in and how they relate to the incident is questionable. From what I can tell, pragmatically, there was an email that went out, was not stopped. The email contained a malicious set of implants that the desktops ran. From there the implant was able to communicate outbound and then lateral movements occurred. Now there are many ways to look at this but from a practical sense here are some ideas that I think could be used to put your hands on things.
- Use something like canary to build yourself a mouse trap or some other early warning system to find people accessing data they should not be accessing.
- Use Cisco Stealthwatch, NTOP, or the Freemium Logging system from LogRythm to find outbound connections and large amounts of data from leaving the environment.
- Try and segment for security instead of for pure performance. In other words, who needs to access sensitive data in an environment and restrict access. With Stealthwatch you can setup virtual zones using host locking so if flows show up from one system to another you can be alerted.
- Finally, I would recommend logging through either ELK, Splunk, or some other mechanism.
- Powershell Script Block Monitoring using Powershell v5 would also be ideal if you don’t use Powershell block it for now. Remember Powershell is replacing cmd.exe so blocking it is not a permanent solution as there are ways to including Powershell in a system, just like you can bring your own cmd.exe.
- Inventory your data! If you don’t know where it is, you cannot hope to protect it.
Have a comment, leave it below.