dimly lit close up of laptop with user typing on keyboard, green text on black background on computer screen
  • Insight
  • 7 min read

Finding Akira’s exploit for CVE-202-3259 and detecting vulnerable devices

Akira and Cisco AnyConnect: The Working Exploit for CVE-2020-3259

In a previous blogpost the likelihood of Akira ransomware group using an old vulnerability in Cisco ASA and FDT devices, tracked as CVE-2020-3259 was discussed. Since then, CISA has added it to their KEV (Known Exploited Vulnerabilities) catalog and issued an advisory related to the TTPs of the Akira ransom group.

In a recent incident response mission, the Truesec CSIRT found clear evidence that Akira has a working exploit for the vulnerability.

Finding the Exploit

In early March, the Truesec CSIRT was engaged in an incident response mission involving the deployment of the Akira ransomware. The affected environment, though relatively small, resembled others seen in Akira-related incidents: A Cisco ASA firewall serving as perimeter protection, with Cisco AnyConnect SSL VPN enabled. Authentication for the VPN users was managed through a Microsoft NPS (Network Policy Server) RADIUS server, without Multi-Factor Authentication (MFA) enabled for the few users of the VPN service.

Fortunately, the NPS RADIUS server retained logs spanning six months, enabling thorough analysis. Examination of the logs revealed the same pattern consistent with what was shown in the previously mentioned blog post, raising suspicions of an exploit being executed. The table in the figure below illustrates the occurrence of malicious logins compared to legitimate logins for the compromised VPN accounts associated with the Akira ransom group. Additionally, it highlights the onset of malicious activities such as network scanning, lateral movement, and encryption, which commenced more than two months after the initial malicious login by the threat actor.

Another fortunate circumstance in this ransomware nightmare was that the victim organization did not disturb the crime scene, ensuring that the ASA firewall remained intact and operational. This provided a unique opportunity to force a core dump of the ASA firewall, allowing for an in-depth examination of the device’s memory for any traces of potential exploits.

During the analysis of the core dump, 582 instances of suspicious HTTP GET requests were observed. To verify that these requests were related to the suspected exploit, tests were conducted in a controlled lab environment using a Cisco ASA with AnyConnect SSL VPN enabled, running a software version vulnerable to CVE-2020-3259. The results confirmed that the observed HTTP GET requests indeed exploited the information disclosure vulnerability identified as CVE-2020-3259. The significant number of HTTP GET requests suggested that the threat actor had exploited the ASA device multiple times during their attack campaign.

The figure below illustrates the contents of the memory retrieved from the vulnerable ASA device when it was exploited. Among the random characters, the username ‘nalnil‘ and the corresponding password ‘shj73!#/(nxhH?‘ are observable. It’s worth noting that a complex password was deliberately chosen for this test account to highlight the vulnerability’s capability to compromise passwords regardless of their complexity.

This type of information might be hard to identify if you don’t know what you are looking for, but just by using the Linux “strings” command utility, the output will become easier to search, as demonstrated in the figure below.

However, it should be noted that there are other methods to extract the username and password automatically and more accurately from the response received. These methods will be discussed further in an upcoming blog post.

In the controlled lab environment, the Cisco ASA device was configured with the following authentication methods:

  1. Local (ASA local account database)
  2. RADIUS authentication (RADIUS server using the Active Directory as the user database)
  3. LDAP authentication (The ASA queried the Active Directory directly)

The tests showed that it was possible to retrieve clear text versions of credentials for recently connected VPN users using any of the authentication methods listed above.

Note: SAML authentication will also be tested, and this blog post will be updated with the results

The Detection

Every time a new (or old) vulnerability is disclosed, cybersecurity practitioners are confronted with questions like:

  • How many vulnerable devices are there?
  • Is it possible to detect the vulnerable devices?

While running an exploit against a vulnerable device is the most direct method of detection, it is also unethical and illegal. Therefore, non-intrusive detection methods are necessary.

Based on the functionality of the exploit and extensive testing in a lab environment, a simple, non-intrusive detection script was developed. This script leverages publicly available data from scanner services such as ‘shodan.io‘ and ‘censys.io‘, along with HTTP GET requests to public URLs associated with the SSL VPN service on Cisco ASA devices. By analyzing the gathered information, the script can determine whether a device is vulnerable or not.

The table below shows the results of sample scans conducted to identify vulnerable devices in selected regions, including the Nordic countries (Sweden, Denmark, Finland, and Norway), Germany, and the USA. These scans revealed a total of 14,569 vulnerable devices across these six countries alone.

CountryDiscovered DevicesVulnerable DevicesVulnerable Devices
Number of vulnerable devices in relation to discovered devices for the Nordic countries and the US.

The detection script, due to its non-intrusive nature, is unable to detect all vulnerable devices. Approximately 5-10% of the exposed vulnerable devices are estimated to remain undetected, meaning that there are more vulnerable Cisco ASA firewalls exposed to the Internet than detected by the script.

The numbers presented in the table above reflect scans conducted from the end of March to the beginning of April. Since then, Truesec has engaged with several affected organizations, many of which promptly mitigated the vulnerability by either disabling the AnyConnect SSL VPN or upgrading their devices. Additionally, Truesec has collaborated closely with CISA and authorities in various countries to raise awareness of the significant number of vulnerable ASA devices and emphasize the urgency of addressing the issue among key organizations. It is, therefore, important to note that the number of vulnerable devices may vary if a scan were to be conducted today.

Given the high number of vulnerable devices and the negative impact a successful exploitation has, Truesec made an early decision to refrain from publicly releasing the exploit. However, it’s critical for affected organizations to take immediate action to mitigate this vulnerability, as there are working exploits currently available on the internet. This underscores the urgent need for proactive measures to safeguard against potential attacks, particularly as this attack vector is no longer limited to the Akira ransom group and its affiliates.