Who Can Sign Off a PEERSTITCH Recovery?
Unit 42’s 14 October 2026 report traces a September 2024 intrusion at one telecoms provider. Attackers stole FortiManager configurations and trust material covering more than 500 FortiGate firewalls, not 500 confirmed compromises. Client networks were not examined.
An incident manager needs to distinguish what was repaired from what the organisation can now substantiate. That is also a communication problem: a customer needs to know which conclusion they are being asked to accept.
The documented chain has two different prerequisites
Unauthenticated CVE-2024-47575 opened FortiManager. Recovered credentials enabled re-entry; authenticated administrative CVE-2025-61624 path traversal then enabled PEERSTITCH on selected firewalls.
The implant patched logging and VPN daemons in memory, leaving no persistent binary, listening port or self-originated outbound connection. Unit 42 publishes memory, daemon-integrity and configuration-history hunting guidance.
The dates describe the intrusion and the report, not disclosure dates inferred from CVE numbers.
Do not turn an incomplete record into an all-clear
Unit 42 assesses management impersonation with medium confidence: either another authentication bypass or reuse of stolen trust. It cannot distinguish them and does not attribute the operation.
BlackTree recommends a recovery record with separate conclusions and named acceptors. In a hypothetical provider handover, one engineer might accept the platform rebuild while a customer representative still awaits an investigation result. Neither signature should erase the unfinished obligation owned by the other.
For example, suppose a customer report contains three claims: the maintenance job completed, a particular investigative question was answered, and a contractual notification was delivered. Give each claim its own dated evidence and owner. If the last two are unresolved, state that explicitly rather than translating the first result into an overall green status.
Make evidence survive the handover
Preserve volatile evidence where safe; rotate exposed credentials, keys and certificates and re-establish management trust. Patching alone is not recovery.
For the hypothetical handover, attach evidence references rather than copying sensitive material into a widely shared ticket. Record who collected each item, its scope, where it is retained and who is authorised to review it. A customer-facing summary and a restricted investigation record need not contain the same detail, but their conclusions must not contradict each other.
Have a second reviewer test the wording as a claim, not as a description of effort. “Completed” should refer to a defined obligation. “No evidence found” needs the examined scope. “Not examined” must remain visible. This is an acceptance method, not a claim that the provider in Unit 42’s investigation followed it.
Close the right obligation
A useful final handover leaves the next owner with a decision they can reproduce: which question was settled, what supports that conclusion and what remains outstanding. A meeting note saying that everyone is comfortable is weaker than an explicit unresolved question with an owner and a review date.
The practical test is whether a customer can understand the boundary of the assurance being offered without attending the incident call. If they cannot, the communication is not finished, even when the underlying engineering task is.
Primary evidence
Unit 42’s PEERSTITCH investigation. The exact vulnerability records are linked above; they are not a substitute for the incident report.
