In order to overcome the adversary, we must first seek to understand. By understanding how attackers operate, and what today’s modern network looks like from an attacker’s perspective, it’s possible to deceive an attacker, or at least have warning around internal network compromise. Today, let’s touch on a classic deception technology that continues to evolve: the honeypot.

Honeypots are decoy systems, deployed alongside production systems with the intent of tricking attackers into interacting with them. By deceiving an attacker into carrying out his/her attack on a non-critical, well-monitored system, valuable insight can be gained into their attack methods, and information can be gathered for forensic or legal purposes.

If deployment is successful, a “Honeypot Access” alert will appear in Investigations:

Permit Vulnerability Scanners

If you perform regular vulnerability scans, chances are you don’t want to receive those alerts every time. You can permit the vulnerability scanner by selecting “Close” on the alert, then by selecting “Ignore honeypot connection attempts from this asset.”

Not yet an InsightIDR user? If you’re still reeling from a previously failed SIEM deployment, InsightIDR has abstracted out all of the pain points of traditional SIEM tools (like buying and managing hardware, poor UX, and writing and tuning detection rules). Even more, it’s a cinch to deploy, as InsightIDR does all the heavy lifting and all that’s required from you is a few clicks of a button to be off the ground running. Sign up for a free trial to get up and running with InsightIDR.

Gotten a chance to read Rapid7’s Quarterly Threat Report for 2018 Q1? If not (or if you’re more of an auditory learner), we’ve put together a 6-minute recap video of the major findings. In our Quarterly Threat Reports, our security researchers provide a wide-angle view of the threat landscape by leveraging intelligence from the Rapid7 Insight platform, Managed Services, Incident Response engagements, Project Sonar, Heisenberg Cloud, and the Metasploit community.

In this Whiteboard Wednesday discussion, Kwan Lin, Senior Data Scientist, takes us through the major trends and patterns of the threat landscape in 2018 Q1. Our researchers saw three main areas of concern for the modern IT defender: user identity, DDoS, and SMB & SMI, all of which are covered in the video below.

The key takeaways from the report? The research team suggests:

Staying extra vigilant if you work in the healthcare industry—a growing target for malicious actors

Double-checking for exposed systems, given the ubiquity of threat movement and remote entry attempts

Re-training your team around the dangers of phishing to prevent credential leaks

Waves of new companies, products and applications exist, often in the form of just wedging a blockchain into an existing application or simply adding “blockchain” or “coin” strategically to an existing name.

In this paper we combine intelligence from Project Heisenberg, our global honeypot network, and Project Sonar, our Internet scanning project with data from the Bitnodes Project, which aims to study the membership of the Bitcoin peer-to-peer network, and offer a variety of our observations.

Since we began monitoring the Bitcoin network in August 2017, we observed 11,000 to 15,000 unique nodes participating in the network in any given day, and over 144,000 unique nodes since the observations began. Germany, China and the United States dominate the network.

Our honeypots are not advertised or published, so any interaction with them is suspect. In this timeframe, Project Heisenberg observed interactions on our honeypots from over 900 unique nodes known to be participating in the Bitcoin network.

Investigations into these interactions showed familiar patterns. Port scans and active reconnaissance with tools like Nmap were rampant, as was repeated attempted exploitation of MS17-010, largely from China.

Who are the perpetrators of these attacks against our honeypots? Are the legitimate owners of these Bitcoin nodes actively attacking other nodes on the public Internet? Are these systems that have been compromised and are now being used to sling exploits and mine bitcoin? We may never know, but we offer several possible explanations along with our research.

Join the block(chain) party. Check out the research report now.

The most vulnerable moment for attackers is when they first gain internal access to your corporate network. In order to determine their next step, intruders must perform reconnaissance to scout available ports, services, and assets from which they can pivot and gain access to customer databases, credit card data, source code, and more. These initial moments are arguably your best opportunities to catch attackers before critical assets are breached, but unfortunately, it can be very challenging to detect them at this stage of the attack chain.

In this post, we’ll walk you through why this is a pivotal moment and how to detect and investigate attacker reconnaissance in our SIEM solution, InsightIDR.

Reconnaissance and deception: Tracking their every move

The moment attackers gain internal network access, their next objective is to scan for promising next steps—any way that allows them to pivot toward valuable assets. Or, perhaps they’ve been able to install malware that allows for remote command and control. Either way, they’re looking for an easy way to secure privileged and persistent access to your network.

This is also the most crucial time for you to find them, when they’re exposed and before real damage is done. An increasingly popular countermeasure is to deploy deception technology, like honeypots. A honeypot is a machine that sits on your network, waiting for a connection request from an attacker. In order to lure attackers, these dummy machines may be set up with vulnerabilities or default configurations to make them an easy, appealing target.

When attackers reach out to the honeypot, either when scanning the network or attempting access with stolen/default credentials, they end up only activating your tripwire. The moment the honeypot detects a network scan, it generates an alert to your team while simultaneously misinforming the attackers, leading them to think they’re still in the system executing their plan.

To show you how this works, we’ll use our deception technology inside InsightIDR as an example. The below investigations page shows alerts generated from our deception suite, which includes honeypots, honey users, honey credentials, and honey files.

In our InsightIDR interactive product tour, you can learn about the different layers of deception, which work together to detect stealthy behaviors that often go unnoticed with log analysis alone.

Gather alerts in context

Attackers often succeed because they’re skilled at covertly sneaking in through bypassing common alert thresholds. With the rich level of data collection in InsightIDR, you’ll be able to track malicious behavior across the attack chain.

Each time you investigate an alert in InsightIDR, notable user and asset behavior is automatically highlighted so you can see what affected users were doing around the time of the alert.

In this example, a honeypot alert triggered on both March 27 and March 30. Since these alerts involved the same user, the data is automatically correlated. Here, you can see step-by-step what an attacker was trying to do, where, and when, giving you access to all notable behavior in one view. For example, you see above that a few virus alerts were triggered, as well as a connection to another country. You can also see what happened before and after each of these events to give you a more complete picture. Once the honeypot alert is triggered, this information is displayed in the visual timeline, accelerating the investigation and helping to make sense of the attack faster.

Because attackers often steal credentials and impersonate company employees (or privileged service accounts), it’s important to see activity across a user’s endpoint, network, and even cloud services. Through the user profile pages in InsightIDR, you can easily drill into any user in your organization.

Event activity, like if the user clicked on a spear phishing URL or if that user’s password was breached, is reported in the profile so you can trace back how the account may have been compromised and what happened before and after. Every employee’s behavior is automatically baselined using user behavior analytics, helping you quickly pinpoint suspicious activity that may indicate a user account has been compromised.

Profiles also include details on the user’s endpoint, which InsightIDR collects in real time via our included Insight Agent. This includes visibility into all running processes and local authentications, and helps expose insider threats and shadow IT, programs installed without IT oversight.

Generate evidence to round out your case

Like any good investigator, you need to have sufficient and accurate information in order to take action against the offender. The InsightIDR investigation interface includes an evidence pane which provides more context, such as the port, type of traffic, and IP address associated with the traffic.

Viewing data from multiple endpoints in your network helps you see the full picture, and with InsightIDR you can query your endpoints in real time, as well as search across network data and raw logs. With easy access to this information, your team can make faster, better decisions. You can see more of this in action in our InsightIDR interactive product tour.

Digging deeper with contextual data

Having the right information, presented in the right way, is the key to a fast and accurate response. An automated timeline that combines data from all endpoints and users into a single view can give you deep,rich insights that show you the who, what, when, and where of a potential attack so you can more effectively put a stop to it.

Want to start detecting and responding to attacks in your environment?

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

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. Microsoftprovided specific guidanceto customers on protecting themselves from WannaCry. MalwareTechwrote abouthow registering a specific domain name triggered a kill switch in the malware, stopping it from spreading. Recorded Futureprovided 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 byProject SonarandProject Heisenbergto measure the population of SMB hosts directly connected to the internet, and to learn about how devices are scanning for SMB hosts.

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:

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 5shows 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 6shows 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.

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.

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 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.

Attacks spotted in the wild

Yesterday, 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 Web

For 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 malware

We 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:

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:

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 innocent

Much 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 sunshine

Based 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!

]]>

(A Story by Rapid7 Labs)

Merry HaXmas to you! Each year we mark the12 Days of HaXmaswith 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

Merry HaXmas to you! Each year we mark the12 Days of HaXmaswith 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.

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.

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.

]]>

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

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.

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.

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.

]]>

Introducing Project Heisenberg Cloud

Project 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

Introducing Project Heisenberg Cloud

Project 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 automation

Heisenberg 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 methodology

Rapid7 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.

Read More

For 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.

Acknowledgements

We 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.

]]>

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.

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.

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

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 ouron-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.

]]>

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

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 Sonarperiodically 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 foundzxcvbnto 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 usat booth #4215 the RSA Conference.

]]>

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?

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:

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):

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):

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).

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!

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

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 cost

You 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:

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.

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

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 practices

About different kinds of honeypots, and which one to use for what

How to you set up a honeyclient to capture client-side attacks

How to use Cuckoo Sandbox for automated malware analysis

Here 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 Speaker

Claudio 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.