MYTHOSAI

Incident recovery / PRACTICAL GUIDE

Plan a known-good rebuild of an affected computer

List trusted installation sources, recovery data and account changes before reusing a compromised device.

Before you start

Authority to rebuild the computer, verified backups and the operating system's supported installation media.

Define what known-good means

Rebuilding replaces a computer's software environment using trusted installation sources and an approved configuration. It is different from deleting one suspicious file and hoping the rest is unaffected. The plan must also account for identities, restored data and the original route of compromise.

Do not start by erasing evidence that the incident owner still needs. Agree on collection and recovery priorities before changing the affected device.

Prepare before wiping

  1. Identify the operating system, required applications and genuine installation sources. Use official vendor media and record the intended supported versions. Avoid an image copied from an unverified download site.
  2. Identify which business data must be restored and which backup points are appropriate. Preserve necessary encryption recovery material securely, and check the recovery route before destroying the only accessible copy.
  3. List credentials, sessions and integration secrets that may need revocation or rotation through trusted systems. Reinstalling Windows or Linux does not automatically secure a compromised online account.
  4. Agree on the authorised rebuild method and a verification checklist. Include updates, device protection, required settings and normal business application tests.

Restore selectively

Recover required data through the approved process rather than blindly restoring every executable, script and old configuration. A backup taken after compromise may contain the same unwanted material. Assess the appropriate recovery point with the responder and document any uncertainty.

Verify before reconnecting fully

Check update status, supported protection settings and required application behaviour. Reintroduce network access according to the recovery plan and watch for the original suspicious symptoms. A quiet system during a short test is not proof that every external account or related device is unaffected.

Close the original entry route

If compromise involved an exposed service, unsupported software or stolen credentials, address that issue before returning to ordinary use. Otherwise the rebuilt device can encounter the same problem again. Record the change and the evidence that it took effect.

Keep a recovery record

Document installation sources, version, restored datasets, rotated access and acceptance tests. Avoid inventing a clean bill of health where testing was limited. The strongest rebuild outcome is a reproducible trusted configuration and a functioning business workflow, with remaining risks and follow-up actions visible to the owner.

Official references

Consult the current vendor documentation if your version or screen differs.

Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.