“INCONTROLLER” / “PIPEDREAM” ICS Toolkit Targeting Energy Sector

“INCONTROLLER” / “PIPEDREAM” ICS Toolkit Targeting Energy Sector

This advisory was written by Travis Holland and Eric Dodge of the Kudelski Security Threat Detection & Research Team


Incontroller/Pipedream is a collection of sophisticated tools thought to be created by group dubbed  “Chernovite” by Dragos. Chernovite is assessed to be a a state-sponsored adversary, with the intention for use in future operations. The primary focus for this toolkit is for use in the electric and natural gas verticals; however, it is not limited to solely those. At this time, the CFC has no intelligence that Pipedream has been successfully deployed in the wild at this time. This has provided researchers time to evaluate the tools proactively. This is a suite of utilities designed to allow for access to and manipulation of Schneider Electric and Omron PLCs, as well as Open Platform Communications (OPC) Unified Architecture OPC-UA servers. Dragos, an ICS focused cyber security company, has broken Incontroller/Pipedream into five categories:  Evilscholar, Badomen, Mousehole, Dusttunnel and Lazycargo.


  • Evilscholar: Provides the capabilities to discover, access and manipulate Schneider Electric PLCs.
  • Badomen: Provides the capability to scan, identify and access Omron software and PLCs.
  • Mousehole: The tool is designed around interacting and accessing OPC Unified Architecture (UA) servers which allow for enumerating nodeids and brute forcing credentials.
  • Dusttunnel: Remote operation implant to establish persistence and command and control.
  • Lazycargo: Interface that drops and exploits a known vulnerable ASRock driver to elevate credentials.


When properly used these tools allow for an attacked to scan for devices, brute force passwords, close connections, and even crash the targeted device. PLC implants are utilized to execute untrusted code from the PLCs, these implants could be on an impacted PLC for long durations, requiring firmware forensic analysis to reveal its presence.


The CFC has worked with its ICS-aware Network intrusion Detection System (IDS) partner, Claroty, who has written and published detection signature for PipeDream. All clients of the CFC’s MDR for O.T have had these signatures updated for their Claroty deployments.

Affected Systems

This impacts the following systems typically located in electrical substations and communicating through IEC-104 protocol:

  • Systems vulnerable to CVE-2020-15368; ASRock driver exploit
  • Schneider Electric MODICON and MODICON Nano PLCs, including (but may not be limited to):
    • TM251, TM241, M258, M238, LMC058, and LMC078
  • OMRON Sysmac NJ and NX PLCs, including (but may not be limited to):
    • NEX NX1P2, NX-SL3300, NX-ECC203, NJ501-1300, S8VK, and R88D-1SN10F-ECT
  • OPC Unified Architecture (OPC UA) Servers

Learn more about the increasing importance for OT cybersecurity in the Energy, Oil and Gas Industry by downloading the eBook.

Technical Details

Incontroller/Pipedream is a sophisticated and modular set of tools that an attacker can leverage once they have established access within an environment. The foothold is established by any vector available to the attacker and is followed up with utilization of the ASRock driver exploit (CVE-2020-15368) to further escalate their privileges, and to move through the environment. The ASRock exploit is rather trivial, and only requires administrative access to further escalate privileges and execute arbitrary code with kernel privileges.


The modular architecture and automation of the tool allows for easy addition of more components as needed (such the ASRock exploit) could easily be swapped in favor of another exploit or tool. Depending on the PLC type there are different actions and objectives that the threat actor would look to achieve.

Capabilities of the tooling per impacted vendor


Schneider Electric Devices:

  • Rapidly scan and identify all Schneider PLC’s on other network via UDP multicast over port 27127
  • Brute force Schneider PLC passwords via CODESYS over port 1740
  • Conduct denial-of-service attacks to prevent network communication to the PLC
  • Drop connections, forcing re-authentication to the PLC to gather credentials
  • Crash the PLC, for a power cycle and configuration recovery
  • Pushing custom Modbus commands/packets
  • Retrieving file/directory listings
  • Deleting files
  • Adding a route if the device gateway IP exists on a different interface
  • Connecting to specific devices


Omron devices:

  • Scanning for Omron via FINS protocol over port 9600
  • Parsing out HTTP response from Omron devices
  • Retrieving MAC addresses of devices
  • Polling for what devices are connected to the PLC
  • Backup and restoration of arbitrary files to or from the PLC
  • Loading custom agents on the PLCs to allow for additional capabilities
  • Wiping the device’s memory and resetting it
  • Activating the Telnet daemon
  • Connecting to the device via the Telnet daemon and uploading or executing payloads and commands
  • Perform a network capture
  • Killing processes on the device
  • Transferring files to the device
  • Connecting and communicating with attached servo drives


  • Identify OPC UA servers
  • Connect to OPC UA servers via default or compromised credentials
  • Reading/Writing tag values for data on OPC UA servers
  • Brute forcing credentials
  • Outputting log files

Currently Known Indicators of Compromise (IOCs)

  • sys (RWEverything)
  • sys (AsrPolychromeRGB)
  • sys (AsrPolychromeRGB)
  • exe


There is currently no evidence of Incontroller/PipeDream being deployed for disruptive or destructive effects. It is known to utilize standard ICS protocols and actions to live off the land natively. Proper monitoring of any suspicious use of the ASRock driver can help mitigate a portion of the toolset seen within Incontroller/PipeDream. It is important to note that utilization of the AsRock Driver exploit requires the attacker to already have administrator level privileges on the host, however, future exploits may have different requirements.


The Cyber Fusion Center recommends the following for mitigation, discovery, and recovery:

  • Appropriate network segmentation, and strong perimeter controls
  • Leverage Secure Remote Access with Multi Factor Authentication and monitored sessions
  • Jump Servers monitored with Endpoint Detection and Response (EDR) technologies
  • Active endpoint monitoring on HMIs, Engineering Workstations, and Historians
  • Strong password policies and management
  • Patch management
  • Only allow connection to ICS/SCADA infrastructure through certain engineer workstations
  • Disable the Schneider NetManage discovery service
  • Monitoring for new outbound connections from PLC’s

Additionally dedicated ICS monitoring can aid in quickly identifying things outside the baseline that could be indicative of movement and attacks within the ICS infrastructure. Examination of non-baseline activity, and restricting access to the following destination ports:

  • TCP 502; Modbus
  • UDP 27127; primarily used for discovery scanning
  • UDP 1740-1743, TCP 1105, and TCP 117470; CODESYS
  • TCP/UDP 9600; default communication port for Omron



What the Cyber Fusion Center is doing

While there are currently no known active deployments of this tooling, the Cyber Fusion Center’s O.T Intrusion Detection System (IDS) partner, Claroty, has developed and published network signatures designed to detect the potential presence of this tooling. All clients of the CFC’s MDR For O.T service have had these new detection signatures deployed on their behalf.


8 Tips for Choosing an MSSP

8 Tips for Choosing an MSSP

Using objective, evidence-based criteria to evaluate vendors is essential.

With hundreds of prospective providers and tons of marketing buzzwords to wade through, choosing the best managed security service providers (MSSPs) to effectively protect both your MSP business and your customers is no easy task. However, as C-suite leaders increasingly push back against security expenditures where there’s little or no proof that they mitigate real-world risks, finding objective, evidence-based criteria to evaluate vendors is essential.

To help navigate the complexities of the market—and better compare providers’ offerings—there are eight key considerations and tips to keep in mind when evaluating the best MSSPs for you and your clients.

