07 Mar 2017
The Rise and Fall of an Empire
Angler, and to a lesser extent, Nuclear, were the predominant exploit kits (EKs) of 2015 and the first half of 2016 before suddenly disappearing early last summer. With plenty of money to be made on the distribution of ransomware and banking trojans, other EKs quickly filled the void. Neutrino and RIG were the first to respond, though Neutrino itself disappeared in September of 2016.
Around the same time, Empire, a privately-sold EK with roots in the more widely-available RIG kit, appeared on the scene, ostensibly to steal a piece of the crimeware pie. Sometimes referred to as RIG-E, Empire delivered a wide variety of payloads during the fall of 2016, including custom ransomware and banking trojans. According to Brad Duncan over at Malware-Traffic-Analysis and Palo Alto Unit42, Empire was often utilized by the EITest campaign, which had previously utilized Angler in great quantities.
Unfortunately for the purveyors of Empire, and fortunately for the rest of us, Empire’s reign was short-lived. Like its predecessors Angler, Nuclear, and Neutrino, Empire itself mysteriously disappeared at the end of December 2016.
While Empire enjoyed only a short period in the sun, RIG itself continues to operate successfully as does Sundown, another exploit kit seeing success in the wake of Angler. Additionally, it seems a new contender has appeared, seeking to take up the slack left by Empire. Seemingly a hybrid of Sundown and Empire, Nebula, first appearing for sale on February 17th, integrated an internal traffic direction system (TDS) seemingly salvaged from the ashes of Empire. For more information, check out Kafeine’s excellent post here.
As a long-overdue exercise in crimeware analysis using OSINT, I decided to take a crack at examining the Nebula EK infrastructure in an attempt to better understand the actors utilizing it and the payloads being delivered. What I found was both amusing and unexpected for an exploit kit so new to the scene.
All of the tools I use to perform this analysis are available either completely free of charge or as full-featured community editions. For visual analysis, I use Paterva Maltego. As data sources used to expand on and add context to the blogs of Kafeine and Brad Duncan mentioned above, I use ThreatCrowd, ThreatMiner, Alienvault OTX, and RiskIQ’s PassiveTotal. All of these offer transforms for Maltego either directly or via other community members.
Brian Krebs: EK Peddler
Analysis begins with a single Nebula EK delivery subdomain provided by Brad Duncan’s analysis of a recent Nebula infection chain: ehpcc.chggannel[.]stream. As a starting point, I dropped the subdomain into PassiveTotal:
Clearly, the subdomain is brand new, having been first seen (and in fact, last seen) on March 2nd, resolving to a Worldstream IP out of the Netherlands. We’ll come back to the IP and the rest of the chggannel domain in a moment. What immediately proved far more interesting to me was the whois record for the domain. Whois pivoting is not always reliable, nor is it always even possible, depending on the registrar used and the OPSEC practices of the actor. Fortunately, in this case, the actors gave us something to work with.
So it seems Brian Krebs has turned to a life of crime and is now a member of the Yugoslavian Business Network? As amusing and unlikely as that is, we likely have a couple of interesting indicators to work from, including a whois name, e-mail, org, and perhaps a phone number. PassiveTotal is a fantastic source for this kind of data and we should be able to pivot on those indicators to learn more, provided the actors have used them with any consistency. Before we move to Maltego and continue exploring, let’s check out the rest of that domain. Looks like there are two other subdomains here, giving us a good starting point to work from:
We’ll go ahead and drop the domain into Maltego and add in the other Nebula domains provided by Brad Duncan’s post. As a first step, we’ll pull in the whois details for all four domains to see whether or not we have consistent indicators to work with:
Sure enough, we’ve definitely got consistent use of the same data for the whois records.
Quickly pivoting through the registrant name, e-mail, org name, and phone number in PassiveTotal show that the e-mail and phone number have the most consistency, as there are obviously some legitimate domains registered by real people named Brian Krebs. There are an identical 114 domains registered with the [email protected][.]com e-mail adress and the same phone number. We’ll go ahead and pivot inside Maltego off the e-mail and pull back all the domains PassiveTotal knows about registered with that address.
Pivoting from these new domains to their IPs by pulling the Passive DNS results from PassiveTotal brings back a whopping one IP. Why? Mr. Krebs seems to be making extensive use of subdomains. The second screenshot shows what happens when we pull in all the subdomains for the domains present, the entity count of the graph nearly triples.
Once more pulling in the IPs via Passive DNS, we see that 300+ domains and subdomains return to only fourteen IPs, in the red-orange color. It should be noted that a few of these IPs are shared webhosts and that the legitimate domains are not displayed on this graph.
Unfortunately, ThreatCrowd, ThreatMiner, and Alientvault OTX all return no results when I attempt to query for malware samples observed at the domains registered by this actor. Further, none of the domains or subdomains host SSL certificates according to PassiveTotal. Accordingly, we’ll wrap up our pivoting here, having exhausted the unique whois indicators provided by the Nebula actors.
Nebula’s Extent and Payloads
In order to clean up the graph and ensure all the data is likely relevant to Nebula, we want to take a look at the registrations from a temporal perspective. Of the 114 domains registered using the farcical Brian Krebs moniker and [email protected][.]com at the time of writing, 12 were registered in May of 2016. All 12 of these domains were also registered under a different whois org name,
ISP. Since February 8th, 2017, 102 domains have been registered under the [email protected][.]com combination, of which 97 used Yugoslavian Business Network as their org name. Curiously, however, the 12 domains registered earlier have active subdomains observed during the recent Nebula campaign.
Little additional information can be gleaned from the OSINT sources I have available to me, but from the analyses performed by Kafeine and Brad Duncan, we know that Nebula leads to a variety of payloads including DiamondFox, Gootkit, Ramnit, and Pitou. With the exception of Pitou, which is a spambot, all of these are bankers. At this time, there is no evidence the Yugoslavian Business Network actors are distributing ransomware via Nebula.
The Yugoslavian Business Network actually has a significant history with the Sundown EK. According to Ed Miles at Zscaler, the first indications of Yugoslavian Business Network involvement with Sundown began in July of 2016. At this time, however, it was unclear how the group, which advertised their coding services in German on forums, was associated with Sundown. By September, Trustwave indicated that the Sundown actors had “outsourced” their DGA work to the Yugoslavian Business Network. By the end of October 2016, Nick Biasini at Cisco’s Talos Intelligence concluded that Yugoslavian Business Network indicators were associated with all Sundown landing pages and that Sundown’s actors were operating a very large domain shadowing and wildcarding operation to power the exploit kit’s spread. Interestingly, he also concluded that the payloads from this operation were exclusively banking trojans.
Given the close historical ties between Sundown and the Yugoslavian Business Network, it is probable that Nebula is simply a new iteration on the existing Sundown exploit kit, operated by the same actors or a closely related group of actors. The willingness of the Yugoslavian Business Network to flaunt their moniker throughout their involvement with Sundown squares with the appearance of that name in the whois records for the Nebula campaign. Additionally, two other calling cards of the YBN appear to be present in the Nebula campaign, the use of subdomains/domain wildcarding and the almost exclusive delivery of banking malware vs. ransomware. Finally, the gang at Digital Shadows has additional details, including tweets from @CryptoInsane and @666_KingCobra (the alleged author of the Terror exploit kit) which seem to indicate that the Nebula source code offered for sale is in fact that of Sundown.
As an alternative hypothesis, it is possible that the Nebula activity I have analyzed here is indicative of a copycat operation, designed to look like the Sundown/YBN activity using the leaked source code. However, I believe that the balance of the evidence supports the original conclusion and that this is probably not a copycat operation.
In a follow-up to this post, I will be detailing the process of using PassiveTotal to set up a public project and the monitor function to track the YBN actor and Nebula campaign. IOCs are provided below. As always, I invite comment, debate, or criticism @swannysec.
Passive Total Project
Alienvault OSX Pulse (Note: Due to an ingestion issue, not all domains/subdomains present)
Yugoslavian Business Network
09 Aug 2016
If you’re reading this, you’ve likely noticed that this blog and my twitter account have been quiet of late. Summer is often a busy time, but my reasons for that are different than usual this year. Over the last few months I’ve been engaged in a lengthy recruitment and interview process and I’m really excited to share that after a decade in public higher education, I’ll be joining Scott Roberts and the other fine folks at GitHub next week! I’ll be working in some form of DFIR role, but I’m not exactly certain what it will entail over the long run; GitHub is still a growing company after all. In the near term, I intend to play Robin to Scott’s Batman or perhaps serve as “Bad Guy Catcher Minion” while I learn as much as I can and find my “sea legs.”
Sidebar: When I set this blog up almost a year ago, I chose this theme completely unaware that Scott had done the same and didn’t realize it until months later. Great minds think alike? Either that or I just rode his coattails all the way to GitHub.
While I won’t go into great detail on the matter, I do want to take a moment to discuss GitHub’s recruitment process. All of my interview experience (both as an interviewee and interviewer) prior to GitHub was extremely formal and restrictive, as might be expected of a state agency. GitHub’s process couldn’t have been more different; it was refreshingly open, honest, and relaxed. This shouldn’t, however, be confused with an easy interview process. GitHub’s process involved multiple video interviews, phone calls, hands-on exercises, and a marathon (for someone new to the public sector world) in-person interview with both technical and non-technical personnel. None of these steps were cake, though I enjoyed every one and learned a lot during most of them as well.
The most fascinating part of the process for me was that each conversation was a two-way street. Not only were my interviewers genuinely interested in my input on challenges they faced at GitHub, but I was able to share some of my own challenges, receiving meaningful input in return. I walked away from many of the conversations with valuable lessons learned and as a better professional, no matter the outcome. That’s a neat feeling, and the further I got into the process, the more I realized that sort of welcoming openness was endemic to GitHub’s culture. Everyone I’ve met so far has been wonderful and despite the length of the process and the inherent stress of any interview situation, I have enjoyed the process enormously. Fortunately, I walked away with more than just lessons learned!
So where do we go from here? I’m presently suffering from an enormous case of imposter syndrome. The professional challenges involved in moving to GitHub are not insignificant. The environment is a complete 180 from the one I’ve just spent a decade operating in, save some philosophical similarities. Additionally, I’m going from a very broad infosec role that included engineering, architecture, policy and compliance work, and only some IR work, to a more specialized role that will primarily handle IR. I will need to learn, or re-learn, a lot of new things both technically and in terms of business process. The near term will be dedicated to getting to know GitHub, building or rebuilding DFIR-specific skills, and moving back up Burch’s hierarchy of competence in an effort to defeat imposter syndrome and be a more effective incident responder.
I will continue to blog and tweet, though I expect my focus will shift somewhat from threat intelligence to DFIR matters as I tend to use the blog, and to a lesser extent Twitter, to flesh out and reinforce what I’m learning or working on. I will likely contribute with less frequency, however, as I have a lot to process as I onboard at GitHub and I have some personal goals for the coming year I’d like to devote some time to:
- Increase the quantity and quality of reading I do.
- My masters degree sort of killed my desire to read a few years ago, which is a shame. I was a voracious reader prior to that experience, and I believe I need to read more to further my personal development. To this end, I am pushing more of my reading, including blogs/RSS, to my kindle and trying to read away from a PC. This has the side effect of better quality sleep, as I tend to read in the evening and less screen-time will help.
- Tackle Python and eventually tinker with Go.
- I will likely never be a great writer of code; it simply doesn’t come naturally to this liberal arts major. I have to work really hard at it, and I honestly don’t enjoy it all that much. That said, I want to reach a point where I establish a reasonable level of fluency and I’m capable of better communicating with those who do write code well.
- Exercise more.
- Duh. I’m thirty now and I need to be in better shape. I’ve got a couple of awesome kids to be healthy for and I want to feel better too. I’d like to ride a bike a couple times a week and also go back to some weightlifting.
- Spend more time with my kids.
- I was seriously burnt out over the last couple of years. My kids are growing up fast and I want to enjoy this time. My oldest is getting into computers, gaming, and shares my love of military history (win!). My youngest is a stout-hearted wild-child that brings me equal joy and trepidation by way of a risk-taking sense of adventure. Both are bright, curious, adorable, and deserve more of Dad’s time.
- Begin speaking at conferences.
- I originally planned to begin speaking this fall or winter, but in light of the new challenges I’m taking on, I’ve decided to spend a little more time absorbing/observing and begin speaking next spring/summer. Nonetheless, it’s on my agenda.
Thanks for tagging along for this wild ride. I look forward to sharing more of my journey as I take on new challenges at GitHub. For now, off to GitHub HQ! As always, feel free to reach out to me @swannysec with your feedback!
17 May 2016
I recently had an interesting conversation with a couple of people from the threat intelligence community around the idea of adversary innovation. Essentially, someone linked to a twitter blurb from a recent convention or trade show where the speaker mentioned that we, as defenders, need to innovate faster because our adversaries are doing it every day.
The immediate reaction, from a couple of very smart people who I consider to be mentors, as well as my own reaction, was that the idea was hogwash; attackers are lazy like the rest of us and only innovate when forced to do so. This makes sense, right? Humans, as a species are inherently lazy, and I know for a fact that most of those involved in technical fields loathe extraneous effort. So, this idea that attacker methods are constantly evolving and we must rise to meet that challenge is surely patently false, correct?
Upon further reflection, I decided that our initial instinct was in actuality incorrect, and may, in fact, indicate a bias on our part. While there are certainly those attackers out there who will innovate only when absolutely forced to do so, and many who never do at all, I think these may represent a smaller sample of the total population than we realize. Those working in or otherwise involved in the serious study of threat intelligence tend to dwell in the land of the APT. We eat, sleep, and breathe cyber-espionage, state-sponsored actors, and super-sophisticated financial crime syndicates. We do this because it’s our job, because it’s what keeps the lights on, because it’s fascinating, or maybe just because we all secretly imagine ourselves to be Jack Ryan.
The reality, however, is that these kinds of threats probably represent a fraction of what the majority of the world contends with every day. In fact, for most, the biggest threat comes from financially-motivated commodity malware. The ransomware industry (and it certainly qualifies as an industry at this point) and banking trojans are likely responsible for far more damage to the worldwide economy than APTs and other sophisticated attacks will ever be. This year’s Verizon DBIR supports this conclusion, as summarized perfectly by Rick Holland below:
The shocking part of this realization, for me, came when I reflected on just how much innovation actually occurs in the malware industry. Take a look at any of the major ransomware or exploit kit campaigns over the last six months. The rate of change is astounding! I probably read two or three reports every week about how the actors behind Angler EK, Locky, TeslaCrypt, or CryptXXX have changed something in their delivery method, in their infrastructure, or their anti-detection measures. Here are a few examples:
It makes sense that commodity malware has to innovate more often. Their methods are simpler, more visible, and ultimately easier for defenders and their technology to defeat. Signature generation and alerting for commodity malware is likely automated or semi-automated by many, raising the stakes for those peddling that malware. If they fail to innovate, they stop making money as signatures and patch management invalidate their methods. APT groups or those engaging in cyber-espionage? Their methods are more complex and sophisticated, in addition to the added burden of attempting to maintain their persistence inside an organization without being detected.
At the end of the day, this is a problem most simply demonstrated by David Bianco’s Pyramid of Pain. In essence, the Pyramid of Pain illustrates the concept that the majority of indicators (IPs, hashes, domains) are simple and low cost/effort to either defend against or replace as an attacker while the more challenging, complex indicators like tools and TTPs are both hard to effectively defend against and costly for an adversary to replace. Commodity malware authors and distributors simply need to change their executable or packaging or their URL-redirect/gate scheme and push the change out across their delivery network, without regard for the noise they make while doing so. These changes live primarily at the bottom of the pyramid; they’re not terribly costly for the adversary. In the case of APTs and other sophisticated intrusions, however, most of their methods exist higher up the pyramid. Accordingly, the cost of changing those methods, particularly while avoiding detection, is quite high. No wonder more sophisticated adversaries innovate only when they absolutely must.
Now, armed with an understanding that the speaker we criticized initially was probably more correct than we gave him credit for, where does the bias lie and how can we combat it? Personally, I have to remember to pinch myself now and then and be mindful of the fact that the world really isn’t as full of Lotus Blossoms, PLATINUMs, and APT6s as it seems. While those types of things are amazing brain fodder for me, my own day-to-day job is a prime example of the broader reality, which is far less exciting.
Image courtesy floodllama, provided under a Creative Commons license.
That reality is that commodity malware is my organization’s single largest threat (which can be just as damaging, if not more so than some APTs). Further, the unfortunate truth is that those threats do iterate quickly. So, sometimes, it’s important to take off my whiz-bang intel wizard hat and look up from the ground; the perspective it brings is critical. I suggest we all take that step back and try to take in a little perspective now and then.
As always, I’d love your feedback; please reach out @swannysec.
12 Apr 2016
Some time ago, I did some analysis that linked a fairly run-of-the-mill Torrentlocker distribution network to actors and infrastructure delivering Pony. I promised some follow-up on that, and it’s still coming, but it’s proving to be a bit of a rabbit hole. I need some more time to dot my i’s and cross my t’s, but I hope to have something to share soon.
In the meantime, I wanted to take some time to write up another piece of research I recently completed on a group of well known Angler EK and Bedep actors. If you’ve followed along with Angler and Bedep over the last year or so, you’ll no doubt be familiar with [email protected], [email protected], and [email protected] These accounts are responsible for the registration of large numbers of domains associated with the distribution of Angler EKs and Bedep, as well as some other unpleasant creatures such as Kazy and Symmi. For more information, check out this great write-up from Nick Biasini over at Talos. An Alienvault OTX pulse with all the goodies is available, likely from Alex Pinto at Niddel, here.
Now that you’re familiar with the campaign in question, let’s take a deep-dive. For this analyis, I will be using Paterva’s Maltego loaded with transforms from two fantastic sources, PassiveTotal and ThreatCrowd. These are fantastic tools with free options that can get you started on some great analysis, so give them a try!
To begin, I entered the three well-known actors referenced above as e-mail entities in Maltego:
Once entered, I started by utilizing PassiveTotal to return all known domains registered by these addresses as shown in the screenshot below (do note that you could manually import these from the Alienvault IOCs provided above, as well). The results follow in the second image, that’s a lot of domains!
Enter ThreatCrowd. Let’s go ahead and enrich each of these domains with any available information ThreatCrowd has to offer (sorry for the API load, Chris!). Select all the domains as follows:
Once you have all the domains selected, use the following transform from ThreatCrowd. The results are below.
As you can see above, I’ve re-arranged the graph into the Organic layout in order to make the clustering around each registrant e-mail (in red) apparent. Below, observe a zoomed view of the links indicating domains from each cluster sharing IP infrastructure. The links are hard to see, so I circled them in red:
At this point, we have clear overlap between these three actors as they’re utilizing some of the same hosting providers and individual hosts to serve malicious domains. In order to go one step further, I expanded the graph again, this time by enriching all IP addresses with ThreatCrowd. (A note of caution here: this can return large number of domains if an IP you choose to expand is a large webhost, so take care to double-check whether returned entities are relevant.) Here’s what the graph looks like after one round of domain enrichment and one round of IP enrichment:
From here, I began working through new clusters of domains looking for new leads by checking whois records with PassiveTotal and looking for malware and other associated infrastructure with ThreatCrowd. After hunting around for a while, I discovered the following indicator, with new domains discovered from it circled in red:
This indicator uncovered something new. Below is a fresh graph, for clarity, containing the new domains discovered from that IP, followed by their enrichment via PassiveTotal’s whois details (scrubbed of all but registrant name, e-mail, and address):
Who is Sara Marsh, why is she registering obviously junky (and potentially DGA-generated) domains, and why is she sharing infrastructure with the likes of the actors we started with? At this point, I almost hit a dead end. Most of my normal, publicly available sources had no information of significance on Sara Marsh, her e-mails, or the domains she registered. ThreatCrowd showed her domains as adjacent to, but not directly hosting malware. Alienvault OTX had no information on her or her domains, and neither did most of the other sources I usually check. However, good old-fashioned google came to the rescue. A quick search of the new e-mail address revealed a pastebin paste from an anonymous source that referenced [email protected]
Post-compromise Bedep traffic observed to destination domains bokoretanom()net, op23jhsoaspo()in, koewasoul()com, and dertasolope7com()com.
Observed referers (forged - machines never actually browsed to the referers): loervites()com, newblackfridayads()com, alkalinerooms()net, new-april-discount()net, violatantati()com, nicedicecools()net, books-origins-dooms()net, adsforbussiness-new()com
Observed traffic patterns:
Bedep immediately opens a backdoor on the target machine; it also generates click-fraud traffic, and can be used to load further malware. Bedep was written by the authors of the Angler Exploit Kit, and as such, AnglerEK is the primary distribution method for this malware.
All observed domains are registered to Sara Marsh ([email protected]) and Gennadiy Borisov ([email protected]) through Domain Context. These are certainly fake names and email addresses, but appear to be used often. As such, they are reliable indicators, for the time being, that a domain is malicious.
While I don’t usually rely on anonymous sources, this simply served to confirm what was already fairly apparent from appearances. This was backed up by the presence of [email protected] on malekal.com’s malwaredb, sharing an IP with a domain from none other than [email protected]
At this stage, I added [email protected] back to our original graph, and used PassiveTotal to return all domains registered to that address. The result is below:
Here’s an additional representation using bubble view. This view adjusts the size of the entities based, in this case, on the number of links associated with them. Again, the actor e-mails are in red:
By now, it is readily apparent that we’ve uncovered an additional actor in this Angler EK/Bedep campaign. In order to further demonstrate some of the relationships between these actors, I selected four related domains from the graph above, moved them to a fresh graph, and enriched them with both ThreatCrowd and PassiveTotal (displaying only relevant results):
The above image displays in a nutshell the close relationship between these actors. Nick Biasini did some fine work in uncovering the first three actors; now a fourth is apparent as well. A list of domains registered to [email protected] is below; this can also be found in an Alienvault OTX pulse which is embedded below. The same list and the Maltego graph are available on my GitHub repo.
As always, I appreciate any feedback; give me a shout @swannysec.
Likely Angler EK/Bedep Domains Registered by [email protected]:
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.
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!