This document summarizes steps for hardening Windows systems used in industrial control systems (ICS). It recommends: 1. Performing basic hardening steps like removing unnecessary software, disabling services, and restricting file system access. 2. Leveraging the native Windows firewall to prevent backdoors and malware from communicating. 3. Implementing whitelisting of authorized software using Software Restriction Policies or AppLocker to prevent unauthorized code execution. 4. Using Enhanced Mitigation Experience Toolkit (EMET) for exploitation mitigation to reduce the impact of zero-day vulnerabilities. 5. Leveraging PowerShell remoting and Just Enough Administration (JEA) to restrict remote access without using

1. Reducing attack surface on ICS with
Windows native solutions
Jan Seidl

2. Who?
Jan Seidl @jseidl
Security Researcher
Brazilian, despite Dutch name and German surname
And that's my full name.

3. Rio de Janeiro

4. Who? (cont)
Speaker at: Hackers 2 Hackers Conference, CeBIT Hannover, Defcon
Bangalore, Brazil Automation, FISL (Intl. Free Software Forum) & more
Co-author of “Seguranca de Automacao
Industrial e SCADA”(SCADA & Industrial
Automation Security)
first book on this subject in Brazilian Portuguese

5. Who? (cont)
Certifications:
Birth Certificate
Yellow Fever Vaccination
(As useful as a CISSP on proving infosec expertise)
Local Pub Contest Winner “Speed Tequila Shots”

6. Who? (cont)
Features:
*NIX/BSD freak
Digital tools blacksmith / python & C lover
Lousy guitar player
Coffee dependent
Hates printers, doesn't likes social networks anything
Selectively-social

7. A huge number of ICS/SCADA systems
runs on Windows OS
DEC VAX & other *NIXes → Windows Family (XP mostly)

8. Standard axioms
Once installed, not much changes on machine (not even patches)
Clear (?) network connection matrix
Custom scripts (bat/vbs) might be used
Terminal Services probably will be used for remoting if needed

9. Let's make those Windows harder

11. Steps for lockdown – The Hardening 101
The things you may already know

12. Start with all the basic steps for your everyday
hardening:
Remove software (Games, Word, Windows Messaging)
Disable services
Restrict/tune file-system access
Perform service-user/account separation + least privilege

13. You know Windows has a native
host-based firewall, right?

15. Firewall adds up:
Prevents backdoors from listening for connections
Prevents malware/shell from communicating with attacker machine
(if egress filtering is done properly)
Separates local interface services (which sometimes listens globally)
from external world

16. Firewall doesn't solves:
Abusing existing allowed ports
Shut down original service, listen on its port
Abusing existing connections
http://www.slideshare.net/bz98/defcon-22-bypass-firewalls-application-white-lists-secure-remote-desktops-in-20-seconds

17. White-listing
Explicitly allowing programs and scripts

18. Problem:
Employees intentionally installs
unauthorized software
and/or
Employees are foiled and
runs unauthorized software
Software has/is a malware
which compromises the machine
Attackers can deploy tools locally
for lateral movement

19. Software Restriction Policies
Windows 7/2008 R2 and above
App Locker
Windows XP / Vista

20. Restriction strategies:
Path-based (support env. vars., registry keys)
Certificate-based
Hash-based (md5 or sha1)
Zone-based (irrelevant for now, just mentioning)

21. About scripting:
AppLocker/SRP cannot restrict code running within environments
(Office VBS, Perl, Python interpreters etc)
CMD, BAT, VBS and PowerShell scripts can be individually signed

22. Whitelisting adds up:
Prevents unauthorized software from running
(hacker tools, misbehaving employees)
Allows controlled use of scripts
Flexibility enables security with minor (yeah, I know) business/operation
hog

23. Whitelisting doesn't solves:
In-memory code execution (e.g. DLL injection)
http://leastprivilege.blogspot.com.br/2013/04/bypass-applocker-by-loading-dlls-from.html
Allowed application exploitation
OS or enforcement application vulns/0days
Running DLLs from rundll32.exe
https://www.attackdebris.com/?p=143

25. Keep a close eye on rundll32

26. EMET
Enhanced Mitigation
Experience Toolkit
Plugging up applications' holes

27. Problem (example scenario):
All software on Machine M001
is unpatched
ICS software was coded by people
without secure SDLC mindset
Lots of software vulns. are present
and won't be fixed soon

29. EMET – System-wide protections

30. EMET – Application-specific protections

32. EMET adds up:
Reduces impact/likelihood of 0day exploitation
Adds complexity to attacks
Foils most off-the-shelf exploits

33. Bypassing EMET is not impossible, but it's tricky:
“We started looking at EMET since version 4.0 and it’s come a long
way since. There's no doubt that Microsoft are stepping up their efforts
at making EMET ever more effective. This sort of layered defense goes
a long way in disrupting commodity attacks and increasing the level of
effort required for successful exploitation.”
https://www.offensive-security.com/vulndev/disarming-and-bypassing-emet-5-1/

34. Bypassing EMET is not impossible, but it's tricky:
“We found that EMET was very good at stopping pre-existing
memory corruption attacks (a type of hacker exploit). But we
wondered: is it possible for a slightly more technical attacker to bypass
the protections offered in EMET? And yes, we found ways to bypass all
of the protections in EMET.”
http://labs.bromium.com/2014/02/24/bypassing-emet-4-1/

35. Bypassing EMET is not impossible, but it's tricky:
“(…) But truth be told EMET has tons of good protections which
render a lot of methods useless (…) EMET fights tough, more than any
public exploit mitigation solution out there. A lot tougher than MBAE
and enterprise exploit detection products.
But if we get to study the system, its only a matter of time.”
http://casual-scrutiny.blogspot.com.br/2015/03/defeating-emet-52.html

37. EMET caveats:
Application might still be exploitable by other means
EMET can be bypassed within a good effort
Some applications might not go well with EMET
Windows XP has very limited support

38. PowerShell Remoting and JEA
Because most of the times you don't really need Terminal Service

39. Problem (example scenario):
Machine M001 runs Software XYZ
Software XYZ runs as Administrator
User ABC needs to restart Software XYZ
User ABC ends up with Administrator account on Machine M001

41. PS Remoting and JEA adds up:
Enables remote operation without Terminal Service
Enables restricted operation environment
Works cross-domains

42. PS Remoting and JEA caveats:
Requires Windows Management Framework (WMF) 5.0
Requires some coding knowledge
Requires some more attention to PS traffic on your wires

43. Implementation techniques for the goodies
Standalone or centralized deployments

44. Deploy from your domain or configure locally:
Firewall rules
EMET install / updates / configuration
Software Restriction Policies (Win XP / Vista)
App Locker policies (Win 7+)

45. Suitable for mixed environments:
Software Restriction Policies & App Locker can coexist
Basic firewall rules applies to whole Windows XP/Vista/7/8
Appropriate version of EMET can be deployed to specific hosts

46. Summing up:
Unauthorized code execution (Whitelisting, AppLocker/SRP)
Unauthorized network communication (Native host-based firewall)
Exploitation mitigation (EMET)

47. Attackers' face upon realizing you've implemented all those stuff

48. If ICS world allowed us to have nice things
Like last-generation tech at least...

49. Configuration management is the word

50. Windows PowerShell Desired State Configuration (DSC)
DSC provides a set of Windows PowerShell language extensions, new
Windows PowerShell cmdlets, and resources that you can use to
declaratively specify how you want your software environment to be
configured.
https://technet.microsoft.com/en-us/library/dn249912.aspx

51. Questions?

52. Thanks for your time!
jseidl@wroot.org // @jseidl // wroot.org
Slides: http://slideshare.net/jseidl Codes http://github.com/jseidl