Web Application Compromise

Incident Response Playbook

Version history

Version Update Date Updated By Reason for Update

1.0 7/14/2021 FRSecure Initial Draft

Web Application Compromise – Incident Response Playbook

Purpose
To guide <ORGANIZATION> in responding to a web application compromise incident. This playbook may also
be used for a website defacement incident.

How to Use This Playbook

The steps in this playbook should be followed sequentially where appropriate. With many steps in the
Containment, Eradication, and Recovery steps, some overlap may occur and is expected.

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).

a. The core CSIRT members should be comprised of individuals responsible for cybersecurity
only.
i. This may include some members of Information Technology roles, depending on the
organization size.
ii. The limited size of the core CSIRT is to assist with confidentiality and efficiency.
iii. The core CSIRT may be activated often to investigate security events that may or may
not result in an incident.
b. Assign roles and responsibilities to each member.
2. Determine extended CSIRT members.
a. This will often be Legal, Compliance, Public Relations, and Executive Leadership.
3. Define escalation paths.
a. 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.
a. 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.

© FRSecure LLC., All rights reserved. | 6550 York Ave S #500, Edina, MN 55435 | 1-888-676-8657 | www.frsecure.com 2
Web Application Compromise – Incident Response Playbook

a. Inquire as to any recent security issues in their environment.

b. Inquire about any potential logs that they may possess.
i. 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.)
a. 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.
b. 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.
a. Interview impacted user to gather details on potential points of compromise.
i. 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?
b. Search for phishing emails.
i. Phishing emails are the most common method for credential theft.
c. Search for emails with links to credential harvesting sites.
d. Search the user’s web history to determine if any potentially malicious sites were visited.
e. Search for potential malware on the user’s workstation.
i. Credential harvesters such as Mimikatz.
ii. Keystroke recording software.
iii. 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.
a. Potential query inputs for email system: Email subject name, document name, document hash,
URL from email, etc.
b. Potential query inputs for SIEM or log searches: IP addresses, URLs, workstation names, etc.
5. Review logs in account login systems searching for anomalies.
a. Login activity from unusual locations, systems, or browser fingerprints.
b. 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.
a. 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.
b. 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.
a. If logs are unavailable, assume all accessible data was accessed by the attacker.

© FRSecure LLC., All rights reserved. | 6550 York Ave S #500, Edina, MN 55435 | 1-888-676-8657 | www.frsecure.com 3
Web Application Compromise – Incident Response Playbook

8. If account compromise has been ruled out, proceed to investigate potential web application
vulnerabilities that may have been exploited.
a. Perform a security scan.
b. Review vendor notifications of security issues.
c. Review community sourced threat-intelligence related to the components in your web
application.

Containment
1. If management or administrative account compromise has been determined:
a. Reset all passwords associated with management and administration of the web application.
i. Begin with the known compromised account passwords (if determined).
b. Enable Multi-Factor authentication anywhere possible for the impacted account(s).
c. Disable or reset alternative authentication methods such as certificates.
d. 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.
a. Work with legal counsel to determine this process.
b. 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:
a. Preserve a sample of the malware.
b. Analyze the malware with any tools available.
i. Gather file hash using PowerShell “Get-Filehash” cmdlet.
ii. Submit hash to community sources VirusTotal, Hybrid-Analysis, etc.
1. If community sources have seen the hash, note the malware characteristics.
c. Isolate infected systems, do not power them off unless absolutely necessary.
i. 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.
a. URLs, domains, message-ID, etc. in spam filters, email based antimalware, etc.
b. 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:
a. Preserve artifacts, systems, and relevant backups according to the sensitivity and scale of the
incident. These may be important for future forensics.

© FRSecure LLC., All rights reserved. | 6550 York Ave S #500, Edina, MN 55435 | 1-888-676-8657 | www.frsecure.com 4
Web Application Compromise – Incident Response Playbook

i. If rebuilding or replacing physical systems, preserve physical hard disks, solid state
drives, or forensically sound images of those storage drives.
ii. 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.
a. 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.
a. 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.
a. 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.
a. Alerts should be configured to aid in quick detection and response.

Lessons Learned
1. Conduct a meeting after the incident to discuss the following:
a. What things went well during the investigation?
b. What things did not go well during the investigation?
c. What vulnerabilities or gaps in the organization’s security status were identified?
i. How will these be remediated?
d. What further steps or actions would have been helpful in preventing the incident?
e. Do modifications need to be made to any of the following:
i. Change control practices
ii. Code review practices
iii. Authentication practices
1. Multi-Factor Authentication
2. Password complexity and use
3. Privileged account access
iv. Network segmentation

© FRSecure LLC., All rights reserved. | 6550 York Ave S #500, Edina, MN 55435 | 1-888-676-8657 | www.frsecure.com 5
Web Application Compromise – Incident Response Playbook

v. Firewall configuration
vi. Application security
vii. Operating System and/or Application patching procedures
viii. Employee, IT, or CSIRT training
2. Create and distribute an incident report to relevant parties.
a. A primary, and more technical, report should be completed for the CSIRT.
b. An executive summary should be completed and presented to the management team.

© FRSecure LLC., All rights reserved. | 6550 York Ave S #500, Edina, MN 55435 | 1-888-676-8657 | www.frsecure.com 6
Web Application Compromise – Incident Response Playbook

NEED HELP?
FRSecure is a full-service information security consultancy.

If you need assistance with anything in this resource, please don’t hesitate to reach out to us.

CONTACT US

(877) 767 – 1891 | 6550 York Ave S #500, Edina, MN 55435

For security emergencies, or quotes on services reach out to us here.

More resources

© FRSecure LLC., All rights reserved. | 6550 York Ave S #500, Edina, MN 55435 | 1-888-676-8657 | www.frsecure.com 7