Slides for "Are you a Janitor or a Cleaner" ToorCon San Diego 2013

1. Are you Janitor or a Cleaner?
John “geekspeed” Stauffacher
@g33kspeed/geekspeed@gmail.com
Matthew “mattrix” Hoy
@mattrix_ / hoy.matthew@gmail.com

2. Brief Bio Matthew
• About:
– Information Security Professional for over 15 years
– CISSP and GCIH
• Contact:
– @mattrix_
– hoy.matthew@gmail.com

3. Brief Bio John
• About:
– Information Security Professional for over 13 years
– CISSP
• Contact:
– @g33kspeed
– geekspeed@gmail.com

4. Purpose of this talk
• Reliance on automated detection has caused
many organizations to be weak in response to an
incident
• Many organizations have no idea who attacked
them, why they were attacked or how the attack
was executed
• Use of old school methods with less reliance on
automated tools can help to understand who,
how and why (motive)
• Strike Back

5. Purpose of this talk
• Where we have failed
• Many organizations fall victim to dangerous
mindsets that prevent them from having an
effective security program
• How do we move forward
• In order to strike back – we need to have our
house in order.

6. The Janitor
Re-images owned boxes and does not identify or analyze the attacker.

7. The Cleaner
Goes beyond just re-imaging owned boxes. Can identify threat, attacker’s
capability and take actions to stop attacker.

8. Incident Response vs. Immediate
Action
Theoretical
Lifecycle of Incident Handling
•
•
•
•
•
•
Preparation
Identification
Containment
Eradication
Recovery
Lessons Learned
Immediate Action
During an attack there is no
immediate order or lifecycle
• True Preparation – Probably
didn’t happen
• Identification of Attacker
• Isolate and Study Attacker
• Stop Attacker
• Restore Services
• Take Attackers methods and
rebuild defenses

9. Preparation
• What is not working
– Set it and forget it mentality
– Inadequate staffing
– Improper use of Vulnerability Assessments
– No asset inventory
– No classification of data

10. Preparation is key
• Attackers have managed to run organizations
that are not unlike the ones they attack

11. Preparation is key
-
Reconnaissance
Weaponize
Deliver
Exploit
Install
C^2
Act on Objectives

12. Preparation is key
•
•
•
•
•
Marketing
Operations
Development
Accounting
HR

13. Preparation is key
• Attackers are streamlined, efficient
– Development takes days, not weeks.
– Rapidly adapts to a changing landscape
– Laser focus
– Aren’t rushed by artificial deadlines / other
interests

14. Where We Have Failed
• We need to fill that position

15. Where We Have Failed
• We let the business dictate our security
posture.

16. Where We Have Failed
• “Our department doesn’t do ‘preventative’
security scanning. We only scan after the
application is in production.”

17. Where We Have Failed
• “We can’t scan that server – it might crash.”

18. Where We Have Failed
• Monitor mode

19. Where We Have Failed
• Sandboxing
The sandboxing appliances popularly deployed today are
performing well against your average"0-day" malware
threat, but capabilities decline dramatically the more
targeted an adversary becomes. As such, organizations
are much better at stopping the generic non-targeted
"Internet threats", but becoming more vulnerable to
marginally tuned malware. For example, any piece of
malware that requires the user to perform an action at a
specific time (before it acts maliciously) is sufficient to
evade detection in most cases. - Gunter Ollmann (2013)

20. Where We Have Failed

21. Where We Have Failed
• Bloat: in some organizations it is typical for
individual business units to have their own
security staff
– …that don’t talk to each other
– …that don’t share information
– …that duplicate efforts

22. Where We Have Failed
• When security takes a back seat to business

23. What we need to change
• Security is EVERYONEs job.
• Misalignment of security goals should be
looked at as a vulnerability in itself – and dealt
with accordingly

24. What we need to change
• Attaching real monetary value to security
incidents is a key way to get the attention of
the stakeholders
• Rather than being defensive – and feeling
responsible – security organizations should
monetize all incidents and use it as
justification for program budget

25. What we need to change
• We often fail inform management of
something as simple as:
- Cost of the solution vs Cost associated with a
security incident.

26. What we need to change
Executives rely on the bottom line numbers, as
well as their advisors to guide their decisions.
They know very little about technology and
most of them don’t really care.
Speak their language. Express your concerns in
dollar amounts and impact to the business.

27. What we need to change
~$250 per record for a DB breach
(42 states have mandatory notification laws)
If 3200 records of a database were breached…
$800,000

28. What we need to change
How much was that WAF?

29. What we need to change
• Get serious about hiring
• Stop putting bodies in chairs because somebody
said we needed a body in a chair.

30. What we need to change
• Teamwork
• Align goals
• Share information
• Share tactics

31. What we need to change
• Security needs to assert itself as a fixture
• Too commonly thought of as an afterthought, or a
remedy for an already bad situation
• Security needs to have the ear of the major
decision makers in the company.
• The only tool for this is communication, and interaction
• Security needs to have teeth
• Back up your policy with corrective action

32. What we need to change
• We need to fight back.

33. True Preparation
• The (enemy) Attacker
1. Has no rules
2. Does not need Change Management to run
Vulnerability Assessments against your people or
infrastructure
3. Does not use checkbox settings in their tools to
exploit your people or infrastructure
4. HAS NO RULES

34. Identification
• What is not working
– Reliance on automated detection
– Set it and forget it mentality
– Staffing
• How was the incident identified?
– Finding out about the compromise when you lose
availability
– Being Blacklisted
– Pastebin

35. Identification Immediate Action
• Assess your attacker’s capability
• Skill Level of attacker – Direct or Indirect
method
• Create a dossier on your attacker
• Identify attacker’s Motive - Usage
• IP Addresses / Map this out / CIDR

36. Often Overlooked
• Actual – Physical Assets
• Data Value – What is on the physical asset?
• Network Connectivity – Where did the attack take
place from? Was this a pivot? Is there true defense in
depth?
• Target Value – Was this a crafted attack? Who’s
machine is this? What access does the person have? –
Yes APT again.
• What devices do you have on the network to identify
the attacker?
• Ask people (end user) questions – Hey did you guys see
any weird email?

37. Tools I Use
•
•
•
•
•
•
robtex.com, spokeo.com, google.com, IRC
NMAP, Wireshark
Network Tap
Acevpn, External Internet
traceroute, telnet, ssh, netstat –an, RDP
If you are looking during an ongoing attack – Bro
IDS and Splunk can be put in place quickly
• Plain pen and paper – important to use a book for
each incident – this may be used for chain of
custody

38. Containment
• What is not working
– We will just unplug the machine
– Switch to DR which has the very same
vulnerability that production had if not more
– Re-image box and put it back into production

39. Flush out your attacker
• If you found a phishing email?
• Feed it some bogus info – You will need to
provide at least 50 pieces of info
• Check your application logs for that very same
info (fake username)
• Look at the timing – Is this automated or
human?
• Are there multiple IP Addresses used or just
one?

40. Assess Attacker’s Capability
• IP Addresses used
• Determine Attacker’s potential for Ddos by IP
Address space
• Time for some OSINT
• Do not be afraid to probe your attacker
• I have scanned my attacker to determine the
attacker’s assets

41. Strike Back
• Get direct with your attacker after
identification
• Go to Meat Space – email or phone call
• If you can’t be direct with the attacker than
the ISP or host may be able to help
• Or maybe not…

42. Strike Back
• An incident occurred with intellectual property in
which my client was accused of leaking
• We were provided a single website of where this
was leaked to
• After determining that this did not originate from
our side we were then able to turn the tables.
• Maltego was used for the target
• Spokeo was used for the target
• End result - The person who leaked this was going
to receive a very interesting letter

43. Lessons Learned
• What is wrong
– This is often a report that is seldom read
– Focuses more on damage control
– Does not solve the issue

44. Lessons Learned Immediate Action
•
•
•
•
Intelligence gathering
Attacker’s skillset
Understand the motive of your attacker
Create automated tools to identify future
attacks – Robert Rowley provided an excellent
example of this in his “Teach your WAF new
tricks” talk
• Use OSINT to learn about similar attackers