woensdag 7 december 2016
Ransomware incident analysis
- Lets start with a disclaimer... I wrote this post a while back, but forgot to publish it, sorry...-
Ransomware encrypted all of the New Jersey Spine Center's electronic health records of patients of the practise. That's interesting news. And I don't believe the explanations in the press release. They were not the victim of some advanced malware sample, I my opinion they did not apply the correct basic security controls.
Ransomware typically encrypts documents, like word, excel, powerpoint. Reading between the lines of the press release, it seems that the practise doesn't use a document management system, a content management system, or an electronic health records system, the practise stores all data in files.
Managing files is a big problem. Ransomware is just one of the problems: if your account is compromised, the ransomware software acts on your behalf and encrypts the documents that you have access to. This is an even bigger problem when using shared folders on a filesystem: the ransomware software not only encrypt your documents, but also all other documents that you can edit. The more permissions you have, the bigger the risk. And if your account is privileged, the problem may even lead to a catastrophe.
In this case there are more strange phenomena. According to the press release the malware would have used passwords that are stored in a file. Do I believe this? No way, the ransomware we know is not actively searching for documents with passwords and when found decrypt the passwords in order to be able to login. No, ransomware makes use of naivity of people by making them activate the ransomware. The only way passwords can be reused by criminals is by criminals remotely hijacking sessions. That's a different problem.
The press release suggests that all of a sudden the virus protection software blocked the malware. That's not how it works. The more logical explanation is that the malware has been active for a while, without anyone noticing. After an update of the antivirus signatures the notifications of the antivirus software showed the presence of the malware and the malware protectoin software may have blocked instances of the ransomware from staying active. The longterm presence of the malware can be assumed by the fact that even the backups of the data were encrypted. In my opinion the backup software has backuped the encrypted files on the backup drive, thereby overwriting possible older original files. And that must have been a while... Or there is not a backup system, but the files have been copied to another filesystem, on which the victims had too many permissions.
Why did I make this analysis? A while back I wrote a blog about ditching documents. It may have been a creative way of solving the problem, but I feel that it may well be a valuable advice.
In electronic healthcare systems and content management systems you don't manage documents, but the content is stored in a database. Malware cannot encrypt data in the database: it would require system authorizations in order to abuse the database management system to be able to encrypt the data. And no, I don't believe that ransomware is able to crack the system password. It would require knowledge of the system used and of the infrastructure the system is running on.
And by the way, ransomware doesn't happen all of a sudden. It requires user interaction. Users visiting infected links, websites or users opening malicious documents.
The hospital paid the ransom fee in order to get the keys to decrypt the data. Waiting for the next instance of malware infecting more data.
Parts 3 and 4 of the blog series from RBAC to ABAC
This year I joined the new Dutch subsidiary of Nixu Oyj, the Finnish cybersecurity company, as a security and IAM consultant. Nixu employs over 50 IAM consultants, so it feels like a great place to have conversations about digital identity, access control and to share knowledge. What better place to post my blogs?
Parts 3 and 4 of my blog series about migrating from RBAC to ABAC have been published at the nixu site:
Part 3 About the need for dynamic access rules
Part 4 Using roles as attributes
Enjoy these reads and feel free to contribute to the discussions!
Parts 3 and 4 of my blog series about migrating from RBAC to ABAC have been published at the nixu site:
Part 3 About the need for dynamic access rules
Part 4 Using roles as attributes
Enjoy these reads and feel free to contribute to the discussions!