Skip navigation
All Places > Nexpose > Blog
1 2 3 4 Previous Next


256 posts

The Windows Registry is a database which stores all settings for a Windows system, e.g. hardware, software installed, Windows updates installed and preferences for users and their applications.  During normal day to day use a standard user will inadvertently push changes into this database when they update the system, add/remove applications and so on.


Remote Registry is a Windows service which allows a non-local user to read or make changes to the registry on your Windows system when they are authorized to do so.  Yes; you read that right - when enabled this service give a remote user complete access to your Windows Registry.  However this isn't as scary as it sounds, given that the remote user has to authenticate with the system and be authorized to read and make changes to the registry.  This serves as a powerful tool for system administrators managing large numbers of Windows systems.


From Nexpose 6.1.7  users can configure a scan template to temporarily enable Remote Registry on all Windows devices as they are being scanned.  This allows information to be retrieved from the registry and means Nexpose can collect more accurate data from the assets. In the Nexpose site configuration a user will need to add credentials which have appropriate permissions on the target systems to read from the registry.  Once the scan is complete the Remote Registry service will be returned to it's prior state.


Why is this useful?  The Windows Registry holds all sorts of interesting information, which can't be accessed normally - even when using a credentialed scan.  As Remote Registry is off by default for most Windows systems, being able to temporarily enable this service gives you a secure method to collecting this additional data.  Safely returning the systems to their original state once they have been successfully scanned ensures security is maintained.


Enabling the Remote Registry setting is as simple as checking a box on the relevant scan template then choosing that scan template for your site, and can be performed by a Global Administrator or Administrator.  Alternatively a site owner could choose a scan template for their site which already has this option enabled.


To enable Remote Registry for a given Site:

  • Navigate to the relevant Site, choose "edit site" option
  • Navigate to the Templates tab of the site configuration page

Screen Shot 2016-01-20 at 08.49.47.png

  • Under the "Select Scan Template" section - copy an existing template using the icons at the end of the table row (or edit a custom template)
  • In the new window showing "Scan Template Configuration" options, enable check box for "Allow Nexpose to enable Windows services"

Screen Shot 2016-01-20 at 08.51.03.png

  • Read and accept warning

Screen Shot 2016-01-20 at 08.50.29.png

  • Save


The next step is to run the scan and see the results - with the benefits of more accurate scan results and less false positives.


To disable Remote Registry, an authorized user can update the scan template being used for a site in the site configuration, or alternatively can select a different scan template which does not have this option switched on.  Easy, right?


Update Tuesday, January 2016

Posted by anowak Employee Jan 12, 2016

The year’s first release contains 9 bulletins, 7 remote code execution (RCE), an elevation of privilege and spoofing vulnerability. The critical bulletins (MS15-001, MS15-002, MS15-003, MS15-004, MS15-005, MS15-006) are comprised of remote code execution vulnerabilities affecting a variety of products and platforms including Edge, Internet Explorer (7 and onwards), Excel Viewer, Office, SharePoint Server, Silverlight, Word Viewer, VBScripting engine and all supported releases of Microsoft Windows.


This month Microsoft resolves 24 vulnerabilities across 9 bulletins with MS16-001, MS16-002, MS16-006, MS16-007 as the bulletins to watch out for, addressing 11 vulnerabilities. Since a wide range of products are affected this month almost all Microsoft users should be on alert. Fortunately no vulnerabilities are known to have been exploited.


Users should be wary of untrusted sources as maliciously crafted content could allow an attacker to remotely execute code to gain the same rights as your user account. Your best protection against these threats is to patch as quickly as possible.


Resolved Vulnerability Reference:

For organizations that want additional security upon login, Nexpose and the Rapid7 Nexpose-Client Ruby Gem will support Two Factor Authentication as of the January 6, 2016 release. Two Factor Authentication requires the use of a time-based one-time password application such as Google Authenticator.


Two Factor Authentication can only be enabled by a Global Administrator on the Security Console.


To enable Two Factor Authentication:

1. As a Global Administrator, go to the Administration tab.

2. Click the Administer link in the Global and Console Settings section.

3. Select Enable two factor authentication.




The next step is to generate a token for each user. The users can generate their own tokens, or you can generate tokens for them that they then change. In either case, you should communicate with them about the upcoming changes.


Method 1: Tokens created by users


Once Two Factor Authentication is enabled, when a user logs on to Nexpose, they will see a field where they can enter an access code. For the first time, they should log in without specifying an access code.





Once the user logs in, they can generate a token in the User Preferences page.





The user should then open their time-based one-time password application such as Google Authenticator. They should enter the token as the key in the password application. The password application will then generate a new code that should be used as the users access code when logging in.


A Global Administrator can check whether users have completed the Two Factor Authentication on the Manage Users page. The Manage Users page can be reached by going to the Administration tab and clicking the Manage link in the Users section. A new field – Two Factor Authentication Enabled – will appear in the table and let the administrator know which users have enabled this feature.





If the user doesn’t create a token, they will still be able to log in without an access code. In this case, you may need to take steps to enforce enablement.


Method 2: Generating tokens for users


You can enforce that all users log in with a token by disabling the accounts of any users who have not completed the process, or by creating tokens for them and emailing them their tokens.


To disable users:

1. Go to the manage users page by going to the Administration tab and clicking the manage link in the Users section.

2. Select the checkbox next to each user for whom the Two Factor Authentication Enabled column shows No.

3. Select Disable users.


To generate a token for a user:

1. Go to the manage users page by going to the Administration tab and clicking the manage link in the Users section.

2. Select Edit for that user.

3. Generate a token for that user.

4. Provide the user with the token.

5. Once the user logs in with their access code, they can change their token if they would like in the User preferences page.

Java based server applications are prevalent throughout most corporate networks.  Thousands, if not millions, of applications are deployed using JBoss, Jenkins, WebLogic and WebSphere - so when a vulnerability affecting the underlying technology pops up, the impact can be significant.  A vulnerability was recently discovered affecting any Java application which can receive data back from users, allowing malicious actors to insert unsafe data as it attempts to ingest the information.  The applications in the title of this post are some of the most popular, and are so widely deployed it is almost certain to hit a wide range of networks.


What is a serialization bug?

Programming languages provide methods to export data, either saving to disk or streaming over the network.  When data is streamed over the network it needs to be converted to another format (e.g. binary) and this process is called serialization.  When the application reads data in the opposite direction, it needs to convert back into the appropriate format.  The vulnerability arises when the applications can be tricked into accepting data which has a nefarious purpose, such as executing dangerous code and/or commands on the underlying server.


Why is this such a problem?

This is a big problem as practically all Java applications use serialization as a way to transfer data, and given how many of these applications are out there - the scale, and surface area for remote attack, is huge.


How do I know if I am affected?

Two of Rapid7's core Threat Exposure Management products - Nexpose and Metaploit - will let you detect whether you have vulnerable systems in your network, verify whether they can be actively exploited, and provide instruction on how to resolve outstanding vulnerabilities.


The fingerprinting capabilities within Nexpose can accurately determine if you have any vulnerable platforms running within your site and are therefore open to malicious attack.  The vulnerability exists in the commons-collections Java library which was found to be exploitable in a number of common platforms including JBoss, Jenkins, WebLogic, and WebSphere.  If you use any of the following platforms then you are potentially vulnerable to this exploit:

  • Jenkins versions below 1.638 and Jenkins LTS versions below 1.625.2 are vulnerable (CVE-2015-8103)
  • Oracle WebLogic Server, versions,,, are vulnerable (CVE-2015-4852)
  • All JBoss AS and EAP versions are vulnerable (CVE-2015-7501)
  • Websphere versions 8.5 and 8.5.5 Full Profile and Liberty Profile, Version 8.0 and Version 7.0 are vulnerable (CVE-2015-7450)


Can it be exploited?

Once Nexpose identifies any potential vulnerable systems, Metasploit will let you confirm if those systems can be successfully exploited.


We have created a Metasploit module which is able to gain a shell giving us full control over a server running an un-patched instance of Jenkins.  For the record we love Jenkins, and while there were a few servers to test our exploit, Jenkins ended up being first!  The Metasploit module will utilize two stagers that are crafted as serialized InvocationHandler Java objects.  These stagers are executed sequentially with the first using FileUtils to write meterpreter to the file system, and the second to load and launch meterpreter.  This is a relatively quiet exploit in that no new threads or processes are spawned, only an existing Java thread is hijacked.    The following Metasploit module can be used to validate this vulnerability and prove definitively if a machine is at risk or not.  First you load the module, and check if the target is vulnerable (omitting setting the target IP etc)


msf > use exploit/linux/misc/jenkins_java_deserialize


msf exploit(jenkins_java_deserialize) > check


Then we set the payload and run the exploit to get a Meterpreter shell:


msf exploit(jenkins_java_deserialize) > set payload java/meterpreter/reverse_tcp

