Chapter 6 Discovering the Scope of the Incident Spring Incident Response & Computer Forensics

Discovering the Scope  Scope: Understanding what the attacker did  To determine the scope, one has to carry out a limited investigation  What helps in scope discovery  Examining initial data  Collecting and reviewing preliminary evidence  Determining course of action

Examining Initial Data  Talk to people involved  Use a “trust but verify” approach  IT people may not know what is important to the investigation  Assemble facts  Think of  Who  What  When  Where  Why  How

Gathering and Reviewing Preliminary Evidence  Identify what source of preliminary evidence may help  Pick sources of evidence that come from several categories and require less effort to analyze  Advantage of using independent sources  When sources agree, probability of incident (or not) is higher  Difficulty for attacker to delete all sources  Likelihood of accidental overwrite is low  Review evidence  Use a method that can do it quickly  Test the method to make sure it is fast and accurate Note: Absence of evidence is not evidence of absence

Determining a Course of Action  Activities include:  Preserving evidence  Containing damage  Questions that may help:  Will the action help answer an investigative question?  Am I following the evidence?  Am I putting too much effort into a single theory?  Do I understand the level of effort?  Am I staying objective?  Have I uncovered something that requires immediate remediation?  Note: there is no “ideal path” to solve a case.

Customer Data Loss Scenario  A company receives complaints from customers saying they are receiving a large amount of spam soon after they registered in company database.  Initial data:  customer complaints  How to verify?  Work with customers to check their s  Create fake customer accounts and register  Rather than waiting, continue with investigation  Find out where customer data is stored and how it is managed

Customer Data Loss Scenario  There is one internal and one external database that stores customer data  Internal DB is the production server used for normal business  External DB is managed by a third party – a marketing firm - used for and postal mail  Interview IT department and learn more about the database and network

Customer Data Loss Scenario  Interview results  The internal DB system: About 500 GB Has advance query monitoring and reporting capability Customers can register directly via company website or manually via phone call into customer service department No other methods of updating customer records exists DB network traffic is approximately 3TB per day Backups are kept both on-site and off-site at another facility  The marketing firm receives data at the end of month following any updates

Customer Data Loss Scenario  Progress so far:  The marketing firm is unlikely the source of data leak  Theft via phone is unlikely as well  So, the focus of investigation should be on the website  The next step  Performing a network packet capture could be difficult  Monitoring DB access would be easier

Customer Data Loss Scenario  Could this be the work of an insider?  Is website code modified such that it sends customer addresses to attacker?  Is someone taking copies of backup tapes?  So far there is no lead to suggest any of the above  What can be done to test these theories?  Enter data directly into the DB bypassing the web portal  Enter some fake records into backup tapes

Customer Data Loss Scenario  After two weeks of creating fake customer accounts, spam s were received by those accounts  Spams also were received by the accounts entered manually into the DB.  So, website is not the source of data theft  No spams received by accounts placed in backup tapes  Backup tapes are not part of the problem  Thus, the strongest lead for data theft is direct access to the DB  We need to check DB activities

Customer Data Loss Scenario  How to check DB transactions?  Network level packet capture  DB-level query monitoring  The first option is not easy Too much data Queries might be encrypted  Query monitoring is set up after creating few more customer accounts

Customer Data Loss Scenario  Log file checked periodically  After two weeks the new accounts start receiving spams  Log shows a query retrieving customer s  Select cust from custprofile where signupdate >= …. ;  The date used was roughly two weeks old  The log shows when the query was executed and from which IP address  The IP address belongs to a desktop belonging to the company’s graphic arts department  The username associated with the query belongs to a DB administrator

Customer Data Loss Scenario  You check with the graphic arts department and ask if they query customer information  Their answer is “no”  But, they say, they do frequently contact several outside vendors via

Customer Data Loss Scenario  What we have learned so far:  Evidence supports customer complaints  Two-week cycle of data theft  Only customer address is stolen  Data stolen from the production DB  Data theft query originated from a desktop computer in the graphic arts department  Graphic arts dept does not use customer information  Query issued from a DB administrator account

Customer Data Loss Scenario  What is the next course of action?  There are two sources of evidence  The production database server  The desktop in graphic arts department  We need to check both sources and gather more data

Customer Data Loss Scenario  Action with respect to the graphics arts desktop  Collect live response  Create forensic images  Interview the user  Action with respect to the production database server  Collect live response  Preserve database logs that record user access  Preserve all query logs  Preserve all application and system logs

Customer Data Loss Scenario  What is the plan now?  Since we know the query origination time, see who was logged on at that time  Check that system’s network activity around that time  Examination of the graphic arts computer shows a malware is installed  The malware provides features such as remote shell, remote graphical interface, the ability to launch and terminate processes  The malware connects to an IP address allocated to a foreign country  The malware has been installed for nearly two years

Customer Data Loss Scenario  Final steps in the investigation process:  Use a host-based inspection tool to examine each computer in the company for indicators of compromise Look for file names, registry keys, and any other unique characteristics of the malware  Query firewall logs for indications that other computers may have been infected Look for traffic to the IP address the malware connects to