MALWARE ANALYSIS

CTEC-3745D
BEBIN REGI
P270326
INDEX
PART 1

Question 1

Question 2

Question 3

Question 4

Question 5

PART 2

Question 1

Question 2

Question 3

Question 4

Question 5

Question 6
Part 1

Question 1

I used pdfid tool to analyse the pdf files

Figure 1: Analysis of cw_pdf_sample1.pdf

Based on the analysis of Sample 1 (file1.pdf), the following observations were made:

 Objects Extraction: the file contains 86 objects

 PDF Versions: The file is using PDF version 1.4
 Encryption: No encryption
 JavaScript Analysis: The file does not contain any JavaScript code, which is
a common vector for malicious PDF files.
 PDFiD Analysis: The analysis using pdfid did not reveal any suspicious
elements, such as shellcodes, JavaScript, or embedded files.

Based on the findings above, Sample 1 (file1.pdf) does not appear to be a malicious
PDF document.
Figure 2: Analysis of cw_pdf_sample2.pdf

I have analysed the cw_pdf_sample2.pdf file using the PDF tool in a REMnux
environment. Here are my findings:

 PDF Header: The PDF header is %PDF-1.6, which indicates that the file is a
PDF document conforming to the PDF 1.6 specification.
 Objects: The file contains various objects, including streams and cross-
reference tables. The number of objects is 146.
 Encryption: The file is not encrypted, as indicated by the /Encrypt 0 line.
 JavaScript: The file contains JavaScript, as indicated by the /JS, /AA,
and /JavaScript lines. This could be a potential indicator of malicious activity,
as JavaScript in PDF files can be used to exploit vulnerabilities.
 OpenAction: The file has an OpenAction, which is an action
that is executed when the document is opened. This could also be a potential
indicator of malicious activity.
  AcroForm: The file contains an AcroForm, which is a PDF form. This is not
necessarily an indicator of malicious activity, but it is worth noting.
 Launch: The file contains a Launch action, which is an action that launches
an application or a document. This could be a potential indicator of malicious
activity.
 EmbeddedFile: The file contains an embedded file. This could be a potential
indicator of malicious activity, as embedded files can be used to hide
malware.
 XFA: The file contains XFA (XML Forms Architecture), which is a format for
representing forms in PDF documents. This is not necessarily an indicator of
malicious activity, but it is worth noting.
 Colours: The file contains colours that exceed 2^24, which is the maximum
number of colours that can be represented by a 24-bit colour system. This is
not necessarily an indicator of malicious activity, but it is worth noting.

Based on these findings, cw_pdf_sample2.pdf may be a malicious PDF document.

Next I used `peepdf` tool to analyse the PDF files.

Figure: 3 Analysis of sample 1 on peepdf

Analysing Figure 2 shows that the file size is 139,996 bytes and contains 85 objects
and 50 streams. It is in linearized and binary format without any errors or comments.
Figure 4: Analysis of sample 2 on peepdf

Upon reviewing the embedded content of Sample 2, I came across an embedded file
within object 144, which was believed to contain JavaScript code as indicated by the
peepdf output. To analyse this content, we made use of the pdf-parser tool to extract
and decode the embedded file's raw data.

Next, I used `pdf-parser`

Figure 5: Analysis of sample 2 on `pdf-parser`

The peepdf tool analysis of cw_pdf_sample2.pdf in Figure 5 reveals the following

information:
  Size: 149387 bytes
 Version: 1.6
 Binary: False
 Linearized: True
 Total objects: 146
 Objects with errors: 1 (object 144)
 Streams: 55
 Suspicious Elements:
 AcroForm objects: 2 (objects 8 and 144)
 XFA object: 1 (object 144)
 AA objects: 2 (objects 11 and 48)
 JavaScript code: 2 (objects 141 and 142)
 EmbeddedFiles object: 1 (object 8)
 EmbeddedFile object: 1 (object 144)

Overall, the analysis suggests that cw_pdf_sample2.pdf is a potentially malicious

PDF file, due to the presence of suspicious elements such as JavaScript code,
AcroForm and XFA objects, and embedded files.

Question 2

a) Verifying file type with PEiD

Figure 7: Verifying file type

Figure 7 shows that the entropy of the packed file is 7.98. Entropy measures the
randomness in information and packed files typically exhibit higher entropy than
unpacked files.

b) Unpacking the File using UPX

The UPX tool was used to conduct the unpacking process with the following
command.
Figure 8: Unpacking the file as ‘unpacked.exe’
Figure 9: Unpacked file

It was confirmed that the "unknown.file" was packed after using the PEid tool to
analyse it. The UPX tool was utilized to unpack the file, which allowed its original
contents to be revealed. This process enabled a more comprehensive analysis of the
file's functionalities and any potential security implications.

Question 3

Static analysis on unknown.file

Figure 10: Identifying type of packing

Figure 10 shows that the "unknown.file" seems to be compressed with UPX, based
on the characteristics of its UPX0 and UPX1 sections in PEid. According to the
virtual size of UPX0, which is 001C000, the packed sections appear to have a
compressed size.

Interesting strings found while analysing the file

Figure 11: String 1

The string "This program cannot be run in DOS mode" is frequently present in
Windows executable files, which confirms that they belong to the valid PE file format.

Figure 12: XML string

In Figure 12 It is possible that the use of a string of XML elements, resembling a
manifest file, indicates the utilization of the Windows manifest in defining application
settings, privileges, and execution level. The execution level specified in this context
conveys information regarding the program's requirements for elevated permissions
and its behaviour across various versions of Windows.

Question 4

Figure 13: Regshot

As shown in Figure 13 I captured the registry and file system using RegShot prior to
running the file. As recommended in the hint, I configured the scan directory to 'C:\'.
Figure 14: Regshot output

According to the Figure 14, four specific registry values were modified between the
first and second snapshots taken by the tool. The key points are as follows: - Only
one value was added. - Four registry values were modified, leading to a total of two
changes. - The modifications suggest targeted alterations rather than additions or
deletions of new registry entries. - One file was added, and one file was modified.

Figure 15: Regshot output

Regshot's report while browsing shows that "unknown.file" execution resulted in
substantial modifications to the system registry. There were 23 existing registry
values modified, suggesting that it might be performing various system-level actions,
such as configuration changes, permission modifications, or component installation.
Furthermore, adding new values could suggest attempts to establish persistence or
introduce new functionalities.

Figure 16: Process Monitor Log

Figure 16 shows Suspicious Strings: "hxxp://" or obfuscated URLs, which could

indicate the file is trying to download malicious content.

- Encoding Detection: Signs of encoding may suggest obfuscated code or data.

- Packing Mentions: Strings related to specific packers (e.g., UPX) may indicate
compressed or obfuscated packing.
Question 5

a) System connected to Internet.

Figure 16: Wireshark data

From Figure 16 we see that the malware is communicating using TCP to a remote
server.

a) The destination port, 8080, is frequently utilized for internet traffic.

b) The malware is contacting the remote server via HTTP requests.

c) The HTTP request header's User-Agent string reads "Mozilla/5.0 (Windows NT

10.0; Win64; x64) AppleWebKit/537.36." Although web browsers frequently use this
User-Agent string, malware also frequently uses it to pass off its activity as authentic
online traffic.

d) Data sent to a server is frequently sent via the "POST" HTTP request mechanism.

e) A significant quantity of data is being sent by the malware in the HTTP request
body.
f) An HTTP status code of 200, indicating a successful request, is being returned by
the server.

These findings suggest that the virus is probably interacting with a command and
control (C&C) server to obtain directives or steal information. Malware frequently
uses HTTP as a communication channel to avoid detection and look like regular
network activity.

b) Isolated environment

Figure 17: Wireshark in isolated environment

The Isass.exe process seems to be trying to establish a connection on port 9001 to a

local IP address. The process is trying to interact with itself or another service that is
executing on the same computer because this is a loopback connection.

The process may be attempting to communicate with a service or component that is

not a part of the normal Windows operating system, as evidenced by the connection
being made to a non-standard port and a local IP address. It is plausible that the
process is making an effort to establish communication with a service that is hidden
or that malware has installed.
PART 2

Question 1

Figure 18: Extracting File

After extraction of the DLL files, we got different files.

Figure 19: Analysing in Resource Hacker

We can see that the software needs to be run under WIN32 in the RCData. This
could be a warning sign because malware that targets 32-bit systems may target
older systems in particular because of possible holes in their security. It's possible
that the Win32 requirement was added on purpose to evade detection on more
recent 64-bit systems with stronger security measures.

After further analysis in the Resource Hacker tool, I found that there are various
strings in the DLL.
Figure 20: Strings in the DLL file

Some strings suggest the program can be malicious even though it seems legit.

Question 2

Figure 21: Analysing the file with PEiD

After checking Figure 21, we see that the file is not packed. We also find that the
entropy value of the DLL file is 6.31.
Figure 22: Date of creation

Figure 22 shows the creation date is February 7,2018 on a Wednesday.

Figure 23: Capture of system activity

Figure 23 displays a capture of system activity, which can be helpful for analysing
what a program does when it runs.
Time (MS): This column shows the time elapsed in milliseconds since Process
Monitor started capturing events.

Operation: This column indicates the type of operation that was performed. Common
operations include reads, writes, deletes, and various file system and registry access
actions.

Result: This column shows the outcome of the operation. Success is typically
indicated by "SUCCESS," while errors might have specific error codes.

Path: This column shows the path to the file or registry key that the operation
interacted with.

Process Name: This column shows the name of the process that initiated the
operation.

Registry Access: The program seems to be accessing the registry, potentially

reading, or modifying values. This isn't necessarily malicious, as many programs
interact with the registry for configuration purposes.

File System Activity: The program appears to be reading and writing files in various
locations, including the user directory ("C:\Users\username") and the Windows
system directory ("C:\Windows\System32"). File access can be a legitimate activity
for many programs, but it can also be a sign of malware if unexpected locations are
being accessed or modified.

From the FileAlyzer tool we find the different DLL files in the SVCcDLL File.
Figure 24: 101 DLL files are imported from the host DLL.

Figure 25: Exported file

DLL files don’t contain exported files, they contain exported functions and other
resources.

Question 3

Figure 26: Log of repeated registry access

Repeated registry access: The log shows repeated access to the same registry keys,
which might indicate that the system is trying to hide or modify certain settings.

Buffer overflow errors: The log shows several BUFFER OVERFL errors, which might
indicate an attempt to overflow the buffer and execute arbitrary code.

Access to sensitive registry keys: The log shows access to sensitive registry keys,
such as HKLM\SECURITY\Policy\SecDesc, which might indicate an attempt to
modify security settings.

Unknown process: The log shows activity from the Isass.exe process, which is a
legitimate Windows process. However, if this process is not expected to be running
or is performing suspicious activities, it might indicate malicious behaviour.

These findings lead us to the conclusion that the DLL file established a network
connection with a distant IP address to send and receive data. This behaviour makes
sense for a malicious DLL that might be corresponding with a command and control
(C&C) server in order to obtain more directives or steal information.

Figure 24: Regshot comparison

Figure 24 shows that 1 value is modified after the regshot comparison.

Question 4

To ensure a secure virtual network analysis environment that captures potential

network behavior from malware, please follow these steps:

First, initiate a virtual machine (VM) by means of virtualization software.

Next, install a network sniffer tool such as Wireshark.

After that, configure the VM to utilize a virtual network adapter that is linked to a
virtual network switch.

Then, connect the virtual network switch to a physical network adapter on the host
machine.

Following that, adjust the host machine's firewall settings to prevent all incoming and
outgoing traffic to the VM, except for the traffic required for analysis.

Transfer the malicious DLL file to the VM by using a secure method like SFTP or
SCP.

Finally, execute the malicious DLL file on the VM and track its network activity using
the network sniffer tool.

Source and Destination IP Addresses: The source and destination IP addresses are
shown for each frame.

Figure 25: Wireshark analysis

The IP addresses involved are:

94.206.5.16

10.0.2.15

204.79.197.200
Protocols: The protocols used in the communication are:

TCP (Transmission Control Protocol)

HTTP (Hypertext Transfer Protocol)

SSLv2 (Secure Sockets Layer version 2)

The use of SSLv2, which is an outdated and insecure version of the SSL protocol.
SSLv2 has been deprecated for many years and is no longer considered secure.

The presence of an "RST, ACK" packet, which is a TCP reset packet. This could
indicate that a connection was terminated unexpectedly, which could be a sign of a
network issue or a malicious activity.

The use of the "GET /fileassoc/0409/xml/redir.asp?Ext=da" HTTP request, which is a

request to download a file. Without more context, it's not possible to determine if this
request is legitimate or malicious.

This research suggests that the DLL is using the TCP protocol, SSLv2 protocol,
HTTP and HTTPS requests, and other network-based operations. Additionally, the
DLL sends and receives a variety of network packets, including and ACK packets.
The DLL's efforts to connect to different IP addresses and ports can be a sign of
malicious activity, including looking for weak systems or trying to steal data.
Question 5

a)

These are the 2 DLL export functions.

b) The address of the 2 functions is 00410AC and 0041128C.

c)

The LoadLibrary method from kernel32 is called by just one function.

d)

Sleep is called by just two functions in kernel32.

6) After further analysis, Service main function was not found in the sample.