Quite a few of the CVEs they can identify have "low" EPSS scores while there's only one with a "low" CVSS score. This could indicate they're not including EPSS scoring in their risk model. The severities for EPSS and CVSS are ranked as follows:

• Critical: CVSS ≥ 9.0; EPSS ≥ 0.90

• High: CVSS 6.0~9.0; EPSS 0.60~0.89

• Medium: CVSS 3.0~6.0, EPSS 0.30~0.59

• Low: CVSS 0.0~2.9; EPSS 0.0~0.29

Note: Counts may not all add up due to some CVEs not having an EPSS or CVSS score assigned yet.

We pulled the tags from the nuclei CVE templates and correlated them with the 300 flagged CVEs to see if ACME is focusing on any particular technology or vulnerability type. Below we see that Remote Code Execution (RCE) and Local File Inclusion (LFI) are the primary areas of focus for ACME.

When looking at the distribution of the cve year tag, we see that ACME primarily focuses on those RCE vulnerabilities that are less than six years old, with the oldest being 14 years.

Years of focus for ACME

When looking at the individual technologies, ACME does seem to prioritize specific ones. Namely a blend of SOHO and enterprise networking equipment, Apache, VMware, Wordpress, Confluence/Jira, and Oracle technologies like Weblogic and Coldfusion.

Technologies of observed CVEs by ACME

The full list of technologies is included at the end of the blog.

As a final observation, 41 CVEs observed by ACME were not among the CVEs used in the nuclei scans. This represents only an 86% accuracy in detecting the correct vulnerability being exploited. Upon investigation we found that some of the reported CVEs are part of a CVE series, meaning the CVE number of the nuclei template is part of the same vulnerability chain ACME reported, but with a different CVE number. However, most of these did not have a matching nuclei template. For example: CVE-2020-29390 (ZeroShell RCE) was observed, but there is no correlating nuclei template.

A list of all observed CVEs is included at the end of the blog.

Conclusion

In this blog series we detailed how to evade honeypots using JA3 hash randomization to enumerate and analyze the honeynets of threat intelligence providers. These providers frequently supply their intelligence to different security tools and services. By accurately mapping and excluding their honeynets, scans can be conducted more discreetly, making detection considerably more challenging.

While honeynets are a valuable tool and an important part of threat feed intelligence, it's good to remember that savvy attackers can evade these kinds of routine detection mechanisms and organizations should seek to include security measures that focus on application/API usage and behavior patterns like the Ghost platform.

Additional Resources

Python script for running nuclei scans

# launch_cve_scan.py
# pip install rich, pyyaml
import os
import sys
import time
import signal
import yaml
import subprocess
from subprocess import PIPE, DEVNULL
from datetime import datetime
from rich.progress import Progress
from rich.console import Console
from datetime import datetime

console = Console()

# Log info
log_info = "[#0079FF][-][/]"
log_success = "[#00DFA2][+][/]"
log_warn = "[#F6FA70][~][/]"
log_error = "[#FF0060 blink bold][!]"

# Filepaths
home_path = os.path.expanduser("~")
config_dir = f"{home_path}/.config"
root_dir = f"{config_dir}/cve_mapper"
pcap_dir = f"{root_dir}/pcaps"
scan_dir = f"{root_dir}/scans"

def parse_nuclei_template(yamlfile):
    with open(yamlfile, "r") as stream:
        try:
            return yaml.safe_load(stream)
        except yaml.YAMLError as exc:
            print(exc)
            return None

def get_nuclei_templates(nuclei_dir=f"{os.path.expanduser('~')}/nuclei-templates") - list:
    cves_dir = f"{nuclei_dir}/http/cves"
    results = list()
    for (dirpath, dirnames, filenames) in os.walk(cves_dir):
        for _ in filenames:
            yaml_file = f"{dirpath}/{_}"
            res = parse_nuclei_template(yaml_file)
            if res:
                res['template_filepath'] = yaml_file
                results.append(res)
    return results

