Using traceback to find Mr. Wrong

Somebody is targeting one of your employees. First they sent a chatty message to Jack in accounting, posing as a coworker, asking Jack to e-mail confidential documents to a Hotmail account. Jack didn’t bite. Next they tried sending a message with a “zero-day” exploit for Microsoft Outlook. That attack failed because you run Notes in the office and Joe has a Macintosh at home. But the attacker isn’t giving up, and you’d like to know who it is. “Traceback” is your goal: That’s the term for using various tools and techniques to follow Internet connections or content back to their point of origin.

A naive analysis of the Internet protocol might lead you to believe that traceback should be easy. After all, every packet that’s sent over the Internet contains the IP address of both its destination and its source. So when packets containing nasty attacks or hostile content show up at Jack’s computer, you should be able to determine the guilty party just by capturing a few packets and then looking at the source address in their packet headers.

Alas, traceback runs into an increasing number of snags, depending on how thoroughly the attacker has covered his tracks.

Return to sender

First, you can’t trust the source address in the packet header. Most operating systems allow programs to fill in any address that they want. Denial-of-service (DoS) attacks are commonly based on the “ping” capability of the Internet common messaging protocol (ICMP) or on the user datagram protocol (UDP), because the Windows and Unix operating systems make it possible for any program to forge the return address. And since ICMP is frequently used for debugging network problems and UDP is used for streaming media like music and video, most organizations don’t want to block these packets.

Forgery is less of an issue with attacks that use the transmission control protocol (TCP). TCP is a bidirectional protocol that’s used for transmitting Internet traffic like webpages and e-mail. Because the protocol requires that both sides be able to communicate, an attacker who forges his source address with TCP usually won’t be very successful, because he won’t know what to send back to the victim computer to allow the connection to progress. But as it turns out, even though it’s very difficult for an attacker to forge an IP address with TCP, it’s still possible for him to hide his location rather effectively.

One way to do so is to bounce the attack through an intermediary, using simple techniques like finding an open proxy server, or complicated ones like renting time on a ‘bot net’ — that is, a network of compromised machines. This creates a chain of return addresses. Although you can try tracking backwards one jump at a time, such tracing is difficult and slow and will be problematic if there is an uncooperative ISP somewhere in the middle.

Given the limitations of using the return address, there are other ways that you can try to get the IP address of the attacker. You can send the attacker an e-mail message with a Web bug in it. Web bugs are very small images that monitor and report on who is reading a message or viewing a page. If the attacker is careless enough to open the e-mail on his computer, the Web bug can reveal the attacker’s location. Web bugs can also be embedded into Microsoft Office documents, so another tactic you can try is to leave a booby-trapped Word file where your attacker will discover it, and then wait to see if anybody triggers the embedded tracking device.

Unfortunately, getting somebody’s IP address is often just the first step of a traceback exercise. On today’s Internet, just about every IP address is assigned to an Internet service provider, a company, a governmental organization or a university. By consulting databases run by the Internet registries, you can pretty easily figure out the organization to which any given IP address belongs. But going from that organization to a particular individual is a much more difficult task. Although some organizations permanently assign each IP address to specific users, most use IP addresses that are dynamically assigned to different users at different times. In either event, you need the cooperation of the organization to consult either their administrative records or their log files. Some organizations won’t cooperate unless a court compels them. And in some countries the courts just don’t care about your plight.

Even if you have an IP address and the organization wants to cooperate, you might still be out of luck. The IP address might belong to a wireless access point — and it’s a very rare access point indeed that keeps detailed logs about who connected to it and when.

The IP address could also be wrong. In many cases the attacker can simply “borrow” the IP address of someone else in his organization. A sophisticated attacker will change both his IP address and his Ethernet address. Although every Ethernet interface sold today comes with a unique 48-bit address that’s burned in at the manufacturer, every interface on the market also can be reprogrammed to use any other 48-bit address. You can even do this trick with wireless Ethernet addresses.

Indeed, a sophisticated attacker can fake practically any kind of information that’s used for traceback. This point is made in great detail by Richard Clayton’s recently completed PhD thesis at Cambridge University in England. For example, many dial-up ISPs record the caller ID of every person who calls up to get Internet access. But caller ID can be faked by anyone who has control of a PBX that connects to the public telephone system over a digital interface. Indeed, it turns out that faking caller ID is a great way to frame somebody, although I’ve never heard of a case in which this was actually done. In his thesis, Clayton shows how everything from Ethernet addresses to DSL records can be forged — and in most cases, it’s impossible to detect that the forgery actually took place.

Fortunately, even if the traceback turns up empty, you still have a few other tries to find the perp.

Beyond traceback

If you have a Microsoft Office file from the attacker’s computer, you might hire an expert in computer forensics. Until a few years ago, every file created by Microsoft Office contained a globally unique identifier (GUID) belonging to the computer that created the file. By looking at the file’s GUID, it was possible to learn things about the computer that created the file. (Several years ago computer security expert Richard Smith used this technique to hunt down the author of the Melissa computer worm.) Modern versions of Office no longer stamp the GUID into every file, but there are other telltale traces that might be left behind — starting with things like the document’s “properties,” document changes and even Microsoft version numbers. Finally, there are linguistic models that can tell you if the writing of a particular document is similar to other documents written by one of your suspected perpetrators. Such models shouldn’t be admissible under the Daubert guidelines that govern the use of scientific testimony in U.S. courts, but they can nevertheless help you guide your own investigation.

If you are being attacked by someone who is using custom-written software, you might hire a specialist in software forensics to analyze the program. Software forensics is even less of a respected art than document forensics, but a good practitioner might be able to tell you if the code that’s in question is similar to other programs by known bad guys.

You might decide to engage the attacker or even infiltrate the attacker’s organization. Infiltration is a bit of a stretch but perhaps isn’t as hard as it seems. There are many cases of system administrators and security consultants engaging attackers over Internet chat. Many attackers are proud of their abilities, dismissive of their victims, and all too willing to taunt the subject of their assault. Others are willing to brag about their exploits on underground websites or meeting locations.

Every time they communicate with the outside world, there’s a chance that they will make a mistake and reveal their location or their identity. If you find somebody who is willing to chat, keep it up and build a rapport. Who knows? The bad guy might even take you into his confidence; there are precedents for this. Depending on who your attacker is, you might even be able to meet him in person at one of the numerous “hacker conventions” that routinely take place in Las Vegas, New York or Germany. You’ll have more luck if you are a twentysomething with a few tattoos and piercings than if you are a fiftysomething in a business suit. And truth be told, you’ll probably have more luck if you’re female — or if you hire somebody who is. Still, this “human intelligence” is always available and frequently underutilized.

To be sure, tactics such as software forensics and infiltration are a long shot, and if your attempt to find Jack’s attacker has come to this, it’s pretty expensive. That’s why most organizations just batten down the hatches and hope that the bad guy will target somebody else.

— Simson Garfinkel is researching computer forensics and human thought at Harvard University. Send feedback to machineshop@cxo.com.



Related Download
2016 Cisco Annual Security Report Sponsor: CompuCom
2016 Cisco Annual Security Report
Download The Cisco 2016 Annual Security Report for a closer look at how security professionals should respond to threats.
Register Now