I've Been Hacked-What Now - Revision history

Larsen: /* Investigation */

2010-11-15T11:54:54Z

‎Investigation

Dc: /* External Resources */

2010-01-11T22:35:34Z

‎External Resources

Bradcausey at 17:01, 6 January 2010

2010-01-06T17:01:41Z

Bradcausey: /* Evidence Collection */

2010-01-06T17:01:01Z

‎Evidence Collection

Xntrik: /* External Resources */ - added APWG Phishing Education Landing Page resource

2010-01-06T12:28:53Z

‎External Resources: - added APWG Phishing Education Landing Page resource

Bradcausey at 03:09, 6 January 2010

2010-01-06T03:09:06Z

Bradcausey at 02:59, 6 January 2010

2010-01-06T02:59:45Z

Bradcausey at 02:55, 6 January 2010

2010-01-06T02:55:39Z

Bradcausey at 02:53, 6 January 2010

2010-01-06T02:53:58Z

Bradcausey at 02:40, 6 January 2010

2010-01-06T02:40:27Z

@@ Line 111: / Line 111: @@
 ==Forensic Analysis==
 ==Investigation==
 ==Incident Follow-up==
 ==Lessons Learned==

@@ Line 116: / Line 116: @@
 ==External Resources==
 * [http://www.zeltser.com/network-os-security/security-incident-survey-cheat-sheet.pdf Cheat Sheet for Server Admin.]
 * [http://www.ucl.ac.uk/cert/win_intrusion.pdf Checking Microsoft Windows® Systems for Signs of Compromise]

← Older revision		Revision as of 17:01, 6 January 2010
Line 108:		Line 108:

	Gathering electronic evidence properly requires a great deal of knowledge and skill. If you do not have this skill in your organization it is suggested you hire a consulting firm that specializes in electronic forensics. Covering how to do this is outside the scope of this document.		Gathering electronic evidence properly requires a great deal of knowledge and skill. If you do not have this skill in your organization it is suggested you hire a consulting firm that specializes in electronic forensics. Covering how to do this is outside the scope of this document.
−
−	~~=== ===~~

	==Forensic Analysis==		==Forensic Analysis==

@@ Line 89: / Line 89: @@
 *Put your hands on your recovery plan, and make sure anything required within is accessible
-== Evidence Collection ==
+== Evidence Collection  ==
 What evidence you collect will be largely determined by your goal in collecting evidence in the first place. There are two primary reasons for collective evidence:
@@ Line 97: / Line 97: @@
 === Evidence for Incident Analysis ===
 === Evidence for Prosecution ===
 ==Forensic Analysis==

@@ Line 114: / Line 114: @@
 * 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?

@@ Line 71: / Line 71: @@
 *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.
+*If database information is required to be passed into your internal network, do so in scheduled DTS packages that are strickly filtered and scrutinized by internal systems
 === Reactive Methods  ===

@@ Line 73: / Line 73: @@
 *If database information is required, do so in scheduled DTS packages that are strickly filtered and scrutinized on the internal network.
-=== Reactive Methods ===
+=== Reactive Methods  ===
-Assuming your proactive methods are in place, you simply need to identify the point of entry, restore the server and applications and close the vulnerability that lead to the compromise. <br>
+Assuming your proactive methods are in place, you simply need to identify the point of entry, restore the server and applications and close the vulnerability that led to the compromise. <br>
 In a scenario where your WA is not properly segmented, you'll need to identify the system where the entry point exists and isolate that system. This is typically the point that some rudamentery forensics is required in order to determine the scope of the breach, time exposed, and other details. This is discussed in more detail in the forensics section.
 Depending on your research, you may find that attempts were made to expand the level of the breach. In this case, you'll need to quickly determine an area of effect. This type of "hacking triage" can be performed by analyzing paths in the network that the attacker most likely took. This can be difficult depending on the network design. The best point to make this evaluation is at the egress point of the network. If out-bound web traffic is proxied, then proxy logs would be a great place to start. Egress firewall logs, IDS logs, and any other type of outbound traffic analysis will provide the most detail. This should provide you a list of compromised machines that you can address quickly.
 This is also the point where you, your legal team, and your organizations leadership will need to make a few critical decisions:
 *Does this breach require customer/FED notification (typically when it involves regulated data such as PII)
 *Do you want to pursue legal prosecution of the attacker? If so, evidence collection should be the next priority above containing the breach.
 *Put your hands on your recovery plan, and make sure anything required within is accessible

@@ Line 55: / Line 55: @@
 ** Evidence of insider threat with identified motivation by salaried employees or contractors
-== Containment ==
+== Containment  ==
 Containment should be broken into proactive and reactive methods.
@@ Line 72: / Line 72: @@
 *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.
 ==Evidence Collection==

@@ Line 61: / Line 61: @@
 <br>
-== Proactive 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 [http://en.wikipedia.org/wiki/Principle_of_least_privilege <sup>1</sup>].
 Additional notes:
 *All tiers of the WA should be behind firewalls with egress filtering enabled.