Vice Society: Profiling a Persistent Threat to the Education Sector

Posted on by Samantha Stallings

Executive Summary

Vice Society is a ransomware gang that has been involved in high-profile activity against schools this year. Unlike many other ransomware groups such as LockBit that follow a typical ransomware-as-a-service (RaaS) model, Vice Society’s operations are different in that they’ve been known for using forks of pre-existing ransomware families in their attack chain that are sold on DarkWeb marketplaces. These include the HelloKitty (aka FiveHands) and Zeppelin strains of ransomware as opposed to Vice Society developing their own custom payload.

In September 2022, a joint Cybersecurity Advisory (CSA) from the FBI, CISA and the MS-ISAC declared they had recently observed Vice Society actors disproportionately targeting the education sector with ransomware attacks. The CSA continued that attacks could increase as the 2022-23 school year begins and criminal ransomware groups perceive opportunities for successful attacks.

Vice Society first surfaced in the summer of 2021, and in that time frame it was seen exploiting the CVE-2021-34527 (aka PrintNightmare) vulnerability as part of their attack chain. The gang is also known to target backups and exfiltrate data from compromised systems to be leveraged for the purpose of double extortion, a common ransomware operation tactic where victims are pressured to pay a specified ransom amount in exchange for decryption and to avoid having sensitive data published on the attacker’s dedicated leak site.

Palo Alto Networks customers receive protections against ransomware used by Vice Society from Cortex XDR, as well as from the WildFire cloud-delivered security service for the Next-Generation Firewall. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Related Unit 42 Topics Ransomware

Vice Society Activity Timeline

Early reports of the extortion group Vice Society were shared on Twitter by malware researchers such as Michael Gillespie. These tweets depicted HelloKitty ransomware payloads appending a .v-society extension to encrypted files on June 10, 2021.

Since then, Vice Society has used a variety of different ransomware strains including the following notable examples:

  • In June 2021, Vice Society infected victims with HelloKitty.
  • In 2021 and 2022, Vice Society used Zeppelin to target Windows hosts.
    • During their 2021 infections, these attackers also exploited vulnerabilities such as PrintNightmare to escalate privileges and spread laterally across targeted networks.

Based on leak site activity we’ve observed in recent months, as shown in Figure 1, we saw a subtle spike at the turning point from 2021 to 2022. This was followed by one large spike of activity at the end of spring 2022.

Figure 1 is a graph chart showing that the Vice Society gang activity timeline of years 2021 and 2021, with increase during the school year.
Figure 1. Vice Society activity timeline (all leak site victim data).

Fast forward to fall 2022, when we saw another wave of Vice Society activity across the education sector, as shown in Figure 2, which prompted a flood of advisories and reports about the group.

The noticeable spikes in spring and fall give us a hint at some of their motivations. As education organizations are the group’s prime target, this could be an indication that they’re timing campaigns to coincide with this sector’s unique calendar year. The school year for most educational institutions in the U.S. typically starts in late August-September and ends in June. They might have been trying to time their attacks in 2022 with the transitions of the beginning and end of the school year.

Figure 2 is a graph chart showing years 2021 and 2022 showing a significant spike at the beginning of the school year for 2022, 2021. The graph starts in January and ends in December.
Figure 2. Vice Society activity timeline (education-specific leak site victim data).

Study of Vice Society’s Victims

Vice Society is notorious for targeting the education sector – K-12 and higher education institutions in particular (as referenced in the recent CISA Advisory). Other targeted sectors include healthcare and nongovernmental organizations (NGOs).

Common targets are small- to medium-size businesses, with no geographical focus apparent at this time. Rather, as noted in a report by SOCRadar, Vice Society focuses on targets of opportunity.

For years, sectors such as education and healthcare have suffered from many challenges in combating ransomware that have made them particularly attractive targets. A lack of budgeting for systems and security solutions has led many organizations to run legacy hardware that isn’t patched against the latest vulnerabilities.

Other challenges that could increase the overall attack surface of these organizations include difficulties in controlling and managing a large number of personal devices brought in by students and staff members. These personal devices introduce inherent risk because they may interact with personal files via cloud services.

Although these sectors might have dedicated IT or security teams that run traditional security solutions such as an intrusion detection system (IDS) or intrusion prevention system (IPS), ransomware threat actors are leveraging living off the land techniques that can effectively circumvent traditional signature-based detection mechanisms. These tactics require an extended detection and response (XDR) platform for more robust behavioral monitoring within a network.

The education and healthcare sectors also experience the common challenge of finding staff who are adequately trained to handle the ongoing threat of ransomware. And lastly, many of these organizations are charged with protecting some of the most sensitive and valuable personally identifiable information (PII) of any business sector.

Geographical Impact

Vice Society is primarily opportunistic, and its targets have included organizations across the globe. The group has infected organizations based in all regions, as shown in Figures 3 and 4, with the largest numbers in the U.S., followed by the U.K., Spain, France, Brazil, Germany and Italy.

Figure 3 is a heatmap of all continents where affected companies are highlighted in a wave. The largest number of cases is in the United States, followed by the United Kingdom, Spain, France, Brazil, Germany and Italy.
Figure 3. Global geographic distribution of organizations listed on Vice Society leak site.
Figure 4 is the chart version of Figure 3 showing the global geographic distribution of organizations. Cases are counted by country starting from the highest number of cases in the United States with 35 cases down to 1 case. The United Kingdom had the second highest number of cases at 18 with with Spain third at 7 cases.
Figure 4. Chart version of global geographic distribution of organizations listed on Vice Society leak site.

The CISA advisory mentions how Vice Society has disproportionately targeted educational institutions in the United States. Looking at leak site data in more detail, the group appears to be targeting more educational organizations based in California, as shown in Figure 5.

Figure 5 shows the United States distribution of organizations listed on the Vice Society leak site. 17 states were affected with the most cases in California, which had 9 cases total.
Figure 5. Vice Society United States victimology (all leak site victim data).

Impacted Industry Verticals

Although Vice Society has been in the headlines for targeting educational organizations, they also extort victims in many other industry verticals, as shown in Figure 6, including those supplying critical infrastructure, such as healthcare, government entities and manufacturing.

Figure 6 shows industry verticals targeted by Vice Society. Pie charts show individual industry with education being the highest affected at 40 cases. Second is healthcare with 13 cases and third is state and local government at 12 cases.
Figure 6. Industry verticals targeted by Vice Society (leak site data).

Leak Site Metric Comparisons

According to analysis of ransomware leak sites, Unit 42 has identified Vice Society as being in the top 10 of the most impactful ransomware gangs of 2022. We estimate that, since it started operations in 2021, Vice Society has impacted more than 100 organizations in total. More than 90 of the total published leak site infections occurred in the year 2022 alone.

Leak site data suggests that Vice Society has had the highest impact on education organizations this year, with at least 33 educational institutions having been listed on the group’s dedicated ransomware leak site. This impact is closely followed by ransomware families such as LockBit 2.0 and 3.0, as shown in Figure 7.

Figure 7 shows ransomware groups targeting educational organizations. Pie charts show that Vice Society targeted 33 organizations. Lockbit 2.0 is second at 16 cases and Lockbit 3.0 is second at 9 cases.
Figure 7. Top ransomware families targeting educational institutions in 2022 (leak site data).

Unit 42 Incident Response Data on Vice Society

Since Vice Society’s inception in 2021, Unit 42 has performed incident response (IR) engagements with clients who have been impacted by Vice Society. Let’s look at some of the data from these incidents.

Dwell Time

In Unit 42 IR cases regarding Vice Society, we observed dwell times as high as six days. This represents the time elapsed between the date of initial compromise and the date of initial discovery.

Ransom Demands

When tracking ransomware group operations, Unit 42 takes note of the initial and final ransom demands made by each ransomware group. This allows us to better understand how aggressive a particular ransomware gang’s demands might be for particular industry verticals, and to get a general view into the rate at which a particular actor might drive their demands down after negotiations take place.

Our observations of ransom demands by Vice Society across IR cases include:

  • Initial demands by this actor could exceed $1 million.
  • Final demands after negotiations were as high as $460,000.
  • The difference between initial demands and final demands could be significant. We saw decreases as large as 60%.

Vice Society Technical Details

Leak Site Synopsis

Over the past year, Vice Society has operated sites on the Tor network using the following .onion address:
vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion

On Oct. 20, the primary .onion address became inactive, while the following site mirror was still active: ssq4zimieeanazkzc5ld4v5hdibi2nzwzdibfh5n5w4pw5mcik76lzyd[.]onion

Recently, the header for the group’s blog site bears a striking resemblance to the logo of a popular video game titled “Grand Theft Auto: Vice City” (shown in Figure 8).

Figure 8 is a screenshot of the Vice Society active leak mirror website. It is purple with imitation Grand Theft Auto branding. It shows a highlighted countdown indicating when ransomed material will be released.
Figure 8. Vice Society active leak site mirror (Oct. 20).

On Oct. 25, the original .onion address became active again. It was updated to include additional blog sections. As of early November, the “Our Blog” page showcased one article that highlights the group's notoriety, as shown in Figure 9.

Figure 9 is a screenshot of Vice Society's "Our Blog" section highlighting press received by the gang and requesting more press tips.
Figure 9. Vice Society leak site including additional blog content (early November).

The new “Our Partners” page takes the place of the main page from the previous incarnation of the leak site, including links to view leaked victim data.

The new “For Victims” page directs victims to the ransom note that is dropped as part of the group’s infection chain. This is followed by additional instructions in case the victim doesn’t respond to one of the contact emails provided in their ransom note. During the extortion process, the attacker typically gives victims seven days to fulfill ransom demands, as shown in Figure 10.

Figure 10 is a screenshot showing Vice Society's "For Victims" website section detailing instructions beyond what is included in their ransom note.
Figure 10. Vice Society leak site victims page.

The “For Journalists” page depicts a “Frequently Asked Questions” section to address general questions about the group, as shown in Figure 11.

Figure 11 is a screenshot of Vice Society's "For Journalists" website section that includes "Frequently Asked Questions including how they started, operation length, and other topics.
Figure 11. Vice Society leak site journalists page.

HelloKitty Usage

At the start of the group’s observed operations in 2021, Vice Society affiliates used the HelloKitty Ransomware variant as a primary payload in their infection chain.

This ransomware family was first observed in December 2020, primarily targeting Windows systems. This variant gets its name from its mutex: HELLOKITTYMutex.

In July 2021, as described in our HelloKitty ATOM, Unit 42 came across a Linux (ELF) sample with the name funny_linux.elf that had a ransom note with contents similar to those of HelloKitty for Windows samples. This Linux sample led to the discovery of additional HelloKitty samples for Linux dating back to October 2020. In March 2021, HelloKitty’s Linux variant was also observed in the wild to target ESXi servers.

Similar to ransomware variants like BlackCat, HelloKitty ransomware typically requires a key to execute, to hinder analysis efforts. In HelloKitty’s case, this key is typically obfuscated with AES 256 encryption. As mentioned in our previous report detailing emerging ransomware families in 2021, HelloKitty features multiple flags that could be set as command line arguments, which are detailed in Table 1 of the linked report.

Figure 12 is a screenshot of a ransom note from Vice Society using HelloKitty ransomware. It details what was stolen, how to recover files, how prove encryption, how to make contact, what steps to avoid, and a request to visit the Vice Society website using Tor.
Figure 12. Vice Society ransom note using HelloKitty ransomware.

When the encryption process is complete, encrypted files are typically appended with an extension using the following format: .v-society.<victim ID>.

Zeppelin Usage

As previously mentioned, the Vice Society group has also been known to adopt other ransomware families such as Zeppelin as a part of their infection chain. Upon execution, the ransomware binary deletes itself and drops a ransom note on the victim machine’s desktop titled !!! ALL YOUR FILES ARE ENCRYPTED !!!.TXT. The contact email address provided by the threat actor vary between samples, but the public v-society.official@onionmail[.]org address and the Tor .onion link remain consistent.

Figure 13 is a screenshot of a Vice Society ransom note using Zeppelin ransomware. It details what was encrypted, how to recover the encrypted files, who to contact, and what steps to avoid.
Figure 13. Vice Society ransom note using Zeppelin ransomware.

Additional execution details include the following:

  • Creating the HKCU\Software\Zeppelin registry key
  • Appending an extension with the format A1A-A80-4CD to encrypted files
  • Creating a file called README.txt.v-society
  • Imphash: 8acb34bed3caa60cae3f08f75d53f727
  • Creating a temp file with a .Zeppelin extension using the following format - C:\Users\<User>\AppData\Local\Temp\7D3ED7F1.Zeppelin

Conclusion

School districts with limited cybersecurity capabilities and constrained resources are often the most vulnerable to threat actors. The opportunistic targeting often seen with cybercriminals can put even school districts with robust cybersecurity programs at risk. K-12 institutions may be seen as particularly lucrative targets due to the amount of sensitive student data accessible through school systems or their managed service providers.

Vice Society and its consistent targeting of the education industry vertical, particularly around the September time frame, serves as a warning that this group has shaped their campaigns to take advantage of the school year in the U.S. It’s likely they’ll maintain use of these tactics to impact the cyberthreat landscape moving forward, as long as their activities continue to be lucrative for them.

Educational institutions should continue to implement security best practices and be wary of the ongoing threat of ransomware, especially during the start and end of the school year.

K-12 institutions and universities do have an advantage when it comes to protecting themselves that too few organizations use to its full potential. In a school environment, there are many educators who can help inform trainings for both staff and students to learn what they need to do to maintain security for everyone in the organization.

Vice Society’s use of multiple ransomware payloads across both Windows and Linux hosts shows that they’re continually evolving. They will likely continue leveraging additional ransomware strains in the future, as well as exploiting newly disclosed vulnerabilities.

As we do with other ransomware groups, Unit 42 strongly advises organizations that have been impacted by Vice Society to avoid paying a ransom if possible, and to instead consult a trusted IR negotiation team for the best course of action.

Palo Alto Networks customers receive protections against ransomware used by Vice Society from Cortex XDR, as well as from the WildFire cloud-delivered security service for the Next-Generation Firewall.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Tactics, Techniques and Procedures (TTPs)

Unit 42 has observed the following TTPs being used by Vice Society in past incident response engagements involving the group. The following table illustrates these TTPs according to the MITRE ATT&CK framework.

TA0001 Initial Access
T1566 Phishing Vice Society is known to use phishing to gain initial access to victims’ systems.
T1078 Valid Accounts Compromised valid credentials have been used by Vice Society to gain initial access. 
T1190 Exploit Public-Facing Applications Internet-facing applications and systems vulnerabilities can be exploited, such as PrintNightmare (CVE-2021-1675) and (CVE-2021-34527), to gain initial access.
TA0002 Execution
T1047 Windows Management Instrumentation (WMI) Malicious commands are executed via WMI as a means of “living off the land” and avoiding detection.
T1053.005 Scheduled Task/Job Vice Society is known to execute commands via scheduled tasks/jobs.
T1059.001 Command and Scripting Interpreter: Powershell Vice Society utilizes PsExec for execution, persistence and defense evasion. 
T1059.003 Command and Scripting Interpreter: Command Shell Batch files are used by Vice Society to deploy the ransomware via PsExec.
TA0003 Persistence
T1543.003 Modify System Process To maintain access to compromised systems, Vice Society leverages Windows operating functions to execute encrypted PowerShell.
T1547.001 Registry Run Keys/Startup Folder Persistence is maintained after boot/reboot via malicious autostart registry keys.
T1574.002 DLL Side-Loading Vice Society utilizes legitimate programs to side-load the group’s own DLL to execute their payload. 
TA0004 Privilege Escalation
T1068 Exploitation for Privilege Escalation Software vulnerabilities, such as PrintNightmare (CVE-2021-1675) and (CVE-2021-34527), may be exploited in an attempt to elevate privileges. 
TA0005 Defense Evasion
T1036 Masquerading Files dropped in the victim’s environment by Vice Society may have been altered to appear legitimate.
T1055 Process Injection Legitimate processes have been corrupted by Vice Society via code injection, as a means to evade defenses. 
T1070 Indicator Removal on Host As with many other ransomware groups, Vice Society attempts to clear system, security and application logs on compromised machines. 
T1112 Modify Registry Vice Society attempts to disable Windows Defender by modifying the Registry.
T1497 Sandbox Evasion Vice Society attempts to thwart reverse engineering and/or dynamic analysis via various sandbox evasion techniques. 
T1562.001 Impair Defenses: Disable or Modify Tools Attempts to disable or modify endpoint security, such as Microsoft Defender, on compromised devices.
TA0006 Credential Access
T1003 OS Credential Dumping Vice Society is known to utilize ntds.dit and comsvcs.dll to extract credentials.
T1003.001 OS Credential Dumping: LSASS Memory  Vice Society utilizes comsvcs.dll to dump credentials from Local Security Authority Subsystem Service. 
T1003.003 OS Credential Dumping: NTDS Vice Society attempts to “live off the land” by utilizing ntds.dit and ntdsutil.exe to dump Active Directory Database in an effort to obtain credentials.
TA0007 Discovery
T1046 Network Service Discovery Vice Society has been seen using the recon tool called Advanced Port Scanner to identify running services and local network infrastructure. 
T1482 Domain Trust Discovery Vice Society has been seen using the attack path reconnaissance tool Bloodhound during the initial stages of their attack before ransomware is deployed.
TA00008 Lateral Movement
T1021 Remote Services RDP is used by the group for lateral movement.
T1021.002 Remote Services: SMB/Windows Admin Shares SMB shares have been used by Vice Society for lateral movement.
T1080 Taint Shared Content Network drives and other shared storage locations are used by Vice Society to deliver payloads.
T1570 Lateral Tool Transfer Lateral tool transfers have been used to move tools and files from one compromised system to another, including SMB and RDP.
TA0010 Exfiltration
T1020 Automated Exfiltration PowerShell scripts are used to exfiltrate data to external C2 servers.
T1041 Exfiltration over C2 Channel Tools such as PowerShell and PsExec are used to exfiltrate data directly to C2 servers.
T1048 Exfiltration Over Alternative Protocol Vice Society has used SMB in attempts to exfiltrate data.
T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage Cloud storage and transfer services such as Mega.nz, Anonfiles.com, File.io, and Sendspace have been used by Vice Society to exfiltrate victim data. 
TA0011 Command and Control
T1219 Remote Access Software Tools such as SystemBC and proprietary backdoors are known to be used by Vice Society.
TA0040 Impact
T1486 Data Encrypted for Impact Vice Society is known for its extortion tactics, encrypting devices and demanding a ransom.
T1531 Account Access Removal Vice Society is known to change passwords of compromised victim accounts and privileged users, such as email and administrator accounts.

Indicators of Compromise (IoCs)

HelloKitty Elf samples featuring Vice Society ransom note header:

  • 643a3121166cd1ee5fc6848f099be7c7c24d36f5922f58052802b91f032a5f0f
  • 754f2022b72da704eb8636610c6d2ffcbdae9e8740555030a07c8c147387a537
  • 78efe6f5a34ba7579cfd8fc551274029920a9086cb713e859f60f97f591a7b04
  • 16a0054a277d8c26beb97850ac3e86dd0736ae6661db912b8782b4eb08cfd36e

Zeppelin ransomware with the Vice Society ransom note header:

  • 4a4be110d587421ad50d2b1a38b108fa05f314631066a2e96a1c85cc05814080
  • 307877881957a297e41d75c84e9a965f1cd07ac9d026314dcaff55c4da23d03e
  • faa79c796c27b11c4f007023e50509662eac4bca99a71b26a9122c260abfb3c6
  • dd89d939c941a53d6188232288a3bd73ba9baf0b4ca6bf6ccca697d9ee42533f
  • 4440763b18d75a0f9de30b1c4c2aeb3f827bc4f5ea9dd1a2aebe7e5b23cfdf94
  • 24efa10a2b51c5fd6e45da6babd4e797d9cae399be98941f950abf7b5e9a4cd7
  • bafd3434f3ba5bb9685e239762281d4c7504de7e0cfd9d6394e4a85b4882ff5d
  • aa7e2d63fc991990958dfb795a0aed254149f185f403231eaebe35147f4b5ebe
  • 001938ed01bfde6b100927ff8199c65d1bff30381b80b846f2e3fe5a0d2df21d
  • Ab440c4391ea3a01bebbb651c80c27847b58ac928b32d73ed3b19a0b17dd7e75

Contact information:

  • vicesociety@onionmail[.]org
  • v-society.official@onionmail[.]org
  • LarryGold@onionmail[.]org
  • MollyThomson@onionmail[.]org
  • BruceBoyle@onionmail[.]org
  • SylvesterJones@onionmail[.]org
  • brendaevans4454@onionmail[.]org
  • warreinolds77@onionmail[.]org
  • DaltonReed@onionmail[.]org
  • FreddieFerrell@onionmail[.]org
  • lewiselsberry@onionmail[.]org
  • inezeng@onionmail[.]org
  • lonnieguzman@onionmail[.]org
  • thomasmoore@onionmail[.]org

Domains:

  • vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion
  • Qu5dci2k25x2imgki2dbhcwegqqsqsrjj5d3ugcc5kpsgbtj2psaedqd[.]onion
  • Wavbeudogz6byhnardd2lkp2jafims3j7tj6k6qnywchn2csngvtffqd[.]onion
  • gunyhng6pabzcurl7ipx2pbmjxpvqnu6mxf2h3vdeenam34inj4ndryd[.]onion

Additional Resources

Threat Brief: Windows Print Spooler RCE Vulnerability (CVE-2021-34527 AKA PrintNightmare)
Emerging Ransomware Groups: AvosLocker, Hive, HelloKitty, LockBit 2.0
Threat Assessment: Zeppelin Ransomware
#StopRansomware: Vice Society | CISA
Dark Web Profile: Vice Society - SOCRadar® Cyber Intelligence Inc.
Michael Gillespie Twitter post
Unit 42 ATOM: HelloKitty
UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat | Mandiant

Blowing Cobalt Strike Out of the Water With Memory Analysis

Posted on by Dominik Reichel

Executive Summary

Unit 42 researchers examine several malware samples that incorporate Cobalt Strike components, and discuss some of the ways that we catch these samples by analyzing artifacts from the deltas in process memory at key points of execution. We will also discuss the evasion tactics used by these threats, and other issues that make their analysis problematic.

Cobalt Strike is a clear example of the type of evasive malware that has been a thorn in the side of detection engines for many years. It is one of the most well-known adversary simulation frameworks for red team operations. However, it’s not only popular among red teams, but it is also abused by many threat actors for malicious purposes.

Although the toolkit is only sold to trusted entities to conduct realistic security tests, due to source code leaks, its various components have inevitably found their way into the arsenal of malicious actors ranging from ransomware groups to state actors. Malware authors abusing Cobalt Strike even played a role in the infamous SolarWinds incident in 2020.

Related Unit 42 Topics Cobalt Strike, Sandbox

Overview of Cobalt Strike

The main driver for the proliferation of Cobalt Strike is that it is very good at what it does. It was designed from the ground up to help red teams armor their payloads to stay ahead of security vendors, and it regularly introduces new evasion techniques to try to maintain this edge.

One of the main advantages of Cobalt Strike is that it mainly operates in memory once the initial loader is executed. This situation poses a problem for detection when the payload is statically armored, exists only in memory and refuses to execute. This is a challenge to many security software products, as scanning memory is anything but easy.

In many cases, Cobalt Strike is a natural choice for gaining an initial footprint in a targeted network. A threat actor can use a builder with numerous deployment and obfuscation options to create the final payload based on a customizable template.

This payload is typically embedded into a file loader in encrypted or encoded form. When the file loader is executed by a victim, it decrypts/decodes the payload into memory and runs it. As the payload is present in memory in its original form, it can be detected easily due to some specific characteristics.

As malware researchers, we often see potentially interesting malicious samples that turn out to just be loaders for Cobalt Strike. It’s also often unclear if a loader was created by a red team or a real malicious actor, thus making attribution even more challenging.

In the next few sections, we’re going to take a closer look into three different Cobalt Strike loaders that were detected out of the box by a new hypervisor based sandbox we designed to allow us to analyze artifacts in memory. Each sample loads a different implant type, namely an SMB, HTTPS and stager beacon. We dubbed these Cobalt Strike loaders KoboldLoader, MagnetLoader and LithiumLoader. We will also discuss some of the methods we can use to detect these payloads.

KoboldLoader SMB Beacon

The sample we’re looking at was detected during a customer incident.

SHA256: 7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292

This 64-bit KoboldLoader executable uses various known tricks to try to bypass sandboxes and to make the analysis process more time consuming.

To bypass sandboxes that hook only high-level user mode functions, it solely calls native API functions. To make the analyst's life harder, it dynamically resolves the functions by hash instead of using plain text strings. The malware contains code to call the following functions:

  • NtCreateSection
  • NtMapViewOfSection
  • NtCreateFile (unused)
  • NtAllocateVirtualMemory (unused)
  • RtlCreateProcessParameters
  • RtlCreateUserProcess
  • RtlCreateUserThread
  • RtlExitUserProcess

The malware creates two separate tables of function hash/address pairs. One table contains one pair for all native functions, while the second table only pairs for Nt* functions.

For the Rtl* functions that were used, it loops through the first table and searches for the function hash to get the function address. For the Nt* functions that were used, it loops through the second table and simultaneously increases a counter variable.

When the hash is found, it takes the counter value that is the system call number of the corresponding native function, and it enters a custom syscall stub. This effectively bypasses many sandboxes, even if the lower level native functions are hooked instead of the high-level ones.

The overall loader functionality is relatively simple and uses mapping injection to run the payload. It spawns a child process of the Windows tool sethc.exe, creates a new section and maps the decrypted Cobalt Strike beacon loader into it. The final execution of the Cobalt Strike loader that in turn loads an SMB beacon happens by calling RtlCreateUserThread.

You can find the decrypted beacon configuration data in the Appendix section.

In-Memory Evasion

With our new hypervisor-based sandbox, we were able to detect the decrypted Cobalt Strike SMB beacon in memory. This beacon loader even uses some in-memory evasion features that create a strange sort of chimeric file. While it’s actually a DLL, the “MZ'' magic PE bytes and subsequent DOS header are overwritten with a small loader shellcode as shown in Figure 1.

Image of shellcode showing disassembled Cobalt Strike beacon loader.
Figure 1. Disassembled Cobalt Strike beacon loader shellcode.

The shellcode loader jumps to the exported function DllCanUnloadNow, which prepares the SMB beacon module in memory. To do this, it first loads the Windows pla.dll library and zeroes out a chunk of bytes inside its code section (.text). It then writes the beacon file into this blob and fixes the import address table, thus creating an executable memory module.

During the analysis of the file, we could figure out some of the in-memory evasion features that were used, as shown in Table 1.

Evasion feature Description Used in our sample
allocator Set how beacon's ReflectiveLoader allocates memory for the agent. Options are: HeapAlloc, MapViewOfFile and VirtualAlloc. No
cleanup Ask beacon to attempt to free memory associated with the reflective DLL package that initialized it. Yes
magic_mz_x64 Override the first bytes (MZ header included) of beacon's reflective DLL. Valid x86 instructions are required. Follow instructions that change CPU state with instructions that undo the change. Yes
magic_pe Override the PE character marker used by beacon's ReflectiveLoader with another value. No
module_x64 Ask the x86 reflective loader to load the specified library and overwrite its space instead of allocating memory with VirtualAlloc. Yes
obfuscate Obfuscate the reflective DLL’s import table, overwrite unused header content, and ask ReflectiveLoader to copy beacon to new memory without its DLL headers. Yes
sleep_mask Obfuscate beacon and its heap, in-memory, prior to sleeping. No
smartinject Use embedded function pointer hints to bootstrap beacon agent without walking kernel32 Export Address Table (EAT). No
stomppe Ask ReflectiveLoader to stomp MZ, PE and e_lfanew values after it loads beacon payload. No
userwx Ask ReflectiveLoader to use or avoid read, write or execute (RWX) permissions for Beacon DLL in memory. No

Table 1. Cobalt Strike evasion techniques that were used.

To sum up, the beacon loader and the beacon itself are the same file. Parts of the PE header are used for a shellcode that jumps to an exported function, which in turn creates a module of itself inside a Windows DLL. Finally, the shellcode jumps to the entry point of the beacon module to execute it in memory.

As discussed, there is no way for us to detect this beacon of our KoboldLoader sample successfully unless we can peer inside memory during execution.

MagnetLoader

The second loader we will look into is a 64-bit DLL that imitates a legitimate library.

SHA256: 6c328aa7e0903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0

This MagnetLoader sample tries to look like the Windows file mscms.dll in a few ways, by using the following similar features:

  • The same file description
  • An export table with many of the same function names
  • Almost identical resources
  • A very similar mutex

These features are also shown in Figure 2, where the malware file is contrasted with the valid mscml.dll.

Left-right comparison image using EXE Explorer where the malware file is contrasted with valid mcml.dll. Left shows MagnetLoader file description, export table and resources compared to msmcl.dll on right.
Figure 2. Comparison of file description, export table and resources of MagnetLoader (left) and mscml.dll (right) as seen with EXE Explorer.

MagnetLoader not only tries to mimic the legitimate Windows library statically, but also at runtime.

All of the exported functions of MagnetLoader internally call the same main malware routine. When one of them is called, the DLL entry point is run first. In the entry point, the malware loads the original mscms.dll and it resolves all the functions it fakes.

The addresses of these original functions are stored and called after a fake method is executed. Thus, whenever an exported function of MagnetLoader is called, it runs the main malware routine and afterward calls the original function in mscms.dll.

The main malware routine is relatively simple. It first creates a mutex named SM0:220:304:WilStaging_02_p1h that looks very similar to the original one created by mscms.dll.

The Cobalt Strike beacon loader gets decrypted into a memory buffer and executed with the help of a known trick. Instead of calling the beacon loader directly, the loader uses the Windows API function EnumChildWindows to run it.

This function contains three parameters, one of which is a callback function. This parameter can be abused by malware to indirectly call an address via the callback function and thus conceal the execution flow.

You can also find the decrypted beacon configuration data in the Appendix section.

LithiumLoader

This last Cobalt Strike sample is part of a DLL side-loading chain where a custom installer for a type of security software was used. DLL side-loading is a technique that hijacks a legitimate application to run a separate, malicious DLL.

SHA256: 8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f

This 32-bit LithiumLoader DLL is part of a custom attacker-created Fortinet VPN installation package submitted to VirusTotal as FortiClientVPN_windows.exe (SHA256: a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786).

The FortiVPN.exe file is not malicious or compromised. Because the file is signed, attackers used it to evade antivirus detection.

The installer is a self-extracting RAR archive that contains the following files:

File name Description
FortiVPN.exe Legit signed FortiClient VPN Online installer v7.0.1.83
GUP.exe Legit signed WinGup for Notepad++ tool v5.2.1.0
gup.xml WinGup config file
libcurl.dll LithiumLoader

Table 2a. FortiClientVPN_windows.exe file contents.

The self-extracting script commands are as follows:

Screenshot of the self-extracting script commands for the RAR file. There are five lines of code in total.
Table 2b. List of self-extracting script commands.

When the installer is run, all files get silently dropped to the local %AppData% folder and both executable files get started. While the FortiClient VPN installer executes, the WinGup tool side-loads the libcurl.dll LithiumLoader malware. The malware does so because it imports the following functions from a legit copy of the libcurl library as shown in Figure 3.:

An image showing the import address of WinGub.exe with libcurl.dll (4) highlighted in left column, with curl_easy_setopt and its ordinal and address highlighted in the right column.
Figure 3. Import address table of WinGup.exe.

This threat also tries to add the %AppData% folder path to the exclusion list in Windows Defender via PowerShell.

On the startup of GUP.exe, the malicious libcurl.dll file is loaded into the process space as it statically imports the functions shown in Figure 3, above. While all four libcurl functions are run, only curl_easy_cleanup contains a malicious routine that was injected while compiling a new version of the library. Thus, we’re not dealing with a patched version of the legitimate DLL. This is a cleaner solution that doesn’t break the code after the inserted malicious routine, as is often seen in other malware.

This curl_easy_cleanup function usually contains only one subroutine (Curl_close) and has no return value (as shown in its source code on GitHub). The altered function is as shown in Figure 4.

A screenshot of the modified curl_easy_cleanup export function showing 9 lines of code with int __cdel curl_easy_cleanup(Curl_easy *data) highlighted.
Figure 4. Modified curl_easy_cleanup export function of libcurl.dll.

The load_shellcode function decrypts the shellcode via XOR and key 0xA as shown in Figure 5.

A screenshot showing 28 lines of code with BOOL load_shellcode() highlighted. This function decrypts the shellcode via XOR and key 0xA on lines 14 and 22.
Figure 5. Shellcode loader function load_shellcode().

This function runs the Cobalt Strike stager shellcode indirectly via EnumSystemGeoID instead of directly jumping to it. This Windows API function has three parameters, the last one of which is a callback function abused by LithiumLoader.

The Cobalt Strike stager shellcode is borrowed from Metasploit and is the reverse HTTP shell payload, which uses the following API functions:

  • LoadLibrary
  • InternetOpenA
  • InternetConnectA
  • HttpOpenRequestA
  • InternetSetOptionA
  • HttpSendRequestA
  • GetDesktopWindow
  • InternetErrorDlg
  • VirtualAllocStub
  • InternetReadFile

The shellcode connects to the IP address of a university in Thailand.

LithiumLoader Detection Issues

At the time of writing this analysis, the Cobalt Strike beacon payload was no longer available. Without a payload or any actionable information in the execution report of API calls, it’s often challenging for a sandbox to determine whether the sample is malicious. This sample doesn’t have any functionality that can be classified as malicious per se.

Catching Cobalt Strike Through Analyzing Its Memory

In all three of these examples there are some common detection challenges. These samples do not execute in normal sandbox environments. But as we discussed, there is a wealth of information that we can use for detection if we look inside memory during execution, like function pointers, decoded stages of the loader, and other artifacts.

For many years now, it has been standard practice for sandbox systems to instrument and observe the activity of executing programs. If our team has learned anything over the years, it’s that this alone is not enough for highly evasive malware. This is why we’ve been working hard the past few years on figuring out how we can add more thorough processing for this type of highly evasive malware.

For accurate detection, one of the key features we’ve found to address highly evasive malware is that we need to look at memory as samples execute in addition to using the system API to get a better understanding of what’s happening.

An image showing a magnifying glass with a target inside with the text "Malware Process". An arrow extends from the target and text to an icon of a computer with "OS" on the monitor to stand for Operating System. The first part of the image text is "Industry standard: Focus mainly on interactions with system APIs. Memory analysis: Focus on memory during live sample execution in addition to observable malware actions.
Figure 6. High level Advanced WildFire detection strategy.

We’ve found that, in malware detection, it’s useful to look at the deltas in memory at key points of execution to extract meaningful information and artifacts. As our system processes a vast number of samples, there have been a lot of challenges to make this work at scale. However, a lot of clever engineering built on top of our flagship custom hypervisor tailored for malware analysis has helped make this idea a reality.

In these next few sections, we will detail some of the main types of data that we are currently collecting from memory to aid detection. This data can be utilized by both our analysts for manual signatures as well as machine learning pipelines, which we’ll be discussing in a future post.

Although we are focusing on memory here, we are by no means suggesting that instrumenting and logging API calls are not useful for detection. Our belief is that bringing execution logs and memory analysis data together creates a sum greater than its parts.

Automatic Payload Extraction

As previously discussed, it is increasingly common for malware authors to obfuscate their initial payloads. While using executable packers that can compress and obfuscate files to accomplish this is nothing new, it becomes problematic when it’s used in combination with evasion strategies, because there is no static or dynamic data that’s useful for an accurate detection.

There are infinite combinations of strategies for encoding, compressing, encrypting or downloading additional stages for execution. The ability to craft signatures for these payloads is obviously an important way that our analysts can catch lots of different malware components from frameworks like Cobalt Strike. If we can catch them in memory, it ultimately doesn’t matter if the malware decides not to execute.

The following simplified diagram in Figure 7 shows an example of what we might see in a couple of stages that were never present in the initial executable file.

Image of a simplified diagram highlighting the possible stages seen in a packed malware executable. On the left is the shellcode stage as part of an executable image, with arrows showing its progress through the stack and then to the heap. From the stack the shellcode moves to the PEs.
Figure 7. Typical stages we might see in a packed malware executable.

On the left side of the diagram, we see an example of a shellcode stage. Although the term “shellcode” was originally coined for hand crafted assembly utilized in exploits to pop a shell on a target system, the word has evolved to encompass any blobs of custom assembly written for nefarious purposes. Some malware stages are blobs of custom assembly with no discernable executable structure. A common pattern for malware authors taking this approach is to dynamically resolve all of the function pointers into a table for ease of access.

On the right side of the diagram, we see that the later stage is an example of a well-formed executable. Some malware stages or payloads are well-formed executables. These can be loaded by the OS via the system API, or the malware author might use their own PE loader if they’re trying to be stealthy in avoiding calling any APIs to do this for them.

Function Pointer Data

Another rich set of data we can pull from memory that we’ve begun to use for detection is dynamically resolved function pointers, as shown in Figure 8. Malware authors learned long ago that if they explicitly call out all of the WINAPI functions they plan to use in the import table, it can be used against them. It is now standard practice to hide the functions that will be used by the malware or any of its stages.

Shellcode hashing is another common stealthy strategy used to resolve pointers for functions without needing their string.

Image of dynamically resolved WINAPI pointers seen in a memory segment. On the left is a block showing the API pointer data. On the right are the targeted OS libraries.
Figure 8. Examples of dynamically resolved WINAPI pointers we might see in a memory segment.

In Advanced WildFire we have begun to selectively search for and use this information about which WINAPI function pointers were resolved in our detection logic.

OS Structure Modifications

Another useful source of detection data we’ve found from analyzing memory is to look for any changes to Windows bookkeeping structures (Malware authors love to mess with these!). These structures are important for the OS to maintain state about the process, such as what libraries have been loaded, where the executable image was loaded, and various other characteristics about the process that the OS might need to know later. Given that many of these fields should never be modified, it’s often useful to keep track of when and how malware samples are manipulating them.

The diagram in Figure 9 shows how a sample might unhook a module it loaded from the LDR Module list. Unhooking a module would mean that there is no longer a record that the module exists. So, for example, after doing this the Task Manager in Windows would no longer list it.

This diagram represents only one of many different OS Structure modifications we’ve seen, but it shows that there are many different types of OS structure modifications that are useful for the malware detection problem.

This image shows three fields on the left indicating the progression from the thread information block to the PEB LDR data structure. An arrow shows the progression from the Data Structure to the LDR Modules. The LDR Module ntdll.dll moves to LDR Module kernel32.dll and unhooks it from the malware to replace it with a separate .dll.
Figure 9. An example of how a module might be unhooked from the LDR Modules List.

Page Permissions

Finally, another useful source of detection data is a full log of all changes made to page permissions. Authors of packed malware often need to change memory permissions in order to properly load and execute further stages. Understanding which pages of memory had their permissions changed often provides important insights into where code was loaded and executed, which can be useful for detection.

Conclusion

Although Cobalt Strike has been around for some years, detecting it is still a challenge to many security software providers. That is because this tool works mostly in memory and doesn’t touch the disk much, other than with the initial loader.

We’ve looked into three new loaders and showed how they can be detected using a variety of techniques. These detection techniques are available within our new hypervisor based sandbox.

Figure 10 illustrates our detection reasons for KoboldLoader.

Screenshot identifying the malware. Listed is the verdict, detection reason 1, detection reason 2, the behaviors (redacted) and the memory analysis behaviors (redacted). The detection reasons include identifying the malware as Cobalt Strike and its variant, and its signatures. It also detected its beacon and shellcode loader.
Figure 10. Internal KoboldLoader sample analysis report.

Palo Alto Networks customers receive protections from these threats:

  • Advanced WildFire identifies the Cobalt Strike loaders and beacons as malicious.
  • Cortex XDR protects endpoints and identifies the loaders as malicious.

Indicators of Compromise

KoboldLoader

7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292
6ffedd98d36f7c16cdab51866093960fe387fe6fd47e4e3848e721fd42e11221
fc4b842b4f6a87df3292e8634eefc935657edf78021b79f9763548c74a4d62b8
062aad51906b7b9f6e8f38feea00ee319de0a542a3902840a7d1ded459b28b8d
a221c7f70652f4cc2c76c2f475f40e9384a749acd1f0dbaefd1a0c5eb95598d2

MagnetLoader

6c328aa7e0903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0

LithiumLoader

8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f
82dcf67dc5d3960f94c203d4f62a37af7066be6a4851ec2b07528d5f0230a355

LithiumLoader Installer

a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786
cbaf79fb116bf2e529dd35cf1d396aa44cb6fcfa6d8082356f7d384594155596

Appendix

KoboldLoader beacon configuration data:

BeaconType - SMB
Port - 4444
SleepTime - 10000
MaxGetSize - 1048576
Jitter - 0
MaxDNS - 0
PublicKey_MD5 - 633dc5c9b3e859b56af5edf71a178590
C2Server -
UserAgent -
HttpPostUri -
Malleable_C2_Instructions - Empty
PipeName - \\.\pipe\servicepipe.zo9keez4weechei8johR.0521cc13
DNS_Idle - Not Found
DNS_Sleep - Not Found
SSH_Host - Not Found
SSH_Port - Not Found
SSH_Username - Not Found
SSH_Password_Plaintext - Not Found
SSH_Password_Pubkey - Not Found
SSH_Banner - Not Found
HttpGet_Verb - Not Found
HttpPost_Verb - Not Found
HttpPostChunk - Not Found
Spawnto_x86 - %windir%\syswow64\dfrgui.exe
Spawnto_x64 - %windir%\sysnative\dfrgui.exe
CryptoScheme - 0
Proxy_Config - Not Found
Proxy_User - Not Found
Proxy_Password - Not Found
Proxy_Behavior - Not Found
Watermark_Hash - Not Found
Watermark - 666
bStageCleanup - True
bCFGCaution - True
KillDate - 0
bProcInject_StartRWX - True
bProcInject_UseRWX - False
bProcInject_MinAllocSize - 35485
ProcInject_PrependAppend_x86 - b'\x90\x90\x90\x90\x90\x90\x90'
b'\x90\x90\x90\x90\x90\x90\x90'
ProcInject_PrependAppend_x64 - b'\x90\x90\x90\x90\x90\x90\x90'
b'\x90\x90\x90\x90\x90\x90\x90'
ProcInject_Execute - ntdll.dll:RtlUserThreadStart
NtQueueApcThread
NtQueueApcThread-s
SetThreadContext
RtlCreateUserThread
kernel32.dll:LoadLibraryA
ProcInject_AllocationMethod - NtMapViewOfSection
bUsesCookies - Not Found
HostHeader - Not Found
headersToRemove - Not Found
DNS_Beaconing - Not Found
DNS_get_TypeA - Not Found
DNS_get_TypeAAAA - Not Found
DNS_get_TypeTXT - Not Found
DNS_put_metadata - Not Found
DNS_put_output - Not Found
DNS_resolver - Not Found
DNS_strategy - Not Found
DNS_strategy_rotate_seconds - Not Found
DNS_strategy_fail_x - Not Found
DNS_strategy_fail_seconds - Not Found
Retry_Max_Attempts - Not Found
Retry_Increase_Attempts - Not Found
Retry_Duration - Not Found

MagnetLoader beacon configuration data:

BeaconType - HTTPS
Port - 443
SleepTime - 3600000
MaxGetSize - 1402498
Jitter - 70
MaxDNS - Not Found
PublicKey_MD5 - 965fe5c869f3eea5e211fa7ee12130d3
C2Server - tileservice-weather.azureedge[.]net,/en-au/livetile/front/
UserAgent - Microsoft-WebDAV-MiniRedir/10.0.19042
HttpPostUri - /en-CA/livetile/preinstall
Malleable_C2_Instructions - Remove 1380 bytes from the end
Remove 3016 bytes from the beginning
Base64 URL-safe decode
HttpGet_Metadata - ConstHeaders
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Host: tileservice-weather.azureedge[.]net
Origin: https://tile-service-weather.azureedge[.]net
Referer: https://tile-service.weather.microsoft[.]com/
Metadata
base64url
append "/45.40,72.73"
uri_append
HttpPost_Metadata - ConstHeaders
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Host: tileservice-weather.azureedge[.]net
Origin: https://tile-service-weather.azureedge[.]net
Referer: https://tile-service.weather.microsoft[.]com/
ConstParams
region=CA
SessionId
base64url
parameter "appid"
Output
base64
print
PipeName - Not Found
DNS_Idle - Not Found
DNS_Sleep - Not Found
SSH_Host - Not Found
SSH_Port - Not Found
SSH_Username - Not Found
SSH_Password_Plaintext - Not Found
SSH_Password_Pubkey - Not Found
SSH_Banner -
HttpGet_Verb - GET
HttpPost_Verb - POST
HttpPostChunk - 0
Spawnto_x86 - %windir%\syswow64\conhost.exe
Spawnto_x64 - %windir%\sysnative\conhost.exe
CryptoScheme - 0
Proxy_Config - Not Found
Proxy_User - Not Found
Proxy_Password - Not Found
Proxy_Behavior - Use IE settings
Watermark_Hash - Not Found
Watermark - 1700806454
bStageCleanup - True
bCFGCaution - False
KillDate - 0
bProcInject_StartRWX - False
bProcInject_UseRWX - False
bProcInject_MinAllocSize - 17500
ProcInject_PrependAppend_x86 - b'\x90\x90'
Empty
ProcInject_PrependAppend_x64 - b'\x90\x90'
Empty
ProcInject_Execute - CreateThread
SetThreadContext
ProcInject_AllocationMethod - NtMapViewOfSection
bUsesCookies - False
HostHeader -
headersToRemove - Not Found
DNS_Beaconing - Not Found
DNS_get_TypeA - Not Found
DNS_get_TypeAAAA - Not Found
DNS_get_TypeTXT - Not Found
DNS_put_metadata - Not Found
DNS_put_output - Not Found
DNS_resolver - Not Found
DNS_strategy - round-robin
DNS_strategy_rotate_seconds - -1
DNS_strategy_fail_x - -1
DNS_strategy_fail_seconds - -1
Retry_Max_Attempts - Not Found
Retry_Increase_Attempts - Not Found
Retry_Duration - Not Found

To decrypt the configuration data we used SentinelOne’s Cobalt Strike Parser.

Additional Resources

EXE Explorer
Cobalt Strike Parser

Updated December 6, 2022, at 9:05 a.m. PT. 

Threat Assessment: Luna Moth Callback Phishing Campaign

Posted on by Erica Naone

Executive Summary

Unit 42 investigated several incidents related to the Luna Moth/Silent Ransom Group callback phishing extortion campaign targeting businesses in multiple sectors including legal and retail. This campaign leverages extortion without encryption, has cost victims hundreds of thousands of dollars and is expanding in scope.

By design, this style of social engineering attack leaves very few artifacts because of the use of legitimate trusted technology tools to carry out attacks. However, Unit 42 has identified several common indicators implying that these attacks are the product of a single highly organized campaign. This threat actor has significantly invested in call centers and infrastructure that’s unique to each victim.

Cybersecurity awareness training is the most effective defense against these stealthy and discreet attacks. However, Palo Alto Networks customers receive protection from the attacks discussed in this blog through the Next-Generation Firewall and Cortex XDR detecting data exfiltration or connections to suspicious networks.

Related Unit 42 Topics Phishing, BazarLoader

What Is Callback Phishing?

Callback phishing, also referred to as telephone-oriented attack delivery (TOAD), is a social engineering attack that requires a threat actor to interact with the target to accomplish their objectives. This attack style is more resource intensive, but less complex than script-based attacks, and it tends to have a much higher success rate.

In the past, threat actors associated with the Conti group have had great success with this attack style in the BazarCall campaign. Unit 42 has been tracking these types of attacks since 2021. Early iterations of this attack focused on tricking the victim into downloading the BazarLoader malware using documents with malicious macros.

This new campaign, which Sygnia has attributed to a threat actor dubbed "Luna Moth," does away with the malware portion of the attack. In this campaign, attackers use legitimate and trusted systems management tools to interact directly with a victim’s computer, to manually exfiltrate data to be used for extortion. As these tools are not malicious, they’re not likely to be flagged by traditional antivirus products.

Please note that the tools named in this post are legitimate. Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not imply a flaw or malicious quality to the legitimate product being abused.

The Typical Callback Phishing Attack Chain

The initial lure of this campaign is a phishing email to a corporate email address with an attached invoice indicating the recipient’s credit card has been charged for a service, usually for an amount under $1,000. People are less likely to question strange invoices when they are for relatively small amounts. However, if people targeted by these types of attacks reported these invoices to their organization’s purchasing department, the organization might be better able to spot the attack, particularly if a number of individuals report similar messages.

The phishing email is personalized to the recipient, contains no malware and is sent using a legitimate email service. These phishing emails also have an invoice attached as a PDF file. These features make a phishing email less likely to be intercepted by most email protection platforms.

The attached invoice includes a unique ID and phone number, often written with extra characters or formatting to prevent data loss prevention (DLP) platforms from recognizing it. When the recipient calls the number, they are routed to a threat actor-controlled call center and connected to a live agent.

Under the guise of canceling the subscription, the threat actor agent guides the caller through downloading and running a remote support tool to allow the attacker to manage the victim’s computer. This step usually generates another email from the tool’s vendor to the victim with a link to start the support session.

The attacker then downloads and installs a remote administration tool that allows them to achieve persistence. If the victim does not have administrative rights on their computer, the attacker will skip this step and move directly to finding files for exfiltration.

The attacker will then seek to identify valuable information on the victim’s computer and connected file shares, and they will quietly exfiltrate it to a server they control using a file transfer tool.

In this way, the threat actor is able to compromise organizational assets through a social engineering attack on an individual.

After the data is stolen, the attacker sends an extortion email demanding victims pay a fee or else the attacker will release the stolen information. If the victim does not establish contact with the attackers, they will follow up with more aggressive demands. Ultimately, attackers will threaten to contact victims’ customers and clients identified through the stolen data, to increase the pressure to comply.

Luna Moth Campaign Analysis

Unit 42 has responded to multiple cases related to a single campaign that occurred from mid-May to late October 2022. ADVIntel attributes this campaign to a threat actor dubbed Silent Ransom with ties to Conti. While Unit 42 cannot confirm Silent Ransom’s tie to Conti at this time, we are monitoring this closely for attribution.

These cases show a clear evolution of tactics that suggests the threat actor is continuing to improve the efficiency of their attack. Cases analyzed at the beginning of the campaign targeted individuals at small- and medium-sized businesses in the legal industry. In contrast, cases later in the campaign indicate a shift in victimology to include individuals at larger targets in the retail sector.

During the initial campaign, the phishing email frequently originated from an address using the format FirstName.LastName.[SpoofedBusiness]@gmail[.]com as seen in Figure 1. The attacker often spoofs the names of obscure athletes for these email addresses.

Unit 42 has also observed emails with the format [RandomWords]@outlook[.]co.th.

Phishing image, with subject line including "thank you for subscribing". Body of the email indicates that the subscription will be activated and paid in 24 hours. It also instructs the target to look at the attached invoice if they have any problems, and directs them to call their "customer support" number. The scheme, used by Luna Moth, is known as callback phishing.
Figure 1. Redacted phishing email.

The wording in the body of the phishing email has changed throughout the campaign. This was likely done to thwart email protection platforms. Regardless of what wording was used, the email always indicated the victim is responsible for the charges detailed in the attached invoice.

PDF documents containing an invoice number were attached to the phishing emails. Unit 42 observed fake invoices spoofing both an online class platform and a health club aggregator in this campaign.

Early incidents used a logo from one of the spoofed businesses at the top of the invoice. Later cases replaced this with the simple header welcoming the target to the second spoofed business on a plain blue background, as shown in Figure 2. Each invoice features a nine- or 10-digit confirmation number near the top, which is also incorporated into the filename. When the recipient contacts the threat actor, this confirmation number is used to identify them.

Image of the fake invoice file from later campaigns including the confirmation number and instructions for canceling the "subscription," urging the target to act within 36 hours. The fake invoice was used by Luna Moth as part of a callback phishing campaign.
Figure 2. Redacted fake invoice.

Early iterations of the extortion campaign recycled phone numbers, but later attacks either used a unique phone number per victim, or victims would be presented with a large pool of available phone numbers in the invoice.

The attacker registered all of the numbers they used via a Voice over IP (VoIP) provider. When the victim called one of the attacker’s numbers, they were placed into a queue and eventually connected with an agent who sent a remote assist invitation for the remote support tool Zoho Assist.

The footer of these invitation emails (shown in Figure 3) revealed the email address the threat actor used to register with Zoho. In most incidents, the attacker chose an address from an encrypted email service provider to masquerade as the same vendor used in the fake invoice.

Image showing a remote assist invitation for the remote support tool used by the Luna Moth threat group in their callback phishing campaign.
Figure 3. Redacted remote assistance invitation.

Once the victim connected to the session, the attacker took control of their keyboard and mouse, enabled clipboard access, and blanked out the screen to hide their actions.

Once the attacker blanked the screen, they installed remote support software Syncro for persistence and open source file management tools Rclone or WinSCP for exfiltration. Early cases also included remote management tools Atera and Splashtop, but recently the attacker appears to have tightened their toolset.

In cases where the victim did not have administrative rights to their operating system, the attacker skipped installing software to establish persistence. Attackers instead downloaded and executed WinSCP Portable, which does not require administrative privileges and is able to run within the user’s security context.

In cases where the attacker established persistence, exfiltration occurred hours to weeks after initial contact. Otherwise, the attacker only exfiltrated what they could during the call. The attacker exfiltrated data shortly before the attack.

The domains used early in the campaign were random words with a top-level domain (TLD) of .xyz. Later in the campaign, domains consistently followed the format of [5 letters].xyz. All observed domains fell into the 192.236.128[.]0/17 network range.

Exfiltration was followed with an extortion email, as shown in Figure 4. Like in other templates used in this campaign, the wording and format in the extortion email has evolved over time. In the cases Unit 42 investigated, the attacker claimed to have exfiltrated data in amounts ranging from a few gigabytes to over a terabyte.

Extortion email with subject line including "stole information and confidential data." In the body of the email, attackers take credit for stealing proprietary and confidential data, and indicate that they will leak this data to clients as well as the attackers' website and social media if they are not paid. They also indicate they will provide evidence of having deleted the data, though this behavior was not seen in all incidents.
Figure 4. Redacted extortion email.

The threat actor created unique Bitcoin wallets for each victim’s extortion payments. These wallets contained only two or three transactions and were emptied immediately after funding.

Attacker’s monetary demands ranged from 2-78 BTC. They researched the target organization’s revenue and used it to justify this extortion amount. However, attackers were quick to offer discounts of approximately 25% for prompt payment.

Paying the attacker did not guarantee they would follow through with their promises. At times they stopped responding after confirming they had received payment, and did not follow through with negotiated commitments to provide proof of deletion.

Prevention and Detection

The threat actors behind this campaign have taken great pains to avoid all non-essential tools and malware, to minimize the potential for detection. Since there are very few early indicators that a victim is under attack, employee cybersecurity awareness training is the first line of defense.

People should always be cautious of messages that invoke fear or a sense of urgency. Do not respond directly to suspicious invoices. Contact the requester directly via the channels made available on the vendor’s official website. People should also consult internal support channels before downloading or installing software on their corporate computers.

The second line of defense against this attack type is a robust security technology stack designed to detect behavioral anomalies in the environment. Palo Alto Networks customers receive protection from the attacks discussed in this blog through the Next-Generation Firewall and Cortex XDR detecting data exfiltration or connections to suspicious networks.

Conclusion

Unit 42 expects callback phishing attacks to increase in popularity due to the low per-target cost, low risk of detection and fast monetization. While groups that can establish infrastructure to handle inbound calls and identify sensitive data for exfiltration are likely to dominate the threat landscape initially, a low barrier to entry makes it probable that more threat actors will enter the fray.

Common observables suggest a pervasive multi-month campaign that is actively evolving. Therefore, organizations in currently targeted industries, such as legal and retail, should be particularly vigilant to avoid becoming victims.

All organizations should consider strengthening cybersecurity awareness training programs with a particular focus on unexpected invoices, as well as requests to establish a phone call or to install software. Additionally, expand investments in cybersecurity tools designed to detect and prevent anomalous activity, such as installing unrecognized software or exfiltrating sensitive data.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Additional Resources

 

An AI Based Solution to Detecting the DoubleZero .NET Wiper

Posted on by Wenjun Hu

Executive Summary

Unit 42 researchers introduce a machine learning model that predicts the maliciousness of .NET samples based on specific structures in the file, by analyzing a .NET wiper named DoubleZero. We identify the challenges of detecting this threat through PE structural analysis and conclude by examining the cues picked up by the machine learning model to detect this sample.

While wipers are not necessarily new, the recent discovery of several new wipers associated with the ongoing Russia-Ukraine cyber activity has driven renewed public interest in understanding how to identify and defend against their use.

Palo Alto Networks customers receive protections from .NET malwares with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services, including WildFire and Advanced Threat Prevention.

Related Unit 42 Topics Machine Learning, WildFire, .NET Framework

DoubleZero Wiper

The wiper DoubleZero was revealed to the public by Ukraine CERT in March 2022. It is one of many wipers – including HermeticWiper, IsaacWiper and CaddyWiper – that were apparently targeted against their country.

DoubleZero is implemented in C#, and it is heavily obfuscated. This wiper is capable of typical, non-reversible and destructive actions that include the following:

  • Gaining the highest privilege in the host
  • Hunting down all available targeted files from every volume
  • Destroying targeted files or disk volumes within a short period of time

Unlike HermeticWiper and other wipers that damage the Master Boot Record (MBR) or GUID Partition Table (GPT), DoubleZero only wipes the first 4096 bytes in selected files using the file system driver. We limit our focus on the .NET samples feature engineering, but this Splunk article provides a more in-depth technical analysis of the wiper sample.

SHA256 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe
File size 419.50 KB

Examining the PE File Structure

Researchers have been commonly using Microsoft Windows Portable Executable (PE) file structure to detect PE malware for many years. The thought behind this tactic is that variants of the same malware family can often share similarities in their file structure.

Machine learning models also detect PE malware based on the file structure. To do so, they have historically used PE header characteristics, imports and section attributes to recognize known malware characteristics.

While the .NET PE file structure is based on the PE format, a lot of its functionality is encoded within the .NET specific structures. In the next section, we’ll dive deeper into the .NET structural attributes.

An Inside Look Into .NET files

The .NET open source framework was introduced in 2002 and is available by default in most Microsoft Windows platforms. The framework provides developers with powerful, built-in methods to access the internet, file system and encryption. Having these options already available makes this framework attractive to both system administrators and malware authors.

Microsoft Windows PE loader will already know how to load and execute the .NET sample once the framework is ready, since .NET assembly re-uses the PE file format.

During code generation, the source code for .NET compatible languages is compiled to platform-agnostic Common Intermediate Language (CIL) byte code. A special .NET IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR can be found in the data directory for referencing the Cor20 header, as shown in Figure 1. The Cor20 header (otherwise known as the CLR header) contains .NET specific information like versioning and resource information and the location of the Metadata header. The resources, streams, type references, methods, CIL byte codes and usage of external assemblies are all in the metadata. For a more detailed description, please refer to our article on dotnetfile.

Diagram illustrating the .NET file structure including MZ and PE headers, data directory, and the text section including Cor20 and metadata headers as well as storage streams and CIL byte code,
Figure 1. A simple illustration of .NET file structure.

Unlike most PE files, where dependent libraries and APIs can be found in the import table, for a .NET file the import table contains just one module (the mscoree.dll) and one imported function (_CorExeMain for executables and _CorDllMain for dynamic load libraries). The resources are contained within the .NET storage stream instead of the .rsrc section.

The entry point of the PE header points to the _CorExeMain or _CorDllMain of the mscoree.dll, while the actual entry point can be found in the Cor20 header as shown in Figure 2. Thus, some of the most useful attributes to identify PE malware files do not contain many clues for .NET malware.

Diagram expanding on the Cor20/CLR header, default streams and metadata table
Figure 2. .NET specific structures and the data they hold.

The metadata table contains defined tables for Module, MethodDef and Assembly among others. By examining the .NET file structure, we can see it provides a lot more information about the file as compared to the PE file structure alone. Instead of only using the general PE features for the .NET machine learning solution, we added the data specifically parsed from the structure of .NET samples. These customized features improve the quality of our machine learning solutions.

Applying Machine Learning to .NET Malware Detection

We have trained a machine learning model on custom features learned on the PE file structure, .NET file structure and other file characteristics of .NET samples, as shown in Figure 3.

As .NET is an extremely popular file type in customer environments, it is necessary for us to have a quick turnaround time in case any disruptive false positives emerge. This means that our model’s functionality has to be well understood by researchers, and that the predictions could be reverse engineered.

Because .NET files are so ubiquitous, they also have a highly imbalanced distribution of benign vs. malicious samples. Consequently, the trained model has to ensure that we maintain extremely low false positive rates while retaining detection accuracy.

Diagram of detection workflow taking a sample and extracting features, then model training and evaluation leads to a final model
Figure 3. An overview of our detection workflow.

Detecting the DoubleZero Wiper

The malware sample has a single import, _CorExeMain, from mscoree.dll, consistent with other .NET executable files. It contains only .text and .reloc sections, all of which are native to the PE file format and have fairly low entropy. Hence, there’s not much we can learn from this file’s PE structure.

The CIL bytecode uses obfuscation to hide the string resources that are critical for pattern based detection. It also interleaves random code among actual operations, together with flattened control flow, to make the code harder to follow. However, we can glean a lot about the objective of this malware by observing the imported libraries and associated API calls found in the decompiled code.

The imports System.DirectoryServices.ActiveDirectory and System.Security.AccessControl indicate the intention to interact with the Active Directory and access control attributes of the files.

The regular expression function imported by System.Text.RegularExpressions is used to locate certain files by patterns.

The most significant signs of malicious code usage are the calls to the unmanaged DLL functions. Platform Invoke (P/Invoke) enables the managed codes in .NET to call the unmanaged functions. Calling the lower level APIs directly is a well known anti-analysis technique to evade API hooking by sandbox. The following unmanaged APIs are used in the sample:

  • ntdll.ntopenfile
  • ntdll.ntfscontrolfile
  • ntdll.rtlntstatustodoserror
  • ntdll.rtladjustprivilege
  • kernel32.closehandle
  • kernel32.getfilesizeex
  • kernel32.getlasterror
  • user32.exitwindowsex

In most of the use cases, there are equivalent managed functions in .NET runtime libraries to use. However, this sample intends to operate at a lower level with some of the unmanaged APIs in ntdll.dll.

The target files and the regular expression patterns are surprisingly stored as plain strings, as shown in Figure 4. This possible mistake by the threat actor allows us to get more insights about the objective of the sample.

Decompiled code snippet showing strings stored in plain text
Figure 4. An example decompiled code snippet where the sample uses regular expressions to search the target files.

Though obfuscation exists, we are still able to get the argument FsControlCode for the call to ntdll.NtFsControlFile, which is 0x980c8 = FSCTL_SET_ZERO_DATA. This is how the wiper writes 4K of null bytes to a targeted file that was opened by ntdll.NtOpenFile.

The sample calls ntdll.RtlAdjustPrivilege several times with privileges 9, 17, 18 and 19. These privileges are SeTakeOwnershipPrivilege, SeBackupPrivilege, SeRestorePrivilege and SeShutdownPrivilege respectively. These privileges are used to ensure the wiper has the access right to destroy the target file and reboot the system after all the actions are done.

Unlike HermeticWiper and ransomware like LockBit, DoubleZero doesn’t delete the shadow copies that can possibly be used to recover files from the damage. However, the wiper does kill any process named lsass. Lsass is important to the Windows system, and any application that kills this process is most likely malicious.

The aforementioned file characteristics give us clues that the machine learning model uses to detect the sample. Though obfuscation is more common among malicious .NET files, because the sample uses several unmanaged APIs as well as sensitive target path patterns, these stand out as potentially malicious indicators.

Conclusion

Researchers have been using PE file structure to detect variants within malware families for years, as they often share similarities in their file structure. Despite the .NET framework being well known, it can still be challenging to detect files using this strategy. Some of the most useful attributes for identifying PE malware files don’t offer many clues for identifying .NET malware.

We have highlighted the fundamental difference between .NET and PE samples to help identify where those clues could be hiding. In doing so, we illustrated that machine learning feature engineering can be improved by correctly parsing out the .NET specific data structure.

We also showed that imported libraries, unmanaged API calls and unencrypted strings are the most useful features for detecting .NET malware. While a recent wiper called DoubleZero was analyzed as an example, the features that are important for detecting .NET can be generalized, and this feature can be broadly useful for future research efforts.

Palo Alto Networks customers receive protections from .NET malware with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

Indicators of Compromise

3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe

Additional Resources

DoubleZero Wiper
Threat Update DoubleZero Destructor
HermeticWiper
IsaacWiper and HermeticWizard
CaddyWiper
dotnetfile Open Source Python Library: Parsing .NET PE Files Has Never Been Easier

Network Security Trends: May-July 2022

Posted on by Erica Naone

Executive Summary

Recent May-July 2022 observations of network security trends and exploits used in the wild reveal that attackers have been making use of newly published remote code execution vulnerabilities. In our observations of network security trends, Unit 42 researchers have pinpointed several attacks based on proof-of-concept (PoC) availability and impact. We have detailed below which of these we believe should be on the defender’s radar.

Other insights that could assist defenders include the following:

  • Rankings of the most commonly used attack techniques and the types of vulnerabilities that attackers have recently favored. For example, among 5,976 newly published vulnerabilities, a large portion (almost 11.6%) involves cross-site-scripting.
  • Lists of major vulnerabilities identified by evaluating more than 340 million attack sessions including remote code execution, directory traversal and information disclosure.
  • Insight into how these vulnerabilities are exploited in the wild based on real-world data collected from our Next-Generation Firewalls.
  • Summaries of key trends from May-July 2022.
  • Analysis of the most recently published vulnerabilities, including the severity and attack origin distribution.
  • Classification of these vulnerabilities to provide a clear view of the prevalence of the different types, such as cross-site scripting or denial-of-service.
  • Lists of the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.

Palo Alto Networks customers receive protections from the vulnerabilities discussed here through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire, Advanced URL Filtering and Cortex XDR.

Types of Attacks and Vulnerabilities Covered Cross-site scripting, denial of service, information disclosure, buffer overflow, privilege escalation, memory corruption, code execution, SQL injection, out-of-bounds read, cross-site request forgery, directory traversal, command injection, improper authentication, security feature bypass
Related Unit 42 Topics Network Security Trends, exploits in the wild, attack analysis

Analysis of Published Vulnerabilities, May-July 2022

From May-July 2022, a total of 5,976 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, availability of working proof-of-concept (PoC) code, and vulnerability categories.

How Severe Are the Latest Vulnerabilities?

To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable PoCs available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the 5,976 CVEs that have an assigned severity score of medium or higher can be seen in the following table:

Severity Count Ratio PoC Availability Change
Critical 1133 19.0% 5.5% -2.3%
High 2399 40.1% 3.8% -1.0%
Medium 2444 40.9% 3.4% -0.2%

Table 1. Severity distribution for CVEs registered May-July 2022, including only those rated medium-critical.

Medium severity: 40.9%, high severity: 40.1%, critical severity: 19.0%
Figure 1. Severity distribution for CVEs registered May-July 2022, including only those rated medium-critical.

Our classification of vulnerabilities is based on CVSS v3 scores. Many conditions must be met to rate a vulnerability as critical, so there are very few at this level. One of the common factors for rating a vulnerability at this level is having a working PoC available. To be considered critical, vulnerabilities generally have low attack complexity, and it is often easy to create a PoC to exploit them.

In the period discussed, the critical-severity ratios increased while high-severity and medium-severity PoC ratios decreased slightly.

Vulnerability Category Distribution

It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 23.5% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 76.5% are remote vulnerabilities, which can be exploited over a network. This means that most newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.

In Figure 2, the most common vulnerability types are ranked by how prevalent they were among the most recent set of published vulnerabilities.

Red = critical, yellow = high, blue = medium. In order from most to least prevalent vulnerability category: cross-site scripting, SQL injection, information disclosure, privilege escalation, denial of service, traversal, command injection, code execution, out-of-bounds write, buffer overflow, use-after-free, improper authentication.
Figure 2. Vulnerability category distribution for CVEs registered May-July 2022.

Cross-site scripting remains the most reported vulnerability during May-July 2022. We also saw that the prevalence of SQL injection vulnerabilities increased during this time, and many of the vulnerabilities in this category are ranked critical. The number of SQL injection and cross-site scripting vulnerabilities slightly increased and out-of-bound vulnerabilities decreased. Most of the recently published cross-site scripting and information disclosure attacks are usually at medium or high severity (rather than critical).

Red = critical, yellow = high, blue = medium. In order from most to least prevalent vulnerability category: cross-site scripting, SQL injection, information disclosure, privilege escalation, denial of service, traversal, command injection, code execution, out-of-bounds write, buffer overflow, use-after-free.
Figure 3. Vulnerability category distribution compared with the previous quarter.

Network Security Trends: Analysis of Exploits in the Wild, May-July 2022

Data Collection

By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from May-July 2022. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 340 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.

How Severe Were the Attacks Exploited in the Wild?

To arrive at 340 million valid malicious sessions, we excluded the original set of low-severity signature triggers used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a medium and higher severity ranking (based on the CVSS v3 Score) as a verified attack.

Network security trends in attack severity. Medium severity: 47.2%, high severity: 21.5%, critical severity: 31.3%
Figure 4. Attack severity distribution, May-July 2022, including only medium-critical vulnerabilities.

Figure 4 shows the ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows a decrease in critical- and high-severity attacks and an increase in medium-severity attacks. However, we still focus more on critical-severity attacks because of their greater potential impact. Many published vulnerabilities are scored medium severity, but attackers typically leverage more severe vulnerabilities for exploits. Defenders should prioritize preventing and mitigating high- and critical-severity network attacks.

Network security trends in vulnerability severity compared with the previous quarter. Red=critical, yellow = high, blue = medium. Medium shows an increase of over 20% since last quarter, high shows less than 10% decrease, and critical shows almost 20% decrease.
Figure 5. Vulnerability severity distribution compared with the previous quarter.

When Did the Network Attacks Occur?

Red = critical, yellow = high, blue = medium, green = total. The bar graph shows attack severity distribution by millions of sessions divided weekly between May-July 2022.
Figure 6. Severity of exploits in the wild measured weekly from May-July 2022.

During May-July 2022, attackers gradually increased their exploitation of vulnerabilities of medium severity, and the number of attacks gradually increased (the last set of data records eight days of attack volume instead of seven days).

As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-22. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.

Network security trends in observed attacks, categorized by the year in which the exploited CVE was disclosed. Red = CVEs disclosed 2021-2022, yellow = CVEs disclosed 2019-2020, blue = CVEs disclosed 2016-2018, green = CVEs disclosed 2010-2015, orange = CVEs disclosed prior to 2010. The bar graph shows attack severity distribution by millions of sessions divided weekly between May-July 2022.
Figure 7. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from May-July 2022.

Exploits in the Wild, May-July 2022: A Detailed View of Network Security Trends

Attack Category Distribution

We classified each network attack by category and organized them in terms of prevalence. In the period discussed, remote code execution ranks first, followed by information disclosure. Attackers typically want to gain as much information and control as possible over the systems they target. Traversal attacks decreased this quarter.

Network security trends in attack category and severity. Red = critical, yellow = high, blue = medium. Attack categories in order of prevalence: remote code execution, information disclosure, traversal, cross-site scripting, DOS, memory corruption, buffer overflow, hacktool, improper authentication, exploit-kit, command injection, and privilege escalation.
Figure 8. Attack category and severity, May-July 2022.
Red = critical, yellow = high, blue = medium. Attack categories in order of prevalence: remote code execution, information disclosure, traversal, cross-site scripting, DOS, memory corruption, buffer overflow, hacktool, improper authentication, and exploit-kit.
Figure 9. Attack category distribution compared to the previous quarter.

Where Did the Attacks Originate?

After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by Germany then the Netherlands. Attacks from the Netherlands and Romania increased significantly this quarter. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.

Network security trends pie chart showing locations of observed attacks. United States = 49.6%, Germany = 17.2%, The Netherlands = 10.2%, France = 5.7%, Romania = 3.3%, Canada = 1.4%, Russian Federation = 1.3%, United Kingdom = 1.1%, China = 0.9%, Others = 9.4%
Figure 10. Locations ranked in terms of how frequently they were the origin of observed attacks from May-July 2022.
Bar chart showing percentage change in location of observed attacks. United States = >20% decrease, Germany = >10% increase, The Netherlands = <10% increase, France = <5 increase, Romania = <5% increase, Canada = ~1% increase, Russian Federation = >1% decrease, United Kingdom = >1% increase, China = <1% decrease, Others = >1% decrease
Figure 11. Attack originate distribution compared to the previous quarter.
Network security trends heat map where attacks appear to originate. The United States is deepest red, followed by Germany and the Netherlands
Figure 12. Attack geolocation distribution from May-July 2022.

Conclusion

The vulnerabilities disclosed from May-July 2022 indicate that web applications remain popular targets for attackers, and that critical vulnerabilities are more likely to have PoCs publicly available.

In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. Attackers continue to make a concerted effort to expand their tool kit of exploits whenever possible.

While cybercriminals will never cease their malicious activities, Palo Alto Networks customers receive protections from the attacks discussed in this blog through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire and Advanced URL Filtering, as well as through Cortex XDR.

To further mitigate any risks to your network:

  • Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
  • Run a Security Lifecycle Review to get a consolidated view of your largest threats and if you have coverage to prevent them.
  • Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g. versions 8638 and above).

Additional Resources

Typhon Reborn With New Capabilities

Posted on by Riley Porter

Executive Summary

In early August 2022, Cyble Research Labs (a cybercrime monitoring service) uncovered a new crypto miner/stealer for hire that the malware author named Typhon Stealer. Shortly thereafter, they released an updated version called Typhon Reborn. Both versions have the ability to steal crypto wallets, monitor keystrokes in sensitive applications and evade antivirus products.

This new version has increased anti-analysis techniques and more malicious features. The threat actors have also improved their stealer and file grabber features.

Palo Alto Networks customers receive protections from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

Malware Sale and Advertisements

The threat actors behind Typhon Stealer were advertising their creation through an underground website as shown in Figure 1, while providing development and distribution updates through their existing Telegram channel.

Website post showing the feature set for Typhon Stealer v.1.1.0 - July 17 update.
Figure 1. Screenshot of underground website for older version of Typhon Stealer.

Typhon Reborn: Stealer With New Features

The original version of Typhon Stealer was updated and released with the new name of “Typhon Reborn.” This new version has increased anti-analysis techniques and it was modified to improve the stealer and file grabber features.

Figure 2 is a screenshot of the latest offerings, listed in a private Telegram channel.

Telegram message listing new features and changes in Typhon Reborn.
Figure 2.Typhon Reborn’s new features as listed in a Telegram message.

In their Telegram channel, the malware author stated that the current price for this stealer is $100 for a lifetime subscription, as shown in Figure 3. They also have claimed that the final compressed Typhon Reborn payload size has been reduced to around 2.3 MB depending on the stealer's build configuration.

Figure 3.Telegram post stating Typhon Reborn’s price.
Figure 3.Telegram post stating Typhon Reborn’s price.

In the Telegram post, we see that the author has added multiple new features and disabled a few old features (e.g. keylogger, clipper miner, etc.). These differences are visible by viewing the code blocks in Typhon 1.2 and the latest Reborn version. Figure 4 shows modules for block list and CryptoApps are present in the latest version.

Module list for Typhon 1.2, to illustrate which have been added or removed between versions
Figure 4a. Typhon 1.2 code block showing available features. This can be compared to the Typhon Reborn code block in Figure 4b.
Module list for Typhon Reborn, to illustrate which have been added or removed between versions
Figure 4b. Typhon Reborn code block showing available features. This can be compared to the Typhon 1.2 code block in Figure 4a.

Technical Analysis

Typhon Reborn was released with multiple new features and configurable options. These new features include block listed usernames and countries, new message clients and a crypto-extension stealer for Google Chrome and Microsoft Edge. The author also removed a few existing features, including the keylogging ability as well as the clipboard stealing and crypto mining features.

Keylogging and crypto mining code is typically easy to detect in dynamic analysis platforms. We speculate the removal of these features was to lower the chances of antivirus detections. The author stated in his release notes that the features that were removed, would be moved to their own projects in the future.

Anti-Analysis Techniques

All of Typhon Reborn’s new anti-analysis checks, once triggered, run the cleverly named MeltSelf method, as shown in Figure 5. This method kills the threat’s process and deletes itself from the disk.

Typhon Reborn’s new anti-analysis techniques include the following:

  • Checking for debugging arguments
  • Detecting virtual machines
  • Checking for debuggers
  • Checking the size of the physical disk
  • Checking for well known analysis processes (blocklisting)
  • Checking for well known sandbox usernames
  • Checking for victim country
Anti-analysis checks that will run "MeltSelf," which terminates the threat's process and deletes itself from disk if it's triggered.
Figure 5. Anti-analysis functions.

Command Line Debugger

Typhon Reborn also checks the command line arguments included to launch the stealer. If the command line argument contains the –-debug keyword, the stealer will “MeltSelf,” as shown in Figure 6.

Typhon Reborn checks the command line arguments included to launch the stealer, for the keyword –-debug.
Figure 6. Detection of command line debugging.

Disk Size for Various Operating Systems

While a disk size check is not a new evasion in general, it is a new feature added to Typhon Reborn (shown in Figure 7). It checks to ensure the disk space is of a certain size based on the operating system. If the current disk is below 30 GB for Windows versions 7 and 10, the stealer again runs “MeltSelf.”

Windows 11 70 GB
Windows 10 30 GB
Windows 7 30 GB

Table 1. The stealer checks disk space based on the operating system.

Code snippet that checks to ensure the disk space is over a certain size based on the operating system.
Figure 7. Anti-analysis check based on disk size, on various operating systems.

Block List Processes

Typhon Reborn has included a larger list of potential analysis processes to check for. The process names included are all well known analysis tools, and if detected, Typhon Reborn will “MeltSelf”

ollydbg

processhacker

tcpview

autoruns

de4dot

ilspy

dnspy

autorunsc

filemon

procmon

regmon

idaq

 idaq64

immunitydebugger

wireshark

dumpcap

hookexplorer

lordpe

petools

resourcehacker

x32dbg

x64dbg

fiddler

Table 2. Block list of processes.

Block List of Usernames

Typhon Reborn has also added a username check to its anti-analysis techniques as shown in Figure 8. The usernames listed below are known to be used in various public and private sandboxes to execute malware. If the malware is executed under any of the following usernames, the malware calls “MeltSelf.”

IT-ADMIN   

Paul Jones 

WALKER     

Sandbox    

Timmy      

John Doe   

CurrentUser

 sand box

maltest

malware

virus

sandbox

Emily

test

Table 3. Block list of usernames.

Code snippet to check for usernames known to be used in various public and private sandboxes.
Figure 8. Check for block list of usernames.

Block Listing Commonwealth of Independent States (CIS) Countries

Typhon Reborn’s new victim country code check enables the attacker to configure locations of machines they do not wish to execute on. During execution of the stealer, the location code checks rely on the third party service ipinfo[.]json to determine the victim’s physical location. If this service is unavailable, the victim's time zone code is used to determine the country of origin instead. If the victim’s machine is located in one of the CIS countries, the stealer will cease execution, as shown in Figure 9.

Code snippet to check if the victim’s machine is located in one of the CIS countries, which will run "MeltSelf" if it's triggered.
Figure 9. Check for block listed countries including those in the CIS.

The samples we were able to acquire did not use this feature. However, the code is supported and configurable at build time.

Checking for a Single Instance

Malware checking is a common technique to make sure only a single instance is running, to avoid multiple instances competing for system resources. Typhon Reborn also implements this check.

Typhon Reborn specifically checks to see if the executable's name is in the startup path. If it is, the malware will “MeltSelf.”

Additional Features in New Version

Typhon Reborn removed the keylogger, clipper, miner and worm features that had been available in previous versions. While it is not explicitly stated why the malware author removed these features from the current codebase, we speculate that they were moved to separate projects to be available for an additional fee in future versions.

Crypto-Extension Stealer for Microsoft Edge and Google Chrome

The previous version of this stealer supported stealing cryptocurrency wallet files, but Typhon Reborn has extended this feature to specifically target Google Chrome and Microsoft Edge crypto app browser extensions.

Code snippet that checks for the presence of cryptocurrency wallet extensions in Google Chrome browser.
Figure 10. Crypto extension for Chrome.

Some of the extensions targeted by Typhon Reborn include Binance, Bitapp, Coin98 and more. Also, they specifically target Microsoft Edge’s web browser extensions for Yoroi, Metamask and Rabet wallets.

Code snippet that checks for the presence of cryptocurrency wallet extensions in Microsoft Edge browser.
Figure 11. Crypto extensions for Microsoft Edge browser.

User and Network Details

Typhon Reborn is now capable of gathering additional victim data, including the following:

  • Machine username
  • Operating system information
  • Antivirus software used
  • Wireless network information
  • Network interface data
  • Language

Below is a screenshot of the data that is scraped and sent to the malware author’s Telegram channel.

Code snippet to format user and network data for exfiltration to the threat operator.
Figure 12. Formatting user and network data.

Typhon Reborn also gathers extended Wi-Fi information. Most of this data is fairly innocuous, such as language, computer name, OS and antivirus if present. However, this version of Typhon Reborn extracts all wireless networking passwords from the victim’s host machine and writes those in a Wifi Passwords.txt file.

Code snippet that gathers victims' Wi-Fi information and writes it to "Wifi Passwords.txt" file.
Figure 13. Stealing Wi-Fi passwords.

The techniques Typhon Stealer uses for data exfiltration have not changed from its previous version. However, we included the screenshot below to illustrate how the malware author is leveraging Telegram’s API and infrastructure to exfiltrate all data stolen by Typhon Reborn.

"Code snippet that illustrates how the malware author is leveraging Telegram’s API and infrastructure to exfiltrate data. "
Figure 14. Example of content sent over Telegram API to attacker.

Conclusion

Typhon Stealer provided threat actors with an easy to use, configurable builder for hire. They are continuing to update their code to enhance their tools and techniques to evade security systems and exfiltrate data smoothly.

Their configurable builders lower the required technical skill set for potential clients. Typhon Reborn’s new anti-analysis techniques are evolving along industry lines, becoming more effective in the evasion tactics while broadening their toolset for stealing victim data.

The longer their malware can run without detection, the more valuable the malware is. With the addition of new cryptocurrency wallet targets, the stealer has shown that there are clearly still more sources of lucrative data, and thus a thriving market for malware for hire services.

Palo Alto Networks customers receive protections from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.

Indicators of Compromise

A12933ab47993f5b6d09bec935163c7f077576a8b7b8362e397fe4f1ce4e791c  Typhon Reborn Stealer
48133d1aaf1a47f63ec73781f6a2b085b28174895b5865b8993487daec373e0a Typhon Stealer

Unit 42 Finds Three Vulnerabilities in OpenLiteSpeed Web Server

Posted on by Aviv Sasson

Executive Summary

The Unit 42 research team has researched and discovered three different vulnerabilities in the open source OpenLiteSpeed Web Server. These vulnerabilities also affect the enterprise version, LiteSpeed Web Server. By chaining and exploiting the vulnerabilities, adversaries could compromise the web server and gain fully privileged remote code execution. The vulnerabilities discovered include:

  1. Remote Code Execution (CVE-2022-0073) rated High severity (CVSS 8.8)
  2. Privilege Escalation (CVE-2022-0074) rated High severity (CVSS 8.8)
  3. Directory Traversal (CVE-2022-0072) rated Medium severity (CVSS 5.8)

OpenLiteSpeed is the Open Source edition of LiteSpeed Web Server Enterprise, which is developed and maintained by LiteSpeed Technologies. LiteSpeed Web Server is ranked the sixth most popular web server. Analysis from Palo Alto Networks Cortex Xpanse and Shodan reveals that LiteSpeed serves roughly 2% of all Web Server applications, with nearly 1.9 million unique servers globally.

Unit 42 responsibly disclosed the vulnerabilities to LiteSpeed Technologies with suggested remediation on Oct. 4, 2022. LiteSpeed Technologies swiftly released a patch version (v1.7.16.1) on Oct. 18, 2022, to mitigate the reported vulnerabilities.

Organizations using OpenLiteSpeed versions 1.5.11 up to 1.7.16 and LiteSpeed versions 5.4.6 up to 6.0.11 are advised to update their software to the latest matching release – v1.7.16.1 and 6.0.12.

Palo Alto Networks customers using Prisma Cloud WAAS or Next-Generation Firewalls with Advanced Threat Prevention receive protection from these vulnerabilities by new rules and signatures that block the attack.

Related Unit 42 Topics Containers

Background

LiteSpeed is a performance-focused web server. According to our findings there are 1.9 million internet facing LiteSpeed Server instances online.

As part of our initiative to contribute to the community to improve security and increase security awareness, we decided to audit OpenLiteSpeed, which is the open source version of the LiteSpeed Web Server.

We tried to imitate the actions of an adversary and engaged in research with the intention of finding vulnerabilities and disclosing them to the vendor. This research has resulted in finding three vulnerabilities that affect both the enterprise and open source solutions. These could be chained and exploited by an adversary who has the credentials for the admin dashboard, in order to gain privileged code execution on vulnerable components.

Remote Code Execution

This vulnerability has been assigned the CVE ID of CVE-2022-0073.

At the first stage of the attack, we tried to gain remote code execution and found that the OpenLiteSpeed Web Server admin dashboard is vulnerable to a command injection vulnerability. A threat actor who managed to gain the credentials to the dashboard, whether by brute force attacks or social engineering, could exploit the vulnerability in order to execute code on the server.

The vulnerability exists in the External App Command field, which allows users to specify a command that will be executed when the server starts.

This functionality is considered dangerous and therefore mitigations for abusing it were implemented. We managed to bypass the mitigations and abuse this functionality to download and execute a malicious file on the server with the privileges of the user nobody, which is an unprivileged user that traditionally exists in Linux machines.

Privilege Escalation

This vulnerability has been assigned the CVE ID of CVE-2022-0074.

After gaining code execution on the server we wanted to take it a step further and escalate our privileges from nobody to root.

While exploring the OpenLiteSpeed Docker image as nobody, we found a misconfiguration in the PATH environment variable that could be exploited into a privilege escalation using the CWE untrusted search path.

When executing a binary with a relative path, the operating system will look at the PATH variable, which contains a list of directories. It will then search for that binary in the listed folders, in the same order that the directories are presented.

The issue in this case was that the second directory in PATH was /usr/local/bin, which is a directory that the user nobody controls.

This leads to a situation where an attacker could execute code as an unprivileged user (such as nobody) to place a malicious file and disguise it as a legitimate binary in /usr/local/bin, with the intention for it to be executed by highly privileged processes because it is in the second directory on the PATH environment variable.

We were able to exploit this by abusing the script entrypoint.sh as shown in Figure 1, which runs as root and executes the binary grep repeatedly.

Code snippet from the entrypoint.sh script which runs as root and executes the binary grep repeatedly.
Figure 1. Entrypoint.sh script showing vulnerable usage of the grep command.

By chaining these vulnerabilities, we were able to gain remote code execution and escalate our privileges to root, as shown in Figure 2.

Code snippet chaining the vulnerabilities to gain remote code execution and escalate privileges to root.
Figure 2. Proof of successful exploitation.

This vulnerability requires the controlled user to have write permissions to /usr/local/bin, which is usually not the case by default. In the OpenLiteSpeed docker container, this directory is writable by the user nobody by default.

Directory Traversal

This vulnerability has been assigned the CVE ID of CVE-2022-0072.

The last issue we found was a directory traversal vulnerability that could allow an attacker to bypass security measures and access forbidden files. An attacker that compromised the server could create a secret backdoor and exploit the vulnerability to access it.

When browsing in LiteSpeed, the server will make sure that clients only access endpoints that should be visible to them. It does so by verifying that the requested URL does not contain characters that will result in a directory traversal and thus allow them to access forbidden endpoints.

This verification is done by two regular expressions, on lines 2060 and 2061. We managed to bypass those regular expression verifications, and we were able to access paths that we were not able to access initially.

Exploitation of this vulnerability allows adversaries to access any file in the web root directory, but it is limited only to that directory.

Mitigations

Unit 42 responsibly disclosed the vulnerabilities to LiteSpeed Technologies with suggested remediation on Oct. 4, 2022. LiteSpeed Technologies has released a patch version v1.7.16.1 for OpenLiteSpeed and 6.0.12 for LiteSpeed, which addresses the disclosed vulnerabilities.

The command injection mitigation regex that we previously mentioned was changed to include binaries such as curl, fetch and wget to prevent downloading external scripts to mitigate CVE-2022-0073.

The rewrite condition regexes previously mentioned were changed in order to mitigate CVE-2022-0072.

The ols-dockerfiles repository was patched as well, to set the PATH variable with the user nobody’s controlled path positioned last, preventing binary execution hijacking to mitigate CVE-2022-0074.

Conclusion

Web technologies, including web servers, have come a long way in the last few decades. They have become much more secure, but vulnerabilities are still being found as technologies are still evolving at a rapid pace.

As part of the commitment of Palo Alto Networks to advancing cloud security, we actively invest in the public cloud and web application research that includes advanced threat modeling and vulnerability testing of cloud platforms, web servers and related technologies

Palo Alto Networks customers receive protection from this kind of attack through the following products and services:

  1. Prisma Cloud WAAS customers received a virtual patch designated to mitigate this threat, and they remain protected until patches are applied to vulnerable assets.
  2. Next-Generation Firewalls with Advanced Threat Prevention signatures 93190 and 93191 can block the aforementioned attacks.

We'd like to thank LiteSpeed Technologies for quickly responding and patching the reported issues, and professionally handling the disclosure process.

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Updated Nov. 15, 2022, to adjust authorship to focus on the discoverer of the vulnerabilities.

Cobalt Strike Analysis and Tutorial: Identifying Beacon Team Servers in the Wild

Posted on by Durgesh Sangvikar

Executive Summary

As Cobalt Strike remains a premier post-exploitation tool for malicious actors trying to evade threat detection, new techniques are needed to identify its Team Servers. To this end, we present new techniques that leverage active probing and network fingerprint technology. This is a fundamental change from previous passive traffic detection approaches.

Over the course of our Unit 42 blog series covering the adversary framework tool Cobalt Strike, we document the encoding and encryption techniques of its HTTP transactions. Specifically, we analyzed the advanced, flexible traffic profiles used by Cobalt Strike’s Beacon command-and-control (C2) communication to evade detection by defenders.

Beacon implants communicate to an attacker-controlled application called Team Server. Team Server and the Beacon’s C2 traffic allow adversaries to easily and effectively cloak malicious traffic as normal, benign traffic. This is made possible by a modular, extensible domain-specific language called Malleable C2.

Sanctioned adversaries (such as Red/Blue team members, pentesters and ethical hackers) as well as malicious actors can use premade or custom Malleable C2 profiles. These profiles can be exceedingly difficult to continually develop traditional defenses against, such as conventional firewall threat prevention.

In previous approaches, Team Server detections could only be made after a Beacon binary was implanted on a victim’s system and attempted to “phone home” to an attacker-controlled server. Our new techniques can proactively detect Team Servers in the wild before an active C2 connection from a victim’s system has been initialized.

We will also demonstrate the following:

  • How Team Servers behave when they receive specially-crafted HTTP requests
  • What kind of network fingerprint can be inferred and with what confidence
  • Details of some real-life malicious C2 between Beacon and Team Server in the wild

Palo Alto Networks customers receive protections from and mitigations for Cobalt Strike Beacon and Team Server C2 communication in the following ways:

