[Maarten Van Horenbeeck] [Information Security] [Resources]

Technology Crime Investigation

Last update: May 24th, 2006


Statement of Purpose:
This document serves to provide guidance on the conduct of technology crime investigations. Each investigation is different and may as such not contain all of the below steps. This document aims to include common best practices used by forensic investigators. As such, should you have any suggestions, please contact me at maarten@daemon.be

Crime Profiling
Preparing the organisation
Responding to an incident
Crime Scene Management
Live system data gathering - Unix
Live system data gathering - Windows
Live system data gathering - Cisco routers
Retrieving evidence
Recovery of deleted files
Analysis of evidence
Malicious Code Analysis
Questioning a suspect or victim
Mobile Forensics
Anti-forensics

Appendix A: Interpretation of common log files
Appendix B: Law Enforcement Contacts

Crime Profiling [back]

Crime profiling is an investigative tool that allows the investigator to make a closer assessment of the perpetrator of a certain crime. It consists of a close behavioral analysis of all evidence, in the hope to gain better knowledge of the criminal and his choices during a crime. Combined with physical evidence, the criminal can then be matched against previously known types, which can help in linking one crime to another.

Profiling can be conducted in two basic, but materially different ways. Deductive profiling is the following of logic sequences of fact regarding a specific case to generate a profile. Inductive profiling studies averages regarding certain crimes and assumes that a criminal who commits one specific crime is likely to have a similar background to previous criminals who committed an identical crime.

In Information Technology crime, it is difficult to work with offender profiles to such degree that we can use them efficiently to identify a culprit. Most cases do not give us sufficient information on the physical behavior of a person; which conflicts with one of the basic laws in criminology: Locard's Exchange Principle, which states that when an offender comes into contact with a location or another person, he always leaves something of himself behind and takes something away of that location or other person. In the digital world, this no longer holds true, unless we can consider bits and bytes to be that "something".

If we want to thoroughly investigate computer crime, we have to do just that. Criminals defrauding a bank over the internet apply a certain methodology. If this methodology works for them, it is likely they will continue to use it, with some minor changes to adjust to new technology. This is what the IT Crime Profiling principle is based on.

Some organizations are building deductive profiles, such as the Hacker Profiling Project. There is some discussion as to how useful these will prove, especially since they sollicit 'hackers' to provide information which will form the basis of all profiling activity.

Likely to prove more useful, in my opinion, is attack profiling. As an investigator, we need to be aware of certain attacks taking place on the internet. At this point in time there are no known approaches to perform this, and most work is put in vulnerability identification. Organizations such as the CERT and NIST have built extensive databases on vulnerabilities that affect computer networks. Attack profiling is done to a lesser degree by the SANS Institute and OWASP, by categorizing threats that may affect a network. This type of information is extremely useful, but in the future should be extended by including specific attacks and actions taken after a compromise succeeded. Compiling this information allows an investigator to more easily identify the goals of a specific attacker.

This type of profiling can be conducted by gathering evidence not only at the level of the compromised host, but beyond, such as traffic taking place on the external perimeter which was blocked and deemed harmless, DNS requests originating from certain hosts, the use of specific proxies, application attacks such as specific types of failed authentication. All this information can help us in linking specific attacks. A great example of some decent profiling by an IT security specialist can be found here.

Preparing the organisation [back]

While forensics is a process that takes place 'after the facts', a significant component of any investment in a forensics program should take place in the preparation for an incident. Some things to take into account:
In addition, think of how you will detect an incident that requires investigation? Intrusion Detection is a very versatile tool, and consists of monitoring your assets and the communications between them for anything that may be part of a security incident. Several types of intrusion detection may be of use to your organization:

Deploying intrusion detection and prevention functionality
Intrusion detection technology allows for detection of the materialization of a certain threat. Intrusion detection requires incident response processes to be defined in order to be successful. Once a threat is identified, action needs to be taken to mitigate the effect of this threat. Intrusion prevention technology, on the other hand, will automatically take responsive action to mitigate the threat.

Network based intrusion detection/prevention
Network based systems inspect network traffic to identify potentially malicious events. They can be either signature- or anomaly-based. Signature- based solutions inspect network traffic for certain attack signatures. For example, the transfer of a malicious file may be detected and alerted upon.

