ThinkstScapes 2013-AH1: On the China report

The Mandiant APT1 report that was released a week ago has been causing some consternation, which makes it a ripe topic for our ThinkstScapes service. This morning, we issued an ad-hoc update to our customers containing our views of the APT1 report. In short, the data is interesting, but does not conclusively point to Unit 61938. There are too many open questions to justify the finger pointing.

Take, for example, the markers released for the APT1 group. The report does not contain sufficient data to replicate the grouping of attackers bearing those markers into a single cohesive unit. By Mandiant's own admission the presence of a single marker is insufficient to tag an attacker as APT1, but thresholds are not provided for the number of markers required. In the end, it appears as if the classification boils down to an analyst's opinion, metrics are absent the public report. The entire report is founded on the notion that APT1 exists and is definable; should this not be the case, the report's raison d'être evaporates. Corroboration is needed in the form of convincing evidence.

In addition, the conclusion that blames hacks supposedly originating from an area the size of Los Angeles on a military unit's building in same area is weak. In this regard, the press' use of the word "neighbourhood" to describe Pudong is misleading. Today's ad-hoc update examines these and other issues in greater detail, and extracts the bits we believe matter for corporates.

To be clear, we do not defend China or absolve it from hacking or espionage; we have little doubt that it conducts such operations as, presumably, do the US and other sufficiently resourced nations. Permit me to repeat this: we are not saying the Chinese government does not hack the US. Our concern is with this specific report; it is the first concrete public attribution of ongoing espionage against the US, and, if the report sets the standard for attribution, future events will be highly muddled as competing hypotheses all meet the low standard set out in Mandiant’s APT1 report. Unfortunately it seems that contrary opinions are being subjected to a level of diatribe usually reserved for arguments of faith, not facts.

Part of the problem is that there is appears to be an information differential, in which a number of folks with apparent non-public information are saying "it's totally legitimate", while those without the information are saying "this does not follow". Mandiant can help the APT1 debate by releasing more data to reduce this differential, specifically:
  1. Is there further evidence that ties the subset of observed IP ranges to the Unit 61398 Pudong building apart from a WHOIS record? (Note that the fibre infrastructure was provided by a different company than the listed owner of the IP ranges.)
  2. The number of attacks that would be classified as APT1, except for the fact that their sink address (e.g. HTRAN receiver) was NOT in Shanghai. What is the method for arriving at this conclusion? Phrased differently, how much weighting does a Shanghai IP address have in the APT1 cluster?
  3. A timestamped listing of known APT1 connections with their associated IP addresses, which would show us the activity levels of APT1.
  4. Metrics showing how many of the APT1 markers are shared with other groups under observation, and to what degree? (i.e. what is the overlap of domains, address blocks and malware hashes across the various groups?)
  5. How many more profiles of APT1 members were discovered, and what confidence does Mandiant hold in them? It seems strange that such a large group with such poor opsec has not leaked many more profiles.
  6. What is the mapping between APT1-associated domain names and IP addresses at the time of observation?
  7. What confidence level is assigned to the APT1⇿Unit 61938 link claim?
  8. By what reasoning does Mandiant eliminate an explanation for the attack pattern that argues for small non-government teams operating in a loosely connected fashion rather than a cohesive and directed group of operators with a common approach?
These debates are important going forward. Putting aside patriotism and pride, there are important questions which remain to be asked about the attribution of online attacks, and the danger in jumping to conclusions is that, when the shoe is on the other foot, equally weak claims are possible by an opponent. Hopefully any forthcoming additional data will settle these questions and we can get back to our regularly scheduled navel-gazing.

Comments

Post a Comment

Popular posts from this blog

Simple Graphs with Arbor.js

Image
We recently released a tool at http://cc.thinkst.com to capture and collect infosec conference details. We commented on it [ here ]. One of the cooler components of it, is the ability to view the relationships between speakers/researchers who have collaborated. This post is a quick introduction to the library we used to build our graphs, with enough info to get you up and running in minutes. As I mentioned, we use ArborJS library which is a a graph visualization library using web workers and the popular jQuery . The API is really well documented [ here ] but like most people, I learn best by example (and there are precious few of these). Hopefully this post will fill that niche, and by the end of it you should have a basic understanding of how to use arbor.js in your project. Our Aim: We will be building a simple contrived example as seen in the image above. Project setup : Create a new html page and include script references to the following libraries (Download them from the links...
Read more

Small things done well¹

Image
Bad design is bad  In 2015 Moxie Marlinspike pointed out that the manual page for GPG is (now) 50% of the novel Fahrenheit 451. Any software whose man page approaches 20 thousand words better have a good excuse, and GPG can only gesture vaguely at decades of questionable design. GPG gets a bad rap but it isn’t really much of an outlier. Security software has a long history of crumby, unintuitive interfaces and terrible design choices. A deep dive into the factors behind awfully designed security software isn’t the purpose of today’s blogpost, but suffice it to say there is seldom pressure from the end users. Security software mandated by a security team is often rammed down users’ throats, so it doesn’t bother being pleasant. It’ll sell anyway. We’ve worked hard to buck this trend from our first version. It’s one reason why we are one of the few pieces of security software that customers actually talk about in terms of love: https://canary.tools/love Recently, we released a major...
Read more

Using the Linux Audit System to detect badness

Image
Security vendors have a mediocre track record in keeping their own applications and infrastructure safe. As a security product company, we need to make sure that we don’t get compromised. But we also need to plan for the horrible event that a customer console is compromised, at which point the goal is to quickly detect the breach. This post talks about how we use Linux's Audit System (LAS) along with ELK (Elasticsearch, Logstash, and Kibana) to help us achieve this goal. Background Every Canary customer has multiple Canaries on their network (physical, virtual, cloud) that reports in to their console which is hosted in AWS. Consoles are single tenant, hardened instances that live in an AWS region. This architecture choice means that a single customer console being compromised, won’t translate to a compromise of other customer consoles. ( In fact, customers would not trivially even discover other customer consoles, but that's irrelevant for this post. ) Hundreds of consoles runn...
Read more