De-Coder’s Ring

Software doesn’t have to be hard

Month: December 2016

Grizzly Steppe: Lighting up Like A Christmas Tree

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.


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

Title Description Count
Malicious IPv4 Indicator This IP address is located in China. 45
Malicious File Indicator It is recommended that network administrators review systems for the existence of this hash and determine possible malicious activity. 17
Malicious IPv4 Indicator This IP address is located in France. 11
Malicious IPv4 Indicator This IP address is located in Japan. 6
Malicious IPv4 Indicator This IP address is located in Canada. 6
Malicious IPv4 Indicator This IP address is located in Thailand. 6
Malicious IPv4 Indicator This IP address is located in Mexico. 3
Malicious IPv4 Indicator This IP address is located in the United Kingdom. 3
Malicious IPv4 Indicator This IP address is located in Puerto Rico. 3
Malicious IPv4 Indicator This IP address is located in Italy. 3
Malicious IPv4 Indicator This IP address is located in Luxembourg. 2
Malicious IPv4 Indicator This IP address is located in Iran. 2
Malicious IPv4 Indicator (empty) 2
Malicious IPv4 Indicator This IP address is located in India. 2
Malicious IPv4 Indicator This IP address is located in Brazil. 2
Malicious File Indicator This DLL is a fully functioning Remote Access Tool and variant of OnionDuke malware family. The following text is … 1
Malicious FQDN Indicator It is recommended that network administrators review traffic to/from the IP address to determine possible malicious activity. 1
Malicious FQDN Indicator The Remote Access Tool malware “AE7E3E531494B201FBF6021066DDD188” attempts to use this C2. 1
Malicious IPv4 Indicator This IP address is located in Mongolia. 1
Malicious IPv4 Indicator This IP address is located in Kenya. 1
Malicious IPv4 Indicator This IP address is located in Cambodia. 1
Malicious IPv4 Indicator This IP address is located in United Kingdom. 1
Malicious IPv4 Indicator This IP address is located in Ukraine. 1
Malicious IPv4 Indicator This IP address is located in Austria. 1
Malicious URL Indicator It is recommended that network administrators review traffic to/from the URL address to determine possible malicious activity. 1

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:
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

Non-authoritative answer: name =


Snippet (Full Whois below):

NetRange: –
NetHandle: NET-65-52-0-0-1
Parent: NET65 (NET-65-0-0-0-0)
NetType: Direct Assignment
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


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 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!




$ whois

# ARIN WHOIS data and services are subject to the Terms of Use
# available at:
# If you see inaccuracies in the results, please report at

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

# The following results may also be obtained via:

NetRange: –
NetHandle: NET-65-52-0-0-1
Parent: NET65 (NET-65-0-0-0-0)
NetType: Direct Assignment
Organization: Microsoft Corporation (MSFT)
RegDate: 2001-02-14
Updated: 2013-08-20

OrgName: Microsoft Corporation
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: *
Comment: For SPAM and other abuse issues, such as Microsoft Accounts, please contact:
Comment: *
Comment: To report security vulnerabilities in Microsoft products and services, please contact:
Comment: *
Comment: For legal and law enforcement-related requests, please contact:
Comment: *
Comment: For routing, peering or DNS issues, please
Comment: contact:
Comment: *

OrgAbuseHandle: MAC74-ARIN
OrgAbuseName: Microsoft Abuse Contact
OrgAbusePhone: +1-425-882-8080

OrgTechHandle: MRPD-ARIN
OrgTechName: Microsoft Routing, Peering, and DNS
OrgTechPhone: +1-425-882-8080

# ARIN WHOIS data and services are subject to the Terms of Use
# available at:
# If you see inaccuracies in the results, please report at

Bad URI Found:

Bad Domain Names Found

Bad File Hashes Found


Bad IP Addresses Found

Other People’s Analysts

Over the last 6 years, I have been entrenched in Cyber Security.

  • Packet capture
  • Network Forensics
  • Identity and Access Management
  • Threat Intelligence

During my nPulse Technologies days (acquired by FireEye), I relearned all the network packet stuff that I had been taught in college.  The OSI network layers, VLANs, Q-in-Q… oh boy!    Reassembling packets (with python no less) was a REALLY fun exercise…  never made it into the product, since there were open source tools that did it better (faster?).. but I did it….   then came the challenge of using the reassembled data in an application.

Imagine this now, you’re a cyber analyst.  You’ve got some juicy intel from your ISAC (FS-ISAC? NH-ISAC?) … or maybe it’s from your industry buddies that you share intel with.   You set up your alerting mechanisms, you set up your SIEM, and you wait.

PING!  You get a hit!   You know now have an IP address that a machine in your network tried to go to.   You start your research, do a little OSINT, do some googling… find out it’s a shared host.  Oh well.

False Positive.

You tell your buddies, and that’s it for the day.

Guess what just happened?   Your group just got smarter because two of you did some work.  The first guy set up the intel, and you validated it as a false positive.    Since you both shared within your community, you just got smarter! You leveraged a few members of the community to make you all better!

This is the best scenario we have today.   Some communities share data.  Not many communities allow for automatic sharing of sightings (did you see that IOC in the wild?).  NO communities allow you to share what you did in regards to that IOC.  Did you block it in a Firewall? Did you mark it as a False Positive?

There aren’t many tools out there that can help this process..    The more we can share, the more we can attribute, the more we can automatically know what’s going on in the network of our peers, the safer we’ll all be.


Mini Rant: Stix Confuses My Computer

For some background, please see my post here


Here at Perch Security ( we’re building a community intelligence sharing platform that adds value to existing intelligence sharing communities… (our marketing folks say that better than I do!).

I’m building a bunch of services to ingest external intelligence, normalize, persist etc. I’m very thankful for standards such as TAXII (transport) and STIX (intelligence).

Reading a STIX doc makes sense for an analyst. The document gives great context around some piece of intelligence. An analyst can look it over, figure out some bad IP addresses and figure out what to do with them. The challenge comes with machine to machine communication. STIX can be used to relate Observables (IP addresses) into context.

For example, when analysts set of a new Indicator (the story of why we care about these IP addresses), they can set a relationship between ports and IP addresses. The facts are the observables (Port 80, IP: etc.

So, looking at this net flow, -> , we can very quickly determine that it’s a DNS request from an internal IP to Google’s DNS server. If that was determined to be malicious, the STIX should be set up like this:

Observable 1: IP
Observable 2: Port 53
Observable 3:
Observable 4: Port 6633
Observable 5: “Observable 1” AND “Observable 2”
Observable 6: “Observable 3” AND “Observable 4”
Observable 7: “Observable 6” AND “Observable 5”

See the tree?

– Description: “There’s a story here about malicious DNS traffic going to host on port 53. We observed this on our network from an internal client”
– Observables: “Observable 7”

So, an analyst reading that understands what’s going on. The immediate issue though for a Machine, is that the ‘internal’ IP part is effectively useless. No big deal, I can programmatically ignore internal IP addresses.

BUT, The REAL problem comes with fast analysts or bad tools. My Stix document comes back looking like this:

Indicator –
– Description: “Bad IP address found”
– Observables: “Observable 1” OR “Observable 2” OR “Observable 3” OR “observable 4”

That’s just plain wrong! Now, all my signature triggers on ALL DNS requests.

I see an education opportunity here for analysts using tools that create this intelligence. Not calling them wrong, but it’s an opportunity to learn to use the tooling a little better to improve all of our communities.

What’s your Risk Tolerance?

I keep running around saying “Go Big or Go Home”…. a lot of times appropriate, sometimes maybe not..

It almost sounds like the stupid “YOLO” trend that went around the internet.  YOLO: You only live once.  This mantra was used to justify doing stupid.  Drugs, Party, Lottery, Not Saving for Retirement… a plethora of stupid.

Today, I wanted to talk about risk tolerance, and when is it appropriate to Go Big or Go Home.

What’s the balance between risk and reward?

  • Personal Finances
  • Career
  • Specific Job
  • Technology Choices
  • Marketing
  • etc

I’ve spoken with many colleagues about leaving the ‘saf’e corporate world to go to a startup.  I’ve done it a few times ( new one can be found @ ).   I get a lot of comments like:

  • “Oh man, I’m so jealous, I wish I could do that..”
  • “Don’t you worry about stability?”
  • “Going without my 401k is blasphemous, there’s no way!”
  • “My job is stable, I’m not interested..”


I get it.  It’s hard to jump into the unknown.  It’s hard to leave a role, or a company that you’ve been with for 10 years (people still do that??).  It always comes down to fear.  Now, I’m not saying if you don’t go to a startup then you’re scared.  I’m saying, if you WANT to go to a startup, if you WANT to try something new, but you’re scared, that’s when there’s a problem.

The majority of jobs in the US are for small companies.  If you find the right company, solving the right problem for the right people, take faith in your ability to problem solve.

For me, I’ve gotten myself into a level of confidence around my employment abilities that I’m not too worried.  If I lose my job,  I’m confident I’ll be able to find a new one.  Heck, THAT role could be even better.   I tend not to be all ‘doom and gloom’, (unless I’m going through a serious case of the “impostor syndrome” …. seriously, that’s for REAL), but I’m confident that I have knowledge, skills, experience etc, that will be valuable to another employer.

Because of these traits that I’ve internalized, I can accept a higher level of risk in employment.   Start ups are my jam.  I can work well in any environment, but I find passion building something new. There’s an excitement in a tiny company that’s unrivaled. Think about it.. if you’re at a large mega bank (no insult to mega banks, I may want a consulting gig some day), but if your project is late by a month. Meh, you’ll get yelled at.. You might get a bad review, might lose some of your bonus. That sucks. but , at a startup, if you piss off your biggest (and only?) customer, and they stop ordering. You’re done. The game is over.

Don’t hear that as “I like risk! I’m a glutton for punishment!”. It just shows the level of excitement… because now, imagine you pull an all-nighter, and get the updated code to a customer BARELY in time, and then they double their order. YES! You win! THAT’s the excitement. (True story, I’ll tell you over a beer, because it was fun.. and scary)

Here’s a list of books that are wonderful, and can really help:

This one is my current read.. blowing my mind:

**Referral links at amazon…. gotta buy my starbucks, yo!

And for fun:


© 2017 De-Coder’s Ring

Theme by Anders NorenUp ↑