Introduction
In the ever-evolving landscape of cybersecurity, cyberattacks have become increasingly sophisticated and persistent. Once a hacker successfully breaches a target system, gaining unauthorized access is only the first step of their nefarious mission.
The true depth and impact of an intrusion are often realized during the post-exploitation phase, where attackers stealthily navigate through the compromised environment, escalate privileges, and maintain persistence to achieve their objectives.
Post-exploitation frameworks play a crucial role in this stage, empowering attackers to maintain control, gather sensitive information, and execute their malicious intent covertly. In this discussion, we will explore the concept of post-exploitation frameworks in cyberattacks, understanding their functionalities, and how defenders can strengthen their security posture to counter such advanced threats. By shedding light on these clandestine tools and tactics, we can better comprehend the importance of proactive defense measures in safeguarding digital assets from persistent adversaries.
Tool
In this blog post, SILENTTRINITY command-and-control (C2) post exploitation framework will be reviewed.
As per MITRE ATT&K Framework, SILENTTRINITY is an open-source remote administration and post-exploitation framework primarily written in Python that includes stagers written in PowerShell, C, and Boo.
According to recent reports, SILENTTRINITY has been used in intrusion campaigns by nation-state actors and cybercriminal groups. Mainly, the intrusion vector is spam emails masquerading as legitimate email where the emails would have a macro-laced attachment or malicious LNK files packed inside ISO files, which would contain SILENTTRINITY’s payload.
Most importantly, one of the most famous SILENTTRINITY‘s stagers (powershell_stageless) acts as a prime example of a fileless malware, as it does not make use of the user's hard drive instead, stores the primary malicious script in the RAM (Random Access Memory), usually into a PowerShell process. Then the injected code will connect to the attackers’ C&C (Command & Control) server for beaconing and communication.
The Attack
Once a system is compromised, the framework acts as a "Swiss Army knife" for attackers, offering a comprehensive suite of post-exploitation functionalities. It enables remote access to compromised systems, allowing attackers to move laterally, escalate privileges, and maintain persistent control, all while evading detection by traditional security measures.
Below diagram summarizes the intended actions on objectives by the attacker.
The attacker prefers a fileless approach where a PowerShell script (stager.ps1) is executed in the memory of the victim after being injected into the hidden PowerShell process. Accordingly, the attacker creates a malicious stager script.
It usually contains the C2 Callback URL, along with a Pre-Shared Key, to be used within the encryption procedure of the payload.
Once script is executed, it injects the victim’s memory with malicious code, which was originally compressed and encoded, for adding additional obfuscation, in an attempt to evade security controls applied.
The script could be easily decompressed and decoded on CyberChef to show its embedded plaintext Boolang hardcoded in the PowerShell script.
Preferred attack vector is to use malicious LNK files renamed to be with PDF extension then packed inside ISO file that is attached to a phishing email and sent to the victim. The victim downloads and mounts that ISO file.
When the victim clicks on the mounted file, a PowerShell invoke command is executed that triggers the download of SILENTTRINITY malicious PowerShell script that orchestrates the beacon and communication towards the C2 server.
Once the script is executed on the victim side, it beacons back to the C2 server every 5000 milliseconds (5 seconds) checking if any new job/task is requested by the C2 server to be executed. Beaconing interval of 5 seconds is the default value and could be easily configured with an additional option of adding a jitter value to circumvent any security device that is recognizing a beaconing pattern.
Usually in C2 post-exploitation frameworks, attackers can configure the attack server to listen for C2 beaconing and communication, on any desired port. As for SILENTTRINITY, the C2 server can be configured to listen on HTTP (TCP port 80) or HTTPS (TCP port 443). The listening port is easily configurable to other ports during listener setup on the C2 server side.
As for the listener protocol, HTTP protocol discloses the protocol headers in unencrypted plaintext form while HTTPS encrypts the protocol headers. It was observed that in both protocols, the payload is encrypted.
NetWitness Incident Response team analyzed the HTTP Listener profile, and it was concluded that the injected malicious payload on victim side communicates with HTTP GET/POST requests methods with the C2 attack server. The GET request headers are configured to fetch any pending jobs (tasks) assigned for the GUID of the victim, for execution and responding back with a POST request method for the respective output. The POST requests include a Job ID (10 alphanumeric random characters) that corresponds to the command (job) created on the C2 server.
Let’s go a bit deeper into the mechanism illustrated above.
Once the victim clicks on the LNK file (renamed to be with pdf extension), the malicious code is executed in memory, immediately spawning a network session, and trying to communicate with its defined C2, as illustrated in below figure.
Once the attacker gains an active beaconing from the victim, he executes multiple enumeration commands, which are passed as jobs to the victim side, for the sake of gaining more information about the infected machine.
Enumeration Commands executed by the attacker vary from netsessions, netshare, whoami, netstat, query session, net user, ipconfig, systeminfo, and tasklist. All commands executed and respective Job IDs are illustrated in below figures, as extracted from the C2 server.
Following the enumeration phase, the attacker conducted a network reconnaissance upon 2 target systems, leveraging the port scanner attack module embedded in SILENTTRINITY Framework.
In addition, the attacker showed interest in locally enumerating the contents of the user’s Documents folder, where an interesting folder called imp was discovered having a file named passwords.txt. The attacker decided to exfiltrate such file for the hope of gaining further access through saved up credentials.
SILENTTRINITY C2 includes built-in ready-made attack modules for credential harvesting purposes as below:
- Executing Mimikatz on the victim machine
- Dumping the SAM registry file and exfiltrating it in chunks to the C2 server then running Pypykatz for parsing it.
- Dumping SAM registry hive followed by its exfiltration to C2 server.
In this attack scenario, the attacker preferred the approach of dumping the SAM registry hive for later exfiltration.
After which, the attacker decided to expand his attack arsenal by moving pscp.exe (PuTTY Secure Copy Protocol) from the C2 server to the victim machine, so as to be utilized as an additional channel for files transfer and/or data exfiltration. The attacker renamed the moved pscp.exe to svchost.exe, resembling same naming convention of legitimate windows system process svchost.exe.
Attackers usually rely on renaming their transferred attack tools to evade any detection rule applied based on the naming convention of the executable files rather than files hash values.
On the victim side, svchost.exe (originally pscp.exe) is created under user’s Documents folder.
The attacker then decides to leverage the pscp.exe on the victim side to transfer another tool, NetScan.exe which is a tool for advanced network reconnaissance, from the C2 server to the victim’s Documents directory as in below figure extracted from the C2 server’s side.
Note
Multiple other attack modules are configured in SILENTTRINITY C2, including but not limited to, the following:
- Popping a UAC-like lure message box asking the victim to enter the Administrator password.
- Privilege escalation leveraging token impersonation technique.
Preamble to Hunting
From the network perspective, understanding how HTTP/HTTPS works, is crucial in detecting malicious C2 over such protocols. Analysts should analyze HTTP/HTTPS traffic generated by malware, and traffic over same protocols generated by users, this allows the analyst to quickly determine what is out of place in a data set vs. what seems to be normal. This is a common strategy among malware authors as they want to blend in with regular network communications and appear as innocuous as possible, but by their very nature, malicious files and trojans are programmatic and structured, and when examined, it becomes clear the communications hold no business value.
It is recommended to familiarize with the hunting guide as a starting point, for effective threat hunting activities.
In addition, from the endpoint perspective, analysts should familiarize themselves with the normal endpoint behavior within their organization’s workstation and servers. Then, baselining is a crucial step for pinpointing abnormalities detected by the EDR currently deployed.
For instance, if PowerShell is usually spawned to run scripts created by developers for business reasons, this should be baselined after proper verification. At this point, if PowerShell process was created to execute scripts from an abnormal directory path or to download external content, such behavior should stand out as suspicious endpoint behavior.
Also, Threat hunting is the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions. Hunting for post-exploitation C2 frameworks’ communication relies on identifying some anomalies, including but not limited to, the below.
- C2 Beacon Pattern.
> Frequent and repetitive network communication with external IP addresses having low variance with respect to the payload size. - Abnormal behavior by an endpoint process.
> Abnormal creation of new files/process by an endpoint process. - Tampering or dumping a registry hive.
- File transfer over standard/unusual protocols and port numbers, for exfiltrating sensitive data or downloading additional files.
- Lateral movement with the below conditions
> Leveraging access of newly created domain user accounts
> Leveraging access of user accounts that do not usually access target systems
> Leveraging access of user accounts during non-business hours
> Leveraging access of service accounts
It is up to the analysts to learn their environment dataset which is considered the biggest hidden Return on Investment (ROI). As a result, anomalies will be detected, and response efforts will be more accurate and in a timely manner. This also will lead to reducing the dwell time and identifying malicious communication based on behavior observed rather than depending on signature-based alerts triggered.
The Detection Using Packet Data
From NetWitness Packets (NWP) perspective and during frequent hunting activities performed, the analyst observed a possible port scanning detected as shown under the Behaviors of Compromise (boc) meta key.
The analyst carved the data for analyzing all related port scanning activities and found that they were all sourced from one machine which is not labeled as a scanner within the organization. This raised analyst’s concern that a network reconnaissance is conducted from this machine, and it might not be legitimate behavior. Specifically, scanned ports are noticed to be ranging from 0 to 1024 pointing to an automated machinery (tool) behavior conducting such scan.
NetWitness Packets makes it possible to pull apart characteristics of HTTP traffic through the Service Analysis meta key. The analyst notices some interesting meta values that can be leveraged to carve the dataset, when focusing the search with ip.src=192.168.157.160, which originated the port scan activity.
The values highlighted in Service Analysis point out to automated machinery behavior rather than normal user web browsing.
Through further data carving with one of the Analysis Service values, http 200 response no data, the analyst discovers multiple filenames associated with such communication, with a random naming convention comprised of 10 alphanumeric characters. Also, most of the communication was targeting destination IP address 192.168.157.130. This intrigues the analyst to dig deeper into such sessions for unfolding more evidence.
The analyst focused the investigations on the above subject machine and observed a beaconing-like behavior every 5 seconds where this endpoint communicates with IP address 192.168.157.130. It is worth nothing that neither of the IP addresses is of particular interest as they are only valid for this lab simulation.
The communication was based on HTTP protocol on port TCP 80 with a GET request crafted with a GUID value along with the word jobs, and session size of 895 bytes as in below figures.
This C2 beacon activity triggered multiple Service Analysis (analysis.service) meta values below which stood out as machine-based communication and do not resemble a human-driven normal web browsing communication.
Analysis.service = ‘http direct to ip request’,’ http1.1 low header count’,’ http1.1 without connection header’,’ http1.1 without accept header’,’ http1.1 without user-agent header’,’ http1.1 without referer header’,’ http single request’,’ http get no post’,’ http no referer’,’ http no user-agent’,’ http six or less headers’,’ http four or less headers’,’ http three headers’,’ http response status ends with space’,’ http content-length zero’,’ http1.1 without server header’,’ http1.1 without server header’,’ http 200 response no data’
The analyst performed appropriate data carving, focusing on communication between the subject machine and destination IP address and discovered a lot of HTTP traffic being exchanged. Raw packet analysis was performed on one of the events accompanied by an HTTP GET request, and a PowerShell script stager.ps1 was discovered to be downloaded and as highlighted in below figure.
Also, the content of that PowerShell script could be analyzed, as the file was transmitted through unencrypted cleartext HTTP.
The analyst downloaded stager.ps1 from the analyzed packet.
At this stage, the analyst could analyze the stager.ps1 script, that was previously tackled at the beginning of the Attack section. The analyst noticed that the script included hardcoded C2 Callback URL, along with base64 encoded content that has also been deflated, meaning more obfuscation was put in place.
This kind of obfuscation is usually adopted by attackers to evade any endpoint detection solution or antivirus deployed on the target network.
Also, Encryption settings and PSK (pre-shared key) are configured in the PowerShell script for encrypting communication between the C2 server and the victim machine.
Above discovered evidence suggest that the communication investigated is suspicious in nature and needs further analysis.
Circling back to the 10-character-alphanumeric-named files captured by NWP and associated with the communication between the possibly infected machine and the external IP.
The analyst focused the analysis to one of the events having the above-mentioned files attached and discovered a communication pattern, where the endpoint is usually sending GET request to the external IP address every 5 seconds (previously discovered beacon) and the associated response header would be 200 OK with no payload.
However, on some occasions, the response is having an encrypted payload which is the command passed from the C2 server.
Subsequently, the above event is directly followed by a POST HTTP method by the endpoint with a Job ID comprised of 10 alphanumeric random characters, which is associated to the output of previously communicated C2 command.
For instance, the figure below shows the output of Job ID v1u0ZkJjL9, which corresponds to command ipconfig triggered from C2 server side and illustrated previously in the Attack Section.
The analyst also observed the transfer of pscp.exe file to the victim machine, through an HTTP GET Request captured by NWP.
This finding confirms files are being transferred through the discovered suspicious communication which in return urges the analyst to further analyze this communication on a much deeper level from the network and endpoint perspectives.
The Detection Using Endpoint Tracking
The analyst, while performing his daily activity of perusing IOC's (Indicators of Compromise), BOC's (Behaviors of Compromise), and EOC's (Enables of Compromise), observes multiple BOC meta values that stand out, mostly pointing to leveraging PowerShell process and execution of enumeration activities.
The analyst analyzed each BOC values and started pulling the threads to get a more holistic view of the suspicious behaviors detected.
At first, a PowerShell script download event was observed, where cmd.exe spawned powershell.exe to download stager.ps1 (default naming convention for SILENTTRINITY C2 PowerShell script) from the C2 server.
Based on the process map, the analyst assumes that the user clicked on a file under the file explorer (explorer.exe) which spawned a cmd.exe that leveraged powershell.exe for downloading a PowerShell script stager.ps1 as in below figure.
Consequently, powershell.exe is observed performing an HTTP connection to download stager.ps1 from the C2 server then invoke it for execution.
Afterwards, the analyst could identify each enumeration command executed during the attack phase, with the source command line argument (param.src) populating the invoked PowerShell command that was originally used for downloading and executing stager.ps1 as in below figures.
Also, NetWitness endpoint process map illustrates the sequence of malicious events starting with PowerShell script stager.ps1 download and invoking (executing) such code followed by enumeration command line arguments passed to the victim machine.
The analyst analyzed one of the endpoint events, as below example showing spawned ipconfig.exe, and could identify that powershell.exe was orchestrating all the processes creation for the malicious enumeration purposes.
Focusing on endpoint events triggered by powershell.exe, the analyst could observe enumeration commands captured in the filename.dst meta key as in below figure.
Also, the analyst unfolded evidence suggesting that the attacker attempted to manually dump the SAM registry hive, using reg.exe, for later exfiltration and parsing. Such endpoint event is captured and triggered the below BOC meta value.
‘boc=exports sensitive registry hive’.
Afterwards, the analyst observed an endpoint event showing that powershell.exe process created file svchost.exe under the victim’s Documents directory, which is an unusual directory path if compared to legitimate svchost.exe usual directory path (C:\Windows\System32). Whereas the command line argument suggests that original transferred filename is pscp.exe as in the figure below.
That event was followed by another event suggesting the transfer of NetScan.exe file to the victim’s machine leveraging transfer capabilities of pscp.exe (fake svchost.exe). NetScan.exe was renamed on victim’s machine as rundll32.exe file, following the naming convention of legitimate Microsoft Windows rundll32.exe.
The analyst exported all command line arguments executed through powershell.exe being the source filename, and all above observations were summarized as in below figure.
Subsequently, the analyst investigated NWE’s “boc = evasive powershell used over network” and could identify a port scanning conducted leveraging powershell.exe on the victim machine targeting two (2) other machines as in the below figure.
Testing HTTPs Listener
While the above attack scenario was conducted utilizing HTTP as main communication protocol between the victim machine and C2 server, Listener protocol can be easily customized to be using HTTPS for the C2 communication.
Attackers might adopt HTTPS as the main listening protocol for the C2 communication for the sake of encrypting the whole malicious communication in an attempt to evade detection by network security controls which rely on deep packet inspection.
NetWitness Incident Response team analyzed HTTPS communication during research and discovered that default settings for such communication presented common schema of the SSL handshake to be having an SSL self-signed certificate “my company”.
This could help build up an application detection rule with the below condition:
analysis.service = ‘ssl certificate self-siged’ && ssl.subject = ‘my company’ && ssl.ca = ‘my company’
Detection
The NetWitness Incident Response team collaborated with the Product team and Threat Intelligence team to implement detection capability in HTTP and fingerprint_certificate LUA parsers based on the observed patterned behavior of SILENTTRINITY C2 framework.
|
IOC Value |
|
Silenttrinity beaconing |
|
Silenttrinity command |
|
Silenttrinity stager |
|
Silenttrinity default certificate |
Conclusion
The blog outlines detection methods for the default configuration of the SILENTTRINITY C2 framework. While the configuration can be easily changed as stated in the respective GitHub page and other online forums, the NetWitness Incident Response team has worked multiple cases where the default configurations for different attacker tools were found in the wild. With that being said, C2 frameworks still need to check-in, deploy their payload, and perform suspicious tasks on the endpoint. The analyst only needs to pick up on one of these activities to start pulling on a thread and unwinding the attacker’s activity.
Furthermore, it is important to note that while the HTTP protocol was used for C2 communication in this showcase, SILENTTRINITY C2 provides built-in encryption for its implants and payloads making it harder for analysts to understand specific threat actor operations on compromised systems. This makes it fundamentally important to also have an endpoint solution in place to keep track of the activities happening on endpoints.
