SentinelOne Integrates With Amazon Security Lake to Power Cloud Investigations

SentinelOne is pleased to announce an integration with Amazon Security Lake, a new Amazon Web Services (AWS) security service that enables organizations to aggregate, store, normalize, and analyze security logs from integrated cloud and on-premises data sources and their private applications at scale. SentinelOne ingests these logs into the Singularity™ XDR Platform for threat hunting, forensics, and to help investigate and establish root cause of security alerts from Singularity Cloud Workload Security.

Amazon Security Lake stores and exports logs using the Open Cybersecurity Schema Framework (OCSF). With support for the OCSF standard, Amazon Security Lake reduces the complexity and costs for customers to make their security solutions’ data more readily accessible, to address a wide variety of use cases such as threat detection, investigation, and incident response.

As part of this integration, SentinelOne has natively adopted OCSF as our XDR data schema so that customers can natively view and query these security logs in the Singularity XDR Platform without the hassle of data transformation. This integration is available for customers participating in the Skylight beta program, which extends the Singularity XDR Platform to partner data sources.

What is OCSF?

OCSF is an open-source security data schema co-founded by AWS in cooperation with security software vendors. By creating an open standard, security data from any number of sources is more easily shared and correlated across various security platforms, thereby creating a more comprehensive view of security and improving security outcomes (e.g., reducing MTTR).

Logs and alerts that leverage OCSF use a common set of fields and formats so that users don’t have to parse and normalize them. In so doing, security analysts, incident responders, and threat hunters have a more enriched dataset to streamline their work.

By more readily sharing security data, it is moved from various siloes and consolidated into a security platform where its value can be unlocked. Better data drives better outcomes.

How SentinelOne Uses OCSF Data

SentinelOne ingests OCSF data from AWS into our Singularity XDR data lake to assist with the investigation of cloud workload security alerts.

This enhanced perspective helps the security analyst more readily understand the root cause of security alerts related to their workloads within AWS, such as those running on Amazon Elastic Cloud Compute (Amazon EC2) instances, Amazon Elastic Container Service (Amazon ECS), and Amazon Elastic Kubernetes Service (Amazon EKS).

For example, by searching AWS CloudTrail logs associated with the EC2 instance that has a cryptomining alert associated with it, you can identify the user that created that instance, and assess if that user is compromised. This detail in turn informs remediation actions, whether manually initiated or automatically taken according to security policy. The customer controls which types of OCSF logs to ingest, choosing one, many, or all sources.

The OCSF logs available for ingestion from Amazon Security Lake to the Singularity XDR data lake are:

  • AWS CloudTrail management events
  • Amazon Virtual Private Cloud (Amazon VPC) Flow logs
  • Route 53 Resolver query logs
  • Amazon Secure Storage Service (Amazon S3) data events
  • AWS Lambda function execution activity
  • and security findings from 8 AWS services via AWS Security Hub.

More data does not mean more noise. In fact, SentinelOne is uniquely positioned to suppress noise and amplify security signals by virtue of our patented Storyline™ technology. Storyline automatically monitors thousands of concurrent OS-level process threads in cloud workloads, correlating and assembling a visualization of related events in an incident sequence.

Security data is automatically mapped to the MITRE ATT&CK framework tactics, techniques, and procedures (TTPs) so that an adversary’s movement across the organization’s hybrid cloud footprint is constantly observed. If any single incident consists of dozens of TTPs, Storyline assembles them all into a single alert. There are no alert storms or alert fatigue. Instead, just real-time forensic details, automatically distilled, are conveniently presented to the SOC to reduce time to investigation. And of course, configurable security policies can be set within the SentinelOne security console to automatically stop incidents in their tracks.

To get started with the integration, first connect with your SentinelOne account team and request access to the Skylight beta program. Then, go to the Singularity Marketplace to set up the integration.

To install the integration, simply set up a cross-account role for SentinelOne to access the account where your Amazon Security Lake logs are stored. SentinelOne then automatically brings those logs into the Singularity XDR Platform, and that’s it. No infrastructure is needed to deploy this integration. From there, Amazon Security Lake continuously notifies SentinelOne when there are new logs to ingest.

Closing Thoughts

Open standards for security data sharing is a game changer. Customer benefits include reduced dwell time, increased visibility and context, streamlined incident response (i.e., reduced MTTR), and better threat hunting. As with any change of this magnitude, early adopters will create their own differentiating use cases. At SentinelOne, we look forward to working alongside our customers to create ever-increasing value in security data mining.

If you would like to learn more about the Singularity XDR Platform and how we can help transform your security operations across cloud workloads, identity, and user endpoints, or would like to learn more about our beta program, please contact us.

SentinelOne Singularity XDR
Supercharge. Fortify. Automate. Extend protection with unfettered visibility, proven protection, and unparalleled response. Discover the power of autonomous with Singularity XDR.

Defending Cloud-Based Workloads: A Guide to Kubernetes Security

As more businesses move their applications to the cloud, in many cases they turn to Kubernetes (k8s) to manage them. In 2021, 96% of organizations surveyed by CNCF (Cloud Native Computing Foundation) were either using or evaluating Kubernetes. This open-source platform helps organizations orchestrate and automate the deployment of containerized applications and services.

While Kubernetes offers many benefits, it also presents new security challenges to overcome. In this post, we discuss how cybercriminals target Kubernetes environments and what organizations can do to protect their business.

Kubernetes Fundamentals

Kubernetes (hereafter, “k8s”) is an open-source container orchestration platform that was originally designed by Google and subsequently then transferred to the Cloud Native Computing Foundation (CNCF). It automates the deployment, scaling, and management of containerized workloads.

K8s has become a popular choice for DevOps as it provides a mechanism for reliable container image build, deployment, and rollback, ensuring consistency across deployment, testing, and product.

Source: Kubernetes

In many ways, containers are very similar to virtual machines; however, the biggest difference is that they are more relaxed in isolation properties, allowing sharing of the operating system across applications. Containers are lightweight (especially compared to VMs), have their own file system, and share CPU, memory, and process space.

Quick Environmental Facts About Kubernetes

The majority of K8s implementations are managed via Infrastructure-as-a-Service (IaaS) tooling, such as Amazon Elastic Kubernetes Service (EKS) or GCP’s Google Kubernetes Engine (GKE). By using these Kubernetes-as-a-service tools, teams can focus on building and deploying, while the Cloud Service Provider (CSP) curates and updates core aspects of the K8s services.

Kubernetes is deployed in a cluster, whereas the physical server or virtual machines which are part of the cluster are known as worker nodes. Each worker node operates a number of pods, which are a logical grouping of 1 or more containers running within each pod.

Applications are composed of microservices in a modern cloud-native architecture.

Microservices is an architecture design that allows building distributed applications that can break applications into independent and standalone deployable services. The best practice is to run one microservice per pod.

Orchestration is key to simplifying and automating workload infrastructure management, so there’s a control plane with many components such as schedules, detects, responds, controllers for nodes, cloud providers, and an API to query and manipulate the current state.


Several features are relevant for security professionals to be aware of:

  • DaemonSet – A manifest of pods to automatically deploy to all worker nodes within a cluster. As demand on the workload varies, a DaemonSet provides a means of auto-scaling infrastructure to meet that demand, with each worker given the appropriate pods and containers upon startup. This simplifies on-demand workload management. This is helpful for security and monitoring.
  • Namespace – A logical construct which allows isolation of resources within the cluster. A namespace separates users, apps, and resources into a specific scope.
  • SecurityContext – defines privileges and capabilities for individual pods and containers.
  • Helm Chart – A manifest of files which describes a related set of K8s resources and which simplifies deployment.

Threat Landscape for Kubernetes

With Kubernetes being still relatively complex to implement, it is often misconfigured and underprotected, which makes it a prime target for cybercriminals. Attacks often escape detection by traditional security tools and systems, and a compromise can allow a threat actor to take control of many containers and applications at once. Further, cloud workloads can provide cybercriminals with access to sensitive data and information that can then be used to launch attacks on other systems.

