11 Mar 2016
Over the next week or so, I’m going to cover, in short form, a couple of topics that have been rattling around my brain for a while now as I continue learning and growing more comfortable working with and thinking about threat intelligence. We are fortunate to have a wonderful community built up around the discipline and I’ve had the opportunity to interact with a lot of amazing people who provide immeasurable wisdom and perspective. Exposure to the community and my own work related to the field inevitably leads me to draw some conclusions and formulate some strong opinions, so here we go.
On Attribution
Whodunnit? Stop it! Stop right there. Before you ask that question, or allow it to be asked of you by management, you need to ask a different question first. Does it matter? While I believe attribution has its place in the analytical process associated with generating threat intelligence, I’m not of the belief it’s always relevant to an organization’s aims in producing that intelligence. While I’m certain that your execs would love to hear that “China did it,” does that matter to your organization? Can you actually do anything with that information?
Image courtesy Charis Tsevis, provided under a Creative Commons license.
Attribution, as with any other element of good threat intelligence, needs to be actionable for it to be relevant. See Richard Bejtlich’s post on attribution here for more on the value of attribution used properly. If you can successfully make a strategic, operational, or tactical shift on the basis of knowing who your adversary is, then by all means, attribute! However, I would imagine very few organizations possess the operational and intelligence maturity to respond meaningfully to knowing which specific cybercriminal, activist, or nation-state actor is targeting them. My personal belief is that all the time, effort, and hot air spent over attribution in our industry is largely wasteful. I will say that there is one key exception to this, however; attribution as an element of analysis (as opposed to an end-goal) may give valuable context to an analyst if they can pivot on some element of that attribution and use it to discover additional items of interest related to the actor. Be careful though, because attribution can also introduce cognitive bias! Robert M. Lee, a man much smarter than I, covers this topic and how attribution applies to the various levels of intelligence here.
Attribution is flashy. Attribution makes it sound like you really know your stuff. Attribution might even give your shareholders someone else to blame. However, if you’re producing intelligence with a stated goal of determining attribution, ask yourself if and how that is relevant to your requirements. If you’re able to translate attribution to meaningful action designed to prevent or respond to a threat, bravo, please continue! If you can’t figure out how to make attribution work for you, either as a component of a finished intelligence product or as an analytical tool, re-assess your goals and requirements and re-direct your efforts to more meaningful analysis that will produce real return on investment for your organization. Threat intelligence is hard enough to master and demonstrate the value of without wasting time pointing fingers to no end, so please, think before you attribute.
Your feedback is important, please head on over to @swannysec and share your thoughts!
05 Feb 2016
In part one of this series we looked at the basics of threat intelligence and how you can begin to absorb and apply it without any technological investment or barrier to entry. For the second installment, I had originally planned to write at length about some low-effort and low-investment methods of automating the ingestion, processing, and application of freely available threat intelligence sources. However, I’ve decided to take a bit of a detour because there are some pre-requisites for this type of intelligence automation and I believe they are worth looking at in detail.
Knowledge
While I’ve previously discussed the fact that you don’t need a fully mature information security program to begin working with threat intelligence, it is helpful to have at least a few things in place to make the most efficient use of threat intelligence data. To begin with, you’ll need one or more human beings capable of digesting threat intelligence data as I outlined in the first part of this series. No automated system is going to make any amount of threat intelligence data magically useful without a human being making informed decisions about the information contained therein as it relates to the security and risk posture of the organization. Once you’re ready to understand intelligence data and make decisions based on it and other data available to you, let’s move on to the next prerequisite.
Tools
Threat intelligence indicator feeds, regardless of whether any processing or filtering has been applied, will generate more data than a human can ingest and process via traditional means such as spreadsheets or simple graphs. Therefore, tools capable of accepting, parsing, and manipulating large data feeds are essential. The quickest way to this capability for many organizations will be a flexible SIEM or SIEM-like tool such as Splunk, ELK, or Graylog. These tools will take just about any type of log-oriented data and allow you to parse it and store it as you see fit. Another option is a SIEM that’s designed specifically to accept these feeds. Splunk’s Enterprise Security product will do so in addition to LogRhythm, ArcSight, Alienvault and others. In the next part of this series I’ll also look at some non-traditional, non-SIEM options for handling large intelligence data feeds.
Photo Credit: Julie Rybarczyk
Once you have a tool in place to help you process and understand large amounts of intelligence data in a meaningful way, you need to operationalize it in some manner. I split this capability into two levels of maturity, which I’ll delve into more in the next post, but can be roughly defined as visibility-only and enforcement. In order to implement visibility-only, you’ll need one or more security devices or systems capable of outputting useful log data that can be cross checked against intelligence data for evidence of malicious or suspicious activity. Possible sources of data ideal for this correlation include firewalls, endpoint logs, an IDS such as Snort, Suricata or Bro (see Security Onion), web proxies, or forensic artifact collectors like Google’s GRR, Mozilla’s MIG, or Facebook’s osquery. In a more mature program, some of those same systems, should they be capable, can be used to actively enforce decisions on intelligence-provided indicators when provided a correctly processed and formatted feed in which the analyst has high confidence. Palo Alto’s dynamic block lists, Symantec Endpoint Protection’s hash blocking, and even Microsoft’s own Group Policy hash rules are all examples of possible enforcement avenues. Again, more detail coming in the next installment, but let’s move on to the final pre-requisite for now.
Self-Awareness
Finally, before you even consider external sources of intel data, you need to be mining your own internal data sources for actionable intelligence. What can possibly be more relevant than data on what is actually happening on your network? (Author’s note: I wrote the preceding sentence before re-reading the links that follow in a table below. I feel dirty for unintentionally taking the words right out of Rick Holland’s mouth. Sorry Rick!) If you have any relatively sophisticated border controls (firewalls, IDS/IPS, proxy) or endpoint detection suites, they will likely be capable of producing basic reporting on threats seen in your environment. If you have a SIEM, you can glean even more from the data produced by those systems. Additionally, are you mining your incident/malware response process? There is valuable information about the “what, where, when, and how” of threats directed at your organization inside the logs and incident reports produced therein. The “why and the who” may be a little harder to glean, and are largely beyond the scope of this discussion, but all of that is possible with internal threat intelligence.
There is a ton of great work by people far smarter than myself that speaks to the value and methods of internal threat intelligence including things like hunting, which represents a maturity level far outside the scope of this series. If you’d like to know more, read here:
Remember, however, that this doesn’t have to be rocket science; we’re starting small. Generate top ten lists of exploits, malware, brute-force attempts, etc. and start to observe trends in those reports. Is a particular exploit targeting a particular host? Are you seeing an uptick in a particular strain of malware? Is one IP the source of many alerts all of a sudden or consistently? Dig a little deeper by looking at account activity. Failed logins, privilege elevations, password changes, and logins from unusual geographic locations all offer value for internal context. Also make sure you’re looking at your vulnerabilities and you have a reasonable inventory of the assets you’re defending; it’s critical that you understand the attack surface available to bad actors. Think about how all of this internal data speaks to @DavidJBianco’s Pyramid of Pain; can you start to discern actors and TTPs based on what you’re observing and put those findings to use in your decision making? If nothing else, begin learning the natural rhythms of your network; you’ll notice when things stand out! In short, make sure you’re looking at what’s happening on the inside before you begin adding external information to the picture.
As I noted in the first part of this series, however, once you have both internal and external data, put them together to form a holistic view of the threats to your environment; this broad view will enable better decision making and a more effective defense. Hopefully, you’re now equipped with a better understanding of the tools and techniques (TTPs anyone?) you need to have in place before you begin ingesting and operationalizing external threat intelligence data. In the next part, we’ll talk about the nuts and bolts of doing just that, as well as the caveats (external threat intel feeds are not magic; human analysts not included). Please reach out to me @swannysec, I’d love to hear your feedback. Thanks for reading!
Note: I will be taking a brief break in this series to run a few analysis pieces in the coming weeks.
14 Jan 2016
In my last post, which appears to have been eons ago, I asserted, contrary to the popular narrative, that I believe it makes a lot of sense for small or still-maturing information security programs to build a threat intelligence capacity. While this may not be a popular opinion, I know that smaller operations can benefit from a right-sized threat intelligence program because I’m in the process of building one currently and there have been tangible results. I also mentioned in my last post that I would provide some details on getting started with threat intelligence.
To begin, one must understand the basics of threat intelligence. I provided the following definition, from Gartner, in my last post:
“Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject’s response to that menace or hazard.”
This blog post will not attempt to teach you all the basics; instead, the focus is on how to start digesting and operationalizing intelligence. Other sources have provided background knowledge more comprehensively; in order to bolster your understanding, I recommend the following:
With the barebones basics established, how tall must one be to ride? In my estimation, you need a good head on your shoulders, a general understanding of the security space, threats, and countermeasures, and enough technical ability to understand and use the data you will be presented. You don’t need a complete infosec program or a whizbang black box racked in a datacenter somewhere. In fact, you don’t really need anything other than an internet-enabled device and your brain to begin digesting threat intelligence.
I recommend that anyone interested in threat intel start simply by seeking out and reading published threat reports from companies such as FireEye, Palo Alto, or Symantec. A large repository of these reports can be located on Github here. In particular, check out the following as excellent examples:
I also recommend that one follows the twitter feeds and blogs of people who do this kind of work for a living and share what they can with the rest of us. Check out Christian P. at his blog and Scott Roberts at his. Learn how they approach threat intel and take their lessons learned into account as you begin your journey. Finally, check out a few of the intel sharing repositories available without expenditure. I recommend Alienvault’s Open Threat Exchange for the general public and CIRCL’s MISP instance if your organization is eligible. These are both excellent sources of human-readable threat intelligence data, but also offer ways to automate collection as you grow into your new threat intel capability.
The key to starting with simple human consumption of publicly available threat intelligence is that one becomes accustomed to how the data is collected, analyzed, and presented. As you digest the information in the reports, start thinking about your own organization. How would you identify this activity on your network? Have you seen any evidence of this in logs? Can you prevent this activity? Can you put proactive alerting in place? This is valuable as a mental exercise and can be translated to real action as your understanding and tools mature. You might even stumble across one of these threats in your organization in real-time. At the most basic level, even if you do nothing further, you are putting threat intelligence to good use by completing this mental exercise and better arming yourself as an analyst with things to watch for and build defenses against.
Ultimately, no matter how you consume and process threat intelligence data, the goal should always be to provide a tangible benefit to your organization by altering or augmenting decision making around both preventative and detective security measures. Learn from the lessons others have endured and prevent your organization from being the victim of something that is already well documented and understood.
In part two, we’ll take the next step by introducing tools such as Bro IDS, Splunk, and CIF, that will facilitate the automated collection and processing of some types of intelligence data. As always, I’m eager to hear your feedback; please reach out @swannysec.
07 Nov 2015
Last week I read a lot on twitter and elsewhere regarding threat intelligence and its place in an organization. A ton of very smart people have strong opinions on this matter, and those opinions cover a wide spectrum, but one trend I’m noticing is that many believe threat intel has no place in an information security program that isn’t fully mature. Many, including many vendors selling platforms or feeds, seem to think the only way to implement threat intel is to drop a fully operational intel capability into a complete, mature information security organization. Many are saying that “we” as an industry need to temper our expectations on threat intel and only apply it when we’re in a position to dedicate 100% effort and resources to it.
As my grandfather would say, “we is a horse turd.” In other words, I don’t subscribe to that way of thinking, and I’m not interested in being part of that “royal” we. I believe threat intelligence has a place in most organizations and can provide value to smaller, less mature information security programs.
Let’s begin with a definition of threat intelligence, provided by Gartner in this particular case:
“Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject’s response to that menace or hazard.”
There are a couple of key things to note about the definition above (which, sadly, does not involve trenchcoats, hats, and hiding in bushes). First, intelligence is comprised of a number of different types of information to include context, indicators, mechanisms, and actionable advice. Second, note carefully the actionable part and that the remainder of the definition states that the intelligence derived can be used to inform how the subject responds to threats.
Given this information, I was taken aback to discover a tweet from an employee of one of the leading threat intelligence providers stating that considering scraping indicators from a public threat report to be good threat intelligence was “doing it wrong.” I challenge this assertion. Working for a small organization (one security professional), I may not be able to make strategic adjustments to better align my whole organization to defend against the actor or his more complex TTPs; what I can do, however, is put those indicators to use immediately to better inform my operations. If those indicators have matches in my environment, be they traffic logs, file hashes, or e-mails, you can bet I’m going to initiate an investigation or formal incident response. Going back to the definition, did I not use derived intelligence to inform how I responded to a threat? Would I have ID’ed the activity without those indicators? Sounds like textbook threat intelligence to me!
Don’t believe me? Take it from some people who live and breathe threat intelligence, Dmitri Alperovitch and Adam Meyers, Co-Founder and VP Intelligence respectively, at Crowdstrike. In an excellent podcast from Down the Security Rabbit Hole, they state unequivocally that organizations can start small with “finished intelligence” feeds that are actionable by analyzing them with a SIEM or feeding them to an enforcement device for blocking. Of course they mention that a more mature organization can derive more from threat intelligence, particularly at the strategic level, but they don’t devalue starting small either! Check it out here. The discussion I’m referencing begins at about 15:30 and runs through 21:30.
Threat intelligence is not an all or nothing proposition. Small organizations can, and should, implement a threat intelligence capability scaled to their maturity level. No one advocates attempting to plop a fully matured infosec program in place on day one. Why should we take the same approach with threat intelligence? Let threat intelligence mature on a scale along with an information security program and make it an integral part of those information security operations.
If you’re still with me, and you want to start small, I’ll outline a few ways to do so in a follow up post in a few days. I’d love to hear some feedback; you can find me @swannysec.
Photo Credit: Emory Allen
31 Oct 2015
If you’re just here for the IOCs, you will find a link to them at the bottom of the post.
It all started with a routine glance at some log data. I noticed a significant uptick in suspicious DNS queries for the subdomain above; thousands were dropped by our security gear over the course of six hours or so. Unfortunately, I have been unable to determine the vector for these because we don’t have full PCAP abilities under normal circumstances. Nevertheless, I was interested in what this subdomain might have been serving up. What I found initially was not terribly surprising. What I found when I continued investigating, however, was a huge surprise. This post will demonstrate how free and open-source intelligence and analysis tools can reveal complex relationships and uncover shared malware infrastructure.
I need to begin with a few caveats:
- I am not a professional analyst. I am a multi-discipline security engineer responsible for everything from firewall rules, to writing policy, to DFIR. Analysis is 5% or less of my job and is a hobby.
- Malware reversing is not a strength of mine. As such, I will not spend a lot of time with the malware discussed in this post. If you’d like to break it down and make a guest post, please contact me! Otherwise, please feel free to write it up yourself, I’d love to know more.
- All of the tools used to conduct this analysis are either open-source or free accounts for various services.
- I have omitted some data in the analysis, such as phone numbers.
- The free versions of Maltego and PassiveTotal have significant limitations which mean that the analysis is not fully “fleshed-out.” I will continue to work on this case going forward.
With that said, let’s get started!
My first step was to enter the subdomain into threat_note, a handy research and indicator tracking notebook from @brian_warehime. Threat_note will pull back whois data, passive DNS where possible, and a nice ThreatCrowd visualization with a quick link to pivot into ThreatCrowd.
Not much to see here unfortunately. Just a subdomain behind a private registrar. Let’s go up a level and look at that root domain. I dropped it into threat_note as well:
Still not much new here, but as with the original subdomain, there is some unusual data present. A Russian registrar located in Nobby Beach, Queensland, Australia? Certainly bizarre, my interest is now piqued. Let’s scroll down a little further and take a look at the ThreatCrowd visualization.
Now we’re cooking! There are malware hashes, a nice network of subdomains, and an IP all associated with
poytowweryt.com. In order to understand what we’re looking at, understand that ThreatCrowd pulls data from a variety of public intel and analysis sources such as VirusTotal, malwr, and Payload Security and correlates it with its own history of DNS and whois data. Data ingested includes domains/subdomains, IPs, malware hashes, and whois information. Let’s hop into ThreatCrowd via the handy pivot link provided.
A substantial network of subdomains is present, all linked back to a single IP. How about the malware?
Definitely has some unwanted behavior associated. And what is Slenderness? Whatever it is, I stole it as a campaign name for threat_note. Let’s look at VirusTotal, what is this thing? Looks like a fairly standard Crypto-variant ransomware, though some vendors appear to be classifying at a Zeus variant or the Androm Backdoor. A google search of the IP hosting it, 51.254.140.74 brings us to abuse.ch’s SSL Blacklist. Ah, it’s TorrentLocker; that will surely ruin someone’s day!
So what do we have so far? Looks like a small distribution network for ransomware. That’s a pretty common thing these days, likely a dime a dozen if you’re really looking. Let’s hop over to Maltego and explore a little more using ThreatCrowd and PassiveTotal transforms.
This is the first domain expanded via the ThreatCrowd transform. As noted above, I do not have access to the full version of Maltego, so all the subdomains are not present.
The next step is to enrich the IP using the ThreatCrowd transforms. These transforms basically extend all the search and correlation power of ThreatCrowd right into Maltego.
Here we can see the IP hosts the second piece of malware from the main domain as well as a bunch of the subdomains that represent it. At this point, I want to be sure I’ve got the full history of the IP, so I elect to transform via PassiveTotal and pull back their entire passive DNS history (sadly I cannot do this for all of the IPs during the investigation due to limitations of the free account).
The result is a new domain not picked up by ThreatCrowd, highlighted below! The PassiveTotal results are available below as well.
Now we’ve got a new lead. Enriching itroxitutr.net gives us a new IP and we can see it’s hidden behind the same suspicious registrar as before, based on the contact e-mail present.
Expanding the discovered IP leads us to new malware and two new domains.
At this stage, I went back to threat_note for some whois data (it can be produced in Maltego too). Recognize what’s circled? It’s that same shady domain registrar. Aside from the direct DNS associations, there’s a very obvious theme present in that all of the domains are registered behind an unusual private registrar.
The IP itself, however, gives our second clue in terms of Geolocation (the first being the TLD of the registrar). It’s hosted in Ukraine. That won’t shock anyone in our line of work, but it certainly raises the probability of nefarious intent given the other indications present here. See below.
What can we learn about the malware related to itroxtutr.net?
Looks like more crypto-variant ransomware, very similar to what was hosted by the original domain, quite likely TorrentLocker again. At this stage, we’ve discovered two separate IPs fronted by a good number of domains and subdomains all serving ransomware. Still nothing out of the ordinary present here, but this is a great exercise nonetheless.
Expanding and enriching the two new domains lunoxdyv.com and towovker.com brings the following results:
What do we have here? More malware and our first actor, that’s exciting! We’ll leave Mr. Malkovich alone for a bit and check on the malware. More ransomware according to VirusTotal:
0e66f3725446fb6502e91830582452de
e242fdb77bb2d75bfc29c086ddd4985e
The third file is a zip with the goods inside:
c8f5cd83c585dee882dc531a29b14e85
78cc33f7f5be12aa7871dd854de1741b
Before expanding things any further, here’s a look at an overview of what we have discovered so far. It’s reaching a point that it is difficult to take readable screenshots, especially if I use the hierarchical views. It would appear that these may be two slightly different malware networks sharing a common piece of infrastructure: 93.171.159.109. Unsurprisingly, that IP is on the SSL Blacklist for being a TorrentLocker C&C host. There’s a nice write-up on TorrentLocker from @marc_etienne_ at ESET here.
We want to continue following the breadcrumbs, so let’s go back to Mr. Malkovich. What can we find out by pivoting off his address via ThreatCrowd?
We’re not in Kansas anymore, Toto! That makes two new domains. Expanding those domains reveals yet more malware and a shared host, 191.1.156.96.
What kind of malware is Mr. Malkovich serving up at motohex.net and hexdroid.net? More ransomware? Looks like it.
09e54636eb4de5e782cc19a9b7dcf267
98ac006fdb0880711509a51ab4901eec
ebacb76eb45d6800da6f4f074ae24e61
e9923215f43335260ad445ebf9375035
2e902e458d88cea396a9cf73068db07d
Sure enough, it’s TorrentLocker again! Taking a look in threat_note for the whois records of these domains brings something very interesting:
A name to go with that e-mail! Sergey Yashin, perhaps a play on a retired ice hockey player. Though a likely alias, let’s pull the whois in Maltego and draw a link between Sergey and his e-mail. I’ll revisit Sergey in another post.
From here, I expanded the malware hashes and checked for other communication. False positives have been removed, such as communication to Windows Update. Looks like everything communicates with 194.1.156.96:
Let’s do a whois via Maltego and expand 194.1.156.96. At this point, I have to apologize because the relationships start to become so tangled that it’s difficult to work in Maltego and display things in a way that’s organized:
So, now we have three more domains and a new actor, Alexey Morozov (I omitted the listed phone number). In addition, the IP is not owned by Sergey Yashin as I had expected. How strange! Alexey is a malware author, as seen here on the file detail tab. It’s also possible he’s really an attempt at registering as another hockey player. Sad to see retired hockey players need to supplement their income in this manner (obviously, again, these are likely aliases).
Once we expand wsevgocis.com and hosiroxair.net, we find a familiar sight, the same anomalous private registrar from our earliest findings:
At this point, we’re still in a network that appears to be dedicated to the distribution of ransomware, primarily, if not entirely TorrentLocker. That’s about to change. Let’s expand madfortgoes.ru. Just one link, to a piece of malware, and no useful whois information. Is this a dead end?
Investigating the malware brings about something substantially more nefarious than TorrentLocker.
It looks like we finally have our first link to something more than ransomware. If we assume the commenter is correct, we’ve clearly left pure TorrentLocker network. On top of that, it’s dropped by Pony/Fareit. Let’s expand that potential bot:
There’s a lot to process here. I begin by expanding the IPs first (I left the whois details out as they do not appear to be relevant):
The IP’s don’t reveal any complex relationships so I began digging through the domains. Rearmheadfire.com is the only domain with whois data and additional links outside this network, as seen below:
At last, this is where we hit our first undeniable links to the Pony botnet after the mention from the VT comment above. Damballa has a fantastic write-up available here. Contained within is the following:
Well, hello! Looks like a clear link indeed from our rinky-dink TorrentLocker network to the Pony botnet!
Here’s what the final view looks like in two different formats:
This is by no means the end of this network, but this post is long enough. I am continuing to investigate and my current view looks something like this:
What conclusions can we draw from this analysis? First and perhaps foremost, open source and free tools can be tremendously powerful. Beyond my own hardware, I didn’t pay a dime for any of this data or the tools to analyze it. The result is pretty interesting; I managed to uncover, in the span of an evening, a link from an operating TorrentLocker distribution network to the Pony botnet. Second, this analysis reveals that malware infrastructure sharing and reuse is likely prevalent among Eastern European cybercriminal groups. As I continue to analyze this case, I’m curious to see if there will be links to additional malware distribution networks. I spoke with Brian Warehime about this and he mentioned something really interesting: changing infrastructure and TTPs is expensive. The bad guys probably have their own version of the Pyramid of Pain in which it is more costly and resource consumptive to change certain parts of their operation. Finally, and perhaps unsurprisingly, these cybercriminals are making heavy use of private registrars and false whois data to shield both themselves and their infrastructure.
I welcome any comments or additional analysis! Find me over at @swannysec.
The IOCs generated by this investigation are hosted on github. For now, a Maltego Entity file is all that’s available. As soon as I can get my hands on a full version of Maltego I will add CSVs (CSV export is disabled in the free version). IOCs will be updated as I progress through additional analysis.
Credits:
