In several recent incident response missions, the Truesec CSIRT team made forensic observations indicating that the old vulnerability CVE-2020-3259 is likely to be actively exploited by the Akira ransomware group.
Truesec platform customers can already read the related threat notice in the Truesec portal.
Indications of Akira Ransomware Group Actively Exploiting Cisco Anyconnect CVE-2020-3259
During the past weeks, the Truesec CSIRT team found forensic data indicating that the Akira Ransomware group might be actively exploiting an old Cisco ASA (Adaptive Security Appliance) and FTD (Firepower Threat Defence) vulnerability tracked as CVE-2020-3259. The vulnerability was disclosed on May 6, 2020, and enables an unauthenticated, remote attacker to extract sensitive memory contents from an affected device. This means that username and passwords can be retrieved from the memory in clear text.
An analysis of the eight latest incident response missions conducted by Truesec, where Akira ransomware had been deployed, and the Cisco Anyconnect SSL VPN was confirmed as the entry point, showed that at least six of the compromised devices were running different versions of the vulnerable software (while for the remaining two, no sufficient data was available to determine with certainty whether the device was vulnerable to CVE-2020-3259).
Technical details and some of the forensic data supporting the indications of CVE-2020-3259 being actively exploited are presented later in this article.
Affected Cisco Systems Devices
For this vulnerability to be exploitable, the device with the vulnerable software needs to have Anyconnect SSL VPN enabled on the interface exposed to the attacker (normally, this is the internet-facing interface of the firewall). More specifically, the following configuration should be in place.
| Device Type | Configuration Enabling the Vulnerability |
| Cisco ASA/FTD | crypto ikev2 enable client-services <port> |
| Cisco ASA/FTD | webvpn enable |
More information can be found in the Cisco advisory [1].
Recommendations to Organizations Using Cisco Anyconnect
When the vulnerability was made public in 2020, no known public exploits were available. However, there are now indications that this vulnerability might be actively exploited.
If your organization is running Cisco Anyconnect, and assuming the device has been patched since a fix for CVE-2020-3259 was available, it is highly recommended that you backtrack when your device was upgraded to a non-vulnerable version. This is important as it is not possible to determine for how long this vulnerability has been exploited. For instance, if your backtracking shows that your devices were upgraded 6 months ago, then it is sound to consider any username and password used for the Anyconnect SSL VPN that has not changed in the last 6 months as compromised. A broad password reset is, therefore, highly recommended.
Furthermore, any other secrets (i.e., local accounts) or pre-shared keys in the configuration of the device should also be considered compromised and should be changed.
To summarize the recommendations:
- Implement MFA on all accounts and services where it is possible, especially for Client VPN connections.
- Enforce a password change, especially if there are accounts in the environment that have not changed password after the version upgrade.
- Change secrets and pre-shared keys in device configurations if they have not been changed after the version upgrade.
- Patch to a non-vulnerable version if not already done.
- Ensure logging is enabled.
If your SSL VPN solution had MFA enabled during the vulnerable period, it is still highly recommended that you enforce a password change, as valid usernames and password combinations can still be compromised and used in other attack vectors. If you suspect that you might have been compromised, ensure that a thorough investigation is performed.
Origins of CVE-2020-3259
The vulnerability CVE-2020-3259 was discovered by the Russian company Positive Technologies [2] and was publicly disclosed in May 2020. One year later, in April 2021, Positive Technologies was put under US sanctions by the US Treasury [3] as the Russian company was supporting Russian activities through the Russian Intelligence Services, namely the FSB, with security solutions and recruitment activities. There is no publicly available exploit code for the vulnerability found by Positive Technologies, CVE-2020-3259, meaning that a threat actor, such as Akira, exploiting that vulnerability would need to buy or produce exploit code themselves, which requires deep insights into the vulnerability.
Akira is likely an offshoot from the now-defunct Conti ransomware syndicate that is known to have had ties to the FSB.
Truesec is not in any way suggesting that the actions of Akira should be attributed to Russian intelligence services, however, we assess that the result of Russian offensive security research is likely to end up in the hands of both nation state and cybercriminal actors, putting high stress on western defenses and societies.
Technical details
During the past year, the Truesec CSIRT team has responded to several incidents in which the Akira ransomware group used Cisco Anyconnect-based VPN as their initial access vector. This has been written about earlier [4].
In most of these cases, the network forensics have been highly limited as network-related logs are generally non-existent in many environments. Many times, the network-related artifacts have been merely enough to undoubtedly deem the Anyconnect solution as the initial access vector.
However, during the last weeks, the Truesec CSIRT team responded to an incident in which more than 6 months of Radius authentication logs from an NPS server were successfully restored. The analysis of the Radius logs revealed a pattern in the treat actor activities related to the multiple accounts that they had successfully compromised. Furthermore, the analysis showed that the first malicious authentication (i.e., logons from threat actor-controlled IP addresses) with all the compromised accounts was preceded by a legitimate authentication from the real user of the same (later compromised) account. This indicates that when the threat actor logged in with an account for the first time, the real user had just recently logged in with the same account. The next figure shows the Radius authentication logs for the three first accounts compromised by the threat actor.
Now, this pattern by itself does not indicate that an exploit has been used. However, the following observations were also made during the investigation.
- At least eight different accounts were compromised. However, the threat actor only used two accounts for lateral movement.
- The compromise of accounts with distinct usernames not following a clear naming convention.
- All compromised accounts had unique passwords, meaning the threat actor must have had access to eight different passwords.
- The investigation did not show any signs of recent phishing campaigns targeting the organization.
- The radius log analysis did not show signs of password attacks against the SSL VPN service (i.e., password spray or brute force attacks).
- The investigation did not find any credentials up for sale on the Darknet.
To investigate what type of information a successful exploit of a vulnerable device would disclose, a “coredump” (memory snapshot) of a vulnerable ASA firewall was generated. For the purpose of testing, two different AD accounts were used to log on to the Anyconnect SSL VPN service using the Anyconnect client software. The authentication method configured was Radius with the Active Directory as the identity database.
In the test scenario, a successful connection was made with the first user, and then the connection was terminated. A new connection was made with the second user, and the coredump was generated while the second connection was still active.
The coredump file was then examined to determine its contents and, ultimately, the content that might be exposed to an attacker exploiting the vulnerability. As shown in the figure below, the memory contains the cleartext version of the username and the password of both connections.
The red box in the figure above shows the first account (disconnected session) used in the test, and the green box shows the second account (active session).
It should be noted that the contents of the memory dump of the device are probably more revealing than the memory content accessed through an exploit. It is, however not possible at this time to determine what an unauthorized attacker has accessed through the exploit. It is also common modus operandi that an attacker exploits the same device multiple times, giving them access to different parts of memory content.
We want to thank Antonio Monaca, Solution Architect at SentinelOne, for bringing CVE-2020-3259 to our attention as a candidate vulnerability to analyze.
References
[3] https://home.treasury.gov/news/press-releases/jy0127
[4] https://www.truesec.com/hub/blog/a-victim-of-akira-ransomware