Grizzly Steppe:  JAR-16-20296

Yesterday, US CERT along with the US Department of Homeland Security (DHS) released a Joint Analysis Report (JAR) on GRIZZLY STEPPE. If you’ve been reading the news over the past few months, you’ve seen the accusations of Russia’s interference on the 2016 US Election. In generalities, the US alleges that Russian nationals hacked into the Democratic National Conventions systems, and through a series of campaigns, were able to leak internal documents that were a bit damning. Many believe there was a direct influence into the results of the election, therefore messing with our need for a pure and ‘internal’ election. This post is not to discuss the politics of it, but more to discuss the GRIZZLY STEPPE release that came out yesterday.

GRIZZLY STEPPE

As you know from my other posts about Threat Intelligence ( Overview, Mini Rant, etc)

a briefing like this comes across in a few formats. First is the writeup:

Security Briefing

Then the STIX:

STIX Documents

Then a PDF:

PDF Documents

Overview of the attack

These are a mix of analysis and marketing, in my opinion. That’s not a bad thing. There is a ton of useful information in that PDF that describes that context around these attacks. You can read in there that there were two groups (APT 28 and APT 29) that were active over the same time period. The attacks came through ‘neutral space’ (AKA The Internet), so there was a tech/air gap between the attackers and the victims. This provides a way of hiding the true source of the attack.

From US CERT – Grizzly Steppe Attack Flow

The initial penetration came from targeted spear-phishing. These are custom crafted emails, that are meant to seem legitimate. Spear-phishing is different from phishing, and can be generally distinguished between the approach. A typical phishing campaign will blast the same email to hundreds or thousands of email addresses, hoping someone clicks a link and enters their bank account information. Spear-phishing is hyper targeted. They will research the recipient, and craft messages to them.

Once a message ends up in someone’s inbox, the user still has to typically perform an action (click a link). When the user clicks the link, they are directed to a malicious website that will drop malware on their machine. After the malware is installed, it can do the nasty things we’re all scared of. In this case, the two types of malware behaved a little differently.

From US CERT – APT 28 and APT 29 Comparison

APT 29’s malware was focused on finding internal data, and sending it out over an encrypted channel using their own encryption keys, making it impossible for anyone to read what was coming out. APT 28’s malware acted more as a zombie piece of code. It waited for command and control messages from an external system before executing. According to the writeup, it logged real time data (keyloggers) and executed code , instead of finding existing files to exfiltrate.
Let’s talk about the observables

Before the briefing (above) got to my inbox, the Perch Security system had already pulled the latest data from DHS AIS. DHS AIS is the Automated Indicator Sharing platform that the Department of Homeland Security runs. Essentially, it’s their TAXII feed that serves STIX data. (( For a refresher, look here: ))

The data comes out in a bunch of documents, that together, form this story.

Grizzly Step STIX content in graphical format

The yellow in the center is the STIX Package. This package let’s us know the general context. In this case, there isn’t much beyond a title: “JAR-16-20296” and the description: “This indicator is alleged to be connected to suspicious malicious activity.”. The TLP (Traffic Light Protocol) of all this is WHITE , which means I can freely share all this information.

There are 912 Indicators (Pink) and each Indicator has an Observable (Blue).
The indicator descriptions are also quite generic.

877 of them have the description”Malicious IPv4 Indicator”

24 of them have the description “Malicious File Indicator”

10 of them have the description “Malicious FQDN Indicator”

1 of them has the description “Malicious URL Indicator”

You can see a full breakdown of the Observables below.. mostly IP addresses, a few domain names and a few file hashes.

Slicing and Dicing

Looking at the data

One issue that is regularly seen is the quality of the Observables, and I’ve blogged about this before (( Mini Rant, again )). Just because an IP address was found during research, doesn’t mean it’s an Indicator of Compromise (IOC). This is a challenge, because sometimes, a ‘safe’ IP address can act bad. How do we list that in STIX? For instance, when a known shared web host, or even a CDN like Amazon or Akamai, temporarily hosts a bad file that one of their customers (hacker?) uploaded. Do you put that IP address in your list of Observables? Do you put the full URL of the specific file? The file hash?

