Dealing with surprise ransomware

Hello dear reader,

Long time no post.

I was a bit busy but information sharing is very important for me and our team so this post can help a lot of people.

I keep hearing about how sharing stories from the trenches can help others.

So, here is how dealt with an out of the blue ransomware case.

Let me setup the stage:

It's a late Monday afternoon, I have an hour before I go home.

One of our sales guys comes in and tells us a company he has worked with in the past is infected with ransomware.

Here are some of the things we did to try and deal with this infection.

Preparation

We have our own internal ransomware handling procedures.

We also have procedures to help our customers.

But, this case came via side-channels. :)

Our team did not have contractual obligations with the infected party.

Yet, our companies have had dealings in the past.

From what I understand, they bought a Palo Alto firewall some time ago.

More on that later in the story.

In my experience I've seen a lot of people shrug off the preparation phase of Incident Response.

There is a lot of documentation and policy involved in creating Incident Response procedures.

Also a lot of training and enforcing said procedures.

Believe me I am not the best person to talk about following processes and procedures.

If you ask me documentation is a framework to follow when investigating.

I know it's not as cool as everything else but it is important.

Having the procedures in place and knowing how to react to certain situations can help reduce the initial panic.

It gives you an ordered approach to handling incidents.

Needless to say we are working on a procedure for out of the blue ransomware cases.

Gathering information

As I said the case was unexpected so we did not have prior information about the infected company.

Or on the incident itself for that matter.

So I set out to gather more information on the business side of things and incident details.

First we talked to the sales guy that reported the incident.

He explained the situation as best he could and gave us contact information for the company.

Turns out our companies do a lot of business together.

This is not the first time the callers get infected with ransomware.

After the first incident they started backing up their servers.

This is where the Palo Alto firewall comes in.

The company bought it in hopes of not getting infected a second time.

A bit of an old school tactic - hide behind the firewall.

Second we went to the managed services network team to inquire about said Palo Alto.

Turns out it's customer managed. We don't have visibility over the configuration or the detection.

All and all gathering prior information took about 5 or 10 minutes.

I gathered as much information on the infected company as I could.

We then moved to the incident itself.

We went to the Service Desk to see if the infected company created a ticket with more details on the incident.

There was no ticket but we needed more information.

We did the next best thing and called the company and had a phone interview with an IT admin.

We did a standard interview as best we could on account of the woman talking at 200 words a second.

We calmed her down as much as possible and we proceeded with the interview.

I want to say, props to the lady.

Even though she was panicking she answered all our questions.

That helped out a lot.

Here are some of the questions we asked about the malware:

• When did you first notice the infection? Today. A few hours ago.
  

• How many hosts have been infected? Several endpoints and 2 servers. One of the financial servers.
  

• How does the desktop look like? Are there changes? Yes.
  

• Have the icons and files changed in any way? Yes.
  

• Is there are ransom note anywhere on screen? No.
  

• Do the files have a strange extension? Yes. .exe.[Frazeketcham@cnidia.com].eth
  

• Can you provide a sample? Yes.
  

• Do you have backups in place? Yes.

The interview took about 15 minutes total. They already knew what getting infected with ransomware looked like.

So they were quick to identify it and seek help.

At first she said there is no ransom note but later she found it and sent it along with a sample file.

After the first infection they had backups in place.

So they had their recovery process.

They had suspicions about an RDP server being used as the initial infection.

More on that below.

The IT lady provided valuable information, malware samples and solid leads on the attack vector.

It's always a good idea to get the admins involved in the Incident handling workflow.

They can provide valuable information and solid leads for the investigation.

Incident handling and infosec in general is not black magic.

We are not doing some exclusive voodoo.

Working together in handling an incident is beneficial for everybody involved.

Identification

We used ID Ransomware and the No More Ransom project to identify the type of ransomware.

There is always hope its decryptable....

.....Unfortunately in this case it was GlobeImposter 2.0 - no decryption.

https://id-ransomware.malwarehunterteam.com/

https://www.nomoreransom.org/crypto-sheriff.php?lang=en

GlobeImposter Ransom Note

Identifying the infection vector

Remember the Palo Alto?

They gave us access to the Palo Alto so we can identify how the infection happened.

There were quite a few lax security policies in place.

A lot of the IPS signatures were disabled.

The enabled ones were out-of-the-box or default signatures. The actions set for the signatures was reset-both.

Reset-both sends RST packets to both the client and the server.

It is not exactly an explicit block.

With enough RST packets a DoS condition may emerge.

Additionally resetting the connection does not stop the attacker to try again.

But this time he/she is alerted to the presence of a firewall or router in the network.

Devices should configured to fit your environment.

That way they can be used to their full capability. References: https://docs.paloaltonetworks.com/pan-os/8-0/pan-os-web-interface-help/objects/objects-security-profiles/actions-in-security-profiles

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CleSCAS

The RDP vector.

The admin suspected the RDP server.

We found RDP login attempts from a few malicious IPs.

Judging by the session duration (~20 sec and ~8 min) and amount of traffic (100 - 800 kb) they could have been successful.

But without any extra logs we could not confirm whether RDP was the vector. The Email vector. We identified a massive brute force to their mail server a week before the infection.

A good example of how the reset-both action on the Palo Alto can create a DoS condition.

Again, we did not have enough logs to confirm or deny an email was the cause of the infection.

There was no email security or monitoring in place.

There is now.

Containment

The infection was not that wide spread but it did get to a few servers.

They isolated the servers from the rest of the network until they can back them up.

Eradication

Reinstalling the end points and restoring server data from the backups.

Lessons learned

For us as a team:

We needed to further develop our internal processes to encompass out of the blue incidents. We did experience a few communication issues with our teams and with the infected company while collecting all the data.

We need to work on communication.

For the company: Moving from a single firewall to a full suite of security tools. Reducing the attack surface by removing the exposed RDP. Reviewing and improving the Palo Alto configuration to fix the lax security policies.

Conclusions

We faced a spectrum of both non-technical and technical issues.

These were the steps that were available to us to deal with the incident.

One thing to know from handling incidents is that there is always room for improvements.

I hope this helps somebody out there.

Cheers.