Published by Phill Moore, Digital Forensics and Incident Response on 3 October 2025
Imagine one morning you get a phone call from the CEO of your company. Emails are working but that’s just about it. No one can access any of their files, the systems aren’t responding and you need to fix it.
What do you do?
Unfortunately, the first instinct would be to panic and try to fix it all as quickly as possible. And ideally you do fix it as quickly as possible, but not by skipping steps in the incident response life cycle.
At a high level, Incident Response frameworks list detect or identify as the first stage during incident response, followed by contain and remediate prior to recovery. After a ransomware attack, identifying that you’ve had an incident is pretty simple – nothing is working, and your organisation’s data is encrypted.
Some limited analysis can be performed by most IT administrators, however what happens if you immediately start to restore services and ‘recover’ too quickly?
Reference – Australian Signals Directorate: Cyber security incident response planning: Practitioner guidance
Why can’t I just restore from backup?
In our 2025 Threat Report which draws out trends and insights from the major incidents we responded to last year, CyberCX found the average dwell time in 2024 in a cyber extortion attack involving ransomware was between 7 and 17 days. Unfortunately, by the time the ransomware runs (and encrypts your data), the attacker has in most cases been inside the network for some time. During this time, attackers will setup backdoors so that they can easily come-and-go as they please. By restoring a backup after ransomware has run, you might just be letting the attackers come right back in with the added knowledge that they didn’t properly delete your backups.
Threat actors can leave behind malicious software or legitimate remote monitoring and management tools that blend in with the rest of the environment. They may have obtained all the credentials in the network rather than just the one you know about, and without identifying their likely initial access vector it’s hard to say that you have remediated the incident completely. They may have even set up additional users, both local and in your Active Directory.
CyberCX has recently assisted organisations that went through the pain of a ransomware incident twice, because of a rush to restore operations without knowing the full extent of the damage, prior to engaging our DFIR team. After the DFIR team was engaged, we were able to understand the actions taken by the attackers which in turn informs appropriate restoration and remediation strategies.
Ransomware against a small business
Recently, CyberCX’s DFIR team assisted a small business that was hit by a ransomware incident. The local IT provider identified that ransomware had run overnight and quickly sought to recover the data from backups before anyone noticed. They succeeded and the practice was up and running with no down time.
A great success! Until it wasn’t… Unfortunately, the attackers had installed AnyDesk, a commonly used legitimate remote management tool, onto a few of the workstations. This allowed them to return the next night and encrypt the network again. This happened a couple more times before the IT provider realised they were out of their depths and called for help.
We jumped into action, locking down the network and restricting internet access while we hunted for the various entry vectors and persistence mechanisms that could be exploited to further damage the business. In the end they could continue to operate with restricted internet access and rebuilt the affected systems without the risk of a repeat offence. However unfortunately by this point data had been taken already, which is very common in today’s cyber landscape.
Persisting in the cloud after ransomware strikes the network
CyberCX’s DFIR team was engaged after a business was impacted by their second ransomware incident in as many months. A month prior they had their on-premise network encrypted and admins locked out of administration consoles. After a lot of work they were able to rebuild Active Directory and other services to restore operations.
Unfortunately, unbeknownst to them, while the attackers were in the network they were able to access one of the Domain Administrator’s workstations and create a new Global Administrator account to the corporate Entra tenancy. In this case, there was no direct connection between Active Directory and Entra so no one thought to check whether Entra was affected during the first incident. This is something to be wary of as there are many stories of attackers remaining within the network and monitoring incident response communications through compromised Microsoft 365 accounts.
With the keys to the kingdom in Entra they were able to create additional accounts for persistence as well as Entra enterprise applications. After a short period, they installed a backup application into the tenancy and downloaded all the data in SharePoint before deleting the online data.
The first indication that this had occurred was a series of emails alerting the business that a large amount of data was being deleted from SharePoint. Thankfully with backups still available, and an Incident Response team on call, they were able to restore operations and root out the malicious persistence mechanisms that had been setup in Microsoft 365.
What does this mean for you?
During an incident, identifying what happened matters. There’s a reason why the Incident Response models start with Preparation and end with Lessons Learned.
At a minimum we recommend:
- Incident response processes should be documented and defined, with annual testing, to ensure that staff are aware of how to proceed in the event of a major incident.
- Organise a workshop with our Cyber Capability Education and Training team to understand how your organisation might deal with a ransomware attack and test decision making at both an operational and executive level.
- Ensure you have appropriate security controls, including system visibility via endpoint monitoring and log aggregation platforms, as well as ensuring actively used systems are patched and up-to-date.
And lastly, if you’re organisation is experiencing a ransomware attack, contact a reputable Incident Response organisation to assist you. The CyberCX DFIR team does this kind of work day-in-day-out, so will be able to walk you through the steps that ensure you can restore operations as soon as possible. If you choose to restore operations without understanding the extent of the damage, and without ensuring that your organisation’s systems are secure, you run the risk that you will have to do it all over again.
