Proactive detection content: CVE-2019-0708 vs ATT&CK, Sigma, Elastic and ArcSight

I think the most of security community has agreed that CVE-2019-0708 vulnerability is of critical priority to deal with. And while saying “patch your stuff!” feels like the first thing that one should think of, the memories of WannaCry and NotPetya are still fresh in my mind. We know that patching ain’t gonna happen at the speed and on the scale it needs to be. And thus we are, yet again, building up the detection rules!

A little yet important detail: the vulnerability CVE-2019-0708 is related to Remote Desktop Services (RDS), so actual Microsoft implementation of using the Remote Desktop Protocol (RDP) on Windows. RDP protocol itself is fine. I feel like this statement needs to be here to avoid all kinds of hype similar to the one we’ve seen during the Wannacry outbreak.

The “BlueKeep” hashtag was first used by Kevin Beaumount. I’ve picked it out for 2 reasons: GoT reference and to find relevant posts on twitter, as one can not simply hashtag a CVE (unless one removes the dashes). BlueKeep is just making twiterops easier 😉

https://twitter.com/GossiTheDog/status/1128348383704485895

Turning the scales in defenders’ favor.
To establish detection theory we have to consider two threat models:

1. Worm threat, similar to WannaCry scenario.
2. APT Actor, using the vulnerability as part of more sophisticated campaign, just like EternalBlue & SMB were merely a part of NotPetya disaster.

To identify assets at risk we will refer to the following table, shared by the courtesy of Dragos:

source: https://dragos.com/blog/industry-news/ics-impact-from-microsoft-rdp-vulnerability/

Can the CVE-2019-0708 be used for Initial Access on a big scale similar to Wannacry? A quick peek at Shodan data reveals plenty of machines on the internet with port 3389 exposed and running the potentially vulnerable versions of Windows:

https://www.shodan.io/search?query=port%3A3389+os%3A%22Windows+7+or+8%22

https://www.shodan.io/search?query=port%3A3389+2003

https://www.shodan.io/search?query=port%3A3389+2008

https://www.shodan.io/search?query=port%3A3389+os%3A%22Windows+XP%22

And in total we are looking at 2.375 million hosts with RDP reachable from internet – but do not draw the conclusion just yet!

https://www.shodan.io/search?query=Remote+Desktop+Protocol

Quoting Dan Tentler tweet from April 23 2017 “not all those hosts are windows, and not all those ports are smb”. Adapting this to the present day “Not all of those 2.3 million hosts are windows and not all those ports are services vulnerable to the CVE-2019-0708”. If we compare this to WannaCry timeline we are at the stage where MS-17010 is already out, EternalBlue is not yet out and thus we can’t go and scan for the next DoublePulsar. And until such PoC exists and someone scans for backdoor present, just like Dan did 2 years ago, we can’t be absolutely sure that things are going south. They are however “about to” get to that stage and perhaps we still have 30 days to put defenses in place, perhaps less.

https://twitter.com/Viss/status/856227372785221632

While we can debate on whether those machines are used by real organizations, their patch status, network segmentation etc., it is common knowledge that many companies still operate the vulnerable versions of Windows and patching cycles may be tough for those systems. Also in comparison to Wannacry, we see roughly 24K+ potentially exploitable hosts vs 140K+ hosts with DoublePulsar facing internet 3 weeks before the incident.

The bigger danger at this stage is the exploitation of CVE-2019-0708 once inside the organization to quickly compromise hosts and for Lateral Movement. And since Exploit PoC is not out as of time of writing of this article (many fake ones are however) we will leverage every tool at our disposal to build detection -before- the exploit is even out.

Considering all of the above the top-3 things you can do as a defender are:

1. Deploy proactive detection content.
2. Rigorously advocate patching or mitigating the vulnerability.
3. Keep track on the situation development following input from researchers your trust.

To reinforce some of the points I’d like to refer to 2 tweets from Florian Roth on the problem:

Sigma rules, first to the rescue.

The first rule, further referenced as Sigma #1, was shared by courtesy of Markus Neis at Sigma github repo for addressing the Lateral Movement technique T12010 / Exploitation of Remote Services https://attack.mitre.org/techniques/T1210/ :

Within one hour, a similar rule (Sigma #2) was published at SOC Prime TDM by Roman Ranskyi as a community / free to use with some distinctions in the detection logic extending to T1036 / Masquerading https://attack.mitre.org/techniques/T1036/ and T1046 / Network Service Scanning https://attack.mitre.org/techniques/T1046/ .

Basically we have a TLP:WHITE and TLP:GREEN detections out there, before exploit! But is this enough to detect a full scale attack?

Machine Learning, taking it one step further.

Let us explore how Machine Learning capabilities can give us a bit of an edge on the problem and start with creating a recipe for the Elastic stack.

ML Recipe: Detect Lateral Movement over RDP potentially related to CVE-2019-0708

Theory

An excessive number of unique destination IP addresses in RDP connections initiated from the one host during limited time window can be an indication of the Lateral Movement and spreading of the worm that uses RDP protocol as propagation method (using the RDS exploit related to CVE-2019-0708 vulnerability).

Description

This use case recipe identifies source IP addresses which potentially can be points of RDP worm propagation or Lateral Movement via RDP / T1076 across network segments.

Effectiveness

This use case recipe is provided as part of an automated Proactive Detection for Remote Desktop Services Remote Code Execution Vulnerability (CVE-2019-0708) not yet existent RDP worm, which is expected to exploit vulnerability and use RDP for the Lateral Movement across internal LAN segments. Additional information in regards RDP worm behavior after observing it in the wild can be used for the recipe tuning to produce more effective detection results.

Use Case Type

Elementary Attack Behavior (EAB) – This use case detects anomalies associated with elementary attack behaviors. Each detected anomaly is assigned a normalized Anomaly Score, and is annotated with values of other fields in the data that have statistical influence on the anomaly. Elementary attack behaviors that share common statistical Influencers are often related to a common attack progression.

Use Case Data Source

Netflow events, VPC flow logs of similar data in ECS format, which contain logs of RDP connections between Windows hosts inside internal LAN segments.

Use Case Recipe

Input Features and Candidate Influencers

Example Elasticsearch Index Patterns:

ecs-netflow*

Example Elasticsearch Query:

“query”: {“term”: {“destination.port”: {“value”: 3389″,”boost”: 1}}}

Machine Learning Analysis / Detector Config:

Detector(s): high_distinct_count(destination.ip) over source.ip
Bucketspan: 15m
Influencer(s): source.ip

Exploring ML outcomes in Elastic stack.

The single metric view does find us the drones we were looking for. So the better dataset we have in place, the more accurate detection of outliers will be.

The Anomaly Explorer helps to explain the story of usual RDP connections vs a worm-like behavior or a super-hard working admin which may or may not be working for the APT threat actor 😉

The warm tube sound of ArcSight correlation engine.

By this stage we have detection logic clearly defined, lets see if we can apply it on the tech that many companies are still using as primary SIEM tool. There are several tasks we will try to solve in regards to the coming threat:

1. Identify the assets at risk on automated basis.
2. Track anomalous RDP activity on assets above.
3. Attempt to detect Lateral Movement by leveraging Sigma and behavior based rules.

Task #1: is where we can rely on several functions in ArcSight.

Make a list of assets vulnerable to CVE-2019-0708 by tapping into Asset & Network model that (should be) populated by any vulnerability scanner that provides CEF output (Qualys, Nessus or even nmap will do the trick).

What if we do not have a scanner? We can track potentially vulnerable hosts by making a filter on Windows XP, 7, 2003 and 2008 assets either on Asset & Network model basis or based on Windows Event IDs generated by those versions which are distinct from newer versions of Windows.

Task #2: to substitute for Machine Learning we will make a rule that picks up Firewall and Netflow events based on Categorization and stores RDP source & destination IPs to the Active List. This way we can find first connection to/from potentially/confirmed vulnerable assets. Additionally we will build Trends to profile RDP connections and detect traffic Spikes by connection count.

Task #3: porting the Sigma rule #1 from query to real-time correlation will cover the detection of Lateral Movement T1210. To accomplish this I’ve copied the Sigma #1 source into Uncoder.io to produce ArcSight query. A nice thing about ArcSight queries is that by having some knowledge of the language one can easily turn the code into the filter for real-time correlation rule.

Put it together and plug it into your SOC!

For ArcSight the content pieces above are tied into a single dashboard which should remain empty under normal operations. To get the events rolling to main SOC channel add a lightweight rule to consume correlated alerts from the active channel “Correlation Event Details”.

For Elastic based SOC we’ve added a simple Kibana dashboard. It displays RDP spikes and Machine Learning visual for finding outliers based on netflow traffic as well as details on Sigma rule triggers, impacted hosts etc.

If you’re already using the SOC Prime dashboard for Watcher management you can explore the data through the prism of MITRE ATT&CK and pivot between the Tactics, Techniques, affected Users, Computers, observe attack Timeline, manage Watchers, pivot to Sigma rules and cases via SOC Workflow app. All of that without leaving Kibana interface.

Elastic, ArcSight or Sigma?

If we just use ATT&CK as a benchmark, Elastic is the winner being 1 technique ahead.

The main advantage of the Elastic stack is its ability to combine both Machine Learning and modern Threat Hunting queries based on Sigma. Remember that the re-factor of Sigma rules to real-time correlation queries does not find Masquerading / T1036 on ArcSight.

However, it is worth noting that it is actually easier to setup ArcSight to leverage data from vulnerability scanners for cross-device correlation. Combined with all the other log sources in detection rule package can be more effective for many organizations.

If we look at the task from the point of the speed and cost of detection development Sigma clearly leads the way. As long as your SIEM or EDR supports Sigma or you have Sysmon logs from all your machines including XP, 7, 2003 and 2008 this will be an optimal solution for you. Once again, the advantage of a bigger detection package vs single rule is mainly based on our assumption that a real attack will leverage RDP for lateral movement. There is no one size that fits all when it comes to threat detection. The final score will be set when the real working exploit is out and we can build out the detection, very likely using Sigma rules. At the end of the day, we have built a Proactive Detection content based on Rules and Machine Learning for the “Known Unknown”, just like Dr. Anton Chuvakin recently stated in his post: https://blogs.gartner.com/anton-chuvakin/2019/04/30/rule-based-detection/ .

 Don’t forget the Prevention and Patch your stuff

Learn on mistakes of the others, patching this in advance will be as beneficial as if you had all SMB patched during Wannacry outbreak. If you get a no on this from the patch team, deploy detections, test the backups and delegate the risk. https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/

Links to free detection content and mappings to MITRE ATT&CK

1. Sigma #1 by Markus Neis https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_susp_rdp.yml Lateral Movement; T1210; log sources: microsoft sysmon.
2. Sigma #2 by Roman Ranskyi https://tdm.socprime.com/tdm/info/2159/ Lateral Movement, Defense Evasion, Discovery; T1210, T1036, T1046; log sources: microsoft sysmon.
3. ArcSight .ARB rule pack https://tdm.socprime.com/tdm/info/2160/ Lateral Movement, Discovery; T1210, T1046, T1076; log sources: firewall, netflow, vulnerability scanner, MS Active Directory logs, Sysmon.
4. Elastic stack rule pack https://tdm.socprime.com/tdm/info/2160/ Lateral Movement, Defense Evasion, Discovery; T1210, T1036, T1046, T1076; log sources: netflow, MS Active Directory logs, Microsoft Sysmon.

SOC Workflow App community edition: https://github.com/socprime/soc_workflow_app_ce

/Stay safe