The team at FIRST (Forum of Incident Response and Security Teams) reached out to talk about my upcoming presentation on Windows credential attacks at their annual conference. We spoke about why enterprise credential protection is so important and some of the recent Microsoft updates to help minimize the attack surface. The entire Windows credential infrastructure has been under unceasing attack over the last couple of years, and amazingly things are about to get far worse. New tools like Bloodhound and Death Star are using graph databases to effortlessly map account permissions and sessions, greatly magnifying poor credential hygiene. At the moment, it is hard to imagine a larger threat to the enterprise. Podcast:

https://media.first.org/podcasts/FIRST2017_ChadTilbury.mp3

 

If you will miss FIRST2017, I will be presenting a complementary presentation at the SANS DFIR Summit on June 22, 2017.

Note:  This article originally appeared on the CrowdStrike blog.  Look here for additional context.

Detecting reconnaissance activity is something that few blue teams spend time on.  Networks are barraged with a near continuous stream of scanning, and determining targeted activity versus Internet noise can be exceedingly difficult.  However, there are a few things you can do to counter activity in this early stage of an attack.

Self-Recon is the Best Recon

Knowing that reconnaissance is ubiquitous, your best defense is to get ahead of the game and scan your own networks.  Schedule regular asset identification and vulnerability scans, and prioritize vulnerability patching.  If someone on your team is regularly testing for SQL injection vulnerabilities in your critical web applications, you won’t have to spend your weekends remediating sqlmap pwnage.  The same preparatory actions can help mitigate both active and passive reconnaissance activity.  Our team regularly helps clients conduct open-source data collection to identify unnecessary information leakage by company or employee assets.  This is exactly what a red team should be doing – helping the organization anticipate attacks and limit their attack surface.

Detection – Look Inside

Scanning activity is typically not difficult to detect on its own.  As an example, does this look like normal Googlebot activity?

Figure 1: Nikto Scan as Seen in Weblogs

Even evasive probes can be identified via frequency analysis like monitoring for number of failures per IP address or stacking user agent strings to find anomalies.  It is amazing how often adversaries manage to make a mistake in their fake user agent or fail to change the default provided by their scanners.

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
mozilla/5.0(compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:2.2.0.3) Gecko/20100101 Firefox/37.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10; rv:33.0) Gecko/20100101 Firefox/33.0
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2224.3 Safari/537.36
Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Figure 2: Stacking Analysis of Useragents.  Can You Spot the Outlier?

While this looks easy, what makes detection futile is the massive amount of recon activity pointed at your Internet-facing servers.  Instead, focus your efforts on your internal network.  Many organizations work so hard on defending Internet-facing resources that their internal servers are largely ignored.  This is at their peril, because once a foothold in the network is established, attackers commonly sweep for internal web applications to help pivot, elevate privileges, and collect sensitive data.

Recon detection is much more feasible when reviewing internal server logs.  You should see a relatively small set of user agent strings for devices present in your enterprise — a Googlebot querying your internal resources would be highly suspicious.  Scanning activity should also be easy to identify, particularly once you filter out your own vulnerability scanner activity.  As an example, imagine how unusual it would be to see something like Figure 3 in an internal application server log.

Figure 3: Web Log Identifying a Sqlmap Scan

Automating Detection

Automated detection of common reconnaissance activity is far more desirable than relying upon intermittent manual review of internal logs.  Tools like web application firewalls in monitor mode can reliably detect common reconnaissance activity like SQL injection, and alerts are more accurate when focused solely on internal requests.   Perhaps the most effective detective capability is network security monitoring (NSM).  It requires internal sensor placement and visibility, but can pay dividends throughout the attack cycle.  A quick review of the excellent Emerging Threats open rulesets shows a variety of signatures available to detect nefarious actions at the reconnaissance stage.  Two examples are shown in Figure 4.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”ET SCAN Possible SQLMAP Scan”; flow:established,to_server; content:” AND “; http_uri; content:”AND (“; http_uri; pcre:”/\x20AND\x20[0-9]{6}\x3D[0-9]{4}/U”; detection_filter:track by_dst, count 4, seconds 20; reference:url,sqlmap.sourceforge.net; reference:url,www.darknet.org.uk/2011/04/sqlmap-0-9-released-automatic-blind-sql-injection-tool/; classtype:attempted-recon; sid:2012755; rev:3;)

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:”GPL EXPLOIT unicode directory traversal attempt”; flow:to_server,established; content:”/..%c1%9c../”; http_raw_uri; reference:bugtraq,1806; reference:cve,2000-0884; reference:nessus,10537; classtype:web-application-attack; sid:2100983; rev:19;)

Figure 4: Sample Emerging Threats Signatures for Recon Activity

Once monitoring is in place and your sensors have been tuned, NSM alerts like the one in Figure 5 can easily lead to reconnaissance detection.

{“timestamp”:”2016-02-10T09:50:04.005484+0000″,”flow_id”:140389013543568,”event_type”:”alert”, “src_ip”:”172.16.30.149″,”src_port”:56173,”dest_ip”:”172.16.10.70″,”dest_port”:80,”proto”:”TCP”,”alert”:{“action”:”allowed”,”gid”:1,”signature_id”:2100983,”rev”:19,”signature”:”GPL EXPLOIT unicode directory traversal attempt”,”category”:”Web Application Attack”,”severity”:1,”tx_id”:0}, “payload_printable”:”0mk………….GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.1\r\nHost: 172.16.10.70\r\nConnection: Keep-Alive\r\nQua”,”stream”:1}

Figure 5: Example Suricata Alert Triggered by Scan of Application Server

Another NSM option growing in popularity is the Bro IDS.  Bro’s event engine and policy scripting allow for very good anomaly detection.  Luckily, there are already scripts for alerting on things like SQL injection, such as detect-sqli.bro.  To make detection feasible, you will need to scale your efforts and get your alerts into an analysis tool.  Our team uses Splunk, and Figure 6 shows a collection of Bro SQL injection alerts primed for analysis.

Figure 6: Bro SQL Injection Alerts Imported into Splunk

Conclusion

While there are many more lucrative opportunities to detect attacker activity further in the kill chain, reconnaissance activity should not be ignored.  Recon your own network and get an attacker-eye view of potential weakness.  Architect monitoring of critical internal networks and systems and focus your detective efforts there.  Start with hunting and then look to automate your high-fidelity signatures.

PowerShell is becoming ubiquitous in the Microsoft ecosystem, and, while it simplifies administration, it opens up a nearly unprecedented suite of capabilities for attackers.  Nearly every malicious activity imaginable is possible with PowerShell: privilege escalation, credential theft, lateral movement, data destruction, persistence, data exfiltration, and much more.  Malicious PowerShell is being used in the wild, and CrowdStrike has seen an uptick in the number of advanced adversaries employing it during breaches.  Dmitri Alperovitch wrote about one of these actors, Deep Panda, in his article “Deep in Thought: Chinese Targeting of National Security Think Tanks.”  Attackers are leaning more on PowerShell because it is readily available and gets the job done with an added bonus of leaving behind almost no useful forensic artifacts.  Jaron Bradley and I previously tackled the subject of command-line auditing in the CrowdCast, “What Malware? Hunting Command Line Activity”.  I am pleased to report that there have been some significant upgrades to command line logging since that webcast.

Process Creation Events

Starting with Server 2012R2, Microsoft released a new group policy setting to enable the recording of full command lines in Process Tracking audit events.  When released, logging was restricted to Windows 8.1 and Server 2012R2 systems, but it has since been back-ported due to popular acclaim.  With the proper patches, any modern Windows system (Windows 7 and newer) can now enable this feature.  One caveat to this significant upgrade is that Process Tracking creation must be enabled in your audit policy.  In fact, Event ID 4688 (Process Creation) is used to record the command lines (see Figure 1).  Historically, this has been a tough sell due to the number of events generated, but, even without command line information, these events can be very useful when hunting or performing incident response.  We have seen this implemented successfully in multiple large environments through the use of centralized logging.  If you do not have this enabled on your sensitive networks, you should absolutely consider it — before you need it.  You can reference the Microsoft Technet article here.

Figure 1: Process creation event recording executed command line

PowerShell Auditing

I am still astonished that something as omnipotent as PowerShell was baked into the world’s most common operating system without security ramifications being considered or adequate security controls provided.  Restricting access to PowerShell is notoriously difficult.  As an example, the PowerShell Empire project has a capability to inject the required .NET assemblies into memory, allowing PowerShell functionality even if PowerShell.exe has been removed or blocked on the system.  Perhaps the only way to truly prevent malicious PowerShell activity is to stop an attacker from achieving administrative privileges.  Since that has proven extremely difficult in most networks, detection is currently your best bet.  Unfortunately, until recently, PowerShell auditing was dismal and ineffective.  A module logging capability has been present since PowerShell v3, but it is difficult to instrument and very unlikely to be used in most organizations.  It was not until the recent PowerShell v5 release that truly effective logging was possible.

All Hail Script Block Logging!

A script block can be thought of as a collection of code that accomplishes a task.  Script blocks can be as simple as a function or as full-featured as a script calling multiple cmdlets.  Script block auditing captures the full command or contents of the script, who executed it, and when it occurred.  Audits are recorded as event log entries in the Microsoft-Windows-PowerShell/Operational log regardless of how PowerShell was executed – from a command shell, the integrated scripting environment (ISE), or via custom hosting of PowerShell components.  Event ID 4104 records the script block contents, but only the first time it is executed in an attempt to reduce log volume (see Figure 2).

Figure 2: PowerShell v5 Script Block Auditing

Needless to say, script block auditing can be incredibly helpful when trying to piece together evil PowerShell activity.  While logging is not enabled by default, the PowerShell team did sneak in the facility to identify potentially malicious script blocks and automatically log them in the PowerShell/Operational log, even with script block logging disabled.  Hence, in environments running PowerShell v5, you should start seeing actionable information populating the Microsoft-Windows-PowerShell/Operational log by default.  That, of course, is the only rub – you need to upgrade to PowerShell version 5 to partake.  But there is great hope on the horizon for those who get there.