Reading view

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

Metrics That Matter: An Attacker’s Perspective on Assessing Password Policy

After compromising a Windows domain controller, one of the actions that NodeZero, our autonomous pentest product, performs is dumping all domain user password hashes from the Active Directory database. This is a common attacker technique, and the resulting dump is highly valuable to attackers. But did you know that this data is a great source of insight for defenders too?

In this post we’ll talk about different metrics NodeZero gathers from analyzing password hashes in the Active Directory database. You’ll see how these metrics can be used to gauge how susceptible your organization is to common attacks that take advantage of weak passwords: password cracking, password spray, and credential re-use. These metrics can then be used as a lever to adjust password policy, improving the long-term cyber resilience of your organization.

Credential Analytics

Password Cracking Metrics

After dumping password hashes from a domain controller, NodeZero attempts to crack them all. This cracking is done without the need to set up dedicated hardware (i.e. GPUs). NodeZero uses a regularly updated wordlist containing billions of potential passwords, including all publicly disclosed breached passwords. NodeZero also tries to crack hashes based on contextual terms such as a company’s name and domain names.

If NodeZero is able to crack any hashes for active users, NodeZero will surface a weakness entitled Weak or Default Credentials - Cracked Credentials from Active Directory Services Database (NTDS).

The proof for this weakness will contain a summary report with metrics covering:

  • Number and percentage of users whose password hashes were cracked

  • Number of cracked accounts broken down by user status (enabled or disabled)

  • Number of cracked accounts broken down by cracking method (empty password, based on username, known breached password, or using a contextual term).

  • Number of cracked accounts broken down by password length

  • Number of cracked accounts with passwords appearing in the list of the top 100, top 1000, and top 10000 worst known passwords

Also included in the proof is the list of active accounts whose passwords were cracked and the methods used to crack them.

Password Similarity Metrics

In addition to hash cracking, NodeZero analyzes the data dump for password reuse: cases where different users are using the exact same or similar passwords. If at least two active users are found to be using the exact same or similar password, NodeZero surfaces a weakness entitled Password Reuse Found in Active Directory Services Database (NTDS).

Password reuse analysis can be done even if no passwords are cracked. Password hashes are dumped from the Active Directory database in NTLM format, which are unsalted MD4 hashes of the passwords. This means that two accounts with the same NTLM hash are using the same password.

If NodeZero is able to crack any password hashes, it goes one step further in its analysis. It compares cleartext passwords with each other to see how similar they are based on the normalized edit distance metric. If two cleartext passwords are at least 70% similar, then NodeZero presumes that an attacker would be able to guess one password from the other.

For instance, suppose we’re comparing two cleartext passwords: Horizon3 and Horizon1!. The edit distance between these two passwords is 2, because 2 modifications are required to turn the first password into the second.

  1. Horizon3 → Horizon1 (replace 1 with 3)

  2. Horizon1 → Horizon1! (add !)

Based on this, NodeZero determines that these two passwords are ~78% similar – close enough for an attacker to easily guess.

Using this type of analysis, NodeZero surfaces the following metrics in the proof for the Password Reuse weakness.

  • Number and percentage of active users using a password similar to another user

  • Worst case and average age password reuse “blast radius

    • This is a novel metric NodeZero surfaces to indicate the number of additional accounts that can be compromised if a single account is compromised. NodeZero assumes an attacker can simply take a compromised password or simple variation of it and attempt it against other accounts.

The top reused passwords are also provided in the proof.

Using Metrics to Gauge Attack Defense Readiness

Now let’s talk about how the metrics above can be used to assess an organization’s susceptibility to different types of attacks.

Defending Against Password Spray Attacks

In a password spray attack, an attacker starts with a list of users and a shortlist of probable weak passwords. The attacker tries (i.e. “sprays”) each password, one at a time, against all users in an attempt to compromise at least one account. Attackers are just trying to take over any account because they know that, once they’ve compromised a single account, they can abuse that account’s access to go further into the network. Password spray attacks are carried out both for initial access and lateral movement.

To avoid account lockouts, attackers usually perform password sprays over long periods of time, limiting the rate of login attempts. Suppose an attacker has a shortlist of 10000 passwords and is spraying at a rate of 4 attempts per hour. It would take the attacker more than a 100 days to complete the spray. This means, to defend against password spray attacks, it’s most important to eliminate any easily guessable passwords that would make an attacker’s shortlist to spray. Even if a password hash is cracked, it doesn’t mean it’s easily guessable – it could be entry number 100,000,000 in a breached password list, and an attacker won’t realistically have the time to attempt that password.

So the metrics that matter most for guarding against password spray attacks are:

  • # Accounts cracked with passwords that appear in the list of top 10000 known worst passwords

  • # Accounts cracked with passwords that are derived from a user’s username

  • # Accounts cracked with passwords derived from a contextual term such as a company name

  • # Enabled accounts with empty passwords

Weak passwords in all of the above categories are ones attackers can easily come up with to generate a shortlist for spraying.

Defending Against Password Cracking Attacks

In a password cracking attack, an attacker has a password hash in hand and seeks to crack it to recover the cleartext. An attacker typically acquires hashes after initial access through attacks such as OS credential dumping, Kerberoasting, or LLMNR/NBT-NS Poisoning.

It is generally hard to defend against password cracking because motivated attackers may have significant cracking hardware at their disposal. Cracking hardware has matured to the point now that an NTLM hash for any password 8 characters or less can be cracked within a few hours or less. There are even publicly available rainbow tables for all NTLM hashed passwords of 9 characters.

If NodeZero was able to crack any hashes at all, you can expect an attacker will also be able to crack them. It’s not unusual for NodeZero to crack more than 50% of an organization’s credentials.

The single best defense against password cracking attacks is to require long passwords. We recommend passwords at least 12 characters in length. This is more than NIST’s guidance of an 8 character minimum.

The metrics that matter most for defending against password cracking attacks are:

  • # Accounts cracked (total amount)

  • # Accounts cracked with password length < 12 characters

Defending Against Credential Reuse Attacks

In a credential reuse attack, an attacker starts with a compromised account and tries to take over other accounts by trying to login with the same password, or a similar password. This is typically carried out as part of lateral movement.

Organizations routinely have a common password or base term that is shared across many accounts. For instance, this base term could be derived from the password new users get when they first join an organization, or a temporary password used as part of a password reset, or a password used for test accounts.

If an attacker is able to compromise a single account using one of these common passwords, you can assume that all other accounts that share that password can also be easily compromised. An attacker may be able to significantly escalate his or her privileges depending on the level of access those additional accounts have.

The Password Reuse Blast Radius metric tracks the number of additional accounts that can be taken over if a single account is compromised. Below are the trackable metrics most useful to defend against the credential re-use attack technique.

  • Worst case password reuse blast radius

  • Average password reuse blast radius

It’s not uncommon for NodeZero to find hundreds of accounts sharing the exact same password or passwords derived from a single base term. Ideally all accounts should be using a unique and dissimilar password.

A Plan For Continuous Assessment and Improvement

The Metrics That Matter

The following chart summarizes the metrics gathered by NodeZero and how they can be used to assess your organization’s posture against different types of attacks.

Attack Type

MITRE Tactic Alignment


Password Spray

Initial Access
Lateral Movement
Credential Access

# Accounts cracked with passwords that appear in the list of top 10000 known worst passwords

# Accounts cracked with passwords that are derived from a user’s username

# Accounts cracked with passwords derived from a contextual term such as a company name

# Active accounts with empty passwords

Password Cracking

Lateral Movement
Credential Access

# Accounts cracked (total amount)

# Accounts cracked with password length < 12 characters

Credential Reuse

Lateral Movement
Credential Access

Worst case password reuse blast radius

Average password reuse blast radius


Horizon3’s Password Policy Recommendations

Based on the above, Horizon3 recommends the following organizational password policy. Our guidance extends and hardens the latest recommendations from NIST Special Publication 800-63B.

  1. All passwords must be 12 characters or longer
  2. No passwords matching the list of known breached passwords
  3. No passwords derived from dictionary terms
  4. No passwords derived from well-known contextual terms such as the company name, product, etc
  5. No passwords derived from well known information about the user such as the username, first name, or last name
  6. All passwords should be unique, and no passwords should be “too similar” to each other
There are a variety of tools to set and enforce password policy. For instance, if you’re using Azure AD, you can enable Azure AD Password Protection to automatically ban well-known bad passwords.

We recommend a program of continuously running NodeZero to verify your posture and adherence to password policy. NodeZero automatically surfaces the metrics in this post whenever it acquires domain admin rights, or if it’s set up to run with a domain admin credential. Check out the free trial here to learn more!

The post Metrics That Matter: An Attacker’s Perspective on Assessing Password Policy appeared first on

FBI Targeted by Russian Hackers in Latest String of Attacks Against U.S. Government Websites

ClearanceJobs: 11/18/22

“With the rise in successful cyber attacks against the United States government and its federal agencies, many are right to wonder whether the public sector’s approach to cybersecurity is in need of a serious change.”

Read the entire article here

The post FBI Targeted by Russian Hackers in Latest String of Attacks Against U.S. Government Websites appeared first on

Cloud security isn’t guaranteed because a provider is well-known, expert says

SC Media: 11/14/22

Brad Hong, customer success manager at Horizon3ai, said he and his team constantly see huge blast radii in attacks and penetration tests originate from the smallest misconfiguration, or even lack of configuration, allowing attacker’s to simply log-in to public facing environments.

Read the entire article here

The post Cloud security isn’t guaranteed because a provider is well-known, expert says appeared first on

Russian Software Found in Smartphone App Used by CDC and U.S. Army

ClearanceJobs: 11/14/22

“After being branded as an American company, the revelation of Pushwoosh being a Russian-originated software firm comes as yet another embarrassment to Apple and Google in the privacy domain,” explained Taylor Ellis, customer threat analyst at Horizon3ai.

Read the entire article here

The post Russian Software Found in Smartphone App Used by CDC and U.S. Army appeared first on

Holiday Season Threat Awareness

As we approach the holiday season, it is important that our customers stay vigilant and continue a regular cadence of autonomous pentests. Although it’s the time of year for holiday cheer, we’ve seen cyber threat actors (CTAs) take advantage of lackadaisical company manning and low staff.

In September 2020, “the SolarWinds (major software company) hack, one of the biggest cybersecurity breaches of the 21st century” and was considered a highly lucrative target for CTAs based on its privileged access to IT systems. Specifically, the SolarWinds Orion IT monitoring software was targeted, allowing access to hundreds of thousands of organizations around the world to include portions of the US Government. Currently, nearly 30% of Horizon3 customers still use or have used SolarWinds applications in their networks, and two years later with 7% still finding the SolarWinds Orion API Authentication Bypass Vulnerability (CVE-2020-10148) in their pentests.

According to open-source research, below is the SolarWinds hack timeline:

Log4Shell: 2021’s worst holiday gift

Another example of a large-scale holiday season attack includes the Log4Shell remote code execution (RCE) vulnerability (CVE-2021-44228) that was surfaced right before Christmas in late 2021. On  December 9, 2021, this new vulnerability was discovered in the Apache Log4j open source library, which is used in most of the developed java applications. Due to the proliferation of Log4j in java, “the number of devices that could potentially be affected by the security vulnerability is approximately 2.5 – 3 billion.” CTAs can exploit a vulnerable application by sending a crafted user input to it, hoping that the application will log their arbitrary code as input and allow them persistent access, as well as lateral movement. One year later, 64% of Horizon3 customers using NodeZero are still experiencing the CVE-2021-44228 vulnerability in their environment.

According to open-source research, below is the Apache Log4j timeline:

  • December 9, 2021 – Original vulnerability disclosed and first patch (2.15.0) was made available
  • December 14, 2021 – Second vulnerability disclosed and second patch (2.16.0) was made available
  • December 18, 2021 – Third vulnerability disclosed and third patch (2.17.0) was made available
  • December 28, 2021 – Fourth vulnerability disclosed and fourth patch (2.17.1) was made available

At the end of the day, attackers care greatly that we want to take some time off and enjoy our families, because that is when we are at our weakest. CTAs use these “down times” to take advantage of low staffing and chaos surrounding the holidays to deploy new tactics, techniques, and procedures (TTPs), while also focusing on targets with the biggest bang for the buck.

Remaining vigilant throughout the holiday season will help ensure your systems and networks are secure, which is why adopting an autonomous approach to proactively finding those attack vectors can save your security team its most critical resource: time. Incorporating a regular pentest cadence will get you results quickly, so mitigations and verifications are timely, giving you much needed time to enjoy the holidays!

Albert Martinek is a Customer Threat Analyst with

The post Holiday Season Threat Awareness appeared first on

Higher Education Organization Improves Cybersecurity Posture with NodeZero

When the director of technology for a higher education organization went looking for a better way to identify and prioritize security weaknesses on the school’s servers and networks, his first interaction with and NodeZero started off with an impressive bang.

“I wanted to see proof of concept, and solved one of our biggest security holes because of that PoC,” or proof of concept, he says. On the first op, NodeZero was able to compromise the domain admin account.
Not just one account, in fact, but four, via an LLMNR vulnerability.

Without a lot of work, we were able to clean that up before we even licensed NodeZero – that was huge,
says their IT director.

Cybersecurity presents a complex challenge for the school, as it is spread out over several campuses and managed remotely. The director of technology is their highest-ranking technology staff member at the organization. The role oversees 400 endpoints within the organization, in addition to securing roughly 600 students on their own VLAN/Subnet during the school year.

NodeZero offers more specificity

Previous pentesting options were helpful, but often left the team chasing down vulnerabilities that turned out to not actually be exploitable.

“Often, it was just informational, and didn’t really affect your security,” he says.

With, “One of the things that really struck me was that it isn’t just the tool – and the tool is fantastic – but it’s the people around the tool who are available, in the chat, scheduling meetings. When I was running the PoV (Proof of Value) someone was there.”

He was also sold on NodeZero by its capability to run on demand.

“What sold me on it was seeing it at work and, because we know security is a journey and not a destination, the idea of being able to continuously run scans and pentests is great,” he says.

The team now runs weekly pentests to maintain vigilant cybersecurity on their network, he notes.

Getting the most from your time

Time management and focusing effort is huge in maintaining a strong security posture. Chasing down every lead with equal time and energy isn’t helpful when we know that not every vulnerability is actionable.

“You have critical down to informational severity issues, but I believe a tool a lot more when it says this is a critical misconfiguration we have compromised – oh and by the way, here’s your hashed password,” he says. “When that’s happened, I recognized the first and last character and knew that was the password.”

Context scoring based on critical impacts helps hammer home where to best deploy limited resources to secure
the environment.

“It’s the difference between casing a house and saying how I might be able to break in – that window might not be locked, that door doesn’t seem secure. But if you can actually break in, that’s critical. It’s the difference between telling me something might happen versus something did happen.”

Easy fixes but you need to find them first

While the LLMNR vulnerability wasn’t a huge challenge to fix, discovering it was a bit of a shock, the Director of Technology explains – and that’s why regular tests are so helpful. Security is so expansive it’s hard to cover everything.

“We try to work to secure our network, but it’s possible for any organization to miss things or have little holes” in their security, he says. A solution like NodeZero can find those small gaps that leave the organization open to risks so the team can shore them up quickly and easily.

“With stuff like LLMNR, the fix isn’t hard if you have the tools to fix a lot of machines at once,” he says. It’s identifying those risks in the grander picture that is the real struggle.
NodeZero helps uncover what you don’t know, he says, and tells you how to fix it so you don’t spend time researching the answer.

“You’re not chasing your tail following a large list of vulnerabilities,” he says. “It cuts down the task of securing your network because you’re starting at the critical, most impactful things. You get a view of things you just aren’t going to have without a pentest.”

Since starting to incorporate NodeZero into their security profile, other features, such as external pentesting, have been released and added to the solution’s usefulness.

“There’s a lot of tools out there that just hand you the tool and you’re on your own,” he says.

“The support, being able to set up a time to answer a question, it’s all been helpful. They work with us as opposed to saying ‘We got ‘em, on to the next account.’”

Download as PDF

The post Higher Education Organization Improves Cybersecurity Posture with NodeZero appeared first on

NodeZero Host Virtual Machine

The NodeZero Host virtual appliance is a small virtual machine based on a pre-configured Ubuntu 20.04 installation. It’s designed to execute NodeZero pentests and bundles tools that facilitate pentest execution, as well as debug and maintenance.


IMPORTANT:Always verify that the files you download come from Horizon3.
VMWare / VirtualBox importable OVA


The NodeZero virtual machine comes pre-configured to use these resources:

  • 2 x CPUs
  • 8GB of RAM
  • 40GB of disk
  • Bridged network adapter


Installing the virtual machine is a matter of importing the OVA file from the download link above into your virtualization environment. We provide the following set of steps as an example to use with VMWare’s vSphere client or with VirtualBox.

VMWare vSphere

vSphere client is one of VMWare’s virtual environment management solutions. You can find more information on the client itself in VMWare’s documentation.

NOTE:The following steps are for vSphere client version

After downloading and verifying the most recent NodeZero-####.ova file from the downloads section above, follow these steps to import and launch the NodeZero virtual machine.

  1. Log into your VMWare vSphere client.
  2. Select Deploy OVF Template from the Actions menu.
  3. Select the Local File option
  4. Click the UPLOAD FILES button to locate the OVA file downloaded in step #1.
  5. Click Next.
  6. Give your VM a name if you want it to be different from the default, and select a location to deploy to.
  7. Click Next.
  8. Select the compute resources you’ll be using.
  9. Click Next.
  10. Verify the import settings are correct and that the signature is from Horizon3.
  11. Click Next.
  12. Select the storage destination.
  13. Click Next.
  14. Select a network to use.
  15. Click Next.
  16. Review your selections
  17. Click Finish.
  18. To launch the VM, select it from the list on the left and click the Power On button.


After downloading and verifying the most recent NodeZero-####.ova file from the downloads section above, follow these steps to import and launch the NodeZero virtual machine.

  1. Open VirtualBox.
  2. Click on Tools.
  3. Click on Import.
  4. Enter the location of the OVA file.
  5. Click Continue.
  6. Click Import wait for it to complete.
  7. Make sure you use a bridged network adapter:
    • Select the newly imported NodeZero virtual machine from the list on the left.
    • Click Settings.
    • Click Network.
    • Check that Attached to: says Bridged Adapter.
    • Check that Name: is the name of the adapter connected to your internal network.
    • Click OK if you had to change anything.
    • NOTE:There are known issues with VirtualBox network bridges over wireless adapters in newer MacOS versions. If you’re experiencing connectivity problems, consider using a wired connection instead.
  8. Select the NodeZero virtual machine from the list on the left.
  9. Launch the VM by clicking Start.



If using vSphere, once you power on the virtual machine, the client interface gives the option of using a web console or a remote console for your first login.

If using VirtualBox, after starting the VM, a new display window appears that shows the operating system load screen.

With either system, once the OS fully loads, you’ll see a login screen that looks like this:

Username and First Login

When first launching the NodeZero virtual machine, SSH password access is disabled until you login and update the default password.

  1. Login with these credentials:
    • Username: nodezero
    • Password: nodezero
  2. When successful, you’ll see a prompt like the one below:
    You are required to change your password immediately (administrator enforced)
    Changing password for nodezero.
    Current password:
  3. Enter the password from step #1 and hit enter.
  4. Next you’ll see a prompt for New password:, enter a secure password that you’ll use from now on and hit enter.
  5. Next you have to confirm the password Retype new password:, enter the same password from step #4 and hit enter.
  6. You are now logged in with a successful password change. Make sure to keep that password for use in the future.

Once the login process completes, you’ll see an Enabling SSH password authentication message. At this point you can continue working through the vSphere or VirtualBox consoles, but you can also use an SSH client to connect to the IP address shown on the login screen.

Using SSH

To connect over SSH with Linux or MacOS, simply run the command below, replacing IP_ADDRESS with the one shown in the login screen.
$ ssh [email protected]_ADDRESS

If you’re using Windows, then you’ll use a client like PuTTY to connect. Simply fill out the Host Name (or IP Address) field with the address shown in the login screen.

Configuration with the n0 command

This virtual machine comes with a simple script that helps adjust basic settings and other maintenance tasks. It’s available under the n0 command, and running it presents you with a menu:

$ n0
1) Check environment
2) System info
3) Configure Static IP
4) Configure network proxy
5) Update
6) Version info

The following sections provide more information on what these options do.

Network configuration

Options #3 and #4 in the n0 command menu allow you to adjust network settings as follows.

Switching between DHCP and Static IP assignment

By default the NodeZero applicance comes with DHCP enabled. But if you need to switch to static addressing, you can use option #3 and follow the prompts to configure a new IP address, Subnet, Gateway and DNS nameserver.

If you ever need to switch back to DHCP, you can use the same option.

Configure a network proxy

You’re also able to setup a proxy server for HTTP and HTTPS traffic. Simply select option #4 and follow the example in the prompt when entering the URL. Note that you’ll have to log out and back in before this change takes effect.

Checking things are working

Option #1 of the n0 command menu checks that the system is ready to execute a pentest. It verifies we have access to the correct amount of resources and the right commands. It’s the same as running the Host Check Script.

Option #2 provides system information and can serve as a way to check your current settings. You’ll find details on the processors, memory, disk and network configuration.

Running a NodeZero pentest

  1. Log into the Horizon3 web portal
  2. Schedule a new pentest following your usual process.
  3. Copy and paste the launch / curl command from the portal into the shell of a NodeZero virtual machine.
  4. Pentest starts executing.

Staying up to date

You can use the n0 command menu’s option #5 to perform an OS and tools update.

The post NodeZero Host Virtual Machine appeared first on

Penetration tester identifies Fortinet exploit source, assists those checking for potential attacks

SiliconANGLE: 11/02/22

“We want to be to have a tool that can be used to exploit our customer system safely to prove that they’re vulnerable, so then they can go and fix it,” said James Horseman (pictured, right), exploit developer at

Read the entire article here

The post Penetration tester identifies Fortinet exploit source, assists those checking for potential attacks appeared first on

Russia-Ukraine Conflict Heightens Wariness of Nation-State Attacks as 64% Of Businesses Believe They Have Been Targeted

CPO Magazine: 10/21/22

Well over half of the respondents not only believe that they have already been targeted by nation-state attacks, but have made changes to their cybersecurity practices due to the Russia-Ukraine conflict.

Read the entire article here

The post Russia-Ukraine Conflict Heightens Wariness of Nation-State Attacks as 64% Of Businesses Believe They Have Been Targeted appeared first on

Verifying Credentialed Access to Your Hybrid Cloud Sprawl Matters More Than Ever

Over the few years, the number of assets in our environments has exponentially expanded. This is because of:

  • Cloud adoption and migration
  • Work-from-home options
  • Company growth and expansion

Let’s start with the cloud. Are you there already? Are you moving there? Are you moving back? Why?

Everyone is talking about infrastructure and environments, the cost, the speed – but core to all that incredible capability remains our credentials. The shared security model for our cloud environments is heavily based on credentialed access, which begs the larger question: do you understand the reach (blast radius) in your cloud account if an attacker obtained a credential for a specific user or role?

Why does this matter?

  1. Statistics show companies are accelerating and growing their cloud environments:
    1. REF:
    2. REF:
  2. Research indicates attacker trends are conducting malware-less attacks and living off the land more and more:
    1. REF:
    2. REF:
  3. Autonomous decision-making platforms make this attack vector easier and faster than ever to execute:
    1. REF:

See what we did there?


We’ll start with what is currently the most commonly used cloud service option available, Amazon Web Services (AWS). There are two main types of identities in AWS: users and roles. To authenticate to AWS as a user you must have either:

  • the username and password for that user, or
  • a set of AWS API keys for that user

Roles operate a little differently and are instead assumed by other AWS services, users, or roles. To assume a role, one only needs to know the account ID and the name of the role. As roles are discovered, these roles could be assumed, allowing attackers to pivot and expand their reach within an AWS account.

Even more interesting is that roles in one AWS account can be assumed by users or roles in another AWS account. This may be common if multiple AWS accounts are tied to a single AWS Organization or in some severe cases any other (unrelated) AWS account.


NodeZero, our autonomous attacker, has multiple vectors through which it can discover AWS Account IDs and AWS roles needed to use these new capabilities just like a human cyber threat actor.

NodeZero Discovers AWS Account IDs through:

  1. Active or expired AWS keys associated with the account. The user may inject keys when configuring an op, or NodeZero may discover keys during an op.
  2. An AWS account ID specified by the user when configuring an op.
  3. AWS credentials that have permissions to see other accounts linked in the same AWS organization. The user may inject credentials when configuring an op, or NodeZero may discover credentials during an op.

NodeZero discovers AWS roles by:

  1. Using brute force tactics to find valid role names.
  2. With an AWS credential that has permission to list roles in an AWS account.

Now for the fun part: chaining these discoveries together.

Attack Path #1

BLUF: In this environment, the cloud domain had a role in its AWS account which was misconfigured to allow any AWS user or role in any AWS account to assume this role.

Using the AWS account ID, NodeZero first enumerates common roles resulting in the discovery of this particular role. NodeZero then attempts to assume this role using its AWS CloudZero keys. Due to the misconfiguration, the ‘assume role’ request is successful and AWS returns AWS temporary keys. This allows NodeZero to then log in with the now compromised role.

Furthermore, with this credential and role, NodeZero was able to compromise AWS services like Beanstalk and Route 53, which could allow an attacker to spin up additional cloud services and instances (e.g., high-end GPUs for crypto-mining or password cracking) on the company dime.

Attack Path #2

This path is much like the previous, but instead of a common role, NodeZero could have discovered a credential elsewhere in the environment (even on-prem), but here a credential was injected to verify the blast radius of a particular credential.

Note: This might be the most valuable perspective in securing your cloud, hybrid, and on-prem environments!

NodeZero was injected with a credential we will call ‘assumable-user’ to keep our stories straight. During the pentest operation, NodeZero found a role in the AWS account that could be assumed by assumable-user. NodeZero then attempted to use that credential to list AWS users and roles, however, assumable-user did not have the required permissions. NodeZero then used the injected credential’s AWS keys to discover the AWS account ID. Using the account ID, NodeZero attempted to brute-force common AWS roles.

In this case, NodeZero discovers the Audit role and then attempts to assume this role with the assumable-user credential. The assumable-user successfully assumed the Audit role, and NodeZero surfaced this weakness to the customer.

What’s interesting here is that the role name can be complicated, so users have another opportunity to confound and limit an attacker.

But they often don’t.

Attack Path #3

If a role was given a complicated name, this will drastically limit the ability for an attacker to assume a role, and therefore compromise additional services in an organization’s private cloud. However, this defensive measure can be circumvented when a credential is compromised.

While it is unlikely an attacker, or even NodeZero, would be able to brute force a complex named role quickly and without drawing attention, if a credential is compromised elsewhere which has access to this AWS account, an attacker can list the roles for that credential in a target account and then easily assume a role now that it knows the name.

The Fix recommends the following steps:

  1. Find your hybrid cloud assets, especially those keys stored in reachable files and misconfigured accounts and credentials, and discover attack paths leading them deeper.
  2. Fix keys, roles, and credentials and the access to critical data each of them has, especially those on your production cloud environments which could impact your business and brand.
  3. Verify your security posture by attacking your hybrid cloud environments, and level up your game by injecting a credential just to see what impact an attacker could levy on your cloud



Credentials are the new RCE – even more so now in our sprawling cloud and hybrid environments. By continuously attacking your cloud environment, you can start fighting through the sprawl and attacking back to find, fix, and verify what matters most.

The post Verifying Credentialed Access to Your Hybrid Cloud Sprawl Matters More Than Ever appeared first on

Black Hat Europe 2022

Date(s): 12/5/22 – 12/8/22
Time: 10:00 am – 6:00 pm GMT
Location: London, UK
Booth #: 424

Description: Join CEO Snehal Antani for his session ‘Credentials are the new RCE’. Learn how attackers are using OSINT and password spraying to breach organization perimeters without ever needing a CVE – and hear real-world stories of how NodeZero does this at scale.

The post Black Hat Europe 2022 appeared first on

OpenSSL Critical Vulnerability: Should You Be Spooked?

On Tuesday, October 25 a new OpenSSL hot-fix release was announced which will patch a critical vulnerability that exists within the v3.0.X branch. OpenSSL 3.0.7 will be released on Tuesday, November 1 and in tandem the details of the vulnerability and its associated CVE will be made public.

OpenSSL is an open source project that provides easy to use cryptographic functions and is used to secure communications around the world. Put plainly, the internet runs on OpenSSL.

This blog will speculate as to the nature of the coming vulnerability and the likelihood of it being weaponize-able from an exploit developer’s perspective.

What’s Affected?

Nearly every *nix distribution uses OpenSSL. Thankfully, the lion’s share of OpenSSL usage still resides on the maintained v1 branch of the project and this vulnerability only effects the v3 branch. We have identified several major linux distributions on the v3 branch:

  • Ubuntu 22.04

  • CentOS 9

  • Fedora 9

Several distributions and appliances we’ve check that are on the v1 branch and not effected:

  • Amazon Linux AMI

  • vCenter

  • Fortinet FortiGate

To asses what version of OpenSSL is being utilized by your system you can run the following:

openssl version

Other installed applications may bring in their own dependencies outside of the system install locations so a more thorough search should be done for any non-standard services.

Open4Sslell… do we have another Log4Shell situation on our hands?

OpenSSL is even more ubiquitous than Log4j, the Java logging library that was affected by the Log4Shell (CVE-2021-44228) nearly a year ago. But, as we’ve seen with the rash of “named” vulnerabilities as of recent like “Spring4Shell” and “Text4Shell”, a critical vulnerability is not always critical.

Log4Shell was easily exploitable in the common configuration and the nature of the vulnerability allowed for attackers to easily execute arbitrary code if run on older Java runtimes.

OpenSSL rates their security issues and we can see that in order for a critical to be issued, the vulnerability must affect the common configuration, and leading to private key disclosure or is easily exploited remotely. This combination of items for an exploit developer definitely points to it being a target of interest.

If this upcoming vulnerability is like the last critical OpenSSL vulnerability in 2016, it will be significantly more difficult to weaponize than Log4Shell. The prior CVE-2016-6309 was a Use-After-Free (UAF) vulnerability that was triggered when processing large messages and only affected a single release version. Memory corruption issues like this are not so straight forward and are increasingly becoming more difficult to weaponize on modern operating systems. Libraries reside in applications which run on operating systems – and there are marathon worth of hurdles to overcome to truly weaponize a Use-After-Free or similar bug.


While this vulnerability may be easy to trigger, it will probably take serious investment by an organization to weaponize. This investment will take time, and time kills access when it comes to N-days and their patch cycles.

As we all eagerly wake up from our night of trick-or-treating come Tuesday morning, I think we’ll find our industry is abuzz about this new hot vulnerability – and a week later we’ll all move on.

We’ll see.

The post OpenSSL Critical Vulnerability: Should You Be Spooked? appeared first on

IANS Information Security Forum

Date: November 15, 2022
Time: 7:00 am – 6:30 pm ET
Location: Marriott Marquis, New York, NY

Description: The New York Forum is designed for information security practitioners across all industries to dive deep on specific topics, share insights, and network with peers. During this one-day event you will present and interact with Forum attendees.

The post IANS Information Security Forum appeared first on

What’s in store for the technology security landscape, and where does pentesting fit in?

SiliconANGLE: 10/18/22

As much as companies are adjusting to new economic realities, one area in which they’re refusing to compromise is security. A major reason behind this is the constantly widening threat area, including multiple simultaneous clouds, managed solutions, and distributed workforces and infrastructures, according to Antani.

Read the entire article here

The post What’s in store for the technology security landscape, and where does pentesting fit in? appeared first on

Horizon3 AI founder discusses MSP and reseller market dynamics in wake of partner program expansion

SiliconANGLE: 10/18/22

“How do we build a product and a business model that enables those last-mile channel partners to make even more revenue using us to underpin their offerings and services and get them to take advantage of the trust that they’ve built over many hard years and use that trust to not only improve the posture of their customers, but have Horizon3 become a force enabler along the way?” asked Snehal Antani, co-founder and chief executive officer of Horizon3 AI.

Read the entire article here

The post Horizon3 AI founder discusses MSP and reseller market dynamics in wake of partner program expansion appeared first on

Secure Your Fortinet Appliances Across On-Prem, Cloud, and Hybrid Networks at Scale

Security Boulevard: 10/18/22

While unannounced zero-day vulnerabilities garner a fair bit of fear and attention, one of the greatest risks introduced to business operations are newly announced vulnerabilities, or N-days.

Read the entire article here

The post Secure Your Fortinet Appliances Across On-Prem, Cloud, and Hybrid Networks at Scale appeared first on

Fortinet Admits Many Devices Still Unprotected Against Exploited Vulnerability

Security Week: 10/17/22

Fortinet is concerned that many of its customers’ devices are still unprotected against attacks exploiting the recently disclosed zero-day vulnerability and the company has urged them to take action.

Read the entire article here

The post Fortinet Admits Many Devices Still Unprotected Against Exploited Vulnerability appeared first on

Fortinet triple-whammy CVE gets PoC, deep dive explanation

The Register: 10/17/22

A critical flaw in Fortinet’s FortiOS, FortiProxy and FortiSwitchManager has been patched, but for those of a curious nature security firm has released a proof of concept for the exploit, as well as explaining how it works.

Read the entire article here

The post Fortinet triple-whammy CVE gets PoC, deep dive explanation appeared first on

Fortinet FortiOS, FortiProxy, and FortiSwitch Manager Authentication Bypass Vulnerability under Active…

NHS: 10/17/22

The US Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2022-40684 to their Known Exploited Vulnerabilities Catalog. A proof-of-concept has also been made public by

Read the entire article here

The post Fortinet FortiOS, FortiProxy, and FortiSwitch Manager Authentication Bypass Vulnerability under Active… appeared first on’s NodeZero Takes Top Honors in the TMC 2022 Cloud Security Excellence Awards

Businesswire: 10/20/22

NodeZero was named a winner for its ability to continuously assess an enterprise’s internal and external attack surface, and how it reveals the many ways in which an attacker could leverage harvested credentials, misconfigurations, dangerous product defaults and exploitable vulnerabilities to compromise systems and data.

Read the entire article here

The post’s NodeZero Takes Top Honors in the TMC 2022 Cloud Security Excellence Awards appeared first on

The Undeniable Effectiveness of Password Spray

One of the most effective techniques NodeZero employs for initial access is password spray. It’s a primitive technique, basically guessing passwords, and when it works it feels like magic. Yet we see it work time and time again in various pentests conducted by NodeZero. In this post we’ll talk about what password spray is and walk through how NodeZero weaponizes this technique in internal and external pentests. We’ll then provide practical tips for defenders to guard against this common attack.


In a traditional brute force attack, an attacker targets a single account and tries to repeatedly guess the password for the account until he/she succeeds, or gives up. This type of attack rarely works unless the account happens to have a really weak password.

In a password spray attack, an attacker starts with a list of users and a shortlist of probable weak passwords. The attacker tries (i.e. “sprays”) each password, one at a time, against all all users in an attempt to compromise at least one account. Attackers usually limit the rate of their attempts to avoid causing account lockouts. Attackers know that, once they’ve compromised at least one account, they can abuse that account’s access to enumerate deeper and potentially compromise more accounts, assets, and data.

A password spray attack has a much higher chance of success than a traditional brute force attack because it only requires compromising one account out of many possible accounts. In large organizations especially, the odds are high that there are going to be some users with weak passwords who would be susceptible to password spray.

Password spray is tracked as MITRE ATT&CK technique T1110.003. APT-28 (Fancy Bear), APT-29 (Nobelium), and APT-33 (Elfin) are examples of well-known threat actors who have used this technique. But this is not a technique just reserved for nation-state threat actors. Microsoft has estimated in the past that password spray attacks account for nearly one third of account compromises. Many spraying toolkits, such as crackmapexec, are readily available, making password spray a point-and-click operation for any level of attacker.

How NodeZero Weaponizes Password Spray

Username Enumeration

The first step for an attacker executing a password spray attack is compiling a large list of users. The larger the list, the more likely the attack will succeed.

NodeZero uses about a dozen different methods to gather usernames, both internally and externally. These methods include scraping user information from social media and exploiting misconfigurations in commonly used applications such as Jira, Jenkins, ManageEngine ADManager Plus, and WordPress. In internal pentests with older domain controllers, anonymous access over SMB is an especially powerful misconfiguration for attackers because it can lead to directly enumerating all domain users. If NodeZero already has a regular domain user credential in hand, it uses that credential to enumerate other domain users.

These username enumeration misconfigurations are often thought to be medium or low severity issues to fix, but they can be really valuable for attackers when used in conjunction with password spray.

Here’s an example of a weakness raised by NodeZero after exploiting a Jira misconfiguration to enumerate all users:

And the associated proof for the weakness showing the list of users that were scraped:

Password List Generation

With a list of usernames in hand, the next step for an attacker is to come up with passwords to spray. NodeZero generates probable passwords to spray based on commonly known breached passwords, context-specific terms such as the company name or domain name, or a custom dictionary supplied by the user.

Attackers know that most companies have set up a password policy to enforce a minimum password length of 8 characters, password complexity rules (including lowercase, uppercase, digits, and special characters), and periodic rotation of passwords. Password complexity and rotation policies have ironically led users to creating more predictable passwords such as passwords starting with an uppercase letter, ending in 1!,, or containing seasons and years. NodeZero optimizes for these cases to maximize the likelihood of success.

In addition to spraying probable weak passwords, NodeZero also attempts to spray any passwords it finds organically during the course of a pentest, just like a real-world attacker would do. These are passwords that may be found through unintended data exposure or exploitation, and they may not necessarily be weak. This form of password spray is used to exploit password reuse across multiple accounts.

Password Spray Execution

In internal pentests, NodeZero conducts password spray against domain controllers in the hope of landing a domain user for initial access. If it already has a domain user in hand, NodeZero will further conduct targeted password spray against privileged domain users in an attempt to compromise the entire domain. In real-world pentests, NodeZero has fully compromised organizations through password spray alone.

Here’s an example of the attack graph generated from a successful password spray of a domain user in an internal pentest. In this case NodeZero scraped users off an ManageEngine ADManager Plus instance and guessed the password for the “santani” user using a password derived from a company name.

NodeZero raised the following weakness with proof of access:

In external pentests, NodeZero conducts password spray against Azure AD in the hope of landing an Azure AD user to access Microsoft365 services or backend Azure services such as the Azure Graph API. NodeZero uses a new public IP address each time it sprays in an effort to evade detection.

Here’s an example of an attack graph NodeZero generates from a successful password spray of an Azure AD user in an external pentest. In this case NodeZero scraped users off an externally accessible Jenkins instance and guessed the password for the “santani” user. NodeZero went on to access the user’s Microsoft365 Outlook mailbox.

NodeZero is designed to be safe to run in production environments. To minimize the possibility of locking out users, NodeZero throttles the rate of password spray to two attempts an hour. In real-world pentests, the time it takes for NodeZero to be successful at password spray can range from less than hour (a single spray attempt) to several days.

Tips for Defenders

There are two approaches for defense against password spray: one is increasing the level of effort for an attacker to succeed, and the second is putting controls in place in case an attacker does succeed. Both approaches are important. There is a tendency to scrutinize specific users and their passwords, but the reality, especially for large organizations, is that there are always going to be some users who choose predictable passwords that a motivated attacker will be able to compromise.

Increasing Attacker Difficulty

To increase the level of effort for attackers to succeed at password spray, we recommend implementing a password policy that is configured to:
  • Ban certain terms and their variants from appearing in passwords. These terms include dictionary words, known breached passwords and company-specific terms such as the company name. This is important because it makes attackers have to think outside the box to come up with passwords to spray. Consider using Azure AD Password Protection.
  • Do away with password complexity and password rotation policies. For a long time people who were advised that password complexity is important and passwords need to be rotated, but this advice has only led to people creating more predictable, easier-to-guess passwords. Our guidance on this is in line with the latest guidance from NIST Special Publication 800-63B.
  • Enforce a minimum password length – we recommend at least 12 characters. This is higher than the NIST-recommended minimum of 8 characters.
  • Set a relatively low account lockout threshold, but not too low. A lower account lockout threshold makes it so attackers have to spend more time conducting the spray. At the same time, if it’s too low, regular users may end up calling the IT helpdesk often after mistyping their passwords, and it’ll also enable attackers to easily perform a denial of service (DoS) attack against the organization. We recommend a threshold between 5 and 10 attempts before lockout.
  • Monitor application and domain controller logs, and setup alerts for login failure events happening across many users within a short window of time.
  • Fix any misconfigurations related to username enumeration, especially ones that yield a full snapshot of all users in the domain. Note that motivated attackers will still be able to compile a list of users, but it’s better to make it harder.

Other Controls

Multi-factor authentication (MFA) is a must-have for any external exposed endpoints. And if there’s an endpoint that doesn’t support MFA, it should not be exposed externally under any circumstances. The advantage of MFA is that, even if an attacker succeeds at password spray, he/she will have another hurdle to get through before fully compromising an account.

For internal networks, MFA won’t help much because there are many lower level endpoints using non-MFA protocols such as SMB, RPC, LDAP, and Kerberos that an attacker can spray against.

We also strongly recommend adhering to the standard principle of least privilege, ensuring all users are provisioned with only the access they need. Security is about defense in depth, and it’s important to minimize the blast radius – a single user being compromised should not instantly cascade into the rest of the organization also being compromised.

Try NodeZero

Finally, to truly get an idea of how well your organization can stand up to a password spray attack, you can run an internal or external pentest with NodeZero. Not only will NodeZero identify whether it was able to successfully execute a password spray attack, you’ll also be able to test your defenses and see what NodeZero is able to do with the credentials it acquires from the attack. Check out the free trial here!

The post The Undeniable Effectiveness of Password Spray appeared first on

Concerns Over Fortinet Flaw Mount; PoC Released, Exploit Activity Grows

Dark Reading: 10/14/22

James Horseman, exploit developer at says public data from GreyNoise—which tracks Internet scanning activity hitting security tools—shows the number of unique IPs using the exploit has grown from the single digits a few days ago, to over forty as of Oct. 14.

Read the entire article here

The post Concerns Over Fortinet Flaw Mount; PoC Released, Exploit Activity Grows appeared first on