Who Was The First To Use The Term Exfiltration?

Information security professionals seem to use the word exfiltration with increasing frequency. However, it remains a relatively geeky way of referring to the process whereby data leaves a compromised network. That’s why I was surprised to see VeriSign use this term to describe its 2010 data breach in a 2011 SEC filing when saying, “Information stored on the compromised corporate systems was exfiltrated.”

First Use of Data Exfiltration with the SEC

VeriSign isn’t the first company to introduce the term exfiltration into SEC documentation in the information security context. As far as I can tell, the first mention can be attributed to SRA International. SRA’s May 11, 2009, 10-Q statement mentions several malware infections identified by the company’s IT and security staff. It continues:

“While we have not determined that specific information was exfiltrated, our forensic analysts suggest that the virus was designed for this purpose and, based on indirect evidence found, there is the possibility that data was compromised.”

These were probably the incidents that prompted SRA to file a notice with the Maryland Attorney General and notify its employees and customers of the breach in January 2009.

Origins of the Term Exfiltration

Oxford English Dictionary defines exfiltrate as:

Withdrawing “(troops, spies, etc.) from a dangerous position.”

It also refers to exfiltration as the “action or process of filtering out” and points to a geological book published in 1866 by P. H. Lawrence. In it, the author states:

“The opal is a product of exfiltration from the rock in or near which it occurs.”

The first mention of the term in the context of information security that I could find dates to the unclassified NSA paper published in 2002 and titled Microsoft Office 2000 Executable Content Security Risks and Countermeasures. It explains:

“Customizations with VBA or ActiveX provide a powerful programming capability within Office applications. An attacker can write a wide range of attacks from altering system settings and exfiltrating information to dangerous denial of service attacks such as deleting all files on a hard drive.”

Do you know of earlier uses of the term exfiltration, especially when used to discuss data breaches? I’m curious.

— Lenny Zeltser

Some Facts and Conjecture About the VeriSign Data Breach

The web is abuzz with stories about the 2010 data breach that VeriSign reported in its Oct 28, 2011, 10-Q statement. The document devotes a couple of paragraphs to the breach and includes the following:

“In 2010, the Company faced several successful attacks against its corporate network in which access was gained to information on a small portion of our computers and servers. We have investigated and do not believe these attacks breached the servers that support our Domain Name System (‘DNS’) network. Information stored on the compromised corporate systems was exfiltrated.”

VeriSign further explains that its information security team detected and responded to the incident. That in itself isn’t a big deal, as successful attacks occur on regular basis among companies large and small. If this were the full the extent of the situation, it wouldn’t be worth including in as part of the 10-Q filing. SEC disclosure guidelines published in October 2011 state that companies “should disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky.”

VeriSign’s mention of the breach in 10-Q implies that the incident was significant, probably because of the kind of data that was compromised. This theory is supported by VeriSign highlighting that although it “is unaware of any situation in which possibly exfiltrated information has been used, we are unable to assure that such information was not or could not be used in the future.”

VeriSign’s disclosure further states that “given the nature of such attacks, we cannot assure that our remedial actions will be sufficient to thwart future attacks or prevent the future loss of information.”

This description sounds like the company believes they were dealing with an APT-style attack. One of the characteristics of APT incidents is that it is very difficult to remove the adversary’s presence from the corporate network. Such efforts may take years and tend to be very expensive.

There is much conjecture regarding what occurred at VeriSign, given how few details the company released to the public. My hope is that VeriSign will do a better job than RSA did at providing a frank and comprehensive explanation of the affected products or services in a timely manner.

Other articles about the 2010 VeriSign breach from across the web:

• Key Internet Operator VeriSign Hit by Hackers by Joseph Menn
• VeriSign Hacked, Data Stolen by Darren Pauli
• VeriSign Hit by Hackers by Bill Brenner

From a more general perspective, I suspect we’ll be hearing more about such breaches due to the relatively recent guidelines published on breach reporting by SEC. How many large critical infrastructure haven’t been compromised at this point? How many of them actually know that this has happened?

— Lenny Zeltser

Incident Response on 64-Bit Windows Using 32-Bit Tools

Incident responders and forensic investigators need to be careful when using 32-bit tools to examine file system artifacts on 64-bit Windows. Christian Wojner documented the issue in a paper titled The WOW-Effect. He demonstrated how the WOW64 File System Redirector built into 64-bit Windows transparently redirects 32-bit tools’ access to core OS directories and registry values. This is likely to confuse forensics personnel performing live analysis of the system.

Christian explained that “64‐bit versions of Windows provide backward compatibility for 32‐bit executables.” For instance, a 32-bit application accessing %windir%\System32 will be transparently redirected by the OS to access a corresponding file in the %windir%\SysWOW64 directory. “In other words, a 32‐bit application will never see any file stored in System32, it will always access SysWOW64 instead.”

Consider the situation, described in Christian’s paper, where the investigator uses the classic md5sum tool (which is usually 32-bit) to look at file that corresponds to a suspicious process…

On my 64-bit Windows 7 laboratory system, I called a demo file “myfile.exe” (0d07469c97791d2d51a6317f84f75025) and placed it in the C:\Windows\System32 directory. I placed a different file (ec75883fdc02c259026e0585e720dfe7) under the same name in C:\Windows\SysWOW64.

I used 32-bit md5sum to read the file from C:\Windows\System32. The OS redirected the program to read from C:\Windows\SysWOW64 without any visual indications that this occurred:

However, when I use a 64-bit tool for calculating the MD5 hash of the same file, I get a different value. This value corresponds to the actual file under C:\Windows\System32 that I intended to examine:

That’s because when the 32-bit md5sum program attempted to read C:\Windows\System32\myfile.exe, the OS transparently redirected it to C:\Windows\SysWOW64\myfile.exe.

You can see a video of my little demo on YouTube.

Christian pointed out another scenario that might mislead incident responders: It’s not uncommon for investigators to upload suspicious files to VirusTotal for malware scanning. However, if the investigator uses a 32-bit browser, then he or she will be uploading a different file than what would be uploaded using a 64-bit browser.

If you’re concerned about this issue, stick to using 64-bit tools when performing live analysis of 64-bit Windows systems. If you’re using 32-bit tools, there is another approach to accessing contents of C:\Windows32, though this doesn’t work for other files and registry items that Windows might redirect. Instead of attempting to access %windir%\System32, access %windir%\Sysnative to avoid redirection. Thanks to Tyler Hudak for telling me about this:

For more details and examples regarding this issue, see Christian’s The WOW-Effect paper. 

— Lenny Zeltser

The Adversarial Cycle of Computer Attacks and Defenses

Understanding the dynamics of the actions taken by computer attackers and defenders is tricky, in part because attackers’ motivations and methods vary. Tao Stein, Erdong Chen and Karan Mangla defined a promising model, called the adversarial cycle, in the paper that describes the Facebook Immune System. The authors described the cycle using a diagram that I recreated below:

The authors explain that “during Attack, the attack has not yet been detected and is largely unfettered. During Detect, the attack has been detected but the system is forming a coherent response.” These aspects of the cycle are controlled by the attacker, because the defender isn’t yet in a position to disrupt the attack.

“During Defense, the attack has been rendered ineffective. The attacker may eventually detect this and begin Mutate to work around the defense mechanism.” In this phase of the cycle, the defender exerts control by restricting the attacker’s actions, until the attacker adjusts offensive tactics and reengages.

Representing the adversarial cycle in this manner helps not only understand the goals of both parties in the attack scenario, but also predict tactics. The authors explain that:

“The defender seeks to shorten Attack and Detect while lengthening Defense and Mutate. The attacker seeks the opposite, to shorten the bottom phases while lengthening Attack and Detect.”

Shortening the half of the cycle that attacker controls usually increases attacker’s costs.

Defenders can shorten the half of the cycle that attackers control by detecting attacks faster and by locking down the environment more tightly. Historically, defenders have been focusing on blocking attacks, without having sufficient detective capabilities.

Defenders can gain further advantage by lengthening the half of the cycle that they control by making it harder for the attacker to analyze the defensive actions that took place and bypass the controls. There are many ways of accomplishing this, including the use of deception in defensive practices.

By automating their activities, both parties in the adversarial cycle can gain an advantage. For instance, attackers might automate the Mutate action through the use of polymorphic malware or automated script obfuscation. Attackers might automate Defense by using intrusion prevention systems.

To learn how Facebook used the adversarial cycle model to automatically curtain malicious activities, be sure to read the Facebook Immune System paper.

Hand-picked related posts:

• 6 Ideas for a Protean Information Security Architecture
• The Big Picture of the Security Incident Cycle
• Tips for Starting a Security Incident Response Program

— Lenny Zeltser

8 Reasons for Denial-of-Service (DoS) Attacks

Denial of Service attacks (DoS) affect numerous organizations connected to the Internet. They distrupt normal business operations, are practically impossible to prevent and are costly and time-consuming to handle. It pays to spend some time understanding the way a DoS inicident might affect your organization and how you might handle the situation.

One way to start thinking about your ability to withstand and respond to DoS attacks is to consider why such incidents occur. The common reasons include the following:

• Extortion via a threat of a DoS attack: The attacker might aim to directly profit from his perceived ability to disrupt the victim’s services by demanding payment to avoid the DoS attack.

• Turf wars and fights between online gangs: Groups and individuals in engaged on Internet-based malicious activities might use DoS as weapons against each others’ infrastructure and operations, catching legitimate businesses in the cross-fire.

• Anti-competition business practices: Cyber-criminals sometimes offer DoS services to take out competitor’s websites or otherwise disrupt their operations.

• Punishment for undesired actions: A DoS attack might aim to punish the victim for refusing an extortion demand or for causing disruption to the attacker’s business model (e.g., spam-sending operations)

• Expression of anger and criticism: Attackers might use the DoS attack as a way of criticizing the affected company for exhibiting undesirable political, economic or monetary behaviors.

• Training ground for other attacks: Attackers sometimes might target when fine-tuning DoS tools and capabilities for future attacks, which will be directed at other victims.

• Self-induced: Some downtime and service disruptions are the result of the non-malicious actions that the organization’s employees took by mistake.

• No apparent reason at all: Many victims never learn why they experienced a DoS attack.

Handling a DoS incident involves operating under stressful circumstances, often with limited resources and time. To learn how to prepare for dealing with a DoS attack and what to do if you’re caught unprepared, see my Network DDoS Incident Response Cheat Sheet.

— Lenny Zeltser

Process Hacker as an Alternative to Process Explorer

Process Hacker is an open source replacement not only for the built-in Windows Task Manager, but also for the popular Process Explorer tool. Process Hacker implements many of the same features that Process Explorer has for examining local processes, and adds a number of unique capabilities that are especially useful when examining an infected system or analyzing malware.

Like Process Explorer, Process Hacker can display the listing of running processes in a tree-like fashion, showing you the parent-child relationship between the processes. Both tools color-code the entries based on the processes’ characteristics:

Process Hacker can visually identify processes that are being debugged, those are associated with services and those that were packed. You can see the legend and change color assignments by selecting Hacker > Options > Highlighting:

Process Hacker includes a separate tab for listing active services, and a tab showing active network connections. The tab shows local and remote IP and port details and identifies the local process that owns the connection:

Process Hacker shines in the number of capabilities it offers for analyzing and manipulating a particular process. For instance, right-clicking the process presents you with various menu options:

Selecting Properties gives you several tabs. One of the most useful ones is Memory, which lets you the ability to view contents of the process’ memory, extract strings, search based on regular expressions and even modify memory contents.

Other capabilities of Process Hacker include the ability to locate some hidden processes, inject a DLL into a process, create a service, locate file handles and DLLs, and many others. The best way to become familiar with the tool is to experiment with it. Give it a try, then be sure to share with others what you have learned.

• 3 Free NirSoft Tools for Malware Analysis
• Process Monitor Filters for Malware Analysis and Forensics
• Using Netsh for Easier Network Setup in a Malware Lab

Just so you know, I teach the malware analysis course at SANS Institute.

— Lenny Zeltser

How to Get into Digital Forensics or Security Incident Response

The field of digital forensics and incident response (DFIR) is attracting a lot attention among information security professionals and law enforcement officers seeking to progress in their careers. One of the challenges of entering this field is that employers often limit their recruitment efforts to experienced forensicators. What can people seeking to get into this industry do?

It seems that organizations rarely want to invest into growing the skills of a beginner forensics or IR analyst. As the result, individuals seeking to get into DFIR should look for opportunities to pick up relevant skills as part of their current job responsibilities. Some ideas and examples:

• If you have system administration duties, start getting to know the steps and tools used to investigate suspected security incidents. Gradually incorporate these utilities into your toolkit. Examine logs for security events. If you encounter a suspicious executable, begin experimenting with it in a malware analysis lab from a behavior-monitoring perspective.

• If you have a network administrator role, become familiar with the essential aspects of network intrusion detection. Use the network troubleshooting tools you already know, but dig deeper into the traffic to identify potentially malicious patterns. Play with network forensics puzzles.

• If you have a programming background, get to know assembly. Pick up a free disassembler and debugger and begin exploring benign programs using these tools. Identify interesting code sections and spend time understanding their inner-workings. When you feel comfortable, start looking at malicious executables.

• If you’ve been performing file system and related forensics tasks, start incorporating additional utilities into the toolkit you use to examine the evidence you already feel comfortable collecting. Look at the artifacts you didn’t consider earlier. Research their meaning and ask questions about what you find.

The idea is to obtain some baseline DFIR knowledge by building upon what you already know. Look for ways to do this in the context of your current job responsibilities without undermining your commitments to your employer. Supplement the research and experimentation you can do at work with studying and exploring on your own time. Read books on the relevant topics, keep up with DFIR blogs and take formal training if your budget allows. Participate in online forms and informal meet-ups. Talk to people who currently work in DFIR.

Once you learn a bit about DFIR through informal exploration, reading and studying, start looking for a job—in your organization or elsewhere—that can provide you with experiences and mentoring in the aspect of digital forensics and interest response that interests you. Don’t forget to incorporate what you’ve learned about DFIR into your resume, of course.

There are many ways to enter a given field, and everyone’s approach might be different. What are your tips for people interested in getting into DFIR? What has worked for you?

Update: For a perspective on this topic from Harlan Carvey, see his Getting Started post.

Hand-picked related posts:

• Making Sense of Digital Forensics and Incident Response Disciplines
• Professional Development in Digital Forensics and Incident Response
• Learning Malware Analysis Through Practice

Just so you know, I teach the malware analysis course at SANS Institute.

— Lenny Zeltser

Can We Rely on the Antivirus’ Ability to Disinfect a System?

Antivirus/antimalware tools play an important role as part of an overall security architecture. One of the many capabilities built into these products is the ability to remove malicious programs discovered on the system during a scan. After all, despite all the technology and caution, malware can find its way onto any system. What happens next?

A Host Infected in the Organization

Let’s say an administrator charged with overseeing corporate antivirus notices an alert indicating that malware was found on a workstation or server. A similar situation arises when an administrator runs an ad hoc scan and encounters a malware warning. The person examines the alert and determines that malware had already executed the on the system prior to being discovered. If the antivirus tool provides the option to automatically disinfect the system, it’s tempting to click “Remove” and move on to fighting other fires.

Antivirus vendors invest significant R&D efforts into creating robust malware removal capabilities, especially for malicious programs most commonly encountered by their users. Yet, in a corporate setting, I am concerned about organizations considering that the security incident has been fully resolved once the antivirus tool removed malware.

The Discovered Specimen Could Be Just a Start

If one malware specimen was encountered on the system, there’s a reasonable chance that there is other malware there that may be still undetected. Moreover, it is possible that an attacker already took advantage of the now-removed malicious program to further compromise the system or other IT resources in the organization. To know for sure, deeper forensic analysis of the incident may be required.

When encountering an infected host in the corporate environment, be weary of relying solely on the antivirus tool’s ability to disinfect the host. If you can, take the time to look for other indicators of compromise to assess the scope and severity of the incident. Investigate further if there are reasons to be concerned. Once you’re ready to eradicate malware, strongly consider reimaging the system or restoring it from backup, instead of automatically disinfecting it and assuming that the situation has been resolved.

Hand-picked related posts:

• When Does a Suspicious Event Qualify as a Security Incident?
• Asymmetry of People’s Time in Security Incidents
• Key Challenges of Combating Malware in the Enterprise

— Lenny Zeltser