1. Understand core objectives
The first issue to consider is the primary objectives for your security stack. Are your clients most concerned with achieving compliance or thwarting attackers? The unfortunate reality of the current threat landscape is that compliance and security are not equivalent concepts. Though most regulatory requirements were enacted in hopes of enhancing security, they’re static, and the audit process captures only a moment-in-time snapshot of your security posture. Meanwhile, attacker tactics and techniques are always changing, as is the technology environment. Simply put, if all your clients want is compliance, choose the cheapest solution for your stack.

If, however, a careful evaluation of your firm’s—and your customers’—business risks reveals that gaining security visibility and responding quickly to attacks is most valuable, look for the provider that can best achieve the objective of detecting and responding to attacks within these various environments.

2. Enhance visibility
An essential truth about today’s computing environments is that infrastructures are more diverse and distributed, systems are increasingly interconnected, and attack surfaces continue to expand. As a result, security visibility is harder than ever to maintain, yet without the correct security logs, data, and visibility, effective threat monitoring and detection is impossible.

Look for a provider that can eliminate blind spots where it matters most to achieve visibility by focusing on your detection objectives. These detection objectives should ideally be the outcome of a threat modeling exercise. Additionally, seek out a provider that offers visibility across multiple environments, including on-premises infrastructures, cloud resources, endpoints, industrial control systems (ICS) / operational technology (OT). You should validate the provider has experience monitoring environments like yours. They should also be able to leverage a formal framework or methodology (such as MITRE ATT&CK(link is external)) to ensure there are no major visibility gaps into attack techniques a lot of adversaries are likely leveraging.

Download our latest research “7 Key Things a Good RFP Should Cover — MSS and MDR” for more insight.

3. Negotiate contract scope and pricing
If a provider is a good fit in all ways but their cost, keep in mind that pricing is almost always negotiable. Don’t settle for a provider that can’t deliver the value and capabilities your MSP needs just because they’re more affordable.

One way to reduce the cost of a provider’s managed detection and response (MDR) services is to reduce the scope of engagement. For example, eliminating lower-level, tactical activities like identity and access management (IAM) services from a contract ensures you’ll get the best an MDR provider must offer: finding threat actors in your environment and responding on your behalf.

It’s also relatively easy to train someone in-house or hire a less-specialized provider to carry out commodity functions. In the current cybersecurity market, it’s more difficult to hire internal detection engineers and response playbook writers.

4. Partner with a single provider for mission-critical work
While removing less-than-essential functions from the scope of a provider’s responsibilities can be an effective cost-limiting measure, it shouldn’t be done in a way that limits visibility.

For example, if you have multiple security service providers with one vendor monitoring your environment, another monitoring your endpoint detection and response (EDR) tool, and another monitoring your security information and event management (SIEM) tool, visibility gaps are all but inevitable for all your providers.

In these “split brain” scenarios, none of your providers will be as effective as they could be. Cyberattacks involve multiple stages and tactics; to fully comprehend a sequence of events, security teams need to be able to understand what happened throughout your customer’s environment—endpoint, network traffic, Azure AD logs, etc.

5. Focus on outcomes
The way to achieve a better overall security posture is by doing the fundamentals consistently, not just relying on flashy new technology. Rather than looking for a provider that can support the trendiest toolsets, concentrate on outcomes. To make fact-based investments, you need to understand where your visibility and detection gaps are so that you can close them effectively.

Also, look for gaps in internal training, policies, and processes. An experienced provider can work closely as a partner and guide you toward greater security maturity by enhancing your fact-based understanding of strengths and weaknesses.

6. Replace legacy technologies if they don’t deliver on necessary outcomes
Although buying the latest and greatest security tools will not improve outcomes on their own, there are times when it makes sense to modernize your security stack. In some cases, you can’t achieve better outcomes just by leveraging technology that’s already in place.

Have an honest conversation with prospective MSSPs about which technologies they support and why.

There’s no way a high-quality MDR provider can be equally effective with every SIEM, EDR, or cloud security platform on the market today.

