Background
In digital forensics and incident response (DFIR), you learn about volatile data, and a concept called "order of volatility." When I was learning DFIR, it was never taught to look externally. In fact, a lot of the literature of the day written by my predecessors, discouraged things like interacting with adversary infrastructure at all. That thought process was still common when I came to the private sector.
However, I believe security professionals can benefit from thinking about "order of volatility" to include information from sources other than those within the direct control of the security team. This includes everything from free and commercial data sources to adversary controlled systems. I have no shortage of success stories tied to this practice.
These days, collecting data from external sources to include adversary infrastructure is a normal day for high end commercial intelligence teams, so I wanted to create a small scale challenge that illustrated the need to go beyond the binary and to simulate missed opportunities to encourage a sense of urgency when pivoting and exploiting leads.
The Challenge
![](https://static.wixstatic.com/media/e5f5a7_bb24c9136475423f863bfc11d1d8a5ec~mv2.png/v1/fill/w_980,h_524,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_bb24c9136475423f863bfc11d1d8a5ec~mv2.png)
I tweeted out a base64 encoded gzip archive that contains an a Mach-O 64bit ARM executable. Here's a quick triage on the command line. (Base64 encoding at the end of the blog for brevity)
pbpaste | base64 -d | file -
pbpaste | base64 -d | gunzip | file -
![](https://static.wixstatic.com/media/e5f5a7_06dd225915814aba8b0d466b019b4ecb~mv2.png/v1/fill/w_980,h_449,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_06dd225915814aba8b0d466b019b4ecb~mv2.png)
Here's a quick triage using CyberChef.
![](https://static.wixstatic.com/media/e5f5a7_7f974f9389f64c48accbdfcf3a42a61b~mv2.png/v1/fill/w_980,h_902,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_7f974f9389f64c48accbdfcf3a42a61b~mv2.png)
If you are capable and set up to reverse the binary, excellent. The program downloads a file "coupon.txt" from a server and prints it to standard out (the terminal). However, as part of your triage, you should consider identifying interesting strings using your preferred tools.
strings coupon
Which would reveal:
http://34.16.152.242:80/coupon.txt
http://%99[^:]:%d/%99[^
Invalid URL format
socket
Invalid hostname
connect
GET %s HTTP/1.1
Host: %s
send
You instantly should see this URL and get excited.
http://34.16.152.242:80/coupon.txt
By the time you have retrieved this binary, this resource is no longer available. That said, it was available. At this point you are faced with looking for other clues in the binary, quitting, or looking externally. Looking for additional clues in the binary will not be fruitful, you probably shouldn't quit after five minutes of triage, and looking externally is a very logical next step for analysts and researchers.
If you use a commercially available malware repository, such as VirusTotal, you would find leads, and you would find additional coupon codes, but none of them would be valid. However, I wanted to make the exercise accessible to those who do not have paid accounts, and I also wanted to force people to pivot beyond the standard malware repositories everyone uses.
When I encounter a network resource, I want to know everything I can about it. Some questions I frequently want to know the answers two include:
What files are affiliated with this server?
What URLs are affiliated with this server?
What services were hosted on this server during, before, and after the relevant time?
What domains resolved to this server during, before, and after the relevant time?
What other entities (files, servers, domains, etc) share characteristics with this server?
These questions are high level and not comprehensive. In this scenario, we already know or believe the specific adversary infrastructure is not providing the response we expect. The window of opportunity to collect the information we wanted directly from the system live has past. Thankfully, there are other opportunities to understand what the infrastructure looked like during the timeframe we are interested in, such as with commercial internet scanning sources like Censys, Shodan, and BinaryEdge.
![](https://static.wixstatic.com/media/e5f5a7_06dfe385439444f7b5552592c0f30922~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_06dfe385439444f7b5552592c0f30922~mv2.png)
If we enter the internet protocol (IP) address into Censys' host search, we find scan results. We see we have an secure shell (SSH) server on the default transmission control protocol (TCP) 22 and an Hypertext Transfer Protocol (HTTP) server on the default port of TCP 80. We remember that our binary downloaded a file using HTTP on port 80, so this is consistent with what we would expect. We see the timestamp for the last scan of the HTTP server is 01/15/2024 21:43 UTC. We must have just missed the opportunity.
If you're experienced in infrastructure analysis, you're excited to see "Directory listing for /" which is one of a few different page titles that indicate what is commonly referred to as an "open directory" or "open dir". Censys and others have even begun tagging servers with a searchable label for things like open directories. Many entities to include adversaries regularly leave their resources exposed. If this open directory is relevant to us, there may be the file we are interested in (coupon.txt) and possibly other files. We click "View All Data" to see what else we can learn.
![](https://static.wixstatic.com/media/e5f5a7_77cb8f549d8c4f8b8c399a05e0782d75~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_77cb8f549d8c4f8b8c399a05e0782d75~mv2.png)
We see that the directory listening includes the file we were looking for (coupon.txt). We do not see any additional files listed in this current listing; however, Censys does have history which is accessible to paying customers. History would not have shown any additional content, but it would help understand how long the server had been up, which is a behavior that may be worth understanding.
We now have high confidence that these scan results are relevant to our investigation or research. We have coupon.txt in an open directory on an HTTP server listening on the port that our binary attempted to download coupon.txt from.
We're inquisitive and on the aggressive side of security (you're on imposecost.net), so we're not happy we have missed this opportunity, and we know adversaries are creatures of habit, so we want to see if we can identify any similar looking servers as well as ideally find one that is live.
![](https://static.wixstatic.com/media/e5f5a7_c03cd8764f3c42469a69f45f0a5e56da~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_c03cd8764f3c42469a69f45f0a5e56da~mv2.png)
Content hashes are considered low hanging fruit. They can be very useful, or they can be very noisy. Either way, they are brittle just as hashes are seen as brittle in the traditional "Pyramid of Pain." However, for quick wins, why not search them and then return to make more resilient queries? Note, some open directory listings may include the IP address and timestamps which means it's unlikely that you will find the same response on a different server. I say unlikely, but also I have seen it. Networking can be highly deceptive at times.
If you clicked the magnifying glass next to the hash, you would have been met with a second server.
services.http.response.body_hashes | sha256:6e3393967f6dd15d13d9725bcf21c60e3362c179916696cb681e237e0ee168c0 |
If you would have clicked on something more broad, such as the HTML title, you would have been greeted by thousands of unrelated but possibly interesting servers.
services.http.response.html_title | Directory listing for / |
You can search by a variety of things, and you can even combine characteristics and use regular expressions if you have the right license; however, I'm not providing a full class on Censys; it's powerful. As a "better than a hash" query, we look for "coupon.txt" in the response body.
services.http.response.body:"coupon.txt"
![](https://static.wixstatic.com/media/e5f5a7_eefd7140da784b20a1c590876dceb525~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_eefd7140da784b20a1c590876dceb525~mv2.png)
We see that we have our original server and the additional server of 34.18.62.146. Note: When crafting queries, you typically want to see your exemplar (the entity you are templating off of) within the returned results as confirmation that your query returns it. However, with Censys there is an occasional 'gotcha'.
As a Censys capability and limitation understanding, Censys scans the internet very frequently on an extensive range of ports; you can expect that they will discover services daily around the clock; however, a limitation is the time between discovery and indexing that is searchable. By that, I mean that if you visit host results by IP address and see interesting results yet that host won't return when you search for content related to it, possibly even for a whole day. This isn't great, and Censys is aware of it; it's just a known limitation; every source has unique capabilities and limitations. I ensured the relevant results were searchable before launching the challenge.
If we review this new host, we find we have the exact same services,
![](https://static.wixstatic.com/media/e5f5a7_06dfe385439444f7b5552592c0f30922~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_06dfe385439444f7b5552592c0f30922~mv2.png)
When we review the HTTP server results, we find we have our one and only file in the open directory, coupon.txt.
![](https://static.wixstatic.com/media/e5f5a7_a8453b8a41ea45109192ded920e57248~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_a8453b8a41ea45109192ded920e57248~mv2.png)
We're excited at this point, and we quickly move to live interrogation of the server. Again, actor controlled infrastructure means they can take it down at any time. If there are more than just the original file, we will want to triage and prioritized acquisition. Note, just because THIS scanning result only has one file in it does not mean that is what the server currently reflects; there could be additional files, or our file could be missing. Note, you are responsible for every packet you send both for your liability and your operations security; this blog isn't a course on operations security.
We acquire the file, which contains the valid coupon code, and we order ourselves some sweet merchandise from imposecost.net.
![](https://static.wixstatic.com/media/e5f5a7_f22711d69937489ba7b5b69609870de9~mv2.png/v1/fill/w_980,h_449,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_f22711d69937489ba7b5b69609870de9~mv2.png)
Alternative with Shodan
Shodan is not anywhere near as robust as Censys; however, it could be used to get the job done in this case.
https://www.shodan.io/host/34.16.152.242 to identify how the host looks.
![](https://static.wixstatic.com/media/e5f5a7_87be3e1b1f3a47d1a02bb5778b3a1f99~mv2.png/v1/fill/w_980,h_281,al_c,q_85,usm_0.66_1.00_0.01,enc_auto/e5f5a7_87be3e1b1f3a47d1a02bb5778b3a1f99~mv2.png)
Reviewing raw data from the results:
![](https://static.wixstatic.com/media/e5f5a7_67dcb4328fb84ab68ec8c5e9c199fca2~mv2.png/v1/fill/w_980,h_296,al_c,q_85,usm_0.66_1.00_0.01,enc_auto/e5f5a7_67dcb4328fb84ab68ec8c5e9c199fca2~mv2.png)
Pivoting on the page hash: https://www.shodan.io/search?query=http.html_hash%3A88554995
![](https://static.wixstatic.com/media/e5f5a7_db28624290774d9db0570ba9e3e0aae9~mv2.png/v1/fill/w_980,h_595,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/e5f5a7_db28624290774d9db0570ba9e3e0aae9~mv2.png)
The Challenge Base64
H4sICKgfp2UAA2NvdXBvbgDtnXFsFFUawL+Zbeu2trBtCXgV6CKpqUC6tMVSatubCg1t4Ghte7keqMN2u2XXbWfLzhRawbAnx50XvTsm550kHofmNG4VExWjt8epRBMhhkSXiBBzZ7YYk20ud9GAiYtg/d7Mg75OQY33j8l9v/bL933vfe97733z2v/mzbsX//NVIYAEiIxSjOLNAdgHXtYEP0JpQ1HVzpb1rZtbuzpgFtLsplmwPA9JLE9Pa2/PNcYrjgHcz+WSw5tV1QiOGtNhznyhO+x8n8rTvizmzYG46Kqqboz06dfN19ts50sIvpjPzfMVXh0f0I1YWNt2nXzwYzvfQcEXkWe6OH5E2xnW+tWwNhC9Rr4neL6tgu/MIcKewwErz7qWnhZ1bcembjub4ngODu3iwmI81vhtUeExXDdfHKbzuIT4PJQ5jnXZ52xj+6YNrevar+wx7lgXTziaa2sJZp6/VRjh4XErsaOW+yt/gQJ2bW5CCaFfyvayF+A91DeidMLMnDLfsweuz4EHARZfo53tzQv2ufCN6DHfYLjP1z822M/7b+br8B258MzSX9b/9qnTseeWbJo4WMPHSVeyyHMs26qd9JVrmWM9lbg/az93zJyfzVvP52D7kJrqc1nWq2tB6R7TjeBQ1Z1VuK5wnz3uVp5/K9bHjfo27rN6MRZxP411O/Bd/vAJgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAI4gfMpejr45d3SeOX14I59dbClBvgBXe+knVLSjaxd/EXU1sgiW373VKjmVkO2fRyJTvpAjNxXkpVSpDN1EpmZS5grCtVmQ9ZCWOXPNJoHgd41F0I2zMLDpWFJFiN7fOs3EVKFjC3FXeh0UxgXCXEuzI4TxxjFLSXoMgoR7AvvQGSmQ1K0p0L1ZkbDpW5eS5c+n5Y12T+RRg/jO1taCdKi+tZTKZDSUITlNzP1tIIJZnVkGTtk6uVZOItV2p8afGoXAwmm/NJ3M9DLA5wzWe+Yc1bm8xdwpzdGJPG9T2J+WQ53rWd5ci5xloTTaYujGtl62B1ZHXDOlr1xDqm9WIzXcrqGO+a8EHyweb4KReOD5xoMu9i9ShVsqwemVpIsrkm0P/YpyTPueDZdK2SDNjzvzhrfqXZ7Bbmr8B2ia99QpdMOc7miXd1YkwGc00yWY/PXsJ6HD9UlpDtXGmMterQ02z2sPWU4xkoZ+cFPmPPuo3PabVhbdke2f6sNYSazdtxDOs/NzW1gM19C/rsjFljtuC+yiE5vvfeL8Rz6Jby/22dI7Bzl1jzKkk8r+blXS3jl6JvJo651A+m1kIK1zM2Wa6M4fxj7gfcpe4l+cvYGcA+k8V4MK9Hxucpl9t2nmCXCPZ8wS4T7MWCfYtg3yrYywS7SrBrBLtOsBsEu9m2Q4Yx3ODz1a6qqq6rqr69pqpmVU1D/UpfIDoyHNWqjFEDeEjFmjVb7m24p6Gi3zYL7oF2bYd/MNzv/WnXRu9ANDbkNwpAjwYiQeNqVyiqG5p/KFgAgaimBQMGrG/t8Vbo3raenk5fdVV1UUEbhjRgU1FBEQ4Pav1gWRXWS+nsFduF/H+IqNk7veydXwVsYe+lA8x+jZ69N1yI0fP4W+EnZZA87C14j/iauCcucS1z7eI6h+tcrvO4voFrN9f5XBdwfSPXhVwXcT2H67n2xPFv/KdJEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEP9HeMH+9vl+sL/tLX7WO0ewb3LaSt6MCwes76bLKJhQWodyH0oc5XcoT6C8hHIC5SxKBuUCG4M/HhQvCvtgu6qq+nAsrBkDaiAUsVzDH4gwRx3whwdntmwb8cf67ab+YCw2DGpgMKoHUfHbFtQBOxmoYS1oqMNGVAN1GEOjMdS8KxYM7ADVunpB5fc3qLoe8GvYpxuxwaBmafzFBatQwjZrfxw+swMtdSikBkeDgREjqIaCflwI5A/5wxoUAQactK5OOIoyB7e3qnn62/JzJc/Vus23fPtOhyt3PkjCo1ju8JscfqfD3+Lw+xx+xOEbDn+Pw/+1w/+9w/+jw3/c4f/V4T/n8I84fHb/BDt77J4JdscEu1+C3S3B7pVgd0qw+yTYXRLsHglWxWKUEmEcK3re9xjvxcM0+3Gq1uP8gR9NVe3o7t7pH27XjOq6K3W8+FHhMSzrH2C6tvOwjf2V7gE5hx1EdhRVlF7ej6Xam/bKUAjfCflTbkj2nSnw4a8ef//uE7u7R/+hnxz/2yIYPbzn1b9/dLb2k3Mlj0Te+fPW5/ccfqk3+vbkwLGcM6lURO7ozZ3a/fLu+/d9+NrDbb9Z8cy39Z+ffzDY++KxluPn29/4xH3XxL8qH/j5xI4Dt9V9Xpla0/F03eG2kzsXPPzm0t3//NNjy38S+VIvf9X8Wd0Kz6bLl3a90NfY+L/O/239/z1S1v3Y0bl3LnxlctHmkvHTY02n/NsiYyMp5Wh236MbI1axvgZoyKAneIUAAA==
Comments