SecurityTrails Blog

Imagine an operating system without much security. Installing any new program would be risky business—it could replace your system files, discover passwords, even delete everything. Sounds like a nightmare? Well, that's what a sandbox can prevent.

Even when your device and operating system have reinforced security, you're not really safe. Malware detection, antivirus software, antispam, endpoint security solutions and the like are all necessary means of cyber protection, but still won't be enough for the sophisticated malware and obfuscation techniques employed by today's malicious actors.

The usual protection techniques and technologies work by identifying known indicators of compromise (IOC), meaning zero day threats and new attacks that easily evade security defenses can be missed. Incorporating sandboxing into your security tooling will provide you with an additional layer of security, allowing you to detect previously unknown threats and advanced persistent threats in a safe environment.

What happens in the sandbox, stays in the sandbox

A sandbox is a preventative analysis technology used for security deception. As an isolated environment on a network, it provides a safe testing area for running programs and executing code separately from the system, with no risk of infecting the system. When running without a sandbox, an application can require access to many of your system's critical resources.

But with a sandbox environment that mimics the operating system of the user, the application will only be able to access resources within the sandbox, with permissions to only those it needs. This way, any suspicious code or program can be kept in an isolated area, ensuring safe execution with no disruptions to the system.

Sandboxing is valuable for both software development and cybersecurity. When it comes to software development, sandbox environments are used to create secure applications, allowing developers to test new code in various environments and noncompatible programs running simultaneously.

For security, sandboxes are used as an addition to firewall solutions by protecting the OS while launching applications and working with sensitive data. Sandboxing can also be used to safely analyze malware and help prepare for future attacks. It's often employed by blue teams to safely test malware against multiple OSs, analyze it and even determine if existing antimalware solutions have properly flagged the malicious code or file. For more on the subject, we recommend you read our Blue Team Toolkit post, in which we talk about the best open source sandbox tools available.

Everyday users also benefit from sandboxes when browsing the web. Web browsers essentially run the web pages you visit in a sandbox as they are constricted to running in the browser only, with no access to your local files, webcam, etc.

Mobile apps are also run in a sandbox—they have to ask for your permission if they want to access any other resources, including your media library, camera and location.

As there are different uses and needs for sandboxing, there are multiple versions and approaches to consider:

**Virtual machines**, VMs, as their name implies, create virtualized hardware devices that emulate the entire operating system, and don't have access to anywhere outside of it. This means you can install software and run code as if you were on your regular device and OS. Well known VMs include VMware, Java VM, VirtualBox and Xen Project.

**Sandboxing programs**, A good example of a sandboxing program is the popular Sandboxie, a sandbox for Windows. It creates an isolated operating environment and applications can be run in it without accessing or modifying the local system, allowing for controlled testing of programs and applications.

**Limiting permissions**, Having the system assign levels of access for users and programs according to determined rules, such as SELinux rules and Posix capabilities, means you can have control o...

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

Are you aware of your infrastructure's weakest spots? Attackers surely are. Target reconnaissance is one of their first steps toward getting full insight into an objective, one that will eventually develop into a complete attack strategy to compromise assets.

Any information that an organization leaks (however benign it may appear) is feasible for malversation and misuse for deceptive purposes.

Today we're testing **Attack Surface Mapper**, a recon tool designed to help you boost the effectiveness of your Osint daily tasks and bring extra help to the existing intel tools already used in daily infosec jobs.

Let's now discover what Attack Surface Mapper is, by exploring the installation, configuration, and testing process. And we'll find out whether it's a good choice for your infosec reconnaissance needs.

What is Attack Surface Mapper?

Attack Surface Mapper, as its name implies, is a free, multi-platform (for Linux, macOS, and Windows) tool used to create a full map of your attack surface.

According to its authors Andreas Georgiou and Jacob Wilkin, this recon tool uses both classic Osint and other types of active techniques to gather all possible intel on any target.

To create the full subdomain map, it launches several brute force mapping attacks as well as passive DNS lookups and searches for data on the same subnet IP addresses to find subdomains.

Once all subdomain, domain, and IP intelligence are found, it can take screenshots of the website, search for email addresses of employees on Linkedin, perform passive port scans, and generate visual maps of your target.

