19.2 Investigating Intrusions


19.2 Investigating Intrusions

As detailed in Chapter 4, the first step when investigating an incident is to determine if there actually was one - there must be a corpus delicti. Computers and networks are complex systems that can be misunderstood or that can malfunction, resulting in false incident reports. To determine what occurred, investigators should interview the individuals who witnessed the incident, those who reported it, and anyone else who was involved. Whenever possible, interviews should be conducted in person or by telephone in a discrete manner. A lack of caution in the initial stage of an investigation can alert an offender and can result in workplace rumors or media leaks that cause more damage than the incident.

CASE EXAMPLE

start example

In one incident, an organization detected employees from a competitor's network gaining unauthorized access to a server. Sufficient evidence was gathered to prove the illegal activity and to identify the competitor's employees who had committed the crime. To avoid publicity and preserve a good relationship with the competitor, the victim organization decided to resolve the problem through private communication rather than through legal action. However, an employee in the victim organization leaked the story to the press, creating a national scandal that caused more damage than the incident itself.

end example

Once the nature and severity of an incident has been determined, it is advisable to inform legal counsel, human resources, managers, public relations, and possibly law enforcement as outlined in the organization's incident/emergency response plan. Keep in mind that it may not be possible to trust the network that the offender has targeted, so encryption should be used for all incident-related communications and activities on the network. Also, be aware that it can take years to resolve some incidents so it is crucial to document all actions taken in response to an incident, including all communications. Detailed notes are useful for recalling, explaining the incident years later, and it may be necessary to re-interview certain people or call on them to testify to clarify certain details. Additionally, noting the dates and times of events, including the time it took to recover systems helps calculate cost of damage.

Investigating computer intrusions usually involves a large amount of digital evidence. Investigators must search large log files for relevant entries, examine programs to determine their purpose closely, and explore the network for additional clues. In addition to being technically challenging, there is often pressure on an investigator to resolve the problem quickly. Relevant log files and state tables might be erased at any moment and the system owners/users want to gain access to the information on the system. It is often necessary to interpret digital evidence instantaneously to determine where additional evidence might be found.

Under such conditions, especially when several computers are involved, it is easy to overlook important digital evidence, neglect to collect digital evidence properly, document the investigation inadequately and jump to incorrect conclusions. The most effective approach to managing this kind of complex, high-pressure, error-prone investigation is to use standard operating procedures (SOPs) with associated forms to collect the most common sources of digital evidence. Having a routine method for quickly preserving digital evidence for future examination leaves investigators with more time to deal with the nuances and peculiarities of individual incidents. These procedures should employ the concepts covered in Parts 1, 2 and 3 of this book.

A common challenge that arises during intrusion investigations is the need to protect the target systems against further attack. Investigators may even be asked to remove a backdoor and repair the target system before they have collected evidence from the system. Whenever possible, evidence should be preserved prior to repairing the target system or altering its state in any other way. It is usually feasible to protect the target system by isolating it on the network while it is being processed as a source of evidence. In some cases, it may be viable to isolate a system simply by unplugging its network cable. However, when the system is a critical component of a network, it may be necessary to involve network administrators to reconfigure a router or firewall, partially isolating the system but permitting vital connections to enable an organization to remain in operation.

CASE EXAMPLE

start example

A routine vulnerability scan of a network detected Back Orifice running on a Windows 2000 server. Because of the critical role that this server played in the organization, a rapid response and recovery was required. The organization was unwilling to take the server offline because this would disrupt business operations. They wanted the server to be fixed quickly and were not concerned with apprehending the culprit. Investigators determined that the server had been compromised via IIS and found Web server access logs that corresponded with the initial intrusion containing the intruder's IP address. Additionally, they found that the Back Orifice executable was named "wlogin.exe" and was installed as a service named "WinLogin" as shown in the following Registry key:

 D:\>regdmp \Registry <cut for brevity> (HKLM\System\CurrentControlSent\Services)    WinLogin     Type = REG_DWORD 0x00000110     Start = REG_DWORD 0x00000004     ErrorControl = REG_DWORD 0x00000000     ImagePath = REG_EXPAND_SZ ' "C:\WINNT\System32\wlogin.exe"'     DisplayName = WinLogin 

