Incidents involving ransomware are becoming more prevalent and can devastate an underprepared organization. What is most alarming is that ransomware variants are increasingly easier to obtain and deploy by not only criminal syndicates, but anyone with the means and desire to purchase.
In the community we have seen rapid development of ransomware with many of the more robust variants becoming more and more difficult to circumvent. Thankfully, many practitioners and researchers have come together to assist ransomware victims in recovering their data. While it is good to see open-sourced solutions available to mitigate ransomware and help victims recover their data, criminals that develop ransomware can easily sidestep identified recovery techniques and deploy a more advanced version.
Not too long ago, ransomware attacks primarily targeted individuals (the Steam ransomware attacks come to mind). Many individual victims did not have the means or desire to pay the ransom, which directly impacted criminal profit. Within the past year we have seen not only an uptick of those exposed to ransomware, but honed targeting more directed at businesses (those with the means and desire to pay).
Two fairly publicized attacks involve Hollywood Presbyterian Hospital and a school system in South Carolina. In both cases, these organizations were underprepared to perform data recovery in-house and business leaders decided their only option was to pay the ransom; this is not the position an organization wants to be in when an incident occurs.
Each time ransom is paid, the attacker wins, the criminals become better funded and the ransomware attack model becomes more lucrative; thus attracting more criminals to conduct such attacks on larger scales. “Funding the cybercriminal” should not be the best option in a disaster recovery plan, although for many organizations it is both the best and only option. While moving at the speed of business, basic industry standards for backup and recovery planning are not being met. This can either be due to ignorance of the threat, lack of funding, too few resources, or misaligned priorities.
Our consultants respond to all types of incidents, including ransomware events. We also help organizations visualize how ransomware spreads by conducting live simulations using custom tools to simulate a ransomware attack and recommend our business-tailored phishing assessments as well. In all cases, our simulations show that clients without a disaster recovery plan (and those underprepared for an information security incident) experience a severe business impact and can easily be crippled by ransomware. A recent incident we responded to involved one click on a phishing email by an over-privileged user, resulting in a near complete loss of company data (even the nightly backup!). While we were able to assist in complete restoration of the encrypted data, I am positive the business leaders will not soon forget this incident.
Practical approaches to defend against ransomware (at a minimum) include:
Robust disaster recovery plans and policy development
End-user awareness of the business threat (easier to conceptualize a threat to business rather than IT screaming “Cyber scary things!”)
Backup and storage solutions that are well-maintained and scalable as the business grows
Segmented network space and restricted user account permissions (Sorry, having admin privileges does not make you cool, it makes you a target and business risk)
Full network packet capture (even small amounts of packet capture can tell a story if there is an incident)
Continuous monitoring and vulnerability assessment
Incidents involving ransomware are likely to continue. Industry involvement and development of mitigating techniques through reverse engineering of ransomware are extremely helpful in assisting an organization overcome by ransomware get back on their feet; this alone is just not enough to protect the business. The only way we can truly stop ransomware and those that distribute and profit from it, is to defund it. When ransomware is no longer lucrative for a criminal organization, ransomware development and improvements will vastly decrease (this goes against the criminal business model). As long as underprepared organizations are willing to pay the ransom, profitability remains. Employing practical approaches to defend against ransomware attacks within your organization will help dry up the ransomware well.
Note: ISACA Now is running a series of blogs on the 10 threats covered in ISACA’s Cybersecurity Nexus (CSX)Threats & Controls tool. The threats include APT, cybercrime, DDoS, insider threats, malware, mobile malware, ransomware, social engineering, unpatched systems and watering hole. To learn more about the controls for cybercrime, as well as recent examples and references, typical patterns of cybercrime and more, visit the tool here.
Brandon McCrillis, Sr., Information Security Consultant, Rendition Infosec, @13M4C
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
