Shuabang with new techniques in Google Play

ELEVENPATHS, RADICAL AND DISRUPTIVE INNOVATION IN SECURITY

ElevenPaths [email protected] elevenpaths.com

Published: November 2014

“SHUABANG” WITH NEW TECHNIQUES IN GOOGLE PLAY

2

"SHUABANG" WITH NEW TECHNIQUES IN GOOGLE PLAY

CONTENTS

1 Executive summary 3

2 Introduction 5

3 Summary diagram of operation 9

4 Attack scheme 10

4.1 The attacker's dashboard 10 4.2 The applications 11 4.3 Perpetrating the fraud 14

5 Findings 16

6 Annex I. Applications analyzed 17

ElevenPaths [email protected] elevenpaths.com

3


1 Executive summary

ElevenPaths has detected malicious apps in Google Play, aimed at performing Shuabang techniques, or BlackASO (Black Hat App Store Optimization). This is a real industry in China that has been active for years. The method consists in creating an infrastructure to score or artificially inflate the number of downloads of an app so they rise up their position on the markets. This "service" is usually sold to third parties. The potential of these malicious apps spotted for Shuabang is above average, since it demonstrates in-depth knowledge of the specific operation of Google's authentication protocols.

The attacker distributed dozens of malicious apps from Google Play's official market. These apps use the victim's telephone information to register the device with fake accounts created by the attacker. This information (a fake account associated with the victim's real phone number) provides the attacker with a horde of accounts that are valid and credible for Google and that may be used to perform different actions in the store. Among these, automated fraudulent rating, made-up apps downloads, etc. so the BlackASO service is delivered.

To carry out the fraudulent scheme, the attacker needs active Google accounts associated with real devices that do not appear suspicious to Google, which would quickly eliminate them otherwise. Different techniques are used for this purpose. The most usual is to hire users that will manually create the accounts and download or rate the apps they are told to. On this particular occasion, they came up with a system that starting from a set of fake Google accounts, distributes and associates them to different devices, so they take full advantage of the number of phones associated with an account.

The attacker had 12,500 Google accounts with usernames and passwords, but none of which were registered with a device. The large majority of the accounts in this database were created by the attacker.

These applications turn the device into a zombie that collected these fake accounts from the central server every 10 minutes and associated them with the information on the victim's phone. The "original" Google account on the victim's device remains safe and the attacker cannot access it at any time. Each account was associated with between 10 and 30 physical phones of victims. The combinations between Google accounts and associated phones are countless. The image shows an example of an attacker account associated with 18 victim devices.

The attacker uploaded more than 300 applications to Google Play throughout the month of October. They were disguised as games, jokes, wallpapers and general entertainment. Of these, approximately 100 committed the fraud by associating these fake accounts to the device's settings and identifier. The remaining 200, although harmless in their first version, were usually later updated to commit the fraud.

The number of downloads of all these applications were in the hundreds of thousands.

4


With this attack scheme, the attacker has obtained a database of 60,000 tokens. Tokens are registries of fake users associated with real devices and they allow to simulate a user as operating from the device, without needing to introduce user and password anymore.

The attack was focused on victims in Brazil, India and Russia, although it was prepared to add any other country. It appears that the next objective were victims in the United States.

ElevenPaths has been able to determine how, since when and by which methods the fraud was committed and also established links between this attacker and other groups of attackers aside from gathering a series of incriminating evidence. Based on these correlations, ElevenPaths was able to find Google Play developer accounts possibly belonging to the same group of attackers.

All of which was possible thanks to the use of Path5, a product developed by ElevenPaths, which allows early detection, investigation and correlation of any type of information about Android applications, among other functionalities.

This report is a real-life example of the power and effectiveness of a product such as Path5 to investigate similar cases.

5


2 Introduction

When a user creates a Google account, once the username and password are provided, he has access to

dozens of Google services, as a Single Sign On. For a user to use this account on his Android system, it is

usually registered during the phone activation process or created from the start in the device itself.

The user enters the account password in the device only once. From that point on, he is registered in a Google

service (sending user, password, device ID...) that will return a token. This master token is stored in the

account manager and will be used from then on in the device (that remains associated) so the password does

not have to be entered again. Other temporary tokens are derived from this master token.

It is common for users to have several devices registered with the same account. This, for example, allows

users to choose where to install apps. The image shows an account associated with various devices. It is a

account from the attacker, but the phones belong to the victim.

6


Any user with a Google accounts may sign in and installs applications from the browser to their device of choice,

as if they were being sent remotely.

7


As mentioned, associating a device to an account requires the following process:

Either creating the account from the device itself. Google prevents automatic creation of fraudulent

accounts by discarding accounts created on devices that are not "real", as well as inserting a

CAPTCHA.

Or using an existing Google account and signing in with it on the device that it is to be associated with.

This process only requires entering the username and password in the phone to add a new account.

What Google does, is associating a device identifier with the account. The Android phone or device will appear

as a device associated with the account on the Google Play settings panel.

8


This low-level registration and association protocol has been studied by the community and specially by

attackers who carry out fraudulent practices. Registration and association can currently be programmed with

raw calls to Google services and providing the necessary information. This process isn't officially documented,

though.

This kind of botnet is a sophisticated system by which attackers use malware with minimum privileges to

associate accounts created by them to real devices. Thus, attackers obtain a number of fake accounts

associated with "real" phones and therefore valid for Google services, allowing them to carry out a variety of

fraudulent schemes. Specifically, artificially increase app downloads or fraudulent app rating.

9


3 Summary diagram of operation

The generic operating scheme of the analyzed apps is as follows:

The database of the attackers had a rule in the firewall that provided privileged passage for a Chinese advertising company with its own account in the database.

10


4 Attack scheme

The scheme of attack is basically divided into three steps.

1. Associating accounts with phones.

2. Data theft, association and delivery to the server.

3. Using the accounts to perpetrate the fraud.

To do this, the attacker uses a dashboard, applications and various tools to perpetrate the fraud.

4.1 The attacker's dashboard

The attacker uses a dashboard from which to control the entire operation. This dashboard has two main views.

One of them is a repository of valid Google usernames and passwords with and ANDROID_ID associated and

classified by countries. Most of these accounts were created (probably by the attacker or a team of

attackers) from October 17 onward. The accounts did not have a history of activity or an associated device.

The account data and complexity of the passwords appear to indicate that they were created with an automated

system. In these cases, the user's name and last name and the password were created automatically and all is

needed is breaking a CAPTCHA to create Google accounts. At the start, the device identifier in this database is

random; it is then updated by the malicious apps with the real ANDROID_ID of the victim's phone.

Thus, at the start, the attacker had a pool of 12,567 inactive accounts at his disposal, including their usernames

and passwords. Although not shown on the dashboard, the password is in clear text in the database. In

addition, the attacker could add new usernames and passwords from a script in the server that fed this database.

The attacker also had a database for storing data about the process of associating accounts to devices. When devices were linked to accounts, Google returned a series of values (including the security master token). This database contains the device identifiers, tokens, etc. In the last step, the malicious app stores this information in the attacker's server. This database of tokens is as well a source for data updates and reuse of token, check if it is still valid and thereby taking full advantage of its possibilities.

The tokens database linked to devices is not visible on the dashboard, but it contents a string (encoded in base64) with this information:

11


Another important view of the dashboard is a very basic administration screen.

In the dashboard, the attacker could set which apps would be downloaded by the fake account, as well as other parameters. Other possibilities are limiting per country, number of downloads, a download counter, etc.

Up until now, two dashboards have been found, located at different URLs. These two dashboards contained more than 12,500 Google accounts created by the attacker. In sum, this was the basic infrastructure for fraud perpetration.

4.2 The applications

In addition to preparing the dashboard with the information, the attacker needed to infect the victims so they would communicate with this command and control and therefore associate the accounts with the device.

This was done by publishing some 300 apps on Google Play since the beginning of October 2014. Of these, more than 100 contained the infecting code. These apps need only these permissions to handle the accounts and link them to the device:

12


These apps were basically hidden under the appearance of desktop backgrounds, jokes, etc. They contained the entertainment features promised, as well as the malicious code.

Once the user downloads the app, two completely different events occur. The first event is that the application indicated that it required an update and invited the user to download an additional application from Google Play. This invitation app is dynamic and based on a rotation system controlled by the attacker in some other server. This event was not related to the main activity of registering accounts. The message was sent in the phone's language.

While this event is taking place, the second event related to the fraud is consolidated in the background. Essentially, what the attacker achieves step-by-step at a high level was the following.

The attacker's server provides the victim with a token from an already liked account. This token may be used to rate, download or score apps as a legitimate user.

13


If the token is no longer valid, a username and password of a Google account is provided, not associated with any device.

The attacker attempts to associate the victim's device with the account, as would occur if he signs in on the phone with this new account. Thus, the victim's device is associated with the user provided by the attacker. The effect is as if the attacker had registered his account officially in the device. Once registration was obtained, Google returned a token for the associated account. This token was uploaded by the attacker to the server to feed back the process.

The app waits for tasks and commands from the server, which is polled every 10 minutes. It would be just like if the attacker were registered on the phone with another account, to which he had access because he knows the original username and password.

Using registered account, the attacker attempts to download the first megabyte of an app that he uploaded to Google Play, with no description or title, etc. It is a dummy app (see the image below). We assume that the end goal is "total activation" of the account (according to official Google help at https://support.google.com/googleplay/answer/1141080): "Before you can shop on Google Play from your computer, you need to link your Google Account to your Android device. To link your Google Account to your Android device, sign in to the Google Play Store app on your Android device and download any app."

14


The tasks assigned by the attacker consist in an application being proposed by the server to download, normally from Google Play. With this, the attacker attempts to artificially increase the app download count, thus distorting Google Play statistics.

If he cannot continue to perform tasks (app downloads) for whatever reason (normally because the token no longer valid or expired), he again requests the data needed for a new association with the device and new accounts provided by the database.

The entire process was orchestrated by a system of intelligent tasks that counts, restricts and distributes processes, apps and tasks during periods of time. The result is that a device or account could be perfectly distributed and associated without raising suspicion.

Although these shuabang techniques are well-known, this summary of behavior hides an intelligent step used to obtain accounts associated with real phones that are then totally operative for Google Play. This method allows the attacker to simulate that the victims is using valid Google accounts and associated with their phones. The attacker could use these accounts to request downloads that were never carried out or rate apps. From Google Play's viewpoint, these actions are real, credible and performed by phones spread out all over the world.

The real account of the phone's user is not useful or interesting for the attacker during this process. The value of the victim in this case is:

Associating an account to a "regular" device values, such as brand, device, identifier, etc.

Carrying out registration and association of accounts in a distributed and orderly manner from various IP addresses, countries, at different times, etc.

4.3 Perpetrating the fraud

The attacker checks in his database whether the IP of the tasks request from the victim's device belongs to Brazil, India or Russia. The server would not respond otherwise. But the attack could be carried out from any part of the world and against any country.

15


Once the attacker had a good database of accounts with their token associated with devices, this allows him to act as legitimate users who clicks on ads, download applications, etc. The potential is very high. He was able to multiply and optimize the number of app downloads that could be performed by a device by associating multiple accounts with multiple devices. This fraud scheme may be used for purposes from money laundering (buying products or services generated by the attacker himself) to renting botnets for fraudulent app search optimization, etc.

While the investigation was being carried out, the attacker modified the database to perpetrate one of the possibilities in the fraud scheme. Numerous applications, advertisement identifiers and another task management system were introduced.

Although the techniques are not new, the malicious apps and dashboard appeared to be very experimental. We have a suspicion that the intended final scenario of this attacker was more ambitious.

Once having obtained the registration of an account controlled by the attacker with the victim's device, theoretically the attacker could sign in with a browser or automatic system and force an app download in the victim's device. However, we were unable to reproduce this process in the laboratory and therefore believe that the attacker also was unable to complete it successfully. If a download is performed, it would actually count as a new download, but it would not be "effective" in the victim. If the attacker had achieved this, he would have been able to install any Google Play app with any level of permission (these would have been approved in the browser) and the victim would not necessarily even see or approve anything in his device. But installation is not allowed unless the account is actually active and synchronized at all times in the phone with the valid token, although the malicious apps reproduce all the necessary steps according to Google help: "Before you can shop on Google Play from your computer, you need to link your Google Account to your Android device. To link your Google Account to your Android device, sign in to the Google Play Store app on your Android device and download any app."

16


5 Findings

Although the attacker seems to have a known ultimate goal (black ASO), he achieved several interesting milestones by developing these malicious apps:

He created or bought 12,567 Google accounts, most of which were automatically created. Account creation requires breaking a CAPTCHA.

He achieved a low level understanding of the Google registration and device to account association process. He was able to program them to work automatically. This is not officially documented and there is very little documentation about this.

He was able to introduce some 100 malicious apps in Google Play with apparently harmless permissions.

He was able to manage a task system that fully optimized the activity of the infected devices by distributing download and account association tasks, etc.

He was able to use the victims' devices features to associate them with accounts and thus perpetrate the fraud, as if a fake user was registered in the victim's device.

This led us to assume that the intention was to take a further step and achieve remote installation in the associated phones.

Although the victim's account data is not affected, these malicious apps imply taking advantage of resources and violating privacy.

Although the shuabang technique has been known and developed for some time via a variety of apps, the attackers' target is usually Google Play as an area for privileged distribution. This is the market that poses the most problems for publishing, but once they get it, and thanks to this intelligent technique described, the success for the attacker is remarkable. These malicious apps seem to be in a development phase, and it seems they were experimenting with these techniques.

17


6 Annex I. Applications analyzed

com.drawmanagesacrifice.eletricscreen,df2d764ff55281d3ae856799f051b489923911b0

com.associationinterruptcrush.eletricscreen,7f74a790588c85187e6a7b2e9e4b0ff202e469c1

com.chainheaddistance.eletricscreen,f39c578489eb007696ed4cc04756167f306954a5

com.buttondetailsuffer.eletricscreen,1f07d84595f110220948038a5af4f2a164e22014

com.busysquareprejudice.eletricscreen,9409bd9d91b69e515c2ea26013650088d56132d3

com.curlfastenlive.trustconfess.matter,d1d63f07b2e5e1f6f0fe50f08ee3dfa40a816536

com.trickpronouncefind.expensedream.tobacco,89755f13b851482872b29d64c53677156aac77de

com.prizeconfidencecomposition.confusescatter.ill,984d0797ec75bd3e868e1e5a25ab012e3dc8a8de

com.smellattractionreply.feedbusiness.speech,6813f7feefe28f4d91b20649f4f4b6dc6072c7b8

com.decisiondaughterquarrel.clubeasy.bundle,169b4a7aeb5245d136ebaf99e96ac43dcda172ed

com.fortunateawkwardaround.swingglass.gold,555a1bd9abe0c18d0b6d4945730c22f63eaa1c3b

com.correctloudthus.hallpool.shut,d2faf306cb7ae5e12c530049633963644e3513d0

com.curiouswhilewalk.eletricscreen,c00899289795a94a1a9cce96f5adec90731d52a1

com.dollarrabbitsteer.firescreen,d708eb1fdd831c519b87139616c9e3960e75a1f0

com.rollinterferenceforeign.industryrecognition.strange,f60da11b2dfb31d757796a40abf52e9d87d29dfe

com.preferencestiffmodern.tapfield.permission,529c2436a0c68cc86c859ba03892e546dbedcfd8

com.statequartersteel.tunethan.tonight,2614cef8502e8898bf37ad4b64e342d770d2c860

com.preferencestiffmodern.tapfield.permission,fb22dfc61b633d302268c06281a6c523eadf1f58

com.centerincludeblade.eletricscreen,39be5d4e81956b6419899dea35d39e22a7dc656d

com.charmscreenproblem.eletricscreen,730186c1d808f121f07ca0416a04783565e79e67

com.connectgatherspeech.eletricscreen,0e458b8fecd238bffd40e4565c595cd2add729ae

com.blockverbfemale.journeyonly.during,287c2fe136255e480a36217e85cca3ba842d260e

com.faintacrosshole.provideair.actual,7d2fd45f3641bb2d8b4bbde047474abd294b3460

com.red.taskapk,b5e3bfc6d7a97baf18edbe13a10bd3b1162bd1ce

com.hurtgoldstorm.separationshirt.north,e4e04124bd6687a8174c21f0b87ea80484de9f68

com.cloudmaybepassenger.eatdirector.sink,13311cf1554370f1f5101f1e4f5283947f63e056

com.eveningworshippity.refernail.prejudice,4bc43d5c5cceae6ccdd768059268dfaaf1f331d1

com.acceptbreatheessence.tonightbridge.wisdom,c37a8ee27ab60a30af46b563f70b3c8c9bc89792

com.clockeffectivewander.damagemind.profit,b19dc2284216a4e0ea528b8ba0606640ad659601

com.cottagehotelremark.furtherverse.effective,c1bcf5265710ed776d951a5ab95f81e36183fc03

com.discussiondistancebook.crackscreen,9e0ad212d35fd722f144d252a679766367764048

com.theessenceattract.countrycall.police,bf3fb908cee958468c5416d0416ef7a207d5a5cd

com.pinkmankindknife.politicalpen.rabbit,c2775bfa6a99112ef849e7dd1600117c62314afb

com.charmscreenproblem.eletricscreen,ae10890b0c4108f13ca063440db0c3ea90f497ef

com.pagetraypower.landknowledge.patience,bbf9c263c680e047d21b2b614bbb866a49612793

com.consciousmarrycustom.stationprint.damage,1fd1287ab8e1992c5cb73f2624d88e18feea51f4

com.timestrengthidle.boxpaste.land,cdfe2f9c640297098533e51e6b265dc60455c1ae

com.engineerrailroadcreep.wishdeserve.lessen,5911d4fc512ca8c245aa6aee9100a200ea46eb4e

com.nicedevilposition.beardsugar.dry,14d9cb259c4e89132e60e39eb4cf2d52b5cdccba

com.sweetknifeverb.leadershipbalance.quiet,bba636226cdfad7f5060852b95216c0e32ee14d1

com.mayreceivewelcome.spotconfess.inquire,609cb5b5936b62ca41943e5fa6956292874bcd0e

com.femaleappearaddress.attractivequality.moral,011665ec4cfc5d32b48e13787e901eb8a84ec935

com.attemptbutbehind.extremelack.among,b78f2d27833f723d1e901a9391d973561916bafa

com.sonbottomsecretary.purposevoyage.introduction,3e5ba2533c53246f12924b10ec0ffed9ade4a32d

com.abroadvictorycorn.eletricscreen,9151621714f1499a4b6124b033ab938019b20a95

18


com.abroadvictorycorn.eletricscreen,e86444d56ce7ad22234f54455225447e6d5d2b1a

com.curelengtharise.eletricscreen,85169820e100641487cd7c5ebedad7dd405fd7d6

com.discoveruntilchest.archsuspicious.eastern,390f5a85d08ac231984c57c50f6e2c9f8028776e

com.jawdespairbackward.advancecreep.island,c31d7f5d3b8faa13a1dea0dd97c886c3ece1229c

com.mapwisdomcheck.morningsecond.have,fb1be2c98157303841fc77b587c4e0697437763b

com.ageconfidencedelivery.machineryrather.basis,8d0dc5f60d231eed4c3c25d2a77cbba17b3d0423

com.develoployaltyfinish.flowhit.fun,09b372410790d79a06e6f477b0ea56a7112808a3

com.theessenceattract.countrycall.police,8831c23520785af930362b23e44b7fda38c7f656

com.attackartificiallamp.eletricscreen,6806b26721d62774e3ce35bb2623a76a56b9f3e7

com.burstearannoy.ele,02f9bbf021b24f3c8e2f7bc583931753bf114113

com.centerincludeblade.eletricscreen,de3e612e1da3b5a3dbd8d12df8b81d40576cc6f7

com.charmoceanwarmth.eletricscreen,dd5196019d5faf4d3d399ee60cfa69bbff0e28c0

com.forestuniversalfinish.mountainoutline.right,1d39fb974d80e6adc2fc0c00d8699d164d396635

com.lessonsuchbrown.elephantcharm.help,8d1eed7bfaf37a1c8d60532bbb3c73b3e97a9083

com.secretfacedrink.factquick.reference,34bbb8f3b5cfb67463de4d5e7677e3e50c2f607a

com.necessaryexpensiveknowledge.barrelleadership.steam,34271a6e1627b317e6dbd8e98f61cb4a8c0daf92

com.doubtswallowchicken.nightvision,954d5dff6ce371a89886b6edc9e425ca1fd578a1

com.downmonthtend.xray,2b497258d81c4385239387023f6fcc7aaf3531b5

com.godbendhuman.xrayscaner,c19492d8fa29d25f6ac56d1c622afd454669cf78

com.curvesentencecake.eletricscreen,604420aa00aa40fab45abc8bb9db27edce4bf71b

com.backaroundhumble.ablenative.state,0adc722b46dec4b719613c9e28d7c51ece72ffdf

com.believegratefulcollection.xray,9e7f0bb3ad88a5580b83b4359209c4869e19216c

com.busymarchprevent.eletricscreen,564a7028ef4c76800c8a6130bc58060ed241a20e

com.businessprisonice.eletricscreen,eb9bd8ff5f4e0235bc07530e80968aa4abb5de70

com.charmoceanwarmth.eletricscreen,22a0446ab4ab528c7a1693e4ea5706d3086b5330

com.supposecomedoubt.considerwidth.farm,7f327903bf28bc648daf610ab3842eabc656ea41

com.soldierexceptionbus.autumneverything.except,f938976a30cf809d825d9583d1dabad1c7e7545d

com.destructiondealafraid.poetmud.grass,2d22b0d6e223154bc8a24fb73e7bc7df2976b855

com.needdisciplinesharp.tideland.may,e68f50cef1a9f0c8e398c8bfe1bbea55518e39bc

com.pridesugaronce.slaverynetwork.whistle,34a6bbb02a580ff1b78160233de368e28cded7c0

com.dishflowstore.suspicionvessel.avoid,ed2421cea491e17078d1ee5a10537eeb99084470

com.pleasantdelayfair.healnorthern.altogether,7ea4129d73bc38d8609d025185cace3631e81c9f

com.heatbreathecommand.cowlean.dream,db5730a4ba36b9023ea90f4797bebe3cb3806efc

com.snowcontainpublic.ribbonapart.hill,0bdcb6dff5f18d6d14e2f1ce40cfab5bb7e71190

com.liveencourageenvy.chesthowever.rain,513ca7bb8d18cf2a278a1cad3a89337ce992bf7f

com.canhousetremble.eletricscreen,e4c7f49a0604c40e37293642d796e3a0eebf501d

com.chainheaddistance.eletricscreen,bce74659ea0ab5df83e74fd845214089414d2103

com.visitsouthmedicine.dreamwalk.solemn,0fddbe77177c7861a6309b1e68d16b8b43c1277c

com.fastendependentadvance.hairsake.towel,e1de72bf9bf42f501cf2f87dc722ccb48f8fdbd5

com.belieftreasureliberty.darkseveral.only,f3bffdea50faa14227a71ae61348d4e09f4bfee0

com.secondwarmsorry.parentgray.difference,1d5d8941049236e036711ac27ffba94899283217

com.learnprettyactive.confidenceexcess.certainty,bc4abe0068e4d096bce60d0607b9c0583de505f2

19


2014 © Telefónica Digital Identity & Privacy, S.L.U. All rights reserved.

The information disclosed in this document is the property of Telefónica Digital Identity & Privacy, S.L.U. (“TDI&P”) and/or any other entity within Telefónica Group and/or its licensors. TDI&P and/or any Telefonica Group entity or TDI&P’S licensors reserve all patent, copyright and other proprietary rights to this document, including all design, manufacturing, reproduction, use and sales rights thereto, except to the extent said rights are expressly granted to others. The information is this document is subject to change at any time, without notice.

Neither the whole nor any part of the information contained herein may be copied, distributed, adapted or reproduced in any material form except with the prior written consent of TDI&P.

This document is intended only to assist the reader in the use of the product or service described in the document. In consideration of receipt of this document, the recipient agrees to use such information for its own use and not for other use.

TDI&P shall not be liable for any loss or damage arising out from the use of the any information in this document or any error or omission in such information or any incorrect use of the product or service. The use of the product or service described in this document are regulated in accordance with the terms and conditions accepted by the reader.

TDI&P and its trademarks (or any other trademarks owned by Telefonica Group) are registered service marks. All rights reserved.

AUTHOR:

ElevenPaths

At ElevenPaths we have our own way of thinking when we talk about security. Led by Chema Alonso, we are a team of experts who are eager to redefine the industry and have great experience and knowledge about the security sector. We focus all our experience and effort on creating innovative products that make digital life safer for everyone.

Security threats in technology evolve at an increasingly quicker and relentless pace. In this context, since June 2013, we have become a startup company within Telefónica aimed at working in an agile and dynamic way and at transforming the concept of security, by forestalling any future problems that may affect our identity, privacy and online availability.

Our head office is in Spain, but we can also be found in the UK, the USA, Brazil, Argentina and Colombia.

CONTACT US

elevenpaths.com Blog.elevenpaths.com @ElevenPaths Facebook.com/ElevenPaths Vimeo.com/ElevenPaths

Technology

Shuabang with new techniques in Google Play