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.
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.
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.
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, 188.8.131.52 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:
The third file is a zip with the goods inside:
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: 184.108.40.206. 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, 220.127.116.11.
What kind of malware is Mr. Malkovich serving up at motohex.net and hexdroid.net? More ransomware? Looks like it.
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 18.104.22.168:
Let’s do a whois via Maltego and expand 22.214.171.124. 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.
27 Oct 2015
Note: This post is the first of a series of non-technical topics relevant to information security and other aspects of technology at large.
Education’s Place in InfoSec - Or: Certs, Degrees, and Experience, oh my!
Earlier this week on Twitter, Christian P. (@CYINT_dude), Kyle Maxwell (@kylemaxwell), and myself had a brief conversation about education. Education is a somewhat divisive subject in our field and it was nice to hear from them on the issue. Like others, I have very strong feelings about education, shaped largely by my journey and the impact varying types of education have had on my personal development and career. This post and its second part will outline my take on the topic, which is wholly personal and meant as food for thought.
One of the questions I see asked most often in public communities is whether or not a four-year computer science or other IT-related degree is a hard requirement for working in the security field. Let me be completely honest: in some cases, yes. Many positions require that degree as a bare-minimum foot-in-the-door differentiator. Technical degrees such as Computer Science or Cybersecurity provide a great starting point for someone interested in Information Security. That said, I find a hard requirement for a technical degree foolhardy and obtuse.
You’re probably expecting me to say I don’t think a degree is important at all; you’ll be disappointed. While it should not be required in most cases, a degree still has a lot of value. What I do believe, however, is that the degrees sought should not be limited to CS/IT fields. My Bachelor’s Degree is in Political Science with a focus on International Relations and a minor in History. So what’s this liberal arts yuppie doing in InfoSec? What might surprise you is just how valuable that degree has been for me. A degree in Political Science/International Relations will ensure that you can effectively communicate, both verbally and in writing. It will ensure you are well prepared to build, relay, and defend an argument. It will give you the foundations of good research and analytical procedure.
In short, such a degree will give you the ability to enrich and exhibit your technical skills for the better. As an added bonus, a background in International Relations is extremely helpful in understanding the geopolitical aspects of attribution, global cybercrime, and cyber espionage and warfare.
The benefits of non-technical degrees don’t stop with Political Science. Education majors are great teachers and communicators. Marketing, Finance, and Business majors understand the needs and realities of operating a business. Communications and Art majors understand the art of communicating their message to varying audiences visually or in other useful forms. Science majors develop excellent troubleshooting and analytical skills. I could go on for days, highlighting some huge benefits of just about any undergrad degree. So please, if you’re a student interested in InfoSec, or a recruiter or HR person, give serious consideration to non-technical degrees.
So, what about a Master’s Degree? Is it necessary? Probably not. Is it helpful? Absolutely. A Master’s allows you a hone the communication skills you developed in the course of a four-year degree. It often requires you to work in a more “professional” format, communicating less academically, and working in groups to accomplish tasks. Sound familiar? Just like the real world. (Detour: do yourself a favor and get your Master’s as soon as practical. The further out you are from college and the more you have going on at home, the harder it will be.) I recommend you seek a Master’s that’s markedly different than your previous education. If you completed a four-year liberal arts or business degree, go get a technical degree, or vice-versa. I got a Master’s in Information Assurance. This ensures you add context, broaden your horizons, and prove you can tackle multiple disciplines. Information security is a broad domain and it requires tackling multiple disciplines; do the same in your education and benefit!
All that said, are degrees the be-all-end-all? Absolutely not. Some of the sharpest security professionals I know don’t have any degrees. I respect them no less than those with degrees, and they’re just as important to their organizations as those with degrees. Certifications and practical experience also have a role to play, which will be discussed in greater detail in Pt. 2 of this series. In closing, consider a degree, or two! Be open to non-technical fields; enrich yourself and add context to your work. Feel free to give me your feedback @swannysec!
Photo Credit: Got Credit