Documentation

The Attacker’s Perspective

Horizon3.ai® can assess the attack surface of your hybrid cloud, helping you continuously find and fix your internal and external attack vectors before criminals exploit them. Follow these simple steps to run a pen test within your network.


1. Set Up a NodeZero Host

NodeZero is our prepackaged software module that simulates the activities of an attacker within your network. Setting up NodeZero requires only two things:

  • A host with Docker installed from which NodeZero will operate (the NodeZero Host)
    • We strongly recommend using Linux, but you can also use Mac or Windows with a little extra work. Click here for a deeper dive into the NodeZero Host.
    • Place this host within the part of your network from which you want the attack to originate.
    • If you need help with Docker installation, click on your platform: LinuxMacWindows
  • Connectivity to the Internet from that host
    • We recommend a hard-wired Ethernet connection of at least 40MBps download.

Once you have your NodeZero Host ready, log into a shell on it using your favorite method. We will be back here shortly.


2. Log Into the Portal

Click here to navigate to our Portal and log in with your credentials.


3. Run a Pen Test

Click
run_button.png
to bring up the Pen Test Configuration panel.

Once you complete all of the configuration steps below, an internal pen test will be executed which will perform recon and maneuver using the same tactics as an attacker, chaining together harvested credentials, misconfigurations, dangerous defaults and safely exploitable vulnerabilities.

Run_a_Pen_Test_c67a3d5abe.jpg

3.1 Pen Test Name

Use the Name section to quickly identify this pen test among the others you have run. We recommend you come up with a naming standard that fits your needs. For example:

[date]|[library]|[Nodezero Src]|[scope]

2021-09-01|NodeZero|East-Coast-Bizops|Full: This indicates that the NodeZero host was placed in the East Coast Bizops network and the scope was the entire enterprise.

2021-09-24|NodeZero|Netherlands Dev|US East Finance: This indicates a test to validate new controls were effective in stopping an attacker from reaching the US East Finance network from a development network.

3.2 Pen Test Scope

The pen test scope is the set of IPs and/or subnets (in CIDR notation) within which you want to run the pen test. The larger the scope, the better results you will get. This is not a “vulnerability scanner” that has a narrow focus. NodeZero assesses your environment and uses any data it finds, and the context around it, to identify and exploit your vulnerabilities, misconfigurations, and poor cybersecurity hygiene.

If you are unclear on CIDR notation, here is a reference and a calculator app to assist you:

If your environment uses 192.168.0.1 and the subnet mask is 255.255.255.0, then you’ll add the following to the Include section: 192.168.0.0/24

For properly segmented environments, use comma-separated CIDR notation. For example: 192.168.0.0/16,172.16.10.0/24,10.0.0.0/8

If you are running NodeZero in a more complex environment, set the scope to cover as many subnets as possible. You should ask your Network Administrator for a list of CIDR annotated subnets.

The Exclude section stops NodeZero from scanning or exploiting a set of IPs or subnets. The IPs within this section may be discovered by NodeZero via various techniques within the pen test, but NodeZero will not touch them. They may show up in the Out of Scope list within the pen test results. Note that this parameter also requires CIDR notation.

3.3 Pen Test Confirmation

Click
Next_Button_e8669ece6a.jpg
through the optional configuration panels until you reach the Review panel.

Op_Confirm_1a29a8839d.jpg

Click
Confirm_a9f97d2a1c.jpg
to launch the pen test.
In a few minutes, the command-and-control system for the pen test will be provisioned and ready for execution.

3.4 Deploy NodeZero

While the pen test is provisioning, its companion one-time-use software module, NodeZero, is made ready for deployment on your NodeZero Host.

Op_Execute_0e9558bc27.jpg

Click
Copy_to_Clipboard_5df769a805.jpg
or highlight the command line provided and copy it with cmd+c or ctrl+c. Now, return to the shell on your NodeZero Host.


4 Execute NodeZero

Paste the command line you just copied into the shell of your NodeZero Host.

This script will validate the Docker installation, download the most up-to-date NodeZero Docker image, and begin the pen test. In the Portal, you will see the status of the pen test transition from Ready to Running.

nodezero_90f0a2aeb3.png

Back to Top

NodeZero Overview

NodeZero is a fully-automated cyber attacker that emulates the tools, tactics, and techniques of real-world attackers, so you can find and fix what matters NOW!

NodeZero.png

No Pervasive or Persistent Agents … 1-Click User Experience … Safe to Run in Production

This is true SaaS. NodeZero is an unauthenticated and ephemeral container you spin up and use on a Docker host. From a single machine anywhere in your environment, NodeZero examines and exploits your enterprise, recording a path to your critical assets, identifying vulnerabilities, chaining weaknesses and earmarking precious data. NodeZero validates what it thinks an attacker can do and delivers those results to you.

At a deeper technical level….

NodeZero enumerates and exploits benignly…learning about each host and the environment and making connections

  • @ Host includes port, service, and application discovery; then fingerprint applications to determine specific versions and attempt benign exploitation, and if successful capture proof of exploitation. NOTE: NodeZero attempts to and distinguishes between successful exploitation vs not, I.E., no false positives and un-exploitable vulnerabilities
  • @ Domain enumeration includes DNS, Active Directory pilfering, etc., then attempt to obtain usernames, credentials, and insecure policies to further exploit
  • @ Web enumeration includes virtual host discovery, endpoint discovery, and using machine learning to identify web pages of interest with high value for other attack methods to take advantage of
  • @ Cloud enumeration expands to include cloud-native capabilities, such as infrastructure as code, exposed data buckets, default credentials, and queuing structures to further exploit

NodeZero then communicates all information feeds back into our algorithms to enable targeted post-exploitation, including access to different critical data resources and credentials

Is NodeZero safe?

NodeZero is safe to run in your production environment. It uses benign exploitation techniques to validate weaknesses, gather proof, and reduce false positives without disrupting your systems and services.

  • We do NOT store the contents of any sensitive data we locate.
  • We do NOT store full passwords, only first & last letter.
  • We do store minimal host/service/weakness fingerprints (name, IP, port, etc) for reporting and algorithm tuning purposes.

Bottom Line: NodeZero chains multiple weaknesses, credentials, services, and misconfigurations to create a bread crumb trail and surfaces the attack path with proof of exploit without disrupting your systems.

Back to Top

NodeZero Host

NodeZero Host is a Docker host that runs the NodeZero container. Think of it as the starting point for an attacker. You decide where you want the Attacker’s Perspective to start and drop a NodeZero Host there. This host has to be running prior to the operation in order to download and execute NodeZero, and must continue running during the operation. Once the operation is complete, you are free to shutdown or remove the host from the network.

If a different distribution is desired contact the H3 team to determine suitability. It is likely that most distributions will run NodeZero without issue, we just haven’t written checks or validated all of them.

Ideal Host System Requirements

UPDATE: We have identified intermittent problems running NodeZero on macOS Big Sur (11.x) due to a Docker Engine issue within Docker Desktop for Mac. When the operation starts, it may not be able to communicate outbound to the Internet from within the Docker container. We are working to resolve this problem and will provide updates as soon as possible. In order to run an operation when this problem arises, we recommend using a virtual machine (such as with VirtualBox, etc.) configured with the required specs (noted below).

  • Machine Specifications
    • 2 CPU (physical or virtual)
    • 8GB RAM
    • 20 GB free HDD space
  • Operating System
    • Ubuntu Linux 16.x, 18.x, 20.x, or higher (also Debian)
    • Redhat Linux 7.x, 8.x, or higher (also CentOS, Fedora)
    • Synology NAS 6.2, 7.0
    • Other Linux distributions (if Docker supports them)
    • Windows 10 with WSL2 (limited NodeZero functionality)
    • macOS 10.x (limited NodeZero functionality)
  • Network Access (See Connectivity Requirements below for more specific information)
    • HTTPS:443 access to AWS SQS, Cognito, S3, and ECR
  • Docker installed (most recent version)
    • See Docker installation instructions below
Connectivity Requirements

The brains of your personal ethical hacker lives in a single-use architecture in the cloud. We call it Core. The NodeZero host needs access to Core over https:443 in order to communicate with it. Think of this communication as the central nervous system. Your brain, must send messages to your hands and your hands need to send feedback to your brain so that it can analyze and decide the next best action.

  • From a Service perspective, NodeZero must be able to communicate with Core. We currently utilize AWS SQS, Cognito, and S3 over HTTPS:443. This is NOT used as part of the assessment and must be allowed.
  • Assessment Perspective: Do NOT modify your environmentNodeZero is not like any other service or tool. If you wouldn’t modify it for an attacker, don’t modify it for NodeZero…If your firewall is configured to block your marketing VLAN from reaching your finance VLAN, leave it. NodeZero will VERIFY that is actually happening.

If your environment connects to the internet via a proxy, this will affect NodeZero's ability to communicate out. Contact us to facilitate compatibility.

Outbound Network Access

Uninterrupted network access to the following endpoints over TCP 443 during the entire operation

Inbound Network Access

The following ports should be opened on the NodeZero host/VM to allow traffic in:

  • TCP 21, 23, 25, 53, 80, 88, 110, 135, 139, 143, 389, 443, 445, 587, 1433, 3389, 8080
  • UDP 69

This is required on the NodeZero host. This does not pertain to perimeter firewalls.


Docker

https://opensource.com/resources/what-docker

“Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and deploy it as one package. By doing so, thanks to the container, the developer can rest assured that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code.”

Installation

To install docker on Ubuntu, perform the following steps:

sudo su
apt-get update
apt-get install docker-ce docker-ce-cli containerd.io

NOTE: On Ubuntu version 20.04, replace the above command apt-get install docker-ce docker-ce-cli containerd.io with sudo apt-get install -y docker.io

You can get more information on installing docker engine for different operating systems in the docker documentation.

Validation

Once the installation is complete, validate your NodeZero host is ready to run operations by running the NodeZero environment validation script (preferred).

Run the following command to run the script:

curl https://h3ai-web.s3.amazonaws.com/checkenv.sh | bash

The output should look similar to the following:

# curl https://h3ai-web.s3.amazonaws.com/checkenv.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 18646  100 18646    0     0  61134      0 --:--:-- --:--:-- --:--:-- 61134

[#] This script validates the environment is ready to run NodeZero.

[#] Checking Operating System:
[+] PASSED: macOS is a supported Operating System.

[#] Gathering environmental variables to conduct further checks:
[+] PASSED: All environmental variables set and proceeding with next checks.

[#] Checking Docker functionality by running the hello-world test container:
[+] PASSED: Docker is installed and functioning properly.

[#] Checking Docker permissions to volume mount files from /Users/test/test directory:
[+] PASSED: Docker permissions are correct for the /Users/test/test directory location.

[#] Checking connectivity to AWS resources:
[+] PASSED: s3.us-east-2.amazonaws.com is reachable.

[#] Checking 6GB HDD space requirements:
[+] PASSED: There is enough space for the NodeZero container: 34.0386GB

[#] Checking memory requirements:
[+] PASSED: This system has 32GB RAM which meets the recommended minimum to support NodeZero.

[#] Checking compute resource requirements:
[+] PASSED: This system has 20 CPUs which meets the minimum logical CPU requirements to run NodeZero.

[#] Script complete. If any checks failed, correct and re-run before attempting to 'Run a Pen Test'. If all checks passed, the environment is NodeZero ready. If there are warnings, the environment is still NodeZero ready and you may choose to accept or correct the warnings.

If you run into any Failures, please contact us via the chat icon in the lower right hand corner of the portal, or shoot us a message at customer.success@horizon3.ai.

Linux Guide

The NodeZero Docker container can be hosted on most Linux Operating Systems by using Docker Community Edition.

References for installing Docker on Linux can be found below:

For more documentation on requirements and setup to run NodeZero, see NodeZero Docker Host

Back to Top

Synology Guide

1. Install the Docker app

To install the Docker app from the Synology UI, open the Package Center app.

1.png

In Package Center, search for docker.

docker1.png

Click on install.

docker2.png

Click open.

docker3.png

The docker app is now installed and running.

2. Confirm SSH is enabled

In the Synology UI, navigate to Control Panel > Terminal & SNMP > Terminal. If it is disabled, check ‘enable SSH’ with the port set to 22. Click apply.

ssh.png

3. Confirm User Home Service is enabled

The user account that will be used to SSH to the Synology NAS must have the User Home Service feature enabled for their account. Please note that depending on the version of Synology you are using, the path to enable the user home service is slightly different.

a. Synology version 6.2

To enable User Home Service in the Synology UI, navigate to Control Panel > User > Advanced. Tick the ‘Enable user home’ service box and click apply.

syn_62.png

b. Synology version 7.0

To enable User Home Service in the Synology UI, navigate to Control Panel > User & Group > Advanced. Tick the ‘Enable user home service’ service box and click apply.

syn_7.png

4. SSH to the Synology NAS

Log in with the user that has User Home Service enabled. By default, you should land in the home directory for that user. If not, cd to the following directory:

cd /var/services/homes/<username>


For more documentation on requirements and setup to run NodeZero, see NodeZero Docker Host.

Back to Top

Windows Guide

 

There are two recommended options for running NodeZero on Windows:

1. Desktop Hypervisor (Recommended)

Using a desktop hypervisor such as VirtualBox (free), VMware Player (free) or VMware Workstation (paid) allows more advanced control. This enables choosing the Operating System (OS) to use as a Docker host by running a Virtual Machine (VM) within the desired desktop hypervisor of choice. This option requires the installation of the desktop hypervisor, deploying a VM or OVA template, and installing Docker on the deployed VM’s OS.

Links for installing desktop hypervisors on Windows are as follows:

VirtualBox (free)
VMware Player (free)
Guides to deploy an Ubuntu VM can be found in the references below:

For more documentation on requirements and configuration to run NodeZero, see NodeZero Docker Host.


2. Windows Subsystem for Linux and Docker Desktop for Windows

Windows Subsystem for Linux (WSL) is a way to enable compatibility with Linux. Using this approach allows the NodeZero launch script to work on Windows.

a. Install Docker Desktop

Download Docker Desktop for Windows from https://hub.docker.com/editions/community/docker-ce-desktop-windows and install.

Check all options in the configuration.

features.PNG

Select Close and restart.

finish.PNG

b. Install and configure WSL

Install Windows Subsystem for Linux from https://docs.microsoft.com/en-us/windows/wsl/install-win10.

If you are running Windows 10 Enterprise, Pro, or Education, enable Hyper-V by following https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v and reboot your computer.

c. Install and configure Linux

Install Linux for Windows from https://www.microsoft.com/en-us/p/ubuntu/9nblggh4msv6?activetab=pivot:overviewtab

Once the install is complete, launch the application from your start menu. It will be named Ubuntu.

After you have followed the prompts to create your username and password, launch Docker Desktop from your Start menu or desktop shortcut.

When Docker Desktop starts, go to Settings > Resources > WSL Integration. You should see something like the below.

D_resources.PNG

Toggle the button next to your installed Linux version (in this case, Ubuntu) and click “Apply & Restart” in the lower right-hand corner.

To validate your install, return to your Linux terminal and run the following:

sudo su
curl https://h3ai-web.s3.amazonaws.com/checkenv.sh | bash 

The output should look similar to the following:

# curl https://h3ai-web.s3.amazonaws.com/checkenv.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 18646  100 18646    0     0  61134      0 --:--:-- --:--:-- --:--:-- 61134

[#] This script validates the environment is ready to run NodeZero.

[#] Checking Operating System:
[+] PASSED: macOS is a supported Operating System.

[#] Gathering environmental variables to conduct further checks:
[+] PASSED: All environmental variables set and proceeding with next checks.

[#] Checking Docker functionality by running the hello-world test container:
[+] PASSED: Docker is installed and functioning properly.

[#] Checking Docker permissions to volume mount files from /Users/test/test directory:
[+] PASSED: Docker permissions are correct for the /Users/test/test directory location.

[#] Checking connectivity to AWS resources:
[+] PASSED: s3.us-east-2.amazonaws.com is reachable.

[#] Checking 6GB HDD space requirements:
[+] PASSED: There is enough space for the NodeZero container: 34.0386GB

[#] Checking memory requirements:
[+] PASSED: This system has 32GB RAM which meets the recommended minimum to support NodeZero.

[#] Checking compute resource requirements:
[+] PASSED: This system has 20 CPUs which meets the minimum logical CPU requirements to run NodeZero.

[#] Script complete. If any checks failed, correct and re-run before attempting to 'Run a Pen Test'. If all checks passed, the environment is NodeZero ready. If there are warnings, the environment is still NodeZero ready and you may choose to accept or correct the warnings.

If you run into any Failures, please contact us via the chat icon in the lower right-hand corner of the Portal, or shoot us a message at customer.success@horizon3.ai

From here you are ready to run an op! Follow starting at step 3 from our getting started guide https://www.horizon3.ai/documentation/getting-started.

d. Troubleshooting

If you run into errors when starting docker please see here for assistance. https://docs.docker.com/docker-for-windows/troubleshoot/#virtualization

Back to Top

Mac OS Guide

There are two supported options for running NodeZero on macOS:

1. Desktop Hypervisor (Recommended)

Using a desktop hypervisor such as VirtualBox, VMware, or Parallels allows better functionality and more advanced control. This enables choosing the Operating System (OS) to use as a docker host by running a Virtual Machine (VM) within the desired desktop hypervisor of choice. This option requires installation of the desktop hypervisor, deploying a VM or OVA template, and installing Docker on the deployed VM’s OS.

Links for installing desktop hypervisors on macOS are as follows:

VirtualBox (free)
VMware Fusion
Parallels Desktop
Guides to deploy an Ubuntu VM can be found in the references below:

2. Docker Desktop for Mac

UPDATE: We have identified intermittent problems running NodeZero on macOS Big Sur (11.x) due to a Docker Engine issue within Docker Desktop for Mac. When the operation starts, it may not be able to communicate outbound to the Internet from within the Docker container. We are working to resolve this problem and will provide updates as soon as possible. In order to run an operation when this problem arises, we recommend using a virtual machine (such as with VirtualBox, etc.) configured with the required specs (noted below).

Hosting the container natively on macOS requires the installation of Docker Desktop for Mac. References for downloading and installing Docker Desktop for Mac are as follows:


For more documentation on requirements and setup to run NodeZero, see NodeZero Docker Host.

Back to Top

NodeZero Deployment Options

BLUF: Where you setup your NodeZero host—your operation launch point—matters.

Before setting up your NodeZero host, you need to decide what you want to learn from the operation. The following are a few options you may find helpful in making this decision.

deploy0.png

1 – Inside Custom Scope

  • If you want to limit the scope and see what an attacker could exploit from inside that defined range, you’d place the NodeZero host within the scope you want to test.

deploy2.png

When you setup the scope for your Pen Test, just make sure the NodeZero host is within one of the specified CIDR range(s) for the test.

PRO TIP: ensure a Domain Controller is in-scope as well, and NodeZero will attempt to exploit any vulnerabilities or misconfigurations on this host, as well as verify weak domain defaults & credentials

This is your high-speed assessment; enabling a lean Find-Fix-Verify loop to initiate an agile security posture

deploy3.png

2 – Outside Custom Scope

  • But if you wanted an “outside-in” perspective to see if an attacker could access critical data and assets inside a specific scope, you’d place the NodeZero host outside the scope you want to test.

deploy5.png

When you setup the scope for your Pen Test, just make sure the NodeZero host is NOT within the specified CIDR range(s) for the test.

NOTE: When NodeZero is not in the same IP range as the scope, it will not execute Man-In-The-Middle and pass-the-hash attacks

This is your unrestricted assessment; providing true insight into what is accessible, valuable, and vulnerable from any starting point

deploy5.png

3 – Endpoints Only Scope

  • Once in a while you may just want to quickly verify if the vulnerability you just remediated had the effect you desired. In this case, you can select a single host or range of hosts by /32s

When you setup the scope for your Pen Test, just make sure the NodeZero host has access to the specific host identified by the /32 CIDR range(s) for the test.

deploy30.png

When you setup the scope for your Pen Test, just make sure the NodeZero host is NOT within the specified CIDR range(s) for the test.

*NOTE: Just as with #2, when NodeZero is not in the same IP range as the scope, it will not execute Man-In-The-Middle and pass-the-hash attacks. Further, with this restricted scope, NodeZero will not chain weaknesses nor paths as you have limited the scope to a specific endpoint for this assessment

This is your restricted assessment; a quick turnaround op to verify your fix-action was implemented and a vulnerability is now presenting less severity to your attack surface

deploy31.png

4 – Intelligent Scope

  • Let’s say you wanted to see what an uncredentialed attacker could enumerate and exploit from a specific starting point in your network – a true “black box” pen test – this calls for Intelligent Scope

deploy7.png

When you setup the scope for your pen test, leave “Include” box blank. NodeZero’s host subnet will provide the initial scope and it will expand organically during the pen test as more hosts and subnets are discovered…just like an attacker would.

This is your proactive assessment; providing true insight into what is accessible, valuable, and vulnerable from any starting point

deploy8.png

5 – All Private IP Scope (i.e., RFC 1918)

  • And when you’re really ready to roll, you’ll love the ability to run an RFC 1918 full private scope pen test, enumerating everything accessible quickly and safely.

deploy10.png

Just select the “Use RFC 1918” box and NodeZero will take care of the rest. As always, you can Exclude any IP addresses or ranges from this and any operation.

NOTE: This op may take a bit longer as NodeZero enumerates any IPs and DNS names it can access…including edge routers; if yours are misconfigured for routing private IPs, NodeZero may attempt to enumerate those external private IPs.

PRO TIP: if you really want to see EVERYTHING, put NodeZero in an unrestricted ACL so it can discover every nook and cranny online in your environment

This is your unrestricted and holistic enterprise assessment–and should be run regularly

deploy11.png

6 – OSINT

  • Available with any of pen test operation is our Open-Source Intelligence (OSINT) assessment, where NodeZero will gather publicly available information to use as part of the pen test.

deploy13.png

The second step of configuring your pen test offers you the ability to take a true external perspective; your company name will be auto-filled for you, and you can provide TLDs and weak password terms you’d like NodeZero to test with any discovered information.

NOTE: NodeZero’s OSINT gathering operates outside your environment so NodeZero placement isn’t as critical…however, when combined with an internal op with a domain controller in-scope, NodeZero will verify domain users and passwords with those found publicly giving your further insight into your attack surface risk.

This is your external reconnaissance capability to see what attacker’s see and use to start their campaigns and establish a foothold in your environment

deploy14.png

Use this table as a reference for all your Automated Pen Test operations!

deploy15.png

Back to Top

API Guide

The Horizon3.ai API provides programmatic access to a subset of functionality available through the Horizon3.ai portal. At a a high level, this API allows for:

  • scheduling an automated pentest, known as an operation
  • monitoring the status of the operation while it is running
  • retrieving an operation report after it’s complete

The API can be used for a variety of use cases such as periodically scheduling assessments of your environment or kicking off an operation as part of a continuous integration build pipeline.

  • Pre-Requisites
    • API Access
    • Client Infrastructure
      • Host/VM Requirements
      • Outbound Network Access
      • Inbound Network Access
      • Container Privileges
    • Create an Operation Template
  • API Specification
    • Authentication
    • Scheduling an Operation
    • Launching an Operation
    • Monitoring the Status of an Operation
      • Operation Life Cycle
      • Querying the Operation State
    • Reporting
  • Example Script

Pre-Requisites

Prior to using the Horizon3.ai API, make sure to complete the following steps:

  • Getting an API Key
  • Setting up a host/VM to host the Horizon3.ai Docker container, called NodeZero
  • Creating an operation template These steps are described in greater detail below.

API Access

An API key is required to access the API. The key is tied to an existing user account with Org Admin privileges in the Horizon3.ai portal.

At this time, API keys are manually provisioned by Horizon3.ai. If you don’t have an API key, please contact your Horizon3.ai representative to acquire one.

In addition, if you have an API key and need to revoke it and/or generate a new one, please contact your Horizon3.ai representative Please download the PDF to view it

Client Infrastructure

Running a Horizon3.ai operation requires running a Docker container, called NodeZero, on a Linux VM or host. The NodeZero container receives instructions from the Horizon3.ai cloud in order carry out the operation.

The NodeZero container may open ports on the host/VM in order to conduct certain types of attacks. The container automatically shuts down after the operation is complete.

A NodeZero container is used only once per operation. Once an operation is complete, the NodeZero container can be removed.

api_img_01.png

Host/VM Requirements

  • Linux:
    • Ubuntu >= 16.04
    • Redhat >= 7
  • 2 CPUs
  • 4GB RAM
  • 10GB free disk space
  • Docker >= v17.0.7

Outbound Network Access

  • Uninterrupted network access to the following endpoints over TCP 443 during the entire operation
    • cognito-identity.us-east-2.amazonaws.com
    • us-east-2.queue.amazonaws.com
    • *.s3.us-east-2.amazonaws.com

It is possible to run NodeZero through a proxy if necessary. Contact your Horizon3.ai representative for more details.

Inbound Network Access

The following ports should be opened on the NodeZero host/VM to allow traffic in:

  • TCP 21, 23, 25, 53, 80, 88, 110, 135, 139, 143, 389, 443, 445, 587, 1433, 3389, 8080
  • UDP 69

This is required on the NodeZero host. This does not pertain to perimeter firewalls.

Container Privileges

The NodeZero container runs with the following elevated privileges:

  • root user inside the container
  • –network=host privileges
  • –cap-add=SYS_ADMIN
  • –security-opt apparmor=unconfined

These privileges are required to carry out certain types of automated attacks.

Create an Operation Template

Prior to scheduling an operation, the user to whom the API key belongs must first create an operation template in the Horizon3.ai portal. An operation template describes the scope that the client wants to scan and the operation configuration. The scope consists of IP addresses and subnets that the client wants to scan. The configuration describes which attack behaviors are turned on or off during the operation.


API Specification

The API is hosted at api.horizon3ai.com. It provides endpoints for authentication, scheduling an op, monitoring the status of an op, and reporting. The current API version is v1, and all endpoints in the v1 API are accessible at api.horizon3ai.com/v1.

At a high level, to run an operation, the following sequence of steps should be followed:

  1. Authenticate using an API key.
  2. Schedule an operation using the operation template you configured earlier.
  3. Download a launch script.
  4. Run the launch script on the NodeZero Linux host to launch the operation. This is done outside of the API.
  5. While the operation is running, its state can be monitored using the API. The operation is complete when its state is “done.”
  6. Download an operation report.

api_img_02.png

These steps are described in further detail below.

Authentication

A client first authenticates by using its API key against the auth endpoint. The auth API validates the API key and returns a JSON Web Token (JWT) that clients use to invoke other APIs, as described below.

The JWT expires after an hour. Clients must retrieve a new JWT from the auth endpoint after an hour.

Example Request


curl \
  -X POST https://api.horizon3ai.com/v1/auth \
  -H "Content-Type: application/json" \
  -d @- <<HERE 
{
    "key": "<API key>"
}
HERE

Example response


{"token": "<token>"}

Status Codes

  • 200: Success: The response contains the JWT in the token field.
  • 400: Bad Request: Missing Content-Type header
  • 401: Unauthorized: Malformed request payload or unauthorized API key
  • 5xx: Internal Server Error

Launching an Operation

After a client schedules an operation, the Horizon3.ai service begins the process of provisioning cloud infrastructure to support the operation. This process can take a few minutes. When the provisioning process completes, the client should download an operation launch script using the graphql query shown below. The nodezero_script_url field in the response returns a short-lived download URL that should be used by the client to directly download a NodeZero launch script. The URL is valid for up to 12 hours.

The launch script is a bash script that should be run on the NodeZero host. The script validates NodeZero system requirements, downloads the NodeZero Docker image, and runs the NodeZero container.

When an operation is initially scheduled, the download URL for the launch script will not be immediately available. The client can poll periodically on the graphql endpoint until a download URL is returned. Alternatively, the client can poll for the operation status as described in the next section. The script will always be available by the time an operation enters the “ready” state.

Example Request

curl \
 -X POST https://api.horizon3ai.com/v1/graphql \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer <token>"
 -d @- <<HERE
{
   "query": "
                 query {
                             op(op_id:\"e11b0a7c-fd24-4d48-b4c9-de8220f99847\") {
                                    nodezero_script_url
                             }
                   }
       "
}
HERE

Example Response

{
     "data": {
             "op": {
                   "nodezero_script_url": "<link>"
               }
       }
}

Status Codes

  • 200: Success. The nodezero_script_url field in the response will contain a link to download the script using an HTTPS GET. If the operation is not yet ready, or if the operation is already running or complete, the nodezero_script_url field in the response will have a value of null.
  • 400: Bad Request: Malformed request. The errors field inside the response will contain a descriptive message.
  • 401: Unauthorized: Invalid or expired JWT
  • 403: Forbidden: op_id in the GET request is invalid or not authorized for access. The errors field inside the response will contain a descriptive message.
  • 5xx: Internal Server Error

Monitoring the Status of an Operation

Operation Life Cycle

It’s helpful to understand the life cycle of an operation. An operation always starts off in an initial state of “scheduled”, and it proceeds until it reaches a terminal state of either “Done”, “Canceled”, or “Error.” In between the initial state and a terminal state, there are other states that an operation can assume. These are described in the table below, roughly in the order that the operation proceeds.

api_img_03.png

State Description
scheduled This is the first state an operation enters, Immediately after an API client or end-user schedules an operation.
provisioning The Horizon3.ai cloud service is actively setting up infrastructure to support the operation.
ready The operation is ready to begin. The Horizon3.ai cloud service is waiting for the NodeZero container to start. The operation launch script is available for client download.
running The NodeZero container has connected to the Horizon3.ai cloud service, and the operation is in progress.
complete The Horizon3.ai service has finished executing all attack sequences against the client environment via NodeZero.
destroying The Horizon3.ai service is actively tearing down infrastructure that was provisioned for the operation.
post-processing The Horizon3.ai service is processing the results of the operation and preparing an operation report.
done The operation report is available in the portal or via the API.
canceled An end-user has manually canceled the operation from the Horizon3.ai portal. An operation can only be canceled while it is in the “ready” or “running” state. After it is canceled, the operation moves into the “complete” state and ends at “canceled” instead of “done.” The operation report for everything that was collected prior to cancellation is available in the portal or via the API.
error Unspecified error

Querying the Operation State

The following graphql query against the graphql API endpoint can be used to retrieve the state of an operation. Knowing the state of an operation is helpful for several reasons:

  • If a client has just scheduled an operation, a client can poll on the operation state until it reaches “ready.” When the operation is “ready”, the client can get a link to the launch script to start the operation.
  • While an operation is “running”, a client can poll the operation state until it reaches “done” or “canceled” to know when the operation report is available for download.

A successful response contains the status of the operation in the op_state field.

Example Request

curl \
  -X POST https://api.horizon3ai.com/v1/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>"
  -d @- <<HERE 
{
    "query": "
        query { 
            op(op_id:\"e11b0a7c-fd24-4d48-b4c9-de8220f99847\") {
                op_state
            }
        }
    "
}
HERE

Example Response

{
    "data": {
        "op": {
            "op_state": "done"
        }
    }
}

Status

  • 200: Success. The response will contains the operation status in the op_state field.
  • 400: Bad Request: Malformed request. The errors field inside the response will contain a descriptive message.
  • 401: Unauthorized: Invalid or expired JWT
  • 403: Forbidden: op_id in the GET request is invalid or not authorized for access. The errors field inside the response will contain a descriptive message.
  • 5xx: Internal Server Error

Reporting

After an operation reaches the “done” or “canceled” state, a client can download a summary report using the following graphql query against the graphql API endpoint. The endpoint returns a set of summary statistics containing the number of weaknesses found, credentials discovered, and hosts scanned.

Example Request

curl \
  -X POST https://api.horizon3ai.com/v1/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>"
  -d @- <<HERE 
{
    "query": "
        query { 
            op(op_id:\"e11b0a7c-fd24-4d48-b4c9-de8220f99847\") {
                op_name
                op_state
                scheduled_timestamp_iso
                launched_timestamp_iso
                completed_timestamp_iso
                duration_hms
                in_scope_hosts_count
                confirmed_weaknesses_count
                confirmed_credentials_count
            }
        }
    "
}
HERE

Example Response

{
    "data": {
        "op": {
            "completed_timestamp_iso": "2020-11-13T23:23:43",
            "duration_hms": "00:21:45",
            "in_scope_hosts_count": 10,
            "launched_timestamp_iso": "2020-11-13T23:01:59",
            "op_name": "my op name",
            "op_state": "done",
            "confirmed_credentials_count": 11,
            "confirmed_weaknesses_count": 7,
            "scheduled_timestamp_iso": "2020-11-13T22:14:17"
        }
    }
}

Status

-200: Success. The response contains summary data for the operation. If the operation was never launched or is not yet done, certain fields inside the response may have null values.

  • 400: Bad Request: Malformed request. The errors field inside the response will contain a descriptive message.
  • 401: Unauthorized: Invalid or expired JWT
  • 403: Forbidden: op_id in the GET request is invalid or not authorized for access. The errors field inside the response will contain a descriptive message.
  • 5xx: Internal Server Error

Example Script

The following bash script demonstrates all of the above API actions, from scheduling an operation to retrieving the operation report after the operation is done.

NOTE: This script does not handle error conditions or token renewal if the operation extends past an hour.

#!/bin/bash
#
# requires: curl, jq
#

# User defined parameters, set in the environment
API_KEY="$API_KEY"
OPERATION_TEMPLATE_NAME="$OP_TEMPLATE"
OPERATION_NAME="$OP_NAME"

# Static
API_URL="https://api.horizon3ai.com"
AUTH_URL="$API_URL"/v1/auth
GQL_URL="$API_URL"/v1/graphql
CONTENT_TYPE_HEADER="Content-Type: application/json"

function authenticate {
    curl -s -S \
     -X POST "$AUTH_URL" \
     -H "$CONTENT_TYPE_HEADER" \
     -d "{\"key\": \"$API_KEY\"}"
}

function schedule_op_template {
    curl -s -S \
     -X POST "$GQL_URL" \
     -H "$CONTENT_TYPE_HEADER" \
     -H "$AUTHZ_HEADER" \
     -d @- <<EOF 
{
    "query": "
        mutation { 
            schedule_op_template(
                op_template_name:\"$OPERATION_TEMPLATE_NAME\"
                op_name:\"$OPERATION_NAME\"
            ) { 
                op {
                    op_id
                }
            }
        }
    "
}
EOF
}

function fetch_op_state {
    curl -s -S \
      -X POST "$GQL_URL" \
      -H "$CONTENT_TYPE_HEADER" \
      -H "$AUTHZ_HEADER" \
      -d @- <<EOF
{
    "query": "
        query { 
            op(op_id:\"$OP_ID\") {
                op_state
            }
        }
    "
}
EOF
}

function fetch_nodezero_script_url {
    curl -s -S \
      -X POST "$GQL_URL" \
      -H "$CONTENT_TYPE_HEADER" \
      -H "$AUTHZ_HEADER" \
      -d @- <<EOF 
{
    "query": "
        query { 
            op(op_id:\"$OP_ID\") {
                nodezero_script_url
            }
        }
    "
}
EOF
}

function fetch_op_report {
    curl -s -S \
      -X POST "$GQL_URL" \
      -H "$CONTENT_TYPE_HEADER" \
      -H "$AUTHZ_HEADER" \
      -d @- <<EOF 
{
    "query": "
        query {
            op(op_id:\"$OP_ID\") {
                op_name
                op_state
                scheduled_timestamp_iso
                launched_timestamp_iso
                completed_timestamp_iso
                duration_hms
                in_scope_hosts_count
                confirmed_weaknesses_count
                confirmed_credentials_count
            }
        }
    "
}
EOF
}

function poll_op_for_status {
    while [ 1 ]; do
        op_state=`fetch_op_state | jq -r .data.op.op_state`
        if [ "$op_state" = "$WAIT_STATE" ]; then
            echo "op_state $op_state == $WAIT_STATE! breaking loop."
            break
        fi
        echo "op_state $op_state != $WAIT_STATE ..."
        sleep 15
    done
}

# Step 1: Authenticate to API to get short-lived session token
TOKEN=`authenticate | jq -r .token`
echo "Authenticated to API"

export AUTHZ_HEADER="Authorization: Bearer $TOKEN"

# Step 2: Schedule an operation
export OP_ID=`schedule_op_template | jq -r .data.schedule_op_template.op.op_id`
echo "Scheduled operation id: $OP_ID"

# Step 3: Wait for op to hit "ready" state
export WAIT_STATE="ready"
poll_op_for_status
echo "Operation is ready"

# Step 4: Get the link to the NodeZero launch script
SCRIPT_URL=`fetch_nodezero_script_url | jq -r .data.op.nodezero_script_url`
echo "Launching NodeZero..."

# Step 5: Launch the NodeZero container
curl "$SCRIPT_URL" | bash &

# Step 6: Wait til the op is "done"
export WAIT_STATE="done"
poll_op_for_status
echo "Operation is done"

# Step 7: Download the op report
REPORT=`fetch_op_report | jq -r .data.op`
echo "Operation report: $REPORT"

Back to Top

Scoring Matrix

Critical (9.0 – 10.0)

Vulnerabilities that score in the critical range usually have most of the following characteristics:

  • Exploitation of the vulnerability likely results in root-level compromise of servers or infrastructure devices.
  • Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victims, and does not need to persuade a target user, for example via social engineering, into performing any special functions.
  • This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.
  • Intruders can easily gain control of the host, which can lead to the compromise of your entire network security and may include full read and write access to files, remote execution of commands, and the presence of backdoors.
Impacts of Critical Severity Vulnerabilities

These vulnerabilities can allow attackers to take complete control of your resources. In exploiting this type of vulnerability, attackers could carry out a range of malicious acts including (but not limited to):

  • Stealing information (for example, user data)
  • Tricking your users into supplying them with sensitive information (for example, credit card details)
  • Defacing your website

By exploiting a critical severity vulnerability, attackers can access your website’s entire server. This allows them to acquire user and administrator information that might allow them to make changes such as delete or modify other user accounts.

On exploiting such vulnerabilities, attackers can access and control logged-in user or administrator accounts, enabling them to hijack accounts and make changes that typically only those users can.

Suggested Action for Critical Severity Vulnerabilities

A Critical severity vulnerability means that resources can be exploited at any time. It is advised to make it the highest priority to fix these vulnerabilities immediately via patching, upgrading or other mitigation measures. Once a fix action has been implemented, rescan the affected resource to ensure the vulnerability or weakness has been mitigated.

High (7.0 – 8.9)

Vulnerabilities that score in the high range usually have some of the following characteristics:

  • The vulnerability is difficult to exploit.
  • Exploitation could result in elevated privileges.
  • Exploitation could result in a significant data loss or downtime
  • This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
  • Intruders can possibly gain control of the host, or there may be potential leakage of highly sensitive information. For example, vulnerabilities at this level may include full read access to files, potential backdoors, or a listing of all the users on the host.
Impacts of High Severity Vulnerabilities

On exploiting such vulnerabilities, attackers can view information about your system that helps them find or exploit other vulnerabilities that enable them to take control of your website and access sensitive user and administrator information.

Suggested Action for High Severity Vulnerabilities

A High severity vulnerability means that resources can be exploited and attackers can find other vulnerabilities which have a bigger impact. Fix these types of vulnerabilities immediately. Once a fix action has been implemented, rescan the affected resource to ensure the vulnerability or weakness has been mitigated.

Medium (4.0 – 6.9)

Vulnerabilities that score in the medium range usually have some of the following characteristics:

  • Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
  • Denial of service vulnerabilities that are difficult to set up.
  • Exploits that require an attacker to reside on the same local network as the victim.
  • Vulnerabilities where exploitation provides only very limited access.
  • Vulnerabilities that require user privileges for successful exploitation.
  • This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or High impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
  • Intruders may be able to gain access to specific information stored on the host, including security settings. This could result in potential misuse of the host by intruders. For example, vulnerabilities at this level may include partial disclosure of file contents, access to certain files on the host, directory browsing, disclosure of filtering rules and security mechanisms, denial of service attacks, and unauthorized use of services, such as mail-relaying.
Impacts of Medium Severity Vulnerabilities

By exploiting Medium Severity Vulnerabilities, attackers will gain information and reconnaissance useful for their attack. Medium Severity vulnerabilities are often used to better understand your system, allowing them to refine and escalate the attacks. Such vulnerabilities can sometimes be connected, to increase the potential damage of the attack.

Suggested Action for Medium Severity Vulnerabilities

Most of the time, since the impact of Medium severity vulnerabilities is not direct, you should first focus on fixing High severity vulnerabilities. However, Medium severity vulnerabilities should still be addressed at the earliest possible opportunity.

Low (0.1 – 3.9)

  • Vulnerabilities in the low range typically have very little impact on an organization’s business. Exploitation of such vulnerabilities usually requires local or physical system access.
  • Intruders may be able to collect sensitive information from the host, such as the precise version of software installed. With this information, intruders can easily exploit known vulnerabilities specific to software versions.
  • This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.
Impacts of Low Severity Vulnerabilities

Do not overly concern efforts towards resources with low severity vulnerabilities. These types of issues do not have any significant impact and are likely not exploitable.

Suggested Action For Low Severity Vulnerabilities

If time and budget allows, it is worth investigating and fixing Low severity vulnerabilities .

Informational

  • Intruders can collect information about the host (open ports, services, etc.) and may be able to use this information to find other vulnerabilities.
  • If this vulnerability exists on your system, intruders can collect information about the host (open ports, services, etc.) and may be able to use this information to find other vulnerabilities.
  • Information may include NTLM Authorization Required, Email Address found, Robots.txt discovered, Web server version exposed, WAF detected, web server listening on port 80, telnet running, etc..
Impacts of Informational Alerts

Reported simply as supporting information for a resource, as they may not have a direct impact but could help an attacker to gain a better understanding of your underlying systems.

Suggested Action for Informational Alerts

In most cases, no action or fix is required.

Back to Top

Inject Credentials

NodeZero operates like an unauthenticated attacker (black box), enumerating and exploiting what it finds to build a true attacker’s perspective of your risk.

However…if you’d like to see how far an attacker can get when compromising a credential within your domain, you can inject a credential (up to 5) into a NodeZero operation to be leveraged as an attacker would and see full path and proof of what risk those particular credentials pose to your environment.

NOTE: this is NOT authenticated or elevated privileged scanning!

Whether injected, discovered, or cracked, NodeZero has two goals after obtaining a credential:

  1. Maneuver Laterally – · Enumerate Active Directory for attack paths that lead to more credentials or more privileged access on a host · Enumerate hosts for elevated permissions and then dump stored credentials in memory, the registry, and other common locations

  2. Obtain Sensitive Information – · Enumerate all endpoints in a network, looking for file shares, databases, and hosts that it can access · Laterally move and repeat

You can inject a credential into any running operation where a domain controller is within NodeZero’s scope for the op.

  • Click on the Action button, and select “Inject Credential”Inject1.png
  • Enter a user domain name and passwordInject2.png
  • Click “Submit”!

There are several use-cases where it is useful to understand how far an attacker may get after compromising a credential:

  • Regular User– Attackers have many common paths to compromise a regular user through phishing, breach data, or poor security hygiene. Whether compromised or deliberate (such as with an Insider Threat), ensuring further compromise is not possible is critical based on the highly demonstrated likelihood of occurrence.

  • Service Account – Service accounts are a high-value target for attackers because they are often over-privileged and multi-factor authentication is rarely enabled. This is the perfect scenario for an attacker to obtain the keys to your kingdom. Service accounts are often obtained after a vulnerability is exploited on an out-of-date application. Injecting service account credentials can help you understand the risk in one of those services being compromised.

Back to Top

Man-in-the-Middle attacks & Cyanide

What does Cyanide do?

Cyanide utilizes an opportunistic attack and combines Impacket’s ntlmrelayx.py along with poisoners (e.g. Responder) in order to correlate:

  • Who

    • Cyanide will provide information of who the user or service account was that was captured
  • What

    • What method of poisoning was used (LLMNT/NBT-NS/MDNS)?

    • What resource was requested (e.g SMB share, SQL database, etc.)?

  • Where

    • Where was the credential used?

    • Where was the source?

  • When

    • Date/timestamp of each event will be available:

    • When the host was poisoned

    • When the hash was captured

    • When a relay attack happened

  • Why

    • With the combined data, you will be able to tell why this attack happened and why it was successful.

Meaning, Responder will poison a host over LLMNR, then the poisoned host will reach back via whatever protocol the broadcast was for (e.g. SMB, RDP, MSSQL, etc.).

  • If the protocol is NOT SMB or HTTP, Responder will simply capture the credential and inform Cyanide of the results. Cyanide will then report this data back to core and an attempt to crack the hash will be made.

  • If the protocol IS SMB or HTTP, ntlmrelayx SMB and HTTP servers will capture the response from the poisoned host, prompt it to supply credentials, capture the credentials and then either save that information to be cracked offline or if relaying is enabled, use the username/hash captured and attempt to login to targets that appear to be high value and dump local credentials. This form of relaying credentials will only work if the target hosts DO NOT have SMB signing enabled.

At the end of an Operation, if Cyanide was successful in capturing a hash and (if relaying is enabled) relaying it, you will be able to see why this happened. Perhaps you have an old service account on a workstation, that is re-using credentials, but the intended network resource no longer exists on the network. This would trigger an LLMNR/NBT-NS event. You will be armed with all of the information needed to find the responsible source host captured from, protocol it was requesting (e.g. SMB), username used, and target service the username and hash was relayed to. Lastly, you can fix the host (applying the appropriate fix action described under the Weakness), and verify by running the same Operation again.

What does Responder do?

Responder is an LLMNR, NBT-NS and MDNS poisoner. It will answer to specific NBT-NS (NetBIOS Name Service) queries based on their name suffix (see: http://support.microsoft.com/kb/163409). By default, the tool will only answer to File Server Service request, which is for SMB. This tool listens on several ports: UDP/137, UDP/138, TCP/389, TCP/1433, UDP/1434, TCP/88, TCP/135, TCP/139, TCP/21, TCP/25, TCP/110, TCP/587, TCP/143, TCP/5985, Multicast UDP/5355 and 5353.

  • Poisoners

    • LLMNR

      • LLMNR stands for Link-Local Multicast Name Resolution. LLMNR is based on the DNS format and enables computers on the same local network to conduct name resolution of other hosts. LLMNR is unicast, so only the device that sent the request will see the reply.

      • Server port UDP/5355

    • NBTNS

      • NBT-NS stands for Network Basic Input/Output System Name Service. NBT-NS is often referred to as its base application programming interface, NetBIOS, for short. The NBT-NS protocol is used similar to LLMNR, except it utilizes hosts on the network by their NetBIOS name and will ask the receiving machine to disclose and return its current set of NetBIOS names. NBT-NS can utilize broadcast, unicast, or multicast.

      • UDP/137

      • UDP/138

    • MDNS

      • MDNS stands for Multicast Domain Naming System (DNS). MDNS replies are sent over multicast so that everyone can see them and keep their local mDNS cache up to date.

      • UDP/5353

  • Servers

    • MSSQL

      • TCP/1433

      • UDP/1434

    • RDP

      • TCP/3389
    • Kerberos

      • TCP/88
    • FTP

      • TCP/21
    • POP

      • TCP/110
    • SMTP

      • TCP/25

      • TCP/587

    • IMAP

      • TCP/143
    • HTTPS

      • TCP/443
    • LDAP

      • TCP/389

      • UDP/389

    • DCERPC

      • TCP/135
    • WINRM

      • TCP/5895
  • NTLM Relaying

NTLM Authentication is a challenge-response based protocol. Challenge-response protocols use a commonly shared secret, in this case the user password, to authenticate the client. The server sends a challenge, and the client replies with the response on this challenge. If the challenge matches the one calculated by the server, the authentication is accepted.

After a host is poisoned and the hash is captured, if relaying is enabled, the username/hash combination will attempt to login to the target hosts over SMB. In order for this attack to be successful the target host must not have SMB signing enabled. Upon successful login, a follow on attack will occur and attempt to harvest local usernames and hashes from that target.

  • Servers

    • HTTP

      • TCP/80
    • SMB

      • TCP/445
  • Attack

    • Secretsdump

      A secretsdump is an action performed against a target machine that will attempt to dump the Security Account Manager (SAM) on Windows hosts. If successful, a list of username/ntlm hashes will be harvested and can be used with tools such as Crackmapexec in order to pass the hash and access other hosts within the network.

      NOTE: SAM dumping can only occur if the user has administrative credentials. A non-privileged user may be able to login, but the default action Cyanide uses of dumping SAM cannot be achieved. However, this does not mean you don’t have to worry about it. Other actions can be utilized to gain access to the host and potential privilege escalate to an administrative user.

  • Where does it work?

    Since Responder works by capturing broadcast packets, capturing requests in different networks is not possible and therefore, Cyanide will only work within the network it resides in.

    Based on the location of NodeZero, that is the subnet that will be poisoned. Two ways Cyanide uses scope:

    Scenario 1: No scope is specified OR if the scope of the NodeZero host subnet is specified

    • Scope defaults to the full subnet of the NodeZero host to poison

      Example 1

      NodeZero host subnet: 192.168.0.0/24
      Scope: **Auto-Expand**
      

      Cyanide will get a scope of 192.168.0.0/24 because no scope was specified and poisoning can only happen within the network of NodeZero. Relaying will occur against high value targets that are discovered during host discovery and have SMB signing disabled.

      Example 2

      NodeZero host subnet: 192.168.0.0/24
      Scope: 172.16.100.0/24, 10.0.0.0/16, **192.168.0.0/24**
      

      Cyanide will get a scope of 192.168.0.0/24 because the specified scope contains the subnet of the NodeZero host. Relaying will occur against high value targets that are within the scope specified and have SMB signing disabled.

    Scenario 2: Scope of the NodeZero host is within the whitelist, Cyanide will get that as its scope

    *Example 1*
    ```
    NodeZero host subnet: 192.168.0.0/24
    Scope: 172.16.100.0/24, 10.0.0.0/16, **192.168.0.0/30**
    ```
    Cyanide will only poison hosts within the 192.168.0.0/30 subnet because it falls within the NodeZero hosts subnet.
    Relaying will occur against high value targets that are within the scope specified and have SMB signing disabled.
    

Summary

At the end of an Operation, if Cyanide was successful in capturing a hash and (if relaying is enabled) relaying it, you will be able to see the full path of exploitation.

Perhaps you have an old service account on a workstation, that is re-using administrative credentials, but the intended network resource no longer exists on the network. This would trigger a poisoning event, capture the hash, relay it, and potentially dump the local usernames & hashes on a target host. There is also the potential that the captured hash or dumped hashes derive from a weak password and could be cracked. In both cases, the potential for host and/or domain compromise is high, resulting in unauthorized access to your data.

Poisoning and relaying is enabled by default within the Advanced Configuration menu under Man in the Middle AttacksAdvanced Configuration - MITM

Back to Top

Contact Horizon3.ai

Horizon3.ai’s mission is to help you find and fix attack vectors before attackers can exploit them. Contact us now for a quote or if you have any questions.