Real-World Kubernetes Attack Examples

CRI-O Container Runtime Allows Attackers Host Access

CRI-O is a container runtime for Kubernetes that allows users to run containers without a full operating system. A recent security flaw in CRI-O allowed attackers to gain host access to systems running the container runtime. The flaw has since been patched, and users are advised to update their CRI-O installations as soon as possible.

Kubernetes Flaw Exposes Cluster Data to Attackers

A flaw in the Kubernetes API server allowed attackers to gain access to sensitive data stored in etcd, the cluster’s key-value store. The flaw researchers at Red Hat discovered could be exploited to gain access to data such as passwords, API keys, and SSL certificates.

The researchers found that the flaw could be exploited by creating a malicious container sending requests to the Kubernetes API server. These requests would then be forwarded to the etcd database, allowing the attacker to access the sensitive data.

Cryptomining Attack Against Kubernetes Cluster in Microsoft Azure

Microsoft disclosed that Kubernetes clusters running on Microsoft Azure were targeted by cybercriminals for cryptomining. While by default, the Kubeflow dashboard is only accessible internally, some developers had modified the configuration of the Istio Service to Load-Balancer, which exposed the service to the internet. By exposing the service directly to the internet, anyone could directly access the Kubeflow dashboard and, with that, perform operations such as deploying new containers in the cluster.

Security Tooling Challenges

Traditional security tools and procedures often focus on what is running within the enterprise network. For some organizations, when procedures like those for incident response were built and implemented, containerization or, to some extent, cloud computing wasn’t even broadly available. With that in mind, there are several challenges regarding protection, detection, and response capabilities for Kubernetes.

By Default, k8s Are Not Optimized for Security

K8s offers a lot of advantages for DevOps to rapidly scale operations. However, many are not aware that, by default, K8s are not optimized to be secure. For example, organizations need to consider how they will secure the API server from malicious access or how they can protect etcd with TLS, Firewall, and Encryption. Also, things like audit logging are often disabled by default. Default configurations for K8s can result in cybercriminals being able to access K8 environments easily.

Lack of Visibility Into Running Processes and Potential Vulnerabilities

Simply put, organizations cannot protect what they cannot see. If security teams cannot see what is running inside the container, then they are also unable to protect, detect, or respond to cyber threats. Therefore, it is critical that as first step organizations gain as much visibility as possible on what’s running inside the Kubernetes environment.

Implementing the Principle of Least Privilege Is Challenging

In an environment as nuanced as K8s, implementing the principle of least privilege is a constant challenge. Default permissions and access rights in K8s, such as with service accounts, adds a significant risk for organizations as it increases their attack surface.

While there must be a balance between productivity and security it is important to understand the security implications. Due to lack of knowledge and configuration complexity, Role Based Access Control (RBAC) is often a common pain point for DevOps and SecOps teams which can quickly become an entry point for cybercriminals.

Legacy Security Tools Are Unable to Provide the Required Scalability

Legacy security tools that are often born on-premises and to some extent simply moved to the cloud end up having scaling issues in an attempt to secure cloud workloads. Unlike on-premises servers that often do not get scaled up or down with workload demand, in the cloud world this can very much so happen. Meaning while in the morning an organization might be operating a few dozen cloud workloads it could reach a few thousands by the end of day. As such, legacy security tools struggle to keep up with the scale of operations.

Lack of Contextual Insights Across Kubernetes Environments

Not all Cloud Workload Protection (CWP) solutions are equal. Some for example can provide real-time visibility and protection, others might be dependent on a Kernel-based agent, and yet others might be simply giving a container inventory as opposed to true detection and response capabilities.

Organizations are in need of a solution that can look at what is running inside the Kubernetes environment and also provide environmental information such as cluster name, service account, instance size, image details, and more.

Friction Between SecOps and DevOps as Both Teams Typically Operate in Isolation

DevOps and SecOps are typically siloed in separate organizations, with one focusing on enabling new business scenarios and the other on reducing cyber risks by optimizing for protection. This can sometimes cause friction between the teams. DevOps builds new services that can scale and are easy to use while often some of the required configuration can widen the attack surface, which is exactly what SecOps is charted to reduce.

To address this challenge, a DevSecOps collaboration framework can help as it adds security best practices into the software development and delivery lifecycle. By implementing DevSecOps, organizations can resolve the friction between DevOps and SecOps as they are now empowered to ship software in an agile fashion without compromising on security.

Kubernetes Security Best Practices

Kubernetes is a powerful tool that can help organizations manage their containerized workloads and services, but it also introduces new challenges for security teams.

Security teams can overcome these challenges using a proper mindset, best-in-class capabilities, and a low-friction approach. By following best practices, organizations can help ensure that their Kubernetes environment is secure and that they can quickly and effectively respond to any possible incidents.

There are a few key things that organizations should keep in mind when securing their Kubernetes environment.

  • Ensure visibility into all aspects of the environment – This includes understanding what is running inside containers, as well as being able to monitor and alert on activity both inside and outside the cluster.
  • Be able to quickly and easily respond to incidents when they occur – This means having a plan in place for responding to attacks, as well as the tools and procedures necessary to execute that plan.
  • Ensure that their security posture keeps up with the development speed – This means automating as much of the security process as possible and integrating security into the DevOps workflow.

To secure a Kubernetes environment, organizations should consider the following:

  • Monitor the Kubernetes cluster for unusual activity.
  • Restrict network access to the Kubernetes API server to authorized users only.
  • Enable auditing and logging for all actions taken on the Kubernetes cluster.
  • Configure RBAC to control access to resources in the Kubernetes cluster.
  • Deploy security tools, such as a Cloud Workload Protection Platform, in the Kubernetes cluster.

Kubernetes is a powerful tool that can help organizations manage their containerized workloads and services. However, it is important for security teams to understand the challenges that come with Kubernetes and to put the proper safeguards in place. By following best practices, such as those listed above, organizations can help ensure that their Kubernetes environment is secure.

How SentinelOne Can Help Reduce Risks of Kubernetes Attacks

The rise of containers and Kubernetes has been accompanied by an increase in the number of attacks targeting these technologies. To properly protect Kubernetes environments, organizations need a purpose-built security solution for these technologies.

SentinelOne’s platform is designed to provide visibility into and protection for containerized workloads and services. The platform’s architecture allows it to be deployed quickly and easily without requiring extensive changes to existing workflows or processes. Its intelligent, autonomous agents can adapt to changing conditions in real time, providing always-on protection against the latest threats. With SentinelOne, organizations can confidently deploy Kubernetes, knowing that their environment is protected against the latest threats.

With SentinelOne’s Singularity™ Cloud Workload Security solution, organizations benefit from the following:

  • One common security umbrella for cloud instances and on-prem endpoints
  • Runtime prevention, detection, and visibility for workloads running in public clouds and private data centers
  • XDR-powered threat hunting, investigations, and forensics across logs
  • One-click response and remediation
  • Deploy, manage, and update easily
  • Maximize uptime with a stable, no-interference design that leverages a highly performant eBPF agent that is deployed as a DaemonSet on a K8s node.
  • Get coverage for many supported operating systems and container platforms such as Amazon ECS, Amazon EKS, and GCP GKE.

The following short demonstration shows how Singularity Cloud’s extended visibility detects and defends against a Doki malware infection, just one example of how Singularity Cloud protects cloud workloads running in Kubernetes from runtime threats and active exploitation.

To learn more about how SentinelOne can help you secure your Kubernetes environment, contact us or request a demo today.

U.S. Govt. Apps Bundled Russian Code With Ties to Mobile Malware Developer

A recent scoop by Reuters revealed that mobile apps for the U.S. Army and the Centers for Disease Control and Prevention (CDC) were integrating software that sends visitor data to a Russian company called Pushwoosh, which claims to be based in the United States. But that story omitted an important historical detail about Pushwoosh: In 2013, one of its developers admitted to authoring the Pincer Trojan, malware designed to surreptitiously intercept and forward text messages from Android mobile devices.

Pushwoosh says it is a U.S. based company that provides code for software developers to profile smartphone app users based on their online activity, allowing them to send tailor-made notifications. But a recent investigation by Reuters raised questions about the company’s real location and truthfulness.

The Army told Reuters it removed an app containing Pushwoosh in March, citing “security concerns.” The Army app was used by soldiers at one of the nation’s main combat training bases.

Reuters said the CDC likewise recently removed Pushwoosh code from its app over security concerns, after reporters informed the agency Pushwoosh was not based in the Washington D.C. area — as the company had represented — but was instead operated from Novosibirsk, Russia.

Pushwoosh’s software also was found in apps for “a wide array of international companies, influential nonprofits and government agencies from global consumer goods company Unilever and the Union of European Football Associations (UEFA) to the politically powerful U.S. gun lobby, the National Rifle Association (NRA), and Britain’s Labour Party.”

The company’s founder Max Konev told Reuters Pushwoosh “has no connection with the Russian government of any kind” and that it stores its data in the United States and Germany.

But Reuters found that while Pushwoosh’s social media and U.S. regulatory filings present it as a U.S. company based variously in California, Maryland and Washington, D.C., the company’s employees are located in Novosibirsk, Russia.

Reuters also learned that the company’s address in California does not exist, and that two LinkedIn accounts for Pushwoosh employees in Washington, D.C. were fake.

“Pushwoosh never mentioned it was Russian-based in eight annual filings in the U.S. state of Delaware, where it is registered, an omission which could violate state law,” Reuters reported.

Pushwoosh admitted the LinkedIn profiles were fake, but said they were created by a marketing firm to drum up business for the company — not misrepresent its location.

Pushwoosh told Reuters it used addresses in the Washington, D.C. area to “receive business correspondence” during the coronavirus pandemic. A review of the Pushwoosh founder’s online presence via Constella Intelligence shows his Pushwoosh email address was tied to a phone number in Washington, D.C. that was also connected to email addresses and account profiles for over a dozen other Pushwoosh employees.

Pushwoosh was incorporated in Novosibirsk, Russia in 2016.


The dust-up over Pushwoosh came in part from data gathered by Zach Edwards, a security researcher who until recently worked for the Internet Safety Labs, a nonprofit organization that funds research into online threats.

Edwards said Pushwoosh began as Arello-Mobile, and for several years the two co-branded — appearing side by side at various technology expos. Around 2016, he said, the two companies both started using the Pushwoosh name.

A search on Pushwoosh’s code base shows that one of the company’s longtime developers is a 41-year-old from Novosibirsk named Yuri Shmakov. In 2013, KrebsOnSecurity interviewed Shmakov for the story, “Who Wrote the Pincer Android Trojan?” wherein Shmakov acknowledged writing the malware as a freelance project.

Shmakov told me that, based on the client’s specifications, he suspected it might ultimately be put to nefarious uses. Even so, he completed the job and signed his work by including his nickname in the app’s code.

“I was working on this app for some months, and I was hoping that it would be really helpful,” Shmakov wrote. “[The] idea of this app is that you can set it up as a spam filter…block some calls and SMS remotely, from a Web service. I hoped that this will be [some kind of] blacklist, with logging about blocked [messages/calls]. But of course, I understood that client [did] not really want this.”

Shmakov did not respond to requests for comment. His LinkedIn profile says he stopped working for Arello Mobile in 2016, and that he currently is employed full-time as the Android team leader at an online betting company.

In a blog post responding to the Reuters story, Pushwoosh said it is a privately held company incorporated under the state laws of Delaware, USA, and that Pushwoosh Inc. was never owned by any company registered in the Russian Federation.

“Pushwoosh Inc. used to outsource development parts of the product to the Russian company in Novosibirsk, mentioned in the article,” the company said. “However, in February 2022, Pushwoosh Inc. terminated the contract.”

However, Edwards noted that dozens of developer subdomains on Pushwoosh’s main domain still point to JSC Avantel, an Internet provider based in Novosibirsk, Russia.


Pushwoosh employees posing at a company laser tag event.

Edwards said the U.S. Army’s app had a custom Pushwoosh configuration that did not appear on any other customer implementation.

“It had an extremely custom setup that existed nowhere else,” Edwards said. “Originally, it was an in-app Web browser, where it integrated a Pushwoosh javascript so that any time a user clicked on links, data went out to Pushwoosh and they could push back whatever they wanted through the in-app browser.”

An Army Times article published the day after the Reuters story ran said at least 1,000 people downloaded the app, which “delivered updates for troops at the National Training Center on Fort Irwin, Calif., a critical waypoint for deploying units to test their battlefield prowess before heading overseas.”

In April 2022, roughly 4,500 Army personnel converged on the National Training Center for a war games exercise on how to use lessons learned from Russia’s war against Ukraine to prepare for future fights against a major adversary such as Russia or China.

Edwards said despite Pushwoosh’s many prevarications, the company’s software doesn’t appear to have done anything untoward to its customers or users.

“Nothing they did has been seen to be malicious,” he said. “Other than completely lying about where they are, where their data is being hosted, and where they have infrastructure.”

GOV 311

Edwards also found Pushwoosh’s technology embedded in nearly two dozen mobile apps that were sold to cities and towns across Illinois as a way to help citizens access general information about their local communities and officials.

The Illinois apps that bundled Pushwoosh’s technology were produced by a company called Government 311, which is owned by Bill McCarty, the current director of the Springfield Office of Budget and Management. A 2014 story in The State Journal-Register said Gov 311’s pricing was based on population, and that the app would cost around $2,500 per year for a city with approximately 25,000 people.

McCarty told KrebsOnSecurity that his company stopped using Pushwoosh “years ago,” and that it now relies on its own technology to provide push notifications through its 311 apps.

But Edwards found some of the 311 apps still try to phone home to Pushwoosh, such as the 311 app for Riverton, Ill.

“Riverton ceased being a client several years ago, which [is] probably why their app was never updated to change out Pushwoosh,” McCarty explained. “We are in the process of updating all client apps and a website refresh. As part of that, old unused apps like Riverton 311 will be deleted.”


Edwards said it’s far from clear how many other state and local government apps and Web sites rely on technology that sends user data to U.S. adversaries overseas. In July, Congress introduced an amended version of the Intelligence Authorization Act for 2023, which included a new section focusing on data drawn from online ad auctions that could be used to geolocate individuals or gain other information about them.

Business Insider reports that if this section makes it into the final version — which the Senate also has to pass — the Office for the Director of National Intelligence (ODNI) will have 60 days after the Act becomes law to produce a risk assessment. The assessment will look into “the counterintelligence risks of, and the exposure of intelligence community personnel to, tracking by foreign adversaries through advertising technology data,” the Act states.

Edwards says he’s hoping those changes pass, because what he found with Pushwoosh is likely just a drop in a bucket.

“I’m hoping that Congress acts on that,” he said. “If they were to put a requirement that there’s an annual audit of risks from foreign ad tech, that would at least force people to identify and document those connections.”

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

The Good

We give thanks this week to the good people at Interpol along with fraud investigators from 30 countries around the world for bringing us HAECHI-IIIa cybercrime busting operation that has resulted in almost 1000 arrests and seizure of approximately $130 million in virtual assets.

HAECHI-III is (as the name suggests) the third iteration of a coordinated law enforcement operation aimed at international cybercrime operations. Almost a year ago to date, we reported on HAECHI-II, which led to a similar number of arrests but only bagged around $27 million of illicit funds. The greater return this time round was a result of targeting voice phishing, romance scams, sextortion, investment fraud, and money laundering associated with illegal online gambling. The cops also leveraged financial experts to help them identify money mules and money laundering activities.

romance scams, sextortion, investment fraud

Among the 1600 or so cases closed thanks to the operation was one that involved call center scammers in Austria and India impersonating Interpol officers and duping victims out of over $150,000. Victims of a business email correspondence (BEC) scam in Ireland were also thankful for the return of €1.2 million as one of HAECHI-III’s many successes.

Aside from the arrests and asset seizures, authorities also seized or blocked 2800 bank and virtual-asset accounts linked to financial crimes during the 5-month operation, which ran from June to November 2022.

The Bad

This week’s bad news concerns users of Amazon, Paypal, Steam and Roblox in 111 countries who are being targeted with info-stealers by Russian-speaking cybercrime gangs.

A new report claims that almost 900,000 devices were infected and over 50 million account passwords stolen by the gangs in the first seven months of 2022. Mainly using info-stealers like Raccoon and Redline, the gangs use Telegram groups as a means to coordinate their criminal activities, including generating malicious content and aiding communication between members.

infostealer malware

Info-stealers target caches in browsers like Chrome, Firefox and Edge to steal saved account passwords, bank card details and crypto wallet information from infected machines. The stolen data is then sold on darknet markets or used directly by the cybercriminals themselves for account takeover or online fraud.

According to the researchers, the first seven months of 2022 saw around $6 million worth of data and bank card details stolen by 34 active Telegram groups. The Russian-speaking cybercriminals’ top targets were users in the United States, Brazil, India, and Germany. The most frequently stolen data was PayPal account credentials and Amazon account credentials. However, a five-fold increase in the theft of passwords for gaming services provided by Steam, Roblox and EpicGames was also reported.

Info-stealers typically require some social engineering of the victim – often in the form of downloading and running suspicious software including fake AV software, fake video player or other “software updates”, and free or cracked apps. A recent info-stealer campaign delivering RedLine used a fake version of popular GPU utility MSI Afterburner to infect victims.

Aside from being cautious and avoiding downloading software from unknown sources, users are advised to use password managers rather than storing credentials in browsers and to regularly clear browser cookies.

The Ugly

While we’re on the subject of info-stealers, users of Facebook business accounts have been the targets of a cybercrime campaign conducted through social media site LinkedIn and messaging software WhatsApp, it was reported this week.

A Vietnamese-linked operation dubbed ‘Ducktail’ is believed to be responsible for luring Facebook business account owners into downloading and launching malware capable of stealing credentials and allowing the attackers to hijack their accounts. Facebook business accounts have high privileges and access to the Business Manager panel can give an attacker control over settings, permissions and financial details, including credit card numbers.

facebook phishing

The report says that the threat actors behind Ducktail used these compromised accounts to run their own Facebook ad campaigns at the victim’s expense. It is thought that so far the operation has caused around $600,000 worth of losses to businesses.

Initially reported in June of this year, the info-stealing malware used in the operation was delivered to victims via lures on LinkedIn related to brands and products relevant to the victim. In the latest activity reported this week, victims have reportedly also been targeted through WhatsApp and Telegram.

Once the target accepts and launches the Ducktail malware, it steals stored session cookies and interacts with a number of Facebook API endpoints to collect access tokens, 2FA codes, IP addresses and geolocation data that allows the threat actors to impersonate the victim and log in from their own devices. Independent research from Zscaler also identified a phishing campaign last month aimed at the same targets.

Facebook account managers are encouraged to review the roles and permissions associated with their accounts and to follow the recommendations here.

Deploying Conditional Access for Frictionless Identity Protection

With the rapid change in modern technologies, workforces are increasingly mobile and require direct access to applications across hybrid IT environments. They often access both on-premises and cloud applications from various devices and locations, some of which could be using public or unencrypted networks. At the same time, security teams have realized that the directory service widely used to manage the required identity-related services, Active Directory, is vulnerable, and identifying its loopholes to protect it from various attacks is a considerable challenge.

How can organizations detect and block identity-related attacks before adversaries or malicious insiders establish complete Active Directory Domain Controller (DC) dominance? How can they most effectively protect critical assets against advanced identity-based attacks?

The best approach is conditional access, which enables administrators to allow or deny access to resources based on the detection of suspicious or malicious activity. In this post, we’ll discuss conditional access solutions, why they are important, and how they can strengthen the overall security posture of an organization.

The Growing Risk of Identity-related Breaches

Identity-related breaches remain the most significant threat of compromise, lost data, or malicious operations. According to the Identity Defined Security Alliance (IDSA) report, 84% of organizations experienced an identity-related breach in the past year, 2021. The most common attacks are phishing attacks (59%), inadequately managed privileges (36%), and stolen credentials (33%).

phishing attempts in 2021

Research conducted by Enterprise Management Associates also reported that 50% of organizations experienced an attack on Active Directory (AD), with more than 40% indicating the attack was successful.

Microsoft AD is the prime target for malicious operations. When attackers gain access to a compromised network, they attempt to discover domain identities and expand access to applications and data with stolen credentials. They can establish persistence, escalate privileges, and move laterally. Attackers attempt to take complete domain dominance through various means, such as OS Credential Dumping, stealing, or forging Kerberos tickets to perform a Pass-the-ticket Attack.

What Is Conditional Access and Why Is It Important?

Conditional access refers to the policy-driven concept of allowing access to corporate resources only when certain criteria are met. The solution is traditionally used in authentication systems to grant access to applications only if users go through Multi-Factor Authentication (MFA) while accessing a trusted resource from a new location or when attempting to access applications or data of a sensitive nature.

The same approach has been adopted for threat protection as well. Conditional access provides an extended layer of security by allowing secure access to on-premises and cloud applications only from trusted users or devices.

Conditional access is a mechanism to enforce access control policies based on suspicious or malicious activity. It is a risk-driven approach calculated based on risk factors such as severity and type of attack, among others.

Perimeter-based security is the traditional and obsolete solution for protecting external attackers from accessing the corporate network and applications. An identity security solution which offers conditional access capabilities allows security administrators to respond to the identified suspicious activities. It can help to quickly detect anomalous user or device behavior, restricting or allowing access to sensitive corporate resources. Conditional access enables administrators to set allow/deny conditions based on the severity of the threat detected.

Every organization can benefit from the following key features of conditional access solutions to improve their defense against threats and provide secure services to their users.

  • Frictionless Identity Protection – Allow seamless user access without causing friction by quickly identifying threats and isolating systems before exfiltrating the data.
  • Risk Driven Protection – Enforce access policy to Allow/Block using MFA based on the risk level of threats detected.
  • Reduced Attack Surface – Significantly reduce the attack surface available for malicious activity against both on-premises and cloud applications.

What Can SentinelOne Singularity Identity’s Conditional Access Offer?

The Singularity™ Identity solution offers deep packet inspection, identifies abnormal behavior, and detects suspicious activities. The solution detects attackers conducting reconnaissance of AD objects based on SAMR (Security Account Manager Remote), LSARPC (Local Security Authority Remote Procedure Call), and LDAP (Lightweight Directory Access) protocols.

An attacker with discovered AD objects can perform the following domain dominance attacks. The solution can detect these attacks in real-time and apply the conditional access protection policy configured for each type of attack.

identity-based attacks

SentinelOne’s Singularity™ Identity conditional access solution also offers an extra layer of security for users accessing cloud applications. The solution enforces risk-driven policies at third-party identity providers based on suspicious activities detected. It can trigger a push notification through MFA and only allow access if approved.

For example, a condition can allow the triggering of MFA for the attack severity of the “High and Above” type. It can allow users access only after meeting certain criteria; otherwise, it blocks the risky access attempt.

Singularity™ Identity’s conditional access capability helps improve an organization’s security posture by supporting Active Directory protection policies by offering the following response actions:

  • Alert Only – Only triggers an event with suspicious details; Domain Username, IP address, AD query, API calls, etc. It is a passthrough action where user access will be permitted to on-premises or cloud applications while generating critical telemetry describing the details of the transaction for analysis.
  • Allow using Multi-Factor Authentication (MFA) – Require Multi-Factor Authentication for the suspicious users detected based on threat severity.
  • Add user to the risky user group – Adds the suspicious user detected in the on-premises environment to the risky user group in a connected identity provider (IdP) platform. This will require suspicious users to always go through additional authentication factors before accessing cloud applications.
  • Block Always – Blocks access to on-premises applications for the suspicious users detected based on threat severity.

How Does Singularity Identity’s Conditional Access Protect Identities?

Attackers use discovery and reconnaissance techniques to find Active Directory objects, identify users, groups, and service accounts with elevated permissions, and perform privilege escalations. Using powerful techniques, attackers can gain unlimited access to any endpoint on the network or service, potentially damaging corporate data resources.

The Singularity Identity solution can prevent such attack techniques by leveraging conditional access requiring MFA. Only a legitimate privileged user who can successfully authenticate using MFA is allowed access. The organization must detect suspicious activities in real-time and only allow access to trusted connections. The deployed solutions must protect all on-premises applications relying on Active Directory and cloud applications integrated with the identity and MFA providers.

Conditional access offers key layers of security for both on-premises and cloud applications. Today, we’ll explore both types of conditional access.

Scenario #1: Conditional Access for On-Premises Applications

Attackers can use the AD data collected using various tools and access critical on-premises systems like Domain Controllers and application servers. If they can compromise AD by stealing credentials, moving laterally and elevating privileges, they can access any resource on the network.

An attacker can enumerate the Active Directory environment on a victim’s system using the standard built-in Windows utilities such as Net.exe, rundll32.exe, reg.exe, and wmic.exe to identify the user and group membership configuration of the system. Attackers can also use third-party open-source tools such as Adfind, Mimikatz, Cobalt Strike, Impacket, Rubeus and others, to advance their attacks.

The Singularity™ Identity solution detects these suspicious activities and blocks the user based on the threat severity. The solution can allow administrators to configure a protection policy that can trigger MFA for conditional access. The solution sends push notifications through Okta or Duo Security and allows access only after successful challenge/response.

Scenario #2: Conditional Access for Cloud Applications

In this scenario, attackers with compromised identities attempt to access cloud applications such as Salesforce, Office 365, or Google Apps and perform advanced attacks. Organizations can leverage Single Sign-On (SSO) mechanisms that enable users to access multiple applications with a single login and one set of identities. They can be set up to trust a third-party IdP, such as Okta, Microsoft 365/ Azure AD, Duo Security, and similar, to authenticate users.

The conditional access solution adds the suspicious user to the risky user group in IdP once an attack is detected for that user in the on-premises environment. Users will then need to go through MFA while accessing any cloud application, thus protecting those systems and the data contained therein.

Singularity™ Identity’s conditional access solution can be deployed in the existing infrastructure and ecosystem. Additionally, the solution provides Active Directory protection against attacks originating from all devices, including Windows and non-Windows platforms such as Linux, macOS, Internet of Things (IoT), and Virtual Private Networks (VPNs).

An attacker could also bypass MFA in their journey, as noticed in the recent Cisco data breach. Attackers bypassed MFA using various techniques, including voice phishing (aka “vishing”) and MFA fatigue. Singularity™ Identity solution helps to detect such bypassing attempts and alerts on multiple failed attempts to perform a privileged operation by the same user.


In today’s threat landscape, organizations implementing multi-factor authentication and conditional access for identities are well-positioned to detect and block attackers’ attempts to establish identity access and domain takeover.

On top of MFA, a comprehensive identity protection program can reduce the attack surface of the corporate AD infrastructure. Such an approach will allow remediation of vulnerable exposures, detection of malicious attempts at reconnaissance, and prevention of identity-based attacks from compromising critical systems and data.

For more information, please visit Singularity™ Identity.

Get a Demo of SentinelOne’s Identity Suite
Bringing Identity to XDR. Ready to experience the market’s leading identity security suite?

SentinelOne Named to Deloitte Fast 500 List for 4th Consecutive Year

SentinelOne was founded on the premise of changing cybersecurity defense as we know it – to help safeguard billions in global enterprise value from the risks and costs of cyber-attacks. It’s been an exciting ride, and today, we’ve hit another milestone. SentinelOne was named one of the fastest-growing companies in North America by Deloitte Technology Fast 500™ for the fourth consecutive year.

Our revenue has grown 814% from 2018 to 2021, a testament to our unparalleled customer traction, scaled go-to-market execution, and innovative XDR platform. We triumphed CrowdStrike’s #242 ranking with a 178% higher growth rate – which we attribute to our ability to provide unprecedented speed and infinite scale across endpoint cloud and identity. With SentinelOne, the future of cybersecurity is autonomous.

Our business momentum remains strong despite uncertain market conditions, reflecting strong demand for our transformative Singularity XDR platform. Over the past year, our total revenue increased 124% to $102.5 million, compared to $45.8 million in Q2 2022, and our Annualized Recurring Revenue (ARR) increased 122% to $438.6 million. We grew our total customer count about 60% to over 8,600 customers, with customers with ARR over $100K growing 117% to 755, signifying rapid adoption of our Singularity XDR platform across the globe.

Through Singularity XDR, we’re delivering what enterprises need the most: best-in-class protection and superior platform value. Singularity XDR provides a cohesive view of the entire enterprise network, enabling enterprises to do more than ever through automation, data analytics, and machine speed XDR. By covering essential attack surfaces across endpoint, cloud and identity, Singularity XDR empowers modern enterprises to take autonomous, real-time action with greater visibility of their dynamic attack surface and cross-platform security analytics.

Now in its 28th year, the Deloitte Technology Fast 500 provides a ranking of the fastest-growing technology, media, telecommunications, life sciences, fintech, and energy tech companies — both public and private — in North America. Winners are selected based on percentage fiscal year revenue growth from 2018 to 2021, and we are honored to be recognized for the fourth consecutive year.

To join the ranks of other customers who have extended protection from the endpoint to beyond with unfettered visibility, proven protection, and unparalleled response, visit to learn more.

SentinelOne Singularity XDR
Supercharge. Fortify. Automate. Extend protection with unfettered visibility, proven protection, and unparalleled response.

Building Blocks For Your XDR Journey, Part 3 | The Value of Securing Identity 

A Guest Post by Mark Harris, former Senior Director Analyst at Gartner

This is Part 3 of our multi-part XDR (eXtended Detection and Response) blog series, where we discuss the importance and value of securing identity. If you haven’t read it yet, we recommend checking out Part 1, which discusses why organizations need to extend protection beyond the endpoint to stay ahead of adversaries, and Part 2, which discusses why Endpoint Detection and Response (EDR) is a foundation and a cornerstone for any XDR strategy.

Identity, The Missing Piece

Malware authors and attackers continue to evolve the tactics, techniques, and procedures (TTPs) that they use. Vulnerabilities in applications and operating systems are regularly identified, and patching and maintaining systems to prevent those vulnerabilities from being exploited has been a constant challenge for organizations large and small. However, most attackers take a more familiar and less technical route to gain initial access: social engineering to access user credentials and data. Research suggests that nearly 50% of attacks are a result of stolen credentials. Once an attacker has control of a user’s identity, they have the same privileges and access as the real user.

Social engineering has been a key element of attacks for many years, whether it be through phishing emails, or clicking on links to exploit a vulnerability. Even the simple warnings seen in Office documents such as Microsoft Word that a document has active content (i.e. Macros) are often ignored and a user will simply enable them. Repeatedly asking users to make cybersecurity decisions will inevitably lead to user fatigue and failure.

Credentials are Gold to the Attacker

Credentials are the key to the user’s identity, the way systems identify and authenticate who a user is. This identity is based on an Active Directory (AD). AD effectively defines an organization structure: users are part of groups, groups have different rights and privileges to access systems and therefore data.

Multi-factor authentication (MFA) is a critical part of checking that the user is real and who they say they are. However, as with many security controls, a balance must be struck between authenticating a user too often and allowing them to get on with their work. Once authenticated, the user won’t be asked to re-authenticate again for some time.

That’s the upside, but the downside is that if malware is successfully installed on an endpoint, and the user has already authenticated, the malware will now have the same access rights as the user. Credentials also cross traditional boundaries and are used to manage cloud entitlements and directory systems that cover both human and machine identities.

MFA is a critical component of Identity Access Management (IAM), which controls access to the systems and services within an organization. Privilege Access Management (PAM) is a subset of IAM and controls not only the access but more fine-grained controls over what the user can do. Both focus on allowing access rather than preventing access, so again, if an attacker has taken control of a device, they are effectively authenticated in the same way as the “real” user.

Managing Identity Risk

Unfortunately, the risks associated with identity don’t stop there. Once you have the credentials for one user, it’s relatively straightforward to gain access to another user’s credentials. There are simple-to-use, free, open-source tools that can escalate privileges from one user to another. Mimikatz is the most widely known. All an attacker needs to do once they have compromised a regular user is download Mimikatz and steal the credentials of another user to gain higher privileged access. This can then be used to connect to another device and move laterally. Access to the active directory can be gained very quickly, and then the attacker can create their own set of credentials and have free reign over the entire organization.

Many malware groups include Mimikatz as part of the malware, or at least their version of it. When combined with scripting tools like PowerShell (e.g., Invoke-Mimikatz), these attacks can be carried out without any further files being written to disk.

Managing AD is notoriously difficult; credential permissions and configurations are constantly changing in most organizations as workers, applications and data morph and evolve. Adapting and responding to business needs means that maintaining security is a constant battle and often leads to protection gaps and accounts being overprivileged.

Gartner estimates that 50% of cloud security failures are due to poor management of identities, access and privileges. This figure is expected to rise to 75% by 2023.

Protecting against these sorts of complex attacks is the focus for Endpoint Detection and Response (EDR) solutions and increasingly Extended Detection and Response (XDR). By correlating and combining information from multiple endpoints, multiple security tools, the tell-tale signs of an attack can be identified. Even so, these solutions on the whole focus on the security of systems rather than users and their identities.

Identity Threat Detection and Response

A new category has recently begun to appear, Identity threat detection and response (ITDR). These solutions focus on detecting identity-based attacks, whilst identity-based attack surface management (ASM) focuses on restricting the ability for the attacker to easily move laterally by identifying misconfigurations and overprivileged accounts.

SentinelOne has introduced both an identity-based attack surface management capability with Ranger AD and ITDR with Singularity Identity.

Ranger AD analyses the active directory structure and identifies accounts that are misconfigured or over privileged. This makes it harder for the attacker to gain privileged access, at the very least making it harder for them.

Singularity Identity not only identifies identity-based attacks but works with Singularity Hologram to create network-based lures and deception to protect assets and trick attackers into revealing themselves. If an attacker gets access to one set of credentials, when they start trying to find another set of credentials to move laterally, they find some lures or “fake” credentials. As soon as they try to use them, their activity is uncovered.

Taking XDR to the Next Level

The identity-based detection and attack surface management tools are a valuable addition for the security teams. However, where it really comes into its own is when it’s combined with Singularity XDR. The attack surface of both devices and identities can be reduced, but more importantly, when an identity-based attack is identified it is both stopped, and the entire attack chain can be identified to allow changes to be made to prevent it from happening again. Identity is the missing piece of XDR and significantly increases the effectiveness of both detection and response.

The open XDR capabilities of Singularity mean that automated responses can be used to remediate compromised user credentials (forcing a reauthentication or change of password for example) and interact directly with identity-based management tools such as IAM and PAM.

Threat actors’ techniques continue to evolve. They have shifted away from targeting individual machines to targeting the entire organization, and that organization consists of users and identities. Identity attack surface management and detection play a pivotal role in cybersecurity. The addition of identity into Singularity XDR means there is finally the opportunity to protect the entire organization, not just the devices and infrastructure.

Parting Thoughts

As EDR evolves into XDR, the role of identity-based controls grows more important. With ITDR as one of the building blocks of a mature security strategy, organizations can more effectively secure their data and systems against sophisticated threats. By reducing the privileged access that users have to infrastructure, you can reduce the risk of data breaches and other security incidents. ITDR controls can help build a stronger defense against today’s threats and better protect an organization’s data and systems into the future.

If you would like to learn more about SentinelOne Singularity XDR platform, contact us for more information or request a free demo.

SentinelOne Singularity XDR
Supercharge. Fortify. Automate. Extend protection with unfettered visibility, proven protection, and unparalleled response. Discover the power of autonomous with Singularity XDR.

About the Author

Mark Harris is a Cybersecurity advisor and former Senior Director Analyst at Gartner with over 25 years of experience. At Gartner Harris was the author of a variety of market shaping research for Endpoint Protection and EDR including the EPP Magic Quadrant and Critical Capabilities as well as Market Guides and research on ransomware and other threats.

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

The Good

U.S. officials have finally arrested and charged long-wanted suspected cyber criminal Vyacheslav Penchukov, a Ukrainian national they allege acted as a ringleader of JabberZeus – one of the most notorious cybergangs on record.

According to the FBI, the JabberZeus gang has stolen upwards of $70 million in both the United States and across Europe in recent years. The crime group leveraged banking trojan Zeus malware and botnets to collect bank account numbers, PIN numbers, passwords, RSA SecureID tokens, and other personal information. After JabberZeus gained access to victims’ bank accounts and drained their funds, the money was then transferred out of the U.S. through a network of mule accounts. JabberZeus has been known to target small to medium-sized entities including businesses, municipalities, and churches.

This arrest comes as a result of U.S. law enforcement playing out the long game. Having been closely monitored by cybercrime analysts as early as 2009, Penchukov (aka “Tank”) was arrested by the Swiss Federal Office of Justice (FOJ) when he eventually travelled to Geneva last month. Penchukov’s extradition to the U.S. was approved this week.

Penchukov has been charged with conspiracy to participate in racketeering activity, bank fraud, conspiracy to commit computer fraud and identity theft, and aggravated identity theft together with eight other suspects. Another alleged member of JabberZeus, Maksim Yakubets (aka “Aqua”), currently has a $5 million bounty on his head offered by the FBI as reward for information leading to his arrest and conviction.

The Bad

This week, security researchers disclosed multiple vulnerabilities and bypass methods found in multi-cloud and application delivery firm F5’s BIG-IP and BIG-IQ devices. The flaws, if successfully leveraged, could compromise affected systems running a customized distribution of CentOS.

Researchers say the two vulnerabilities could be exploited to achieve remote access. CVE-2022-41622 (CVSS 8.8) is assigned to flaws in BIG-IP and BIG-IQ vulnerable to unauthenticated remote code execution via cross-site request forgery (CSRF). CVE-2022-41800 (CVSS 8.7) describes a bug in the appliance mode, iControl REST, which makes it vulnerable to authenticated remote code execution (RCE) via RPM spec injection.

Attackers exploiting the flaws could gain persistent root access to a device’s management interface though this would require an administrator to visit a malicious website while in an active session. F5 explained that the vulnerabilities cannot be exploited without an attacker having first moved past existing barriers using unknown mechanisms. Needing such specific criteria to exist, F5 notes that these methods would be very difficult to exploit, but could lead to complete compromise should it occur.

So far, the company is not aware of any incidents involving these vulnerabilities, though a detailed proof of concept has since been released. Impacted customers have been advised by F5 to request and install the hotfix specific to their product version.

The Ugly

Concerns over the prevalence of the Log4Shell RCE vulnerability continue nearly a year after its initial disclosure. CISA and the FBI reported this week than an unnamed Iranian-backed APT actor used Log4Shell to compromise a U.S. Federal Civilian Executive Branch (FCEB) organization over a period of months.

A CISA investigation found that as early as February 2022, the threat actor exploited the notorious vulnerability in an unpatched VMware Horizon server to install XMRig crypto mining software. Then, shifting laterally into the domain controller (DC), they compromised credentials and implanted Ngrok reverse proxies on several hosts to establish persistence in the FCEB agency’s network.

The joint advisory urged all organizations using VMware systems that were not immediately patched or mitigated with workarounds to assume breach and begin threat hunting efforts after patching against Log4Shell.

Log4Shell is a critical vulnerability allowing an attacker to run unauthorized code on an affected server, access parts of a network that is not connected to the internet, and move laterally across a network to access internal systems storing sensitive data. Scoring a 10 on NIST’s severity scale, Log4Shell is as critical as a vulnerability can get and it continues to be abused by various threat actors since it first made global headlines in December 2021.

Late last year, CISA had issued warnings that the vulnerability had the potential to affect an unprecedented number of devices. In June of this year, the Cyber Safety Review Board (CSRB) published a formal review of the December Log4j event remarking that the endemic flaw “remains deeply embedded in systems” and that “organizations should be prepared to address Log4j vulnerabilities for years to come”.

Researchers Quietly Cracked Zeppelin Ransomware Keys

Peter is an IT manager for a technology manufacturer that got hit with a Russian ransomware strain called “Zeppelin” in May 2020. He’d been on the job less than six months, and because of the way his predecessor architected things, the company’s data backups also were encrypted by Zeppelin. After two weeks of stalling their extortionists, Peter’s bosses were ready to capitulate and pay the ransom demand. Then came the unlikely call from an FBI agent. “Don’t pay,” the agent said. “We’ve found someone who can crack the encryption.”

Peter, who spoke candidly about the attack on condition of anonymity, said the FBI told him to contact a cybersecurity consulting firm in New Jersey called Unit 221B, and specifically its founder — Lance James. Zeppelin sprang onto the crimeware scene in December 2019, but it wasn’t long before James discovered multiple vulnerabilities in the malware’s encryption routines that allowed him to brute-force the decryption keys in a matter of hours, using nearly 100 cloud computer servers.

In an interview with KrebsOnSecurity, James said Unit 221B was wary of advertising its ability to crack Zeppelin ransomware keys because it didn’t want to tip its hand to Zeppelin’s creators, who were likely to modify their file encryption approach if they detected it was somehow being bypassed.

This is not an idle concern. There are multiple examples of ransomware groups doing just that after security researchers crowed about finding vulnerabilities in their ransomware code.

“The minute you announce you’ve got a decryptor for some ransomware, they change up the code,” James said.

But he said the Zeppelin group appears to have stopped spreading their ransomware code gradually over the past year, possibly because Unit 221B’s referrals from the FBI let them quietly help nearly two dozen victim organizations recover without paying their extortionists.

In a blog post published today to coincide with a Black Hat Dubai talk on their discoveries, James and co-author Joel Lathrop said they were motivated to crack Zeppelin after the ransomware gang started attacking nonprofit and charity organizations.

“What motivated us the most during the leadup to our action was the targeting of homeless shelters, nonprofits and charity organizations,” the two wrote. “These senseless acts of targeting those who are unable to respond are the motivation for this research, analysis, tools, and blog post. A general Unit 221B rule of thumb around our offices is: Don’t [REDACTED] with the homeless or sick! It will simply trigger our ADHD and we will get into that hyper-focus mode that is good if you’re a good guy, but not so great if you are an ***hole.”

The researchers said their break came when they understood that while Zeppelin used three different types of encryption keys to encrypt files, they could undo the whole scheme by factoring or computing just one of them: An ephemeral RSA-512 public key that is randomly generated on each machine it infects.

“If we can recover the RSA-512 Public Key from the registry, we can crack it and get the 256-bit AES Key that encrypts the files!” they wrote. “The challenge was that they delete the [public key] once the files are fully encrypted. Memory analysis gave us about a 5-minute window after files were encrypted to retrieve this public key.”

Unit 221B ultimately built a “Live CD” version of Linux that victims could run on infected systems to extract that RSA-512 key. From there, they would load the keys into a cluster of 800 CPUs donated by hosting giant Digital Ocean that would then start cracking them. The company also used that same donated infrastructure to help victims decrypt their data using the recovered keys.

A typical Zeppelin ransomware note.

Jon is another grateful Zeppelin ransomware victim who was aided by Unit 221B’s decryption efforts. Like Peter, Jon asked that his last name and that of his employer be omitted from the story, but he’s in charge of IT for a mid-sized managed service provider that got hit with Zeppelin in July 2020.

The attackers that savaged Jon’s company managed to phish credentials and a multi-factor authentication token for some tools the company used to support customers, and in short order they’d seized control over the servers and backups for a healthcare provider customer.

Jon said his company was reluctant to pay a ransom in part because it wasn’t clear from the hackers’ demands whether the ransom amount they demanded would provide a key to unlock all systems, and that it would do so safely.

“They want you to unlock your data with their software, but you can’t trust that,” Jon said. “You want to use your own software or someone else who’s trusted to do it.”

In August 2022, the FBI and the Cybersecurity & Infrastructure Security Agency (CISA) issued a joint warning on Zeppelin, saying the FBI had “observed instances where Zeppelin actors executed their malware multiple times within a victim’s network, resulting in the creation of different IDs or file extensions, for each instance of an attack; this results in the victim needing several unique decryption keys.”

The advisory says Zeppelin has attacked “a range of businesses and critical infrastructure organizations, including defense contractors, educational institutions, manufacturers, technology companies, and especially organizations in the healthcare and medical industries. Zeppelin actors have been known to request ransom payments in Bitcoin, with initial amounts ranging from several thousand dollars to over a million dollars.”

The FBI and CISA say the Zeppelin actors gain access to victim networks by exploiting weak Remote Desktop Protocol (RDP) credentials, exploiting SonicWall firewall vulnerabilities, and phishing campaigns. Prior to deploying Zeppelin ransomware, actors spend one to two weeks mapping or enumerating the victim network to identify data enclaves, including cloud storage and network backups, the alert notes.

Jon said he felt so lucky after connecting with James and hearing about their decryption work, that he toyed with the idea of buying a lottery ticket that day.

“This just doesn’t usually happen,” Jon said. “It’s 100 percent like winning the lottery.”

By the time Jon’s company got around to decrypting their data, they were forced by regulators to prove that no patient data had been exfiltrated from their systems. All told, it took his employer two months to fully recover from the attack.

“I definitely feel like I was ill-prepared for this attack,” Jon said. “One of the things I’ve learned from this is the importance of forming your core team and having those people who know what their roles and responsibilities are ahead of time. Also, trying to vet new vendors you’ve never met before and build trust relationships with them is very difficult to do when you have customers down hard now and they’re waiting on you to help them get back up.”

A more technical writeup on Unit 221B’s discoveries (cheekily titled “0XDEAD ZEPPELIN”) is available here.

Venus Ransomware | Zeoticus Spin-off Shows Sophistication Isn’t Necessary for Success

Venus ransomware has been launching data encryption attacks across the globe since at least August 2022. Last week, the Health Sector Cybersecurity Coordination Center issued an advisory stating that at least one healthcare entity in the United States had fallen victim to Venus ransomware, prompting wider warnings for healthcare and other organizations to be on their guard.

In this blog post, we provide further analysis, indicators of compromise, and TTPs associated with Venus ransomware to help organizations and security teams better understand and defend against this threat.


Venus ransomware, also known as Goodgame, has been attracting attention since August 2022 and related samples have been known since at least mid-2021. There are sufficient markers and other metadata present in Venus samples to suggest a genealogy with Zeoticus ransomware, which dates back to early 2020.

Venus ransomware is in the tradition of what now might be termed the “legacy ransomware” model: a file locker sold on underground markets as a standalone package rather than on a subscription or “ransomware-as-a-service” model. The package includes a compiled binary and access to decryptors. Unlike more modern data extortion schemes, there is no public data leak site or double extortion methods known to be associated with operators of Venus ransomware at this time.

Underground adverts offering Venus ransomware for sale began appearing in May 2022.

Venus ransomware forum advert

Translated, the message shown in the image above states “We are looking for pentesters”,  a common euphemism for ransomware in the wake of a crackdown on overt ransomware discussion in many forums after certain high profile attacks brought unwanted attention.

Aside from HC3’s warning last week of a healthcare organization being compromised by Venus ransomware operators, there is little indication that targets are industry or sector-specific. Initial access is reportedly publicly-exposed and vulnerable RDP (Remote Desktop Protocol) services, a common weakness found across many different types of organizations, regardless of industry or sector. Cybercriminals discover such vulnerable RDP services through tools like Shodan, direct scanning, COTS/Open-source tools, or by purchasing access from an Initial Access Broker.

Venus Ransomware | Technical Analysis

On launch, Venus ransomware samples will spawn a UAC (User Access Control) prompt in an attempt to elevate privileges before continuing execution.

Venus ransomware elevate privileges UAC dialog

Subsequently, the malware launches a child process with the following syntax:

file.exe g g g o n e123

In common with Zeoticus, the ransomware then uses the ping to achieve a delay before deleting its own first-stage binary and hiding the console window from victims.

/c ping localhost -n 3 > nul & del C:Users[user]Desktopfile.exe

Following this stage, a hardcoded list of processes is compared against what is running on the target and any applicable processes are shutdown via taskkill.exe.  A full list of processes targeted mirrors the hardcoded list found in Zeoticus samples.


Persistence is achieved by adding an entry for the ransomware payload in the registry (Windows run key).  For example:

Write Value HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun352.exe

Once encrypted, affected files will be appended with the .venus extension. Note that .TXT files are not always encrypted by Venus ransomware.

The malware also changes the icons of encrypted files with an image written to %Windir% in the early stages of execution. The user’s Desktop wallpaper is likewise replaced by a .jpg image written to %temp%. Both are given file names with a random 20-character string that conform to the regex d{20}, for example:

  • 16773516481972502376.jpg
  • 34004731821972527219.jpg
  • 28604229151972527219.jpg

Once all files have been processed, the malware uses registry modification to change the wallpaper.

REGISTRYUSER[USERIDENTIFIER]Control PanelDesktopWallpaper = "C:Users[user]AppDataLocalTemp\[20char string)].jpg"

Venus ransomware file encrypted

After the Desktop wallpaper is updated, the ransom note is displayed to the user.  The ransom note is an .HTA file similarly written to  %temp% with a 20-character string of digits for the file name.

Venus ransomware ransom note

During the course of execution, the malware attempts basic local discovery such as finding the machine name and OS. Venus ransomware traverses available network shares via NetShareEnum and wNetOpenEnum.

Some variants of Venus will utilize WMI to query or redirect additional system services and details. The following command is one launched by Venus ransomware:

wmi - start iwbemservices::execquery - rootcimv2 : select __path, processid, csname, caption, sessionid, threadcount, workingsetsize, kernelmodetime, usermodetime, parentprocessid from win32_process where ( caption = "msftesql.exe" or caption = "sqlagent.exe" or caption = "sqlbrowser.exe" or caption = "sqlservr.exe" or caption = "sqlwriter.exe" or caption = "oracle.exe" or caption = "ocssd.exe" or caption = "dbsnmp.exe" or caption = "synctime.exe" or caption = "mydesktopqos.exe" or caption = "agntsvc.exe" or caption = "isqlplussvc.exe" or caption = "xfssvccon.exe" or caption = "mydesktopservice.exe" or caption = "ocautoupds.exe" or caption = "agntsvc.exe" or caption = "agntsvc.exe" or caption = "agntsvc.exe" or caption = "encsvc.exe" or caption = "firefoxconfig.exe" or caption = "tbirdconfig.exe" or caption = "ocomm.exe" or caption = "mysqld.exe" or caption = "mysqld-nt.exe" or caption = "mysqld-opt.exe" or caption = "dbeng50.exe" or caption = "sqbcoreservice.exe" or caption = "excel.exe" or caption = "infopath.exe" or caption = "msaccess.exe" or caption = "mspub.exe" or caption = "onenote.exe" or caption = "outlook.exe" or caption = "powerpnt.exe" or caption = "sqlservr.exe" or caption = "thebat64.exe" or caption = "thunderbird.exe" or caption = "winword.exe" or caption = "wordpad.exe")

In addition, the following commands are commonly used across Venus variants in order to inhibit or disable system recovery and backup systems.

vdsldr.exe -Embedding
cmd.exe (wbadmin.exe) delete shadows /all /quiet && bcdedit.exe /set {current} nx AlwaysOff && wmic SHADOWCOPY DELETE
wbadmin.exe delete catalog -quiet
vssadmin.exe delete shadows /all /quiet
mshta.exe [name].hta) - "C:Users[user]AppDataLocalTemp16773516481972502376.hta" {xxxxxxxxx-F1C3-4B2E-88BF-xxxxxxxxxx}{1E460BD7-F1C3-4B2E-88BF-xxxxxxxxxx}
bcdedit.exe /set {current} nx AlwaysOff

Venus Ransomware’s Connection to Zeoticus

Like Zeoticus, Venus instructs users to reach out via email and TOX in order to engage with the ransomware operators and does not use C2 servers for data exfiltration or backdoors.

As noted above, there are certain code similarities between the way Zeoticus and Venus use the ping command.

Zeoticus ransomware
Zeoticus ransomware
Venus ransomware
Venus ransomware

Also note how the p r i v e t2 marker in Zeoticus is paralleled by the g g g o n e123 marker in Venus.

Command line syntax for persistence, task termination and various ‘housekeeping’ tasks between the two families is almost identical, and both malware families hardcode the same list of processes to target for termination.

Like Venus, Zeoticus is also offered as a complete standalone package rather than a RaaS and is not associated with a leaks site.

The ransom notes and Desktop backgrounds have similar stylistic overtones, and both malware variants write copies to mounted Recovery volumes.

Neither family is particularly sophisticated, and both use hardcoded strings within the malware with no attempt at obfuscation or anti-analysis.

SentinelOne Protects Against Venus Ransomware

SentinelOne Singularity™ fully detects and prevents payloads, behaviors, and artifacts associated with Venus and Zeoticus ransomware families.


Organizations are right to be concerned about the uptick in activity of this ransomware variant. Insofar as organizations leave vulnerable RDP services exposed to the public internet or fail to protect endpoints with a reliable Next-Gen security solution, attackers need not invest resources in sophisticated malware. Venus ransomware may not be specifically targeting healthcare organizations, but public service and critical infrastructure organizations may be symptomatic of those that most need to up their game to combat threats such as these.

Indicators of Compromise




S0106 – cmd.exe
T1005 – Data from Local System
T1012 – Query Registry
T1018 – Remote System Discovery
T1070.004 – Indicator Removal: File Deletion
T1082 – System Information Discovery
T1112 – Modify Registry
T1120 – Peripheral Device Discovery
T1202 – Indirect Command Execution
T1486 – Data Encrypted for Impact
T1490 – Inhibit System Recovery
T1491.001 – Defacement: Internal Defacement
T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
T1555.003 – Credentials from Password Stores: Credentials from Web Browsers
T1564.003 – Hide Artifacts: Hidden Window