Dirty Networks, Clean Data: Managed Attribution in Triage Environments

This is the part three of a five part tradecraft series on managed attribution strategies. Don't forget to check out parts one and two.

So, you’ve decided to create a managed-attribution platform. Maybe you bought some burner phones and installed Qubes. Perhaps you’ve entered the multicloud and built a complex web of VPNs and configurable containers that you can build and destroy at will. The power is intoxicating. But what’s next? Sure you can get on the internet and read Wikipedia safely, but you could already do that.

If you’ve come this far, your goal is likely to inform and enrich your existing business processes with third-party data that may not be safe to upload to the company shared drive. In this article, we’ll go over some things to think about before, during, and after ingesting data from outside of your organization.

Data Processing & Enrichment

Many young analysts and investigators have endeavored to consume the vastness of the internet’s data only to later realize they neither had the storage capacity nor the legal justification to keep it. For these reasons and more, data processing, enrichment, and analytic filters often become necessary components of a managed attribution strategy. 

Some of these tasks may be done on overtly managed infrastructure that is simply firewalled and segregated from sensitive corporate assets, frequently referred to as a ‘dirty’ network. This is the realm of digital forensics and reverse engineering, as well as some log analysis and password cracking—all of which have vastly different requirements. In other contexts, it may involve triaging communications collected from an illicit forum to ensure only legally defensible and operationally relevant data is retained. (NOTE: We’re only talking about data triage here. We’ll discuss the complexities of data collection in the next installment.)

Some tasks, such as dynamic malware analysis, inherently incur higher risk and require a more thoughtful approach, while others such as password cracking are low-risk but necessitate greater computing resources than a local container may be able to provide. Most require bespoke software that may not be compatible with your corporate security protocols. If you've made it this far, chances are you're familiar with the risks they involve. If not, now would be a good time to start learning.

It's best to avoid external connections from an analytic environment, especially a triage network.  Exceptions are often made for convenience, such as the need to query vendor APIs or update software; however, such overt connections should be limited whenever possible. Rather, it is preferable to wait until your data has crossed the boundary into your enterprise environment for vendor enrichment (see below). Software updates on closed networks should be implemented through mirrored repositories within a strict Supply Chain Risk Management (SCRM) framework. 

Where possible, hardened ephemeral containers such as Kasm should be implemented in order to ensure each session starts fresh and containers can be updated via CI/CD processes. In this scenario, backend data stores should be tightly bound to container environments to ensure they are not exposed to outside connections. How you implement this strategy depends largely on your organization’s threat model. In some instances, even storing a license key attributable to a corporate payment account may be unpalatable, thus requiring alternative solutions.

Another common requirement includes the need to document results of your analysis and prove your work. Tools like OBS Studio, OpenShot, and/or DaVinci Resolve are useful in this context, while many virtualization platforms can also be configured to record sessions natively. As outlined above, licensed software can become as much of a liability as it is an asset to a high-risk OSINT investigator. There are countless examples of popular, yet poorly configured OSINT tools that become the indicator used to identify and manipulate investigations. In a worst-case scenario, they may even leak a user’s identity or affiliation posing a physical threat to researchers’ safety. We’ll go deeper into this in a future installment.

Subscription-based Accounts

There are a variety of use cases involving subscription-based access to information not otherwise publicly available. Many subscriptions have free-tier access and employ minimal verification, allowing easy access to valuable data in moderation. Premium providers may require their subscribers be vetted prior to granting access to potentially sensitive data. Often, service providers have complex Terms of Service limiting who may use their service and under what circumstances. All of these types of services are a double-edged sword.

Subscription service providers have done the hard work of collecting valuable information in bulk and shielding your intent from adversaries by allowing you to avoid interacting with risky infrastructure. By necessity, a subscription provider may also correlate every search you ever run and every record you see. This type of service relationship is best limited to trusted providers capable of obtaining approval for integration into your corporate environment. This is the cleanest way to ensure data enrichment needs remain confidential. If you must perform enrichment elsewhere, the following are but a few of the most significant considerations.

Not all service providers are created equal. Some offer a free tier hoping to attract paid subscribers, while others privately aggregate data about their users to sell to third-party vendors. Many noteworthy subscription services share your data publicly as a stipulation of the service in furtherance of broader community research objectives. If your super-secret sock puppet obtains a copy of a bespoke piece of malware or private link from a bad guy, submitting it to a platform like VirusTotal, urlscan, or Hybrid Analysis may result in it being shared publicly or with a broad community of researchers and potentially compromise your singular access.

If you’re unsure of how a provider uses your data, or if you think you already know, read the Terms of Service and Privacy Policy! There is no better reminder of this than in 2017 when 22,000 people agreed to perform community service in exchange for free Wi-Fi. In other interesting privacy documentation, Activision may still collect information about the way people smell. Why? And who are they sharing that with? Is there a Big Deodorant conspiracy I don't know about in the gaming community?

All jokes aside, it’s important to understand how a provider will use your data before you can decide whether using their service is an acceptable risk. This cost-benefit analysis will help determine whether your business can approach them openly as a trusted provider and incorporate them into your corporate environment, whether you can mitigate the risk through compartmentalization, or whether they should be written off altogether. Above all else, consider the legal implications of your use case. While a large corporation may be willing to go to court over ToS, a small non-profit probably isn't.