Tristan Bunnage | SOC Analyst | 15 July 2026
Many platforms grant benefits to newly created accounts, making them a natural target for financially motivated actors who create large numbers of accounts to claim those benefits multiple times. This practice, known as multi-accounting, usually violates the terms of service of these platforms.
Detecting these malicious accounts has become increasingly difficult. Recently, Fortian has detected the use of scripts and botnets to randomise sign-up parameters at account creation. Fields such as email addresses, usernames, and user agents can vary across each account in each multi-accounting campaign, allowing these accounts to blend in with background traffic and evade conventional detection strategies. Complicating matters, Fortian has also observed threat actors increasingly leverage residential IP proxy networks to further obfuscate malicious activity and blend in with legitimate traffic. When an actor implements these evasion techniques simultaneously, conventional detection rules struggle to be successful. In this blog, we will describe a machine learning model that assists analysts detect large-scale automated account-creation campaigns that target these platforms.
Many multi-accounting campaigns are detectable with standard query-based detection rules. Campaigns composed of accounts created using a single IP address, a single name, unusual email domains, or unusual user agents represent patterns that surface readily in a SIEM. Given a sample of malicious accounts with one or more similar properties, an analyst can quickly identify the scope of the campaign.
The problem arises when a threat actor engineers their campaign to blend in with background activity. To do this, an actor may draw names from a realistic pool, generate emails across multiple common providers, spoof user agents that match modern browsers and operating systems, and rotate through a botnet of residential IP addresses. Residential IP proxying is particularly hard to detect, as sign-ups through compromised residential devices cause each request to appear as if originating from a genuine consumer. It is entirely feasible for a sophisticated actor to use all of these strategies simultaneously. Doing so renders even advanced anti-fraud tooling unreliable and makes implementing targeted rule-based detections impossible without creating too much noise for analysts.
One parameter that must be generated is the email username. All email addresses must be unique, while also appearing natural enough to pass general scrutiny. For large multi-accounting campaigns, actors use scripts to efficiently generate these usernames. Consequently, all usernames generated by a given script will follow an underlying pattern or structure. Our approach targets the patterns generated at the script level to detect large campaigns that necessarily utilise them.
Detecting these campaigns requires finding accounts that share similar username templates while also having other randomised fields, with no labelled examples to learn from. Unsupervised clustering algorithms are a natural fit as they group similar data points together without requiring any labelled training data.
In our operations, we use the bisecting k-means algorithm. Unlike standard k-means, which partitions all data in a single pass, bisecting k-means builds a hierarchy by recursively splitting clusters. Clusters that are not split over many iterations are strong bot campaign candidates, as the algorithm has repeatedly judged their members to be more similar to one another than to the broader population.
Each sign-up event is converted into a numerical feature vector before clustering. The most significant component is derived from usernames used to sign up. We have developed a custom tokenisation script that parses a username into typed segments. Name-matching substrings are tagged as name, digit patterns that may refer to a date are tagged as year, and residual fragments are classified as initials or generic strings. Remaining fragments are assessed for statistical properties to distinguish structured strings from randomly generated character sequences. The output is a pattern string such as name.sep.name.sep.year that captures the structural template of a given username. Both this template and a list representing the count of each segment type are included in the feature vector and assigned a high weight.
Even when a campaign randomises user agents across accounts, the randomisation is not unconstrained. Threat actors will select user agents from a pool of plausible browser and operating system combinations chosen to reflect regular user activity. Campaigns therefore tend to cluster around a consistent subset of user agents.
We also use user agent strings to cluster on, where possible. They are categorical variables with virtually unlimited cardinality. To handle this, the solution uses a feature hashing method described by GreyNoise, which maps strings into fixed-length vectors. The user agent string is split into a set of string elements, each element is passed through the SHA1 hashing function, and the remainder of the result is computed when divided by the vector length. The vector element at the index equal to the remainder is incremented by one for each element, and the final vector is normalised. For example, a common Chrome user agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 may be encoded into a vector of length eight:
norm([1, 2, 3, 1, 10, 1, 3, 2])
The same method is applied to IP addresses. Even campaigns that rotate through residential IPs must cycle through a finite pool of addresses, so the same IP may be reused over a long enough period. Campaigns using hosting provider infrastructure have an additional property that makes this encoding particularly effective. Addresses from the same provider are allocated from contiguous subnet blocks, meaning the IPs used will be from the same or similar subnets. Therefore, shared octets consistently hash to the same buckets and produce similar vectors across the IP range.
When available, other features are engineered as follows: email domains are hashed and sorted into buckets, verification method is one-hot encoded, and temporal features are cyclically encoded. Each feature is appropriately weighted and appended to the vector.
Fitting the model to a given dataset produces clusters of varying sizes. With no labels, there is no direct way to tell which clusters contain malicious activity. The solution applies four statistical flags to produce a shortlist for manual investigation.
Any cluster triggering one or more flags became a candidate for manual review.
To validate the solution, Fortian applied it to a representative dataset of sign-up activity spanning a 90-day period.
The model produced clusters of various sizes, of which six were marked as suspicious by the statistical flags. All six clusters were small compared to the others, containing hundreds of sign up-events. Two of the six flagged clusters were found to contain malicious campaigns.
The first cluster was marked as suspicious by every flag and contained a campaign that had already been detected via our custom analytic rules. This campaign was composed of accounts with highly randomised usernames and originated from a wide variety of residential IP addresses. The usernames characteristic of this campaign formed anomalously long patterns and always used two separators and one number. For example, the usernames 42_alpha.gamma and blue-green-007 formed the patterns number.sep.string.sep.string and string.sep.string.sep.number respectively. The campaign further failed to randomise other features. Each account used the same name, email domain, and user agent, leading to a strong signal for the model. The campaign was also characterised by short bursts of activity. Only one benign account was in the cluster, easily separated out as it had a different user agent and name.
The second malicious cluster was flagged due to low correlation with background activity and low entropy across the service provider and username pattern features. This cluster was particularly noisy, with roughly half of the accounts associated with a large malicious campaign. The remaining accounts were composed of benign accounts and additional malicious accounts whose parameters suggested manual multi-accounting behaviour unrelated to the large campaign.
The large campaign within this cluster generated accounts by selecting random first and last names and constructing email usernames from them. The dominant structures were name.name.number and name.number.name, where the name components matched the account's registered first and last name. In some cases, the username followed a pattern such as string.name.number, where the string token was a name with a character removed, for example JohDoe5678. This may have occurred when the generated email address was already taken, forcing the script to fall back to a modified form. The actor created both Outlook and Gmail email addresses. User agents were drawn from a small set of common Chrome browser strings.
The campaign's IP behaviour was similar. Across the 90-day period, all accounts originated from just 18 distinct IP addresses spread across two hosting providers. The actor throttled sign-up rates for each IP address used to blend in with background traffic. As shown in Figure 1, this produced a steady creation rate sustained across the entire period. The combination of distributed naming, common email domains, plausible user agents, and strictly throttled hosting-provider IPs allowed the campaign to operate continuously without triggering any existing rate-based or pattern-based detections.
The four remaining flagged clusters were assessed as benign. Each contained accounts with consistent niche fingerprints, such as specific Linux distributions or older Android browser versions. The small number of accounts with these features caused them to cluster together. None displayed the username pattern uniformity associated with automated campaigns.
In this blog, we have introduced our novel approach to detect large multi-accounting campaigns that have been deliberately engineered to evade traditional detection. Our method targets the structural patterns that scripts inevitably impose on generated usernames and has identified a previously unknown campaign that had not triggered any existing detection.
Machine learning does not replace query-based rules. Smaller, less sophisticated campaigns are often detected by query-based rules, and the clustering model often does not have the fidelity to isolate small campaigns contained in large datasets. This approach can, however, identify high-volume campaigns that utilise a wide range of evasion techniques. As adversarial techniques continue to evolve, approaches that combine behavioural signals across multiple dimensions will be essential to staying ahead of sophisticated multi-accounting campaigns.
Request a consultation with one of our security specialists today or sign up to receive our monthly newsletter via email.
Get in touch Sign up!