Threat analysis: Pysa (Mespinoza) ransomware
- Pysa is the newest variant of Mespinoza ransomware — it encrypts files and appends the .pysa filename extension
- Pysa was first seen in December 2019, while its precursor Mespinoza appeared in October 2019
- Pysa uses the cryptographic library Сrypto++ to encrypt victims’ files with a combination of RSA-4096 and AES-256-CFB
- Persistence techniques pop up the ransom note at logon
Distribution and attack vector
Pysa takes an approach commonly referred to as “big game hunting,” meaning that the ransomware group targets high-value assets in organizations that are particularly sensitive to data loss or system downtime. The idea is that victims — which may include healthcare providers, government agencies, and managed service providers — are more likely to quickly pay the ransom, regardless of its cost.
Pysa is an example of human-operated ransomware, in contrast with more automated threats like WannaCry or Petya. It’s typically distributed via brute-force attacks on servers in which RDP or AD is exposed to the internet. Attackers then exfiltrate the organization’s credentials database. PowerShell and Batch scripts attempt to stop — or even uninstall — antivirus solutions. There are currently 46 organizations known to have been targeted by the Pysa ransomware, with victims in France, Australia, and the USA.
Once executed, Pysa performs the following actions:
- Creates a mutex named “Pysa” to check whether another instance of Pysa ransomware has already run If the “Pysa” mutex already exists, the malware finishes its execution without encrypting. This prevents double encryption of the user’s files
- Creates two threads for encryption
- Uses a persistence technique — adding a reference to the system registry — to open the ransom note every time the system boots up
- Deletes its executables by dropping a .bat file
Pysa uses the Crypto++ library instead of the more common Microsoft CryptoAPI.
AES symmetric cipher is used for file encryption in cipher feedback (CFB) mode. CFB mode is a close relative of cipher block chaining (CBC) and makes a block cipher into a self-synchronizing stream cipher. CFB shares two advantages over CBC mode with the stream cipher modes OFB and CTR: the block cipher is only ever used in the encrypting direction, and the message does not need to be padded to a multiple of the cipher block size.
Before starting the encryption process, Pysa calls the SinkArray() function twice per file, generating a 256-bit AES key and IV for each.
Pysa then imports the embedded master public RSA-4096 key using Crypto++ interfaces, such as RSAFunction() and x509PublicKey(). After that, it encrypts each file’s key and IV with the master key.
After generating the unique key and IV, Pysa divides up files and directories for encryption according to the allowlist and denylist hardcoded in the ransomware body. The allowlist includes vital directories, such as Windows and Boot, as encrypting these would make recovery via the attackers’ decryptor impossible. Also included are any files with the .README, .exe, .dll, .search-ms, .sys, and .pysa extensions.
1Pysa's allowlist of directories skipped during encryption.
The denylist contains the SQL directory, as well as any files with the following extensions:
Files and folders that aren’t specified on either list are automatically added to the blacklist and marked for encryption.
Encrypted files are appended with the .pysa extension. An encrypted folder might look like this:
Pysa adds the encrypted AES-256-CFB key and IV (800 bytes in size) to the file footer.
Finally, Pysa drops the ransom note in every directory, except for those on the allowlist.
Pysa’s ransom note reads as follows:
To keep showing the ransom note even after system reboot, the ransomware uses the LegalNoticeCaption and LegalNoticeText values in the system registry, which normally contain the title and body of the legal notice displayed to users at logon.
To do so, Pysa first opens the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System registry key.
It then creates a value of “legalnoticetext” with the contents of the ransom note.
Next, it creates a “legalnoticecaption” key with the value “PYSA”.
After the registry modifications, the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System key looks as follows:
Upon reboot of the infected system, the following message will appear:
The last step that Pysa takes is self-deletion. It creates an update.bat file in the %TEMP% directory. The batch script’s template is found in the ransomware code:
After deriving the remaining parameters, the malicious executable, its directory, and the batch file are deleted:
When Pysa was distributed as “Mespinoza,” it was often difficult to identify which ransomware variant had infected the system — the .locked extension has been widely used by ransomware writers, and the executable was deleted from the infected system after the attack.
Pysa’s operators have moved forward in this regard to create their own identity, and refuse to offer decryption services over Tor as a part of an RaaS model. Instead, they’ve simplified the extortion process to adjust it to the targeted attack scenario. Communication is done simply through the email accounts indicated in the ransom note. The encryption model implementation is bulletproof and unique, as is the new ransom note persistence mechanism via the system registry key.
Whether you’re a home user, business, or service provider, Acronis’s cyber protection solutions can safeguard your systems against Pysa and other modern ransomware variants. An advanced integration of data protection and cyber security — powered by Acronis Active Protection’s AI-driven behavioral heuristics — actively protects critical data and applications across entire workloads, stopping ransomware and other cyberthreats in their tracks.
Content of update.bat
Content of the ransom note
Embedded RSA key