Mockbin and the Art of Deception: Tracing Adversaries, Going Headless and Mocking APIs

On September 4, 2023, CERT-UA revealed a meticulously planned cyberattack targeting Ukraine's critical energy infrastructure. The attack's modus operandi was distinct; it utilized deceptive emails containing bait links, luring victims into downloading a seemingly innocuous ZIP archive. This archive, however, harbored malicious files designed to hijack the victim's computer, redirecting data flows and exfiltrating sensitive information using services like mockbin.org and mocky.io. Parallel to this, Zscaler ThreatLabz identified a campaign—dubbed the "Steal-It" campaign—exhibiting striking similarities. Focusing on regions like Australia, Poland, and Belgium, this campaign also harnessed Mockbin APIs to exfiltrate NTLMv2 hashes. Intriguingly, the tactics, techniques, and procedures (TTPs) align closely with those exhibited by APT28 (also known as Fancy Bear). The convergence of these findings underscores an adversary leveraging public services in broad daylight, orchestrating sophisticated attacks, and continuously adapting to the digital landscape.

The Splunk Threat Research Team (STRT) delved deeper into the findings reported by CERT-UA and Zscaler. This blog walks through our process of reconstructing the key components of the attack, our experience with Splunk Attack Analyzer for rapid sample triaging, and our deep dive into paths linked to mockbin.org and mocky.io. Furthermore, we'll detail how the STRT gathered crucial data from Mockbin. The goal of this blog is to illuminate how different adversary campaigns can intersect, wield the same tools conspicuously over extended periods, and provide guidance on spotting such activities using Splunk.

Attack Analysis

How are mockbin.org and mocky.io being used?

Let's begin by understanding Mockbin and mocky.io in depth. Both Mockbin and mocky.io are invaluable tools designed primarily for developers and testers. They provide platforms to create custom endpoints, allowing users to test, mock, and monitor HTTP requests and responses. This can be especially useful when integrating libraries, testing sockets, or experimenting with APIs.

However, while these platforms have legitimate and beneficial uses, they can also be exploited by adversaries. By leveraging the persistent and reliable hosting capabilities of Mockbin and mocky.io, threat actors can conveniently host and retrieve their malicious payloads. This offers them a stealthy approach, as these services are typically seen as benign, making their malicious activities harder to detect.

In our detailed analysis, we observed a consistent pattern of adversaries exploiting mockbin.org as an initial point of interaction, often serving as the first click or download in their attack chain. One notable method involves embedding links in LNK files, wherein a PowerShell script is triggered to send web requests to mockbin.org. This, in turn, redirects to mocky.io, fetching the first-stage payload. More recently, we noticed a direct approach where Mockbin links are delivered straight to potential victims' inboxes. Once clicked, these links redirect the user to mocky.io for a zip file download. Delving deeper into the contents of this zip file, we identified batch scripts that further rely on mocky.io URLs to progress the attack.

The intricacies of this multi-stage attack were meticulously documented in the CERT-UA blog post dated September 4th. While the post dives deep into various components of the campaign, the concluding screenshot effectively encapsulates the different stages of the attack, offering a visual representation.

^{(https://cert.gov.ua/article/5702579, CERT-UA)}

We received two samples related to the campaign that include the batch file and decoy images. 

https://www.virustotal.com/gui/file/b30f229ca49c8c0cd734e47336eeb49a483920914093d36672c64d45481ee71e
https://www.virustotal.com/gui/file/749533eef943e019e1f6ccf61f36cc0939f7aa0c730bac84467d83441a0584f0

With the mocky.io sites currently offline, we weren't able to proceed with the subsequent stages of the attack. Drawing insights from the CERT-UA blog, had the sites been operational, an additional BAT and VBS would have been deployed to further the attack. Delving into the primary .cmd file provides us with the following insights:

Weblinks.cmd

The second bat file contained the following - B207a288-3e1f-42cc-b.bat -

Notably, one of the compelling detection opportunities lies in identifying any usage of mockbin.org and mocky.io within an organizational network.

Headless Browsing

Headless browsers have become a cornerstone tool for developers. In essence, a "headless" browser is a web browser without a graphical user interface (GUI). This means that it can access web pages, but it doesn't display them to users. Instead, it operates programmatically, often used for automated testing, web scraping, and other server environments where a visual display isn't necessary.

Benefits of Headless Browsers:

• Speed: Without the overhead of a UI, tasks can be executed faster.
• Flexibility: They can be run in environments that do not have a display.
• Automation: Ideal for automated testing frameworks.

Below are example usage of three popular browsers using the headless parameter. 

Google Chrome:

• Command: chrome --headless --disable-gpu --remote-debugging-port=9222 https://www.example.com
• The --disable-gpu flag is often needed, especially on Windows, to enhance stability.
• The --remote-debugging-port allows developers to send commands to Chrome via the Chrome DevTools Protocol.

Mozilla Firefox:

• Command: firefox --headless https://www.example.com
• Firefox has streamlined its headless offering, requiring just the --headless flag.

Microsoft Edge:

• Command: msedge --headless --disable-gpu --remote-debugging-port=9222 https://www.example.com
• Given that Edge is now based on Chromium, its commands closely mirror those of Chrome.

According to CERT-UA, the adversary leveraged the headless mode in a strategic manner. By running browsers in this mode, they could programmatically access the mockbin.org site, ensuring the redirection to the next stage of their attack. This tactic, while efficient, also has a layer of stealth to it; since headless browsers don't display their activities visually, it's easier for malicious actions to go unnoticed. The reliance on familiar developer tools in a malicious context underscores the craftiness of modern adversaries. They're co-opting legitimate tools, using them in ways they weren't originally intended for, all to further their malicious goals.

Headless browsing brings up an interesting detection opportunity as most endpoints across a fleet do not use it. This should stand out as non-standard behavior, but every organization is different, therefore we recommend baselining. A higher fidelity analytic could be used to look for headless and mockbin.org on the CommandLine together.

LNK Delivery

As outlined by Zscaler, the LNK method similarly uses Mockbin to redirect to Mocky and download the next stage. 

^{(Zscaler,2013)}

^{(Zscaler, 2013)}

Many samples on VirusTotal may be obtained that contain similar artifacts. For the purposes of our research, we utilized this.

In this instance, once the LNK is clicked it will use PowerShell to hit the Mockbin (https://mockbin.org/bin/de22e2a8-d2af-4675-b70f-e42f1577da6e/view) site which returns the NTLM relay. Clever, right?

There are many variances, and most date back to earlier this year. It wasn’t until about 2 months ago we saw the first Bin ID on VirusTotal being used similarly as CERT-UA identified in their September 4, 2023 post.

Expanding on the NTLM Relay 

In the midst of this, the STRT found two samples that matched what Zscaler had also identified. The two scripts on VirusTotal were defanged enough to where we could not run them. Unbeknownst to us at the time, Zscaler found this customized version of Nishang’s Start-CaptureServer.ps1. 

The samples:

https://www.virustotal.com/gui/file/5c08c1c1b7e089b172e30b9ad452bab7ce64ee48201f603fc96fd9c6e24db1dc
https://www.virustotal.com/gui/file/52951f2d92e3d547bad86e33c1b0a8622ac391c614efa3c5d167d8a825937179

Initially, our view was these were bespoke instances of the tool Inveigh.

With that, we created a proof of concept that writes the credentials to disk instead of sending to Mockbin:

https://github.com/MHaggis/notes/blob/master/utilities/FancyNTLMRelay/fancyntlmrelay.ps1

We compared the two instances. First is our new version which will write it to a txt file:

These were the two variations on VirusTotal:

And

Both samples on VirusTotal were specially crafted for use. As obvious as it looks, they are not being picked up by many AV engines as of this writing. 

This demo video showcases our version of Nishang’s Start-CaptureServer.ps1 script that logs locally. 

From PowerShell NTLM Relay to Mockbin

Changing gears a bit, we will now focus on Mockbin and its use in the campaign shared by CERT-UA. 

We initially started by viewing the reported URLs from VirusTotal. From everything we found on VirusTotal for the Mockbin domain, to using urlscan.io to gather additional Bin IDs, we were able to collect 26 unique IDs all related to the same activity reported by Zscaler and CERT-UA. We manually reviewed the content of each to validate it was the same as reported. 

Bin IDs

Below is the list of Bin IDs we gathered while digging into this. 

• 4063e80e-4c99-4c7e-8784-66804c906a60
• 31b1332f-8f5c-490e-8ec0-78e77b4e5709
• 31df6e74-9d7f-4759-b628-6424187c95d3
• 6cd1ea35-0211-4477-a7fc-8e4571b344b5
• bcaa7ea0-2fa4-4351-881e-dbf4dbead486
• 43a37cb6-2118-4c0d-8c14-0b2aaf14ff6a
• 61efbe8d-8747-402d-916c-6ebd50c9dc82
• 0279e826-fd08-4592-a9b6-0a86611cff30
• a7dc1a35-1b5d-40d1-ab8a-75291baf5a76
• 4dde8cac-e636-4c89-85b8-f41b085e0efe
• caaf15b4-a8d7-44bd-baa9-cedca95b216a
• 3619f974-701e-4ffc-93a4-68d0e22c82c9
• 8d432c43-f2ef-44f5-ac68-b473dbfe5bf8
• a18010d7-70c1-403b-b15c-7c669ea8841c
• 8d30e216-cc73-47a6-8deb-4f1d9cfa0a26
• 6a9bbefa-94dd-468f-9ce5-2fb5b8b0c509
• 84a2791a-6585-46ce-bc1c-e42a03538715
• 2e04b6dd-9e86-49ea-b08c-29312f0f2a39
• 7e3602b1-35d8-4bac-8dc7-b33471bc04a7
• f5c8bc48-a69e-4091-8fd4-8cfd966a1f03
• b8bdfad1-9902-4d19-856a-f65818ee6165
• de22e2a8-d2af-4675-b70f-e42f1577da6e
• 1a5c942f-4e74-4881-bb8e-1bca54aad3de
• de22e2a8-d2af-4675-b70f-e42f1577da6e
• 9ee0aeac-e308-47e3-a3ba-f91afd56a736
• 873377bb-b44f-478a-95f3-9cd747e1c6b7

As detailed in our analysis, the campaign often leverages mockbin.org as an initiation point, redirecting to mocky.io for subsequent stages. Upon extracting the URLs associated with this strategy, we found that the ensuing stages—whether zip files or other payloads—are currently inaccessible.

Mocky Access Logs

Mocky is free and open, therefore it allows us to request every script and access log being hosted by that Bin Identifier. We can do this via the website by going to the Bin ID and hitting the /log or /view. In addition, Mocky provides an API endpoint for each. For example, we can retrieve the log and view the data hosted. 

View a script being hosted at https://mockbin.org/bin/31df6e74-9d7f-4759-b628-6424187c95d3/view

And the log can be viewed at https://mockbin.org/bin/31df6e74-9d7f-4759-b628-6424187c95d3/log

Mocky also offers an API that allows retrieval of all access logs and hosted scripts. We collected all the Bin Identifiers from VirusTotal and subsequently gathered the associated logs. We've shared the script we utilized to aid researchers in further investigations here.

Once we collected data from each Bin ID, we reviewed the scripts. 

Most all of them are the same with the only difference being the mocky.io address. It begins by using a function “getBrowserVersion” to determine the browser in use. From there, it redirects to the next stage. Windows users with the presence of the string “win” in the user-agent, but not containing the string “wow”, and with the browser version above 100 will be redirected to mocky.io. Otherwise, directed to msn.com. 

In Splunk, we were able to develop a simple query to show geographically where most of the ClientIPAddress were coming into the mockbin.org links.

|  inputlookup extractedips.csv
| iplocation A
| geostats latfield=lat longfield=lon count

Security Content

Throughout our research process, we devised a new analytic story for Forrest Blizzard and associated prior analytics. Furthermore, we enhanced our analytic set by crafting two distinct analytics. These are designed to aid defenders in baselining the utilization of mocky.io and mockbin.org, as well as in detecting headless browsing within their environments.

Headless Browser Usage

The analytic outlined below taps into endpoint process and command line data to pinpoint instances of headless browsing. Its primary goal is to assist organizations in establishing a baseline of normal activity, thereby making it easier to discern potential threats.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
  as lastTime from datamodel=Endpoint.Processes where 
  (Processes.process=*--headless* AND Processes.process="*--disable-gpu*") by Processes.dest Processes.user Processes.parent_process
  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id sourcetype
  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Headless Browser Mockbin or Mocky Request

The second analytic we developed aims to detect headless browsing that directly accesses the mockbin.org or mocky.io sites, aligning with the findings shared by CERT-UA.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
  as lastTime from datamodel=Endpoint.Processes where 
  (Processes.process=*--headless* AND Processes.process="*--disable-gpu*" AND (Processes.process="*mockbin.org/*" OR Processes.process="*mocky.io/*")) by Processes.dest Processes.user Processes.parent_process
  Processes.process_name Processes.process Processes.process_id Processes.parent_process_id sourcetype
  | `drop_dm_object_name(Processes)` | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Closing Thoughts

This campaign offers a striking testament to the evolving tactics of modern adversaries. Their ability to repurpose legitimate developer tools and public services for malicious ends presents both a challenge and an opportunity for the cybersecurity community. As threats become more sophisticated and covert, our ability to identify, analyze, and counteract these strategies becomes all the more crucial. The discoveries shared in this analysis underscore the importance of continuous vigilance, research, and collaboration. By understanding the methods of our adversaries, we can better equip ourselves to anticipate and mitigate future threats.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Michael Haag for authoring this post and the entire Splunk Threat Research Team for their contributions alongside the community: Teoderick Contreras, Mauricio Velazco, Patrick Bareiss, Nasreddine Bencherchali and Jose Hernandez.