As a matter of course, investigators are tasked to address rogue code attacks. Handling such an attack presents challenges in terms of priorities. For example, certain types of attacks spread very quickly affecting computers on networks in large numbers. The Morris Internet Worm was one such attack.
There are many demands placed on the responders once they are aware of a potential critical incident. The clear first priority is isolating the attack. Infected computers must be isolated from the surrounding system to prevent the infecting code from spreading to other systems. With this done, responders should ask themselves if it is important to determine the origins of the infection, or not. If the network and its connecting systems are cleansed of the rogue code, the evidence of its origin may be erased; however, if the systems containing the code are isolated, they remain inoperable until the investigation is completed, negatively affecting productivity.
Viruses
In a virus attack, it is very likely the virus has infected many systems. The responder's likely priority is isolating the infected machines, clean them, and return them to their users. In these cases, analyzing the virus and its origins is secondary. Tracing the virus is difficult, if not impossible in a large system, but there are some considerations that can be made:
-
Make a forensically sound copy of one of the infected hard drives.
-
Treat the hard drive as if it were evidence and a crime scene in its own right.
-
Make a second forensic copy of the drive and use it as a work copy for future analysis.
-
If the first infected computer in the system can be identified by timestamp analysis, it may be possible to identify the origin of the infestation.
Experience Note | It is extremely difficult to identify the person who introduced a virus into a network. Anti-virus software must be constantly updated and users trained not to open e-mail attachments. Usually the best that can be done is to isolate the systems, cleanse them, return the systems to the production environment, and train users. |
Trojan Horses and Logic Bombs
In many regards, these examples of malware code are easier to handle than viruses because they are usually confined to one machine. The problem is that they might remain dormant or unused on that machine until a triggering event takes place. Triggering events are items such as calendar dates, keystrokes made in a specific order, or the execution of program code. Once the triggering event takes place, the user discovers the malicious code and administrators take appropriate restoration steps. With the malicious code running, it's going to be fairly obvious where it is located. For example, if there is a logic bomb planted in a billing program, it is possible that users will know it when they try to execute the application and it does its damage.
With the execution of a logic bomb, the damage is done. Depending on the extent of possible legal action, the best solution is to cleanse the victim system and reinstall the software with clean backed-up data. It is possible that evidence could be collected, timestamps compared, and an attacker identified. Conducting such an investigation can be very time-consuming and resource intensive; consequently, it must be determined if it is worth the effort or not.
In the event of a suspected logic bomb hidden in an application, there are some specific steps that can be taken to prevent it from executing and doing its damage. It is important that a forensically sound copy of the suspected drive is made and preserved as evidence. Copy the evidence drive for performing all analyses and return a clean drive to the original system. The best way to locate the malicious code is to compare the victim system, where the malicious code is resident, with a clean backup copy. Investigators should review the date of the last change in the target media and compare it to the date of the last change for the same file in the backup copy. Continue to compare backups as far as is practical and compare dates. If there is a timestamp date change that cannot be explained or is not documented, the altered file is probably the guilty one.
If the investigators can gain visibility into the programmer's code (this may or may not be possible) there are editors that will automate the line by line comparison revealing any changes.
In the event of suspected malicious code, here are a few types of event logging that will help:
Things to Do after a Malicious Code Attack
If a system has been the victim of a malicious code attack or denial-of-service attack, either as a result of outside or inside activity, here are a few suggested measures:
-
Contain the potential problem. The most efficient way to accomplish this is to simply remove the Ethernet cable from the NIC card, or isolate the affected systems from the rest of the network by some other means. If this cannot be accomplished, disable the power to the target machine. If you do not disconnect the target machine from the network, infections or attackers will cause havoc because they will continue to have access to the system.
Experience Note Managers should not be lulled into the idea that attackers having penetrated a system will not return. Once in, they will continuously attempt to intrude or deny service.
-
Preserve the target media as evidence. This probably will mean making a forensic copy of the target drive and preserving it for evidence.
-
Cleanse the original drive and return it to service. Make forensic copies of media containing the malicious code and preserve them as evidence. This will preserve the timestamp dates of infection. Cleansing media may consist of media degaussing, reformatting the drive, or launching a forensic erasing tool where the entire drive is overwritten several times destroying the offending code.
-
A completely clean reinstallation will be more time consuming, but will ensure correct functionality rather than running the anti-virus software to delete or quarantine the offender.
Digital Bloodhounds
For matters that are going to be pursued to levels of litigation, it is important for investigators to discover the identities of those responsible for causing system damage. In many cases, civil and criminal legal processes can be, and should be, pursued on parallel tracks. It is not unusual for an individual to be criminally charged while the damaged parties file lawsuits to recover their losses. Considering all the different technologies that can be employed to conceal the attacker's identity such as anonymous e-mail re-mailers and compromised server accounts, it would seem attackers have a definite advantage over investigators.
IP Addresses
When investigators begin looking for evidence in an attacked a system, the most logical place to begin searching is the IP address. IP addresses create areas of difficulties when locating the offender.
It is possible, and indeed quite likely, that the source IP address is spoofed and not correctly resolved to the attacker.
It is possible, and indeed likely, that the source IP address used for an attack is many hops away from the actual origin of the attack. Experienced attackers will pass through multiple systems before actually launching an attack. It is very common for investigators to have to obtain information from the administrators of multiple systems in the attack-chain before arriving at the attacker's origin.
Experience Note | Much of IP tracing depends on the investigator's skill and luck. This is not to say it is not successful, but realistically it can be difficult and discouraging. |
The IP address is assigned to an individual machine. It may be difficult to determine who was using a particular machine at a particular time in a shared environment like a school or library.
0 comments:
Post a Comment