Anomaly- based network intrusion detection systems verify whether existing network behavior is in line with the expectations generated by previous behavior. For example, if a network usually only makes connections to a limited set of hosts, and suddenly unexpected connections to machines in China are detected, they will flag a security event.

Signature-based solutions do sometimes contain signatures to detect on certain malicious code. For example, if a network vulnerability is exploited by an attacker, or a certain malicious file is transferred over the network, these may be identified by the signature-based solution in a way very similar to that of anti virus solutions. However, some significant drawbacks apply: monitoring-only solutions that are deployed ‘out of band’, outside the critical path of the network between sender and recipient, may not see all traffic to the same degree as an anti virus solution would. In addition, attack tools can be written as to avoid detection by these tools.

Anomaly-based solutions could be of help if the traffic generated by for example a Trojan is sufficiently irregular. In this report, for example, the backdoors connecting on non-standard ports, such as 7128, have a higher likelihood of being detected by such solution than those that connect on the regular HTTP port of 80.

Host based intrusion detection/prevention
Host based intrusion detection systems also have two common ‘modus operandi’. Most solutions detection intrusion by reviewing local log files, investigating when potentially malicious code is running on the system or when certain vulnerabilities (e.g. buffer overflows) are being exploited. These solutions are likely to detect these targeted Trojan attacks as they tend to make changes to critical system objects, such as the Windows registry.

A second group of host intrusion detection/prevention systems operate by profiling code running on the system. Whenever an application attempts to embark upon an action which does not match its profile, it is halted. These solutions are highly likely to identify these targeted Trojan attacks, as they tend to behave outside the specifications of the normal system.

Responding to an incident [back]

Response to an incident needs to address a number of basic requirements of the organisation. The SANS institute, a leading authority in the field of IT Security, recognizes the following basic steps in each incident response:


Crime Scene Management [back]

As technological Crime Investigations are only a subset of regular criminal investigations, the golden rule of crime scene management remains in force:

"Never touch, change, or alter anything until it has been documented, identified, measured, and photographed . . . when a body or article has been moved, it can never be restored to its original position."

Ofcourse this needs to be translated into the field of Information Technology. There, we have two major items which we need to keep under control:
The amount of control which needs to be exercised by the above strongly depends on the situation at hand. In some casees, limiting external network access may not be applicable, while in other situations, access may not be easy to control without moving the affected devices to a lab.

Live system data gathering - Unix [back]
This information is to be gathered from the affected system prior to any changes taking place (such as a hard shutdown), unless there is reason to assume that the cracker may become aware of your investigation due to them. The target output of each of these devices should ideally be a USB memory stick, if available, or a socket opened with cryptcat over the network.

An example of a cryptcat transfer:
Workstation: cryptcat -l -p 5689
Investigated machine: ps aux | cryptcat "workstation IP" 5689

- Obtain the date of the affected system
date > /data/date.txt

- Which users are logged in?
w > /data/w.txt

Running processes
ps -auwx > /data/ps.txt

- Ports open and listening processes
netstat -anp > /data/netstat.txt

- Information on all interfaces (PROMISC?)
ifconfig -a > /data/network.txt

- Listing of all files with access time, inode change time and modification time
ls -alRu / > /data/files-atime.txt
ls -alRc / > /data/files-ctime.txt
ls -alR / > /data/files-mtime.txt

- Bash history of root (and other users)
cat /root/.bash_history > /data/roothistory.txt

- Last logins to the system
last > /data/last.txt

- Basic check of access logs looking for access to tmp directories
cat /*/access_log | grep "%20/tmp" > /data/access.txt cat /*/access_log | grep "%20/var/tmp" > /data/access.txt

- Listing of files open by processes
lsof -i > /data/lsof.txt

- List of loaded modules
lsmod > /data/lsmod.txt

- Obtain a list of all suid/sgid files
find / -perm -004000 -type f - print find / -perm -006000 -type f -print

- Information which may be useful to assess whether LKM rootkits are loaded
cat /proc/ksyms > /data/ksyms.txt cat /proc/modules > /data/modules.txt kstat -s > /data/kstat.txt strings /proc/kmem > /data/kmem.txt

Execute a basic check to see whether rootkits are active on the affected system:

- Verify MD5SUM of "known good" binaries with their current installation.
- Verify for hidden processes
Check processes found by "ps" with the amount of those in /proc. A mismatch may indicate hidden processes for your account (which is not so good if you have administrator credentials).
- Use tools such as chkrootkit and rkhunter
- Look for common configuration and installation files of rootkits, they may in some cases be forgotten
If you do find source code or a module indicative of a rootkit, look for strings common in the compiled file in the output previously stored of "strings /proc/kmem".

- Verify installed modules and module symbols

Live system data gathering - Windows [back]
- Review the event log
- Check the Recycle Bin of each profile
- Verify the registry for added startup items
- Copy the page file for later analysis (win386.swp/pagefile.sys)
- Look for broken links on the system (tools which were removed). This can be done using the chklnks.exe tool from the NT Resource Kit
- Verify locally stored files from the web browser. A tool which can be used for Internet Explorer is Pasco
- netstat -anp: verify listening processes
- fport: verify which processes have listening sockets open
- listDLLs: show command line arguments for each process running
- Verify anti-virus logs for e.g. trojans received through e-mail
- Use PestPatrol to find known backdoor software on the system
- Verify the service pack level to assess known vulnerabilities (CSDVersion key in the registry)
- Run "rasusers" to obtain all users connected through RAS.
- Run "net start" to obtain a list of all running services
- Verify scheduled jobs with "at", especially for listening shells scheduled to start at certain times
- Check the registry to obtain SIDs for those systems to which the current user has logged on. Users will only have the SID of a remote domain in their Profile list if they have succesfully logged onto the domain in the past.

Live system data gathering - Cisco routers [back]

- sh clock: Gets the current time set on the Cisco router.
- sh users: Obtains the users whom are currently logged on.
- sh version: Obtain version information, as well as uptime from the router.
- perform a portscan for the listening ports : It is also a good idea to perform a configuration review to see which services are enabled.
- sh route : Obtain routing information from the device. This is necessary to investigate e.g. route insertion attacks.
- details for the active routing protocols : Such as sh ip ospf neighbor. This makes it possible to see which hosts are currently transmitting route updates, and through which avenues certain dynamic routes are learned.
- sh int : Information on each interface. When was it last enabled, which IP address and subnetmask is assigned, is there an access-list applicable ?
- sh arp : Are the hosts which the router knows truly the hosts which are on the network, or has a certain IP been hijacked?
- sh tcp brief all This command shows a conscise description of all TCP connection endpoints. This gives you an idea of all TCP connections ending on the router. The command sh tcp provides you with a more detailed overview.
- sh ip sockets This command shows a brief overview of all remote users connected to the router.
- sh ip nat translations In order to make sure you are able to correlate events consistently, it is important to have all established NAT translations at the time of the incident. These can be retrieved using this command.
- sh ip cache flow Provides active information on the NetFlow data collected by the router. If this information is stored remotely, verify whether these logs are consistent with that available on the device.
- sh ip cef Displays information from the FIB (Forwarding Information Base). This includes detailed switching information which is mainly router internal, but may be useful to assess network load and routing.
- sh ip mds forwarding Displays information from the Multicast Forwarding Information Base. Equivalent to the above, but for multicast.
- sh snmp user Information on log-ons and actions of users for certain traps. Useful to assess whether a community string was compromised.
- sh clock detail Are we still in sync with the network NTP server ?
- sh logging What is happening ?
- sh ip brief all Give concise description of all current TCP endpoints
- sh reload When was the device last reloaded ?

Recovery of deleted files [back]
Recovery of deleted files is a bit easier on Windows than on Unix. Both operating environments have entirely different ways of getting rid of files after they have been deleted:
Retrieving evidence [back]

If the initial live system investigation has revealed items of concern, the next step would most likely be to duplicate the entire system for further lab investigation. Perform a hard shutdown of the system, and then use a tool to correctly duplicate the drive. It is important to be aware of two legal differences in evidence:

A forensic duplicate consists of every bit of the raw bitstream stored in an identical format (e.g. using an identical disk).
On the other hand, a qualified forensic duplicate is a copy where every bit of information is still stored, but perhaps in a different form, such as an ISO image.

Both are submissable as evidence, but the "best evidence" should be used, e.g. the original disk.

Bit-to-bit copy with dd/dcfldd:
dd if=/dev/hda of=/dev/evidence1
dcfldd if=/dev/hda of=/dev/hda

Once an image is acquired, it needs to be analyzed. There are several ways and tools of analyzing an image for forensic evidence. The dominant commercial tools in the marketplace are Guidance Software’s Encase and AccessData’s FTK. These pieces of software prove especially useful in the parsing of file formats. While free tools are available to perform all the activities of these commercial sets, parsing specific files can be a very, very slow process when performed manually.

The most well known open source forensic toolkit is called the Sleuth Kit. It consists of command line utilities to perform very specific functions on disk images. In addition, a graphical user interface is available in form of Autopsy.

Sleuth Kit tools all operate in a very specific layer. Generically speaking, there are four layers of interest:

The File System Layer specifies exactly how data is organized on an image, such as the range of blocks/clusters. Depending on the file system, the fsstat tool provides all information it understands about the image's file system. At this level we're not really concerned about the actual contents, we're just preparing on how to read them.

Much more practical, the File Name Layer consists of actual file names, located in the parent directory. Files have their human names in this layer. Two tools exist, ffind which can be used to find a file name using a certain inode, and fls, which generates lists of files and directories in a forensic image.

In the Meta Data Layer, data is contained that bridges the file name layer with the data unit layer. It includes directory entries and inodes, and describes when files were last accessed, or which data units are occupied by a certain file. Files are addressed by numbers here. Tools that operate on this level are icat, ifind, ils and istat

The Data Unit Layer is the deepest level the Sleuth Kit can move into. It consists of the actual data units, which are blocks of a fixed size (referred to as clusters on some platforms) and actually contain the data. The principal tools here are dcat, dls, dstat, dcalc.

Brian Carrier, the lead developer on the Sleuth Kit, and a former @stake employee, has done a great job linking all of these tools together. Each of them has a specific function and each function returns on a specific layer. For example, the 'stat' tools return detail and statistical information about a certain structure, and are available at each level. As such, you have an "fsstat" on the file system layer, an 'istat' on the meta data layer and 'dstat' on the data unit layer.

String searching
grep -a -B40 -A40 "searchstring" /dev/hda1 > stringmatch.txt

Analysis of evidence [back]

In some cases, files may need to be compared against a list of 'known goods' or 'known bads' to identify whether investigating it further may be of use to the investigation. The most significant of the 'known good' lists is produced by the NIST, which makes available the National Software Reference Library. This list contains MD5 hashes of several well known operating systems and software applications, both commercial as free, which can be used to exclude known goods from an investigation. Lists of 'known bads' are more difficult to come by. I maintain a private collection of malicious code purely for comparative purposes, and also often use the anti virus database of the open source Clamav project.

Clamav's sigtool allows you to easily write signatures for new malware. That is not its only use, though. The ClamAV database is very useful for detection of recent malware (due to the project's relative youth they lack a bit of signatures in the old malware department). As much of today's malware is static, and it is fairly easy to write good signatures using merely the MD5 hash of an executable, some of the signatures can be exported from the database as MD5 hashes and can be of use as a known bad set. Signatures that are built on their pattern matching and protocol interpretation mechanisms can still be used to better understand the malware at hand

sequoia:/tmp$ sigtool -u main.cvd
sequoia:/tmp$ cat main.db
...
AMorph.367=25cd210e1f0e07b41791b4572ae55a595bcd00b43fbe
Amstrad.1=217260ba7d02b8023dcd21a31401
Amstrad.2=0e0100002e8c0610012eff2e0e01
Amstrad-740=7257ba1202b8023dcd21a314018bd8
Amt.3000 (Clam)=3f4d5a7403e95301e8c9fcc41e4800268b470fb10cd3e0
...

Analyzing malicious Office files

The implementation of plenty of organized crime currently takes place through the distribution of malicious Office files. Some small tools can come in really useful if you want to avoid attaching a debugger to your Word session. Consider using your stock anti-virus. In many cases, it might be able to spot malicious files when they exploit a known vulnerability. Some names attributed to malicious Word files so far appear to generically trigger on malicious files:
Trojan-Dropper.MSWord.1Table.bo
Exploit.MSWord.Gen
Exploit-1Table

Others vendors decided not to include patterns for exploitative Word documents, but provide them for their payload only, when it gets executed. While this generates less false positives, it also provides less protection for malicious code that is targeted, or has only recently been distributed. It also misses the exploit on the e-mail gateway. You may want to check in with your vendor to see what their approach to the issue is.

Another tool that is still useful is the regular hex-editor, or even strings. Seeing the MZ ‘magic’ and a stub executable, or even the UPX markers in a Word file is unusual:

dhahran:/tmp# hexdump -C malicious.doc | grep "UPX"
0103d0 55 50 58 30 00 00 00 00 00 20 12 00 00 10 00 00 |UPX0..... ......|
0103f0 00 00 00 00 80 00 00 e0 55 50 58 31 00 00 00 00 |........UPX1....|
010420 55 50 58 32 00 00 00 00 00 10 00 00 00 60 12 00 |UPX2.........`..|
0105e0 55 50 58 21 0c 09 05 06 5c 5d 41 a8 32 6d b5 68 |UPX!....\]A.2m.h|

Other useful tools have been released by Sourcefire and SecureWorks. SourceFire’s OfficeCat scans an Office file for the exploitation of a long list of known vulnerabilities.

Sourcefire OFFICE CAT v2
* Microsoft Office File Checker *
Processing c:\office\malcode2.doc
VULNERABLE: CVE-2006-2492

SecureWork’s Fess, short for File Exploit Scanning System, is an open-source tool that scans files for exploits using a Snort-like inspection language. Its basic release does not contain Office sigs, but one was released a few months later on the Fess-users mailing list. It’s a powerful tool, but you may need to write signatures yourself based on what specifically you are looking for. It’s a tool that would allow you to scan Office files for shellcode, for example.

Microsoft also has tools to bring clarity into the format. In essence, Microsoft Office files are of OLE Structured Storage nature, and consist of numerous ‘storage’ and ‘stream’ items. In order to identify each of the storage items, at the end of 2006, Microsoft released a tool called STG, which can display the different structure components and their contents. This can prove valuable when you’re trying to identify malicious components. Many of you may have worked with a similar tool, DocFile viewer, part of Visual Studio.

If none of these help you identify the nature of the malicious code, a debugger could come in very handy. Plenty of free debuggers exist for the windows environment, such as Ollydbg and WinDBG. Both can easily attach to a running process, such as winword.exe, but the latter can also easily be implemented as the Windows port-mortem debugger (windbg -I), which means it will automatically launch upon an application crash, instead of Dr Watson.

Malicious code analysis [back]
More often than not, you will find binaries on the investigated systems of which you cannot determine the cause. The following gives a quick overview of the basic actions to take in order to investigate them and ascertain their meaning in the crime scene:

- Make sure you are running in a sandbox environment (VMWare, UML, Vservers)
- Verify the following aspects of the binary under investigation:
  1. Is the binary compiled in debug mode?
  2. Is the binary statically or dynamically compiled?
  3. Is the binary packed (UPX, ...) ?
Whether a file is compiled in debug mode can be ascertained by using the "nm" tool. This tool can display the symbol types used in a certain binary. If these are somewhat readable, and include source code filenames as well as line numbers, this usually provides valuable information in identifying the actual tool.

To verify whether a file is statically or dynamically compiled, use the "file" tool. This will display which operating system and binary format the file was compiled for, as well as whether it is statically compiled or dynamically linked.

Using "strings" is an easy way to verify whether a binary is packed with UPX. If this command shows you a UPX version, the file need to be unpacked first prior to completing your analysis.

The above items also provide you with insight in what exactly the binary is supposed to do. If you are unable to assess the file's goal correctly, you may wish to resort to dynamic analysis of the tool.

In order to verify the tool in working order, we need to have some controls in place to limit our exposure. One of the things most advisable is once again to run the tool within a sandbox. When using VMWare, it is possible to enable the option non-persistent writes which means that all writes to the filesystem will be undone after a shutdown of the virtual machine. Additionally, it would be best to run the tool on a system which is linked to a "virtual internet", e.g. that DNS resolution and IP routing is possible, but where all access is dropped on a perimeter firewall/router. This is done to prevent the tool from alerting the actual cracker that his tool has been acquired by an investigator. However, take care even with DNS resolution. By crafting DNS queries, which are forwarded to internet DNS servers, it would still be possible to "patch through" a call to an internet host (DNS server).

When these constraints are fulfilled, dynamic tool analysis comes down to actually executing the malicious code, while monitoring the entire system and its network connectivity in detail.

Several steps should be followed in such analysis, these are detailed and described below:
  1. Intercept system calls: Under Unix, this can be done using the "strace" tool. Running "strace filename" will give you a nice overview of all system calls done by the tool. All events preceding the "getpid()" call are internal to the operating system, while starting up the application. Events after this are actually coded into the executable code. It is especially important to have a look at calls such as "open", "exec", "execve", "read", "write", "unlink", "lstat", "socket", "close", which indicate files being opened and written too, as well as Unix socket activities (network and local). Less important are calls such as "brk", "mmap", "munmap" which are indicative of memory management activity.
  2. Monitor Network Activity: Run a sniffer on an independent machine connected to the testing sandbox with a hub. This to prevent from the tool actively monitoring whether a sniffer is running. Ofcourse, the sniffer can also run outside of the sandbox and monitor the virtual interface. Make sure to disable all other networking tools on the device prior to starting the actual tool. This way it can be ascertained with a high degree of confidence that the tool is actually generating this traffic.
  3. Registry Interaction: Under Windows, tools such as regmon can monitor any changes made to the registry in realtime. If there is any expectation that the tool may actively try to detect regmon, make a copy of the registry prior and after running the tool, and verify these results on an independent machine.
  4. File system interaction: Running a full list (including checksums) of all files on the connected filesystems gives you insight in what has changed. On Unix, ls -R should suffic, on Windows, specialized tools such as filemon could be helpful.
  5. Run the file through an AV scanner: Run the file through a virus scanner supporting heuristics checking. Many new virusscanners suffice, but I tend to run the file through older versions of Thunderbyte Antivirus as well, due to their excellent and very verbose heuristics engine.
Questioning a suspect or victim [back]

Questioning, within the context of an IT Security Investigation, may take place in two separate situations. You may either want to interrogate a potential culprit, hereafter called the "suspect", or you may wish to question a victim to obtain additional information. Obviously both of these situations request a separate approach.

A well known interrogation technique, often featured in film and television series is the Reid technique. This technique frequently involves the use of lies ("we have evidence you were the culprit!") to convince the subject into admitting his guilt. While effective, the technique has often been criticized for eliciting false confessions.

FAINT is another technique commonly used during forensic investigations, and well adopted by the technological Forensic industry. It's short for the Forensic Assessment Interview and Integrated Interrogation technique, in which the subject is submitted a test of 30 fairly generic questions. It then uses specific clues that can be spotted in the way the subject answers these questions, to assess the validity of his statements. Actual culprits will likely minimize penalty ("he shouldn't be punished too badly, it depends on the situation") while trying to create additional subjects ("Ellen may have done it"). Much of this is described in Nathan J. Gordon's book "Effective Interviewing and Interrogation Techniques".

Non-verbal analysis
Many techniques have been developed to perform non-verbal analysis, to ascertain whether your suspect is telling the truth. Most of these are scientifically not proven, and should thus be used with care.

A common technique is SCAN, short for Scientific Content Analysis. It was developed by Avinoam Sapir, an Israeli polygraph examiner. It consists of allowing the subject to write down in his own words what happened. His writings are then evaluated for very specific nuances, such as the use of pronounce, how storylines are connected, changes in timing (did the subject cover the night an incident occured in great depth while only covering the preceding and following days very briefly. The goal is to assess the validity of statements through such behavioral analysis.

Another researcher who studied this field in-depth is Paul Ekman, from the University of San Francisco. He has published several books on kinesic interrogation, which deals with the reading of subtle signals pronounced by a person physically, while stating his story. Many of these techniques are taught worldwide, but are heavily debated as to their effectiveness.



Mobile forensics [back]

Technically speaking, all information located on the phone could be considered potential evidence. In some cases, seemingly benign information such as battery contents may be useful in establishing a relevant fact – such as how long ago the owner last recharged. However, on this specific phone, the following information can prove particularly useful:
  1. Contact list
  2. Inbound and outbound calls
  3. Calendar
  4. Text messages
  5. Deleted text messages
  6. E-mails
  7. Multimedia files
In addition, the SIM card may harbour additional useful information that could help to identify the phone, previous calls made, text message and location information. Tools that are able to read the full SIM file system should all be able to review these information items.

Three generic choices exist for retrieving data from the mobile device. These are the use of a data cable, an infrared connection or BlueTooth. In this specific case, the mobile phone has been identified as not supporting infrared, and as such only a data cable or Bluetooth remain as viable possibilities.

A direct cable connection offers the highest guarantee with regards to integrity, as both endpoints of the cable are directly under our control. Infrared is similarly trusted, as the beam is direct and as such can be controlled. When using BlueTooth, specific wireless attacks would apply, and there is less guarantee as to the integrity of all traffic. All further investigation will need to take place within a Faraday cage to ensure no RF signal is leaked or malicious RF signals are introduced by a third party.

Acquisition of data from the SIM card is preferably done directly by reading out the data using a smart card reader. This allows us to fully acquire all information without having it interpreted by the phone’s software. However, in order to remove the SIM card from the phone in this model, the battery needs to be removed. This could lead to loss of valuable information stored in the phone’s memory.

High-level acquisition protocol

When investigating a mobile device, there are two possible methods of acquiring data - logical and physical, as with regular hardware.
  1. Logical acquisition: this method of data retrieval reads and interprets the file system to acquire stored information. By doing so, it can add context and meaning to any data retrieved, and identify certain contents as belonging to a defined type of file;
  2. Physical acquisition: a full image, without interpretation, of a drive is read and stored to a file. This allows an investigator to have a full and clear image of the drive, but will make analysis more difficult as no distinction is made between different files or even directories.
Most acquisitions will take place over USB. In order to guarantee evidence integrity in a court setting, a USB sniffer such as the one belonging to the Device Monitoring Studio should be used in each such acquisition. The output of this software allows one to prove that all evidence acquisition consisted of read-only transactions only. Such information will also prove most useful to evaluate an end-user tool from a forensic perspective.

Note that the use of a write blocker could be considered, but in most cases will not be possible. USB write blockers, as advised per the NIST Guidelines on Cell Phone Forensics (NIST, 2006, p.48) would be successful in allowing read access while blocking write commands to mass storage devices such as memory sticks. However, cell phones are generally accessed through a binary protocol, which is usually not supported by such write blocker. As such, any commands transmitted to the phone would be blocked, preventing forensic access. In order to still prove our close adherence to the basic evidential principles of not changing evidence, sniffer logs should be maintained within the chain of custody.

Upon completion, where possible, any gaps in data gathering should be noted, and any information collected needs correlation with the information available through the phone’s user interface.The SIM card can then removed from the phone to allow for its information to be retrieved directly using a smart card reader. In order to access the SIM card, a PIN code is required. However, where this is not available, the phone can still be unlocked by providing the IMSI number to the proprietor of the mobile network that issued the SIM card.

Note that should the PIN code not be available, this may cause some issues during acquisition of the actual phone’s information. Without the PIN code, most forensic tools would not be able to gain access to the device, and as such would not be able to gather the IMSI from the phone. In order to obtain the IMSI, the SIM card would have to be removed and read separately. This would have required the battery to be removed from the phone, leading to potential loss of volatile data.


Anti-forensics [back]

Anti-Forensics is the group of methods used to prevent forensic investigators from achieving the goal of any investigation they conduct. It aims to hide information or prevent an investigator from accessing it. For a long time anti-forensics has been commonly applied in corporate fraud, where organizations needed to dispose of evidence of fraudulent transactions. Recently however, it has become common in day-to-day computer compromises, especially those involving an aspect of industrial espionage or credit card fraud.

A common anti-forensic method are Encryption, in which data is encrypted using either a private algorithm with embedded key or a common algorithm with a remotely stored key. One such example is the packing of malicious code prior to storing it on a compromised server. Steganography consists of the hiding of data so that it is more difficult to identify. This is often done by embedding data in graphics or music files on a server, by using a number of less important bits in the image - someone viewing the media file will not see a difference, but the attacker knows the location where his data is stored and can easily access it.

Anti-forensics processes can also be embedded in the operating system. Rootkits could be used to prevent certain changes from being made to the system, or from making those changes visible to users and investigators. If the rootkit no longer makes certain alterations, such as update modification times, even after acquisition and investigation using forensic tools it will be difficult to work with timelines. If changes are made invisible on-the-fly using a rootkit, later acquisition and analysis efforts will still provide an investigator with information. Root-kits can also be an issue on the application level. Several researchers have published information on Database Rootkits. As these Database applications have grown, they have incorporated increasing amounts of functionality from the base operating system. Once compromised, an attacker can easily alter system views or add threshold actions, as such hiding certain database jobs from sight relatively easily.

There is a wide set of anti-forensic tools available. Common wipers are srm, wipe, fwipe and grind. The Defiler's Toolkit was a tool first discussed in Phrack edition 59, in an article by the grugq. It is a set of programs designed specifically for anti-forensic purposes on the ext2fs filesystem. Necrofile, one of its components, allows easy identification of inodes matching a certain deletion time, and subsequent scrubbing of them. This ensures that not only data blocks are wiped, as with common wiping tools, but also all other metadata which could prove a file's previous existence. Klismafile, another Defilter tool allows the secure overwriting of deleted directory entries. RuneFS, by the same author, uses the bad block inode, which precedes the root inode, to allocate blocks. This defeats common forensic tools such as TCT and TASK, which do not consider the bad blocks inode in an investigation.

More recently, in 2005, HD Moore's Metasploit project started concentrating on anti-forensics. Under the Metasploit Anti-Forensic Investigation Arsenal (MAFIA), several tools have been released. Timestomp allows the modification of all four timestamps on the NTFS file systems: modification, access, creation and entry modified. Slacker allows you to hide files within NTFS slack space. Sam Juicer is a tool which greatly matches the current tendency of attackers to do all in RAM while not touching the disk - it allows dumping of hashes from the SAM without them ever being written to disk.


Appendix A: Interpretation of common log files [back]

CheckPoint logs
In order to correctly read CheckPoint logs, you first need to determine whether you have the logs available in binary or text format. By default, CheckPoint uses a proprietary binary logging format, which can be read using tools made available by CheckPoint (such as the SmartDashboard Log Viewer, or the command line "fw" tool).



PIX logs
The PIX firewall is able to log both locally and remotely, but local logs are only stored temporarily, and will be lost upon reboot. Another issue here is that logs can only be transferred using SYSLOG, which is usually a UDP protocol. The PIX software, as of version 4.3, also allows syslog/TCP, but in this case you need a non-standard syslog daemon which supports this.

On the PIX, all syslog messages are numbered. There are different messages for dropped protocol, dropped by outbound an inbound access list, and dropped UDP and TCP packets.

A full list of all Cisco PIX syslog messages can be found on the Cisco Website here.


Named (Unix BIND) logs
While DNS servers with full logging enabled are still quite rare, they do offer a lot of useful information to an IT crime investigator. When the ISP of an attacker is known, it is possible to correlate network access from certain IP subnets not only on the IP level (firewall) but also on the application level.

Let's have a look at a very simple query:
Nov 28 14:01:52.889 client 192.168.0.1#1024: query: sequoia.daemon.be IN A

In this case, host 192.168.0.1 did a query towards our nameserver, coming from ephemeral port 1024, for the A record "sequoia.daemon.be".

It is also possible to have a look at DNS logs to see whether certain hosts made such queries. An example:

Nov 28 13:49:30.481 createfetch: gesture.brigadoon.com A

In this case, our DNS server created a DNS request for the host "gesture.brigadoon.com". This is usually in response to an internal host performing a query for a certain hostname. It can usually be correlated to another request, such as:

Nov 28 13:49:09.733 client 10.0.0.1#37150: query: gesture.brigadoon.com IN A

Appendix B: Law enforcement contacts [back]

Belgium
Federal Computer Crime Unit
Notelaarstraat 211
B-1000 Brussels
Tel +32 2 743 74 74 (business hours)
Tel +32 2 743 73 84 (24/24)
Fax +32 2 743 74 19
E-mail contact@fccu.be

Chile
Policia de Investigaciones de Chile - Ciber Crimen
General Mackenna 1314
Santiago
E-mail cibercrimen@investigaciones.cl
http://www.investigaciones.cl

Pakistan
National Response Center for Cyber Crime
FIA Headquarters
G-9/4, Islamabad
Tel +92 051 9260944
Fax +92 051 9262376
http://www.nr3c.gov.pk

United Kingdom
National Hi-Tech Crime Unit
PO Box 10101
London
E14 9NF
Tel +44 (0)870 241 0549
Fax +44 (0)870 241 5729
http://www.nhtcu.org

Norway
OKOKRIM - Norwegian National Authority for Investigation and Prosecution of Economic and Environmental Crime
CJ Hambros plass 2B (7th floor)
N-0164 Oslo
Tel +47 23 29 10 00
Fax +47 23 29 10 01
http://www.okokrim.no

United States of America
Internet Fraud Complaint Center
http://www.ifccfbi.gov