07 April 2021

    Vulnerability in FortiGate VPN servers is exploited in Cring ransomware attacks

      In Q1 2021, threat actors conducted a series of attacks using the Cring ransomware. These attacks were mentioned in a Swisscom CSIRT tweet, but it remained unclear how the ransomware infects an organization’s network.

      An incident investigation conducted by Kaspersky ICS CERT experts at one of the attacked enterprises revealed that attacks of the Cring ransomware exploit a vulnerability in FortiGate VPN servers.

      Victims of these attacks include industrial enterprises in European countries. At least in one case, an attack of the ransomware resulted in a temporary shutdown of the industrial process due to servers used to control the industrial process becoming encrypted.

      In this paper, we discuss the results of our research and interesting aspects of the attack.

      It is worth noting that Fortinet has on several occasions warned users of its devices of the danger posed by the vulnerability and a high risk of attacks, including attacks by APT groups.

      Initial attack vector

      The attackers exploited the CVE-2018-13379 vulnerability in FortiGate VPN servers to gain access to the enterprise’s network.

      Unpatched FortiGate devices are vulnerable to a directory traversal attack, which allows an attacker to access system files on the FortiGate SSL VPN appliance. Specifically, an unauthenticated attacker can connect to the appliance through the internet and remotely access the file “sslvpn_websession”, which contains the username and password used to access VPN, stored in cleartext. The vulnerability affects devices that run FortiOS versions 6.0.0 to 6.0.4, 5.6.3 to 5.6.7, and 5.4.6 to 5.4.12.

      Several days before the start of the main attack phase, the attackers performed test connections to the VPN Gateway, apparently in order to check that the authentication credentials stolen in an attack on the VPN server could still be used.

      The attackers may have identified the vulnerable device themselves by scanning IP addresses. Alternatively, they may have bought a ready-made list containing IP addresses of vulnerable FortiGate VPN Gateway devices. In autumn 2020, an offer to buy a database of such devices appeared on a dark web forum.

      Message on a dark web forum with an offer to buy a database of vulnerable devices

      Lateral movement

      After gaining access to the first system on the enterprise network, the attackers downloaded the Mimikatz utility to that system. The utility was used to steal the account credentials of Windows users who had previously logged in to the compromised system.

      With the help of the Mimikatz utility, the attackers were able to compromise the domain administrator account, after which they started distributing malware to other systems on the organization’s network. They used the Cobalt Strike framework for that purpose. The Cobalt Strike module was loaded on attacked systems using the PowerShell.

      Fragment of a PowerShell script downloaded to an attacked system

      After launching, the malicious PowerShell script decrypted the payload – the Cobalt Strike Beacon backdoor, which provided the attackers with remote control of the infected system.

      The IP address 198.12.112[.]204 was specified as the Cobalt Strike Beacon command-and-control server.

      Fragment of decrypted code from the Cobalt Strike payload


      After gaining control of the infected system, the attackers downloaded a cmd script to the machine. The script was designed to download and launch the malware – the Cring ransomware.

      The script was saved to the following path: %TEMP%\execute.bat (e.g., C:\Windows\Temp\execute.bat).

      Malicious cmd script

      After being installed on the system, the cmd script named execute.bat was executed. The script launched PowerShell under the name “kaspersky”. The attackers used this technique to mask the traces of the malware activity and disguise the operation of the malware as that of security solutions. A command to download a file from the internet was passed to the running PowerShell shell. The file’s URL was http://45.67.231[.]128/ip.txt. The downloaded file was saved as C:\__output.

      Although the file specified in the URL had the extension .txt, it was in fact the executable file of the malware – the Cring ransomware. At the time of analyzing the malware hosting server, the file ip.txt had already been removed, but the attackers had uploaded a newer version of the Cring malware (the file NoNet.txt) to the server.

      Contents of the malware hosting server used in the attack

      To be able to encrypt database files and remove backup copies, the Cring malware stoped the services of the following programs:

      • Veritas NetBackup: BMR Boot Service, NetBackup BMR MTFTP Service
      • Microsoft SQL server: SQLTELEMETRY, SQLTELEMETRY$ECWDB2, SQLWriter

      The SstpSvc service, which is used to create VPN connections, was also stopped. It is most likely that the attackers, who at this stage controlled the infected system via Cobalt Strike, did this to make it impossible to connect to the infected system remotely via VPN. This was done to prevent system administrators from providing a timely response to the information security incident.

      Additionally, the malware terminated the following applications’ processes in order to encrypt files without hindrance:

      • Microsoft Office: mspub.exe
      • Oracle Database software: mydesktopqos.exe, mydesktopservice.exe

      The malware removed backup files that had the following extensions: .VHD, .bac, .bak, .wbcat, .bkf, .set, .win, and .dsk. It also removed files and folders located in the root folder of the drive if their names started with the word “Backup” or “backup”.

      To perform these operations, the malware created a cmd script named kill.bat on the drive, which deleted itself after execution.

      Code of the kill.bat script

      Next, the malware started to encrypt files using strong encryption algorithms, which means that files could not be decrypted without knowing the RSA private key held by the attackers. Each file was encrypted using AES and the AES encryption key was in turn encrypted using an RSA public key hard-coded into the malicious program’s executable file. The RSA key size was 8,192 bits.

      Files with the following extensions were encrypted:

      • .vhdx (Virtual Hard Disk)
      • .ndf (Microsoft SQL Server secondary database)
      • .wk (Lotus 1-2-3 spreadsheet)
      • .xlsx (Microsoft Excel spreadsheet)
      • .txt (text document)
      • .doc (Microsoft Word document)
      • .docx (Microsoft Word document)
      • .xls (Microsoft Excel spreadsheet)
      • .mdb (Microsoft Access database)
      • .mdf (disk image)
      • .sql (saved SQL query)
      • .bak (backup file)
      • .ora (Oracle database)
      • .pdf (PDF document)
      • .ppt (Microsoft PowerPoint presentation)
      • .pptx (Microsoft PowerPoint presentation)
      • .dbf (dBASE database management file)
      • .zip (archive)
      • .rar (archive)
      • .aspx (ASP.NET webpage)
      • .php (PHP webpage)
      • .jsp (Java webpage)
      • .bkf (backup created by Microsoft Windows Backup Utility)
      • .csv (Microsoft Excel spreadsheet)

      Upon completing file encryption, the malware dropped the following ransom note:

      Ransom note

      The ransom note was saved in the file !!!!WrReadMe!!!.rtf.


      Various details of the attack indicate that the attackers had carefully analyzed the infrastructure of the attacked organization and prepared their own infrastructure and toolset based on the information collected at the reconnaissance stage.

      For example, the malware hosting server (45.67.231[.]128) from which the Cring ransomware was downloaded had filtration by IP address enabled and only responded to requests from several European countries.

      The attackers’ cmd scripts disguised the activity of the malware as the operation of the antivirus solution (Kaspersky) used by the enterprise and terminated the processes of database servers (Microsoft SQL Server) and backup systems (Veeam) that were used on systems selected for encryption.

      An analysis of the attackers’ activity demonstrates that, based on the results of reconnaissance performed on the attacked organization’s network, they chose to encrypt those servers the loss of which the attackers believed would cause the greatest damage to the enterprise’s operations.

      Causes of the incident

      It is worth highlighting a number of reasons that contributed to the information security incident investigated by the Kaspersky ICS CERT team or directly led to it.

      The primary causes of the incident include the use of an outdated and vulnerable firmware version on the FortiGate VPN server (version 6.0.2 was used at the time of the attack), which enabled the attackers to exploit the CVE-2018-13379 vulnerability and gain access to the enterprise network.

      The lack of timely antivirus database updates for the security solution used on attacked systems also played a key role, preventing the solution from detecting and blocking the threat. It should also be noted that some components of the antivirus solution were disabled, further reducing the quality of protection.

      Other factors contributing to the incident’s development included the user account privilege settings configured in domain policies and the parameteres of RDP access.

      There were no restrictions on access to different systems. In other words, all users were allowed to access all systems. Such settings help attackers to distribute malware on the enterprise network much more quickly, since successfully compromising just one user account provides them with access to numerous systems.

      Attack workflow


      1. Keep the VPN Gateway firmware and endpoint security solutions updated to the latest versions.
      2. Keep antimalware databases updated to the latest versions.
      3. Check that all components of endpoint security solutions are enabled.
      4. Make sure that the Active Directory policy allows users to log in only to those systems which are required by their operational needs.
      5. Restrict network connections, specifically VPN connections, between hosts on the industrial network, block connections on all ports that are not required by the industrial process.
      6. Configure the backup system to store backup copies on a dedicated server.
      7. To further enhance your organization’s resilience to possible ransomware attacks, consider implementing Endpoint Detection and Response type security solutions both on your IT and OT networks.
      8. Adapting Managed Detection and Response services to get immediate access to high-level security professionals’ knowledge and expertise may also be a good idea.
      9. Use dedicated protection for the industrial process. Kaspersky Industrial CyberSecurity protects industrial endpoints and enables OT network monitoring to identify and block malicious activity.

      Indicators of compromise (IOC)

      File path
      • %temp%\execute.bat (downloader script)
      • C:__output (Cring executable)
      • c5d712f82d5d37bb284acd4468ab3533 (Cring executable)
      • 317098d8e21fa4e52c1162fb24ba10ae (Cring executable)
      • 44d5c28b36807c69104969f5fed6f63f (downloader script)
      IP addresses
      • 129.227.156[.]216 (used by the threat actor during the attack)
      • 129.227.156[.]214 (used by the threat actor during the attack)
      • 198.12.112[.]204 (Cobalt Strike CnC)
      • 45.67.231[.]128 (malware hosting)