OSINT Threat Modeling for Managed Attribution: Part 2

Ntrepid headquarters, managed attribution solutions for government

Share this post

OSINT Threat Modeling for Managed Attribution: Part 2

In my last post, I briefly explained the methodology I use for threat modeling managed attribution (MA) systems. Now, I’m going to take it one step further and apply the process to a scenario for open source intelligence gathering: OSINT threat modeling.

For OSINT threat modeling, an operator’s mission would be to collect OSINT on discussions within a private forum on a major social media platform. The MA requirement is that the operator blends in with the general population of the group that tends to be highly paranoid and wary of outsiders. The operator also needs to avoid the social media company detecting them as an alias account. If they are discovered to be inauthentic, their account will be terminated, and they will have to begin working their way into the group again.  

Let’s start off with a quick recap. The threats against managed attribution (MA) are memorable through the acronym CAKED. 

  • Correlation of entities 
  • Attribution of actors 
  • Knowledge of operation 
  • Exposure of aliases 
  • Discovery of resources 

Categories of threat actors who could be creating those threats 

  • Unprivileged observers 
  • On the wire 
  • On the device 
  • In the conversation 

If the operator tries to attempt this mission without any attribution management, they are simply connecting directly to the social media site from their computer and lurking on the discussion. They would use their real phone number to satisfy any multi-factor authentication requirements.  

With this situation, there are a few obvious spots where threat actors could be positioned. The threat actor could be watching the phone or internet connection between the operator and the social network service. This could expose the existence of operational activity and attribute it to the operator’s organization. This can be mitigated by adding encryption and intermediate hops to the phone and data paths.  

Most social media companies actively work to detect and shut down “fake accounts,” so they are considered a threat actor, too. The company can clearly attribute the operator’s organization, the nature of the operation, and the identities of any aliases. This can also be mitigated by hiding the source of the traffic, ensuring that unassociated aliases use different paths.  

Finally, the operator’s target is a threat actor. They have access to the full contents and metadata of any message exchanges. Being part of a highly paranoid group, they will likely be sensitive to the possibility of aliases infiltrating their conversations. They will look for any clues that the alias is anything other than it claims to be. Such clues could be technical anomalies or non-technical OPSEC errors. Appropriate MA solutions can prevent many technical and OPSEC errors that could expose an alias. However, proper training and procedures is the only protection against some kinds of non-technical exposures.  

Applying those mitigations to the design may lead you to create an architecture like the one pictured below.  

In this figure, the MA service manages the system fingerprints and connects through a relay to the social media service. The phone connection is associated with the same location as the visible traffic, separating attribution from the operator, and a public email service further prevents the company from associating accounts with the operator. 

Some threat actors can see across multiple hops and connect activity across relays. That level of visibility could bypass this architecture. Fortunately, it is usually possible to identify those few entities and analyze their threat level individually.  

In the figure below, you may notice that by adding a CONUS exit point, we have also introduced new locations for a possible threat actor: they could be hiding on the wire between each element or sitting on the exit point. If positioned at the exit point, the threat actor could detect an operation and attribute it to the MA service. The threat actor on one of the connections between elements would only know that the operation is using an MA service and a given exit point, and that an exit point is connecting to a social media service. These new threat actors are usually considered acceptable risks and are easily mitigated.  

The process of threat modeling for managed attribution is an iterative process. You need to examine each element and vantage point to look for what threats are possible and decide to take precaution or accept the threat; any new mitigations need to be examined for new vulnerabilities. 

For a more detailed examination of OSINT threat modeling, you can watch the video below.