DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your

production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.




McAfee Labs Threat Advisory
Combating FakeAlerts
July 20, 2011
Summary
Software that masquerades as a legitimate security application purely for monetary gain is termed as a fake
or a rogue security product
1
. Such products usually employ social engineering, scare tactics, and trickery to
entice unknowing users to purchase their products.

Infection and Propagation Vectors
Characteristics and Symptoms
Prevention and Mitigation
Getting Help from the McAfee Foundstone Services team
Infection and Propagation Vectors
Fake security products often use trojan-like behavior. Unlike viruses, trojans do not self-replicate. They
spread manually, often under the pretense that they are beneficial or wanted. The most common installation
methods for fake security products involve:
System or security exploitation such as drive-by downloads
Links within spam emails that lead to malicious pages
Execution of unknown programs
Downloads by other malware
Peer-to-peer networks, etc.
Characteristics and Symptoms

Description
Once it successfully installs, a fake security product often triggers a brief system scan. After completing the
scan, the application displays a fairly long list of infections. The files and registries listed in the infection are
either dummy detections on objects that do not exist or objects that the rogue product itself has created.
Fake software may also create shortcuts on the desktop and in the start menu that point to its main
executable.

Though there is no definitive rule to identify a fake infection, this document attempts to offer some helpful
guidelines in doing so.

The real purpose of fake software is to get users to purchase their product. Therefore, such software is
usually very persistent in its attempts to coax customers into buying them. Users will often suffer multiple
pop-up windows indicating that their systems have been infected or are actively being exploited.

The following are some typical symptoms of a FakeAlert infection:




1
The terms fake and rogue are used interchangeably.
DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Fake Online System Scans

Re-direction or spam email links are a common method utilized to trigger an initial download. If so,
users are redirected to web pages that may have embedded Java Script that display a fake Scan
window such as the one shown below.
NOTE: This is an IE page that attempts to pose as an explorer Window. It shows drives that may not
even exist on your computer or may not be a complete list of drives.



At this point your system is not infected.
If however, the Remove all or Cancel buttons in the browser are clicked, they will attempt to push
an executable. If the executable is run, the FakeAlert is delivered on to the system. This method is
purely based on User Interaction and thrives on a common Social engineering attempt.
The Fake Online scan is typically followed by infection and issues a Fake System Scan.

Fake System Scans

In most cases a drive-by download or a browser exploit is used as a delivery mechanism. This is a
preferred method of infection by the malware since it requires no user interaction. Using exploits
would cause a system to get infected.
After infection, the rogue application attempts to trigger a system scan. A result window is displayed
at the end of the scan identifying malware that was found on the system.


Displaying a Fake EULA

Depending on the installation method, fake security software may or may not display an End User
License Agreement (EULA).

DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Exploit-based downloads: If the download was made using an exploit, the chances are the
rogue software will execute without the users knowledge.
User-initiated downloads: In cases where a re-direction attempt or spam email is involved; A
EULA may be displayed to make the delivery more believable. Remember, they have to build user
trust in order to get them to purchase their software and the intention here again is to pose as
legitimate software.



Although the EULAs have no significance with fake software, users may be able to identify fake
software because of the way they display EULAs. In the above screenshot, the fake software does not
display the EULA explicitly but simply provides a link. As you can tell, the intention is not to help
customers understand terms and conditions. The message is just bait for trusting users.

Well Designed Graphical User Interfaces

It must be noted that Fake Alert typically has very well designed Graphical User Interfaces. This is
another social engineering attempt to make their software look legitimate. The following is an
example of a post scan interface:






DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


At the end of the scan an Alert is displayed. The following are examples of the same:







Nonstop and Desperate Registration Requests

Even if a user closes any of the displayed windows, the rogue software continues executing in the
background, constantly displaying alerts that warn of active infections.

The only apparent alternative to activating the product is to stay unprotected or something
similar. This scare tactic attempts to make users anxious. With a sense of limited options and
constantly nagged by pop-ups, users sometimes believe their machines are vulnerable.

Fake products do not generally offer trial versions. Although its not always the case, most legitimate
software gives users at least a 10-day trial period. Rogue software will show users a list of
infections, but those applications always expect payment to clean them. Therefore, messages that
encourage users to activate the product are a common symptom.

The following screen images depict how a rogue product constantly reminds users of the importance
of product registration and the negative impact of not registering:



DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.








DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.




Balloon Messages

The following balloon messages are further examples of the constant reminders and scare tactics:









DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Typically after an infection, systems will slow down and become unusable for productive work. This is
another trick to make users believe they are infected.


FakeAlert Registration

Attempting to activate the product will launch a registration website in a browser. Here are a few
things to note about these websites:

The site will have very few sections and will be as simple as possible to make it look legitimate.
The common sections are often limited to:
o Home
o Features
o Purchase
o Company
o Screenshots
o Support

The websites will usually not have the following:
o Forums
o Career Links
o Search tabs
o Blogs

The site will host only one productthe rogue software.
The website will have no advertisements. Fake websites dont remain hosted for long. Either they
eventually get blacklisted, or they give the product a new name and register it under a new
domain. We never find them using a marketing model based on advertising.
Every page on the website will provide you an option to purchase their product.
Usually once you are on the purchasing page, the other linksfor example, Home, Features, or
Supportno longer appear. This is intentional. Giving customers fewer options will prevent them
from getting distracted and will focus them on purchasing the product.



DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.





Browser Hijacking

The following screen indicates an active infection. The fake software has already installed itself on the
victims machine. It attempts to hijack the users browsing and to induce fear by continuously
reminding the users to register the product. Legitimate software is never this intrusive.




Denial of Service to User Applications

On installation, FakeAlerts may prevent User applications from working as expected. They do so by
hijacking certain Windows Registry keys that associate applications based on Extension types.
Examples of such keys are:
o HKEY_CURRENT_USER\Software\Classes\.exe\shell\open\command
o HKEY_CLASSES_ROOT\.exe\shell\open\command
Other examples may include .doc, .xls associations.
By hijacking such keys, the FakeAlert may prevent normal user working by disabling applications
from running.






DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Fake Security Center Windows

The following two screens depict an original, legitimate configuration of Security Center in Windows
XP.

Without anti-virus software installed:




With anti-virusMcAfee VSE + Antispywareinstalled:





DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Now compare the above to the following two screens, which show a fake window generated by a
rogue security product. Note that the following two windows do not have the Microsoft Privacy
Statement displayed at the bottom of the window. Further, Microsoft Security Center does not make
recommendations on what brand of anti-virus software to use.

This Security Center pop-up in a fake product has the Resources section displaying
nonstandard information and making fake recommendations to register the product:



A Security Center pop-up in a fake product with a different setting:





DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Summary of Rogue Security Software Checklist

The presence of any of the following should warn users that they might have a fake product on their
systems.

Unknown icons on the desktop and start menu
AV-like scanner software with an interface that seems to report an unreasonably high number of
infections
AV-like scanner software that shows only infections but requires registration to clean the
infections
AV-like scanner software that has no trial period. Indications that the only way to clean your
machine is to register and pay for the software
Constant pop-ups, balloon messages, and other alerts that indicate an infection
Constant interruption of work due to the requests to register a product in spite of any user
requests to stay unprotected
Absence of a EULA. If there appears to be a EULA, no cancel option or the software installs
anyway.
Hijacking the browser while surfing
Preventing normal applications from working
Linking to a registration site that has no advertisements and sells only one productthe rogue
application. The website has only limited content and every page has a link that takes you to the
purchase page. From the purchase page there is no link to go to any other page.

Prevention and Mitigation

This section provides detailed steps to help prevent FakeAlert type viruses from infecting systems by utilizing
Access Protection (A component of McAfee VirusScan Enterprise). All current versions of VirusScan are
capable of the rules mentioned in this document (VirusScan Enterprise 8.5i, 8.7i, and 8.8i).

Prevention
FakeAlert families are known to be installed by other trojan downloader. These trojan usually arrive as email
attachments or by drive-by download attacks exploiting vulnerabilities in Windows and third-party
applications.

Users should be careful about suspicious email attachments
Users should apply latest security patches for Windows and applications including following:

Internet Explorer
Microsoft Office (Excel, Word, PowerPoint, etc.)
Adobe Reader
Java
Flash Player
RealPlayer
QuickTime

McAfee Labs updates signature everyday for recent variants of FakeAlert. Please ensure that you
keep current with DAT files.


Mitigation
This section gives a brief introduction on how to prevent being infected with fake or rogue security products.

Leveraging Access Protection
Access Protection rules give the flexibility to limit potential outbreak damage, even before a .DAT file is
issued. They also provide the ability to close ports, monitor applications and email engines, block files and
directories, and trace and block infection sources. Aside from pre-defined Access Protection rules,
Administrators will have the ability to create user-defined rules that are specific to the organization.


DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Methods of creating User-Defined Rules

File/Folder Blocking
File/Folder protection rules allow the administrator to prevent read access, write access, file execution, and
creation or deletion of files and folders. This feature can be very powerful in preventing intrusions, as well as
stopping viruses from spreading during an outbreak. Access restrictions will remain in place until the
administrator removes it.

Port Blocking
Port blocking rules will allow the administrator to block incoming or outgoing traffic on specified ports and
choose to log entries when attempts are made to access blocked ports. When a port is blocked, both
Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) accesses are blocked. Ports can
be blocked by creating rules to specify which port numbers to block and whether to restrict access to inbound
or outbound processes.

Exclusions can be made if the administrator wants a specific process, or list of processes, to be allowed
access to the otherwise blocked port. This can be very advantageous in an instance when a known virus
accesses the system using specified ports. However, use caution as legitimate applications may also need to
access the system on those same ports. To help counter a situation where a legitimate application needs
access but protection is required for unknown applications, an exclusion list may be used.


Registry Blocking
Registry-blocking protection rules prevent unauthorized programs from altering, creating, or deleting registry
keys and values that they shouldnt.


Pre-Defined Access Protection Rules

Anti-Virus Standard Protection

Prevent registry editor and Task manager from being disabled

Impact: If utilizing Group Policy to prevent access to Task Manager or Registry Editor to the
end user, then an exclusion must be made to allow modification to the registry (e.g.
gpupdate.exe would be the appropriate exclusion for Group Policy updates).
Benefits: This rule protects Windows registry entries to prevent the disabling of the registry
editor and Task Manager. Some variants of FakeAlert have been known to disable these in
order to complicate the cleaning process.

Prevent user rights policies from being altered

Impact: If utilizing Group Policy to modify end user account privileges, an exclusion must be
made to allow modification to the registry (e.g. gpupdate.exe would be the appropriate
exclusion for Group Policy updates).
Benefits: Many variants of FakeAlerts attempt to locate accounts on network systems that
have administrative rights. Enabling this rule prevents malicious code from modifying the
rights of users.

Prevent hijacking of .EXE and other executable extensions

Impact: This rule will have an impact if the administrator requires that an application run
alongside a specific file extension (e.g. an administrator would like a disclaimer to launch
when an executable .EXE is opened by a user).
Benefits: This rule protects the .EXE and other keys under HKEY_CLASSES_ROOT. Some
variants of FakeAlert alter these keys to ensure that the virus is run when any other
executable runs. Enabling this rule will prevent variants of FakeAlert from modifying
important operating system and executable files.


DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Prevent Windows Process spoofing
Impact: This rule can potentially block legitimate executables (e.g. if a file named
svch0st.exe vs. svchost.exe is launched AP will determine the svch0st.exe file to be malicious
and will be blocked due to the modified file name).
Benefits: Many variants of FakeAlert run using the name of a Windows process. This rule
prevents files from being created or executed with the most commonly spoofed names.


Example:



Anti-Virus Maximum Protection

Prevent altercation of all file extension registrations:

Systems running Microsoft Windows operating systems use a three- or four-letter identifier added to
file names after a period (.) to identify a file type. When a file is opened, the file extension is used to
decide what program should be used to open the file, or if the file is a program that should be run.
Variants of FakeAlert can modify the file extension registrations in such a way that execution of the
malicious code is silent. This rule prevents variants of FakeAlert from modifying the shell extension.

Impact: If enabled, disabling the rule or adding exclusions when installing legitimate software
that requires modification of extension registrations will be required (e.g. when installing
Microsoft Office the .docx file extension will be defaulted to Microsoft Word. In addition to
this, if a user would like to change the default application of a specific file type the rule would
need to be disabled).
Benefits: This is a stricter version of the Anti-virus Standard Protection: Prevent hijacking of
.EXE and other executable extensions rule. Instead of just protecting .EXE, .BAT, etc., it
protects all the extension options under HKEY_CLASSES_ROOT.














DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Example:




Common Standard Protection

Prevent installation of Browser Helper Objects and Shell Extensions:

Impact: If enabled, this may prevent Add-Ons from being installed. This is mostly going to
impact toolbars like Ask, Google, Yahoo, etc. Testing with approved Browser add-ons may be
required to determine appropriate exclusions.
Benefits: This rule prevents variants of FakeAlert from installing as Browser Helper Objects.
Browser Helper Objects are often utilized by FakeAlerts to redirect traffic to malicious sites.

Example:




Common Maximum Protection

Prevent programs registering to Autorun:

Impact: Many applications will create entries in the registry to launch the application upon
bootup. Testing will be required to determine which applications will need to launch on boot
(e.g. Applications like Adobe or HP printers will have an application to monitor when there is
a software update available to the user).

DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


Benefits: Most variants of FakeAlert attempt to register themselves in such a way that they
get loaded every time the system is booted. This rule is designed to prevent any process not
on the excluded list from registering processes that execute on every boot.

Example:




User Defined Access Protection Rules

File/Folder Blocking Rules (File actions to prevent new files being created):

Impact: This will prevent EXE, DLL, SYS file types from being created in the root of the
directories mentioned. Testing will be required before implementing these rules to ensure
there is no conflict with either software installations or general application functionality. This
is especially important for rules that block creation in temp directories (e.g. If you download
an application that writes to the root of the users temp directory then it will be prevented
from creation. Typically EXE, SYS, and DLL files are not placed in the root of Application Data
or Local Settings directories although this should be tested regardless to ensure there will be
no complications).
Benefit: Based off of behavioral characteristics of most FakeAlerts we have determined that
by blocking EXE, SYS, and DLL file extensions from the root of the Application Data/Local
Settings directories you can prevent FakeAlerts from infecting a system. Typically a startup
entry will be created to either launch the executables or will append the DLL/SYS file to a
legitimate Windows process (e.g. Rundll32.exe, WinLogon.exe, etc.).

User Defined Rules for Windows XP and Prior Operating Systems

C:\Documents and Settings\*\Local Settings\Application Data\*.exe
C:\Documents and Settings\*\Local Settings\Application Data\*.sys
C:\Documents and Settings\*\Local Settings\Application Data\*.dll
C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.exe
C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.sys
C:\DOCUME~1\*\LOCALS~1\APPLIC~1\*.dll
C:\Documents and Settings\*\Application Data\*.exe
C:\Documents and Settings\*\Application Data\*.sys
C:\Documents and Settings\*\Application Data\*.dll
C:\DOCUME~1\*\APPLIC~1\*.exe
C:\DOCUME~1\*\APPLIC~1\*.sys
C:\DOCUME~1\*\APPLIC~1\*.dll
C:\Documents and Settings\*\Local Settings\temp\*.exe
C:\Documents and Settings\*\Local Settings\temp\*.sys
C:\Documents and Settings\*\Local Settings\temp\*.dll
DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


C:\DOCUME~1\*\LOCALS~1\TEMP\*.exe
C:\DOCUME~1\*\LOCALS~1\TEMP\*.sys
C:\DOCUME~1\*\LOCALS~1\TEMP\*.dll

Examples:





DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.





User Defined Rules for post Windows Vista Operating Systems

C:\Users\*\AppData\local\*.exe
C:\Users\*\AppData\local\*.sys
C:\Users\*\AppData\local\*.dll
C:\Users\*\AppData\Roaming\*.exe
C:\Users\*\AppData\Roaming\*.sys
C:\Users\*\AppData\Roaming\*.dll


DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.







Blocking and Reporting
DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.



Blocking
This will block files, folders, ports, and/or registry entries based off of the criteria you have selected
pertaining to each individual rule:

File/Folder Blocking
Read access to filesBlock read access to the specified files
Write access to filesBlock write access to the specified files
Files being executedBlock files from being executed in the specified folder
New files being createdBlock new files from being created in the specified folder
Files being deletedBlock files from being deleted from the specified folder
Port Blocking
Rule nameType the name for this rule
Processes to includeRestrict access to the specified ports
Processes to excludeAllow access to the specified ports
Starting portSpecify the first port number. This can be a single port or the starting
number of a range of ports.
Ending portSpecify the last port number in a range of ports
InboundPrevent systems on the network from accessing the specified ports
OutboundPrevent local processes from accessing the specified ports on the network

Registry Blocking
Rule nameSpecify the name for this rule
Processes to includeRestrict these processes from access. Wildcards are allowed.
Processes to excludeAllow access to these processes. Wildcards are allowed.
Registry key or value to protectProtect this registry key or value

Reporting
When enabling a specific Access Protection rule to report a log of violations will be created within the
default logging directory. This can not only be helpful to the administrator but to the McAfee Support
Representative as well. For administrators these logs will help determine appropriate exclusions for
the Access Protection rules implemented. This will also be beneficial when determining the method at
which the malware infected the machine. To access the logs navigate to the %VSEDEFLOGDIR%
directory.

Threat Isolation and Sample Submission
If there are systems within the environment that exhibit symptoms of FakeAlert you will want to first ensure
the following:

You have the latest Microsoft Security updates installed
VirusScan Enterprise is utilizing the latest DAT definition files


Additional Scanners and Resources
McAfee offers additional scanning options in the event that either Pre-Boot scanning or custom tailored
Stinger utilities are necessary:

McAfee Stinger
Stinger is a standalone light weight utility used to detect and remove specific viruses. It is not a
substitute for full anti-virus protection, but rather a tool to assist administrators and users when
dealing with an infected system in particular, FakeAlerts. Stinger utilizes next generation scan engine
technology, including process scanning, digitally signed DAT files, and scan performance
optimizations.

FakeAlert Stinger
http://www.mcafee.com/us/downloads/free-tools/fake-alert-stinger.aspx

Command Line Scanner
McAfee CLS is used for various purposes including but not limited to:
Scanning a computer before installing VirusScan to ensure it is clean.
When a workstation has been infected and you are unable to load the VirusScan Console.
DISCLAIMER: It is recommended that extensive testing be performed prior to pushing out any Access Protection rules to your
production environment. Each rule will contain a section discussing the potential impact. While these rules can be beneficial from a
security perspective some are a tradeoff for convenience.


When VirusScan Enterprise (VSE) does not install successfully.

Certain aggressive signatures may take some time to go through our Quality Assurance cycles. In
such cases even though our DAT may have the signature available, they are exposed to a restricted
set of products. CLS is one such product that may have access to our most up to date signatures.
Thus, it is recommended to utilize the CLS as an option to scan infected systems since a number of
new and aggressive signatures are made available to it.

KB51141 - How to perform a command-line scan in Microsoft Windows
https://kc.mcafee.com/corporate/index?page=content&id=KB51141

Obtaining and Submitting Suspicious Files
The following KnowledgeBase article contains instructions for manual sample collection:

KB53094 - Troubleshooting procedure for finding possible infected files
https://kc.mcafee.com/corporate/index?page=content&id=KB53094

Once suspicious files have been discovered they will need to be submitted. The following article
contains a step-by-step procedure for sample submission:

KB68030 - How to submit samples to McAfee Labs
https://kc.mcafee.com/corporate/index?page=content&id=KB68030&actp=search&viewlocale
=en_US&searchid=1308006042707

Recommendations for Deployment

When creating or deploying Access Protection rules in your environment or utilizing additional tools
such as Stinger and CLS, it is always recommended that users carry out a slow start deployment.
Please start with a few non-critical nodes to ensure you have a good estimate and measure of any
potential impacts. In case of Access Protection Rules, you may start with rule creation in reporting
mode first, followed by monitoring Logs. This should allow you to understand potential risks if any
that may be related to a full scale deployment.

Getting Help from the McAfee Foundstone Services team
This document is intended to provide a summary of current intelligence and best practices to ensure the
highest level of protection from your McAfee security solution. The McAfee Foundstone Services team offers a
full range of strategic and technical consulting services that can further help to ensure you identify security
risk and build effective solutions to remediate security vulnerabilities.
You can reach them here: https://secure.mcafee.com/apps/services/services-contact.aspx
2011 McAfee, Inc. All rights reserved.