ESET Threat Blog

Archive for October, 2008

Google Chrome May be the Wrong Choice


Friday, October 31st, 2008

After having used the Google Chrome internet browser for a while now, I can say that it is generally a pretty nice browser, but I have some very serious privacy concerns.

When you open a new tab in Chrome, it displays pictures from websites you have visited. This means that if someone is sitting next to you, the moment you open a new tab, your recent browsing history is prominently displayed. The obvious response to this by some will be “Then don’t visit porn sites.” This is of course a very short-sighted response.

Do you work for a company with an internal website? Is Chrome going to show people confidential or proprietary information as soon as you open a new tab? Do you want to tell the person sitting next to you on an airplane or in a coffee shop where you bank, what stocks you own, your own medical conditions which you may be researching, that you are looking for homeopathic cures for hemorrhoids, and so on?

With Chrome you will instantly and automatically display websites you visit when you open a new tab.  If a person is a victim of domestic violence, this could be an extremely serious privacy and safety problem which may result in injury or death. Simply clicking on new tab to hide the current window from prying eyes may cause even more harm.

ESET Researcher Pierre-Marc Bureau pointed out to me that already when you start typing a URL into the address bar it may display some sites you have visited. This is a valid point, however the size of the displayed data is significantly smaller, and the duration of the display is probably going to be much, much shorter. Unlike Firefox, Chrome has no setting to automatically delete the history, etc. when you close the browser and no user control over how long history and temporary files are stored.

Chrome is still in beta and when it releases, perhaps the new tab display design flaw will be fixed. For the time being, I would have to say that Chrome is inappropriate for corporate users, the worst choice for victims of domestic violence, and a miserable choice for those who like privacy and tabbed browsing.

For a product in beta it is understandable that Chrome is quite weak on configurability options, but quite frankly, with such an obvious design flaw related to privacy, Chrome went into beta prematurely.

For the time being, the work around is to clear the browsing data regularly. Another option is to change the shortcuts to Chrome. Chrome has a feature called “incognito” browsing. Incognito is quite misleading, it doesn’t make you at all incognito, but it does help with privacy… most noticeably by not displaying any of your browsing history in a new tab. Unfortunately Chrome has no setting to start in incognito mode. To start the browser in incognito mode you need to modify the command line and add “–incognito” without the quotes. I use the quick launch button to open Chrome. If you right click on the Chrome Icon and choose properties there is a field called “Target” and that tells the computer what program to run when you click the button. By default the entry for Chrome is
"C:\Documents and Settings\<user name>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe"

By adding –incognito to the end of this as shown here:

"C:\Documents and Settings\<user name>\Local Settings\Application Data\Google\Chrome\Application\chrome.exe" -incognito

I always launch Chrome in incognito mode and don’t have to worry about the Chrome tabbed browsing privacy vulnerability (or design flaw) on my computer.  Note that <user name> is the name of the user who is currently logged in.

If Google fixes this egregious privacy problem, the browser looks like it will easily contend for market share with Microsoft and Mozilla. If Google adds some additional configuration flexibility the browser will even be suitable for use by people who understand security and privacy. The inability to choose to be prompted for an action when a “secure web page” attempts to display both secure and insecure content leaves a lot to be desired. For now I would have to recommend that most users stick other current browsers, especially in a corporate environment, or if there is any need for privacy and confidentiality at all.

Randy Abrams
Director of Technical Education

Giving (Samples) to Charity


Tuesday, October 28th, 2008

You may have noticed that we have an intense interest in issues around sample-sharing and testing. Recently we noticed a thread in a forum associated with a free security product, originating in an open letter to a well-known tester, asking him to donate his sample set for the improvement of the product.

You might think that the anti-malware industry might hate the idea of free anti-malware products. As it happens, we aren’t against free products in principle: some companies make a free version of their software available for home users, and others (like ESET) make a free on-line version available. (There is a problem with many free products if the user gets the idea that they’re better protected by freeware than is really the case, and I’ll revisit that issue in another, more general blog.)

However, on this occasion, many of the people involved in the thread have missed the point, and that’s the point I want to focus on now.

Sample sharing in the anti-malware industry is done on the basis of responsible, ethical exchange between trusted parties (including reputable testing organizations). The exchange might be regulated by contractual agreements, but even when the agreement is informal, it’s always on the assumption that the same samples will only be passed on subject to terms acceptable to the original source of the samples.

In other words, if source A gives samples to tester B, A is entitled to expect that B will not pass them on to anyone else unless that’s within the terms of their agreement, and that if B does pass them on, it will be in a responsible manner to a trustworthy individual. (Let’s be original and call him C.) If those expectations are not met (as when B doesn’t have permission to share A’s samples, or A doesn’t regard C as a trustworthy individual), the trust relationship between A and B evaporates: A stops giving samples to B, so C’s supply also dries up. Everybody loses.

It’s not about C being in competition with the commercial interests of mainstream vendors: the purveyors of free software aren’t generally able to offer the full range of features and support that commercial vendors can, so aren’t really in competition. It’s perfectly possible for a developer of free software to develop trust relationships of his own with the anti-malware industry, but he has to prove in some way that he’s honest and competent.

Let’s assume that C is a sincerely well-meaning individual with no hidden agenda, but has no interest in co-operating with the anti-malware community at large. That may be because he doesn’t trust that community, which is his prerogative, but means there is no basis for a mutual trust relationship. Even worse, he may not understand not only the ethical framework but also the technical issues around co-operation in the industry, which suggests that he doesn’t really understand the nature of the threat he’s aiming to mitigate. (That’s also an issue that deserves its own blog.)

To attempt to use someone else’s trust relationship to get an occasional transfusion of samples so as to avoid subjecting oneself to the scrutiny of the anti-malware industry would , regardless of the ethical issues, simply not be a practical approach to maintaining a serious malware-specific scanner.

David Harley
Director of Malware Intelligence

An Introduction to Packers


Monday, October 27th, 2008

Packing technology is really just compression. You know, ZIP, CAB, RAR, and so on. There are many types of packers and some people even write their own. The way a packer compresses the file is called an algorithm. There are many different algorithms and unless you know what one was used, or have a tool to unpack the file you will not be able to use the file.

A simplistic explanation of packers, or compression (same thing) is that symbols are used to represent repeated patterns.

Take the following sentence:

The monkey does not know he is a monkey, he thinks that you are the monkey.

What if we replace the word “monkey” with “%”?

The % does not know he is a %, he thinks that you are the %.

The sentence has fewer characters, but unless you know our “algorithm” you won’t know what the sentence means.

How about “The * does not know he is a *, he thinks that you are the *.”

Since I have not told you what the “*” replaces you don’t know if now I am talking about cats, pigs, aliens, or what.

If I live in a place where I am not allowed to say the word “Freedom”, this technique allows me to effectively say the word “Freedom” to anyone who understands the algorithm, but the authorities will not see the word if they scan my emails.

A packed file can contain malware and unless your anti-virus product knows how to unpack the file the malware will not be detected. On the bright side, if the malware is packed it cannot infect your computer. That would seem to be the end of the story, except that we have something called run-time packers. Here is how they work. The packed file is an executable (program) that is only partially packed. A tiny bit of the program is not packed. The beginning of the program is not packed so, when you run the packed executable it starts unpacking the rest of the file. The un-packer tool is built right in.

Runtime packers are used by malware authors because it makes it much harder to detect the malware. One of the strengths of the type of heuristics that ESET, and some other vendors, use is that we create a virtual computer in the scanning engine and run the program. This can force a run-time packed program to unpack itself, saving us the trouble of needing to know the algorithm.

There’s always a catch though… a crafty programmer can make the program detect it is running in a virtual environment and then the program may not unpack itself or may only unpack harmless parts of itself to fool the virus scanning program.

There is another approach to dealing with the problem. Some companies pretend like they detect malware when they actually simply detect anything that is packed with specific types of packers. This makes them score better on tests that are not well constructed. We have encountered very few packing technologies that are ONLY used for bad software. This means that good software that is packed is detected as infected by those companies who only detect the packer. These are false positives.

Another approach is to combine recognition of packers with more sensitive behavioral detection as simply being packed with some programs makes the file very, very suspicious. Many of the threats we see are packed with a program called “Themida”. The program itself is often used for copy protecting software, but it was a difficult packer to reverse engineer. The malware writers knew this so they started using the technology extensively. Themida is an example of a runtime packer.

The key thing about packers is that in addition to making files smaller, they also break traditional signatures, so a heuristic approach is required in order to detect the packed files without creating false positive on legitimate software.

If you have any questions on this topic, or other security topics, feel free to email askeset@eset.com. The address is not for technical support however.

Randy Abrams
Director of Technical Education

A Closer Look at Gimmiv.A


Friday, October 24th, 2008

As stated previously by Randy, a new vulnerability affecting the Windows operating system from Microsoft has recently been discovered and has been patched Yesterday by an out of cycle patch.  This vulnerability has been exploited by attackers to install a trojan horse on victim computers.  The name of this trojan is Gimmiv.A.  This blog post will give more details on this malware that is the payload of the attack.  For our readers who want more information on the MS08-067 vulnerability and potential exploits, we recommend consulting Microsoft’s advisory.  Exploit code has already been made public for this vulnerability but finding it is left as an exercise to the reader.

The threat labeled as Win32/Gimmiv.A is an executable that writes a DLL (sysmgr.dll) to disk.  The executable registers the DLL as a system service with the name "System Maintenance Service".  Before starting the newly created service, the Gimmiv.A executable launches a batch script that tries to kill Trend Micro’s antivirus.  This executable is easy to analyze since it doesn’t include any obfuscation and has debugging messages as shown in the code snippet below:

call    ds:RegCreateKeyExA
mov     [ebp+call_result], eax
cmp     [ebp+call_result], 0
jz      short no_error_found
push    offset aRegcreatekey_0 ; "RegCreateKeyEx() failed!\n"
call    debug_message

sysmgr.dll contains the main functionalities of this piece of malware.  The first steps it takes are to verify that the infected system is connected to the internet by sending a ping to a google server.  If an answer is received, the malware continues executing.  Otherwise, the malware uninstalls and exits.  When reporting to its home base, Gimmiv.A sends information on the version of the operating system it has infected and which antivirus is installed.  This malware checks the system to identify the presence of the following antivirus products:

  •  Trend Micro
  • Symantec
  • BitDefender
  • Rising
  • Kaspersky
  • Kingsoft
  • Microsoft One Care
  • Jiangmin

The main purpose of Gimmiv is to give access to an infected computer to the attacker, it also gathers a lot of information on the infected computer and sends them back to the attacker.  The collected information includes:

  • MSN Messenger username and password
  • Outlook Express username and password
  • Saved passwords in Internet Explorer
  • Web Cookies with potential authentication tokens
  • Any file wanted by the attacker

At the moment, we are not seeing a lot of activity from this malware.  Its distribution point has already been taken offline.  From the information we could gather on this threat, it seems like it was targeting users in Asia.  This malware seems to be well programmed and could have been used by professionals but it is a bit too generic to indicate it was used in very precisely targeted attacks.

Pierre-Marc Bureau

Researcher

 

Microsoft’s October Out of Band Patch


Friday, October 24th, 2008

Typically, Microsoft releases patches (security fixes) on the second Tuesday of each month. This day is affectionately called “Patch Tuesday” by many. On very rare occasions when there is a particularly severe vulnerability Microsoft will release a patch as soon as possible.

Yesterday (October 23rd, 2008) Microsoft made a rare exception and released an “out of band” patch. The reason for the patch is a vulnerability that can allow a Windows computer to be exploited without requiring user interaction. This means that worms can spread very quickly.

The newest Microsoft operating systems, Vista and 2008 Server, are less prone to worm type attacks, but even XP can be fairly resilient if you have the firewall turned on and do not enable file and printer sharing.

Typically, when such a vulnerability is exploited, the result is that malicious software is downloaded and run on the affected computer. Antivirus software can often protect a user against such an attack, even when the vulnerability is exploited, but still, the best defense is to patch your operating system. Even with the firewall enabled it is very easy to trick users into running programs that exploit the vulnerability.

I highly recommend that you go to Windows update and make sure you have all of the current security updates. We have samples of exploits in the wild, so this is not a theoretical problem.

At http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx you can click on your operating system under the section titled “Affected and Non-Affected Software and be taken to the page with the appropriate patch download, or simply use Windows Update in your Windows operating system.

For the techies in the audience, stay tuned for a post by Pierre-Marc Bureau. Pierre has been analyzing samples of exploits!

Randy Abrams
Director of Technical Education

Asking for samples for testing


Friday, October 17th, 2008

From time to time we are asked to provide samples or malicious URLs to individuals and groups who are not in the full-time testing business. We do, of course, share such material with other actors in the security industry who are within our web of trust, but are not usually able to honor requests from other groups for the following reasons.

Bias and Statistical significance

Firstly, there’s nothing to stop us, or any of our competitors, sending a reviewer essentially unimportant links or samples, knowing that it’s unlikely that the competition will have exactly the same malware derived from exactly the same sources. This really proves nothing about the detection capabilities of our  product or the competition: it simply enables the tester to gather samples that may or may not be valid.

Secondly, the small sample sets with which occasional tests are normally carried out are statistically uninformative. We see some tens of thousands of such active links daily (usually because we have detected some malware being downloaded from them) and process over 100,000 unique samples daily: clearly, turnover on this scale is impractical for an occasional tester. It’s also quite likely that out of any set of links that we forward in good faith, a proportion will be ‘dead’ by the time a reviewer comes to test them.

Ethical considerations

It is, of course, hard for us as a company not to offer help with the acquisition of samples, as non-participation is likely to be interpreted negatively by both the reviewing organization and by the reader. Equally clearly, it is nice to have any (positive) publicity that can be generated by the review. However we generally feel that we are unable to help, not because we believe we would do particularly badly in a specific test, and not only because we often believe the tests in question to be seriously flawed, but also because of the ethical objections to providing malicious samples and links. Such provision is at best a ‘gray’ area, and goes against the normal practices of the industry (at least, from the more traditional anti-virus vendors).

ESET does share samples with bona-fide vendors, researchers and law enforcement agencies, but this is only done in specific circumstances under tightly-controlled conditions with vetted individuals representing respected testers and other organizations. In principle, we don’t see a real difference between supplying malicious URLs and supplying actual samples of malware.

Contrary to the popular myth, this practice, which is common among anti-malware vendors, is not adhered to because vendors are somehow conspiring to prevent anyone finding out how ineffective all the products are. In reality, we have always tried to act in such a way as to prevent the possibility of our actions ever causing others to become infected or affected by malware. Were we to pass samples to an individual or group whose trustworthiness and/or competence we are unable to evaluate effectively, we would be ignoring the risk of such undesirable side-effects. Certainly, we do not object when testers commission a recognized independent testing company such as AV-Test or AV-Comparatives to perform testing on their behalf, as they have established methods of handling and dealing with the samples that would be unlikely to cause any collateral damage.

Furthermore, while we obviously have an interest in doing well in independent tests, we don’t feel that contributing to tests that may be biased or misleading is good for the consumer or for the industry. Often we have no visibility into the methodology used, or consider the methodology as described to be inadequate to meet the needs of the test and test audience. For example, we don’t consider tests based on validation (or even worse, actual testing) by submitting samples to VirusTotal and similar facilities to constitute a fair test of a modern scanner’s capabilities. Similarly, the use virtual machines, though convenient for the tester, is complicated by the fact that a large percentage of modern malware is able to detect that it is running in a virtual machine (of whatever stripe), and either exits, or acts abnormally in such circumstances, therefore adding a further layer of difficulty to establishing the sample as truly active malware.

Where Next?

We are all too aware that some aspiring testers will find this position unhelpful, and may feel obliged to find other sources of malware to test with: this is unfortunate, because ready sources of malware are rarely reliable, but we can’t accept “if I don’t do it, someone else will” as an ethically sound position. We are, however, more than happy to discuss these issues further, and help anyone with a bona fide interest in testing in any way we can, subject to the ethical and moral framework in which we have to operate, as a responsible security vendor.

We also recommend that anyone with a serious interest in anti-malware testing consider joining or aligning with the aims of the Anti-Malware Testing Standards Organization (AMTSO), and at least to check out the AMTSO web site at http://www.amtso.org, where an expanding range of informational resources is becoming available.

Resources

AMTSO Dynamic Testing Practices RFC, AMTSO Fundamental Principles of Testing RFC: http://www.amtso.org/documents/cat_view/13-amtso-principles-and-guidelines.html

Testing-related papers and other resources: http://www.amtso.org/relatedresources/6-resources.html

EICAR test file: http://www.eicar.org/anti_virus_test_file.htm

David Harley, Robert Slade: “Chapter 9: Product Evaluation & Testing” in “Viruses Revealed” (Osborne, 2001) by Harley, Slade & Gattiker

Andrew Lee, David Harley: “Chapter 10: Antimalware Evaluation and Testing” in “AVIEN Malware Defense Guide for the Enterprise (Syngress, 2007) ed. Harley

 

 

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

Wave of Malicious PDFs


Thursday, October 16th, 2008

For the last couple of weeks, we are seeing a wave of malicious PDFs crafted to exploit security flaws in PDF reader software.  For the last two weeks alone, we have detected more than 25 000 attacks involving this type of file.  Attackers are exploiting two different vulnerabilities in Adobe Acrobat Reader to execute arbitrary code on victim computers and install malware.  The two vulnerabilities are described in details here: CVE-2007-5020 and CVE-2007-5659.  Versions of Adobe Acrobat Reader higher than 8.1.1 are not vulnerable to these attacks.  We have seen malicious PDFs being distributed as email attachments but also in exploitation packs like NeoSploit that use this file as another way to attack web browsers.

Malware authors have been fast in introducing multiple layers of obfuscation in PDF files to try to evade antivirus detection.  The first layer of obfuscation is directly in the PDF file.  According to the specification, parts of the file can be compressed using zlib compression.  Malware authors use this compression to hide their javascript from direct inspection.  The javascript is then responsible of checking the reader’s version, building a shellcode, placing everything in memory and calling one of the vulnerable function.  In a majority of cases, the shellcode is also obfuscated using another layer of javascript obfuscation.  More information on obfuscation used in PDFs can be found in a blog post from Websense’s research team.

ESET NOD32 Antivirus detects PDF threats as PDF/Exploit.Pidief.  The final payload of these attacks is, most of the time, to install a fake antivirus like XP Antivirus which is detected as Win32/Adware.Antivirus2008 by our antivirus.

Pierre-Marc Bureau
Senior Researcher

Testing Internet Security Suites: More Questions than Answers…


Tuesday, October 14th, 2008

…and for once we’re not one of the vendors getting hammered.

Secunia, a Danish company that sends out security notifications, has announced that it has tested a dozen security suites. Interestingly, Secunia used a number of exploits developed in-house for analysing vulnerabilities rather than the sort of malware sample based testing that we’re more used to discussing here. Secunia state that they chose to test "high-end" product suites marketed as "comprehensive Internet Security Suites" because their marketing gives the impression that users are "fully protected against all Internet threats." I don’t believe that it’s altogether appropriate to blame vendor marketing for this impression. I’d agree that it is iniquitous to market any product in terms of "this is the only security measure you’ll ever need and you can do anything you like and click on anything you like because we will fully protect you from yourself as well as the bad guys." Technology cannot protect anyone from everything, even someone who behaves responsibly on-line. However, I think you’ll find that many researchers within the industry are of the same opinion: certainly Graham Cluley was quoted by John Leyden of The Register as agreeing that patching is important and that there’s no such thing as "the perfect security suite",  while Graham also remarked that it sounded as though the products tested would probably perform better in a more "real-life test". 

However, Leyden - never the anti-malware industry’s number one fan – clearly feels that a point has been made about the incompetence of this product sector, and made some cutting remarks about chocolate teapots. Thomas Kristensen, of Secunia, was quoted as saying that "generic detection of exploits would be a better approach". Apart from the fact that it seems very archaic to assume that a modern anti-malware program (let alone a suite) is wholly dependent upon signature scanning, this comment does bring to mind the old saw (pun intentional) that to a man with a hammer, every problem is a nail. It’s to be expected that Secunia would focus on exploits, since that’s their specialty. And it’s perfectly true that there are classes of threat that can be forestalled generically (we do quite a lot of that ourselves…) but an awful lot of threats are not exploits of unpatched vulnerabilities, and it’s misleading to focus purely on that approach as if it were The Answer(TM).

In other forums, there’s some disagreement about whether there’s an element of dynamic analysis present in this test, pending further clarification from Secunia. I have the permission of Andreas Marx, a very experienced tester and one of the leading lights of AV-Test, to quote him at length. (Thanks, Andreas!)

Andreas believes that there are a number of problems with the test, at least as described by Secunia:

  • some critical details are missing, for example, the time of the last update of the scanners, the exact product versions, and the like
  • only the on-demand scanner and the on-access guard was tested, so it was only checked if the file-scanner would trigger an alert
  • the paper also speaks about a test with html/web pages, but I cannot see a single test case for the part in the review (is it missing or was it excluded?)"

He believes that a critical point here is that scanning "all data files for possible exploits…would slow down the scan speed dramatically." He states, quite rightly, that most companies have focused on common file-based exploits like the ANI exploits. (In a perfect world, all vulnerable systems would have been patched for these long ago, of course.) He goes on to point out that there are many other approaches to proactively preventing exploits that don’t seem to have been tested here, such as:

  • filtering known "bad" URLs
  • browser exploit filtering
  • buffer, stack or heap overflow protection

HIPS, IDS or personal firewall components

 He concludes that "a better test setup would…have the vulnerable applications installed on the test PC, together with the security suite…Then the tester would need to trigger the exploit, and see whether the machine was exploited successfully or not…really focusing on the entire suites’ features and not only on the ‘traditional’ scanner part of an AV product."

This, of course, is an approach much closer to the dynamic testing models towards which the better testing organizations are moving, as providing a fairer assessment of the capabilities of  tested products. I’m hoping that Secunia will respond to various requests for clarification of their methodology, and in particular whether it’s seen as aligning with AMTSO recommendations for good testing practice.

David Harley
Malware Intelligence Team

 

Phishers Don’t Care…


Monday, October 13th, 2008

I don’t suppose you thought they did. But just to prove that scammers have no compunction about using people’s understandable fears about the current financial crisis as a means of stealing from them, here’s a short extract from a fairly typical example of a current wave of fraudulent emails.

"Subject: New campaign against financial markets collapse

 Due to collapse of financial markets, Barclays Bank PLC, Treasury, Bank of England and Financial Services authority launch a protection program  to ensure the safety of your personal savings, loans, personal and business accounts. Barclays Bank PLC is fighting to ensure that non of our customer will suffer any damage on they personal accounts. Is imperative for all Barclays Bank PLC customers to take this protection program very seriously."

This is a crude example that doesn’t show very effective psychological manipulation techniques, but there are examples that do a much better job. The important thing, though, is not to focus on specific tricks, as these are changed and updated all the time. It’s better to (a) assume that unsolicited material like this is guilty until proven innocent (b) look for the underlying logical inconsistencies and technical anomalies rather than specific phrases.

I realize this is more difficult than it sounds, but we do have a couple of papers on our white papers page that include some tips and tricks ("A Pretty Kettle of Phish" and "Phish Phodder"). Bear in mind, though, that it’s not unusual for scammers to try to twist such advice in such a way that they can build it into a new social engineering technique.

David Harley
Director of Malware Intelligence

Memetic Malware Part 36


Monday, October 13th, 2008

Memetic malware, in case you haven’t heard me ranting on the subject before, is a pseudo-technical term applied by some to hoaxes, semi-hoaxes, urban legends and so on, especially when spread via email and other Internet services.

The adjective memetic derives from the coining by Richard Dawkins of the noun meme, which he described in "The Selfish Gene" as "a unit of cultural transmission" in much the same way that a gene might be described as a unit of biological inheritance: it describes the dissemination of an idea or fragment of thought passed on by replication in a way that is not unlike the mechanism by which a computer virus passes on a "possibly evolved copy of itself. So the term memetic malware is often applied to virus hoaxes, all manner of chain letters, and so on. The anti-malware community in general has largely lost interest in them, now we rarely see brand new metaviruses like "Good Times" or "SULFNBK" (though old virus hoaxes continue to be seen: in fact old hoaxes of all sorts circulate tirelessly.

Of the comparatively recent hoaxes to have crossed my radar in the past few months, most have been related to the US presidential elections, and while an analysis of some of those might be an interesting and useful educational exercise, I’d just as soon not open this blog to a debate on the vices and virtues of various candidates.

I don’t really see it as being within my remit to defend the commercial interests of Starbucks, either, but since friends of mine here in the UK were recently taken in by a variation of a common chain letter hoax claiming that Starbucks declined to send free coffee to US (or in this case, UK) forces serving in Iraq, I will point out that these stories have been analysed at length by knowledgeable commentators such as Snopes. In fact, while this particular hoax has gained traction because so many people have strong opinions on the Iraq conflict, it has some resemblance to an older group of food-related hoaxes such as the Nieman-Marcus cookie hoax. To me, this suggests that hoaxers are as inventive as the disseminators of real malware in seeking new social engineering tricks to gain new victims.

Please note that it’s unlikely that any comments will be approved here focused on the rights and wrongs of the Iraq conflict…

David Harley
Malware Intelligence Team