4
incident response 8 Introduction Intellectual property theft ranges from an employee using proprietary information to establish a competing product, to an individual holding valuable infor- mation ransom, to an unethical organiza- tion breaking into a competing organization’s systems. In such cases the target is generally information and, to varying degrees, the organization. The thief may intend to use the informa- tion to create a competitive advantage, in which case the information is the primary target. If the thief takes the information and then destroys the original copy to effect the organization adversely, the information and organization are targets to equal degrees. However, if the thief attempts to make a profit by holding the information ransom, the organization is the primary target. Generally, a thief with inside knowl- edge of an organization can cause more damage than an outsider. However, such generalizations are of limited use in actual investigations because each situation is different. It is more informative to examine available evidence to determine the threat posed by a given thief. An organization’s abili- ty to assess the threat in a given case and apprehend the perpetrator depends largely on how the incident is handled. Proper evidence collection and inter- preting behaviour represented in the digital evidence are cornerstones of effective incident handling. To understand how digital evidence reflects behaviour, it is instructive to consider some examples. When thieves target an organization’s comput- er systems, their actions leave behind digital evidence that can reveal their intent, skill level, and knowledge of the target. Network logs may show a broad network scan prior to an intrusion, sug- gesting that the individual was explor- ing the network for vulnerable and/or valuable systems. This exploration implies that the individual does not have much prior knowledge of the net- work and may not even know what he/she is looking for but is simply prospecting. Conversely, thieves who have prior knowledge of their target will launch a more focused and intricate attack. For instance, if a thief only tar- gets the financial systems on a network, this directness suggests that the intrud- er is interested in the organization’s financial information and knows where it is located. So, if the targeting is very narrow – the thief focuses on a single machine – this indicates that he/she is already familiar with the network and there is something about that particular machine that interests him/her. Similarly, time pattern analysis of the target’s file system can show how long it took the intruder to locate desired infor- mation on a system. A short duration is a telltale sign that the intruder already knew where the data was located where- as protracted searches of files on a sys- tem indicates less knowledge. The sophistication of the intrusion and subsequent precautionary acts help determine the perpetrator’s skill level. The thief’s knowledge of the target and criminal skill can be very helpful in nar- rowing the suspect pool, particularly when only a few individuals possess the requisite knowledge and skills suggesting insider involvement, as in the “Breaking the Bank” case presented by Fred Cohen in the November 2002 issue of Computer Fraud and Security. The following two case examples pro- vide different lessons for dealing with and interpreting digital evidence in computer intrusion cases. Case #1: Compromised W2K Domain Controller In February 2002, a client called an information technology consultant to report that their sole Windows 2000 domain controller was running slowly and had rebooted unexpectedly on sever- al occasions. The consultant scanned the server using Internet Scanner and looked at running processes using fport (www.foundstone.com) to get an initial sense of the system. Internet Scanner found only one security problem with the domain controller – it was running a variant of Back Orifice 2000 (BO2K) on TCP port 1177. The output of fport showed that port 1177 was associated with the executable c:\windows\sys- tem32\wlogin.exe. When the client was informed of this problem, their primary concern was Determining Intent — Opportunistic vs Targeted Attacks Eoghan Casey To assess the importance and potential impact of an incident accurately com- puter security professionals need to understand an offender’s criminal skill, knowledge of targets, and intent. A thief who selects targets of opportunity based on insecure systems presents a significantly different threat than an indi- vidual who targets a specific organization to obtain specific information. This article compares two intellectual property theft cases to provide readers with practical investigative insights, noting costly mistakes and pointing out behav- iour reflected in digital evidence. Although these cases are based on actual inves- tigations, they have been modified to protect the innocent.

Determining Intent — Opportunistic vs Targeted Attacks

Embed Size (px)

Citation preview

incident response

8

IntroductionIntellectual property theft ranges from anemployee using proprietary informationto establish a competing product, to an individual holding valuable infor-mation ransom, to an unethical organiza-tion breaking into a competingorganization’s systems. In such cases the target is generally information and, tovarying degrees, the organization. The thief may intend to use the informa-tion to create a competitive advantage, inwhich case the information is the primarytarget. If the thief takes the informationand then destroys the original copy toeffect the organization adversely, theinformation and organization are targetsto equal degrees. However, if the thiefattempts to make a profit by holding theinformation ransom, the organization isthe primary target.