Installation

Installing Attack Surface Mapper is pretty straightforward, requiring only three simple commands to get it working. Let's cover the process step by step:

Download AttackSurfaceMapper from their Github repo:

A few dependencies may be needed. Follow the next steps to solve those dependencies using pip:

The next step is configuring your AP-I key. This is only if you want to integrate any of the following services into your scan: VirusTotal, Shodan, Hunter, LinkedIn, Gray Hat Warfare.

Open the keylist.asm file:

Then configure all keys as needed:

Do the same, and tweak the AP-I configuration file as you desire to match your own keys.

How does it work?

Running Attack Surface Mapper is easy. Just use:

Replace "securitytrails.com" with your real target, and set a desired file name to save the results (in our case "results"), and that's it. In our tests, we set the target to be 'shodan.io', as you can see in the following screenshot:

In the video below, you can see a demo by one of the authors in which he demonstrates how Attack Surface Mapper works:

Analyzing the results

We ran numerous tests against several targets, and here's what we discovered.

Once the app finishes its attack surface mapping, it will display the results on the same screen, shown here:

These results found a lot of subdomains, 185 to be exact. Apart from that, we also found DNS records, including MX and D-Marc information, as well as the SPF data. When it comes to IP addresses, after performing the IP lookups it found two addresses and included geolocation, ASN, and CIDR.

Scrolling down a bit, we found the summary of findings related to the shodan.io domain name:

3 IPs, 185 subdomains, 24 open ports, and more. However, let's remember that this was the default command suggested by the documentation. By exploring the official docs a bit and playing with the '--help' option we found other options that may be used:

Now you see that we can add more intelligence data to our ASM execution, by adding options like:

-sc: to grab a screenshot of the target website.

-ln: to extract a list of emails and employees from Linkedin.

-sth: to use passive mode using only Osint traditional techniques.

-w: to load subdomain names from...

Security professionals today constantly need to appease the growing number of digital assets on a network: cloud platforms, containers, web applications, IoT devices, operational technologies, and the list goes on. The more assets one has, the more opportunities for malicious actors to break defenses and get access to sensitive data.

The modern attack surface is constantly evolving and growing. Just how much of an organization's assets are exposed determines how many vulnerable entry points it has for attackers trying to infiltrate their systems. This means that reducing cyber exposure is crucial in reducing the cyber risks your organization is facing.

What constitutes a cyber exposure?

We talked about what an "exposure" is in cybersecurity when we were discussing the topic of CVEs, but let's reiterate. An exposure is considered an error or misconfiguration that provides attackers indirect access to a system or a network, often leading to a data breach. But, when talking about cyber exposure in general, the definition might be wider, and goes beyond purely technical misconfiguration.

**Cyber exposure** is considered to be the worst case scenario in the event of an organization suffering a cyber attack, and the probability of the attack occurring. It's a discipline of managing and measuring risk associated with sensitive assets and data being compromised.

Here are three examples of what is considered an exposure that greatly increases the risk of unauthorized access:

**BYOB**: The more devices that don't have security controls accessing the organization's network, the bigger the attack surface.

**Supply chain**: Being part of a supply chain greatly increases your exposure as there are now more players in the game, and more networks and systems with security measures you have no knowledge of.

**Data and security policies** not being continuously reviewed.

Cyber exposure provides a framework with which organizations can have a better grasp over their assets and risks across all levels. Larger organizations have a larger network of digital assets, meaning that the attack surface and cyber exposure are much greater. With millions of digital assets there are challenges with the lack of visibility of those assets, and you can't protect what you can't see. But it isn't enough to know only what assets belong to the organization such limited knowledge would leave security teams without enough context for their detection, protection and remediation efforts. This leads us to prioritization, which is one of the pillars of any discipline handling risk.

Cyber exposure is not the same as a vulnerability. It actually depends on the exploitability of that vulnerability and the consequences measured in financial, reputational and operational losses that would follow. It's important to understand which vulnerability is being currently exploited by hackers, which vulnerability poses the greatest risk to your critical assets, and what would be the damage done if that vulnerability is exploited. In this way, you can understand which exposure is the most important.

A breach on assets that don't contain any critical financial, customer or intellectual data is not the same as cyber exposure, and shouldn't be treated as one that would involve any piece of that critical data.

What you don't know, will hurt you: The cyber exposure gap

While talking about cyber exposure, there is one term we should go over to aid in understanding the entire concept of exposure. As we mentioned above, one of the biggest challenges regarding cyber exposure is the lack of visibility. The cyber exposure gap represents the lack of visibility between what your security tools are showing you and critical areas of your attack surface, such as any vulnerability or misconfiguration not shown by currently used tools.

To reiterate you can't protect what you can't see. And the solution here isn't as simple as merely getting a single security tool that wil...

We've been having some Friday fun running Securitytrails Recon Safari on Twitter. Over the past few months, we've conducted over 30 successful investigations that were easy to research thanks to Securitytrails AP-I and Surfacebrowser. And as a result, Recon Safari began in the form of long Twitter threads, eventually evolving into fun and digestible infographics, ultimately followed by a writeup on our blog

For this first Recon Safari on our blog, we're looking into recent data breaches to see what we uncover.

Friendemic, a reputation management and digital customer experience company for car dealers, had a data breach in mid-September. Over 2.7 million records were leaked, with consumers' names, email addresses and phone numbers compromised. Aaron Phillips, a researcher at Comparitech, found a backup copy of an SQL database, or an SQL dump, that could have been caused by bad backup or copy error during migration.

Our team's initial reaction was to dig a bit into our Osint data using Surfacebrowser, our go-to tool when we need to know everything quickly. We designed Surfacebrowser to be an all-in-one passive intelligence tool that allows us to effortlessly browse through the external Internet surface area of any company, and identify unknown assets or spot network weaknesses.

In the case of Friendemic, we used the tool to access some telling data:

Whois history.

DNS history.

Subdomains with their hosts, ports, and more.

SSL certificates.

Domain registration

First, we wanted to verify ownership of the domain, in case it had been initially registered to someone else and then bought by new owners. Their Whois registration showed the domain was first registered on July 23, 2010, and that was confirmed on their "About" page. If Whois data and the company's founding date don't correlate, that can indicate that the domain may have been registered to someone else, and then bought by the current owners.

Our Whois historical data shows that the domain was registered to a "Brigham White" using a personal email address. There is no mention of this person on the company's "About" page, but the registration address refers to Utah as White's state and the company itself is based out of Salt Lake City, Utah.

Friendemic's "About" page mentions their acquisition of GoFanbase in 2017. Our data re-affirms this.

The providers for the subdomains used by Friendemic include:

Digital Ocean.

Amazon.

Cloudflare.

Serverstack.

According to the Comparitech security expert, "The data was stored in an Amazon S3 bucket, it appeared to be an SQL dump or a backup copy of an SQL database, which is usually created for the purpose of migrating a server." The breached data was exposed via an unsecured S3 bucket, and the visibility of Amazon as a provider re-affirms this.

It appears that Digital Ocean is now being used for most of the testing and development:

Open ports

The list of open ports found on Friendemic subdomains includes: 80, 443, 2082, 2083, 2086, 2087, 2095, 2096, 8080, 8443.

The bulk of the current open ports are on Cloudflare subdomains:

The company used Cloudflare for many years to provide DNS-A records but switched to Digital Ocean in 2019:

Email

Google has been Friendemic's email provider since 2017. Additionally, TXT records show that they are also using MailGun, possibly for outgoing transactional emails, newsletters, and the like:

SSL certificates

The bulk of the SSL certificates are from Let's Encrypt, but their main domain is behind Cloudflare SSL.

The two most recent subdomain changes, from September 25 and 30, correlate with the breach discovery and Friendemic's team patching it up.

No company is 100% secure at all times and Friendemic may have existing bugs. After the breach, we suspect that they will take their security more seriously and this is evidenced by the introduction of Cloudflare. The risks associated with exposing personal data can further be prevented by using non-pub...

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

Are you a Cisco SecureX user? Conducting cyber threat intelligence campaigns? Now you can integrate the Securitytrails AP-I into your existing SecureX Dashboards, by using a serverless relay running Amazon's Lambda infrastructure.

Cisco SecureX is a cloud-native platform that allows you to connect your infrastructure to create one unified dashboard and increase visibility. This platform allows you to maximize your operational efficiency while reducing threat responsiveness, through a series of available automated workflows.

Using the Cisco SecureX platform in conjunction with the Securitytrails AP-I module will empower your infosec efforts by taking your cyber threat intelligence endeavors to the next level.

Securitytrails integration how-to

Today we're addressing the module's installation and configuration so you can get it ready to go.

The idea behind this setup is to configure a serverless instance using Amazon's Lambda platform. This allows the exchanging of information between our service and Cisco's—without the need to install dedicated infrastructure that adds a fixed additional cost to your Opex.

Getting the code

First off, you can find all of the code plus the documentation on Cisco Security's Github repository, located here. The complete environment configuration does involve plenty of steps and can be tricky, but we'll do our best to make it as simple and self-explanatory as possible.

To begin configuring, you'll need to clone all the code. Start by running the git clone command, then enter the recently created folder as shown:

In this folder, you'll find all the necessary files and folders to upload the relay into Lambda.

You must verify the Zappa configuration by checking the zappa_settings.json file included in the cloned folder:

Amazon Web Services configuration

Configuring AWS can be a difficult task in itself, so we'll explain every step to help you get this relay to work:

Configure a new user on IAM (Identity and Access Management).

Retrieve user credentials and place them in your OS's environment for Zappa to use them.

Configure the deployment policy for the serverless user to create the whole environment.

Configure the execution policy for the serverless user to run the relay.

Now let's get into specifics.

User setup

Getting this deployment to work properly requires an existing user with a specific role and a set of policies that constrain what this application can and cannot do.

This is done by following the steps below:

Open your AWS console in

Choose your desired application region (in this example we'll use US-East-1).

Enter the IAM by clicking Services, History, IAM located at the top menu to the left of the screen.

Click Access Management, Users located on the left menu.

Click on Add User as shown in the image below.

For this deployment, the documentation recommends we set up the user's name to **serverless** and leave the **Programmatic access** checkbox on.

Click on the **Next: Permissions** button followed by **Next: Review**, and once this is done you're ready to hit the **Create user** button to finish. As you receive the success message, it's possible you'll get an additional **no permissions** warning; this is correct and will be solved afterward.

To finalize, you need to download the credentials file as shown above. By clicking on the **Download .csv** button you'll receive a pair of keys that needs to be placed inside your local configuration files, as stated in the documentation:

"Once the user is created and the credentials are downloaded, the best way to store that data is to put it into your AWS credentials file usually located on **~/.aws/credentials** (Linux and Mac) or **%USERPROFILE%\.aws\credentials** (Windows).

Each profile can also specify different AWS regions and output formats in the AWS config file us...

**October is the National Cybersecurity Awareness Month (NCSAM)** aimed towards raising awareness about the importance of cybersecurity and sharing the knowledge and resources needed to stay secure while connected. This year's theme is **"Do Your Part. #BeCyberSmart"**, and we, of course, want to do our part.

Everyday, we are spending more of our time online, browsing, shopping, and working. With more everyday tasks we do online, more of our personal data is shared. And if that data falls into the hands of cyber criminals, sensitive information could be at risk.

Most successful attacks and data breaches are the result of simple human error and a moment of carelessness. Being aware of ways attackers might gain access to your personal information or infect your device with malware, and knowing what to watch out for, can reduce your chances of becoming a victim. This is why we've prepared 10 do's and don'ts of staying safe while connected.

Our advice is aimed towards the everyday user, with measures that are easy to implement but poised to make you that much more secure while still freely scrolling online. You can find additional links and resources that tackle different topics mentioned here, so you can always read more about different types of cybercrime and protection measures.

Do: Use complex passwords and change them regularly

While this might be a no-brainer, using common and easy to guess passwords isn’t a safe practice. The password 1, 2, 3, 4, 5, 6 alone is used by over 20 million people. This is exemplified by the fact that stolen credentials are one of the most common causes of data breaches. And one way cyber criminals frequently gain unauthorized access to systems is actually quite simple—by guessing passwords. Known as a brute force attack, attackers can guess an individual's password using relevant clues they have on them. Another example of brute force attack is to rely on users reusing their passwords, some of which have been exposed by previous data breaches.

**You can find out if your credentials have been compromised in a previous data breach, by visiting Have-I-Been-Pwned.**

Always use complex passwords with a mix of lower and upper case letters, numbers and special characters; and make sure they are regularly changed and different on all accounts. If it seems daunting to remember all those long and complicated passwords, using a secure password manager is a great way to stay on top of your password security.

Don't: Use any of your personal information as your password

When we mentioned that attackers can guess your password by using relevant clues, some of the more obvious tip-offs can be your first name, last name, date of birth, location and other personal information. Some clues, however, can be easily found by observing your social channels. That's why your password should never reference anything that's easily connected to you. Instead, use random words and phrases, or a combination of "nonsensical" word formations.

Do: Use multi-factor authentication

Chances are you're probably using at least a two-factor authentication on some of your accounts, as platforms often require you to create one. Authentication factors are: knowledge - something you know about the device, such as email and password; possession - another device that will verify your identity, such as an SMS code; inherence - something you actually are, such as a fingerprint, and location.

In the case of identity verification, the more the merrier. Multi-factor authentication considers the use of two or more authentication factors, which is not only important for creating an additional barrier to attackers trying to gain unauthorized access to your account, but also because SMS code and similar types of authentication aren't that secure.

Most, if not all, platforms will have 2FA and MFA authentication easily accessible, so it's simple to get started and add another layer of protection to your online accounts.

Don...

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

One of the core products at Securitytrails is our API. And to ensure that its usage is simple and user-friendly, we strive to follow industry best practices and standardization that the user base will be familiar with.

We take this even further by offering extensive documentation that is easy to understand as well as interactive. On the documentation page, you can test APIresults in the browser to see the outcome.

The interactive APIcalls can also show beginners how to construct the correct URL and call the needed API in order to fetch the desired data. Once you understand how the different APIcalls work, you can browse through code snippets for your favorite language (Python, Java, PHP, Go, Ruby, Node, and JavaScript are supported) and use these snippets locally or build on them to create your own Osint investigative tool.

What is Subdomain-Enum?

The above outline of our APIleads us to an independent developer Chaitanya Krishna, building his own script to enumerate subdomains using the Securitytrails API. This tool is called: Subdomain-Enum.

This interactive script can find all associated subdomains with a given domain and saves the results to a CSV. Written in Python, the script is very easy to understand for anybody familiar with writing code. We'll demonstrate this by attempting to extend or modify the script for different purposes, using the Securitytrails API.

Who should use it?

Subdomain enumeration is a great technique for anyone looking to find subdomains quickly during a reconnaissance or data-gathering task.

Whether you're on the offensive or defensive side of your target, enumerating subdomains can help in getting a broader idea about commonly used hosts but also it may discover long-forgotten hosts that are still connected and silently listening.

To name one notorious case affected by this kind of deception technique, here's the one perpetrated on PricewaterhouseCoopers (PwC) subdomain amyza-devapi.pwc.com as the following image shows:

As you can see in the Google search above, this subdomain was filled with fake content that actually had malware hosted. This was possible due to a broken C-Name record that pointed to an expired domain name registered by the deceiver. This is also known as subdomain takeover.

By accomplishing this, they managed to use a good standing subdomain name containing a reputable apex domain, and redirected users into a malware trap hosted at **amyca-dev-node.azurewebsites.net**. These are called stale DNS records.

Installing Subdomain-Enum

Let's now proceed with installing the Python script. And remember, it's always important to use some type of sandboxing environment when installing new software. You could opt for a virtual machine (VM), container, or a remote test server. We are using Ubuntu 18.04 for this review, and any commands used here should apply to Debian-based distros (and with a few minor tweaks, to other distros as well).

First, we should update our sandbox and install the software we need:

Now we can make a Python virtual environment to install the necessary Python packages:

We noticed that the repo for Subdomain-Enum does not have a 'requirements.txt' file which specifies the required packages. After taking a look at the script, the only 3rd-party Python library we need is 'requests' (which we installed above).

In terms of Python virtual environments, there are many ways to install and use it. Any installation method that gives you a 'virtual-env' should enable you to use the instructions below as is. If you opt for installing the necessary Python packages via 'apt', you might need to adapt the scripts below (this is as yet unverified).

If you haven't already, get your free APIkey today. With the APIkey ready, we can now add it to the script on line 12 of the subdomain-enum.py file:

Once your APIkey is stored and saved...

In recent years, more emphasis is put on privacy concerns and data security while online. The shields at the forefront of this battle for privacy and secure internet access are VPNs and proxies, and more notably residential IP proxies. While claiming to offer anonymization to users, residential proxies also account for some security issues.

**Residential IP proxies** are used for ads, shopping, and social networks, but a number of them are used for malicious purposes. Cyber criminals and bot developers are anonymizing their traffic using residential IP proxies, whose small footprint makes them harder to detect.

Spur Intelligence started as an industry exposé of VPNs, residential proxies, malware proxies and other anonymization behaviour, and their role in cybercrime and fraud. Thomas Kilmer and his co-founder Ethan Smith started Spur in 2017 and today they are a multi-purpose IP context provider.

To aid in understanding the role anonymization infrastructure plays in the cybercrime realm, we chatted with Tom Kilmer. We met (virtually) with Tom in Orlando, and heard his backstory, how he discovered the need for a service like Spur, and how they have been positioning themselves as an "anti-TI" vendor in the IP reputation space.

**Securitytrails: Tom, you finished a BS in Computer Science in Texas and after that, had some experiences in the public sector before joining Team Cymru and later Redacted. Can you tell us more about that time?**

**Thomas Kilmer:** After graduating college in 2011, I went to work for the Department of Defense in Maryland. I consider the nearly 3 years I spent in the public sector a continuation of my education. I also met the co-founder of Spur, Ethan Smith, during that time.

Although I enjoyed my time with the government, I also wanted to experience the private sector. At the recommendation of a mentor, I moved with my wife to Florida in 2014 and joined Team Cymru. Cymru was different from my government experience and it provided me with a wealth of knowledge and experiences that would prove invaluable nearly 3 years later at Spur.

In late 2016, my buddies from my time in the government called to let me know they were joining up with some folks from Silicon Valley to tackle problems facing the private sector. It sounded very exciting as I knew being part of a start-up would provide the necessary experiences to eventually start my own company.

I met back up with Ethan and others at Redacted. We were responsible for building a lot of the backend infrastructure in-between stress tests and trying to automate as much of the process as possible. We were exposed to a lot of 3rd party data, threat intelligence products and platforms, which gave us incredible insight into the state of security at a lot of high profile companies. However, our roles were not lending themselves to growth outside of a technical one. With that thought, we decided to take the leap and created Spur.

**How did you leverage your past experiences in making the jump from the private sector to becoming an entrepreneur and running your own company?**

**Tom:** I had no idea what I was doing. I had a lot of experience interfacing with customers, performing data acquisition, and building technical solutions. At both Cymru and Redacted I would often think to myself how easy the non-engineering teams had it. The more I talk with technical folks, I realize it is a very common sentiment. But I was wrong. Bizdev is hard. Sales is hard. General business management and keeping up with filings is tedious.

We took a very alternative approach to starting Spur. We wanted to be employee owned and not raise outside funding. Our mentors all told us it was a doable but much slower process and that we would have to be very careful. We sought out contract work from the connections we made throughout our careers. We knew it would be a split of time between contracts and our own work, but we'd ultimately build a product that would be ours...

We are thrilled to announce new features for Surfacebrowser, our SecurityTrails API, and Console.

With Surfacebrowser you now have the ability to download data from more pages, and can benefit from our Host Page improvements, Egress Activity, and much more.

More data downloads

With this latest release, we've enabled you to download data from the following pages:

**Whois**.

**Mergers & Acquisitions**.

**Activity**.

**Sub organizations**.

These downloads enable you to locally analyze, filter and further process the data with your own toolkit. For example, you can use the activity data to scan all newly seen hostnames.

Egress Activity

We've also reintroduced the Egress Activity option, which helps you detect outgoing traffic from any specific IP or subnet.

Host Page: new data about SSL and HTTPS crawls

The host page overview now has a new SSLcrawl summary that incorporates important details about your SSLcertificates, such as:

**Issuer** (organization, city, state, country, etc.).

**Fingerprint** (SHA256, self-signed verification, and validity date).

**Subject** (organization, state, locality, email, country, and common name).

And when it comes to **HTTPS crawl data**, you can visualize information including title, copyright notes, server type, meta generator, content type, MD5 fingerprint, and redirect chains detected on the website. Take a look at the following screenshot:

Console and API updates

Along with updates to Surfacebrowser, we've also enhanced the Console's usability by adding a search field to the navigation bar. This feature helps our customers access data in an instant.

The SecurityTrails API has been updated as well, with two new improvements:

"if-none-match" header support has been added to the feed endpoints

Firehose and Feed endpoints no longer count towards the quota

Remember, you can keep track of every change to all our apps and products from our SecurityTrails Changelog.

**Learn more about Surfacebrowser**

Discover how we can help you maximize the visibility of all your digital assets

Book a demo!

Note: The audio version doesn't include code or commands. Those parts of the post can be seen in the text version.

Over the past few years, data breaches involving millions of leaked records have become the norm. A common offender we're seeing more of is the presence of poorly secured and misconfigured databases connected to the Internet.

Leaving any database exposed to the Internet is often the result of simple human error, but the consequences are anything but simple. In the past three months alone, hundreds of unsecured databases left exposed to the Internet were the subject of "meow" attacks that destroyed data without much explanation—leaving only the word "meow" as a calling card. So far, more than 1,000 unsecured databases have been permanently removed.

To shed light on these recent leaks and attacks, Gregory Boddin from Leak "IX" is joining us in this latest installment of ProTips. Leak "IX" is a new engine developed in Belgium that indexes and provides insight into compromised devices, servers and databases. Leak "IX" helps security researchers and threat intelligence companies keep track of all campaigns active in the wild by providing actionable data on cybercrime campaign trends.

Today we'll learn about how to secure databases, how to identify meow attacks, the pros and cons of open search engines, Gregory's favorite open source scanning tools, and we'll even tackle some underappreciated practices such as source code mining and IPv6 scanning.

Pro-Tips

1. Open databases and how to secure them.

2. Identifying meow attacks.

3. Best open source scanning tools.

4. Pros and cons of open search engines.

5. Tackling IPv6.

6. Source code mining.

7. Leak "IX" power tips.

ProTip 1: Open databases and how to secure them

Most of the databases left open at the moment are MongoDB and Elasticsearch servers. They're used for various purposes, ranging from simple log servers to full-on "source of truth" object storage.

This means they can contain logs from users visiting your site, sometimes including what is posted on the forms: name, firstname, location, passwords or credit card numbers.

After logs, you can find full repositories of various objects:

Users.

Payment information.

Metrics about infrastructures, revealing their schema and internal config.

Large aggregates of data used for research, sometimes leading to disastrous consequences (social account scraping, sensible internet recon).

On the MySQL side, many instances turn out to be development instances. Those may include production data, depending on the company policy.

ProTip 2: Identifying meow attacks

When Leak "IX" was first released to the public, it was mostly a tool to help tracking the schema of databases. It turns out you can get many types of information from a database schema without accessing the data itself.

Identifying ransom campaigns were one of them, as those groups usually leave the same message with different mail-BTC addresses in a newly created database or index with a specific name, such as "hello" or "read_me".

What we didn't expect, however, was for all those servers to be completely wiped by what seems to be a non-profit attack.

Focusing on the Elasticsearch side, we started seeing meowed servers in the wild around the 20th of July. 500 servers were touched on the first day and the attack would keep running strong for the next two weeks:

There would be no sign of new infections until the 12th of August, followed by a total of ~600 infections since then.

Those represent a subset of what happened since we cannot guarantee we indexed ALL servers. From our data, however, we found that:

7,340 out of 12,371 Elasticsearch servers have been infected.

3,200 out of 15,664 MongoDB servers have been infected.

809 out of 7,689 Zookeeper servers have been infected.

You can find the full list of infections with daily reports here.

ProTip 3: Best open source scanning tools

**1 SYNACK scans**

If...