def launch_nuclei_scan(cve_template, targ_list_fpath, progress, header_fpath, iserver, cap_iface='eth0', port='443'):
    cve = cve_template['id']
    template_path = cve_template['template_filepath']
    output_path = f"{scan_dir}/{cve}.json"
    pcap_path = f'{pcap_dir}/{cve}.pcap'
    pcap_cmd = f'tcpdump port {port} -i {cap_iface} -w "{pcap_dir}/{cve}.pcap"'
    pcap_p = subprocess.Popen(pcap_cmd, stderr=DEVNULL, stdout=DEVNULL, preexec_fn=os.setsid, shell=True)
    # ./go/bin/nuclei -duc -silent -t {template_path} -l {targ_list_fpath} -tlsi -jle {output_path} -H {header_fpath} -iserver {iserver} -bs 150 -rl 300
    args = ['./go/bin/nuclei', '-duc', '-silent', '-t', template_path, '-l', targ_list_fpath, '-tlsi', '-jle', output_path, '-H', header_fpath, '-iserver', iserver, '-bs', '150', '-rl', '300']
    progress.print(f"{log_info} [{cve}] Launching scan, please wait...")
    start_time = datetime.now()
    nuke_p = subprocess.Popen(args, stdin=PIPE, stdout=PIPE)
    output = nuke_p.communicate()
    os.killpg(os.getpgid(pcap_p.pid), signal.SIGTERM) # Safely close the pcap, so it doesn't get corrupted.
    end_time = datetime.now() - start_time
    progress.print(f"{log_success} [{cve}] Scan complete! Took: {end_time}")

def main():
    # Create our cache directories if they don't exist yet.
    if not os.path.exists(config_dir):
        os.mkdir(config_dir)
    if not os.path.exists(root_dir):
        os.mkdir(root_dir)
    if not os.path.exists(pcap_dir):
        os.mkdir(pcap_dir)
    if not os.path.exists(scan_dir):
        os.mkdir(scan_dir)
    
    console.log(f"{log_info} Loading nuclei templates. Please wait...")
    nuke_templates = get_nuclei_templates()
    console.log(f"{log_info} Loaded a total of {len(nuke_templates)} CVE templates.")
    
    targets_filepath = sys.argv[1]
    iserver = sys.argv[2]
    headers_filepath = "./headers.txt"
    
    # NOTE. tcpdump may have issues with permissions with -w on digitalocean droplets even if chmod 777 the directory
    # If it's not writing pcaps, run: sudo apparmor_parser -R /etc/apparmor.d/usr.bin.tcpdump
    
    with Progress() as progress:
        task_id = progress.add_task("[cyan]Scanning. Please wait...", total=len(nuke_templates))
        start_time = datetime.now()
        for nuke_template in nuke_templates:
            launch_nuclei_scan(cve_template=nuke_template, 
                              targ_list_fpath=targets_filepath, 
                              progress=progress, 
                              header_fpath=headers_filepath, 
                              iserver=iserver)
            progress.advance(task_id)
        end_time = datetime.now() - start_time
        console.log(f"{log_info} Scan took {end_time} for {len(nuke_templates):,} individual scans.")

if __name__ == "__main__":
    main()

Full list of technologies:

{ 
  "total": 394, 
  "router": 26, 
  "apache": 24, 
  "vmware": 11, 
  "oracle": 10, 
  "atlassian": 9, 
  "wavlink": 7, 
  "dlink": 7, 
  "cisco": 7, 
  "adobe": 6, 
  "netgear": 5, 
  "manageengine": 5, 
  "confluence": 5, 
  "wordpress": 5, 
  "jira": 5, 
  "msf": 5, 
  "weblogic": 5, 
  "mirai": 5, 
  "sophos": 4, 
  "coldfusion": 4, 
  "struts": 4, 
  "airflow": 3, 
  "firewall": 3, 
  "terramaster": 3, 
  "sap": 3, 
  "zoho": 3, 
  "wp": 3, 
  "spring": 3, 
  "glpi": 3, 
  "zimbra": 3, 
  "drupal": 3, 
  "vcenter": 3, 
  "gitlab": 3, 
  "hongdian": 3, 
  "cockpit": 3, 
  "zabbix": 2, 
  "solarview": 2, 
  "totolink": 2, 
  "wp-plugin": 2, 
  "ognl": 2, 
  "voipmonitor": 2, 
  "wso2": 2, 
  "apisix": 2, 
  "laravel": 2, 
  "fortinet": 2, 
  "fortigate": 2, 
  "fortios": 2, 
  "pentaho": 2, 
  "zyxel": 2, 
  "utm": 2, 
  "memory": 2, 
  "securepoint": 2, 
  "vbulletin": 2, 
  "vrealize": 2, 
  "zeroshell": 2, 
  "dotnetnuke": 2, 
  "tomcat": 2, 
  "bypass": 2, 
  "microfocus": 2, 
  "graphql": 2, 
  "exchange": 2, 
  "microsoft": 2, 
  "log4j": 2, 
  "bigip": 2, 
  "saltstack": 2, 
  "openam": 2, 
  "druid": 2, 
  "grafana": 2, 
  "shellshock": 1, 
  "syncserver": 1, 
  "geoserver": 1, 
  "dotcms": 1, 
  "spacelogic": 1, 
  "pfsense": 1, 
  "pfblockerng": 1, 
  "ibm": 1, 
  "aspera": 1, 
  "faspex": 1, 
  "smuggling": 1, 
  "netweaver": 1, 
  "web-dispatcher": 1, 
  "memory-pipes": 1, 
  "roxy": 1, 
  "kubeview": 1, 
  "kubernetes": 1, 
  "razer": 1, 
  "centos": 1, 
  "zzzphp": 1, 
  "zzzcms": 1, 
  "actuator": 1, 
  "wapples": 1, 
  "atom": 1, 
  "consul": 1, 
  "hashicorp": 1, 
  "qnap": 1, 
  "unisharp": 1, 
  "wpquery": 1, 
  "workspaceone": 1, 
  "fortiproxy": 1, 
  "joomla": 1, 
  "altenergy": 1, 
  "moveit": 1, 
  "odoo": 1, 
  "insight": 1, 
  "minio": 1, 
  "console": 1, 
  "kerbynet": 1, 
  "phpmyadmin": 1, 
  "dnn": 1, 
  "phpunit": 1, 
  "couchdb": 1, 
  "primetek": 1, 
  "telerik": 1, 
  "panos": 1, 
  "globalprotect": 1, 
  "axis": 1, 
  "axis2": 1, 
  "kentico": 1, 
  "iis": 1, 
  "pulsesecure": 1, 
  "influxdb": 1, 
  "lansweeper": 1, 
  "aem": 1, 
  "piluscart": 1, 
  "kibana": 1, 
  "sonicwall": 1, 
  "obr": 1, 
  "zerof": 1, 
  "movable": 1, 
  "metabase": 1, 
  "aviatrix": 1, 
  "yealink": 1, 
  "websvn": 1, 
  "elasticsearch": 1, 
  "ruby": 1, 
  "sitecore": 1, 
  "tenda": 1, 
  "saltapi": 1, 
  "omi": 1, 
  "motorola": 1, 
  "cobbler": 1, 
  "hpe": 1, 
  "mod-proxy": 1, 
  "solr": 1, 
  "sureline": 1, 
  "struts2": 1, 
  "r-seenet": 1, 
  "rocketchat": 1, 
  "lucee": 1, 
  "ivanti": 1, 
  "epm": 1, 
  "csa": 1, 
  "trendnet": 1, 
  "fortilogger": 1, 
  "tapestry": 1, 
  "jellyfin": 1, 
  "workspace": 1, 
  "hikvision": 1, 
  "opensis": 1, 
  "vsphere": 1, 
  "oam": 1, 
  "ntopng": 1, 
  "sonarqube": 1, 
  "cocoon": 1, 
  "xenmobile": 1, 
  "django": 1, 
  "mongo": 1, 
  "express": 1, 
  "opentsdb": 1, 
  "mida": 1, 
  "solarwinds": 1, 
  "linksys": 1, 
  "cacti": 1, 
  "solman": 1, 
  "artica": 1, 
  "opm": 1, 
  "yii": 1, 
  "gridx": 1, 
  "flink": 1, 
  "netsweeper": 1, 
  "fhem": 1, 
  "mobileiron": 1, 
  "sentry": 1, 
  "superwebmailer": 1, 
  "ucmdb": 1, 
  "rails": 1, 
  "acs": 1, 
  "liferay": 1, 
  "monitor": 1, 
  "dasan": 1, 
  "gpon": 1, 
  "logontracer": 1, 
  "lg-nas": 1, 
  "jenkins": 1, 
  "splunk": 1
}

To actually generate and send our request, we need to add a "Sender" node too. Let's add that and an Output node to capture and generate some output.

Wiring Up Your First Request

Let's wire it up and send the first request. A "Sender" node needs several inputs:

• A trigger event to trigger the request. This can come from the "replacements" or from the "start".

• The "request" input is the formatted request to use. In this case, the one we imported.

Then, move the mouse near the output section of "Start" and the circle will be highlighted. Once that has happened, click and hold the left mouse button and drag the wire over to attach it to the "start" of the "Sender" node. Repeat to wire everything up as shown.

Then, click the "Output" node, and in the "Template" section type "Done!"

Now our basic workflow is ready to run! Click the play arrow in the bottom left and it will fire our request off.

Capturing and Displaying Response Data

Now that we have the basics of wiring up a workflow, let's capture and display our IP address returned in the response.

Add another node, this time adding an "Extractor" node. Disconnect our sender's output from the Output node and instead connect the Sender to the "response" of the Extractor and the output of the Extractor to the Output node.

Click the "Extractor" node and select "Entire Body" from the Type menu, and I set the variable I want this captured in to $RESP_BODY$ and then I changed my Output template to the following:

In Reaper, variables are named in between two $ characters and can be accessed in anything from output to request nodes, in the event we want to say, replace a header value.

Then click the play button again, and we should see our IP displayed in the output window!

Basic Fuzzing: Sniper Mode

Next, let's try adding a Fuzzer to show a basic fuzz similar to Burp's Intruder sniper tool.

Click on the Fuzzer to open its menu. Let's change the placeholder variable's name. We will set it to $PLACEHOLDER$ And change our numeric list to run from 0 to 5.

The Fuzzer node will replace anything with that placeholder with the values in its list, during its loop phase. We will need to rewire our workflow to leverage the fuzzer. Anything connected to the right of the fuzzer is "downstream" of the Fuzzer and will be within its loop.

Then we need to take advantage of the fuzzer, so I modified the URL in the request to include the $PLACEHOLDER$ variable. I also changed my output template to:

We wire the fuzzer's "output" to a sender's "replacements" option.

After clicking play, we can see we fired off 5 requests to http://icanhazip.com/0, http://icanhazip.com/1, and so forth.

More Advanced Fuzzing: Pitch Fork

We can accomplish a similar task as intruder's "Pitchfork" attack type. To do this, wire up two Fuzzers to the start node. This will loop through each payload set simultaneously.

Let's add another fuzzer node and a merger node. The merger node will merge two sets of variables together to input them into the "replacements" section of the sender.

I simply set mine to use the CSV: a,b,c,d,e and changed my output to:

You can import this workflow to play with yourself. Download the atk file and click the folder icon in your workflow pane, and select the file to import it.

More Advanced Fuzzing: Cluster Bomb

Another common Intruder attack type is the "Cluster Bomb", which will try all possible combinations of the different payload sets.

In Reaper, you can consider a Fuzzer node like a for loop. Daisy chaining multiple fuzzers together will create the conditions for a "Cluster Bomb" style attack.

I set my Output to:

And Fuzzer A to use a numeric list from 1-5, and Fuzzer B to use a CSV of a,b,c,d,e,f

You can see from the output that it loops over each combination of each fuzzer, like a nested for loop.

I have attached the workflow below so you can import it to your Reaper instance to play around with.

Keep an eye out for more Reaper how-to guides!