Generally, a thief with inside knowl-edge of an organization can cause more damage than an outsider.However, such generalizations are oflimited use in actual investigationsbecause each situation is different. It ismore informative to examine availableevidence to determine the threat posedby a given thief. An organization’s abili-ty to assess the threat in a given case

and apprehend the perpetrator dependslargely on how the incident is handled.Proper evidence collection and inter-preting behaviour represented in thedigital evidence are cornerstones ofeffective incident handling.

To understand how digital evidencereflects behaviour, it is instructive to consider some examples. Whenthieves target an organization’s comput-er systems, their actions leave behinddigital evidence that can reveal theirintent, skill level, and knowledge of thetarget. Network logs may show a broadnetwork scan prior to an intrusion, sug-gesting that the individual was explor-ing the network for vulnerable and/orvaluable systems. This explorationimplies that the individual does nothave much prior knowledge of the net-work and may not even know whathe/she is looking for but is simplyprospecting. Conversely, thieves whohave prior knowledge of their targetwill launch a more focused and intricateattack. For instance, if a thief only tar-gets the financial systems on a network,this directness suggests that the intrud-er is interested in the organization’sfinancial information and knows whereit is located.

So, if the targeting is very narrow –the thief focuses on a single machine –this indicates that he/she is alreadyfamiliar with the network and there issomething about that particularmachine that interests him/her.Similarly, time pattern analysis of thetarget’s file system can show how long ittook the intruder to locate desired infor-mation on a system. A short duration isa telltale sign that the intruder alreadyknew where the data was located where-as protracted searches of files on a sys-tem indicates less knowledge.

The sophistication of the intrusionand subsequent precautionary acts helpdetermine the perpetrator’s skill level.The thief ’s knowledge of the target andcriminal skill can be very helpful in nar-rowing the suspect pool, particularlywhen only a few individuals possess therequisite knowledge and skills suggestinginsider involvement, as in the “Breakingthe Bank” case presented by Fred Cohenin the November 2002 issue of ComputerFraud and Security.

The following two case examples pro-vide different lessons for dealing with andinterpreting digital evidence in computerintrusion cases.

Case #1: Compromised W2KDomain ControllerIn February 2002, a client called aninformation technology consultant toreport that their sole Windows 2000domain controller was running slowlyand had rebooted unexpectedly on sever-al occasions. The consultant scanned theserver using Internet Scanner and lookedat running processes using fport(www.foundstone.com) to get an initialsense of the system. Internet Scannerfound only one security problem withthe domain controller – it was running avariant of Back Orifice 2000 (BO2K) onTCP port 1177. The output of fportshowed that port 1177 was associatedwith the executable c:\windows\sys-tem32\wlogin.exe.

When the client was informed of thisproblem, their primary concern was

Determining Intent —Opportunistic vs TargetedAttacksEoghan Casey

To assess the importance and potential impact of an incident accurately com-puter security professionals need to understand an offender’s criminal skill,knowledge of targets, and intent. A thief who selects targets of opportunitybased on insecure systems presents a significantly different threat than an indi-vidual who targets a specific organization to obtain specific information. Thisarticle compares two intellectual property theft cases to provide readers withpractical investigative insights, noting costly mistakes and pointing out behav-iour reflected in digital evidence. Although these cases are based on actual inves-tigations, they have been modified to protect the innocent.

incident response

9

business continuity. Because of the criti-cal role that this server played in theWindows domain, a rapid response andrecovery was required. The client wasunwilling to take the domain controlleroffline because this would disrupt busi-ness operations. In short, the clientwanted the server to be fixed with mini-mal impact on the organization and wasonly casually interested in apprehendingthe culprit.

