Magical lights shine on you

2007-04-01

Righard Zwienenberg

Norman, The Netherlands
Editor: Helen Martin

Abstract

'The use of trojans to gather evidence has previously been proposed by law enforcers in Sweden, the Netherlands, Denmark and the USA ... However, there is something of an obstacle for all magic lantern projects: the anti-malware industry has the habit of developing solutions that detect malicious or unwanted activity.’ Righard Zwienenberg, Norman.


In February, the light of a 'magic lantern' shone once again, this time on computer users in Germany. 'Magic lantern' is the term that has been adopted by the anti-malware industry to describe a trojan that is planted (without the user's consent) on a system by an official intelligence agency or criminal investigator in order to gather evidence relating to the user's activities.

The magic lantern idea is not new. The use of trojans to gather evidence has previously been proposed by law enforcers in Sweden, the Netherlands, Denmark and the USA. The first time the magic lantern idea came to light was in 2001, when there was rumoured to be in existence a key logger, created by the FBI, which could be installed remotely via an email attachment or by exploiting vulnerabilities in the operating system. (Code Red was first discovered in July 2001 - was it a trial run?)

However, there is something of an obstacle for all magic lantern projects: the anti-malware industry has the habit of developing solutions that detect malicious or unwanted activity. And we are getting better and better at doing so in a generic way, using heuristics or behavioural analysis. Therefore there is a very high likelihood that at least one anti-malware product or forensic tool will be able to detect the malicious nature of the code (which, at least from the user’s point of view is unwanted), thus revealing the presence of the trojan to the user. This would put the evidence gathering at risk: a criminal who detects a surveillance trojan on his system would likely then delete all the evidence before the investigators have obtained it. Extremely counterproductive!

To get around this problem, the intelligence agencies will have to ask the anti-malware industry not to detect their magic lantern trojans. To ask one company for cooperation would seem reasonable, but to get the entire anti-malware industry to agree not to detect a piece malicious code (whose origin and purpose is irrelevant for analysing engines) would be a utopia.

The anti-malware industry as a whole has, in fact, already agreed to make one exception to its detection rules: almost all anti-malware products detect and treat as malicious the (clean) EICAR test file (see http://www.eicar.org/anti_virus_test_file.htm). However, in the case of the magic lantern trojan, even if the majority of vendors agreed not to detect the trojan, it is likely that there will always be one or two (if not more) vendors who choose to detect it. This may be for ethical reasons, it may be because the vendors are new to the market and unaware of the non-detection agreement, it may be for PR reasons (making such an exception would get the company a lot of press coverage), or it may simply be because the vendor has updated its behavioural analysis module, with the result that the trojan has become detectable.

For the sake of this article, let's assume that it is possible to have a global non-detection agreement for a magic lantern trojan. The next problem is that the trojan can only be used once. Criminals may have backups which are not discovered and confiscated at the time of their arrest. These could then be analysed by the criminals or their associates, and information about the trojan would quickly become freely available. Even if the established anti-malware industry didn’t detect it, there would be a market for one-off scanners, detecting just this instance of the 'magic lantern trojan'. So, for every instance in which an agency wants to deploy a magic lantern trojan, a new one would have to be made - and in every instance it would require the agreement of all anti-malware and forensic utility vendors not to detect it. World peace would be easier to accomplish.

As for whether such a magic lantern does exist and has ever been used, I am not aware of one, and I don't believe such a thing has ever been deployed (yeah, right!). If I at least plead ignorance in public, it might save me from being taken away in a dark-windowed car by men in black suits and sunglasses.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.

Excel Formula/Macro in .xlsb?

Excel Formula, or XLM – does it ever stop giving pain to researchers? Kurt Natvig takes us through his analysis of a new sample using the xlsb file format.

Decompiling Excel Formula (XF) 4.0 malware

Office malware has been around for a long time, but until recently Excel Formula (XF) 4.0 was not something researcher Kurt Natvig was very familiar with. In this article Kurt allows us to learn with him as he takes a deeper look at XF 4.0.


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.