From the desk of: Sam C. Chan
 

Bravo CryptoWall SIR Guidelines

Published:   Nov. 5, 2014
Last Revised:   Feb 5, 2015 (incorporated 2.0 & 3.0 info)

Based on my original analysis. This is a checkist to convey the subtle but critical conceptual points. It is also a field-tested strategic- & tactical-level guideline. Not a tutorial!  (See also multiple addenda at the end)

Prospect of Permanent Data Loss

  • restore from backup
    • geographic proximity of backup media, or bandwidth from backup server
    • age & physical condition of media
    • restore point range: retention period
    • restore point granularity
    • restore time + verification/review
    • selective repopulation of most recent "journal" to be nearly seamless
    • other advanced "surgical" techniques
    • triage: phased restores
  • forensically recover & reconstruct deleted files
    • massive quantity and duplicated versions to wade thru
    • must create custom signature (file header area) for unusual file formats
    • partial recover, as some will be perm lost
    • concern over risk of corrupted data (misconstruted cluster chains)
  • pay ransom: successful restore hinges upon...
    • able to complete the payment process via Bitcoin
    • actually obtaining the correct PKI private key (RSA 2048-bit)
    • encrypted copy was successfully generated and written by attacker
    • all your attempts to repair/clean/recover thus far have not harmed those preserved encrypted copies

Mitigation Strategies

  • Pertaining Data Resilency
    • direct local storage areas isolation
      • delete mapped drives (it targets drive letters, not UNC)
      • disconnect external drives
      • isolation via advanced ACL:
        • dropbox style simplex write-only
        • mutual hold but untouchable: double simplex access
        • for QB, which manages rotation: use secondary simplex copy to final  destination
        • off-host (but not necessarily off-site, as it's irrelevant) backup
      • multi-generational versioning scheme
        • extend retention period before rotation, to guard against future case with latent discovery
        • already past proof-of-concept stage, in-the-wild for targeted attacks
        • likely implemented in 4.0 or later versions, especially
        • when pay-thru ratio wans, as more victims have backup
      • stop cloud sync, which assists spread of droppers
      • do not attach any external HD/USB thumb drive
        • until AFTER ALL affected stations are declared clean
        • --even if the missing data is urgently needed!
      • if emergency backup is performed during SIR,
        • never use any Sync process
        • certified non-destructive unconditional copying ONLY.
    • LUA
      • prevents VSS copy sabotage
      • no system-level cross-profile infection
      • severely hampers dropper stage penetration and propagation
  • Other Threat-Specific Countermeasures
    • Group Policy/Local Security Policy (gpedit.msc/secpol.msc)
      • ban executables in certain known locations
      • must cover multiple temp folders in user profile
      • requires custom whitelisting, and on-going maintenance
    • block known IP of C&C hosts (brute force)
      • host-level application-/folder-based outbound control
      • perimeter destination-based outbound control
    • feign Virtualization to foil attempt at Dropper stage
    • GHOST or Windows System Image
    • all the usual end-user best practices

Incident Handling Stages

  1. assessment
  2. containment (perimeter, NIC cables, usr-acct, fw, ACL, shares, ext dev, NAS)
  3. preserve
  4. investigate
  5. repair
  6. verify & certify clean
  7. restore
  8. debriefing
  9. follow-up & planning
 
 
 
 

Copyright @2005-2006   Bravo Technology Center  *  Bravo:GO  *  Contact Us