Reverse Engineering & Malware Analysis
Project Report
Development & Analysis by:
K039-Krishika Jain
K053-Pranav Singh
K058-Rumit Amonkar
B.Tech Computer Science & Engineering Cybersecurity
Under Guidance Of:
Prof. Dhanashree Kulkarni
1
Index
S. No. Section Title
1. Malware Development
Type of Malware Created
Purpose
Techniques Used
Execution Flow
Challenges Faced in Development
Code Snippet (SoftwareUpdate.py)
Output Received
2. Reverse Engineering Overview
Description
Submitted Files
File Structure
YARA Rules
Analysis
Mitigation Strategies
Indicators of Compromise (IOCs)
3. Links
4. Document FAQ
2
Malware Development
Type of malware created:
This data-stealing malware targets a file named private on the victim’s
Desktop (Kali VM). Once executed, it:
1. Encrypts the file using a fixed key (133) to prevent access.
2. Sends the encrypted file (private.enc) to the attacker’s email via SMTP.
3. Is delivered as a .exe via social engineering (email) and runs
automatically when downloaded.
Purpose:
The primary objective of the malware is to simulate a real-world data
exfiltration attack for academic and research purposes. It demonstrates how an
attacker can target a specific file on a victim’s machine, encrypt it to prevent
further access, and exfiltrate the stolen data through email. The malware is
designed to operate stealthily, minimizing user awareness and avoiding
detection. It is delivered via a social engineering technique, where the victim
unknowingly downloads and executes the malware disguised as a legitimate
file. This helps in understanding how attackers exploit human behaviour in
addition to system vulnerabilities. The project showcases key cybersecurity
concepts like file encryption, email-based exfiltration, and stealth operations. It
also highlights the importance of secure email practices, endpoint protection,
and user awareness in preventing such attacks.
Techniques Used:
1. Social Engineering (Phishing Email):
The malware is shared through a convincing email, encouraging the
victim to download and run the file, simulating a phishing attack.
2. Targeted File Access:
It is programmed to search for and access a specific file named private
located on the victim’s Desktop.
3. Symmetric Encryption:
Once accessed, the file is encrypted using a predefined key (133) via a
symmetric encryption algorithm to prevent the victim from reading the
data.
3
4. Email-Based Exfiltration:
The encrypted file is sent directly to the attacker’s email using Python's
smtplib for exfiltration without needing any external server.
5. Silent Execution:
The malware runs automatically when the victim downloads the
executable file, with no need for user interaction, mimicking real-world
stealth attacks.
6. Self-Contained Payload:
All functionalities—from encryption to sending—are built into a single
Python script compiled into an .exe, allowing smooth execution on the
target machine.
Execution Flow
Malware Delivery:
The attacker sends a phishing email with the malware attached as an .exe file to
the target's Gmail account.
Download & Auto Execution:
The victim (target) downloads the .exe file. Upon downloading, the malware is
executed automatically without requiring user interaction.
File Location:
The malware searches for the file named private located on the Desktop of the
target system.
Encryption:
If the file is found, the malware encrypts its contents using a symmetric key
(133) to prevent the victim from reading it.
Exfiltration:
The encrypted file (private.enc) is then sent via email from the victim’s machine
to the attacker’s email address using Python’s email-sending libraries.
End of Execution:
The malware completes its task silently without displaying any message or
notification to the user.
Challenges Faced in Development:
• Handling SMTP authentication securely for email-based file exfiltration
without exposing sensitive credentials.
4
• Converting the Python script into a .exe file that executes silently and
avoids detection by users or security tools.
• Facing issues while sending the .exe file via email, as email providers
flagged or blocked it due to its malicious nature.
• As a workaround, the Python file was shared instead for demonstration
purposes and had to be executed manually.
• Managing cross-platform compatibility between the attacker machine
(Windows) and the target machine (Kali Linux).
• Ensuring the stolen file was properly encrypted and then deleted from the
target system without leaving traces.
5
Code Snippet (SoftwareUpdate.py)
Output Received:
6
Reverse Engineering
Description:
This report presents an in-depth analysis of a malicious executable file using
static and dynamic analysis methods. The malware under investigation is
designed to exfiltrate sensitive information from the victim machine using a
stealthy payload, executed through social engineering techniques. The
executable was analysed using tools like Virus Total, IDA, and PEStudio.
Submitted Files:
Filename Description
SoftwareUpdate.exe Payload executable for analysis
Report.docx Original documentation of findings
File Structure
Type of file: Application (.exe)
7
• Indicates this is a Windows executable file, meaning it can run as a
program.
Description: SoftwareUpdate(obfuscated)
• A user-defined description, likely set during or after the build using tools
like PyInstaller or Resource Hacker.
Size Details
• Size: 14.7 KB (15,070 bytes)
o Actual size of the file on disk.
• Size on disk: 16.0 KB (16,384 bytes)
Timestamps
• Created: 07 April 2025, 13:31:10
• Modified: 07 April 2025, 13:31:11
• Accessed: 08 April 2025, 08:17:36
Yara Rules
A YARA rule is a pattern-matching rule used to identify and classify malware
based on textual, binary, or structural signatures. It helps detect malicious files
by defining specific strings, conditions, or behaviours commonly found in
malware.
Analysis:
We tried de-obfuscating the code, but de-obfuscation wasn’t happening:
8
Virus Total:
Detection Tags Explanation:
Engine Detection What it means
DeepInstinct MALICIOUS Confident detection; it's
flagged as malware
outright.
Elastic Malicious (high Confidence) Their AI-based model is
very confident that this is
harmful.
ESET- Python/Packed.Agent.E It looks like a packed
NOD32 Suspicious (compressed/encrypted)
malware made with
Python.
SentinelOne Static AI - Suspicious PE Their ML model finds the
(Static ML) Portable Executable (PE)
suspicious by structure.
SecureAge Malicious Generic malicious flag.
9
Skyhigh BehavesLike.Win64.Agent.tc It behaves like a Win64
(SWG) malware agent – i.e.,
drops files, connects out.
• It’s likely obfuscated or packed to avoid detection.
• It may have been written in Python, then compiled into an EXE (possibly
using PyInstaller).
• It's flagged not just for its contents, but also for its behaviour (e.g.
accessing network, modifying system settings, etc.).
PEStudio:
10
Imports (flag = 28)
Found in: imports (flag = 28)
This section shows Windows API functions the executable uses. Malware often
uses suspicious or dangerous functions, and here are a few critical ones found:
Function What It Does Why It’s Suspicious
ReadProcessMemory Reads memory of Used in process
another process injection
LoadLibraryExW + Dynamically loads Hides true functionality
GetProcAddress and calls functions
GetProcessHeap, Allocates memory Typical for unpacking
HeapAlloc shellcode
CreateSymbolicLinkW Creates symbolic Can be abused for
links privilege escalation
ShowWindow, GUI control Might simulate a fake
DestroyWindow UI or distract the user
GetModuleFileNameW Gets the file's path Common in self-
copying or hiding
behaviour
These imports strongly suggest the file might be:
11
• A loader (used to run other malware),
• An injector (injects malicious code into other processes),
• Or even a dropper (drops and installs more malware).
Using PEStudio, we analysed the executable file softwareupdate.exe and
observed critical details related to its overlay — the data appended beyond the
standard Portable Executable (PE) format.
Key Observations:
1. Signature:
o Status: Unknown (Unsigned)
o Implication: The file lacks a valid digital certificate. This is a
strong indicator of a potentially malicious or suspicious executable,
as legitimate software is usually signed to ensure integrity and
authenticity.
2. Overlay Entropy:
o Value: 7.999 (near maximum)
o Implication: High entropy suggests the data is encrypted or
compressed, commonly used by malware to evade detection and
hinder analysis.
3. Overlay Location and Size:
o Start Address: 0x00051600
o End Address: 0x001A5388
12
o Size: ~1.39 MB (1,392,008 bytes)
o Implication: A large overlay size indicates a significant amount of
hidden or obfuscated data, which is highly suspicious. Such
overlays may contain embedded payloads, shellcode, or
configuration files used by malware post-execution.
4. File Ratio:
o Value: 80.68%
o Implication: More than 80% of the file consists of overlay data.
This disproportionate ratio further suggests that the main
functionality of the file may lie outside the standard executable
sections, a common trait in obfuscated malware.
5. Hex and Text View (First 32 Bytes):
o Hex Start: 78 DA
o Implication: These bytes indicate the use of compression, a known
technique for packing payloads in malicious software.
The overlay characteristics of this file — including its large size, high entropy,
missing digital signature, and compressed format — strongly indicate that the
executable is packed or obfuscated. It likely contains a hidden or encrypted
payload, which could be unpacked and executed at runtime.
IDA:
13
It contains:
• Memory assignments to an address stored in off_14002DD60
• A jump (jmp) to sub_140002B80 (this is the payload function)
The red block (sub_140002B80) indicates a direct jump without any
conditional checks — classic behavior for payload execution after basic
setup.
The executable does not perform much in main() except store values and
redirect execution.
The real logic is hidden in sub_140002B80 — this is likely where:
• Files are read/written
• Network calls are made
• Sensitive data is collected
• Anti-analysis or evasion logic might exist
Key Observations:
1. Heavy use of E8 opcodes
• E8 is the opcode for CALL instructions.
• You're seeing a ton of calls — this suggests a chain of function calls
possibly:
o Setting up strings
14
o Writing files
o Stealing or modifying data
o Connecting to a C2 server
2. Presence of swprintf and swprintf_0
• This is commonly used to:
o Format Unicode strings (e.g., file paths, data blobs)
o Build logs or command strings
o Obfuscate filenames or commands
• Indicates the malware might be crafting file paths or building messages.
3. Multiple subroutines like sub_7FF6CB1810XX
• These are auto-generated function names, likely unresolved by IDA.
• The malware probably uses custom routines rather than standard API
calls to evade detection.
4. Exit Code 1 in Debugger Output
• It terminated intentionally with exit code 1, which is not a crash.
• Suggests that the malware executed something and then quit. It may have:
o Stolen data and deleted itself
o Dumped something to disk and exited
o Failed a condition (like anti-VM or anti-debug)
Mitigation Strategies
1. Prevention
• Email Filtering: Implement advanced email filters to block phishing
attempts and executable attachments.
• Application Whitelisting: Only allow trusted applications to run,
preventing unknown executables.
• User Education: Regularly train users to recognize phishing emails and
avoid downloading suspicious files.
• Endpoint Protection: Use antivirus and endpoint security software with
real-time protection.
15
• Least Privilege Principle: Limit user permissions to prevent unauthorized
file access or deletion.
3. Detection
• YARA Rules & Signature-Based Detection: Use custom YARA rules to
scan for known malware patterns like encryption, file deletion, and SMTP
usage.
• Email Gateway Monitoring: Monitor outbound and inbound emails for
suspicious attachments or unusual patterns.
• File Integrity Monitoring: Track sensitive file changes (e.g., encryption or
deletion of important files).
• Anomaly-Based Monitoring: Detect unusual user behavior, such as
sudden data exfiltration or access to critical files.
3. Response
• Immediate Isolation: Disconnect infected systems from the network to
prevent further data exfiltration.
• Incident Response Plan: Have a predefined response plan outlining roles,
communication flow, and containment steps.
• Forensic Analysis: Analyze the malware behavior to understand the entry
point, propagation, and data stolen.
• Notification & Reporting: Notify stakeholders and report incidents to
appropriate authorities if needed.
• System Recovery: Restore encrypted or deleted files from secure backups
after ensuring the malware is fully removed.
Indicators of Compromise (IOCs)
File-Based IOCs
• Presence of suspicious executable file (SoftwareUpdate.exe)
• Creation of encrypted file: private.enc in system folders (e.g., Desktop,
Public folder)
Process/Behavioural IOCs
• Execution of unknown or unsigned EXE or Python script by user
• Launch of smtplib process or access to system email resources without
user interaction
• Usage of cryptography libraries (e.g., Fernet) for unexpected encryption
Email IOCs
16
• Phishing email with suspicious subject line (e.g., "Urgent: Confidential
Report Attached")
• No file extension warning (disguised .exe or .py as a document)
Links
GitHub: https://github.com/kri794/DataStealing_Malware
FILE DELIVERY VIA EMAIL
We created a self extracting archive for the delivery of the file to the victim as any
mail server flags compressed files and exe files as unsafe.
WE USED 7ZIP FOR THE CREATION OF THE ARCHIVE
17
THE PAYLOAD CREATED WAS IN THE FORM OF AN APPLICATION
he mail was then delivered to the client via gmail :
AS SOON AS THE VICTIM OPENS THE ATTACHMENT, IT
EXECUTES ITSELF WITHOUT ANY USER INTERACTION
This hides the
attachment from being flagged as unsafe.
18
Document FAQ:
Q1. What was the purpose of this analysis?
To understand how the malware operates, what files it interacts with, and how it
exfiltrates data.
Q2. What tools were used?
IDA (Free version), PEStudio, VirusTotal.
Q3. What is the risk level?
High. The malware includes stealth, obfuscation, and likely data theft
capabilities.
Q4. What’s the origin of the malware?
It was embedded in an exe file and delivered via social engineering (e.g., email
attachment).
Q5. What are immediate next steps?
Isolate any affected systems, block related indicators, and conduct full forensic
analysis.
19
