Man-in-the-Network: Network Devices are Endpoints too
Networking devices as endpoints are often forgotten by the information security community. The majority are focused on protecting systems and detecting threats in a Windows domain environment. Some expand their operation to include the macOS and Linux endpoints. This is not in reference to capturing network traffic, NetFlow, or running an IDS.
Common logging tools to assist in those endeavors are Sysmon for windows, Auditd, and Auditbeat for Linux and macOS. For the networking side, network traffic will be analyzed with a NIDS like Snort or Suricata, and possible protocol parsed with tools like Zeek, and PCAP will be saved for analysis later.
All of this data is then typically centralized to a log analysis tool like ELK or Splunk where analysts run search queries or analytics to detect adversary actions in their environments. The MITRE ATT&CK framework provides a good starting point to measure and mold what techniques your analysts should attempt to detect in the data, based on what an adversary might do in each step of the kill chain. Read more on the MITRE ATT&CK Framework here.
What the Enterprise ATT&CK matrix doesn’t cover are the networking devices themselves and tactics and techniques an adversary might perform on such devices. One might say that this attack surface is small and not a plausible target, but I would disagree. Network devices will generally account for 10–20% of the devices in a network that is ~75–90% Windows and 1–3% Linux. That’s including routers, switches, firewalls, VPN concentrators, wireless access points, wireless LAN controllers, et cetera.
These devices have CVE’s just like Windows, Linux, and macOS — high vulnerabilities that give a “system” or “root” like access (Level 15). They are patched less often by the administrators. The patching is not as automated as a Linux yum/apt command or as simple as an SCCM/WSUS server. The network infrastructure devices are also almost always older as they are replaced much less often and fall out of support by the vendor. They often have default credentials that don’t get changed, and insecure configurations, like Web GUIs, left enabled. A potential adversary could take advantage of these misconfigurations and vulnerabilities.
These devices provide more than network traffic to be analyzed. Just like Linux Syslog, they too have logs that can be forwarded to a SIEM. Syslog is a good start; be this isn’t about a “Network Operations Center” this is about a “Security Operations Center”. Syslog can be useful, and you’ll find interesting artifacts in the warning, error, and debug levels, but those logs will mostly be about the operation the device is performing.
Most modern network devices you’ll have deployed in your enterprise support remote logging. Cisco, Brocade, Juniper, Dell, et cetera — all support TACACS or RADIUS for AAA. “Triple-A” is Authentication, Authorization, and Accounting. When turned on across all of your networking endpoints, it gives you visibility into what’s occurring on those devices. Is that Administrator adding a local user? Analyzing these logs using MITRE ATT&CK’s model will help you detect whether or not the actions being taken on your network infrastructure are legitimate or not.
Currently, the MITRE ATT&CK model does not classify network devices and their operating systems as a “Platform”. And only one “Technique” references “Network Device Logging” as a data source. The analytics you would need for detection rely upon network device logs, specifically the Authentication and Accounting logs of AAA. Authorization would be primarily used for mitigation and ensuring your network administrator accounts have the least privilege necessary to perform their functions.
Out of the current 244 Enterprise ATT&CK Techniques, I believe that 64 of them can apply to Network Devices. Using AAA, Netflow, IDS, and Syslog you will be able to detect the majority of what is occurring on your networking devices, whether its legitimate administration or nefarious activity.
The U.S. CERT says:
Russian cyber actors leverage a number of legacy or weak protocols and service ports associated with network administration activities. Cyber actors use these weaknesses to: identify vulnerable devices; extract device configurations; map internal network architectures; harvest login credentials; masquerade as privileged users; modify device firmware, operating systems, configurations; and copy or redirect victim traffic through Russian cyber-actor-controlled infrastructure. Additionally, Russian cyber actors could potentially modify or deny traffic traversing through the router.
You may ask who is targeting networking devices, and when they do what kind of actions are they taking? The US Cert advises that routers and switches are being targeted:
https://www.us-cert.gov/ncas/alerts/TA16-250A
https://www.us-cert.gov/ncas/alerts/TA18-106A
APTs and Malware that target network devices:
· SYNful Knock — A cisco router implant https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.html
· Dragonfly 2.0 / Berserk Bear https://www.darkreading.com/endpoint/privacy/russian-apt-compromised-cisco-router-in-energy-sector-attacks/d/d-id/1331306
· Gekko Jackal — Activist Group https://go.crowdstrike.com/rs/281-OBQ-266/images/15GlobalThreatReport.pdf
· Symantec — Hacking routers 101 https://www.symantec.com/connect/articles/exploiting-cisco-routers-part-1
Data Sources:
Currently, MITRE has one data source called Network Device Logs, without much information out there about it, save one Technique that can currently use it. I would propose these network device logging categories:
- Network Device (System) Logs — via Syslog protocol
- AAA logs — via TACACS or RADIUS protocol
The below image is a layer from the ATT&CK Navigator the represents all of the Techniques that would apply to Network Devices, color-coded by data source you can use to detect it. The “Accounting” data source (in blue), is further broken down into confidence levels High, Medium, and Low to denote how easy it would be to determine if the actions are a legitimate Administrator action or an adversary.
Analytics:
I have written 12 “Sigma” analytics using the “Accounting” data source of AAA from the networking devices. Yes, a lot of these actions performed on a networking device are done by administrators, but there are ways to reduce the false-positive rate. Baseline what network admins are doing on their systems regularly: who typically performs the function, and when. By enabling the rules, watching, and documenting common behavior, you’ll be able to tweak your analytics to alert less often.
Read about the Sigma project (Generic Signature Format for SIEM Systems) here!
A few things to note about the analytics. It is common in networking operating systems that you can shorten a command and it will still run, for example, “show history all” can be shortened to “s hi a” and still give the same results. However, when logging with AAA, TACACS will log the full intended command. Therefore, when writing detection analytics for certain commands being run, only the full command must be accounted for. Also when the | (pipe) command is used with “include” to filter the results, that is not shown in the AAA Accounting logs, | only filters what is being shown to the terminal output.
Mitigation:
Most of the mitigations already listed on the MITRE ATT&CK wiki are also applicable to networking devices in a generic sense. But overall the main mitigation not listed that applies solely to network operating systems is when applying AAA, the authorization aspect of only giving limited user privilege level access is imperative. An enterprise policy can even constrain what commands administrators are allowed to run.
Segment the network devices on different VLANs, configure the devices securely following best business practices, change default credentials, patch appropriately, apply least privilege concepts, enable remote logging, and follow the NIST governance framework.
Overview of the 12 Tactics in the Enterprise matrix as they could apply to network devices:
Initial access
Four techniques associated with networking devices — the two primaries being, exploit a vulnerability or use stolen credentials to log in remotely. The network infrastructure will most likely not be the initial access vector into a network, but it does provide an attack surface for an attacker to target after they have a foothold inside.
Execution
Two main vectors, the adversary is either using the command line or the GUI if there is one and it’s been enabled. Use the accounting logs to see what’s being executed.
Persistence
Just like a Windows or Linux machine the adversary could create a new account, schedule a job, use a valid account, or even replace the firmware (as was the case with the SYNful Knock malware).
Defense Evasion
It would be trivial for an adversary to clear command history or even turn off remote logging with the right level of access. That’s why alerting on those analytics should be of high confidence and priority. Train your admins not to do these functions to lower the false positive rate.
Credential Access
Similar to Persistence, credentials can be recovered from looking at the history (contains plaintext passwords), looking at files (old configs) saved on the device, or even packet sniffing on the device itself.
Discovery
These are commands a normal admin may run, the point of creating and seeing how often they use these commands allows you to create a custom baseline. Maybe some commands are never used and can become a more useful alert. Look for common times that your admins may perform these functions or if it’s always the same people. Then tailor the alerts for your environment.
Lateral Movement
Copying files between devices using SCP, TFTP, or FTP are common.
Collection
The configuration of a network device provides a lot of information about a network, to include keys and passwords that an adversary would want to collect.
Command and Control
A web service and commonly used port can be used to communicate to a C2 server owned by the adversary in their cloud infrastructure.
Exfiltration
Data can be easily exported via file transfer or over a common port or even copy-pasted out!
Impact
The impact is the most applicable to the network devices because they can affect large portions of your network. ACLs can be emplaced on the devices to drop or degrade traffic. Configurations can be wiped, and devices rebooted which would DOS the network. Configurations can be modified, file systems wiped, files deleted, overwriting firmware, et cetera. All of which can be detrimental to the device and/or the network.
Techniques:
Review the break-down of each of the 64 ATT&CK techniques I think apply to network devices on my GitHub here! It details the technique, the data source, an example network device command (if applicable), and my comments on why I believe it applies.
