HackingTheUniverse

A. DEFENDERS: SI-3 MALICIOUS CODE PROTECTION
[the italicized section below is a security control from NIST SP 800-53]

Control: The information system implements malicious code protection that includes a capability for automatic updates.

Guidance: The organization employs virus protection mechanisms at critical information system entry and exit points (e.g., firewalls, electronic mail servers, remote-access servers) and at workstations, servers, or mobile computing devices on the network. The organization uses the virus protection mechanisms to detect and eradicate malicious code (e.g., viruses, worms, Trojan horses) transported: (i) by electronic mail, electronic mail attachments, Internet accesses, removable media (e.g., diskettes or compact disks), or other common means; or (ii) by exploiting information system vulnerabilities. The organization updates virus protection mechanisms (including the latest virus definitions) whenever new releases are available in accordance with organizational configuration management policy and procedures. Consideration is given to using virus protection software products from multiple vendors (e.g., using one vendor for boundary devices and servers and another vendor for workstations).

Control Enhancement 1: The organization centrally manages virus protection mechanisms.

Control Enhancement 2: The information system automatically updates virus protection mechanisms.

[the following section is the PHA response to the control described above]

Implementation: All PHA computer systems must have anti-virus protection software installed, active and up to date. Automation of the update process is critical and will be done from a central location. Anti-virus signature files (also known as .DAT files) must be updated on a periodic basis or whenever a new threat materializes.

B. ATTACKERS: Custom Malware
Anti-virus software and most intrusion detection tools do a lot of their threat detection by recognizing previously identified signatures. A signature is derived from some of the code that the virus or trojan program is likely to depend upon and not very likely to be modified without altering the functionality of the malware. Malware is collected and analyzed to produce the signatures when it is noticed and that most often occurs when it has become widespread and created an effect. If the malware is not widely used and goes un-noticed and uncollected, it won’t be analyzed for development of a detection signature.

Targeted attacks, designed to be used against a single target, can avoid signature detection. Since the malware is custom designed to avoid any known signatures and has never been widely released, a signature for it will not exist and no signature detection mechanism will find it, whether in anti-virus software, intrusion detection software, or any other form. Malware can also be disguised from signature detection by using polymorphic tools that change the code constantly, creating a unique version with a unique signature each time the program is created. Polymorphic toolkits such as: ADMutate, PHATBOT, Jujuskins, TAPioN and CLET put this kind of functionality within the reach of the average skilled malware creator, if not the novice. As polymorphic shell code has become more common, defenses have adapted to detect it. More advanced detection tools use traffic profiling techniques, known as “anomaly detection” to filter out traffic that does not fit a profile of normal traffic. This takes malware detection a step beyond merely using signatures and might detect a threat that has no known signature. An offensive counter to anomaly detection is described in a paper titled, “Polymorphic Blending Attacks”.

Joanna Rutkowska describes her concept of hard to find malware as, “Type II: Malware which modifies things which are designed to be modified (DATA sections).” One of the examples she offers of type II malware includes the FU rootkit by Jamie Butler. An FU based module has been available for some time for the old classic backdoor program, BackOrifice2000. FU-like features have turned up in Rbot and the Myfip worm. Although this class of malware is more difficult to detect, it can be discovered. Joanna goes on to describe an even more stealthy class of malware which she calls “stealth by design”. In this “proof of concept” design, the malware has its’ own shell and TCP/IP stack, minimizing traceability.

In another separate, but real-life example of stealthy malware, the Gozi trojan existed in the wild for over fifty days in the beginning of 2007, and it has been estimated that the first variant of it infected more than 5,000 hosts and stole account information for over 10,000 users. Gozi’s primary function was to steal credentials being sent over SSL connections before they were encrypted and add them to a database server that would dispense them on demand in exchange for payment. Had the malware author made a better choice of the packing utility used, the trojan may have gone much longer before being detected.

C. Scenario (Bypass)
The by-pass attack team used several custom made trojan programs to completely by-pass the perimeter defenses. The trojan programs were delivered by email and web pages, but the anti-virus defenses were not triggered because the trojans did not have any known signatures. Many different versions were used in the hopes that if one was noticed, collected and scrutinized; it would not reveal information that could create a signature that would detect the others.

Email addresses for people inside the target organization were collected during the basic reconnaissance and more were accumulated over time with searches based on domains and user names. Some emails simply sent attachments, often with a spoofed source address, designed to convince the recipient that the email was valid, but not allow any trace back to the real sender. Other emails sent links to web pages that had downloads available or malicious scripts to run. In either case, the trojans were made to look like a valid object and usually delivered some kind of camouflaging action while the program was being installed to convince the user that nothing was amiss.

Once the trojan program was installed, it activated a remote access backdoor to allow the attackers to control the compromised system. The backdoors used a variety of techniques to get out past the perimeter. The goal was to allow responses and data from the compromised host inside the perimeter to get outside to a command and control node and to allow more instructions to get back inside to the compromised host. Web traffic was most often the carrier for this, since the perimeter defenses were required to allow it to pass through. Sometimes the web traffic was encrypted with SSL. In some cases, encrypted secure shell sessions were used. In other cases, Email traffic was used to carry embedded data in attached files, usually encrypted.

None of this activity was detected by the defenders. Once the attackers had established a presence on a system, they followed up with variations of the techniques described in Chapter 8 – Entrench.