Impersonation-as-a-service (IMPaaS) – sophisticated black market for trade in online fingerprints

0
202

Security on the internet is a never-ending cat-and-mouse game. Security specialists constantly come up with new ways of protecting our treasured data, only for cyber criminals to devise new and crafty ways of undermining these defenses.

Researchers at TU/e have now found evidence of a highly sophisticated Russian-based online marketplace that trades hundreds of thousands of very detailed user profiles. These personal ‘fingerprints‘ allow criminals to circumvent state-of-the-art authentication systems, giving them access to valuable user information, such as credit card details.

Our online economy depends on usernames and passwords to make sure that the person buying stuff or transferring money on the internet, is really the person they are saying. However, this limited way of authentication has proven to be far from secure, as people tend to reuse their passwords across several services and websites.

This has led to a massive and highly profitable illegal trade in user credentials: According to a recent estimate (from 2017) some 1.9 billion stolen identities were sold through underground markets in a year’s time.

It will come as no surprise that banks and other digital services have come up with more complex authentication systems, which rely not only on something the users know (their password), but also something they have (e.g. a token).

This process, known as multi-factor authentication (MFA), severely limits the potential for cybercrime, but has drawbacks. Because it adds an extra step, many users don’t bother to register for it, which means that only a minority of people use it.

To alleviate this problem, an alternative system of authentication has recently become popular with services such as Amazon, Facebook, Google and PayPal. This system, known as Risk-based Authentication (RBA), looks at ‘user fingerprints‘ to check someone’s credentials.

These can include basic technical information, such as type of browser or operating system, but also behavioral features, such as mouse movement, location and keystroke speed. If the fingerprint complies with what is expected from a user—based on earlier behavior—they are allowed to login right away, using only their usernames and passwords.

If not, additional authentication through a token is required.

Of course, cyber criminals have quickly come up with ways of circumventing RBA, developing phishing kits that also include fingerprints. However, they have found it hard to turn this in an effective and profitable business. One of the reasons is that these user profiles vary with time and across services and must be collected through additional phishing attacks.

Impersonation-as-a-service

Researchers at TU/e have now found evidence of a largescale and highly sophisticated marketplace that appears to overcome these limits. The marketplace, which is based in Russia, offers more than 260.000 highly detailed user profiles, together with other user credentials, such as email addresses and passwords.

“What is unique about this underground website is not only its scale, but also the fact that all the profiles are continually updated, which means they retain their value,” says Luca Allodi, researcher at the Security group at the department of Mathematics and Computer Science, who together with Ph.D. student Michele Campobasso was responsible for the research.

“In addition, customers can search the database, so that they select precisely the internet user they want to target, enabling highly dangerous spearphishing attacks. They can also download software that automatically loads the purchased user profiles in the targeted websites.”

To stress the systematic nature of the website, Allodi and Campobasso have coined the term ‘Impersonation-as-a-service’ (IMPaaS), echoing well-known cloud-computing services like SaaS (software-as-a-service) and IaaS (infrastructure-as-a-service).

“As far as we know this is the largest and most sophisticated criminal marketplace to systematically offer these services.”

Researching the marketplace wasn’t easy. To get access to the listings of available user profiles, the researchers had to get hold of special invite codes shared by existing users. Harvesting the data was also difficult, as the platform operators actively monitor ‘rogue’ accounts. The researchers have also decided to keep secret the real name of the website to minimize the risk of retaliatory actions from the market operators.

Price

The price of a user’s ‘virtual identity’ on the marketplace ranges from 1 dollar to approximately 100 dollar. Access to cryptocurrency profiles and webmoney platforms seem to be the most valued. “The mere presence of at least one crypto-related profile nearly doubles the average profile value,” says Allodi.

Another important factor driving up the price is the wealth of the country where the user is located. “This makes sense: attackers looking to impersonate and monetize user profiles assign a greater value to profiles that are likely to bring larger financial gains, and these are mainly found in developed countries,” according to Campobasso.

Also very highly valued are user profiles that give access to more than one service and profiles with ‘real’ fingerprints, as opposed to fingerprints ‘synthesized’ by the platform.

Putting the profiles to use

In their paper the researchers also describe a few examples of how criminals ‘weaponize’ these profiles, which they found on a secret Telegram channel used by platform clients. In one of the reported attacks, an attacker describes setting filters to a victim’s email mailboxes, with the aim of hiding notifications from Amazon related to purchases the attacker made using the victim’s Amazon account.


BACKGROUND AND RELATED WORK
User impersonation attacks

With the rise of sophisticated web applications, much of a user’s In- ternet activity happens by accessing a multitude of remote services, from banking to e-commerce and social network platforms, through the browser. Most of these services will have authentication mech- anisms that are meant to grant access to the underlying service to the authorized user(s) only.

From an attacker’s perspective, user impersonation provides a large portfolio of additional attack op- portunities, ranging from economic gain [2, 16] to more targeted scenarios such as targeted-phishing [24] and violent crimes [21].

Password-based authentication (PBA) is the most common (first) barrier attackers have to overcome to perform an impersonation attack. Whereas passwords have proven difficult to securely handle, are prone to leaks and to off-line attacks [32, 43] and still present severe usability problems [37], they represent the most widespread means of authentication online [7, 8].

PBA requires users to create a non trivial secret, not to reuse it across several services and to memorize both the secret and where it has been used; nonetheless, several studies indicate that up to 90% of users reuse passwords or small variations thereof across several services [14, 28].

Whereas this leaves room for password guessing attack, addi- tional attack vectors (such as malware and phishing [9, 40]) can be used to obtain user passwords, regardless of their complexity. In general, hijacked accounts can allow adversaries to tap into social connections of victims to compromise additional accounts [18, 39], by creating targeted social-engineering attacks against their circle of trust or by spamming malicious content [36], liquidate financial assets [27], steal sensitive information with the aim of blackmailing users [9, 36] and sextortion [42].

Additionally, stolen user creden- tials are oftentimes made available to the cybercrime community through underground markets [35, 40]. These markets generally provide ‘dumps’ of stolen credentials obtained from data leaks from an affected platform, or as a result of an extensive phishing campaign targeting its users [40]; common target platforms include banking or trading websites, cryptocurrency services, pornographic websites, and other internet services. A recent estimation calcu- lates that, between March 2016 and March 2017, 1.9 billion phished credentials has been sold through the underground markets [40].

Countermeasures to attacks against PBA

Multi-Factor Authentication. To mitigate the shortcomings of authentication mechanisms relying solely on passwords, web plat- forms have started adopting additional authentication measures such as Multi-Factor Authentication (MFA). MFA moved the au- thentication paradigm from (solely) something that the user knows (e.g. a password) to something the user has (e.g., a token) [15, 40].

This is achieved mainly with a combination of a pair of valid cre- dentials and a One Time Passcode (OTP) received via some trusted component such as a mobile phone, email, or a hardware token [15]. Albeit possible attack scenarios exist where the attacker can obtain the information required for the authentication almost in real-time (stolen token generator, compromised email, SIM swap attacks [33], etc.), MFA dramatically increases the costs for an attacker, and is widely regarded as an effective countermeasure to password-based impersonation attacks [40].

Nonetheless, MFA is not devoid of se- curity problems, perhaps most notably related to its usability [31], concerns on token-recovery mechanisms, and third-party trust [7].

Risk-Based Authentication. Partly to mitigate the usability prob- lem, Risk-Based Authentication (RBA) is oftentimes adopted as a means to evaluate whether the authenticating user is (likely to be) the one that has, historically, access to a specific account. RBA is an adaptive security technique aiming to strengthen password-based authentication by monitoring how unexpected or suspicious a login attempt is from the perspective of the authenticating ser- vice [31, 40, 41].

During the authentication, the RBA system moni- tors both behavioral and technical characteristics of the user and of the device, producing a fingerprint of the authenticating user [41]. RBA computes a risk score associated to the ongoing authentication by comparing the existent profile of the authenticating user against the features collected for that instance of the authentica- tion.

The features vary from basic information such as User-Agent, system time and OS, to environmental or behavioral features, such as system language, keyboard layout, fonts and plugins installed, mouse movement, geolocation and keystroke speed [1, 17, 40, 41]. Whereas the high dimensionality of this data generates, with high probability, unique ‘fingerprints’ of a user, these are not necessarily stable in time (as, for example, users may access the service from multiple or new systems, may update software configurations, or authenticate from different locations).

Depending on the computed risk score for that transaction, the authenticating service may grant access to the user with only a valid password (if the risk level is low), or require additional authentication factors (e.g., codes sent to associated email accounts, SMS verification) or even deny access for higher risk levels [31, 41].

This mechanism relies on the assumption that attackers cannot systematically re-create the profile of the victim, unless the attacker is already in control of a user’s system. Following the implementation of RBA techniques across critical services, adversaries developed sophisticated solutions aiming to impersonate the user profile of the authenticating user.

Recent literature has shown that phishing kits have developed capabilities to obtain user profiles that can then be re-used by the attacker; similarly, recent malware has been specifically engineered to re- port user activity back to the attacker [40]. In particular, Thomas et al. [40] highlight the improved capabilities of phishing kits in collecting information related to victims, including geographical location, browser metadata and answers to security questions; they found that attacks relying on user profile information collected from phishing kits are 40 times more likely to be successful than ‘regular’ attacks based on leaked credentials. On the other hand, the collection of user profile information does not scale well across users and platforms as user profiles may vary with time, across services, and must to be collected by the attacker through additional
attack means (e.g., phishing).

Analysis of current attack strategies

Attack capabilities. From the analysis above, we identify six ca- pabilities required to systematically bypass RBA systems.
Password authentication. At the very minimum, an attacker needs the authentication credentials of the victim.

User profiling. To attempt circumventing RBA systems, an attacker should have an accurate measurement of the victim’s profile/fin- gerprint for that platform.

Multi-platform. The attacker may need to access multiple web plat- forms to bypass some MFA controls (e.g. tokens or OTPs sent to an email account of the victim).

Authentication credentials and user profiles need to be collected for these additional platforms as well. The capability of impersonating the victim on multiple platforms further increases the attack surface in scope of the attacker.
Profile updates.

User profiles are unique but not necessarily sta- ble. For example, a user may update a password, change software configuration, or access the service from a different geographical region. These changes may invalidate previously collected profiles for that user, which may therefore require updating.

Infection infrastructure. The attacker requires an infrastructure to in- fect users, and collect and update the collected user profiles. This has to be maintained as defensive capabilities evolve (e.g. blacklisting of an employed phishing domain), and may require the acquisition of external services (e.g., for an infection update [10, 20]).

Automated profile enforcement. Once a profile is collected, the at- tacker needs to enforce it when authenticating on the platform. Whereas some aspects of the profile are easy to reproduce (e.g., user agent, screen resolution), others are not (e.g., installed fonts/plugins, keystroke speed, mouse movements, etc.). As profiles change across users and platforms, the attacker likely needs a system capable of enforcing the collected profiles in an automated fashion.

Analysis across attack strategies. Kurt et al. [40] identify three main strategies for impersonation attacks. Table 1 provides an overview of their capabilities.

Leaked credentials. credentials derived from data breaches on a platform. Leaked credentials are generally traded in bulk in under- ground forums; the leaked data oftentimes only contain associations between usernames and (hashed) password, with no user profile information. The data is static and if a user changes the password, the information owned by the attacker loses all value.

As the leak concerns only one platform (and multiple leaks are likely unrelated to each other), cross-platform attacks against one user are not enabled by this attack strategy. However, password-reuse attacks may provide the attacker with access to additional platforms on top of the one that suffered the leak.

Phishing kits. attackers can employ kits to deploy phishing websites aimed at stealing user credentials. As users directly interact with the phishing kit, user profiling can be achieved by injecting finger- printing code in the phishing webpage [40]. The profiles derived through phishing kits are however limited to only one occurrence of the authentication (on the phishing website) and may be in- complete or inaccurate.

For example, the employment of password manager software may hinder the realism of the derived fingerprint (e.g., in terms of input time or user behaviour on the page) when compared to the one measured by the original platform. To achieve multi-platform capabilities, the attacker must develop or acquire a phishing kit for each of the phished platforms, and collect the relevant data through separate attacks against the same user.

Malware. the attacker has access to the system through a keylogger or trojan/bot. This requires the attacker to either purchase/rent the infected system [20], or create the infection themselves (e.g., through malware attached to a phishing email, or through Pay-per-Install services [10]).

Due to the specificity of the attack, custom malware is likely needed to collect and update the profiles. As the attacker is virtually already in full control of the user system, they can collect user profiles related to any platform accessed by the victim. However, due to the position of the attacker, most of the impact (e.g., email access or web session hijacking) can be achieved through malware without the need of collecting the user profiles to then replicate them at a later stage.

Figure 1: Diagram of Impersonation-as-a-Service operations.

Researchers find huge, sophisticated black market for trade in online ‘fingerprints’
By only owning the credentials of the victim, the attacker cannot bypass the MFA as the Risk-Based Authentication (RBA) system will detect an anomaly in the profile of the authenticating user. By relying on Impersonation-as-a-Service (IMPaaS), the attacker can reliably impersonate that profile by providing the values the RBA system expects for that user. IMPaaS obtains user profiles from a (large) botnet, and provides them in bundles as user profiles. An attacker purchases a user’s profile(s) on the IMPaaS platform together with a browser extension that, provided the victim’s profile as an input, reproduces it when accessing a service.

Table 1: Overview of impersonation attack capabilities.

THE IMPERSONATION-AS-A-SERVICE MODEL

