On the heels of RSA comes this month’s Below the Surface Threat Report. Our theme this month is “Time”. In the context of cyber warfare, cyber criminal attacks, and long-running espionage campaigns, it is time that serves as the ultimate advantage (or disadvantage) over an adversary. Both sides of the struggle are in a race. The blue team races to thwart the attacker’s objectives and their potential impacts to the mission, safety, uptime or revenue. The adversary on the other hand, has a bear on their back: eternally working to outpace the blue team’s next generation security stack; one that has become integrated, automated, and expanded via XDR. One that is better and faster at detecting and then interrupting an active attack. Both sides are in a race, and this race plays out across more than just the notional kill chain activities, but also in the realms of research, development, cooperation, software, firmware and hardware vulnerabilities, and in the human domains of endurance, focus, distraction, determination and persistence. Yet, how do we actively identify, baseline, and measure metrics related to time? With our playbooks? With our patching cadence for CISA’s KEVs or our CD (Coordinated Disclosure) timelines? It’s about how fast we can develop solutions vs. how fast cyber criminals develop malware, tooling, infrastructure and novel evasions.
One of the greatest myths in cyber security is that the adversary is more “sophisticated” or “advanced” than we are. They aren’t. They are simply quicker than our defenses. So it’s remarkable how little we focus on time itself, while the adversary continues to simply outpace us, instead of outsmarting us.
Real-World Examples
Why does the Iranian-backed Phosphorus group leverage spear-phishing to ascertain or influence the geo-location of targets they want kid-napped? Because it is the fastest way to organize that campaign and funnel on-the-ground resources to their targets. Put another way, it’s the quickest way to manifest kinetic/physical world objectives.
Why has the Conti core group of developers focused on low-level tactics to target the UEFI via BIOS write-enable vulnerabilities, or via the all-too-common and vulnerable Intel ME pathway? Because they know they can buy back precious time, and persist longer, by dipping underneath the entire rest of the security stack above. The adversary can out-pace, but they can ‘buy back’ time, too.
Why are newly-disclosed vulnerabilities targeted within hours of being disclosed? Why are there entire infrastructures already stood up to take advantage of these disclosures the moment they surface? Because both criminals and APTs know that the time advantage they have over blue team’s ability to assess, mitigate or patch is eternally in their favor, and that defenders are fixated more on efficacy and observables (of detection/blocking, etc.) than they are on speed and anticipation, respectively.
Why are attackers likely to take advantage of a new vulnerability in coreboot that allows for arbitrary code execution in SMM (System Management Mode)? Perhaps because researchers (ours, in fact) unveiled similar issues in 2017, including SMM not coming with write-protection enabled, giving attackers the greatest time advantage possible once exploited for persistence.
Why do adversaries leverage diversion, DDoS, and other tactics that lend to the ‘fog of war’ during an intrusion, or just prior to exfiltration? Obviously to divert resources but also to degrade confidence in the ability to make decisions quickly as a defender. Those delayed decisions buy back time. One of the greatest DFIR lessons during WannaCry, in both IT and OT environments alike, was that defenders did not have the tooling needed to identify devices, know who owned them, what their function/criticality was, whether they were vulnerable, etc. In essence, the device-level problem space was not captured by the victim orgs, and therefore both the automated worming elements as well as the hands-on keyboard activities of the threat actors (in certain target environments) were able to outpace defenders’ ability to identify, contain and eradicate the threat.
Look no further than PRC-backed hacking activity over the last two and half years as outlined in this CISA advisory. In it, we learn that these state actors are leveraging RouterSploit and RouterScan [T1595.002] to exploit no less than eight RCE (Remote Code Execution) vulnerabilities on six device manufacturers, four authentication bypass vulnerabilities on four vendors’ devices, as well as privilege escalation, injection and XML-related vulnerabilities on a total of ten popular manufacturers’ devices.
| Vendor | CVE | Vulnerability Type |
| Cisco | CVE-2018-0171 | Remote Code Execution |
| CVE-2019-15271 | RCE | |
| CVE-2019-1652 | RCE | |
| Citrix | CVE-2019-19781 | RCE |
| DrayTek | CVE-2020-8515 | RCE |
| D-Link | CVE-2019-16920 | RCE |
| Fortinet | CVE-2018-13382 | Authentication Bypass |
| MikroTik | CVE-2018-14847 | Authentication Bypass |
| Netgear | CVE-2017-6862 | RCE |
| Pulse | CVE-2019-11510 | Authentication Bypass |
| CVE-2021-22893 | RCE | |
| QNAP | CVE-2019-7192 | Privilege Elevation |
| CVE-2019-7193 | Remote Inject | |
| CVE-2019-7194 | XML Routing Detour Attack | |
| CVE-2019-7195 | XML Routing Detour Attack | |
| Zyxel | CVE-2020-29583 | Authentication Bypass |
Top network device CVEs exploited by PRC state-sponsored cyber actors via CISA
This in turn allows them to quickly gain access to credentials inside the organization via classic RADIUS and other AAA (Authentication, Authorization, and Accounting) services, and from there, double back to attack an even larger set of devices in order to configure them to do network boundary bridging [T1599], mirror [T1020.001], and exfiltrate traffic out of the victim environment. If this sounds like the same kind of network penetration testing we used to do in the late 90’s and early 2000’s…that’s because it is. Why? Because it is still the most efficient and quickest way to get into an organization, and get data out of it. Why does quickness matter? Because this set of APTs knows that device-level integrity monitoring, log-monitoring, and configuration management moves at a slower pace than what is needed to achieve attacker objectives. It’s not that organizations aren’t doing those things, it’s that they don’t have the tooling, resources, or discipline to continuously improve the cadence at which they monitor these controls. Yet, when many read the CISA advisory above, they may not be giving enough credence to statements like this, mentioned in the first two recommended mitigations:
- Keep systems and products updated and patched as soon as possible after patches are released [D3-SU] . Consider leveraging a centralized patch management system to automate and expedite the process.”
- Immediately remove or isolate suspected compromised devices from the network.
And while the subsequent twelve mitigations are of paramount importance, try giving them a read and simply appending “as fast as possible” to the end of each. Indeed “Sooner is better than perfect” applies to every one of them. How might you baseline, in time-based metrics, your organization’s ability to execute each of them, such that you can show that over time, your organization is getting faster at being able to do each? Focus on getting faster at making decisions that matter in time enough to matter, ahead of those impacts that stand to cause your organization the greatest harm.
As you read through the stories, advisories, and research below, take a moment to reflect on not whether your organization is prepared for them, but rather, how quickly those preparations, mitigations, patches, playbooks, and device management are being carried out.
If a picture is worth a thousand words, this video might be worth a million. In just sixty seconds, an attacker goes from the results of a simple SHODAN scan, to exploiting an RCE on an Internet-facing VPN appliance, and gaining root and a reverse shell from a Windows host on the internal network.