The consultant’s first task was todetermine how BO2K had beeninstalled on the domain controller. Thesystem was located in a locked roomand only one employee could access it physically using a smartcard. Thisindividual was the only suspect becausethe domain controller did not have any obvious vulnerabilities and nobodyelse could legitimately access the systemover the network to install programs.Although the system administrator vehemently denied any involvement,the consultant knew that it would be relatively straightforward to find incriminating digital evidence on the server. Therefore, beforeattempting to remove BO2K, the consultant saved system logs and file system date-time stamps from the server for later analysis if the client decided to discipline the systemadministrator.

In the past, the consultant had success-fully removed BO2K by removing theassociated value in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run Registry key, rebooting the system, anddeleting the executable. However, therewas no sign of BO2K in the Run Registrykey so the consultant performed anextended search of the Registry and sys-tem files for references to the Trojan pro-gram. In this case, dumping the Registryand searching for references to wlogin.exerevealed that BO2K was being started asa service.

After removing the rogue service fromthe Registry, the consultant obtained per-mission to reboot the server to ensurethat all remnants of the process wereeliminated. Unfortunately, the domaincontroller did not reboot successfully

because the Trojan horse program hadreplaced the legitimate WinLogin service.By removing the rogue service, the con-sultant had effectively done more damagethan the intruder, interrupting businessoperations while attempting to restorethe server. After some pandemonium, thesystem administrator came to the consul-tant’s aide and resolved the problem bychanging the HKLM\System\CurrentControlSent\Services\WinLogin\ImagePath Registry key to point to the legitimateWinLogin.exe executable.

The client was outraged by the disrup-tion cause by the failed reboot. The con-sultant was summarily dismissed but notbefore blaming the system administratorfor installing BO2K on the server. Theclient decided to involve law enforcementto recover damages from whoever wasresponsible.

By discovering intent, thesignificance of the

intrusion becomes clear,and relevant action can be

taken.

A closer examination of the log filesand other digital evidence the consultantcollected from the system revealed that, although Microsoft InternetInformation Server (IIS) was fullypatched at the time of examination, the machine had been compromised viathe IIS Unicode vulnerability before it was patched. Also, Norton AntiVirus had made numerous entries inthe Application Event log reporting that BO2K had been found on the system but nobody had been readingthese logs. So, although the systemadministrator could be faulted for patch-ing the system too late and missing obvious signs of intrusion, it seemed less likely that he was guilty of installingBO2K particularly since he lacked a motive and appeared more interested in helping the organization maintain their operations than in dis-rupting them.

At this point, the investigators deter-mined that they needed more evidencefrom the domain controller and thenetwork to gain a more completeunderstanding of the intrusion. By thistime, the client had formed manyurgent questions including why thissystem was targeted, what was taken,and by whom.

A more complete examination of thedomain controller revealed that theintruder had installed an IRC Eggdropbot in C:\Winnt\Java. The Eggdrop bot’sfiles contained information about servers,nicknames, channels, and channel pass-words relating to the intruder.Additionally, log entries from the organi-zation’s intrusion detection systemshowed a broad network scan for vulnera-ble Web servers prior to the intrusion.Unfortunately, because the server hadbeen in operation after the intrusion,investigators could not determine if theintruder had accessed sensitive files, cap-tured passwords, or obtained other valu-able information from the server.Fortunately, the intruder did not appear to be seeking proprietary informa-tion on the system. An analysis of thecomputer and network showed that theintruder primarily used the system forstorage and to connect to IRC and wasnot interested in its contents.Additionally, the intruder did not exhibita high amount of skill or knowledge ofthe network, suggesting an outsider look-ing for poorly secured systems.

The cost of damage caused by thisintruder was difficult to determinebecause the consultant caused much of the harm. However, it was likely that this intruder had compromised other systems or would attempt to com-promise other systems in the future.Therefore, a more detailed networkassessment was warranted to locate othercompromised systems and prevent simi-lar attacks.

Mistakes in Case #1:In addition to causing significant dis-ruption, the information technology

incident response

10

consultant made several mistakes in han-dling this incident. While examiningand attempting to repair the system, theconsultant altered many aspects of thecompromised computer, including mod-ifying important Registry values and filedate-time stamps, effectively tainting thecrime scene. Also, either by design oraccident, the Trojan wlogin.exe waszeroed out after the system was reboot-ed. Thus, an important piece of evidencewas lost – the executable may have con-tained characteristics or configurationoptions that reveal something about theintruder.The consultant made another mistake inassuming that only one backdoor existed.The consultant stopped looking for othersigns of intrusion once he found BO2Krather than checking all running process-es to ensure that there are no other suspi-cious or unexplainable programs. Theconsultant also should have looked fornew accounts in the administrator groupand other changes to the system (e.g.,Registry permissions) that could be usedto regain access to the system.

Furthermore, the consultant onlyretained one copy of the evidence, com-pressing all evidentiary files into a singleZip file and transferring it to a remotesystem over the network. Unfortunately,the Zip file was corrupted in transit andcould not be opened. The contents ofthe Zip file was partially recovered usinga file repair program but some evidencewas lost. Although there is nothinginherently wrong with compressing andsaving evidence files in a compressedarchive or transferring them to a remotesystem via a network connection, mak-ing just one copy of the evidence is high-risk behaviour. It is advisable to save acopy of all digital evidence in uncom-pressed form to a diskette and clearlylabel it with the contents, current date,and investigator’s initials.

Case #2: Intranet WebServerIn December 2002, the CEO of a medi-um-sized organization contacted an

investigator for urgent assistancebecause a competitor had obtained pri-vate information from his system andhe wanted to know how. Only onecomputer contained this informationand the investigator performed ananalysis of running processes and otheraspects of the system using a procedurethat minimized changes to the system, but found nothing unusual. Extendinghis search to neighboring machines, the investigator found one computer on the same subnet that showed signs of compromise. The investigator quickly shut the system down, made an image of the hard drive, and performed a detailed analysis of the system. Although there was very little information on the system, Webserver access logs indicated that theintruder gained access via the InternetInformation Server (IIS) Unicode vul-nerability.

The log entries indicated that the attack originated in Italy and the tools were downloaded from an IP address in Canada using tftp. Most notably, the intruder placed netcat on the system and configured it to give a command prompt to anyone connecting to port 443 usingTelnet.

Date-time stamps of files on the sys-tem showed that most activity occurred early in the morning of 03/01/2002with several files accessed. Interestingly,these date-time stamps did not indicate that the intruder searched around thefile system, suggesting that she did not have interest in the contents of the serv-er. However, one other file named win-dump.exe was added to the system on 02/28. Additionally, investigatorsfound an unusual file on the compro-mised system named dump that was created around the time of the intrud-er's last connections containing net-work traffic from the organization’snetwork. This file did contain sensitive information but not the specific data that the client was originally concernedwith. It was likely that the intruderobtained the private information using the sniffer and deleted the file

from the compromised system to coverher tracks.

Upon closer inspection, comparingthe Web access logs with file date-timestamps, the investigator realized thatsome IIS log entries from later on02/28 and 03/01 were missing, indicat-ing that the intruder had deleted them.The investigator began to suspect thatall was not as it seemed. This conceal-ment behaviour along with the relativesophistication of the attack convincedthe investigator that he was dealingwith a highly skilled adversary. So, theinvestigator sought more reliablesources of evidence on the network toget a complete picture of what hadoccurred.

Analyzing the organization’s firewallconfiguration showed that the compro-mised Web server could not be accessedfrom the Internet. This implied that the Italian IP address in the compro-mised Web server logs was fabricated toconceal the actual source of the attack.An analysis of relevant Snort andNetFlow logs showed that the attack wasactually launched from another systeminside the organization’s network andindicated that the initial compromiseoccurred on 02/28 between 18:57 and19:03. This machine did not have logfiles or other information that could beused to determine how the system wascompromised or where the attackercame from. However, network logsshowed one remote logon to themachine at the time from a largeInternet Service Provider (ISP).Additionally, NetFlow and Snort logsshowed that this was a focused attack onthe target systems – the intruder did notprobe any other systems. The fact thatno other machines were attacked in thisincident indicated that the intruder hadsome prior knowledge of the networkand her target. This was a highly target-ed attack and the type of informationsought using the sniffer suggested thatintellectual property theft was the likelyintent.

Based on the level of skill of the thiefand the likelihood that sensitive infor-mation was stolen, the investigator

incident response

11

informed his client of the seriousness ofthe incident and advised them toinvolve law enforcement. Law enforce-ment was contacted and they obtainedinformation about the intruder fromthe originating ISP. Although the dial-up account that the intruder usedturned out to be stolen, the ISP main-tained Automatic Number Ident-ification (ANI) information thatrevealed the intruder’s phone number.A search warrant was served on theintruder’s home and an examination ofher computer revealed not only thestolen information from the client’s sys-tem but also relevant communicationswith the competitor.

How it should be doneThis case highlights the importance ofa methodical approach to incident han-dling and digital evidence processing.The investigator was thorough and efficient, causing less disruption thanthe previous case although the incidentwas more serious and more sources ofevidence were involved. Additionally,the investigator quickly assessed that he was dealing with a highly skilledoffender and reacted accordingly by obtaining evidence from the targetnetwork that the intruder could not alter.

Notably, the investigator did notattempt to fix the compromised system.As noted in the previous case example,attempting to fix a system while con-ducting an investigation can under-mine evidence preservation efforts.Additionally, the intruder could subtlyalter a system to facilitate future com-promise, making it more difficult toeradicate the intruder completely.Instead, the investigator focused onpreserving evidence and determiningwhat had occurred. Afterwards, theinvestigator recommended that thecompromised system be reformattedand rebuilt before reconnecting it tothe network. The process of rebuildinga compromised system involves backing

up data files before reformatting thedrives, reinstalling and securing the sys-tem, and carefully examining filesbefore placing them on the rebuilt sys-tem to ensure that they do not containa backdoor. The investigator also rec-ommended using network encryption(IPSec) between critical systems to pre-vent the type of eavesdropping thatoccurred in this incident.

When dealing with moresophisticated offenders,

investigators must be pre-pared for misdirection and

concealment.

ConclusionsThese two case examples compared atarget of opportunity versus a deliberate attack. In the first case, a low-skilled intruder with little priorknowledge of the target system found a vulnerable host by scanning the network indiscriminately. This intruderappeared to be satisfied with just gaining access to the compromised host and made no effort to obtain valu-able information, as the client had feared. If handled properly, thedamage caused by this low-threat inci-dent would have been minimal and theorganization could have continued nor-mal operations without the added costand disruption of a full investigation.This case example demonstrated that determining the intent is of littleuse when an incident is handledimproperly.

In the second case, a highly skilledattacker demonstrated knowledge of the target system, bypassing the firewalland gaining access to a sequence of computers with the specific intent ofobtaining valuable information. Whendealing with more sophisticatedoffenders, investigators must be pre-pared for misdirection and conceal-ment. In this case, the intruder altered

server logs to misdirect the investigator.If the kernel is modified, signs of intru-sion are more difficult to detect soinvestigators should not assume that asystem is not compromised just becausethere are no obvious signs. These typesof concealment behavior can be detect-ed by correlating evidence from thecompromised host with network logs.The investigator in this case handledevidence properly, correctly assessed theskill level of the offender, and ultimate-ly helped the organization resolve theincident with minimal impact on theiroperations. Evidence from multipleindependent sources on the networkwere used to overcome missing andmisleading evidence on the compro-mised hosts, enabling the investigatorto reconstruct a more complete pictureof the crime.

In both cases, digital evidencerevealed the intruder’s behaviour to the extent that an investigator coulddeduce the intruder’s intent, level of skill, and knowledge of the targetsystem.

About the Author

Eoghan Casey is Technical Director andPartner in Knowledge Solutions, LLC. He investigates network intrusions, intel-lectual property theft, and other computer-related crimes, and has exten-sive experience analyzing digital evi-dence. He has assisted law enforcement ina wide range of criminal investigationsincluding homicide, child exploitation,cyberstalking, and larceny. Mr. Casey alsohas extensive information security experi-ence. As an Information Security Officerat Yale University and in subsequent con-sulting work, Mr. Casey has performedvulnerability assessments, deployed andmaintained intrusion detection systems,firewalls and public key infrastructures,and developed policies, procedures, andeducational programs. Mr. Casey is theauthor of Digital Evidence andComputer Crime and the editor of theHandbook of Computer CrimeInvestigation.