This document discusses common defensive strategies and how attackers bypass them. It notes that while best practices like passwords, patching, and anti-virus are important, they also introduce commonalities that attackers learn to exploit. The document recommends that defenders study attack techniques to prioritize risks and design defenses that differentiate from standard approaches in order to limit widespread exploitation.

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