Recently, the San Francisco Municipal Transportation Agency, also known as MUNI, was attacked by a new variant of Mamba (a.k.a HDDCryptor) – a disk-encypting ransomware. The incident left their ticketing services with inoperational systems and a note that read, “You Hacked,ALL Data Encrypted,Contact For Key(email@example.com)”
Fortinet first discovered Mamba two months ago. Since then, it has been under the radar – until this big attack. We will now take a look at a few irregularities and some new developments it has employed over the past few months.
This is the very same ransom note that could be found in the infected systems in Muni – using the same attacker email and ID. This is the primary reason why we think this is the malware that hit Muni.
Fig.1 Ransom note of the new Mamba ransomware
As in the previous version, this variant of Mamba installs the legitimate disk-encryption tool, DiskCryptor, along with other components for encrypting network shares. This time, the installation directory is “%SystemRoot%/Users/WWW/”
For some reason, as of this writing, the website of DiskCryptor is inaccessible. Apparently, it has been down for at least two months - around the same time that it was first seen being used by Mamba ransomware.
A notable irregularity is found in the installed mount.exe component, which was used to encrypt network-shared files. In this variant, the component dropped is still encrypted.
Fig.2 Encrypted mount.exe
We expected that it will be decrypted at some point, and executed. However, the malware continued to try and execute the file as it is, but obviously, nothing happens. This is a very confusing behavior. The log message about network share encryption has also been removed. It’s possibile that the real intention was to disable the feature, but there is surely a better way to do that.
Fig.3 Executing the encrypted mount.exe
Another irregularity is the fact that it tries to find a directory that it has not created, but was used in a previous variant’s installation – “%SystemRoot%/Users/ABCD”.
In this version, most of the strings that it uses are already encoded by Base64 algorithm. Although this is not a very complicated obfuscation, it can still be effective against signatures based on the plain strings from the older version.
Fig.4 Base64-encoded API strings
And it still uses plain text for logging its status.
Fig.5 Mamba status log
There’s no big development between the first Mamba sample that we discovered and this new one. It is the same simple and direct ransom malware - no fancy encryptions, anti-sandbox, or anti-debugging mechanisms.
So how was this simple ransomware able to land a big blow to one of the largest transit systems in United States?
As we keep on reiterating, the effectiveness of an attack relies heavily on how it gets into systems. It does not matter how dangerous, simple, or complicated a payload is. If it doesn’t have an effective way to force itself inside systems, it’s just a bullet with no gun to fire it.
In the case of Muni, reports suggest* that the malware may have been installed by exploiting a vulnerability related to an unpatched Oracle server program. It’s an old vulnerability, and a simple update to patch the system could have saved them a lot of money, along with a great deal of inconvenience and public embarrassment.
Special thanks to my teammates, Artem Semenchenko and Tony, for sourcing samples
-= FortiGuardLion Team =-
645b8dfe73255d9e5be6e778292f3dde84ff8c5918a044ae42bcace0fe9ca279 (main executable) - W32/Mamba.WWW!tr
525fa1bf741aedac29a87925094ee7cd5849e3d162a6997db7202c04daccb882 (modified dcapi.dll) - W32/Mamba.WWW!tr