These are quick first looks and trend and threats


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

Archive for the ‘Security’ Category

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:

http://blog.k7computing.com/feed

https://icann-deal.with.it (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 baidu.com 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 baidu.com 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 Ipv6whitelist.eu 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. we.can.deal.with.it

References:
[12] http://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_the_attack
[13] Information on http://en.wikipedia.org/wiki/IDN_homograph_attack
[14] Information on http://www.ipv6whitelist.eu

Lokesh Kumar
K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
http://blog.k7computing.com/feed/

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 mashable.com.

Priyal Viroja, Vulnerability Researcher, K7TCL

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

http://blog.k7computing.com/feed

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.

No CAPTCHA

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 halomedia.co.za.

Priyal Viroja & Archana Sangili, K7 Team

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

http://blog.k7computing.com/feed

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:
http://blog.k7computing.com/feed/

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:
http://blog.k7computing.com/feed/

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:
outright.com
officeclipart.com

Kaarthik RM
K7TCL

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

http://blog.k7computing.com/feed/

https://icann-deal.with.it (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.

References:
[7] Information on http://www.us-cert.gov/reading_room/IPv6Malware-Tunneling.pdf
[8] Information on http://www.cybertelecom.org/dns/ipv6_transition.htm
[9] https://blog.damballa.com/archives/438
[10] Internal data
[11] http://www.circleid.com/posts/digging_through_the_problem_of_ipv6_and_email_part_1

Lokesh Kumar
K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
http://blog.k7computing.com/feed/

“Now You See Me, Now You … Errr … See Me”

Wednesday, August 6th, 2014

Much has already been written about Win32/Poweliks, the touted fileless persistent malware.

The malware uses an embedded NUL within the key under the following registry path:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

This non-standard use of NUL as part of the key name is not new. A similar trick was likely used by variants of more advanced malware such as ZeroAccess, when creating helper files on disk. Regedit, a usermode process, is unable to read this keyname, but it doesn’t mean the entry is invisible. In fact K7′s rootkit scanner reveals the key with ease:

The other important point is that the infection chain involves a malicious Microsoft Office document containing a dropper Windows executable file, both of which must exist on disk as normal files, albeit ephemerally, and executed before the above-mentioned registry entry can be created. This provides a fleeting opportunity to detect these vital components easily, and detect them we do as

Trojan ( 0001140e1 )

and

Trojan ( 0049882d1 )

respectively.

The techniques used by the malware to execute a JS-decoded DLL via a registry entry are indeed interesting, but there are still quite a few opportunities to flag the infection at various stages of the infection chain, including at the entry spam email stage itself. It remains to be seen if the malware evolves to employ more sophisticated techniques in future.

Samir Mody
Senior Manager, K7TCL

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

http://blog.k7computing.com/feed

Tax Deducted @ Spam?

Tuesday, August 5th, 2014

‘tis the season for filing Income Tax Returns in India! Fa la la la la la la la!  To make the task easier, nowadays there are agencies that help people file their IT returns online. On 1st August 2014 one of the researchers in our lab received an email in his spam folder from an agency with the subject stating, Today is the last day for filing your Income Tax return, i.e. well after the deadline of 31st of July, IST, for filing returns.

The actual message received is shown in the image below:

What caught our attention is that, on hovering over the button “File your Income-tax return Today!” the website in the hyper link was different from the website address the email was claiming to come from. The resulting website when you click on this button asks for sensitive information like PAN card and bank account details.

Further investigation helped to identify the websites as clean. However, it has been constantly advised by the Government of India not to carry out these kinds of sensitive activities through any unauthorized third-party websites, to avoid any unhappy situations, as explained in the following popup image from incometaxindiaefiling.gov.in, the bona fide portal through which ITRs ought to be filed:

The websites involved in such ITR-filing activities seem to be  unaware of the future consequences of their ill-thought-out email campaigns to promote their businesses.

It’s a known issue that hackers are always in search of new ways to harvest private/critical information from users for their own gain. The strategies used here by the third-party agency to redirect to its own tax filing page might also be used by hackers in phishing activities to exploit GOOD RETURNS!

Let’s now look at other facets of the above email which increase suspicion levels:

  1. The email is not addressed to the receiver but rather to a generic “Hello [NAME]”
  2. Questions are to be emailed to an email domain name which appears, at first glance, to originate from outside India

No wonder this email, which by the way was received TWICE within a short span of time, ended up automatically in the spam folder.

Vivek Das
Automation Developer, K7Lab

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

http://blog.k7computing.com/feed/