Reconnaissance Detection (Blue Team)

As we move through this Red Team vs. Blue Team series, our intent is to provide insight into both sides of the struggle. That said, detecting reconnaissance activity is something that few blue teams spend much 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 and here we’ll explore some ideas.

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 pownage. While the red team in the prior post focused on active recon, the same preparatory actions can help mitigate passive reconnaissance activity. Our team regularly helps clients conduct open-source data collection to help 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 witnessed in the prior red team post is 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...html"; 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.