In this paper we describe evidence of a new emerging attack model, namely Impersonation-as-a-Service (IMPaaS for short), and the crim- inal infrastructure supporting it.
IMPaaS directly addresses the main limitations of the ‘traditional’ impersonation attack strategies highlighted above by moving the ac- quisition and enforcement of victim profiles from an ad-hoc process to a systematic one. An overview of the comparison between IMPaaS and current vectors for impersonation attacks is summarized in Ta- ble 1. Figure 1 provides a birds’ eye view of the attack process, from profile acquisition, to selection and enforcement. IMPaaS operators rely on widespread malware infections to acquire ‘user profiles’ globally, and provide these profiles as ‘goods’ via the underground economy through a dedicated marketplace. As a result, attackers can acquire systematic access to a large set of user profiles span- ning multiple platforms (social networks, email, corporate accounts, banking/cryptocurrency, etc.), alongside associated credentials and cookies; attackers can select the profiles they are most interested in based on a number of features, including the geographic location linked to the profile, the platforms for which impersonation data

impersonation of Internet users at large across multiple platforms.
Profile acquisition. The IMPaaS infrastructure is fueled by a bot- net whose goal is, rather than solely collecting credit card informa- tion or banking credentials, to provide the information needed to replicate the user profiles of the infected victims across the online platforms on which affected users are active. The malware distri- bution is independent from the IMPaaS model: it can be delivered through phishing campaigns, targeted attacks, pay-per-install [10] or exploitation-as-a-service infrastructures [20]. Through the cho- sen attack vector, the attacker installs on the victim system custom malware engineered to collect user credentials and cookies from the victim’s browsers; the custom malware further collects a large set of technical and (user) behavioral information that can be repli- cated, by means of the infrastructure itself, to fully emulate the user; these include the fingerprint(s) of the victim’s browser(s) and other behavioral metadata that uniquely identify the user, such as network activity, browser history, cookie data, and interactions with the user interface of the platform. As profiles are fetched by means of a persistent malware infection, the infrastructure can provide updates of the profile data and credentials for each affected user. The harvested profiles and the respective updates are then pushed to the IMPaaS servers.
Profile selection. An IMPaaS operator provides the harvested user profiles to interested attackers via a dedicated marketplace. The mar- ketplace provides an overview of the characteristics of the collected profiles available for purchase, such that the attacker can select which profiles best fit their goal by searching for victim profiles

that show specific features, such as a certain geographic location, web services for which stolen credentials are available, presence of cookies, etc. Albeit less targeted than allowed by a spear-phishing attack scenario, the selection procedure allows for a high degree of precision on the characteristics and/or environment of the user. For example, by browsing though the available credentials it is possible to identify users operating in a specific environment (e.g. a specific corporation, university, or other organizations), or with profiles on platforms of interest to the attacker. Once an attacker has identified their victim(s), the attacker can then proceed to buy the selected profiles. This can be achieved through the usual payment methods adopted in the cybercrime markets, such as via cryptocurrency pay- ments to the marketplace, and/or by relaying the payment through a third-party escrow service. Importantly, as each profile can be purchased individually, the IMPaaS platform is in the position of removing purchased profiles from the marketplace listings, thus potentially reassuring the customer that they are the only one (next to the platform operators) with access to that profile.
Profile enforcement. The IMPaaS platform provides their cus- tomers with a customized software bundle that includes a custom browser (based on open-source projects) and a browser extension that allows attackers to fetch and ‘enforce’ the purchased user profiles during the attacker’s browsing session on that platform. Based on the profiles selected and purchased by the attacker, the software provided by the IMPaaS platform recreates a browsing environment that replicates the victim’s environment by instantiat- ing exact copies of the stolen cookies and user credentials, and by spoofing other information on the victims’ systems (e.g., installed fonts/plugins, browser agent, . . . ). Further, the profile enforcement system provides cookies that embed behavioral metadata derived from the victim [12] without requiring explicit action from the attacker, and provides SOCKS5 proxy solutions to spoof the usual geographic location of the victim.

CHARACTERIZING IMPAAS IN THE WILD

In this section, we describe the operations of an emergent, invite only IMPaaS platform, ImpaaS.ru 1. The platform has operated since late 2016 and grew considerably, in terms of available user profiles, in 2019. At the time of writing, ImpaaS.ru provides ap- proximately 260′000 (and growing) user profiles available for impersonation attacks against Internet users worldwide. ImpaaS.ru is a Russian IMPaaS platform reachable from the surface web. This platform is, to the best of our knowledge, the first, large IMPaaS operator operating in the underground.

On ImpaaS.ru, a user pro- file contains information coming from user systems infected with a credential stealer custom malware acting as a man-in-the-browser.

The custom malware enables the exfiltration of cookies, creden- tials and sniffing of keystrokes, alongside additional environmental and device information that uniquely characterize the user. The IMPaaS platform states user profiles are updated and pushed to the attacker’s system in real-time, and that sold user profiles are re- moved from the listings of profiles available for purchase, although this is difficult to verify empirically, and ethically.2

An overview of the profile characteristics is provided to browsing customers; profiles with specific characteristics can be searched through the marketplace interface. From the platform, it is possible to access the list of bought profiles and download the related fingerprint.

Further, ImpaaS.ru provides their customers with a custom chromium- based browser plugin and a pre-built version of Chromium for both macOS, Linux and Windows. This bundle can be accessed only after having bought at least one user profile on the platform.

The plugin comes with the capability of loading fingerprints previously ob- tained from the acquired profiles and can tunnel the traffic through an attacker-specified SOCKS5 proxy to spoof a victim’s geolocation.

Malware customization. The latest known custom malware em- ployed by ImpaaS.ru is based on the AZORult malware [6, 13, 19]. ImpaaS.ru reports a recent update (Nov 2019) in AZORult addressing changes introduced in the Chrome browser that appear to have affected the malware functionality.

Confirmation of massive phishing campaigns in that period associated with AZORult come independently from Kaspersky and other researchers [6, 19, 30]. Note that, start of 2020, AZORult was abandoned by ImpaaS.ru in favour of a new (and, at the time of writing, still unnamed), custom malware. Due to the changing nature of the adopted malware, we here only provide a high-level overview of AZORult operations from samples available (at the time of data collection) in the underground and malware repositories.

For our analysis we replicated the latest three versions of AZORult (at the time of writing 3.3, 3.4.1 and 3.4.2) in a virtual environment, with the aim of evaluating its overall functionalities and their relevance to ImpaaS.ru. Malware customization happens through two modules, namely the builder and the C2 server.

The builder has the purpose of generating the custom build of AZORult including the URL of the C2 server. The C2 server module is a ready-to-deploy web service providing an overview of the harvested data and a page for setting up the features of the malware; these features are user-defined, and include the collection of browser history, saved passwords, cryptocurrency client files, Skype history, a customizable regexp-based file grabber targeting user-defined folders on the infected host, and an additional setup for the deployment of a second stage infection on the victim system: as AZORult removes itself from the system after execution, the second-stage mechanism can allow ImpaaS.ru op- erators to obtain persistence on the infected system and further refine the data collection (e.g., to harvest behavioral data over time, see profile updates analysed in Sec 5).

Platform infiltration

Access to ImpaaS.ru is invite-only, and a valid account is needed to access the listings of available user profiles. Access to the registration procedure is provided through invite codes available to members already active on the platform, provided they spent at least 20 USD in purchased user profiles.

To gain access to ImpaaS.ru we probed several underground forums in which we have a pre-existent foothold, and identified users that claim to be involved with ImpaaS.ru. As recent evidence suggests that underground platform operators are actively monitoring and blacklisting ‘rogue’ accounts (e.g., performing scraping activities) [11], we aimed at the collection of several valid accounts prior to data collection to distribute the activity and have ‘backup’ identities to use if some of our accounts were to be blacklisted.

Our search lead us to six members in Torum and one member in Crdclub (who claimed to be one of the operators of ImpaaS.ru) that were offering free invite codes between December 2019 and March 2020.

We contacted them through the private messaging facility of the forums as well as on the messaging board, and obtained valid invitation codes from three of them in Torum.

From Crdclub we gained access to an additional eight valid invitation codes using separate (and active) identities on the forum, for a total of eleven ImpaaS.ru accounts overall.

User profiles on ImpaaS.ru

ImpaaS.ru offers an overview of the available profiles, highlighting the information bundled in that user profile. A view of the interface accessed by attackers is provided in Figure 11 and Figure 10 in the Appendix. It is worth to note that, whereas ImpaaS.ru listings do not readily provide identifying information on the user, the information available on a listing is detailed enough to identify users operating in specific target environments such as a specific organization (e.g., to then perform lateral attacks [25]).

ImpaaS.ru distinguishes between the following information in a user’s profile: cookies, resources and fingerprints.
Cookies. These are the cookies captured by the custom malware and available for injection toward the respective platforms once the user profile is purchased and enforced by the attacker.

Resources. Resources are collections of data derived from key- logging activity and probing of browser’s local resources, such as the database of stored passwords, and browser history. Some well-known resources (e.g., related to social media platforms, home banking, etc.) are highlighted as known resources by the platform, suggesting that the type of extracted Resources is an important information for the attacker to consider.

A resource can include mul- tiple data reporting login credentials, answers to security questions, detailed balance info for bank accounts, credit/debit card numbers and holder details. ImpaaS.ru states that the malware extracts Resources from infected systems through three main modules: FormParser reads the contents of the form data inputted by the user; SavedLogins gathers credentials saved in the browser’s local database; InjectScript implements code injection on the victim’s browser on behalf of the attacker, but its operation is unclear and most of the listed profiles do not appear to rely on it.

Fingerprints

Fingerprints provide a collection of the features exposed by a browser when interacting with RBA systems, ranging from technical metadata (user-agents, browser version) to more finely grained features (geolocation, latency, system language, fonts installed, web site device access permissions, etc.)3. Depending on the specific RBA implementation, a service may probe a specific sub- set of the features characterizing a browser or system.

Differently from Resources (which are tied to a specific service, e.g. a user-name/password combination on Amazon), the features collected in an ImpaaS.ru fingerprint are not bounded to a specific service, but to the browser environment itself (e.g., available system fonts, or installed plugins).

Therefore, these constitute a pool of features that can be requested by any service, when available. ImpaaS.ru distinguishes between two types of Fingerprints:

(1) Real fingerprints: these are directly collected from the vic- tim’s device, providing an accurate identity of the imperson- ated device; albeit rarely available in bots, they appear to be sought after by market users;
(2) Synthetic fingerprints: these fingerprints are generated on the basis of the data collected by the malware. How- ever, accurate ‘synthetic’ fingerprints cannot be generated without user data (e.g, system fonts, plugins installed in a browser, etc.). For this reason, we consider the availability of Resources and of browser data in a user profile as an indication that the malware is in the position of collecting the necessary data to generate a reliable synthetic fingerprint.

Data collection strategy

To collect data on ImpaaS.ru operations, we first consider a number of structural limitations at the core to our sampling strategy:

  • Lim-1 To avoid disclosing our identity to the ImpaaS.ru operators, we perform the scraping behind TOR. This poses technical limits (as well as ethical concerns) for bandwidth usage.
  • Lim-2 We have a limited number of accounts to perform our mea- surements; aggressive probing risks exposing our accounts to the ImpaaS.ru operators, and lead to blacklisting.
  • Lim-3 Information on Resources cannot be accessed in bulk via an API or other requests to ImpaaS.ru, but rather have to be requested in limited bundles with separate requests. This explodes the number of requests necessary to obtain Resources information on all user profiles on ImpaaS.ru.

To address Lim-1 and Lim-2, we employ an ad-hoc crawler. Initially the crawler was set to work ≈ 24h/day issuing, on average,
15 requests per minute; despite the relatively low requests volume, this strategy led two of our accounts to be blacklisted, suggesting that ImpaaS.ru operators may be employing network monitoring solutions to avoid measurement activities. Following [11], we progressively reduced the crawling activity to ≈ 6h/day. In the process, an additional three accounts were banned, for a total of five banned accounts.

It is interesting to note that three of the five blocked accounts were not linked to each other in any way,4 suggesting that market operators have kept their crawling-detection efforts high during our activities. To mitigate this problem we employed different strategies to access specific pages and resources to crawl on ImpaaS.ru: as already noted in [11], accessing URLs directly (as opposed to via website navigation) may generate anomalies in crawler monitoring systems.

For this reason, we operationalised all crawling activities through browser instrumentation, and config- ured the crawler to mimic activity patterns compatible with those of a human user (e.g. timeouts between requests proportional to the length of the visited webpage, taking breaks, …). With this final setup, we finally managed to silently crawl the market avoiding the detection and ban of the remaining accounts in our possession.
While necessary, the above strategy makes it impossible to gather complete information on Resources due to the exploding number of requests (Lim-3).

This results in two datasets:

  • Full database includes information on approximately 262′000 user profiles on ImpaaS.ru, including (infection, update) dates, prices, number of browsers for which resources are available, number of collected fingerprints for that user pro- file, and number of stolen cookies.
  • Sampled database adds Resources information to a ran- dom selection of approximately 5% (n = 13′512) of the user profiles available on the market.5

The collected data is available for sharing to the research com- munity at https://security1.win.tue.nl.

Analysis procedure

The data analysis in Section 5 is split in two subsections: in Sec. 5.1 we provide an overview of the data collected in the Full dataset, and characterize ImpaaS.ru op- erations by looking at its evolution, victim profile characteristics, profile updates, and pricing; in Sec. 5.2 we analyse the distribution and effect of Resources on pricing, as reported in the Sampled database. Standard sanity checks (e.g. on the regression results presented in Sec 5.2) are performed on all analyses. Reported loga- rithms are natural logarithms unless otherwise specified.


Manual resources classification. To factorize the type of resources reported in Sampled database in the analysis, we provide a clas- sification of each resource in one of six categories. Table 2 lists the employed categories and their corresponding definitions. The classification was done manually by one of the authors over 454 unique platforms for which Resources are reported in the dataset. The other author independently classified a random sample of 100 platforms, reaching an agreement score of 89%; after review, conflicts were resolved and the classification was updated accordingly. Additional random checks did not reveal any remaining mismatch.

Ethical considerations and limitations. No personally identifiable information is reported in our dataset. IP addresses of victims are masked on the platform, and no detailed information about the victims is available without purchasing a user profile. For obvious ethical concerns, we did not purchase any. Whereas this limits our analysis in that we do not have access to the software bundle provided by ImpaaS.ru, and cannot ascertain in detail the quality or operative aspects of the IMPaaS service provided by ImpaaS.ru, we are in the position of providing a full evaluation of the data is available to the attacker when browsing for victims.

REFERENCES

  1. Alaca, F., and Van Oorschot, P. C. Device fingerprinting for augmenting web authentication: classification and analysis of methods. In Proceedings of the 32nd Annual Conference on Computer Security Applications (2016), pp. 289–301.
  2. Allodi, L. Economic factors of vulnerability trade and exploitation. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (2017), ACM, pp. 1483–1499.
  3. Anderson, R., and Moore, T. The economics of information security. Science 314 (2006).
  4. Bank, T. W. World development indicators. https://datacatalog.worldbank.org/ dataset/world-development-indicators.
  5. Binsalleeh, H., Ormerod, T., Boukhtouta, A., Sinha, P., Youssef, A., Debbabi, M., and Wang, L. On the analysis of the zeus botnet crimeware toolkit. In Privacy Security and Trust (PST), 2010 Eighth Annual International Conference on (2010), IEEE, pp. 31–38.
  6. Bisson, D. Azorult trojan disguised itself as fake protonvpn installer, Feb 2020.
  7. Bonneau, J., Herley, C., Van Oorschot, P. C., and Stajano, F. The quest to replace passwords: A framework for comparative evaluation of web authenti- cation schemes. In 2012 IEEE Symposium on Security and Privacy (2012), IEEE, pp. 553–567.
  8. Bonneau, J., Herley, C., Van Oorschot, P. C., and Stajano, F. Passwords and the evolution of imperfect authentication. Communications of the ACM 58, 7 (2015), 78–87.
  9. Bursztein, E., Benko, B., Margolis, D., Pietraszek, T., Archer, A., Aqino, A., Pitsillidis, A., and Savage, S. Handcrafted fraud and extortion: Manual account hijacking in the wild. In Proceedings of the 2014 conference on internet measurement conference (2014), pp. 347–358.
  10. Caballero, J., Grier, C., Kreibich, C., and Paxson, V. Measuring pay-per-install: The commoditization of malware distribution. In Usenix security symposium (2011).
  11. Campobasso, M., Burda, P., and Allodi, L. Caronte: crawling adversarial resources over non-trusted, high-profile environments. In 2019 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) (2019), IEEE, pp. 433– 442.
  12. Chen, Y., Pavlov, D., and Canny, J. F. Large-scale behavioral targeting. In Proceedings of the 15th ACM SIGKDD international conference on Knowledge discovery and data mining (2009), pp. 209–218.
  13. Cylance. Threat spotlight: Analyzing azorult infostealer malware, Jun 2019.
  14. Das, A., Bonneau, J., Caesar, M., Borisov, N., and Wang, X. The tangled web of password reuse. 2014. Cited on (2014), 7.
  15. Dmitrienko, A., Liebchen, C., Rossow, C., and Sadeghi, A.-R. On the (in)security of mobile two-factor authentication. In Financial Cryptography and Data Security (Berlin, Heidelberg, 2014), N. Christin and R. Safavi-Naini, Eds., Springer Berlin Heidelberg, pp. 365–383.
  16. Franklin, J., Paxson, V., Perrig, A., and Savage, S. An inquiry into the nature and causes of the wealth of internet miscreants. In Proc. of CCS’07 (2007), pp. 375– 388.
  17. Freeman, D., Jain, S., Dürmuth, M., Biggio, B., and Giacinto, G. Who are you? a statistical approach to measuring user authenticity. In NDSS (2016), pp. 1–15.
  18. Gao, H., Hu, J., Wilson, C., Li, Z., Chen, Y., and Zhao, B. Y. Detecting and characterizing social spam campaigns. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement (2010), pp. 35–47.
  19. Gatlan, S. Azorult malware infects victims via fake protonvpn installer, Feb 2020.
  20. Grier, C., Ballard, L., Caballero, J., Chachra, N., Dietrich, C. J., Levchenko, K., Mavrommatis, P., McCoy, D., Nappa, A., Pitsillidis, A., Provos, N., Rafiqe,M. Z., Rajab, M. A., Rossow, C., Thomas, K., Paxson, V., Savage, S., and Voelker,G. M. Manufacturing compromise: the emergence of exploit-as-a-service. In Proc. of CCS’12 (2012), ACM, pp. 821–832.
  21. Havron, S., Freed, D., Chatterjee, R., McCoy, D., Dell, N., and Ristenpart,T. Clinical computer security for victims of intimate partner violence. In 28th USENIX Security Symposium (USENIX Security 19) (Santa Clara, CA, Aug. 2019), USENIX Association, pp. 105–122.
  22. Herley, C. So long, and no thanks for the externalities: the rational rejection of security advice by users. In Proc. of NSPW’09 (2009), NSPW ’09, ACM, pp. 133–144.
  23. Herley, C. Why do nigerian scammers say they are from nigeria? In Proc. Of WEIS’12 (2012).
  24. Ho, G., Cidon, A., Gavish, L., Schweighauser, M., Paxson, V., Savage, S., Voelker, G. M., and Wagner, D. Detecting and characterizing lateral phishing at scale. In 28th USENIX Security Symposium (USENIX Security 19) (Santa Clara, CA, Aug. 2019), USENIX Association, pp. 1273–1290.
  25. Ho, G., Javed, A. S. M., Paxson, V., and Wagner, D. Detecting credential spearphishing attacks in enterprise settings. In Proceedings of the 26rd USENIX Security Symposium (USENIX SecurityâĂŹ17) (2017), pp. 469–485.
  26. Holt, T. J., Smirnova, O., and Hutchings, A. Examining signals of trust in criminal markets online. Journal of Cybersecurity (2016), tyw007.
  27. IOActive. Technical white paper: Reversal and analysis of zeus and spyeye banking trojans, 2012.
  28. Ion, I., Reeder, R., and Consolvo, S. âĂIJ… no one can hack my mindâĂİ: Comparing expert and non-expert security practices. In Eleventh Symposium On Usable Privacy and Security ( SOUPS 2015) (2015), pp. 327–346.
  29. Krebs, B. Krebs on security, Mar 2020.
  30. Labs, K. New azorult campaign abuses popular vpn service to steal cryptocur- rency, Feb 2020.
  31. Milka, G. Anatomy of account takeover. In Enigma 2018 (Enigma 2018) (Santa Clara, CA, Jan. 2018), USENIX Association.
  32. Morris, R., and Thompson, K. Password security: A case history. Communica- tions of the ACM 22, 11 (1979), 594–597.
  33. Mulliner, C., Borgaonkar, R., Stewin, P., and Seifert, J.-P. Sms-based one- time passwords: attacks and defense. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (2013), Springer, pp. 150– 159.
  34. Oest, A., Safei, Y., Doupé, A., Ahn, G.-J., Wardman, B., and Warner, G. Inside a phisher’s mind: Understanding the anti-phishing ecosystem through phishing kit analysis. In 2018 APWG Symposium on Electronic Crime Research (eCrime) (2018), IEEE, pp. 1–12.
  35. Onaolapo, J., Mariconti, E., and Stringhini, G. What happens after you are pwnd: Understanding the use of leaked webmail credentials in the wild. In Proceedings of the 2016 Internet Measurement Conference (2016), pp. 65–79.
  36. Sabillon, R., Cavaller, V., Cano, J., and Serra-Ruiz, J. Cybercriminals, cyber- attacks and cybercrime. In 2016 IEEE International Conference on Cybercrime and Computer Forensic (ICCCF) (2016), IEEE, pp. 1–9.
  37. Stobert, E. The agony of passwords: Can we learn from user coping strategies? In CHI’14 Extended Abstracts on Human Factors in Computing Systems. ACM New York, NY, USA, 2014, pp. 975–980.
  38. Stringhini, G., and Thonnard, O. That ainâĂŹt you: Blocking spearphish- ing through behavioral modelling. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (2015), Springer, pp. 78–97.
  39. Thomas, K., Li, F., Grier, C., and Paxson, V. Consequences of connectivity: Characterizing account hijacking on twitter. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (2014), pp. 489–500
  40. Thomas, K., Li, F., Zand, A., Barrett, J., Ranieri, J., Invernizzi, L., Markov, Y., Comanescu, O., Eranti, V., Moscicki, A., et al. Data breaches, phishing, or malware? understanding the risks of stolen credentials. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security (2017), pp. 1421–1434.
  41. Wiefling, S., Iacono, L. L., and Dürmuth, M. Is this really you? an empirical study on risk-based authentication applied in the wild. In IFIP International Conference on ICT Systems Security and Privacy Protection (2019), Springer, pp. 134– 148.
  42. Wittes, B., Poplin, C., Jurecic, Q., and Spera, C. Sextortion: Cybersecurity, teenagers, and remote sexual assault. Center for Technology at Brookings (2016).
  43. Yan, Q., Han, J., Li, Y., DENG, H., et al. On limitations of designing usable leakage-resilient password systems: Attacks, principles and usability. In 19th Network and Distributed System Security Symposium (NDSS) (2012).

More information: Michele Campobasso, Luca Allodi. Impersonation-as-a-Service: Characterizing the Emerging Criminal Infrastructure for User Impersonation at Scale. arXiv:2009.04344 [cs.CR] DOI: 10.1145/3372297.3417892arxiv.org/abs/2009.04344

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.