Rapid7 Blog

Roy Hodgman  



WannaCry Update: Vulnerable SMB Shares Are Widely Deployed And People Are Scanning For Them

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…

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 scans.io. 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): 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: 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: <span 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. 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. 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. 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. Related: Find all of our WannaCry related resources here [Blog] Using Threat Intelligence to Mitigate Wanna Decryptor (WannaCry)

The Data Science Process at Rapid7

Data Science is more than just math. A successful Data Science team and successful Data Science projects require relationships with outside teams, clear communication, as well as good decision making, problem solving and critical thinking abilities. Thus, when we talk about Data Science at Rapid7,…

Data Science is more than just math. A successful Data Science team and successful Data Science projects require relationships with outside teams, clear communication, as well as good decision making, problem solving and critical thinking abilities. Thus, when we talk about Data Science at Rapid7, we talk about the Data Science Process our teams use to take a Data Science project from inception to completion, where math and analysis are important, but not the only aspects of the project.What are we talking about here?To be clear about terms, we consider Data Science to be composed of several related disciplines, such as statistics, machine learning, visualization and to some extent, data engineering and management.Additionally, Data Science (and machine learning in particular) is the right tool to address some problems. However, it is important to distinguish between machine learning applied to problems for which it is the right tool to solve them, and machine learning applied to problems for the sake of being able to market “more machine learning.”Why does Rapid7 use Data Science?Rapid7's motivation for using Data Science is to solve complex problems to make our products more effective and our customers happier. Specifically, it is not to be able to market the inclusion of machine learning capabilities in our products. When a problem we're working on can be best addressed by machine learning, we will try to use machine learning techniques to address that problem, otherwise, we will find another more appropriate way to address the problem, possibly even a simple rule.Ok, walk me through this processWhen people or groups within Rapid7 (problem owners) have a problem they think can be solved or addressed by the Data Team, they come to us to figure out if we can help. Throughout the entire process described below, the Data Team and the problem owner are in contact to make sure the assumptions we make about the problem, the data, and the solution are correct.There are six steps involved in the Data Science Process:Understand the problemIdentify relevant dataDetermine viabilityResearch research researchReportHand offUnderstand the problemThe first step is to get a deep understanding of the problem to be solved. This involves a few rounds of questions and answers with the problem owner to make sure they are convinced that the people from the Data Team really do understand the problem. Without this deep understanding of the problem (Why is it a problem in the first place? Why does it need to be solved? What does a good solution look like?), it is easy to end up with a solution that isn't what the problem owner really needs.Identify relevant dataThe next step is to figure out if there is data that can help solve the problem, and if there is, where that data lives. Do we already have it? Do we need to gather it? Buy it? Generate it? Working together with the problem owner, as much as they are able to, we make a determination together about whether or not the data we plan to work with is appropriate for the problem, or if there is other data we should be using.Determine viabilityThis is the squishiest step of them all, but is crucial. In this step, the Data Team will determine whether or not the relevant data is sufficient to try to solve the problem, or at least start research. This isn't an attempt to rate the quality of the available data from a mathematical or statistical point of view, but rather to take a step back from the work that's been done thus far and take stock of whether or not there is enough available data to do anything worthwhile.For instance, if the available data consists of two data sets from two different sources which share a field in column that can link the two, but the intersection of these data sets is some very small proportion of either, it's worth taking time here to evaluate if there's more data that can be gathered to make that intersection larger, or whether there's a different way to join the data.Research research researchThis is the stage where the Data Science team will do the work they probably consider the most interesting and fun. They will investigate whether different Data Science techniques are appropriate to solve the problem. If machine learning looks viable, they will identify which machine learning algorithms are appropriate and see if they can make an interesting model. Ideally, this is the stage where the problem is solved, or if it can't be solved, it becomes clear why that is.It is also crucial that through this phase the Data Team and the problem owner consult with each other frequently about the progress being made and the issues that come up. In most cases the problem owner will have more domain knowledge about the problem and the data at hand than the Data Team does, so being able to check in frequently and run new findings by domain experts will help the Data Team quickly readjust their efforts when necessary.ReportThe reporting stage is an opportunity for the Data Team to communicate back to the problem owner everything they've done in the “research research research” phase. This is the inverse of the first stage, in that now the problem owner should be making sure they understand as much as they can about the outcome of the research. The Data Team will explain data they used, why it was useful, the methods they used to transform and analyze that data, and what they've come up with as a solution to the problem. Additionally, they will present an overview (or as much detail as the problem owner wants) about specifically what did not work.This stage is crucial to the Data Science Process. It allows both the Data Team and the problem owner to come back together and fully evaluate whether or not the outcome of the research addresses the problem, and if the Data Team has achieved its goal from the first stage when they identified what a good solution would look like.Hand offThe final stage of the process is to work with the problem owner to hand off the research output and make it useful. In this stage, both the Data Team and the problem owner need to figure out:What will an embodiment of the solution look like? (A command line tool? A hosted service? A shared library? An additional API? A serialized model?)Who will update and maintain that embodiment?Where does it live? And who gets the call at 3:00 a.m. when something breaks?Without a clear plan for how to incorporate the solution into a system that can make use of it, it can easily wither and not be adopted.Great, this seems familiar, how is this specific to Data Science?Except for the details of the “research research research” phase, very little of this is specific to Data Science. This process is derived from and can be applied to other disciplines, but just spelling it out and going through the process has been immensely useful to our Data Team.We have had projects where we didn't fully understand the problem and found ourselves at the end of a project presenting something back to the problem owner that they already knew or knew how to do.We have had projects where we didn't fully explore the available data, or determine whether that data was viable, and we worked on incomplete data sets and ended up with a solution that didn't give the problem owners much confidence in the solution's utility.We have had projects where we didn't communicate our findings well or thoroughly to the problem owner and as a result, our research output was not adopted due to incorrect conclusions drawn about it.And we have certainly had projects where everything works well up until the point where we try to figure out where the solution lives, and it sits in limbo instead of being useful.The Data Science Process emphasizes and requires communication throughout, and relies on teams to establish and maintain relationships instead of working in isolation. With a prescribed set of steps that keep the Data Science team and the problem owner in sync, from establishing expectations about the problem and solution at the outset, to working together to find a home for the solution, the Data Science Process has enabled our Data Team to be more successful and useful to the Rapid7 community, internally and externally. It allows us to make our engineers, our consultants, our products and ultimately you, our customers, happier, more efficient, and more secure.

NCSAM: You Should Use a Password Manager

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial…

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face. This year, NCSAM is also focused on taking steps towards online safety, including how to have more secure accounts. In 2016, just like in most of the last 15 years, we learned new information about recent and not so recent data breaches at large organizations, during which sensitive account information was made public. Essentially, these breaches have unearthed data on what puts accounts at higher risk for a breach. Putting aside the concerns about non-password account information being made public, one of the factors that determines how bad a data breach is for users is the format of leaked passwords. Are they plaintext? Plaintext passwords are just the actual password that a user would type. For example, the password "taco" is stored as "taco" and when made public, can be used by an attacker right away. Have they been hashed? Hashed passwords are mathematical one way transformations of the original password, meaning that it is easy to transform the password into a hash, but given a hash, it's very difficult to recover the original password. For example, the password "taco" is stored as "f869ce1c8414a264bb11e14a2c8850ed" when hashed with the MD5 hash algorithm, and the attacker must recover the original password from this hash in order to use it. Have they been salted and hashed? Hashed passwords are good, but there are several tools and methods that can be used to try to reveal the original password. There are even dictionaries that connect hashes back to their original passwords. Submitting "f869ce1c8414a264bb11e14a2c8850ed" to http://md5.gromweb.com/ reveals that the word "taco" was used to generate that hash. Adding a "salt" to a password, means to add extra data to it before it gets hashed. For example, the password "taco" is combined with the word "salsa" before being hashed, and the resulting hash is stored as "6b8dc43f9be3051e994cafdabadc2398". Now, an attacker looking up the hash "6b8dc43f9be3051e994cafdabadc2398" in a dictionary won't find anything, and will be forced to create a new dictionary which ideally is time consuming. Have they been hashed with a well studied unbroken algorithm? The MD5 algorithm has known attacks against it, so it is a good idea to use another algorithm. Have they been hashed multiple times? Or with a computationally expensive algorithm? Or with a memory expensive algorithm? These and other questions get into the nitty gritty of how passwords can be stored scurely so that they are of little use to an attacker once they are made public. Luckily, there are plenty of resources for security engineers to follow in order to make their sites more secure, and in particular, their storage of passwords more secure even if they are disclosed. Dropbox has an interesting post about how they store passwords, and this talk by Alec Muffet from Facebook, which describes their methods for storing passwords, is really interesting. In fact, there is an entire conference dedicated to passwords and the engineering that goes into keeping them secure. This site tracks published details about password storage polices of various sites, and this presentation provides the motivation for doing so. That's great, but I'm not a security engineer, what do I need to know about passwords? There is an unending list of articles, blog posts, howto guides and comics written about passwords. Passwords are going away. Passwords will eventually go away. Passwords are here to stay. Passwords are insecure. Two factor authentication will save us all. Biometrics will save us all. Whatever your opinion you probably have multiple accounts with multiple websites and ideally you're using multiple passwords. It's a good idea to recognize that whether or not the sites you use are doing a good job of protecting your passwords, you too can take steps to make your password use more secure. If you take nothing else away from this post, remember to setup a password manager (there are many), actually use it to create different passwords for each account you have, routinely look into whether your account information has been leaked recently, and if it has, change the password associated with that account. What's the big deal? If you have an account with an online service, like an email provider, a social network, or an ecommerce site, then it is very likely that you have a password associated with that account. It's also likely that you have more than a few accounts, and having so many accounts you have most likely been tempted to use the same or similar usernames and passwords across accounts. While there are clear benefits (among some privacy / tracking drawbacks) to having a consistent identity across services (ironicjen182@gmail.com, ironicjen182@facebook.com, ironicjen182@totallylegitonlinebusiness.biz), there are clear drawbacks to using the same password across services, mainly that if one of these services is attacked and account information is leaked, your accounts with identical or similar usernames at the other services could be vulnerable to misuse by an attacker. Ok, but who cares? It's just my (hotmail | twitter | ebay | farmersonly) account. You should care, these accounts paint a very detailed picture of who you are and what you do. For instance, you email has a record of emails you have sent and of those sent to you, and from that an attacker can learn a surprising amount about you. With email providers that offer effectively unlimited email storage and provide little incentive for users to erase emails, it's nearly impossible for a user to be sure that nothing useful to an attacker is buried somewhere inside. Furthermore, your email (and social media accounts) are effectively an extension of you. When an attacker has control of your account, emails, tweets, snaps sent from your account are accepted as coming from you, and attackers can take advantage of those assumptions and the trust that you've built up with you contacts. For example, consider the Stranded Traveler Scam in which an attacker sends a message to one or more of your contacts claiming to be in a bad situation somewhere far away, and if they could just wire some money, things would surely work out. There are news reports about these types of scams all the time (2011, 2011, 2012. 2013, 2014, 2015, 2016) Because the email has come from your account and bears your name, your relatives, friends and coworkers are more likely to believe it is actually you writing the message than a scammer. Similar attacks involve sending malware in attachments and requesting wire transfers for family members or executives, or requesting w-2 forms for employees. None of these attacks require that takeover of your account, but are certainly strengthened by it. Really, how often does this happen? Can't I just deal with it when I hear about it on the news? You could do that, and it would be better than not doing anything at all, but breaches that leak account information happen surprisingly frequently and they don't always make the news that you read. Sometimes, we don't learn about them for weeks or years after they happen, meaning that passwords you used a long time ago may have been known to attackers for a while before you were made aware of a breach. Is my password really out there? Sometimes. Maybe. It's hard to say. Often, sites will hash passwords before they are stored. However, different sites use different hash methods which have different security characteristics, and some methods previously believed to be secure are no longer considered so. Shouldn't these sites be more secure? That would be nice, but data security is a difficult and quickly changing field and not every site prioritizes security as highly as you might like. Fine, what should I do? You should to a few things: Use a password manager There are many password managers available to you, like LastPass, 1Password, KeepassX or if you're into the command line, try out pass. Use a different password for every account you have Now that you have a password manager storing all your passwords, there's no need to reuse passwords Use complex passwords Most password managers can create long random strings of letters, numbers and symbols for you. Since the password manager stores these passwords and you don't have to remember them, there's no need to use simple or short passwords. Keep an eye on sites that catalog leaked account information. Have a look from time to time at sites that keep track of leaked accounts to see if your account has been leaked. haveibeenpwned.com is usually kept up to date and is easy to use.

The Attacker's Dictionary

Rapid7 is publishing a report about the passwords attackers use when they scan the internet indiscriminately. You can pick up a copy at booth #4215 at the RSA Conference this week, or online right here. The following post describes some of what is investigated in…

Rapid7 is publishing a report about the passwords attackers use when they scan the internet indiscriminately. You can pick up a copy at booth #4215 at the RSA Conference this week, or online right here. The following post describes some of what is investigated in the report. Announcing the Attacker's Dictionary Rapid7's Project Sonar periodically scans the internet across a variety of ports and protocols, allowing us to study the global exposure to common vulnerabilities as well as trends in software deployment (this analysis of binary executables stems from Project Sonar). As a complement to Project Sonar, we run another project called Heisenberg which listens for scanning activity. Whereas Project Sonar sends out lots of packets to discover what is running on devices connected to the Internet, Project Heisenberg listens for and records the packets being sent by Project Sonar and other Internet-wide scanning projects. The datasets collected by Project Heisenberg let us study what other people are trying to examine or exploit. Of particular interest are scanning projects which attempt to use credentials to log into services that we do not provide. We cannot say for sure what the intention is of a device attempting to log into a nonexistent RDP server running on an IP address which has never advertised its presence, but we believe that behavior is suspect and worth analyzing. How Project Heisenberg Works Project Heisenberg is a collection of low interaction honeypots deployed around the world. The honeypots run on IP addresses which we have not published, and we expect that the only traffic directed to the honeypots would come from projects or services scanning a wide range of IP addresses. When an unsolicited connection attempt is made to one of our honeypots, we store all the data sent to the honeypot in a central location for further analysis. In this post we will explore some of the data we have collected related to Remote Desktop Prodocol (RDP) login attempts. RDP Summary Data We have collected RDP passwords over a 334 day period, from 2015-03-12 to 2016-02-09. During that time we have recorded 221203 different attempts to log in, coming from 5076 distinct IP addresses across 119 different countries, using 1806 different usernames and 3969 different passwords. Because it wouldn't be a discussion of passwords without a top 10 list, the top 10 passwords that we collected are: password count percent x 11865 5.36% Zz 10591 4.79% St@rt123 8014 3.62% 1 5679 2.57% P@ssw0rd 5630 2.55% bl4ck4ndwhite 5128 2.32% admin 4810 2.17% alex 4032 1.82% ....... 2672 1.21% administrator 2243 1.01% And because we have information not only about passwords, but also about the usernames that are being used, here are the top 10 that were collected: username count percent administrator 77125 34.87% Administrator 53427 24.15% user1 8575 3.88% admin 4935 2.23% alex 4051 1.83% pos 2321 1.05% demo 1920 0.87% db2admin 1654 0.75% Admin 1378 0.62% sql 1354 0.61% We see on average 662.28 login attempts every day, but the actual daily number varies quite a bit. The chart below shows the number of events per day since we started collecting data. Notice the heavy activity in the first four months, which skews the average high. In addition to the username and password being used in the login attempts that we captured, we also collected the IP address of the device making the login attempt. To the best of the ability of the GeoIP database we used, here are the top 15 countries from which the collected login attempts originate: country country code count percent China CN 88227 39.89% United States US 54977 24.85% South Korea KR 13182 5.96% Netherlands NL 10808 4.89% Vietnam VN 6565 2.97% United Kingdom GB 3983 1.80% Taiwan TW 3808 1.72% France FR 3709 1.68% Germany DE 2488 1.12% Canada CA 2349 1.06% With the data broken down by country, we can recreate the chart above to show activity by country for the top 5 countries: RDP Highlights There is even more information to be found in this data beyond counting passwords, usernames and countries. We guess that these passwords are selected because whomever is conducting these scans believes that there is a chance they will work. Maybe the scanners have inside knowledge about actual usernames and passwords in use, or maybe they're just using passwords that have been made available from previous security breaches in which account credentials were leaked. In order to look into this, we compared all the passwords collected by Project Heisenberg to passwords listed in two different collections of leaked passwords. The first is a list of passwords collected from leaked password databases by Crackstation. The second list comes from Mark Burnett. In the table below we list how many of the top N passwords are found in these password lists: top password count num in any list percent 1 1 100.00% 2 2 100.00% 3 2 66.67% 4 3 75.00% 5 4 80.00% 10 8 80.00% 50 28 56.00% 100 55 55.00% 1000 430 43.00% 3969 1782 44.90% This means that 8 of the 10 most frequently used passwords were also found in published lists of leaked passwords. But looking back at the top 10 passwords above, they are not very complex and so it is not surprising that they appear in a list of leaked passwords. This observation prompted us to look at the complexity of the passwords we collected. Just about any time you sign up for a service on the internet – be it a social networking site, an online bank, or a music streaming service – you will be asked to provide a username and password. Many times your chosen password will be evaluated during the signup process and you will be given feedback about how suitable or secure it is. Password evaluation is a tricky and inexact art that consists of various components. Some of the many aspects that a password evaluator may take into consideration include: length presence of dictionary words runs of characters (aaabbbcddddd) presence of non alphanumeric characters (!@#$%^&*) common substitutions (1 for l [lowercase L], 0 for O [uppercase o]) Different password evaluators will place different values on each of these (and other) characteristics to decide whether a password is "good" or "strong" or "secure". We looked at a few of these password evaluators, and found zxcvbn to be well documented and maintained, so we ran all the passwords through it to compute a complexity score for each one. We then looked at how password complexity is related to finding a password in a list of leaked passwords. complexity # passwords % crackstation crackstation % Burnnet Burnett % any any % all all % 0 803 20.23 726 90.41 564 70.24 728 90.66 562 69.99 1 1512 38.10 898 59.39 634 41.93 939 62.10 593 39.22 2 735 18.52 87 11.84 37 5.03 94 12.79 30 4.08 3 567 14.29 13 2.29 5 0.88 13 2.29 5 0.88 4 352 8.87 7 1.99 4 1.14 8 2.27 3 0.85 The above table shows the complexity of the collected passwords, as well as how many were found in different password lists. For instance, with complexity level 4, there were 352 passwords classified as being that complex, 7 of which were found in the crackstation list, and 4 of which were found in the Burnett list. Furthermore, 8 of the passwords were found in at least one of the password lists, meaning that if you had all the password lists, you would find 2.27% of the passwords classified as having a complexity value of 4. Similarly, looking across all the password lists, you would find 3 (0.85%) passwords present in each of the lists. From this we extrapolate that as passwords get more complex, fewer and fewer are found in the lists of leaked passwords. Since we see that attackers try passwords that are stupendously simple, like single character passwords, and much more complex passwords that are typically not found in the usual password lists, we can surmise that these attackers are not tied to these lists in any practical way -- they clearly have other sources for likely credentials to try. Finally, we wanted to know what the population of possible targets looks like. How many endpoints on the internet have an RDP server running, waiting for connections? Since we have experience from Project Sonar, on 2016-02-02 the Rapid7 Labs team ran a Sonar scan to see how many IPs have port 3389 open listening for tcp traffic. We found that 10822679 different IP addresses meet that criteria, spread out all over the world. So What? With this dataset we can learn about how people looking to log into RDP servers operate. We have much more detail in the report, but some our findings include: We see that many times a day, every day, our honeypots are contacted by a variety of entities. We see that many of these entities try to log into an RDP service which is not there, using a variety of credentials. We see that a majority of the login attempts use simple passwords, most of which are present in collections of leaked passwords. We see that as passwords get more complex, they are less and less likely to be present in collections of leaked passwords. We see that there is a significant population of RDP enabled endpoints connected to the internet. But wait, there's more! If this interests you and you would like to learn more, come talk to us at booth #4215 the RSA Conference.

RiskRater Endpoint Report

Today we're releasing the second of three reports derived from our RiskRater research.The first report focused on mobile devices and the BYOD movement. Today's report is concerned with endpoint devices and their security.Given that user endpoints are increasingly becoming the target of attacks,…

Today we're releasing the second of three reports derived from our RiskRater research.The first report focused on mobile devices and the BYOD movement. Today's report is concerned with endpoint devices and their security.Given that user endpoints are increasingly becoming the target of attacks, we were interested in how well the respondents:Enable code execution prevention techniquesBlock suspicious email attachmentsRequire and enforce periodically expiring strong passwordsOverall, we were happy to find that 4 out of 5 respondents indicated they have implemented all but one of the security controls we asked about. The exception is that only 46% of respondents had implemented code execution techniques (such as DEP or ASLR).While we are encouraged that so many respondents have taken steps to protect their endpoint devices, we want to stress that this research only covers a few basic security controls. We want to make it clear that endpoint security is an ongoing process that must be monitored and managed, and is most effective when coupled with a full complement of network, application and user security controls and practices.The full report is located here, please take a look.If you have not yet had a chance to participate in our RiskRater program, you can do so here.

Introducing RiskRater - a free tool for benchmarking endpoint, mobile and user risk management programs

IntroductionsAfter lurking for a little while, I'm starting to write on SecurityStreet today in order to introduce RiskRater, a tool we've been working on recently. RiskRater is an interactive free tool designed to give security professionals a quick snapshot of how they are doing in…

IntroductionsAfter lurking for a little while, I'm starting to write on SecurityStreet today in order to introduce RiskRater, a tool we've been working on recently. RiskRater is an interactive free tool designed to give security professionals a quick snapshot of how they are doing in terms of their security controls for endpoints, mobile devices and user-based risk.What Does RiskRater Do?We frequently hear from security professionals that they are under constant pressure to keep up to date and are often under-resourced. As a result, they need to work hard to prioritize their actions for maximum efficiency and effectiveness. Thus, we created RiskRater to help identify the areas of a security program that need work and to give guidance about what can be done, as well as the importance of doing each of these things.The tool aims to bring to your attention areas that need work in a prioritized order. Of all the tasks you could do to improve your organization's overall security, which should you do first? Some are more valuable to do before others, and RiskRater will help you identify what they are.How Does RiskRater Work?Essentially, RiskRater is a straightforward grading tool focused on security. It poses a number of questions for each of three categories (endpoint, mobile, and user), and calculates a score from 1-10 based on your answers. The scoring is determined using an algorithm we created, and then mapped against benchmarks for the three categories. We developed those benchmarks by working with data collected from our own research, as well as responses from over 600 organizations. Thank you very much to everyone who gave us feedback. We really wanted to create a baseline so users can see how they're doing compared to others, so we greatly appreciate the information you shared with us. As more people use the tool, the benchmarks will evolve to reflect the user base (but no specific or personal attributable information will be shared).Calculating RiskI worked on the risk calculation part of the project and want to explain how that works. The main RiskRater page tells you that RiskRater helps "you understand your endpoint, user and mobile risk and security posture, and gain practical advice on how you can strengthen your defenses" but it doesn't give any more detail than that, so here's a little more on how it works.RiskRater uses a grading model to produce results. You supply answers to questions, it grades your answers and then it gives you results. The calculations we use in the RiskRater model aren't very complicated. Instead, we focus on creating good weights for each question. These weights are derived from a mixture of personal experience and expertise gathered from our in house security experts, (the Rapid7 Labs team and Metasploit researchers), from published guidance, and from insight and analysis of our customer's security practices.If you answer "yes" to all the questions you'll get a 10 (out of 10). If you answer "no" or "don't know" to all the questions, you'll get a 1. More specifically, each of the questions to which you answer "yes" contributes a certain amount to your scores, and these amounts are what determine the guidance RiskRater gives.Not every action you take to improve your security has the same value. For instance, our research shows that in general, keeping commonly exploited applications and operating systems up to date is more valuable than preventing data from being copied to or from USB thumb drives. Which isn't to say that restricting data transfer to and from USB thumb drives isn't worthwhile, just that if you need to do decide which problem to address first, we recommend making sure everything is updated.We have tried to encode our knowledge of the varying importance of different security measures into RiskRater, by having different questions have different values, so it can give you useful guidance.Give it a goAnswering the questions RiskRater asks only takes a few minutes and you'll see your scores right away as soon as you're done. So go try RiskRater for yourself, and if you have any questions or feedback, please let us know in the comments section below.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More


Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now


Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now