A few weeks ago, I asked my manager, Chris Bareford, if he would approve the purchase of a licence to use the https://www.shodan.io open intelligence platform. I was both vague and detailed enough to justify the purchase, something about gathering threat intelligence as far as I can recall. My request was approved, and I am now in possession of the Shodan freelancer API entitlement. This is useful to me in automating certain intelligence and discovery tasks.
This blog, however, is NOT about the Shodan freelancer API.
Part of my job is to help enable cyber readiness for both my internal colleagues and my customers and prospective customers, and as part of this remit I publish a weekly threat landscape report, which is essentially a collection of things I have found to be interesting (and/or concerning) during the previous week from a cyber-security perspective. One element of this report covers what I would consider to be largely opportunistic attacks (or probes), and so I summarize an anonymized set of the past week’s common vulnerabilities & exposures (CVE) that VMware customers have had. When collating this type of information on a regular basis, what you notice is that, in addition to a set of common, frequently attempted CVE probes, we see waves of seemingly random probes of CVEs which may be years or even decades old. It seems like this is more than just opportunism, although it could be, and more likely driven by some level of intelligence — but from where?
In the more salubrious corners of the internet, there are many sources of open intelligence — places where you can, mostly for free, perform various discovery functions on internet-facing entities. These intelligence sources are intended for legitimate use: supporting the health and vulnerability status monitoring of organizations’ public-facing technology and even identifying malicious entities for proactive/reactive protection.
As I am an open and honest individual, I’ll admit that I use a few of these myself to support my sales process (shodan, mxtoolbox). In my pre-sales role, customers cannot always be totally open with me about their environment and security posture, and these sources allow me to perform my own intelligence gathering, which enables me to focus on areas which will be more relevant (and therefore more valuable) to the prospective customer, and help them solve their problems, whatever they may be. I have found this kind of discovery to be extremely valuable, both in enabling my own sales processes, and also in showing the customer precisely what information can be discovered via public sources. In a few cases it is a real eye-opener to them, and even if there is no problem or the customer has no need of VMware products, our discussion was still valuable to them. Sometimes they leverage these tools to their own advantage, and sometimes they take steps to ensure that information which appears publicly is limited or deliberately misleading.
These discovery tools are very powerful, and as with all such things, they are powerful for legitimate, and, unfortunately, nefarious activities as well (I will let you decide if using them for sales enablement is ‘good’ or ‘bad’ — honestly I am still not too sure).
Of course, in the less salubrious corners of the internet, there are … different tools, which are also powerful, and designed specifically to enable sophisticated and less sophisticated threat actors to launch malicious attacks.
Let me give you a brief example. Let’s imagine for a moment that we are opportunistic cyber criminals and we are looking for some easy routes into a customer environment.
We will use the free features of shodan — and, let me be clear, shodan is certainly NOT designed for use by threat actors. It is an extremely valuable tool which can be used in a number of ways for proactive defensive intelligence, but it can also be used in other ways…
We start our intelligence gathering with a basic search. Let’s see how many Microsoft Exchange servers we can find:
You won’t be surprised to hear that we can find a lot, since one of the primary use cases for Microsoft Exchange is to be internet facing. Here are the numbers for the top 10 geolocations:
So now I might want to make my search a bit more specific based on geolocation. I won’t share with you the precise location that I have chosen, but after a few scrolls of the mouse, we begin to find things that might be interesting to an attacker. We know the server name and organization (which I have redacted), the version of Microsoft (although this could be fake), and we can see that this server is vulnerable to a number of CVEs.
When we look at the details, we can see that while the CVEs in question could potentially provide us an easy route to compromise this server, that approach might be a bit of a noisy way in. But, based on our level of sophistication, we might just go for one of these options.
If we are a bit more thorough, we might also be interested in other services this server provides. In addition to email (port 25), we can see that this server has a few more public-facing services:
What are those services? Take a look:
FTP server. Although the server vendor and version may be fake, if the information is real we can determine if there are any associated vulnerabilities, or perhaps default accounts that we could try. This could be a handy place to store malicious files, or exfiltrated data, or it might even be a good place from which to exfiltrate data.
Mail Server. Again, we assume the information the server gives us is real (but it could be fake), and in addition to the known CVEs we found, we could probe this server further to see if we could use it as a relay from which to originate malicious emails.
Web Server (MS IIS). Looking like a part of the Microsoft Exchange installation, this webserver could be a useful place to stage malicious URLs — to which we could re-direct victims.
VPN. It looks like the organization has some remote access services. Perhaps we could attempt to gain access this way, or perhaps disrupt business by overwhelming the VPN server with requests (DoS/DDoS).
OpenVPN
PPTP (VPN – Point-to-point Tunnelling Protocol). This server’s hostname suggests that not a lot of care was taken when it was configured. Could this also offer us another route in?
Now, the more experienced cyber professionals amongst you may have doubts at this point. There are a few things about this server which seem a bit fishy to me, and almost too good to be true from an attacker’s point of view. It’s likely (although not certain) that this server is a honeypot — one designed to attract the attention of the less sophisticated threat actors, either to catch them in the act, or at least to try to learn more about their tactics, techniques, and procedures by monitoring their attempts to gain access.
In some of the findings, I mentioned that certain pieces of information we found could be fake. For example, just because the server is configured to tell us that it’s running Microsoft Exchange 15.1.1415.2, that’s not necessarily the case. In fact, we may consider techniques like this to be viable, proactive security counter-measures.
Hopefully, at this point it’s clear: the purpose of this blog is to highlight for those who might not otherwise be aware that there are legitimate services out there which enable quick and easy intelligence gathering. These services may be beneficial to threat actors, but they’re also valuable to organizations (including intelligence agencies) looking to enable proactive cyber defences.
Now, back to my Shodan freelancer API.
I value being able to use sources like Shodan, and perhaps other more specifically cyber IOC-focused providers, to gain information programmatically, which I can then use to protect my assets.
For example, I might want to constantly probe my public-facing services and identify any assets that may be vulnerable to known CVEs — just like we did above, but rather than using this information for bad things, I can use this in my orchestration layer or in my playbooks to protect my assets. Further, I might want a playbook which takes this information, checks my NSX distributed IPS policy, and ensures that these vulnerabilities are mitigated through virtual patching.
Let’s say I was not aware that I had a public-facing FTP server, and, now that I am, perhaps I should be checking on the segmentation / micro-segmentation policies applied in my NSX distributed firewall, in particular, based on the business need of this service. Should I be more restrictive about which applications are able to use it? Maybe I should be more restrictive about who can connect to this device in the first place, and whether files can be transferred bi-directionally or not.
Additionally, I might be interested in using the NSX Network Sandbox in order to verify that the files stored on my server are in fact legitimate. Perhaps I should do that with NSX Guest Introspection? And by checking files based on a File Create or File Modify activity, I could even prevent malicious files being written to disk.
Finally, I might also be interested in creating custom network analysis rules for these assets, which would alert me when the observed network behavior does not match what I define. Or I could just let the NSX Network Traffic Analysis AI-based behavioral models automatically tell me if any of these assets are exhibiting behaviors which, while not clearly malicious, may present risk through security-relevant network anomalies.
