Threat Hunting a Telegram C2 Channel
Introduction
A novel C2 Channel leveraging Telegram’s API as a backdoor channel was recently discovered in the wild. Written in the Go programming language, the malware was first reported on February 4 by MalwareHunterTeam (@malwehunterteam) on X, who shared the hash after discovering the malicious backdoor and noted it had not been previously reported on VirusTotal. Following this initial discovery, Netskope Threat Labs published a detailed analysis on February 14, documenting the key behaviors and characteristics of the malware.
This article extends their excellent research by identifying practical detection opportunities for security teams. After recreating the malware and simulating an attack in a controlled environment, I uncovered several detection methods that threat hunters can implement.
The malware contains telltale flaws visible through common security tools, while its network communication patterns create distinctive signatures detectable through network monitoring. These detection strategies apply not only to this specific Telegram-based malware but also provide valuable insights for identifying similar masquerading techniques used by other malware families.
The Malware’s Core Behaviors
Before diving into detection strategies, let’s examine the malware’s three key behaviors which will inform our detection methods.
First, the malware performs an initial check before executing its main function. It verifies whether it’s running from “C:\Windows\Temp\svchost.exe”. If not, it copies itself to that location, launches the copy, and terminates the original process.
Second, once running from the correct location, the malware creates a new bot instance using NetBotAPIWithClient() from the Telegram’s API by leveraging an API token from Telegram’s BotFather feature. This allows it to use Telegram for communication, helping it blend in with legitimate traffic. The malware further benefits from Telegram’s end-to-end encryption and anonymity features, which help conceal the actual C2 server location.
Third, after establishing connection, the malware can execute various commands on the infected system, primarily using PowerShell.
Understanding these fundamental behaviors provides the foundation for developing effective detection strategies.
Why Do Malware Authors Favor svchost.exe?
Svchost.exe (Service Host) is a Windows system process that loads services from DLL files. It implements Windows’ shared service architecture, allowing multiple services to share a single process to conserve system resources.
Malware authors commonly disguise their malicious code as svchost.exe for two practical reasons:
- It’s an expected process that normally runs multiple instances on Windows systems, helping the malware blend in with legitimate activity.
- Svchost.exe typically has network connectivity, enabling backdoor communications without triggering network-based alerts.
Why The Temp Directory?
Having established why malware disguises itself as svchost.exe, let’s examine why it specifically targets the C:\Windows\Temp\ directory. This location offers several advantages for malware authors:
The Temp directory is writable by default, even with standard user permissions, allowing the malware to copy itself there without requiring administrative privileges.
This directory also typically contains numerous files from legitimate applications using it for temporary storage, making an executable there less immediately suspicious among the regular file activity.
The Process + Location Combination Don’t Make Sense
The malware’s disguise strategy contains a fundamental flaw: while both tactics make sense individually, they create an inconsistency when combined. Legitimate svchost.exe processes always run from C:\Windows\System32 (or C:\Windows\SysWOW64 on 64-bit systems for 32-bit processes). A svchost.exe process would never legitimately execute from C:\Windows\Temp.
This inconsistency creates a clear detection opportunity. Using a tool like System Informer (formerly Process Hacker 2), we can easily distinguish between legitimate svchost.exe instances (Image 1) and the malware version (Image 2) by examining the process path.
Image 1. File path for the legitimate svchost.exe image.
Image 2. File path for the malicious svchost.exe image.
Type of Process
Looking at the list of svchost.exe processes on the system reveals another immediate detection opportunity. In System Informer, legitimate svchost.exe instances appear highlighted in light or dark blue, while the malware instance stands out in yellow (Image 3).
Image 3. An overview of active instances of svchost.exe.
This color coding is significant because blue represents either Service Processes (light blue) or System Processes (dark blue) – exactly what we expect from legitimate svchost.exe instances. These different blue shades reflect the various security contexts under which Windows services operate. Additionally, all legitimate processes include the description “Host Process for Windows Services” since they’re launched by the Service Control Manager to host DLL-based services.
In contrast, the malware appears in yellow, indicating an “Own Process,” and lacks any description in the process list. This reveals that the malware was launched directly by a user or program rather than through Windows’ service architecture. This discrepancy clearly signals impersonation, as genuine svchost.exe processes are never designed to run independently of the service management system.
PPID Discrepancy
Another significant detection opportunity comes from examining the Parent Process ID (PPID) of the processes. As shown in Image 4, all legitimate svchost.exe instances share a PPID of 896, while the malware has a completely different PPID of 6380.
Image 4. We can see that the malicious svchost.exe is the only instance that does not have a PPID of 896.
The PPID represents the unique process ID of the parent process that created the current process. When we investigate any legitimate svchost.exe instance (Image 5), we discover that services.exe created it. This makes perfect sense because services.exe is a critical system process responsible for starting, stopping, and managing all Windows services, including svchost.exe. We would always expect services.exe to be the parent of svchost.exe, or occasionally wininit.exe during system startup.
Image 5. Legitimate instances of svchost.exe are usually spawned by services.exe.
Looking at the malware process (Image 6), we see something entirely different. Not only is the PPID different from legitimate instances, but the parent process is listed as “Non-existent process.” This indicates that the program that launched it is no longer running, which aligns with what we know about the malware’s behavior – after the original instance copied itself to the Temp directory and renamed itself, it terminated the original process.
Image 6. The malicious instance of svchost.exe was spawned by the original executable, and since it has since terminated it only appears as “Non-existent-process”. This parent process discrepancy creates another clear indicator that can help identify the malicious svchost.exe impersonator.
Certificate
One final critical difference between legitimate and malware processes involves digital certification. Comparing the process properties (Image 7), we can see that the legitimate svchost.exe is recognized as published by Microsoft, confirming its authenticity through a valid digital certificate.
Image 7. The legitimate process (top) possesses a certificate, while the malicious one (bottom) does not.
In contrast, the malware process is labeled “UNVERIFIED,” indicating it lacks any digital certificate to confirm its identity. This absence is telling since any genuine Microsoft application or process would invariably carry a proper digital certificate. A legitimate svchost.exe without Microsoft’s digital signature would never exist in a properly functioning Windows environment.
This certificate verification provides another straightforward detection method that clearly distinguishes between the authentic Windows service host and its malicious impersonator.
These findings demonstrate that simply renaming a malicious process to svchost.exe is a superficial disguise that might only deceive during casual observation. Upon closer examination, numerous red flags immediately become apparent to a trained observer or automated detection system.
Let’s continue our investigation in System Informer to examine the network activity associated with this process.
Network Activity
As noted earlier, malware authors favor impersonating svchost.exe partly because its outbound network connections raise fewer suspicions than if the malware disguised itself as a program like notepad.exe. However, examining the specific network behavior reveals more telling discrepancies.
When we double-click on the malicious svchost.exe instance and select the network tab (Image 8), we immediately observe a pattern familiar to those who investigate Command and Control (C2) infrastructure: consistent data transmission at regular 30-second intervals. This regular cadence typically indicates beaconing activity, where an agent periodically checks in with its C2 server for new instructions.
Image 8. Network activity for the malicious svchost.exe.
However since we know this malware maintains a persistent connection, given that agent response is immediate (Image 9), these consistent pulses most likely serve a different purpose. Rather than checking for new commands, these regular transmissions likely prevent the connection from timing out due to inactivity. Servers typically terminate idle connections after a threshold period to conserve resources, and thus to prevent this the agent will automatically communicate with the server following 30 seconds of idle time.
Image 9. The Derpness (server) issuing a command (/whoami), which is then immediately responded to by the orlok (the agent).
This pulsing pattern, whether for check-ins or connection maintenance, is distinctly abnormal for legitimate svchost.exe processes. After examining dozens of genuine svchost.exe instances with network activity, not a single one displayed this regular pattern. Instead, legitimate instances communicate in irregular bursts with variable timing between transmissions and differing payload sizes (Image 10).
Image 10. A “typical” network activity for a legitimate instance of svchost.exe displays irregular bursts of activity.
This consistent, metronome-like network activity provides another clear indicator that distinguishes the malicious process from legitimate Windows service hosts.
Process-Host Correlation
Since we’ve established that our malware process is communicating externally, let’s examine the Network tab in System Informer to identify the specific destination. Using the process ID (11080) to locate our malicious svchost.exe instance (Image 11), we can see it’s connecting to the IPv6 address 2001:67c:4e8f:f004::9.
Image 11. An overview of the host pair addresses associated with the malicious process.
While System Informer doesn’t provide additional context for this connection, this IPv6 address represents a critical piece of intelligence that we’ll leverage during our network-based threat hunting activities. The consistent communication with this specific external host creates another detection opportunity that we’ll explore further when we analyze network traffic patterns.
Sysmon Detection
Sysmon provides powerful detection capabilities for this malware, but requires proper configuration and effective query mechanisms to be useful. Without these, sifting through Event Viewer logs becomes overwhelming due to the sheer volume of data generated.
Since we know the malware runs as svchost.exe and executes commands (behavior atypical for legitimate svchost.exe processes), we can identify suspicious activity by looking for instances where svchost.exe spawns command-line utilities – see Image 12 below.
Image 12. A confirmation that this approach works, showing our malicious process (PPID 11080) running whoami.exe.
There are multiple detection opportunities when using Sysmon:
First, we can create rules that alert when svchost.exe spawns unexpected child processes like powershell.exe, cmd.exe, or whoami.exe – behavior that legitimate service host processes don’t exhibit.
Second, we can leverage our earlier findings about process anomalies to create targeted Sysmon rules. As shown in Image 13, we can detect svchost.exe running from non-standard locations (C:\Windows\Temp instead of C:\Windows\System32) or being spawned by unusual parent processes (not services.exe).
Image 13. Example rules that could be used for detection of this malware include seeing if it spawns an unusual process (top), or if it is running from a non-standard directory (bottom).
These detection strategies extend beyond this specific malware variant. The behavioral patterns we’ve identified represent suspicious activity in nearly any context and could identify various malware families using similar techniques.
While Sysmon offers numerous additional detection possibilities for this threat, our focus here is to simply highlight its potential as a detection tool. Let’s now shift our attention from endpoint detection to network-based detection opportunities.
RITA
Since we identified the target IP address during our endpoint analysis, we can use RITA to further investigate this connection (Image 14).
Image 14. RITA results for the malicious connection.
The RITA results confirm our earlier suspicions about the nature of this connection. The malware maintains a persistent connection with the server, active for 23 hours, 58 minutes, and 57 seconds out of a 24-hour monitoring period.
Based on this persistent connection and likely other behavioral indicators, RITA has classified this connection with a “High” Threat Severity rating. This classification serves as a clear signal that this particular connection warrants deeper investigation.
AC-Hunter
AC-Hunter confirms our findings from RITA regarding the persistent nature of the connection between the infected endpoint and the command and control server (Image 15).
Image 15. AC-Hunter results for the malicious connection.
This persistent connectivity pattern emerges as a reliable detection indicator regardless of the specific malware implementation details. Whether the malware employs novel endpoint techniques or sophisticated communication channels, the extended connection time between agent and server serves as a consistent and measurable network anomaly. The persistent connection pattern stands out in network traffic analysis tools like AC-Hunter, ensuring that even as malware evolves, this fundamental behavioral indicator remains detectable.
Threat Intelligence from IP Correlation
Our final detection method involves IP intelligence. Using IP2Location (Image 16), we can identify critical information about the destination host.
Image 16. Key details about the target server the malware has been in communication with.
The results confirm that the IP address belongs to “Telegram Messenger INC,” which perfectly aligns with our understanding that this malware exploits the Telegram API for command and control communication.
Whether a persistent connection to Telegram represents suspicious behavior ultimately depends on your specific network environment. In organizations where Telegram is authorized and serves legitimate business purposes, this connection might appear normal. However, in environments where Telegram lacks business justification or is explicitly prohibited, this persistent connection should immediately trigger further investigation.
This contextual awareness highlights the importance of understanding your network’s legitimate communication patterns. Even seemingly legitimate destinations can represent security threats when the connection patterns don’t align with organizational policies.
Conclusion
This article set out to extend existing research on a newly discovered C2 channel by identifying practical detection opportunities for security teams. By recreating the malware in a controlled environment, I’ve uncovered a handful of methods to detect this threat, both at the endpoint and network levels.
Endpoint analysis revealed several indicators that expose the malware’s impersonation attempts. As we repeatedly saw, the impersonation of svchost.exe is superficial, and displays numerous inconsistencies:
- The location discrepancy (running from C:\Windows\Temp instead of System32)
- Process type anomalies (appearing as an “Own Process” rather than a Service Process)
- Parent process irregularities (not spawned by services.exe)
- Missing digital certificate (lacking Microsoft’s verification)
- Abnormal child process behavior (spawning command-line utilities)
We can thus see that crude masquerading techniques contain inherent flaws that can be detected through intentional observation, as well as basic alerting using a tool such as Sysmon.
Network analysis highlighted the persistent nature of the malware’s connection, something we expected based on the real-time communication between the agent and server. This consistent connection, coupled with the regular transmission pattern to prevent connection timeouts differs significantly from legitimate svchost.exe network behavior.
And, as we’ve seen time and time again, RITA and AC-Hunter provide a universal, agnostic approach to identifying malicious communications. Regardless of the specific malware implementation, endpoint disguise, or communication channel innovations, the fundamental network behaviors remain consistently detectable. While some things change, others do not – and it’s detecting these constants where RITA and AC-Hunter excel.
This case study once again reinforces the values in combining endpoint and network-based detection approaches. By implementing the detection strategies outlined in this article, you can enhance your ability to identify and mitigate threats extending beyond this specific malware variant, keeping your network safe and secure.
Live long and prosper.
Faan
Faan has a profound love for the natural world, technology, design, and retro aesthetics. He is incredibly grateful to have discovered cybersecurity as a path relatively late in his life, and his main interests are threat hunting and post-exploitation custom tooling, in particular C2 frameworks and RATs.