I've Been Hacked-What Now

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.

My server has been hacked...what do I do now?

This page will offer suggestions and resources for identifying and eliminating threats to your web servers/applications after a suspected attack.

Anyone interested in contributing is welcome.

Identification

Basic principles:

• Incident identification/notification may occur from a number of information sources (events):
  • Staff reporting unusual activity
  • Staff, clients or public reporting a problem
  • Technical teams/support discovering evidence of an incident on systems.
  • Alerts from IDS, security monitoring systems or anti-virus software, Firewalls or WAFS.

• Roles:
  • A Security incident owner must be assigned.
  • A point of contact must be available to respond to incidents at all times.
  • A security incident owner must track the security incident to remediation and resolution.

• Examples of an incident:
  • Virus/malware infection
  • Unauthorized system changes
  • Unauthorized application/web site changes
  • Unauthorized disclosure of client information or information leakage
  • Theft or loss of company information/assets

• Examples of an event:
  • Reports from intrusion detection system/WAF/Firewall or log scraping system
  • Reports from vulnerability scanning/traffic monitoring/performance monitoring

Assessment

Incident severity :

Risk Rating

• Low:
  • Events that cannot be 100% identified as attacks and have no effect on operations;
  • False activation of intrusion detection systems, WAF alerts etc
  • Non-repeated scans or probing from an external uncontrolled network

• Medium
  • Incidents that have no negative impact on operations. Incidents identified but unsuccessful in an attempt to actively breach information security controls from external or internal standpoint
  • Repeated active probing or parameter manipulation from an external or internal source.
  • Malware/rogue code/virus that has been successfully contained or removed

• High
  • Incidents that have major impact to operations or corporate branding
  • Evidence of insider threat with identified motivation by salaried employees or contractors

Containment

Containment should be broken into proactive and reactive methods.

Proactive Methods

These are methods to be used in anticipation of a Web Application server compromise. Web applications have, by comparison to other server types, a much larger attack surface. This is typically because of the fact that by nature they are meant to be internet accessible and require anonymous access in order to be functional. Part of being proactive is segmentation of functions. Your web server should be separate from your application server and separate from your database server. Each tier should be divided by firewalls that only allow the necessary protocols and ports between each tier. In addition, accounts used to communicate between tiers of your web application (WA) should be implemented using the least-privelege method ¹.

Additional notes:

• All tiers of the WA should be behind firewalls with egress filtering enabled.
• Your web server should never speak directly to your database server.
• All communications should be filtered by a reverse proxy when possible.
• No communications should be allowed between the DMZ segments and the internal company network.
• If database information is required, do so in scheduled DTS packages that are strickly filtered and scrutinized on the internal network.

External Resources

• Cheat Sheet for Server Admin.
• Checking Microsoft Windows® Systems for Signs of Compromise
• SECURITY INCIDENT QUESTIONNAIRE FOR RESPONDERS
• SAN's SysAdmin Cheat Sheet
• http://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf
• http://usa.visa.com/download/merchants/cisp_responding_to_a_data_breach.pdf

Questions to Ask

• Was card data compromised?
• Do you need professional legal advice?