The Security Skeptic

Identifying Cybercriminals: Is An IP Address Sufficient?

I'm often asked, “I’ve found the IP address of a criminal, where do I find information about the criminal associated with this address?

I’ve begun using the following explanation to help investigators so that they appreciate context and relationships between Internet identifiers – domain names, IP addresses, or Autonomous System Numbers (ASNs) – and criminal acts and actors.

People and networks use Internet identifiers to name or number individual computers (hosts) so that these can communicate. These identify location, for example, in the most basic interpretation:

• IP addresses identify Internet’s streets and house numbers
• Autonomous System Numbers identify the Internet’s “neighborhoods”
• Domain Names provide user-friendly ways to remember addresses, e.g., “My friend Matt’s house”.

Let’s imagine that you are investigating a complaint about illegal content (counterfeit goods, child abuse material, etc.). The complaining party gives you a domain name or URL. You use the DNS to identify an IP address that is associated with that domain name. This is the location where the content is being hosted or published, or perhaps the location where a spam or phishing email originated.

Some investigators are tempted to associate this IP address with the person whose published the illegal content in the same definitive manner as one might associate a fingerprint collected at a crime scene with an alleged perpetrator (or person of interest). Both of these are presumptive conclusions; for example, even in cases where a single fingerprint is collected at a crime scene, more evidence is necessary to prove without reasonable doubt that the person whose fingerprint matches the one found at the crime scene committed the crime. In many crime scenes, multiple fingerprints may be collected. This increases the list of persons of interest, and investigators must gather additional evidence to place a particular person of interest not only at the scene, but also at the scene at the time of the crime.

This is also true for an IP address. Different individuals can use an IP address at different times (at a public library or Internet cafe). Often, many individuals using a public or private network that uses network address translation (NAT) may share a public IP address. Thus, IP addresses pose additional hurdles for investigators:

• They can be spoofed, i.e., a criminal actor can forge an IP address and thus “leave some other person’s fingerprints”
• A criminal actor can relocate his illegal content from one IP address to another, or host that content from multiple IP addresses and thus leave lots of fingerprints over time.

Even if your person of interest uses a public IP address and the illegal content remains at this address as you pursue your investigation, you are in most cases confronted with – and about to be confounded by – the problem of associating this “fingerprint” with an actual individual. The situation an investigator most often encounters is similar to taking a fingerprint from a crime scene and finding no match among all the available crime databases:

• The provider of the service where the content is hosted (or where the content is originating from) has inaccurate or fraudulent contact data, or the contact data is accurate but further investigation reveals that the criminal forged, hijacked or impersonated an innocent party or exploited an innocent party’s resources (e.g., a web site).
• The IP or Domain registration data (Whois) has inaccurate data or fraudulent contact data, or (again), the registration data are accurate, but further investigation reveals that the criminal forged, hijacked or impersonated an innocent party’s identifiers (e.g., a domain name).
• The contact data in any of the above scenarios is “privacy” protected and the party that provides this confidentiality service won’t cooperate with the investigator (without a court order).
• You can’t serve a court order because any of the above party’s do not recognize your jurisdiction.

All these hurdles reinforce the following: gathering the addresses or names allegedly associated with a criminal activity is necessary but not sufficient evidence collection to “identify the criminal”. A law enforcement colleague I contacted agrees, noting that, “Knowing the shot that killed John F. Kennedy came from Book Directory wasn’t enough to prove Lee Harvey Oswald was the shooter.”

What do you do next?

My law enforcement and private sector colleagues all give me the same answer:

Police work.

Revisit the crime scene. In a real world investigation, you’d look for camera footage, shell casings, and fiber remnants. Are there any data that you haven’t yet used but might use to find evidence by flexing your google-fu? Your person of interest may be no different than any other Internet user. He may use social media and perhaps may brag about or unwittingly share his “accomplishment”. Have you searched Facebook, Twitter, or other social media using digital trace evidence you found?  Have you canvased the digital neighborhood? You may find and associate other addresses or domain names with the crime, and registration or other data associated with these may reveal more about your person of interest or his conspirators. Can you single out individuals who associate with your person of interest and among these, can you identify potential informants, or turn a co-conspirator? Was malware associated with the crime? Bomb makers have unique signatures and often, so do malware authors.  And the obvious: can you question the person of interest and obtain a confession?

Many crimes today have both real world and online components, and no small part online investigations involve the same police work and investigative methods as real world investigations.

It’s tempting to imagine that there’s a silver bullet of evidence among the identifier data you collect but it just isn’t so.

Criminals haven’t adopted online crime to make finding them easier.

 

A special thanks to my colleague Mert Saka for inspiring this post.

Domain Name Seizures Prominent in Dismantling the ZeuS botnet

On 19 March 2012 Microsoft, FS-ISAC , and NACHA filed a Complaint with the US District Court, Eastern District of New York, against thirty nine John Doe defendants who allegedly participated in a criminal enterprise, the Zeus botnet.

Microsoft alleges that ZeuS botnets have purportedly infected an estimated 13 million PCs and have been used to steal over $100M during the past five years. The official Microsoft blog post provides a summary of Operation b71, which involved seizures by US Marshalls of command and control servers in Scranton, PA and Lombard, IL., sinkholing of traffic for subsequent analysis, and the seizure of Harmful Domains and IP addresses used to manage and operate the criminal botnet infrastructure.

Photo by ElDave

Gary Warner and Brian Krebs have again posted excellent analyses of the ZeuS botnet takedown.  Rather than duplicate their efforts,  I’ll instead highlight what I thought to be aspects of the ZeuS Complaint that went beyond actions from earlier takedowns (see Coreflood). I’ll then focus on the seizure of Harmful Domains and comment on the value of providing complete and accurate DNS, Whois, and registry information in legal orders. 

The Complaint and the xTRO 

Microsoft, FC-ISAC, and NACHA identify the 39 John Doe Defendants by their fictitious names: the user IDs of email addresses of the defendants found in Whois records for the thousands of domains enumerated in the Complaint. The claims for relief include the usual suspects Microsoft has included in prior complaints against Rustock, Coreflood or Kelihos: computer fraud or abuse, spam, electronic communications privacy violations, trademark or Lanham Act violations, trespass, unjust enrichment...

New among the claims for relief is the allegation that the 39 defendants acted in concert and conspiracy and thus violated the RICO (Racketeer Influenced and Corrupt Organizations) Act.

John Does 1-3 are alleged to have organized the racketeering enterprise and John Does 4-39 to have contributed various skills to the enterprise: botnet, exploit, and web software development, mule recruiting, botnet and hosting administration, domain and IP registrations.  Botnet customers and "cash out" operators who sold credit card and credentials obtained via infected PCs were also listed.

The Complaint thus alleges that certain defendants conspired as a group to construct the botnet, others used (“leased”) to commit criminal acts, and still others turned stolen properties into cash.

The Temporary Restraining Order is ex parte because the fraudulently composed Whois records are the only identification available to the plaintiffs.The Court accepted the plaintiffs' claims that harms cited in the Complaint will continue unless the defendants are restrained, and ordered simultaneous actions at hosting companies (Continuum Data Center LLC and Burstnet Technologies, Inc.) 'to disable and seize servers and associated stored data' at hosting centers and to monitor and collect traffic for analysis.

Photo by xfordy

John Doe Defendants

The Court also ordered domain registries with US presence to assist in discovering the true identities of John Does 1-39, redirect traffic to servers at a Microsoft secured IP address and to disable Defendants' IP addresses.

It's noteworthy that the order sought to minimize collateral damage to parties that are not named as defendants but are affected by the seizure of equipment and disconnects.

Seizing Harmful Domains

Domain names and name servers play a prominent roles in the ZeuS criminal enterprises. "eCrime" name servers operated by criminals are used to resolve host names for command and control servers and for servers that host ZeuS files.  In Guidance for Preparing Domain Name Orders, Seizures & Takedowns, I explain that providing complete and unambiguous information to domain name registration providers can prevent confusion or delay, and may help prevent or minimize collateral damage. The ZeuS xTRO is a good case study for why I believe this guidance paper is important. 

In my thought paper, I point out that seizures typically instruct registries or registrars to modify the TLD zone file, the domain name registration record (and what is displayed by Whois), and the registry database (of domain names). In the ZeuS botnet xTRO, the Plaintiffs instruct the TLD registry operators to take the following action:

"2. For currently registered domains, the domain name registrant information and point of contact shall not be changed and associated WHOIS information shall not be changed;

"3. Domain names shall not be deleted or otherwise made available for registration by any party, but rather should remain active and redirected to IP address 199.2.137.141;

"4. Domain names shall not be transfered to any other person or registrar, pending further notice from the court.