1. In this technologists opinion, we need a few things.
2. In the STIX standard, indicators give us context. We need to know when something is always bad (file hash)
   If a URL, web domain, etc are maliciousn (www[.]g00gle[.]com, let me know that.. then I need a way to know what IP address that domain resolved to at the time of attack… but consider that ‘meta-data’. Don’t consider the IP address as necessarily malicious.

As far as I know, some tools like to add the IP address at the time an analyst enters the domain name. That’s fine, but it should not be treated as the ‘Observable’ of concern. This is a tough concept for some analysts who aren’t as well versed in how networks/shared hosts, etc work, but with education, we should be able to fix some of this.

Example From the GRIZZLY STEPPE documentation

You can find reference to:
65[.]55.252.43
Observable ID: NCCIC:Observable-bfb9577a-f49e-49f8-8e71-02bf68e4cc1b
Which I’ve related to Indicator NCCIC:Indicator-3b9b8d85-ad2c-4759-83d7-b2b2d29e35be

The indicator is also related to a phase of the Lockheed Martin Kill Chain phase of “Command”.

Command IP Address defined from Lockheed Martin Kill Chain

After our research, (nslookup and whois), we determined this to be a Microsoft node used for telemetry.

NSLOOKUP

$ nslookup 65.55.252.43
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
43.252.55.65.in-addr.arpa name = msnbot-65-55-252-43.search.msn.com.

WHOIS

Snippet (Full Whois below):

NetRange: 65.52.0.0 – 65.55.255.255
CIDR: 65.52.0.0/14
NetName: MICROSOFT-1BLK
NetHandle: NET-65-52-0-0-1
Parent: NET65 (NET-65-0-0-0-0)
NetType: Direct Assignment
OriginAS:
Organization: Microsoft Corporation (MSFT)

Yep, that’s pretty straight forward that it’s part of the Microsoft block of IPs.  With a little networking-foo, it can be determined that this MAY have been observed during the incident.. and if it were a CDN (which this isn’t, from what we can tell), it MAY have been used to serve static content that acted as the C&C channel… but we know that this isn’t forever bad, or permanently bad.

Impact to Analysts

If you aren’t aware, give me a second to tell you about the startup I’m working on right now.  I’m building a platform that allows communities to share and detect threat intelligence data.  There are intelligence sharing communities out there (ISAC: Information Sharing and Analysis Center, ISAO: Information Sharing and Analysis Organization).   ISACs are centered around critical infrastructure, ISAOs are centered around companies/industries of like-ness.   Find more here:

National Council of ISACs

DHS ISAO FAQ

We pull in data regularly on behalf of our customers in order to allow them to effectively leverage the intelligence.   Essentially, we pull the data, and use it in our network monitoring platform to detect bad things for them.    In addition to ISAC/ISAO data, we provide a ‘community’ around the DHS AIS data.

Ok, that’s the context, now the reason I’m telling you this.

When a system like ours gets this ‘muddy’ intel data, our system lights up like a Christmas Tree.   Within an hour of the DHS AIS system having the GRIZZLY STEPPE data available, we started notifying our customers that they’re seeing those Observables (IOCs) on their network.    AWESOME!! Except that the data is pretty much determined to be a False Positive (FP).  Sure, the intel was found during the analysis to write up the paper for US-CERT/DHS, but now every consumer of that intel has to determine that this Observable is a FP.    Normally, every consumer would do this research.   Thankfully, with a shared community around DHS AIS within our system, we do the research once, and suppress it for the time being.   This goes to the power of a community as I write up in “Other People’s Analysts“.

Ok, if you don’t belong to an ISAC/ISAO, or any sharing communities, we’d be happy to help you find the right one.  Check us out at https://perchsecurity.com or email ‘info[@]perchsecurity[.]com’

defanging email addresses in a blog post feels so 1999, but, I think I still have to do it….

Thanks for reading!

chris.

Appendix

Full WHOIS

$ whois 65.55.252.43

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

#
# Query terms are ambiguous. The query is assumed to be:
# “n 65.55.252.43”
#
# Use “?” to get help.
#

#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=65.55.252.43?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange: 65.52.0.0 – 65.55.255.255
CIDR: 65.52.0.0/14
NetName: MICROSOFT-1BLK
NetHandle: NET-65-52-0-0-1
Parent: NET65 (NET-65-0-0-0-0)
NetType: Direct Assignment
OriginAS:
Organization: Microsoft Corporation (MSFT)
RegDate: 2001-02-14
Updated: 2013-08-20
Ref: https://whois.arin.net/rest/net/NET-65-52-0-0-1

OrgName: Microsoft Corporation
OrgId: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 1998-07-10
Updated: 2016-06-30
Comment: To report suspected security issues specific to traffic emanating from Microsoft online services, including the distribution of malicious content or other illicit or illegal material through a Microsoft online service, please submit reports to:
Comment: * https://cert.microsoft.com.
Comment:
Comment: For SPAM and other abuse issues, such as Microsoft Accounts, please contact:
Comment: * abuse@microsoft.com.
Comment:
Comment: To report security vulnerabilities in Microsoft products and services, please contact:
Comment: * secure@microsoft.com.
Comment:
Comment: For legal and law enforcement-related requests, please contact:
Comment: * msndcc@microsoft.com
Comment:
Comment: For routing, peering or DNS issues, please
Comment: contact:
Comment: * IOC@microsoft.com
Ref: https://whois.arin.net/rest/org/MSFT

OrgAbuseHandle: MAC74-ARIN
OrgAbuseName: Microsoft Abuse Contact
OrgAbusePhone: +1-425-882-8080
OrgAbuseEmail: abuse@microsoft.com
OrgAbuseRef: https://whois.arin.net/rest/poc/MAC74-ARIN

OrgTechHandle: MRPD-ARIN
OrgTechName: Microsoft Routing, Peering, and DNS
OrgTechPhone: +1-425-882-8080
OrgTechEmail: IOC@microsoft.com
OrgTechRef: https://whois.arin.net/rest/poc/MRPD-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

Bad URI Found:

http://efax.pfdregistry.org/eFax/37486.ZIP

Bad Domain Names Found

Bad File Hashes Found

Bad IP Addresses Found