Introduction

In an earlier post we looked at setting up our lab environment to launch attacks against our vulnerable Cisco Switch in our home lab using CVE-2023-20198 & CVE-2023-20273.

Today we look at options to check if the vulnerability is present on your Switch, how to mitigate against the vulnerability, some detection and threat hunting techniques for blue/purple teams and some other useful information for IR teams should incident forensics need to be performed.

Spoiler on the incident forensics, it’s isn’t easy…..cheers Cisco 🙂

Check to see if you are vulnerable

Below are some examples of scripts that can be used to check to see if you vulnerable to CVE-2023-20198.

smokeintheshell

Grab a copy of smokieintheshell python script

gitclone https://github.com/smokeintheshell/CVE-2023-20198.git

To check to see if the switch is vulnerable

python3 exploit.py -t [TARGET IP ADDRESS] -c

Mitigations

From our testing, for the attack to succeed the following conditions must be met

• The firmware on the switch must be less than 16.12.10a (Cisco Catalyst 3850)
• In order for CVE-2023-20198 or CVE-2023-20273 to be exploited the Web Management Interface must be exposed to the attacker
  • The web management interface is intended to allow administrators to administrate the Cisco Switches via a browser as opposed to through a console.
• Configuring AAA authentication on the Cisco Switch via methods such as Radius will mean that, although an attacker could use CVE-2023-20198 to create a type 15 account on the Cisco Switch, the attacker WILL NOT be able to SSH directly into the switch as said account if the AAA configuration is set to use Radius as its primary authentication method.
• However, regardless of if Radius is configured or not, the attacker is still able to use the type 15 account to log directly into the Web Management Interface or to execute commands as the root user at the kernel level using CVE-2023-20273.

Patch

Without stating the obvious, patch the switch if you can. Cisco provides an online software checker on their advisory page which confirms if your firmware version is vulnerable or not.

Cisco have released free software updates that address the vulnerabilities described in this advisory. Customers with service contracts that entitle them to regular software updates should obtain security fixes through their usual update channels.

Disable/Restrict Web Management Interface

If patching isn’t something that is possible then disabling or restricting access from untrusted networks to the Web Management Interface will also be effective.

Disable Web Management Interface

The below shows commands to disable the Web Management Interface for both http and https

config t

no ip http server

no ip http secure-server

Note. Worth rebooting the switch at this point as when testing we noticed that existing shells did still remain active.

Restrict Web Management Interface

Although not ideal, below are example commands that will only allow remote access to the HTTP Server from the trusted 192.168.0.0/24 network:

ip http access-class 75
ip http secure-server

access-list 75 permit 192.168.0.0 0.0.0.255
access-list 75 deny   any

After implementing any changes, use the copy running-configuration startup-configuration command to save the running-configuration. This will ensure that the changes are not reverted in the event of a system reload.

Detect/IR Response

There is a fair amount of logging that can be leveraged in order to detect for the attack. If 💩 has hit the fan then there are some options to perform IR on the compromised switch as well.

Syslog

Syslog from the switches can be forwarded to your SIEM of choice. On my switch I can access the syslog config settings by going to Troubleshooting –> Syslog -> Manage Syslog Configuration.

SIEM Alerts/Threat Hunting

Check the system logs for the presence of any of the following log messages where user could be any unrecognised user accounts.

Examples of what suspicious log messages look like include: 

%SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as user on line

Note: The %SYS-5-CONFIG_P message will be present for each instance that a user has accessed the web UI. The indicator to look for is new or unknown usernames present in the message.

As an example, the below was observed within my switch’s syslog’s when running CVE-2023-20198

%SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as admin on vty0

%SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as admin on vty0

When running exploits associated with CVE-2023-20273 the below logs were recorded within syslog.

%WEBSERVER-5-LOGIN_PASSED: Switch 1 R0/0: nginx: Login Successful from host 192.168.1.46 by user 'cyber0pste4m'

%WEBSERVER-5-LOGIN_PASSED: Switch 1 R0/0: nginx: Login Successful from host 192.168.1.46 by user 'cyber0pste4m'

Although we didn’t observe the following within our syslog when running the exploits, Cisco also advise looking out the following as well:

%SEC_LOGIN-5-WEBLOGIN_SUCCESS: Login Success [user: user] [Source: source_IP_address] at 03:42:13 UTC Wed Oct 11 2023

%WEBUI-6-INSTALL_OPERATION_INFO: User: username, Install Operation: ADD filename

Webserver Logs

The Web Server logs can be accessed by navigating to Troubleshooting -> Logs -> Web Server Logs.

When running exploits associated with CVE-2023-20198 against my Cisco Switch the below requests were recorded:

{nginx_R0-0}{1}: [ngx_core] [24238]: UUID: 0, ra: 0, TID: 0 (note): [24244] [access_log] [ATTACKERIP] - - [DD/MON/YYYY:HH:MM:SS +0000] "POST /%2577eb%2575i_%2577sma_Http HTTP/1.1" 200 14601 "-" "[USER AGENT STRING]"

When running exploits associated with CVE-2023-20273 against my Cisco Switch the below requests were recorded:

2025/08/06 17:59:55.231 {nginx_R0-0}{1}: [ngx_core] [24238]: UUID: 0, ra: 0, TID: 0 (ERR): [24244] 2025/08/06 17:59:55 [error] 24244#0: *1412 remaining lifetime is -1, client: 192.168.1.46, server: , request: "POST /webui/rest/softwareMgmt/installAdd HTTP/1.1", subrequest: "/aaa_request", host: "192.168.1.69“

2025/08/06 17:59:55.232 {nginx_R0-0}{1}: [errmsg] [24238]: UUID: 0, ra: 0, TID: 0 (note): %WEBSERVER-5-LOGIN_PASSED: Login Successful from host 192.168.1.46 by user 'cyber0pste4m'

2025/08/06 17:59:55.263 {nginx_R0-0}{1}: [ngx_core] [24238]: UUID: 0, ra: 0, TID: 0 (note): [24244] [access_log] 192.168.1.46 - cyber0pste4m [06/Aug/2025:17:59:55 +0000] "POST /webui/rest/softwareMgmt/installAdd HTTP/1.1" 200 5 "-" "CVE-2023-20273"

2025/08/06 17:59:58.495 {nginx_R0-0}{1}: [ngx_core] [24238]: UUID: 0, ra: 0, TID: 0 (ERR): [24244] 2025/08/06 17:59:58 [error] 24244#0: *1413 remaining lifetime is -1, client: 192.168.1.46, server: , request: "GET /webui/jyCnYl3H HTTP/1.1", subrequest: "/aaa_request", host: "192.168.1.69"

2025/08/06 17:59:58.502 {nginx_R0-0}{1}: [ngx_core] [24238]: UUID: 0, ra: 0, TID: 0 (note): [24244] [access_log] 192.168.1.46 - cyber0pste4m [06/Aug/2025:17:59:58 +0000] "GET /webui/jyCnYl3H HTTP/1.1" 200 39 "-" "CVE-2023-20273"

Review the running config

Review the running config on the compromised switch and do a diff against a known good backup (if possible). To extract the running config, issue the following commands with a type 15 account:

show running config

Things to look for:

• Any suspicious local accounts created
• Any changes made to the authentication method
• AAA/TACACS+ server modification (server IP address change)
• Loopback interface IP address modifications
• GRE tunnel creation and use
• Creation of unexpected local accounts
• ACL modifications
• SNMP community string modifications
• HTTP/HTTPS server modifications on both standard and non-standard ports

Crash Dumps

Crash dumps can be extracted from the live running server and can help in determining if successful logins had been made to the Web Management Interface. Cisco provide a guide on how these dumps can be extracted alongside other logs.

Information captured, from our experience, from the crash dumps can include:

• Username of logins
• Date and time of login
• Source IP address of login
• Some captures of both POST & GET request headers

Do note that these are crash dumps, so some information might be missing.

Snort Rules

Below are the snort rules that can help with the detection of the attack

• 3:50118 – alerts for initial implant injection (CVE-2023-20273)
• 3:62527 – alerts for implant interaction
• 3:62528 – alerts for implant interaction
• 3:62529 – alerts for implant interaction
• 3:62541 – alerts on attempted exploitation for initial access (CVE-2023-20198)
• 3:62542 – alerts on attempted exploitation for initial access (CVE-2023-20198)

Suricata Rules

Fox-IT has created Suricata rules for the detection of CVE-2023-20198:

# CVE-2023-20198 exploitation attempt (set flowbit, alert prio 3)

alert http any any -> any any (msg:"FOX-SRT - Exploit - Possible CVE-2023-20198 Exploitation Attempt Observed"; flow:established, to_server; http.method; content:"POST"; http.uri.raw; content:"%"; http.uri; content:"wsma_Http"; nocase; fast_pattern; flowbits:set, fox.cve-2023-20198.bypass; threshold:type limit, track by_src, count 1, seconds 600; classtype:attempted-admin; priority:3; reference:url, https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/; reference:url, github.com/fox-it/cisco-ios-xe-implant-detection; metadata:ids suricata; metadata:created_at 2023-10-19; metadata:cve 2023-20198; sid:21004544; rev:5;)

# CVE-2023-20198 exploitation attempt (matches any encoded percent, due to different escape possibilities that we cannot catch with Suricata, flowbit only and doesn’t alert)

alert http any any -> any any (msg:"FOX-SRT - Flowbit - Possible CVE-2023-20198 Exploitation Attempt Observed"; flow:established, to_server; http.method; content:"POST"; http.uri.raw; content:"%25"; fast_pattern; flowbits:set, fox.cve-2023-20198.bypass; flowbits:noalert; threshold:type limit, track by_src, count 1, seconds 600; classtype:attempted-admin; priority:3; reference:url, https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/; reference:url, github.com/fox-it/cisco-ios-xe-implant-detection; metadata:ids suricata; metadata:created_at 2023-10-19; metadata:cve 2023-20198; sid:21004554; rev:1;)

# Successful CVE-2023-20198 exploitation (check flowbit, alert prio 1)

alert http any any -> any any (msg:"FOX-SRT - Exploit - CVE-2023-20198 Possibly Successful Exploitation Attempt Observed"; flow:established, from_server; flowbits:isset, fox.cve-2023-20198.bypass; http.stat_code; content:"200"; http.response_body; content:"xmlns=|22|urn:cisco:"; fast_pattern; threshold:type limit, track by_src, count 1, seconds 600; classtype:successful-admin; priority:1; reference:url, https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/; reference:url, github.com/fox-it/cisco-ios-xe-implant-detection; metadata:ids suricata; metadata:created_at 2023-10-19; metadata:cve 2023-20198; sid:21004545; rev:4;)

Examination of the Linux Subsystem

By design Cisco do not allow owners of their own equipment unimpeded access to the Linux kernel portion of the switch. The “guestshell” feature only offers a containerised instance of a Linux Shell. CVE-2023-20273 however, would have allowed the attackers to operate at the Linux kernel unconstrained, at root privileges without the need for Cisco’s consent.

In order to obtain legitimate access to the Linux kernel of the Cisco switch one must first contact Cisco TAC and go through the following sequence of events in order to be granted root level access to the Linux kernel on the switch. The process involves Consent Token being exchanged between the network administrator and a representative from Cisco TAC.

As far as we are aware, there is no other way to access the Linux Kernel without the consent tokens being exchanged. Well, apart from CVE-2023-20273 of course😏

Once the tokens have been exchanged the network admin is dropped into a Linux terminal. Essentially from here you can perform IR like you would on any other Linux system, albeit on a stripped-down Linux system.

Below are some useful commands to run:

OS details

uname -a

Bash History

echo $HISTFILE

cat /root/.bash_history

If all fails:

find / -name ".bash_history"

Passwd Files

cat /etc/passwd

cat /etc/shadow

IR Collection Scripts Tested To Work

CatScale (takes a while to run):

 git clone https://github.com/WithSecureLabs/LinuxCatScale.git

cd LinuxCatScale

chmod +x Cat-Scale.sh

./Cat-Scale.sh

 Find based on time modification

 Review files based on key dates according to the timeline of compromise

 find / -[m|a|c]time [+-]n

Web Directory Review

cat /var/www/

Temp Folder

ls /tmp

USB Extraction of Files

If storage is getting low and you have physical access to the Switch then one method to extract the evidence while within the Linux kernel is to plug in a USB stick to the front of the Switch.

The USB stick must be FAT (FAT16) formatted. From testing we got a USB stick working when formatting the stick to use FAT16 and a primary partition of 4GB.

The USB stick should then be accessible as normal under /mnt within the Linux subsystem.

Resources & Credit

Cisco Talos – Active exploitation of Cisco IOS XE Software Web Management User Interface vulnerabilities

Cisco Talos – Weathering the storm

Cisco Advisory – CVE-2018-0171

Cisco Advisory – CVE-2024-20399

Cisco Advisory – CVE-2023-20198 + CVE-2023-20273

smokeintheshell

horizon3ai CVE-2023-20198 research
horizon3ai CVE-2023-20198 PoC
nuclei CVE-2023-20198 template 
LeakIX CVE-2023-20273 PoC