Back

The Value of Detective Controls

For as long as I can remember, security professionals have spent the majority of their time focusing on preventative controls. Things like patching processes, configuration management, and vulnerability testing all fall into this category. The attention is sensible, of course; what better way to mitigate risk than to prevent successful attacks in the first place?

However, this attention has been somewhat to the detriment of detective controls (I’m intentionally overlooking corrective controls). With budget and effort being concentrated on the preventative, there is little left over for the detective. However, in recent years, we have seen a bit of a paradigm shift; as organizations have begun to accept that they cannot prevent every threat agent, they have also begun to realize the value of detective controls.

Some may argue that most organizations have had detective controls implemented for years and, technically speaking, this is probably true. Intrusion detection and prevention systems (IDS/IPS), log aggregation and review, and managed security services responsible for monitoring and correlating events are nothing new. However, in my experience, these processes and technologies are rarely as effective as advertised (IDS/IPS can easily be made ineffective by the noise of today’s networks, logs are only worth reviewing if you’re collecting the right data points, and correlation and alerting only works if it’s properly configured) and far too many companies expect plug-and-play ease of use.

Detective controls should be designed and implemented to identify malicious activity on both the network and endpoints. Just like preventative controls, detective controls should be layered to the extent possible. A good way to design detective controls is to look at the steps in a typical attack and then implement controls in such a way that the key steps are identified and trigger alerts.

Below is a simplified example of such an approach:

Attack StepKey Detective Control
Gain access to restricted network (bypass network access control)Network access control alerts for unauthorized devices
Discover active systems and servicesIDS / IPS / WAF / HIPS; activity on canary systems that should never be accessed or logged into
Enumerate vulnerabilitiesIDS / IPS / WAF / HIPS; activity on canary systems that should never be accessed or logged into
Test for common and weak passwordsCorrelation of endpoint logs (e.g., failed login attempts, account lockouts); login activity on canary accounts that should never be used
Execute local system exploitAnti-malware; monitoring of anti-malware service state; FIM monitoring security-related GPO and similar
Create accounts in sensitive groupsAudit and alert on changes to membership in local administrator group, domain admin group, and other sensitive local and domain groups
Access sensitive dataLogging all access to sensitive data such as SharePoint, databases, and other data repositories
Exfiltrate sensitive dataData leakage prevention solution; monitor network traffic for anomalies including failed outbound TCP and UDP connections

This example is not intended to be exhaustive but, rather, in meant to illustrate the diversity of detective controls and the various levels and points at which they can be applied.

While every environment is slightly different, the general rules remain the same: implementing controls to detect attacks at common points will greatly increase the efficacy of detective controls while still sticking within a reasonable budget. The one big caveat in all of this is that, in order to be truly effective, detective controls need to be tuned to the environment; no solution will perform optimally right out of the box. At the end of the day, proper application of detective controls will still cost money and require resources. However, the impact of an attack will be reduced substantially through strong detective controls.

Back

Firewall Configuration Review

Firewalls are a spot of contention for many within the information security community. Many people put too much faith in a network firewall and assume that because there is one on the network somewhere, that they’re “hacker proof.” Others do not put enough faith in a network firewall because many are deployed improperly or they’re deployed in the wrong spot on the network, or not enough firewalls are deployed to provide adequate protection within their environment. There are seemingly endless technical challenges when it comes to proper deployment, configuration, management, and review of firewalling technology.

Regular review of firewall configurations and how they’re deployed is considered a best practice and really helps promote good configuration from the simple act of looking at it from time to time. If best practice isn’t enough reason, regulatory requirements such as PCI require you to perform regular firewall configuration reviews (Requirement 1.1.6).  The firewall isn’t a black box that you setup and walk away from. Many times, this is the heart of your critical network, and to continue smooth operations, it requires maintenance. Improper segmentation and rule set configuration are also likely one of the core reasons you failed your most recent penetration tests, but this is often lost on a lot of people. Sure the initial access vector was MS08-067 on a test server, but why was someone from the user segment able to talk directly to the test network in the first place? Take my word for it, periodic configuration reviews are very important, regardless of the technology.

Unless you’re intimately familiar with firewall technologies, performing a useful review of a firewall is quite difficult. Many businesses don’t have the luxury of a dedicated firewall configuration employee or team.

There are a lot expensive tools that will look at your configuration and give you some rule set and configuration recommendations, but those require capex and opex budget allotments as well as the expertise to get the most out of the tools to maximize your investment. Unless you’ve mastered the basics, buying a tool isn’t going to be a good use of limited information security budget dollars. If you don’t want a tool, there are a plethora of clumsily put together checklists that attempt to help you solve this problem. However, even the better checklists seem to be a response to regulation and ignore best practice and availability items.

So what is my brilliant revelation, you ask? Well, I’ve created a checklist of course! Before you run to the wood shed and grab the pitchfork, take a look at what I have. My checklist isn’t specific to a product, platform, or regulation. This should be a good general checklist that you can use in any environment and the risky items should become self-evident as you work through the checklist.

Here are the goods:

  • Firewall checklist (short) – short and to the point – for use on a regular basis. Use one form per device per quarter (or more frequently if you’re able). NetSPI recommends that you look at your firewalls as often as you can, within reason. 
  • Firewall checklist (long) – same as above, but this includes some long form descriptions about why this is on the list, as well as example values. The example can be neutral, positive, or negative. 

So how do I use these documents, you ask? Print out one of the checklists above. The first couple times it may help to use the long form with the explanations so you know what I’m asking and why. Once you’re comfortable, you can start using the short form. Every quarter, or whenever your firewall configuration cycle rolls around, print out a form for each of your firewall and access control devices. Go through the device configuration and fill out the form to the best of your ability. If you get stuck, reach out to any internal network and firewall administrators to help you understand what to write down. When you find an item that needs attention, create an internal project or ticket to correct that configuration or deployment problem. File the form away in a safe place. That’s it!

Over time, you should see the overall configuration of the firewalls improve, and you have a review trail that you can give your auditor if they ask about a firewall review requirement. When the business considers buying new firewalls or access control devices, pull out a form and run through it for each proof of concept deployment in your demo environment. If you buy a product and deploy it in demo, run through the checklist before you sign off on the deployment to your production environment.

This is version 1 of the document. If you have any feedback, or you know of other useful firewall checklists, please let me know.

Back

Binrev- Automate Reversing Windows Binaries for Pentesters

I made a script to chain together some common tools to reverse-engineer Windows applications. It has come in handy for me in several situations when an application contains hundreds of assemblies written in native C, .NET or Java.

What you can do with this?

  • Static analysis: you can do a basic manual code review for decompiled sources to discover hidden communication channels, search for hard-coded passwords, or SQL injection vulnerabilities.
  • Import decompiled projects to an IDE to reconstruct and modify the original source code
  • Call hidden native exported functions with rundll32

Here is a rough description of what it does, and what tools it is using:

  • For exe, dll files:
    • Detect and de-obfuscate for .NET libraries with de4dot
    • Decompile .NET libraries with JustDecompile
    • Zip decompiled source code to netsources.zip
    • Run strings against native libraries
    • Export call-able functions with dllexp. You can then try to run those functions with command Rundll32 <dll>,<function name>
    • Export dependencies with depends
    • Extract native resources with resourcesextract
  • For jar files:
    • Extract and combine java classes into a single zip file
    • Decompile java sources with procyon
    • Zip decompiled source code to javasources.zip

Requirements

Usage

1. Configure the correct path to the  installed tools in the script:

set justdecompile="JustDecompileJustDecompile" set dllexp="dllexpdllexp"
set peverify=”peverify”
set zip="7-Zip7z"
set strings="strings"
set de4dot=" de4dot-2.0.3de4dot"
set java7="C:Program Files (x86)Javajre7binjava"
set procyon="procyon-decompiler-0.5.7.jar"

2. Run

Binrev [Source folder] [Output folder]
Output
/java/decompiled: decompiled Java class files
/native: native win32 libraries
/native/resextract: native win32 resource files
/net/decompiled: decompiled .NET projects
/net/bin: .NET libraries and executables
/net/deobs: deobfuscated .NET libraries
/logs: strings on native libraries, exportable functions, dependencies, list of decompiled and native dlls
/other: unhandled file extensions

The script is available at https://github.com/NetSPI/binrev

Back

Identifying Rogue NBNS Spoofers

One of the easiest ways for us to capture and/or relay hashes on the network is through NBNS spoofing. We will primarily use Responder.py or the Metasploit nbns spoofing module . Both of these tools can be great for attackers to use during a pen test, but remediation options for fixing the underlying issues are limited. In response to a lack of available mitigation options, I’ve written a script to help identify NBNS spoofers on the network.

This script makes frequent NBNS requests for a non-existent host name (the default is NETSPITEST) and it then listens for NBNS responses. Since there shouldn’t be any responses for this host name, the listener will sit idle until a response is received. If a response is received, we will know that there’s a spoofer on the network. Once a spoofer is identified, email alerting and syslogging options are available to alert network administrators of the issue.

Example Usage:

sudo python spoofspotter.py -i 192.168.1.161 -b 192.168.1.255 -n NBNSHOSTQUERY -s 192.168.1.2 -e karl.fosaaen@example.com -f test.log

This example command will make custom queries for NBNSHOSTQUERY for the responder to respond to. It will send an email alert to karl.fosaaen@example.com when an attack is identified and responses will also be logged to test.log

Required arguments:

-i 192.168.1.110The IP of this host
-b 192.168.1.255The Broadcast IP of this host

Optional arguments:

-h, –help Show this help message and exit
-f /home/nbns.log,
-F /home/nbns.log
File name to save a log file
-S trueLog to local Syslog – this is pretty beta
-e you@example.comThe email to receive alerts at
-s 192.168.1.109Email Server to Send Emails to
-n EXAMPLEDOMAINThe string to query with NBNS, this should be unique
-R trueThe option to send Garbage SMB Auth requests to the attacker (not implemented yet)
-c trueContinue Emailing After a Detection, could lead to spam

Example Script Output:

$ sudo python spoofspotter.py -i 192.168.1.161 -b 192.168.1.255 -n testfakehostname -s 192.168.1.2 -e karl.fosaaen@netspi.com -f test.log
Starting NBNS Request Thread...
Starting UDP Response Server...
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:47.497274 from host 192.168.1.162
Email Sent
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:49.549245 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:51.600981 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:53.657044 from host 192.168.1.162
A spoofed NBNS response for testfakehostname was detected by 192.168.1.161 at 2013-09-04 12:03:55.721037 from host 192.168.1.162
^C
Stopping Server and Exiting...

The script is available out on NetSPI’s github page: https://github.com/NetSPI/SpoofSpotter

There is an additional option that I’m currently working on, to make your pen tester especially annoyed. The –R flag will set the SMB response option to try and authenticate with the spoofer’s system. Since the NBNS spoofing attacks are used to capture (or relay hashes), why not send the attacker some hashes. Why not send a ton of them and make the attacker take their time trying to crack them, or just overload their logs. This will probably annoy an attacker more than anything else, but anything to make their attack harder may give you extra time to respond.

On that note, it was a little difficult for me to write this tool, as I have a feeling it will come back to haunt me in a future pen test. Feel free to send me any comments or feedback on the script through this blog or through our github page.

Special thanks go out to our client who had the idea for this script.