Jul 20, 2011 - HKEY_CURRENT_USER\Software\Classes\.exe\shell\open\command o .... (e.g. Applications like Adobe or HP pri
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 product1. 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:
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. 1
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 user’s 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 it’s 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 product—the rogue software. The website will have no advertisements. Fake websites don’t 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 links—for example, Home, Features, or Support—no 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 victim’s machine. It attempts to hijack the user’s 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-virus—McAfee VSE + Antispyware—installed:
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 product—the 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 shouldn’t. Pre-Defined Access Protection Rules Anti-Virus Standard Protection
Prevent registry editor and Task manager from being disabled
Prevent user rights policies from being altered
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.
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 files—Block read access to the specified files Write access to files—Block write access to the specified files Files being executed—Block files from being executed in the specified folder New files being created—Block new files from being created in the specified folder Files being deleted—Block files from being deleted from the specified folder Port Blocking Rule name—Type the name for this rule Processes to include—Restrict access to the specified ports Processes to exclude—Allow access to the specified ports Starting port—Specify the first port number. This can be a single port or the starting number of a range of ports. Ending port—Specify the last port number in a range of ports Inbound—Prevent systems on the network from accessing the specified ports Outbound—Prevent local processes from accessing the specified ports on the network Registry Blocking Rule name—Specify the name for this rule Processes to include—Restrict these processes from access. Wildcards are allowed. Processes to exclude—Allow access to these processes. Wildcards are allowed. Registry key or value to protect—Protect 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.
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.