Skip navigation
All Places > Information Security > Blog

With the scent of scorched internet still lingering in the air from the WannaCry Ransomworm, today we see a new scary-and-potentially-incendiary bug hitting the twitter news. The vulnerability - CVE-2017-7494 - affects versions 3.5 (released March 1, 2010) and onwards of Samba, the defacto standard for providing Windows-based file and print services on Unix and Linux systems. Check out Samba's advisory for more details.


We strongly recommend that security and IT teams take immediate action to protect themselves.


Who is affected?

Many home and corporate network storage systems run Samba and it is frequently installed by default on many Linux systems, making it possible that some users are running Samba without realizing it. Given how easy it is to enable Samba on Linux endpoints, even devices requiring it to be manually enabled will not necessarily be in the clear.


Samba makes it possible for Unix and Linux systems to share files the same way Windows does. While the WannaCry ransomworm impacted Windows systems and was easily identifiable, with clear remediation steps, the Samba vulnerability will impact Linux and Unix systems and could present significant technical obstacles to obtaining or deploying appropriate remediations. These obstacles will most likely present themselves in situations where devices are unmanaged by typical patch deployment solutions or don’t allow OS-level patching by the user. As a result, we believe those systems may be likely conduits into business networks.


How bad is it?

The internet is not on fire yet, but there’s a lot of potential for it to get pretty nasty. If there is a vulnerable version of Samba running on a device, and a malicious actor has access to upload files to that machine, exploitation is trivial.


In a Project Sonar scan run today, Rapid7 Labs discovered more than 104,000 internet-exposed endpoints that appear to be running vulnerable versions of Samba on port 445. Of those, almost 90% (92,570) are running versions for which there is currently no direct patch available. In other words, “We're way beyond the boundary of the Pride Lands.” (sorry - we promise that’s the last Lion King reference. Maybe.)


Samba 445 major_minor_vulnerable_version_counts_updated.png

We’ve been seeing a significant increase in malicious traffic to port 445 since May 19th; however, the recency of the WannaCry vulnerability makes it difficult for us to attribute this directly to the Samba vulnerability. It should be noted that proof-of-concept exploit code has already appeared on Twitter, and we are seeing Metasploit modules making their way into the community.


We will continue to scan for potentially vulnerable endpoints and will provide an update on numbers in the next few days.


RESEARCH UPDATE – 5/25/17We have now run a scan on port 139, which also exposes Samba endpoints. We found very similar numbers to those for the scan of port 445. On port 139, we found approximately 110,000 internet-exposed endpoints running vulnerable versions of Samba. Of these, about 91% (99,645) are running older, unsupported versions of Samba (pre-4.4).


Samba 139 major_minor_vulnerable_version_counts_updated.png



What should you do to protect yourself?

The makers of Samba have provided a patch for versions 4.4 onwards.


A workaround for unsupported and vulnerable older versions (3.5.x to 4.4.x) is available, and that same workaround can also be used for supported versions that cannot upgrade. We also recommend that users of older, affected versions upgrade to a more recent, supported version of Samba (4.4 or later) and then apply the available patch.


Organizations should be reviewing their official asset and configuration management systems to immediately identify vulnerable systems and then perform comprehensive and regular full network vulnerability scans to identify misconfigured or rogue systems. Additionally, organizations should review their firewall rules to ensure that SMB/Samba network traffic is not allowed directly from the internet to their assets.


Many network-attached storage (NAS) environments are used as network backup systems. A direct attack or worm would render those backups almost useless, so if patching cannot be done immediately, we recommend creating an offline copy of critical data as soon as possible.


In addition, organizations should be monitoring all internal and external network traffic for increases in connections or connection attempts to Windows file sharing protocols.


How can Rapid7 help?

We are working on checks for Rapid7 InsightVM and Rapid7 Nexpose so customers can scan their environments for vulnerable endpoints and take mitigating action as quickly as possible.


We also expect a module in the Metasploit Framework very soon, enabling security professionals to test the effectiveness of their mitigations, and understand the potential impact of exploitation.


We will notify users of the availability of these solutions as soon as they are available.


PRODUCT UPDATE – 5/25/17 We have authenticated checks available for Samba CVE-2017-7494 in Rapid7 InsightVM and Rapid7 Nexpose.  The authenticated checks relate to vendor-specific fixes as follows:

  • ubuntu-cve-2017-7494
  • debian-cve-2017-7494
  • freebsd-cve-2017-7494
  • oracle_linux-cve-2017-7494
  • redhat_linux-cve-2017-7494
  • suse-cve-2017-7494


PRODUCT UPDATE 2 – 5/25/17 – We now have both authenticated and unauthenticated remote checks in Rapid7 InsightVM and Rapid7 Nexpose. In the unauthenticated cases we use anonymous or guest login to gather the required information, and on systems that are hardened against that kind of login, the authenticated remote check is available.


Not a Rapid7 customer? Scan your network with InsightVM to understand the impact this vulnerability has on your organization. We also have a step-by-step guide on how to scan for Samba CVE-2017-7494 using our vulnerability scanners.


PRODUCT UPDATE 3 - 5/25/17 - We now have a Metasploit module available for this vulnerability, so you can see whether you can be exploited via Samba CVE-2017-7494, and understand the impact of such an attack. Download Metasploit to try it out.


P.S. yes, we know the lion is called Simba. But who doesn't love a gratuitous and tenuous cartoon lion reference?! Rowr.

This blog is a continuation of our blog post series around the CIS Critical Controls.


The biggest threat surface in any organization is its workstations. This is the reason so many of the CIS Critical Security Controls relate to workstation and user-focused endpoint security. It is also the reason that workstation security is a multibillion-dollar industry. For the next two posts, I’ll be covering the specifics of Controls 7 and 8, which focus on the biggest weak points in Information Security: web browsers, email, and malware. This set of posts is intended to help you understand how to properly control the threat surface without limiting usability.


Email and web access are critical for most day-to-day operations in any organization, but they’re also a significant source of attacks and incidents. Properly securing email servers, web browsers, and mail clients can go an extremely long way in limiting incidents that routinely make news headlines. Good configuration and control of email and web browsers is also going to significantly reduce the number of low-level incidents your organization will encounter on a monthly basis.


What the CIS Critical Control 7 covers

Critical Control 7 has eight sections that cover the basics of browser and email client safety, secure configuration and mail handling at the server level. The control pays specific attention to concepts like scripting and active component limiting in browsers and email clients, attachment handling, configuration, URL logging, filtering and whitelisting. The premise of the control is fairly straightforward: browser and email client security are critically important for low-level risk mitigation. If your browsers and email aren’t secure, your users and your network aren’t either.

It’s worth noting that this control as well as Controls 1, 2 and 8 are often directly connected, and tie into quite a few of the other 20 pretty easily. As I mentioned in the posts for Controls 1 and 2, properly implemented browser and email security will improve any organizations security posture with regards to the other controls.


How To Implement it

Since this control touches on a number of typically different IT functions, it’s important to have the people who run the various systems implicated on board when working with it. Personally, I love dealing with controls like this, as they have the potential to unify an IT or IT/IS department in terms of strategy and process, which always helps improve security awareness and capacity.


Start with filtering

Successful implementations of Control 7 usually work from two sides: the server/network side and the endpoint configuration/application side. Networking and email server teams should start by limiting how attachments are handled and forwarded from the mail server to clients, and implement content filtering first. In many cases, this is already set up on mail servers for purposes of space management or security, but it’s worthwhile to go a step further and ensure that potentially malicious content is being filtered before it reaches any user’s inboxes.


Implement SPF, or something similar

At the same time, implementing Sender Policy Framework at a DNS level and on the mail servers should cut down on the amount of spam and malicious traffic that is coming in to the system. It should be noted that while SPF is not an anti-spam measure, it's effective as a control for malicious mail traffic. It’s important that the SPF records and implementation include receiver-side verification (this is actually directly mentioned in sub-control7.7). Typically, this section of Control 7 is overlooked, as it's a high-effort measure, but it's worthwhile for a number of reasons, including SMTP traffic reduction, better junk mail sorting, compatibility with other services, and a general reduction in those "I didn't send a message to this person, but I'm being notified that I did" conversations with your colleagues.


It's also worth noting that there are a few pitfalls in implementing it. has a good overview of SPF best practices, which should serve as a good starting point. While the CIS recommends SPF, there are alternative systems and strategies. I'd suggest looking into DKIM and DMARC, since they work well in combination with SPF although they're not directly mentioned in the CIS Critical Control 7. If you're using a third-party provider for e-mail, it's assessing this with their personnel; they may have extra expertise on hand, or have done it already.


Configure all the things!

By far, the hardest part of this control is managing the browsers and clients on your network. It’s inevitable that there will be roadblocks, but the good news is that there are a number of good ways to handle browser configuration that should both enable your users, and limit the risks from 3908396264_351e7f2ae6.jpgmalicious code in websites (and any attachments that do get through your already iron-clad email server). Typically, Rapid7 recommends that workstations have a “2 browser” system- one should be well secured, and seriously limit access for third-party scripting, ads, and any software that hasn’t been reviewed by the security team. The second should be used for general Internet access, and anything that is considered remotely risky.


The other configuration should usually be less secure, but limited in use to internal or organization specific services. Usually, this means script based applications or software that require old, out of date or insecure code and components. For example, if your corporate intranet relies on Flash and ActiveX scripts to manage employee benefits, it’s probably a good idea to set up a browser so that your users access the intranet with a specially configured browser for that task. This can be as simple as putting a link or batch file on workstation desktops with specific startup info for the browser, or leaving the homepage set to the specific resource in question. I’ve seen more complex configurations that rely on secure jumphosts, Citrix, or remote desktop and network limitations, but these are often cumbersome for most users, and not recommended.


One last bit of advice

The simple axiom to follow when implementing this control is: You need to make it simple for the users, or they will find a way around it. It's important to consider this when applying controls 7 and 8, because increasing complexity or the effort your users have to put in often leads to privilege misuse or other workarounds to defeat the controls. In this context, it's worth remembering that human error is still the major source of most breaches and incidents. This includes phishing and clickjacking campaigns, which often foil the best of us, despite well configured systems.


A note on URL requests, privacy and security

Subcontrol 7.4 specifically identifies URL request logging as a necessity for the identification of potentially compromised systems. This subcontrol actually overlaps with Critical Control 6, which Cindy Jones discussed in an earlier post. While it’s important to have this data for incident response and awareness purposes, it’s worth considering how long it’s kept, and how it’s managed; it’s extremely important that the request logs are considered private or limited-access data, and aren’t being shared in a way that could put users of your network at risk. This also applies to any TLS or encrypted traffic monitoring that you may be undertaking.


SPF diagram courtesy of

"Double Fail" image courtesy of Dmitry Baranovskiy via Flickr

Arapahoe Basin and ski poles banner courtesy of the author. As with security, proper configuration is often what makes or breaks good skiing.


Related Blog Posts:

Control 1: Inventory of Authorized and Unauthorized Devices Explained

Control 2: Inventory of Authorized and Unauthorized Software Explained

Control 3: Secure Configurations for Hardware & Software Explained

Control 4: Continuous Vulnerability Assessment & Remediation Explained

Control 5: Controlled Use of Administrative Privilege Explained

Control 6: Maintenance, Monitoring and Analysis of Audit Logs Explained

Executive Summary

In October of 2016, former Rapid7 researcher Phil Bosco discovered a number of relatively low-risk vulnerabilities and issues involving home security systems that are common throughout the United States, and which have significant WiFi or Ethernet capabilities. The three systems tested were offerings from Comcast XFINITY, ADT, and AT&T Digital Life, and the issues discovered ranged from an apparent "fail open" condition on the external door and window sensors, to weak, pre-shared WiFi access passwords, to cleartext communications over the network.

Rapid7 has been in touch with all three vendors over the last few months, per our standard disclosure policy, and was involved with both communicating the issues and helping to resolve them in a timely manner. Today, we're happy to report that all of the identified issues have been either resolved or sufficiently mitigated against! In all cases, customers who use these products for home security should not need to apply patches manually or otherwise alter their current system configurations for any software updates, as all vendors have the capability to remotely update any problematic networked components.

Before getting into the technical details of the issues discovered, we'd like to state that risk of exploitation of these issues was relatively low before fixes were implemented. In all cases, attackers would have to be reasonably close to the target's residence, and in some cases, be in possession of low-power jamming equipment. Attackers could not exploit these issues from across the Internet.

Finally, we also would like to acknowledge ADT, AT&T Digital Life, and Comcast XFINITY for their responsiveness and engagement in discussing, validating and resolving these issues in a timely fashion.



The issues discovered and documented in this advisory were all discovered using standard assessment tools and techniques applied to a single residential installation in the researcher's home, and all equipment was originally installed by authorized technicians. All screenshots, video captures, and other evidence of compromise were collected from the researcher's own systems.

It's important to note that the two "Insecure Sensor Fail Open" issues identified as R7-2016-26.1 and R7-2016-27.1 were discovered by using radio frequency (RF) shielding, rather than RF jamming.

In a shielded test, the researcher is able to guarantee a failure event on the sensors by physically wrapping the sensors in RF-blocking material, and observing the resulting behavior on on the systems' base stations. In this way, the researcher may be able to simulate a radio interference condition, rather than actually creating one. While shielding has the advantage of creating a more controlled failure event, one shortcoming of this technique is that shielding will not activate any RF interference detection on the base stations, since no detectable RF noise is generated.

In short, shielding creates an ideal situation for testing failure conditions, while an active RF jamming event more closely resembles an actual attack. Unfortunately, intentionally creating RF interference, even for the purpose of testing one's own equipment, continues to be a contentious subject in the offensive security testing community, and so shielding is meant as the closest approximation of what low power jamming would do.


Vulnerability Overview

Below is an overview of the vulnerabilities and exposures discovered during testing. Each vendor's home security platform is explored in turn, along with any recommended remediations or mitigations, as well as a statement provided by the vendor. Again, all vulnerabilities were disclosed and discussed privately with each vendor before publication.








Insecure Sensor Fail OpenADTR7-2016-26.1CVE-2016-6570Mitigated by sensor placement
Weak WPA2 Pre-Shared KeyADTR7-2016-26.2CVE-2016-6571Fixed
Cleartext WLAN CommunicationsADTR7-2016-26.3CVE-2016-6572Mitigated by R7-2016-26.2
Insecure Sensor Fail OpenAT&T Digital LifeR7-2016-27.1CVE-2016-6573Mitigated by sensor placement
Default physical access administrative credentialsAT&T Digital LifeR7-2016-27.2CVE-2016-6574Fixed
Insecure Network Administrative AccessAT&T Digital LifeR7-2016-27.3CVE-2016-6575Mitigated by R7-2016-27.2
Cleartext WLAN CommunicationsAT&T Digital LifeR7-2016-27.4CVE-2016-6576Mitigated by R7-2016-27.2
Cleartext Credential Storage and DisplayAT&T Digital LifeR7-2016-27.5CVE-2016-6577Mitigated by R7-2016-27.2
Weak WPA2 Pre-Shared KeyComcast XFINITYR7-2016-23.1CVE-2016-6568Fixed
Cleartext WLAN CommunicationsComcast XFINITYR7-2016-23.2CVE-2016-6569Mitigated by R7-2016-23.1

In the cases involving the WiFi networked components, potential attackers would have to be reasonably close to the target's residence and within line-of-sight, and are limited by the signal strength of the attacking equipment. They could not exploit these issues from across the internet, and could not scale these attacks outside of a limited geographic range.

In the cases of creating RF interference to cause external door and window sensors to go offline, the attacker would need to carefully modulate their interference signal strength in order to avoid triggering anti-jamming detection technologies already provided by the vendor. Triggering these detection mechanisms would cause an alert to be sent to the vendor's normal monitoring systems. In addition, onsite motion sensors installed as part of the complete security system would either be wired – and thus immune to radio frequency interference – or wireless, which would make it extremely difficult to jam both an external sensor and an internal sensor yet still avoid triggering anti-jamming detection.

In cases of the cleartext transmission vulnerabilities and exposures documented in this advisory, these are dependent on other vulnerabilities being exploited first. For example, if an attacker finds it impossible to associate to the network, it is immaterial (practically speaking) that the communications over that WiFi network are themselves in the clear, as all of the home security WiFi networks employ industry-standard encryption provided by WiFi Protected Access II (WPA2). That said, a defense-in-depth posture is usually recommended for networks that carry sensitive information, so that a failure in one component does not expose the entire network and its assets to compromise.


R7-2016-26: ADT Home Security

Three issues were identified with ADT's home security solution: Exterior sensors appear to fail open when RF transmissions are blocked; systems were installed with a weak, pre-shared WPA2 key for authentication to the wireless network; and cleartext communications on that network.

A failure condition in the 908.42 MHz radio frequency band will cause the system to fail open, and the base system will fail to report a communications failure with the associated devices. In addition, due to a weak, pre-shared key shipping with the WiFi access point component of the product, an attacker can rapidly compromise the network on which the security cameras communicate. Finally, all communications to and from the security cameras are conducted in the clear. Once an attacker is associated with the WiFi network, it is possible to capture the administrative credentials to the camera and the provided access point's administrative credentials.


R7-2016-26.1: ADT Insecure Sensor Fail Open (CVE-2016-6570)

A failure condition in the sensor's RF band can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. Exploiting the insecure fail open issue can be accomplished with commodity RF jammers.

Failing Open

In order to cause the system to fail open, an attacker would need to block communication in the sensor's RF band. While jamming devices are illegal to operate in the US, they are relatively easy to buy or build using commodity electronics equipment. This issue is essentially identical to R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open, and those details are immediately applicable in this case.

For testing purposes, jamming was simulated by physically shielding the devices to effectively block all radio communications.


The RF jamming attack can be mitigated by two shipping solutions. One, the system's base station is equipped with interference detection, so an attacker would need to ensure that any jamming signal has sufficient power to effectively block communication from the exterior sensor, but not so much power as to be detected by the base station.

Two, many of ADT's home security systems are installed with interior, wired motion sensors. Because these sensors do not rely on RF communications, they are effectively immune to this attack, and therefore, any movement after jamming the exterior sensor will be alerted on by these motion sensors. In the case where interior motion sensors are wireless, again, the attacker would need to ensure that jamming is sufficient to block both the exterior sensor and the interior motion sensor, but not the base station. Such an attack would be extremely tricky to implement, require physical reconnaissance in order to plan the attack, and may be impossible depending on the placement of the base station and interior motion sensors.


R7-2016-26.2: ADT Weak WPA2 Pre-Shared Key (CVE-2016-6571)

Exploiting the weak WPA2 pre-shared key (PSK) can be accomplished with a WiFi deauthentication and offline cracking attack.


First, an attacker would locate the ADT gear, using standard tools such as the Aircrack-NG WiFi security assessment toolkit. Figure 1 demonstrates the use of airodump-ng.


Figure 1: Identifying associated devices

Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 2.


Figure 2: Deauthenticating an identified device

Doing this allows the attacker to capture the WPA2 handshake, which is then subjected to cracking with Aircrack-ng, as shown in Figure 3.


Figure 3: Bruteforce cracking of the WPA2 pre-shared key

Because the vendor-supplied password is exactly thirteen characters, consisting only of numbers, it generally does not take very much time to crack with typical consumer-grade hardware.


The vendor updated all components of customers' WiFi networks with a more complex generated password during the first quarter of 2017.


R7-2016-26.3: ADT Cleartext WLAN Communications (CVE-2016-6572)

Exploiting the cleartext communications can be achieved once the attacker is associated with the special-purpose WiFi network, and can provide an attacker with administrative credentials and direct camera feeds.

Camera Credential Collection

Once the attacker recovers the WPA2 pre-shared key, they can then connect to the device network and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 4.


Figure 4: ARP spoofing to recover the Base64 credentials

The attacker can then reuse these credentials to log in the cameras directly and access live video feeds, as seen in Figure 5.


Figure 5: Direct video feed of the researcher's residence (and cat)


The upgraded password complexity implemented as a solution R7-2016-26.2 makes associating to the WiFi network difficult to impossible, and thus, effectively mitigates the malicious use of cleartext communications on the WPA2 WiFi network.


R7-2016-27: AT&T Digital Life Home Security

Five issues were identified with AT&T Digital Life's home security solution: exterior sensors appear to fail open when RF transmissions are blocked; physical network access is governed by an easily-guessed default administrative credential; network administrative access does not challenge for a credential; the WiFi network uses cleartext communications; and saved credentials are stored and displayed in cleartext.

AT&T Digital Life's home security systems ship with a base station, window and door sensors, motion sensors, wireless cameras, and a mobile app, as described by the vendor.

A failure condition in the 433.92 MHz radio frequency band used by AT&T Digital Life's third party home security equipment can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices.

WiFi access control appears to be sufficient and reasonable, since the WPA2 network is secured with a 32-character password made up of uppercase, lowercase, and numeric characters.

Due to an installation error, access to this network can be accomplished via a physically accessible LAN Ethernet port to the base station, and access to the shipped Cisco management interface is controlled by easily-guessed default credentials. Since the time of this discovery, AT&T Digital Life has updated their installation procedures to ensure that this LAN Ethernet port is disabled after initial setup on customer sites.


R7-2016-27.1: AT&T Digital Life Insecure Sensor Fail Open (CVE-2016-6573)

A failure condition in the sensor's RF band can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. Exploiting the insecure fail open issue can be accomplished with commodity RF jammers.

Failing Open

In order to cause the system to fail open, an attacker would need to block communication in the sensor's RF band. While jamming devices are illegal to operate in the US, they are relatively easy to buy or build using commodity electronics equipment. This issue is essentially identical to R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open, and those details are immediately applicable in this case.

For testing purposes, jamming was simulated by physically shielding the devices to effectively block all radio communications. It should be noted that AT&T does not believe that jamming (unlike shielding) can be performed without triggering certain anti-jamming alerts.


The RF jamming attack can be mitigated by two shipping solutions. One, the system's base station is equipped with interference detection, so an attacker would need to ensure that any jamming signal has sufficient power to effectively block communication from the exterior sensor, but not so much power as to be detected by the base station.

Two, AT&T Digital Life's home security systems are typically installed with at least one interior, wireless motion sensor. In this case, the attacker would need to ensure that jamming is sufficient to block both the exterior sensor and the interior motion sensor, but not the base station. Depending on the placement of the interior motion sensor, such an attack could be extremely tricky to implement, since it would require physical reconnaissance in order to plan the attack, and may be impossible depending on the relative placement of the base station and interior motion sensors.


R7-2016-27.2: AT&T Digital Life Default physical access administrative credentials (CVE-2016-6574)

If an attacker is able to physically access the base station and connect to an enabled Ethernet port, access to an administrative interface is possible.

Physical-Only Administrative Access

Assuming an attacker can physically connect to the base station via an Ethernet port, they can connect to an administrative web service on the default gateway ( and provide the easily-guessed login credentials of "admin:admin." From here, the attacker has complete administrative control over the device and can learn the WiFi SSID and pre-shared key.

This key would be difficult to impossible to crack in an offline deauthentication attack, since it is a complex, 32-character string. However, once physical access is achieved and the administrative interface is loaded in a browser, the key is displayed to the logged-in attacker.


During testing, disabling the Ethernet diagnostic port was a manual step that field technicians could accidentally skip, and that appears to have been the case during the installation at the researcher's residence. Since this report, AT&T Digital Life has thoroughly reviewed its automatic post-installation verification procedures, and now ensures that every installation of its home security system does, in fact, disable the physical Ethernet port. Disabling this port does not require an on-premises visit, and can be achieved remotely by AT&T Digital Life. It is impossible to enable this port locally; field technicians must activate this port with an authenticated service call.


R7-2016-27.3: AT&T Digital Life Insecure Network Administrative Access (CVE-2016-6575)

If it is possible to learn the WPA2 pre-shared key, other administrative interfaces become available to the attacker over the local WiFi network.

Port 8090

Once the attacker is associated with the WiFi network, he can then connect to the administrative web interface for the system, which is listening on port 8090/TCP. This interface does not challenge for authentication credentials, and from this interface, the attacker can add or remove devices, cameras and keypads, and can also disarm any alarm-related functionality, as shown below.


Figure 6: Front door armed state


Figure 7: Disarming the front door sensor


Figure 8: Front door sensor is disarmed


As there is no reasonable way for an attacker to perform an offline bruteforce attack on the WPA2 key due to the strength of this pre-generated key, physical access is required as well as access to an active, administrative Ethernet LAN port. Therefore, due to remediations provided in R7-2016-27.1 and R7-2016-27.2 described above, this attack vector is effectively mitigated.


R7-2016-27.4: AT&T Digital Life Cleartext WLAN Communications (CVE-2016-6576)

If an attacker can achieve wireless administrative access, credentials can be learned through ARP spoofing.

Camera Credential Collection

Once the attacker recovers the WPA2 pre-shared key, he can then connect to the device network, and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 9.


Figure 9: Basic Authorization header collection


As with R7-2016-27.3 above, the remediations provided for R7-2016-27.2 effectively mitigate this attack, since the attacker can no longer learn the WPA2 pre-shared key.


R7-2016-27.5: AT&T Digital Life Cleartext Credential Storage and Display (CVE-2016-6577)

If an attacker can achieve wireless administrative access, credentials can be learned directly from associated devices. These credentials can be discovered without ARP spoofing by accessing the administration web page on port 8090, since it is displayed in cleartext, as shown in Figure 10.


Figure 10: Browsing to stored credentials


As with R7-2016-27.3 and R7-2016-27.4 above, the remediations provided for R7-2016-27.2 effectively mitigate this attack, since the attacker can no longer learn the WPA2 pre-shared key.


R7-2016-23: Comcast XFINITY Home Security

A certain generation of Comcast XFINITY's Home Security product was found to utilize a weak algorithm to generate its per-premise WPA2 security key. While a sufficiently random WPA2 key cannot be bruteforced, the weak keys generated by the algorithm in question could be bruteforced in one to two months on average with commodity hardware, giving a physically-proximate and persistent attacker access to the WiFi network over which the touchscreen and cameras communicate.

Once the attacker achieved access to the network, they could have captured administrative credentials to the camera and the access point, which are sent in the clear between the touchscreen and these two devices.

Finally, it was noticed that the URLs used to view camera feeds were not protected by session authentication. While session-controlled access to individual feeds is a more standard approach to securing video streams, the URLs were randomized with a sufficient (128-bit) keyspace to prevent live brute-forcing. Access is conducted over HTTPS, and the URLs are periodically regenerated. After discussing this approach with Comcast XFINITY and CERT/CC, we came to the conclusion that this implementation does not present any practical security concerns. Nonetheless, Comcast XFINITY agreed with our suggestion and has since implemented session authentication as an additional layer of security.

R7-2016-23.1: Comcast XFINITY Weak WPA2 Pre-Shared Key (CVE-2016-6568)

Exploiting the weak WPA2 PSK can be accomplished with a WiFi deauthentication and offline cracking attack.


First, an attacker would locate the Comcast XFINITY gear, using standard tools such as the Aircrack-NG WiFi security assessment toolkit. Figure 11 demonstrates the use of airodump-ng:


Figure 11: Identifying associated devices

Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 12:


Figure 12: Capturing the WPA2 handshake

Doing this allows the attacker to capture the WPA2 handshake, which is then cracked using aircrack-ng, as shown in Figure 13:


Figure 13: Bruteforce cracking of the WPA2 pre-shared key

Because the vendor-supplied password is exactly eight characters, consisting of uppercase letters and numbers, it is quite feasible to crack this password with typical consumer-grade hardware.


The vendor has updated all components of customers' WiFi networks with a much longer, mixed-character password, during a staged rollout across all installations throughout the first quarter of 2017.


R7-2016-23.2: Comcast XFINITY Cleartext WLAN Communications (CVE-2016-6569)

Exploiting the cleartext communications can be achieved once the attacker is associated with the special-purpose WiFi network, and can provide an attacker with administrative credentials.

Camera Credential Collection

Once the attacker recovers the WPA2 pre-shared key, they can then connect to the device network and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 14.


Figure 14: ARP Spoofing to capture Base64 credentials

The attacker can then reuse these credentials to log in the camera base station, and access live video feeds. An example taken from the researcher's camera is shown in Figure 15.


Figure 15: Video capture from the researcher's residence

Router Credential Collection

Both the administrative touch screen and the cameras log into the WiFi router periodically to check for firmware updates. By ARP spoofing the router interface, the router's administrative credentials can also be collected. This is shown in Figure 16.


Figure 16: ARP spoofing the router

Once administrative router access is secured, the attacker can perform all normal administrative functions, such as providing a malicious firmware update or redirecting DNS traffic to a name server controlled by the attacker, as seen in Figure 17.


Figure 17: Changing DNS addresses


The upgraded password complexity implemented as a solution to R7-2016-23.1 makes associating to the WiFi network difficult to impossible, and thus effectively mitigates the malicious use of cleartext communications on the WPA2 WiFi network.

Vendor Statement on R7-2016-23

Our customers’ safety and security is our top priority.  We have developed and deployed fixes for the issues reported by Rapid7, which they identified as low-risk. For the vast majority of affected customers, these issues are fully mitigated. A small number of XFINITY Home customers need to make manual updates, and we are contacting those customers by email and/or phone.


At XFINITY Home, we regularly perform stringent information security testing of our products, both before and after we launch them.  However, no product can ever be completely free of security vulnerabilities, and experts intent on hacking into any system will discover vulnerabilities.  So another way we maintain our customers’ trust is by responding quickly and effectively to reported vulnerabilities.


We are grateful to Rapid7 security researcher Phil Bosco and research director Tod Beardsley for responsibly disclosing these vulnerabilities to us.  While Rapid7 identified these issues as low risk, XFINITY Home moved quickly to remediate them.




All of the issues described in this vulnerability disclosure were discovered by former Rapid7 researcher Phil Bosco and disclosed by Rapid7 according to our standard disclosure policy.


Disclosure Timeline

R7-2016-26 (ADT)

  • Wed, Oct 26, 2016: Vendor contacted
  • Fri, Oct 28, 2016: Disclosed details to the vendor
  • Wed, Nov 09, 2016: Discussed details with the vendor
  • Fri, Nov 18, 2016: Disclosed details to CERT/CC
  • Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6570, CVE-2016-6571, and CVE-2016-6572
  • Fri, Jan 27, 2017: Discussed vendor's plans for remediation
  • Thu, Mar 16, 2017: Vendor confirmed remediation is on track
  • Fri, Apr 28, 2017: Further clarification from the vendor on mitigations (ongoing through May)
  • Wed, May 17, 2017: Public disclosure of R7-2016-26.


R7-2016-27 (AT&T Digital Life)

  • Wed, Oct 26, 2016: Vendor contacted
  • Mon, Nov 07, 2016: Details disclosed to the vendor
  • Wed, Nov 09, 2016: Discussed details with the vendor
  • Fri, Nov 18, 2016: Disclosed details to CERT/CC
  • Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6573, CVE-2016-6574, CVE-2016-6575, CVE-2016-6576, and CVE-2016-6577
  • Thu, Jan 12, 2017: Clarified fixes and mitigations with the vendor
  • Tue, Mar 28, 2017: Further clarifications on disclosure content with the vendor (ongoing through May)
  • Wed, May 17, 2017: Public disclosure of R7-2016-27.


R7-2016-23 (Comcast XFINITY)

  • Wed, Oct 26, 2016: Vendor contacted
  • Fri, Oct 28, 2016: Disclosed details to the vendor
  • Tue, Nov 08, 2016: Discussed details with the vendor
  • Fri, Nov 18, 2016: Disclosed details to CERT/CC
  • Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6568 and CVE-2016-6569
  • Fri, Jan 27, 2017: Discussed vendor's plans for remediation
  • Thu, Mar 16, 2017: Vendor confirmed remediation is on track (ongoing through May)
  • Thu, Mar 16, 2017: Vendor also implemented session controls for video URLs
  • Wed, May 17, 2017: Public disclosure of R7-2016-23.

WannaCry Overview

Last week the WannaCry ransomware worm, also known as Wanna Decryptor, Wanna Decryptor 2.0, WNCRY, and WannaCrypt started spreading around the world, holding computers for ransom at hospitals, government offices, and businesses. To recap: WannaCry exploits a vulnerability in the Windows Server Message Block (SMB) file sharing protocol. It spreads to unpatched devices directly connected to the internet and, once inside an organization, those machines and devices behind the firewall as well. For full details, check out the blog post: Wanna Decryptor (WannaCry) Ransomware Explained.


Since last Friday morning (May 12), there have been several other interesting posts about WannaCry from around the security community. Microsoft provided specific guidance to customers on protecting themselves from WannaCry. MalwareTech wrote about how registering a specific domain name triggered a kill switch in the malware, stopping it from spreading. Recorded Future provided a very detailed analysis of the malware’s code.


However, the majority of reporting about WannaCry in the general news has been that while MalwareTech’s domain registration has helped slow the spread of WannaCry, a new version that avoids that kill switch will be released soon (or is already here) and that this massive cyberattack will continue unabated as people return to work this week.


In order to understand these claims and monitor what has been happening with WannaCry, we have used data collected by Project Sonar and Project Heisenberg to measure the population of SMB hosts directly connected to the internet, and to learn about how devices are scanning for SMB hosts.


Part 1: In which Rapid7 uses Sonar to measure the internet

Project Sonar regularly scans the internet on a variety of TCP and UDP ports; the data collected by those scans is available for you to download and analyze at WannaCry exploits a vulnerability in devices running Windows with SMB enabled, which typically listens on port 445. Using our most recent Sonar scan data for port 445 and the recog fingerprinting system, we have been able to measure the deployment of SMB servers on the internet, differentiating between those running Samba (the Linux implementation of the SMB protocol) and actual Windows devices running vulnerable versions of SMB.


We find that there are over 1 million internet-connected devices that expose SMB on port 445. Of those, over 800,000 run Windows, and — given that these are nodes running on the internet exposing SMB — it is likely that a large percentage of these are vulnerable versions of Windows with SMBv1 still enabled (other researchers estimate up to 30% of these systems are confirmed vulnerable, but that number could be higher).


We can look at the geographic distribution of these hosts using the following treemap (ISO3C labels provided where legible):

fig1.png[ Figure 1 ]


The United States, Asia, and Europe have large pockets of Windows systems directly exposed to the internet while others have managed to be less exposed (even when compared to their overall IPv4 blocks allocation).


We can also look at the various versions of Windows on these hosts:

fig2.png[ Figure 2 ]


The vast majority of these are server-based Windows operating systems, but there is also a further unhealthy mix of Windows desktop operating systems in the mix—, some quite old. The operating system version levels also run the gamut of the Windows release history timeline:

fig3.png[ Figure 3 ]


Using Sonar, we can get a sense for what is out there on the internet offering SMB services. Some of these devices are researchers running honeypots (like us), and some of these devices are other research tools, but a vast majority represent actual devices configured to run SMB on the public internet. We can see them with our light-touch Sonar scanning, and other researchers with more invasive scanning techniques have been able to positively identify that infection rates are hovering around 2%.


Part 2: In which Rapid7 uses Heisenberg to listen to the internet

While Project Sonar scans the internet to learn about what is out there, Project Heisenberg is almost the inverse: it listens to the internet to learn about scanning activity. Since SMB typically runs on port 445, and the WannaCry malware scans port 445 for potential targets, if we look at incoming connection attempts on port 445 to Heisenberg nodes as shown in Figure 4, we can see that scanning activity spiked briefly on 2017-05-10 and 2017-05-11, then increased quite a bit on 2017-05-12, and has stayed at elevated levels since.


incoming-connections.png[Figure 4]


Not all traffic to Heisenberg on port 445 is an attempt to exploit the SMB vulnerability that WannaCry targets (MS17-010). There is always scanning traffic on port 445 (just look at the activity from 2017-05-01 through 2017-05-09), but a majority of the traffic captured between 2017-05-12 and 2017-05-14 was attempting to exploit MS17-010 and likely came from devices infected with the WannaCry malware. To determine this we matched the raw packets captured by Heisenberg on port 445 against sample packets known to exploit MS17-010.


Figure 5 shows the number of unique IP addresses scanning for port 445, grouped by hour between 2017-05-10 and 2017-05-16. The black line shows that at the same time that the number of incoming connections increases (2017-05-12 through 2017-05-14), the number of unique IPs addresses scanning for port 445 also increases. Furthermore, the orange line shows the number of new, never- before- seen IPs scanning for port 445. From this we can see that a majority of the IPs scanning for port 445 between 2017-05-12 and 2017-05-14 were new scanners.


unique-source-ips.png[ Figure 5 ]


Finally, we see scanning activity from 157 different countries in the month of May, and scanning activity from 133 countries between 2017-05-12 and 2017-05-14. Figure 6 shows the top 20 countries from which we have seen scanning activity, ordered by the number of unique IPs from those countries.


ips-by-country.png[ Figure 6 ]


While we have seen the volume of scans on port 445 increase compared to historical levels, it appears that the surge in scanning activity seen between 2017-05-12 and 2017-05-14 has started to tail off.


So what?

Using data collected by Project Sonar we have been able to measure the deployment of vulnerable devices across the internet, and we can see that there are many of them out there. Using data collected by project Heisenberg, we have seen that while scanning for devices that expose port 445 has been observed for quite some time, the volume of scans on port 445 has increased since 2017-05-12, and a majority of those scans are specifically looking to exploit MS17-010, the SMB vulnerability that the WannaCry malware looks to exploit.


MS17-010 will continue to be a vector used by attackers, whether from the WannaCry malware or from something else. Please, follow Microsoft’s advice and patch your systems. If you are a Rapid7 InsightVM or Nexpose customer, or you are running a free 30 day trial, here is a step by step guide on on how you can scan your network to find all of your assets that are potentially at risk for your organization.


Coming Soon

If this sort of information about internet wide measurements and analysis is interesting to you, stay tuned for the National Exposure Index 2017. Last year, we used Sonar scans to evaluate the security exposure of all the countries of the world based on the services they exposed on the internet. This year, we have run our studies again, we have improved our methodology and infrastructure, and we have new findings to share.



Basics of Cyber Threat Intelligence

Cyber Threat Intelligence is analyzed information about the opportunities, capabilities, and intent of cyber adversaries. The goal of cyber threat intelligence is to help people make decisions about how to prevent, detect, and respond to threats against their networks. This can take a number of forms, but the one people almost always turn to is IOCs. IOCs, or indicators of compromise, are technical network artifacts that can alert a defender that their system is compromised. These include things like IP addresses, domain names, hashes, file names, etc. IOCs are often a good way to detect malicious activity, but they are not the only output of threat intelligence, and often they are not the best output.


Threat Intelligence for WannaCry

In the case of WannaCry (get an overview of the WannaCry vulnerability here) – the primary IOCs available are the hashes and file names of the ransomware samples. By the time you alert on those on your system, it is already too late: the system is already being encrypted. WannaCry also uses a cryptographic loading mechanism that prevents the malicious DLL from ever touching the disk, which means that antivirus will not detect or block it. The hashes are useful from a research perspective, such as identifying new variants or tracking changes to the malware, but they are not useful for detection.


Likewise, there are a few blogs that have published IP addresses that are related to the campaign, but have not provided information as to the nature of those IPs. This makes it hard to know how to handle them or use them in incident detection and response scenarios. Many of the IPs associated with WannaCry are so associated because they have been seen scanning for port 445. We know that WannaCry must scan for that port to identify systems to compromise; however, Wanna Cry is not the only thing that scans the internet, and blocking or alerting on scanning IPs will create a large number of false positives.


The kill switch domain is a good indicator that you have compromised systems on your network that should be remediated. Contact with this domain - which should be allowed to prevent encryption! – can be used as a way to track what systems are compromised and launch investigations accordingly. It is not a prevention method, but it can help identify hosts compromised with this variant. The InsightIDR threat community has a threat list that will alert (but not block) this domain to assist with identification of compromised hosts.


A Better Approach


IOC-based threat intelligence is not the best approach for dealing with WannaCry—a vulnerability-based approach is. The best indicator that you will be compromised is whether or not you are vulnerable to the ETERNAL BLUE exploit that WannaCry uses as an initial attack vector. One researcher put a SMB honeypot up with port 445 open and was exploited in less than 3 minutes. With the way that WannaCry is spreading, if you are vulnerable, you will be compromised. Ensuring that all of your systems are patched, port 445 is not open to the internet, and network segmentation is in place are all far better things to focus on than finding IOCs for WannaCry.


For information on how to scan for, and remediate, MS17-010 with Nexpose and InsightVM, please read this blog.


WannaCry is Just the Beginning...

The reality is that we're likely to see more attacks leveraging this attack vector.


The basic equation for threats is as follows:

Threat = opportunity + capability + intent


Screen Shot 2017-05-15 at 7.35.41 PM.png


For the WannaCry Ransomworm, the equation looks like this:


WannaCry = Unpatched flaw in SMB + ETERNAL BLUE with ransomware and worming capabilities + Desire for $$$


But we have an almost unending list of potential threats, since the opportunity and capability are both public. It is almost guaranteed that we will see other threats where:


Opportunity = Unpatched flaw in SMB

Capability = Some variation of ETERNAL BLUE

Intent = Money, power, chaos, revenge, etc.


We can monitor for new capabilities that are being developed, we can brainstorm potential threat actor intents to understand whom the threat may target, but what will remain the same across all of these threats is the opportunity that the attacks have. If we can remove that opportunity then the threats will not exist, and will become an insubstantial threat, as the attackers will have no way to leverage their capabilities.


Want to learn more? Visit our resource page filled with relevant information around WannaCry.

Mark the date: May 12, 2017.


This is the day the “ransomworm” dubbed “WannaCry” / “Wannacrypt” burst — literally — onto the scene with one of the initial targets being the British National Health Service. According to The Guardian: the “unprecedented attack… affected 12 countries and at least 16 NHS trusts in the UK, compromising IT systems that underpin patient safety. Staff across the NHS were locked out of their computers and trusts had to divert emergency patients.” A larger estimate by various cybersecurity firms indicates that over 70 countries have been impacted in some way by the WannaCry worm. As of this post's creation time, a group with the Twitter handle @0xSpamTech has claimed responsibility for instigating the attack but this has not yet been confirmed.


What is involved in the attack, what weakness(es) and systems does it exploit, and what can you do to prevent or recover from this attack? The following sections will dive into the details and provide guidance on how to mitigate the impact from future attacks.


What is "Ransomware"?


“malicious software which covertly encrypts your files – preventing you from accessing them – then demands      payment for their safe recovery. Like most tactics employed in cyberattacks, ransomware attacks can occur after      clicking on a phishing link or visiting a compromised website.” (


However, WannaCry ransomware deviates from the traditional ransomware definition by including a component that is able to find vulnerable systems on a local network and spread that way as well. This type of malicious software behavior is called a “worm” and the use of such capabilities dates back to 1988 when the Morris Worm spread across the internet (albeit a much smaller neighborhood at the time).


Because WannaCry combines two extremely destructive capabilities, it has been far more disruptive and destructive than previous cases of ransomware that we’ve seen over the past 18-24 months.


While the attackers are seeking ransom — you can track payments to their Bitcoin addresses:

  • 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
  • 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
  • 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

here: there have been reports of this also corrupting drives, adding a destructive component as well as a ransom-recovery component to the attack.


What Systems Are Impacted?

WannaCry only targets Microsoft Windows systems and is known to impact the following versions:

  • Microsoft Windows Vista SP2
  • Windows Server 2008 SP2 and R2 SP1
  • Windows 7
  • Windows 8.1
  • Windows RT 8.1
  • Windows Server 2012 and R2
  • Windows 10
  • Windows Server 2016
  • Windows XP


However, all versions of Windows are likely vulnerable and on May 13, 2017 Microsoft issued a notification that included links to patches for all impacted Windows operating systems — including Windows XP.

As noted, Windows XP is impacted as well. That version of Windows still occupies a 7-10% share of usage (as measured by NetMarketshare):


and, this usage figure likely does not include endpoint counts from countries like China, who have significant use of “aftermarket” versions of Windows XP and other Windows systems, making them unpatchable.

The “worm” component takes advantage of a Remote Code Execution (RCE) vulnerability that is present in the part of Windows that makes it possible to share files over the network (known as “Server Message Block” or SMB). Microsoft released a patch -MS17-010 - for this vulnerability on March 14th, 2017 prior to the release of U.S. National Security Agency (NSA) tools (EternalBlue / DoublePulsar) by a group known as the the Shadow Brokers. Rapid7’s Threat Intelligence Lead, Rebekah Brown, wrote a breakdown of this release in a blog post in April.


Vulnerability detection tools, such as Rapid7’s Metasploit, have had detection capabilities for this weakness for a while, with the most recent Metasploit module being updated on April 30, 2017.

This ransomworm can be spread by someone being on public Wi-Fi or an infected firm’s “guest” WiFi and then taking an infected-but-not-fully-encrypted system to another network. WannaCry is likely being spread, still, by both the traditional phishing vector as well as this network worm vector.


What Can You Do?

  • Ensure that all systems have been patched against MS17-010 vulnerabilities.
  • Identify any internet-facing systems that have not been patched and remediate as soon as possible.
  • Employ network and host-based firewalls to block TCP/445 traffic from untrusted systems. If possible, block 445 inbound to all internet-facing Windows systems.
  • Ensure critical systems and files have up-to-date backups. Backups are the only full mitigation against data loss due to ransomware.


NOTE: The Rapid7 Managed Detection & Response (MDR) SOC has developed detection indicators of compromise (IOCs) for this campaign, however we are only alerted once the malware executes on a compromised system. This is not a mitigation step.


UPDATE - May 15, 2017: For information on how to scan for, and remediate, MS17-010 with Nexpose and InsightVM, please read this blog.


A Potentially Broader Impact

We perform regular SMB scans as a part of Project Sonar and detected over 1.8 million devices responding to full SMB connection in our May 3, 2017 scan:

Some percentage of these systems may be Linux/UNIX servers emulating the SMB protocol but it’s likely that a large portion are Windows systems. Leaving SMB (via TCP port 445) open to the internet is also a sign that these systems are not well maintained, and are also susceptible to attack.


Rapid7’s Heisenberg Cloud — a system of honeypots spread throughout the internet — has seen a recent spike in probes for systems on port 445 as well:



Living With Ransomware

Ransomware has proven to be an attractive and lucrative vector for cybercriminals. As stated previously, backups, along with the ability to quickly re-provision/image an impacted system, are your only real defenses. Rapid7 has additional resources available for you to learn more about dealing with ransomware:


If you’d like more information on this particular ransomworm as seen by Project Sonar or Heisenberg Cloud, please contact research [at] rapid7 [dot] com.


Many thanks to the many contributors across Rapid7 who provided vital information and content for this post.


For more information and resources on WannaCry and ransomware, please visit this page.

Yesterday President Trump issued an Executive Order on cybersecurity: “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure.”


The Executive Order (EO) appears broadly positive and well thought out, though it is just the beginning of a long process and not a sea change in itself. The EO directs agencies to come up with plans for securing and modernizing their networks; develop international cyber norms; work out a deterrence strategy against hacking; and reduce the threat of botnets – all constructive, overdue goals. Below are an overview, a highlight reel, and some additional takeaway thoughts.


Cybersecurity Executive Order Overview

Executive orders are issued only by the President, direct the conduct of executive branch agencies (not the private sector, legislature, or judiciary), and have the force of law. All public (not classified) EOs are published here. This cyber EO is the first major move the Trump White House (as distinct from other federal agencies) has made publicly on cybersecurity.


The cyber Executive Order takes action on three fronts:

  1. Federal network security. Directs agencies to take a risk management approach, adopt the NIST Framework, and favor shared services and consolidated network architectures (including for cloud and cybersecurity services).
  2. Protecting critical infrastructure. Directs agencies to work with the private sector to protect critical infrastructure, incentivize more transparency on critical infrastructure cybersecurity, improve resiliency of communication infrastructure, and reduce the threat of botnets.
  3. National preparedness and workforce development. Directs agencies to assess strategic options for deterring and defending against adversaries. Directs agencies to report their international cybersecurity priorities, and to promote international norms on cybersecurity.


Cybersecurity Executive Order Highlights

  • Federal network cybersecurity:
    • The US will now manage cyber risks as an executive branch enterprise. The President is holding cabinet and agency heads accountable for implementing risk management measures commensurate with risks and magnitude of harm. [Sec. 1(c)(i)]
    • Agencies are directed to immediately use the NIST Framework for Improving Critical Infrastructure Cybersecurity (NIST Framework) to manage their cyber risk. [Sec. 1(c)(ii)]
    • DHS and OMB must report to the President, within 120 days, a plan to secure federal networks, address budgetary needs for cybersecurity, and reconcile all policies and standards with the NIST Framework. [Sec. 1(c)(iv)]
    • Agencies must now show preference for shared IT services (including cloud and cybersecurity services) in IT procurement. [Sec. 1(c)(vi)(A)] This effort will be coordinated by the American Technology Council. [Sec. 1(c)(vi)(B)]
    • The White House, in coordination with DHS and other agencies, must submit a report to the President, within 60 days, on modernizing federal IT, including transitioning all agencies to consolidated network architectures and shared IT services – with specific mention of cybersecurity services. [Sec. 1(c)(vi)(B)-(C)] Defense and intel agencies must submit a similar report for national security systems within 150 days. [Sec. 1(c)(vii)]


  • Critical infrastructure cybersecurity:
    • Critical infrastructure includes power plants, oil and gas, financial system, other systems that would risk national security if damaged. The EO states that it is the government’s policy to use its authorities and capabilities to support the cybersecurity risk management of critical infrastructure. [Sec. 2(a)]
    • The EO directs DHS, DoD, and other agencies to assess authorities and opportunities to coordinate with the private sector to defend critical infrastructure. [Sec. 2(b)]
    • DHS and DoC must submit a report to the President, within 90 days, on promoting market transparency of cyber risk management practices by critical infrastructure operators, especially those that are publicly traded. [Sec. 2(c)]
    • DoC and DHS shall work with industry to promote voluntary actions to improve the resiliency of internet and communications infrastructure and “dramatically" reduce the threat of botnet attacks. [Sec. 2(d)]
    • Agencies shall assess cybersecurity risks and mitigation capabilities related to the electrical sector and the defense industrial base (including supply chain). [Sec. 2(e)-(f)]


  • National preparedness and workforce:
    • The EO reiterates the US government’s commitment to an open, secure Internet that fosters innovation and communication while respecting privacy and guarding against disruption. [Sec. 3(a)]
    • Cabinet members must submit a report to the President, within 90 days, on options for deterring adversaries and protecting Americans from cyber threats. [Sec. 3(b)]
    • Cabinet members must report to the President, within 45 days, on international cybersecurity priorities, including investigation, attribution, threat info sharing, response, etc. The agencies must report to the President, within 90 days, on a strategy for international cooperation in cybersecurity. [Sec. 3(c)]
    • Agencies must report to the President, within 120 days, how to grow and sustain a workforce skilled in cybersecurity and related fields. [Sec. 3(d)(i)]
    • The Director of National Intelligence must report to the President, within 60 days, on workforce development practices of foreign peers to compare long-term competitiveness in cybersecurity. [Sec. 3(d)(ii)] Agencies must report to the President, within 150 days, on US efforts to maintain advantage in national-security-related cyber capabilities. [Sec. 3(d)(iii)]


The Executive Order is just the start

As you can see, the EO initially requires a lot of multi-agency reports, which we can expect to surface in coming months, and which can then be used to craft official policy. There are opportunities for the private sector to provide input to the agencies as they develop those reports, though the 2-4 month timelines are pretty tight for such complex topics. But the reports are just the beginning of long processes to accomplish the goals set forth in the EO - it will take a lot longer than 60 days, for example, to fully flesh out and implement a plan to modernize federal IT. The long haul is beginning, and we won't know how transformative or effective this process will be for some time.


Thankfully, contrary to prior rumors, the EO does not over-expand the role of DoD in securing national networks, nor does the EO call for an expansion of government authority over the private sector (although the reports agencies must produce under the EO may call for new authorities). However, the EO also does not directly touch on important topics such as data breach, IoT insecurity, support for strong encryption, vuln disclosure, or unfilled critical appointments (such as a national CTO). Rapid7 applauds the effort toward enforcing enhanced security to better protect organizations, infrastructure, and individuals through the EO, though we hope to see further consideration on other key cybersecurity issues in the future.


Deral Heiland IoT - IoT Research Lead Rapid7

Nathan Sevier - Senior Consultant Rapid7

Chris Littlebury  - Threat Assessment Manage Rapid7


End-to-end ecosystem methodology

When examining IoT technology, the actionable testing focus and methodology is often applied solely to the embedded device. This is short sighted and incomplete. An effective assessment methodology should consider the entire IoT solution or as we refer to it, the IoT Product Ecosystem. Every interactive component that makes the product function is included in this IoT Product Ecosystem.

  • Embedded device and associated sensors receivers and actuators
  • Mobile application and or command and control software
  • Cloud API and or associated web services
  • Network communication protocols:
    • Ethernet
    • 802.11 Wifi
    • Intra-component communication such as Zigbee, Z-Wave, Bluetooth, etc.



Figure 1: Product IoT Ecosystem


Rapid7’s motivations behind examining the entire ecosystem is to ensure all components of the technology are secure. Failure of any component of the product ecosystem can and will affect the overall security posture. As an example, a failure in the cloud API security can easily lead to unauthorized access control of the embedded hardware, allowing a malicious actor to carry out attacks that could potentially impact the safety and security of the product user.


In the following sections we discuss the various areas and processes that should be a focus to ensure a thorough assessment of an IoT product ecosystems is conducted.


Functional evaluation

When conducting a test on an IoT product's ecosystem, first and foremost an IoT product should be set up and configured within normal specifications. We generally prefer to set up two separate environments, which will better facilitate vulnerability testing, such a cross account and cross system attack and can also be used to make comparisons between normal and altered configurations. Leveraging a fully functional environment, we can then more effectively map out all functions, features, components and communication paths within the products ecosystem. Using this data we can next build out a test plan, which covers the products ecosystem from end-to-end.


Device reconnaissance

We start each IoT security assessment by conducting reconnaissance and open source intelligence gathering (OSINT) to enumerate information about the components and supporting infrastructure. This enumeration can include, researching the make and model of the components and software used by the device, and identification of any external presence that makes up the cloud component of the product.


Cloud focused testing

IoT technology uses various web services for remote control, data collection, and product management. Often web services and cloud API can be the weakest link within an IoT product ecosystem. To validate the security, we conduct a very comprehensive assessment of the associated cloud services using functions and communication between the cloud services and all components in the product ecosystem. This allows us to validate the overall security posture of the product and determine impact and risk caused by security issues between components of the ecosystem. This also includes focused testing of the OWASP Top 10.


Mobile application/control system-focused testing

Generally IoT technologies commonly leverage various forms of remote control services such as mobile application (android, iOS) to remotely manage and control IoT technology. During this phase of testing we conduct in-depth testing and analysis of the mobile and remote application used to manage the IoT product. Again similar to the cloud testing, Rapid7 tests all functions and communications between the mobile applications and all components in the product ecosystem to validate the overall security posture of the product. This testing also focuses around the OWASP mobile top 10 to assure the application meets all security best practices.


Network-focused testing

IoT technologies commonly expose services via standard network communication paths such as ethernet and wifi, which can create an elevated level risk. During this phase of testing, we will identify all exposed TCP and UDP ports within the IoT ecosystems infrastructure. With this list of ports we can then conduct a thorough penetration test to identify all vulnerable or misconfigured services, which can be leveraged to compromise the system and or gain access to critical information.


Physical inspection

We also perform a physical inspection to assess the physical attack surface of an IoT device. This inspection includes examining the device for JTAG and Serial pin-outs, as well as identifying the pins used for power, data, and control of individual components. Each device will have different components or elements but some common attack vectors include:

  • Exterior USB Access
  • Exterior port access
  • Location and medium of storage
  • Availability of debug console access
  • Availability of serial console access
  • Efforts required for disassembly of the device
  • Risk to compromise based on brief physical access to the device
  • Risk to compromise based on extended physical access to the device
  • Risk to compromise based on allowed connectivity medium (Wireless, Wired, Bluetooth, etc.)


Physical device attacks

Physical inspection of the device is key to identifying the most logical physical attacks. After inspection, we conduct physical tests against the IoT device. Though these attack vectors may differ, they often follow common themes. Often, this testing will resemble the following actions:

  • Compromise through available ports.
  • Circumvention of device protections such as boot loader restrictions or restricted bios.
  • Access to modify the configuration of the device.
  • Access to storage to pull configuration keys used by the cloud component.
  • Access to firmware that would otherwise be restricted.
  • Access to the console or logs to isolate traffic destinations during communication with the cloud component.


Radio-focused testing

Most IoT devices also use radio based communication (RF) methods. We focus our communication testing methods to identify security issues to help determine risk and impact. To accomplish this we conduct specialized testing and analyses of the radio-based communication to identify if the communication:

  • Conforms to expected encryption techniques.
  • The component pairing processes cannot be subverted.
  • Allows unauthorized access or control.
  • Can be easily used to map out the underlying command and control traffic
  • Is vulnerable to replay attacks.


Need help securing your IoT devices? Check out our IoT Security Testing Services to learn more.

How many times have you witnessed security problems caused by a user making bad decisions? I'd venture to guess at least a few dozen if not hundreds. We've all seen where the perfect storm forms through weaknesses in technical controls, user training, and – most often – common sense and the outcome is not good. Best case it's ransomware or a similar malware infection. Beyond that, the sky is the limit. Before your organization suffers a breach and is having to answer to the news media and lawyers, there's one thing that you have to do: keep your users out of the security decision-making process.

Those of us working in IT and security are not in the business of making people feel good about their jobs. Rather, it's our duty to make sure that everyone is set up for success in day-to-day business processes. Every time you have a user faced with a security decision such as whether or not to click a link, setting a weak or a strong password, or updating software on their computers, you give away your power and put it in the hands of your users – where it does not belong. I understand that it's difficult to manage a network environment especially when you feel like users are working against your efforts every day. If anything, that should give you that much more of a reason to keep them from making security decisions in the first place.

I don't think it's insensitive or demeaning to keep people from having to make security decisions. They're not security experts. I know, your annual user awareness training session and security policies are supposed to cover all of that, but reality usually tells a different story. Like it or not, people make bad decisions and you have to do what it takes to keep them from doing so. In many cases, you can do this with technology. For example, in the case of passwords, if people are provided with the option to select a weak password, they will – most of the time. Ditto for backing up their data, updating their software, opening attachments, and so on. Throughout the history of humans, we have seen that people will, by and large, take the path of least resistance. What’s easiest and what's going to get them what they need sooner as opposed to later. Instant gratification is the name of the game.

Start thinking about how you can set your users, your business, and especially yourself up for success by taking users out of the security equation. Look at your business workflows. Look at your user on-boarding process. Look at your challenges with shadow IT, BYOD, and the like. It's everywhere across your organization. Some things are obvious. Others not so much. But if you look long enough and hard enough you'll find the areas where you need to control things using technologies, process adjustments, or just eliminating the situation altogether. If you continue to ignore this security challenge, your users will continue to make bad security choices, period. That's not what you want. Be proactive. Take charge. I strongly believe that if you spend enough time and effort in this one area of security, you'll can make huge strides towards minimizing your IT-related business risks.

Since its inception, Rapid7's Project Sonar has aimed to share the data and knowledge we've gained from our Internet scanning and collection activities with the larger information security community.  Over the years this has resulted in vulnerability disclosures, research papers, conference presentations, community collaboration and data.  Lots and lots of data.


Thanks to our friends at, Censys, and the University of Michigan, we've been able to provide the general public free access to much of our data, including:



As project Sonar continues, we will continue to publish our data through the outlets listed above, perhaps in addition to others.


Are you interested in Project Sonar?  Are you using this data?  If so, how?  Interested in seeing additional studies performed?  Have questions about the existing studies or how to use or interpret the data?  We love hearing from the community!  Post a comment below or reach out to us at research [at] rapid7 [dot] com.

The much-anticipated, tenth-anniversary edition of the Verizon DBIR has been released (, once again providing a data-driven snapshot into what topped the cybercrime charts in 2016. There are just under seventy-five information-rich pages to go through, with topics ranging from distributed denial-of-service (DDoS) to ransomware, prompting us to spin a reprise edition of last year’s DBIR field guide ( data-breach-investigations-report-the-defenders-perspective).


Before we bust out this year’s breach-ography, let’s set a bit of context.


The Verizon DBIR is digested by a diverse community, but the lessons found within are generally aimed at defenders in organizations who are faced with the unenviable task of detecting and deterring the daily onslaught of attacks and attackers. This post is also aimed at that audience. As you go through the Verizon DBIR, there should be three guiding principles at work:



Time to fire up the jukebox and see what’s inside.


The Detection-Deficit is Dead…Long Live the Defender’s Differential!


The first chart I always went to in the DBIR was the Detection-Deficit chart. Said chart “compared the percentage of breaches where the time-to-compromise was days or less against the percentage of breaches where the time- to-discovery was days or less.” (VZDBIR, pg 8). It’s also no longer an artifact in the Verizon DBIR.


The Verizon Security Research team provided many good reasons for not including the chart in the report, and also noted several caveats about the timings that you should take time to consider. But, you still need to be tracking similar metrics in your own organization to see if things are getting better or worse (things rarely hold steady in infosec land).  We’ve taken a cue from the DBIR and used their data to give you two new metrics to track: the “Exfiltration-Compromise Differential”

Verizon DBIR Summary: Exfiltration Chart

and the “Containment-Discovery Differential”.

Verizon DBIR Summary: Containment Chart

The former chart shows a band created by comparing the percentage of breaches where exfiltration (you can substitute or add-in other accomplished attacker goals) was in “days or less” (in other words, less than seven days) to those when initial compromise was “days or less”. This band should be empty (all attacker events took days or longer) or as tiny as possible.


The latter does the same to compare the defender’s ability to detect and contain attacker activity. That band needs to be as YUGE as you can make it (aligned to your organization’s risk and defense spending appetites).


As noted in the Verizon DBIR, things aren’t getting much better (or worse) when looked at in aggregate, but I’m hopeful that organizations can make progress in these areas as tools, education, techniques and processes continue to improve.


Some other key takeaways in the “Breach Trends” section include:


  • The balance between External and Internal actors has ebbed-and flowed at about the same pace for the past 7 years, meaning Figure 2 does not validate the ever-present crusade by your Internal Audit department to focus solely on defending against rogue sysadmins. There is a cautionary tale here, though, in that many of the attacks marked as “internal” were actually committed by external attackers who used legit credentials to impersonate internal users.
  • We have finally reached the Threat Action Trifecta stage with Social, Malware and Hacking reigning supreme (and will likely do so for some time to come).
  • Financial gain and stealing secrets remain primary motives (and defending against those who seek your secrets may become job #1 over the coming years if Figure 3 continues the trend).


Team DBIR also provided a handy punch-card for you in Figure 9:


Verizon Data Breach Investigation Report Summary: Figure 9

It’s your “at-a-glance” key to the 2016 chart-toppers by industry. Keep it handy as you sit in your post-DBIR-launch roadmap adjustment meetings (you do have those, right?).


The Secret Life of Enterprise Vulnerability Management (Guest starring IoT)


Verizon has many partners who provide scads of vulnerability data, and the team took a very interesting look at  patching in the intro section preceding the individual industry dives.

Verizon DBIR Summary: Figure 14

Verizon gives a solid, technical explanation of this chart, so we’ll focus on how you should benchmark your own org against it.


Find your industry (NAICS codes are here: but you can also Google™ “COMPANY_NAME NAICS” and usually get a quick result) on the right then hit up your vulnerability and patch management dashboards to see if you meet or beat expectations. If you’re a college, do you patch more than 12% of vulns in 12 weeks-time? If you’re in a hospital, do you meet the 77% bar?


The chart is based on real data from many organizations. You may have some cognitive dissonance reading it because we constantly hear how awesome, well-resourced financial institutions are at IT & security and the converse for industries such as Healthcare. One way to validate these findings is to start tracking this data internally, then getting your ISAC partners (you are aligned with one — or more — information sharing and analysis centers, right?) to do the same and compare notes a few times a year. You also need to define your own targets and use your hit/miss ratio as a catalyst for process improvement (or funding for better tooling).


But wait…there’s more!


Verizon DBIR Summary: Figure 56Keep one finger on page 13 and then flip to Appendix B to get even more information on vulnerability management, including this chart >


Network ops folks patching on 90-day cycles shouldn’t really surprise folks - we need to keep those bits and bytes flowing and error-free high-availability switchover capability is expensive - but take a look at the yellow-ish line. First, do you even track IoT (Internet of Things, i.e. embedded) patching? And, if you do — or, when you start to after reading this — will you strive to do better than the “take 100 days to not even get half the known vulns patched”?


IoT is a blind-spot in many (most) organizations and this chart is a great reminder that you need to:


  • care about
  • inventory/locate, and
  • track


IoT in your environment.


Industrial Development


Unfortunately, digesting the various Industry sections of the Data Breach Investigations Report is an exercise that you must — dear, reader — undertake on your own, but they are a good resource to have for planning or security architecture development session.


Find your industry (see the previous section in this post), note the breach frequency (they’ll likely have fixed the bug in the Accommodation section by the time our blog post drops), top patterns, actor information and compromise targets and compare your 2016 to the overall industry 2016. Note the differences (or similarities) and adjust accordingly.


The DBIR team provides unique details and content in each industry section to help you focus on the differentials (the unique incident characteristics that made one industry different from each other). As you go through each, do not skip over the caveats. The authors of the report spend a great deal of time sifting through details and will often close out a section with important information that may change your perspective on a given area, such as this closing caveat in the Retail section: “This year we do not have any large retailers in the Point of Sale Intrusions pattern, which is hopefully an indicator of improvements and lessons learned. We are interested in finding out if smaller retailers also learned this lesson, or if single small breaches just aren’t making it into our dataset.”


The Last Waltz: Dancing Through Incident Classification Patterns


We’ll close with an overview of the bread-and-butter (or, perhaps, avocado toast?) of the DBIR: the incident classification patterns. Figures 33 & 34 provides the necessary contextual overview:

Verizon DBIR Summary: Figure 33 Breaches hurt, but incidents happen with more regularity, so you need to plan for both. First, compare overall prevalence for each category to what your own org saw in 2016 so you understand your own, unique view.


Next, make these sections actionable. One of the best ways to get the most out of the data in each of the Patterns sections is to take one or two key details from each that matter to your industry (they align the top ones in each category) and design either tabletop or actual red-team exercise scenarios that your org can run through.


For example, design a scenario where attackers have obtained a recent credential dump and have targeted your employee HR records (yes, I took the easy one from Figure 52, page 58).  MITRE has a decent “Cyber Exercise Playbook” ( -playbook.pdf) you can riff off of if you don’t have one of your own to start with.




This is the first year Rapid7 has been a part of the DBIR corpus and we want to end with a shout-out to the entire DBIR team for taking the time to walk through our incident/breach-data contributions with us and look forward to contributing more —and more diverse — data in reports to come.

This post describes a security vulnerability in the Fuze collaboration platform, and the mitigation steps that have been taken to correct the issue. The Fuze collaboration platform did not require authentication to access meeting recordings (CWE-284). Shortly after being informed of this issue, Fuze disabled public access to all recorded meetings, and implemented user-configurable controls in the client application to mediate public access to shared meeting recordings. Affected recordings that had already been shared were reviewed and addressed as well. Rapid7 thanks Fuze for their timely and thoughtful response to this issue.

Product Description

Fuze is an enterprise, multi-platform voice, messaging, and collaboration service created by Fuze, Inc. It is described fully at the vendor's website. While much of the Fuze suite of applications are delivered as web-based SaaS components, there are endpoint client applications for a variety of desktop and mobile platforms.


This issue was discovered by Samuel Huckins of Rapid7 (that's me ), and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.


Recorded Fuze meetings are saved to Fuze's cloud hosting service. They could be accessed by URLs such as "", where "7DIGITNUM" is a seven digit number that increments over time. Since this identifier did not provide sufficient keyspace to resist bruteforcing, specific meetings could be accessed and downloaded by simply guessing a replay ID reasonably close to the target, and iterating through all likely seven digit numbers. This format and lack of authentication also allowed one to find recordings via search engines such as Google.

Vendor Statement

Security is a top priority for Fuze and we appreciate Rapid7 identifying this issue and bringing it to our attention. When we were informed by the Rapid7 team of the issue, we took immediate action and have resolved the problem.


As of Mar 1, 2017, all meeting recordings now appear to require password authentication in order to be viewed from Fuze's cloud-hosted web application via direct browsing or from the Fuze desktop and mobile clients. This authentication control is configurable by the user via the client applications as of version 4.3.1 (released on Mar 10, 2017). Fuze users are encouraged to update their Fuze client applications in order to take advantage of new access controls. Additional options, such as downloading the recording locally, are available at

Disclosure Timeline

  • Thu, Feb 23, 2017: Discovered by Samuel Huckins of Rapid7.

  • Mon, Feb 27, 2017: Vulnerability verified by Rapid7.

  • Mon, Feb 27, 2017: Vulnerability details disclosed to Fuze.

  • Wed, Mar 01, 2017: Fuze disabled public access to meeting recordings.

  • Fri, Mar 10, 2017: Version 4.3.1 of Fuze endpoint client released, providing authentication controls for recorded meetings.

  • Tue, Mar 15, 2017: Vulnerability details disclosed to CERT/CC.

  • Tue, Mar 21, 2017: VU#590023 assigned by CERT/CC to track this issue.

  • Tue, Apr 25, 2017: CERT/CC and Rapid7 decided not to issue a CVE for this vulnerability. The issue was primarily on Fuze's servers, thus the end user didn't have to take any actions, and the issue has already been corrected.

  • Tue, May 02, 2017: Disclosed to the public


Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames, passwords, and PINs via a log transmission feature. This feature was introduced in version 3.9.4 on December 8, 2016, and removed by Hyundai on March 6, 2017 with the release of version 3.9.6.

Affected versions of Hyundai Blue Link mobile application upload application logs to a static IP address over HTTP on port 8080. The log is encrypted using a symmetrical key, "1986l12Ov09e", which is defined in the Blue Link application (specifically,, and cannot be modified by the user.

Once decoded, the logs contain personal information, including the user's username, password, PIN, and historical GPS data about the vehicle's location. This information can be used to remotely locate, unlock and start the associated vehicle.

This vulnerability was discovered by Will Hatzer and Arjun Kumar, and this advisory was prepared in accordance with Rapid7's disclosure policy.

Product Description

The Blue Link app is compatible with 2012 and newer Hyundai vehicles. The functionality includes remote start, location services, unlocking and locking associated automobiles, and other features, documented at the vendor's web site.


This vulnerability was discovered by independent researchers William Hatzer and Arjun Kumar.

Exploitation for R7-2017-02

The potential data exposure can be exploited one user at a time via passive listening on insecure WiFi, or by standard man-in-the-middle (MitM) attack methods to trick a user into connecting to a WiFi network controlled by an attacker on the same network as the user. If this is achieved, an attacker would then watch for HTTP traffic directed at an HTTP site at 54.xx.yy.113:8080/LogManager/LogServlet, which includes the encrypted log file with a filename that includes the user's email address.

It would be difficult to impossible to conduct this attack at scale, since an attacker would typically need to first subvert physically local networks, or gain a privileged position on the network path from the app user to the vendor's service instance.

Vendor Statement

Hyundai Motor America (HMA) was made aware of a vulnerability in the Hyundai Blue Link mobile application by researchers at Rapid7. Upon learning of this vulnerability, HMA launched an investigation to validate the research and took immediate steps to further secure the application. HMA is not aware of any customers being impacted by this potential vulnerability.


The privacy and security of our customers is of the utmost importance to HMA. HMA continuously seeks to improve its mobile application and system security. As a member of the Automotive Information Sharing Analysis Center (Auto-ISAC), HMA values security information sharing and thanks Rapid7 for its report.


On March 6, 2017, the vendor updated the Hyundai Blue Link app to version 3.9.6, which removes the LogManager log transmission feature. In addition, the TCP service at 54.xx.yy.113:8000 has been disabled. The mandatory update to version 3.9.6 is available in both the standard Android and Apple app stores.

Disclosure Timeline

  • Tue, Feb 02, 2017: Details disclosed to Rapid7 by the discoverer.
  • Sun, Feb 19, 2017: Details clarified with the discoverer by Rapid7.
  • Tue, Feb 21, 2017: Rapid7 attempted contact with the vendor.
  • Sun, Feb 26, 2017: Vendor updated to v3.9.5, changing LogManager IP and port.
  • Mon, Mar 02, 2017: Vendor provided a case number, Consumer Affairs Case #10023339
  • Mon, Mar 06, 2017: Vendor responded, details discussed.
  • Mon, Mar 06, 2017: Version 3.9.6 released to the Google Play store.
  • Wed, Mar 08, 2017: Version 3.9.6 released to the Apple App Store.
  • Wed, Mar 08, 2017: Details disclosed to CERT/CC by Rapid7, VU#152264 assigned.
  • Wed, Apr 12, 2017: Details disclosed to ICS-CERT by Rapid7, ICS-VU-805812 assigned.
  • Fri, Apr 21, 2017: Details validated with ICS-CERT and HMA, CVE-2017-6052 and CVE-2017-6054 assigned.
  • Tue, Apr 25, 2017: Public disclosure of R7-2017-02 by Rapid7.
  • Tue, Apr 25, 2017: ICSA-17-115-03 published by ICS-CERT.
  • Fri, Apr 28, 2017: Redacted the now-disabled IP address for the LogManager IP address.

In your organizational environment, Audit Logs are your best friend. Seriously. This is the sixth blog of the series based on the CIS Critical Security Controls. I’ll be taking you through Control 6: Maintenance, Monitoring and Analysis of Audit Logs, in helping you to understand the need to nurture this friendship and how it can bring your information security program to a higher level of maturity while helping gain visibility into the deep dark workings of your environment.


In the case of a security event or incident, real or perceived, and whether it takes place due to one of the NIST-defined incident threat vectors, or falls into the “Other” category, having the data available to investigate and effectively respond to anomalous activity in your environment, is not only beneficial, but necessary.


What this Control Covers:

This control has six sections which cover everything from NTP configuration, to verbose logging of traffic from network devices to how the organization can best leverage a SIEM for a consolidated view and action points, and how often reports need to be reviewed for anomalies.



There are many areas where this control runs alongside or directly connects to some of the other controls as discussed in other CIS Critical Control Blog posts.


How to Implement It:

Initial implementation of the different aspects of this control range in complexity from a “quick win” to full configuration of log collection, maintenance, alerting and monitoring.


Network Time Protocol: Here’s your quick win. By ensuring that all hosts on your network are using the same time source, event correlation can be accomplished in a much more streamlined fashion. We recommend leveraging the various NTP pools that are available, such as those offered from Having your systems check in to a single regionally available server on your network, which has obtained its time from the NTP pool will save you hours of chasing down information.


Reviewing and Alerting: As you can imagine, there is a potential for a huge amount of data to be sent over to your SIEM for analysis and alerting. Knowing what information to capture and retain is a huge part of the initial and ongoing configuration of the SIEM.


Fine tuning of alerts is a challenge for a lot of organizations. What is a critical alert? Who should be receiving these and how should they be alerted? What qualifies as a potential security event? SIEM manufacturers and Managed Service Providers have their pre-defined criteria, and for the most part, are able to effectively define clear use cases for what should be alerted upon, however your organization may have additional needs. Whether these needs are the result of compliance requirements or you needing to keep an eye on a specific critical system for anomalous activity, defining your use cases and ensuring that alerts are sent for the appropriate level of concern as well as having them sent to the appropriate resources is key in avoiding alert fatigue.


Events that may not require immediate notification still have to be reviewed. Most regulatory requirements state that logs should be reviewed "regularly" but remain vague on what this means. A good rule of thumb is to have logs reviewed on a weekly basis, at a minimum. While your SIEM may have the analytical capabilities to draw correlations, there will undoubtedly be items that you find that will require action.


What should I be collecting?

There is a lot of technology out there to “help” secure your environment. Everything from Active Directory auditing tools, which allow you to pull nicely formatted and predefined reports, to the network configuration management tools. There are all flavors out there that are doing the same thing that your SIEM tool can do with appropriately managed alerting and reporting. It should be able to be a one stop shop for your log data.

In a perfect world, where storage isn’t an issue, each of the following items would have security related logs sent to the SIEM.

  • Network gear
    • Switches
    • Routers
    • Firewalls
    • Wireless Controllers and their APs.
  • 3rd Party Security support platforms
    • Web proxy and filtration
    • Anti-malware solutions
    • Endpoint Security platforms (HBSS, EMET)
    • Identity Management solutions
    • IDS/IPS
  • Servers
    • Special emphasis on any system that maintains an identity store, including all Domain Controllers in a Windows environment.
    • Application servers
    • Database servers
    • Web Servers
    • File Servers – Yes, even in the age of cloud storage, file servers are still a thing, and access (allowed or denied) needs to be logged and managed.
  • Workstations
    • All security log files


This list is by no means exhaustive, and even at the level noted we are talking about large volumes of information. This information needs a home. This home needs to be equipped with adequate storage and alerting capabilities.


Local storage is an alternative, but it will not provide the correlation, alerting or retention capabilities as a full blown SIEM implementation.


There has been some great work done in helping organizations refine what information to include in log collections. Here are a few resources I have used.


SANS - ement-strategies-audit-compliance-33528


NIST SP 800-92 -


Malware Archeology -



Read more on the CIS Critical Security Controls:


What are the CIS Critical Security Controls?


The Center for Internet Security (CIS) Top 20 Critical Security Controls (previously known as the SANS Top 20 Critical Security Controls), is an industry-leading way to answer your key security question: “How can I be prepared to stop known attacks?” The controls transform best-in-class threat data into prioritized and actionable ways to protect your organization from today’s most common attack patterns.


Achievable Implementation of the CIS Critical Security Controls


The interesting thing about the critical security controls is how well they scale to work for organizations of any size, from very small to very large. They are written in easy to understand business language, so non-security people can easily grasp what they do. They cover many parts of an organization, including people, processes and technology. As a subset of the priority 1 items in the NIST 800-53 special publication, they are also highly relevant and complimentary to many established frameworks.


Leveraging Rapid7's expertise to assist your successful implementation


As part of a Rapid7 managed services unit, the Security Advisory Services team at Rapid7 specializes in security assessments for organizations. Using the CIS Critical Security Controls (formerly the SANS 20 Critical Controls) as a baseline, the team assesses and evaluates strengths and gaps, and makes recommendations on closing those gaps.


The Security Advisory Services team will be posting a blog series on each of the controls. These posts are based on our experience over the last two years of our assessment activity with the controls, and how we feel each control can be approached, implemented and evaluated. If you are interested in learning more about the CIS Critical Controls, stay tuned here as we roll out posts weekly. Thanks for your interest and we look forward to sharing our knowledge with you!


The definitive guide of all CIS Critical Security Controls

As the blog series expands, we’ll use this space to keep a running total of all the 20 CIS Critical Controls. Check back here to stay updated on each control.


Control 1: Inventory of Authorized and Unauthorized Devices

This control is split into 6 focused sections relating to network access control, automation and asset management. The control specifically addresses the need for awareness of what’s connected to your network, as well as the need for proper internal inventory management and management automation. Implementing inventory control is probably the least glamorous way to improve a security program, but if it's done right it reduces insider threat and loss risks, cleans up the IT environment and improves the other 19 controls. Learn more.


Control 2: Inventory of Authorized and Unauthorized Software

The second control is split into 4 sections, each dealing with a different aspect of software management. Much like Control 1, this control addresses the need for awareness of what’s running on your systems and network, as well as the need for proper internal inventory management. The CIS placed these controls as the "top 2" in much the same way that the NIST Cybersecurity Framework addresses them as "priority 1" controls on the 800-53 framework; inventory and endpoint-level network awareness is critical to decent incident response, protection and defense. Learn more.

Control 3: Secure Configurations for Hardware & Software

This control deals with Secure Configurations for Hardware & Software. The Critical Controls are numbered in a specific way, following a logical path of building foundations while you gradually improve your security posture and reduce your exposure. Controls 1 and 2 are foundational to understanding what inventory you have. The next step, Control 3, is all about shrinking that attack surface by securing the inventory in your network. Learn more.


Control 4: Continuous Vulnerability Assessment & Remediation

Organizations operate in a constant stream of new security information: software updates, patches, security advisories, threat bulletins, etc. Understanding and managing vulnerabilities has become a continuous activity and requires a significant amount of time, attention and resources. Attackers have access to the same information, but have significantly more time on their hands. This can lead to them taking advantage of gaps between the appearance of new knowledge and remediation activities. Control 4 challenges you to understand why vulnerability management and remediation is important to your overall security maturity. Learn more.


Control 5: Controlled Use of Administrative Privilege

The ultimate goal of an information security program is to reduce risk. Often, hidden risks run amok in organizations that just aren’t thinking about risk in the right way. Control 5 of the CIS Critical Security Controls can be contentious, can cause bad feelings, and is sometimes hated by system administrators and users alike. It is, however, one of the controls that can have the largest impact on risk.  Discover how reducing or controlling administrative privilege and access can reduce the risk of an attacker comprising your sensitive information. Learn more.


Control 6: Maintenance, Monitoring and Analysis of Audit Logs

This control has six sections which cover everything from NTP configuration, to verbose logging of traffic from network devices to how the organization can best leverage a SIEM for a consolidated view and action points, and how often reports need to be reviewed for anomalies. Learn more.


Control 7: Email and Web Browser Protection

Critical Control 7 has eight sections that cover the basics of browser and email client safety, secure configuration and mail handling at the server level. The control pays specific attention to concepts like scripting and active component limiting in browsers and email clients, attachment handling, configuration, URL logging, filtering and whitelisting. The premise of the control is fairly straightforward: browser and email client security are critically important for low-level risk mitigation. Learn more.


Control 8: Malware Defenses

Control 8 covers malware and antivirus protection at system, network, and organizational levels. It isn’t limited to workstations, since even servers that don't run Windows are regularly targeted (and affected) by malware. Control 8 should be used to asses infrastructure, IoT, mobile devices, and anything else that can become a target for malicious software—not just endpoints. Learn more.

Filter Blog

By date: By tag: