How to Bring a File-Transfer Server Back Online Safely After a Precautionary Shutdown

Kiteworks lifted its precautionary shutdown advisory on 27 September 2026 with a short instruction: if you have not already restarted, you may bring your system back online, and if you self-host Advanced Forms, contact support first. That is the vendor's job done. Yours is different. A server that was taken down because an attack was expected should come back up as a system under suspicion, not as a system that happened to be rebooted. This guide lays out a restart sequence for a managed file transfer (MFT)Managed File Transfer (MFT)🛡️A platform for moving files between organizations or systems with authentication, encryption, audit logging and retention controls. Because MFT servers are internet-facing and hold current copies of regulated data, they are a favored target of data-theft extortion groups. server or any similar internet-facing data platform after a precautionary shutdown.

Before you power anything on

Decide what "clean" means for this system and write it down. In the Kiteworks case the vendor said there was no indication of compromise, but the intelligence concerned an actor who intended to attack; nobody has said when that actor acquired the capability. Your baseline should be the last point at which you have positive evidence the server was in a known-good state: a verified backup, a fresh build, or a configuration snapshot you can diff against.

Confirm with the vendor, in writing, three specifics: whether the fix applies to your deployment model (hosted, on-premises, cloud-hosted), whether any compensating controlCompensating Control🛡️A security measure applied in place of a primary control that cannot be implemented yet, such as network restriction while a patch is unavailable. It reduces risk to an acceptable level without fixing the underlying flaw. they applied covers your environment, and whether the affected module is licensed or enabled on your instance. Do not assume a version number tells you this. Kiteworks said release 9.5.1 addressed all known vulnerabilities before the Advanced Forms flaw was identified; being on that version predates the fix that matters.

Check that the shutdown actually happened. Virtual machines can be paused rather than stopped, cloud instances can be restarted by autoscaling, and a hosted instance may have been handled by the vendor on a different schedule. Pull the hypervisorHypervisor🌐Software that creates and manages virtual machines by allocating physical hardware resources among multiple guest operating systems. VMware ESXi is a Type 1 (bare-metal) hypervisor. or cloud console event log and confirm the power state for the whole window.

Restore in a controlled order

Bring the server up with its external interface blocked. A firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. rule denying inbound from the internet, or the load balancer pool member left disabled, gives you a window to inspect before anyone outside can reach the system. If the platform has a maintenance mode, use it as a second layer, not a substitute.

Verify the running version and integrity from the console. Compare installed package versions, binary hashes where the vendor publishes them, and configuration against your baseline. Any difference you did not make is a finding.

Apply the vendor fix if it is not already present, then re-verify. If the fix arrived as a hosted-side change or a "protective layer" rather than a version bump, ask the vendor how you can confirm it is active on your instance.

Examine the logs before the gap, not just after

The shutdown creates a clean boundary in your logs. Everything before it is the period during which an attacker with the capability could have acted quietly. Prioritize:

• Authentication events. Successful logins from new sources, service accounts authenticating at unusual hours, and any account created or modified in the days before the shutdown.
• Unauthenticated endpoints. Form submissions, anonymous uploads, self-registration and public API calls are where a pre-authentication exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. arrives. Look for oversized or malformed submissions, unusual content types, and requests to paths that do not correspond to a published form.
• Web server errors. Exploitation attempts against a parser or input handler tend to leave 500-series errors, stack traces or crash-and-restart events before they succeed.
• File system changes. New files in web-accessible directories, scripts in upload folders, and modified timestamps on platform binaries. A web shellWeb Shell🛡️A malicious script placed in a web server's content directory that lets an attacker execute commands through HTTP requests. Web shells are a common persistence mechanism after remote code execution and are detected by looking for unexpected files in webapp directories. dropped through a form upload is the classic artifact.
• Outbound connections. An MFT server's egress should be predictable. Any connection to an address that is not a known integration partner deserves an explanation.

If the logs were only held locally on the server, accept that an attacker who got in could have edited them, and weight the off-box copies accordingly. This is the moment to fix log shipping if it was not already in place.

Rotate what the server knew

Assume the server's secrets are exposed unless you can prove otherwise. That means the service accounts it uses to reach internal shares, directories and databases; API keys and integration tokens for connected systems; the TLS private key if it lives on the box; and any administrator credentials used during the incident window. Rotation is cheap relative to the cost of leaving a stolen credential in place, and it turns an uncertain "probably fine" into a definite state.

Review the platform's stored data too. Files retained on an MFT server are the target; if retention was long, consider whether files that had already been delivered can be purged now, before the system is exposed again. The companion piece on why managed file transfer platforms are an extortion crew's favorite target explains why the retained data, not the server, is what the adversary wants.

Reopen, then watch harder than usual

Re-enable external access only once the version, integrity, logs and credentials have been reviewed and signed off by whoever owns the risk. Then raise the monitoring posture for at least a few weeks: alert on the same categories you reviewed above, in near real time, and keep a person responsible for reading those alerts. An actor who lost a window may try again once systems are back.

Document the whole sequence with timestamps. If a compromise is later discovered elsewhere in the fleet, your record of what was checked and when is what separates a contained incident from an open-ended one.

Fix the design gap while it is fresh

The Kiteworks episode demonstrated that when a vendor cannot disable a single feature remotely, the only mitigation is a full shutdown. Take the opportunity to ask your vendor for per-module controls and to confirm you can disable optional, unauthenticated-facing features yourself. Then take a hard look at your own inventory: the learn article on why an optional module few customers use can still be your front door covers how to find the features you did not know were exposed.

A precautionary shutdown is an unusual event. The restart afterwards should be a routine one, because you have rehearsed it. If this was your first time, write the runbook now while every step is still fresh, and put a date on the calendar to test it.