payload => java/meterpreter/reverse_tcp


msf exploit(jenkins_java_deserialize) > run


You may have to run it a couple of times for it to trigger, but this will give you access via the meterpreter shell.


How can I fix it?

Nexpose provides solutions and remediation steps to instruct you on how to upgrade from the affected versions above, and ultimately ensure you are no longer exposed to this vulnerability.


Link to original research article here.

After releasing TLS Coverage Improvements in Nexpose 6.0.2 we figured that the Nexpose Security Console should be able to abide by our own suggestions. Last year we had already disabled SSLv3 support by default and allowed configuring what other protocols are enabled on the console as well. With this week's release we're limiting the TLS cipher suites available to the console's web server by default. Similar to the protocols, the cipher suites can also be configured to be more or less strict as required by your organization.


Configuring SSL/TLS Protocol and Cipher Settings

Currently, these settings are configured through the file, which can be created/edited in the [installation path]/nsc/ directory. A restart of the Nexpose service is required for changes to take effect. The following examples reflect the default settings, which means setting them exactly as shown will not change anything.


For SSL/TLS protocols, the following parameters are allowed:

  • SSLv3
  • SSLv2Hello
  • TLSv1
  • TLSv1.1
  • TLSv1.2


To configure the enabled protocols, add the following line to the file where each protocol is separated by a comma without any spaces:




For cipher suites, you can use either Apache-style syntax or JSSE syntax. To configure the enabled cipher suites using Apache-style syntax, add the following line to the file:


com.rapid7.nexpose.nsc.sslEnabledCiphers=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AE S256:ECDH+AES128:DH+AES:!aNULL:!MD5:!DSS


If the default cipher suites are not suitable for your use, we suggest reviewing the recommendations from Mozilla as they are quite comprehensive: Security/Server Side TLS - MozillaWiki.


SHA-1 Certificates

If your Nexpose Security Console is still using a SHA-1 certificate (generated more than a year ago), you have a few options to upgrade the certificate strength. If you're using the generated self-signed certificate, you can simply generate a new one from the Administration > Administer Console page. Under the Web Server settings click the Manage Certificates button, then generate a new certificate. A restart of the Nexpose service is required for the new certificate to be used.


If you're using a certificate signed by an internal or external Certificate Authority (CA) you can generate a new CSR, which requires generating a new self-signed certificate as well. Note that if the parameters of the CSR are not satisfactory for your requirements, your CA may allow overriding some of the settings related to algorithms when signing the certificate.


In the future we hope to expand the functionality around certificates and TLS connections from the user interface. We would love to hear your feedback on what options you need the most and how you would like to use them.

Nexpose has long provided the ability to filter vulnerabilities by a wide variety of categories and operators. Starting in Nexpose 6.1, filtering in new-vulnerability actions in Adaptive Security closely mirrors that of Nexpose. New vulnerability actions were covered in a recent blog .How Adaptive Security fits into your Vulnerability Management Program).nexposeVulnFilters.png



Similarity to Nexpose Filtering

The enhanced filters now mirror those of Nexpose in their entirety. Users can now automate any workflows they have which only operate on certain types of vulnerabilities.


More Selective Scanning

This enhanced filtering allows users to be much more specific in which types of new vulnerabilities are scanned for. Nexpose released an average of 283 new vulnerabilities per week in 2015, but depending on the customer's assets, only some vulnerabilities are worth scanning for right away. The new filters allow much more pin-pointed scans that target exactly the types of vulnerabilities the user is concerned about.


Example Use Case

Suppose a user has a site which does not contain any Windows assets. They want to scan right away for high-risk vulnerabilities, but not Microsoft-related vulnerabilities, because those should not be applicable to their assets. With this knowledge, they can filter only the vulnerabilities they are interested in.




Over the last year, Nexpose added 13,854 new vulnerabilities, but only 6001 met these criteria. Applying these filters will prevent scans for new vulnerabilities that are uninteresting.

The SNMP protocol is very common, has many implementations and is deployed in diverse networks. In some cases it responds very promptly, in others it is relatively slow to respond. We found that in some environments a 1 second request timeout was insufficient, so in Nexpose 6.1.1 we have changed the default to 3 seconds in order to improve the service and related vulnerability detection.


This, however, can have a major impact on scan times on port 161 and may not be desirable on networks with low latency as all relevant vulnerability checks wait 3 times longer to timeout (currently 77 checks). This is why we made the SNMP request timeout configurable via JVM property.

The value of SNMP request timeout can be changed for the console by running a console command. From Administration tab select 'Run' link under 'Maintenance, Storage and Troubleshooting section'. Type:

set custom property

(this will set the timeout to 10 seconds, as the value is represented in milliseconds) and hit the 'Execute' button. The new value is applied immediately and will be used in running scans.

Alternatively the timeout can be changed by creating a file called (if it doesn't exist already) in:

  • [INSTALLATION_PATH]/nsc for Nexpose console or
  • [INSTALLATION_PATH]/nse for Nexpose engine,

and adding the following line to this file:

(again, this will set the timeout value to 10 seconds). The console or engine must be restarted after making the changes to take effect.


Update Tuesday, December 2015

Posted by anowak Employee Dec 8, 2015

December continues this quarter’s trend, 10 bulletins addressing remote code execution (RCE) vulnerabilities, while the remaining two address elevation of privilege. The vulnerabilities affect Internet Explorer (7 and onwards), Edge, Office, Silverlight, VBScript scripting engine and Windows (Vista and onwards). It is advisable for users and administrators to patch the affected platforms.


Microsoft released 12 security bulletins this month, two thirds of them rates as critical, resolving a total of 58 vulnerabilities. All of the critical bulletins (MS15-124, MS15-125, MS15-126, MS15-127, MS15-128, MS15-129, MS15-130, MS15-131) are remote code execution issues affecting a variety of products and platforms including Edge, Internet Explorer, Live Meeting, Lync, Office, Office for Mac, Office Web Apps, Silverlight, Skype, VBScript and all supported releases of Microsoft Windows.


Specifically, MS15-124, MS15-125 and MS15-128 are the bulletins to watch out for this month, addressing 33 vulnerabilities. Since a wide range of products are affected this month almost all Microsoft users should be on alert. Microsoft’s update addresses the vulnerabilities by resolving underlaying issues with how certain functions in VBScript handle objects in memory, preventing cross site scripting (XSS) from incorrectly disabled HTML attributes, proper enforcement of content types and cross–domain policies.


From the bulletins released in December, the following vulnerabilities are know to have been exploited:


Users should be wary of untrusted sources as maliciously crafted content could allow an attacker to remotely execute code and gain the same rights as the user. Your best protection against these threats is to patch as quickly as possible. 


Resolved Vulnerability Reference:

Building an Application Vulnerability Management Program, found in the SANS Institute Reading Room ( ulnerability-management-program-35297), identifies vulnerability program management as a cyclical process involving the following steps:

  • Policy
  • Discovery and Baseline
  • Prioritization
  • Shielding and Mitigation
  • Eliminating the Root Cause
  • Monitoring


While the use of Nexpose applies to several of these steps, the scope of this article is how Adaptive Security fits into your vulnerability management program. To that end we will cover monitoring.



Monitoring is the part of the vulnerability management cycle where changes and refinements are considered and adjustments are made before proceeding to the next iteration. Two critical areas of change to consider are as follows:

  • Covering gaps in your vulnerability assessments
  • Discovery of new vulnerabilities


Covering Your Blindspots

Your run regular scans to discover and assess the assets connected to your network. You carefully schedule the vulnerability scans on nights and weekends to reduce the impact on your network during business hours. How will you ensure that of those laptops that people take home and on the road are also scanned for vulnerabilities? Adaptive Security allows you to automatically detect and scan assets that were previously connected to your network and have missed recent vulnerability scans.


There is a prerequisite for an automated action to employ the discovery trigger:


To create or manage automated actions, click the automated actions icon on the top navigation bar.


Click the NEW ACTION button to create a new action.


Select the type of trigger for your action. For this use case, we'll choose "Known asset available" to detect when assets are reconnected to the network.


Next, select the discovery connection you wish to use as the source for this trigger. We're using a DHCP dynamic discovery connection that accepts Infoblox Triznic log entries via syslog.


Optionally specify one or more filter criteria to refine the assets to be processed. Since we want to scan returning assets that have missed recent scans, we'll select Hours Since Last Scan and enter 84 to include only assets that have not been scanned in a week. Click on the Next button to continue.


Select the action to take when the trigger is invoked. We'll use "Scan." Since this action uses the site from each asset's most recent scan, there is no need to provide any further information.


Enter a descriptive and unique name for this action and then click the Save button.


You should see you new automated action in the list. Here you may view the current state of the action and turn it on and off.


From this point forward, the automated action will scan all returning assets that have not been scanned in the last week.


Reacting to New Vulnerability Discoveries

Researchers continuously discover and publish new vulnerabilities. Quickly assessing your network’s exposure to the more critical new vulnerabilities is essential. Also, with the seemingly increasing number of high-profile breaches in the media, you need to be able to report your assessed risk to executives as soon as possible. In any case, you can reduce your risk by scanning for new, critical vulnerabilities as soon as they're published rather than waiting for the next scan window. With Adaptive Security, you can create an automated action that triggers scans for only the new vulnerabilities that meet your criteria as they are published.


Click the automated actions icon from the top navigation bar and press the NEW ACTION button. Next, select the "New vulnerability coverage available" trigger. Finally, specify a filter for refining the vulnerabilities that will be automatically scanned.



Select the "Scan for new vulnerabilities" action and then select the site to be scanned when new vulnerabilities are published.


Enter a unique, descriptive name for the action and press the SAVE button.


Your new action will be displayed in the list of automated actions. Again, you may view the action state or turn it on and off from here.


Your new action will now automatically scan the specified site for the new vulnerabilities that are published and meet your filter criteria.



Nexpose was already a major player in your vulnerability management program. Adaptive security makes monitoring possible to complete the loop.

The number one critical security control from the Center for Internet Security recommends actively managing all hardware devices on the network:


CSC 1: Inventory of Authorized and Unauthorized Devices

Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access.


Here a some of the reasons you should actively inventory your hardware:

  • Discover new assets that have not yet patched
  • Detect returning hardware such as laptops that have missed previous updates
  • Identify unauthorized hardware


Whatever the scenario, you’ll want to establish your surface area in order to accurately assess your risk and remediate vulnerabilities.


Before you can track and correct assets on your network, you must first establish a method to inventory all of the assets connected to your network. Employing a DHCP dynamic discovery connection in Nexpose is a great way to determine what hardware is present on your network.


Nexpose dynamic asset discovery via DHCP parses DHCP server logs and supports two collection methods for gathering DHCP log entries:

  • Directory watcher – watches a specified directory for new and updated DHCP log files.
  • Syslog – listens on a TCP/UDP port to receive syslog messages much like a syslog server


Nexpose dynamic asset discovery currently supports Microsoft Server 2008 and 1012 using either directory watcher or syslog, as well as, Infoblox Trinzic using syslog.


How to Create a DHCP Discovery Connection

From the Administration page, find the Discovery Options section and click the Create link next to CONNECTIONS.


Next, fill in all three tabs of the form…


From the General tab, select DHCP Service and provide the name of your discovery connection.


From the Service tab, select the event source, collection method, and engine. The source and collection method will determine what additional fields are required. In the example, using the directory watcher collection method for Windows Server mandates providing the fully qualified path to the directory where DHCP logs reside.


From the Credentials tab, provide the username and password for you to access the directory.


As the DHCP server logs events, they will be parsed and imported as assets discovered by connection. Previously assessed assets that appear in DHCP logs will continue to show only as assessed. Discovered assets have not been assessed and present unknown risk to your network.



The Assessment Status chart on the Assets page gives you a clear indication of your un-assessed surface area. Additionally, the Discovered by Connection table enumerates the discovered assets that have not yet been assessed.

Rapid7 has made it a priority to support security industry standards, including the Open Vulnerability and Assessment Language (OVAL).  Those of you who use Nexpose to measure policy compliance, either by using the built-in CIS, DISA, and USGCB policies, or by writing your own custom policies, are using OVAL for these policies.


A decision by the National Institute of Standards and Technology (NIST) has made it necessary for us to make changes in our OVAL implementation.  These changes affect policies written for Microsoft Windows systems.  Previously, Nexpose would convert case-sensitive comparators for certain objects and states to case-insensitive comparators, in order to support the case-insensitive behaviour of Windows.  This was a convenient function when uploading third-party policies, which would sometimes be written with default case-sensitive comparators, leading to false positives.


In order to comply with NIST's requirements for OVAL, it will now be necessary to honour the comparators exactly as written, meaning that comparators will now default to being case-sensitive on Windows systems.  This will not have any effect on policies that have already been imported into Nexpose, nor will it have any effect on the current set of built-in policies.


However, this change will affect:


1) Newly uploaded custom policies

2) Custom policies created by copying built-in content

3) Custom policies created by copying previously uploaded custom policies


As an example, consider the following registry object:


<registry_object xmlns="" 
id="oval:nist.validation.winRegistry:obj:19" version="1">
    <name operation="equals">vQwordLE</name>


The name element in that object has an 'operation = "equals"' attribute.  Previously, this attribute would have been automatically converted to be 'operation = "case insensitive equals"'.  With the new change, this will no longer be the case: there will be no conversion, and the attribute will remain as 'operation = "equals"'.  This is also the default behaviour: when no operation is specified, the operation will be "equals".


As a result, a policy rule that would have passed regardless of whether the name field in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\SCAP_Validation_Test\win_reg\exists were "vqwordle", or "VQWORDLE", or "vQwordLE", will now only pass when the value in the name field is exactly "vQwordLE".


To change the behaviour of the object to match its previous behaviour, you would need to change:


<name operation="equals">vQwordLE</name>


to be:


<name operation="case insensitive equals">vQwordLE</name>


The following objects and states will be affected by this change:

accesstoken_object, accesstoken_state

environmentvariable_object, environmentvariable_state

environmentvariable58_object, environmentvariable58_state

fileauditedpermissions_object, fileauditedpermissions_state

fileauditedpermissions53_object, fileauditedpermissions53_state

