Mayors’ offices and courts in Russia are under attack by never-before-seen malware that poses as ransomware but is actually a wiper that permanently destroys data on an infected system, according to security company Kaspersky and the Izvestia news service.
Kaspersky researchers have named the wiper CryWiper, a nod to the extension .cry that gets appended to destroyed files. Kaspersky says its team has seen the malware launch “pinpoint attacks” on targets in Russia. Izvestia, meanwhile, reported that the targets are Russian mayors’ offices and courts. Additional details, including how many organizations have been hit and whether the malware successfully wiped data, weren’t immediately known.
Wiper malware has grown increasingly common over the past decade. In 2012, a wiper known as Shamoon wreaked havoc on Saudi Arabia’s Saudi Aramco and Qatar’s RasGas. Four years later, a new variant of Shamoon returned and struck multiple organizations in Saudi Arabia. In 2017, self-replicating malware dubbed NotPetya spread across the globe in a matter of hours and caused an estimated $10 billion in damage. In the past year, a flurry of new wipers appeared. They include DoubleZero, IsaacWiper, HermeticWiper, CaddyWiper, WhisperGate, AcidRain, Industroyer2, and RuRansom.
Kaspersky said it discovered the attack attempts by CryWiper in the last few months. After infecting a target, the malware left a note demanding, according to Izvestia, 0.5 bitcoin and including a wallet address where the payment could be made.
“After examining a sample of malware, we found out that this Trojan, although it masquerades as a ransomware and extorts money from the victim for ‘decrypting’ data, does not actually encrypt, but purposefully destroys data in the affected system,” Kaspersky’s report stated. “Moreover, an analysis of the Trojan’s program code showed that this was not a developer’s mistake, but his original intention.”
CryWiper bears some resemblance to IsaacWiper, which targeted organizations in Ukraine. Both wipers use the same algorithm for generating pseudo-random numbers that go on to corrupt targeted files by overwriting the data inside of them. The name of the algorithm is the Mersenne Vortex PRNG. The algorithm is rarely used, so the commonality stuck out.
CryWiper shares a separate commonality with ransomware families known as Trojan-Ransom.Win32.Xorist and Trojan-Ransom.MSIL.Agent. Specifically, the email address in the ransom note of all three is the same.
The CryWiper sample Kaspersky analyzed is a 64-bit executable file for Windows. It was written in C++ and compiled using the MinGW-w64 toolkit and the GCC compiler. That’s an unusual choice since it’s more common for malware written in C++ to use Microsoft’s Visual Studio. One possible reason for this choice is that it gives the developers the option of porting their code to Linux. Given the number of specific calls CryWiper makes to Windows programming interfaces, this reason seems unlikely. The more likely reason is that the developer writing the code was using a non-Windows device.
Successful wiper attacks often take advantage of poor network security. Kaspersky advised network engineers to take precautions by using:
Behavioral file analysis security solutions for endpoint protection.
Managed detection and response and security operation center that allow for timely detection of an intrusion and take action to respond.
Dynamic analysis of mail attachments and blocking of malicious files and URLs. This will make email attacks, one of the most common vectors, more difficult.
Conducting regular penetration testing and RedTeam projects. This will help to identify vulnerabilities in the organization’s infrastructure, protect them, and thereby significantly reduce the attack surface for intruders.
Threat data monitoring. To detect and block malicious activity in a timely manner, it is necessary to have up-to-date information about the tactics, tools, and infrastructure of intruders.
Given Russia’s invasion of Ukraine and other geopolitical conflicts raging around the globe, the pace of wiper malware isn’t likely to slow in the coming months.
“In many cases, wiper and ransomware incidents are caused by insufficient network security, and it is the strengthening of protection that should be paid attention to,” Friday’s Kaspersky report stated. “We assume that the number of cyberattacks, including those using wipers, will grow, largely due to the unstable situation in the world.”
Microsoft on Thursday fingered Russia’s military intelligence arm as the likely culprit behind ransomware attacks last month that targeted Polish and Ukrainian transportation and logistics organizations.
If the assessment by members of the Microsoft Security Threat Intelligence Center (MSTIC) is correct, it could be cause for concern for the US government and its European counterparts. Poland is a member of NATO and a staunch supporter of Ukraine in its bid to stave off an unprovoked Russian invasion. The hacking group the software company linked to the cyberattacks—known as Sandworm in wider research circles and Iridium in Redmond, Washington—is one of the world’s most talented and destructive and is widely believed to be backed by Russia’s GRU military intelligence agency.
Sandworm has been definitively linked to the NotPetya wiper attacks of 2017, a global outbreak that a White House assessment said caused $10 billion in damages, making it the most costly hack in history. Sandworm has also been definitively tied to hacks on Ukraine’s power grid that caused widespread outages during the coldest months of 2016 and again in 2017.
Last month, Microsoft said that Poland and Ukraine transportation and logistics organizations had been the target of cyberattacks that used never-before-seen ransomware that announced itself as Prestige. The threat actors, Microsoft said, had already gained control over the victim networks. Then in a single hour on October 11, the hackers deployed Prestige across all its victims.
Once in place, the ransomware traversed all files on the infected computer’s system and encrypted the contents of files that ended in .txt, .png, gpg, and more than 200 other extensions. Prestige then appended the extension .enc to the existing extension of the file. Microsoft attributed the attack to an unknown threat group it dubbed DEV-0960.
On Thursday, Microsoft updated the report to say that based on forensic artifacts and overlaps in victimology, tradecraft, capabilities, and infrastructure, researchers determined DEV-0960 was very likely Iridium.
“The Prestige campaign may highlight a measured shift in Iridium’s destructive attack calculus, signaling increased risk to organizations directly supplying or transporting humanitarian or military assistance to Ukraine,” MSTIC members wrote. “More broadly, it may represent an increased risk to organizations in Eastern Europe that may be considered by the Russian state to be providing support relating to the war.”
Thursday’s update went on to say that the Prestige campaign is distinct from destructive attacks in the past two weeks that used malware tracked as AprilAxe (ArguePatch)/CaddyWiper or Foxblade (HermeticWiper) to target multiple critical infrastructures in Ukraine. While the researchers said they still don’t know what threat group is behind those acts, they now have enough evidence to finger Iridium as the group behind the Prestige attacks. Microsoft is in the process of notifying customers who have been “impacted by Iridium but not yet ransomed,” they wrote.
Underscoring the sophistication of the attacks, Iridium members used multiple methods for deploying Prestige on the targeted networks. They included:
Windows scheduled tasks
encoded PowerShell commands, and
Default Domain Group Policy Objects
“Most ransomware operators develop a preferred set of tradecraft for their payload deployment and execution, and this tradecraft tends to be consistent across victims, unless a security configuration prevents their preferred method,” MSTIC members explained. “For this Iridium activity, the methods used to deploy the ransomware varied across the victim environments, but it does not appear to be due to security configurations preventing the attacker from using the same techniques. This is especially notable as the ransomware deployments all occurred within one hour.”
The post contains technical indicators that can help people figure out if they have been targeted.
Microsoft is facing criticism for the way it disclosed a recent security lapse that exposed what a security company said was 2.4 terabytes of data that included signed invoices and contracts, contact information, and emails of 65,000 current or prospective customers spanning five years.
The data, according to a disclosure published Wednesday by security firm SOCRadar, spanned the years 2017 to August 2022. The trove included proof-of-execution and statement of work documents, user information, product orders/offers, project details, personally identifiable information, and documents that may reveal intellectual property. SOCRadar said it found the information in a single data bucket that was the result of a misconfigured Azure Blob Storage.
Microsoft can’t, or Microsoft won’t?
Microsoft posted its own disclosure on Wednesday that said the security company “greatly exaggerated the scope of this issue” because some of the exposed data included “duplicate information, with multiple references to the same emails, projects, and users.” Further using the word “issue” as a euphemism for “leak,” Microsoft also said: “The issue was caused by an unintentional misconfiguration on an endpoint that is not in use across the Microsoft ecosystem and was not the result of a security vulnerability.”
Absent from the bare-bones, 440-word post were crucial details, such as a more detailed description of the data that was leaked or how many current or prospective customers Microsoft really believes were affected. Instead, the post chided SOCRadar for using numbers Microsoft disagreed with and for including a search engine people could use to determine if their data was in the exposed bucket. (The security company has since restricted access to the page.)
When one affected customer contacted Microsoft to ask what specific data belonging to their organization was exposed, the reply was: “We are unable to provide the specific affected data from this issue.” When the affected customer protested, the Microsoft support engineer once again declined.
Critics also faulted Microsoft for the way it went about directly notifying those who were affected. The company contacted affected entities through Message Center, an internal messaging system that Microsoft uses to communicate with administrators. Not all administrators have the ability to access this tool, making it likely that some notifications have gone unseen. Direct messages displayed on Twitter also showed Microsoft saying that the company wasn’t required by law to disclose the lapse to authorities.
“MS being unable (read: refusing) to tell customers what data was taken and apparently not notifying regulators—a legal requirement—has the hallmarks of a major botched response,” Kevin Beaumont, an independent researcher, wrote on Twitter. “I hope it isn’t.”
As the Grayhat Warfare images Beaumont posted indicate, the cached data included digitally signed contracts and purchase orders. He said that other exposed data includes “emails from US .gov, talking about O365 projects, money etc.” It also included information pertaining to CNI, short for critical national infrastructure.
Besides criticism of the way Microsoft has gone about disclosing the leak, the incident also raises questions about Microsoft’s data retention policies. Often, years-old data is of more benefit to potential criminals than it is to the company holding it. In cases like these, the best course is often to periodically destroy the data.
Microsoft didn’t immediately respond to an email seeking comment for this story.
Prospective or actual Microsoft enterprise customers over the past five years should review both blog posts linked above and also check Message Center for any exposure notifications. In the event an organization is affected, personnel should be on the lookout for scams, phishing emails, or other attempts to exploit the exposed information.
For almost two years, Microsoft officials botched a key Windows defense, an unexplained lapse that left customers open to a malware infection technique that has been especially effective in recent months.
Microsoft officials have steadfastly asserted that Windows Update will automatically add new software drivers to a blocklist designed to thwart a well-known trick in the malware infection playbook. The malware technique—known as BYOVD, short for “bring your own vulnerable driver”—makes it easy for an attacker with administrative control to bypass Windows kernel protections. Rather than writing an exploit from scratch, the attacker simply installs any one of dozens of third-party drivers with known vulnerabilities. Then the attacker exploits those vulnerabilities to gain instant access to some of the most fortified regions of Windows.
It turns out, however, that Windows was not properly downloading and applying updates to the driver blocklist, leaving users vulnerable to new BYOVD attacks.
As attacks surge, Microsoft countermeasures languish
Drivers typically allow computers to work with printers, cameras, or other peripheral devices—or to do other things such as provide analytics about the functioning of computer hardware. For many drivers to work, they need a direct pipeline into the kernel, the core of an operating system where the most sensitive code resides. For this reason, Microsoft heavily fortifies the kernel and requires all drivers to be digitally signed with a certificate that verifies they have been inspected and come from a trusted source.
Even then, however, legitimate drivers sometimes contain memory corruption vulnerabilities or other serious flaws that, when exploited, allow hackers to funnel their malicious code directly into the kernel. Even after a developer patches the vulnerability, the old, buggy drivers remain excellent candidates for BYOVD attacks because they’re already signed. By adding this kind of driver to the execution flow of a malware attack, hackers can save weeks of development and testing time.
Over the past couple of years, we have seen a rash of new BYOVD attacks. One such attack late last year was carried out by the North Korean government-backed Lazarus group. It used a decommissioned Dell driver with a high-severity vulnerability to target an employee of an aerospace company in the Netherlands and a political journalist in Belgium.
In a separate BYOVD attack a few months ago, cybercriminals installed the BlackByte ransomware by installing and then exploiting a buggy driver for Micro-Star’s MSI AfterBurner 184.108.40.20658, a widely used graphics card overclocking utility.
Microsoft is acutely aware of the BYOVD threat and has been working on defenses to stop these attacks, mainly by creating mechanisms to stop Windows from loading signed-but-vulnerable drivers. The most common mechanism for driver blocking uses a combination of what’s called memory integrity and HVCI, short for Hypervisor-Protected Code Integrity. A separate mechanism for preventing bad drivers from being written to disk is known as ASR, or Attack Surface Reduction.
Unfortunately, neither approach seems to have worked as well as intended.
Over the past 15 years, Microsoft has made huge progress fortifying the Windows kernel, the core of the OS that hackers must control to successfully take control of a computer. A cornerstone of that progress was the enactment of strict new restrictions on the loading of system drivers that could run in kernel mode. These drivers are crucial for computers to work with printers and other peripherals, but they’re also a convenient inroad that hackers can take to allow their malware to gain unfettered access to the most sensitive parts of Windows. With the advent of Windows Vista, all such drivers could only be loaded after they’d been approved in advance by Microsoft and then digitally signed to verify they were safe.
Last week, researchers from security firm ESET revealed that about a year ago, Lazarus, a hacking group backed by the North Korean government, exploited a mile-wide loophole last year that existed in Microsoft’s driver signature enforcement (DSE) from the start. The malicious documents Lazarus was able to trick targets into opening were able to gain administrative control of the target’s computer, but Windows’ modern kernel protections presented a formidable obstacle for Lazarus to achieve its objective of storming the kernel.
Path of least resistance
So Lazarus chose one of the oldest moves in the Windows exploitation playbook—a technique known as BYOVD, short for bring your own vulnerable driver. Instead of finding and cultivating some exotic zero-day to pierce Windows kernel protections, Lazarus members simply used the admin access they already had to install a driver that had been digitally signed by Dell prior to the discovery last year of a critical vulnerability that could be exploited to gain kernel privileges.
ESET researcher Peter Kálnai said Lazarus sent two targets—one an employee of an aerospace company in the Netherlands and the other a political journalist in Belgium—Microsoft Word documents that had been booby-trapped with malicious code that infected computers that opened it. The hackers’ objective was to install an advanced backdoor dubbed Blindingcan but to make that happen, they first had to disable various Windows protections. The path of least resistance, in this case, was simply to install dbutil_2_3.sys, the buggy Dell driver, which is responsible for updating Dell firmware through Dell’s custom Bios Utility.
“For the first time in the wild, the attackers were able to leverage CVE-2021-21551 for turning off the monitoring of all security solutions,” Kálnai wrote, referring to the designation used to track the vulnerability in the Dell driver. “It was not just done in kernel space, but also in a robust way, using a series of little- or undocumented Windows internals. Undoubtedly this required deep research, development, and testing skills.”
In the case involving the journalist, the attack was triggered but was quickly stopped by ESET products, with just one malicious executable involved.
While it may be the first documented case of attackers exploiting CVE-2021-21551 to pierce Windows kernel protections, it’s by no means the first instance of a BYOVD attack. A small sampling of previous BYOVD attacks include: