Академический Документы
Профессиональный Документы
Культура Документы
Ben Downton
June 2, 2010
Abstract
I would like to thank the University of Bedfordshire and Dr. Paul Sant for providing
support for this project, MWR InfoSecurity for giving me a platform to perform and
publish this work, and finally Rhiannon for diligently proof-reading and supporting
me throughout.
Contents
1 Introduction 3
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Literature and Tool Review . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Forensic Investigations . . . . . . . . . . . . . . . . . . . 4
1.3.2 Malware Analysis . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Threats and Exploitation . . . . . . . . . . . . . . . . . . 5
1.3.4 Tool Review . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 7
2.1 Key Players . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Victim’s Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Recommendations for Victim . . . . . . . . . . . . . . . . . . . . 8
2.4 Account Compromise . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Malware Analysis 21
4.1 Antivirus Considerations . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Static Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Live Analysis - Playing in the Sandbox . . . . . . . . . . . . . . . 25
4.3.1 Dropping the Payload . . . . . . . . . . . . . . . . . . . 25
4.3.2 Vulnerability Exploitation . . . . . . . . . . . . . . . . . 27
4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1
CONTENTS 2
6 Remedial Actions 40
7 Conclusions 42
A Code 44
A.1 FTPCHK3.php Removal . . . . . . . . . . . . . . . . . . . . . . 44
Chapter 1
Introduction
3
CHAPTER 1. INTRODUCTION 4
Finally, the conclusion of the work will be to illustrate the impact caused
by 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 be
discussed.
The outcome of this work will be:
• Raising awareness of how security weaknesses are exploited in the real world
• grep - a command line tool written for Unix systems for searching for text
• hexedit - a tool for viewing and editing the raw data of a file in hex format
• Helix - a live Linux distribution containing tools and features geared towards
forensic analysis
Background
7
CHAPTER 2. BACKGROUND 8
attacks on the network. An opportunistic attacker may not continue the attack
once the vulnerabilities have been resolved, however a determined attacker that is
targeting Victim specifically will likely seek out other avenues of attack.
In order to maintain a good working relationship with Client it is also
recommended that Victim engage in discussions about how best to maintain the
service offered. It may not be the place of the investigator to determine how Victim
should proceed, however that does not preclude them from offering advice from a
trusted position. In this case, Client has demanded that provision is made for all
file transfers to be conducted over SFTP. This is a more secure alternative to FTP
offering encryption, message integrity checking and identity verification by, for
example, public keys. The use of SFTP offers additional protection against traffic
sniffing or man-in-the-middle (MitM) attacks to recover Client’s credentials; it will
not provide protection against the use of weak or easily guessable passwords.
As a general recommendation, Victim should ensure that sufficient technical
resource is available to support the investigation. Any delays in acquiring
information can cost Victim in wasted time on the part of the investigator.
Furthermore, failure to properly contain the incident in a timelay manner can
expose the network to a greater risk of attack.
• Malicious ex-employee
• Leaked credentials
The first case is that of a malicious ex-employee with remote access to their
account. This scenario is likely, particularly for a company that does not have
a 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 a
new position, indicating the value that employees place on their (ex)company’s
data. At this point it becomes useful to discuss the circumstances in which the
employee left and any other relevant information (such as position, access levels
and technical ability) with the HR department. For this case study it was noted that
the employee left on reasonably good terms, though it was likely that they would
have continued working in the same industry. The employee was not particularly
CHAPTER 2. BACKGROUND 10
technically proficient, and would have known what areas of the server they would
and 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 which
exploits are well documented). Again this is a situation where useful information
can be gathered through discussions with the Victim. The account that has been
compromised did not have a high level of access; it is likely that exploitation of
the vulnerabilities in the software would have resulted in root access to the system
rather than an individual lower privilege account. Even had the software been up to
date, the possibility of a zero-day (0-day) attack being executed against the server
should be considered.
It is possible that an account could become compromised through leaked user
credentials. This becomes even more of an issue when there are limited password
policy 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 support
encryption (unlike the more secure alternative SFTP), meaning credentials are sent
over clear-text channels. User credentials could also become compromised by
targeting the owner of the credentials directly, as they may be cached on the owners
system or even stored in a text file or written on a piece of paper. The owner of the
credentials could also be the target of a phishing attack where, if successful, they
would unwittingly submit credentials to an attacker. It was noted by Victim that
the original owner of the account was particularly ‘mobile’, attending conferences
and working from public locations, which would have increased the risk that the
owner would be the target of an attack.
A common method through which accounts can become compromised is by
an automated brute force or dictionary attack. This type of attack involves an
attacker attempting to log in to accounts with multiple different passwords until a
successful login occurs. This attack is not particularly stealthy, as large volumes of
traffic and log file evidence can be identified, but can have a high chance of success
where a weak password policy is in place. Password controls, such as applying
temporary account lockouts for multiple logon failures, regular forced password
changes and a password history can significantly reduce the threat of brute force
attacks. The success of a brute force attack can be made more likely through the
use of specially crafted dictionaries. Where a brute force attack would attempt all
passwords between for example a to ZZZZZZZZ, a dictionary attack uses a list of
commonly used passwords. This increases the likelihood of finding the password
quickly at the cost of potential success should the password used not be in the
dictionary. Typically a brute force attack will show up in logs as multiple login
failures, followed by a successful login, followed by more login failures. This is
due to the automated nature of such attacks, where an attacker will commonly leave
an attack tool or script running in the background whilst performing other tasks.
Chapter 3
Evidence of a brute force attack would identify the earliest time that the account
was compromised, as well as identify whether the attack was successful (through
evidence of a logon success). A search through the log files for a high number of
logon failures would highlight evidence of a brute force attack.
Figure 3.1 shows an example log entry for failed logon attempts. A number
of logon attempts for the 3rd of March at approximately 18:13 onwards were
identified from the same IP address (marked below as 71.62.X.X). Once an IP
address has been identified as suspicious it is always advisable to try and pinpoint
the owner of that IP address. Whilst it is common for an organised attacker to
utilise compromised machines in many geographical locations (to evade detection),
it is less common for malicious insiders to have these resources available. It is
also 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 conviction
to 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)
The whois tool can be used to query Regional Internet Registries (RIRs) which
hold contact, ownership and status information for domains and IP addresses. An
example 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 that
this IP address belonged to the US office that had conducted some of the initial
investigation. The logon failures identified were a result of the IT department
attempting to guess the password for the ‘attacker’ account in order to investigate
further. Whilst this did not significantly hinder the investigation, it highlights some
of the issues involved with non-experts conducting investigations as part of the
initial 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 expert
are fully understood and documented.
whois 71.62.X.X
Further searches for login failures by the attacker account were conducted
using a simple grep command: grep "attacker ERR:logon failure" *.
Whilst a number of logon failures were identified, there was not a significant
number (or in succession) that would indicate a brute force attack.
The login messages in Figure 3.3 were flagged by Victim as suspicious due to
the apparent ‘randomness’ of the data in the message. As this type of data was
not commonly seen by Victim it was not known whether the data was indicative of
abnormal 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 an
XAUT logon attempt where the username and password combination is encrypted.
Examination of other similar login attempts revealed that this activity was normal
not only for the suspect1 and suspect2 accounts but also for a number of other
accounts in normal use.
Furthermore, a search for any activity by the accounts suspect1 and suspect2
matching 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’s
folders, was enough to exclude the suspect1 and suspect2 accounts from further
investigation for the time being.
30Gb in size), narrowing down the window of investigation in the early stages can
significantly speed up future searches.
A search for all successful logons to the attacker account revealed no activity
between March and November. It was confirmed by Victim that the original
owner of the account left in March, which corresponds to the time that the
activity stopped. This information narrows down the window of intrusion (the
time between first contact and incident containment) to five months, significantly
smaller than the log files provided. The IP addresses used to access the account
from 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 address
of the attacker is not consistent. This is typical for remote attacks where an
attacker will ‘pivot’ attacks through other compromised machines. Launching
attacks from various different locations makes it more difficult to identify the
attacker, both at a physical level (for example to pursue a conviction) and at a
logical level (such as blocking access from specific ‘at risk’ IP addresses). The
majority 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 attack
origins indicate that it is likely that compromised machines have been used as the
final hop before the attack on Victim’s servers. Public machines such as those
in 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 for
anonymity. Furthermore, launching attacks from systems located in countries that
may 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 will
be able to negotiate access to the compromised machines. A report by 7Safe (2010)
reported that approximately 10% of attacks under their investigation were launched
from these countries, however it is also acknowledged that the attacks could have
been launched from compromised machines.
The first method that the attacker used to enumerate account permissions was to
identify what directories the account had access to by attempting to systematically
read the contents of subdirectories. The attack was performed by changing the
current directory to each subdirectory in alphabetical order (identified by the CWD
command) 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 automated
attack to enumerate permissions of the attacker account. Figure 3.5 shows an
example of where the automated script was performing recursive queries, as the
attacker attempted to change to a directory that was actually a file. Information
such as this may not provide a definite answer for what caused the incident but can
nevertheless contribute towards building a profile of the attacker, such as the level
of sophistication and resources available. An attack such as this is not particularly
stealthy 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
0228 16:23:59 (00001370) ftp.victim.com D(0) 69.73.X.X attacker PASV DATA connection to
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 PASV
0228 16:24:00 (000012c4) 69.73.X.X attacker:ftp.victim.com forced close listener socket
0228 16:24:00 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker NLST
0228 16:24:00 (00001370) ftp.victim.com D(0) 69.73.X.X attacker PASV DATA connection to
69.73.X.X:36827
0228 16:24:00 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker CWD /ASOT LTD
0228 16:24:00 (000012c4) ftp.victim.com D(0) 69.73.X.X attacker PASV
0228 16:24:00 (000012c4) 69.73.X.X attacker:ftp.victim.com forced close listener socket
The second method that the attacker used to enumerate permissions was to
identify which of these directories could be written to. This was achieved by
attempting to systematically upload and then immediately delete a file named
tmp5842258422.html to various directories. It is thought that the attacker deleted
this file immediately as a method of evading detection, as copies of the file left
in various folders may arouse suspicion. It should be noted however that the
CHAPTER 3. LOG FILE ANALYSIS 16
attacker did not make particular efforts to conceal their presence elsewhere, and
it is possible that this behaviour was typical of an automated tool that a lower
skilled attacker could use.
The file named above (and shown in Figure 3.6) could not be recovered for
further analysis. The file may have been a dummy file (with minimal size) to allow
the uploads to occur as quickly as possible. The file may also have contained
malicious code to be executed by either the attacker or an unsuspecting victim at a
later date. In this instance it can be seen that the file was approximately 18Kb in
size - enough to contain a malicious web shell that could potentially be accessed
through 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
0229 04:30:24 (00001620) ftp.victim.com D(0) 87.118.X.X attacker PASV DATA connection to
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)
amount of information about the attackers activity still remaining would suggest
that they have not been modified at all, particularly as the account would not have
been able to modify the logs without elevating privileges.
With no successful download attempts noted for the client folder, it remained
to determine whether any files had been removed or uploaded. Figure 3.7 shows
an 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)
Successful Uploads
Following on from this discovery, it became necessary to
identify exactly what files the attacker had uploaded. This
was 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 the
attacker account. This also returned three lines of context surrounding any
instances so that further information about an attack could be obtained and stored
in the attacker stor.txt file.
In this instance a number of issues were found with the above command. Firstly
the results could be repeated a number of times due to the use of the -C flag
denoting the surrounding context lines to be captured. Secondly, a large number of
failed file upload attempts were noted and any successful uploads may have been
lost 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 to
refine the output using another scripting language. Figure 3.8 shows a script
CHAPTER 3. LOG FILE ANALYSIS 18
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 STOR
command is used but an error (ERR) does not occur. The space in the command
if lines[count].include?(" STOR") is intentionally added as an additional
measure for extracting only successful storage attempts (as a failure is denoted by
ERR: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 s
f . close
c o u n t =0
w h i l e ( c o u n t < 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 n o t l i n e s [ c o u n t + 1 ] . i n c l u d e ? ( ”ERR” ) t h e n
p r i n t l i n e s [ count ]
end
c o u n t +=1
end
As the only information available at this stage was the log files, some
assumptions 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 be
common Lotus Notes components. It was not immediately clear why an attacker
would wish to upload files for running Lotus Notes, a client for managing business
emails, calendars and applications. It is possible that the attacker was using this
client to pivot further attacks (such as interfacing with a Lotus Domino server) or
to trick a user into installing malicious software.
To fully understand the motives behind uploading these files, the log files
detailing these uploads were examined manually for further information. By
examining the successful upload within the context of the surrounding activity,
it became clear that the attacker was actually uploading files that had been
downloaded 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 the
RETR command showing a successful download followed by deletion with DELE.
Seconds later a connection is initiated again, this time uploading the file with the
STOR 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)
This activity constitutes a high risk for victim, and warranted further
investigation. The fact that files have been downloaded and then replaced within
seconds 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) 20530
bytes were downloaded and 172594 bytes were uploaded, again suggesting that
the files have been modified. This modification was noted as highly likely to be
malicious.
CHAPTER 3. LOG FILE ANALYSIS 20
3.3 Conclusions
As a result of the initial investigation, Victim was happy with the assessment that
Client’s information had not been downloaded by a malicious attacker. Despite the
fact that the suspicious file uploads had been raised, Victim no longer wished to
continue the investigation and issued a statement to Client detailing the findings of
the investigation as they relate to Client’s property.
The following day, Victim examined the files that had been uploaded and
immediately received an alert from their anti-virus, reporting an infection of
TrojanHorse.Generic (shown in Figure 3.11). As the anti-virus engine couldn’t
provide any further information, Victim supplied the infected files for inspection
and the investigation continued.
Malware Analysis
The alert in Figure 3.11 shows how anti-virus can use detection techniques above
normal ‘signature’ based detection to alert the user to a threat. The anti-virus
software in use detected that the virus has been packed (a form of encrypting
viruses to make them undetectable) but was unable to obtain any identifiable
information from either unpacking the virus or identifying the packer in use. In
this situation the user has been alerted to an infection, but actually identifying the
contents will require a manual approach.
Detecting malware behaviour can take place in various environments, typically
falling into one of four stages: Static, Mounted, Live or Network. Figure 4.1 shows
the natural progression of malware investigation in the four stages.
Static analysis takes place when the infected file is placed into a
non-functioning environment and analysed as raw data. The benefits that this has
are that the virus cannot utilise any advanced techniques to evade detection and
any unencrypted strings or headers can be easily identified. However, if the virus
has been created using a packer (which is then decrypted at run time) there will be
little information about its behaviour in the static analysis phase.
Mounted analysis involves mounting the filesystem on which the infected
files are stored as a logical drive within the investigation machine. This has the
advantage that the file can be viewed in it’s native environment, allowing for file
and folder permissions and metadata to be more easily examined. It is also easier
to run the file through anti-virus engines to determine if the infection conforms
to any known signatures. Whilst in the mounted stage, anti-virus scanning is
typically limited to matching signatures (or definitions) from a known database
and 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 files
or injecting processes into memory.
Live analysis should occur within a sandboxed environment where the
resources available can be strictly controlled. At this stage the infection can be
set loose on a system and its effects monitored or controlled. Live analysis can also
make use of anti-virus engines to detect malware like behaviour that may indicate
the type of infection. Typically this stage makes use of virtual machines such as
VMWare, as we will see in Section 4.3.
Finally, the network analysis stage looks at any network traffic associated with
the infection. When viruses are created for profit (rather than to annoy), they
typically need to transfer information to be successful. This can be to infect further
machines, 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 Wireshark
can 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 been
made clear by the fact that positive identification of the virus and it’s behaviour
was not possible. This chapter discusses the benefits and drawbacks of automated
anti-malware services before detailing a manual approach towards identifying virus
behaviour.
circumstances all of a company’s mail or web traffic will be passing through the
managed service provider. This would result in them being a single point whereby
a malicious attacker could gain access to all business data not protected using other
means (for example PGP or HTTPS). The company should therefore acknowledge
that the potential compromise of the third-party’s systems could expose a large
amount of business data to a malicious attacker or insider. Whilst this risk is likely
to be less than that exposed by not utilising such services it is important that this
dependency be acknowledged and documented on the appropriate risk register.
them. In Figure 4.2 the multiple file headers show the sections of the program
designed to drop the payload, the original program and the malicious payload
respectively.
The first section of the program (from the start of the file to the PE header at
0x1200) contains code that has been designed to execute the original program as
well as the malicious payload at 0x6232. Examination of a number of the infected
files revealed that the first section was identical across all of them - something that
would not be typical of a number of different programs.
The PADDINGXX (seen just above the third and final PE header) appeared to
be suspicious, particularly as this file had already been flagged as high risk. Use
of repeated sequences is typically seen as padding in exploits for buffer overflow
vulnerabilities (notably \x41), and so PADDINGXX could be part of an exploit in
the malicious payload. Sashazur (2004) explains that PADDINGXX is seen as a side
effect of using the UpdateResource function to correctly align sections within an
executable. Whilst this provides a lead as to how this section of the executable was
created 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; examining
copies of known safe versions of Lotus Notes executables revealed that PADDINGXX
is commonly seen.
Finally, the last section of the executable is the malicious payload. There is
CHAPTER 4. MALWARE ANALYSIS 25
little information available by examining this section statically, as there are no clear
text strings containing information about the payload. This could be by design
or, more likely, that the payload is encrypted with a packer (described further in
Chapter 5).
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.tmp
is identical to the other files dropped by the infection, as discussed later in this
section.
The file could easily be overlooked as a normal temporary file, given it’s
location and filename. However, as the results from the Sysinternals tools show this
file is flagged as suspicious. FileAlyzer is a useful tool for Windows, developed by
Safer Networking, that allows files to be analysed in detail. It also allows the raw
data to be analysed and, as Figure 4.4 shows, the 1.tmp file has a PE header; the
file is an executable and not an ordinary temporary file.
Infecting the machine multiple times (through executing the infected file
multiple times) is a useful method for determining virus behaviour. Comparing
the 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 to
change, as copies of 2.tmp, 3.tmp, 4.tmp, 16.tmp, C.tmp and D.tmp were all seen
as a result of reinfection where 1.tmp already existed.
One method of identifying files is by a unique signature or hash; a hash of a
file is an (effectively) unique value that is generated based upon the raw data of the
file. This hash will be calculated exactly the same when when identical input data
is 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 matter
how insignificant) will result in a very different output. Hashing files is therefore
a useful way of determining whether two files are identical, as they will have a
matching hash value.
CHAPTER 4. MALWARE ANALYSIS 27
The MD5 hash (a commonly used algorithm) of all the files examined in the
Temp folder was: c5ad1457dba612bbd7751aa5354075b1. It is acknowledged
that MD5 contains known flaws which can, under special conditions, be exploited
to make malicious modifications to files that will still pass integrity checks;
however, for the purposes of swiftly comparing file contents it is suitable.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\GRE_Initialize
4.4 Conclusions
Some of the behaviour of the infection has been identified, and a likely target for
exploitation has been seen (though not actively exploited in the tests performed).
Some viruses have the capability of detecting virtualisation technology and will
modify their behaviour accordingly.
Whether this failure to infect the sandbox further is a method of preventing
analysis, a bug in the malware or simply a result of virtualisation not emulating a
live machine exactly, the full extent of the infection cannot be established solely by
monitoring it’s behaviour.
The following chapter explores the techniques used to identify the behaviour
of the virus through reverse engineering and debugging.
Chapter 5
29
CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 30
• Memory discrepancies
• System discrepancies
• CPU anti-debug
taking a path that was difficult to follow, and it is thought that these artefacts were
intentionally placed to make debugging more difficult.
An example of one of the methods employed to make debugging more difficult
is seen in Figure 5.1. The function at 0042290D is called, followed shortly
by a RETN and the jump is then taken. This section could be reordered to
perform effectively the same result, however it makes understanding the process
slightly more difficult when reverse engineering. Whilst not a particularly
sophisticated protection method, defying various coding conventions can slow
down the investigation of a piece of malware.
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 part
of a development process to set placeholders or for timing purposes, however the
instruction is not commonly seen in production software. Optimisation performed
by 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 ‘NOP
slide’ as a technique of improving the success of exploiting vulnerable software.
CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 32
Solar Eclipse (2002) gives an example from the Honeynet Project of a NOP slide
in use against a Solaris machine on SPARC architecture. It should be noted at this
point that as SPARC architecture is different from x86 a NOP instruction does not
exist (though other instructions are used as NOPs), though the concept of a NOP
slide is still valid. As the location of shell code may be unknown (and may not
even be a static location), a string of NOP instructions placed before the estimated
location of the shell code will suffice. Overwriting a return address (for example
by a buffer overflow) does not therefore require the exact location of the shell code
to 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 modern
intrusion detection systems will attempt to detect long sequences of NOP codes
on the stack, other instructions can be used as long as they do not jeopardise the
correct 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. In
particular it was noted that where conditional jump instructions were used (such
as JNZ - jump if zero flag is not set, or JE - jump if zero flag is set) the jump was
typically to a NOP instruction. This could have been used as a placeholder for other
code as part of the development process, or may simply be used as a silent marker
used in debugging to indicate that the program is on the right path. Nevertheless it
gives 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 typical
conventions are not followed. This also includes areas of code that common
compilers would attempt to optimise and thus suggest a manual approach has been
taken.
Figure 5.2 shows an example where the INC (increment) function was used on
the ECX register to increase its value by 1 a total of four times. The purpose of
this particular action is explained further in Section 5.2.4, however this is clearly
not optimal. The use of an instruction such as ‘ADD ECX, 4’ would suffice.
Within the unpacking routine (described further in Section 5.2.4) the code
is unpacked four bytes (a DWORD) at a time. Whilst this is not a misuse of
instructions in itself, it is common to handle such a routine a single byte at a time.
CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 33
Reference to kERNeL32.Dll
An instruction pushed onto the stack was discovered to have an uncommon
naming convention. References to both kernel32.dll and KERNEL32.DLL (a base
Windows API) are common, however the peculiar capitalisation shown in Figure
5.3 is not. As a number of signature based virus detection tools may look for
references to kernel32.dll (or KERNEL32.dll) this could be a method used to evade
detection. In any case, this is again not a common coding practice.
As the goal of the exercise is obtain identifiable information from the program,
any invalid instructions can be bypassed or circumvented. Whilst this may seem
like valuable information is lost when the behaviour is not fully understood, it is
useful as a type of brute-force approach to get the program into a state where the
unpacking begins.
This particular invalid opcode can be bypassed by setting the EIP (the
instruction pointer) to the next line of code 00401050. In Immunity this can be
set 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 jump
is reached.
Figure 5.5 shows a JE instruction to the address 00401164, the code for which
can be seen in Figure 5.6. Again this code is invalid and causes the process to
terminate, therefore the jump at 004011DD must be bypassed. In Figure 5.5 the
top-right corner shows the Zero Flag is set - the Zero Flag is set to 1 if the result
of 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 is
taken’). To bypass this jump a breakpoint should be set, instructing the debugger
to await further instruction, and the Zero Flag set to 0. The condition for the JE
instruction will not be met and the jump will not be taken.
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 Graphs
function in Immunity provides a visualisation of the branches that the process can
take depending on whether the jump is taken or not. Figure 5.7 shows the path
taken in red if the jump is not taken (the current option) and in green if the jump is
taken. Immediately it is obvious that not taking the jump will result in termination
of the process, as the function kernel32.ExitProcess is called. Again the Zero
Flag must be modified and, this time, the jump is taken.
The final set of invalid instructions forms an infinite loop unless bypassed by
setting a new origin, as described above. The instruction at 00422891 calls a
function at address 0042298C (see Figure 5.8). Rather than ending with a RETN
CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 35
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 would
be performed instead of a more efficient instruction, such as ‘ADD ECX,4’. It is
possible that this is set to deal with timing issues or may simply be a sign of the
coder’s thought pattern. The result of this action is clear however, as the value of
ECX is used to set the memory address of the data to unpack (not shown). Thus
with 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 may
not be clear what this unpacked data represents. After several iterations a text
string 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 vital
clue, 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 for
Lighty Compressor, necessitating this manual approach.
Martyanov (2008) details some of the uses of Lighty Compressor as a packer in
a Live Journal blog on multiple occasions in reference to virus infections. In reply
to a comment placed by another poster, Martyanov explains that an unpacker could
not be found in the public domain but that a manual approach should be successful
once the line “Lighty Compressor” is stored in memory. This is in line with the
results seen so far.
CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 37
5.2.5 Identification
Allowing the unpacking routine to continue allows more data to be viewed in it’s
unpacked format. As this unpacked data resides in memory, taking a snapshot or
dump 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 for
further investigation, including the ability to generate a list of all the strings
identified in the process. These strings often provide further information about
the functions being called, file references and sometimes identifiable information
such as IP addresses, server names or usernames and passwords.
Figure 5.11 shows some of the strings that are particularly interesting, as they
reference files such as nvaux32.dll, aston.mt and dllcache\\user32.dll (a
non-standard location for the user32.dll file).
A logical next step is to research the files named by these strings and determine
whether they are referenced by any known and previously identified viruses.
Whilst viruses are typically seen in multiple different mutations and may behave
differently in different situations, this technique can be used to narrow down the
search significantly. Once common infections have been identified, the behaviour
CHAPTER 5. REVERSE ENGINEERING AND UNPACKING 38
Whilst the exact methods the worm uses to spread may differ slightly in this
particular incarnation, the following attack vectors are common to a Mariofev
infection:
5.3 Conclusions
The techniques presented in this chapter can be used in the future for dealing with
viruses that cannot be unpacked and identified by anti-virus software. It may not
be known that Lighty Compressor has been used to pack a piece of malware until
it’s protections have been bypassed, however the presence of artefacts presented in
Section 5.2.2 could suggest that Lighty Compressor has been used. Whether Lighty
Compressor has been used or not, the ‘brute force’ approach to reverse engineering
malware - forcing the code towards a state where the unpacking routine begins, can
lead to quick (if not complete) results.
The worm in this case has been packed with another file as a Trojan and
therefore requires user interaction to unleash it. Once unleashed however the worm
can spread without requiring any user interaction through the methods outline
above.
To determine whether the worm has been unleashed, a final scan of the log
files 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 with
grep and then examined for any matches with a list of known infected files. This
was performed on a subset of the log files starting from the time after which the
infected files were first uploaded to the server.
:˜$ grep RETR R ./ > retr
:˜$ for FILE in ‘cat infected_files.txt‘; do grep $FILE retr done
:˜$
In this case Victim has been fortunate - no successful downloads of the infected
files can be seen from the log files and the risk that this poses to Victim is now
significantly lower.
Chapter 6
Remedial Actions
40
CHAPTER 6. REMEDIAL ACTIONS 41
booting the machine into safe mode so that any infections cannot utilise advanced
anti-detection techniques. Furthermore, the FTP server should be treated as
compromised until it can be securely wiped and rebuilt using the latest stable and
secure software. This action will ensure that the known vulnerabilities associated
with the server are removed and that traces of any malicious software that may
have been installed on the server are removed.
Chapter 7
Conclusions
42
CHAPTER 7. CONCLUSIONS 43
Code
# http://digitalpbk.blogspot.com/2009/10/ftpchk3-virus-php-pl-hacked-website.html
use strict;
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;
close(FP);
open FP,"listofinfected2";
my $file;
while($file = <FP>){
44
APPENDIX A. CODE 45
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;
close(FP);
References
[2] 7Safe and ACPO. Good Practice Guide for Computer-Based Electronic
Evidence. 2007.
[5] S.K. Cha, I. Moraru, J. Jang, J. Truelove, D. Brumley, and D.G. Andersen.
SplitScreen: Enabling efficient, distributed malware detection. Proc. 7th
USENIX NSDI, San Jose, CA, 2010.
[8] Solar Eclipse. Honeynet Project Scan of the Month for April 2002, 2002.
http://www.phreedom.org/solar/honeynet/scan20/scan20.html.
46
REFERENCES 47
[20] A. One. Smashing the stack for fun and profit. Phrack magazine,
7(49):1996–11, 1996.
[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.
[27] M. Richard and M. Ligh. Making Fun of your Malware. In Defcon 17, 2009.
[30] Net Security. Workers stealing data for competitive edge, 2009.
http://www.net-security.org/secworld.php?id=8534.