Furthermore, NT Application Event logs showed that Norton AntiVirus had detected Back Orifice but had not been able to remove it:

 D:\>dumpel -c -l application <cut for brevity> 1/19/2002,12:32:48 AM,4,0,20,Norton AntiVirus,N/A,CONTROL, Unable to restore C:\WINNT\system32\wlogin.exe from backup file after clean failed, 1/19/2002,1:09:11 AM,1,0,5,Norton AntiVirus,N/A, CONTROL, Virus Found!Virus name: B02K.Trojan Variant in File: C:\WINNT\Java\w.exe by: Scheduled scan. Action: Clean failed : Quarantine succeeded : Virus Found!Virus name: BO2K.Trojan Variant in File: C:\WINNT\system32\wlogin.exe by: Scheduled scan. Action: Clean failed : Quarantine failed : 1/19/2002,1:09:11 AM,4,0,2,Norton AntiVirus,N/A, CONTROL, Scan Complete: Viruses:2 Infected:2 Scanned:62093 Files/Folders/Drives Omitted:89 

The intruder had also installed an IRC bot in C:\WINNT\Java that contained several possible leads including IP addresses, nicknames, and IRC channel passwords. However, because the priority was to recover the system, this evidence was collected hastily and the Trojan horse program was removed. After removing the rogue service from the Registry, the server was rebooted to ensure that all remnants of the process were eliminated. Unfortunately, the domain controller did not reboot successfully. Attempting to fix the problem had effectively done more damage than the intruder, interrupting business operations while attempting to restore the server. After some pandemonium, the system was restored from backup, a lengthy process resulting in a prolonged interruption in business that the organization had hoped to avoid.

By the time the domain controller had been recovered, the organization was more interested in apprehending the culprit. Their concerns were exacerbated when they realized that the intruder could have obtained passwords from the server and used them to compromise other system on the network. Unfortunately, much of the evidence had been destroyed when the system was restored from backup and the Back Orifice executable had been erased by Norton AntiVirus. It was determined that there was too little evidence to apprehend and prosecute the intruder. Using the little information that they had preserved, the organization did their best to determine if the intruder had targeted any other systems on their network.

end example

One of the more difficult decisions is whether to shut down a compromised system or collect some data from it beforehand. When investigating a computer intrusion, it is often desirable to capture and record system information that is not collected by a bitstream copy of the hard disk. For instance, it is useful to document current network connections, which user accounts are currently logged on, what programs are running in memory (a.k.a. processes), and which files these processes have open. Processes in memory, network state tables, and encrypted disks may contain valuable data that are lost when a system is shut down. However, examining a live system is prone to error and may change data on the system. One approach to minimizing these risks is to use automation - running a standard script that gathers basic information and saves it to external media. However, this does not address the possibility that the operating system is untrustworthy. Even when trusted tools are used to examine a computer, system calls can be intercepted and manipulated by a rootkit. Ultimately, investigators must weigh the importance of volatile data against the risk of operating the computer.

Notably, shutting a system down does not necessarily destroy all process-related data. Virtual memory, in the form of swap files, enables more processes to run than can fit within a computer's physical memory (RAM). Therefore, digital evidence from processes can be recovered even after the system is shut down. For instance, the following information was recovered from the Windows 2000 swap file "pagefile.sys" on a compromised Web server, showing the intruder (208.61.131.188) executing commands on the system via a vulnerability in the Web server:

    COMPUTERNAME=WWW……………ComSpec=C:\WINNT\system32\cmd.exe    ……………CONTENT_LENGTH=0…………….GA    TEWAY_INTERFACE=CGI/1.1…….HTTP_ACCEPT=image/gif, image/x-xbitmap, ima    ge/jpeg, image/pjpeg, */*…………HTTP_HOST=192.168.16.133    …‥HTTP_USER_AGENT=Microsoft URL Control - 6.00.8862……….    …‥HTTP_CACHE_CONTROL=no-cache…‥HTTPS=off…….INCLUDE=C:    \Program Files\Mts\Indude…………INSTANCE_ID=1LIB=C:\Prog    ram Files\Mts\Lib.LOCAL_ADDR= 192.168.16.133…….NUMBER_OF_PROCES    SORS=1……….Os2LibPath=C:\WINNT\System32\os2\dll;……‥    OS=Windows_NTPath=C:\Perl\bin;C:\WINNT\system32;C:\WINNT;C:\Program    Files\Mts…………….PATH_TRANSLATED=c:\lnetpub\wwwroot    …………PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.VBE;.JSE;.WSF;.WSH    ……‥PROCESSOR_ARCHITECTURE=x86……PROCESSOR_IDENTIFIER=x86 F    amily 6 Model 5 Stepping 2, Genuinelntel…………‥PROCESSOR_LE    VEL=6……………PROCESSOR_REVISION=0502………QUER    Y_STRING=/c+ping+172.16.81.74+-n+56000+-w+0+-l+56000……‥REMOTE_ADDR=    208.61.131.188……REMOTE_HOST5208.61.131.188……REQUEST_METHOD=G    ET…………‥SCRIPT_NAME==/msadc///////winnt/system3    2/cmd.exe…‥SERVER_NAME=192.168.16.133……SERVER_PORT=80SERVE    R_PORT_SECURE=0…………SERVER_PROTOCOL=HTTP/1.1/……‥S    ERVER_SOFTWARE=Microsoft-IIS/4.0……………SystemDrive=C:    <cut for brevity>    "c:\lnetpub\wwwroot\msadc\\\\\\winnt\system32\cmd.exe" /c    ping 172.16.81.74 -n 56000 -w 0 -l 56000. 

Other similar fragments, some in Unicode format, were also recovered showing the intruder launching denial of service attacks against many hosts on the Internet.

When dealing with a computer intrusion, do not assume that the incident is isolated - there may be other systems on the network that are involved.

CASE EXAMPLE

start example

A system administrator found unusual files on a Windows NT server that he was responsible for. The host had been compromised via the IIS Web server and was running Serv-U FTP Server v3.0 ("c:\winnt\system32\setup\x2x\rundll16.exe") on ports 666 and 9669. The FTP server was being used to share pornography, feature length films, and other media stored in "d:\recycler\<sid>\COM1\database." The term "Pubstro" is sometimes used to refer to a Windows NT server that has been compromised and is being used to distribute files. Windows has difficulty with directories named "COM1" and "LTP1" because it associates these names with DOS drivers. This trick makes directory traversal during a live examination difficult. The FTP server configuration file referenced several other directories that did not appear to be present on the system including "d:\recycler\<sid>\COM1\databaselRWAMLCDP" and "c:\IRWAMELCDP." Logs from the FTP server showing many connections from many hosts downloading files were located in "c:\winnt\system32\os2\dll\backup\." The intruder placed the pulist and kill utilities from the NT resource kit on the system with the FTP server along with a DLL called psapi.dll was in the directory along with the FTP server. The intruder also placed two executables, named nc.exe and bot.exe, in "c:\winnt\system32." A related configuration file contained the following lines:

    #0dayvcd with password psA4C70E33CF55B74D5F1C21B8EE46DD8F    Vcd with password pt0BED4C47C1826BE160D6FA8E4F85A28F    admin with password qgEDA3C477AF1702713437C873A460F230 

Another file named "msgtoadmin.txt" contained the following text:

Note To admin

Well what can I say. I broke in yes. But I'm not here to attack. I'm sorry for any inconvience this may have caused you. No viruses or worms have been installed. That is not my intension. I just love you bandwidth:) If you have read this you must have cought me. And once you have don't worry, I'm gone and won't bother you again. again sorry for any inconvience this may have caused. Have a good day,

X

Not taking the intruder's assurances to heart, the system administrator port scanned all of the systems on the network looking for ports 666 or 9669 and found several other similarly compromised systems. The administrator found other compromised systems by monitoring network traffic for distinctive terms like "#0dayvcd" and "RWAMLCDP."

end example

When responding to an incident on a large network, port scanning may produce too many false positives in which case simple Perl scripts can be created to scan machines on a network and inspect their responses for specific class characteristics to determine if they are compromised. For instance, in the preceding case example, scanning for systems that displayed the distinctive Serv-U logon banner would be more accurate. Also, configuring an intrusion detection system to look for specific class characteristics in network traffic is an effective approach to finding other compromised systems.

19.2.1 Processes as a Source of Evidence (Windows)

When a computer program is executed it is instantiated in RAM, taking up system resources such as memory and file descriptors. Such an instantiation of a program is called a process because it is performing a task or process as it runs on the system. Examples of processes are winword.exe (Microsoft Word for Windows) and lsass.exe (Windows NT's local security administration subsystem). Default processes on Windows 2000 are listed on the Microsoft Web site.[3] However, when investigating a computer intrusion, it is not safe to assume that a program is legitimate simply based on its name or the port it is bound to. Computer intruders take advantage of an investigator's preconceived theories by making malicious programs resemble legitimate ones. It is trivial to name an executable inetinfo.exe and have it listen for network connections on port 80 to mislead investigators into assuming that it is a Microsoft Internet Information Server (IIS). Only a closer inspection of the process, such as which files it has open, will reveal its true nature.

There are a number of utilities that enable investigators to gather information about processes that are currently running on a Windows NT/2000/XP computer. Commands such as netstat and nbtstat are installed with the operating system and other specialized tools that are freely available on the Web such as fport[4] and handle.[5] Although many of the details provided by utilities like handle may not be relevant to the investigation, small segments can reveal useful details about programs and files created by an intruder. The usefulness of these tools is best demonstrated through a detailed case example.

CASE EXAMPLE

start example

The following intrusion detection system logs show an attack against a critical UNIX machine (192.168.128.14) from another important Windows 2000 server (192.168.164.163) on the network:

    [**] [1:1326:1] EXPLOIT ssh CRC32 overflow NOOP [**]       04/24-03:28:43 192.168.164.163192.168.128.14 S: 2445 D: 22    [**] [1:1326:1] EXPLOIT ssh CRC32 overflow NOOP [**]       04/24-07:18:21  3 192.168.164.163192.168.128.14 S: 2888 D: 22 

A port scan of the Windows 2000 server, named "server1," showed many open ports, including one that gave a command prompt to anyone who connected using Telnet:

    % bin/probe_tcp_ports 192.168.164.163    Port 80 (possibly http)    Port 135 (possibly rpc service)    Port 139 (possibly rpc service)    Port 443 (possibly https)    Port 445 (possibly netbios)    Port 1025    Port 1046    Port 1048    Port 1051    Port 1061    Port 1433  (possibly ms-sql)    Port 2025    Port 3372    Port 3389    Port 3497    Port 4362    Port 7904    Port 12323    Port 43958    % telnet server1 12323    Microsoft Windows 2000 [Version 5.00.2195]    (C) Copyright 1985-2000 Microsoft Corp.    C:\WINNT\system32> 

The network cable was disconnected from server1 immediately to prevent further unauthorized remote access. A rapid response and recovery was desired to minimize the impact on business continuity. Management wanted to determine what the intruder changed on the system and what actions were necessary to remove all backdoors.

The output of the netstat command confirmed the ports that were seen with the remote port scan, but did not show the remote addresses of machines that were connected to this system because the network cable had been unplugged. The processes listed using Alt-Ctrl-Del included two unrecognized processes named sqldiagmsrv and sqldiagncv as shown in Figure 19.1. More details about these processes, like how long they had been running, could be obtained using pslist.[6]

click to expand
Figure 19.1: Unusual process viewed using All-Ctrl-Del.

These unrecognized processes were examined more closely to determine what they were doing on the system. The fport command showed that c:\winnt\system32\sqldiagncv.exe was bound to port 12323.

    D:\>fport    FPort v1.33 - TCP/IP Process to Port Mapper    Copyright 2000 by Foundstone, Inc.    http://www.foundstone.com    Pid     Process           Port        Proto    Path    1152    inetinfo    ->    80          TCP      C:\WINNT\System32\inetsrv\inetinfo.exe    484     svchost     ->    135         TCP      C:\WINNT\system32\svchost.exe    1152    inetinfo    ->    443         TCP      C:\WINNT\System32\inetsrv\inetinfo.exe    8       System      ->    445         TCP    556     msdtc       ->    1025        TCP      C:\WINNT\System32\msdtc.exe    960     MSTask      ->    1027        TCP      C:\WINNT\system32\MSTask.exe    1152    inetinfo    ->    1028        TCP      C:\WINNT\System32\inetsrv\inetinfo.exe    892     sqlservr    ->    1029        TCP      C:\MSSQL7\binn\sqlservr.exe    8       System      ->    1031        TCP    892     sqlservr    ->    1433        TCP      C:\MSSQL7\binn\sqlservr.exe    1152    inetinfo    ->    2025        TCP      C:\WINNT\System32\inetsrv\inetinfo.exe    556     msdtc       ->    3372        TCP      C:\WINNT\System32\msdtc.exe    368     termsrv     ->    3389        TCP      C:\WINNT\System32\termsrv.exe    1152    inetinfo    ->    4362        TCP      C:\WINNT\System32\inetsrv\inetinfo.exe    1152    inetinfo    ->    7904        TCP      C:\WINNT\System32\inetsrv\inetinfo.exe    1052    sqldiagncv  ->    12323       TCP      c:\winnt\system32\sqldiagncv.exe    1068    wingtm      ->    43958       TCP      C:\WINNT\system32\wingtm.exe    484     svchost     ->    135         UDP      C:\WINNT\system32\svchost.exe    8       System      ->    445         UDP    256     services    ->    1026        UDP      C:\WINNT\system32\services.exe    516     spoolsv     ->    1030        UDP      C:\WINNT\system32\spoolsv.exe    916     rtvscan     ->    2967        UDP      C:\ProgramFiles\NavNT\rtvscan.exe    1152    inetinfo    ->    3456        UDP      C:\WINNT\System32\inetsrv\inetinfo.exe 

The handle command, which lists which system resources each process is using, showed that the sqldiagncv executable was running with SYSTEM level authority, allowing significant access to the system:

    sqldiagncv.exe pid:       1052 NT AUTHORITY\SYSTEM        18: File              C:\WINNT\system32        e0: Section           \BaseNamedObjects\__R_0000000000f2_SMem__ 

The listdlls command showed the command line parameters that sqldiagncv was executed with as well as its associated dynamic link libraries:

    sqldiagncv.exe pid: 1052    Command line: c:\winnt\system32\sqldiagncv.exe -l -d -p 12323 -t -e cmd.exe    Base        Size        Version            Path    0x00400000  0x13000                        c:\winnt\system32\sqldiagncv.exe    0x77f80000  0x7b000     5.00.2195.2779     C:\WINNT\System32\ntdll.dll    0x77e80000  0xb5000     5.00.2195.4272     C:\WINNT\system32\KERNEL32.dll    0x75050000  0x8000      5.00.2195.2871     c:\winnt\system32\WSOCK32.dll    0x75030000  0x13000     5.00.2195.2780     c:\winnt\system32\WS2_32.DLL    0x78000000  0x46000     6.01.9359.0000     C:\WINNT\system32\MSVCRT.DLL    0x77db0000  0x5c000     5.00.2195.4453     C:\WINNT\system32\ADVAPI32.DLL    0x77d40000  0x70000     5.00.2195.4266     C:\WINNT\system32\RPCRT4.DLL    0x75020000  0x8000      5.00.2134.0001     c:\winnt\system32\WS2HELP.DLL    0x785c0000  0xc000      5.00.2195.2871     C:\WINNT\System32\rnr20.dll    0x77e10000  0x64000     5.00.2195.4314     C:\WINNT\system32\USER32.DLL    0x77f40000  0x3c000     5.00.2195.3914     C:\WINNT\system32\GDI32.DLL    0x77980000  0x24000     5.00.2195.4141     c:\winnt\system32\DNSAPI.DLL    0x77340000  0x13000     5.00.2173.0002     c:\winnt\system32\iphlpapi.dll 

Searching the Registry revealed that the sqldiagncv process was being started as a service named sqldiagmsrv:

    sqldiagmsrv        Type = REG_DWORD 0x00000010        Start = REG_DWORD 0x00000002        ErrorControl = REG_DWORD 0x00000001        ImagePath = REG_EXPAND_SZ c:\winnt\system32\sqldiagmsrv.exe        DisplayName = sqldiagmsrv        ObjectName = LocalSystem        Parameters        Application = c:\winnt\system32\sqldiagncv.exe -I -d -p 12323 -t -e cmd.exe 

The last write time of this Registry key was consistent with the intruder's other activities on the system:

    D:\> keytime[7] system/currentcontrolset/services/sqldiagmsrv    HKEY_LOCAL_MACHINE\system/currentcontrolset/services/sqldiagmsrv, Wed    4/3/2002 14:21:09:971 

A copy of the sqldiagncv executable was placed on an analysis system for further inspection and it quickly became apparent that it was netcat:

    C:\WINNT\system32>sqldiagncv -h    [v1.10 NT]    connect to somewhere:      nc [-options] hostname port[s] [ports]     listen for inbound:        nc -l -p port [options] [hostname] [port]    options:          -d                   detach from console, stealth mode          -e prog              inbound program to exec [dangerous!!]          -g gateway           source-routing hop point[s], up to 8          -G num               source-routing pointer: 4, 8, 12, ...          -h                   this cruft          -i                   secs delay interval for lines sent, ports scanned          -I                   listen mode, for inbound connects          -L                   listen harder, re-listen on socket close          -n                   numeric-only IP addresses, no DNS          -o file              hex dump of traffic          -p port              local port number          -r randomize         local and remote ports          -s addr              local source address          -t                   answer TELNET negotiation          -u                   UDP mode          -v                   verbose [use twice to be more verbose]          -w secs              timeout for connects and final net reads          -z                   zero-I/O mode [used for scanning]     port numbers can be individual or ranges: m-n [inclusive] 

In summary, the intruder used the Windows 2000 system to launch an attack against the SSH server on an internal UNIX machine, thus bypassing the firewall which did not allow connections to the SSH server from the Internet.

end example

In some instances, it may be desirable to capture data in memory relating to a particular process using the pmdump[8] utility. For instance, the following commands show pmdump being used to copy the contents of memory relating to a Pretty Good Privacy (PGP) process:

    D:\>pslist pgptray    Name         Pid       Pri      Thd   Hnd       Mem          Elapsed Time    PGPtray     1332    8    7            150       1264         2:20:33.466    D:\>pmdump 1332 d:\evidence\pgptray.mem 

The resulting memory dump file may contain a PGP passphrase or data in unencrypted form.

19.2.2 Processes as a Source of Evidence (UNIX)

Although the full contents memory can be dumped into a file using dd (e.g. dd </dev/mem > host.mainmemory), this lumps everything together and does not provide information about separate processes. One approach to examining processes on UNIX systems is to use the ps command as shown here, specifying that all processes should be listed using command options like "ps -aux" for most versions of UNIX and "ps -ef" for others:

    % ps -aux I more     USER   PID %CPU %MEM     SZ    RSS   TT    S    START    TIME   COMMAND     root     3   0.4  0.0     0      0   ?     S   Apr 25   64:39   fsflush     root   199   0.3  0.2  4800   1488   ?     S   Apr 25    2:14   /usr/sbin/syslogd     root  3085   0.2  0.2  2592   1544   ?     S 14:07:12    0:00   /usr/lib/sendmail     root     1   0.1  0.1  1328    288   ?     S   Apr 25    4:03   /etc/init -     root  3168   0.1  0.1  1208    816   pts/5 O 14:07:27    0:00   ps -aux     root  2704   0.1  0.2  2096   1464   ?     S 14:05:37    0:00   /usr/local/etc/sniffer     root   163   0.0  0.1  1776    824   ?     S   Apr 25    0:19   /usr/sbin/inetd -s     root   132   0.0  0.1  2008    584   ?     S   Apr 25    0:00   /usr/sbin/keyserv     root   213   0.0  0.1  1624    776   ?     S   Apr 25    0:16   /usr/sbin/cron     root   239   0.0  0.1   904    384   ?     S   Apr 25    0:07   /usr/lib/utmpd 

Additional information about each process, including a list of files and sockets that they are using, can be obtained using the lsof utility. Much of the detail provided by lsof may not be useful in most cases, such as which libraries are being accessed by each process. However, lsof can be useful for finding programs and files created by an intruder and can be compared with the output from ps to find discrepancies caused by rootkits. If a particularly interesting process appears in this list like "sniffer" or "destroyer," an investigator might want to take a closer look. Some types of UNIX allow one to save and view the contents of RAM that is associated with a particular program using the "gcore" command.

Another approach to examining processes on a UNIX system is through the /proc virtual file system. For instance, the following files on a Linux system are linked with the command line parameters, memory contents, and other details associated with a running netcat process:

    $ ls -l /proc/1104    total 0    -r--r--r--      1    eco    eco    0      May 17     12:36    cmdline    lrwxrwxrwx      1    eco    eco    0      May 17     12:36    cwd  ->    /usr/local/bin    -r--------      1    eco    eco    0      May 17     12:36    environ    lrwxrwxrwx      1    eco    eco    0      May 17     12:36    exe  ->    /usr/sbin/nc    dr-x-----       2    eco    eco    0      May 17     12:36    fd    -r--r--r--      1    eco    eco    0      May 17     12:36    maps    -rw------       1    eco    eco    0      May 17     12:36    mem    -r--r--r--      1    eco    eco    0      May 17     12:36    mounts    lrwxrwxrwx      1    eco    eco    0      May 17     12:36    root -> /    -r--r--r--      1    eco    eco    0      May 17     12:36    stat    -r--r--r--      1    eco    eco    0      May 17     12:36    statm    -r--r--r --     1    eco    eco    0      May 17     12:36    status    $ more /proc/1104/cmdline    /usr/sbin/nc-l-p31337-t 

The grave-robber program in The Coroner's Toolkit can be used to collect process information and other system details, including the following:

    -rw-r--r--    1    root    root    1558129    May 30    18:50    coroner.log    -rw-r--r--    1    root    root     154596    May 30    18:50    MD5_all    -rw-r--r--    1    root    root       5618    May 30    18:50    error.log    drwx------    2    root    root       4096    May 30    18:50    trust    drwx------    2    root    root       4096    May 30    18:50    user vault    drwx------   10    root    root       4096    May 30    18:49    conf_vault    -rw-r--r--    1    root    root    2939919    May30     18:48    body    drwx-------   2    root    root       4096    May 30    18:48    command out    drwx------    2    root    root       8192    May 30    18:48    icat    drwx------    2    root    root       8192    May 30    18:47    proc    drwx------    2    root    root       4096    May 30    18:47    removed_but_running    drwx------    2    root    root      16384    May 30    18:47    pcat    -rw-r--r--    1    root    root      10470    May 30    18:45    body.S 

The "coroner.log" documents each action taken by grave-robber along with the date and time. Extracted data, such as recovered files, and process memory obtained using pcat and from the /proc virtual file system are organized into directories. The output of certain commands like lsof and ps are saved in the "command_out" directory and a mactime database (a.k.a. body file) of all files on the system is created. System configuration files and other files of interest are also preserved. Additionally, grave-robber calculates the MD5 values of all files, including the file containing the MD5 values. Even though a log file is created when grave-robber is run, it is advisable to document the process by taking notes and using the script command as discussed in Chapter 15.

19.2.3 Windows Registry

As demonstrated in previous case examples, intruders use the Registry to ensure that programs they have installed stay running, even after the system is rebooted. For instance, Trojan horse programs often have associated entries in the Registry. The most common locations in the Registry for Trojans are:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Run    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\RunOnce    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\RunOnceEx    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnceEx   HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices 

This list is not exhaustive since intruders regularly think of new ways to utilize the Registry such as making entries in the following keys:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs    HKEY_CLASSES_ROOT\exefile\shell\open\command    HKEY_LOCAL_MACHINE\Software\Classes\exefile\shell\open\command 

The default Registry value for version 7.2.1 of SubSeven is "WinLoader" and for Back Orifice 2000 it is "UMGR32," but these can be modified to make them harder to detect. Also, some Trojan horse programs do not just use the Registry. For instance, Subseven can be configured to start using entries in WIN.INI (e.g. run = subseven.exe) and SYSTEM.INI (e.g. shell = explorer.exe subseven.exe).

19.2.4 Acquisition Over Network

When it is necessary to make a bitstream copy of the hard drive on a compromised system, it is possible to do so over the network. For example, the following shows one partition on "host13" being copied using dd to a remote system called "examiner" via netcat:

    host 13# df -k    Filesystem              kbytes       used        avail   capacity     Mounted on    /proc                        0          0            0         0%     /proc    /dev/dsk/c0t3d0s0       134335      30698        90204        26%     /    /dev/dsk/c0t3d0s6       737894     461662       217201        69%     /usr    fd                           0          0            0         0%     /dev/fd    swap                    139944      29044       110900        21%     /tmp    host13# dd bs = 4096 if = /dev/dsk/c0t3d0s0 | nc examiner 3416    examiner# nc -l -p 3416 > host13-c0t3d0s0.dd    examiner# mount -o ro,loop,ufstype = sun -t ufs host13-c0t3d0s0.dd /mnt/host13 

There are other methods of acquiring a bitstream copy of a disk over a network, including using Open Data Duplicator (ODD)[9].

19.2.5 Classification, Comparison, and Evaluation of Source

When investigating computer intrusions, it is often necessary to inspect files closely to determine what they are and how to interpret them. One approach to classifying files placed on a system by an intruder is to search the Internet for files with similar characteristics. For instance, the denial of service attack tools that were used to attack Yahoo and other large Internet sites contain information that can be useful for locating the source of the attacks. For instance, the following lines can be extracted from a denial of service tool called "trin00." The IP addresses at the end indicate where the "trin00 master" programs are located on the Internet. The computers running the master programs may have useful digital evidence on them:

    socket    bind    recvfrom    %s %s %s    alf3YWfOhw.V.    PONG    *HELLO*    10.154.101.4    192.153.76.84 

In addition to classifying a certain piece of digital evidence, it is often desirable to find unique characteristics that differentiate a given piece of digital evidence from other, similar pieces of digital data. In particular, it is very desirable to be able to determine the source of a piece of digital evidence. For instance, being able to show that a given sample of digital evidence originated on a suspect's computer could be enough to connect the suspect with the crime.

CASE EXAMPLE (LONDON 2002):

start example

21-year-old Samir Rana, nicknamed "t0rner," was arrested following a year-long investigation into the creation of the Linux rootkit called "tOrnkit" and on suspicion of being a leading member of the infamous hacker group "Fluffi Bunni." Investigators had copies of the rootkit, IRC chat logs, and other evidence indicating that the suspect was the creator of tOrnkit. It was also reported that the suspect owned the pink stuffed toy depicted in website defacements by Fluffy Bunny.

end example

[3]http://support.microsoft.com/support/kb/articles/q263/2/01.asp

[4]http://www.foundstone.com

[5]http://www.sysinternals.com

[6]http://www.sysintemals.com

[7]Executable version of keytime.pl from http://patriot.net/~carvdawg/per/.html

[8]http://ntsecurity.nu

[9]http://odessa.sourceforge.net




Digital Evidence and Computer Crime
Digital Evidence and Computer Crime, Second Edition
ISBN: 0121631044
EAN: 2147483647
Year: 2003
Pages: 279

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net