Exploiting CVE-2018-13379 – A Case Study of Threat Actors Exploiting Years Old CVEs

Introduction

This blog provides details into an attack investigated by Arista’s Awake Labs team, whereby initial access was achieved via a vulnerability in Fortinet FortiOS (CVE-2018-13379) first disclosed in July 2018, more than three years prior to this blog being published. In addition to our technical analysis of this attack we pose the question of whether vendors should take responsibility for automatically installing patches to versions of their platforms deployed within customer environments, especially when dealing with critical vulnerabilities.

Executive Summary

• Arista’s Awake Labs team responded to a cybersecurity incident involving one or more actors that had been active since at least January 2021.
• At least one of the attacks leveraged a critical vulnerability (CVE-2018-13379) in an external-facing Fortigate appliance to harvest Virtual Private Network (VPN) and Active Directory (AD) credentials, including some highly privileged domain administrator accounts.
• Persistence was achieved through newly created rogue domain accounts and scheduled tasks which launched Cobalt Strike Beacon.
• Lateral movement was achieved primarily using common tools such as Microsoft Remote Desktop (RDP) and PsExec.
• This write up also discusses:
  • the struggles some organizations have with legacy vulnerabilities that are exploited by threat actors;
  • monitoring for and patching well known critical vulnerabilities in the deployed technology stack;
  • monitoring / periodically auditing membership of privileged Active Directory groups;
  • the issues around having vendors be responsible for automatically patching critical flaws in their products after a certain time of exposure.

Understanding the Attack

In this post we break down several aspects of this threat and its actors, including:

• Industries and Geography
• Tactics and Techniques
• Investigation and Technical Analysis
• Indicators of Compromise (IOCs)
• Detecting the Techniques

Industries and Geographies

Awake’s analysis of this event shows that the threat actor(s) appears to have specifically targeted an organization which provides monitoring of critical infrastructure providers through a vast network of IoT devices in remote locations around the globe.

Geographic attribution details are scarce, but a brute-force username list and Cobalt Strike server hosting location suggests portions of the threat actors’ infrastructure are hosted out of Europe, in France and Netherlands.

Tactics and Techniques

Through the investigation, Awake identified several threat actor tactics and techniques across the MITRE ATT&CK Framework. These are detailed below.

The History of Legacy CVE-2018-13379

In incident response engagements, it is commonplace to see exploitation of vulnerabilities often disclosed over a year ago being used for initial entry into a network. This emphasizes the challenges some businesses have in managing security. The vulnerability associated with CVE-2018-13379 in particular is seen in many attacks and significant activity occurs even three years later. As a barometer of interest, the figure below represents the number of tweets per day, which is essentially all of the individuals talking about it and the media postings. It raises a question with so much public notification – should the vendor take on the responsibility to force-update customer devices for something so critical, within a certain time frame, to avoid the inevitable when a customer doesn’t take on the action? Would customers agree to this auto action? What are the potential legal and ethical issues involved? Would customers have an opt-out? Many of these questions have no easy answers.

https://cvestalker.com/cve.php?cve=CVE-2018-13379

Despite public advisories and forum discussions, vendor’s still failed to reach many of their customers. In April of 2020, months prior to initial access in the investigation outlined below, there was a public article stressing “it is increasingly important that organizations using any of these SSL VPNs ensure they’ve been appropriately patched”.

Almost exactly a year later, in April 2021, there is a more severe posting from the NSA on the vulnerability “The National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and the Federal Bureau of Investigation (FBI) jointly released a Cybersecurity Advisory, Russian SVR Targets U.S. and Allied Networks, today to expose ongoing Russian Foreign Intelligence Service (SVR) exploitation of five publicly known vulnerabilities.”

In June 2021, we see more postings, like this one, focusing on industries in the health sector. “Advanced persistent threat (APT) actors are continuing to exploit three, unpatched, critical vulnerabilities in certain Fortinet FortiOS devices to gain access to victims’ networks for nefarious activities, including data theft and data encryption, according to a recent FBI alert.”

It was at this time in June 2021, a few days into our incident response investigation, when Awake was able to obtain enough forensic information to identify CVE-2018-13379 as the initial access point for the attackers and recommend the patch. However, as recently as July 28th we see another cry out by the U.S government, “The U.S. government and its allies are pleading with defenders to pay attention to gaping holes in perimeter-type devices, warning that advanced threat actors are feasting on known security defects in VPN appliances, network product gateways and enterprise cloud applications.”

Knowing the criticality and the trend showing current exploitation more than 3 years after this announcement and many more alerts from the government, it is clear that organizations are ill informed and/or struggling to protect their own networks. This is not just an isolated event, this is a relatively common problem being exploited. Therefore, maybe there should be a line in the sand – such as a Metasploit module being released – where the vendor is now responsible to auto-patch customer equipment on their behalf.

This may seem like an intrusive solution, however in April this year, we saw the Department of Justice remove webshells on Microsoft Exchange servers in bulk: “The Justice Department today announced a court-authorized operation to copy and remove malicious web shells from hundreds of vulnerable computers in the United States running on-premises versions of Microsoft Exchange Server software used to provide enterprise-level e-mail service.” Although this example is slightly different – the action not actually being taken by the vendor, and being the removal of files as opposed to a patch, which may require reboots and downtime – it is a clear example of a third party reaching into the organization to solve a larger security issue affecting the community and globe as a whole.

Vendors would not need to reach in to organizations to accomplish forced-patching. Most (all?) modern hardware and software already ships with functionality to check for available updates and patches. Vendors could modify this functionality to mark a specific patch as Critical/Force-Update after a certain period of time or on-demand as the vendor. Customers could have the option to opt-out / disable these types of forced-patches at their own risk but then perhaps they could also be considered liable.

Why not opt-in?

The same organizations that are currently struggling to stay informed, or to assign resources to manage asset inventory and patching are also likely to leave most hardware and software defaults in place. To mitigate the risk for these customers, if no other action is taken, an opt-out approach would ensure that critical patches are applied when needed.

Incident Timeline and Technical Analysis

The incident was first detected around 153 days after the initial activity, when IT personnel spotted a rogue account with domain administrator privileges.

The earliest activity Awake identified was the execution of PC Hunter from the C:\PerfLogs directory on multiple hosts in the enterprise. Due to a lack of historical VPN, firewall, and host logging data, the Awake Labs team was unable to correlate the remote connection details from the early days of the incident. Instead, the initial access date comes from forensic artifacts recovered from the endpoints.

Figure 1 – Incident Timeline Summary

In total, the activity from the threat actor(s) continued for 158 days before containment. Figure 1 provides a summary of each major stage of the incident, while additional technical details are described below.

Initial Access

Initial access was gained through exploitation of a known vulnerability in FortiOS v5.6.7 build 1653. This version of FortiOS is vulnerable to a directory traversal attack (CVE-2018-13379) which allows remote, unauthenticated access to system files existing on the FortiGate appliance. One particularly sensitive file made accessible by this vulnerability is /dev/cmdb/sslvpn_websession. Successfully authenticated user credentials were saved, in plaintext, to this file. Any unauthenticated visitor could exploit the vulnerability to retrieve this file and collect plaintext credentials.

This CVE and attack were previously illustrated at DevCore (Figure 2).

Figure 2 – DevCore Screenshot of CVE-2018-13379

At the victim the Awake Labs team was engaged with, multi-factor authentication to the VPN was not configured. Therefore, these stolen credentials provided complete access to the SSL VPN and internal resources for the environment.

No Privilege Escalation Required

Awake’s analysis revealed an incident timeline in which the earliest execution of the threat actor toolset used compromised credentials of members of the domain administrator group.

Least privilege practices were not enforced and therefore some employees were using domain admin-level accounts to authenticate directly to the SSL VPN service. This combined with the FortiOS vulnerability mentioned above allowed the threat actor to harvest domain admin credentials during the initial access phase.

