Cybereason, USA
During 2018, we identified a series of attacks targeting telecommunication companies. The attacks shared the same TTPs, consisting of a webshell execution followed by the deployment of Poison Ivy, a well-known RAT attributed to Chinese APT groups. This was the beginning of the APT saga. The targeted companies are in the telecommunication industry, have a global spread, hundreds of millions of customers and thousands of employees. Like other telecommunication operators, some of these companies have also gone through several M&A processes (mergers and acquisitions), which inevitably affected their IT infrastructure.
In some of these companies, we have identified that the same threat actor – which we have been tracking since early 2018 – has been operating in the company’s environment for at least two years. The threat actor (like any well-organized R&D department, or organization) has a tasks Gantt for every quarter. We performed a retrospective analysis of the attacks we were able to identify, and found changes in the attack patterns and new activity every quarter.
Figure 1: Changes and new activity every quarter.
The initial indicator that ‘sparked our imagination’ was malicious activity performed by w3wp.exe, an IIS process, which was eventually classified as a webshell activity. By investigating the webshell (which was later classified as the ‘China Chopper’ [1, 2] webshell), we were able to unravel several attack phases and TTPs used by the attackers.
The attackers leveraged the webshell to run reconnaissance commands and credential-stealing activities.
Figure 2: Reconnaissance commands.
One of the reconnaissance actions was to run a modified NirSoft NetBIOS scanner in order to identify available NetBIOS name servers locally or over the network.
Figure 3: A modified NetBIOS scanner was run to identify available NetBIOS name servers.
The credential-stealing tool was a modified Mimikatz version, which, when executed, only dumps NTLM hashes (note that it does not require any command line arguments). We renamed this sample maybemimi.exe.
Figure 4: We reamed the modified Mimikatz version maybemimi.exe.
Reverse engineering shows the string similarity between maybemimi.exe and Mimikatz, as shown in Figures 5 and 6.
Figure 5: Mimikatz code from GitHub.
Figure 6: Maybemimi strings.
In mid-2018, while we were continuing to observe the attackers’ activities, we spotted new webshells emerging, as well as reconnaissance and credential-stealing activity. In addition, we uncovered the usage of PiVy (Poison Ivy) by the attackers.
Poison Ivy (or PiVy for short) is a RAT that is associated with Chinese threat actors. PiVy is a powerful, well-featured RAT that allows an attacker to take total control of a machine. Among its notable features are:
Figure 7: Poison Ivy control panel (courtesy of Sam Bowne – samsclass.info).
The strain of PiVy that we detected and investigated (and which also helped us to attribute those TTPs to the same attack group) is dropped by combining several methods:
The PiVy sample that we observed was running as a DLL that was loaded into the Samsung RunHelp.exe tool. This is another indicator that assisted us in attributing multiple attacks to the same threat actor. The method of using the NSIS installer in conjunction with the tool is not new and has been covered before by Palo Alto [3] (albeit with a different trojan).
Those findings, and more, led us to contact the attacked vendors and advise them on active containment actions that, later on, were put in place on an ad-hoc basis. We kept track in our research of the different TTPs of the threat actor, and there were no new indicators until the end of 2018. During that time, we detected interesting compressing activity carried out by the attackers in order to exfiltrate data. The attackers used WinRAR, which they downloaded from their C2 server, to compress the data they wanted to steal. By leveraging (another) webshell, and a renamed cmd.exe version, the attackers executed reconnaissance commands, collected data, dropped tools like portqry.exe and hTran, and performed lateral movement using net use and wmic.exe.
Figure 8: Reconnaissance commands.
Figure 9: Compressed stolen data.
One of the tools that the attackers deployed in order to exfiltrate the data from network segments that were not connected to the Internet was a customized version of hTran, a ‘connection bouncer’ tool which allows the attacker to redirect ports and connections between different networks. hTran’s code is publicly available on GitHub [4].
When we first executed the version of hTran that was dropped by the attackers, we noticed that the debug messages were a bit hard to understand (Figure 10). It was very obvious that this had been done deliberately to throw off researchers.
Figure 10: Difficult to understand debug messages.
However, since hTran’s source code is available, comparing the debug output to the code allowed us to determine that it was indeed a modified version of the tool, as shown in Figure 11.
Figure 11: Disassembly of the modified hTran.
In Figure 11, we can see a disassembly of the modified hTran. We can see that printf is being called (dubbed by us as ‘looks_like_printf’) and the output is ‘C e.’. However, when we look at the source code (Figure 12), we can see that this actually means ‘connect error’.
Figure 12: Connect error.
When you think of extensive breaches in large companies the first thing that comes to mind is usually payment data. A company that provides services to a large customer base has a lot of credit card data, bank account information, etc. on its systems. If such a malicious operation is conducted by a cybercrime group then the motive of the attackers, usually, is to go after that payment data since the end goal is to make money.
However, this case was different. When a nation-state-sponsored group attacks a large company, in most cases, the end goal is not financial but rather intellectual property or sensitive information and data about one (or more) of its clients, which is exactly what happened in this case.
As we mentioned before, the breached companies were in the telecommunications industry (or telco for short).
One of the most valuable pieces of data that telcos hold are CDRs – call detail records. CDRs are basically a large subset of metadata containing all the details about calls, for example:
Obtaining access to such data allows the threat actor to know more about the individual(s) they are targeting:
Figure 13: Example CDR data.
Figure 14: Details of CDR data.
As a result of that information, the different TTPs we identified, and the data that was stolen during this campaign, we were able to attribute those attacks to a nation-state threat actor.
When we research such a campaign, it is very important for us to manage all of our findings and ask very simple questions about them:
Our research started with one binary file and a single domain with which the file’s process has communicated. Our methodology is described in the next section.
At that point, we knew the following:
Webshells were used to execute multiple commands, both for reconnaissance and as well as for lateral movement and tool execution. We had the hashes of these tools and we also had a hostname to which all of the tools were connecting. We noticed that the attackers were using the same tools with minor changes (different names, string changes) across their campaigns, where all the payloads were connecting to the same IP address as the C2 server, albeit to a different hostname.
We started to try and make sense of everything by feeding all of that data into multiple threat intelligence sources that we have access to (both our own and third party).
Note: Since we cannot share any IoCs, we will refer to file hashes, hostnames, IP addresses and other IoCs as generic placeholders.
Hostname1 is the hostname that was used for the C2 server targeting the telco companies.
Figure 15: All files were contacting hostname1.
After analysing the files we saw that all of them were contacting the same host (hostname1), which was used as the C2 to which all of the malware and webshells were connecting.
Once we determined that all of the hashes in the scope of the attack were only connecting to hostname1, which is a dynamic DNS hostname, we wanted to see if we could find more information about the C2 server.
A simple WHOIS query revealed that the IP was registered to a colocation hosting company in Asia. There was no other publicly available information about this IP address.
We then started to query all of our threat intel resources about this IP address, and discovered that it was associated with multiple dynamic DNS hostnames.
Figure 16: The IP address was associated with multiple dynamic DNS hostnames.
When we looked for any signs of connections to Dynamic.DNS2 and Dynamic.DNS3 we could not find any. However, they were registered and they were associated with IP.Address1. It was then time to determine the purpose of the other dynamic DNS hosts.
By leveraging various threat intel repositories, we crafted queries that searched for executables with these IPs and hostnames in their string table. One of the queries returned a few DLLs, with identical names to the DLL that we had initially investigated. However, the hashes were different. We took those DLLs, patched them back into the NSIS installer and detonated these samples in our testing environment. Once they were detonated, we saw that the configuration code that was injected into nslookup.exe did not have IP addresses and domains that were related to the first company that we identified in our initial research, but instead contained domains that were related to a different telecommunication company. Naturally, we reached out to that company, alerted them, and gave them all of the necessary information.
Figure 17: Strings from the dumped memory section of the injected shellcode. We can see many details about the campaign including domains and C2 IPs.
Figure 18: Shellcode being unpacked and injected into a remote process. The redacted segments contain the name of the customer, C2 IPs and domains.
Figure 19: The threat actor’s modus operandi.
This pattern of behaviour allows us to understand the threat actor’s modus operandi.
The threat actor uses one server with the same IP address for multiple operations. This server is their ‘non-attributable’ infrastructure.
The separation between operations is performed via different hostnames per operation, albeit hosted on the same server and IP address. While this method may be cheap and efficient for the attackers, it is almost transparent for a well-seasoned researcher with access to the right threat intelligence tools.
In addition, monitoring this infrastructure allows us to know if the attackers are starting new campaigns, engaging in new activities, making changes, etc.
When researching C2 servers one should watch for:
This demonstrates the importance of proper operational security (OpSec) and proper separation between tools and operations on the threat actor’s side.
Throughout this investigation we have uncovered the complete infrastructure of the aforementioned malicious operations by this threat actor. We have observed a wide campaign against multiple telecommunication companies. The data exfiltrated by this actor, in conjunction with the TTPs used, allows us to determine with very high probability that the actor behind these malicious operations is backed by a nation state.
Due to multiple and various limitations we cannot include all of the information that we have on these attacks in this report. Our team will continue to monitor and track that malicious actor’s activity in order to find more tools and compromised companies.
This research, which is still ongoing, has been a huge effort for the entire Cybereason Nocturnus team. Special thanks go to Assaf Dahan, Noa Pinkas, Josh Trombley, Jakes Jansen, and every member of the Nocturnus team for the countless hours and effort that was put into this research. We will continue to monitor and update our blog with more information once available.
[1] China Chopper. MITRE ATT&CK. https://attack.mitre.org/software/S0020/.
[2] Lee, T.; Ahl, I.; Hanzlik, D. Breaking Down the China Chopper Web Shell – Part I. FireEye. August 2013. https://www.fireeye.com/blog/threat-research/2013/08/breaking-down-the-china-chopper-web-shell-part-i.html.
[3] Falcone, R. PlugX uses legitimate samsung application for dll side loading. Palo Alto. May 2015. https://unit42.paloaltonetworks.com/plugx-uses-legitimate-samsung-application-for-dll-side-loading/.
[4] hTran. https://github.com/HiwinCN/HTran.
