Kiteworks Told Customers to Power Off With No CVE and No Indicators. Capture the Evidence First.

Powering a suspect appliance off for nine hours destroys the only evidence that can answer the question you will be asked on Monday: was it already compromised before we pulled the plug? Memory goes first, then the process table, then whatever a webshell was holding open. The disk survives. Very little else does.

That is the position Kiteworks customers were handed on Friday. The company emailed them to recommend a nine-hour precautionary shutdown in local time, anchored on a coordinated window of 02:00 to 08:00 UTC on Saturday, September 26. Organizations on the US East Coast were given 10:00 pm Friday through 4:00 am Saturday. Central Europe got 04:00 to 10:00 Saturday morning. Customers who self-manage the product, on premises or inside their own AWS or Azure tenant, had to perform the shutdown themselves. Kiteworks powered down the instances it hosts on its customers' behalf.

The stated reason was deliberately thin. In its public advisory, Kiteworks said it had received "credible threat intelligence from federal intelligence authorities indicating that a threat actor may attempt to target some Kiteworks systems." CISO Frank Balonis added that "we have no indication that Kiteworks or our customers' systems have been compromised, so this advisory is preventative rather than a response to a confirmed breach." The company pointed customers at release 9.5.1, which it says carries fixes for every vulnerability it knows about.

What nobody published was a CVE identifier, an affected version range, or a single indicator of compromise. The Sophos Counter Threat Unit wrote up the advisory and could add nothing beyond telling customers to follow the vendor email. The FBI declined to comment to TechCrunch, and a CISA spokesperson declined to speak on the record. Defenders were asked to take a production system offline on trust.

Who this reaches, and who can close the tab

Close the tab if Kiteworks hosts your instance. The vendor executed the shutdown for you and there is nothing on your side of the line. Close it as well if the product you actually run is Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai or 123FormBuilder. Kiteworks named each of those subsidiaries as outside the scope of the warning.

This one is yours if you run a self-managed Kiteworks appliance, wherever it sits. It is yours on a slower clock if you run any internet-facing managed file transfer product at all, because the decision Kiteworks compressed into a Friday afternoon is the decision every one of those teams eventually gets, usually with less warning. The specific vendor here matters far less than the shape of the request.

One limit worth stating plainly: nobody outside the briefing knows whether a Kiteworks zero-day exists. The vendor says it has no evidence of compromise, and no researcher has published a bug. Treating the advisory as confirmation of an active exploit would be wrong. Treating it as a live fire drill for a scenario that hits this product class repeatedly is correct.

The base rate that should set your posture

Managed file transfer is a small slice of the software world and an outsized slice of the damage. Pull the CISA Known Exploited Vulnerabilities catalog and count. Of 1,726 entries in the September 25 release, 19 belong to file transfer and secure file sharing products: Accellion FTA, Fortra GoAnywhere, Progress MOVEit, Cleo, CrushFTP, SolarWinds Serv-U, IBM Aspera Faspex, and Citrix ShareFile.

Thirteen of those 19 carry CISA's "Known" flag for use in ransomware campaigns. That is 68 percent. Across the whole catalog the rate is 21 percent. A file transfer bug that reaches KEV is roughly three times more likely to end up in an extortion campaign than an average KEV entry, and the pattern has held every year since 2021. Run it yourself:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o kev.json

python3 - <<'PY'
import json
kev = json.load(open("kev.json"))["vulnerabilities"]
names = ("FTA","GoAnywhere","MOVEit","Cleo","CrushFTP","Serv-U",
         "Aspera","ShareFile","Content Collaboration")
mft = [v for v in kev
       if any(n.lower() in v["product"].lower() for n in names)
       or v["vendorProject"] == "Cleo"]
ransom = sum(1 for v in mft if v["knownRansomwareCampaignUse"] == "Known")
print(f"file-transfer KEV entries : {len(mft)}")
print(f"  known ransomware use    : {ransom} ({100*ransom/len(mft):.0f}%)")
print(f"catalog-wide ransomware   : "
      f"{100*sum(1 for v in kev if v['knownRansomwareCampaignUse']=='Known')/len(kev):.0f}%")
for v in sorted(mft, key=lambda x: x["dateAdded"], reverse=True):
    print(v["dateAdded"], v["cveID"], v["vendorProject"], "/", v["product"])
PY

The reason is structural. These boxes sit on the public internet by definition, they authenticate strangers, they hold the files an organization already decided were too sensitive for email, and they are usually owned by an IT team rather than a security team. An attacker who lands on one skips lateral movement entirely and goes straight to the data.

Kiteworks carries the specific history too. The company was Accellion until late 2021. In February of that year CISA, the FBI and partner agencies in Australia, New Zealand, Singapore and the United Kingdom published advisory AA21-055A on mass exploitation of the Accellion File Transfer Appliance through four bugs: CVE-2021-27101, CVE-2021-27102, CVE-2021-27103 and CVE-2021-27104. One line in that advisory matters more than the CVE list. The webshells attackers deployed could "send commands to targeted devices, exfiltrate data, and clean up logs."

Three options, and what each one costs

The vendor recommended exactly one course of action. There were three available, and the right answer depends on what your telemetry looks like, not on what the email said.

Power it off cold, as instructed

This is the lowest-risk option for preventing exploitation and the highest-cost option for answering questions afterward. A guest shutdown flushes RAM, kills every established connection, and clears the process table. If an attacker was already resident with an in-memory implant, the shutdown removes the implant and the proof of it in the same second. You get safety and amnesia together. It is the correct default for a team with no forensic capability, because the alternative is leaving an exploitable box exposed to protect evidence you could not have collected anyway.

