Some time ago, I spent some time researching a core SolarWinds product, SolarWinds Platform (previously Orion Platform). At that time, I hadn’t been aware of the SolarWinds Access Right Manager product (Solar Winds ARM).

Afterward, Trend Micro’s Zero Day Initiative began receiving submissions of vulnerabilities in Access Rights Manager (ARM). The first submissions we received were from Sina Kheirkhah (@SinSinology), and one of those was a pre-auth RCE based on the .NET Remoting service. After his issues were patched, we received some additional, anonymous reports, in which pre-auth RCE was achieved via an unauthenticated gRPC/.NET Remoting based service on port 55555/tcp. An unauthenticated attacker was able to call its many methods, which were vulnerable mainly due to:

·       Exposing dangerous functionalities (command execution possibilities).
·       Path traversals.

I also had a quick look at this product. I have found 18 vulnerabilities in several iterations. My findings included:

·       Pre-auth RCE vulnerabilities.
·       Authentication bypasses chained with post-auth RCE vulnerabilities, which were based on insecure deserialization.
·       Pre-auth file deletion and file read vulnerabilities.
·       Local privilege escalation vulnerabilities.

I want to have my first ARM-related blog post focused on something unusual, thus this blog post is about pre-auth Arbitrary File Deletion vulnerabilities. You may say that File Deletions are not unusual, and you would be right. The ones we will describe here are very interesting though, because they may lead to local privilege escalation on domain-joined Windows machines. These vulnerabilities were addressed by the vendor with the ARM 2024.3 update.

ARM and Active Directory

Before we dig into the vulnerabilities, let’s have a look at the product itself. SolarWinds Access Rights Manager is used to “manage and audit access rights across your IT infrastructure”, as described by the vendor. It provides integration with multiple architectures and solutions, including Windows Active Directory.

When we think about a solution that can perform management tasks in the Active Directory, we know that this product probably operates using some AD account. When you configure this product, you need to provide valid credentials for the AD account with appropriate permissions to conduct management tasks. This is well documented by SolarWinds.

In general, the vendor recommends using a dedicated service account for the ARM operation, and this is a very good approach. However, it allows you to use a Domain Admin account for the product. To use some features, it may be even required to use such an account, depending on the AD configuration.

Nevertheless, every SolarWinds ARM installation will probably run on one of two categories of accounts:

·       A highly privileged service account, which may potentially have administrative rights on multiple domain-joined machines.
·       An account belonging to the Domain Admin group.

I’ve been working as a penetration tester for a while, and I’ve seen multiple solutions like ARM (AD management products) in the wild. Many were running on Domain Admin accounts. According to this, it is quite safe to assume that you will see some environments with ARM using Domain Admin for the AD-related operations.

Arbitrary File Deletion and Impersonation

During my research, I discovered the following vulnerabilities in SolarWinds ARM:

·       2x Pre-Auth Arbitrary File Read and Deletion.
·       4x Pre-Auth Arbitrary File Deletion.

Those vulnerabilities are quite simple. For no particular reason, let’s focus on CVE-2024-23474. The unauthenticated attacker can use the service listening on 55555/tcp to invoke the TracerActiveDirectoryWuselServiceImplementation.DataAvailablemethod:

At [1], the DoWork method is called and we fully control the input argument - TracerDataContainer object.

At [1], the deleteTransferFile method is called, with the container.TransferFileName member delivered as an input.

Before looking at this method, let’s have a quick look at the TracerDataContainer. It’s in fact an abstract class, which is extended by several different classes. We only care about the TransferFileName member here though, and its handling is implemented in the abstract class.

One can see that either if TransferFileName is set through the constructor ([1]) or through a setter ([2]), the attacker’s string is never verified. It means that we can reach the deleteTransferFile method with any string that we like.

At [1], the code will delete the attacker-specified file.

Thus, we have a pre-auth file deletion vulnerability. I haven’t mentioned one special thing about it though: The file deletion will be performed while impersonating the domain account specified in the SolarWinds ARM configuration. This impersonation is used for all the file deletion/read vulnerabilities I found in this product.

This means we can remove files remotely as a highly privileged domain account.

One Vulnerability to LPE Them All – Escalating Privileges on Any Domain Machine

You are probably aware of the File Deletion to LPE technique, which was discovered by Abdelhamid Naceri, and then upgraded by my colleague Simon Zuckerbraun. It allows you to escalate privileges by just abusing a privileged file deletion operation.

Let’s assume that SolarWinds ARM runs with a Domain Admin account. As already discussed, I believe that this is quite a common scenario.

We have an arbitrary file deletion vulnerability on steroids, because:

·       It is performed with the Domain Admin account.
·       We can execute it remotely, without any authentication.
·       Windows loves UNC paths. You can deliver a UNC path, which leads to a remote machine in a domain.

In such a scenario, we can abuse this vulnerability to locally escalate privileges on any Windows machine that is joined to our domain! A sample scenario looks like this:

