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

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:

Quick Fixes for a Safer Online Banking Experience

Monday, September 15th, 2014

Recently, a researcher colleague at K7 Threat Control Lab faced a minor glitch in accessing his online banking account at one of India’s leading banks. This led him to explore the bank’s online banking website, and he was surprised to find that not only was the main logging information portal vulnerable to simple exploitation but the authentication process also seemed weak in certain areas.

Driven by curiosity, we experimented with the entry level data validation mechanism at the online banking websites of major banks in India to discover if their online banking services are as sound as they claim them to be. Our very basic, high-level “field trials” made us realize that both the bank’s online security methods and user practices could potentially compromise the security of the bank’s online services.

We observed a few simple logic flaws in the online security process which could present loopholes for the bad guys to exploit, thus potentially bruising the bank’s online defences. Note: These logic flaws do not involve the exploit of web application vulnerabilities such as XSS, SQL, RCE, etc.

Field Value Enumeration

A customer trying to access his account is required to submit a login form to confirm his authenticity. We noticed that most of the banking sites validated each entry of the login credentials separately. This kind of independent validation could lead to ‘Field Value Enumeration’ and could subsequently lead to attackers deliberately locking out user accounts. For example, if the account policy of a bank holds that users will be locked out after five failed login attempts, an attacker could lockout an account by deliberately sending an invalid password on five attempts for a valid username. On a large scale, mass account lockouts could amount  to a ‘Denial of Service’ attack, which, if successful, would harm the reputation of the targeted banking institution.

Weak Usernames

Nearly 50% of the internet banking portals have a feeble username-strength validation process. Usernames should be unique, and ideally not be enumerable or guessable, and should never be a “Bank Client ID”, “Bank Customer ID”, “Email ID”. By setting username standards by including alphanumeric and special characters, the strength of usernames can be improved, thus making it that much more challenging for the miscreants to abuse.

Easy-to-Remember Passwords

The password is usually the critical barrier which blocks malicious intruders at entry. However, customers generally opt for passwords which are simple and easy to remember, which makes the hacker’s job a tad easier. For a sturdy password, it should be made mandatory for users to employ criteria such as uppercase, lowercase, numbers and symbols, and minimum length in their passwords as a precaution against brute-force and dictionary attacks.

Additional validation from server side

User validations are mostly coded on client side scripting languages, and are therefore easily circumvented. Additional duplicate user validation processes should ideally be implemented at the server end as well to enhance the overall user validation process.


Almost 60% of the online banking websites lack CAPTCHA implementations. Incorporating a CAPTCHA as an additional step in the user authentication process can significantly mitigate against bots and brute-force attacks.

Mail Notification for “Authentication”

Almost all online banking services have a mail delivery process for each user transaction that occurs. However, we noticed that 60% of net banking services are not sending mail notifications on unsuccessful authentication. Such a notification can be useful for users to be apprised of any unauthorized login attempt. There is unlikely to be a bombarding of the user’s inbox with notifications given that the probability of a legitimate user repeatedly typing in the wrong username and/or password is pretty low.

In conclusion a more secure online banking service can exist by employing enhanced protection strategies and by encouraging customers to adopt good security practices for usernames and passwords, thereby protecting their medium of access to these online banking websites.

Image courtesy of

Priyal Viroja & Archana Sangili, K7 Team

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:

Drive by and you’ll be taken for a ride

Tuesday, September 9th, 2014

Recently we came across a commercial website catering to cycling enthusiasts that appears to be compromised.

The site’s java-scripts are all injected with a malicious iframe strategically placed between blocks of seemingly innocent HTML content. This is an age old technique meant to trick web masters who tend to look for malicious code either at the beginning or at the end of an HTML file.

On visiting the site, your browser loads all the java-scripts for the page which then redirects you to a malicious URL displayed in the screen shot above. This redirected site has just a few lines of HTML  like below:

You’ll immediately be redirected to another URL that looks to be generated using a Domain Generation Algorithm (DGA). This third level of redirection will then lead you to the actual exploit code, which on successful exploitation will drop a malicious payload named “wiupdat.exe” thus completing the cycle of the classic drive-by download attack.

On further analysis of the executable, we realized that the malware pretends to be from K7 Computing by imitating our version strings like below:

This is done to gain the user’s trust who may choose to ignore the executable thinking that it belongs to a reputed security vendor. K7 users will be protected from this malicious file, the compromised website, and the intermediary URLs.

Imitations are flattering!!!

Melhin Ahammad
K7 Threat Control Lab

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

BackOff, from the Point of Sale – But not too much

Saturday, September 6th, 2014

BackOff – a lot has been discussed by the Anti-Virus security community and the non-AV community alike, about this malware and other families of PoS RAM scrapers. In conjunction with the mentioned article, we thought it would be nice to shed some light on this topic, however we’ll try and take a more ‘desi’ angle.

First, some insight on how this brand of malware works. Though generally targeted at PoS (Point of Sale) systems, the malware isn’t restricted only to those systems. It just requires a Windows-based operating system. Once executed it would copy itself into one of those usual Windows directories and with the usual registry entry to ensure auto-initiation between reboots. The dropped copy (mostly faking a legitimate 3rd party Windows software’s name) then goes on to scan the system processes for specific strings that would resemble your common credit and debit card details. It even goes a step further to ‘whitelist’ known processes (like csrss.exe, winlogon.exe, etc.,) and skips scanning those processes. So when an unsuspecting billing clerk at your retailer swipes your card at an infected PoS system your card details would be read by the system and processed in its memory. This data would now be easily accessible for this malware, since it just keeps scraping the memory for exactly such details. Apart from this, the malware also has functionality to log your keystrokes, i.e. whatever you type. While actively collecting all this information it also keeps posting it onto a remote C&C (Command and Control) server. Despite its ‘swiss army knife’-esque functionality this malware has little persistence; it has an injected process and an encrypted copy to achieve this. In case the malware process has been killed or has crashed, the injected process would then decrypt the encrypted copy and re-execute it. But these are techniques that are easily overcome by most Anti-Virus products today.

Getting back to the article, it says this Trojan is “spreading”, whilst in reality Trojans do not really spread themselves; only worms and viruses do. This malware family is almost a targeted type, hence it needs to be strategically ‘placed’ in a proper location to work; in short the distribution vector is of low activity, well, at least in India. A PoS system in a retailer chain would be sitting in one of the most secure network rings of the store, but as always an attacker is going to use various infiltration techniques to obtain access. This might range from a simple SQL injection to a well-crafted, target-specific, exploit-containing spam email to a vulnerable employee. The attackers in this case are targeting ‘remote desktop applications’ enabled systems and try to brute force them to obtain access. The article however describes this to be a functionality of the malware, which is not so. It cannot scan for remote desktop systems and propagate through them.

People in India might recall that the RBI made it mandatory to enter your card’s PIN for using debit cards at the PoS. Though the RBI has averted a huge risk by thwarting a fraudster who doesn’t know a stolen/lost debit card’s PIN from using it, there might now be a new risk of handing the PIN to schemers who control this PoS malware network. However the RBI has also enforced upon banks a policy to limit the scope of MagStripe cards to domestic usage only, and in case a card should have international transaction capability it must be EMV (EuroPay, MasterCard and Visa) Chip and PIN enabled, i.e. very difficult to duplicate.

As always it is advisable for individuals to keep track of their banking transactions, via SMS or email to identify any fraudulent transactions initiated from your cards ASAP.

As for K7 users, though, in case this malware does manage to find its way onto your system it would be stopped dead as we detect all its variants.

Images courtesy of:

Kaarthik RM

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

Thursday, September 4th, 2014

This is the second 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 first part of my paper…

Internet Metamorphosis

The Internet is witnessing a critical phase in the transition from an old technology to a new one, and users must understand the security implications involved. These implications could manifest themselves either during the implementation stage or after.

Tunnel Vision. IP tunnelling implementation involves encapsulating the IPv6 packets into IPv4, which is similar to creating a Virtual Private Network (VPN). Teredo, for example, is a tunnelling protocol that is installed by default on Windows Vista and Windows 7 operating systems, and provides IPv6 connectivity to a native IPv4 device [7].

Fig.4: Example of tunnelled IPv6 traffic[8]

Since the IPv6 contents are disguised inside the IPv4 packets, most security devices struggle to analyse and detect them. This in turn opens the door for attacks when these tunnels are used to transport malware.

There have been known instances of malware which enable IPv6 on a compromised host to communicate with its creator using these IP tunnels. The fact that IPv6 is enabled by default on most new operating systems makes it easier for malware to spread without being noticed. The infamous Zeus, for example, is known to support IPv6 from early 2010 onwards. This malware not only boasts of having the capability to sniff IPv6 traffic, but also supports an IPv6 Peer-to-Peer network [9].

Stack ’em Up. Dual Stack Implementation involves running both IPv4 and IPv6 in parallel, with one protocol taking preference over the other. Communication is done using the preferred protocol first, failing which it is retried using the secondary protocol.

Fig.5: Example of dual stack traffic[8]

Considering that communications happen natively either in IPv4 or in IPv6, and that both protocols co-exist in the network, until sufficient machines become IPv6 compliant, at which point IPv4 can be pensioned off, this is the preferred method of transition.

To NAT or Not. Network Address Translation (NAT) is a technique that allows multiple devices within an internal network to get online by sharing a single public IP address. This public IP address would be provided to a router at the gateway level, which in turn directs traffic to machines inside the network that use non-routable IP addresses.

On a small scale, NAT is used within a Small Office Home Office (SOHO) environment, and on a large scale, often referred to as Carrier Grade NAT (CGN), it is used by ISPs who have a limited number of IPv4 addresses.

Fig.6: Simple implementation of NAT within a SOHO environment

Apart from cutting down on the number of routable IPv4 addresses used, this technology also provided a certain degree of privacy and security to the users in the internal network. Automated port scans and information gathering attempts are deterred at the gateway, and would only succeed from inside the private network.

The gargantuan number of addresses available in IPv6 means that ISPs could technically do away with NAT, and assign a static IP address to each of its users, and yet never run out of addresses in the foreseeable future.

While this would promote end to end connectivity, which was how the Internet was originally envisaged, it could also open up the flood gates of machines which were never previously directly connected to the Internet, for now they would be vulnerable to prying eyes and groping hands.

The silver lining, however, is that since an IPv6 address can now be mapped to each user, tracking down malicious traffic & the victims of a malware incident also becomes easier. It could be a boon or a bane, depending on how one perceives it.

The Whois Who of Malware URLs , Phishing & Spam

Over the years as communication media within the Internet expanded from e-mails to other forms such as instant messaging, forums, blogging, social networking, etc., spammers followed suit with campaigns targeting these channels. These campaigns include the relatively innocuous comment spam posted in blogs/forums, Pump ’n Dump scams, attempts to sell Viagra and the like, phishers vying for sensitive user information, and malware related spam which go for the jugular.

The current volume of spam received via various communication channels is kept to a minimum thanks to a combination of techniques which involves, but is not limited to, content based and list based filtering. Given the plethora of malware URLs and spam messages disseminated everyday, most of this filtering is done using automated systems.

Fig.7 below shows a steady rise in the number of malware/phishing URLs for the first half of the year 2012

Fig.7: Number of malicious URLs crawled by K7 from January 2012 to June 2012 [10]

Content Based Filtering. This works on analyzing different characteristics of a message or a URL. For example, messages with keywords such as Viagra, Rolex, etc, somewhere in the MIME envelope could automatically be declared as spam. Similarly, a URL with words like PayPal or Facebook in the sub-domain component, combined with a recently registered domain name having a minimum validity can be deemed suspicious. However, when these keywords are represented in another language, automated content based filtering could become more challenging since we would now have to recognise the representation of a keyword in as many different character sets or Puny Code equivalents, as possible.

List Based Filtering. This aims to assign a reputation to the source of the e-mail message or the URL. For example, when a stream of messages detected as spam originates from a single IP address, that address may then be assigned a bad reputation, and would go into a blacklist. Similarly, a malicious domain or IP could go into this list.

Subsequent messages from a blacklisted IP address would automatically be labeled as spam & dropped when e-mail servers query the blacklist in real time. Likewise, URLs containing blacklisted domains or IP addresses would also be blocked as malicious.

Fig.8: One blacklisted IP address used to both send spam and host malware [10]

Once a domain/IP address gets blacklisted, the attacker shifts to a new address from which to send the spam or on which to host malware until that gets blacklisted too. They do this by either releasing and renewing their IP from their service provider, if the machine used to send the spam or host the malware is physically owned and controlled by them, or by selecting a new bot, a machine from their botnet consisting of many infected machines, from which to send the spam vicariously or to host malware on the attacker’s behalf.

On an IPv4 network the attacker has a theoretical maximum of only 4 billion addresses to cycle through. This number increases manifold within an IPv6 network. The increase in the number of domain names, due to the introduction of IDNs, is also likely to add to the blacklist woes, especially when these domains originate from an IPv6 network.

Fig.9 below shows the steady rise in the number of IDNs in the first half of the year 2012. Though currently small, the numbers are expected to increase significantly over time.

Fig.9: Number of malicious IDNs crawled by K7 from January 2012 to June 2012 [10]

Another problem with respect to blacklists is the amount of disk space occupied by these lists and the time taken to look them up. Even in the case of the relatively impoverished IPv4, assuming that all 4 billion addresses get blacklisted, a flat CSV file containing all these addresses occupies a minimum of approximately 60 Gigabytes of disk space on a Unix platform [11]. Consider further the amount of time taken in creating, maintaining, and querying such a big database in real time. Such a system would be nigh on unworkable for IPv6.

Click here to read the third part of this blog.

[7] Information on
[8] Information on
[10] Internal data

Lokesh Kumar
K7 Threat Control Lab

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