Technology sprawl affects all information security teams, including MDR providers and MSSPs. Learning each additional tool requires time, money, and training. Like everyone else, security providers must make tradeoffs about which technologies to prioritize. Any MDR provider who says they support every technology is either dishonest or ineffective.

7. Look for meaningful SLAs
Meaningless service-level agreements (SLAs) are all too common today. If your desired outcome is to be able to detect and respond to malicious activities quickly enough to prevent ransomware from spreading across your environment, does the number of “dedicated” resources assigned to your account matter?

I’ve seen organizations request SLAs such as “critical alerts must be triaged within five minutes, and low-criticality alerts within six hours.” How could your provider possibly validate that a new alert is critical without triaging it?

Sure, providers can look at the criticality of the technique detections are trying to find. However, waiting six hours to triage a low-severity detection could be detrimental. A small breadcrumb that triggers a low-severity alert can lead to the discovery of a seasoned and methodical threat actor.

Note that attackers also use MITRE ATT&CK to identify likely gaps in visibility or to build novel techniques not currently included in the knowledge base.

8. Engage key stakeholders
It’s important to manage your customer’s procurement process carefully. Decision makers often seek to achieve business objectives at the lowest cost possible and may not understand the nuanced differences between vendors or the desired security objectives.

Make sure all the key stakeholders thoroughly understand how well the provider can support outcomes that will meaningfully reduce business risk.

The original article was featured in Channel Pro Network.

CredManifest: Azure AD Information Disclosure Leading to Privilege Escalation & Free Tool Released

CredManifest: Azure AD Information Disclosure Leading to Privilege Escalation & Free Tool Released


On November 17th, 2021 Microsoft disclosed the existence of a high severity information disclosure vulnerability impacting Azure Active Directory (Azure AD) that could allow authenticated Azure AD user to escalate their privileges. Azure AD is Microsoft’s Identity and Access Management system used by Azure Cloud and Office 365. The vulnerability, dubbed “CredManifest” (CVE-2021-42306) existed because Azure incorrectly wrote private certificates data in cleartext in Application and Service Principal Manifests. These manifests can be read by any authenticated Azure AD user by default.

Successful exploitation of this vulnerability could have allowed an attacker with access to any account in target’s Azure AD environment to read private certificates from manifests. Attackers could then leverage those certificates to authenticate as the application with the “contributor” role, granting them full access to manage all Azure resources.

Microsoft has since mitigated the vulnerability by restricting access to the “keyCredentials” property in Application and Service Principal manifests as of October 30th, 2021. Restricting access to the property which contains the private certificate data ensures that attackers can no longer access the sensitive data. However, it’s possible that attackers have gathered these credentials prior to Microsoft becoming aware of the issue and thus may still have access to privileged credentials for impacted environments. The Cyber Fusion Center strongly recommends that organizations identify impacted Application registration and Service Principals and rotate those certificates as quickly as possible and investigate Azure AD audit logs for suspicious activity from associated accounts.

For additional details on how to identify impacted App registrations & Service Principals, please review the “solution” section of this advisory.

Affected Azure AD Services

Azure AD Service Impacted Scenarios
Azure AD Automation with “Run As” accounts enabled Any Azure AD automation accounts created with “Run As” accounts generated between 10/15/2020 – 10/15/2021 are impacted.


Automation accounts created with Managed Identities are not impacted.

Azure Migrate service Azure Migrate appliances registered prior to 11/02/2021 or registered with auto-update disabled are impacted.
Azure Site Recovery (ASR) Users who deployed the preview version of VMware to Azure DR with Azure Site Recovery before 11/01/2021 are impacted.
Azure AD Applications and Service Principals Please review the “solution” section of this advisory to identify impacted Azure AD Apps & Service Principals.


Microsoft has update Azure software to mitigate and resolve the issue, however certain Application and Service Principal credentials must be rotated to fully remediate the issue. Please follow the guidance listed in this advisory and Microsoft’s remediation guide to identify credentials that must be rotated.

CFC Releases Free Tool to check for impacted Applications & Accounts

The Cyber Fusion Center has also created a free tool to allow organizations to identify impacted Automation “Run-As” accounts, Application Registrations, and Service Principals. The tool allows Azure AD administrators to easily see impacted credentials that need to be rotated. The free tool is available at the following location:


Once an organizational administrator has granted read-only content to the tool, organizations will be able to see identify impacted Applications:

A listing of applications that are impacted and should have their credentials rotated

Manually Identifying Impacted Applications, Service Principals, and Run-As Accounts

Microsoft has enhanced manifests on impacted objects to return new properties that help identify impacted credentials that must be rotated. Organizations can identify impacted Azure AD Aps and Service Principals by looking a property of “hasExtendedValue” within the “keyCredentials” object being set to true.

Below is an example of an *impacted* credential (notice the hasExtendedValue property set to True):

    "@odata.context": "https://graph.microsoft.com/beta/$metadata#applications(keyCredentials)/$entity",
    "keyCredentials": [
            "customKeyIdentifier": "7A28B6653D0319E69D27E74580E7C91D765AF867",
            "endDateTime": "2021-05-21T03:35:32Z",
            "keyId": "772faab4-9b59-456e-b73e-baadbfa4b92d",
            "startDateTime": "2020-05-21T03:15:32Z",
            "type": "AsymmetricX509Cert",
            "usage": "Verify",
            "key": "MIIDKzCC……",
            "displayName": "CN=MyCert",
            "hasExtendedValue": True

Free Microsoft Scripts to identify impacted Applications, Service Principals, and Run-As Accounts.

Additionally, Microsoft has made several scripts and automation tooling available to identify and remediate impacted Azure AD App Registrations and Service Principals here:


What the Cyber Fusion Center is doing

The Cyber Fusion Center is actively working to develop tooling to help clients identify impacted App registrations and Service Principals. The CFC will engage directly with clients who subscribe to CFC services that required Azure AD App Registrations to support data and alert consumption (such as the CFC’s MDR For Endpoint with Microsoft Defender for Endpoint and MDR for Cloud with Azure / Office 365) to identify if they are impacted, and if necessary, rotate credentials.

The Cyber Fusion Center will engage with clients to directly coordinate the rotation of impacted certificates and credentials and ensure no impact to the delivery of your CFC services. Clients working to mitigate impacted Azure AD App registrations should coordinate with the CFC to ensure we can continue to receive critical data required to deliver your services.

Temporary Workarounds and Mitigations

Microsoft has proactively mitigated the issue by limiting access to private certificate data from manifests. This has prevented attackers from gaining access to private certificates since 10/30/2021. However, impacted credentials must still be rotated to ensure attackers who may have exploited this vulnerability prior to mitigation do not retain privileged access to Azure AD environments.

Organizations who identify impacted App registrations and Service Principals should review Azure AD audit logs for sign of abuse of these credentials as soon as possible.



OT: The Time for Remote Access Security is Now

OT: The Time for Remote Access Security is Now

Critical infrastructure systems are becoming increasingly connected to traditional IT systems, and as a result, are increasingly targeted.

Critical infrastructure systems are becoming increasingly connected to traditional IT systems, and as a result, are being increasingly targeted. A Siemens study found that 56 percent of the world’s gas, wind, water and solar utilities experienced at least one shutdown or operational data loss per year. The potential repercussions of a critical infrastructure breach within an industrial setting go far beyond financial loss or reputational damage.

Attacks in this space have already resulted in large-scale societal consequences. A cyber attack on Colonial Pipeline, the largest pipeline system for refined oil products in the U.S., caused the company to suspend operations and left the East Coast with a temporary gas shortage. In this case, Colonial Pipeline shut down its fuel pipeline operations pre-emptively even though its’ operational technology (OT) systems were not directly impacted. Sources claimed that the shutdown was due to the invoicing and billing systems being encrypted and unavailable, leaving the business with no way to properly track or invoice clients for fuel.

Colonial Pipeline’s hack is an important case study about how critically interdependent IT and OT systems are, even if they’re segregated technically and air gapped appropriately. This incident highlighted the imminent need for cybersecurity and risk management programs for an organization’s operational/industrial control system (ICS) environments, as well as security being at the forefront for all OT engineers and plant managers.

Remote access vulnerabilities

Within the past few years, the convergence of IT and OT systems has expedited the adoption of remote access technologies in critical infrastructure settings. More recently, the COVID-19 pandemic forced organizations to limit the number of people who were physically located within a plant or OT site. This drastically increased the number of ICS management and monitoring systems that are directly connected to the internet, potentially leaving them accessible to remote attackers.

These unprotected remote access systems or solutions essentially act as bait to threat actors wanting to compromise critical infrastructure systems. For example, a security researcher from the University of Tulsa revealed the ability for hackers to control entire networks of U.S. wind farm turbines. The researchers broke into a facility and installed a Raspberry-Pi-based computer through which they were able to access the systems remotely. This experiment shone a light on the simplicity of covertly installing unauthorized remote access systems that provide easy access to OT systems that were through to be fully air gapped from the internet, and the potential damage that can be done.

Understanding OT vulnerabilities to mitigate the risks

Despite these glaring vulnerabilities, there is a widespread lack of knowledge about asset protection across the manufacturing, energy, and oil and gas industries. Many OT operators and engineers, unfortunately, are not yet aware of the severity of the potential risks that insecure remote access points can bring. There is a significant disconnect between risk perception and actively implementing processes and procedures to mitigate those risks, with little incentive to replace or improve equipment that still functions but does not meet security requirements. Industry professionals must be educated on the risks of vulnerable remote access points.

The reality of OT systems is that plants and manufacturing sites are often designed and built to last and to remain “stable” for decades to come. This means that there are often no plans to keep software updated by installing security patches, changing configurations to make the systems more secure, or reducing risk by turning off unnecessary features on Programmable Logic Controllers (PLCs). Consequently, the most common risks in critical infrastructure OT systems include the following: outdated operating systems, unencrypted passwords used to connect to systems over unsecured networks, remotely accessible devices, lack of passive network monitoring, weak access control systems, and the failure to keep antivirus signatures updated to track new malware strains.

It’s not uncommon for security providers to deploy passive network monitoring systems in OT environments and immediately see years old malware running rampant (such as slammer or conflicker) with the OT engineers being none the wiser. The attacks against these systems typically don’t require sophisticated zero-day vulnerabilities in the software used on engineering workstations or in PLCs but instead rely on abusing poor security hygiene and differing priorities.

Preventing future hacks

Poor cyber hygiene remains the top challenge in securing these systems. Thankfully, some steps can be taken to reduce risk. One key priority is to focus on protecting IT / OT network boundaries. More specifically, focus on remote access systems and software that may allow direct access to critical OT networks to enable engineers to monitor systems remotely.

Perhaps most importantly, proper education and increased awareness remains the most effective way to prevent incidents. If detection and risk mitigation is to be a priority, education must come first. Site managers and OT engineers must be aware of these risks and work closely and collaboratively with corporate information security teams to appropriately defend these environments in a non-disruptive way.

One of the simplest ways to deploy risk mitigation measures is deploying an approved set of remote access tools designed specifically for OT environments and ensuring these systems are appropriately configured to record a user’s activity and limit their access based on least privilege.

Implementing security practices and procedures is not a choice for most business-critical OT systems. Security must be at the forefront of all new critical infrastructure systems to protect against a growing number of vulnerabilities due to the convergence of IT and OT systems and the increasing number of access points. Companies must mitigate the risk of OT breaches and ensure their risk management and information security programs also help protect these environments.

This article was originally featured in Industry Today.

Security Advisory: Kaseya VSA Supply Chain Compromise Used to Execute REvil Ransomware

Security Advisory: Kaseya VSA Supply Chain Compromise Used to Execute REvil Ransomware


On July 2nd, a large-scale supply chain attack operation by the REvil ransomware group affected multiple I.T Managed Service Providers (MSPs) and leveraged the I.T MSP’s Kaseya VSA instances to infect the MSP’s clients. As of this writing the attack campaign has affected 60 I.T MSPs and over 1500 end clients.

The attack was operated by compromising self-hosted Kayseya VSA servers. The threat actors appear to have gained access by abusing authentication bypass and command injection bugs present on the management web UI. Once threat actors gained access to the VSA servers, they quickly locked legitimate users out of the systems and delivered a malicious payload to end user systems the compromised I.T management tool.

The Kudelski Security Cyber Fusion Center and Kudelski Group were not affected as this solution is not leveraged internally nor externally.

Affected Systems

All self-hosted VSA servers. Unfortunately, there is currently no\ patch available, as such it is strongly recommended to keep the servers shutdown.


Once threat actors used their initial access to VSA servers they locked out administrators and leveraged VSA’s update mechanism to deploy their malware as a base64 encoded “.crt” file. The threat actors then used a powershell command to disable Windows Defender Antivirus, decode the file and save it in the c:\kworking directory of the Kaseya VSA software (which was typically excluded from AV scanning as recommended by Kaseya). Finally, the agent.exe malware dropper is started by the Kaseya agentmon.exe binary, gaining system level privileges.

The malware dropper extracted from the encoded agent.crt file was digitally signed with a valid digital signature using the following information:

• Email: [Brouilettebusiness@outlook[.]com]
• SUBJECT: CN=Sectigo RSA Code Signing, CAO=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB
• Serial #: 119acead668bad57a48b4f42f294f8f0
• Issuer: https://sectigo[.]com/

Once executed, the dropper writes the following files to the c:\Windows path:

• MsMpEng.exe – a legitimate but very outdated Windows Defender executable
• Mpsvc.dll – the encryptor payload complied as a dynamic link library that is sideloaded by the vulnerable Defender executable

Known associated IOCs (SHA256):

• agent.exe (d55f983c994caa160ec63a59f6b4250fe67fb3e8c43a388aec60a4a6978e9f1e)
• mpsvc.dll (e2a24ab94f865caeacdf2c3ad015f31f23008ac6db8312c2cbfb32e4a5466ea2)
• mpsvc.dll (8dd620d9aeb35960bb766458c8890ede987c33d239cf730f93fe49d90ae759dd)

The threat actors appear to have performed initial exploitation activity from the following IP addresses:

• 18.223.199[.]234 (Amazon Web Services)
• 161.35.239[.]148 (Digital Ocean)
• 35.226.94[.]113 (Google Cloud)
• 162.253.124[.]162 (Sapioterra)

CFC Monitoring

Cyber Fusion Center has been actively monitoring this attack campaign and continues to track the situation to keep our clients updated. The CFC will perform threat hunting on the IOCs listed in this advisory and any updated IOCs released in the future.

Additionally, the techniques leveraged by the threat actors in this attack campaign are not unique or novel, several threat actors have leveraged PowerShell cmdlets to disable security solutions in the past and often use the Certutil binary to decode or download malicious files. The CFC is able to actively monitor and response to these techniques leveraging Endpoint Detection and Response (EDR) tooling.


Kaseya’s R&D team was able to replicate the attack vector and is working on the process of remediating the malicious code and applying necessary patches.

Temporary Mitigations

All Kaseya hosted VSA servers as part of Kaseya’s SaaS solution were put into maintenance mode by Kaseya to prevent further exploitation.

Self-hosted VSA servers should remain shutdown until Kaseya provides a patch for the issue.