·       The attacker gets low-privileged access to a Windows machine in the domain. Let’s call it “Machine A”.
·       He exploits the pre-auth file deletion in SolarWinds ARM (which is installed on “Machine B”), to remove files as an admin from “Machine A”.
·       The attacker abuses the File Deletion to LPE technique to escalate privileges on “Machine A”.

There’s one small wrinkle here though. To escalate privileges with the aforementioned technique, an administrator needs to perform a deletion action on the following path:

           C:\Config.Msi::$INDEX_ALLOCATION

One may think that we can perform this remotely by providing a following UNC path to the File.Delete method:

           \\target.zdi.local\c$\Config.Msi::$INDEX_ALLOCATION

This path won’t work though, due to some internal path processing, which is out-of-scope for this blog. However, one can use a different syntax to successfully perform this operation remotely:

           \\.\UNC\target.zdi.local\c$\ Config.Msi::$INDEX_ALLOCATION

In my PoC, I’m running the exploit as presented in the following screenshot.

After a while, we will reach the File.Delete method with the path provided to the exploit.

Finally, the file will be removed and we will get a SYSTEM shell afterward.

Demo

As usual, I have prepared a demo for you. It shows two screens. The left one presents a domain-joined machine, where the attacker has access to a low-privileged account. The right screen shows the SolarWinds ARM machine with the debugger attached. The emo shows the entire process of going from a remote file deletion exploitation to LPE.

SolarWinds ARM Running with Service Account Scenario

The previous scenario assumed that SolarWinds ARM runs with the Domain Admin account, a very probable scenario. On the other hand, it is safe to assume that some instances will run on a more restricted account. By saying “more restricted”, I mean an account that does not have a local admin privileges on all AD machines.

Still, there is a huge chance that this account may have administrative access to some machines in the domain. You can execute the following steps:

·       Use the File Deletion vulnerability to remove a file from the machine you control. In such a way, you can observe the NTLM authentication process. This allows you to discover the name of the SolarWinds ARM AD account.
·       Starting with the name of the user that ARM uses, you can perform your AD enumeration magic, to find out some more info about this user.
·       Then, you can look for potential targets and think about how you can use this vulnerability to your advantage.

Summary

In this blog post, I’ve shown you how an inconspicuous file deletion vulnerability may have an impact on the security of the entire Active Directory domain. Depending on the domain account used by SolarWinds ARM, it could even allow escalating privileges on any Windows domain-joined machine, even those on which SolarWinds ARM is not installed. SolarWinds has resolved these vulnerabilities related to ARM 2024.3. It is recommended that all users of SolarWinds ARM test and deploy this update as soon as possible.

You can follow me at @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

As long as we've had the internet, users have tried to obfuscate how and what they are connecting to. In some cases, this is to work around restrictions put in place by governments or a desire to access content that is not otherwise available in a given region.

This is why technologies like VPNs and The Onion Router (TOR) become popular: They allow users to easily access content without exposing their IP address or location. These technologies are intended to protect users and information and have done a good job of doing so. However, adversaries have taken notice and are using proxy networks for malicious activities.

Proxy Chain Services

It is important to distinguish the different proxy chain services, as there are legitimate reasons for some of them to exist. From a privacy/defender point-of-view, they can be split into the following groups:

• VPN and TOR: These services provide the user anonymity, but the defender can, for the most part, determine that it's receiving requests from these networks. As such, there is no expectation that the origin of the connection is the exact same as the user’s physical location. The user has no control of the path or exit node location. 
• Commercial residential services: These provide anonymity to users, while at the same time allowing them to choose the exit point. These services do not provide any clues to the defender about the nature of the connection. 
• Malicious proxy services: Threat actors use these networks to hide their location and choose their exit node. These are set up to be used by malicious operators from multiple sources. They can take two shapes: The nodes are installed on leased servers from different providers in different regions, or their nodes can be compromised edge devices that bounce connections in chains.

The first group has a clear legitimate use case, and the second has been advertised as a means to measure marketing engagement. However, threat actors can also use them without the bandwidth owner understanding what is at risk. The third case is clear: The networks are built to be rented for distributed denial-of-service (DDoS) attacks or access to be sold so other actors can anonymize their activities.

History

Leveraging proxy networks for malicious purposes was something we first stumbled on with our research into Honeygain. This was one of the first times we saw technologies like proxyware being abused maliciously. 

Proxyware is a type of technology that uses agents installed by users to act as proxies for other users. The users installing these agents are typically compensated for adding their node to the proxy network. Criminals stumbled upon this quickly and began to weaponize and monetize it, allowing them to benefit from the anonymity these technologies provide since it traces back to a random computer in a random location. At the time, the focus was purely criminal in nature, but state-sponsored groups have been leveraging TOR and VPNs for decades to launch their attacks, typically dropping out of a VPN near the target.

State-sponsored groups also realize that TOR and VPNs have limitations and could potentially expose their operations, so they needed something more opaque and less traceable. Enter VPNFilter.

VPNFilter was the first large-scale proxy network leveraged by state-sponsored actors, in this case Russia. This completely changed how proxy networks were operated and would set the tradecraft for state-sponsored proxy networks for the next several years. The most unique aspect of VPNFilter was the targeting: small office and home office (SOHO) routers. 

The network was made up of SOHO routers that were being compromised with malicious firmware providing a variety of capabilities, including interception and proxy capabilities. 

This was also a fairly significant botnet, consisting of some 500,000 devices that created a massive network from which to launch attacks without repercussions. Fortunately, we worked with affected vendors, and they resolved many of the issues that were being exploited, both vulnerability and otherwise. 

This wasn't the last time we saw Russian-aligned actors leveraging these types of botnets. A few years later, Cyclops Blink was uncovered. Another Russian actor controlled a proxy network that again primarily consisted of consumer devices. 

The targeting of consumer devices for this type of activity has become the focus of state-sponsored groups’ foray into this space. They also make excellent targets, since many users leave default configurations in place and rarely think to update their devices. Fortunately, post-VPNFilter, many vendors have switched to automatic updates, allowing for more frequent patching. This has resulted in state-sponsored groups widening their targeting. 

Today, we see not just SOHO routers, but also NAS and a variety of IoT devices being targeted and added to these networks. This problem has just gotten worse in the past several years.

State of the Art

As recently as September, the FBI took down a botnet associated with Chinese hacking activities. This was just the latest in a spate of attacks originating from proxy networks. This activity has been largely associated with Volt Typhoon by the U.S. Government, with a broader attribution of China-linked activities in the recent FBI takedown.

Currently, there are several proxy-based networks, with a focus on SOHO devices (e.g., routers, NAS, etc.) and a variety of IoT components (e.g., security cameras) being compromised and added to a botnet that, in some ways, mirrors Mirai botnet activities. 

The basic operating model for these botnets is that they are peer-to-peer, meaning there is no discernable routing. This model provides a sophisticated network of devices to obfuscate the true origin of an attack, and in many circumstances, allows the attacker to appear in close proximity to the victim, including coming from geographically adjacent residential networks. 

The attacks originating from these networks have been tied to espionage and the targeting of critical infrastructure in the U.S. and globally. Most countries are concerned with this escalation, and it has the attention of the majority of vendors in this space. 

These networks have also grown with staggering efficiency, with new nodes being added constantly as other nodes fall off and need to be compromised again. Based on reporting, the majority of these infections are using N-Day vulnerabilities or weak credentials to gain access, something we've seen repeatedly out of botnets like Mirai for the last decade. The major difference is that Mirai is used to conduct DDoS attacks, and the new iterations are being used to launch state-sponsored attacks with anonymity.

Network Resiliency Coalition

The repeated use of N-Day vulnerabilities and weak credentials ties into the work that Cisco has been doing for some time related to old and outdated networking equipment and the risks they introduce. The Network Resiliency Coalition is one of the projects aimed at trying to resolve this difficult problem. Anonymization networks' reliance on networking equipment, specifically exploiting known vulnerabilities, adds more weight to the importance of this effort. By working with industry peers, Cisco is trying to help remove many of the systems that are being abused in these attacks by working with vendors to ensure proper patching is provided to mitigate these known vulnerabilities, in a timely manner.  

More projects like this that encompass the IoT industry and the non-edge SOHO appliances like NAS devices would also have a contribution to the fight against anonymization networks. This combined with better credential management, most notably ensuring that default credentials are complex and unique, could make a huge impact on how successful these networks are in continuing to grow. Vendors are working to try and resolve some of these weaknesses, but it also is paramount for defenders to take note.

Impact on Defenders

This continued focus by state-sponsored groups to leverage these networks presents problems for defenders. Attacks from these groups are likely to be coming from residential networks, potentially even from residential networks in the same cities and countries as your organization operates, making identification and attribution increasingly difficult. 

Organizations need to realize that attacks can come from anywhere, even the same IP space that your employees connect to their VPNs, so plan accordingly. 

This is further complicated by the increased focus by state-sponsored groups on the use of legitimate credentials. If you have a connection coming from the same IP space as your employees, using legitimate credentials organizations have little hope to stop it. This is where the increased focus on identity comes into play — organizations need to start taking additional steps to be able to distinguish between the illegitimate and legitimate use of credentials, and that ties back to behavior. 

Increasingly, organizations should be looking at users’ behavior when it comes to connections.

• Are they using their typical device type? (e.g., Windows desktop/MacOS laptop)
• Are they logging on during their typical hours? (e.g., 9-5 M-F)
• Are there other managed devices in proximity?
• Are they using their managed device?

This last point is a critical one. For organizations particularly concerned with credential abuse, managed device access restriction may be the best option. 

This ensures that only managed devices can connect to corporate VPNs through technologies like certificates. 

The downside to this approach is that it's expensive, and for many organizations not practical, but for those with the budgets and the concern, it's a needed escalation beyond just multi-factor authentication (MFA). 

You may have noticed we haven’t mentioned MFA until now. But that’s because in 2024, it's assumed you've already rolled out MFA for medium to large enterprises. It is no longer an optional security feature. 

Defenders need to adjust for the state-sponsored threats they will be facing in 2024 and beyond. This means adding more identity capabilities in the near term and looking at additional security protections like managed device-only access in the future.