Lesson Progress
0% Complete
  1. Initial notification to ISOC team by CSS WAF team.
    1.1 Provisioning of access to ISOC Team by CSS Linux or Windows team for the affected web server to perform manual investigation.
    1.2 ISOC would start the investigation.
  2. CSS (Linux or Windows) will redirect all the access to the compromised page to the home page or another URL.
  3. The initial investigation will start with the report that comes from CSS SOC. This will usually contain 2 leads for the investigation.
  4. The attackers IP address(es)
  5. The suspected bad links.
  6. From this information there’s a 3 step cyclical process to follow until all information is gathered.
  7. Confirm the file is malicious
  8. Check the IP addresses that accessed the files
  9. Get a list of pages accessed by all IP’s from step 2
  10. For each page listed in step 3 start the process again.
  11. Other than the pages reported through the WAF and the process above. Check legitimate files too. Sometimes attackers will attempt to hide files in plain sight with commonly used php file names. Some examples are info.php, main.php.
  12. Another step is to look at the legitimate files accessed by the attackers. This could help in pointing out the vulnerability used to exploit the machine. A very good thing to look for is the referrer link in the logs for the first malicious file accessed on the server. This usually shows where the attacker went from using legitimate functionality to a malicious file they control and points to the weakness.
  13. Look for patterns in the pages and focus on anything that doesn’t fit the pattern.
    8.1 For example, on a linux box if you do ls –la to view all attributes of the files you might notice all but one file is owned by apache and the final one owned by root. It doesn’t fit the pattern and might be worth looking into.

Note: There is one concerning issue with all web incidents at the moment, we are not recording POST logs. Without POST logs we cannot definitively say what actions and attacker might have taken. This especially concerning when we suspect SQLi or command injection.

Closure guidelines
1) Removal of all the malicious files from the folder.
2) Perform thorough web security assessment before the site is made available.

Identification

  1. Review the relevant events in SEIM and collect the following information:
    a) HTTP session ID (Source User ID)
    b) The username associated with the session ID if available (Source User Name)
    c) Source IP address and geo location of the connections
    d) Destination IP address and the F5 policy name (Device Custom String 1)
    e) Any additional information about the web server or the destination host (asset name, criticality, owner, etc.)
    f) Name and category of the web attack (Event Name, Device Custom String 1)

Instructions:
• Open the web attack active channel
• Modify the time stamp based on the time of the incident
• Find the relevant events that have triggered the rules
• Search the correlation and basic events to collect the information that are required

  1. Evaluate the user and analyze the events and network traffic if available:
    a) Investigate the malicious IP address and URL using the available information sources (X-Force Exchange, IP Void, etc.) to see if it is/has been associated with malicious/unauthorized activity. (Please be careful not to go directly to any sites thought to be malicious)
    a. Where are the connections coming from and what resources are access on the application?
    b. Is it associated with known malicious activity or indicators of compromise (e.g., malware, malicious IPs/domains, etc.)?
    c. What type of site/IP/hostname is it? Is it an official affiliated vendor, group, association, etc?
    d. Does it appear to be a legitimate site/IP/hostname?
    e. Are there professional relationships in place? Are they in the same division or industry?
    b) Check internal references for authorized exceptions (e.g., CMDB Tool, CSIRT team)
    NOTE: It is the recommended to search the following websites to get more information about the source IP and level of risk:
    • https://exchange.xforce.ibmcloud.com
    • https://ipintel.io
  2. Follow the instructions below to search the source IP address in the “Manual TOR list” active list:
    a) Right-click on the “Manual TOR list” active list.
    b) Selection “Show Entries” from the list
    c) Click on the “Filter” in the top panel
    d) Add a new condition by adding the “IP” filed
    e) Type in the source IP address in the text box and click OK
  3. Search for any possible related incidents in the ticketing system or the SIEM solution based on the following fields:
    a) Session ID (search only in SIEM)
    b) Source IP Address
    c) User Name
    In case of finding relevant incidents, create a master incident ticket and link all the existing tickets with the master ticket
  4. Collect as much information as possible about the web attack:
    a) All connections related to the same session ID along with additional information (Time Stamp, user name, HTTP response code, web attack name, web attack category)
    b) All connections related to the same source IP address along with additional information (Time Stamp, user name, session ID, HTTP response code, web attack name, web attack category)
    c) All connections related to the same user name address along with additional information (Time Stamp, source IP address, session ID, HTTP response code, web attack name, web attack category)
    Note: Consider running a report on the logger for each of these 3 items and attach the CSV export to the ticket.
  5. Categorize the incident as Web Application Attack and assign the incident to the appropriate team based on the document “SOC Tier 1 – Security Threat Monitoring Process/Procedure”.
    NOTE: Below is the list of available options for the incident types:
     Malicious Code
     Web Application Attack
     Unauthorized Access
     Unauthorized System Activity
     Unauthorized Network Activity
     Suspicious System Activity
     Suspicious Network Activity
     Probes and Scans
     Denial of Service
     Policy Violation
     Device Misconfiguration
     Device Malfunctioning
     Communication with Malicious Network
  6. Search the session IDs that are involved in the incident in F5 ASM for a more detailed analysis of HTTP requests and responses.
  7. Search the usernames in the application logs for more detailed analysis of the user behavior and the resources that are access on the website.
  8. In case of SQL injections attacks, consider reviewing the database logs to understand what queries have run against the database and what type of information is retrieved.
  9. Prioritize the incidents based on the instructions provided in the document “Security Incident Management Process”.
  10. Identify the severity of the incident based on the following scenarios, and assign the incident to the appropriate team based on the document “SOC Tier 2 – Security Incident Triage Process/Procedure”
     Any types of web application attack that is detected on web servers and is successfully blocked by the web application firewall
     Any types of web application attack that is detected on web servers and is NOT blocked by the web application firewall
     Any types of web application attack that is detected on critical web servers and is successfully blocked by the web application firewall
     Any types of web application attack that is detected on critical web servers and is NOT blocked by the web application firewall

Containment

  1. Consider possible short-term containment actions:
    a) Disable the account at the application level: In situations where the attack is initiated by a compromised account, disabling or removing the account can be the best option to contain the web attack.
    b) Change the required rules in the web application firewall to blocking mode: If the web attack can be detected by F5 ASM without a considerable number of false positives, it is recommended to enable the relevant rules in F5 ASM in the blocking mode.
  2. Block the external IP addresses on the firewalls: If we experience persistent attacks coming from a range of IPs that do not conflict with the client’s IP addresses, it is recommended to consider blocking those IP addresses at the firewalls.
  3. Conduct further network and host forensics as required

Eradication

  1. If there are any unauthorized changes on the protective technology by the internal users or admins, ensure all the user accounts that are associated with the person are disabled.
  2. Take the following Consider possible long-term containment actions:
    a) Patch the vulnerability on the applications: Inform the application team about the incident and consider patching those vulnerabilities on the application.
    b) Conduct a comprehensive pen test: To identify all the possible variations of the attacks that can successfully pass the web application firewalls, it is recommended to conduct a comprehensive pen test on the web applications to identify all the possible vulnerabilities on the application and come up with solutions that addresses most of those vulnerabilities.
  3. If the incident is left open for an extended period (e.g., 7+ days) Ensure at least one follow-up notification is sent and If they are still unresponsive, escalate to management for action

Recovery

  1. Work with the Threat Intelligence, IT Security Infrastructure and Application Admins teams to refine existing rules or develop new signatures/rules in SIEM or the web application firewall to detect activity, as necessary.
  2. Look for attacker’s artifacts to come back:
    a) Suspicious network communication from the same IP ranges or geo locations
    b) Unusual activity by the same users
    c) Similar types of web attacks

Lessons Learned

  1. Put together a report detailing what happened, why it happened, what could have prevented it, and what you’ll be doing to prevent it from happening again.
  2. Meet with management to go over the report and get their approval for the changes needed to prevent similar incidents in the future.