The Rubidium01 case
Streamscan specializes in the detection and elimination of intrusions into computer networks. We are constantly called upon to intervene directly in companies to limit the damage during a computer attack. Our interventions are based on the most advanced technologies in artificial intelligence and also on the expertise of our cybersecurity experts.
During a deployment of our incident response team, we documented the course of our intervention. This is the Rubidium01 case.
Friday, 5:45 p.m.
An IT consulting firm contacts us to report that one of their large clients is undergoing a computer attack. One of the system administrators noticed that several production servers were rebooting on their own. On rebooting, a message appeared on the screen indicating that the hard drive had been encrypted and that a ransom must be paid to recover the data. At that time, 17 servers were infected. While we are talking, my interlocutor is informed that 5 more servers have restarted and are infected. All infected servers have the same Windows version and the same antivirus. Our interlocutor also informs us that his client has received a ransom demand email in bitcoins in the order of 300 000$ CAN and that he has 48 hours to pay otherwise the ransom will double. The IT consulting office gives us the company's address.
Friday, 5:58 p.m.
Our Incident Management Coordinator arranges a teleconference with members of our Incident Response Team to prepare for deployment. The modus operandi (restarting infected servers) makes us think that there could be many more servers infected. It is imperative that we act as quickly as possible to counter the incident and prevent it from spreading throughout the company network. Three experts from our team are rushing to the infected company.
Friday, 6:30 p.m.
We drop by our office to pick up two CDS servers already configured and ready to be connected to the client's network. We also bring a keyboard, computer monitor, power cables, network cables, and blank hard drives and DVDs. We also take two laptops with us: the first contains tools for investigation and evidence collection while the second contains an environment for analysis, autopsy and reverse engineering of viruses and malicious tools (sandbox).
Friday, 6:53 p.m.
Our Incident Response Coordinator arrives at the client's premises with two servers under his arm. A brief meeting is arranged with the company's IT manager to gather information on the evolution of the situation and any mitigation actions that have been taken so far. It emerged from this that a total of 27 servers were infected. These include highly sensitive databases that are vital to the customer's business operations. As a precautionary measure, all servers have been shut down. A firewall rule was also created to block all internet traffic. We recommend a communication strategy to the IT Director so that the company has full control over the information released about the incident. Indeed, if communication is not controlled, there could be several versions of the incident.
Friday, 6:58 p.m.
The other two experts from our team arrive at the client's premises. The Incident Response Coordinator presents them with the status of the situation. An action plan is defined and communicated to the client's IT manager.
Friday, 7:12 p.m.
In such a situation, the first urgent action to be taken is to contain the incident to prevent, for example, data leakage or the incident from spreading through the network. We recommend the implementation of firewall rules to completely isolate the server area from the rest of the company network.
Friday, 7:25 p.m.
Our cyber security experts begin the installation of our CDS technology in the customer's network. The objective is to enable real-time detection of data exfiltration attempts or attempts to propagate the malicious tool through the network. The CDS will enable us to map all the servers already infected in the network.
Friday, 8:00 p.m.
Both CDS instances are installed and functional in the customer's network. The network is monitored to detect intrusion attempts, cyber threats or any attempt to exfiltrate data. Email notification is enabled. After a few minutes of analysis, the CDS detects suspicious behaviour in the network. A series of alerts are displayed in the dashboard of our detection system. Our experts begin analyzing the security events generated.
Friday 8:15 p.m.
Beginning investigations. Priority number one: find a copy of the ransomware to understand its modus operandi. A virtual machine from an infected server is installed in our sandbox for analysis. We find the executable file of the ransomware in a directory.
Friday, 8:45 p.m.
We perform dynamic analysis of the ransomware executable file to better understand its behavior, persistence and propagation mode. We extract compromise indicators (IOCs) from the ransomware which are the artifacts that uniquely characterize it (for example: name and size of the ransomware executable file, name of the processes created, registry keys added, domain names or IP addresses with which the ransomware communicates). We are able to identify the ransomware as ARENA (Crysis Dharma). This is a malware that appeared in 2017 and has already claimed thousands of victims worldwide. It is also one of the most active ransomwares in 2020.
Friday, 8:53 p.m.
The client is informed of the results obtained. We always recommend not to pay the ransom demanded by the pirate. The customer agrees.
Friday, 9:32 p.m.
Determining the propagation mode of the ransomware. By analyzing the network communication flows generated during the dynamic analysis of the ransomware, we are able to confirm that the ransomware cannot propagate on its own. This assumes that the hacker connects to each server and manually runs ransomware.
Friday, 9:37 p.m.
Debriefing with the client. We request the change of the passwords of all user accounts and administrators of the network servers (local accounts and Active Directory). The hacker certainly uses a password to connect to the servers. This change will prevent the hacker from compromising additional servers.
Friday, 21:39 p.m.
We create a behavioral model of the ransomware and integrate it into the CDS. This new model allows the CDS to detect other variants of ransomware. The new behavioural model is shared with other users of the CDS, so we can prevent other companies from being attacked in the same way.
Friday, 9:42 p.m.
One of the CDSs generates alerts about attacks that target a web server. The client confirms that it is one of their transactional web servers. We indicate the measures to be put in place to block the attack.
Friday, 10:45 p.m.
As with all incident management, you know when you start, but never when you finish. We order pizza, boxes of water, fruit and snacks. It could be a long night. The team is motivated and determined to resolve the situation as quickly as possible to limit the impact on the company.
Saturday, 11:26 p.m.
The IT Director informs us that he has received an email from the hacker who tells him that if the ransom is not paid within 24 hours, the amount will double. The IT Director wants to negotiate, which we strongly advise against.
Saturday, 1:00 a.m.
Investigations continue...
Saturday, 1:35 a.m.
The CDS generates alerts about infected systems. After information is received, these are employee workstations. Surprise for the customer: there is an up-to-date antivirus on each of the affected computers. We request the disconnection of the computers in question. They will be cleaned up later. We also request the implementation of firewall rules to block communications to the remote IP addresses with which the infected computers are trying to communicate. Investigations are ongoing.
Saturday, 2:45 a.m.
Our team identifies the source of the problem. The pressure's easing off. We have traced back to patient zero (1st infected server) and are able to confirm that the hacker connected to this server via a support account with administrator privileges and then executed the ransomware manually. The same support account exists on all other infected servers. This machine has been compromised by a brute force attack (targeting the RDP protocol) from the Internet. We propose measures to strengthen remote RDP access.
Saturday, 3:43 a.m.
Debriefing with the client's IT manager. We tell him what action to take: reinstall the infected servers from scratch, restore data backups, strengthen remote RDP access control, etc.
Saturday, 3:55 a.m.
One of our team of experts goes home to rest. He'll take over in the morning.
Saturday, 4:54 a.m.
At this point, we are able to confirm that all infected servers have been identified and isolated. The client's IT team is exhausted as they have been working on the case since Thursday. As the incident is under control, they are returning home to rest in order to be fit for further work. One of their IT technician stays on site with us as needed. Meanwhile, our security team monitors network security, identifies attacks and works with the client's IT technician to block them.
Saturday, 10:00 a.m.
Start installing the operating system of previously infected servers. We recommend shielding measures for the operating system of reinstalled servers.
Saturday, 11:14 a.m.
The IT Director informs us that the most recent data backups are one week old. Restoration of this data is acceptable.
Saturday, 12:52 p.m.
The pirate is about to double the amount and he has the courtesy to inform us so that we don't overcharge. Even so, the pirate obviously wants us to do good and is concerned not to make us spend too much. Obviously, his reminder is ignored.
Saturday, 1:00 p.m.
Our team continues to monitor network security. They identify attacks and work with the customer's IT technician to block them. We detect other intrusions into the company network that are not related to the current attack.
Saturday, 2:04 p.m.
Another raise from the pirate, who's starting to get feverish. He realized that the situation could get out of hand...
Sunday, 6:09 a.m.
Another raise from the pirate who now wants to negotiate. He has realized that the situation has eluded him. We don't know that.
Sunday, 11:00 a.m.
Begin data recovery starting with the most critical servers.
Sunday, 5 p.m.
Progressive return to production.
For the next two weeks, our team will accompany the IT team in the restoration of the servers. For each reinstalled server, we make sure it is well secured. We identify the immediate points of improvement to be implemented and work with the client on their application.
At the client's request, our compromise detection system (CDS) is permanently installed in their infrastructure. This allows us to provide post-incident security monitoring of the customer's network via our CDS. In this way, the security level of the customer's environment is optimal. Attacks and infections identified during post-incident monitoring are traced back to the customer and we help them deal with them.