Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In a previous article, I noted that organizations are witnessing a surge in integrity-based attacks targeting their networks. Enterprises can defend themselves against these types of threats by turning to the National Institute of Standards and Technology (NIST) Cybersecurity Framework. They can then pair the risk-based approach with NIST SP 800-53 and other security control catalogs that enable integrity management.

Windows supports a code-signing feature called Authenticode, which allows a software publisher to digitally sign executable files (e.g. .exe, .msi, …) so that users can verify their autenticity. The digital signature of a file can be viewed in the file properties in Windows explorer on the “Digital Signature” tab.

In part one I provided a high level overview of PowerShell and the potential risk it poses to networks. Of course we can only mitigate some PowerShell attacks if we have a trace, so going forward I am assuming that you followed part 1 of this series and enabled: Module Logging, Script Block Logging, Security Process Tracking (4688/4689)

Imagine someone getting the seemingly innocent ability to run a couple of commands on a machine on your network WITHOUT installing any new software, but those commands resulting in a reverse shell running on that same machine – giving the intruder a convenient outpost in your network. Now stretch your imagination even further and pretend that all of this happens without leaving any unusual traces in logs – leaving you completely in the dark.