A talk given at the ITWeb Security Summit 2013.

1. Offence oriented Defence
Dominic White & Jeremy du Bruyn
@SensePost

2. This talk is about …
• Understanding how attackers attack
– acknowledging the problem
– allows more innovative defence
• Common defences allow common bypasses
– Best practises introduce commonality that is
exploited
– Common defences lose out over time as
attackers adapt
• Many “security basics” are honestly hard
– knowing the attacks help to prioritise

3. Why listen to us?
• We attack networks and systems as our day
(night) job
– They’re often quite similar
• We care about making them harder to attack
• We spend time studying how others attack
networks and systems
– Other pentesters
– Real bad guys (“APT” campaigns)
• SensePost has been doing it since 2000
– Possibly more insight into .za infosec practises than
any other

4. How defenders spend
• Compliance/GRC
– Policies, auditing, responding
• Risk Management
– Ranking, prioritising, justifying
• Best Practises
– Passwords, patches, policies
• Technology
– UTM, WAF, DLP, DAM, SIEM, IPS, AV
• Staff
– Compliance specialists, risk specialists, security
managers, device ops managers

5. Truth is …
• Those defences don’t
– Block actual attacks
– Move to counter the bypasses used to side-step them
• Risk Management
– Hard to link risk-based priorities to meaningful technical
priorities
• Compliance
– “teach the test”
– Little incentive to create contradictory measurements
• Best Practice
– We can’t honestly say we know how to defend
– Some practises are hard/impossible to do
– Common best practises have common bypasses

6. The Wall
• Your defences are a wall
• We get to evaluate the wall, figure out how to get
over it, and do it
– Attackers can often evaluate your defences before
getting to you
• Once we’ve done it, we have the
capability/technique/tool we can do it again, with
much less effort
– Attackers can keep building their toolchain
– Attackers are good at sharing
• Defenders now need to build an increasingly huge
wall as “the basics” become by-passable with tools

7. And so …
• Popular defensive design patterns lead to
popular attack patterns to bypass them
– Knowing these can help you avoid or rejigger
them
• Some stuff has been recommended for
decade+, are we really just too lazy?
– Let’s just admit that some stuff, will never be
done, and come up with a prioritisation strategy
that works
– Although, you shouldn’t need a pentest/breach to
be reminded, design for them

8. PASSWORDS

9. Corporate Passwords
• Best Practice
– Enforce password complexity
– Expire them monthly
• Belief
– Passwords will be more complex & harder to guess/crack
– Passwords have a shelf life
• Reality:
– Users employ coping methods
• Password1 or June2013 or Password8
• <Capital><rest of word><number>
• Call centre resets to same password every time
– Most organisations pick the same policy
– Cracking common storage formats is efficient
• NTLM / LanMan

10. Corporate Passwords
• Best Practice: Lock an account after X failed
login attempts
• Belief: People won’t be able to guess
passwords
• Reality
– Lockout period has a timeout, just try one
password across all accounts (horizontal brute)
• Bonus
– Find an Internet-facing auth point & brute there
for ext->int win
– Executives get exceptions

11. So what?
• Best practises created the vulnerability
• Everybody doing the same thing lets
attackers optimise
• The actual attacks aren’t being looked for

12. Defend!
• Differentiate yourself from the optimised
attack
– Blacklist common passwords
– Enforce length rather than complexity (15+
bonus)
– Extend password expiry
• Crack your own passwords (or look for
duplicate hashes)
– Operationalise this as a metric
• Monitor for horizontal brutes
• Canary accounts
• Two factor authentication

13. MASSPLOITATION

14. Service/Default Accounts
• Best Practice:
– Change all vendor supplied/service passwords from
the default or disable
• Belief:
– Requires attackers to guess the password or can’t
use the account
• Reality:
– The rate of developer new app use exceeds security
capacity to secure
– Complexity across application stack
– Belief about network controls/development boxes
lead to exceptions

15. Patching
• Best Practice:
– Ensure systems are fully patched
• Belief:
– Known vulnerabilities will not be exploitable
• Reality:
– Known systems are(?), unknown aren’t
– Some software is easier to patch than others
– Unknown vulnerabilities & patch window are
realities

16. Baselines & Homogonaity
• Best practice:
– Ensure all systems are configured the same
• Belief:
– All systems will have the same security baseline
• Reality:
– A flaw in one is a flaw in all, Mistakes scale
against you
– Management agents are remote access methods
– Local admin passwords …

17. So what?
• 100% compliance for every piece of software, on
every machine, for all time …
– You need to do the basics, but let’s admit
100% as impossible
– 99% on 1k machines, still gives 10 vuln hosts
• Attackers are good at finding the 1%
• Attackers care about exploitation, missing
language packs not so much

18. Defend!
• Admit you’ll never hit 100%
• Use attacker tools/methods to find the 1%
– Find the machines your risk/compliance based focus
didn’t care about
– Scope be damned!
• Prioritise based on ease of exploitation
– Availability/popularity/stability/ease of exploit
• Make hard choices – do you need that software
there?
• Defence in depth
– Check out hardening tools EMET/PAX (grsec)
– Have a plan for once exploited

19. ANTI-ANTI-ANTI-ANTI-VIRUS

20. Anti-Virus
• Best practice:
– All systems must make use of Anti-virus to protect
against malware
• Belief:
– Malware/attacks will be blocked
– Malicious e-mail will be blocked
– We don’t need to follow up if AV said it blocked
• Reality:
“All of us had missed detecting this malware for
two years. That's a spectacular failure for the
antivirus industry in general. We were out of our
league, in our own game.” Mikko Hypponen

21. The truth
• Mikko was talking about Flame (APT)
• Is it that hard?
• R600 will buy you access to a great
“crypter”
– Will make any file undetectable by AV,
updated regularly
• 20 lines of code to implement my own
– Currently bypasses all AV, with a delay &
custom file template

22. Attackers Get to Practise

23. So what?
• You wouldn’t run without it, but guaranteed
bypassable
• We need to do something, AV is something,
do AV
• Attackers can test their attacks
• Do we just keep building the wall & run all of
them?
• A lot of money at stake in perpetuating the
problem
– “I've never seen _single_ report when modern
updated AV with all features was bypassed.”
Jindrich Kubec Director of Threat Intelligence @
avast!

24. Defence!
• AV isn’t useless, a signature may only be
added a year from now, but it’ll tell you, you
missed something – investigate
• Push your vendor to do better, don’t accept
lame signatures, get them to block
techniques
• Watch the logs, alerts then silent is a bypass
pattern
• Run multiple AV engines at different layers

25. LATERAL MOVEMENT

26. Network Pivoting & DMZs
• Best Practice:
– Separate your Internet-facing systems into their
own network, then only allow connections into the
DMZ, not out
• Belief:
– Contingency plan; even if your Internet-facing
servers get hacked, hackers can’t get to your
internal network
• Reality:
– “Lateral movement” is a regular action by so-
called APT actors

27. DMZ – Screw ups
• (lame) Web servers in the DMZ, DB in the internal net
• Attack
– SQLi on the DB (with command exec) gets you onto the internal
network
• (less lame) Web server & DB in DMZ/s, but on the domain
• Attack
– Get command exec, get domain account, connect to DC
• (least lame) A connection can be initiated to the internal
network
• Attack
– Move around until you can find something you can own, that has
access to the internal network
– Often not as hard as it sounds

28. The trouble with tunnels

29. Trying to explain a real attack …

30. The toolchain
• “Pushing a camel through the eye of a needle”
– 2008 BH/Defcon talk by Haroon Meer & Marco Slaviero
• Released reDuh by haroon/marco/glenn/ian/gert
@sensepost

31. Defend!
• DMZs must disallow connections from being initiated
to internal
– Check for yourself, plugin and portscan
• But, stuff’s not architected to make that easy
• Web services provide hope
– Expose integration services in the DMZ, have a worker
from internal consume it
• Other important advice we don’t have time for
– Needs separate/disconnected management infrastructure
– Don’t share with VPN – fundamentally different purposes
– Actually, if you can, stick every machine in it’s own DMZ
ala AP isolation
– Don’t forget egress filtering & split DNS

32. Account Pivoting & Escalation
• “When in doubt, attack the control plane.
When certain, attack the data plane.” -David
Ulevitch
• Belief:
– Centralised user management makes systems
more secure.
• Reality:
– In some ways, yes, but it gives us organisation
wide administrative accounts, and it’s easy(ish) to
do.

33. Lateral Movement
• Windows is *terrible* at passwords & keeping secrets
– Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft
Techniques
• Attackers have gotten really good at post-exploitation
• Attacks
– Digest auth gives clear-text creds! (wce/mimikatz)
– Windows security tokens work well too (incognito)
– Still passing-the-hash 16 years later (wce/pth-toolkit)
– SMB/NTLM relay attacks (metasploit)
– NTLM/LM unsalted, Kerberos can’t do IP, crack away (john/hashcat)
– Cached logins (at least they’re salted)
• Lateral opportunities – if it works on one …
– Local accounts (local admin)
– Domain accounts (admin or service)
– Apps & Agents (VNC, DBs etc.)
– Connected shares

34. So what?
• Good advice is blindly implemented, and the
original point missed
– DMZs are a great idea, but must not allow
connections initiated in low trust network
• Advanced protections have well understood
bypasses and haven't grown
– Tunnelling & windows cred extraction sound
hard, but the tools are there
• Your exposure is greater than the sum of the
parts, you can't look at vulns in isolation, or at
entry-only

35. Defend!
• Use specialised/separate DA, server admin & user
accounts
– Only use the relevant account when required
– Limit DAs to login from management network &
management jump box (not laptop)
• Monitor *all* your AD groups
– Administrators, Enterprise Admins, Domain Admins,
Shared Trust, Sub-Group inheritance
• Beware of the tokens
• Check out RODC & Attribute/Account Filters
• Read MS’ paper

36. CONCLUSION

37. This talk was about …
• Understanding how attackers attack
– acknowledging the problem
– allows more innovative defence
• Common defences allow common bypasses
– Best practises introduce commonality that is
exploited
– Common defences lose out over time as
attackers adapt
• Many “security basics” are honestly hard
– knowing the attacks help to prioritise

38. Questions?
research@sensepost.com
@sensepost
dominic@sensepost.com
@singe