Rapid7 Blog

Networking  

Project Sonar Study of LDAP on the Internet

The topic of today's post is a Rapid7 Project Sonar study of publicly accessible LDAP services on the Internet. This research effort was started in July of this year and various portions of it continue today.  In light of the Shadowserver Foundations's recent announcement regarding…

The topic of today's post is a Rapid7 Project Sonar study of publicly accessible LDAP services on the Internet. This research effort was started in July of this year and various portions of it continue today.  In light of the Shadowserver Foundations's recent announcement regarding the availability relevant reports we thought it would be a good time to make some of our results public. The study was originally intended to be an Internet scan for Connectionless LDAP (CLDAP) which was thought to only be used by Microsoft Active Directory. This protocol uses LDAP over UDP instead of the typical TCP. CLDAP was proposed in RFC 1798 in June of 1995 but its standard was marked as abandoned per RFC 3352 in March of 2003 due to lack of support and implementation. Microsoft uses CLDAP as part of the client's discovery mechanism via LDAP Ping (additional reference). In the early phases of the study it was determined that the toolset could be used to survey LDAP over TCP and so the scope was expanded. In this document the term LDAP will used to interchangeably for both LDAP (TCP) and CLDAP (UDP). The intent of the study was to attempt to answer multiple questions: How prevalent is publicly accessible LDAP on the Internet? The term "publicly accessible" in this case means services that allow connections from and communications with our various scanners. In no case did we test with any form of authentication other than that of an anonymous LDAP bind. Can we identify the remote service and, if so, determine if Microsoft Active Directory is the only product using CLDAP protocol? Would CLDAP be an effective service in DRDoS attacks? Study implementation Like most other UDP services CLDAP will only respond to correctly formatted probes. In our study we performed service discovery using Zmap with a probe file containing a rootDSE request. This request, defined in RFC 4512 Section 5.1, is part of the LDAP protocol standard and is essentially a request for information about the server and its capabilities. The rootDSE request was chosen as the functionality should be present on all LDAP servers and, importantly, it does not require authentication by RFC definition. This reduces the legal risk of the study as no authentication mechanisms needed to be bypassed. During the study it was found that most of the LDAP responses were larger than a single packet and were fragmented in order to traverse the Internet.  Fragment reassembly functionality is not part of the Zmap use case at this time so we followed the scan with another scan against open services using a custom tool that performs a more comprehensive capture of the response. Since the protocol for communicating with Microsoft's LDAP on UDP is pretty much per RFC standard, it would make sense that any tooling that works with LDAP over UDP should also work with LDAP over TCP with minor changes. This turned out to be the case and the study was expanded to the following ports and services: Port/Proto Description 389/tcp Standard LDAP port, depending on product/config it may support STARTTLS 636/tcp LDAP over TLS 3268/tcp Microsoft Active Directory Global Catalog, may support STARTTLS 3269/tcp Microsoft Active Directory Global Catalog over TLS 389/udp Connectionless LDAP implementation for Active Directory We've performed multiple Internet wide scans on these ports as part of the study. Where possible we negotiated TLS or STARTTLS. The results published in this post are based on Internet wide IPv4 scans performed September 14th and 15th of this year. Study results Prevalence The answer to the study's first question is that there are a significant number of publicly accessible LDAP servers on the Internet. Port Responses Decoded as LDAP Percent 389/tcp 300,663 264,536 88.0% 636/tcp 91,842 72,230 78.6% 268/tcp 113,207 96,270 85.0% 269/tcp 30,199 29,668 98.2% 389/**udp** 79,667 78,908 99.0% The percentage of LDAP servers is actually slightly higher than reported. Some of the service responses that did not decode as LDAP were visually identified as fragments of legitimate LDAP responses. Service identification A significant number of services returned information that allowed us to successfully fingerprint them. This fingerprinting capability was added to the Rapid7 Recog tool which is discussed later in this post. In our data set we found that most of the LDAP services were Microsoft Active Directory Controllers (ADC) or Lightweight Directory Services (LDS) (formerly Active Directory Application Mode) Here is the breakdown of ADC and LDS services in the data set. The Samba ADC implementation has been included as well. Port Total LDAP MS ADC % MS LDS % Samba AD % 389/tcp 264,536 117,875 44.6% 4,209 1.6% 1,276 0.5% 636/tcp 72,230 37,848 52.4% 214 0.3% 1,222 1.7% 3268/tcp 96,270 95,057 98.7% 0 0.0% 1,169 1.2% 3269/tcp 29,668 28,470 96.0% 0 0.0% 1,159 3.9% 389/udp 78,908 76,356 96.8% 1,223 1.5% 1,283 1.6% It turns out that it is possible to not only identify the software in most cases, but we can usually identify the host operating system as well. In the case of Microsoft ADC and LDS services, there is almost always enough information to determine the more specific operating system version such as Windows Server 2012 R2. Most of the ADC and LDS services in the data set are running supported versions of the OS. Some are ahead of the curve, some are behind. As a note, Microsoft ended all support for all versions of Windows Server 2003 as of July 14, 2015. Product 389/tcp % 389/udp % Total AD and LDS 122,084 77,579 MS Windows Server 2008 R2 48,050 39.4% 21,309 27.5% MS Windows Server 2012 R2 35,159 28.8% 28,354 36.6% MS Windows Server 2003 15,476 12.7% 12,342 15.9% MS Windows Server 2008 12,307 10.1% 5,750 7.4% MS Windows Server 2012 10,868 8.9% 8,862 11.4% MS Windows Server 2016 224 0.2% 195 0.3% MS Windows Server 2000 0 0.0% 767 1.0% We can also identify other products, just in smaller numbers. The table below contains a few examples selected from a much longer list. Count Product Port 52,429 OpenLDAP OpenLDAP 389/tcp 13,962 OpenLDAP OpenLDAP 636/tcp 9,536 Kerio Connect 636/tcp 2,149 VMware Platform Services Controller 6.0.00 389/tcp 2,118 VMware Platform Services Controller 6.0.00 636/tcp 517 IBM Security Directory Server 6.3 389/tcp 435 Fedora Project Fedora Directory Server 1.0.4 B2007.304.11380 389/tcp 397 IBM Security Directory Server 6.1 389/tcp 248 innovaphone IPVA 636/tcp 154 Sun Microsystems Sun Java System Directory Server 5.2_Patch_6 389/tcp 148 IBM Domino LDAP Server 8.5.30 389/tcp This allows us to answer the study's second question of the ability to identify services. We can successfully do this in many cases though there is a non-trivial number of generic LDAP response returned on 389/tcp. We've also determined that Microsoft ADC and LDS aren't the only services using CLDAP as we found six instances Novel LDAP Agent for eDirectory in the data set. DRDoS utility The specific type of DDoS we are interested in was described by Rapid7 Labs researcher Jon Hart in a recent Rapid7 Community blog post: A distributed, reflected denial of service (DRDoS) attack is a specialized variant of the DDoS attack that typically exploits UDP amplification vulnerabilities.  These are often referred to as volumetric DDoS attacks, a more generic type of DDoS attack that specifically attempts to consume precious network resources. A UDP amplification vulnerability occurs when a UDP service responds with more data or packets than the initial request that elicited the response(s). Combined with IP packet spoofing/forgery, attackers send a large number of spoofed UDP datagrams to UDP endpoints known to be susceptible to UDP amplification using a source address corresponding to the IP address of the ultimate target of the DoS.  In this sense, the forged packets cause the UDP service to "reflect" back at the DoS target. Based on service responses to probes on 389/udp it would appear CLDAP does provide a significant amplification source. The UDP datagram probe that was used in the study was roughly 51 bytes.  Most of the valid LDAP responses without the headers ranged from 1,700 to 3,500 bytes. There were a few outliers in the 5,000 to 17,700 range. The chart below shows the response size distribution with the larger outliers removed. The services returning a 3,000 bytes in response data are providing a 58x bandwidth amplification factor. We didn't track the number of packets returned but using almost any reasonable MTU value will result in a packet amplification factor of 2x or 3x. Based on this finding CLDAP is effective as a DRDoS amplification source. Its utility as such will primarily be limited by how prevalent public access to the service remains over time. Study success When the study completed we were able to answer the study's primary questions. LDAP is fairly prevalent on the public Internet.  We can identify the software providing most of the LDAP services.  We were able to determine that Microsoft ADC and LDS weren't the only software providing CLDAP services though the Internet presence of others was statistically insignificant.  We were also able to determine that CLDAP could be used in DRDoS attacks if significant numbers of services remain available on the public Internet. Community contributions Rapid7 is a strong supporter of open source.  In addition to well known projects like Metasploit we also open source some of our tools and utilities. Two such tools were used in this study and have been enhanced as a result of it. Recog The initial scans provided us with a corpus of responses that we could use for generating product fingerprints. Reviewing the responses proved to be time consuming but very fruitful. The result was that Rapid7's open source fingerprinting tool Recog was updated to support LDAP fingerprints and an initial 55 fingerprints were added. Part of the update also included adding support to Recog for building fingerprints and examples with binary strings. This means that server responses can be handed directly to Recog without being processed or stripped if the fingerprint was constructed to support it. This functionality is available in the public Recog GitHub repo and gems as of version 2.0.22 which was released on August 25, 2016. DAP As part of our study process we often run the scan results through Rapid7's open source Data Analysis Pipeline (DAP) tool for data enrichment. This generally includes adding geoIP tagging and protocol decoding if appropriate. DAP can also leverage Recog's version detection for determining the remote service's product, version, and/or operating system. Part of this study included adding support for decoding LDAP protocol responses to DAP. It will now decode a properly formatted LDAP response into a nested JSON structure. This functionality is available in the public DAP GitHub repo and gems as of version 0.0.10 which was released on August 2, 2016. Example In the example below DAP is handed JSON formatted data that contains an IP, a base64 encoded server response, the port, and protocol. It returned additional data including version detection (dap.recog..), decoded LDAP response (data.SearchResultEntry…., data.SearchResultDone), and geoIP information (ip.country…, ip.latitude, ip.longitude). At the end the jq utility is used to improve the readability of the result. Command bash echo '{"ip": "66.209.xxx.xxx", "data": "MDACAQdkKwQAMCcwJQQLb2JqZWN0Q2xhc3MxFgQDdG9wBA9PcGVuTERBUHJvb3REU0UwDAIBB2UHCgEABAAEAA==", "port": 389, "proto": "tcp"}' | \ bin/dap json + \ transform data=base64decode + annotate data=length + \ recog data=ldap.search_result + \ decode_ldap_search_result data + \ remove data + geo_ip ip + \ geo_ip_org ip + json | jq Result { "ip": "66.209.xxx.xxx", "port": 389, "proto": "tcp", "data.length": 64, "data.recog.matched": "OpenLDAP", "data.recog.service.vendor": "OpenLDAP", "data.recog.service.product": "OpenLDAP", "data.SearchResultEntry": { "objectName": "", "PartialAttributes": { "objectClass": [ "top", "OpenLDAProotDSE" ] } }, "data.SearchResultDone": { "resultCode": 0, "resultDesc": "success", "resultMatchedDN": "", "resultdiagMessage": "" }, "ip.country_code": "US", "ip.country_code3": "USA", "ip.country_name": "United States", "ip.latitude": "36.xx", "ip.longitude": "-115.xxxxxxxxx" } This is one of the simpler examples. The responses from Active Directory Controllers contain significantly more information. Final thoughts The results from the study were able to successfully answer the original questions but prompted new ones. Fortunately there is quite a bit of information that remains to be extracted from the data that we have. It is likely that there will be multiple future blog posts on the data, the software and versions identified in it, and information about the individual hosts that can be extracted from it. Unlike other studies that Project Sonar publishes on Scans.IO, we have not yet made these data sets available. For those of you that are concerned that your network may be exposing LDAP services I recommend the following: If your organization is a service provider or a company with assigned ASNs you can sign up for free Shadowserver reports. The Shadowserver Foundation scans the Internet for certain services of concern, such as those that could be used in DDoS, and will provide regular reports on these to network owners. Last week they announced support for discovering and reporting on CLDAP. Use an external service, such as the Rapid7 Perimeter Scanning Service, or an externally hosted scan engine to perform scans of your Internet accessible IP space. Ensure that the ports listed above are included in the scan template. This will provide a more accurate picture of what your organization is exposing to the Internet than that provided by an internally hosted scanner. Review firewall rules to determine if any are overly permissive. As always, if you are interesting in having Sonar perform additional relevant studies, have interests in related research, or if you have questions, we welcome your comments here as well as by reaching out to us at research@rapid7.com.

Rapid7's Data Science team, Live! from SOURCE Boston!

Suchin Gururangan and I (I'm pretty much there for looks, which is an indicator that Jen Ellis might need prescription lenses) will be speaking at SOURCE Boston this week talking about "doing data science" at "internet scale" and also on how…

Suchin Gururangan and I (I'm pretty much there for looks, which is an indicator that Jen Ellis might need prescription lenses) will be speaking at SOURCE Boston this week talking about "doing data science" at "internet scale" and also on how you can get started doing security data science at home or in your organization.  So, come on over to learn more about the unique challenges associated with analyzing "security data", the evolution of IPv4 autonomous systems, where your adversaries may be squirreled away and to find out what information lies hidden in this seemingly innocuous square:

[5 Min Demo] Expose Risky User Behavior from Endpoint to Cloud

How much visibility do you have across your network today? Today's security teams use sophisticated tool stacks, but siloed solutions cannot cover the sprawling network ecosystem of endpoint, network, and cloud services. Big data solutions are capable of flexible integrations, but struggle with identifying stealthy…

How much visibility do you have across your network today? Today's security teams use sophisticated tool stacks, but siloed solutions cannot cover the sprawling network ecosystem of endpoint, network, and cloud services. Big data solutions are capable of flexible integrations, but struggle with identifying stealthy attacks (e.g. compromised credentials & lateral movement) without a waterfall of false positives.In addition to helping detect and investigate outside attacks, UserInsight sheds a spotlight on your internal behavior. By correlating all network activity to the users behind them, we automatically identify your riskiest users so you can proactively follow-up.Related Resource: Download our beginner's guide to User Behavior Analytics with UserInsight ToolkitEvery day, notable behavior happens in your organization. There is always someone with the highest firewall traffic, or a first time administrative action, or a new log-in to an asset. However, these anomalies are useless without context, as 99% of this behavior is legitimate activity. Therefore, we don't generate incident alerts for these – our customers only receive a handful of incident alerts, things they want to know about. However, these notable behaviors can be correlated to identify attacks and add context to incident investigations.Beyond users, UserInsight helps identify security risks such as unknown administrators, shared accounts, accounts with non-expiring passwords, and even Shadow IT – unauthorized cloud services and process hashes on your endpoints. See how you can expose risky user behavior with this 5-minute Demo Video: For more on User Behavior Analytics, we recommend the Gartner Market Guide, which recommends, “Use User and Entity Behavior Analytics to detect insider threats and external hackers.” Get the report here.

The End Of The Internet

On Sept 24th, ARIN announced it had finally run out of IPv4 addresses. The open pool of IPv4 addresses is now gone, and the only way to get them now is via a transfer from another party who owns them or IP ranges which are…

On Sept 24th, ARIN announced it had finally run out of IPv4 addresses. The open pool of IPv4 addresses is now gone, and the only way to get them now is via a transfer from another party who owns them or IP ranges which are returned to ARIN. The switch to IPv6 is imminent. Once switched, the number of available public addresses available will be roughly 4.2 x 10^37. This will be more than capable of handling our need for interconnection for decades. What Does This Announcement Mean? This means we have reached the limit of what 32-bit addressing can give us, about 4.2 billion things. The projections on Internet Of Everything devices however number 25 billion by 2020. This means that we will likely be playing a shell game for a while of using the open IPv4 addresses while trying to build and deploy IoE devices at breakneck speeds. But eventually, we hit a wall. Where Did All The IPv4 Space Go? By 1995, the last restrictions on using the Internet to carry commercial traffic were lifted, allowing for the emergence of the modern day internet, which continues to evolve. Likely in anticipation of this, the Department of Defense becomes the owner of the largest number of IPv4 addresses, with over 218 million usable. This is just over 5% of the total IPv4 addressable space. The rest of it is used by innovations within an information revolution, which we are currently (still!) in the middle of. Globalization, commercialization, e-business and mobile technologies are the biggest drivers of IP use. Innovations like cloud computing, the Internet Of Everything, and a voracious appetite for data all lead to the inevitability of using up a finite resource. How Should Organizations Proceed? The most obvious answer is making the switch to IPv6 as soon as possible. But, the switch to IPv6 is not easy, and many companies have not even started. Adoption is slow and no one is yet ready to “turn off” IPv4. That's going to take a lot of agreement among a lot of people. Just a few of the issues at risk are software compatibility, replacement costs of hardware, and ease of use/deployment based on current skill and knowledge. The DoD started working on an IPv6 implementation in 2003. They sought to demonstrate IPv6 viability for all network backbones by 2008, and implement. Of course it took until 2012 for the government to decide it had met the initial goals! But the point is, they had proven IPv6 is viable, and then they disabled the functionality. So the DoD backbones still use IPv4, which is more limited, hampers their innovation and impacts the DoD's very specialized version of the Internet of Everything. As software consultants, we will often cite IPv6 as a security concern and suggest that organizations disable IPv6 services. This is not because we think IPv6 is less secure. We understand that organizational maturity is a key factor in securing an enterprise of any size, and complications with understanding and managing IPv6 increase the attack surface for threat actors. It's simply too large a negative risk to manage and secure IPv4 and IPv6 in parallel. Until the entire enterprise is ready to make the switch, which for some could take many years, we will continue to recommend this. It's estimated that 15%-20% of allocated IPv4 addresses are not being utilized. That means the shift to larger spaces will likely take some time. It also opens up the possibilities of IPv4 marketplaces, similar to what we have today with domain names. ARIN has already said they will not limit the number of transfer requests as of Sept 24. The DoD might also start releasing unallocated space back if they make the full switch to IPv6. This would breathe some limited life into the kicking corpse of IPv4. Unfortunately, none of this is optimal, and certainly not desirable. But there is hope. Requirements to be “IPv6 ready” have been in place for all systems being placed on the DoD networks, including commercial products, for quite some time. This has spurred a number of organizations to work towards this goal in order to keep their business relationships with the DoD. In this regard, the DoD actually inspires change and progress to be made. We just need now to lead a charge to make the switch in the commercial industrial space. The Next Steps The right thing is to start planning your IPv6 transition now. First and foremost, start documenting your network requirements. For any organization which seeks to increase its maturity we find a lack of documentation being the biggest contributing factor to security posture. Organize your network assets, classify them using a simple classification scheme, and identify which assets are IPv6 ready. For the ones that are not, make sure that your equipment refresh plans include IPv6 support. Also ensure your current and future purchase pans include this. Document your IPv6 allocated and unallocated space, to prepare your addressing plan. This will be instrumental in helping you make the transition when you are ready. Educate yourself on IPv6! The assumptions of IPv4 do not always exist in IPv6. Work with your providers on IPv6 requirements. They need to support it, and they need to support you. Test your plans and assumptions! Monitor for reliability and performance – in test and production Advertise in DNS by updating with AAAA records pointing to IPv6 addresses For more information on making the switch to IPv6, TeamARIN has some great information and resources for you. This post was co-authored by Joel Cardella and Cindy Jones. You can reach us on Twitter at @JoelConverses and @SinderzNAshes. EDIT: Corrected Cindy's twitter handle!

The real challenge behind asset inventory

As the IT landscape evolves, and as companies diversify the assets they bring to their networks - including on premise, cloud and personal assets - one of the biggest challenges becomes maintaining an accurate picture of which assets are present on your network. Furthermore, while…

As the IT landscape evolves, and as companies diversify the assets they bring to their networks - including on premise, cloud and personal assets - one of the biggest challenges becomes maintaining an accurate picture of which assets are present on your network. Furthermore, while the accurate picture is the end goal, the real challenge becomes optimizing the means to obtain and maintain that picture current. The traditional discovery paradigm of continuous discovery sweeps of your whole network by itself is becoming obsolete. As companies grow, sweeping becomes a burden on the network. In fact, in a highly dynamic environment, traditional sweeping approaches pretty quickly become stale and irrelevant.Our customers are dealing with networks made up of thousands of connected assets. Lots of them are decommissioned and many others brought to life multiple times a day from different physical locations on their local or virtual networks. In a world where many assets are not 'owned' by their organization, or unauthorized/unmanaged assets connect to their network (such as mobile devices or personal computers), understanding the risk those assets introduce to their network is paramount to the success of their security program.Rapid7 believes this very process of keeping your inventory up to date should be automated and instantaneous. Our technology allows our customers to use non-sweeping technologies like monitoring DHCP, DNS, Infoblox, and other relevant servers/applications. We also enable monitoring through technology partners such as vSphere or AWS for virtual infrastructure, and mobile device inventory with ActiveSync.. In addition, Rapid7's research team through its Sonar project technology (this topic deserves it's own blog) is able to scan the internet and understand our customer's external presence. All of these automated techniques provide great visibility and complements the traditional approaches such that our customer's experiences on our products revolves around taking action and reducing risk as opposed to configuring the tool.Why should you care? It really comes down to good hygiene and good security practices. It is unacceptable not to know about the presence of a machine that is exfiltrating data off of your network or rogue assets listening on your network. And beyond being unacceptable, it can take you out of business. Brand damage, legal and compliance risks are great concerns that are not mitigated by an accurate inventory alone, however, without knowing those assets exists in your network in a timely manner it is impossible to assess the risk they bring and take action.SANS Institute has this topic rated as the Top security control https://www.sans.org/critical-security-controls/control/1. They bring up key questions that companies should be asking to their security teams: How long does it take to detect new assets on their networks? How long does it take their current scanner to detect unauthorized assets? How long does it take to isolate/remove unauthorized assets from the network? What details (location, department) can the scanner identify on unauthorized devices? and plenty more.Let Rapid7 technology worry about inventory. Once you've got asset inventory covered, then you can move to remediation, risk analysis, and other much more fun security topics with peace of mind that if it's in your network then you will detect it in a timely manner.

The Black Hat Attendee Guide Part 5 - Meaningful Introductions

If you are just joining us, this is the fifth post in the series starting here. Making An Introduction I might be wrong, but I'll argue that networking is a transitive verb, so ENGAGE! The real magic starts happening as you progress: Level 1-- Start…

If you are just joining us, this is the fifth post in the series starting here. Making An Introduction I might be wrong, but I'll argue that networking is a transitive verb, so ENGAGE! The real magic starts happening as you progress: Level 1-- Start with a “Hi, my name is… ” Yes, it's that simple, thanks to Slim Shady Level 2-- Demonstrate that you have an idea of the world the other person lives in, their passions and interests Level 3-- Make a meaningful (and unforgettable) introduction Connecting people is like a sport for me, and I enjoy it immensely. A good introduction might be the most wonderful gift you can give someone, I have been so endeared to those giving a graceful introduction. There is a fine line between grace and flattery (i.e., an unfounded and disingenuous compliment), so get it right, keep it real… or go so completely tangential—they'll laugh as you run off to your pressing appointment. Introductions serve a purpose, the motivation should be self-evident when you are done. I see the introduction as an event: You are investing energy and excitement into the lives of two people, regardless of how well you know them, or may be walking someone through the door of opportunity, changing their career path forever. Make it a point to use people's names when connecting them. Make sure you're pronouncing their name correctly—never be afraid to ask, laughably mispronounce, or politely reaffirm if you're not sure! There is a chance they've already met and know each other well and you're new to the party. Flipside, perhaps they've met and maybe don't remember each other's names (I'm THAT guy!). I'd recommend starting off with an “oh dear—Jim, have you met Ryan?” It's a safe tactic: You'll know instantly where you stand, and whether or not to charge into introductions. Sometimes you have to neutralize an awkward air because someone is standing too close, maybe that killed a serious and sensitive conversation that was happening, so be aware of that when you approach. I have a specific and reckless strategy, unapologetically stolen and adapted from my good friend Quinton Jones—he's something of a Yoda figure in my world who is basically a genius at this kind of thing. Quinton's guidance might be summarized as follows: Check your brain at the door. Analysis paralysis is a conversation killer, doubly so when surrounded by introverts at Black Hat!  How? (See this post.) Say hello, and be slow to judge. Question, if not flat-out ignore convention, find comfort knowing that we all say stupid stuff. Ignore the mechanics, feed on the excitement of their world! Speak from the heart, try to meet people where they are. Be genuine, be real, and be sensitive to the world/stress/distractions/interest of the folks standing before you. In brokering an introduction, get their attention, be memorable, build intrigue ... or offer a bold-faced lie—more than memorable, be unforgettable! Never be guilty of the bland, one-sentence email intro… this is almost unforgivable in person. _YAWN_ If you can't find the angle, go hyperbolic and be obvious about it! Your introduction will address these three key questions: 1) What do I need to know? A decent introduction must cover these basics at an absolute minimum. Who is this person, what is their name, how did you meet them? Where are they from, what do they do? This could be their job, their field of expertise, a challenge they're exploring at the show, tech needs they have, positions they are hiring for, hobbies the other person may find interesting, or how amazing their BBQ is 2) Why do I care? A proper introduction will give the introducees some context to help ensure it doesn't die the second you leave, as well as to help all parties remember each other a little better in the long-run. They'll care, even if only a little bit, because they respect you, and they're being polite Perhaps they are both from the same tribe (appsec, pen testing, etc), heading for the same talk, looking to hire similar people, or have a common passion 3) What do you need from me? A really damn good introduction will have a call to action, setting conversational wheels in motion. “You two should discuss ” “Look, we just met, and this is my best friend, they're my favorite human on this planet, so make nice!” “One of you had an amazing perspective on something from this talk or booth we saw, or you destroyed the lab in this workshop -- tell us again!” WOW! This person is cool, now what? At some point, you'll get introduced to someone amazing. Sometimes a card exchange is customary. You've got a fleeting moment to anchor that connection when appropriate, so have a plan to connect with them again via: Twitter Tweets and DMs make a great way to track folks down or invite them to gatherings later. A quick “@username Nice chatting with you about $topic today” can do wonders in keeping that conversation--and relationship--going. And serve as a handy reminder about who you just met. Please consider putting a real face as your avatar (even if only during the event.) Put a link in there to your LinkedIn profile. @Gabe Bassett has some great thoughts on using Twitter in InfoSec LinkedIn Seriously, you should have a real profile, with a real picture. Seriously. This page serves as a living CV/resume, so treat it with that same level of seriousness and respect. Phone numbers It's kinda old-school, but it's a thing that won't go away. Some folks will have burner phones for the week, so make sure you know how to track them down in the longer term. Pro-Tip: On my iPhone, I have a ‘Trey Ford' entry with my contact information—work and personal email, phone, address, etc—that I can just tap “Share Contact” and send it on its way. If you have an iPhone, it saves time typing in all your info. Email. (Duh!) Business Cards Approximately the worst option, but it is a formal tool. Stop and write (on the card) how you met, and DO SOMETHING WITH IT to follow up before you misplace that card. (I am still guilty of this, striving to improve.) Just to be thorough, let's cover points of performance for introductions to an audience: You don't use the person's name until the very end. Period. You are building energy up to this point. Do not cover the speaker's material, but rather why you are excited to hear them. Share how the speaker is uniquely qualified or positioned to provide meaningful perspective. Share a brief anecdote or story about the person, their achievements or credentials. Be positive, and build the energy all the way up to: “Join me in welcoming Herbert OZWOLDO BLUMPERFARKEN!!!” (or somesuch) Did that feel like a non-sequitur? Good. I've wrecked a mess of public introductions, so this is my penance, I think everyone should know Dale Carnegie's recipe for public speaking introductions… you'll know if Black Hat proctors took note. Parting Shots Black Hat USA attendance is a serious commitment and investment. Come well-rested, well-groomed, and well-prepared to meet some amazing people. Be deliberate in your time and interactions, try to manage your energy levels. Bring your very best. As always, I welcome additions, edits and feedback—comment here or say hi on Twitter! ~@treyford Continue on to Part 6 of this series: The Sponsor Hall, Arsenal & more ...Or go back and read Part 4: Talking to the Media & Press Want more? You can read the rest of the Black Hat Attendee's Guide series here.

The Black Hat Attendee Guide Part 3 - Networking Like A Boss

If you are just joining us, this is the third post in the series starting here. Networking Like A Pro Black Hat will clear 9,000 attendees this year, and it is really easy to feel really small in a crowd that big. The vast…

If you are just joining us, this is the third post in the series starting here. Networking Like A Pro Black Hat will clear 9,000 attendees this year, and it is really easy to feel really small in a crowd that big. The vast majority of folks you'll see there will only know a few people at the show—it is your duty to change that for them. This blog post won't make you the best conversationalist at the conference, but it should be enough to get you off the bench and into the game. Let me expound: As geeks, we have a time honored tradition and reputation to uphold, that of culturally-sensitive, socially-aware, well-groomed, charming, and social creatures. No? Not yet? We will, come the first week of August this year. If you are attending Black Hat, you are in the hottest, most-sought-after, and one of the best-paid verticals in modern history. Next time you meet some random Joe and let slip you work in “cyber security,” just listen to them prattle on about how important that work is, and how badly we need to be successful. Boardrooms are paying more attention now than ever. As a Black Hat delegate, you stand on the shoulders of giants, reaping the fruits of a hard working community, representing a profession in high demand that's racing to mature. You are our diplomats and emissaries for security, research, and hacking. Much of the general public still sees our work as a dark art and witchcraft, your decisions and actions are critical to winning hearts and minds. Nearly Zero Unemployment. Think on that for a moment. Not only have the unemployed worked themselves into breathtaking niches, our profession cannot recruit, train, and groom talent fast enough. Everyone, ABSOLUTELY EVERYONE you will meet at the show is tied to the recruiting force, and only a handful of those folks have been in their jobs or at their current company for more than 5-7 years. Let me be clear - I am not telling you to find a new job. Unless you want one We all have roles our teams that need to be filled, or have friends with specific needs. Even if you're not looking, still make a point to meet people, and help connect them to others. So, in light of that: Be a connector. So almost every company is hiring for something, we get it. The magic is the people, and everyone has a story: Many are looking for jobs, while others are looking for a way to get started. Some of the folks you meet love their jobs, others are mastering challenges they face, or are the verge of giving up. Others will be running low on life, beat down in their world, and have come to have their cups refilled by the energy and excitement of the community and breaking research. Be a connector, not match-maker. If you're hanging with a group, and have a discussion in play, pull the lurkers in. Peel off, say hi, ask where they're from. (“Hey! We're discussing — care to join us?”) As mentioned above, everyone you will meet has a story. Let's be honest though: We're at Black Hat. People are afraid of the wireless, debated bringing a pencil and paper instead of mobile hardware, and are looking at everyone as though they're some kind of double agent looking to steal corporate secrets or passwords from them. Take a deep breath. Most of the APT buzz you're hearing is out on the vendor floor, you can spot the offending booths. Some of the folks you'll meet have real war stories from engagements with a determined adversary, others are telling tall tales, while some are running you through a Kobayashi Maru (like it or not), which may be an interview, so play nice! Respect OpSec. People may not want to talk about their employer, or they may not be comfortable with the idea. Spoiler alert: Real spooks at the show aren't going give you the “if I tell you, I'd have to kill you” line with their best “1,000 yard stare.” They'll have a cover story, and it'll be a simple one. That said, lots of cool people work for HUGE companies, that as a matter of public policy “do not send their people to Black Hat or DEF CON”— and that's a tough spot to be in. Here they are, they may have fought to get here, might have paid their own way (!!!) — and they very simply can't tell you where they work, or what they do, and they feel ridiculous saying that. Even more painful for these kindred souls, they may not even have an explanation why corporate overlords have that policy. Amazing job, strong budget, interesting problem space … and the occasional policy that makes zero sense. It happens. Be aware of special situations around corporate growth. Some startups are still in stealth mode, others may be approaching an S-1 filing, while others work for visible companies that may have a legal requirement to keep quiet after an IPO, merger, or acquisition. Watch for the awkward smile or brief “thanks” or “we are excited” response — some topics, for reasons that can't be discussed, are off limits. Be aware of corporate relationships, and the occasional slip-up. Companies may be consulting, partnering, customers or service providers, and that may all be under NDA. Just because you know what's going on doesn't mean it is your business to disclose. Look for those edge cases, and try to make life less awkward for them. Respect the rules of OpSec others may follow (even if against their will,) and try to warm things up. Be aware of human factors: People are jet lagged, sleep deprived, …hung over, stressing about a presentation or a meeting, afraid of large crowds, or are actively avoiding you because you forgot to brush your teeth or put on deodorant (don't be that guy!) Start Small. My advice is to not start with “hi, where do you work” or “what do you do?” It's a trap. Earn permission, and think of this as building social context or relational capital. We're all excited, and we're extremely passionate about our chosen profession… but we're not giving it all away up front. It may be a waste of your time and mine to get into that, or you have somewhere to be, or as mentioned in the above section, these questions could be minefields anyway. Polite company will find common ground, and start neutral: Where are you from? When did you get in to Las Vegas? What's the best session you've seen? Which session are you looking forward to most? What brings you to Black Hat this year? How long have you been attending Black Hat? Did you come here with a team or group? It's kind of unavoidable: The conversation will wander into our chosen profession, which is ultimately why you are in the desert this week, hiding from the angry and unforgiving Las Vegas sun. Offering up some of the answers to these questions before asking creates context and offers a safer conversational space. How long have you been in InfoSec? What line of work are you in? What would you consider your speciality? Is that what you do for your day job, or is that something you're looking to do more of? For many of you, this is kinda obvious. If you're Canadian, you learned this by third grade… I was home schooled, so someone had to explain this to me. And in any case, even if it's new to you — that's okay too! Consider me passing these random thoughts forward. Connect the Dots. I remember as a kid, my pastor always saying it isn't always what you know, but who you know. There's something to that. As you meet people, be present. The magic of events like Black Hat is the people, and you will miss out if you aren't tuned in. Slow down the mental hamster wheel and stay focused in the here and now. What happened in history, or what happens later today doesn't matter. As Gavin de Becker says, “Now is the only time anything ever happens—now is where the action is.” Strive to really connect with the neat people you meet. Identify their interests and passions, get to know them, and start building a network. When I started traveling, I learned it was better to be somebody somewhere rather than a nobody everywhere. A big conference with 9,000 humans is less intimidating when you recognize a few faces in the crowd. Where and when does this happen? Right now, right where you are! (Bathrooms notwithstanding.) In the elevator Standing in line Coffee Lunch Waiting for a session In the booths on the vendor floor If you are sitting next to a human (and the talk hasn't started) say hello! As you find people of your tribe, introduce them to each other. Don't slack here. If you're more comfortable online/on social networks than in person, you'd be surprised how often you will find folks in your chosen sessions that you've interacted with on Twitter. And by the way, meeting IRL— especially after chatting for 10 minutes, only to realize you kind of already know of each other — is kinda magical. Sidenote: The persona you have in your head for that cyberspace personality won't always match the meatspace version, and bridging that gap can make for some interesting moments. image credit: http://comicalconcept.com/illustrations/the-facebook-you Ignore the nervous reflex to check your phone or scan Twitter. Stay present, stay put. To quote egyp7, "never leave a hallway conversation you know is good for a talk that might be." There's so much more to networking at Black Hat that I didn't want to cram it all into one post, so we'll continue this thread part five, which will be all about the Art and Science of Making Introductions. So come on back here tomorrow for more on that -- same Bat-Time, same Bat-Channel. As always, I welcome additions, edits and feedback - comment here or say hi on Twitter! ~@treyford Continue on to Part 4 of this series: Talking to the Media & Press ...Or go back and read Part 2: Getting the Most Out of Black Hat Briefings Want more? You can catch all the entries in the Black Hat Attendee's Guide series right here.

2015: Project Sonar Wiki & UDP Scan Data

Project Sonar started in September of 2013 with the goal of improving security through the active analysis of public networks. For the first few months, we focused almost entirely on SSL, DNS, and HTTP enumeration. This uncovered all sorts of interesting security issues and contributed…

Project Sonar started in September of 2013 with the goal of improving security through the active analysis of public networks. For the first few months, we focused almost entirely on SSL, DNS, and HTTP enumeration. This uncovered all sorts of interesting security issues and contributed to a number of advisories and research papers. The SSL and DNS datasets were especially good at identifying assets for a given organization, often finding systems that the IT team had no inkling of. At this point, we had a decent amount of automation in place, and decided to start the next phase of Project Sonar, scanning UDP services.While we received a few opt-out requests for HTTP scans in the past, these were completely eclipsed by the number of folks requesting to be excluded after our UDP probes generated an alert on their IDS or firewall. Handling opt-out requests became a part-time job that was rotated across the Labs team. We tried and often succeeded at rolling out exclusions within a few minutes of receiving a request, but it came at the cost of getting other work done. At the end of the day, the value of the data, and our ability to improve public security depended on having consistent scan data across a range of services. As of mid-December, the number of opt-out requests has leveled off, and we had a chance to starting digging into the results.There was some good news for a change:VxWorks systems with an internet-exposed debug service have dropped from a peak of ~300,000 in 2010 to around ~61,000 in late 2014Servers with the IPMI protocol exposed to the internet have dropped from ~250,000 in June to ~214,000 in December 2014NTP daemons with monlist enabled have decreased somewhere between 25-50% (our data doesn't quite agree with ShadowServer's)The bad news is that most of the other stats stayed relatively constant across six months:Approximately 200,000 Microsoft SQL Servers are still responding to UDP pings and many of these are end-of-life versionsOver 15,000,000 devices expose SIP to the internet and about half of these are from a single vendor in a single region.One odd trend was a consistent increase in the number of systems exposing NATPMP to the internet. This number has increased from just over 1 million in June to 1.3 million in December. Given that NATPMP is never supposed to be internet facing, this points to even more exposure 2015.We conducted over 330 internet-wide UDP scans in 2014, covering 13 different UDP probes, and generating over 96 gigabytes of compressed scan data. All of this data is now immediately available along with a brand new wiki that documents what we scan and how to use the published data.2015 is looking like a great year for security research!-HD

Top 3 Takeaways from the webcast "2015 Security Outlook: See How your Security Program Measures Up"

As 2014 comes to an end, you might be putting the finishing touches on your 2015 security plan, or perhaps you haven't even started yet. Whatever the case may be, if you didn't catch the 2015 IT Security Outlook Rapid7 webcast yesterday - you are…

As 2014 comes to an end, you might be putting the finishing touches on your 2015 security plan, or perhaps you haven't even started yet. Whatever the case may be, if you didn't catch the 2015 IT Security Outlook Rapid7 webcast yesterday - you are in luck! Read on for my top takeaways from the webcast, but if you want to see it now, you can watch the webcast on demand now.Thanks to our  panel - Rapid7's expert Strategic Services team (Nicholas J. Percoco, Wade Woolwine, and Maranda Cigna) who presented their findings on the top tactics and strategies being implemented by best in class organizations in 2015.  Here my Top 3 Takeaways on what to account for in your 2015 security planning:Attacker Behaviors: Know thy enemy! - A lot of companies seem to solely pay attention to what the media tells them is their enemy and not spending enough time investigating who is attacking them and why. Nick puts an emphasis on the need to know your attacker and find out what data is valuable to them. As Wade points out, Malware and tools will change, attacker behavior won't. Once you have that information, you will be better equipped to fill in the gaps in your security program. Prepare for a Long Term Outlook – Rome wasn't built in a day and neither will your security program be! Nick advises not to rush things, it takes several years to build a mature program. Where to start? Get the basics started today, be innovative tomorrow, and be sure to vet and review your program once a year to ensure that you're keeping up with attackers and technology. Wade advises that you rehearse, rehearse, rehearse, this will help you to perfect your security program over time and help to highlight your company's capabilities and deficiencies.Top Down vs Bottom Up Approach – In the past, companies traditionally run an annual pen test discovering vulnerabilities and remediating any issues that pop up, repeating the tactic year over year in a patch and remediate cycle. The problem is that this doesn't cover all of the systemic and pervasive issues that arise. Pen testing is important, of course, but measuring your security effectiveness and identifying your gaps is better done if you evaluate your security controls and schedule regular assessments. This helps get at the root of the cause and helps to cut down on associated costs of reoccurring issues. To learn more about 2015 security strategies - view the recording of his webcast on demand now!To learn more about our Strategic Services Team and offerings click here!

Securing DevOps: Monitoring Development Access to Production Environments

A big factor for securing DevOps environment is that engineers should not have access to the production environment. This is especially true if the production environment contains sensitive data, such as payment card data, protected health information, or personally identifiable information because compromised engineering credentials…

A big factor for securing DevOps environment is that engineers should not have access to the production environment. This is especially true if the production environment contains sensitive data, such as payment card data, protected health information, or personally identifiable information because compromised engineering credentials could expose sensitive data and lead to a breach. While this requirement is a security best practice and has found its way into many compliance regulations, it can be hard to enforce the strict division of church and state when you are running a high velocity operation with many releases per day and frequent changes to code and systems. Set up alerts for zone policy violations One way to help manage this risk is to set up zone policies and monitor if they are being violated. For example, you define a certain zone as the production zone and then create a network policy that the engineering team is not authorized to access this part of the network. Implementing this may be challenging in some environments, but it's actually very easy in UserInsight, Rapid7's user behavior analytics and incident response solution. How to monitor for zone policy violations in UserInsight Setting up a network zone policy in UserInsight is very easy. From the UserInsight dashboard, choose Settings in the top menu and then select Network Zones in the left menu. Click the Add Zone button and define the zone you'd like to monitor. Next, click on Network Policies in the left menu. Enter the name of the Active Directory group for your developers and define that they cannot access the production environment zone. If anyone violates this rule, you'll be alerted on the UserInsight dashboard, on the Incidents page, and you'll receive a notification by email. In this example, we see that user vgonzales violated this policy 100 times. Simply click on this incident alert or on the name to dig in deeper and get more context around this user. If you'd like to get a personal, guided demo of UserInsight or set up a proof of concept in your environment, please provide your details on the demo request page.

UserInsight Detects Network Zone Access Violations

Information security regulations are often vague and open to some interpretation, but one common theme across most is that you need to separate the systems with critical data from the rest of your network. The vast majority of employees in your organization should never have…

Information security regulations are often vague and open to some interpretation, but one common theme across most is that you need to separate the systems with critical data from the rest of your network. The vast majority of employees in your organization should never have access to systems that:process or store payment card data -- PCI DSSqualify as Critical Cyber Assets (i.e. have a role in the operation of bulk power systems) -- NERC CIPprovide services not needed for internal business use -- FISMAprocess or store protected health information (PHI) -- HIPAATo summarize: whatever data you consider valuable to attackers should be kept in segments of your network that only a small, qualified group of individuals can access. This makes sense, but is it that easy?The challenge of monitoring network zonesIf network segmentation were simple, the past twelve months wouldn't have seen numerous breaches where a third-party vendor's credentials were used to access the network and begin moving from system to system until the valuable data was reached and the exfiltration process begun. Unless your organization has gone through the significant effort tobuild an air-gapped network that is physically separated from the less secure portion of your network, restricted zones are connected to unrestricted zones with controls used to prevent unauthorized access, be they firewalls, access control, or a number of other options. This means that you don't have the benefit of an impenetrable wall between the critical servers and the computers on which your summer interns are watching John Oliver clips on Youtube.Getting exactly what you need from an array of controls is very challenging because of the many exceptions that are made over the course of a year. More rules are created for firewalls between zones, more users are added to the privileged groups, and more software solutions in the protected network zones need access to the outside Internet for updates. Quickly, the benefits of segmenting your network begin to fade because it becomes a challenge to know exactly who can access it and how. This often means that the perfect-world impenetrable wall more closely resembles a beaver dam: it greatly reduces the flow to your protected zone, but it would be a challenge to predict exactly what will and will not get through.UserInsight can help you detect network zone violationsSome of our customers explained this challenge to us and asked to simply be alerted when zone policies are violated. So, as is our way, we built a simple solution for this: just tell us the simple IP address ranges that makes up your zones to monitor and tell us which user groups can or cannot access it.If one of your developers is accessing the production zone, we will immediately alert you.If someone steals credentials belonging to a user outside the small group permitted to access the protected zone and tries them there, UserInsight will trigger one of our infrequent alerts like you see above.Alternatively, if you want us to profile access to the critical assets in this zone and detect a change in behavior for the individuals that should be accessing them, you can tag these asset as critical. The first time your permitted users access the critical assets, you tell UserInsight that they are allowed to do so. We will continue to list any access made to the critical asset, but won't alert you again until they come from a different place.In this alert, we are letting you know that, while Sara Hughes has legitimately used this administrator account before to access the critical asset, she has never done it from this shared asset or her user endpoint. Either access could represent an insider or intruder stealing her credentials and using them to authenticate to this asset used to process or store valuable data.If you would like to hear more about detecting unwanted access to the protected areas of your network, you can register for a free, guided demo of UserInsight.

Weekly Metasploit Wrapup: SQL Server Privileges, Templating New Modules

Microsoft SQL Server Pen-Tester Pro Tip This week, we've landed a trio of fun and interesting modules from long-time Metasploit community contributor Scott nullbind Sutherland which automate up a couple Pro Tips on what to do when you've scored a login on a Microsoft SQL…

Microsoft SQL Server Pen-Tester Pro Tip This week, we've landed a trio of fun and interesting modules from long-time Metasploit community contributor Scott nullbind Sutherland which automate up a couple Pro Tips on what to do when you've scored a login on a Microsoft SQL Server during a penetration test. One of these is a method to escalate the privileges of a SQL Server user. Oftentimes, when a pen-tester discovers a valid credential for an MSSQL server, she will check if it's an administrator account; otherwise, it'll go on in the "other discovered credentials" section of the report, and that will be that. Not so fast! Turns out, MSSQL provides some built-in privilege escalation functionality via the IMPERSONATION privilege, and Scott has automated out the procedure to a) check if the current user can impersonate any other user, and if so, b) pick out a user that already is sysadmin. Therefore, the enterprising penetration tester now has a quick and easy way escalate a ho-hum, boring user to an exciting and dangerous sysadmin-level user, opening up what might have been an overlooked post-exploitation path. Now, this is not a bug or a backdoor or anything like that; it's normal functionality, but it might be missed by a standard (if naive) audit of user permissions. It's this kind of domain-specific knowledge of a particular application that makes contributor-sourced Metasploit modules so valuable -- Scott has effectively trained everyone who uses Metasploit to look for this potential exposure in Microsoft SQL Server merely by publishing a module that not only makes it easy to discover, but explains exactly what it's doing along the way. As an added bonus, we also have a version of the module that does the same thing, but over SQL injection via a vulnerable web application. So, vector that might normally considered to be an internal-only exposure can be leveraged (in many cases) externally, over port 80. You can read along with the testing notes on Pull Request #4130, but the punchline is shown here: msf auxiliary(mssql_escalate_execute_as_sqli) > set GET_PATH /testing2.asp?id=1+and+1=[SQLi];-- GET_PATH => /testing2.asp?id=1+and+1=[SQLi];-- msf auxiliary(mssql_escalate_execute_as_sqli) > run [*] 172.16.158.132:80 - Grabbing the database user name... [+] 172.16.158.132:80 - Database user: MyUser1 [*] 172.16.158.132:80 - Checking if MyUser1 is already a sysadmin... [*] 172.16.158.132:80 - MyUser1 is NOT a sysadmin, let's try to escalate privileges. [*] 172.16.158.132:80 - Enumerating a list of users that can be impersonated... [+] 172.16.158.132:80 - 3 users can be impersonated: [*] 172.16.158.132:80 - MyUser2 [*] 172.16.158.132:80 - MyUser3 [*] 172.16.158.132:80 - sa [*] 172.16.158.132:80 - Checking if any of them are sysadmins... [*] 172.16.158.132:80 - MyUser2 is NOT a sysadmin [*] 172.16.158.132:80 - MyUser3 is NOT a sysadmin [+] 172.16.158.132:80 - sa is a sysadmin! [*] 172.16.158.132:80 - Attempting to impersonate sa... [+] 172.16.158.132:80 - Success! MyUser1 is now a sysadmin! [*] Auxiliary module execution completed Thanks Scott! Templates for New Modules If you're the sort to write your own modules for Metasploit, Rapid7 Labs contributor Jon Hart provided a pretty handy template for a basic UDP port scanner this week. There was some debate over where these sorts of template module should go. Technically, the module provided does actually function and Do A Thing, so it's not unreasonable to keep this (and others like it) the main modules tree. After all, for people new (and not so new) at writing Metasploit modules, the first inclination is typically to look around "nearby" for a module that kind of does something similar, and model the new functionality off of that with a copy-paste. Of course, this leads to some cargo culted code along the way, but if we have a module that's usable and findable in a spot that's likely to be looked at, the chances of cargo culting tends to drop off. At least, that's the idea. Some day soon, we hope to have a simplified module template generator available as a rake task, similar to the Corelan Team's mona.py module generator (which is great for spitting out "traditional" memory-manipulation exploits, by the way). I'm kind of surprised that nobody has taken on this mini-project for Metasploit development already, given how much we use rake tasks today. If you're looking for a useful way to contribute, and you're more of a Ruby person than a buffer overflow poking person, this might be a fun project to take on. If you're interested in hacking on Metasploit like this, feel free to drop in on our Freenode IRC channel and/or subscribe to the Metasploit Hackers mailing list and give us a shout. New Modules Including those discussed above, we've landed three new exploits and seven new auxilary modules this week. Beware the return of Sandworm! Exploit modules Visual Mining NetCharts Server Remote Code Execution by juan vazquez and sghctoma exploits ZDI-14-372 MS14-064 Microsoft Windows OLE Package Manager Code Execution Through Python by sinn3r, juan vazquez, and Haifei Li exploits CVE-2014-6352 MS14-064 Microsoft Windows OLE Package Manager Code Execution by sinn3r, juan vazquez, and Haifei Li exploits CVE-2014-6352 Auxiliary and post modules ManageEngine Password Manager SQLAdvancedALSearchResult.cc Pro SQL Injection by Pedro Ribeiro exploits CVE-2014-8499 Microsoft SQL Server SUSER_SNAME SQL Logins Enumeration by nullbind Microsoft SQL Server - Escalate EXECUTE AS by nullbind Microsoft SQL Server - SQLi Escalate Execute As by nullbind ManageEngine Eventlog Analyzer Managed Hosts Administrator Credential Disclosure by Pedro Ribeiro exploits CVE-2014-6039 Oracle TNS Listener Checker by ir0njaw (Nikita Kelesis) UDP Scanner Example by Joe Contributor

UserInsight's New User Statistics Provide Great Visibility for Incident Responders

Nate Silver made statistics sexy, and we're riding that wave. But seriously, breaking down some of the more noisy alerts on the network by users and showing you spikes can really help you detect and investigate unusual activity. That's why we've built a new UserInsight…

Nate Silver made statistics sexy, and we're riding that wave. But seriously, breaking down some of the more noisy alerts on the network by users and showing you spikes can really help you detect and investigate unusual activity. That's why we've built a new UserInsight feature that shows you anti-virus alerts, vulnerabilities, firewall activity, IDS/IPS alerts, and authentications by users that show the most activity and enable you to dig in deeper by filtering by user. You can get to the new stats page by clicking on the Active Users link on your UserInsight dashboard:What you'll see is the stats for five different data types:Virus Alerts: Most security professionals see anti-virus solutions as a protective solution for mass malware rather than a detection solution. However, we believe there is some value to this much-bashed data when you apply statistics to them and break them down by user. In our demo system, the user Shawna Roy popped up at the top of the list with 65 virus alerts. By clicking on the little graph icon on next to the name on the right, you can display the data for this user only (and add additional users to the chart by clicking their icon). Shawna saw 30 alerts on August 14, which is probably worth investigating. By clicking on the name itself, you can get more context on Shawna's activities, such as assets and cloud services she authenticated to, applications she accessed, and locations she logged on to the network from. This may show other indicators of compromise that can be helpful in triaging this statistical outlier.Exploitable Vulnerabilities: Slicing vulnerability data by CVSS score, exploitability, and critical hosts is something security professionals are very familiar with. However, most security programs can't provide visibility by user, which can be important in the context of phishing and other social engineering campaigns that target client-side vulnerabilities. The more exploitable vulnerabilities a user has, the more attack surface cyber-criminals have to work with. The new UserInsight vulnerabilities user stat feature shows you which users have the most exploitable vulnerabilities and warrant a second look to ensure that a security program is prioritizing the right vulnerabilities for remediation. It can also help give context of the likelihood that an attack against a certain user successfully exploited their machine.Firewall Activity: Firewall activity is very noisy, especially if you don't just take denies but all traffic. In the following example, Joshua Green had a million firewall connections in a single day, which is clearly an outlier when we filter for this user. This is definitely worth investigating, since it may be a sign of a malware/botnet infection that is scanning the Internet or participating in a DDoS attack. IDS: IDS/IPS data is also extremely noisy data. One customer we spoke to has 20,000 alerts per day, making it impossible for him to investigate every single one. Providing user context can also greatly increase visibility and help make sense of the data. Check out Matt's blog post on canceling noisy alerts, which covers a lot of this topic already.Authentications: Both successful and failed authentications can provide a lot of visibility into what's happening on your network. Accounts with many successful authentications can be legitimate or a cause for concern. There will be some obvious accounts, such as your vulnerability scanner or a backup solution that logs onto many devices many times, but there may also be accounts that should not exhibit this type of activity. You may discover that a user account is being abused as a service account, for example, which is not a best practice. Failed authentications may point you to a brute force attack on a certain user, or show you an issue with a device using an outdated password.Check out the new user stats page and let us know if you discover a use case that we're not listing here, or a new stat you'd find useful. The feature is already live in your UserInsight environment. If you don't have UserInsight yet, please sign up for a free guided demo and chat with us about a proof of concept in your environment to detect and investigate incidents.

Top 3 Takeaways from the "Simplify Controls: How to Align Security Controls to Reduce Risk to Your Business" Webcast

This week we heard from Bill Bradley, Product Marketing Manager at Rapid7, about the far reaching implications of security controls. Each organization (SANS and the Australian Signals Directorate to name a couple) that highlights recommended controls promotes a slightly different twist on the weighting and…

This week we heard from Bill Bradley, Product Marketing Manager at Rapid7, about the far reaching implications of security controls. Each organization (SANS and the Australian Signals Directorate to name a couple) that highlights recommended controls promotes a slightly different twist on the weighting and criticality of controls. We looked at which controls across each organization with recommendations are the most important and effective risk reduction tools, and how professionals in different industries should prioritize them. Read on to learn the top 3 takeaways from, "Simplify Controls: How to Align Security Controls to Reduce Risk to Your Business": 1. Patch, Patch, Patch – Implementing automated patching tools and processes is important for helping to minimize forgetfulness and ensure that your security program is rigorous and constantly looking for machines that need updating. Vulnerabilities are discovered continually. It's important to know what is out there, and which ones may impact your environment. Develop an inventory of what's in your production system so that you can classify the risk of different vulnerabilities and determine their severity within your environment. Any risk can have a different level of relevance to your organization depending on how your business is designed and where your security priorities lie.2. Deploy, Segment & Conquer – When deploying devices onto your network, make sure you have a detailed understanding of how they will fit in, and configure devices so they can be modified and updated over time to have a small vulnerability footprint on the network. Speaking of networks - it's highly recommended for security professionals to implement network segmentation. Segmentation helps limit what an attacker can do if they've successfully gotten past your security measures. Breaking up the network into different logical segments ensures that the attacker will have much more difficulty moving through your network, and this will make your organization a much less attractive target. Some deployment best practices: take inventory of your assets, identify target systems, categorize installed software, determine critical gaps, and more. It's important that when you're planning and implementing controls that you have short and long term goals for maintenance and tracking. View the full webcast for more details. 3. Communicate with Users and Management – Educating users on why and how the controls you have in place benefits the organization is important for keeping everyone on the same page and understanding of how you are working to protect any and all sensitive data tied to the company. If everyone is aligned about business and security priorities, and management is able to see metrics and tangible successes based on your controls, you may even be able to get increased budget to implement more and even better controls over time.For the in-depth look at security controls best practices, including how different industries should prioritize them: watch the full webcast now.

Don't Be An Easy Target: Testing Your Network Segmentation

Network segmentation is the act of splitting a computer network into subnetworks, each being a network segment, which increases security and can also boost performance. It is a security best practice that is recommended (but not required) by PCI DSS and it makes the top…

Network segmentation is the act of splitting a computer network into subnetworks, each being a network segment, which increases security and can also boost performance. It is a security best practice that is recommended (but not required) by PCI DSS and it makes the top 20 list of critical security controls suggested by SANS. Due to the ongoing investigation, the world doesn't have the full details on the Target breach yet, but there are strong indications that network segmentation could have considerably reduced the impact of that breach.It appears that the attackers entered through an HVAC company that supplied heating/cooling systems to Target stores. While it was first speculated that this external  partner had remote access to the HVAC systems for maintenance, it was later disclosed that it was their EDI/Billing integration that turned out to be Target's soft spot.While network segmentation cannot help you keeping attackers out, it can help you contain the impact of a breach to one part of the network. With solid network segmentation between the billing and the POS systems, Target may have avoided the attackers from reaching their pot of gold - the POS systems.To help our customers audit if their network segmentation is effective, we are updating Metasploit Pro to test the connection between any two network segments, testing open ports between the Metasploit Pro instance and a network segmentation testing server. In addition to this very quick and easy network segmentation test, you can use Metasploit Pro to conduct a penetration test from any network segment and try to reach another, such as the cardholder data environment (CDE). Metasploit Pro's VPN pivoting can help you traverse network segments connected by multi-homed machines. The new Network Segmentation Testing MetaModule will be available soon - watch this space!

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