Here at Sona IT, we come across all sorts of interesting situations.
In the summer of 2019, we got a call out of the blue from the distressed owner of a pharmaceutical distribution company with over 100 employees who were unable to work.
He had unfortunately been a victim of cybercrime, with ransomware surging through his network and encrypting everything it touched. He had an on-site IT engineer, but they insisted on a 3rd party company to conduct post threat analysis. We answered the call and I was on-site within an hour.
This job required a team but due to the situation, only I was able to attend the site. For these situations we carry equipment which once connected to the network allows us to tag in team members at Sona IT HQ to help with the analysis.
I want to share with you the report produced from this event including the analysis that was conducted and recommendations made. Please note some information is omitted to protect the client.
Server layout:
1 Physical server running HyperV Windows 2012 r2– 2 NAV servers, Database and Server
1 Physical server running 2008 R2 – Active Directory, File server, DNS, DHCP
Sona IT have been instructed to provide an analysis into the data loss that recently occurred at the XXXXX
Our team have reviewed and assessed the situation and have identified and confirmed a series of events that have led up to the breach and are summarised below:
Series of events:
Saturday 04/08/19 – 16:00, files began to get encrypted on the AD/File server. We can confirm this with the encryption time stamp on the Phobas (ransomware).
Monday 05/08/19 – Morning, staff recognised files and NAV server to be in-accessible. The ransomware is built on connecting all mapped drives and encrypting files by moving latterly through the network.
The Deep dive on Phobas confirms this is done by design. It does not require an attacker to login to the RDP session.
We confirmed that Phobas had been used to encrypt the data No More Ransom confirms the strain.
The service/file was identified and called: AntiRecuvaAndDB.exe
Monday 05/08/19 – 11:06, Login/log off logs on AD/FS had been cleared. We are unable to confirm whether this was built into the ransomware as part of the automation or if the attacker logged in directly to clear logs. We have however found articles stating other worms which have this facility built in. Petya clears logs so it is very possible this was imbedded into the strain XXX received.
Monday 05/08/19 – 11.15 – Servers were shutdown to prevent damage and further spreading of the infection.
IT reviewed the backups to see if they were recoverable, however due to the exposure of one of the Domain Admin accounts, the malware was able to move latterly through the network encrypted multiple servers and thereby also into the backup servers.
This incident was reported to the UK Police, none emergency and Action Fraud. A cyber/ police case reference has been provided.
Action Fraud have advised that the data cannot be decrypted without paying the ransomware. Sona IT confirmed there is no known decrypter for this strain of ransomware. There is no guarantee that any ransom paid will result in decryption in any event.
NAV database is critical to stock/sales of pharmaceutical products.
Wednesday 07/08/19 – IT were unable to recover any data. IT setup a blank database for all new transactions to be logged. This allowed the business to start functioning again.
Current State:
Data remains in a corrupted state. The files are related to day to day documents. Primarily Word documents, spreadsheets, financial data and SAP data is both irretrievable and therefore now lost. Due to this loss XXX would no doubt find it difficult to recall sufficient financial data historical or otherwise as a result of this breach.
We have no solution for any gaps in data or recall which will inevitably form due to the breach and its consequences.
Root cause of breach:
Primary failure was leaving the RDP port open to public. Along with a known password which is on a data breach list Found here.
Recommended Changes:
Firstly, we advise keeping a copy of the encrypted files along with a copy of the malware AntiRecuvaAndDB.exe. There is a very small chance that a decrypter would be available in the future.
-Use a VPN Tunnel for 3rd party to access the NAV server they manage.
-Using Computer generated passwords, confirm they are not on the breach list.
-Isolate server/desktops/guests/mobiles/VoIP via VLANs. Keep all equipment segregated with isolated networks.
-Ensure 3 backups are taken at Machine level. Ensure that the backup server is not part of any domain and has a different password.
We further recommend;
1 copy on-site at block level such as Veeam,
1 copy off-site block level such as Veeam,
1 copy file level such as Acronis or Azure backup of Primary NAV database and company AD/Files
-Have Anti-virus running on All servers, regardless of roles. Anti-virus needs to be tweaked for server use. If this is not done, it will cause performance issues. We advise Webroot as it provides web console to tweak settings.
-Use a firewall which includes IPS/IDS systems. This will allow you to block activity to from top 20 hacking countries.
-Use of an MSP to manage high level infrastructure to ensure best practices are followed
References:
Phobas Ransomware Deep dive – https://blog.malwarebytes.com/a-analysis/2019/07/a-deep-dive-into-phobos-ransomware/
Ransomware validator – https://www.nomoreransom.org/crypto-sheriff.php?lang=en
Ransomware adds work capabilities – https://www.microsoft.com/security/blog/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
Haveibeenpwned data breach password/email checker – https://haveibeenpwned.com/