Matrix Ransomware: What To Do If You’re Infected

Tetra Defense looks back at some ransomware strains we’ve seen as the past oftentimes informs the present. Learn how Matrix Ransomware operated to stay updated on possible future strains. 

What is Matrix Ransomware?

Matrix ransomware is part of a new breed of malware whose favored method of distribution is by exploiting RDP (remote desktop protocol) vulnerabilities using a brute-force password attack. Matrix has this in common with the SamSam and Phobos ransomware strains, all of which had remote desktop services as the primary attack vector. Some security professionals have observed that this ransomware vector strategy appears to be trending upward.

The Matrix strain of ransomware follows in this tradition by implementing a targeted RDP exploit attack methodology against pre-selected victims, usually small, medium, or enterprise-level businesses. These may be businesses that the attackers assume would be more likely to pay the ransom if they successfully hack into the infrastructure.

The bigger the fish, the bigger the prize?

So far, the discovered footprint of the Matrix ransomware is relatively low, and the number of organizations that have been affected by the malware is relatively small. Still, importantly, the reward for successful ransom is significantly high.

As always, figures for ransomware attacks are difficult to estimate, but ZDNET has observed that of the known Matrix victims, 28% were businesses based in the United States, and 17% were in Belgium. Additional significant Matrix ransomware infections occurred in Taiwan, Singapore, Germany, Brazil, Chile, South Africa, Canada, and the UK.

There are 30 known extensions used by the Matrix ransomware, and with most strains, the attackers masquerade as the FBI claiming to have remotely locked the encrypted files on the victim’s computer. Most likely, the goal of this tactic is to create fear and make an emotional impact on the victim.

Unusually, with Matrix ransomware, the ransom demand is always in US Dollars instead of bitcoin. The ransom payment still happens in bitcoin, but some experts believe that this approach protects the attackers from widely fluctuating bitcoin currency valuations.

How Does Matrix Ransomware Work?

A server or computing infrastructure device that is exposed to the Internet and has RDP enabled is at risk of an RDP attack. Remote desktop services are a legitimate administration tool used by computer operators to manage servers and devices.

RDP uses port 3389, and with the proliferation of cloud computing, there are a vast number of public-facing computers with remote desktop services enabled. Security experts warn against allowing RDP unless necessary, and they advise the use of secure passwords and multi-factor authentication.

RDP connections protected by weak, simple, and human-readable passwords easily cracked using sustained dictionary attack hacking tools. A botnet, or a group of compromised servers, is used to identify and attack the RDP connection. This methodology creates a sustained, high-volume attack that challenges the RDP protocol with millions upon millions of passwords in quick succession.

Victims of Matrix Ransomware will most likely have had their systems accessed over RDP, either directly or indirectly. The payload is copied over to the victim’s computer and executed manually.

The ransomware payload follows a typical trend after execution: Matrix removes Windows Volume Shadow Service snapshots and system restore points to prevent restoration, and antivirus software is disabled before encryption. Standard user files are targeted, including pictures, documents, databases, and a variety of non-system files – all of which are locked using encryption.

The malware attempts to copy itself to admin shares on the network, and the attacker may attempt to access internal systems, which they can accomplish easily if RDP cached credentials exist within the compromised system.

Another feature that differentiates Matrix ransomware is how the attackers carry out the ransom demand. The ransom note gives instructions for the user to send 3-5 of the obfuscated and encrypted files to the attacker, together with the KEYIDS.KLST file that was created by the ransomware.

This action serves two purposes; firstly, the ransom note proves to the victim that the attack can unlock files, but it also gives the attacker the upper hand, as the data sent by the victim may potentially hold business information. The attackers could identify who the victim was and use that knowledge to issue a personalized demand in another ransom note. The costs may be high or low, depending on the likelihood of payment. The follow-up ransom demands include a bitcoin address of where to send the payment.

How Do I Prevent Matrix Ransomware?

Because Remote Desktop Protocol (RDP) is the primary attack vector for Matrix and many other ransomware variants, securing all your RDP connections is a fundamental best practice to invoke. Only enable RDP on public-facing systems if absolutely necessary. Restrict RDP access to a set number of authorized IP addresses: this is an essential precaution on cloud computing infrastructure.

Passwords used on RDP hosts must be complex, non-dictionary words, ideally protected by multi-factor authentication, such as RSA. Enhanced RDP security features, called Network Level Authentication, should also be switched on from the Windows operating system. Network layer protection should also be engaged using a network firewall that drops any unauthorized traffic.

Educating employees about ransomware and securing RDP are great strategies to help thwart malware like Matrix. Education about ransomware variants, malware, phishing campaigns, and how to react to unexpected attachments is also a recommended approach.

Proactive prevention is another strategy that can prove useful. This strategy may include technical measures such as robust email filtering, email authentication, email encryption, and endpoint monitoring tools. Patch all network infrastructure to the latest security levels, including servers, antivirus, antimalware, device firmware levels, and application updates.

We recommend that you follow additional strict business practices to help prevent Matrix from infecting your infrastructure. These practices include creating and maintaining a system inventory of your entire infrastructure and using this information to conduct a risk analysis to identify security weaknesses, allowing you to create a priority list of what to fix first.

Replace end-of-life Operating Systems including Windows XP, Windows 7, and, soon also, Windows Server 2008 R2. OS licensing is expensive, but it is critical to have supported operating systems that entitle you to security updates and patches.

Finally, use backups. If the worst does happen and you are affected by ransomware, often the quickest resolution is to restore from backup. Regular offsite backups should be completed on a daily, weekly, monthly rotation to reduce the likelihood of the backups also becoming infected.

Have a disaster recovery plan in place to prepare for the eventuality of a total outage caused by ransomware. This plan might be a high availability Disaster Recovery set up in a secondary site or with a cloud provider.

How Do I Get Rid of Matrix Ransomware?

Nearly all antivirus products are now capable of blocking malware using real-time protection agents, and fortunately, the Matrix application hashes are known and easily detected by AV. Combining this with a strong RDP security strategy will put you in the best possible position.

There are many websites online that claim to be able to remove Matrix. However, most of these are fake scamming sites. There is no known publicly available decryptor for the Matrix Ransomware.

We strongly recommend a full rebuild of any machine infected with Matrix from a backup. Rebuilding machines may cause short-term pain, but in the longer term, there is the assurance that the malware wholly removed during the rebuild process.

Tetra Defense prioritizes restoration to get businesses back to where they were before the ransomware attack. We approach ransomware restoration and investigations simultaneously, so you return to normal operations at the same time you are getting answers.

Our teams are standing by to focus on what matters most: your business! We will survey the ransomware attack and perform an initial assessment; this will identify the optimal course of action to address the incident. If deemed necessary, we can conduct ransom negotiation and, if needed, can facilitate ransom payment.

We remove the threat from and secure your systems, conduct malware scans, and network threat hunting. Tetra leverages each incident to learn from the ransomware attack and to discover the root cause. Once Tetra obtains the decryption keys, we decrypt the data and get systems restored to full functionality as quickly as possible.

Example of Matrix Ransom Note

Get Help with Matrix Ransomware

If you’re ready to get help removing Matrix ransomware from your critical systems, contact Tetra Defense’s incident response team today. We will reach out for an assessment and build a plan to get your network up and running once again.

Check out some related content on our blog:

MobileSMS.plist and the Joy of Testing – My Favorite Artifacts, Part Two

President of Tetra Defense, Cindy Murphy, shares her insights:

The proper method for inquiring after the properties of things is to deduce them from experiments.
~ Isaac Newton

Quick note: The images in this post are watermarked by Gillware Digital Forensics, now known as Tetra Defense.

Testing is the way to figure out YOUR favorite artifacts.

This is a test. This is only a test.

In saying “only,” I’m certainly not implying that testing isn’t important. Testing is one of the most powerful, yet least talked-about or taught techniques in digital forensics.  Testing is the way to find the answers to how things work.   It’s the way to discover the answers when Google doesn’t have them (or just gets sort of close). In digital forensics, and in particular, smartphone forensics, testing is no longer an optional skill, but rather one we all need to know how to use.

You might even say that testing is a subject of great “gravity” in our field.

In the past couple of posts, I’ve been talking about my favorite artifacts. As I showed in last month’s installment, in which I talked about smartphone user dictionary files, I went into detail about my first encounter with the artifact in question and showed how I came to discover that particular artifact.

The fact is, which artifact is “my favorite” is generally based on whatever casework I’m currently doing and what I need to find out.  I could cover a thousand artifacts but never hit on the one artifact you want to know more about.  But if you start to incorporate testing into your daily practice, that won’t matter because you’ll have the key to finding out for yourself and verifying what you find in your research. In other words, when you start testing, you’ll start building your own list of “My Favorite Artifacts.”

A Timely Example of My Favorite Artifact: MobileSMS.plist

Right now, I am working on a case in which I need to know how long various users had set their iPhones to keep their text messages. Over a dozen iPhones and backup files were submitted to us for analysis, all of different models and all running different versions of iOS.

This is not a common request. In fact, in over 20 years of doing digital forensics, this is the first time I’ve been asked to answer this particular question. Message retention is not a setting that forensic tools automatically parse for us, so actually answering this question would take more elbow grease and in-depth examination than many of the other questions we’re commonly tasked with answering.

All of this makes this scenario a perfect example to demonstrate the power of testing!

This Is Only a Test

Test phones are a “must have” for mobile forensics practitioners.  Without test phones, there just isn’t a way to find answers to all of the various questions that might arise. After all, you don’t want to risk testing something on an indispensable piece of evidence, lest you end up inadvertently destroying something you need to have preserved.

I started at the beginning with some good old-fashioned research. I looked at a freshly-factory-reset iPhone to see what the options were for text message retention. There were three options: “Forever,” “1 Year,” and “30 Days.”

Then I checked my bookshelf.  A search of the indexes of “Practical Mobile Forensics: Second Edition,” “iPhone Forensics,” “Learning iOS forensics,” and “OS Internals: Security and Insecurity” revealed no quick answers.

I next turned to the Internet where I dug up the 2016 BlackBag Tech blog post “Are the Messages Being Automatically Deleted?” This helpful write-up contained information about an artifact called MobileSMS.plist, but it didn’t answer the specific question I had. It did, however, lead me to the name of the artifact that stores, among other things, the user setting for how many days SMS messages should be kept before deletion–exactly what I was looking for.

I had plenty of test phones to experiment on, and now I knew which rabbit hole I needed to jump down. It was time to discover what would soon become one of my favorite forensics artifacts.

What’s Next?

Now I had an idea of which specific artifact I needed to focus on in testing. The next step was to use the scientific method to figure out what would happen to the MobileSMS.plist file under various conditions.

As a refresher, the scientific method is a pretty simple six-step process.  Here’s how I applied it to the MobileSMS.plist message retention question:

  1. Make an Observation: The file that holds information about how long the user wants messages to be kept is the MobileSMS.plist file.
  2. Form a Question: What changes happen to the MobileSMS.plist file when the user changes the retention setting?
  3. Form a Hypothesis: There will be at least one value in the MobileSMS.plist file (probably KeepMessageForDays mentioned in the BlackBag blog post) that changes when the user settings are changed.
  4. Conduct an Experiment: Use a freshly-reset test phone to check the default settings. Then change the settings to all of the various possible options. Image the phone in its default state, then image it after each change is made so that a comparison can be made of the MobileSMS.plist file in each state.
  5. Analyze the Data and Draw a Conclusion: Document what the changes were and nail that artifact down!

What I found out about the MobileSMS.plist artifact:

Default Settings:

I started with a freshly-factory-reset test iPhone running iOS 11.1.2. (Remember that with any iOS version, artifact locations and behavior could potentially be different. Therefore, you might have to repeat testing for different versions.)  I looked at the default setting for how long to keep messages and found that the default setting was “Forever.”

Below are screenshots showing how to navigate to the setting:

Instructions on how to find message retention settings on an iOS device

Instructions on how to find message retention settings on an iOS device

Without making any changes to the settings, I used Physical Analyzer to do an “Advanced Logical 1” extraction from the device.  Here’s what the MobileSMS.plist file located at /mobile/Library/Preferences/ looks like (kudos to Cellebrite for recently adding in a great .plist viewer to their tool!):

A closer look at MobileSMS.plist

A closer look at MobileSMS.plist

There are some potentially interesting values there, but notice the conspicuous absence of the entry “KeepMessageForDays.” Interesting! If the default value for message retention has never been altered, apparently this entry isn’t present.

Change settings to Keep Messages for 30 Days:

I then changed the message retention setting to keep messages for “30 Days.”

The phone shows a notification indicating that this change will cause the deletion of messages older than 30 days.  Good to know.  I again used Physical Analyzer to do an “Advanced Logical 1” extraction from the device and looked at the MobileSMS.plist once more. Here’s what I found this time:

Observing the changes in MobileSMS.plist

Observing the changes in MobileSMS.plist

After changing the setting from default, the KeepMessagesForDays value shows in the MobileSMS.plist file. And, there’s another new entry named KeepMessagesVersionID that appears with a value of 1. It’s a new artifact that led me to develop a pretty obvious new hypothesis. I posited that this value was related to me changing the default value for how long to keep messages one time.  All of a sudden, I found myself testing more than one thing.

Change settings back to default:

Next, I changed the message retention setting back to the default setting, “Forever.”

This is because I wanted to know what the change would be in the KeepMessageForDays value, which didn’t previously exist when the phone was in its default state.  Here’s what I found:

Observations of the way MobileSMS.plist changes as I alter its conditions continue

Observations of the way MobileSMS.plist changes as I alter its conditions continue

When the user resets the settings back to the default (Forever), the KeepMessageForDays value becomes 0. And notice that our KeepMessagesVersionID value ticks up to 2 with the second change of the setting.

Change settings to Keep Messages for 1 Year:

I next changed the settings on my test iPhone to keep messages for “1 year.”

Again, I got the deletion notification, telling me that this would permanently delete messages over a year old:


I did yet another “Advanced Logical 1” extraction from the device and looked at the MobileSMS.plist file yet again.

It’s beginning to feel like Groundhog Day, isn’t it?  But here’s what I found this time:

Yet another round of testing MobileSMS.plist to learn of its secrets

Yet another round of testing MobileSMS.plist to learn of its secrets

When the retention setting is set to keep messages for one year, the KeepMessageForDays value becomes 365. And our KeepMessagesVersionID ticks up to 3 corresponding to the 3rd change of the setting.

So, in summary now we know:

Remember, It’s “Only A Test”

I opened this post talking about testing.  Hopefully, you’ve seen that testing doesn’t have to be a complex and high-stress thing.   With a test phone, a solid toolset, a little time, and a bit of research, we now know a whole lot more than we used to about the MobileSMS.plist file.  The steps I walked through here are really all it takes to find and explore your favorite artifacts.

“I’ve got a great notion that force is a changer of motion. Let’s put it this way:  f = ma
The rest is just sweat and devotion.” ~ Unknown

Check out some related content on our blog: