When ransomware changes file extensions and adds a note

A ransomware incident can look deceptively simple: report.docx becomes report.docx.locked, while READ_ME.txt appears beside it. The suffix may hint at the malware family, but it does not prove that every file is encrypted or that the note is genuine. Stop further damage without destroying evidence.

Ransomware may also delete shadow copies, steal credentials, and spread through remote-access tools. Use a separate clean device for account recovery and backup checks. These steps cover containment, recovery, Australian obligations, and repeat prevention.

Identify the extension pattern and ransom note

Record the exact changed suffix, old and new filenames, the note's name, and the date and time. Check whether the suffix was appended or replaced, and whether the note is .txt, .html, or .hta. Do not double-click the note or a renamed executable; active content can run code. The malware removal guidance helps distinguish a ransom note from an operating-system warning.

Compare a copied, non-critical file with an earlier version. Unchanged size and readable contents suggest a rename; changed size and unreadable contents suggest encryption. A note claiming total destruction is not proof. Keep samples and the note, but assess the incident before following payment instructions.

Contain the affected device

Disconnect the computer from Wi-Fi, Ethernet, and VPN, then unplug external drives. From a clean device, pause OneDrive, Google Drive, Dropbox, or other file synchronisation so encrypted copies are not uploaded. Do not reconnect the infected machine to run antivirus or test a backup.

If files are still changing, keep the machine isolated and ask an experienced responder whether to leave it powered on, since a key may be in memory. Record the last activity, terminate any remote session, and preserve logs. Change important passwords and revoke sessions from the clean device.

Secure accounts and cloud services

Ransomware commonly abuses email, Microsoft 365, Google Workspace, VPN, and remote-support credentials. Reset administrator, email, cloud, and remote-access passwords from a clean device; enable multi-factor authentication, remove unfamiliar devices, and revoke active sessions.

Identify the last known clean state before restoring anything. Test offline or immutable backups on a separate network, and check version history for documents and folders. A backup connected during the attack may contain encrypted files and could reintroduce malware.

Observation	Likely explanation	Practical response
Original name retained with a new suffix	Files may be renamed	Compare a copied sample with an earlier version and preserve the mapping.
Size changed; contents will not open	Encryption or destructive change is likely	Keep a sample, isolate backups, and investigate a decryptor for the exact variant.
Only shortcuts or selected folders changed	The attack may be partial	Do not execute affected items; inspect them from a clean environment and review logs.

Determine whether files are encrypted or renamed

A changed extension alone cannot establish the damage. In a safe copy, compare file properties with a document created before the incident. If size and contents are unchanged, the file may only have been renamed. If contents are unreadable binary data, treat it as encrypted until a specialist says otherwise.

Keep a mapping of old names to new names when contents survived, but do not bulk-rename everything. Ransomware may have changed directories, altered selected file types, or affected backup copies. A clean rebuild is often safer than repairing hundreds of mismatched names.

Investigate decryptors and recovery paths

No single decryptor handles every extension pattern. Identify the malware family, note wording, operating system, and representative samples, then check whether a reputable researcher released a tool for that exact variant. Confirm it through a trusted security source. The ransomware recovery guidance explains how to collect these details without exposing confidential files.

Try clean backups, snapshots, and versioned storage before considering payment. Do not upload encrypted files, credentials, or customer data to an unfamiliar “free decryptor” site; some are stealers or scams. Payment does not guarantee a usable key. Even without a decryptor, preserve samples, the note, logs, and backup metadata for insurers, investigators, or a later release.

Follow Australian reporting and business guidance

A business incident should be managed as a cyber security event, not a desktop support ticket. The Australian Cyber Security Centre provides advice and an incident-reporting route at cyber.gov.au. Large organisations should involve legal counsel, cyber insurers, and their managed service provider; small businesses can use Australian IT support and ACSC resources.

If renamed files held personal information, the Privacy Act 1988 and Notifiable Data Breaches scheme may require notification to the Office of the Australian Information Commissioner and affected people. Relevant state or territory regulators can advise on privacy duties. Teams in Sydney, Melbourne, Brisbane, and Perth should keep one incident log and record Australian Eastern Standard Time or daylight-saving time.

Importers and exporters should preserve records used for customs and supply-chain documentation and seek legal advice before notifying overseas partners. If Australian Customs and Border Protection systems are involved, use the organisation's official incident contacts rather than public forums. Australian businesses often rely on Microsoft 365, Google Workspace, and remote-access products, so account recovery must include those services.

Build a recovery and prevention checklist

Recovery works best when facts are captured before devices are wiped or files are renamed. Record the extension pattern, note details, affected accounts, backup locations, and every action taken. Keep original media disconnected or read-only where practical, and make a second evidence copy before repair attempts.

Record these details

• Exact old and new filenames, including the changed suffix
• Ransom-note name, creation time, and affected operating systems
• The last known clean backup and available version history
• Accounts, devices, and third-party services involved

Then reduce repeat infections

• Use phishing-resistant multi-factor authentication for administrators and email
• Separate backup credentials and test restoration on an isolated network
• Patch systems, remove unknown remote tools, and restrict executable extensions
• Segment networks and limit access to shared business folders

After recovery, validate the clean device, accounts, and backups before restoring normal operations. A known-clean environment, documented evidence, and tested recovery copies turn a threatening note into a manageable incident.