These are quick first looks and trend and threats

Written by the security and AV professionals from team K7, meant for the general audience
These are usually articles that go into internals of a virus or deal with security issues
Senior managers speak on areas of interest to them, inside and outside the industry

Archive for the ‘Security news’ Category

“I’m not a robot”, Google to reCAPTCHA the Flag

Friday, December 12th, 2014

Over the years, online users have had to identify obscure images, typically worn-out text from old newspapers or street addresses, and type the contents into a box to prove their humanness. CAPTCHA (an acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart”), as this process is called, helped prevent robots gain illegal access to websites, in order to propagate spam (unsolicited messages), for example.

However, these days advanced Artificial Intelligence technology with image recognition can solve CAPTCHA puzzles with astonishing accuracy, a whopping 99.8% according to Google. In an attempt to beat these more advanced bots, Google has recently launched a new API (Application Program Interface) called CAPTCHA reCAPTCHA.

With CAPTCHA reCAPTCHA , users are now directly asked to check a box as shown above. If this step is still insufficient to confirm the user’s humanness, a CAPTCHA is thrown. This CAPTCHA asks the users to match a given image with a set of images, usually animals or birds. Though this approach appears simple, Google claims that advanced risk analysis runs on the backend which monitors the user’s interaction with the CAPTCHA till the very end. This is a welcome change, especially for mobile users who face mild inconvenience in resolving the distorted images.

We hope CAPTCHA reCAPTCHA will be more effective in the fight against the bots created by cyber criminals.

Images courtesy of:

Archana, Content Writer

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

DEATHRING: The Android You Bought Can Spy on You!

Wednesday, December 10th, 2014

Recently, DeathRing, the latest pre-installed Android malware supposedly from China, was spotted in popular low-end smartphones sold in Asian and African countries including India, Vietnam, Indonesia, Nigeria, Taiwan and China.

This mobile Trojan disguises itself as a ringtone application and attempts to download other malware APKs, or target the user’s personal information and act as per the remote commands from a Command & Control server operated by cyber criminals. To avoid being uninstalled by the user, this malware is packed in the device as a system application.

One should now be paranoid about trusting a new smartphone. A precautionary action of scanning the new smartphone with a Mobile AV before use, or may be even before purchase, would stand as a temporary solution, but the Antivirus might not be able to remove the malware as it resides in the restricted-privilege system area.

Now, let us look briefly at what this malware does to achieve its malicious behavior. Even though this application is pre-loaded, supposing a user installs this application at will, the group permissions requested from the user during installation will be as shown in Figure 1 below.

Figure 1.Permissions requested from user during installation

Few of the important permissions to be granted by the user are shown in Figure 2 below. With these permissions, this Trojan app gains the ability to unmount and mount the phone’s file system with its desired privileges to install another malware APK in the system area, kill other running processes, interfere with a user’s outgoing calls and receive BOOT_COMPLETE information on device power-on.

Figure 2.Permissions list

Interestingly, this malware also requests permission to inject into user events (key, touch or trackball)  to deliver the event stream  to  the main activity of the Trojan.

Figure 3.Permission to inject into a user key event

Further analysis of this malware reveals that it also registers more than one callback and several services with the android system to start its malevolent behaviour with all possible intents that include ACTION_SHUTDOWN, NEW_OUTGOING_CALL etc., as shown in Figure 4.

Figure 4.Callbacks registered by the DeathRing malware

This malware carries the code to receive the key events in the main activity by declaring click listeners to trigger the corresponding relative activity.

Figure 5.Code to receive Click Listener

One of the relative activities listens for the key press events like onClick and onKeyDown from the SHUTDOWN key as a part of its malicious functionality as shown in Figure 6.

Figure 6.Code listening on shutdown button

This malware is also interested in the network state of the user’s device by first checking the user’s network type and subscriber ID, and then enabling the network connectivity based on the subscriber’s ID type.

Figure 7.Code identifying wi-fi connection

Figure 8.Code enabling network state

As proposed to Google in our last VB paper, an updated boot and broadcast framework that enabled the AV component to load earlier than any other application, even system applications, could help detecting and removing such malware.

Also, identifying and correcting the loophole through which the malware is loaded into the life-cycle of manufacturing and delivering the device at the earliest would help prevent pre-loaded malware, unless the presence of pre-loaded malware is not accidental.

K7 Mobile Security users are protected against this malware with the detection “Trojan (0001140e1)”.

Senior Threat Researcher, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

How Vulnerable is Android to Attack? (Part 2)

Monday, November 24th, 2014

Here is the second part of a two-part blog based on my paper for AVAR 2013.

Continuing from the first part of my paper…

Exploits for Android

This section would demonstrate few of the major security vulnerabilities in the Android OS.

Master Key Vulnerability:

This vulnerability has attracted a lot of interest from both security researchers and from the news media. This vulnerability resides in the cryptographic signature verification of Android Application Packages (APK). The problem here is that the files in the APK (Zip archive) are parsed (unzip of a file) and verified using Java ZipFile implementation from libcore, whereas the code that loads the data from the package is from a different C re-implementation2. The way in which these implementations handle multiple files with the same name differs, which results in verifying signature for one file with a name as per Java and installing the contents of a different file with the same name as per C.

In general, a zip format will not allow two or more files with the same name to be within an archive. But this can be circumvented with the help of some utilities available or a bit of tweaking. For example, the Android malware called Andr/MstrKey-A (Sophos) travels across with two copies of files named “AndroidManifest.xml” and “classes.dex”.

Figure 3: Malware APK with multiple files of same name

While the AndroidManifest.XML of size 2644 bytes and classes.dex of size 45228 bytes are the original files, the other two files were added by the malware author.

Manifest and Dex2Jar Vulnerability:

Android malware Backdoor.Android.Obad, called to be the most sophisticated, was found to exploit more than one vulnerability in the system to achieve the malevolent behaviour. The dexguarded Obad is seen to engage three of the vulnerabilities in the system to send out premium rate SMS without user’s knowledge.

Apparently, dexguard protection on this malware encrypts the strings and the class names involved, making static analysis challenging.

The figure below is a code snippet of Obad backdoor sample in Java format, highlighting some of the encrypted strings and class names.

Figure 4: Java code snippet of Backdoor Obad sample

The AndroidManifest.xml is a file which defines an application’s structure, permissions required and the launch parameters. This file plays a vital role during the installation process of the application. OBAD targets an error in the processing of AndroidManifest.XML file by modifying the XML file in such a way that it does not comply with Google standards but still gets executed properly and installs the application as usual, which stands as the first vulnerability availed.

Secondly, the Dex2Jar utility, that helps researchers to convert .dex to .jar files, has an error that it fails to convert the dex to jar properly, which takes the second place in the vulnerability order.

As third one, this malware registers as a device admin and utilises a vulnerability that it does not appear in the administrator list. By Android Framework, only user level applications (non-administrators) can be uninstalled by the user through uninstall option under settings whereas for the device administrators, uninstallation is possible only from the device administrator list. As this malware does not have any icon and runs in the background, absence of the application name in the administrator list makes it tough for an end user to identify the infection and delete the application.

It is also under discussion that because of the flaw in the XML encoding in dexguard 5.2.00 and the fact that the application is missing the associated label, which is required to display the application name in the Device administrators list, this malwares enjoying the administrator privileges without being listed under the administrators. Even though the malware does not aim at hiding itself or exploiting a vulnerability in the system, the vulnerabilities in the development environment and the supporting tools, may make it relatively tough to statically analyse a malware.

Privilege Escalation Vulnerability:

To procure the root access, there were malware instances that invoked other application in the victim’s device that require root access or driving the user to grant the root access to the application. As a step ahead, exploiting vulnerability in the Android OS to acquire administrative rights was also witnessed in case of Android TrojanSpy Droiddream that carries Exploid and RageAgainsttheCage.

The daemon process, Android Debug Bridge in Android, when started runs with the root permissions but later, the daemon drops its root permissions with the help of setuid() to run as a user process.The problem arises when there are maximum number of user processes are already running in the system.

Exactly the same happens in case of the malware Android Droiddream where RageAgainsttheCage confirms the max count of user processes (RLIMIT_NPROC) and forges the required number of processes to reach its limit. Now the exploit kills one of the processes and restarts the adb process. But as the target user’s process had already reached its maximum (RLIMIT_NPROC), setuid() fails. However, setuid() function’s return value is not verified and the adbd also fails to drop its privileges and continues to run as root.

Technical Analysis of Droiddream malware describes that RageAgainsttheCage is tried first and at the failure of which, is called Exploid, an udev exploit. This second exploit executes by using hotplug that is run by changing the state of the wi-fi adapter and resuming to its original state.  Successful execution of these exploits aids the malware with root access.

The above described vulnerabilities had a huge impact on the malware approach to silently have venomous actions in the compromised device.

Android OS Update

According to Google’s architecture for OS update, a user will receive updates from the respective device manufacturers/carriers. The reason behind is to aid the handset manufacturers/OEM versions to customize the updates for their device design. But many a time, the update process is slow that it resulted in a delay for a user to receive updates or at times the user could miss the update at all, that leaves them exposed to the dangerous vulnerabilities. Considering the data security of an Android user, Google should release increased and regular security updates without waiting for any upcoming GUI/OS update. Also it is debated many a times that updates should be directly available to the user instead of routing through the device company. User responsibility also has a share in this topic, to regularly check for updates and update the device, if any to avoid any uncool situations.

Risk Mitigation

Apparently, to mitigate the risk of vulnerability, there should be technology improvements in the Android OS that enhances the security context. The implementation of most awaited deployment SELinux3, Mandatory Access control (MAC) in Android OS could help solve the problem. With SELinux, MAC layer can control the user access to both their and the system data. Interestingly, with extra layer of security, it is possible to define system-wide policies, applicable for Super User (root) even.

It works by defining policies that describes the type of interactions a process is allowed to. For example, if a daemon process has a system-wide policy defined to access only a file with a specific label, then the process cannot access any other file. This acts as a solution to the privilege escalation vulnerability, but unfortunately SELinux is implemented only in the permissive mode. Removing the permissive mode and imposing the SELinux along with the regular OS/Security update with no delay could reduce the opportunities for exploits in the malware spread. Eventually, Google could come up with a vulnerability scanner for different versions of Android OS, which the users can make use of and proceed further to their carriers to patch the unpatched device.


Evidently, there is a rise in the smartphone usage around the world in both personal and business sectors. As quoted earlier, Google’s Android also contains vulnerabilities. It is a known fact that there are mobile malware in the rounds targeting the OS vulnerabilities to accomplish their noxious activities. These malware, even though, avail exploitation techniques to infect a device, their ultimate aim is at financial benefits by stealing user’s banking details, or stealing user data or personal information. Victimizing smartphones that are engaged in business communication can still intricate the situation. It is demonstrated already by Android malware to adapt to advanced evasion technique, which is expected to continue in the future as well. Hence, to overcome this scenario, regular security and/or OS updates should be made available to the user, to patch the disclosed vulnerability(s). With the enforcement of the SELinux technique in Android could considerably reduce the vulnerability risk in the system.


Images courtesy of:

Senior Threat Researcher, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

Invite Trouble!!

Friday, November 21st, 2014

Nowadays, major web players employ invite-only strategy, the hot trend to promote their new web services and apps. The invite-only buzz resonates exclusivity, thus making the forbidden more attractive to young users. Google Inbox, the new email app is currently channeling this fad, getting users excited about invites.

However, we observe some security concerns with this trend, as we notice suspicious campaigns doing the rounds. Few of the users, with or without invite shares, are seen to post hostile links that redirects to unsafe websites or demanding email id’s to distribute invites.

Here is an imaginary scenario that describes what could happen with an excited user who responds to an anonymous link that claims to send an invite. Consider, Sara wants an invite to the new email service “INBOX” and John tweets that he has “INBOX” invites to share as in the pictures below,

Now, Sara looks at the tweet, clicks on the link, shares her personal details with John as instructed. Possibility is that the link itself could be malicious.

Supposing the link is not malicious, it’s uncertain, if Sara would receive a link which redirects to a malicious link or would receive an invite mail from John after giving her personal information.

Wear your safety goggles; don’t share personal data on public platforms and be suspicious of links to invite-only emails and messages from unknown sources.

Priyal Viroja & Archana Sangili, K7 Team

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

How Vulnerable is Android to Attack? (Part 1)

Sunday, November 16th, 2014

Here is the first part of a two-part blog based on my paper submitted for AVAR 2013 that discusses the known vulnerabilities for Android OS with examples of Android malware exploiting them and few of the ways of mitigating the risk including the patch management.

Google’s Android, as any other mobile operating system, also contains a number of vulnerabilities. Android malware writers are now increasing the use of these exploits to evade detection. Early Android malware used simple ways to either spread or compromise the user’s device however with the increase in the Android malware count year-on-year and the advancement in detection techniques used by security software, malware writers have been forced to evolve new approaches to evade detection by mobile security products. A reminder of Darwin’s “Survival of the fittest”.

In the recent past, there have been a few Android malware instances that focus on exploiting vulnerabilities in the Android OS to attain root access or administrative privileges. For example, Android TrojanSpy Droiddream involved Exploid and RageAgainsttheCage exploits to obtain root access of the victim’s device.  To complicate the scenario further, the obfuscated Backdoor.AndroidOS.Obad utilises multiple system vulnerabilities in the Android OS to have its stealthy malicious behaviour. In addition there has been some publicity about the critical vulnerability in Android’s application signature check that could allow a hacker to inject malicious code into the legitimate application without even breaking the signature.

Known vulnerabilities in Android include those related to privilege escalation, common intent and so on. The exploitation of vulnerabilities provides a powerful mechanism for malware writers to compromise a system and deploy malicious code so it is imperative that we understand the scope of these attacks.

This paper provides an account of the known vulnerabilities used in the Android threat landscape with examples of Android malware exploiting them. The paper will also focus on the ways and means of mitigating the risk, including a discussion of patch management for Android.

Severity Evolution of Android Threat

Malware authors started investing time in identifying new ways to install their applications and to trick the user into installing their packages, with the focus on improving the propagation methods. Along with the early SMS Trojans, the severity of the Android threats notably increased with the emergence of other malware like fake applications, Zitmo/Spitmo, Image modifiers and so on, that really improved the complexity of the Android threats. In addition to these categories, targeted attacks, SMS worms were also predicted.

Unfortunately, in the past, there were few occurrences of malicious applications in the Android official market itself which had the outcome of Google’s Bouncer, a behavioural scanner. Even though malware writers can upload their malware package in the third party markets for Android, with the advancement in the security measures, such as Google’s Bouncer, the detection techniques involved by the mobile security products and last but not the least because of the smartphone user’s awareness on malware propagation methods, malware writers are forced to discover a new route that serves them to evade detection techniques and successfully execute their malicious code.

In the past, many Android malware required root access (administrative power) to execute the desired malefide functions on the victim’s device. For instance, Android.Droiddream involves the exploits Exploid or RageAgainsttheCage to exploit the vulnerability in the Android OS to attain root access. Notably, in the recent past, malware authors engage exploitation of the OS vulnerability increasingly to run their piece of malware and they are seen to target other functionalities in the OS apart from the root access.

Known Vulnerabilities

The saying that popularity brings in the danger of threats holds good for Google’s Android as well. Exploiting vulnerability in any OS stands as one of the best possible ways for malware authors to achieve privilege escalation or DoS.

Figure 1 below represents the count of major Android Vulnerability year on year since 20091.

Figure 1: Android Vulnerabilities by year till November 2013

The Vulnerabilities listed above were exploited to cause any adverse effects from remote code execution to denial of service attack.

Figure 2 shows the effects of exploitation of Android vulnerabilities

Figure 2: Exploitation Effects

Data from the above chart depicts that many of the exploitations are aimed at either remote code execution or performing denial of service. Malware authors may exploit one or a combination of these known vulnerabilities to reach their goal. The same example Android.Droiddream can be quoted here again for the exploitation of privilege escalation vulnerability.

The table below describes a few of the major security vulnerabilities and their security impact on the mobile device.

CVE-2013-4787 Code Execution Master Key Vulnerability – flaw in cryptographic check for application’s signatures
CVE-2012-6301 DoS Browser application in android 4.0.3 allows remote attackers to cause DoS (application crash)
CVE-2012-4222 DoS KGSL kernel mode driver for Android allows remote attacker to cause Denial Of Service through Null pointer dereference
CVE-2012-4221 DoS,

Code Execution

Integer overflow in DIAG kernel mode driver allows remote attacker to cause either DoS attack or remote code execution
CVE-2012-4220 DoS,

Code Execution

DIAG kernel mode driver allows remote attacker to cause DoS/remote code execution by incorrect pointer dereference
CVE-2012-3979 Code execution Flaw in Mozilla before 15.0 allows remote attacker to execute arbitrary code via crafted webpage that loads a javascript dump function
CVE-2011-3918 Dos Zygote process in android accepts fork requests from arbitrary UID, that causes remote attackers to cause DoS by reboot loop
CVE-2011-3874 Code Execution Stack-based buffer overflow allows user-assisted remote attacker to execute arbitrary code.
CVE-2011-2357 Bypass Cross application script vulnerability in the  browser URL loading functionality allows local applications to bypass sandbox and execute  javascript
CVE-2011-1823 Code Execution

Memory Corruption


The vold volume manager daemon on Android 3.0 and 2.x before 2.3.4 trusts messages that are received from a PF_NETLINK socket, which allows local users to execute arbitrary code and gain root privileges
CVE-2011-0680 Flaw in draft cache management by data/ in the Mms application in Android before 2.2.2 and 2.3.x before 2.3.2 allows remote attackers to read SMS messages intended for other recipients in opportunistic circumstances via a standard text messaging service.
CVE-2011-0419 DoS Stack consumption vulnerability
CVE-2010-1807 DoS

Code Execution

Flaw with floating point data validation allows remote attacker to cause DoS attack or remote code execution
CVE-2010-2656 DoS Unspecified issue in the process allows remote attacker to cause Dos via crafted SMS message, which is possibly related to CVE-2010-3698 and CVE-2010-2999
CVE-2009-2348 Bypass Android 1,5 CRBxx allows local users to bypass the android.permission.CAMERA and android.permission.RECORD_AUDIO configuration settings by executing an application

that does not request permission before using camera or microphone

Table 1: Android Security Vulnerabilities list till November 2013

Given below is a list of the vulnerabilities and the handset/installed app that they target:

CVE-2013-4777 Privilege Escalation A certain configuration of Android 2.3.7 on the Motorola Defy XT phone for Republic Wireless uses init to create a /dev/socket/init_runit socket that listens for shell commands, which allows local users to gain privileges by interacting with a LocalSocket object.
CVE-2011-2344 Privilege Escalation Android Picasa in Android 3.0 and 2.x through 2.3.4 uses a cleartext HTTP session when transmitting the authToken obtained from ClientLogin, which allows remote attackers to gain privileges and access private pictures and web albums by sniffing the token from connections with
CVE-2011-1352 Privilege Escalation Memory Corruption The PowerVR SGX driver in Android before 2.3.6 allows attackers to gain root privileges via an application that triggers kernel memory corruption using crafted user data to the pvrsrvkm device.

Table 2: Specific Android Security Vulnerabilities list till November 2013

The list in Table 1 and  Table 2 above are extensive and does not include the vulnerabilities seen after the mentioned time period. Exploiting one of these vulnerabilities may help the attacker in planting the malicious application on the user’s device. Once on the device, they can behave in the way that any malicious app would,  like sending SMS messages without user’s knowledge, stealing personal/user information, Zitmo/Spitmo, etc.,

to second part


Images courtesy of:

Senior Threat Researcher, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

Watch Out for K7 Speakers at AVAR 2014!!

Monday, November 10th, 2014

The 17th AVAR conference is scheduled for the coming week (12th to 14th November 2014) to be held in Sydney, Australia. Topics discussed includes mobile malware, Advanced Persistent Threats (APT), targeted attacks and other security related topics under the theme “Security Down Under”.

K7 representatives, Lokesh Kumar, Systems Manager, K7TCL and Gregory Panakkal, Senior Software Architect will be presenting a paper titled “Shell Team Six: Zero Day After-Party “ on the 13th of November at 14:55, along with other security experts from the Asia-Pacific Region.

We hope to see you all there.

Archana Sangili
Content Writer

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

Editor of World-Renowned Security Magazine Appreciates K7 Speakers!!

Friday, November 7th, 2014

In a nice gesture, the editor of the acclaimed Virus Bulletin magazine has blogged about the presentation of our reserve speaker duo who were meant to present a paper and a short demo, in the event of an absent speaker at the 2014 Virus Bulletin International Conference held recently in Seattle, USA. VB2014 has already been discussed, highlighting the presentation by K7’s Gregory Panakkal. Nevertheless, this post is dedicated to the reserve speakers from K7 Threat Control Lab, Samir Mody, Senior Manager and V.Dhanalakshmi, Senior Threat Researcher.

Their paper, “Early launch Android malware: your phone is 0wned”, demonstrates the difficulties in
removing an active Android ransomware, “’Koler/Simple Locker”, infection that prevents a user from
uninstalling it. It also proposes a new framework which Google could induct to help mobile security vendors defeat Android malware strategies.

View the full presentation and demo at our official YouTube channel.

Archana Sangili
Content Writer

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

Android to Cross Lollies with Malware Authors this Diwali!

Tuesday, October 21st, 2014

The next sweet to taste after Kitkat, “Lollipop” (Android 5.0), loaded on Nexus devices, is expected to hit the market next month, as announced by Google on October 15, 2014.

The much awaited Lollipop carries many improved and new ingredients, but we’ll concentrate on the security implications of the new OS:

  • The “Factory Reset Protection” (opt-in Kill Switch) requires the user to enable and enter the Google login and a pass code to factory reset his/her device.
  • “Automatic Data Encryption” shields the user data when the device is lost or stolen.
  • Enforced SELinux” for all applications to defend against exploits and malware.
  • “Smart Lock Feature” allows only trusted devices for device pairing (user’s phone can be unlocked through the paired bluetooth device).

In addition to these “features”, we are eager to know if the experimental DM-Verity introduced in Kitkat (4.4) to protect the integrity of the device’s boot process is still imposed by default in Lollipop.

Another new feature, “Device sharing”, allows users to share the device among family members or friends under “Guest user” accounts. “Screen Pinning” restricts the guest to view only the pinned screens of the user. However, going further, Lollipop permits the user to login to another Android device remotely to access synced data contents. As one would know, Android malware utilizes every possible way to infiltrate the user’s device, and therefore the above said remote login raises eyebrows about the security implications in authenticating and controlling remote sessions.

The notable news for the corporate IT admins is that, with Lollipop, users can partition work and personal spaces within the device. However, the implications as far as the BYOD concept is concerned have yet to be spelled out.

Android Lollipop’s new security enhancements and features have raised a few questions. We are anticipating the answers!

Happy Diwali!!!

Images courtesy of:

Senior Threat Researcher, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

K7 Security Expert Presents at VB2014

Friday, October 17th, 2014

The annual Virus Bulletin International Conference was held this year on 24-26 September, in Seattle, USA. As usual, VB2014 featured presentations from several notable vendors in the anti-threat sphere, describing their recent research and development in the field of IT security. Anti-Malware tools and techniques, botnets, mobile security, network security, spam and hacking were some of the highlighted topics that were contemplated upon.

Every year, K7 Computing shares the knowledge and technical advances made by our R&D teams. This year, Gregory Panakkal, a Senior Software Architect at K7 Computing, who extensively develops the handling  of anti-malware components in the K7 security suite, presented on the topic, Leaving our ZIP undone: how to abuse ZIP to deliver malware apps. His paper deals with the ZIP format which is employed in Android applications and the possible crafted malformations of the ZIP format that can be used to bypass AV detection, without breaking trust for the Android OS. It discusses the challenges for AV components in handling such scenarios, as well as introducing the concept of the “Chameleon ZIP” which complicates the contextual handling of a crafted amalgamated ZIP package which can be interpreted differently based on the application which opens it.

Gregory’s presentation can be found on the VB website.

Archana Sangili, Content Writer

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

Gmail Passwords Leaked

Friday, September 12th, 2014

A list of millions of Gmail user names and passwords were recently posted in a Russian bit-coin site. While details on how exactly the passwords got leaked remain murky, the popular email service provider has confirmed that none of their servers were breached to ex-filtrate the data. Users of these compromised accounts are now being re-directed to Google’s password reset page to regain access.

To be on the safe side, users should consider implementing two factor authentication for Gmail accounts.

If history has taught us anything, sensational news like this is likely candidate for social engineering based abuse. Web sites purporting to allow people to check if their Google accounts have been compromised are already cropping up and it could be only a matter of time before we start seeing phishing campaigns on this subject. Users are advised to be vigilant and avoid such emails at all costs.

Lokesh Kumar
K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: