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’ Category

Exorcising CTB Locker from your Computer: What you Need to Know

Friday, January 30th, 2015

Ransomware, a type of malware which holds your files to ransom by encrypting them and then demanding a ransom for their “release”, i.e. by decryption, is nothing new. Cyber criminals make a lot of money by extorting funds from victims all over the world.

The latest family of widely distributed ransomware is called CTB Locker. In this blog we have decided to provide information about CTB Locker in the form of an FAQ so that our customers and the general public globally may be well-informed about the dangers of this malware family, learn how to avoid it, and be reassured about our robust response to it.


  • How do you prevent your computer from becoming infected by CTB Locker?

Let’s begin with this question as it is the most important one to keep your computer safe. Prevention is always better than cure.

The initial spreading vector for CTB Locker is a spam email with enticing content which uses social engineering techniques to convince the potential victim to unzip a ZIP archive attachment (extension ‘.zip’) and execute its embedded file.

This embedded file, which is currently around 40KB in size, may have misleading extensions such as ‘.scr’ in order to masquerade as a screensaver application. This file is the downloader component for CTB Locker’s main payload, which then does the actual file encryption and makes ransom demands. We urge you to be vigilant against such spam emails as it is very first line of defence against CTB Locker as well as a host of other malware families which also use the same old time-tested technique to spread.

If an email comes from an unknown or unexpected source containing an attachment or a website link requesting you to open the attachment or click on the link, please exercise extreme caution. We would suggest simply deleting such emails if they are not already quarantined by your spam filter.

The spam emails tend to be targeted at English-speaking countries and at least 3 European countries given that the malware payload provides its ransom messages in German, Dutch and Italian.

This ransomware is not targeted at Indian users per se but given the ubiquitous nature of spam there will be “collateral damage” resulting in not just Indian victims but also many other hapless victims in other non-target countries.

  • What should you do when you discover your computer is infected with CTB Locker?

If you have seen messages demanding a ransom as shown above, it is likely that many, if not all, of your personal files such as Microsoft Office documents, PDF, TXT, ZIP and even ‘C’ source code files will be in an encrypted state, i.e. appear to contain random binary junk. Files encrypted by CTB Locker will have filenames such as yourfile.ext.<7 random lowercase letters>, e.g. 253667.PDF.iryrzpi

Executable files, e.g. EXE, DLL, OCX, etc, and files with extensions unknown to the malware will not be touched.

First and foremost, we would request that you do not attempt to pay the ransom to get your files back. Even if the cyber criminals do actually decrypt your files, the money they get from you will only serve to encourage them to continue their nefarious practices, investing R&D in enhancing their capabilities and global reach. Cyber criminals must be stripped of their Return on Investment incentive to create malware.

Once you have decided not to pay the ransom we would recommend removing the malware immediately. This can be done most easily by:

  1. updating your product
  2. rebooting into Safemode
  3. performing an on-demand scan on your computer
  4. removing the detected components. Note, the main CTB Locker payload is detected as ‘Trojan ( 0049d83b1 )’ and its downloader component is detected as ‘Trojan-Downloader ( 00499db21 )’

  • Is it possible to decrypt files encrypted by CTB Locker?

The malware itself demonstrates that files can be decrypted by randomly choosing 5 samples to decrypt.

However, the malware uses a high-grade encryption algorithm with a key which is unique to your computer, rendering it effectively impossible to force a decryption en masse.

  • How to restore files encrypted by CTB Locker?

It may not be possible to restore all files encrypted by CTB Locker. However, if your Windows operating system supports System Restore it is possible to recover the contents of many of your folders to a recent restore point before the infection took place.

The most reliable solution, though, is to restore your critical files from regular backups. If you don’t backup your important files regularly then we urge you to start doing so ASAP. Apart from a CTB Locker infection, there are numerous other factors which could render your files irrecoverable in the future, including a hard disk failure. Note, it may also be possible to use deep forensics tools to recover some critical files if they still exist on sectors on the hard disk, but this is not an alternative to regular backups.

  • Will paying the ransom actually decrypt your files?

We refuse to pay any ransom so we are unable to confirm whether payment will actually result in your files being released. Once again, we would request you to not attempt to pay the ransom for the reasons mentioned earlier.

  • Why did K7 not detect and remove CTB Locker?

At K7 Threat Control Lab we are constantly monitoring and acting against CTB Locker infections, including coding robust generic detection for all components of CTB Locker. However, the cyber criminals behind the CTB Locker family have been investing considerable resources in morphing, i.e. changing the appearance of, all their components and spam emails such that they may sometimes be able to get past security scanners, not just K7’s, albeit for a very short period of time. We at K7, and our colleagues at other security companies, are working hard to stay ahead of CTB Locker in order to protect all our customers across the planet.

Samir Mody
Senior Manager, K7TCL

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

Hacked Websites: Consequences and Mitigation

Wednesday, January 28th, 2015

This is the final chapter of my blog series on “Hacked Websites” describing the consequences faced by users of visiting a hacked website, along with a few mitigation guidelines for the developers and webmasters, following on from the previous chapter covering the vulnerabilities and exploits involved in a website compromise.

Back in the old days, hackers used to hack to try to solve problems, to improve internet security and experience, and to boost their own self-esteem. Over time, hackers’ intentions changed and they began to hack for many more troublesome reasons such as to deface a website and convey a specific message, to steal confidential data or services, to host illicit material, for malicious redirects, to utilize a server’s resources for malicious intent, DDos, etc; by and large for money, theft of intellectual property, curiosity, prestige and as a publicity stunt.

Consequences for a user in visiting such a compromised website are that a user may

  • become a victim of a socially engineered phishing attack and give away his/her banking credentials, personal information and credit/debit card data on fraudulent sites.
  • become a victim of unintentional malicious downloads and installs (aka ‘drive-by download’), including becoming part of zombie botnet armies.
  • To ensure a safe and secure visit for a user to their website, webmasters must periodically verify their websites’ integrity. Below are a few of the mitigation guidelines for both developers and webmasters.

    For developers :

    ●     Implementation of effective input/output validation and sanitization approach.
    ●     Implementation of effective account management, authentication and authorization practices.
    ●     Encrypting users’ secret session values and sensitive data.
    ●     Securely handling exceptions, errors and logs.
    ●     Following the standards described in OWASP, CERT guidelines.

    For webmasters :

    ● Do not entertain cloaking, link farming, content autogeneration and other SEO tactics that may welcome SEO Poisoning attacks.
    ● Carefully deliver content from open, restricted and forbidden areas.
    ● Serve sensitive content over secure pipelines such as HTTPS.
    ● Encrypt data (using industry grade encryption algorithms) before storing into database.
    ● Update and patch servers within regular scheduled time intervals.
    ● Perform web application security audits and penetration testing on a regular basis.

    As one would expect, in the event of any compromise of their website, webmasters should carry out the process of clean up and recovery of the hacked website at the earliest with a custom recovery process or by following the guidelines available online.

    I hope this blog series helps people, both laymen as well as webmasters and web developers, in understanding what a hacked website is, the vulnerabilities and exploits involved, and the consequences to a user of visiting a hacked website, and finally the mitigation guidelines for developers and webmasters to reduce the risk of their websites getting hacked.

    Image courtesy of:

    Priyal Viroja, Vulnerability Researcher, K7TCL

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

    Shell Team Six:Zero Day After-Party (Part I)

    Wednesday, January 21st, 2015

    This is the first part of a six-part blog based on the paper submitted by my colleague Gregory and myself on Advanced Persistent Threats (APT), for AVAR 2014. This first part introduces the reader to the different phases of an APT and discusses the methodology, prevention and detection techniques of the initial phase of an attack in detail.

    The IT security industry is faced with the challenge of dealing with old invasion tactics that have been reborn in new avatars as Advanced Persistent Threats (APTs). APT attacks are tenacious at pursuing their targets and are played out in stages, possibly over a long period of time. With financial backing from state actors and criminal rings, APTs tend to be compound, sophisticated and difficult to detect. Each facet of the intrusion, in an idealist scenario, may be refined to such an extent that the end goal is achieved without a trace before, during or after the event.

    Despite the complexity of these types of attacks, certain parameters always need to be satisfied to deliver the payload and retrieve the expected results, leading to the emergence of an attack pattern which may be placed under the microscope and flagged. These parameters include executing arbitrary code by invoking zero-day exploits for popular software, defeating security measures such as DEP & ASLR, e.g. via heap spray and ROP/JOP chains, exploiting EoP vulnerabilities, establishing remote C&C communication channels to issue commands or to exfiltrate stolen data in encrypted form, etc.

    Drawing on evidence from documented real-world case studies, this paper details techniques that assist an assailant during the different phases of an APT, bypassing protection mechanisms like application-sandboxing, EMET, IDS, etc. thus attempting to fly under the defense radar at all times. Equipped with this information, we hope to explore methods of discovering each part of the life-cycle of a targeted attack as it is in progress or in the post mortem, thus reducing their efficacy and impact.


    “If you know your enemies and know yourself, you will not be imperiled in a hundred battles… if you do not know your enemies nor yourself, you will be imperiled in every single battle.” Sun Tzu

    As technologies implemented in organizations are becoming advanced, the threats are rapidly evolving too. Through tenacious and coordinated attacks on one’s infrastructure, APTs are able to infiltrate and overwhelm the organization.

    The threat landscape has changed. But the general principles of war remain the same.  Knowing the modus-operandi of your faceless attackers helps one evaluate, and harden one’s security measures, and gear up towards facing the attackers head on.  This paper aims to help you do just that.

    APT Life-Cycle

    The stages of an APT can broadly be classified as follows:

    •   Target reconnaissance
    •   Initial compromise
    •   Expanding access and strengthening foothold
    •   Data exfiltration and cleanup


     Target Reconnaissance

    The reconnaissance phase of a targeted attack sets the stage for the rest of the threat campaign and therefore involves a high degree of planning. The perpetrators spend significant amounts of time learning about their target, collecting as much information as possible about the human, physical and virtual resources of the organization. The intelligence garnered during this stage not only helps the assailants determine key points of entry into the target network but also empowers them to navigate the victim’s network once inside more effectively & efficiently.

    Reconnaissance Methodology

    The target’s virtual network is plotted using publicly available resources. These resources include:

    •   DNS records
    •   WHOIS information
    •   Email messages
    •   Inadequately protected network logs
    •   Misconfigured servers, etc.

    The organizational structure is also studied to determine employees and their organizational access levels, using social media, search engines and the target’s own website. Profile intelligence gathered could include potential passwords, personal and official email addresses, whether the user is a regular employee, a SOHO user, or a contractor.

    Based on this harvested intelligence the infrastructure needed for the attack will be acquired, the course of action to successfully execute the campaign will be determined & evasion techniques that could be followed during the attack will be planned. New domains may be registered, command and control servers set up, exploits crafted, vulnerable employees identified, custom social engineering schemes plotted for these target employees, malicious files created, etc.
    Recently, US airport workers from over 75 airports were targeted via malicious emails based on information such as their names, titles, and email addresses that were harvested via publicly-available documents [1].

    Fig.1 shows how a simple search engine query can divulge information like emails exchanged between personnel in public forums which may seem innocuous, but can be used to launch a spear phishing attack. Popular mailing lists mask this sensitive information to avoid it from being scraped and abused by bots. Valid users on the other hand are allowed access after solving a simple CAPTCHA.

    Fig.1: Search result revealing email addresses and other information about employees of an organization.


    Most of the intelligence collected by the assailants during this stage is publicly available and in general doesn’t involve the attackers touching any of the internal systems. Information that was gathered from previous APT campaigns but applicable to the current one could also be reused. This makes detecting an APT during these early stages of the attack challenging.

    Usual best security practices such as conducting periodic penetration tests, hardening the applications & the operating systems, etc. are still relevant, but these measures by themselves don’t stand a chance against this adversary.

    Organizations should take care to both restrict the amount of information that is flowing outside and be aware of publicly available sensitive information which could potentially be used against them.

    Profile Scraper

    Automated bots can be used to collect publicly available information on the company, the employees, etc. from popular social networking sites and search engines, etc. The data collected can automatically be analyzed for potential sensitive leaks.

    Honey Profiles

    Fake profiles at different organizational levels meant to be trip wires can be set up on popular social networking sites and connection attempts and profile hits can be analyzed. This could allow organizations to both recognize if they are being targeted and predict which individual or group of individuals are being targeted.


    Images courtesy of

    Lokesh Kumar
    Manager, K7 Threat Control Lab

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

    Hacked Websites: Vulnerabilities and Exploits

    Monday, January 12th, 2015

    This is the second chapter of my blog series focusing on the vulnerabilities and exploits involved in a website compromise following on from the previous chapter covering the reasons for which website access can be blocked.

    New age Internet, a web of images, videos and user-friendly interactive content, is delivered by tools like image/video gallery, sliders, gadgets, CMS, etc., for quick design and implementation.

    Because of the complexity of these evolving web technologies, there is a high possibility that security vulnerabilities in web applications might be overlooked by both the developers and the quality assurance process. Such vulnerable web applications are susceptible to hackers and bots to break into a victim’s computer and to infect websites to spread malicious files or send spam messages.

    The most common web application vulnerabilities are described below.

    Code Injection

    A huge number of data breaches happen via code injection attacks, i.e. the injection of malicious code specific to a vulnerable application either on the victim’s computer or on the website host server into a web application in order to carry out silent execution of the injected malicious code. This kind of attack includes Cross-Site Scripting (XSS), SQL Injection, XML injection, RCI, Header Injection, Log Injection and Full Path Disclosure. To have a clearer picture of code injection, let us look at the XML injection example shown below.

    Let us consider the following form and actual inputs:

    Name: test
    Password: test123

    Data is sent to the web host as follows:

    Expected XML result at the server side is:



    A valid user id 101 is created for the user “test”.

    Now, let us suppose a hacker submits an XML code as input in one of the aforesaid form fields to control a user account.

    Name: test
    Password: test123</password><id>0</id><!–
    Mail: –><mail>

    Now, the data sent would be in the format,</password><id>0</id><!–&mail=–></mail>

    Modified XML result is:



    In the above example, as the hacker has entered the XML code “</password><id>0</id><!–” along with the password “test123” in the password field and “–><mail>” along with the mail “”, the website server generated id “101” is commented out and a possibly pre-existing id “0” is assigned to the user “test” via password and mail parameters provided by the attacker. Now the hacker can avail the privileges or the functionality associated with the id “0”, thus severely violating the security objective of access control.

    Broken Authentication and Session Management

    Many developers prefer relying on their own, custom authentication and session management schemes than using the standard authentication and session management methods. As seen in cases earlier, custom schemes regularly fail in functionalities such as password management, sign in, logout, timeouts, secret question, account update, etc.

    Some common flaws attributed to the failure cases are listed below:

    ●     Storing credentials in plain text, i.e. without hashing or encrypting them.

    ●     Weak account management modules (e.g. account creation, account deletion, change/update password, recover password, etc)

    ●     Session IDs

    1. exposed in a URL
    2. that do not properly timeout or are not validated during logout
    3. that are not updated after a specific time period once logged in.

    ●     Confidential data transfer over unencrypted connections.

    In the example below, a movie-booking application exposes the session ID in the final URL as shown below,,6,9 &sessionid=2QZABDJ3NDXYXK5CJ8N290

    Now, if an authenticated user shares the above link with others, the allotted sessionid will also be visible to the receiver. When the receiver accesses the shared link, he/she will have the privileges associate with that session ID and can therefore hijack the session. These scenarios can cause adverse effects in case of gift vouchers, saved credit card details, etc associated with the authenticated user.

    Security Misconfiguration

    Secure configuration of an application stack including operating system platform, web server, application server, database, framework and code is one of the primary goals for  developers and system administrators. Security misconfiguration can occur at any level of an application stack. Exploiting such misconfigurations, ranging from failure to apply appropriate patches, use of default accounts, failure to set useful security headers on a web server, use of unnecessary services and disabling platform functionality could grant unauthorised access to an attacker.

    For example, consider the scenario where the server XYZ has a few java class files (compiled Java source code files) hosted, but unfortunately has directory listing is enabled, unknown to the administrator. If an attacker manages to discover that the server XYZ’s directory listing is enabled, the attacker would be able to collect the compiled code and reverse engineer it to get source code.

    Format String

    Exploitation of Format String occurs when the submitted input string is misinterpreted as a command by which the attacker can trick the concerned application to read values off the stack, induce a segmentation fault, or execute a user supplied string as a code, to cause an unexpected behavior that could compromise the stability and security of an application, thus potentially allowing execution of malicious code by a remote attacker.

    Intelligent fuzzers are used to automate fuzzy input supply to the application, with the intention of crashing the application and generating errors that can disclose sensitive information. The most common C runtime functions printf(), fprintf(), sprintf(), snprintf(), scanf(), etc., process data based on a format string and %x, %s, %n, %%, %p, %d, %c, %u  are some of the most common parameters used in this attack.

    For example,

    Let us discuss the following C code,

    int main(int argc, char** argv)
    char buffer[100];
    strncpy(buffer, argv[1], 100);

    return 0;

    In the above C code, the printf() function takes one argument “buffer” instead of the usual two arguments, format specifier and the associated variables. An attacker can trick the printf() function in the above code by passing an input string “%p %p %p %p %p”  to the buffer where %p is the format specifier of a pointer. During execution, printf() will look at the argument as  “%p %p %p %p %p”, consider that it has 5 arguments and will print the next 5 addresses on the stack (for 32-bit architecture) from the current position. Possible output could be:

    => ./output.out “%p %p %p %p %p”
    0xffffdddd 0xf7ec 0×1279 0xffffdbdf 0xffffdbde

    Thus, a format string vulnerability gives the attacker the ability to read an arbitrary value from an arbitrary address and potentially perform malicious activity.

    Apart from exploiting web application vulnerabilities, hackers may also avail of weak password policies, insecure FTP/HTTP connections, outdated third party add-ons and server vulnerabilities to compromise access to a website host. To accomplish an attack successfully, attackers may combine two or more vulnerabilities together on the target webserver.

    In the next chapter of my blog series, I will describe the consequences faced by users  visiting a hacked website, along with a few mitigation guidelines for the webmaster.

    Images Courtesy:

    Priyal Viroja, Vulnerability Researcher, K7TCL

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

    Hacked Websites: When Access is Denied

    Tuesday, December 23rd, 2014

    Are you excited about the new social networking platforms, games, mobile apps and the Internet of Things? Yes? Great, but BEWARE, hackers too are excited! With the K7 product installed, while visiting a website have you ever hit upon the message, “Access denied! The access to this page has been denied by K7Total Security Safe Search”? If you have, good, you’re safe.

    We at K7TCL process a huge number of suspicious website URLs everyday and identify many  malicious ones, some of which are hosted at compromised or hacked websites (websites which are owned by legitimate entities but have been forcibly taken over by hackers without the owners’ knowledge). To provide better protection to the user, URLs identified as malicious, including phishing, fraudulent and malware-payload links are blacklisted and the product denies access to them. We have stringent quality assurance processes to ensure that we don’t block access to clean websites.

    As we blogged earlier, we occasionally receive URL false positive reports from our clients for the websites that are indeed compromised. So we thought it would be a good idea to educate the public with a blog series covering:

    1. How a website is typically hacked
    2. Factors to identify a hacked website
    3. Role of software vulnerabilities (defects in software that can be exploited by hackers) involved
    4. Consequences to the user in visiting a hacked website, along with a few mitigation guidelines for the webmaster

    This is the first chapter of my blog series that briefly describes hacked websites and the reasons for a website to be blacklisted.

    Usually hackers and their automated bots, which are malware designed to infect a user’s computer and connect back to a central command and control (C&C) server, break into targeted website hosting by exploiting a web application vulnerability on the target. Targeting a massive user base, hackers often prefer to hack renowned legitimate sites that own heavy network traffic to propagate the hosted malware and infect a large number of users, or fraudulently suck information from them, even before it is identified that the website is hacked, as in the case of the recent Ebay hack. Compromised websites are either injected with a malicious script that downloads another malware on to a user’s computer or ends up redirecting to another malicious site. Such a hacked website remains infected until the webmaster identifies, assesses, and remediates threats to his/her systems.

    In response to the aforesaid incidents, we duly inform the concerned authority, i.e. the webmasters, of such infected websites about the scenario and the recommended course of action. Therefore we recommend that webmasters provide accurate, up-to-date contact details on their domain registrations and DNS records so that we know whom to contact when the need arises.

    To an end user visiting a compromised website with a vulnerable browser or browser plug-in may leave the user’s computer infected with a malware without his/her knowledge. So, it is advisable that users regularly apply update patches for their operating system and the other software they use.

    A blacklisted website/URL satisfies one or more of the following criteria:

    1) It redirects to a malicious link or points to a malicious payload
    2) It is used in spam or phishing campaigns
    3) It is hosted on a compromised web server
    4) It contains malicious JavaScript code

    Alexa, a well-known provider of web traffic information, ranks 1 million domains and sub-domains on a daily basis according to their popularity. To get an idea of the number of compromised and popular websites used in malicious attacks, we looked at how many malicious URLs are hosted on websites listed on Alexa’s top 1 million. From our latest lab data and instrumentation, we observe that currently approximately 7500 popular domains are compromised and 10791 exploit-related URLs are blocked by our product’s site blocker. Furthermore, out of these,16 sub-domains and 16 blocked URLs have domains ranked within Alexa’s top 100.

    In the next chapter of my blog series, I will describe how websites get hacked in the first place, focussing on the vulnerabilities and exploits involved.

    Priyal Viroja, Vulnerability Researcher, K7TCL

    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:

    SOCK! BASH!! SLAP!! PINCH! Battling Vulnerability Fatigue!

    Wednesday, October 15th, 2014

    Whilst the ghost of Shellshock still haunts everybody two diametrically opposite vulnerabilities have made the headlines over the past 24 hours or thereabouts:

    1. CVE-2014-4114, a remote code execution vulnerability in the Microsoft OS’s rendering of certain OLE objects, actively exploited in the wild, allegedly by Russian threat actors
    2. CVE-2014-3566, effectively a data leak vulnerability in SSL 3.0 for which a PoC attack to steal secure session cookies has been described by the discoverers of the vulnerability at Google

    Let’s discuss CVE-2014-4114 first since its impact is more severe given the remote code execution aspect and the evidence of malicious exploitation in the wild. The good news is that Microsoft has issued the patch for this vulnerability as of yesterday. As members of the Microsoft Active Protections Program (MAPP), we at K7 have also received more information about how the vulnerability can be exploited. We have already secured protection against known bad exploit files, and a heuristic fix is ready, but as an additional paranoid step, if you have the K7 product with firewall installed, it should be possible to add a carefully-configured firewall rule for Microsoft Office OLE rendering applications, e.g. POWERPNT.EXE, EXCEL.EXE and WINWORD.EXE, to prevent them from accessing remote network locations, thus mitigating against the silent download and rendering of malicious files.

    Now then, CVE-2014-3566; the Google PoC describes a Man-in-the-Middle attack which can be used to steal a supposedly secure session cookie (but this can be any encrypted data) IF the encryption channel is SSL 3.0 based. Serious as this sounds, CVE-2014-3566 is not as potent as the bash vulnerability suite, and not as valuable as Heartbleed in the grand scheme of things. The reasons for this is that there are several mitigating factors:

    1. The communication has to be via SSL 3.0 which is an antiquated, discredited protocol long since replaced by the more secure TLS. Of course client-side browsers may be duped into believing that the server supports only SSL 3.0, and therefore switch to this protocol
    2. The attacker has to insert himself/herself between the client and the server in order to control the format of the traffic and derive the tasty data byte-by-byte
    3. The encrypted traffic itself, separated into blocks, needs to lend itself to the attack in the sense that certain content deemed interesting to the attacker must be at deterministic locations in the encrypted blocks, with a rinse and repeat function as part of the modus operandi.

    At the recently-concluded Virus Bulletin 2014 conference, at which we were Shellshocked for the first time, the managing of vulnerability disclosures was extensively discussed. The above couple of vulnerability disclosures have been suitably managed, minimising the impact on the general public.

    Samir Mody
    Senior Manager, K7TCL

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

    Thursday, October 9th, 2014

    This is the final part of a three-part blog based on my paper for AVAR 2012 that discusses the security challenges involved in adopting two relatively new technologies, namely, Internet Protocol Version 6 and Internationalized Domain Names.

    Continuing from the second part of my paper..

    Social Engineering. Malware authors/Spammers/Phishers who now have a larger character set to play with are likely to register domains resembling an original site to trick users into divulging information.

    Fig.10 below shows the domain information for and an IDN equivalent. Considering that the name servers, the e-mail address used to register the domain, etc, do not match, even security savvy users are likely to find it tricky to validate a URL from such IDNs before visiting it.

    Fig.10: whois information on the original and the squatted IDN version

    Thanks to social networking sites like Facebook, twitter etc., which enable instant sharing of information among millions of users from different backgrounds, uncommon URLs could invoke a click from curious users even if they don’t recognise the character set. Malware campaigns such as these, though short lived, could still cause enough damage globally.

    Fig.11: Representative example of an attack based on socially engineered IDNs

    Matching Incongruence

    URL scanners could focus more on consistency or the lack thereof while dealing with phishing and malware related URLs arriving from IDNs. Language mismatch between the message body of the e-mail and the URL, or the URL and the contents of the page that the URL points to, can be deemed suspicious.

    Restrictions may be imposed on visiting IDNs which don’t match a user-defined list of allowed languages. Similarly, domains created by combining visually similar characters from different character sets can also be curbed. Popularly known as a Homograph attack, most common browsers already defend users against such threats. While this protection is only limited to within the browser, it can be extended to protect e-mail, social networking and other layers as well [12].

    Fig.12 below shows two domains, one created entirely using the Latin character set and the other using a combination of Latin and Cyrillic character sets. Though both domains visually appear to be similar, their Puny Code representation proves otherwise.

    Fig.12: Example of two visually similar domains and their Puny Code representation [13]

    Security vendors could also continue existing practices of assigning a poor reputation to domains that originate from certain high-risk countries. Such domains are usually created due to nonexistent or inadequate cyber laws in the host country, which result in malware authors abusing them. Reputation can also be assigned to registrars of IDNs based on their commitment to handling abuse reports, enforcement and verification of registrant details, ease of registering domains in bulk, etc.

    A solution to address the e-mail spam problem could involve creating a white list of registered mail servers. The project, for example, works on the assumption that all computers send out spam, unless they have been previously registered on the white list [14]. In addition, since there are few mail servers catering to a significantly large user base, one could argue that e-mail could continue using IPv4, which could breath new life into the practice of IP blacklisting, at least for e-mail spam.

    There is a Certainty in Uncertainty

    The implications of the transition from IPv4 to IPv6, and the introduction of IDNs, are bound to be of major significance to the Internet infrastructure. These changes engender the continuous growth of the Internet by accommodating an increasing number of inter-connected devices, and variegated foreign languages.

    As with any change, given the absence of a crystal ball, the move to these new technologies involves risk.Without doubt spammers, phishers and malware authors, seeking to make a quick buck, will exploit the larger attack surface provided by a vastly increased IP address space and language diversity via IDNs. We in the AV industry must take cognizance of this to determine the security implications and forge robust solutions.

    As discussed in this paper, the new technologies will put pressure on current methods to counter spam, phishing and malicious URLs, especially where reputation is of prime importance. Fortunately, AV vendors have generally been able to adapt to the regular inflow of new issues, with new responses for these constantly on the anvil.

    The changes about to be witnessed and the solutions proposed are likely to have security companies relying heavily on aggressive heuristics and policy-based restrictions, which could increase the number of false positives. However in corporate environments, rules can be configured to suit the risk appetite of the user in question.

    Things are about to get a whole lot more difficult. However, greater vigilance, user education, and as ever, timely security industry data sharing, will help in controlling the fallout. The challenge is indeed a major one, but it is certainly not insurmountable.

    [13] Information on
    [14] Information on

    Lokesh Kumar
    K7 Threat Control Lab

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

    Keep e-Phishing at Bay

    Friday, September 19th, 2014

    A thus far undisclosed, potentially serious security flaw has been discovered on eBay according to BBC News. Hackers were apparently successful in exploiting a weakness on eBay’s website that enabled them to multi-redirect customers, via a landing page listing iPhones, to phishing pages purporting to be those of eBay so as to steal their login credentials.

    Unfortunately is it likely that several users would have been duped into surrendering their credentials, thus handing over control of their accounts to the bad guys. However, K7 users would have been protected since one of the redirector URLs was blocked by the malicious URL-blocking feature which has the overall effect of nullifying the multi-step redirector chain and protecting users.

    From the user’s side it’s difficult to differentiate between legit redirection and non-legit redirection so this is best left to the site blockers in internet security products such as K7 Total Security.

    In addition to that we also found directory listing and outdated plugins (such as JWplayer) on the destination website to which users were being redirected. Based on website fingerprinting, it seems websites hosting the phishing pages were almost certainly compromised by the attackers to hide their tracks.

    The phishing pages have now been removed, but the domains are still live and we aren’t sure whether the core vulnerability which allowed the hackers in in the first place has been patched. In other words the webserver may be vulnerable to being hacked once more.

    At the time of writing this blog we are unsure whether the cross-site scripting (XSS) flaw exists in other eBay item listings which may or may not be currently in the process of being maliciously exploited. Given the popularity of a site such as eBay, the impact of such an attack can be far reaching and varied; it is possible to leverage redirections to deliver malware via drive-by-download attacks.

    The question which pops up is, “Was this just a phishing attack ??” It could have been much much more damaging.

    Image courtesy of

    Priyal Viroja, Vulnerability Researcher, K7TCL

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