In August 2018, Group-IB published research (available in translated form here) regarding a financially-motivated group referred to by the community as Silence. Included in this report is the mention of a proxy tool that the group uses to route traffic to and from devices on an infected network that are normally isolated from the Internet.
Although the tool is simple (and in development), it has not yet been well-documented in the public space. This may partly be because the tool is relatively rare: Group-IB describes Silence as a small group performing a limited set of activities. For researchers to obtain a copy, the Silence proxy would have to be deployed post-compromise, identified during incident response, and uploaded online. Given the rarity, some notes on the .NET version of this tool are below as a reference to future analysts.
Technical Details
Files examined:
50565c4b80f41d2e7eb989cd24082aab (New)
8191dae4bdeda349bda38fd5791cb66f (Old)
The Silence proxy is written in .NET and known versions are packed with SmartAssembly. This can be unpacked automatically using a tool such as De4Dot to facilitate static analysis; however, this can lead to issues during debugging (with a tool such as DnSpy) that prevent the malware from properly executing. In the two known samples, the malware’s source code is readable even without this step.
The Silence proxy performs four basic tasks:
1) The malware reads and parses its configuration
2) The malware enters a switch/case statement based on a configuration value
3) The malware opens a connection to a specified C2, the type of which depends on task 2
4) (Optional) The malware can perform status logging (to a local location that varies by sample)
In the sample analyzed, the configuration specifies the following:
BackConnectServerIP – C2 server IP
BackConnectServerPort – C2 server port
ConfiguredAs – Type of connection (used in the Case/Switch statement)
DomainName – Used for NtlmAuth case
PortToListen – Listening port
ProxyIP – Endpoint IP
ProxyPort – Endpoint Port
UserName – Used for authentication cases
UserPassword – Used for authentication cases
From here, the tool passes the ConfiguredAs value into a Case/Switch statement that determines what type of connection to open. This routine is not fully implemented, and thus serves as an excellent example for malware that is “under development.” The first image below shows a portion of the Case/Switch statement with several cases that have not yet been populated with code. The second image below is from a “newer” sample. While there is still an empty case, the ProxyBackConnector case has been filled in.
In total, the tool supports (or likely will support) the following cases, which represent the functionality of the malware:
SocksServer – Act as a listener for network traffic
DirectBackConnector – Open a connection to a specified IP and accept the response
ProxyBackConnector – Open a connection to a specified IP and route the response to another device
ProxyBackConnectorWithAuth- Not implemented, likely intended as proxy + regular (non-domain) credentials
ProxyBackConnectorWithNtlmAuth – Proxy with an implementation to pass domain credentials
As mentioned at the start of the post, this is not a complex tool. Despite this, its appearance on the network should be cause for concern, as it is indicative of an adversary that is attempting to route traffic to and from a specific isolated device.