Related Unit 42 Topics Cobalt Strike, C2, Tutorials

Probing and Fingerprint Identification Technology

The Cobalt Strike Team Server, also known as CS Team Server, is the centralized C2 application for a Beacon and its operator(s). It accepts client connections, orchestrates remote commands to Beacon implants, provides UI management, and various other functions.

During our research and development of Advanced Threat Prevention’s inline deep learning detection for Cobalt Strike traffic, we began experimenting with forging C2 requests to suspected malicious Team Servers on the Internet. Through our analysis of attacker-controlled server responses, we developed a variety of techniques to classify previously undetected Cobalt Strike Team Servers before an attack can occur.

In the following sections, we share our findings on the following identification techniques:

Active Probing Over HTTP HTTP/S OPTIONS Request and Response Fingerprint

The Team Server is a Linux program running an HTTP server configured to respond to a variety of HTTP requests. When the server receives requests with the HTTP OPTIONS method, the server will return HTTP status code 200 and Content-Length: 0.

Figure 1 shows an HTTP request and response to a Team Server. The URI provided in an HTTP OPTIONS request is disregarded as the same response is returned regardless of URI.

Image showing an HTTP OPTIONS request and HTTP 200 response to a Team Server.
Figure 1. HTTP OPTIONS request with HTTP 200 response.

HTTP/HTTPs GET Request and Response Fingerprint

When a Team Server starts, the HTTP server exposes certain URIs. Figure 2 shows the list of URIs.

The URLs stager and stager64 are masked if the profile has the set host_stage "false"; option set. The HTTP server will return HTTP status code 404 if the URI begins with a forward slash (/).

Image showing a list of URIs from the Team Server, including associated port number (80), type (beacon), and descriptions.
Figure 2. List of the URIs from the Team Server.
Request to Stager URI

When a user sends the following HTTP request to a Team Server, the server will return the 32-bit Beacon binary to the client. Figure 3 shows the HTTP request and response. Note the lack of a forward slash (/) at the beginning of the URI path.

Image showing an HTTP GET request and response for a 32-bit Beacon payload.
Figure 3. HTTP GET request and response for a 32-bit Beacon payload.
Request to Stager64 URI

To receive a 64-bit Beacon payload, a user must send an HTTP GET request to the URI stager64. Figure 4 shows the HTTP request and response for a 64-bit Beacon payload.

Image showing an HTTP GET request and response for a 64-bit Beacon payload.
Figure 4. HTTP GET request and response for a 64-bit Beacon payload.
Request to Beacon.http-get URI

Certain preset URI paths can be configured in the Malleable C2 profile to serve static data. If a user sends a GET request to the URI beacon.http-get, the Team Server responds with the data that has been specified in its profile. Specifically, it sends the output section within the server tag of the http-get configuration.

If the output section only contains the command print;, the server responds with HTTP status code 200 and Content-Length: 0. Figure 5 shows the HTTP request and response with the default profile.

Image showing an HTTP request and response with the default profile.
Figure 5. HTTP request and response with default profile.

If Team Server initializes with the Malleable C2 Gmail profile, the server responds with static data presented as described above. In this profile, GET requests to beacon.http-get result in a response containing a JavaScript payload.

Figure 6 shows the HTTP request and response generated by a Beacon session preset with the Gmail Malleable C2 profile.

Image showing an HTTP request and response with the Gmail Malleable C2 Gmail profile.
Figure 6. HTTP request and response configured with the Gmail Malleable C2 Gmail profile.
Request to Beacon.http-post URI

Team Server’s behavior is the same for a GET request to the URI beacon.http-post as it is for the URI beacon.http-get. Figure 7 shows the HTTP request and response for a Team Server instance that initializes with the default Malleable C2 profile.

Image showing an HTTP request and response for a Team Server instance that initializes with the default Malleable C2 profile.
Figure 7. HTTP request and response configured with the default Malleable C2 profile.

Figure 8 shows an HTTP transaction when a GET request for beacon.http-post is sent to a Team Server instance that has initialized with the Gmail Malleable C2 profile.

"Image showing an HTTP transaction when a GET request is sent to a Team Server instance that has initialized with the Gmail Malleable C2 profile. "
Figure 8. HTTP request and response configured with the Malleable C2 Gmail profile.
URI Checksum

Team Server utilizes a custom one-byte checksum of the request URI as a condition to serve the 32-bit or 64-bit version of the Beacon binary. A simple checksum algorithm implemented in Java named checksum8 is used to calculate the checksum of the request URI.

As shown in Figure 9, for 32-bit payloads, the code compares the URI checksum result to the literal integer 92L (where the L suffix is Java syntax for integer type long). For 64-bit payload requests, the algorithm compares the checksum to 93L.

Image showing code to check the URI checksum. For 32-bit payloads, the code compares the URI checksum result to the literal integer 92L. For 64-bit payload requests, the algorithm compares the checksum to 93L.
Figure 9. Code to check the URI checksum.

When a user sends a GET request to a Team Server, the URI is passed to checksum8 and is compared to both integer values 92L and 93L. If the checksum satisfies one of the conditions, the server will respond with the raw bytes of the appropriate Beacon binary.

Figure 10 details an example of a URI that computes to a value that satisfies the checksum8 condition, as well as the Team Server’s response with the Beacon binary payload. This information was extracted from Beacon configuration scripts, which continue to provide threat intelligence that is useful for preventing Cobalt Strike connections.

Image showing an HTTP GET request and response with a URI that satisfies checksum8, as well as the Team Server’s response with the Beacon binary payload.
Figure 10. HTTP GET request and response with a URI that satisfies checksum8.
Random URI

If a user sends a randomized URI path, the Team Server will respond with HTTP status code 404 with Content-Length: 0. Figure 11 shows the HTTP response from a Team Server when a user sends a GET request with the URI randomURI.

Image showing an HTTP GET request and response from a Team Server for a randomURI path.
Figure 11. HTTP GET request and response for a randomURI path.

Active Probing Over DNS

Cobalt Strike’s DNS listener enables Beacon implants to covertly utilize the DNS protocol to communicate with the Team Server. The DNS-based Beacon uses the DNS TXT, AAAA, and A records for task monitoring and other related functions. The configuration is set by data channel mode in the Malleable C2 profile.

Figure 12 shows a DNS request originating from a Beacon querying the TXT record for the domain aaa.stage[.]xx.

Image showing a Beacon DNS request querying the TXT record for the domain aaa.stage[.]xx.
Figure 12. Beacon DNS request for TXT record.
Once the request is received, the Team Server responds with the base64-encoded Beacon binary in the TXT record response, as shown in Figure 13 below:

Image showing the Beacon DNS Listener response with the base64-encoded Beacon binary.
Figure 13. Beacon DNS Listener response (base64-encoded data).

Team Server Found in the wild

Based on the fingerprints and signals discovered, we utilized open source threat intelligence feeds including ZoomEye, Shodan and Censys to scour the internet in search of undetected Cobalt Strike Team Servers in the wild.

The following table details IP/port and URI indicators of compromise (IoCs) related to live Team Server instances we discovered in the wild in September 2022. We utilized Shodan’s feed service to collect IP addresses of potential Team Servers before sending 32-bit stager probes to test the daemon for positive indicators. Once a candidate returns the expected Cobalt Strike response, we initialize a TCP connection with netcat to test, verify and extract the served stager bytes as shown in Figure 14.

Image showing the successful HTTP/S probing for Team Server via stager check.
Figure 14. Successful HTTP/S probing for Team Server via stager check.
IP Address:Port Payload Type GET-URI POST-URI
43[.]129[.]7[.]189:8080 windows-beacon_http-reverse_http /updates /aircanada/dark.php
117[.]50[.]37[.]182:80 windows-beacon_http-reverse_http /api/x /api/y
42[.]192[.]206[.]174:80 windows-beacon_http-reverse_http /dpixel /submit.php
194[.]37[.]97[.]160:80 windows-beacon_http-reverse_http /cx /submit.php
92[.]222[.]172[.]39:80 windows-beacon_http-reverse_http /ptj /submit.php
79[.]141[.]169[.]220:443 windows-beacon_http-reverse_http /pixel.gif /submit.php

Table 1. IP/port and URI IoCs related to live Team Server instances.

Conclusion

Cobalt Strike is a potent post-exploitation adversary emulator that continues to evade conventional next-generation solutions, including signature-based network detection. However, Advanced Threat Prevention’s inline deep-learning models and heuristic techniques provide defenses against Cobalt Strike Beacon and Team Server C2 communication before they occur.

The probing and fingerprint technology detailed in this publication is very efficient and reliable in identifying Cobalt Strike instances in the wild with a very high degree of certainty. A single modern network security appliance is not sufficient to provide comprehensive coverage against complex malicious tools such as Cobalt Strike. Only a combination of security solutions including firewalls, sandboxes, endpoint agents and cloud-based machine learning can integrate the required data to prevent advanced adversaries from mounting successful cyberattacks from end to end.

Palo Alto Networks customers receive protection from this kind of attack by the following:

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

CS Samples

  • 50ea11254f184450a7351d407fbb53c54686ce1e62e99c0a41ee7ee3e505d60c

CS Beacon Samples

  • /lNj8
    • SHA256 hash:
      • e712d670382ad6f837feeb5a66adb2d0f133481b5db854de0dd4636d7e906a8e

CS Teamserver IP addresses

  • 92[.]255[.]85[.]93
  • 43[.]129[.]7[.]189
  • 117[.]50[.]37[.]182
  • 42[.]192[.]206[.]174
  • 194[.]37[.]97[.]160
  • 92[.]222[.]172[.]39
  • 79[.]141[.]169[.]220

Additional Resources

Cobalt Strike Training
Cobalt Strike Malleable C2 Profile
Cobalt Strike Decryption with Known Private Key
Cobalt Strike Analysis and Tutorial: How Malleable C2 Profiles Make Cobalt Strike Difficult to Detect
Cobalt Strike Analysis and Tutorial: CS Metadata Encoding and Decoding
Cobalt Strike Analysis and Tutorial: CS Metadata Encryption and Decryption
Cobalt Strike Attack Detection & Defense Technology Overview

Threat Brief: CVE-2022-3786 and CVE-2022-3602: OpenSSL X.509 Buffer Overflows

Posted on by Erica Naone

Executive Summary

On November 1, 2022, OpenSSL released a security advisory describing two high severity vulnerabilities within the OpenSSL library (CVE-2022-3786 and CVE-2022-3602). OpenSSL versions from 3.0.0 - 3.0.6 are vulnerable, with 3.0.7 containing the patch for both vulnerabilities. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

In the days leading up to the security advisory, many were saying these vulnerabilities had the potential to be as bad as the Heartbleed vulnerability, and even OpenSSL originally stated that CVE-2022-3602 was going to be rated critical. Several factors seem to indicate that these vulnerabilities will not be easy to exploit and pose much less risk than originally thought:

  • Both vulnerabilities require a malicious X.509 certificate that has been signed by a valid certificate authority (CA).
  • A vulnerable server/client must parse client-side/server-side X.509 certificates to be affected by either of the CVEs.
  • OpenSSL 3.0.0 was released in September 2021 and is much less widely used than OpenSSL 1.x.x, limiting the attack surface significantly as compared to Heartbleed. Based on data from the attack surface management tool Cortex Xpanse, we estimate the number of internet-facing OpenSSL 3.x installs to be less than 1% of the total OpenSSL installs.
  • CVE-2022-3786 only allows bytes containing the character “.” (decimal 46) to be entered on the stack. Therefore an attacker has no ability to control the payload even though they can gain an arbitrary length overflow. This results in a denial of service (DoS) but not remote code execution.
  • CVE-2022-3602 does allow for an attacker to gain a 4-byte overflow. However, default compiler settings of the OpenSSL project enable stack cookies and – outside of some edge case scenarios – the 4-byte overflow will overwrite the stack cookie and crash the program on Windows.
    • Even without stack cookies enabled, successful exploitation will be highly dependent on the stack layout, which can change with compiler types and selected compiler options.
    • On Linux there appears to be padding of a seed variable before the stack cookie and the 4-byte overflow overwrites this uninitialized variable instead of the stack cookie, and it does not crash the program.

Palo Alto Networks recommends customers apply the latest patch, because both vulnerabilities have been shown to cause a denial of service at the very least. There is publicly available proof-of-concept code that will enable anyone who manages to create a malicious certificate and successfully sign it, to crash unpatched servers.

OpenSSL is also distributed as source code, so compiler options are completely up to the end user, who may opt out of modern memory mitigations such as stack cookies, ASLR, DEP/NX, etc. Such decisions would make exploitation easier and raise the risk of remote code execution for CVE-2022-3786.

Palo Alto Networks customers receive protections from and mitigations for CVE-2022-3786 and CVE-2022-3602 in a variety of ways, including the following:

  • Next-Generation Firewalls and Prisma Access with an Advanced Threat Prevention security subscription can automatically block related sessions.
  • A Cortex XSOAR playboook can help automate remediation.
  • Cortex XDR customers receive protections against remote code execution memory corruption exploits.
  • XQL queries provided below can be used with Cortex XDR to help track attempts to exploit these CVEs.
  • Cortex Xpanse customers can identify impacted versions through its “Insecure OpenSSL [CVE-2022-3602 and CVE-2022-3786]” policy.
  • Prisma Cloud customers can identify vulnerable resources under the vulnerabilities tab.
Vulnerabilities Discussed CVE-2022-3602, CVE-2022-3786

Details of the Vulnerability

As described by OpenSSL in a security advisory, both vulnerabilities (CVE-2022-3786 and CVE-2022-3602) are “triggered through X.509 certificate verification, specifically name constraint checking.” They also note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate, or for the application to continue certificate verification despite failure to construct a path to a trusted issuer.

Both vulnerabilities occur within the ossl_punycode_decode function of the OpenSSL library.

Both vulnerabilities require the following to successfully exploit:

  • A malicious X.509 certificate that is signed by a valid CA
  • A vulnerable server that is parsing the client-side TLS certificate

The malicious certificate will have a subjectAltName that specifies the otherName field with an SmtpUTF8 email address. The certificate will also have a namedConstraint field with an email address that includes punycode. These two certificate items combined allow the parsed certificate data to reach the ossl_punycode_decode function within the OpenSSL library. The namedConstraint field will contain the payload that is decoded to a 513 byte overflow.

The vulnerability described in CVE-2022-3786 allows an attacker to achieve a stack overflow of arbitrary length, which is limited to the “.” character (decimal 46), by crafting a malicious email address within the attacker-controlled certificate as described above.

The vulnerability described in CVE-2022-3602 is an off-by-one vulnerability that allows an attacker to obtain a 4-byte overflow on the stack by crafting a malicious email address within the attacker-controlled certificate as described above. On Windows systems the overflow will either result in a crash (most likely scenario) or a potential remote code execution (much less likely).

OpenSSL distributes the OpenSSL library with stack cookies enabled by default. Testing of CVE-2022-3602 by OpenSSL and external researchers has shown the 4-byte overflow will overwrite the stack cookie resulting in a crash. However, OpenSSL is distributed as source and therefore compiler options are completely up to the end user, who may opt out of modern memory mitigations such as stack cookies, ASLR, DEP/NX, etc. Such decisions would make exploitation easier and raise the risk of remote code execution for CVE-2022-3786.

On Linux systems, research has shown there is an uninitialized seed value on the stack just before the stack cookie. This uninitialized seed value on Linux systems gets overwritten and no ill effects have been witnessed. This vulnerability received quite a bit of attention in the week leading up to the security advisory, and several excellent blogs describe it in detail (in particular, posts from Datadog Security Labs and Colm MacCarthaigh).

Current Scope of the Attack

There are no known instances of exploitation of either of these vulnerabilities. Proof of concept code does exist that results in crashing of the process. Assuming an attacker is able to craft a certificate signed by a valid CA, denial of service attacks would be possible.

Interim Guidance

Update to the most recent version of OpenSSL as soon as possible. OpenSSL also recommends that organizations operating TLS servers should consider disabling TLS Client Authentication if it is being used, until patches are applied.

Conclusion

OpenSSL’s latest security bulletin describes two memory corruption vulnerabilities that initially were thought to be critical and potentially as bad as the Heartbleed vulnerability (at least in the case of CVE-2022-3602). Ultimately both were rated high risk and deemed not likely to result in remote code execution.

Based on OpenSSL’s blog post on the issue, they and several external researchers (Datadog, Colm MacCarthaigh and unnamed researchers who assisted OpenSSL during their investigation), have done extensive research that supports this conclusion. Although this was probably the best outcome we could have hoped for on such a widely used library, Palo Alto Networks still recommends customers apply the latest patch. Both vulnerabilities have been shown to cause a denial of service at the very least. There is also at least one publicly available proof of concept that will enable anyone who manages to create a malicious certificate, and successfully sign it, to crash unpatched servers.

Palo Alto Networks Product Protections for OpenSSL Vulnerabilities

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention

Both Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) and Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-3602 using Threat ID 93212 (Application and Threat content update 8638).

Cortex XSOAR Automated OpenSSL Vulnerability Management

The related Cortex XSOAR automation playbook can help you:

  • Automate incident data enrichment
    • Tag CVE indicators
    • Link indicators to incidents in your environment
  • Automate endpoint hunting
    • Hunt for Windows OS and/or Linux OS endpoints and retrieve OS endpoint IDs
    • Hunt for active processes running OpenSSL 3.x running in the above mentioned OS environments, Azure Sentinel logs and/or Splunk
  • Take remediation action
    • Download the latest version of OpenSSL
    • Install the latest version of OpenSSL across relevant endpoints
  • Notify analysts
    • Send analysts a notification if further investigations are needed
Image showing a sample section of the XSOAR automation playbook
Figure 1. A sample section of the Cortex XSOAR playbook designed to help with OpenSSL vulnerabilities.

This playbook is part of the Rapid Response Pack, which includes various playbooks for trending vulnerabilities and threats. The Cortex XSOAR playbook for CVE-2022-3786 and CVE-2022-3602 is now available in the Cortex Marketplace.

Cortex XDR

Cortex XDR customers receive protections against remote code execution memory corruption exploits (including those that may be possible in relation to these vulnerabilities) through its multi-layered security approach.

Cortex XDR customers can also make use of the XQL queries suggested by the Managed Threat Hunting team in the section below to search for signs of exploitation.

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below.

Host Insights indexes endpoint host files with the Search and Destroy feature, enabling analysts to sweep across endpoints in near-real time to rapidly locate files, such as vulnerable OpenSSL software.

Cortex XDR Pro endpoint customers without Host Insights can search for the presence of OpenSSL using the following query:

Cortex XDR customers with Unit 42 managed services subscriptions, including Unit 42 Managed Threat Hunting and Unit 42 Managed Detection and Response, automatically received a Threat Impact Report with technical details and guidance.

Cortex Xpanse

Cortex Xpanse customers can identify impacted versions through its “Insecure OpenSSL [CVE-2022-3602 and CVE-2022-3786]” policy. The policy is available to all customers with a default state of On.

Screenshot showing Cortex Xpanse Insecure OpenSSL policy
Figure 2. Cortex Xpanse "Insecure OpenSSL [CVE-2022-3602 and CVE-2022-3786]" policy.

Prisma Cloud Vulnerability Management

If you are using Prisma Cloud, you can detect affected resources under the Vulnerabilities tab. The scan automatically detects and alerts on vulnerable entities with the vulnerable OpenSSL package.

You can also search for CVE-2022-3786 and CVE-2022-3602 through the Vulnerability Explorer to list the affected resources in your environment.

Image showing detection of CVE-2022-3602 in the Vulnerability Explorer within Prisma Cloud
Figure 3. CVE-2022-3602 in Prisma Cloud.

Updated Nov. 4, 2022, at 8 a.m. PT. 

Banking Trojan Techniques: How Financially Motivated Malware Became Infrastructure

Posted on by Erica Naone

Executive Summary

While advanced persistent threats get the most breathless coverage in the news, many threat actors have money on their mind rather than espionage. You can learn a lot about the innovations used by these financially motivated groups by watching banking Trojans.

Because attackers constantly create new techniques to evade detection and perform malicious acts, studying monetarily motivated malware can help defenders understand threat actor tactics and protect organizations more effectively. Some of the banking Trojans described here are historically known for being financial malware, but now they’re primarily used as infrastructure to deliver other malware. Which is to say, by preventing techniques used by banking Trojans, you can also stop other types of threats.

We’ll survey techniques used by notorious banking Trojan families to evade detection, steal sensitive data and manipulate data. We’ll also describe how those techniques can be blocked. These families include Zeus, Kronos, Trickbot, IcedID, Emotet and Dridex.

Palo Alto Networks customers are protected from such attacks using Cortex XDR and WildFire.

Banking Trojan families' techniques discussed Zeus, Kronos, Trickbot, IcedID, Emotet, Dridex

What Are Webinjects?

Webinjects are modules that can inject HTML or JavaScript before a web page is rendered, and are often used to trick users. They are known to be abused by banking Trojans, as well as being employed to steal credentials and manipulate form data inside web pages. In most banking Trojan families, there is at least one webinjects module.

An early stager of the banking Trojan usually injects the banking Trojan’s main bot into a Windows process, and that process injects the webinjects module into the machine’s available web browser processes as shown in Figure 1.

Code snippet showing Trickbot going through browser processes including Chrome, Internet Explorer, Firefox and Microsoft Edge, to inject with its webinjects module.
Figure 1. Trickbot goes through processes one by one to find browsers to inject with its webinjects module, using a stealthy technique known as reflective injection.

The webinjects module hooks the API calls responsible for sending, receiving or encrypting data sent to a web server. By intercepting the data before it is encrypted, the malware can read HTTP-POST headers and manipulate them on the fly.

Code snippet showing Trickbot webinjects module going through browser processes including Internet Explorer, Microsoft Edge, Chrome and Firefox to place hooks.
Figure 2. Trickbot webinjects module placing hooks based on the browser.
Code snippet showing Trickbot placing hooks on Wininet.dll functions including HttpSendRequestA, HttpSendRequestW, HttpSendRequestExA, HttpSendRequestExW and InternetCloseHandle.
Figure 3. Trickbot placing hooks on wininet.dll functions.

By fully controlling the HTTP headers just before the webpage is rendered, the malware can completely modify the forms and fool the user. The malware may inject HTML or JavaScript code to trick the user into inserting sensitive information, such as a PIN code or credit card number, enabling the malware to collect it. The malware can extract this information and send it to its command and control (C2) server without actually sending the forged headers to the targeted web page server.

Chrome (chrome.dll) Firefox (nspr3.dll / nspr4.dll) Internet Explorer / Edge (Wininet.dll)
ssl_read PR_Read HttpSendRequest
ssl_write PR_Connect InternetCloseHandle
PR_Close InternetReadFile
PR_Write InternetQueryDataAvailable
HttpQueryInfo
InternetWriteFile
HttpEndRequest
InternetQueryOption
InternetSetOption
HttpOpenRequest
InternetConnect

Table 1. Frequently hooked API functions.

How to Detect Webinjects

This technique can be prevented by detecting an injection into a web browser process. The injected thread calls the NtProtectVirtualMemory function where the NewAccessProtection argument is PAGE_EXECUTE_READWRITE and the BaseAddress argument is an address to a library function targeted by banking Trojans.

For example, Trickbot uses both VirtualProtect and VirtualProtectEx in its various versions. Inspecting NtProtectVirtualMemory calls covers both.

Some banking Trojans opt to avoid code injection. Instead, they suspend the remote process threads and install the hooks remotely. Inspecting remote NtProtectVirtualMemory calls can detect this variant technique.

Code snippet showing NtProtectVirtualMemory prototype.
Figure 4. NtProtectVirtualMemory prototype.

Infecting Web Browsers During Process Creation

Some banking Trojans aim to infect a target process as soon as it is launched, by injecting code into a predicted parent process of the real target. Once the banking Trojan executes in the context of the parent process, it hooks process creation library functions and waits until the real target is created.

Inside the hook, the banking Trojan manipulates the process creation flow. Then, for example, it initializes the webinjects module inside the remote process. The explorer.exe and runtimebroker.exe parent processes are frequently abused for this goal, as they usually launch the real targets.

For instance, the Karius banking Trojan used this technique by injecting code into explorer.exe and hooking CreateProcessInternalW. The Trojan’s hook handler looked for a spawned web browser process and injected the malicious webinjects module into it.

How to Prevent Attempts to Infect Web Browsers During Process Creation

This technique can be prevented by looking for an injection into explorer.exe or runtimebroker.exe, where the injected thread hooks process creation functions like NtCreateUserProcess, NtCreateProcessEx, CreateProcessInternalW, CreateProcessA or CreateProcessW.

Named Pipe Communication Between Injected Processes

Many banking Trojans use named pipes to communicate with various processes under the threat actor’s control. To do this, they inject their main bot into a Windows process, and then inject their other modules into different processes according to the module’s purpose. They then establish communication between the different processes using named pipes.

For example, Trickbot injects the main bot into svchost.exe. It creates a named pipe server and reflectively injects the webinjects module into web browsers. This injected module connects to the same named pipe as a client to communicate to the main bot and deliver the fetched credentials to the C2 server.

Code snippet showing Trickbot creating a named pipe server.
Figure 5. Trickbot named pipe server.

How to Prevent Named Pipe Communication Between Injected Processes

This technique can be prevented by inspecting named-pipe events. An injected thread creates a named pipe inside a Windows process, and then another injected thread that lives inside a web browser attempts to connect to that same named pipe.

Heaven’s Gate Injection Technique

Heaven's Gate is a technique used by malware, which enables a 32-bit (WoW64) process to execute 64-bit code by performing a far jump/call using segment selector 0x33. Modern malware uses Heaven's Gate to inject into both 64-bit and 32-bit processes from a single 32-bit process on x64 systems. This bypasses WoW64 API hooks, it hinders analysis on some debuggers, and it fails emulation on some sandboxes.

Even though this method is old, it is still effective and frequently used.

Trickbot and Emotet loaders use Heaven's Gate for process hollowing from a WoW64 process into a 64-bit svchost.exe (For more about process hollowing, see the section on Evasive Process Hollowing By Entrypoint Patching below). The architecture of these two banking Trojans dictates that their main bot persists inside svchost.exe while the web content manipulation and credential stealing modules live inside the browser processes.

Showing Emotet using Heaven's Gate technique in its Microsoft Outlook Messaging API module.
Figure 6. Emotet using Heaven's Gate in its Microsoft Outlook Messaging API (MAPI) module.

How to Prevent Heaven's Gate

A WoW64 process usually goes through the wow64cpu.dll to perform the transition to x64 CPU mode. Heaven's Gate does this transition manually.

Prevention methods can find Heaven's Gate by inspecting whether a WoW64 process system call didn’t go through the wow64cpu.dll. This can be done by placing hooks on critical APIs, generating a stack trace and inspecting the stack trace for wow64cpu.dll.

Showing WoW64's normal syscall flow.
Figure 7. WoW64’s normal syscall flow.

Evasive Process Hollowing by Entrypoint Patching

Process hollowing is a process injection technique that creates a new legitimate process in a suspended mode, unmaps its main image and replaces it with malicious code. The malicious code is written into the newly created process and the suspended thread context instruction pointer is changed using NtGetContextThread/NtSetContextThread.

Security product vendors check for main image unmapping combined with the usage of NtGetContextThread/NtSetContextThread to detect process hollowing.

A known technique for evading detection is to patch the process entry point with a small jump that redirects execution to the payload without actually using NtGetContextThread/NtSetContextThread functions or unmapping the main image. For example, Trickbot and Kronos have both used this technique.

Kronos mapped a suspended svchost.exe into its own process and patched it in its own memory address space. Similar to other banking Trojans, Kronos' main module ran within svchost.exe and orchestrated the whole operation from the remote svchost.exe process.

Trickbot implemented process hollowing by first using VirtualProtectEx on the process entrypoint, and then writing the hook stub using WriteProcessMemory.

Code snippet showing Kronos mapping svchost.exe and patching its entrypoint.
Figure 8. Kronos mapping svchost.exe and patching its entrypoint.
Figure 9. Kronos hook stub template – x86 opcodes for push and ret.
Figure 9. Kronos hook stub template – x86 opcodes for push and ret.

How to Prevent Evasive Process Hollowing by Entrypoint Patching

This technique can be prevented either by inspecting whether the address argument provided to the calls of NtWriteVirtualMemory or NtProtectVirtualMemory is a remote process entry point or by detecting suspicious remote mapping and reading of svchost.exe memory.

PE Injection

Common injection methods used by banking Trojans involve writing a mapped PE into a remote process using WriteProcessMemory. Some malware families try to obscure the call by wiping artifacts from the buffer, such as wiping the PE header.

For example, Zeus variants use this technique to inject themselves into other processes, allowing them to stay hidden, as well as to perform webinjects and to perpetrate financial data theft.

Code snippet from Zeus injection code, taken from its leaked source code.
Figure 10. Zeus injection code from its leaked source code.

How to Prevent PE Injection

This technique can be prevented by inspecting the buffer sent to NtWriteVirtualMemory for executable artifacts.

Process Injection via Hooking

Hooking can be used as an injection technique. Injecting a banking Trojan’s main payload into a legitimate-looking process maintains stealth and helps avoid endpoint protection detection.

This technique utilizes hooking to get code execution, usually by hooking a frequently called API function with a jump to a payload/shellcode. This avoids calling any suspicious APIs often used in code injection techniques like CreateRemoteThread or NtSetContextThread.

For instance, IcedID injects its main bot into a hollowed instance of svchost.exe using API hooking. This is also known as the ZwClose technique (ZwClose was the hooked API in Zberp, the first to employ this injection technique in the wild).

The injection flow of IcedID is slightly different than that of Zberp. It first hooks NtCreateUserProcess and then calls CreateProcessA to create svchost.exe without any special parameters or argument. In a regular flow, the newly created svchost.exe should terminate right away.

Code snippet from IcedID initiating svchost.exe hooking.
Figure 11. IcedID initiates svchost.exe hooking.
Code snippet from IcedID hooking NtCreateUserProcess.
Figure 12. IcedID hooks NtCreateUserProcess.

However, because IcedID hooked NtCreateUserProcess, the hook handler is called right after the call to CreateProcessA. In the handler, it performs the following activities:

  • Unhooks NtCreateUserProcess
  • Calls NtCreateUserProcess (which creates svchost.exe)
  • Decompresses a local buffer that contains the payload to inject using RtlDecompressBuffer
  • Allocates memory for the payload at the remote svchost.exe process
  • Writes the payload into the remote svchost.exe using NtAllocateVirtualMemory and ZwWriteVirtualMemory

For the execution, IcedID hooks RtlExitUserProcess in the newly created svchost.exe with a jump stub to the payload. As mentioned, svchost.exe was created without any parameters and it will try to exit. However, due to the IcedID hook, it will jump to the payload.

Code snippet from IcedID hooking RtlExitUserProcess.
Figure 13. IcedID hooks RtlExitUserProcess.

How to Prevent Injection via Hooking

This technique can be prevented by inspecting calls to NtProtectVirtualMemory and NtWriteVirtualMemory. The provided address argument for NtProtectVirtualMemory is an exported function from one of the Windows libraries, and the NtWriteVirtualMemory written buffer is a hooking stub. In both cases, the remote process has to be a known injection target.

AtomBombing Injection Technique

AtomBombing is a technique that allows malware to inject code while avoiding calling suspicious APIs that security vendors are watching. Dridex uses a slightly modified AtomBombing technique that injects one of its stages into a Windows process (usually explorer.exe) and employs various steps to cause financial data theft.

Malware using the AtomBombing technique first writes the payload into the global atom table, which can be accessed by all processes. They then dispatch an asynchronous procedure call (APC) to the APC queue of a target process thread using NtQueueApcThread, forcing the target process to call GlobalGetAtomA.

The target thread then retrieves the payload from the global atom table and inserts it into a read/write (RW) region inside the target process memory space (a code cave inside the kernelbase.dll data section). The payload has to be split into NULL-terminated strings and an atom is created for each string.

For the execution, the injector process dispatches another APC using NtQueueApcThread to force the remote process to execute NtSetContextThread. The injected process then calls NtSetContextThread, which invokes a return-oriented programming (ROP) chain that allocates execute/read/write (RWX) memory. The ROP chain then copies the payload from the RW region into the newly allocated RWX region, and lastly, executes it.

The unique idea behind AtomBombing is the write-primitive, which allows writing to the remote process using atom tables and APC.

Dridex uses a variation of AtomBombing that queues an APC to call memset to clean an RW region in ntdll.dll. Then, it copies the payload and its import table into the target process using the same write technique into the ntdll.dll RW region.

For the execution, Dridex modifies the copied payload memory into executable memory using NtProtectVirtualMemory. Then it hooks GlobalGetAtomA by calling NtProtectVirtualMemory and by using the same write primitive. Finally, it queues an APC into the patched GlobalGetAtomA to get the payload running.

Code snippet from AtomBombing proof of concept
Figure 14. AtomBombing proof of concept code.

How to Prevent AtomBombing and its Variants

These techniques can be prevented by inspecting whether the arguments provided to NtQueueApcThread/NtSetContextThread calls point to a suspicious API – the APC routine argument in the case of NtQueueApcThread, or the new instruction pointer in the context argument in the case of NtSetContextThread. Both API calls have to be called into a remote process.

Conclusion

Threat actors who are in it for the money use a wide range of malware techniques for injection and financial fraud, and they are always looking for new ways to develop evasive techniques. We have explored some of the more interesting banking Trojan techniques and how they’re used to steal victims’ sensitive data. And finally, we describe how these techniques can be used to detect malicious behavior, so it can be prevented.

Palo Alto Networks customers using Cortex XDR receive protections from such attacks in different layers, including the following:

  • Local Analysis Machine Learning module
  • Behavioral Threat Protection
  • Behavioral indicators of compromise (BIOC) and Analytics BIOCs rules

These layers identify the tactics and techniques that banking Trojans use at different stages of their execution.

Palo Alto Networks customers also receive protections against the attacks discussed here through the WildFire cloud-delivered security subscription for the Next-Generation Firewall.

Indicators of Compromise

  • Trickbot
    • testnewinj32Dll.dll: 4becc0d518a97cc31427cd08348958cda4e00487c7ec0ac38fdcd53bbe36b5cc
    • Webinjects: ef6603a7ef46177ecba194148f72d396d0ddae47e3d6e86cf43085e34b3a64d4
  • Emotet: dd20506b3c65472d58ccc0a018cb67c65fab6718023fd4b16e148e64e69e5740
  • Kronos: aad98f57ce0d2d2bb1494d82157d07e1f80fb6ee02dd5f95cd6a1a2dc40141bc
  • Zeus: 0f409bc42d5cd8d28abf6d950066e991bf9f4c7bd0e234d6af9754af7ad52aa6
  • IcedID: 358af26358a436a38d75ac5de22ae07c4d59a8d50241f4fff02c489aa69e462f
  • Dridex: ffbd79ba40502a1373b8991909739a60a95e745829d2e15c4d312176bbfb5b3e

 

Defeating Guloader Anti-Analysis Technique

Posted on by Mark Lim

Executive Summary

Unit 42 researchers recently discovered a Guloader variant that contains a shellcode payload protected by anti-analysis techniques, which are meant to slow human analysts and sandboxes processing this sample. To help speed analysis for this sample and others like it, we are providing a complete Python script to deobfuscate the Guloader sample that is available on GitHub.

In early September 2022, we discovered a Guloader variant with low VirusTotal detection. Guloader (also known as CloudEye) is a malware downloader first discovered in December 2019.

We analyzed the control flow obfuscation technique used by this Guloader sample to create the IDA Processor module extension script so researchers can deobfuscate the sample automatically. The script can be applied to other malware families like Dridex, which utilize similar anti-analysis techniques.

Palo Alto Networks customers receive protections from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services, including WildFire and Advanced Threat Prevention.

Related Unit 42 Topics Malware, anti-analysis

Guloader Control Flow Obfuscation Technique

The Guloader sample in question uses the control flow obfuscation technique to hide its functionalities and evade detection. This technique impedes both static and dynamic analysis.

First, let’s look at how this threat hampers static analysis. In short, it uses CPU instructions that trigger exceptions, resulting in unintelligible code during static analysis.

After peeling away the packer layer of our Guloader sample, we see that its code is obfuscated. Using static analysis tools such as IDA Pro, we observe many 0xCC bytes (or int3 instructions) littered throughout the sample, as shown in Figure 1.

Following the 0xCC bytes are junk instructions. These added bytes disrupt the static analysis tool’s disassembly process, resulting in the wrong disassembly listing.

Scrolling through obfuscated code to show 0xCC bytes throughout.
Figure 1. Obfuscated code blocks.

0xCC bytes are CPU instructions that trigger an exception EXCEPTION_BREAKPOINT (0x80000003), which pauses the execution of a process. The CPU will pass the code flow to the handler function before the execution continues. The handler function is responsible for moving the instruction pointer to the correct address.

The presence of these same 0xCC bytes make it so that using a debugger during dynamic analysis would crash the Guloader sample. Debuggers insert 0xCC bytes as software breakpoints to halt the execution of the sample. The debugger handles the exception instead of the handler function.

Before understanding what happens in the handler function, we first have to locate its address.

Guloader uses the AddVectoredExceptionHandler function to register the handler function, as shown in Figure 2. The second argument of the AddVectoredExceptionHandler function points to the address of the handler function.

Function prototype of AddVectoredExceptionHandler used to register the handler function.
Figure 2. Function prototype of AddVectoredExceptionHandler.

Using a debugger as shown in Figure 3, we locate the address of the handler function registered by the Guloader sample. With the address information, we can examine its code. Notably, this ExceptionHandler is registered with the order of 1, meaning it is the first handler to be invoked.

Using a debugger to locate the address of the AddVectoredExceptionHandler function registered by the Guloader sample.
Figure 3. Debugging the call to AddVectoredExceptionHandler in Guloader sample.

Analyzing the Vectored Exception Handler Function

The first step of analyzing the handler function is to apply its type information, as shown in Figure 4.

Showing the type information for the handler function.
Figure 4. Type information for the handler function.

Next, we apply the type information for three Windows data structures (shown in Figure 5) used by the handler function.

Showing the type information of three Windows data structures to be applied on the handler function.
Figure 5. Type information of three Windows data structures to be applied on the handler function.

With the type information applied, we can examine how the function handled the exceptions caused by the 0xCC bytes. Figure 6 shows the decompiled handler function (Func_VectoredExceptionHandler) annotated with comments.

Decompiled handler function (Func_VectoredExceptionHandler) annotated with the following comments: "Check type of exception raised," "Check for hardware breakpoint," "CC byte raising exception," "Decode offset byte," "Loop to check for software breakpoint," "Exit handler function if software breakpoint is found," and "Update EIP with offset."
Figure 6. Decompiled handler function.

The handler function begins with anti-debugging checks. It will terminate execution when hardware or software breakpoints are found. Next, the offset value is computed by XOR decoding the byte after the 0xCC byte with 0xA9. Finally, the offset value is added to the instruction pointer before the code execution resumes. Code execution continues at the address pointed to by the updated instruction pointer.

After understanding how the obfuscation is carried out, we can identify the legitimate instructions and discard the unwanted ones, as shown in Figure 7.

Labeled code block so we can identify the legitimate instructions and discard the unwanted ones
Figure 7. Labeled code block.

To completely deobfuscate the Guloader sample, we need to replace all the 0xCC bytes with a JMP short instruction (0xEB) and the following byte with the decoded offset value.

Because doing all this manually is time consuming, in the next section we will show you how to write an IDA Processor module extension to automate the deobfuscation process.

Writing an IDA Processor Module Extension

IDA Processor module extensions allow us to influence the disassembler logic in IDA Pro. These extensions are written using Python to enable us to filter and manipulate how IDA Pro disassembles the instructions in the sample.

The Python script extends the ev_ana_insn method in the IDP_Hooks class. It starts by checking if the current instruction is the 0xCC byte. Next, the 0xCC byte is replaced with the JMP short instruction (0xEB). Finally, the following byte is replaced with the decoded offset value.

Figure 8 shows the function in the Python script where this deobfuscation is implemented.

Function in the Python script where we're extending the ev_ana_insn() to deobfuscate the sample.
Figure 8. Extending the ev_ana_insn() to deobfuscate the sample.

After applying the Python script, IDA Pro can deobfuscate the Guloader sample automatically, as shown in Figure 9.

Code before and after applying the Python script so IDA Pro can deobfuscate the Guloader sample automatically
Figure 9: Obfuscated code (left) and code block after deobfuscation (right).

Conclusion: Malware Analysts vs. Malware Authors

Malware authors often include obfuscation techniques, hoping that they will increase the time and resources required for malware analysts to process their creations. Using the steps above, you can reduce the time needed to analyze these malware samples from Guloader, as well as those of other families using similar techniques.

Palo Alto Networks customers receive protections from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services, including WildFire and Advanced Threat Prevention.

Indicators of Compromise

SQ21002728.IMG:
SHA256: fb8e52ec2e9d21a30d7b4dee8721d890a4fbec48103a021e9c04dfb897b71060
SQ21002764

SQ21002728.vbs:
SHA256: 56cdfaa44070c2ad164bd1e7f26744a2ffe54487c2d53d3ae318d842c6f56178
SQ21002764

Additional Resources

 

Trends in Web Threats in CY Q2 2022: Malicious JavaScript Downloaders Are Evolving

Posted on by Tao Yan

Executive Summary

Palo Alto Networks Advanced URL Filtering subscription collects data regarding two types of URLs; landing URLs and host URLs. We define a malicious landing URL as one that allows a user to click a malicious link. A malicious host URL is a page containing a malicious code snippet that could abuse someone’s computing power, steal sensitive information or perform other types of attacks.

Our researchers regularly track web threats to better understand trends that develop over time. This blog will cover trends we’ve identified between April 2022 and June 2022 using our web threat detection module.

Our detection module found around 751,000 incidents of malicious landing URLs containing different kinds of web threats, 253,000 (around one third) of which are unique URLs. In addition, the detection module also detected around 1,740,000 malicious host URLs, 256,000 (almost 15%) of which are unique.

In this blog, we present our analysis and findings of these web threat trends, including the following information:

  • When these web threats were more active
  • Where they were hosted
  • What categories they belong to
  • Which malware families are the most prevalent

We will also examine a malicious downloader case study regarding a campaign that shows how malicious JavaScript downloaders are evolving to evade different kinds of detections.

Palo Alto Networks customers receive protections from the web threats discussed here, as well as many others, via the Advanced URL Filtering, DNS Security and Threat Prevention cloud-delivered security services.

Types of Attacks and Vulnerabilities Covered Skimmer attacks, malware
Related Unit 42 Topics Information disclosure, A Closer Look at the Web Skimmer 

Web Threats Landing URLs: Detection Analysis

Between April and June 2022, we collected data from our customers with our Advanced URL Filtering subscription, within the web threat detection module which uses special YARA signatures. We detected 751,331 incidents of landing URLs, containing all kinds of web threats, such as web skimmers and web scams. 253,644 of these landing URLS were unique. Compared with the results from last quarter (Q1 2022), which had a total of 577,275 detected landing URLs and 116,643 unique URLs, we can see the totals rose in Q2.

Web Threats Landing URLs Detection: Time Analysis

Figure 1 shows the total number of web threat hits in Q2 of 2022, how many of those hits were unique, and how many of those hits were also observed last quarter. As we can see, the repeated unique number from Q1 is low, which suggests that attackers are always trying to target new entry points.

Bar chart describing web threats landing URLs distribution April-June 2022. Blue bars indicate all detections, including repeated detections of the same URL, red bars indicate detection of unique URLs, and orange bars indicate a detection that was seen in 2022 Q1 but unique in 2022 Q2.
Figure 1. Web threats landing URLs distribution April-June 2022. (Blue bars indicate all detections, including repeated detections of the same URL, and red bars indicate detection of unique URLs. Orange bars indicate a detection that was seen in Q1 2022 but unique in Q2 2022 ).

Web Threats Landing URLs: Geolocation Analysis

According to our analysis, the previously mentioned 253,644 unique URLs are from 34,833 unique domains. After identifying the geographical locations for these domain names, we found the majority of them seem to originate from the United States, followed by Germany and Russia, as was also the case last quarter. However, we recognize attackers are leveraging proxy servers and VPNs located in those countries to hide their actual physical locations.

The choropleth map shown in Figure 2 indicates the wide distribution of these domain names across almost every continent. Figure 3 shows the top eight countries where the owners of these domain names appear to be located.

Choropleth map showing the geolocation distribution of landing URLs between April and June 2022
Figure 2. Web threat landing URLs’ domain geolocation distribution April-June 2022.
Pie chart showing distribution of originating country of landing URLs from April to June 2022. United States - 64.4%, Germany - 4.9%, Russia - 2.0%, France - 2.0%, Canada - 1.8%, United Kingdom - 1.7%, Netherlands - 1.7%, India - 1.3%, Others - 20.2%
Figure 3. Top eight countries where web threat landing URLs’ domains originated April-June 2022.

Web Threats Landing URLs: Category Analysis

We analyzed the landing URLs initially identified by our detection model as benign, to find the common targets for these cyberattackers and where they may be trying to fool users. These landing URLs lead to people clicking on malicious host URLs. Going forward, all these landing URLs that lead to malicious code snippets will be marked as malicious by our product.

As shown in Figure 4, the top apparently benign targets are personal sites and blogs, followed by business and economy sites, and computer and internet information sites. Compared to last quarter, computer and internet information sites take third place over shopping sites. Because attackers often try to trick users into following malicious links from seemingly benign sites, we strongly recommend users exercise caution when visiting unfamiliar websites.

Pie chart showing the top 10 categories hosting web threats from April to June 2022. Personal sites and blogs - 14.3%, business and economy sites - 13.8%, computer and internet - 7.8%, shopping - 5.5%, health and medicine - 4.7%, society - 4.6%, entertainment and arts - 4.4%, search engines - 3.7%, parked - 3.4%, travel - 3.2%, Others - 34.7%
Figure 4. We divided landing URLs that originally appeared benign into categories. Here are the top 10 categories that hosted web threats April-June 2022.

Web Threats Malicious Host URLs: Detection Analysis

With Advanced URL Filtering, we detected 1,744,629 incidents of malicious host URLs from April to June 2022, of which 256,844 are unique URLs. The following section will take a closer look at those malicious host URLs. (“Malicious host URLs” specifically refers to pages containing malicious snippets that could abuse users' computing power, steal sensitive information, and so on).

Although the total number of hits is similar to last quarter’s total, the number of unique hits is much greater. This number rose by 42%, suggesting attackers are trying more variants with malicious behavior.

Web Threats Malicious Host URLs Detection: Time Analysis

Figure 5 shows the total number of web threat hits, including those categorized as unique hits.

Bar chart showing April-June 2022 on the X-axis, and 0-1,000,000 on the Y-axis. Key indicates blue bars are all hits, and red bars are unique hits. April 2022 = 805,6924 total hits: 76,866 unique hits. May 2022 = 385,834 total hits: 64,553 unique hits. June 2022 = 553,103 total hits: 115,425 unique hits.
Figure 5. Web threats malicious host URLs distribution from April-June 2022.

Web Threats Malicious Host URLs Detection: Geolocation Analysis

In our geolocation analysis of host URLS, we discovered that the 256,844 unique malicious host URLs belong to 23,663 unique domains. This is fewer unique domains than we observed for landing URLs.

After identifying the apparent geographical locations for these domain names, we found that the majority of them seem to originate from the United States – as we observe for web threats generally. Figure 6 shows a heat map illustrating these findings.

Choropleth map showing the geolocation distribution of malicious host URLs from April to June 2022
Figure 6. Web threats malicious host URLs’ domain geolocation distribution April-June 2022.

Figure 7 shows the top eight countries where the owners of these domain names appear to be located. Compared to what we observed for web threats overall – the top three countries were the United States, Germany and Russia – the top three host domain countries for malicious host URLs were the same. This matches our findings from last quarter.

Pie chart showing distribution of originating country of malicious host URLs from April to June 2022. United States - 66.0%, Germany - 4.8%, Russia - 2.4%, France - 1.7%, United Kingdom - 1.6%, Canada - 1.6%, Netherlands - 1.6%, India - 1.4%, Others - 18.9%
Figure 7. Top eight countries where web threats malicious host URLs’ domains appeared to be located April-June 2022.

 

Web Threats Malware Class Analysis

The top five web threats we observed are cryptominers, JavaScript downloaders, web skimmers, web scams and JavaScript redirectors. To define these classes, please refer to our blog, “The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More”.

As shown in Figure 8, JavaScript downloader threats showed the most activity, followed by web skimmers and web miners (aka cryptominers). This finding is similar to last quarter.

Bar chart showing js_downloader, web_miner, web_skimmer, web_scam and js_redirector on the X-axis, and 0-1,000,000 on the Y-axis. Key indicates blue bars are all hits, and red bars are unique hits. Js_downloader = 930,359 total hits: 112,422 unique hits. Web_miner = 327,472 total hits: 25,590 unique hits. Web_skimmer = 337,710 total hits: 71,468 unique hits. Web_scam = 18,132 total hits: 3,749 unique hits. Js_redirector = 92,157 total hits: 2,988 unique hits.
Figure 8. Top five web threats category distribution April-June 2022.

Web Threats Malware Family Analysis

Based on our classification of web threats explained in the previous section, we further organized our set of web threats by malware family. The family is important to understanding how threats work, because threats in the same family share similar JavaScript code even if the HTML landing pages where they appear have different layouts and styles.

As we did in our yearly analysis, The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More, we identified pieces of malware as part of a family by checking for certain characteristics: similar code patterns or behaviors, or having originated from the same attacker.

Figure 9 shows the number of snippets observed for the top 10 malware families we identified. As we’ve seen previously, there were fewer families of JS redirectors, web scams and JS downloaders, while web skimmers show more diversity in code and behavior.

Bar chart showing the web threat families along the X-axis, and 0-200,000 on the Y-axis. Key indicates that blue bars are total hits, and red bars are unique hits.
Figure 9. Web threat malware family distribution from April-June 2022.

Web Threats Case Study: Malicious JavaScript Downloader

Among all of the web threats we detected during this analysis, the most notable was a malicious JavaScript downloader commonly injected into webpages from a popular content management system. This downloader is injected into a legitimate webpage and redirects the user to ads, spam, etc.

We found many websites infected with variants from the same family, which is evolving to evade detection. When we first found this malware family, it was not obfuscated at all. But from a sample we found in the second quarter of 2022, we see it is lightly obfuscated to hide the redirection URL.

Figure 10 shows the malicious JavaScript code snippet from the source code of the compromised website.

JavaScript code snippet from the source code of the compromised website, lightly obfuscated with CharCode.
Figure 10. Source code of a malicious injected JavaScript code snippet.

As we can see, the snippet is lightly obfuscated with CharCode. After we deobfuscate the sample, we get the code shown in Figure 11.

The malicious JavaScript code creates several new script elements that redirect website visitors to another malicious destination. This example code is under the head of the page, which will be triggered whenever the page is clicked. We identified several malicious domains, including train[.]developfirstline[.]com, js[.]digestcolect[.]com and stat[.]trackstatisticsss[.]com.

Deobfuscated source code showing several malicious domains
Figure 11. Deobfuscated source code of a malicious injected JavaScript code snippet.

From a more recent sample we found in this malicious downloader family, the whole JavaScript code is highly obfuscated, as shown in Figure 12. After we deobfuscated the JavaScript function eval, the malicious code is like Figure 11 shown above.

Highly obfuscated code from a malicious downloader sample
Figure 12. Source code of a highly obfuscated malicious downloader sample.

From our detection data, we found around 5,000 hits for this type of JavaScript injection from our customers. This threat infected around 300 different domains from April 2022 to June 2022, which shows how active this malicious JavaScript downloader family is.

Conclusion

As we highlighted in this blog, the most prevalent web threats are still JS downloaders, cryptominers, web skimmers, web scams and JS redirectors. Of the landing URLs we analyzed, the top three verticals targeted by attackers were personal sites and blogs, business and economy sites, and computer and internet information sites.

We found one threat particularly notable, where a JavaScript downloader evolved over time to more effectively evade detection. Earlier in its history, variants from this family were less obfuscated, but more recent versions are more highly obfuscated.

While cybercriminals continue to seek opportunities for malicious cyber activities, Palo Alto Networks customers receive protection from the web threat attacks discussed here as well as many others, via the Advanced URL Filtering, DNS Security and Threat Prevention cloud-delivered security services.

We also recommend the following actions:

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

Malicious Web Skimmer SHA256:
bb38741575706a94cc1a3ab43d445b641b2c225f408d67a76d3302ca1233e122

Train[.]developfirstline[.]com
Js[.]digestcolect[.]com
stat[.]trackstatisticsss[.]com

Acknowledgements

We would like to thank Mike Harbison, Billy Melicher, Alex Starov, Jun Javier Wang and Laura Novak for their help with the blog.

CNAME Cloaking: Disguising Third Parties Through the DNS

Posted on by Erica Naone

Executive Summary

When you visit a website, do you ever feel like you’re being watched? Who is observing your movements through that website - or across the internet in general? Is it possible to limit or at least understand that information flow?

With advertising at the heart of much of the internet, user data is an invaluable resource to those companies that profit from monitoring people’s online activities. In many cases, the information they collect provides helpful (if not truly necessary) support for a good user experience. In other cases, tracking practices infringe on people’s privacy, and they have raised valid concerns.

In response to these concerns, many groups have developed tools or adapted applications to protect user privacy. One step taken by major browsers is to block third-party cookies. This action has led analytics, advertising and marketing organizations to develop new strategies for collecting user information. One of these is CNAME cloaking.

CNAME cloaking leverages the Domain Name System (DNS) to hide when a browser is sending information to a domain controlled by a third party (such as an advertiser) rather than staying on the domain controlled by a website owner. CNAME cloaking undermines mechanisms that some people depend on to guard their privacy, and could lead to or be used with other practices that decrease people’s privacy.

Palo Alto Networks has developed a system to detect domains used in CNAME cloaking. The insights generated by this detector are available to Palo Alto Networks Next-Generation Firewall customers with cloud-delivered security services, including DNS Security and Advanced URL Filtering.

Related Unit 42 Topics DNS

How Tracking Leads to Cookies

Much of the content and many services available on the web are funded by revenue from advertising. Advertising has historically relied on tracking. This relationship stems from advertisers’ desire to maximize the efficiency of their marketing efforts.

One way advertisers try to maximize efficiency is to show people only advertisements for products or services they are likely to purchase. How do advertisers know which advertisements are actually relevant? While there is no cookie-cutter approach, tracking is currently a popular option.

In the context of the internet, tracking involves monitoring people’s activities within a website or across multiple websites. Tracking can serve many useful purposes.

For example, a website owner can use tracking data to personalize a customer’s experience, maintain their cart, or measure the effectiveness of an advertising campaign. Customers can benefit from these enhancements, and (where tracking is kept to a reasonable scope) issues regarding privacy can be limited. However, in practical application, the scope in which information is shared is often larger than a specific website or company.

Both website owners and advertisers use the services of companies specializing in analytics and marketing, which can include passing along user data. This data sometimes includes personal information. Even if it does not, the ability for various parties to collect information about users without their knowledge and consent – potentially across multiple sites and devices – has caused people much concern.

In response to these concerns, developers of major browsers began introducing features to protect people against certain types of tracking. One of the major changes developers made was to change how browser cookies are handled, by blocking third-party cookies or placing limitations on how they are accessed.

How Does Cookie Blocking Work?

A cookie is essentially a token that a website gives a user, which their browser is expected to send in communications with that website.

The cookie provides convenient support for tracking, in that it ties the request to the user, and it also tells the website owner what the user is doing.

A first-party cookie is generated by the owner of the domain hosting the website a person is browsing. Third-party cookies belong to a domain a user is not currently visiting, and they are usually used for advertising.

To give an example: suppose a user, Alice, browses www[.]example[.]com. Bob owns the domain example[.]com and has configured his servers to send users cookies when they visit the website hosted at that domain. When Alice browses to other pages in example[.]com (e.g. chocolate_chip.example[.]com or www[.]example[.]com/gingersnap), the messages that she sends will include that cookie. Figure 1 illustrates these interactions.

The user pictured browses to www[.]example[.]com. An HTTP Get request is sent to the site's webservers, and the owner has configured them to send users cookies in response. In this example, the cookie "my_cookies" is set to the value "peanut_butter." When the user in this example browses to other pages on this domain, the messages that she sends will include the cookie "peanut_butter," allowing her movements on the site to be tracked.
Figure 1. The cookie my_cookie is set via the headers in the response from www[.]example[.]com.
Depending on the cookie’s attributes and Alice’s browser configuration, Alice’s requests to example[.]com will only include the cookie if Alice is already browsing example[.]com. For example, Alice’s browser will include the cookie in a request for example[.]com/oatmeal.png if Alice is browsing www[.]example[.]com, but not if she is visiting www[.]example[.]net. This limitation helps to protect Alice’s privacy by preventing Bob from seeing what other sites Alice visits.

As another step to help protect Alice’s privacy, her browser can block cookies set by any domain other than example[.]net while Alice is browsing example[.]net. To illustrate this, suppose an advertisement from ads[.]example[.]com appears on www[.]example[.]net. The owner of ads[.]example[.]com sends Alice’s browser a cookie when serving the advertisement, and this would be a third-party cookie (as shown in Figure 2). If Alice’s browser is set to block third party cookies, the cookie will not be returned to example[.]com in future requests.

The user pictured browses to www[.]example[.]com. An HTTP Get request is sent to the site's webservers, and the owner has configured them to send users cookies in response. In this example, the cookie "my_cookies" is set to the value "peanut_butter." When the user in this example browses to other pages on this domain, the messages that she sends will include the cookie "peanut_butter," allowing her movements on the site to be tracked.
Figure 2. The cookie from example[.]com is a third-party cookie, and it is blocked.

What Is CNAME Cloaking?

The prospect of the elimination of third-party cookies has caused some concern among advertisers and companies providing web-traffic analytics. These organizations often have their content embedded in other websites, and they rely on cookies being sent from those websites to collect information about their audience so they can tailor their campaigns accordingly.

With the elimination of third-party cookies, these entities will have less information with which to target their ads or perform their analysis. To address this limitation, some have turned to a practice known as canonical name (aka CNAME) cloaking.

A CNAME record is a type of DNS resource record (RR) that maps an alternate domain name to its true name. CNAME records are also useful for directing users to a single domain from multiple domain names.

If a DNS resolver sends a request for the IP address of a domain and receives a CNAME record, the resolver will then typically query for the IP address of the CNAME. Once the resolver has the IP address, it will return that IP address to the client that initiated the query.

When browsers initiate DNS queries for the domain names of websites, they often do not have visibility into these queries, and thus will not know that a domain has a CNAME record. The browser only sees the original name; the IP address to which that name ultimately resolves.

Figure 3 shows the basic outline of how CNAME cloaking works. A website owner, Bob, embeds content provided by a third party into the website at www[.]example[.]com. That content is served from ad[.]example[.]com, which is a subdomain of the domain used to host the website.

Bob also creates a CNAME record for ad[.]example[.]com that points to a subdomain belonging to the tracker x[.]example[.]net. When Alice browses to www[.]example[.]com and her browser sends a request to ad[.]example[.]com, that request appears to be going to the same domain used to host the website.

Alice’s browser will treat cookies sent in the response from ad[.]example[.]com as first-party cookies. This is how CNAME cloaking allows third parties to receive and set cookies, circumventing protections the browser might have against such activity.

CNAME cloaking does not support the same level of tracking as would be available if third-party cookies were allowed. The practice is nevertheless concerning because it hides information about where people’s data is sent, and it might create other problems such as leaking information to the third party or creating new vulnerabilities.

The user pictured browses to www[.]example[.]com. An ad embedded on the site is located at x[.]example[.]net, but because the website owner created a CNAME record that resolves to the IP address 1.2.3[.]4, this tracking activity is disguised.
Figure 3. CNAME cloaking allows tracking activity to be disguised.

Defenses

CNAME cloaking is not a new strategy, and a few defenses have already been deployed in this area. Some of these defenses come in the form of browser extensions that rely on blocklists. However, blocklists do not provide a scalable approach to CNAME cloaking detection, as the number of first-party subdomains that can be used to point to third parties is almost limitless.

UBlock Origin is one extension that takes a different approach to detecting CNAME cloaking based on DNS lookups. However, this defense only works in Firefox due to restrictions on access to DNS APIs.

Privacy Badger also takes a slightly different approach and looks for tracking behavior. Unfortunately, this browser plugin only works to block third parties, and because CNAME cloaking disguises third parties this plugin does not protect against this technique.

In contrast to browser-based defenses, a DNS-based approach allows communication to be blocked based on the domain name of the tracker, rather than that of the subdomain used for tracking. A few other groups, such as AdGuard and NextDNS have used this strategy for ad blocking.

This DNS-based approach is more scalable than most browser-based approaches, and it is the one Palo Alto Networks has taken. Using the insights provided by our passive DNS data, we can see the subdomains resolving to domains belonging to known trackers. This information forms the basis of our CNAME cloaking detector. These results provide people with insights into which advertising or marketing organizations are accessing their data via CNAME cloaking. Customers can also block the cloaked fully qualified domain names (FQDNs).

CNAME Cloaking Detections in Action

After running for a month, our CNAME cloaking detector identified almost 43,000 cloaked subdomains in over 38,000 root domains. The cloaked subdomains have CNAME records pointing to domains belonging to 32 organizations, which are largely focused on analysis for advertising or marketing purposes (see Figure 4). The lists created by Adguard and EasyPrivacy each cover less than 10% of the subdomains we detect.

Of the domains using CNAME cloaking, 98% have a cloaked subdomain pointing to only one third-party domain. Several hundred subdomains rely on two third-party domains, and a handful rely on three or four domains.

Similarly, over 92% of domains using CNAME cloaking have only a single cloaked FQDN, but several thousand have two or more, and a few have over ten. We have even observed some cases where entities will create a wildcard record pointing to the third-party domain.

 

This chart shows newly detected first party domains using a tracker CNAME. The X-axis has a date range from June 22, 2022 to July 5, 2022. The Y-axis is delineated in increments of 50, between zero and 200. The key identifies nine specific marketing and analytics companies, and one category marked "other".
Figure 4. Newly detected first-party domains per day, by tracker.

As noted above, CNAME cloaking is not an indication of inherently malicious activity. However, it does cause several problems: it undermines practices designed to protect people’s privacy, it decreases visibility into where their data goes, and it can create additional vulnerabilities. Examining a sample of slightly over 4,000 of the cloaked FQDNs identified by our detector provides insights into how cloaking is used.

Cloaking for Third-Party Cookies

As expected, many domains use CNAME cloaking to support sending cookies that were generated in the first-party context to a third-party service.

For example, 85% of the websites using CNAME cloaking with Adobe Experience Cloud sent requests to the cloaked FQDN that contained an AMCV cookie. As Adobe’s documentation explains, an AMCV cookie allows a website owner to track users across the website or across multiple domains belonging to that owner.

Slightly over a third of the websites using Adobe sent a s_ecid cookie, which supports “persistent ID tracking in the 1st-party state,” and it is “used as a reference ID if the AMCV cookie has expired.” This cookie is only usable for domains leveraging CNAME cloaking.

Other Adobe Experience Cloud cookies sent by many of the domains using the service include the AMCVS cookie (a session cookie used to determine if the session has been initialized), the s_cc cookie (used to determine if cookies are enabled), and the s_ppv cookie (used to measure scroll activity).

Requests to cloaked domains with CNAMEs pointing to Mapp’s wt-eu02[.]net include a variety of cookies supporting several functions such as; load balancing, determining whether a visitor is a newcomer or returning guest on a website, and tracking. In our sample, 76% of sites relying on Mapp used at least one of these cookies.

About 14% of domains using Salesforce sent visitor_id and visitor_id<accountid>-hash cookies to their cloaked subdomains.

Evading Defenses With Cookie Syncing

The Salesforce cookies provide an interesting example of one way trackers are handling protections introduced by browsers. Salesforce has developed an approach to deal specifically with Safari’s limitations on third-party cookies with Intelligent Tracking Prevention (ITP) 1.2.

Following this approach, Salesforce customers embed code in their websites to retrieve a script from pi.pardot[.]com that sets the visit_id and visit_id<acountid>hash cookies, and then it retrieves a script from the customer’s cloaked domain (as shown in Figure 5).

Script retrieved from pi.pardot[.]com.
Figure 5. Script retrieved from pi.pardot[.]com.
The script retrieved does nothing (as shown in Figure 6), but the HTTP response headers set the same two cookies (shown in Figure 7).

The script retrieved from the cloaked domain does nothing.
Figure 6. Script retrieved from cloaked domain.
The HTTP response headers set the visit_id and visit_id<acountid>hash cookies.
Figure 7. Headers in response return a script from a cloaked domain.

This process results in identical cookies but with different domains (shown in Figure 8), which is an example of cookie syncing.

The visit_id and visit_id<acountid>hash cookies for the tracker and cloaked domains are the same.
Figure 8. The same cookie is set on the tracker domain and the cloaked domain.

Cookie Leaks

One consequence of using CNAME cloaking is that other first party cookies might automatically be sent to the cloaked FQDN. Unexpectedly, the most common cookies seen in requests to cloaked domains were not those set by the tracker involved in the cloaking, but those associated with Google Analytics (see Table 1).

Cookie Websites sending cookie to cloaked domain Tracker domains receiving cookie
_ga 322 18
_gid 299 17
_gcl_au 191 14
GoogleAnalytics_gat 149 10
GoogleAnalytcs_ga 95 15
Adobe_AMCV 92 2
Adobe_AMCVS 91 2
s_cc 85 3
GoogleAnalytics_gtm 80 9
Act-On Beacon Cookie 75 2

Table 1. These cookies are those seen most commonly in requests. Rows in blue indicate Google Analytics Cookies.

Other cookies commonly seen in the requests sent to cloaked FQDNs include those belonging to Hotjar, Microsoft and Dynatrace. None of these services are on our list of parties supporting CNAME cloaking.

Conclusion

Many websites use CNAME cloaking to circumvent browser restrictions on third-party cookies. It is useful for those who want to leverage the services of third-party analytics, advertising or marketing organizations efficiently.

While cookies and the services provided by organizations that deal in tracked information can serve constructive purposes, CNAME cloaking raises serious security and privacy concerns. First and foremost, the practice decreases visibility into who is receiving users’ data, and it limits people’s ability to control what’s done with their information. Secondly, CNAME cloaking can lead to extra user information being sent to third parties due to cookie leaks. Finally, the use of CNAME cloaking could indicate a willingness to undermine other privacy protections, as we also see it in conjunction with other questionable practices such as cookie syncing.

Palo Alto Networks detects domains using CNAME cloaking and assigns them to the adtracking category through our cloud-delivered security services for Next-Generation Firewalls. These subscriptions include DNS Security and Advanced URL Filtering. Through this detector, we provide our customers visibility into and control over where their data is sent.

Additional Resources

 

Trends in Web Threats: Old Web Skimmer Still Active Today

Posted on by Tao Yan

Executive Summary

Palo Alto Networks Advanced URL Filtering subscription collects data regarding two types of URLs; landing URLs and host URLs. We define a malicious landing URL as one that provides an opportunity for a user to click a malicious link. A malicious host URL is a web page that contains a malicious code snippet that could abuse someone’s computing power, steal sensitive information or perform other types of attacks.

Between January 2022 and March 2022, Palo Alto Networks detected over 577,000 instances of landing URLs, of which 20% were unique URLs. We also detected over two million host URLs, of which about 9% were unique URLs. This analysis was done using our web threat detection modules, which is used in our cloud-delivered security services such as Advanced URL Filtering.

In this blog, we present our analysis and findings around the latest trends of web threats like host and landing URLs including; where they are hosted, what categories they belong to, and which malware families are more likely to pose a threat. We also take a look at other threats such as skimmer attacks, downloaders and cryptominers.

With the help of Palo Alto Networks Advanced URL Filtering and Threat Prevention cloud-delivered security services, customers are protected from the threats discussed in this blog. Our web protection engine, Advanced URL Filtering, helps detect malicious URLs such as landing and host URLs. Our intrusion prevention system, Advanced Threat Prevention, applies added protection and helps prevent web threats like cryptomining and JavaScript downloading.

Types of Attacks and Vulnerabilities Covered Skimmer attacks, malware, cryptominers
Related Unit 42 Topics Information stealing, A Closer Look at the Web Skimmer , The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More

Web Threats Landing URLs: Detection Analysis

Palo Alto Networks crawls and analyzes millions of URLs from different sources every day, including newly seen URLs in customer traffic and email links. We collected web threat related data from customers with our Advanced URL Filtering subscription, using special YARA signatures.

Between January 2022 and March 2022, we detected 577,275 incidents involving landing URLs containing all kinds of web threats, 116,643 of which were unique URLs. We discovered, when compared to the previous quarter, the total number of incidents involving landing URLs increased while the number of unique URLs decreased.

Web Threats Landing URLs Detection: Time Analysis

As shown in Figure 1 and also mentioned in our blog, “Web Threats: Malicious Host URLs, Landing URLs and Trends”, we saw an increase in landing URLs in November 2021, and then began to see this number decline beginning in January through March 2022.

Bar chart showing web threat trends. January-March 2022 on the X-axis, and 0-250,000 on the Y-axis. Key indicates blue bars are all hits, and red bars are unique hits. January 2022 = 216,621 total hits: 46,534 unique hits. February 2022 = 212,643 total hits: 31,825 unique hits. March 2022 = 148,011 total hits: 38,284 unique hits.
Figure 1. Web threats landing URLs distribution January-March 2022. (Blue bars indicate all detections, including repeated detections of the same URL, and red bars indicate detection of unique URLs).

Web Threats Landing URLs: Geolocation Analysis

According to our analysis, the previously mentioned 116,643 malicious unique landing URLs came from 22,279 unique domains. After identifying the geographical locations of these domains, we found that the majority of them seem to originate from the United States, followed by Germany and Russia, which was also the case in the previous quarter. However, we recognized that attackers are leveraging proxy servers and VPNs located in those countries to hide their actual physical locations.

The choropleth map shown in Figure 2 shows the wide distribution of these domains across almost every continent, including Africa and Australia. Figure 3 shows the top eight countries where the owners of these domain names appeared to be located.

Choropleth map showing the geolocation distribution of landing URLs from January-March 2022
Figure 2. Web threats landing URLs’ domain geolocation distribution January-March 2022.
Pie chart showing distribution of originating country of landing URLs from January-March 2022. United States - 62.2%, Germany - 3.9%, Russia - 3.0%, France - 1.6%, United Kingdom, Brazil, Netherlands - 1.3%, Canada - 1.1%, Others - 24.3%
Figure 3. Top eight countries where web threat landing URLs’ domains originated from, between January 2022 and March 2022.

Web Threats Landing URLs: Category Analysis

We analyzed landing URLs that were originally identified by our detection module as benign, to find common targets for cyberattackers, and where they might be trying to fool users. These landing URLs can potentially lead to people clicking on a malicious host URL. Going forward, all these landing URLs that lead to malicious code snippets will be marked as malicious by our Advanced URL FIltering service.

As shown in Figure 4, the top apparently benign targets are business and economy sites, followed by personal sites and blogs, and then shopping sites. Compared to last quarter, the top two categories flipped. Because attackers often try to trick users into clicking malicious links from seemingly benign sites, we strongly recommend that users exercise caution when visiting an unfamiliar website.

Pie chart showing the top 10 categories hosting web threats from January-March 2022. Business and economy sites - 14.9%, personal sites and blogs - 9.1%, shopping - 7.8%, computer and internet - 7.5%, health and medicine - 5.5%, society - 4.8%, entertainment - 4.3%, web hosting - 3.6%, travel - 3.3%, parked - 2.9%, Others - 36.3%
Figure 4. We divided landing URLs that originally appeared benign into categories. Here are the top 10 categories that hosted web threats January-March 2022.

Web Threats Malicious Host URLs: Detection Analysis

With Advanced URL Filtering, we detected 2,043,862 incidents of malicious host URLs from January 2022 to March 2022, of which 180,370 were unique URLs. In the following section, we will take a closer look at those malicious host URLs. (“Malicious host URLs” specifically refers to pages that contain a malicious snippet that could abuse users' computing power, steal sensitive information and so on).

Web Threats Malicious Host URLs Detection: Time Analysis

As seen in our analysis of landing URLs, and also mentioned in our previous blog, “Web Threats: Malicious Host URLs, Landing URLs and Trends”, we discovered web threats were more active in November 2021 and slowly declined, beginning in January through March 2022.

Bar chart showing January-March 2022 on the X-axis, and 0-1,000,000 on the Y-axis. Key indicates blue bars are all hits, and red bars are unique hits. January 2022 = 841,284 total hits: 77,460 unique hits. February 2022 = 688,020 total hits: 50,996 unique hits. March 2022 = 514,558 total hits: 51,914 unique hits.
Figure 5. Web threats malicious host URLs distribution January-March 2022.

Web Threats Malicious Host URLs Detection: Geolocation Analysis

In our geolocation analysis of host URLs, we discovered that the 180,370 unique malicious host URLs belonged to 17,660 unique domains – fewer unique domains than we observed for landing URLs. This suggests attackers target different entry points but often use fewer domains to host the malicious code. The total number of unique malicious host URLs was otherwise higher than unique landing URLs, which suggests that attackers are deploying more malicious code when they can leverage a single entry point.

After identifying the apparent geographical locations of these domains, we found that the majority of them also seem to originate from the United States – as we observed for web threats generally. Figure 6 below shows the heat map.

Choropleth map showing the geolocation distribution of malicious host URLs from January-March 2022
Figure 6. Web threats malicious host URLs’ domain geolocation distribution January-March 2022.

Figure 7 shows the top eight countries where the owners of these domain names appeared to be located.

Pie chart showing distribution of originating country of malicious host URLs from January-March 2022. United States - 66.0%, Germany - 4.2%, Russia - 3.4%, France - 1.6%, Brazil - 1.5%, Netherlands - 1.3%, United Kingdom - 1.2%, Italy 1.1%, Others - 19.7%
Figure 7. Top eight countries where web threats malicious host URLs’ domains appeared to be located January-March 2022.

Web Threats Malware Class Analysis

The top five web threats we observed are cryptominers, JavaScript (JS) downloaders, web skimmers, web scams and JS redirectors. Please refer to our previous analysis for the definition of these classes: “The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More”.

As shown in Figure 8, JS downloader threats showed the most activity at the start of 2022, followed by web miners (aka cryptominers) and web skimmers which was similar to the previous quarter.

Bar chart showing js_downloader, web_miner, web_skimmer, js_redirector and web_scam on the X-axis, and 0-1,000,000 on the Y-axis. Key indicates blue bars are all hits, and red bars are unique hits. Js_downloader = 889,106 total hits: 70,081 unique hits. Web_miner = 463,611 total hits: 25,917 unique hits. Web_skimmer = 351,660 total hits: 29,728 unique hits. Js_redirector = 192,096 total hits: 4,990 unique hits. Web_scam = 80,158 total hits: 12,401 unique hits.
Figure 8. Top five web threats category distribution January-March 2022.

Web Threats Malware Family Analysis

Based on our classification of web threats explained in the previous section, we further categorized them by malware family. The family is important to understanding how threats work since threats in the same family share similar JS code, even if the HTML landing pages where they appear have different layouts and styles.

As we did in our yearly analysis, The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More, we identified pieces of malware as part of a family by checking for certain characteristics: similar code patterns or behaviors, or indications of having originated from the same attacker.

Figure 9 shows the number of snippets observed from the top 18 malware families we identified. As we’ve seen previously, there were fewer families of cryptominers and JS downloaders, while web skimmers showed more diversity in code and behavior.

Bar chart showing the web threat families along the X-axis, and 0-200,000 on the Y-axis. Key indicates that blue bars are total hits, and red bars are unique hits. There are 3 Coinhive families, 8 skimmer families, 4 downloader families, 1 redirector family, and 2 web scam families represented.
Figure 9. Web threats malware family distribution January-March 2022.

Web Threats Case Study

Among all of the web threats we detected during this analysis, the most notable was a web skimmer that we identified, which has been active for the last five years.

As shown in Figure 10, the source code of this web skimmer was injected into the target web page with a lightly obfuscated JS code.

Lightly obfuscated JS source code injected into the target web page
Figure 10. Source code of a web skimmer that has been active for at least five years.

After deobfuscating and clarifying the JS code as shown in Figure 11, we can extract the collection server of the web skimmer: cloudfusion[.]me. This web skimmer is simple, yet classic.

It checks whether the current URL is the payment page by comparing the window.location.href property with the strings onepage or checkout. If a match is found, the code collects the inputs from the input and select elements (as well as other sensitive information from customers) when the button is clicked.

The code then sends that information to the remote collection server, https://cloudfusion[.]me/cdn/jquery.min.js, which is controlled by the attacker.

Deobfuscated source code showing the address of the remote collection server
Figure 11. Deobfuscated source code of the web skimmer that has been active at least five years.

As early as 2017, researchers reported that this web skimmer pretended to be a part of the JQuery library. From our detection data, we found that this web skimmer is still very active in 2022.

There are 27,917 URLs from 14 different websites that the attacker injected with this web skimmer family. Based on our telemetry, this threat is one of the most active web skimmers in recent history.

There is a malicious JavaScript file named jquery.min.js, which is hosted on the server controlled by the attacker. It is responsible for receiving sensitive information sent by the web skimmer. By searching for the SHA value of jquery.min.js as shown in Figure 12, we can see it was once hosted on different IP addresses that were located in Germany and Russia.

Virus Total relations tab results for jquery.min.js showing different in-the-wild IP addresses in Germany and Russia
Figure 12. Relations about jquery.min.js

Since March 13, 2020, cloudfusion[.]me has started pointing to the following IP addresses:

  • 198.54.117[.]197
  • 198.54.117[.]198
  • 198.54.117[.]199
  • 198.54.117[.]200

These IP addresses are actively involved in other malware campaigns, such as the following Trojan (SHA256: 992cfcb5790664d02204e5356e3dd6e109f0cba90b8e552598f2afb11f468a1f). They connect to these IPs through the domain voques-tfr[.]xyz.

Although this domain is not resolvable anymore, we analyzed the malware traffic based on another similar request to the URL www.misuperblog[.]com/tmz/?sRjPP6ZH=21Ru2Nt5y6IynFa8dNKfckGmLKuTraB2ebSZxsJ3CJwKQtaV8aXvWfS0YurLHqXx0CGvRSPYnS9vGtnwfQCtQg==&EZ442V=IbnToV6xqdfx. We found that this URL loads obfuscated JS that triggers several redirects to an adult website (yhys93[.]site).

Conclusion

As we highlighted in this blog, this quarter’s most prevalent web threats were cryptominers, JS downloaders, web skimmers, web scams and JS redirectors. Of the landing URLs we analyzed, the top three industry verticals targeted by attackers were business and economy sites, personal sites and blogs, and shopping sites.

Furthermore, we found an old web skimmer is still active after five years. This shows that old threats can remain popular for long periods of time, and that it is critical for users to exercise caution when visiting unfamiliar sites.

While cybercriminals continue to seek opportunities for malicious cyber activities, Palo Alto Networks customers benefit from protection against web threats discussed in this blog and many others, via our Advanced URL Filtering and Advanced Threat Prevention cloud-delivered security subscriptions.

We also recommend the following actions:

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

Malicious Web Skimmer SHA256:

79eedf9c1b974992a4beada1bd6343ecadece0b413acccd4deded4a49a4ad220
992cfcb5790664d02204e5356e3dd6e109f0cba90b8e552598f2afb11f468a1f

Acknowledgements

We would like to thank Billy Melicher, Alex Starov, Jun Javier Wang, Mitchell Bezzina, Ashraf Aziz and Jen Miller Osborn for their help with the blog.

Detecting Emerging Network Threats From Newly Observed Domains

Posted on by Zhanhao Chen

Executive Summary

In May 2021, Palo Alto Networks launched a proactive detector employing state-of-the-art methods to recognize malicious domains at the time of registration, with the aim of identifying them before they are able to engage in harmful activities. The system scans newly registered domains (NRDs) and detects potential network abuses. However, the proactive detector has limitations; created to only focus on new domains, it cannot obtain and analyze malicious indicators appearing after a domain's creation. In addition, in the cases of adversaries leveraging or compromising aged domains to carry out attack traffic, the proactive detector fails to capture the emerging threats because the malicious domains are out of the scope of being considered NRDs.

In addition to scanning for potential abuses at the time of registration, we have another great opportunity to detect malicious domains proactively when they start carrying attack traffic. A malicious domain may be registered long before it serves its attacking campaign and exposes indicators of abuse. Once the domain starts carrying malicious traffic, we can observe its DNS requests from passive DNS. To block network threats at this early stage, we developed a new proactive detector that ingests newly observed domains (NODs) to discover potential threats among them. The new detector leverages various machine learning techniques to expose suspicious behaviors based on various information about NODs, including their latest WHOIS records and DNS traffic.

This blog will illustrate how we collect and analyze the enriched features available for NODs to detect emerging threats. Our detector scans 2.6 million NODs and captures around 2,300 suspicious domains every day. To evaluate the performance, we cross-checked the detected domains against other threat intelligence from VirusTotal. 33.08% of the NODs detected by our system were also labeled as malicious by other sources later. But our detector's average discovery time is 4.79 days earlier than any VirusTotal vendor. Furthermore, we will explain the new system's benefits with case studies about various network abuses such as command and control (C2), phishing and unethical search engine optimization (SEO) practices. We will discuss how the proactive detector captured and blocked these threats based on different indicators for cybercriminal activities.

Once the proactive detector captures a potentially harmful domain, the knowledge is distributed from DNS Security to other Palo Alto Networks Cloud-Delivered Security Services, including URL Filtering and WildFire.

Related Unit 42 Topics DNS Security

Detection Methods and High-level Statistics

Palo Alto Networks collects passive DNS data from multiple sources, including our DNS Security service, as well as external providers from all around the world. Our cloud-based passive DNS system can ingest and process about 13 million DNS logs each day. The data ingestion pipeline catches the latest DNS data every hour and extracts the domains that haven't been seen carrying traffic before. These domains will be forwarded to the proactive detector to identify emerging threats. Our system can capture and scan about 2.6 million NODs daily.

Number of newly observed domains shown in blue bars. Detection percentage shown in red line. Period covered is April 27, 2022-May 23, 2022
Figure 1. Daily NOD amount and the percentage flagged as suspicious.

For each NOD, our centralized data collector will actively crawl all related information, including the latest WHOIS record and all DNS traffic requesting the domain and its subdomains. To leverage a variety of malicious indicators, we developed individual machine learning models to analyze different information. Specifically, we built a reputation system to evaluate WHOIS records, applied multiple classification models to DNS-related features, and used the bigram model to analyze hostnames. These models captured about 2,323 unique potentially malicious NODs every day. Figure 1 shows the daily NOD amount and detection rate from April 27-May 2, 2022.

Number of days between when a domain is considered a newly registered domain (NRD) and when it is considered a newly observed domain (NOD). The graph shows the cumulative distribution function of their dormant periods.
Figure 2. Malicious NOD Dormant Period CDF.

To analyze attackers' behaviors, we compare the registration date of potentially malicious NODs and the date when they start hosting DNS traffic to see how long they keep silent before activation. Figure 2 presents the cumulative distribution function (CDF) of their dormant periods. The malicious domains start carrying traffic 5.57 days after their registration on average. However, during the period studied, our detector captured 152 NODs involving network abuses more than one year after creation – some domains can lie dormant for a significant amount of time before beginning malicious activity.

The cumulative distribution function of how many days before any vendor of VirusTotal the proactive detector was able to flag malicious domains among newly observed domains.
Figure 3. Early discovery time CDF.

Of all suspicious NODs detected by the new proactive system, 37.11% were labeled as confirmed malicious 30 days later by Palo Alto Networks or other threat intelligence vendors in VirusTotal. Figure 3 shows the CDF of how many days before any vendor on VirusTotal the proactive detector was able to flag malicious domains. On average, our detector can capture these malicious domains and isolate their traffic 4.79 days before any VirusTotal vendor blocks them. Furthermore, we can discover 19.47% of malicious NODs more than a week earlier than others.

Broader Visibility Into Emerging Internet Threats

One major benefit of our new proactive malicious NOD detector is that it extends visibility into emerging attacking domains. The previous proactive detector scans threats among NRDs only. However, not all top-level domains (TLDs) disclose their new domains to the public. For example, hundreds of country-level TLDs are maintained by governments. Access to their complete domain list or WHOIS database is restricted.

Let's take a malicious domain within the .ga TLD, for instance. Our proactive detector captured and labeled the NOD payment-downlaods[.]ga as grayware on March 4. .ga is the country code TLD for Gabon. This TLD offers free domain registration, but its domains’ creation dates are not available in the WHOIS records. Therefore, we cannot directly confirm .ga NRDs based on the registration information. Monitoring passive DNS data is the primary way to detect recently active .ga domains. We caught payment-downlaods[.]ga carrying C2 traffic 12 days after we first observed its DNS traffic. The domain served Android Package Kit (APK) spyware that attempted to steal private information including SMS messages (SHA256: e9ad04ae0201307e061cdae350c392a6b4537876991b2c97857ea71086fa0496).

Besides textual characteristics, the WHOIS record is another important feature that can be used for proactive malicious domain detection. It can expose various network abuse warning signs such as registrants, registrars and name servers. Our malicious NOD detector will actively crawl new domains’ WHOIS records for analysis once we observe their DNS traffic.

For example, our detector blocked a phishing domain within the .ml TLD as soon as we observed it in passive DNS data on May 10. The centralized WHOIS database for .ml is not publicly available, so the detectors focusing on NRDs failed to inspect this domain. However, once it began to carry traffic, the proactive malicious NOD detector crawled its WHOIS record and found the name server is offshoreracks[.]com, which provides an offshore and anonymous hosting service. Besides this questionable name server, the NOD's registrar also has a bad reputation. The NOD is a squatting domain mimicking a major international banking group based in Italy. The phishing website copied the text from the official site but with fake contact information. Interestingly, despite mimicking an Italian bank, the website uses Turkish, so it's likely intended to target Turkish victims.

Capture More Malicious Indicators

Unlike the WHOIS record that is available once a domain is created, some indicators for cybercriminal activities will only be exposed after a malicious domain starts carrying attacking traffic. Therefore, our detector also analyzes the DNS traffic of NODs to capture any suspicious behaviors.

Example of a scam page hosted on a DGA subdomain that asks for notification permissions. The presence of a large number of subdomains produced by DGAs can be an indicator that a newly observed domain is suspicious.
Figure 4. Black hat SEO page hosted on DGA subdomain of twtyowq[.]tk.
One of the abnormal DNS traffic patterns that is highly related to network threats is the presence of a large number of subdomains produced by domain generation algorithms (DGAs). Attackers could use these subdomains to exfiltrate stolen information or perform black hat search engine optimization (SEO) with wildcard DNS. Our proactive detector leverages this indicator to identify potentially abused NODs.

Let's take a pop-up advertising campaign that we detected as an example. This campaign was distributed through .tk domains such as twtyowq[.]tk, bsdybwo[.]tk and bwafduj[.]tk. The creation time of .tk domains is unavailable so we cannot obtain any NRDs under this zone. However, when we first saw these domains' DNS traffic, each of them had hundreds of DGA subdomains hosting scam pages asking for notification permission and redirecting visitors to unwanted ads (see Figure 4).

Traffic from gateway domains such as jxc786[.]com will reach this gambling website, but if a visitor opens the subdomain directly, they are redirected to a search engine for cloaking.
Figure 5. Gambling website hosted on jxc786[.]com.
Besides explicit DGA subdomains, our detector digs deeper into NODs' DNS logs to expose DGA traffic hidden behind them. For example, the domain jxc786[.]com was registered on April 23, but we didn't see any evidence of cybercriminal activity at that time. However, it started pointing to b136jishiang01hy.bakbitionb[.]com on May 22. bakbitionb[.]com is the infrastructure domain for a gambling campaign. In passive DNS, this domain has hundreds of DGA subdomains associated with different gateway domains through CNAME records. If visitors directly open these DGA subdomains in their browsers, they will be redirected to baidu[.]com for cloaking. However, traffic from gateway domains such as jxc786[.]com will reach the gambling website shown in Figure 5.

A phishing page hosted on a subdomain as part of an attempt to use levelsquatting to impersonate Apple.
Figure 6. Fake iCloud account recovery page hosted on asuna-sao[.]us.
The proactive detector can also discover and block levelsquatting subdomains from NODs’ passive DNS records. The levelsquatting technique includes a legitimate website’s domain as a subdomain in order to trick visitors into thinking they have arrived at the legitimate website. It is commonly used in conjunction with phishing attacks.

For example, our system recognized multiple subdomains of asuna-sao[.]us as levelsquatting hostnames masquerading as Apple Inc and labeled the domain as dangerous. The domain was registered on April 12 and started receiving traffic for subdomains like www.flnd-appleld.asuna-sao[.]us, www.lcloud-supoort.asuna-sao[.]us and www.apple-flnd.asuna-sao[.]us on the same day. These hostnames all deliver the same phishing page, which tries to steal Apple ID credentials (Figure 6).

Capture Aged Malicious Domains

In previous writing on strategically aged domains, we reported that some had been registered years before they were actively involved in cybercriminal campaigns. These domains didn't reveal any indicator for network abuses when they were created. Monitoring NODs gives us a second chance to capture aged malicious domains.

A rogue advertising page hosted shortly after the domain's WHOIS record was updated, illustrating how it can be important to check newly observed domains for malicious indicators even if they were benign at the time of registration.
Figure 7. Advertisement page hosted on createruler[.]com.
When crawling NODs' WHOIS records, we discover that many aged domains have recent WHOIS record changes before they are involved in network abuses. For example, createruler[.]com was registered in May 2022. Its WHOIS was updated on June 3, 2022. Then the domain started hosting a rogue advertising page, as shown in Figure 7. Our proactive detector analyzed its latest WHOIS record and classified it as suspicious based on its use of a highly abused name server. The name server is a parking service provider that monetizes domains' traffic through advertisement networks. This kind of parking site could expose visitors to various threats, such as malware distribution, potentially unwanted program (PUP) distribution and phishing scams.

The proactive detector also captured some domains repeatedly leveraged by network threats. For example, we captured a squatting domain mimicking a major digital payment network based in the United States. It used to serve a phishing campaign in 2020 and expired in 2021. But the adversary registered it again on March 13, 2022. Our detector observed it started carrying traffic and recognized it as a potentially malicious NOD on Sept. 2, 2022. The domain hosts a rogue website that tags the legitimate target domain on the index page and tries to collect the visitor's contact information. This website is highly suspicious and likely to be engaged in network fraud.

Conclusion

At Palo Alto Networks, we extract NODs from passive DNS and proactively detect potential cybercriminal activities among them. The new detector leverages various machine learning techniques to capture indicators for network abuses from WHOIS records, DNS traffic and lexical features. The system extends our visibility on emerging network threats and identifies new kinds of suspicious behaviors. As a result, it can discover about 2,323 potentially malicious domains as soon as they become active every day and protect our customers on average 4.79 days before the domains are confirmed to be involved in attacking campaigns.

Palo Alto Networks identifies the detected domains with the grayware category through our cloud-delivered security services for Next-Generation Firewalls, including URL Filtering and DNS Security. Our customers receive protections against damage from risky domains mentioned in this blog, as well as additional risky domains captured by our system.

Indicators of Compromise

C2 Domain

payment-downlaods[.]ga

Phishing Domains

asuna-sao[.]us
intesa-sanpaola[.]ml
zellesupport[.]info

Grayware Domains

bakbitionb[.]com
bsdybwo[.]tk
bwafduj[.]tk
createruler[.]com
jxc786[.]com
twtyowq[.]tk

SHA256

e9ad04ae0201307e061cdae350c392a6b4537876991b2c97857ea71086fa0496

 

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow