The Warning Signs Before Ransomware Strikes

KEEPING SAVANNAH MOVING · INVESTIGATION 4 OF 8

Imagine the first trucks are due out in an hour. Dispatch can still open the shipment schedule, but its provider sees an account connecting to a server it does not normally manage. A backup setting has also changed overnight. There is no ransom note. In this hypothetical Savannah freight business, the question is already urgent: who will check what happened, and what are they authorized to do?

Original AI-generated editorial illustration of a hypothetical freight dispatch office.

In Part 3, How Ransomware Spreads Through a Business, we followed the access that can turn one compromised workstation into a wider outage. This installment asks how a business might notice suspicious activity and get it to someone who can respond. The Coast Guard’s 2019 bulletin did not provide a log-by-log timeline or identify missed alerts at the unnamed maritime facility. The examples here illustrate broader guidance; they do not reconstruct that incident.

Start with an account behaving differently

Start with the dispatcher’s normal work. The account needs shipment instructions and customer communications. An attempt to administer an unfamiliar server deserves an explanation. Has the employee changed roles? Is an approved support session underway? Did someone grant permissions the job does not require?

An unfamiliar sign-in location, repeated failed logins or a new remote-support application can each justify a closer look. None independently establishes ransomware. A traveling employee, mistyped password or legitimate vendor visit may explain the event. Record the account, device, time, requested resource and result so the person reviewing the alert can check the explanation.

The joint guidance on event logging and threat detection identifies unusual account access and unexpected security changes as behaviors worth investigating. If the same account reaches several servers shortly after gaining new privileges, the connected events deserve more attention than an isolated failed login. They still do not establish which attacker or malware is involved.

Notice changes to recovery and security controls

MITRE’s Ryuk profile records behaviors including stopping services, interfering with recovery copies and encrypting files. Those observations help defenders choose what to investigate. They do not mean that every service stop is malicious or that a particular signal will provide advance notice.

For our logistics company, an unplanned backup-retention change, a security tool unexpectedly stopping or a recovery job disappearing should have an explanation. Ask who made the change, whether it was approved and what it affects. These events may reflect maintenance or a fault, but an unexplained change to the systems that protect or restore the business deserves prompt review.

A wave of inaccessible shipment files, unfamiliar file extensions or ransom notes may mean damage is already occurring. Escalate through the incident process immediately. The CISA and partners’ #StopRansomware Guide calls for coordinated isolation of affected systems and preservation of evidence. Employees need a reporting route; the designated responder should direct containment. Keep operational safety in view when a system supports physical equipment.

Collect records that can answer business questions

The joint logging guidance recommends useful event details, consistent timestamps, centralized collection and appropriate retention. In practical terms, the reviewer needs to connect an account, a device, an action and its result. A collection of alerts with no underlying records may leave crucial questions unanswered.

Begin the conversation with your most important workflow. For dispatch, can you review sign-ins to the business account, endpoint-security alerts from the workstation, relevant server activity and changes to backups? If the shipment application is a cloud service, determine what its audit records actually show and whether your provider receives them. A workstation agent does not establish visibility into every connected application.

Ask the provider to show how it knows those records are still arriving. A quiet dashboard could mean a quiet day, an offline device or a broken connection. Agree how missing data is reported, how long relevant records remain available and who may access them. Record any gaps alongside the systems you rely on.

Give the alert an owner and a decision path

NIST’s Small Business Quick-Start Guide asks organizations to establish incident-response authority and responsibility. Apply that directly: name the person who first reviews an alert, the person who can approve containment and the backup contact if either is unavailable.

For a small operation, this might mean an outside provider investigates while the owner approves taking a dispatch workstation out of service. Agree which urgent actions are authorized in advance. Record how the provider reaches the owner if company email is unavailable, and who explains a resulting delay to the customer.

Also distinguish continuous data collection from staffed review. Ask about coverage hours, after-hours escalation, expected acknowledgment and response times, and the systems included in the agreement. A dashboard can display an alert while nobody is available to investigate it. If your dispatch team starts before the help desk opens, decide how an urgent report reaches a responder during that gap.

Test the route from event to response

Choose a noncritical test workstation and agree on a harmless event with the provider. For example, change a designated test file only after confirming that a file-change detection rule is configured. Define the expected record, alert, recipient and response before running the exercise. A product’s test-notification button may check delivery alone; document exactly which stages your chosen test exercises.

Figure 1. Trace one harmless test through collection, detection, review and authorized action. A notification-only test verifies only the stages it exercises.

1. Confirm the source event identifies the expected device, account and time.

2. Find the collected record and the alert produced by the intended rule; record when each arrived.

3. Have the assigned reviewer acknowledge the alert, inspect the evidence and document a decision.

4. Confirm the agreed escalation reaches the owner or backup contact. Record any delay or missing step and assign a correction.

This exercise proves only that the tested stages worked under those conditions. It does not measure detection of every ransomware technique or guarantee warning before damage. Do not introduce malware, delete real recovery copies or disable production protection. Discuss how the same response would work outside the test window, including the hours when your business operates.

A useful result this week is one completed alert exercise and a short record of the gaps it exposed. Give each gap an owner and a next step. The next time dispatch receives an unusual warning, the business should know who is checking it, who can authorize action and how essential work will continue.

Next in the series: Your Backups Won’t Save You If You Can’t Restore.

Sources and further reading

• U.S. Coast Guard, MSIB 10-19, December 16, 2019

• MITRE ATT&CK: Ryuk, S0446

• ASD ACSC, CISA and international partners, Best Practices for Event Logging and Threat Detection, August 2024

• NIST SP 1300, Cybersecurity Framework 2.0: Small Business Quick-Start Guide

• CISA, FBI, NSA and MS-ISAC, #StopRansomware Guide, October 2023