How do I check whether my business is being targeted by ransomware?
Key takeaways
- A sudden spike in failed logins, followed by a success, is the classic pre-encryption pattern to watch for in business logs.
- CERT-In's 180-day log retention rule is what makes this detection possible, and a business with 30-day logs can only ever see a fraction of the story.
- Windows event ID 7045, a new service installation, and ID 4720, a new account creation, are the two most useful local triage events.
- A sudden increase in outbound traffic or bulk file downloads often precedes encryption, which is the last cheap warning you will get.
- Credential-stuffing is the dominant route in Indian SME incidents, so check whether your email, VPN and admin passwords appear in known breach lists.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
What are the early warning signs of an impending ransomware attack?
Seven, ordered by how early they appear. First, a spike in failed logins, particularly against VPN, RDP, webmail and admin panels, often followed by a success from the same source. Second, a new service, scheduled task or local account that nobody created. Third, security tooling, backup jobs or endpoint detection being disabled or uninstalled, which is deliberate anti-recovery behaviour. Fourth, a jump in outbound traffic or bulk file downloads, which suggests exfiltration before encryption. Fifth, reconnaissance artefacts: a mass password-spray across accounts, or a series of 2,000-series Windows event IDs. Sixth, partial encryption or renaming on a single host, which is often the first machine touched. Seventh, the ransom note itself, which is the point of no return. The first six are all visible in logs if you kept them.
How do I check the logs myself?
Four places, and none of them require a paid tool to start. In Windows Event Viewer, filter Security for failed logons, event 4625, and successes, 4624, from the same source; look for event 7045, a new service installed, and 4720, a new account created. In the firewall or proxy logs, look for outbound volume spikes and for a workstation talking to unusual destinations on unusual ports. In the identity provider, review sign-in risk events and MFA fatigue attempts, where an attacker repeatedly pushes a prompt to make you approve it. And in the EDR console, look for a change in agent status or policy. Do this weekly, write down what you see, and compare month to month, because the signal is a change, and a change only stands out against a baseline.
Should I check whether my credentials are already for sale?
Yes, and it is cheap. Ask staff and leaders to register their work email addresses on a reputable breach-notification service, which will alert them if the address appears in a known breach, and rotate any password that has been exposed. Separately, run a dark web exposure check on your domain and on any domain administrator accounts, which will show whether your email addresses or password hashes have appeared in credential markets. Also review any staff accounts that have left, and any personal email addresses used for registrar, cloud and banking access, since those are the accounts an attacker buys. If an old staff account with a reused password is still active, that is the most likely way you are currently being targeted.
What do I do if the indicators suggest an attack is under way?
Move straight to the incident playbook rather than continuing to investigate. Isolate the affected or suspected hosts from the network, without powering them off, because the running processes are evidence. Disable or reset the credentials used on the affected machines. Stop cloud sync clients and revoke active sessions, so encrypted or deleted state is not replicated. Then complete the CERT-In reporting obligation, which requires a log to CERT-In or a law-enforcement incident report within 6 hours of being informed, and notify your insurer within the policy window, since late notification is the leading reason claims are declined. A scoped forensics engagement before you restore tells you what was taken, not only what was encrypted.
| Indicator | Where to look | What it suggests |
|---|---|---|
| Failed login spike then success | Identity provider, VPN and RDP logs | Credential attack in progress |
| New service or account | Windows event 7045 and 4720 | Attacker establishing persistence |
| Backup job or EDR disabled | Backup console, security tooling console | Deliberate anti-recovery step |
| Outbound traffic spike | Firewall and proxy logs | Data exfiltration before encryption |
| MFA fatigue or triage messages | Identity provider sign-in risk events | Attacker trying to obtain an approved login |
| New ransom note | Shared folder or desktop | Encryption has begun, act immediately |
What are the frequently asked questions?
Get a straight answer on this
Book a ransomware targeting assessment, and we will run the log review, the credential exposure check and the containment drill with your team.
Send us the details See pricing