Introduction
Threat analysts investigating malicious infrastructure are likely to encounter “open directories” during their investigations. These directories, commonly referred to as “opendirs” are openly accessible servers where threat actors host malicious files related to their operations.
An open directory is a simple concept that many will be familiar with. Despite this, there is little public documentation regarding their discovery and how to identify and track new open directory infrastructure.
This blog will cover the basics of an open directory, how you can discover them during hunting, and how to further your investigations into open directory infrastructure.
What Is An Open Directory?
An open directory is simply a server where a directory has been left “open” and is publicly accessible by browsing to the IP or domain of the site.
From the threat actors’ perspective, this directory enables malicious files to be easily accessible and delivered when and where they are needed. This is often second stage files for malware, or tooling used in hands-on operations.
There are legitimate use cases as well, where a legitimate service needs to make a file publicly and easily accessible, but for today, we will focus on malicious use cases and how to separate them from genuine examples.
Below (shared by RussianPanda9XX on X/Twitter) is one malicious example where an open directory is hosting malicious files. This example shows an Apache-based open directory when viewed directly in a browser.
Another example is an open directory used by ValleyRat and reported by Zscaler.
The open directory is utilising the HFS (HTTP File Server) software.
The appearance differs between software, but the functionality remains the same. Here is another example of slight differences between Apache and Python. These differences are covered in more detail in the “Dorking The Internet” Report by Censys.
So How Can You Find an Open Directory?
Open directories can be discovered in the community edition of Censys by searching for the open-dir label.
Censys automatically scans the internet for open directories and applies the open-dir label, regardless of the software used. This means that Apache, Python, HFS and others will all be included and do not need to be searched individually.
This label will include all open directories, including both malicious and legitimate results. The label alone can return hundreds of thousands of results.
We see this below with a plain search for labels:open-dir, which returns 450,153 current open directories.
As shown, the search for labels:open-dir will return all results regardless of whether they are malicious or legitimate.
The remainder of this blog will demonstrate how to combine this query with additional parameters to identify only malicious results.
Section 1: Static File Names For Open Directory Hunting
The most simplistic method to identify malicious directories is to leverage file names from previous incidents.
Let’s consider 81.71.147[.]158, which was shared by @morimolymoly2 on Twitter/X. This IP contains an open directory with a large number of suspicious files.
If we search for the IP on Censys, we will end up at the host page where the following information is available on port 80.
The open directory on 81.71.147[.]158 contains multiple files that are unique enough to be used as pivot points. Which are values that are unique enough to be used in a query.
There are two primary patterns which stand out.
- A.dll, a.exe, a.hta, a.jpg – Suspicious files with short and single character file names.
- Yaml-payload.jar – Suspicious file containing “payload” in the file name. Likely related to a Java Deserialization exploit.
We can combine these file names with the labels:open-dir query to identify open directory infrastructure hosting files with the same names.
Pivoting on Static File Names
File names like a.exe can be combined with the labels:open-dir parameter to identify open directories hosting files with the same name (although not necessarily the same file contents).
Censys stores open directory content in the services.http.response.body field, so this is where we can place a file name in combination with labels:open-dir
Hence, we can search for open directories containing a.exe by searching for labels:open-dir and services.http.response.body:a.exe. This simple search returns 9 similar servers.
As shown above, the search reveals 9 open directories containing a.exe.
The first result from the search is 159.223.130[.]216. Browsing to the associated host page shows an open directory hosting a.exe, as well as other files with similar single-character naming schemes. In addition to a.exe, we now have b.exe, c.exe and curl.exe.
Curl is a “legitimate” tool used to download files, so curl.exe is unlikely to be malware, but instead a supporting tool used to “install” curl during operations where the curl tool was not present.
To confirm the nature of these files, we can download them (using a sandbox or separate analysis machine) by browsing to the site directly and then performing manual analysis or submitting them to a sandbox. This is not always recommend for opsec reasons, but this is a topic for another discussion.
In cases where the infrastructure is not sensitive, the files can be scanned by inputting the URL directly into VirusTotal. In this case, we can input <IP>/b.exe and see that it has 34 detections and contains a Sliver C2 Implant.
Note that this kind of scanning will often alert the actor that their servers are being investigated. You should take this into consideration when investigating infrastructure.
The b.exe file has 34 detections, but the open directory hosting it has 0.
This means that we’ve likely found some “new” infrastructure, using only a simple file name for our analysis.
We can continue investigating the search results for more instances of a.exe.
Another result from our prior search is 121.43.135[.]166, which contains a.exe and numerous other suspicious files.
The same patterns of file naming can be seen across other servers returned by the search, which all contain a.exe in combination with other suspicious files.
Pivoting on An Exploit File Name
The initial IP contained another suspicious file named yaml-payload.jar. Googling this file suggests that it is related to a Yaml Deserialization exploit.
Repeating the process from before, we can identify similar servers by searching for labels:open-dir and services.http.response.body:”yaml-payload.jar”
The simple search returns 8 open directories hosting files with the same name.
One of the results contains yaml-payload.jar and a reference to artifact_x86.exe, which is a common file name for Cobalt Strike.
This means that our simple pivot on yaml-payload.jar has likely led to the server of an actor leveraging Cobalt Strike.
The artifact_x86.exe name is unique enough to be utilised as another pivot point. An analyst could perform additional pivoting on the artifact_x86.exe name.
This would be as simple as repeating the previous searches with different filenames in the services.http.response.body field.
Summary – Static File Names For Open Directory Hunting
Static file names serve as a simple and highly effective means to discover new malicious open directories.
By using public reporting (Social Media, Intel Repos, Internal Incidents), you can easily identify simple file names that can lead to new infrastructure.
To achieve all of this, simply search for labels:open-dir and then add your suspicious file name into the services.http.response.body field.
Section 2: Autonomous Systems and Hosting Providers
Open directory hunting can be heavily assisted by combining hosting providers with the labels:open-dir query.
This can be especially effective when an actor uses a unique or uncommon hosting provider.
Consider the IP 77.105.160.30 (initially shared by @karol_paciorek). This server has an open directory and is hosted on EVILEMPIRE with an Autonomous System Number of 216309.
Since this is an uncommon provider, we can discover more open directories by combining the associated ASN number with labels:open-dir.
The usage of EVILEMPIRE is unique enough that there are only 8 open directories hosted there.
One of those results is 77.105.132[.]27, which matches our search criteria and has already been marked as a known C2.
By browsing to the host page and looking at the directory contents, it appears to be hosting both Vidar and Lumma malware.
Summary – Autonomous Systems and Hosting Providers
Combining open directory hunts with unusual hosting providers can quickly lead to new results.
This works best when the provider is uncommon or well known for hosting malicious actors. So be careful when applying this technique to a large provider such as Amazon or CloudFlare. Large providers such as these can be associated with tens of thousands of results, which can be difficult to parse and extremely prone to false positives without additional filtering.
Consider that CloudFlare was linked to 38,614 open directories in 2023 alone. With Amazon being linked to a considerable 21,805. More statistics are covered in detail in “Dorking The Internet”.
Section 3: File Name Patterns and Regular Expressions
In the first section, we used static file names to pivot to additional open directories. However there is a much better way to do this with the addition of regular expressions.
Consider the search for “files named a.exe” vs. the search for “ANY single character .exe.” The second option is more generic (in a good way) and allows for more effective searching.
We can abstract the a.exe file name using regular expressions to instead search for any single-character executable. For more effective searching, we can even expand this to any single-character filename with the extensions exe, hta or rtf.
Consider the following file names from one of our previous searches.
The open directory contains 9 files with only a single character before the extension (a.dll, 1.rtf, a.hta etc).
Rather than searching for these names individually, let’s create a regular expression that searches for single-character file names with any of the exe, rtf or hta extensions.
We can create a simple prototype using CyberChef, and then add it to the services.http.response.body field.
Note that we’ll now need to utilise the raw HTML content and not the HTML rendering from previous screenshots, so we’ll be adding .*\” to both sides of our regular expressions. This accounts for the HTML syntax (shown below) and specifies that we only want files named a.exe, not those containing a.exe.
Below we can see the quotes “ before and after file names, which we should account for in our regular expression.
Taking the raw HTML into account, we can search for single-character filenames with the following query.
labels:open-dir and services.http.response.body:/.*\”\w\.(exe|hta|rtf)\”.*/
For those unfamiliar with regular expressions, here is a visualization courtesy of regexper.com
Executing this new search returns 57 results for open directories with single character file names.
One of these results is 20.98.129[.]89, which contains a single character e.hta file (matching our regular expression) as well as a very suspicious payload.exe.
Another search result is 1.92.96[.]35, where our regular expression has matched on single-character file names like f.exe, m.exe, m.hta, p.hta.
In addition to the matching names, we now have an open directory referencing cs4.9, which is likely a reference to Cobalt Strike Version 4.9. The cs4.9 string would be great to use for additional pivots.
Another search result is 38.206.173[.]58, which appears to be hosting ransomware due to the presence of unlocker.exe and READ_TO_DECRYPT.html.
There are numerous opportunities here for files that could be used to pivot to additional servers.
Summary – File Name Patterns and Regular Expressions
File Name Patterns in the form of regular expressions can be far more effective than static name searching. If you notice multiple file names with different but “similar” values, try using a regular expression to group them together.
Advanced queries utilising regular expressions will often lead to additional malicious servers.
Section 4: Combining File Extensions
File extensions can be another simple and effective way to identify suspicious open directories.
For example, the combination of an .exe and .hta file in the same open directory is rare and unlikely to occur in a legitimate directory. So we can use this idea to identify malicious servers. The same concept can be applied to a .hta and .ps1 sharing the same directory.
Consider one of our previous results, which contains a mixture of .hta, .png, .exe, .msi and .txt. We can use this combination (or a subset) to identify additional infrastructure.
We can build an query that searches for all open directories containing both a .hta and .exe extension.
labels:open-dir and same_service(services.http.response.body:*.hta* and services.http.response.body:*.exe*) and not services.http.response.body:*htaccess*
A few quick notes on that query:
- Same_service – This tells the search only to include results where the files were observed on the same port. We don’t want a server with .hta on port 443 and .exe separately on port 80.
- Not .htaccess – This is a legitimate file which matches on our wildcard search for .hta, we want to exclude this from our results without resorting to regular expressions.
Running that query returns 9 results, one of these is an open directory on 20.163.176[.]155.
This directory matches our search for both a .hta and .exe file on the same service.
This open directory on 20.163.176[.]155 contains multiple “update” files that are marked as downloaders by VirusTotal. So we’ve encountered another server containing malicious files.
The open directory also contains a new pattern of ps1 and exe files, so we can adjust our query to search for this and identify further suspicious results.
This query will search for open directories containing both a powershell script and executable file.
labels:open-dir and same_service(services.http.response.body:*.ps1* and services.http.response.body:*.exe*)
The search returns 84 results for open directories containing powershell scripts and executables.
One of these results is 96.255.173[.]42, which contains both .exe and ps1, as well as a collection of other suspicious files likely related to the PowerSploit Toolkit.
Bonus Pivot On Filename Patterns
The previously shown directory contains multiple files with “power” in the file name, followed by a ps1 or py extension.
Using regular expressions, we can turn this into a generic query for any open directory containing .py or ps1 and a file name beginning with power.
We can first prototype a regular expression using CyberChef.
With the regular expression working, we can search for .ps1 or .py files whose file name contains power.
The search returns 7 results, one of which is 95.111.214[.]111.
We can see that this directory contains even more files related to offensive Powershell toolkits.
Another result is 116.114.20[.]180, which contains powercat.ps1, amongst other suspicious file names.
The Powercat file is likely a reference to the Powershell implementation of Netcat.
Summary: Combining File Extensions
File extensions can be as useful and simple as file names when searching for open directories.
If an investigation shows an open directory with an unusual combination of file types, try utilising that in your query. You’d be surprised how simple this is, yet how often it can lead to new malicious results.
Conclusion
We’ve now shown 4 useful techniques for identifying and hunting malicious open directories. These techniques are extremely effective for finding and hunting open directory infrastructure used by Threat Actors.
Although this is not an exhaustive list, these techniques, both on their own and in combination are amazing methods to have in your investigation toolkit.
With the exception of regular expressions, all of these techniques are available to try out in the Community edition of Censys.
And for those who love statistics and deep dives, check out the Dorking The Internet report by Censys. This enormous 31 page report takes a look at all the nitty gritty of open directory exposure, including both how and where they are being found in both malicious and legitimate scenarios.
Bonus Related Queries
For Community Users
ANY open directory (Link)
labels:open-dir
Open directories containing a.exe files (Link)
labels:open-dir and services.http.response.body:a.exe
Open directories containing “Payload.exe”
labels:open-dir and services.http.response.body:payload.exe
Open directories referencing CS4.9 (Link)
labels:open-dir and services.http.response.body:cs4.9
For Users With Regular Expression Access
Open directories containing “Power” files with ps1 or py extension
labels:open-dir and services.http.response.body:/.*power[a-z]+\.(ps1|py).*/
Open directories containing single character RTF, HTA or PS1 files
labels:open-dir and services.http.response.body:/.*\W\w\.(hta|rtf|ps1)\W.*/
Open directories referencing any version of Cobalt Strike in format csX.X (Link)
labels:open-dir and services.http.response.body:/.*\W(cs|cobalt)[34]\.\d(\.exe)?.*/
Open directories with short numeric names for PNG files
labels:open-dir and services.http.response.body:/.*\”[0-9]{1,5}\.png\W.*/
Visit Embee Research
Go to Censys Search
