Cybercrime is already a global scourge...Do you really think you are protected?

Wednesday, December 23, 2015

Nowadays, the exponential development experienced within the ICT field has led to a new scenario where the organizations are capable of exchanging information more effectively, stablishing new business models, and in general, decreasing operational costs while increasing their levels of efficiency and profitability.

Nevertheless, the technology has evolved for everyone, enabling cybercriminals to take advantage of these new and more sophisticated techniques, even perpetrating coordinated and complex attacks against organizations or their supply chain within a few minutes. Subsequently, this fact has driven to a new generation of threats and cybercrime which imply greater risks and a bigger impact for companies.

In fact, the latest figures indicate that the cybercrime cost already represents 0.8% of the global economy, even exceeding the drug and arms trade. The fact is that any organization can be attacked. The cybercriminals do not discriminate on the basis of the company location, size, industry or ethics anymore. Actually, recent studies show that the 97% of the organizations have been hacked or breached to a greater or lesser extent, and the 69% of the detected threats have been discovered by external agents, which means that the internal traditional means are not sufficient anymore.

Another clear example which shows the organizations are not prepared for this new scenario is that, according to the new figures resulting from the latest global reports, these ones take over eight months on average to notice and fully recover from an attack, fact which, in some cases, can result in a critical impact for the organization, and even becoming a threat to their own survival.

Therefore, it is clear that the traditional approach (castle security) is no longer sufficient to face the risks the organizations are exposed nowadays, but a focus beyond the own organization environment becomes necessary, focused on the security risks which impact on their business, included their supply chain. In this sense, the implantation of a new risk management model which adequately coordinates the capacities of prevention, detection, analysis, mitigation, response and recovery becomes essential.

For the purpose of addressing this new scenario, ElevenPaths counts on CyberThreats, whose holistic risk management model focused on cyberintelligence, help prevent, detect and respond continuously which against cyberthreats which might represent a high impact on the organization´s business model. Below the main modules on which CyberThreats is structured, is shown:

Overall, thanks to our expert team specialized in Threat Detection and Incident Response, along with the orchestration of our own proprietary technology and processes combined with the market´s best practices and strategic alliances, the organizations can benefit from a continuous advanced support through the entire threat lifecycle, which facilitates the decision-making process and corporate risk management. The next graph summarizes the CyberThreats' performance model, from the multiple-source scouting to the value delivery to customers:

For further information, please visit the CyberThreats webpage or contact us:

You might also be interested in:

Manuel Muñiz Somoza

Metashield for Exchange soon to be available. How does it work?

Wednesday, December 16, 2015

Metashield for Exchange stacks up to our currently offered server-side metadata cleaning solutions and broadens the flexibility and customization options that we offer companies to get rid of sensitive information and metadata leaks.

A plugin for Outlook is already offered but depending on the needs and architecture of an organization’s servers it may opt for a centralized Exchange-specific solution. In this case, it will be easier for the end user because the cleaning process is completely transparent and occurs asynchronously on the server.

So where exactly does Metashield For Exchange fit in the Exchange message pipeline? There are several roles that run in Exchange servers such as Mailbox, Client access and Edge Transport server roles. Metashield For Exchange is installed to Mailbox servers as a plugin-like "Routing Agent" and resides more specifically in the "Transport" service.

Once configured, instances of Metashield For Exchange are then spawn according to outgoing messages. These instances bind to the "OnSubmittedMessage" event of the message delivery pipeline and perform the cleaning process of the document asynchronously using the "Metashield Engine" service. As soon as the document is clean it’s sent forth to the pipeline until its destination.

This way we ensure that every single outgoing document is metadata-free when reaching our organization mailserver’s outer boundaries.


However there are cases that a certain email attachment should not be cleaned and metadata should be maintained. For this purpose the administrator can define advanced rules to skip those messages and leave them "unclean".

Configuring Metashield whitelist
As for customizable options, a caching layer is available and configurable as memory or file based. Considering the case of forwarded message chains containing attachments, the use of a cache may result in significant performance boost. We reccomend its use.

Using cache in Metashield for Exchange

Of course, the profile and template based cleaning system known from other "Metashield" products is maintained. For the sake of example, let’s see a real world configuration where documents should include information about a company but all other metadata is cleaned:

A step by step example
First of all a new template with the desired actions needs to be created. This one will be a simple one for demonstration purposes.

Creating a new template

After that, the newly created template should be assigned to the desired extensions or extension families.

Add the template to a profile
Upon applying the configuration "Metashield" will start cleaning all the newly configured extesions and will include the company information that we’ve configured in the template. That simple. 

Overall we hope that Metashield For Exchange contains everything that a System administrator concerned about security needs to prevent metadata leakage in corporate emails, while maintaining usability and good performance.

Plugin for EmetRules: Now, easier to use

Sunday, December 13, 2015

EmetRules is a simple tool we created two years ago. Not meant to change the world, it was a first incursion in certificate pinning universe, and intended to ease one of the harder-to-use-features of EMET: pinning. We have developed now an easy plugin for Internet Explorer that uses EmetRules, so pinning with EMET is easier than ever. Let’s see how it works.

Internet Explorer is one the only (main) browser not supporting HPKP yet. In fact, is the browser with fewer options to pin certificates in general. EMET included a few versions ago a feature for pinning, but it was indeed complicated and tricky to use. So we created a simple tool called EmetRules to pin lots of domains at once.

EmetRules counts with some fans. So we have created a very simple plugin for calling EmetRules from the browser itself, so it is even easier to pin a domain. Just visit it, and click a button. The domain will go to EMET configuration and will be pinned there

EmetRules itself has been updated to support being called directly from Internet Explorer, just adding a new option. To better explain it, a few screenshots of how it works:
  • Visit the domain you want to pin with Internet Explorer.

Visit the domain you want to pin
  • Click on the icon in the bar, or right click somewhere on the webpage and "Pin with EmetRules"
Use the icon or the entry in the right click menu
  • The first time you use it, a warning signal will appear. It is ok as long as the program is signed by us. This means the operative system is telling you an external program is being called from somewhere inside a web and wants to go out from the protected mode (is going to be launched in medium integrity level instead of low).
Warning about executing a file from the browser
Now it on depends on the "traditional" EmetRules. A command window will be launched, it will fetch the certificate for you, build an XML file and feed EMET.
  • If you are an "admin and not an admin" (you are using UAC), an UAC dialog will prompt, since inserting domains in EMET needs administrator privileges.
  • If everything is ok, the domain will appear in EMET pinning panel.
The domain is finally pinned in EMET

If you want to modify default settings, just modify the html file (JavaScript) in the installation directory.

 Hope you enjoy it. The new version may be downloaded from here.

IoT - The new security headache for the enterprise IT department?

Wednesday, December 9, 2015

2015 could prove to be the year that enterprise adoption of BYOD takes a step further, and evolves into BYOIoT. Several reports (i) have already predicted the rise, spurred on by the popularity and proliferation of wearable devices in the workplace. What’s essential is that IT departments are aware of how to manage the resulting security and ecosystem challenges this will bring.

The great benefit of IoT is that connected devices are able to interpret and interact seamlessly with the networked environment around them – proving seamless usability and convenience for the end user. The issue for the IT department is that any connected device can theoretically collect and access sensitive information purely because they’re located on the company’s premises. Similarly, since they are usually connected to the corporate network, they can not only exchange data with internal systems but also with external servers. In many cases internal data must be protected, and IT departments will want to control what sensitive information is accessed beyond its network. There is no doubt that connected devices allow employees to be more efficient in their daily operations but are companies fully aware about the security risks that their use also involves?

The potential for security breaches increases with the uptake of IoT polices in the workplace. What is disconcerting is that IT departments often have little or no control over new devices connecting to the network. This has been backed up by a recent study (ii) published by OpenDNS which found that IT professionals are often completely unaware of the presence and prevalence of IoT devices on their corporate networks.

This apparent lack of control contrasts with a 2013 Forrester (iii) study which stated that security concerns are the main reason businesses are slowing down the incorporation of workplace IoT technologies. This surely begs the question, if security is considered such an important element, why aren’t special measures being put into place? Perhaps the answer lies in the ambiguity in defining what an IoT device is.

To get a hand on the solution IT departments must first identify the risks, which are as follows:
  • IoT devices are a new remote attack vector for security exploits. Devices are not designed in line with individual business security requirements and cannot be updated easily to conform with corporate network policies.
  • They often use external clouds beyond the control of IT departments. Without the implementation of traffic control measures, internal data risks being compromised.
  • Users tend to consider these devices as toys and are not aware of the security implications that their use has on a corporate network.

The solution for IT departments can be neatly surmised in one word… visibility.

The infiltration of IoT devices in the enterprise is clearly underway, as such companies should review their current policies to mitigate potential risks, and once identified put new policies into action where necessary. Most security experts surveyed in the OpenDNS report rely on measures relating to network design and deployment to contain threats, but is it enough? In our point of view, these measures are simply necessary but not wholly sufficient.

We propose two approaches.

Firstly, we consider focusing on the terminal absolutely necessary. This approach not only identifies all the devices that are within the company premise, but also catalogues and monitors them in order to meet corporate security guidelines. It’s a similar approach to that already undertaken in Mobile Device Management solutions and BYOD policies.

It is no coincidence that MDM vendors consider IoT as the next big challenge for their organisations (iv). MDM platforms have grown from a core set of rules associated to the use of smart phones at work to the complete management of any device, including tablets, laptops and even electronic ink readers. With the introduction of IoT and wearable devices, the next logical step is to implement new functionalities to manage all these devices remotely. There is no doubt that a promotion of industry standards will make the collaboration among different device providers easier to manage. In addition, it is important that these assets are included within the scope of security audits performed internally by company’s IT department.

Secondly, the approach from the network side should relate to traffic behavior and subsequent analysis. Think of like this, when facing an unknown illness, the best way for a doctor to work out a medication is to identify the symptoms. Everything that is outside normal patterns is likely to be harmful and should be investigated. By examining network traffic using big data matching tools it becomes possible for the IT department to construct behavior models capable of discerning anomalous situations. In this way they can identify new devices, connections to unknown IP addresses, suspicious traffic or strange commands.

IoT is already within the enterprise environment, and the only option for companies is to evolve and adapt their security practices accordingly. Ignoring the threat will not make it go away, and IT departments need to be on the front foot when it comes to identifying and mitigating against risk. After all, what is not known cannot be secured.

i 'Bring Your Own Internet of Things' coming to businesses in 2015
ii The 2015 Internet of Things in the Enterprise Report
iii 'Mapping The Connected World' by Christopher Mines
iv IoT in the E: How the Internet of Things Will Transform the Enterprise

v Also it can interest you:
BANDS: Detección proactiva de amenazas en infraestructuras críticas
Qué hemos presentado en el Security Day 2015 (III): un combinado de Tacyt y Sinfonier

Inside Mobile Connect (I)

Monday, December 7, 2015

This is the first of a series of technical articles about the Mobile Connect architecture and the different components that make it up. But, hold on a second… what is Mobile Connect about?

Mobile Connect is a mobile centric solution that aims for MNOs (Mobile Network Operator) to become a trusted identity service provider to third party providers. However, Mobile Connect is not only a new way to authenticate users in the mobile network. Moreover, it provides a way to link the digital and real identity of a person and protect their data, giving them back the control for sharing this information when, where and who with.

MobileConnect takes advantage of the MNO assets such as the mobile device and the SIM card. Thanks to these assets the MNO can almost always reach the user and send a challenge to authenticate them. In that way, the user’s device turns into a kind of addressable support that keeps the user identity that in turn can be validated by means of different authenticators or different ways to authenticate the user.

These different ways to authenticate users provide different validation security levels. This is the so called Level of Assurance (LoA) that describes the degree of confidence in the authentication process. In short they provide certain assurance that the user who is being authenticated is who they claim to be.

Mobile Connect Logical Architecture (Telefonica Implementation)

Note that Mobile Connect is an interoperable solution. Therefore it must work with any MSISDN from all the MNOs onboard in the Mobile Connect ecosystem. This is accomplished using a discovery process that occurs in a previous phase to the authentication process. The aim of the discovery process is to find the Identity Provider the MNO user belongs to, and redirect them to the MNO Mobile Connect implementation.

The figure above shows a very high level architecture of the Telefónica Mobile Connect system, but it does not give us too much information. It seems that there are a set of boxes that you can combine and voilá! you have an implementation of Mobile Connect, well... It is a no brainer that it cannot be so easy, right? 

Don’t worry, in the next section we are going to try to explain the main functionality of each component in the architecture and its role in the mobile connect authentication process flow.

Telefónica Mobile Connect Architecture

Our Mobile Connect implementation is based on a set of microservices that in turn make up larger components or subsystems which each have a specific role (see figure above).

You can distinguish three main functionalities in Mobile Connect: 
  • The Identity Gateway, the brain of Mobile Connect, offers the interface for the Service Providers to be integrated in Mobile Connect.
  • The Authenticators, provide user validation.
  • The Data Gateway gives the user’s attributes.

Mobile Connect interface to Service Providers follows the Authorization Code Flow of the OpenID Connect protocol, where Service Providers act as the RP-Relay parties in the OIDC protocol.

Abstract of the OpenID Connect protocol steps

Identity Gateway (ID)

The Identity Gateway (aka ID-GW) server is a component that can be broken down into a set of individual components. These components meet the functionality of Identity and Access Management along with the functionality to control and protect the resources that show the attributes that can be shared.

OIDC AuthServer

It is the core component that implements the OpenID Connect protocol as per the OIDC Mobile Connect Profile. It shows the Authorization and Token endpoints. It receives the authentication request, checks if the client (service’s app) is allowed to request the claimed scopes and, in such event it sends the request to the authenticator selector. In addition, in the case of successful authentication, it generates the authorisation_code and the access_token, along with the id_token server.
Authenticators Routing Subsystem

This component is called by the OIDC server during the authentication process. It selects the right authenticator based on the context in the request (e.g. LoA), routing policies, etc. and prompts the user to provide their credentials where appropriate.
Token Manager

This component creates the id_token, access_token and the authorisation_code in the auth_code flow. It also offers an API to query the information associated to an access_token.

Access Gateway

The Access Gateway shows the UserInfo endpoint. It aims to protect access to the real UserInfo resource showed by the back-end. The Access Gateway acts as a proxy that receives the request from the service provider, checks the access_token against the Token Manager to determine the client granted scopes. If the client has the necessary scopes to access the requested resource and the request upper limit has not been reached (traffic throttling), the Access Gateway routes the request toward the Data GW providing the granted scopes.


This component offers an API to provide any data that the ID-GW needs to carry out the different tasks for which it is intended to: the scopes, products (set of scopes for different grant types), devs, apps and APIs.


This component shows an HTTP REST API to manage the provision of the Mobile Connect users. It will be used to register, update users, etc.


These components represent an abstraction layer that allows the ID Gateway subsystem to talk to the different authenticators in the MNO. All the Mobile Connect authenticators are Mobile Centric authenticators, that is to say, all of them authenticate the end users interacting with their Mobile phone.

Authentications using Mobile Connect SMS+URL

 In the next few paragraphs we describe some of the most common authenticators used in Mobile Connect, taking into account that a big list of them can be integrated in the solution.

SMS based authenticator

SBA sends a SMS to a mobile phone number. This SMS should have a code (OTP), a link or both in order to authenticate the user.

  • OTP: sends an One Time Password in the SMS that must be validated in the form entry.
  • URL: sends a URL in the SMS that must be clicked by the user to be authenticated.
  • OTP+URL: sends an OTP together with a URL. The user can submit the OTP in the form entry or click the URL to be authenticated.
MSSP (Mobile Signature Service Provider)

This component is the server side of the SIM Applet based authenticator. It can deal with both LoA2 and LoA3 authentications, by sending a challenge using a "class 2" binary 3.48 SMS to the end user’s SIM. This message reaches the SIM directly without any possibility to be intercepted by any application in the mobile phone.

Then the SIM wakes up an applet asking the user for consent using "click-ok" or by a PIN/Personal Code. Once user verification is done, the applet returns an authenticated response back to the MSSP. The MSSP validates the response and gives back success or error. It is worth it to point out that all messages between the MSSP and the SIM are end-to-end encrypted.

FIDO Authenticator

This component implements a FIDO Server authenticator which will send a challenge to authenticate the user by a biometric authenticator in their mobile phone.

Remark: these are some of the authenticators that can be used to authenticate user in Mobile Connect. However, as one of the key requirements of Mobile Connect is to be able to authenticate the end user irrespective of the underpinned authenticator, it needs to have a flexible way to integrate the ID-GW with the different kind of authenticators that show different APIs in turn. To achieve this objective, an adaptor (based on redirections) has been built per every authenticator to communicate it with the ID-GW.

Data GW (Data Gateway)

This component will be connected to the different sources in the MNO or to potential 3rd parties. It gathers all the attributes that will be showed in the UserInfo endpoint and probably other future info endpoints with extra information.

Mobile Connect makes headway with launch of cross-border pilot

Friday, December 4, 2015

European trial makes Mobile Connect the first private-sector cross-border public service authentication solution compatible with European Union eIdentification and Trust Services (eIDAS) Regulation.

Throughout the next few weeks, Mobile Connect will be trialled in two EU Member States, establishing proof-of-concept for cross-border authentication to e-Government services. The pilot, launched on November 16, will demonstrate how Mobile Connect can be used to identify an EU-citizen of one Member State in order to gain access to a public service of another. Mobile Connect offers a simple way of achieving pan-European federation of cross-border services for the EU governments compatible with the eIDAS regulation, whilst enabling growth in digital public services nationally.

The trial is taking place between Spain Catalunia and Finland, and will enable customers of participating Spanish operators, to log-in to a Finnish eGovernment service, and on the Catalunia side the log-in through a digital identity validator granting access to a complete public services portfolio. The customer experience is the same in both countries: After the customer presses the Mobile Connect button and enters their mobile number on the discover page, a PIN request appears on their mobile phone. By entering the correct PIN, the user’s identity is confirmed and the customer is logged-in to the eGovernment online service.

The pilot is the result of collaboration between organisations seeking to accelerate the uptake of trusted and secure digital authentication in response to the eIDAS Regulation. The Regulation aims to enhance trust in electronic transactions in the EU internal market by providing a common foundation for secure electronic interaction between citizens, businesses and public authorities, thereby increasing the effectiveness of online services in the EU. The GSMA with major operators, Orange Spain, Telefonica, TeliaSonera, and Vodafone Spain are supporting the trial, as well as Gemalto, Mobile World Capital, the Catalonia Regional Government, the Finnish Ministry of Finance and Finnish Population Registration Centre.

Hear from the participants in the trial on their experience with Mobile Connect:

“Finally with Mobile Connect we can create international eID services that are based on real identities, and for those identities we can create a new breed of trust services for a global market.” Joni Rapanen, TeliaSonera.

“We in the Ministry of Finance are very satisfied with this successful project. Our role was limited compared with the participants who planned the actual trial, but the results are very important to us when we are building a national trusted network for e-identification.“ Mr Olli-Pekka Rissanen, Special Adviser, Ministry of Finance.

“Orange Mobile Connect solution meets the needs of our customers for a secured journey and also paves the way for a rapid take-off of eIDAS services” Alicia Calvo, Innovation Director, Orange Spain.

“Mobile Connect is a key component of Telefonica’s security services. It has greatly expanded the identity and privacy solutions we offer to our customers José Luis Gilpérez, Defense and Security Director, Telefónica.

“For Vodafone, it is important to provide to our Customers confidence and simplicity when using digital services. Mobile Connect will be a key enabler of the Customers Digital Journey” Ibo Sanz, mCommerce Director, Vodafone Spain.

“The identification and trust services for electronic transactions in the internal market aligned with eIDAS regulation, is a milestone for a Government of Catalonia to provide a confident environment to enable secure and seamless electronic interactions or transactions between European businesses, citizens and public authorities. In this regard, this experience, is focused on this European government’s spirit of collaboration” – Jordi Puigneró – General Director for Telecommunications and ICT at Government of Catalonia.

Oscar Pallarols, Smart Living Director at Mobile World Capital Barcelona. .

The trial occurs just weeks after the EU’s recent adoption of the implementation rules of the eIDAS Regulation, which makes the EU the first and only region in the world to have a legal framework for safe cross-border access to services and online interactions between businesses, citizens and public authorities.

The Regulation is part of the European Commission’s push towards the Digital Single Market, and is designed to enable citizens to carry out secure cross-border electronic transactions. For example, enrolment in a foreign university, filing of multiple tax returns, access to electronic medical records or authorisation of a doctor to access these on one’s behalf. It will also enable citizens moving or relocating to another member state to manage registration and other administration online with the same legal certainty as they currently have with traditional paper-based processes.

Mobile Connect’s technical architecture follows secure user authentication requirements provisioned by the eIDAS Regulation, and its technical specifications of implementation – and is the first private-sector cross-border public service authentication solution to be compatible with it. As such, the pilot will test how eIDAS cross border authentication works and reveal any practical challenges in implementing the solution.

The solution is ideally placed to address both service providers’ needs acting as a primary log-in for websites, apps, and other online services and consumers’ demands for straightforward and secure authentication and identification. Mobile Connect can help government agencies and other service providers increase usage of their online services, improving efficiency, enriching the end-user experience and increasing engagement. With the demand for secure and convenient authentication for digital services at an all-time high, this pilot further illustrates the market readiness of Mobile Connect. To find out more email the team at

Source: GSMA

Original post Mobile Connect makes headway with launch of cross-border pilot by GSMA.

ElevenPaths Black Friday

Thursday, November 26, 2015

The highly anticipated Black Friday starts at Eleven Paths with the very best desktop tools against metadata.

Friday November 27th Metashield desktop suite of products for Client and for Outlook can be exclusively yours for free for 1 year.

Use the codes Black Friday and will turn on the best technology of preventive security on your computer against leakage of metadata.

Links of products:
Metashield Engine Stand-Alone 3.2

Metashield For Client SA 3.2

Metashield For Outlook SA x86 3.2
Metashield For Outlook SA x64 3.2

Black Friday 1 year free activation code:
Metashield for Client: BLACKFRIDAY27NOVMSCW
Metashield for Outlook: BLACKFRIDAY27NOVMSOU

Activation mail:
Do not let this chance go away.

More information on

* 27 November one day special offer.

Quick and dirty script in Powershell to check certificate fingerprints

Sunday, November 22, 2015

Malware is using signed binaries to attack Windows systems. Malware needs it to get into the roots of the operative system. So attackers steal or create their own certificates. Everything counts to "look good" for the users and machines. Sometimes, when a signed malware is discovered, you may wonder if any of the binaries in your machine is signed with that certificate. This is a simple powershell script to get that.

Script in powershell

With Powershell, retrieving the fingerprint of the certificate is quite easy. Just a few lines of code. Since most of the suspected machines will be Windows and all modern versions are able to use Powershell, this a simple solution. Just add the certificate fingerprint you are searching for in your computer, tell the program where to start from, and that is all.

To use it, just create your txt file with some fingerprints. For example, these are the fingerprints for the certs used in TheFlame (2012) and WildNeutron (2015) operations respectively.


We have uploaded the code to our Github. Whatever good idea you may have to improve it, just share it with us in our community.

Please note this is "quick and dirty" code with both practical and educational purposes.

Research: On the overexposure of Amazon credentials in mobile apps

Sunday, November 15, 2015

The development of mobile applications that interact with common services in mobility environments such as Amazon Simple Storage Service (S3), Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) or Amazon Mobile Analytics is becoming more frequent.

To interact with these services, apps need to communicate with them and authenticate with some kind of credential (usually based on tokens). We have identified unsafe programming practices in the form of poor management of login credentials, which could allow an attacker to modify the behavior of the affected apps.

Identity management in Amazon AWS

Mobile app developers need their own access keys to programmatically call Amazon Services. They can use the AWS Command Line Interface (AWS CLI)  , AWS SDKs or direct HTTP calls using APIs for AWS individual services.

The latter is more common in apps communications. From the Amazon Management Console, access keys, known as access keys and secret keys can be created, modified, viewed or rotated. These access keys are valid to programmatically interact with the contents or services offered by Amazon. Apps that use these contents must therefore know the access keys.

Although there are more appropriate methods, some programmers embed this information in the app itself. If access is read-only, this can result in a bad programming practice, but not necessarily in a security problem. However, if permissions are poorly established, contents could be controlled. If, in addition, access keys are accessible by anyone analyzing the application, an attacker could modify those contents that later on would be used by the app.

If necessary measures are not taken when setting access permissions of the API keys, anyone with access to the keys could not only access the information, but modify it.

However, access keys can also be introduced into an app through a credentials file located within the APK, in clear text. This way, apps are easier to manage and maintain. This file is generated with the AWS CLI. Its default name is, and its format is similar to the following:
(Falso) example of credentials
With Tacyt , ElevenPaths’ Cyber intelligence Tool for mobile apps, we have searched how many apps in the different monitored markets contain a file of such type, subsequently verifying the nature of the associated credentials.

First seach in Tacyt for APKs with this kind of files

At the time of writing this report, we found 1,635 APK files containing a file of this type in our database, formed by 4.5 million apps. Those 1,635 files correspond to apps and also to different versions of those same apps (hashes) stored in our database. Unique apps (regardless of their version, and on the basis of unique package name) are actually 478 different apps distributed over different markets.

We have studied the situation of credentials and if they represent any risk.

Data analysis

These are the results obtained after analyzing the apps containing files that could potentially pose a security problem:
  • Of all studied apps, 102 are no longer in the official market and have been removed. Although removed, they still to pose a problem, since the apps remain in the installed devices, and furthermore, credentials do not stop being valid even so.
  • We have found 478 different apps containing valid credentials. 408 of them in Google Play.
  • However, the number of different access keys found in all markets is not too high: 63. This means that several of those 63 credentials are distributed between different apps. In other words, many seemingly different developers share valid AWS accounts. In particular, two different credentials are shared in 523 and 196 different versions of the apps. There are only 26 unique credentials that are not shared and that are found in a sole app.
  • 37 of the 63 access keys found remain fully operational, which means they allow the correct performance of the authentication process. The valid access keys shared have the following distribution. Among the valid access keys, one is distributed in 523 different versions of different apps.  
  • Of these access keys, we have obtained permissions (ACL) from 26 credentials. 
  • 22 access keys kept FULL CONTROL with those credentials. This means that some contents hosted on Amazon could be read, written and even edited.The rest of them allowed Write, which for practical purposes also poses a security problem.
  • The credentials found on Google Play are distributed over 408 different apps. In turn, many seemingly different developers share credentials. It is interesting to see how there is a single credential present in 74 different developers, each one with their respective apps.
Of the 74 credential-sharing developers on Google Play, it should be noted that most of them seem to be magazine publishing companies and media in general, some of them quite known. This suggests that these companies’ apps have been developed by the same team, which has somehow reused part of the resources, including the infrastructure in the cloud and, with it, the access credentials. This exchange of shared credentials between different apps that load contents hosted on a third party opens an interesting attack window, depending on the credentials permissions.

It is necessary to clarify that not all apps containing credentials have to use them. It can simply constitute a "bad practice" if using the appropriate permissions, which means that, even if it involves exposure of sensitive information, in practice it does not open any security breach or attack possibility against app users or developers.

The Android Trojan preinstalled in Amazon Tablets is in Google Play as well

Friday, November 13, 2015

Researchers from Cheetah Mobile have found Trojans preinstalled in some cheap Amazon tablets, very hard to remove. But, here in ElevenPaths we have found that a version of this Trojan is present right now in Google Play hidden as a HTML 5 games application. The malware has been dubbed "Cloudsota".

The app, still in Google Play, made by the same band of "Cloudsota".
The Trojan found by Cheetah Mobile, is preinstalled in tablets, restores itself after reboots if deleted, hijacks the browser homepage and downloads apps from some servers to install them silently if the device is rooted (which, in these tablets, is very likely). We found a very similar behavior in a Google Play app, downloading apps from the same servers and with quite similar code. What we can be sure is that is made by the same people behind this Cloudsota. Although maybe with enough changes to be able to get in the official market.

How it works

Once the apps found by Cheetah were analyzed, thanks to Tacyt, we found a strong correlation with just one out of 4.6 million apps in our database. It has been in Google Play since August 2015. This app, when booting or if a user is present (unlocks the screen), calls a method called "b" inside the class, that visits this site hxxp:// and sends some interesting information.

JSon sent to the server before being encoded
After sending some encoded personal information (email, MAC, if the device is rooted or not, etc) it finally downloads (with some encoding as well) a dex file called business.dex. We guess the file may be different depending on this information previously sent.

The code to download and use business.dex
This business.dex is terribly offuscated, and contains most of the malicious code. Business.dex is as well programmed to download different versions of business_X.dex (the X depends on the configuration in the device) that we suppose that makes its behavour quite unpredictable.

If busybox util is found in the device, it tries to load libraries, install and uninstall apps... This is done just before business.dex is downloaded, we guess this is for uninstalling any antivirus the user may have just before downloading the (even more) malicious code, that is more likely to be detected.

Triying to uninstall code

As far as we know, the app itself or the business.dex does not contain code to survive and install itself after reboot or hijack the homepage, but it definitely could, as we can see some references in the code. 

It may hijacks the homepage
Aside, it shares with Cheetah samples, the use of a very particular library
It uses, shared with Cloudsota

The app in Google Play is detected by some antiviruses. But most of them do not detect the app because of this behavior, but because of it containing some Airpush SDK code. Airpush was considered a potentially unwanted adware SDK long time ago by the antiviruses. It is interesting as well that the app has been downloaded 5.000 and 10.000 times, but only 3 votes have been given.

Too many downloads for so few votes...

That make us think about some time of artificial boost with unreal downloads made by the same developers to enhance searching position.

Sergio de los Santos

Miguel Ángel García

Apps in Google Play that install an HTTP Server as a backdoor in your Android

Thursday, November 5, 2015

Trend Micro has discovered a very interesting problem with an SDK called Moplus that, literally, works as a backdoor for Android devices. The problems here are that this SDK belongs to Baidu (the Chinese biggest search engine); that is used not only by their apps but others; and that some of the apps are in Google Play right now, with millions of downloads. Finding vulnerable devices is just as easy as scanning a network and send some HTTP commands. Aside Trend Micro research, we have discovered some of these apps in Google Play and other curiosities.

This SDK is called Moplus. Aside its "official features" it sets up a local HTTP server (the well known nanoHttpd), that listens in different ports, depending on the app and SDK version (probably 6259 TCP port). If connected to that port, nothing is served (documentRoot is at data/data/apkName\files\local_http_server)… but it allows the attacker to send POST requests with commands.

Defining the port where the server will listen
And that is all. Any attacker may send commands to the port via HTTP POST requests with no strong authentication. One of the weakest version only needs the header "remote-addr" to be set to But some others need the referer header to match this.


If it works, it will execute the orders and return a JSON with the response (given the right permissions, which most of the spotted apps seem to have).

What commands does it support?

It is very clear with this piece of code:

Code with the accepted commands
It allows downloading files, and uploading anything. From retrieving the lists of apps to inserting new contacts. In rooted devices, any new apk could be installed silently.

Code to add contacts silently
Part of the code to upload files
Trend Micro contacted Baidu, that has created a new version that removes most of the malicious commands of the list. They are replacing most of the affected apps.
What did we found?

Trend Micro talks about thousands of apps affected. With Tacyt, we found the ones using the SDK and still available in Google Play. Some of them with up to 5 million downloads and not related to Baidu at all.

A variation of the code with the commands
These are some of the packageNames spotted in Google Play (although there will be more, for sure), different from the ones published by Trend Micro (so far):
  • com.ivodani.comicsisland.activity
  • com.pad.comicsisland.activity
  • com.cubic.choosecar

We could not confirm that the commands works the same in all of them. For sure, they contain the offensive code, but maybe with slightly different systems to be able to get in. They should be reversed individually to be sure how to make it work (or if they even work).

One of the easiest that we tested, was the very popular Baidu Maps. Not this one, but a previous version (8.7.0).

In the image, we use this Chrome plugin to inject POST commands. The result (inserting a contact remotelly) is shown. As you can see, Baidu Maps icon is on the top.

Adding contacts with a POST

It is worth mentioning that, many of the spotted apks, rely on two different classes.dex files. This means that, once executed, the app may load classes2.dex from its own "main" code, and usually this classes2.dex is the one with the offensive code.

An app containing a second "dex" file
This is not new. Many malware/adware in Google Play use this trick to try to fool detections. They may download the .dex file from elsewhere, or hold it inside. It is quite interesting finding that, some of the apps were using the "Moplus SDK capabilities" in this second dex file.

Aside, one of the most interesting point is that Mobo Launcher, related to the well known Mobogenie market, counts with this code backdoor as well, and it is very popular even outside China. It has been in Google Play since late 2014. In fact, is the oldest in Google Play with this version of the backdoor, as far as we know.

Some of the detected apps in Tacyt
Although we could not get to make it work and actually send a command (not sure why), the nanoHttp service was up, and code to receive commands is there... so there are strongs reasons not to trust this app, and reverse it even deeper to know exactly what is happening and how it works.

Of course, there are a lot of APKS outside Google Play (aptoide, mobogenie...) with this backdoor as well.

The good part is that most of these programs are already detected by several antiviruses, not all of them because of this, but detected, anyway.

Sergio de los Santos

Juan Manuel Tirado

Android malware not only posing as Word documents… but Excel as well

Saturday, October 31, 2015

China is a paradise for "SMS stealing malware" for Android. These programs steal your SMS inbox, notebook… The only "problem" for malware creators is to induce users to install the app. They usually use supposed pornographic content as a decoy. Zscaler just found some malware of this kind posing as a word document. We have updated their research with some new malware for android posing as Excel documents and some other interesting stuff.

Zscaler describes a more or less typical SMS infostealer Chinese malware. The improvement here is that they use a Word document icon for the Android malware. That would make the user believe that they are not installing anything, but trying to view a simple document. We searched and found some other malware (probably from the same attacker) posing as an Excel document, and got access to the email where the stolen info is sent to.

Some interesting stuff

The samples we have analyzed use an Excel icon. They are slightly different depending on the sample.

App that tries to look like an Excel document,
and another example of icon it may use
In this samples, the attacker uses an approach different from the one described by Zscaler that seems to be a little bit more advanced. Malware sends SMS history and contact list to the attackers' email, but in this case, the password for sending the email (and to check it, too) is not directly in the code, but in a configuration file.

Configuration file for the malware. Password and email included

We got to get into the mailbox of these mails and confirmed that, indeed, there were real SMS and contacts there. In an account, we found lots of supposed IMSI numbers and the whole SMS collection of the victim.

Stolen SMS from the victims

Zscaler found the "word document" malware was stealing the IMEI, while this one, as can be seen in the image, is identifying the victim by its supposed IMSI. In another account from other sample, we find the contacts list of the victim (name and number).

Some of the stolen contacts

The malware is able to "silent" the phone as well.

Setting the audio to silence

As usual, the attacker is a "regular" Google Play developer. He has been uploading apps to Google Play for months, and there are some of them online.

Some apps from the same developer

Thanks to Tacyt, we can get to know the developer, more than a single app. Most of the apps by this developer are removed, but they are not like this kind of malware described above. SMS stealers would not be able to bypass Google checks. Most of them are clickers, riskware in general or very aggressive adware. One of the few that are still alive is this:

One of the apps from the same developer still in Google Play.
It is not a SMS stealer, but aggresive adware.


We got to expand and improve the Zscaler research. Same old tricks as used in PC are more and more used in Android again and again, like this "icon decoy" system. It is importan to highlight that this malware has nothing to do with Microsoft, Office, Word or Excel in Android, they just use their icons as something attractive to confuse users.

Sergio de los Santos

Juan Manuel Tirado

New Financial Cyber Threats Report

Wednesday, October 21, 2015

New "Financial Cyber Threats (Q3 2015)" report
You can now download the full report about Financial Cyber Threats (Q3 2015) carried out by Kaspersky's Global Research & Analysis Team (GReAT) & ElevenPaths' Analyst Team. It`s available at ElevenPaths web.

This report analyzes the current trends related to financial phishing and banking malware, including attacks on mobile devices, POS (Point of Sales) systems and ATMs. It is mainly based on statistics and data from KSN (Kaspersky Security Network) although reliable information from other sources may also be referenced. The timeframe for this analysis contains data obtained during the period from July 1st, 2015 to October 1st, 2015.

A group of 14 countries are on the receiving end of the 90 % of all phishing attacks. The remaining 10 % is distributed among more than 170 different countries. Only the first three countries in this ranking account for half of the worldwide detected attacks.

The number of phishing attacks against Mexico is remarkable, taking over from United Kingdom the second position in the ranking of phishing attacks in comparison to the last period. New Zealand has been the country that suffered more phishing attacks per user over the course of Q3 2015.

During Q2 2015 United Arab Emirates was in the first place of countries with higher percentages of users attacked by phishing. This level has slowed down during this Q returning to its historical series. Phishing messages targeting the financial sector (banks, payment systems and online shops) accounted for more than 30% during this period, an increase of a 2.8 % compared with the data analyzed in Q2 2015. Banks are still the main targets within this sector as we observed during the last years.

Banking malware
For the first time since the start of the year the number of Dyre infections decresed (-2%) globally. The impact in UK and Spain of this malware has grown significally during this period, confirming the interest of the Dyre gang for both countries.

The number of infections of the Zeus Trojan and its variants keeps decreasing for the second period during this year.

When it comes to POS malware the number of infections for Cardthief, a 64 bits POS malware, shows an increase of activity during the end of Q3 2015.

Mobile malware
Once again Android is the most frequently targeted platform. 99.69% of the mobile malware detected target this operating system.

Russian Federation, Vietnam and Ukraine have almost the 90% of infections. Germany, Italy, France, Poland and Austria are the most infected European countries.

More info about our Security Trends Reports at
ElevenPaths' Analyst Team

About the relations between ngemobi/Xinynhe, Ghost Push, Kemoge and Odpa malicious Android adware

Tuesday, October 20, 2015

Over the last few weeks we have seen some blog entries about different new Android based mobile malicious adware families discovered or spotted by CM Security Research Lab, Checkpoint, FireEye and Trend Micro, that allows a complete takeover of an Android user’s device. These mobile malicious adware families have been named "NGE MOBI/Xinyinhe", "Brain Test", "Ghost Push" and "Kemoge", and are supposed to be developed by Chinese groups. We have tried to detect relationships between these different families. For example:
  • What’s going on with these "new" malicious adware families? How "new" are they?
  • Are these different malicious adware campaigns somehow connected?
  • Who has developed this adware campaigns?
In order to find the answer to these questions, the reported malicious adware families have been "squeezed" by Eleven Paths analyst researches using our in-house developed mobile cyber-intelligence Tacyt tool, to obtain more contextual information and the particular associated app "singularities" (technical or circumstantial app data that are "singular or unique" to a developer and/or application).

The above mentioned different adware campaigns have been analyzed and correlated on the basis of various application parameters, and the evidences obtained suggest us that:
  • The malicious adware family reported recently by FireEye (in September and October) seems to be related with the "Ghost Push" malware discovered by CM Security Research Lab and Trend Micro, as several clues regarding the links and associated certificate info included in the app point to the same developers, which in turn, seems to be related with the FireEye’s "Kemoge" called adware family as well.
  • The "Brain Test" malware app reported by CheckPoint contacted a server domain included also on the "Kemoge" adware family sample.
  • The aggressive adware discovered apps have had some versions in Google Play in early 2015, by a developer that produced aggressive adware as well.

Taking into account the several obtained "singularities" and hints, it seems that this adware or malware may all come from a single root, probably the known Odpa or Opda (it depends on the antivirus engine) creators (a known adware and infostealer) that may be the predecessor of these malicious adware families.

Brief research schema

Squeezing the Apps

Here we expose a few details of a much deeper analysis that you may find complete in a link below.

As shown in one of the FireEye reports the attackers have repackaged popular apps and inject ed malicious logic and ad components into the apps. The malicious adware iterates some domains and posts data once a connection is established. Searching with our Tacyt tool for the specific domains used by the malicious adware as indicated by the FireEye team, our analysts have found 12 different apps (some from the report itself, some from "Kemoge" samples). One of them, with "" package name, to be related to another (and supposed different) described mobile attack dubbed "MonkeyTest" by Cheetah Mobile on September 18th, 2015.

Searching for the app (from CM report), it reveals that this app uses a certificate singularity shared with one of the FireEye is reporting as downloaded by their samples. It shares the word "dashi" as well in the package name. There are even some specific strings in the code, which are shared between samples from all the reports.

It seems that some of the apps related with the developers were uploaded to Google Play back in late December or January. Searching with Tacyt for some specific binary files inside the apk, it brought us to some apps on Google Play which have been removed last January from the market.

Apps sharing very specific binary files

A curious thing is that most of them share this application permission, which is not very common (32 out of 4.5M apps): android.permission.ACCESS_MTK_MMHW.

Searching for certificates with those particular characteristics and for apps removed from Google Play the exact same day (which is supposed to be when Google discovered the fraud and cleaned the market), Tacyt obtained some evidence of related bands, like this particular UMENG ApiKey, as shown on the picture below:

Shared UMENG Api Key
This UMENG ApiKey has been shared with only a previous version of "Root Checker", removed from Google Play on 27th, December, 2014 and from "OPDA" developers that claim that their developer web is, which in turn, is related to a previous package name used in NGE (Xiny) attack. And there are even more connections between the word "Dashi" and OPDA developer. OPDA developers may be behind Odpa/Opda adware famlily, found in summer 2014.

On the other hand, CheckPoint reported that some of the domains found inside "Brain Test" malicious app seems to be present in "Kemoge" adware family as well:

Sharing specific domains


Tacyt’s powerful engine enables the analyst teams of the organizations to easily evaluate and correlate the application and its circumstances: when, who, what and where.

Using Tacyt our analyst team has been able to obtain further evidences that suggest a relationship between several reports, and confirm that some of aggressive apps discovered had a version in Google Play in early 2015. The evidences suggests that this supposed different families of malware, may be just the same Chinese band (because of the infrastructure, domains, topics, files, etc. they use) evolving the same idea about serving aggressive ads, rooting the devices, sending commands and installing new packages.

We assume this because of the several hints that join the families: domains, dates, permissions, names, certificates, resources, etc. They started their activities maybe in late 2014, using the OPDA "brand", trying to introduce malware in Google Play and legitimate apps as well. Later, they have evolved with new techniques, from "Xinyinhe adware", that seems to be just a variant of "Ghost Push" to "Brain Test" which seems some experiment before they got to "Kemoge". It seems that this Chinese gang is evolving techniques and creating more effective adware that are not able to spread via Google Play anymore, but third party stores. Anyhow, it seems that they use Google Play to serve "less aggressive" adware.


This whole report has been done without code analysis and with the minimum information provided by the blog post mentioned above. Taking into account more samples, relations between all the samples are even stronger. A further analysis of all the data collected (emails, links, strings, etc) from all the apks related, may guide us to a more accurate attribution.

Although hereby we briefly describe our research, the complete analysis process may be found here.