journey to the centre of the breach - f-secure labs · journey to the centre of the breach ben...

Journey to the Centre of the Breach

Ben Downton

June 2, 2010

Abstract

Computer forensics is no longer exclusively the domain of law enforcementinvestigators. The same techniques applied to gathering evidence for use in courtcan also be applied to investigating a security incident in order to provide the victimwith information and assurance. In this report, a case study is presented that detailsthe tools and techniques used in the investigation of a breach of an FTP server, fromthe initial log file analysis through to reverse engineering the discovered malware.

Acknowledgements

I would like to thank the University of Bedfordshire and Dr. Paul Sant for providingsupport for this project, MWR InfoSecurity for giving me a platform to perform andpublish this work, and finally Rhiannon for diligently proof-reading and supportingme throughout.

Contents

1 Introduction 31.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Literature and Tool Review . . . . . . . . . . . . . . . . . . . . . 4

1.3.1 Forensic Investigations . . . . . . . . . . . . . . . . . . . 41.3.2 Malware Analysis . . . . . . . . . . . . . . . . . . . . . 51.3.3 Threats and Exploitation . . . . . . . . . . . . . . . . . . 51.3.4 Tool Review . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Background 72.1 Key Players . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Victim’s Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Recommendations for Victim . . . . . . . . . . . . . . . . . . . . 82.4 Account Compromise . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Log File Analysis 113.1 Identifying the Attacker . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Login Failures . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 Suspect Logins . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Identifying Attacker Activity . . . . . . . . . . . . . . . . . . . . 133.2.1 First Contact . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Enumerating Permissions . . . . . . . . . . . . . . . . . 143.2.3 File Uploads . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Malware Analysis 214.1 Antivirus Considerations . . . . . . . . . . . . . . . . . . . . . . 224.2 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Live Analysis - Playing in the Sandbox . . . . . . . . . . . . . . . 25

4.3.1 Dropping the Payload . . . . . . . . . . . . . . . . . . . 254.3.2 Vulnerability Exploitation . . . . . . . . . . . . . . . . . 27

4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1

CONTENTS 2

5 Reverse Engineering and Unpacking 295.1 Packers, Wrappers and Binders . . . . . . . . . . . . . . . . . . . 295.2 Unpacking the Virus . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.1 Anti-Debugging . . . . . . . . . . . . . . . . . . . . . . 305.2.2 Manual Coding Artefacts . . . . . . . . . . . . . . . . . . 315.2.3 Bypassing Invalid Instructions . . . . . . . . . . . . . . . 335.2.4 The Unpacking Loop . . . . . . . . . . . . . . . . . . . . 365.2.5 Identification . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Remedial Actions 40

7 Conclusions 42

A Code 44A.1 FTPCHK3.php Removal . . . . . . . . . . . . . . . . . . . . . . 44

Chapter 1

Introduction

1.1 Problem Statement

A client has reported that the FTP server (supplied by the victim) that is usedto store the clients data has been misconfigured. A full investigation has beendemanded by the client to ensure that their data has not been compromised.

As a result of the initial investigation, suspicious activity by a user account hasbeen noted and further investigation by a forensic examiner has been requested.

1.2 Aims and Objectives

The report will present a case study for an investigation into a security incident.The investigation will be described from the point of view of an external examinerand will address the issues of the client-supplier relationship as well as thedetailed techniques used. As the case study comprises evidence gathered froma fully operational environment, techniques of evaluating the relevance of suspectinformation will be discussed.

The goal of the case study is to illustrate the tools and techniques used toconduct an investigation into a security breach to establish the full cause and extentof such an incident. In all stages detailed technical output will be given to illustratethe findings and results, including:

• Client/Supplier relationship and potential issues

• Detailed log file analysis

• Static file analysis

• Live malware analysis

• Reverse engineering and unpacking malware

3

CHAPTER 1. INTRODUCTION 4

Finally, the conclusion of the work will be to illustrate the impact causedby the security incident and detail some of the failings that led to the incident.Countermeasures that would prevent a similar incident from occurring will also bediscussed.

The outcome of this work will be:

• Presentation by example of a methodology that evolves as an investigationcontinues

• Highlighting the advantages and disadvantages of forensic tools andtechniques

• Raising awareness of how security weaknesses are exploited in the real world

• Encouraging manual approaches to forensic analysis where automated toolsmay fail

• Furthering the field of computer forensics through documenting methods ofdefeating a known malware packer

1.3 Literature and Tool Review

The field of computer forensic analysis is not as rapidly changing as othersecurity fields, such as penetration testing, as the core tenets defined by the ACPOguidelines will apply in any situation. However, when using forensic techniquesfor incident response, it is important that the investigator has knowledge of currentthreats, as without this knowledge a new attack may go undiscovered. This iseven more crucial when dealing with malware; as anti-virus companies have largeamounts of resources to put towards defeating malware, so too must attackers to besuccessful.

1.3.1 Forensic Investigations

The core tenets of a forensic investigation are defined by the ACPO guidelineswhich apply to all forensic investigations. These guidelines are available fromeither the ACPO or 7Safe website and contain details on the proper procedure fordealing with the acquisition of data and subsequent analysis from various electronicdevices. Specific analysis techniques are not detailed, however an investigator thatconducts an investigation within the frameworks presented can be confident of theintegrity of any evidence and results gathered.

A commonly referenced book is File System Forensic Analysis by Carrier(2005). The book covers FAT, NTFS, Ext2, Ext3, UFS1 and UFS2 file systems ingreat detail and is an excellent reference guide for a forensic investigator. Thoughcommonly used digital forensic tools can understand a range of file systems andrecover large quantities of information from them automatically, an understanding


of the underlying structure allows an investigator to take a manual approach. Thebook also presents examples on using the Sleuth Kit and Autopsy tools (which areincluded in the Helix live distribution). As will be shown in this report, a manualapproach supported by tools has the best chance of success.

It is vital that an investigator has a good understanding of the software theyare investigating. To that end, the supporting documentation for Ipswitch WS FTPserver was a particularly useful resource as it described in detail the commandsused and the format of the log file entries. This then allowed searches to beconstructed with a greater degree of accuracy.

1.3.2 Malware Analysis

As malware analysis is one of the fastest changing fields, the majority ofinformation on malware infections (and how to defeat them) is anecdotal evidenceon the Internet. This typically falls into two categories; blogs, where a user presentsdetails of an infection, and forums, where a user requests help in dealing with aninfection.

Whilst the anecdotal evidence presented in these mediums have a higher chanceof being incorrect, especially with malware infections having many variants, it isalso more easily verifiable. Any research that may be appropriate can be quicklytested on the malware sample in question and the results compared - this approachis seen in Section 5.2.4 when comparing this analysis to Martyanov’s (2008)analysis of the Lighty Compressor. The article written by Martyanov also raisesthe point that research on more obscure malware may not necessarily be conductedin English, as this article had to be translated from Russian. The meaning of thepost was clear in this translation, but any hypotheses in other languages shouldbe treated with extreme caution, as their meaning or intent could be lost ontranslation. Some of the other blogs with articles relevant to this research included‘RemoteDesktop’ and ‘the Digital Me’.

There are not many books available on malware threats, as the field changesrapidly. Articles and presentations on malware analysis are more common buttypically revolve around new detection techniques or tools, such as Preda et al.(2008), Kolbitsch et al. (2009), and Cha et al. (2010). For analysis details ofspecific infections, the best sources of information are knowledge bases maintainedby anti-virus vendors, such as the TrendLabs blog, McAfee Threat Resources andBitDefender Defense Center.

1.3.3 Threats and Exploitation

For information on particular vulnerabilities the CVE (Common Vulnerabilitiesand Exposures) resource, which indexes publicly known information securityvulnerabilities, is particularly useful. This site was used to identify a knownvulnerability in the system, which is discussed in Section 4.3.1. A similar resource


that relates specifically to Microsoft products is the Microsoft Security Bulletin,detailing vulnerabilities and supplying patches to resolve them.

A vital source of information on current threats is research presented at securityconferences. Holt et al. (2009) presented research on predicting threats inthe Russian hacker community based on information gathered from LiveJournalaccounts. Similarly Granick and Opsahl (2009) presented research on high profilecomputer crime cases. Richards and Ligh (2009) and Percoco and Ilyas (2009) bothpresented at Defcon 17 on real world malware samples extracted from attemptedattacks.

1.3.4 Tool Review

A key part of a forensic analysis is in using the right tools and techniques to reachthe appropriate conclusions. Particularly with incident response, where timing maybe more critical, it is vital that the investigator has a toolkit that allows them to dealwith any possible situation. The tools used in this investigation are:

• grep - a command line tool written for Unix systems for searching for text

• whois - a tool for querying RIPE databases to determine registrationinformation for IP addresses and domains

• hexedit - a tool for viewing and editing the raw data of a file in hex format

• BackTrack - a live Linux distribution containing a number of security testingand forensics tools

• Helix - a live Linux distribution containing tools and features geared towardsforensic analysis

• VMWare - virtualisation software used to create a virtual machine to be usedas a sandbox environment for malware analysis

• AVG Antivirus - anti-virus software for detecting and removing malware

• FileAlyzer - file analysis tool developed by SaferNetworking

• Sysinternals - a suite of tools designed to help manage, troubleshoot anddiagnose Windows systems and software

• Immunity Debugger - a debugger specifically designed for the securityindustry, supporting malware analysis, reverse engineering and exploitdevelopment

• IDA Pro - commercial disassembling and debugging software

• PEiD - a tool for identifying packers used in malware samples

Chapter 2

Background

The server is known to be running a vulnerable version of Ipswitch WS FTPsoftware (3.1.4) with an Internet facing web interface. This version of softwarecontains a number of known vulnerabilities, including buffer overflows (allowingfor remote code execution) and Denial of Service (DoS) conditions. Thesevulnerabilities were known to Victim at the time as a result of previous penetrationtests highlighting the issue, however the resources to resolve the issue have notbeen made available.

No file integrity monitoring or anti-virus software is in place on the FTP server.Whilst it can be argued that file integrity monitoring software for an FTP servermay produce too many alerts to be valuable, software can be configured to monitorcritical system, archive and log files for alterations.

The log files provided were assumed to be complete and safe from corruption,however due to the nature of such a security incident their integrity cannot beguaranteed. Whilst no evidence was found that the log files had been compromised,it should be noted that a sophisticated attacker that gains access to the server mayalter the log files. The log files provided were approximately 30Gb in size anddated back over 18 months.

2.1 Key Players

The following key players in this incident are named below, with a brief summaryof their involvement:

• Investigator - The third-party investigator for this particular investigation

• Victim - The owner of the FTP server that has been reported compromised.The investigation was commissioned by Victim

• Client - A client of Victim and the reporter of the security incident

• Attacker - The person identified as causing the security incident. Note thatthe compromised account is named Attacker

7

CHAPTER 2. BACKGROUND 8

• Suspect 1 - An additional suspicious account identified by Victim

• Suspect 2 - An additional suspicious account identified by Victim

2.2 Victim’s Actions

In many environments, particularly commercially driven ones, it is typical that theorganisation will wish to contain the incident as soon as possible. It is importanttherefore that the processes undertaken preserve any evidence. This can includequarantining and sealing any infected removable media (such as USB devicesor DVD media), shutting down systems so that no further changes are made, orpreventing mobile devices from being remotely erased. The investigator must beprepared for the possibility of forensic evidence being potentially contaminatedby prior investigations conducted by a non-expert. The investigator should alsounderstand that commercial considerations may mean that forensic acquisition isnot possible. Investigations can encounter delays when third parties are involved,particularly when on-site access is required to secure facilities. In addition,delays in obtaining information (such as log files, backups, information regardingpersonnel etc.) can lengthen the investigation.

It is known that the Victim has conducted a limited investigation prior toengaging a specialist - artifacts of this investigation will be shown in Chapter 3.In particular, Victim has disabled the ‘attacker’ account, which was confirmed inthe most recent log entries as attacker ERR:logon disabled when attemptswere made to log in as that account. The IP addresses identified as attempting tolog in to the account after it had been disabled were noted and added to the suspectIP list.

At the time of the initial investigation the log files were stored on the FTPserver itself. To limit the risk that the log files could be tampered with they havebeen stored in a secure location away from the targeted server. The log files weretoo large to be stored on read-only media (such as a DVD-ROM), which wouldhave ensured their integrity for future investigation. The log files were instead sentvia email in a PGP signed and encrypted zip file to ensure that the confidentialityor integrity of the files were not altered in transit.

2.3 Recommendations for Victim

It was recommended that Victim continue to monitor server logs for failed accessattempts and ensure that further breaches do not take place. Monitoring of thelog files after the account had been disabled has already revealed IP addresses thatcan be added to the suspect list. Any other activity might reveal more informationabout the attacker.

Firewall and IDS/IPS logs were also closely monitored for suspicious IPaddresses (identified as a result of this investigation) that may signify further


attacks on the network. An opportunistic attacker may not continue the attackonce the vulnerabilities have been resolved, however a determined attacker that istargeting Victim specifically will likely seek out other avenues of attack.

In order to maintain a good working relationship with Client it is alsorecommended that Victim engage in discussions about how best to maintain theservice offered. It may not be the place of the investigator to determine how Victimshould proceed, however that does not preclude them from offering advice from atrusted position. In this case, Client has demanded that provision is made for allfile transfers to be conducted over SFTP. This is a more secure alternative to FTPoffering encryption, message integrity checking and identity verification by, forexample, public keys. The use of SFTP offers additional protection against trafficsniffing or man-in-the-middle (MitM) attacks to recover Client’s credentials; it willnot provide protection against the use of weak or easily guessable passwords.

As a general recommendation, Victim should ensure that sufficient technicalresource is available to support the investigation. Any delays in acquiringinformation can cost Victim in wasted time on the part of the investigator.Furthermore, failure to properly contain the incident in a timelay manner canexpose the network to a greater risk of attack.

2.4 Account Compromise

Before the analysis begins, it is important to consider the methods by which auser account could become compromised. This allows the investigator to identifyavenues of further investigation based on the likelihood of occurrence. In thisparticular case, there are four major scenarios to consider:

• Malicious ex-employee

• Exploitation of software vulnerability

• Leaked credentials

• Brute Force/Dictionary attack

The first case is that of a malicious ex-employee with remote access to theiraccount. This scenario is likely, particularly for a company that does not havea formalised joiners and leavers process for staff. A survey by Net Security(2009) revealed that 41% of employees have taken sensitive data with them to anew position, indicating the value that employees place on their (ex)company’sdata. At this point it becomes useful to discuss the circumstances in which theemployee left and any other relevant information (such as position, access levelsand technical ability) with the HR department. For this case study it was noted thatthe employee left on reasonably good terms, though it was likely that they wouldhave continued working in the same industry. The employee was not particularly


technically proficient, and would have known what areas of the server they wouldand would not have been able to access.

The exploitation of a vulnerability in the FTP server is also a possible scenario,given that the version in use contains a number of known vulnerabilities (for whichexploits are well documented). Again this is a situation where useful informationcan be gathered through discussions with the Victim. The account that has beencompromised did not have a high level of access; it is likely that exploitation ofthe vulnerabilities in the software would have resulted in root access to the systemrather than an individual lower privilege account. Even had the software been up todate, the possibility of a zero-day (0-day) attack being executed against the servershould be considered.

It is possible that an account could become compromised through leaked usercredentials. This becomes even more of an issue when there are limited passwordpolicy controls in place (such as no password expiration or password history).User credentials could be leaked unintentionally through a number of methods.They could become compromised in transit as the FTP protocol does not supportencryption (unlike the more secure alternative SFTP), meaning credentials are sentover clear-text channels. User credentials could also become compromised bytargeting the owner of the credentials directly, as they may be cached on the ownerssystem or even stored in a text file or written on a piece of paper. The owner of thecredentials could also be the target of a phishing attack where, if successful, theywould unwittingly submit credentials to an attacker. It was noted by Victim thatthe original owner of the account was particularly ‘mobile’, attending conferencesand working from public locations, which would have increased the risk that theowner would be the target of an attack.

A common method through which accounts can become compromised is byan automated brute force or dictionary attack. This type of attack involves anattacker attempting to log in to accounts with multiple different passwords until asuccessful login occurs. This attack is not particularly stealthy, as large volumes oftraffic and log file evidence can be identified, but can have a high chance of successwhere a weak password policy is in place. Password controls, such as applyingtemporary account lockouts for multiple logon failures, regular forced passwordchanges and a password history can significantly reduce the threat of brute forceattacks. The success of a brute force attack can be made more likely through theuse of specially crafted dictionaries. Where a brute force attack would attempt allpasswords between for example a to ZZZZZZZZ, a dictionary attack uses a list ofcommonly used passwords. This increases the likelihood of finding the passwordquickly at the cost of potential success should the password used not be in thedictionary. Typically a brute force attack will show up in logs as multiple loginfailures, followed by a successful login, followed by more login failures. This isdue to the automated nature of such attacks, where an attacker will commonly leavean attack tool or script running in the background whilst performing other tasks.

Chapter 3

Log File Analysis

3.1 Identifying the Attacker

The first stage of analysis is to find methods of identifying the attacker. Thiscould be through behavioural patterns or common links such as IP address orgeographical location. Since the account was known to be in use by a legitimateuser up until a certain date, it is important to clarify the difference betweenlegitimate activity and attacker activity.

3.1.1 Login Failures

Brute force and dictionary attacks can be easily identified in log files as theytypically have a number of key features (discussed further in Section 2.4), suchas:

• Multiple login failures

• Logon failures are in rapid succession indicating automation

• A logon success is normally followed by more logon failures

Evidence of a brute force attack would identify the earliest time that the accountwas compromised, as well as identify whether the attack was successful (throughevidence of a logon success). A search through the log files for a high number oflogon failures would highlight evidence of a brute force attack.

Figure 3.1 shows an example log entry for failed logon attempts. A numberof logon attempts for the 3rd of March at approximately 18:13 onwards wereidentified from the same IP address (marked below as 71.62.X.X). Once an IPaddress has been identified as suspicious it is always advisable to try and pinpointthe owner of that IP address. Whilst it is common for an organised attacker toutilise compromised machines in many geographical locations (to evade detection),it is less common for malicious insiders to have these resources available. It isalso useful to identify not just the owner of an IP address but the geographical

11

CHAPTER 3. LOG FILE ANALYSIS 12

location, which may point to areas for further investigation or allow a convictionto be pursued.

0303 18:13:09 (00001580) 71.62.X.X:64298 connected to 10.250.50.6:21

0303 18:13:09 (00001580) ftp.victim.com D(0) 71.62.X.X UNK USER attacker

0303 18:13:09 (00001580) ftp.victim.com U(Logon_Fail) 71.62.X.X attacker ERR:logon failure (A2)

0303 18:13:41 (000012ec) 71.62.X.X:55101 connected to 10.250.50.6:21

0303 18:13:41 (000012ec) ftp.victim.com D(0) 71.62.X.X UNK USER attacker

0303 18:13:41 (000012ec) ftp.victim.com U(Logon_Fail) 71.62.X.X attacker ERR:logon failure (A2)

Figure 3.1: Logon Failures by the ‘attacker’ account

The whois tool can be used to query Regional Internet Registries (RIRs) whichhold contact, ownership and status information for domains and IP addresses. Anexample of part of the whois output for the IP address above is given in Figure 3.2,identifying the IP address as belonging to Comcast (an ISP) in New Jersey.

This IP address was queried with Victim, after some research it transpired thatthis IP address belonged to the US office that had conducted some of the initialinvestigation. The logon failures identified were a result of the IT departmentattempting to guess the password for the ‘attacker’ account in order to investigatefurther. Whilst this did not significantly hinder the investigation, it highlights someof the issues involved with non-experts conducting investigations as part of theinitial response. Where organisations do not have a specific incident response team,it is critical that the consequences of any actions taken prior to engaging an expertare fully understood and documented.

whois 71.62.X.X

OrgName: Comcast Cable Communications Holdings, Inc

OrgID: CCCH-3

Address: 1800 Bishops Gate Blvd

City: Mt Laurel

StateProv: NJ

PostalCode: 08054

Country: US

Figure 3.2: whois entry for a suspect IP address

Further searches for login failures by the attacker account were conductedusing a simple grep command: grep "attacker ERR:logon failure" *.Whilst a number of logon failures were identified, there was not a significantnumber (or in succession) that would indicate a brute force attack.

3.1.2 Suspect Logins

Whilst the investigation was being carried out, Victim had been continuing theirown investigation of log files. In addition to the investigation into the attackeraccount, it was also requested that the login attempts in Figure 3.3 are investigated.


0827 21:40:50 (000012a0) 192.28.x.x:47310 connected to 10.250.50.6:21

0827 21:40:50 (000012a0) ftp.victim.com D(0) 192.28.x.x UNK

XAUT 2 :8C<D=<667C4B2:?56D=>4<7:?@6C?;862D7>983:5@2

0827 21:40:50 (000012a0) ftp.victim.com S(0) 192.28.x.x suspect1 logon success (B1)

0905 20:12:24 (00000e48) 12.192.x.x:50176 connected to 10.250.50.6:21

0905 20:12:24 (00000e48) ftp.victim.com D(0) 12.192.x.x UNK

XAUT 2 88>5C?5;85>:C>828:=@@>4:;1>7D=5?85>5B36:7=>5@76>;;

0905 20:12:24 (00000e48) ftp.victim.com S(0) 12.192.x.x suspect2 logon success (B1)

Figure 3.3: Suspicious logon attempts

The login messages in Figure 3.3 were flagged by Victim as suspicious due tothe apparent ‘randomness’ of the data in the message. As this type of data wasnot commonly seen by Victim it was not known whether the data was indicative ofabnormal behaviour (such as an attempt to launch exploit code or fuzz the service)or legitimate operations.

The seemingly random code in the messages above is typical behaviour for anXAUT logon attempt where the username and password combination is encrypted.Examination of other similar login attempts revealed that this activity was normalnot only for the suspect1 and suspect2 accounts but also for a number of otheraccounts in normal use.

Furthermore, a search for any activity by the accounts suspect1 and suspect2matching the list of suspect IP addresses revealed no matches. This information,in addition to the fact that no download or upload attempts were made to Client’sfolders, was enough to exclude the suspect1 and suspect2 accounts from furtherinvestigation for the time being.

3.2 Identifying Attacker Activity

In order to narrow down the time window under investigation it is important toestablish at what point an attacker gains access to an account. Since there was noevidence of a brute force attack taking place it may be more difficult to establishwhen the attacker gained control of this account. Analysis of behavioural patternshowever can indicate whether activity was conducted by a legitimate user or anattacker.

3.2.1 First Contact

A critical part of the investigation was to identify exactly when the account wasfirst used fraudulently. The possibility of the attacker being the original owner ofthe account was not ruled out entirely and so identifying patterns of use could bothnarrow down the window under investigation and provide clues about the identityof the attacker.

Given that the log files provided cover over two years of traffic (and are over


30Gb in size), narrowing down the window of investigation in the early stages cansignificantly speed up future searches.

A search for all successful logons to the attacker account revealed no activitybetween March and November. It was confirmed by Victim that the originalowner of the account left in March, which corresponds to the time that theactivity stopped. This information narrows down the window of intrusion (thetime between first contact and incident containment) to five months, significantlysmaller than the log files provided. The IP addresses used to access the accountfrom November onwards were logged and added to the suspicious IP list.

It should be noted that, for the results given in this section, the IP addressof the attacker is not consistent. This is typical for remote attacks where anattacker will ‘pivot’ attacks through other compromised machines. Launchingattacks from various different locations makes it more difficult to identify theattacker, both at a physical level (for example to pursue a conviction) and at alogical level (such as blocking access from specific ‘at risk’ IP addresses). Themajority of attacks appeared to originate from countries such as the Ukraine,China, Russia, and one instance from a library in the US. The wide range of attackorigins indicate that it is likely that compromised machines have been used as thefinal hop before the attack on Victim’s servers. Public machines such as thosein libraries are often not subject to such strict maintenance and security controls,and are commonly found to be compromised by malware or used by attackers foranonymity. Furthermore, launching attacks from systems located in countries thatmay not be politically cooperative with the target country (in this case the UK)provides another level of protection as it is unlikely that local law enforcement willbe able to negotiate access to the compromised machines. A report by 7Safe (2010)reported that approximately 10% of attacks under their investigation were launchedfrom these countries, however it is also acknowledged that the attacks could havebeen launched from compromised machines.

3.2.2 Enumerating Permissions

Once an attacker has gained access to the account it is likely that they will attemptto identify what level of access they have obtained. This could be through a numberof methods, such as accessing user group or policy information, through built incontrols (such as whoami), or by simply attempting to perform actions and notingsuccess or failure.

It was clear that the attacker was attempting to enumerate the permissionsof the account through automated attacks in two distinct ways. The process ofautomatically enumerating account permissions is not consistent with the theorythat the account had been accessed by a malicious ex-employee. This was basedon information provided by Victim. Firstly the employee would have knownwhat directories were accessible (as these would be the clients of this particularemployee). Secondly, as the employee was not known to be technically proficient,it is unlikely that automated tools or scripts would be used.


The first method that the attacker used to enumerate account permissions was toidentify what directories the account had access to by attempting to systematicallyread the contents of subdirectories. The attack was performed by changing thecurrent directory to each subdirectory in alphabetical order (identified by the CWDcommand) followed by an attempt to list the contents with the NLST (name list)command. Figure 3.4 shows a sample of the activity indicating an automatedattack to enumerate permissions of the attacker account. Figure 3.5 shows anexample of where the automated script was performing recursive queries, as theattacker attempted to change to a directory that was actually a file. Informationsuch as this may not provide a definite answer for what caused the incident but cannevertheless contribute towards building a profile of the attacker, such as the levelof sophistication and resources available. An attack such as this is not particularlystealthy or sophisticated.

0228 16:23:59 (00001334) ftp.victim.com D(0) 69.73.X.X attacker PASV DATA connection to

69.73.X.X:32982

0228 16:23:59 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker CWD /Arnaco

0228 16:23:59 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker PASV

0228 16:23:59 (000012c4) 69.73.X.X attacker:ftp.victim.com forced close listener socket

0228 16:23:59 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker NLST


69.73.X.X:33737

0228 16:24:00 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker CWD /Arselis Tech



0228 16:24:00 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker NLST


69.73.X.X:36827

0228 16:24:00 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker CWD /ASOT LTD



Figure 3.4: Successful CWD and NLST commands

0228 16:24:13 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker CWD /Centaur/db_backup.zip

0228 16:24:13 (000012c4) ftp.victim.com U(NoFolder) 69.73.X.X attacker

ERR:CWD /Centaur/db_backup.zip (Centaur)

0228 16:24:13 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker CWD /Centaur/forecast.xlsx

0228 16:24:13 (000012c4) ftp.victim.com U(NoFolder) 69.73.X.X attacker

ERR:CWD /Centaur/forecast.xlsx (Centaur)

Figure 3.5: Failed CWD and NLST commands

The second method that the attacker used to enumerate permissions was toidentify which of these directories could be written to. This was achieved byattempting to systematically upload and then immediately delete a file namedtmp5842258422.html to various directories. It is thought that the attacker deletedthis file immediately as a method of evading detection, as copies of the file leftin various folders may arouse suspicion. It should be noted however that the


attacker did not make particular efforts to conceal their presence elsewhere, andit is possible that this behaviour was typical of an automated tool that a lowerskilled attacker could use.

The file named above (and shown in Figure 3.6) could not be recovered forfurther analysis. The file may have been a dummy file (with minimal size) to allowthe uploads to occur as quickly as possible. The file may also have containedmalicious code to be executed by either the attacker or an unsuspecting victim at alater date. In this instance it can be seen that the file was approximately 18Kb insize - enough to contain a malicious web shell that could potentially be accessedthrough the web front end.

0229 04:30:24 (00001620) ftp.victim.com D(0) 87.118.X.X attacker PASV

0229 04:30:24 (00001620) 87.118.X.X attacker:ftp.victim.com forced close listener socket

0229 04:30:24 (00001620) ftp.victim.com D(0) 87.118.X.X attacker STOR tmp5842258422.html


87.118.X.X:2640

0229 04:30:24 (00001620) ftp.victim.com S(0) 87.118.X.X attacker STOR tmp5842258422.html

(D:/FTP-Data/tmp5842258422.html) (17946 bytes, 265ms)

0229 04:30:24 (00001620) ftp.victim.com D(0) 87.118.X.X attacker DELE tmp5842258422.html

0229 04:30:24 (00001620) ftp.victim.com S(0) 87.118.X.X attacker DELE tmp5842258422.html

(D:/FTP-Data/tmp5842258422.html)

Figure 3.6: Upload/Delete of sample file

3.2.3 File Uploads

Uploads to Client Folder

As Victim was interested primarily in any activity that might have affectedtheir client, a key part of the investigation was identifying whether the client’sinformation had been compromised. It was clear from the activity of enumeratingpermissions that the account was capable of uploading or downloading informationfrom the client folder, and so for Victim to provide a statement any activity mustbe rigorously identified.

A search for any uses of the RETR command related to the client folderrevealed no matches, indicating that the client’s intellectual property remaineduncompromised. Whilst it is possible that the attacker was able to compromisethe log entries and modify them (a scenario that should also be considered whenperforming an investigation), no evidence had been found to indicate this hadoccurred. Typically where an attacker has removed log file entries it is done inan obvious manner, with large chunks (or even the entirety) of the logs missing.Where an attacker has used more sophisticated means, such as only removingcertain incriminating log entries, it is less likely still that they will create legitimateentries in it’s place. With a server such as this that has high amounts of activity,a gap in the timestamps of the log entries of even a minute would be suspicious.Finally, the reason that the log files were not assessed as compromised was that the


amount of information about the attackers activity still remaining would suggestthat they have not been modified at all, particularly as the account would not havebeen able to modify the logs without elevating privileges.

With no successful download attempts noted for the client folder, it remainedto determine whether any files had been removed or uploaded. Figure 3.7 showsan attempted upload and removal of the ftpchk3.php file to the client folder.

1203 19:08:28 (000017b4) ftp.victim.com D(0) 194.186.X.X attacker STOR ftpchk3.php

1203 19:08:28 (000017b4) ftp.victim.com U(NoPermission) 194.186.X.X attacker ERR:STOR

ftpchk3.php (D:/FTP-data/client/ftpchk3.php)

1203 19:08:28 (000017b4) ftp.victim.com D(0) 194.186.X.X attacker DELE ftpchk3.php

1203 19:08:28 (000017b4) ftp.victim.com U(NoFile) 194.186.X.X attacker ERR:DELE

ftpchk3.php (D:/FTP-data/client/ftpchk3.php)

Figure 3.7: Attempted Upload/Delete of ftpchk3.php file

References at the RemoteDesktop.com blog noted the ftpchk3.php file beingone of those dropped by an machine infected with a variant of the Bagle virus. Theftpchk3.php file reportedly tests functionality of sites before paving the way forfurther files to be uploaded containing malware (such as the Downloader.Tibs.9.Vtrojan). Prabhakar (2009) reported in more detail on the effects of the virus, withparticular note that the code attacks vulnerable web servers but the most commoninfection vector is through vulnerable FTP servers. Note that a removal scriptis supplied in Appendix A.1, and was also supplied to Victim as a precautionarymeasure.

The attacks reported by Prabhakar indicate a similar scenario, with the filebeing uploaded to a vulnerable FTP server. However in this case it was noted thatthe file upload was not successful.

Successful Uploads

Following on from this discovery, it became necessary toidentify exactly what files the attacker had uploaded. Thiswas achieved simply by chaining grep commands, i.e.grep -C 3 "attacker" * | grep -C 3 "STOR" > attacker_stor.txt,which would return any instances of the STOR command being used by theattacker account. This also returned three lines of context surrounding anyinstances so that further information about an attack could be obtained and storedin the attacker stor.txt file.

In this instance a number of issues were found with the above command. Firstlythe results could be repeated a number of times due to the use of the -C flagdenoting the surrounding context lines to be captured. Secondly, a large number offailed file upload attempts were noted and any successful uploads may have beenlost in the noise, as the resulting file was approximately 3Gb in size.

Rather than trawl through 30Gb of log files again it is more effective torefine the output using another scripting language. Figure 3.8 shows a script


written in Ruby that can be used to check for successful upload attempts.The script reads the file line by line and prints any lines where the STORcommand is used but an error (ERR) does not occur. The space in the commandif lines[count].include?(" STOR") is intentionally added as an additionalmeasure for extracting only successful storage attempts (as a failure is denoted byERR:STOR).

f= F i l e . open ( ’ a t t a c k e r s t o r . t x t ’ , ’ r ’ )l i n e s = f . r e a d l i n e sf . c l o s e

c o u n t =0whi le ( count < l i n e s . s i z e −1)

i f l i n e s [ c o u n t ] . i n c l u d e ? ( ” STOR” )and not l i n e s [ c o u n t + 1 ] . i n c l u d e ? ( ”ERR” ) then

p r i n t l i n e s [ c o u n t ]endc o u n t +=1

end

Figure 3.8: Ruby Script to identify successful uploads

The result of this script revealed a number of instances of successful uploadsby the attacker. Ordering these uploads by date revealed a trend, as shown in Figure3.9. The first entry for each upload attempt shows when the transfer began. Thesecond entry shows a successful upload, displaying the location of the file on theFTP server and the number of bytes and time taken for transfer.

1207 00:39:03 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR AMOVIE.EXE

1207 00:39:10 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR AMOVIE.EXE

(D:/FTP-Data/WindowsServices/lotus/notes/AMOVIE.EXE) (1207808 bytes, 6625 ms)

1207 00:39:13 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR kvoop.exe

1207 00:39:14 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR kvoop.exe

(D:/FTP-Data/WindowsServices/lotus/notes/kvoop.exe) (193024 bytes, 1250 ms)

1207 00:39:17 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR ldapsearch.exe

1207 00:39:18 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR ldapsearch.exe

(D:/FTP-Data/WindowsServices/lotus/notes/ldapsearch.exe) (225844 bytes, 1313 ms)

1207 00:39:26 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR nadminp.exe

1207 00:39:30 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR nadminp.exe

(D:/FTP-Data/WindowsServices/lotus/notes/nadminp.exe) (647729 bytes, 3578 ms)

1207 00:39:41 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR nca.exe

1207 00:39:45 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR nca.exe

(D:/FTP-Data/WindowsServices/lotus/notes/nca.exe) (913965 bytes, 4750 ms)

1207 00:39:48 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR nchronos.exe

1207 00:39:49 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR nchronos.exe

(D:/FTP-Data/WindowsServices/lotus/notes/nchronos.exe) (176690 bytes, 1157 ms)

Figure 3.9: Successful uploads by the attacker


As the only information available at this stage was the log files, someassumptions had to be made in determining the next stage of the investigation.Identifying the uploads by filename alone, the majority of the files appeared to becommon Lotus Notes components. It was not immediately clear why an attackerwould wish to upload files for running Lotus Notes, a client for managing businessemails, calendars and applications. It is possible that the attacker was using thisclient to pivot further attacks (such as interfacing with a Lotus Domino server) orto trick a user into installing malicious software.

To fully understand the motives behind uploading these files, the log filesdetailing these uploads were examined manually for further information. Byexamining the successful upload within the context of the surrounding activity,it became clear that the attacker was actually uploading files that had beendownloaded previously.

Figure 3.10 shows an example of the activity related to the nnotesmm file.First the attacker retrieves the file from the FTP server, identified through theRETR command showing a successful download followed by deletion with DELE.Seconds later a connection is initiated again, this time uploading the file with theSTOR command (as seen previously).

1207 00:41:14 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker SIZE nnotesmm.exe

1207 00:41:14 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker RETR nnotesmm.exe

1207 00:41:14 (0000125c) ftp.victim.com D(0) 92.62.X.X attacker PASV DATA connection

to 92.62.X.X:3927

1207 00:41:16 (0000125c) ftp.victim.com S(0) 92.62.X.X attacker RETR nnotesmm.exe

(D:/FTP-Data/WindowsServices/lotus/notes/nnotesmm.exe) (20530 bytes, 1094 ms)

1207 00:41:16 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker DELE nnotesmm.exe

1207 00:41:16 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker DELE nnotesmm.exe

(D:/FTP-Data/WindowsServices/lotus/notes/nnotesmm.exe)

1207 00:41:16 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker TYPE I

1207 00:41:16 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker PASV

1207 00:41:16 (00001a6c) 92.62.X.X attacker:ftp.victim.com forced close listener

socket

1207 00:41:17 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker STOR nnotesmm.exe

1207 00:41:17 (00001a6c) ftp.victim.com D(0) 92.62.X.X attacker PASV DATA connection

to 92.62.X.X:4276

1207 00:41:18 (0000125c) 10.250.50.4:23654 connected to 10.250.50.7:21

1207 00:41:18 (00001a6c) ftp.victim.com S(0) 92.62.X.X attacker STOR nnotesmm.exe

(D:/FTP-Data/WindowsServices/lotus/notes/nnotesmm.exe) (172594 bytes, 1031 ms)

Figure 3.10: Retrieval and upload by the attacker

This activity constitutes a high risk for victim, and warranted furtherinvestigation. The fact that files have been downloaded and then replaced withinseconds is not normal activity, and suggests that the files have been modified.Examining the data transferred showed that (for the file of the same name) 20530bytes were downloaded and 172594 bytes were uploaded, again suggesting thatthe files have been modified. This modification was noted as highly likely to bemalicious.


3.3 Conclusions

As a result of the initial investigation, Victim was happy with the assessment thatClient’s information had not been downloaded by a malicious attacker. Despite thefact that the suspicious file uploads had been raised, Victim no longer wished tocontinue the investigation and issued a statement to Client detailing the findings ofthe investigation as they relate to Client’s property.

The following day, Victim examined the files that had been uploaded andimmediately received an alert from their anti-virus, reporting an infection ofTrojanHorse.Generic (shown in Figure 3.11). As the anti-virus engine couldn’tprovide any further information, Victim supplied the infected files for inspectionand the investigation continued.

Figure 3.11: Generic Trojan horse detected

Chapter 4

Malware Analysis

The alert in Figure 3.11 shows how anti-virus can use detection techniques abovenormal ‘signature’ based detection to alert the user to a threat. The anti-virussoftware in use detected that the virus has been packed (a form of encryptingviruses to make them undetectable) but was unable to obtain any identifiableinformation from either unpacking the virus or identifying the packer in use. Inthis situation the user has been alerted to an infection, but actually identifying thecontents will require a manual approach.

Detecting malware behaviour can take place in various environments, typicallyfalling into one of four stages: Static, Mounted, Live or Network. Figure 4.1 showsthe natural progression of malware investigation in the four stages.

Figure 4.1: Malware Investigation Methodology

Static analysis takes place when the infected file is placed into anon-functioning environment and analysed as raw data. The benefits that this hasare that the virus cannot utilise any advanced techniques to evade detection andany unencrypted strings or headers can be easily identified. However, if the virushas been created using a packer (which is then decrypted at run time) there will belittle information about its behaviour in the static analysis phase.

Mounted analysis involves mounting the filesystem on which the infectedfiles are stored as a logical drive within the investigation machine. This has theadvantage that the file can be viewed in it’s native environment, allowing for fileand folder permissions and metadata to be more easily examined. It is also easierto run the file through anti-virus engines to determine if the infection conformsto any known signatures. Whilst in the mounted stage, anti-virus scanning istypically limited to matching signatures (or definitions) from a known databaseand behavioural analysis is not as easily performed. This does however offer the

21

CHAPTER 4. MALWARE ANALYSIS 22

advantage that malware also cannot utilise evasion techniques such as hiding filesor injecting processes into memory.

Live analysis should occur within a sandboxed environment where theresources available can be strictly controlled. At this stage the infection can beset loose on a system and its effects monitored or controlled. Live analysis can alsomake use of anti-virus engines to detect malware like behaviour that may indicatethe type of infection. Typically this stage makes use of virtual machines such asVMWare, as we will see in Section 4.3.

Finally, the network analysis stage looks at any network traffic associated withthe infection. When viruses are created for profit (rather than to annoy), theytypically need to transfer information to be successful. This can be to infect furthermachines, to ‘phone home’ to a botnet controller or to send sensitive information,such as web browsing habits and keystrokes, to a remote machine. Consequently,monitoring network traffic from an infected machine with a tool such as Wiresharkcan narrow down the type of infection by looking for identifiable network traffic.

In this situation, the limitations of the anti-virus software in use have beenmade clear by the fact that positive identification of the virus and it’s behaviourwas not possible. This chapter discusses the benefits and drawbacks of automatedanti-malware services before detailing a manual approach towards identifying virusbehaviour.

4.1 Antivirus Considerations

Whilst there are clear benefits from having robust anti-malware provisions it isimportant to acknowledge the potential risk also associated with this software.Anti-malware services run with a high level of privilege and are usuallyintrinsically linked to the operation of the underlying Operating System. Therefore,a vulnerability in the technology itself (as have been identified previously in a widerange of anti-malware products) can potentially represent a significant threat to thesystem it is running on.

It is therefore important that the use of malware protection on any system bebased on a risk driven evaluation of its benefits against any potential vulnerabilityit introduces. The result of this is such that in the case of any system handling orprocessing user supplied data (for example, file servers, email servers etc) the useof an anti-malware product is recommended. However, where systems are subjectto strict software installation and management procedures a decision not to installanti-malware software may be the lower risk approach. Ultimately this decisioncan only be made with knowledge of operating procedures and the amount ofcontrol that can be practically exercised over systems within the company. Wherethese cannot be guaranteed the use of anti-malware solutions are often the lowestrisk option.

The use of a managed service for anti-malware control can offer significantbenefits, however, this does also introduce an element of risk. In these


circumstances all of a company’s mail or web traffic will be passing through themanaged service provider. This would result in them being a single point wherebya malicious attacker could gain access to all business data not protected using othermeans (for example PGP or HTTPS). The company should therefore acknowledgethat the potential compromise of the third-party’s systems could expose a largeamount of business data to a malicious attacker or insider. Whilst this risk is likelyto be less than that exposed by not utilising such services it is important that thisdependency be acknowledged and documented on the appropriate risk register.

4.2 Static Analysis

Remote or physical access to the FTP server was limited due to difficultiesin obtaining permissions from the hosting company - a common occurrence incommercial environments that highlights the importance of being fully prepared foran investigation. The files were instead extracted by Victim directly and courieredon an encrypted USB stick, which was recommended for two reasons. Firstly,it would prevent an unwitting user infecting further machines should they comeacross the device. Secondly, it was not known at this stage whether the malwarewas custom written to target Victim, and thus could contain information sensitiveto the organisation.

The infected files were copied from the USB media onto a DVD-ROM topreserve their integrity before analysis could begin. The encryption program onthe USB device was also not supported across all major operating systems and, aswill be shown in this section, use of both Linux and Windows systems is required.

A useful tool for analysing malware is a live environment, such as BackTrackor Helix. Live environments can be run entirely in volatile memory and, typically,leave no footprint on the host machine. This is particularly appealing for analysingmalware as dummy or ‘goat’ machines can be used temporarily and any infectionseasily removed by simply shutting down the machine. As a number of livedistributions are based on the Linux operating system they are inherently moreresilient against malware attacks, including common exploitation of Windowsfeatures (such as infected autorun.inf files and executable Windows binaries).

A common factor in files infected with a Trojan (as detected in Figure 3.11) isthat they contain multiple PE headers. PE stands for Portable Executable and is afile format for executables and DLLs (Dynamic Link Libraries) used in Windowsoperating systems. Ordinary executables have a PE header at the start of the file,which can be identified by the file signature \x4D\x5A or MZ. Files infected with aTrojan however have multiple PE headers, as shown in Figure 4.2.

A Trojan, named after the Trojan Horse of Greek mythology, is a deliverymethod for a malicious payload. The payload is hidden within another (usuallylegitimate) file, execution of which will drop the payload whilst executing theoriginal program. From the point of view of the user, the file behaves normall; theyhave no knowledge of an infection until abnormal behaviour or anti-virus alerts


Figure 4.2: PE Headers in infected file

them. In Figure 4.2 the multiple file headers show the sections of the programdesigned to drop the payload, the original program and the malicious payloadrespectively.

The first section of the program (from the start of the file to the PE header at0x1200) contains code that has been designed to execute the original program aswell as the malicious payload at 0x6232. Examination of a number of the infectedfiles revealed that the first section was identical across all of them - something thatwould not be typical of a number of different programs.

The PADDINGXX (seen just above the third and final PE header) appeared tobe suspicious, particularly as this file had already been flagged as high risk. Useof repeated sequences is typically seen as padding in exploits for buffer overflowvulnerabilities (notably \x41), and so PADDINGXX could be part of an exploit inthe malicious payload. Sashazur (2004) explains that PADDINGXX is seen as a sideeffect of using the UpdateResource function to correctly align sections within anexecutable. Whilst this provides a lead as to how this section of the executable wascreated and discredits the idea that this is an intentional buffer overflow exploit,it alone does not determine whether this section is the malicious payload or not.In actual fact, PADDINGXX is part of the original file Lotus Notes files; examiningcopies of known safe versions of Lotus Notes executables revealed that PADDINGXXis commonly seen.

Finally, the last section of the executable is the malicious payload. There is


little information available by examining this section statically, as there are no cleartext strings containing information about the payload. This could be by designor, more likely, that the payload is encrypted with a packer (described further inChapter 5).

4.3 Live Analysis - Playing in the Sandbox

With the static analysis clearly showing that the files contain some maliciouscontent, it becomes necessary to advance to the next stage of analysis to gainfurther information about the effects of an infection. In this situation there is nobenefit to performing a mounted analysis (which would allow anti-virus scans tobe performed) as the presence of malicious content has already been identified;analysis could move straight to a live environment.

Arguably the best method of determining the behaviour of a virus infection isto deliberately infect a machine and monitor its effects. This has a high level ofrisk associated with it however, as an unidentified infection could cause havoc ona network and the investigation machine could be used to infect other machines onthe network. The most appropriate method of monitoring an infection therefore isto use a sandbox - a safe environment with limited connectivity that can be closelycontrolled.

In this case, a virtual machine using VMWare was created for the purposesof analysing the infection. VMWare has a number of features that can be usefulin analysing a virus, such as the ability to control the resources available to themachine and the ability to create and revert to snapshots of the machine.

Another set of tools that are useful in analysing malware are the Sysinternalssuite of tools. In particular RegMon, FileMon and ProcMon allow any accesses toregistry keys, files and processes to be monitored and logged. As there are largeamounts of registry and file accesses through normal operations of a Windowssystem it is important when using these tools that the filters are set appropriately.Filters that are not restrictive can lead to information overload and any maliciousactivity is lost in the noise, however filters that are too restrictive may not capturevital information about the behaviour of the infection.

4.3.1 Dropping the Payload

Having let the uninfected system run for a short time and filtering out any standardsystem processes, a malicious file was selected and executed. A number oflocations were scanned by the process and directory contents listed (a sign of thevirus establishing the system’s directory structure). Of particular note, was a filecreated at the following location:

C:\Documents and Settings\%User%\Local Settings\Temp\1.tmp


Figure 4.3 shows the output from FileMon, one of the Sysinternals tools,capturing the creation of a file 12.tmp in the location listed above. The file 12.tmpis identical to the other files dropped by the infection, as discussed later in thissection.

Figure 4.3: FileMon output showing payload creation

The file could easily be overlooked as a normal temporary file, given it’slocation and filename. However, as the results from the Sysinternals tools show thisfile is flagged as suspicious. FileAlyzer is a useful tool for Windows, developed bySafer Networking, that allows files to be analysed in detail. It also allows the rawdata to be analysed and, as Figure 4.4 shows, the 1.tmp file has a PE header; thefile is an executable and not an ordinary temporary file.

Figure 4.4: FileAlyzer output showing PE header

Infecting the machine multiple times (through executing the infected filemultiple times) is a useful method for determining virus behaviour. Comparingthe results of a reinfection can reveal whether any randomness in code, location,filename and other attributes are present. In this case the filename was found tochange, as copies of 2.tmp, 3.tmp, 4.tmp, 16.tmp, C.tmp and D.tmp were all seenas a result of reinfection where 1.tmp already existed.

One method of identifying files is by a unique signature or hash; a hash of afile is an (effectively) unique value that is generated based upon the raw data of thefile. This hash will be calculated exactly the same when when identical input datais supplied, as the algorithm of a hashing function is mathematically well-defined.A hashing function is also defined by the property that a change in input (no matterhow insignificant) will result in a very different output. Hashing files is thereforea useful way of determining whether two files are identical, as they will have amatching hash value.


The MD5 hash (a commonly used algorithm) of all the files examined in theTemp folder was: c5ad1457dba612bbd7751aa5354075b1. It is acknowledgedthat MD5 contains known flaws which can, under special conditions, be exploitedto make malicious modifications to files that will still pass integrity checks;however, for the purposes of swiftly comparing file contents it is suitable.

4.3.2 Vulnerability Exploitation

The process 1.tmp attempted to access a number of registry keys. Some of thesekeys were core to the Windows operating system (such as Winlogon, TerminalServer and Diagnostics) and are typically accessed by malware to determineinformation such as the current privileges associated with the process, whatplatform it has been executed on and other information that may be relevant toexploitation. In particular access attempts to the following key were noted:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize

This entry is related to a buffer overflow vulnerability, exploitation of whichcould allow escalation of privileges or remote code execution. The presence of thiskey indicates a system that is vulnerable to CVE-2008-1087, and would be a likelycandidate for malware to target in an attempt to gain SYSTEM level access.

The operating system in use as the sandbox was Windows XP SP3 with allrecent security updates applied, and as such this registry key did not exist. Whenmanually spawning the process (by executing 1.tmp or similar), access attemptsfor this key were noted followed shortly by the process being killed, potentiallyindicating a failed exploitation attempt. Figure 4.5 shows access attempts by theprocess 2.tmp - the reference to nvaux32 should also be noted as it becomesrelevant in Chapter 5.

Figure 4.5: Access attempts to the GRE Initialise registry key

In order to investigate further, a vulnerable machine is needed. An unpatchedversion of Windows 2003 was installed as a virtual machine and the infectedfiles transferred. Examination of the registry revealed that the GRE Initializekey existed and the system was vulnerable. The various Sysinternals tools weresimilarly used to monitor activity and the infection was launched. The processterminated upon accessing the GRE Initialize key in the same manner as before.


4.4 Conclusions

Some of the behaviour of the infection has been identified, and a likely target forexploitation has been seen (though not actively exploited in the tests performed).Some viruses have the capability of detecting virtualisation technology and willmodify their behaviour accordingly.

Whether this failure to infect the sandbox further is a method of preventinganalysis, a bug in the malware or simply a result of virtualisation not emulating alive machine exactly, the full extent of the infection cannot be established solely bymonitoring it’s behaviour.

The following chapter explores the techniques used to identify the behaviourof the virus through reverse engineering and debugging.

Chapter 5

Reverse Engineering andUnpacking

As malware often goes through many stages of modifications and updates, it iscommon to see malware in the wild that has similar behaviour and functionsto those that came previously. When limited time is available, it is not alwaysnecessary to fully identify every aspect of the malware’s behaviour but to establishwhat family it belongs to. From there it can be determined whether the observedbehaviour is consistent with descriptions provided by virus databases and othermalware researchers to provide a higher level of assurance as to the nature of theinfection.

In this example it becomes apparent that a full analysis was not necessary. Afterdefeating anti-debugging defenses and obtaining an unpacked copy of the infectionit was possible to obtain clues that lead to the identification of the virus, with finalconfirmation provided by anti-virus.

The tools used in this section are Immunity Debugger and IDA Pro, commercialtools that can be used for debugging a variety of programs and are extremely usefulfor identifying virus behaviour.

5.1 Packers, Wrappers and Binders

The terms packer, wrapper and binder are sometimes used interchangeablyto represent a method of creating Trojan infections, whereby two (or more)executables are wrapped together. In this context the term packer has aspecific meaning as the methods of compression and decompression (packing andunpacking) are used to evade detection by anti-virus engines that look for knownsignatures. It can also slow down reverse engineering attempts. Unpacking thedata at runtime, sometimes only in small increments, ensures that the function ofthe malicious code is exposed as minimally as possibly.

Parker (2007) discusses packers as part of an introduction to reverseengineering malware, in particular the example shows the UPX packer. The UPX

29

CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 30

packer is relatively unsophisticated, as it was not designed to evade detection andit can be fully unpacked using the same tool as created it. In addition its use isdisclosed in plain-text within the file. Nevertheless, the methods used to extractfurther information about the contents of the packed file are still relevant to othermalware investigations.

Tools such as PEiD can be used to detect the presence of common packersthrough both known signatures and common behaviours (such as known entrypoints or file offsets). The majority of modern anti-virus programs will also attemptto positively identify the packer used when encountering packed malware and,where possible, unpack the data. As seen in Figure 3.11 the anti-virus programin use was not able to do this. Thus the goal of the investigation at this stage wasto capture any unpacked data and examine it for any identifying information.

5.2 Unpacking the Virus

5.2.1 Anti-Debugging

An important consideration when reverse engineering programs, particularly whendealing with malware, is the presence of anti-debugging defenses. Typicallythese defenses are centred around methods of detecting whether the process isin a debugger but, like other malware anti-detection mechanisms, many moresophisticated approaches exist. Falliere (2007) provides an overview of some of thecommon anti-debugging defenses and ways of defeating them, broadly categorisedas:

• Memory discrepancies

• System discrepancies

• CPU anti-debug

Exploiting memory discrepancies for anti-debugging are givenas checks for flags and returned values, such as the result of thekernel32!IsDebuggerPresent Windows API returning a 1 or thePEB!IsDebugged flag being set. System discrepancies describe behaviourthat is different when running inside a debugger, for example theSetUnhandledExceptionFilter() will call the exception filter unless theprogram is being debugged (at which point the process will terminate). CPUanti-debugging is dependent on the architecture in use but exploits CPUinstructions to fool debuggers, for example INT3 (an interrupt command) is oftenrecognised by debuggers as a break-point and can alter the course of the programin weaker debuggers.

During the investigation, some deviations from common coding practices werenoted which are discussed in Section 5.2.2. These deviations resulted in the process


taking a path that was difficult to follow, and it is thought that these artefacts wereintentionally placed to make debugging more difficult.

An example of one of the methods employed to make debugging more difficultis seen in Figure 5.1. The function at 0042290D is called, followed shortlyby a RETN and the jump is then taken. This section could be reordered toperform effectively the same result, however it makes understanding the processslightly more difficult when reverse engineering. Whilst not a particularlysophisticated protection method, defying various coding conventions can slowdown the investigation of a piece of malware.

Figure 5.1: Function call and jump ordering

Whilst debugging, the process would randomly terminate forcing it to berestarted. This may be a result of poor coding or intentional anti-debuggingdefenses such as monitoring CPU cycles to detect when the process is significantlyslowed down for manual examination. The jumps that had to be bypassed (seeSection 5.2.3) to avoid invalid code may also be symptomatic of anti-debuggingtechniques.

5.2.2 Manual Coding Artefacts

Whilst debugging the virus, a number of deviations from common codingconventions were identified. The presence of these artefacts suggests that areasof the code had been written manually, as they would not typically be seen whenusing common compilers.

These artefacts give an insight into the coding practices of the creator of thepacker (which in this case could be a different individual to the attacker), and canalso help to understand the level of sophistication of such a packer.

Use of NOP

The NOP instruction (short for ‘No OPeration’ or ‘No Operation Performed’)effectively performs no action. It can be used legitimately, particularly as partof a development process to set placeholders or for timing purposes, however theinstruction is not commonly seen in production software. Optimisation performedby common compilers will typically detect and remove so called ‘redundant code’i.e. code that has no effect.

NOP instructions may also be used in sequence to create a ‘NOP sled’ or ‘NOPslide’ as a technique of improving the success of exploiting vulnerable software.


Solar Eclipse (2002) gives an example from the Honeynet Project of a NOP slidein use against a Solaris machine on SPARC architecture. It should be noted at thispoint that as SPARC architecture is different from x86 a NOP instruction does notexist (though other instructions are used as NOPs), though the concept of a NOPslide is still valid. As the location of shell code may be unknown (and may noteven be a static location), a string of NOP instructions placed before the estimatedlocation of the shell code will suffice. Overwriting a return address (for exampleby a buffer overflow) does not therefore require the exact location of the shell codeto be written - the jump can be taken to the location of the NOP codes and then‘slide’ through the NOPs until the shell code is reached. As a number of modernintrusion detection systems will attempt to detect long sequences of NOP codeson the stack, other instructions can be used as long as they do not jeopardise thecorrect running of the shell code.

The infection had a number of areas where NOP instructions were used,however none were of a significant amount to be classed as a NOP slide. Inparticular it was noted that where conditional jump instructions were used (suchas JNZ - jump if zero flag is not set, or JE - jump if zero flag is set) the jump wastypically to a NOP instruction. This could have been used as a placeholder for othercode as part of the development process, or may simply be used as a silent markerused in debugging to indicate that the program is on the right path. Nevertheless itgives an insight into the coding practices used in creating this packer.

Misuse of Instructions

In a number of areas it is apparent that code has been custom written as typicalconventions are not followed. This also includes areas of code that commoncompilers would attempt to optimise and thus suggest a manual approach has beentaken.

Figure 5.2 shows an example where the INC (increment) function was used onthe ECX register to increase its value by 1 a total of four times. The purpose ofthis particular action is explained further in Section 5.2.4, however this is clearlynot optimal. The use of an instruction such as ‘ADD ECX, 4’ would suffice.

Figure 5.2: Use of the INC function multiple times

Within the unpacking routine (described further in Section 5.2.4) the codeis unpacked four bytes (a DWORD) at a time. Whilst this is not a misuse ofinstructions in itself, it is common to handle such a routine a single byte at a time.


Reference to kERNeL32.Dll

An instruction pushed onto the stack was discovered to have an uncommonnaming convention. References to both kernel32.dll and KERNEL32.DLL (a baseWindows API) are common, however the peculiar capitalisation shown in Figure5.3 is not. As a number of signature based virus detection tools may look forreferences to kernel32.dll (or KERNEL32.dll) this could be a method used to evadedetection. In any case, this is again not a common coding practice.

Figure 5.3: A pointer on the stack referencing kERNeL32.Dll

5.2.3 Bypassing Invalid Instructions

As discussed at the beginning of this chapter, the use of a debugger can causeprograms and processes to behave in unpredictable ways. The use of a debuggeron an infected machine to identify the behaviour of a program with anti-debuggingdefenses can introduce even more unpredictable behaviour.

The first instance of this behaviour can be seen in Figure 5.4 where, shortlyafter executing the program, the process terminates as it comes across invalid code.

Figure 5.4: Invalid opcode


As the goal of the exercise is obtain identifiable information from the program,any invalid instructions can be bypassed or circumvented. Whilst this may seemlike valuable information is lost when the behaviour is not fully understood, it isuseful as a type of brute-force approach to get the program into a state where theunpacking begins.

This particular invalid opcode can be bypassed by setting the EIP (theinstruction pointer) to the next line of code 00401050. In Immunity this can beset simply by right-clicking on the line of code and selecting ‘New origin here’.Bypassing this section of invalid code allows the program to continue until a jumpis reached.

Figure 5.5 shows a JE instruction to the address 00401164, the code for whichcan be seen in Figure 5.6. Again this code is invalid and causes the process toterminate, therefore the jump at 004011DD must be bypassed. In Figure 5.5 thetop-right corner shows the Zero Flag is set - the Zero Flag is set to 1 if the resultof an instruction was zero or false. As the Zero Flag is set the jump will be taken -the condition is satisfied (this is also shown in Immunity by the message ‘Jump istaken’). To bypass this jump a breakpoint should be set, instructing the debuggerto await further instruction, and the Zero Flag set to 0. The condition for the JEinstruction will not be met and the jump will not be taken.

Figure 5.5: Jump to invalid opcode

Figure 5.6: Invalid opcode

On bypassing this jump the process continues until a similar condition is met,in this case the Zero Flag is not set and a JNZ instruction exists. The Graphsfunction in Immunity provides a visualisation of the branches that the process cantake depending on whether the jump is taken or not. Figure 5.7 shows the pathtaken in red if the jump is not taken (the current option) and in green if the jump istaken. Immediately it is obvious that not taking the jump will result in terminationof the process, as the function kernel32.ExitProcess is called. Again the ZeroFlag must be modified and, this time, the jump is taken.

The final set of invalid instructions forms an infinite loop unless bypassed bysetting a new origin, as described above. The instruction at 00422891 calls afunction at address 0042298C (see Figure 5.8). Rather than ending with a RETN


Figure 5.7: Branch structure showing jump results

(return) instruction and continuing, the function reaches a JMP (unconditionaljump) which then calls the same function again, looping continuously.

In this case the jump at 004289A is never reached, but it must exist for a reason.Examining the location of the jump reveals that it leads to a NOP instruction at004228A8 - from the knowledge gathered so far about the coders use of NOPinstructions denoting useful code blocks, it is likely that taking this jump will resultin the process continuing. Again, setting the origin either to the NOP location orthe jump itself continues the process and in this case leads to a critical part of theprogram - the unpacker.

Figure 5.8: Infinite function loop


5.2.4 The Unpacking Loop

The section of code responsible for unpacking the data can be seen in Figure 5.9

Figure 5.9: The unpacking loop

One point to note is that the command INC ECX appears four times,incrementing the ECX register by 1 each time. It is not clear as to why this wouldbe performed instead of a more efficient instruction, such as ‘ADD ECX,4’. It ispossible that this is set to deal with timing issues or may simply be a sign of thecoder’s thought pattern. The result of this action is clear however, as the value ofECX is used to set the memory address of the data to unpack (not shown). Thuswith each iteration, four bytes (a DWORD) are decrypted at a time.

It is clear that the code is changing with each iteration and at first it maynot be clear what this unpacked data represents. After several iterations a textstring begins to appear, referencing “Lighty Compressor” (as seen in Figure 5.10).Lighty Compressor is the name of the packer used to create this virus - a vitalclue, as a number of unpacking tools have been developed for common packers.Unfortunately in this case an unpacker does not exist in the public domain forLighty Compressor, necessitating this manual approach.

Martyanov (2008) details some of the uses of Lighty Compressor as a packer ina Live Journal blog on multiple occasions in reference to virus infections. In replyto a comment placed by another poster, Martyanov explains that an unpacker couldnot be found in the public domain but that a manual approach should be successfulonce the line “Lighty Compressor” is stored in memory. This is in line with theresults seen so far.


Figure 5.10: Unpacked code revealing “Lighty Compressor”

5.2.5 Identification

Allowing the unpacking routine to continue allows more data to be viewed in it’sunpacked format. As this unpacked data resides in memory, taking a snapshot ordump of the current memory state allows the unpacked data to be examined further.

Loading this memory dump in IDA Pro provides a number of options forfurther investigation, including the ability to generate a list of all the stringsidentified in the process. These strings often provide further information aboutthe functions being called, file references and sometimes identifiable informationsuch as IP addresses, server names or usernames and passwords.

Figure 5.11: Strings within the unpacked data

Figure 5.11 shows some of the strings that are particularly interesting, as theyreference files such as nvaux32.dll, aston.mt and dllcache\\user32.dll (anon-standard location for the user32.dll file).

A logical next step is to research the files named by these strings and determinewhether they are referenced by any known and previously identified viruses.Whilst viruses are typically seen in multiple different mutations and may behavedifferently in different situations, this technique can be used to narrow down thesearch significantly. Once common infections have been identified, the behaviour


of different variants can be explored to see if it conforms to the behaviour seen inChapter 4.

Virus databases of common anti-virus vendors is a useful place to findinformation on infections, the McAfee ‘Threat Resources’ site matches a numberof the strings identified with the W32/Mariofev worm. Furthermore, a report fromPrevx on the NVAUX32.DLL file identifies behaviour consistent with that noted inChapter 4 whereby *.tmp files are dropped in the Temp folder.

Having identified a strong candidate for the virus, it is important to positivelyidentify it. The common locations for the known malicious files are listed withinthe virus reports noted above, and so it remains to examine these locations for theexpected artefacts. Figure 5.12 shows that the nvaux32.dll existed within thesystem32 folder as expected; a virus scan of this file was finally able to detect andidentify it as an infection of the Mariofev worm.

Figure 5.12: nvaux32.dll within the system32 folder

Whilst the exact methods the worm uses to spread may differ slightly in thisparticular incarnation, the following attack vectors are common to a Mariofevinfection:

• Dictionary attack against network file shares

• Attempts to establish network connections to HTTP servers based in Russia

• Attempting to disable common anti-virus and virtualisation software (suchas VMWare)


5.3 Conclusions

The techniques presented in this chapter can be used in the future for dealing withviruses that cannot be unpacked and identified by anti-virus software. It may notbe known that Lighty Compressor has been used to pack a piece of malware untilit’s protections have been bypassed, however the presence of artefacts presented inSection 5.2.2 could suggest that Lighty Compressor has been used. Whether LightyCompressor has been used or not, the ‘brute force’ approach to reverse engineeringmalware - forcing the code towards a state where the unpacking routine begins, canlead to quick (if not complete) results.

The worm in this case has been packed with another file as a Trojan andtherefore requires user interaction to unleash it. Once unleashed however the wormcan spread without requiring any user interaction through the methods outlineabove.

To determine whether the worm has been unleashed, a final scan of the logfiles for any instances of successful downloads of the infected files was performed.Figure 5.13 shows how a list of all uses of the RETR command can be created withgrep and then examined for any matches with a list of known infected files. Thiswas performed on a subset of the log files starting from the time after which theinfected files were first uploaded to the server.

:˜$ grep RETR R ./ > retr

:˜$ for FILE in ‘cat infected_files.txt‘; do grep $FILE retr done

:˜$

Figure 5.13: Identification of any downloads of infected files

In this case Victim has been fortunate - no successful downloads of the infectedfiles can be seen from the log files and the risk that this poses to Victim is nowsignificantly lower.

Chapter 6

Remedial Actions

A number of activities performed by Victim could have prevented this incidentfrom occurring. A formal joiners and leavers process to fully identify the level ofaccess required and granted should be established. In addition, any further accessrequests should also be formalised and maintained on record. This will ensurethat a complete list of all user accounts and access levels are available when astaff member leaves and the accounts can be disabled appropriately. This type ofprocess typically requires coordination with HR, as they must regularly inform theIT department of joiners and leavers.

Regular monitoring of log files may have alerted Victim to this incident earlier,as some of the identified activity suggesting automated attacks were clearly notin line with legitimate user activity. It is anticipated that manual monitoring ofsuch detailed log files may be time consuming, however a daily review of WS FTPgenerated reports will allow Victim to spot behavioural trends that could point tomalicious activity.

The use of file integrity monitoring software would also have alerted Victimto the modification of files that was the main impact of the reported incident. Filemonitoring software implemented for an FTP server (where constant file changesare normal activity) may not be as effective as other applications, however a fileintegrity alert could be used as a trigger to identify files for automated virusscanning. In this way a file that has been modified to contain malware would beidentified.

To fully ensure that this incident has been contained there are a number ofactivities that Victim must perform. Despite the fact that no log entries indicatedthat the infected files had been downloaded via FTP, it is still important that anyat risk machines are identified. This should follow an umbrella approach whereany person or machine with physical or network access to the server is considered,and the scope of the risk is methodically narrowed down. These at risk machinesshould then be subject to an anti-virus scan with up to date anti-virus definitions.It is also essential that these machines are manually examined for existence ofthe files detailed in this report; where possible this should be performed by

40

CHAPTER 6. REMEDIAL ACTIONS 41

booting the machine into safe mode so that any infections cannot utilise advancedanti-detection techniques. Furthermore, the FTP server should be treated ascompromised until it can be securely wiped and rebuilt using the latest stable andsecure software. This action will ensure that the known vulnerabilities associatedwith the server are removed and that traces of any malicious software that mayhave been installed on the server are removed.

Chapter 7

Conclusions

A log file analysis is a good place to start an investigation, as with carefullyconstructed queries a large amount of information can be gathered from them.Being such a valuable source of information it is common to find them corrupted ordestroyed, and in this case it is fortunate they have not been compromised further.Log files should not be used to assess the current state of a system without a directexamination, but are the first step in narrowing down the window of investigation.In this case the log files provided an alert to the possibility of malicious filesexisting on the server.

It is not known how the attacker came to acquire credentials to a valid account.Whilst a number of theories have been discussed, ultimately it is irrelevant aslong as Victim engages in a program of remediation. By mitigating against likelyattacks and educating staff in secure working practices, Victim can ensure that thepossibility of further compromise is minimised.

A malware analysis that encompasses all four stages of the analysismethodology - static, mounted, live and network has a good chance of identifyingthe behaviour of malware. In cases where the malware cannot be positivelyidentified by anti-virus, the techniques presented can build up a picture of itsbehaviour such that it can at the very least be narrowed down to particular virusfamily. The top anti-virus vendors have large research teams dedicated to capturingand identifying malware, and it is likely the malware discovered is not being seenin the wild for the first time. A combination of tools and techniques to identify thisbehaviour is normally enough to find a match against previous analysis.

The use of reverse engineering techniques allowed both the virus and the packerused to evade detection to be positively identified. The efforts required to gain thisinformation will be returned many times over as Victim is able to focus attention onmonitoring the specific infection vectors used by the virus, by monitoring access tospecific web addresses and brute force attacks against file shares. Even experiencedbreach investigators should expect to learn something new from each investigationand until a successful unpacking tool is released for Lighty Compressor, theability to manually bypass the protections used will significantly benefit any future

42

CHAPTER 7. CONCLUSIONS 43

investigations. Future work in this area could be focussed on investigating theLighty Compressor further and developing an automatic unpacker that can bothdetect the use of Lighty Compressor and provide an investigator with the unpackedcontent.

On this occasion, Victim has been fortunate that further infection did notoccurr. Furthermore, the breach showed a number of changes that need to made toVictim’s security program in a harsh method of highlighting current weaknesses.Security weaknesses in commercial organisations often stem from a lack of supportat board level and for all the recommendations that can be made by external securityassessors, nothing raises awareness quite like a breach. Whilst the cost of a breachcan be high, both in terms of system repair and staff time, the assurance gainedfrom knowing the attacker has not penetrated further and the lessons learned fromthe incident are invaluable.

Appendix A

Code

A.1 FTPCHK3.php Removal#!/usr/bin/perl

# http://digitalpbk.blogspot.com/2009/10/ftpchk3-virus-php-pl-hacked-website.html

use strict;

‘grep -Rn aWYoIWlzc2V0KCRiMHNyMSkpe2Z1bmN0aW9u * | cut -d ’:’ -f 1 > listofinfected‘;

open FP,"listofinfected";

my $file;

while($file = <FP>){

print "Testing $file ... ";

chomp($file);

if(-e ($file)){

open VI,$file;

my @filecon = <VI>;

close VI;

if($filecon[0] =˜ m/aWYoIWlzc2V0KCRiMHNyMSkpe2Z1bmN0aW9u/){

$filecon[0] =˜ s/(<\?.*?\?>)//g;

rename($file,$file.".infected");

open VI,">$file";

print VI join(’’,@filecon);

close VI;

print $file." Fixed !!";

}

}

print "\n";

}

close(FP);

‘grep -Rn ftpchk3.php * | cut -d ’:’ -f 1 > listofinfected2‘;

open FP,"listofinfected2";

my $file;

while($file = <FP>){

44

APPENDIX A. CODE 45

print "Testing $file ... ";

chomp($file);

if(-e ($file)){

open VI,$file;

my @filecon = <VI>;

close VI;

my $fc = join(’’,@filecon);

$fc =˜ s|document.write(’<script(.*?)ftpchk3.php(.*)script>’);||sig;

$fc =˜ s|<script[\s]+src="?http(.*?)ftpchk3.php(.*?)script>||sig;

rename($file,$file.".infected");

open VI,">$file";

print VI $fc;

close VI;

print $file." Fixed !!";

}

print "\n";

}

close(FP);

References

[1] 7Safe. UK Security Breach Investigations Report. 2010.

[2] 7Safe and ACPO. Good Practice Guide for Computer-Based ElectronicEvidence. 2007.

[3] BitDefender. BitDefender Defense Center, 2010.http://www.bitdefender.co.uk/site/VirusInfo/.

[4] B. Carrier. File system forensic analysis. Addison-Wesley Professional, 2005.

[5] S.K. Cha, I. Moraru, J. Jang, J. Truelove, D. Brumley, and D.G. Andersen.SplitScreen: Enabling efficient, distributed malware detection. Proc. 7thUSENIX NSDI, San Jose, CA, 2010.

[6] CVE. Vulnerabilities in GDI Allows Code Execution (MS08-021), 2008.http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1087.

[7] e-fense. Helix, 2010. http://www.e-fense.com/helix/.

[8] Solar Eclipse. Honeynet Project Scan of the Month for April 2002, 2002.http://www.phreedom.org/solar/honeynet/scan20/scan20.html.

[9] N. Falliere. Windows Anti-Debug Reference. Retrieved October, 1, 2007.

[10] Ipswitch FTP. Ipswitch FTP Server, 2010.http://www.ipswitchft.com/Business/Support/WsFtpServer/index.aspx.

[11] J. Granick and K. Opsahl. Computer Crim Year in Review. In BlackHatBriefings, 2009.

[12] T. Holt, M Kilger, D. Strumsky, and O Smirnova. Identifying, Exploring, andPredicting Threats in the Russian Hacker Community. In Defcon 17, 2009.

[13] Jibz, Qwerton, snaker, and xineohP. Peid, 2007. http://www.peid.info.

[14] C. Kolbitsch, P.M. Comparetti, C. Kruegel, E. Kirda, X. Zhou, X.F. Wang,and UC Santa Barbara. Effective and efficient malware detection at the endhost. In 18th Usenix Security Symposium, 2009.

46

REFERENCES 47

[15] V. Martyanov. Vladimir martyanov’s live journal, 2008.http://v-martyanov.livejournal.com/1738.html.

[16] McAfee. Mcafee threat resources, 2008.http://vil.nai.com/vil/content/v 144571.htm.

[17] Trend Micro. TrendLabs Malware Blog, 2010. http://blog.trendmicro.com/.

[18] Microsoft. Microsoft Security Bulletin, 2010.http://www.microsoft.com/technet/security/current.aspx.

[19] Safer Networking. FileAlyzer, 2008.http://www.safer-networking.org/en/filealyzer/index.html.

[20] A. One. Smashing the stack for fun and profit. Phrack magazine,7(49):1996–11, 1996.

[21] D. Parker. Reverse engineering malware, 2007.http://www.windowsecurity.com/articles/Reverse-Engineering-Malware-Part4.html.

[22] N. Percoco and J. Ilyas. Malware Freak Show. In Defcon 17, 2009.

[23] A. Prabhakar. Ftpchk3 : Virus that adds malicious scripts to your website.,2009. http://digitalpbk.blogspot.com.

[24] M.D. Preda, M. Christodorescu, S. Jha, and S. Debray. A semantics-basedapproach to malware detection. ACM Transactions on ProgrammingLanguages and Systems (TOPLAS), 30(5):25, 2008.

[25] Prevx. Prevx file investigation report, 2008.http://www.prevx.com/filenames/20878752371790299-X1/NVAUX32.DLL.html.

[26] RemoteDesktop.com. Bagle’s back, 2010.http://www.remotedesktop.com/?p=30.

[27] M. Richard and M. Ligh. Making Fun of your Malware. In Defcon 17, 2009.

[28] R. Russinovich. Microsoft Sysinternals), 2010.http://technet.microsoft.com/en-us/sysinternals/default.aspx.

[29] Sashazur. Using UpdateResource to change a string resource, 2004.http://www.codeproject.com/kb/string/updatestringresource.aspx.

[30] Net Security. Workers stealing data for competitive edge, 2009.http://www.net-security.org/secworld.php?id=8534.

[31] Offensive Security. BackTrack-Linux.org, 2010.http://www.backtrack-linux.org/.