One Possible Attack Source

Windows Security Event Log events 4624 and 4625 Network Logon (Type 3) events contain the source workstation name of the authenticating user. In some cases, this reveals the threat actor’s source hostname.

In network logon events attributed to the threat actor(s), Awake identified 3 source workstation names. Two are Windows-generated (random) names similar to WIN-OI1BP7W3V81 and DESKTOP-011BATP, but the third was “Vultr-Guest” (Figure 3).

Figure 3 – Network Logon Source Host

The WIN- and DESKTOP- naming convention are the default for new Windows Server and Workstation deployments, respectively. The name Vultr-Guest is a default host name for endpoints at Vultr Hosting. This suggests the threat actor(s) were using ephemeral workstation and server instances from Vultr.

Lateral Movement, Execution, and Toolset

The primary method of access and lateral movement was through the VPN and Remote Desktop Protocol (RDP).

On each impacted system, the toolset was staged in C:\PerfLogs\ or on the Desktop.

The earliest artifact on the incident timeline is a single execution artifact of PC Hunter (C:\PerfLogs\PC Hunter (cr)\PC_H_n_cr_64.exe) found in UserAssist registry keys. Unfortunately, other logs and artifacts had rolled over or were otherwise unavailable to show the specific access methods in this time period.

Two months later, logs show remote access via RDP from the VPN IP range. The threat actor executed %USERPROFILE%\Desktop\netscan.exe (SHA256: c7d994eb2042633172bd8866c9f163be531444ce3126d5f340edd25cbdb473d4)

Four months into the incident, PsExec was run from a VPN source IP to create a scheduled task on domain controllers.

The scheduled task was named ‘TP’, set to Hidden so it would not appear in the Task Scheduler GUI, and created at C:\Windows\System32\Tasks\Microsoft\Windows\TPM\TP – which is an otherwise legitimate location for default scheduled tasks.

On boot, the task would execute PowerShell with an encoded command (Figure 4). Awake’s analysis revealed this command creates a Cobalt Strike service and begins beaconing.

Figure 4 – Cobalt Strike Scheduled Task

Figure 5 shows the decoded PowerShell script. There is a variable $var_code that holds a base64 encoded string. The decoded value is binary executable code injected into the memory of a running process to trigger the Cobalt Strike Beacon outbound.

Figure 5 – Scheduled Task Decoded

The Cobalt Strike shellcode was then injected into running svchost.exe processes.

Svchost.exe -k LocalSystemNetworkRestricted

Svchost.exe -k netsvcs

Awake further analyzed the binary executable code and extracted network indicators. Figure 6 shows an example:

Figure 6 – Cobalt Strike Beacon Hosts

Awake analyzed a memory dump of the injected svchost process and identified the following URL. The URI “jquery-3.6.0.min.js” indicated the malleable C2 profile selected for this particular Cobalt Strike beacon configuration (Figure 7).

hxxps://manageupdaternetwork[.]com:990/jquery-3.6.0.min.js?PHPSESSID=MLHCqQGI9ZkGiPeZB4U<redacted>

Figure 7 – Cobalt Strike Beacon Configuration

Even after the Cobalt Strike C2 channel was established, the threat actor(s) continued to access the system via VPN and RDP.

17 days after the C2 beacons were activated, the threat actor(s)used RDP to connect to workstations and servers throughout the environment for the purpose of harvesting credentials from memory using Mimikatz and the Password Recovery Tools set from NIRSoft.

Additional Tools

LadonGUI and GMER were each executed once on two distinct endpoints.

C:\PerfLogs\Ladon-master\LadonGUI.exe (SHA256: 783fff87a0ebe85d271e6b7680c1cbc14afdce6d419fa7e6c50e4a5897065df1 ) is a post-exploitation framework which facilitates additional host discovery and vulnerability scanning. It is compatible with Cobalt Strike. The purpose of using LadonGUI in the context of this intrusion is unclear.

Ladon and other tools are hosted from k8gege[.]org – where additional details are available (Figure 8).

Figure 8 – Ladon and Cobalt Strike

The source and compiled binaries are available on Github

C:\PerfLogs\5z2nmo8o.exe (GMER) (SHA256: e8a3e804a96c716a3e9b69195db6ffb0d33e2433af871e4d4e1eab3097237173) is a utility to scan for and terminate running processes, disable unwanted services, and scan for existing malware or rootkits (Figure 9). GMER was observed in the sborka5.zip toolset found during the Operation White Stork incident investigated by Awake Security.

Figure 9 – GMER Kill Process View

Conclusions and Recommendations

A critical (CVSS 9.8) pre-authentication vulnerability went unpatched for almost three years after the advisory and CVE were reported and despite a patch being available from the vendor. In fact, for more than a year prior a public exploit has been available within the Metasploit Framework. Of course some might say this is a unique situation. Unfortunately, this is not a one-off organization forgetting to patch a system. Asset inventory and patch management remains a challenge to all organizations across verticals and it is especially challenging for under-resourced security teams simply trying to understand what is deployed in their environment. Let alone then having to keep up with every advisory for every technology deployed.

Vendors of perimeter hardware and software can take responsibility for forced patching of vulnerabilities. Should they? And would customer’s approve?

In the case of a VPN gateway, patching may well require forced reboots or power-cycling which can certainly come at inconvenient times and cause short-term outages. That would seem however like an acceptable trade-off to avoid a potential million dollar ransom.

Prevention, Detection, and Containment Recommendations

Enterprise personnel increasingly work remotely and connect into corporate resources via VPN. These employees are not likely to be connecting to VPN from Cloud Hosting providers like Amazon AWS, Microsoft Azure, Google Cloud, or Vultr Hosting. Most of these providers publish a full list of their IP ranges. Awake recommends implementing firewall policies to block all that IP space from connecting to the external SSL VPN interfaces. Where there is a business need, explicit exceptions should be made.

Additional recommendations to prevent similar attacks:

• Enable and enforce multi-factor authentication on 100% of external access points and applications
• Understand your external-facing attack surface – yes all applications and systems whether remote access systems, IoT devices etc.
• Monitor for and patch critical vulnerabilities in that deployed technology stack
• Enforce a posture-check on all remote assets that require SSL VPN access – EDR/AV signatures are up to date, group policy is applied, etc.
• Centralize logging and ensure 6-month historical retention at a minimum. When an incident response investigation is needed, it is critical that the historical logs exist for analysis.

Threat Hunting Opportunities

Awake Security Platform

Attempted exploitation of of the Fortinet FortiOS vulnerability

Look for HTTP requests attempting to access the sslvpn_websession file

Unusual RDP Connections

Look for RDP connections coming from the internal VPN IP subnet, on days and times that fall outside of normal Business and/or Change Control hours.

Yara Scans

Yara signatures for Cobalt Strike are readily available on GitHub. The signature file apt_cobaltstrike.yar from JPCert matched this sample. Run this live with your EDR platform of choice, or against a memory dump using volatility

Example with Volatility:

Figure 10 – Memory Dump Analysis using Volatility

OSQuery or Daily Targeted Vulnerability Scan

Included in the Threat Actor toolset was a .reg file called enable_dump_pass.reg (SHA256: 23f8874584b16aa398dc068d111b09a7f7da52e1279c63ef8d4d169aa22e5661) – which sets the necessary configuration in place to allow a Windows host to begin storing credentials in memory and allow that memory to be dumped via Mimikatz.

If the Enterprise has group policies in place to set these registry keys explicitly according to best practice, a daily scan for changes in the following settings can help identify threat actor activity.

Indicators of Compromise (IOC)

Host-based IOCs

Other host-based IOCs:

Network IOCs

Detecting the Techniques

Contributors

Thanks to Jason Bevis for contributing to the research and blog post.