The Key to Deobfuscation is Pattern of Life, not Overcoming Encryption

The Internet is a large and complex system, composed of hundreds of thousands (if not millions) of separate administrative networks. The Classless Inter-Domain Routing (CIDR) Report [12] measures upward of 931,903 separately routable network prefixes that are distributed across over 74,728 distinct Autonomous Systems (ASes), as of May 2023 [12]. In order to use our methodology to deobfuscate network sources that are using Privacy Preserving Technologies (PPTs), measurements must be made at specific locations along the network paths between clients and the services they transact with. Because PPTs operate in very different ways from each other, our generalizable approach leverages knowledge of how these technologies specifically operate and coarsens the Internet’s complex technology. From the starting premise that being able to observe all network paths throughout the Internet would be infeasible but would enable deobfuscation, we have constructed a methodology to identify what specific subset of locations are necessary and sufficient.

The intuition behind scopes is to project the protocols’ control flows that are being used. In order to transact with an Internet service (such as a message forum), users first perform Domain Name System (DNS) resolution [10], followed by a transport-layer connection to a service (e.g. a message forum service). Each of these stages can take on different forms that depend on how service operators deploy their infrastructures. Some web-based message forums may use Content Distribution Networks (CDNs), some may use local instances at fixed locations. Similarly, some DNS providers offer resolution services from single networks, and some distribute across many locations. Furthermore, there are vast and complex topologies of inter-domain routing networks that often exist between endpoints of communication. In order to accommodate the varying degree of complexity in different networks, Scopes quantizes the protocols’ communications into general regions (illustrated in Figure 2). For example, when a user configures a public DNS resolver, and that service iterates through the DNS delegation hierarchy to resolve the domain name of the website for a message forum, we break this into the following Scopes:

• •

  The user’s Access network, or their Internet Service Provider (ISP) scope: where all of a user’s traffic originates and returns to.

• •

  The Access-to-resolver scope: the set of inter-domain networks that connect the ISP to a public resolver.

• •

  The public DNS (pDNS) resolver scope: the network(s) responsible for operating the DNS resolution service.

• •

  The Resolver-to-Authoritative Zones scope: the potentially large portion of the Internet where inter-domain transit routing occurs.

• •

  The DNS root zone scope: the networks responsible for DNS resolution of the root zone.

• •

  The Top-Level Domain (TLD) scope: where resolution of a given TLD (such as .com, .edu, .org, etc.).

• •

  The Second-Level Domain (SLD) scope: the specific authoritative zone for an Internet service (such as gmu.edu, dhs.gov, etc.).

Next, we use a similar projection method to model the control flow of a user transacting with an Internet service. The scopes involved in these transactions are:

• •

  The user’s Access network (ISP), again.

• •

  The Access-to-service scope: an amalgamation of the large set of inter-domain networks that connect users’ access/ISP networks to a specific service scope.

• •

  The Service scope: the specific network(s) that an Internet service (like a message forum) are operated on.

In addition to the above scopes that befit a basic Internet transaction (whether an HTTP [13], HTTPS, TLS [3], etc.), our Scopes methodology includes semantics for when other common PPTs are used. Some PPTs, such as DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH), implement their protections along the same control path as plain old DNS (poDNS). As a result, these PPTs make use of the same network scopes that are used for poDNS. In contrast, however, some PPTs use different control flows. For example, Virtual Private Networks (VPNs) create encrypted tunnels between endpoints. One common form of VPN is for clients to encrypt network traffic and send it to a VPN provider, and for that provider to act as the source/destination of the resulting (unencrypted) network flows across the Internet. This has the effect of making the VPN provider’s network appear to be the endpoint of clients’ Internet traffic, but results in tunneled communications between the provider and the client. To accommodate this PPT, we are able to extend the existing Scopes to include:

• •

  Access-to-VPN scope: where VPN-tunneled traffic is sent from a client’s access/ISP network to the VPN provider.

• •

  The VPN Provider scope: where encrypted tunnels terminate, and where de-encapsulated client traffic is sent to Internet destinations (appearing to come from that VPN endpoint/egress).

• •

  The VPN-to-resolver scope: which is a similar amalgamation to the Access-to-resolver scope (defined above), but separated in our model as it may have some degree of disjointness from other transit paths.

Some of the scopes that are necessarily involved in communications are inherently composed of single (or a small number of) administrative organizations. Examples include the ISP scope, to DNS root zone scope, each TLD scope, each SLD scope, VPN provider scopes, and the Service scopes. We classify these scopes are low-order scopes, because of the low-order of administrative entities that they contain. While the administrative diversity within these scopes is small, the Internet is composed of many instantiations of these low-order scopes. Conversely, some other scopes amalgamate large numbers of inter-domain ASes. Examples of these include the Access-to-resolver scope, Resolver-to AuthZones scope, and the VPN-to-service scope. We broadly classify these other scopes as amalgamation scopes.

This subsection is provided to give an overview for the high level steps of the algorithms used. Detailed pseudocode for the algorithm is provided in Appendix A and in depth steps describing why each step was included, the values used for each algorithm and the process taken to arrive at each value is provided in the following subsections.

The model used for preprocessing the data and deobfuscating users to IP addresses follows the following stages. The hypothesis behind this approach is that when users communicate online in a live discussion, they leave traces of their communication throughout the Internet. These traces are time-varying signals, time series, which can identify the user. These time series persist to varying degrees even when users attempt to hide their identity with PPT. These identifying features’ performance can be compared, and the degree of privacy per scope can be quantified.

1. 1.

   Data from PCAPs is grouped on a per IP basis: if the IP is seen in the packet or occurs within a time window of other packets being sent (Appendix Algorithm 1 Lines 1–15)

2. 2.

   Feature selection based on available scopes (Appendix Algorithm 1 Line 17)

3. 3.

   Sliding-sum over features extracted for each scope (Appendix Algorithm 1 Line 18)

4. 4.

   Features are transformed using Topological Data Analysis-Persistence Landscape to capture multivariate PoL (Appendix Algorithm 1 Line 19 and Appendix Algorithm 5)

5. 5.

   Above steps are repeated for features of the service of interest (e.g. a message board) (Appendix Algorithm 2)

6. 6.

   PoLs seen in scopes are compared in PoL of the users on the service of interest using normalized cross-correlation for the time the persona was using the service (Appendix Algorithm 4 and Algorithm 3)

7. 7.

   Time series with the highest normalized cross-correlation are determined to be the same persona. (Appendix Algorithm 3)

First the time series on a per user basis must be created from the raw data available at the scopes. Our methodology is designed to ingest packet captures from separate network scopes, $Scope\in\mathbf{Scopes}$. All scopes were included initially for the experiments, and subsets of scopes and features were evaluated to provide recommendations for deployment. The model accepts PCAPs, although other formats that capture the same features can be used. Data is grouped into data frames, tables/arrays used by machine learning algorithms, by IP address. This grouping isolates different user’s features before transforming them into time series. Each IP address’s POL also captures information indirectly related to them (e.g., communications that could have resulted from a client communication/other client communication that the client could use, estimates of cached data). It is only possible to determine if one packet is related to another with complete knowledge of each system involved. As the goal of this model is to work without complete knowledge of every system, it must make an educated guess if a packet is related to other users. The experiments presented here use a simple model for this purpose and use steps later on, TDA, to attempt to remove noise in the data. A small time window is used to detect data that may be related to an IP address but does not have the IP address in the packet. A packet is related to the IP address if a packet from or to the IP was sent within the window of the other packet. Equation 1 defines this set of packets per IP. This is to best estimate the information that could influence a client’s state. The time window used is based on the DNS TTL for the domain/message board of interest. This process is carried out for each scope individually because different features may appear different and have varying degrees of important information encoded. Pseudocode for this step can be found in Algorithm 1.

Feature selection is then performed on the dataframe to preserve only the most performant features (e.g., IP packet length, per-flow inter-segment time spacing). A complete list of features extracted and tested can be found in Table I. These features were selected because of their ability to be transformed into time series and contain state or personal information. Additionally, previous work has shown time and packet length as key identifiers in machine-learning models for deanonymization [14] [15]. Deployment of the model does not require all features from this list. Each feature was tested independently and in combination with other features. Not every feature is available at every scope, and some PPTs block our insight into some features. If this happens, the feature is removed from evaluation at the given scope in these cases. This is done by detecting features that have zero variance across all clients.

Based on the extracted features in each scope, the model transforms each feature per scope per IP into a time series using a one-second sliding sum with a one-second skip as seen in Equation 2. This is done to transform tabular data into a time series. A rolling sum was chosen to avoid losing any variability in the communications. A one-second time window was chosen through a grid search of possible values. These time series can be subselected to form different univariate and multivariate time series.

If a multivariate time series is chosen, it must be transformed into a univariate time series. This is done using the techniques from topological data analysis in this evaluation. Specifically, the $L_{2}$ norm of the series’s TDA persistence landscape (TDA-PL) is based on the work done in [16]. This method was chosen over others because it has been shown to be able to capture the topological and geometric information of multivariate time series for similar problems. Additionally, the output of the persistence landscape function exists in a measure space under the $L_{2}$ norm, allowing it to be used with traditional machine learning algorithms and techniques.

The method takes an input multivariate time series, $t$, and splits it up using a sliding window with user-defined size and skip, such as in Equation 3. This results in a series of point clouds. For each of these windows, the Vietoris-Rips filtration, rips filtration, calculates the persistent homology in the form of a set of birth-death pairs. Persistent homology will compute topological features of a point cloud by building up a simplicial complex of the point cloud and capturing how the topology changes over time. A simplex is a generalization of a triangle to higher dimensions. A simplicial complex is a collection of simplices where, for each n-simplex, all (n-1)-simplices are included in the complex. The Vietoris-Rips filtration was chosen due to its speed at computing a good representation of the persistent homology. This is helpful due to the time complexity of the inherent mathching problem. The Vietoris-Rips filtration computes a simplicial complex by ordering all point pairs by their distance from each other. It then begins adding 0-simplices and 1-simplices (lines between points) to the simplicial complex in order from closest points to further away points. It forms a higher dimensional simplex for a group of points if they all have 1-simplices between them (they are fully connected). The Vietoris-Rips filtration requires a maximum distance for its computation where it will not stop adding 1-simplices when the distance between the points involved is above this value. Additionally, this set can be limited to simplices of a max dimension, known as a $n$-skelton. This is done to focus the analysis on specific types of topological features. This is desired as persistent homology is an expensive computation. When persistent homology is computed it quantifies when a topological feature is first and last seen and stores these values as the birth and death, respectively. These birth-death pairs encode the persistent homology of the point cloud. The set of birth-death pairs for each window can not be easily compared to each other and are not stable under perturbation. Different functions can move the birth-death pairs into a space where statistical machine-learning algorithms can be applied. Our model uses the persistence landscape function to gain order to gain the properties mentioned. This moves the birth-death pair sets into a measure space. The persistence landscape takes each birth-death pair and turns it into two connected line segments. For a given birth-death where the birth with $b$ and the death $d$ the first line segment begins at $(b,0)$ and ends at $(((d-b)/2)+b,(d-b)/2)$. The other line segment for the pair starts at $(((d-b)/2)+b,(d-b)/2)$ and ends at $(d,0)$. This transformation is done for all birth-death pairs in the set. The persistence landscape then defines the $k^{th}$ landscape as the set of $k$-max points of the persistence landscape. The resulting persistence landscapes can then be compared to each other using the $L_{2}$ norm. The algorithm used for TDA can be found in Algorithm 5. This transforms the landscapes into a single-point summary of the persistent homology. Putting these together into a time series gives insight into how the topology of our original multivariate time series varied over time. This process is summarized in Equation 4. A grid search of possible hyperparameters for TDA-PL was done to determine the best values. The grid search was run over the window size, window skip, $n$-skelton/dimension of the homology, number of persistence landscapes to keep, and Vietoris-Rips max distance. The complete similarity function discussed here can be found in Algorithm 4.

The data of communications on the server can be captured in different manners, but should be transformed so that it is on the same scale as the network data (i.e., a one-second rolling sum of features). The model assumes the following PAI from the server for each message: message text, the user who posted the message, and the time stamp of when the message was first seen. The pseudocode for this step can be found in Algorithm 2.

The output POL time-series for each IP’s network traffic is then compared to the POL of the user’s messages. There are many options for similarity functions at this stage. The results presented use the normalized cross-correlated (NCC) as the similarity function. Equation 5 defines NCC where $\overline{f(x)}$ is the complex conjugate of $f(x)$. Cross-correlation is chosen as it is designed to detect when two time series vary similarly over time. This captures if there is a certain IP address whose traffic elsewhere in the network is usually seen before activity from an unknown user is seen.

Normalized cross-correlation between time series is done by taking the time series of an unknown user on the server and iteratively going through every time series from possible source IP addresses. First, the source address is filtered down to only include the same time range as the unknown user’s activity (a small amount of buffer room can be added here to account for network delay). This is done to remove noise on either end of the communication of interest. The user may have been using another site prior that would include unrelated traffic, or an incorrect user may have sent unrelated messages. This minimizes both of these types of noise. Then, the normalized cross-correlation is computed between the two-time series, and the best, highest value is selected. The source IP with the best normalized cross-correlation is labeled as the IP that generated the traffic. This method evaluates the performance of the scopes by looking at which scopes went into a given time series. The pseudocode for this step can be found in Algorithm 3.

This approach ranks its output time series, where those with the highest normalized cross-correlation rank highest and indicate the highest likely deobfuscated attribution (e.g., the IP where the user is most likely communicating from). Additionally, the method can return a list of the $k$ most likely IP addresses for an analyst to search through. This technique could then be applied to all users of a group of collaborating users to determine their origin. Those users could then be tracked from conversation to conversation and site to site to increase confidence in the results and determine other venues where conversations between the same users are occurring (e.g., creating a social network of users of interest).

Our simulations simulated 10 ISPs with clients uniformly distributed across them. Our model showed that the performance at an ISP was equal to the percentage of clients on that ISP multiplied by the performance of an ISP in general. When tracking down a specific user, this equated to finding the user with the metrics provided for a given experimental setup if the user’s ISP was monitored and being unable to find the user if the incorrect ISP was monitored.

The results of the experiments completed are summarized in the following graphs and accompanying text. The results for a given PPT are shown for the best-performing setup for a given scope across all metrics. For example, the Service scope shows the results for the best-performing model that only uses data from the Service scope. If more than one scope is used, the two scope names are separated with a hyphen. ISPs in the experiments were labeled ISP1, ISP2, …, ISP10. If two scopes have equal accuracy, their order has no significance. If a scope performs with all metrics 0 for a given PPT setup, the model could not make any prediction when only given the scope. This could be true for different reasons, including the scope being absent in the experiment or no user-origin IP was ever seen in that scope (the model will only be able to evaluate the IP which it has seen in the dataset). The global scope in the graphs refers to performance when the model has access to every scope in the topology.

Some PPT setups have different scopes available. When DoT or DoH were used with a VPN (i.e., DoT+VPN and DoH+VPN), the origin IP cannot be seen at the resolver or service, and thus, the model performed with 0 accuracy for those scopes. By contrast, when DNS, DoT, and DoH were used with no VPN, those PPTs have no metrics for the VPN scope.

The model presented achieved above 90% accuracy for most PPT combinations at multiple scopes as seen in Figure 7. DoH and DoT do provide additional privacy-preserving capabilities over plain old DNS at the ISP, Resolver, or Service scopes. Our approach’s strong ability to deobfuscate sources indicates that each these PPTs do not appear to provide enough privacy to be considered a complete solution. With the addition of a VPN, there is a noticeable shift in which scopes can be monitored, as now some scopes which previously performed very well cannot be used at all.

Initially, to evaluate our model, we ran a simulation where no clients were using any PPT, and our model had complete knowledge of the communications. It found that it was able to identify personas with 98% and up when monitoring from several different scopes. When the service, access-to-service, client resolver or client ISP are monitored the model achieved a perfect score. Although some of these best features may appear intriguing, it must be recalled that as part of our data preprocessing, we were able to remove irrelevant data in a given scope and only monitored DNS requests to the server, because (without a PPT) DNS query names were visible. As a result of this preprocessing, some variables always return that same value for every packet. This results in the features providing the same information with a scalar difference, which is removed due to the normalization in our cross-correlation calculation, resulting in those features being similar to a count of relevant packets.

The baseline simulations and analysis are repeated but with the addition of all clients using DoH. The model results indicate how well the model can deobfuscate a source address using specific features and scopes. The model can identify the correct user with the same performance as when no PPT was used. The only changes of note is that performance decreased by 3% to 95% at the client’s resolver and by 4% to 95% at the client’s ISP. This shows that our methodology overcomes DoH’s protections 95% of the time. No decryption is needed to gain these results, and the model shows that even monitoring the number of packets over time to the resolver reveals enough pattern of life to perform to deobfuscate the client with high accuracy.

When running the simulation and analysis with DoT, the model results show a similar level of privacy protection as with DoH: our approach is highly effective at deobfuscation. These results show the same monitoring limitations and flexibility observed for DoH, including no need to decrypt communications. We can see that, while DoT provides almost the same level of privacy as DoH, more is needed in a comprehensive privacy solution.

When operationalizing our methodology in our dashboard, recall@k is one of the most important measures for this type of model. This is because it quantifies the experience and trust an analyst can have in such a tool. A high recall@k tells the analyst the likelihood that the correct answer is within the top k returned results allowing them to have an understanding for the “search” performance of the model.

When using multivariate time series analysis with this dataset we see that there is varying impact when adding a second feature. For some stronger scopes, our top performing scopes, there is little to no change. On the other hand with some weaker scopes there can be a fairly significant drop in performance when adding unhelpful features. Performance can drop by 3̃0% accuracy in some cases. This shows that there is still a need for an experienced analyst to be able to get the most out of the model. We have seen that can sometimes occur that two features when combined produce results that our lower than both of the input features individual performance.

When the client uses a VPN for all of their traffic (i.e. sending both DNS and HTTPS traffic through the VPN), some scopes that previously performed well no longer produce strong results. Monitoring at the client’s resolver, the DNS root, TLD, SLD, access-to-service, and server now can not deobfuscate client on their own as they cannot see the client’s original IP but only the VPN’s IP. As a result, these scopes now show as 0 for all metrics.

While Figure 9 shows DoH with VPN is slightly more privacy-preserving than DoH, our methodology can still deobfuscate with roughly 90% accuracy. On the other hand, Figure 8 shows DoT with VPN provides significantly more privacy-preserving capabilities than any other method we tested. Accuracy drops by around 28%-33%, and recall@k follows a similar pattern. This is interesting as DoT and DoH are believed to provide the same privacy and security protections as they both use TLS.

In our experiments, we have seen that subnet information is leaked when using a VPN. This is due to the service employing techniques best to serve the clients with a better CDN location, specifically EDNS client subnet zero [19]. This information could be used in a multistage analysis of our existing method, where the leaked subnet information determines the client’s ISP or VPN. This would be followed by tapping the given scope, which would allow for deobfuscation of the client. Figure 8 and Figure 9 show the best possible performance of our methodology, with full visibility of all Internet traffic.

There is an important takeaway when applying our method for using multiple features on the data set provided. Traffic cannot always be observed from an optimal scope. For example, traffic from a user’s resolver may not be available. However, using multivariate analyses over multiple scopes together can produce equivalent results. We have seen that the method presented can be used to transform multivariate time series of network data into univariate time series using TDA that can capture the pattern of life of users online. Although the current method does not provide results that are strictly better than the univariate version of the model, it can be seen that the transformation using TDA often does not lose any resolving accuracy while taking advantage of multiple features from different scopes. Table  II shows the best multivariate performance compared to the best univariate performance for different PPT. This comparability is an important finding as this is not an obvious outcome from using the techniques. TDA inherently transforms the data into a smaller space; thus, the ability to do so while still preserving the key features of the pattern of life is very promising future work.

To operationalize our methodology, the first step is to scrape the message board in question. Specifically, for the user in question, scrape as many messages as possible (across all threads the user was using on the site if possible) and the time each message was posted (as much resolution on the time stamp as possible). Our methodology then looks for the pattern of life (POL) of these messages across monitored traffic to determine the origin IP of the user. The best monitoring places depend on the user’s Privacy Preserving Technology (PPT). Some scopes always work to find the user: such as the user’s origin ISP. Though, clearly, one cannot always know the user’s origin ISP without some guilty knowledge. One could monitor every ISP, but this is not realistic.

Some scopes give general information, which can be a helpful place to start. The access-to-service or resolver scopes would be ideal as we can quickly determine if an IP’s POL matches our user (e.g. an origin IP or a VPN server). If there is no precise match, then our user is likely using some PPT, and as a result, we need to move our monitoring closer to the user’s source.

Suppose we know that the user did not use any PPTs. In that case, we can monitor where the HTTPS traffic passed through (e.g. origin ISP or access-to-service) or anywhere the complete DNS went (i.e., resolver. Note: root DNS, TLD, and SLD only have a partial view of the DNS traffic due to caching at the resolver. If the client also caches DNS, then the resolver would also not have a complete view of the DNS). Monitoring at any of these scopes is very similar, so tapping them is equal.

If the user only uses a DNS PPT, we can find them using the same techniques as if no PPT were used. We have found only a minor degradation in performance when adding a DNS PPT.

If the user uses a VPN, the goal should be to find a scope pre-VPN or at the VPN. These can be used to find the origin IP. Unfortunately, this is a much larger space with many more scopes. If the VPN or user’s ISP identified a different way then this would become a much easier problem. Once a pre-VPN scope is found it is reasonable to be able to find the user if they are using DoH and harder but still possible if they are using DoT.