BSides Charm Presentation Posted: PowerShell Security: Defending the Enterprise from the Latest Attack Platform

This was my second year speaking at BSides Charm in Baltimore. Last year I spoke about Active Directory attack & defense and it was my first time speaking at a conference. 🙂

The presentation slides for my talk “PowerShell Security: Defending the Enterprise from the Latest Attack Platform” are now on the Presentations tab here on ADSecurity.org. The talk was recorded, so follow @BSidesCharm on Twitter for information about video publishing.

AD Security Presentations

Here’s my PowerShell talk description:

PowerShell is a boon to administrators, providing command consistency and the ability to quickly gather system data and set configuration settings. However, what can be used to help, can also be used for less altruistic activities. Attackers have quickly learned over the past few years that leveraging PowerShell provides simple bypass methods for most defenses and a platform for initial compromise, recon, exploitation, privilege escalation, data exfiltration, and persistence.

With the industry shift to an “”Assume Breach”” mentality, it’s important to understand the impact on the defensive paradigm. Simply put, don’t block PowerShell, embrace it. Blocking PowerShell.exe does not stop PowerShell execution and can provide a false sense of security. The key is monitoring PowerShell usage to enable detection of recon and attack activity. As attack tools like the recently released PowerShell Empire become more prevalent, it’s more important than ever to understand the full capabilities of PowerShell as an attack platform as well as how to effectively detect and mitigate standard PowerShell attack methods.

The presentation walks the audience through the evolution of PowerShell as an attack platform and shows why a new approach to PowerShell attack defense is required. Some Active Directory recon & attack techniques are shown as well as potential mitigation. This journey ends showing why PowerShell version 5 should be the new baseline version of PowerShell due to new defensive capability.

This talk is recommended for anyone tasked with defending an organization from attack as well as system administrators/engineers.


BSides Charm talk outline:

  • Brief PowerShell Overview
  • Typical PowerShell defenses (and why they fail)
  • PowerShell as an Attack Platform
  • Real-world PowerShell attacks
  • PowerShell Persistence
  • PowerShell without PowerShell.exe
  • PowerShell Remoting
  • PowerShell Logging & Attack Detection
  • PowerShell Defenses
  • PowerShell v5 Security Enhancements
  • Windows 10 PowerShell Security
  • Securing PowerShell: A Layered Defense
  • Appendix: Microsoft Office Macro Security

Some of this information is in the post titled “Detecting Offensive PowerShell Attack Tools “.

As a follow-up to one of the questions regarding the Invoke-NinjaCopy powershell tool that can copy a locked file from a server (such as NTDS.dit), I refer you to the author’s blog post on his tool.

There was also a question after the talk about managing computers without leaving credentials behind. PowerShell remoting is ideal since it uses a “Network” logon where no credentials are placed on the target system. This has been a problem with RDP since logging into a server via RDP involves entering a username and password. This action usually involves placing the user credentials on the remote system and when connected to a computer via RDP, the user credentials are placed on that system. RDP /RestrictedAdmin is a new feature (now available for Windows 7 / Windows 2008 R2 and newer) which prevents the credentials from being placed on the target RDP server, so they can’t be stolen. This is great for help desk support that needs to RDP to user workstations as a workstation admin. When using standard RDP, these credentials could be stolen. With RDP /RestrictedAdmin, the credentials aren’t on the box to take.

Thanks to the BSides Charm organizers for a great event!

Follow-up note:
Test PowerShell logging levels. Someone reported to me that checking the box “Log script block invocation start / stop events” can generate a large amount of PowerShell log events, so check before deploying.

 

(Visited 6,642 times, 1 visits today)