How MSPs can win new business with attack surface reports

* Recorded live on Thursday, April 25, 2024. Please note since this recording, Covalence has been renamed Field Effect MDR.

More managed service providers are leveraging Field Effect’s attack surface reports (ASRs) to provide immediate value to prospects, differentiate their managed security service, and accelerate the sales process.

Not just a sales tool, ASRs help you unlock new opportunities and close deals faster.

Join our CISO and ASR specialist, Matt Lewis, to learn

• What an attack surface report looks like
• Key benefits ASRs provide to your clients—and you
• How the ASR can fit into your sales workflow

What is an attack surface report?

An attack surface report looks at the internet-connected devices of an organization—everything that’s connected to the internet—and gathers data through open-source repositories like Shodan.

What we're hoping to find, and what we usually find, is devices, servers, networking equipment. Unfortunately, we also often find things that shouldn’t be directly connected to the internet or that are misconfigured and present opportunities for improvement.

So, we’re really looking at the organization from the outside in—at what a hacker would see when they look up that organization.

The first thing is that an ASR is completely complimentary to our channel partners. We want to see you guys grow. We’re trying to give you the tools that you can use to grow your business. So, there's no charge to Field Effect partners.

The second thing that's important to note is that it's completely non-invasive. We're using open-source databases, the same tools that hackers use, like Shodan. So, we don't actually have to do any type of penetration testing. We don't have to touch the infrastructure of that network. There's no Nmapping or TCP reconnaissance. There's plenty of that going on on the internet already. We don't need to add to that mess.

Lastly, it's automated. It's kind of been a passion project for mine to keep one foot in data analysis. So on the side, I've been building up the code, which takes everything I know about cybersecurity, what's bad, and Shodan, and automates it into a repeatable PDF that you can use.

How to request an attack surface report

There's a public form that includes all the details we need. All we need is the domain, the netblocks, the IPs that the organization has, and contact details so we know where to send the report. That’s all it requires.

We don’t specifically need netblocks or IPs, we can usually get a good report based on the domain. But any additional information you have is appreciated. We’ve seen a lot of ASRs lately where the difference between having that IP and not having it can take a basic report with few findings and turn it into one that really encapsulates the true threat surface of that organization. So anytime you can give us the IPs, we really appreciate that.

If a small or medium-sized business doesn’t know what their IPs are, you can usually get one or two by having them visit a website like “What’s my IP?” while connected to their VPN or in the office. That’s usually all it takes.

Inside the attack surface report

Let’s go through an attack surface report and the structure of it for an organization. I ran a sample one. It’s all redacted, so we don’t have to tell you who the exact organization was.

On the title page, you’ll see at the top “Your Logo Here.” We’re trying to make our MSP partners the stars of the ASR. It’s completely white-labeled, you won’t see any mentions of Field Effect in there. We’ll get a logo from you or pull it from your website, and we can customize the template of the report, so it reflects you and your style.

Next, we have the table of contents. One of the nice things about it is the little icon on the left for each section of the report, showing whether there were any findings there. The person reading it can immediately look down the table of contents and see if there were issues in section three (vulnerabilities) or section eight (protocols).

At the bottom, Annex A contains the full logs of the report, but there might be two annexes if we detect in Shodan that there are publicly available screenshots for this organization, something like a login screen. Those will be included in a separate Annex B. If there are no screenshots, we don’t include Annex B in the report.

Introduction

Next, we get to the introduction. Again, we tailor this so that you’re the stars of the show. We'll take a chunk from your website from the About Us section, or you can send us some custom text, and we can highlight in the second part of this page what's unique about your business and the services you offer to your customers. We'll also attach a link to your homepage so the person receiving the report can find out more details about you.

Executive summary

The next section is the executive summary. The summary starts with us calculating the overall risk. We're not trying to make a complex calculation here. We're just saying that if there are six or seven issues in the report, it's going to be high risk. If there are two or three issues, it's probably low risk. It’s not meant to be sophisticated, but it does a good job of letting the recipient know where they stand.

The next thing you'll see on this page is some automatically generated next steps. This is all built into the code. For example, if it sees something about remote desktop, and we all know that’s a big issue from a cybersecurity perspective and heavily leveraged by cybercriminals, it might suggest disabling remote desktop.

If we’ve seen TLS versions 1.0 or 1.1, it will mention making sure those deprecated encryption protocols are disabled. We do our best to help you and the recipient pivot from the report and say, “Okay, this is great, I’ve got these findings. Where do I go from here?”

Software

The first section of the data portion of the report is all about software. If we’ve seen any evidence that they’re running out-of-date software, old programs that can no longer be patched or don’t receive security updates, we’ll call that out in the report.

In this example, the organization has a couple of issues. They’re running an old version of Microsoft IIS web server, and they also have OpenSSL and PHP, probably on another web server, that are out of date.

In all of the data sections, we’re trying to give them an overview. The detailed findings, including affected IP addresses, will all be in Annex A. This allows us to keep the main report crisp and clean without worrying about pagination, and we can structure it to be highly readable.

As you know, having out-of-date software is a huge risk for any organization, so that’s the first thing to call out.

Operating systems

The next section is operating systems, which is very similar to the first. If we find evidence that they’re running older operating systems that no longer receive security updates, we’ll note it here.

That ties directly to our IIS findings, they’re running Windows 8 or Server 2012, something that should be addressed by this organization. It’s not only a security risk but also a reputational one. If I were considering doing business with them and saw that they’re running servers that can’t even be patched, I might think twice about it.

Vulnerabilities

Now, this section can be a little scary for someone receiving the report, so it’s important that it’s phrased correctly. Because we’re doing this passively and in a non-intrusive manner, none of these vulnerabilities are confirmed.

We’re using NIST data, taking all the information we find in open-source repositories about the software, and comparing it to known vulnerabilities to identify potential matches. All this is really saying is that the organization has something connected to the internet that has had vulnerabilities associated with it in the past. They need to make sure it’s patched and up to date.

If you’re running a web server that’s had 73 vulnerabilities associated with it, you can be sure number 74 is right around the corner. What we’re highlighting here is that the organization has infrastructure that can be secured, it just needs a regular patching cadence. That’s something your MSP can help them with.

Internet of things (IoT) and industrial control systems (ICS)

Sections five and six are IoT (Internet of Things) and ICS (Industrial Control Systems). In a perfect world, we wouldn’t see these at all, but they show up far too often in Attack Surface Reports.

For example, this sample organization we ran the report for had building controllers and even their HVAC system connected to the internet.

Why is that a risk? Often, these devices use protocols that predate the internet, meaning no authentication, no encryption, and no concept of modern security. For IoT devices like cameras, they’re often running end-of-life web servers that can’t be patched or updated. These are devices that should never be directly connected to the internet.

If I were briefing on this report, I’d recommend moving those devices inside the network, preferably onto their own segregated subnet or VLAN, isolated from everything else. If they’ve been on the internet for any amount of time, you have to assume they’ve been compromised in some way.

Protocols

The next section is protocols. What we’re looking for here is anything outdated, unencrypted, or associated with single-factor authentication. For example, protocols like POP3 and IMAP don’t even support multifactor authentication, so we’d flag those. If we see something like SNMP with known vulnerabilities, that’ll be highlighted as well.

If I were an MSP giving this report to someone, I’d say that we need to look at your firewall rules and really evaluate the business case for having these protocols accessible to the internet at all. We’ll work with you to reduce that attack surface and make sure that only what’s necessary is responding from your servers and devices.

Encryption

There might come a day when we’re all using a new type of encryption but, for now, we’re still dealing with the same old PKI systems that rely on certificates. For these systems to function properly, the certificates must be signed (not self-signed) and valid (not expired).

If we find expired or self-signed certificates, we’ll let the customer or prospect know in this section. Wildcard certificates aren’t as much of a concern, but there’s always a trade-off between ease of deployment and security, and we’ll flag that too.

Databases

The next section focuses on databases. If there’s a database running on the internet, we want to know about it.

And the organization should too, because databases are prime targets for cybercriminals. If I’m a cybercriminal, I usually have to work really hard to get onto your network and find where your data is and your databases are. But if you’ve put them directly on the internet, you’ve essentially given me that information for free. You’ve made my job a whole lot easier and told me exactly where your core data is.

Other issues

Section 12 is a grab bag for anything that doesn’t fit neatly into the first 11 sections. If we see printers, remote procedure call ports, or other miscellaneous items, they’ll appear here. The code behind this report is composed of hundreds of signatures, and we’re adding more all the time, to accurately reflect what’s going on with our customers and their threat surfaces.

Annexes

Annex A includes the detailed report that you’ll need to pivot from the findings and start addressing the issues. It’s broken into individual sections so you can easily find information.

Annex B might be included, or it might not. But if it is, it contains some of the most eye-opening content. That’s because it means one of those open-source repositories had publicly available screenshots of the organization’s actual devices. Maybe they had RDP open and it captured a screenshot of the login screen. Maybe an ICS system had no authentication, and Shodan was able to grab that image.

If screenshots like these are in the report, this is where things get real for the organization. You can tell them, “Look, a hacker with a simple query can pull this up and see what your infrastructure looks like without even touching it.” It drives home how real these threats are, and how focused organizations need to be on security.

Using attack surface reports effectively

So here are my takeaways from doing a few presentations on ASRs. What works, what doesn’t, and the keys to using them effectively.

Consent is key

The first, and I think most important, is that consent is key. If you’re looking to drop an Attack Surface Report on someone who hasn’t requested one, generally speaking, that conversation doesn’t go well. I’d encourage you to offer it first, see if they’re interested, and that usually makes things go much smoother.

Break it to them gently

The second is to break it to them gently. This report can lend itself to hyperbole, but the key is not to overdramatize it. Don’t tell them they’re going to get hacked tomorrow. The best approach is to say, “This shows where you’re at right now, and with a little more investment and monitoring, we can start making meaningful improvements.”

Pivot

The third is to pivot. Take the findings from the report and turn them into opportunities to show how you can help. Maybe the report identifies something about their email security and notes that they need a DMARC record. That gives you a chance to tailor the discussion, explain your services, and show how you can help them not only with security but also with day-to-day IT operations.

Bad isn't necessarily good

What I mean by that is people often assume that the worse the Attack Surface Report, the easier the sales conversation will be. But in my experience, that’s not true. Usually, the worse the report, the harder the conversation. That’s because it often reveals you’re dealing with a small or medium-sized business without proper IT, whether from lack of investment or otherwise. Getting them to suddenly care about it can be challenging.

Often, the best conversations come from medium-range reports where the organization is doing a decent job overall, but your report highlights a few issues they weren’t aware of, and they’re motivated to improve. Those are the ones who say, “Thanks, I didn’t know about that. I could’ve spent a lot of money on a penetration test to get similar results, and you’re giving me this guidance for free.”

We can help

Lastly, we can help. If you’re new to using the Attack Surface Report and don’t yet have the confidence to take a prospect through it, we’d be happy to support you on your first few.

Trends we’re seeing right now

The first major trend is way too much exposure. There are simply too many things connected to the internet that don’t need to be. Whether it’s IoT cameras, industrial control systems, or other devices, there’s too much unnecessary exposure. The key message here is that every single service and piece of infrastructure connected to the internet can be reached by hackers 24/7. If it doesn’t absolutely need to be accessible, it should be pulled internal.

The second trend is end-of-life software. Unfortunately, we’re still seeing a lot of Windows Server 2012 and Windows 7, organizations that haven’t yet spent the money to upgrade their infrastructure. You’ll spot this often, so it’s a great opportunity to explain how you can help them upgrade their servers in a non-intrusive way, with no business downtime.

The third trend is insecure cloud deployments. Many people thought moving to the cloud was a cure-all, but unfortunately, we’re seeing the same mistakes there as on-premises. Poor firewall rules, too much exposure, and services that shouldn’t be publicly accessible. This is something to be aware of and discuss with your customers.

The fourth trend is poor web hosting. Not every web hosting company treats security the same way. From running these reports, it’s obvious that some web hosts understand security, while others either don’t know or don’t care. Sadly, a lot of small and medium-sized businesses have their websites hosted by the latter. 

What that means is that your organization’s cybersecurity is only as strong as the cybersecurity of the company hosting your website. If I’m a hacker and I can get onto that box, I can start hosting malware there immediately. That can impact you, your customers, and your reputation.

I’m not expecting every MSP to start managing their customers’ websites, but the key message here is that as MSPs, we get it. We understand the risk, and we can point clients in the right direction, helping them move to a web hosting provider that truly understands security. That way, they don’t have to worry about it. But it’s an issue that comes up frequently, so it’s worth being prepared for that.

In fact, one of the comments we can auto-generate in the first section will say something like, “We detected IP [address] as hosting your website. It has a poor security posture. You might want to reassess it.” That’s how often that issue shows up in these reports.

Requesting an attack surface report

Here’s the form where you can request your Attack Surface Report. Provide as many details as possible—IPs, domains, anything you can—and we’ll take it from there.

If you can give us a couple of days’ notice, that’s great. The more lead time we have, the more thoroughly we can check them over and even add new signatures to improve accuracy.

Q&A

Q: Is there a different report based on location. For example, the USA versus Canada?

No, the code and automation are the same. There’s no difference. Often, we find organizations, especially in Canada, where some of their infrastructure is hosted in the U.S. If it’s out there and we can find it, it’ll be included in the report.

Q: Are the bad actors running these types of scans without the IP addresses?

Yeah, I’d say for a lot of small and medium-sized businesses, the reason we need the IP address is that there’s nothing in the WHOIS record. There’s nothing there that identifies it as belonging to a specific organization. If we’re running a report on a larger organization with 500 or 700 people, they’ll often have a netblock of IPs that we can find because there’s a WHOIS record, and Shodan or whatever source we’re using will know about it.

But for smaller organizations, the IP is critical. Sometimes all we have is the IP of their router and their website.

Q: I assume Field Effect can and will do an internal scan if requested?

One of the benefits of Field Effect MDR is that, from an internal perspective, you’re already getting many of the advantages of an internal scan but passively—especially if you have the on-prem appliance. We’re looking at network connections, monitoring traffic, and you get a lot of that for free.

Q: When bad actors use Shodan, how are they able to see the exact location or organization?

One of the queries they’ll run is either a hostname or SSL query on the organization’s domain name. That will bring up any IP Shodan finds with SSL certificates tied to that domain. The same goes for hostnames.

We use those same queries in our own reports to identify IPs. That’s why, especially for larger organizations, we can usually produce a good report based solely on the domain name because we’re running the same types of searches.

Q: Is all of this information sourced from Shodan, or are other tools being leveraged?

Yeah, we’re using Censys too. We’ve started to build that into the code so we’re taking the best of both worlds. Sometimes one of them will have data the other doesn’t, so combining Censys and Shodan really helps fill in the gaps and ensures we’re providing the most thorough report possible.

Q: How do the different laws in various states affect the outcomes of this report?

This is all open-source information. I’m not sure of the exact legalities around Shodan. But, generally speaking, the courts have determined that this kind of network reconnaissance is completely legitimate from an internet reconnaissance standpoint.

Q: How do people generally react to the report?

Overall, the reaction has been mostly favorable. I’ve seen a couple of discussions go off the rails, but those usually happen when consent came from a non-technical leader, and then the IT person was brought in afterward and had the report dropped on them. That never goes well.

Q: Where’s the best spot in a marketing funnel to put the ASR?

I’d say top of funnel, for the request not generating the report. Saying something like, ‘Come talk to us and we’ll give you this complimentary report to show where you’re at,’ works well. Once you have the report, you can tailor your talk track around how your services can help that organization. And if you combine that discussion with a Field Effect MDR demo? Even better.