Cut it off at the firewall and leave it running

Drop inbound and outbound at the perimeter and keep the guest powered. Exposure closes within a minute of the rule change, and memory, connections and process state survive for collection. CISA's own Accellion guidance lists "temporarily isolate systems from internet access" ahead of anything else. The cost is that you must be confident in the isolation: a management interface on a second NIC, an out-of-band update channel, or a site-to-site tunnel you forgot about will quietly keep the box reachable. Verify the block from an external host before you claim it.

Leave it up and watch harder

Defensible only if you already have full packet capture or rich flow data on that network segment and somebody rostered to watch it live through the window. For nearly every team reading this, that describes an aspiration rather than an arrangement. Choosing this option because a shutdown is inconvenient is how organizations end up with neither protection nor evidence.

My recommendation for a self-managed deployment is the second option first and the first option second: isolate, snapshot, then power off inside the vendor's window. That sequence costs about fifteen extra minutes and preserves everything the third option was supposed to give you.

Take the evidence off the box before the power button

On a hardened appliance you rarely get a root shell, so most guest-level forensics are unavailable. Work at the layer below it instead. On VMware, a snapshot that includes memory captures the full RAM image of a running guest, which a graceful shutdown would have discarded:

# VMware: find the VM, then snapshot WITH memory (4th arg = 1) and no quiesce.
vim-cmd vmsvc/getallvms | grep -i kiteworks
vim-cmd vmsvc/snapshot.create <vmid> "pre-shutdown-2026-09-26" \
        "precautionary advisory, memory included" 1 0

# AWS and Azure snapshot disk only; RAM is lost either way, so pull
# whatever the appliance will export before you stop the instance.
aws ec2 create-snapshot --volume-id vol-0abc123 \
    --description "kiteworks pre-shutdown 2026-09-26"
az snapshot create -g rg-mft -n kiteworks-pre-shutdown \
    --source /subscriptions/.../disks/kiteworks-osdisk

Then collect what already lives somewhere else, because that is the material a power cycle cannot touch. Your firewall or NetFlow collector holds every destination the appliance contacted. Your reverse proxy or load balancer holds the request paths. Your DNS resolver holds the lookups. None of it is on the appliance, so none of it dies with the guest.

# Every distinct external peer the appliance talked to in the last 30 days,
# from flow records rather than from the box itself.
nfdump -R /var/cache/nfdump -t 2026-08-27/2026-09-26 \
       "src ip 10.20.4.15 and not dst net 10.0.0.0/8" \
       -s dstip/bytes -n 50 -o extended

# Same question against a proxy log, ranked by volume out.
awk '$1=="10.20.4.15"{b[$4]+=$6} END{for(h in b) printf "%12d %s\n", b[h], h}' \
    /var/log/proxy/access.log | sort -rn | head -40

Sort the results by bytes outbound, not by hit count. Exfiltration through a file transfer appliance looks like a small number of very large sessions to a destination the box has no business reaching.

What to check on the way back up

Restarting is the part most teams treat as a non-event. It is where a persistent foothold becomes visible, if anyone looks.

Six checks before the appliance carries traffic again

• Confirm the build. Verify the running version is 9.5.1 or later, and record the build string in the ticket. "We think we were current" is not an answer you want to give a regulator.
• Diff the web root. Compare file inventories against a known-good manifest or the vendor image. Accellion's attackers left webshells in exactly this kind of directory, and the 2021 shells were built to erase their own log entries.
• Audit accounts and tokens. List every administrator, service account, API key and integration token, and match them against a roster someone recognizes. A new account created during an unmonitored window is the cheapest persistence an attacker can buy.
• Rotate the credentials the appliance holds. LDAP or Entra bind accounts, SMTP credentials, object storage keys, SSO signing certificates. These are the assets that make an MFT box valuable after the initial access is gone.
• Write down the log gap. Record the exact start and end of the outage in the incident record. A nine-hour hole in your timeline is defensible when documented and indefensible when discovered later by someone else.
• Re-verify the egress rules. Whatever posture you set for the outage, confirm the production rules came back as intended. Emergency changes made at 10:00 pm are the ones that never get reverted.

Prove it with something you can rerun

# External view of the appliance after restart: what is actually listening?
nmap -Pn -sT -p- --open -T4 mft.example.com

# Compare against the port list you expect. Anything extra is the finding.
diff <(nmap -Pn -sT -p- --open -oG - mft.example.com \
        | awk -F'[ /]' '/Ports:/{for(i=1;i<=NF;i++) if($i=="open") print $(i-1)}' \
        | sort -n) \
     expected-ports.txt

Write the power-off runbook before the next vendor email

The uncomfortable part of this weekend was not the shutdown. It was how many teams discovered, at 9:00 pm on a Friday, that they had no agreed procedure for taking a production system offline on a vendor's word, no named person who could authorize nine hours of downtime, and no list of what to capture on the way out. Kiteworks gave its customers several hours of notice, which is generous. The next advisory of this kind may give you thirty minutes.

Pick your two or three most exposed internet-facing systems this week and write one page for each: who authorizes an emergency outage, what gets snapshotted and where, which off-box telemetry gets exported, who notifies customers, and what gets verified before the service returns. That page takes an afternoon to write and it is the difference between a controlled outage and a scramble. If you want a second set of eyes on the version you write, or help building the incident response plan it belongs in, that is work we do.