fileeffectiverights_object, fileeffectiverights_state

fileeffectiverights53_object, fileeffectiverights53_state

file_object, file_state

group_object, group_state

registry_object, registry_state

sid_sid_object, sid_sid_state

sid_object, sid_state

user_object, user_state


Depending on your requirements, you may need to rewrite your custom policies to reflect these changes.  It will also be necessary to evaluate the functionality of any new policies that you create by copying previously imported policies.  We regret that this change might be disruptive, but it is necessary to ensure full compatibility with industry security standards.


Update Tuesday, November 2015

Posted by anowak Employee Nov 10, 2015

November sees a mix of remote code execution and elevation of privilege vulnerabilities enabling an attacker to gain the same rights as the user when the victim opens specially crafted content, such as a webpage, journal file or document containing embedded fonts. These vulnerabilities affect Internet Explorer (7 and onwards), Edge, and Windows (Vista and onwards).  It is advisable for users and administrators to patch the affected platforms.


Microsoft includes 12 security bulletins, a third of them rated as critical, resolving a total of 49 vulnerabilities. All of the critical bulletins (MS15-112, MS15-113, MS15-114, MS15-115) are remote code execution issues affecting affecting a variety of products and platforms including Edge, Internet Explorer, Lync, Office, Office for Mac, Office Web Apps, Skype for Business, SharePoint Server and all supported releases of Microsoft Windows.


MS15-112 is the bulletin to watch out for this month, it addresses 25 vulnerabilities. It is rated Critical for Internet Explorer 7 - 11 on Windows clients and moderate on Windows servers. Microsoft's update addresses the vulnerabilities by resolving underlaying issues with how objects are handled in memory for JScript and VBScript, properly re-implemeting the ASLR security feature and adding additional permissions to Internet Explorer.


Users should be wary of untrusted sources as maliciously crafted content could allow an attacker to remotely execute code and gain the same rights as the user. Your best protection against these threats is to patch as quickly as possible.


Resolved Vulnerability Reference:


Increasing Risk Visibility

Posted by anowak Employee Oct 29, 2015

We at Rapid7 are committed to providing our customers with the best, most accurate vulnerability detection and remediation information. To better serve you, starting October 28th, 2015, Rapid7 will begin generating content for Nexpose in a way that will provide greater visibility into risk. This change will start with content generated for Adobe, Debian and Ubuntu and eventually all supported platforms will transition to this approach. For the end user the benefit is more accurate representation of risk and better data to prioritize remediation steps.

As a customer you may be asking, how will this change impact me? Under the historical approach vulnerability results are from the perspective of the Vendor, via their advisory, which may contain one or more vulnerabilities. Unfortunately this masked actual risk in a way that was not anticipated. As an example taken from an Ubuntu advisory, USN-2735-1, you will notice this one advisory addresses 8 vulnerabilities (CVE-2015-1291, CVE-2015-1292, CVE-2015-1293, CVE-2015-1294, CVE-2015-1299, CVE-2015-1300, CVE-2015-1301, CVE-2015-1332).

Historically we would have taken the highest CVSSv2 score out of those 8 (which in this case is a 7.5) and reported this as one vulnerability with that score. Going forward, Nexpose will report the score per vulnerability giving you greater visibility into the risk within your environment through an increase in the detail of vulnerability results.

We will publish a supplementary blog post with each platform that move to the vulnerability-centric approach.

Rapid7’s Vulnerability Management and User Behavior Analytics solutions, Nexpose and UserInsight, now integrate to provide visibility and security detection across assets and the users behind them. Combining the pair provides massive time savings and simplifies incident investigations by highlighting risk across your network ecosystem without writing queries or digging through logs.


Related Resource: Download our beginner’s guide to User Behavior Analytics with UserInsight Toolkit


Nexpose proactively identifies & prioritizes weak points on your network, while UserInsight helps detect stealthy attacks with behavior analytics, investigate security incidents faster with user context, and expose risky internal behavior from endpoint to cloud. 4-minute UserInsight demo. Let’s look at two specific benefits: (1) user context for your vulnerabilities, and (2) automatic security detection for your critical assets.




User Context for Your Vulnerabilities

UserInsight integrates with your existing network & security infrastructure to automatically baseline your users’ activity. By correlating all activity to the users behind them, you’re alerted of attacks that often go unnoticed, such as compromised credentials and lateral movement.


When UserInsight ingests the results of your Nexpose vulnerability scans, they are also added to each user’s profile. By simply searching for an employee name, asset, or IP address, you get a complete look at their activity:




How this saves you time:

  • Immediately see who is affected by what vulnerability – this helps you get buy in to remediate a vulnerability by putting a face and context on a vulnerability (“The CFO has this vulnerability on their laptop – we must remediate immediately so they don’t get phished.”)
  • Have instant context on the user behind the asset, so you can assess whether a particular piece of malware that exploits a particular vulnerability could have been successful
  • Proactively bolster and check risk surface – verify key players are not vulnerable


Automatic Security Detection for Critical Assets

In Nexpose, you can dynamically tag assets as critical by factors such as being in the IP range of the DMZ or containing a particular software package/service unique to domain controllers. Critical asset tags can be synced with UserInsight, where they show up as restricted assets.


Some examples of critical asset alerts:

  • First authentication from an unfamiliar source asset: If there’s an unfamiliar attempt to authenticate to a restricted asset, you’ll receive an alert.
  • An unauthorized user attempts to log-in: This can include a contractor or compromised employee attempting to access a financial server.
  • A unique or malicious process hash is run on the asset: UserInsight uses an agentless endpoint monitor to identify every process run on your endpoints. We run these process hashes against the wisdom of 50 virus scanners to identify malicious processes, as well as identify unique processes for further investigation.
  • Lateral movement (both local and domain): Once inside your organization’s network, intruders typically run a network scan to identify high-value assets. They then laterally move across the network, leaving behind backdoors & stealing higher privilege credentials.
  • Endpoint log deletion: After compromising an organization’s asset, attackers look to delete system logs in order to hide their tracks. This is a high-confidence indicator of compromise.
  • Anomalous administrative activity, including privilege escalation exploits: Once gaining access to an asset or endpoint, attackers will use privilege escalation exploits to gain administrative access, allowing them to take next steps such as password hash scraping. We identify and alert on anomalous administrative activity across your network ecosystem.


As Nexpose identifies critical or vulnerable assets, UserInsight automatically adjusts its detection thresholds to alert you about things you’ll want to know about.




Configuring the UserInsight-Nexpose Integration

If you have Nexpose & UserInsight, setting up the Event Source is easy.

  1. In Nexpose, setup a Global Admin
  2. In UserInsight, click on the Collectors tab -> Rapid7 -> “Add event source”


     3. Add the information about the Nexpose Console (Server IP & Port)

     4. Add the credentials of the newly created Global Admin


And you’re all set! If you have any questions, contact your QuickStart Manager or Support. Don’t have UserInsight and want to learn about User & Entity Behavior Analytics? Get the Gartner Market Guide for UEBA here.

With the release of Nexpose 5.17, customers were enabled to easily gain an outsider’s view of their internet-facing assets.  This capability was made possible through integration with Rapid7 Labs’ Project Sonar.


What is Project Sonar?


Project Sonar is a community effort to improve security through the active analysis of public networks. This includes running scans across public internet-facing systems, organizing the results, and sharing the data with the information security community.    Sonar regularly ‘scans the internet’ and gathered data is archived and made publicly available in cooperation with the University of Michigan.


Integration with Nexpose

When designing the integration with Project Sonar, we spent a lot of time determining the ‘best fit’ for a seamless integration into the Nexpose workflow.  We wanted it to make it both easy and intuitive to retrieve and view data from this new external data source.


Connecting to Sonar

Working with Rapid7 Labs engineers, we were able to create an ‘always there’, trusted connection to Sonar based on the user’s Nexpose license.  A properly licensed Nexpose console install (with internet access) would be able to automatically authenticate with and connect to the Sonar service.  No action is required from the user.


We wanted the user to be able to confirm this connection was active.   Since Sonar represents a new way for the user to discover assets, showing the connection in the ‘Discovery Connections’ listing was a natural fit.

Screen Shot 2015-10-05 at 5.31.53 PM.png

*note: Since the Sonar connection is always available, edit and delete have been disabled.  If your console is not licensed or cannot reach the internet, the Sonar connection will not exist in this table.


Asset Data

When determining how to organize and present Sonar gathered data, we considered that Nexpose assets are divided into 3 categories:

  • Discovered by Connection:  Assets that have been discovered from an external connection (ie: DHCP).  Very little is known about these assets otherthan their hostname and ip address.
  • Discovered by Scan: This category holds assets that have been scanned in some way (ie: discovery scanned) so that more catalog information is known about the asset.
  • Assessed.  To be categorized as assessed, an asset has been Nexpose scanned and evaluated for vulnerabilities or policy. (ie: full audit scan)

Screen Shot 2015-10-05 at 6.14.08 PM.png

Sonar data fits best into the ‘Discovered by Scan’ state, as there is a variety of asset information cataloged, but it does not contain vulnerability and policy data that would be gathered and evaluated during a typical Nexpose scan.


On the Nexpose assets page, imported Sonar assets will be found in the ‘scanned’ asset listing. The ‘assessed’ column will say ‘no’.

Screen Shot 2015-10-05 at 6.33.06 PM.jpg



Retrieving Data from Sonar

Sonar ‘scans the internet’ so it contains a huge dataset with has varying degrees of freshness.  We could not automatically collect data without user input.  In the simplest case, a target ‘search domain’ would be required.  We already had a mechanism in place for specifying a set of filters to be applied to a connection from which assets could be pulled.  When creating a site, the user is given several options to specify which assets to scan.  One of those options is via discovery connection.  And discovery connections allow the user to create filters.

Screen Shot 2015-10-06 at 3.17.16 PM.png

This is how you bring in assets from Sonar.  Create a site and select 'specify assets by connection.'  The Sonar connection will be in the dropdown list (again, properly licensed, console with an internet connection).  Add a search domain on which to filter and click the 'filter' button to see a listing of assets that would be brought into Nexpose when that site is saved and scanned.  A 10,000 asset limit was imposed for a given Sonar site to help the user avoid retrieving more assets than expected.   Remember, Sonar's dataset is the internet.


A Note on 'scanning' a site based on a Sonar connection

Screen Shot 2015-10-06 at 3.43.21 PM.png

When the a Sonar site is 'scanned', what is actually happening is that we retrieve the most current asset data archived in the Sonar dataset.  Project Sonar has done the actual exploratory scan of the asset at different times as it works its way through scanning the internet.


'Scanning' a Sonar site *does not* perform a Nexpose assessment of those assets, it simply retrieves archived scan data from Sonar.  (note: The 'last scan' date in the asset listing will show the last time it was seen by Sonar, not the last time time a Sonar data retrieval was performed.  We realize this will create some confusion with users who would like to perform a full-audit scan of their discovered externally facing assets.


Think of a Sonar scan as a discovery scan that retrieves a larger set of data per asset.  It does not assess for vulnerabilities or policy but does find relevant assets and ip addresses that the user might want to more carefully audit.  To audit assets discovered by the Sonar site, the user will need to create an Asset Group (dynamic or static) containing the assets which are desired for a full-audit.  That asset group can then be scanned by Nexpose in the traditional way.

Screen Shot 2015-10-06 at 4.01.25 PM.png


What is Next?

We are reaching out and listening to users to discover how they would like us to evolve this functionality.  We are planning to add more complex filtering to the initial import of Sonar data.  A big example of this is filtering by last Sonar scan date.  The Sonar project does not currently age out asset information.  We want to give users the ability to say "I only want to retrieve assets that have been seen by Sonar within the last X days".


Additionally, we're thinking about alleviating the extra steps required to perform a Nexpose scan of assets imported from Project Sonar.  We want to make this process as easy as possible while making sure users don't full-audit scan unintentionally large datasets (or assets that they don't own).


From the Engineers

We hope our community is excited to have yet another method for discovering their full surface area and for this unique 'outsider's' view of their internet presence.  We are actively working with customers, project management, and other stakeholders to make sure Project Sonar integration is a valuable and seamless addition to the Nexpose product.

Filter Blog

By date: By tag: