Web Application Attack Response Playbook

Preparation

Note: Preparation steps should primarily be completed prior to an event or incident.

1. Determine the members of the Cybersecurity Incident Response Team (CSIRT).
   1. The core CSIRT members should be comprised of individuals responsible for cybersecurity only.
      1. This may include some members of Information Technology roles, depending on the organization size.
      2. The limited size of the core CSIRT is to assist with confidentiality and efficiency.
      3. The core CSIRT may be activated often to investigate security events that may or may not result in an incident.
   2. Assign roles and responsibilities to each member.
2. Determine extended CSIRT members.
   1. This will often be Legal, Compliance, Public Relations, and Executive Leadership.
3. Define escalation paths.
   1. Incidents may start as events, or as a lower impact/severity and then increase as more information is gathered. Establishing an escalation path is critical to success.
4. Document third-party web-hosting contacts.
5. Ensure logging levels for account login system components are set to appropriate levels.
   1. 90 days should be the minimum.
6. Ensure logging for account login system components are stored in secure locations, preferably on a secondary system such as a SIEM.
7. Ensure that web application backups are functioning as expected.

Identification

1. If the web application is hosted on another service (GoDaddy, HostGator, Ionos, local hosting company, etc.) contact the hosting service to report the issue.
   1. Inquire as to any recent security issues in their environment.
   2. Inquire about any potential logs that they may possess.
      1. Obtain these logs and preserve them ASAP.
2. Use the evidence that resulted in notification of compromise to determine next steps based on method of compromise. (Some steps may be irrelevant based on the method of compromise.)
   1. Example of evidence: abnormal behavior in the web application, notification of compromise from an outside source, client report of anomalous or malicious behavior related to the web application, etc.
   2. Method of compromise examples: exploited vulnerability in web application, credential harvesting phish, credential scraping from local systems, brute forced password, etc.
3. Determine initial method of account compromise. This will be limited to those with web application management/administrative access.
   1. Interview impacted user to gather details on potential points of compromise.
      1. Example questions:
         1. Did you receive a suspicious email?
         2. Did you enter your email credentials after clicking a link, or on a website that seemed to not accept them?
         3. Have you downloaded any new software?
         4. Have you received any documents via email that you weren’t expecting?
         5. Have no noticed abnormal actions on your workstation?
   2. Search for phishing emails.
      1. Phishing emails are the most common method for credential theft.
   3. Search for emails with links to credential harvesting sites.
   4. Search the user’s web history to determine if any potentially malicious sites were visited.
   5. Search for potential malware on the user’s workstation.
      1. Credential harvesters such as Mimikatz.
      2. Keystroke recording software.
      3. Clipboard scraping malware.
4. Once method of initial compromise is determined, use the Indicators of Compromise (IoCs) gathered to search the environment for other victims.
   1. Potential query inputs for email system: Email subject name, document name, document hash, URL from email, etc.
   2. Potential query inputs for SIEM or log searches: IP addresses, URLs, workstation names, etc.
5. Review logs in account login systems searching for anomalies.
   1. Login activity from unusual locations, systems, or browser fingerprints.
   2. Note all systems accessed by the attacker if possible.
6. Assess victim accounts to determine if sensitive information may be contained in them, or if they have access to sensitive information on centralized storage such as fileservers.
   1. This may need to be extended to other sources these users and/or accounts have access to such as OneDrive, Google Drive, SharePoint, shared mailboxes, fileservers, etc.
   2. If sensitive information is a possibility, consult legal counsel for next steps.
7. Use the information gathered in Step 4b to determine what sensitive information could’ve been accessed by the attacker.
   1. If logs are unavailable, assume all accessible data was accessed by the attacker.
8. If account compromise has been ruled out, proceed to investigate potential web application vulnerabilities that may have been exploited.
   1. Perform a security scan.
   2. Review vendor notifications of security issues.
   3. Review community sourced threat-intelligence related to the components in your web application.

Containment

1. If management or administrative account compromise has been determined:
   1. Reset all passwords associated with management and administration of the web application.
      1. Begin with the known compromised account passwords (if determined).
   2. Enable Multi-Factor authentication anywhere possible for the impacted account(s).
   3. Disable or reset alternative authentication methods such as certificates.
   4. Revoke authentication tokens for all management/administrative account(s).
2. If an external organization is identified during the investigation, notify the organization of any compromises or concerns.
   1. Work with legal counsel to determine this process.
   2. This will help prevent the organization’s users from being targeted again from the same compromised source.
3. If malware is discovered during the investigation:
   1. Preserve a sample of the malware.
   2. Analyze the malware with any tools available.
      1. Gather file hash using PowerShell “Get-Filehash” cmdlet.
      2. Submit hash to community sources VirusTotal, Hybrid-Analysis, etc.
         1. If community sources have seen the hash, note the malware characteristics.
   3. Isolate infected systems, do not power them off unless absolutely necessary.
      1. Preserve the system(s) for further forensic investigation including log review, MFT analysis, deep malware scans, etc.
4. Block all associated IoCs in email system, firewall, and other security components such as endpoint protection systems.
   1. URLs, domains, message-ID, etc. in spam filters, email based antimalware, etc.
   2. File hashes, malware identified, IP addresses identified, etc.
5. Preserve a copy of any existing web application code that may be compromised and/or altered maliciously.

Eradication

1. Compare current web application code to a known-good copy to determine if any malicious additions have been removed.
2. If systems were determined to be compromised with malware or by other means:
   1. Preserve artifacts, systems, and relevant backups according to the sensitivity and scale of the incident. These may be important for future forensics.
      1. If rebuilding or replacing physical systems, preserve physical hard disks, solid state drives, or forensically sound images of those storage drives.
      2. If rebuilding or replacing virtual machines, preserve a copy, full (independent) snapshot, or a backup of the system.
3. Preserve any volatile data that may have been collected during the identification and containment phases.
   1. This may include log files, code samples, backups, malware samples, memory images, etc.
4. Review and monitor logs to ensure that the compromise has been entirely contained.
5. Once all relevant data, web application code samples, or other potential items of evidence have been preserved, proceed to Recovery.

Recovery

1. Replace potentially compromised web application code with a known-good copy.
   1. This may be completed by removing code anomalies or from restoring a known-good copy.
2. Review current web application code to ensure that all code anomalies have been removed.
   1. This should be a new review, preferably by a different individual than the one who performed the review in Eradication step 1.
3. Restore web application functionality.
4. Restore impacted systems from a clean backup, taken prior to infection if these backups are available.
5. For systems not restorable from backup, rebuild the machines from a known good image or from bare metal.
6. Remediate any vulnerabilities and gaps identified during the investigation.
7. Reset passwords for all impacted accounts and/or create replacement accounts and leave the impacted accounts disabled permanently.
8. Continue to monitor for malicious activity related to this incident for an extended period.
   1. Alerts should be configured to aid in quick detection and response.

Lessons Learned

1. Conduct a meeting after the incident to discuss the following:
   1. What things went well during the investigation?
   2. What things did not go well during the investigation?
   3. What vulnerabilities or gaps in the organization’s security status were identified?
      1. How will these be remediated?
   4. What further steps or actions would have been helpful in preventing the incident?
   5. Do modifications need to be made to any of the following:
      1. Change control practices
      2. Code review practices
      3. Authentication practices
         1. Multi-Factor Authentication
         2. Password complexity and use
         3. Privileged account access
      4. Network segmentation
      5. Firewall configuration
      6. Application security
      7. Operating System and/or Application patching procedures
      8. Employee, IT, or CSIRT training
2. Create and distribute an incident report to relevant parties.
   1. A primary, and more technical, report should be completed for the CSIRT.
   2. An executive summary should be completed and presented to the management team.