"5. The Registries shall assume authority for name resolution of domain names to IP address 199.2.137.141 using the name servers of the Registries;

"6. Name resolution services shall not be suspended"

Instruction (2) is clear with respect to preserving registrant and point of contact information, but a consequence of saying only that "associated WHOIS information shall not be changed" is that some of the Whois returned is exactly what was in the registration data "pre-seizure",some of the Whois returned has the registrant/contact information the same as "pre-seizure" but the name server information is changed to NS1.MICROSOFTINTERNETSAFETY.NET, and Whois for some (try FILMV.NET) returns conflicting NS data from the the "thin" .NET registry and the sponsoring registrar. These inconsistencies might have been prevented if specific instructions for how name server information associated with the domain name had been provided.

(3) and (4) instruct registries or registrars to set domain status codes. These are adequately clear, but to eliminate any ambiguity, the order might have specified the exact EPP Status Codes for both registrar (client) and registry (server).

(3) further instructs the registries to keep the domain names "active and redirected to IP address 199.2.137.141." Neither instructions (3) nor (5) make clear whether the Plaintiffs are asking for changes to TLD name server configuration, name service for each domain name listed in the Complaint, or hosting, so they could be interpreted to mean that the registries are supposed to modify the name server configuration information ("glue") in the TLD zone file. They could also mean that Registries should provide name resolution for the Harmful Domains (which would be well out of scope).

A DNS lookup using the dig command shows that 199.2.137.141 is asssociated with a name server, NS1.MICROSOFTINTERNETSAFETY.NET.  In this case it was easy to deduce that the Plaintiffs' intention was that Microsoft was to act as the authority for the nameservers and would provide authoritative name resolution for the domains from a name server operating at IP address 199.2.137.141. In other (future) cases, orders could more accurately say "we want TLD name servers to be configured so that the authoritative name server for all the Harmful Domains listed in the Complaint is NS1.MICROSOFTINTERNETSAFETY.NET/199.2.137.141". The Plaintiffs are then in a position to decide whether to host zone data for the Harmful Domains or to return NXDOMAIN for hosts in the Harmful Domains".

(6) instructs that "name resolution services shall not be suspended". A random sample of the names in the xTRO shows that some return non-existent domain (NXDOMAIN) and some timeout without a response. So by some definition, either (6) was not executed properly by some parties subject to the order but the instruction did not make clear whether "name resolution services" applied to the TLD, which is responsible for identfying the name server(s) associated with the Harmful Domains listed in the Complaint, or resolution of host names associated with the Harmful Domains.

Closing remarks

Inaccuracies and ambiguities are not uncommon in legal orders, in part because the courts or plaintiffs are unfamiliar with the DNS or domain registrations, are imprecise when using domain name-related technology, operations, and terminology, or pressed for time. Checklists like those provided in Guidance for Preparing Domain Name Orders, Seizures & Takedowns may be beneficial in minimizing omissions and inaccuracies. 

David Dittrich has written a brilliant post on the Zeus botnet civil action entitled Thoughts on the Microsoft "Operation b71". One of the points he makes dovetails nicely with what I've discussed here:

"The act of writing up a complaint, backing it up with declarations in support of the plaintiff's motions, and having a federal judge review and grant plaintiff's motions is a very clear, very thorough, and very public justification for taking bold action. This process explains of who is being harmed, how they are being harmed, what can be done to stop the harm, and why the court should grant the plaintiff's motions. If this were a federally funded research study on developing a treatment for a disease, it is this level of detail that must be provided in order to get approval from ethics review boards. If we require such justification of doctors doing risky medical research that can harm us, why should we not have to similarly justify risky actions we take to resolve infected computers? This is the kind of standard that is warranted in order to show defensible justification for taking risky and aggressive action, before such action is initiated."

A late, final word

A recent analysis of operation b71 by Michael Sandee calls attention to the easily overlooked issue that collateral damage is not limited to suspending or making legitimate domains or web sites unreachable. A criminal enterprise the size of ZeuS will no doubt be the target for numerous investigations. Absent sufficient information sharing, cooperation, coordination and trust among investigating parties, there is too much room for error or interference, and one party's success can hamper the erstwhile and equally important efforts of others. Looking ahead, providing clear instructions for domain registries or registrars can be an important part of the level of detail that Dittrich insists must be provided.  Coupling this with the kinds of reasonable efforts Sandee encourages to verify that domains listed in complaints are "harmful" when the legal orders are executed is equally important to minimize collateral damage.