Category Archives: McAfee

  • 0

McAfee and Amazon Web Services: A Secure Relationship

Category : McAfee

As enterprises continue their journey to the cloud, many are using a hybrid model that engages both the private and public cloud.  McAfee has embraced this “hybrid cloud” strategy to enable companies to migrate to the public cloud, and we are investing in the tools and relationships to enable the transition. Working with Amazon Web Services (AWS) is an important part of bringing enterprise-level security to public cloud deployments, and I’m happy to announce two new partner relationships with AWS. Also, McAfee will be joining AWS at the AWS re:Invent Expo in Las Vegas in late November, where we will demonstrate products that customers can use in their hybrid cloud strategy.

McAfee is Now an APN Advanced Technology Partner

For enterprise engagements, McAfee has become an Amazon Partner Network (APN) Advanced Technology Partner. To become an APN Advanced Technology Partner we have demonstrated that our products, customer relationships, expertise and overall business investments on AWS have grown and are meaningful to AWS.

McAfee builds tools that automate the rollout of security controls and security operations consistently across organizations. Our solutions — such as Virtual Network Security Platform, Cloud Workload Security, and Web Gateway — can play significant roles in helping companies adopt AWS securely:

McAfee Virtual Network Security Platform (vNSP): Designed specifically for fully virtualized public and private clouds, vNSP delivers an elastic security control that provides comprehensive network inline intrusion prevention, application protection, zero-day threat detection and visibility into lateral attack movement. The scalable and highly distributed architecture has been certified as “Well Architected” by Amazon. Integration with orchestration and automation frameworks makes this an ideal solution for adoption in DevSecOps environments.

McAfee Cloud Workload Security (CWS): As data center parameters get redefined, the ability to navigate current datacenter workload assets and plot the journey to the cloud requires a map that will safely show the way. Cloud Workload Security provides visibility and protection for your workloads in the cloud with agility and confidence through an integrated suite of security technologies, ensuring control of new parameters.

McAfee Web Gateway (MWG)With its best-in-class malware protection efficacy and policy flexibility, we now have the ability to deploy MWG directly in AWS. This is in addition to the appliance model and SaaS deployment model. MWG boasts the most flexible options in the industry for Web security. With an AWS deployment, customers can not only offload workload from on-premise appliances through hybrid policy enforcement, they can also provide advanced in-line malware detection for SaaS-based apps. This is the same value proposition that McAfee has historically offered for endpoint protection, but we are now able to offer it for SaaS-based applications as well.

To learn more about our solutions that keep you better protected on AWS, visit

McAfee Accepted into the AWS Public Sector Partner Program

In addition to the commercial sector, McAfee knows that Government, Education and Nonprofit customers need quality security in the cloud. AWS has accepted McAfee into its AWS Public Sector Partner Program. This designation reflects McAfee’s strong commitment to support public sector customers in their transition to the cloud. As our presence in the AWS Public Sector Partner Program grows, so too will the value of our solutions specifically targeted for the public sector.

McAfee is a Sponsor at AWS re:Invent

Join us the week of November 27th at the AWS re:Invent event in Las Vegas. Visit the McAfee (Booth 1238) at the Venetian. McAfee experts will share strategies and best practices to help customers secure and manage data on AWS. Plus, you can see live how McAfee vNSP expands network protection across virtualized environments.


Author: Raja Patel

  • 0

New Android Malware Found in 144 GooglePlay Apps

Category : McAfee

McAfee’s Mobile Research team has found a new Android malware in 144 “Trojanized” applications on Google Play. We named this threat Grabos because we found this string in several elements of the code, including variable and method names. Grabos was initially found in the Android application “Aristotle Music audio player 2017,” which claimed to be a free audio player on Google Play:

Figure 1. Trojanized music app in Google Play.

At the time Aristotle Music was discovered, the application had a very good rating. According to Google Play, the application was installed between one and five million times and had a recent comment from a user saying that the application was detected as malware:

Figure 2. User reporting the application Aristotle Music being detected as malware.

Grabos on Google Play

McAfee Mobile Research notified Google about Grabos in September and confirmed that Google promptly removed the reported application. After further research, we found another 143 applications (see complete list at the end of this post); all have been removed from Google Play. Six were removed after we reported the first to Google:

Figure 3. Additional Grabos Trojanized apps formerly on Google Play.

At the time of writing this post, 34 applications still had their webpages available in cache, so we were able to obtain additional information such as the approximate number of installs, last updated date, and rating. Most of these apps were last updated in August and October. They had an average rating of 4.4, and between 4.2 million and 17.4 million users downloaded these apps from Google Play:

Figure 4. Malicious apps details from Google Play.

Grabos likely evaded Google Play security measures because the injected code is protected with a commercial obfuscator, making it very difficult to statically analyze without executing the application. Even dynamic analysis to stop its execution is difficult without knowing what the app is checking. However, once we unpacked the code, we proceeded with our analysis.

“Fake” vs. “real” apps

We found Grabos injected in file explorer and music player applications, some of them open source. Every time that the app is opened, it checks if any of the following settings is not true to decide whether to launch the “fake” (legitimate functionality) or “real” (injected packed code) app:

  • isOnline: Checks if the device has Internet connectivity
  • getIsBlacklisted: Checks if the Android debug bridge (adb) and development settings are enabled or if the device is in an emulator. If the latter is the case, the device is blacklisted and the “fake” app is launched.
  • getIsForcedBlacklisted: Flag set by the control server.

The code also has a test mode that allows the execution of the “real” app in case it is running in an emulator or has adb and development settings enabled. These checks detect if the app is currently being dynamically analyzed and prevent the execution of the hidden code if necessary.

In case the app is not being analyzed or is in test mode, the “real” app launches. This hidden music downloader searches for a specific song on YouTube. Once the song is selected, it can be downloaded in MP3 or MP4 format to be played offline.

Figure 5. “Fake” vs “real” app flow. “BL” stands for “blacklisted.”

At this point, the application seems to be just a music downloader hidden in a Trojanized app that checks for dynamic analysis to avoid being removed from Google Play due to its downloading of copyrighted music. In the background, however, more is happening.

Communicating with the Control Server

In addition to the “fake” and “real” app functionality, Grabos is also present in the AndroidManifest as a receiver that executes every time there is a connectivity change or when the app is installed:

Figure 6. Grabos receiver in the AndroidManifest.

If the receiver is executed due to a connectivity change, the execution ends if the device is offline or if fewer than five seconds have passed since the last connection. If more than five seconds have already passed, the method “updateRemoteSettingsSynchronousTask” executes. This method collects and encrypts (Base64 plus Advanced Encryption Standard) the following data from the infected device:

  • Device information:
    • android_version
    • build_model
    • install_referrer
    • network_country
    • sim_country
    • carrier_name
    • language_code
    • country_code
    • time_timezone
  • Device location: Grabos uses free IP geolocation API services to obtain IP address information such as city, country code, ISP, organization, region, and ZIP code.
  • Device configuration:
    • is_emulator
    • is_rooted
    • is_adb_enabled
    • is_dev_settings_enabled
    • allow_mock_location
    • allow_non_market (unknown sources enabled/disabled)
    • is_vpn_connected
    • dp checks (additional root, debug, and emulator checks provided by the commercial obfuscator)
  • Installed Grabos app information: version_code, package_name, and install_time
  • Specific apps installed: Grabos reports if any app in a predefined list is currently installed on the infected device (more on this later).

All the information is encrypted and submitted to a control server. The remote server responds with encrypted data that contains parameters required to download music (URLs, API keys, user agents, client_id, etc.) to show advertainments (nativead_id, interstitial_id, banner_id, etc.) and display customized notifications such as asking the user to rate the app in Google Play:

Figure 7. “Rate this app” parameters provided by the control server.

The rating pop-up appears the first time the app is opened. If the button “Rate 5 Stars” is clicked, the app opens in Google Play so the user can rate the app there.

Figure 8. Rating pop-up.

In a similar way, the remote server also provides parameters to ask the user to share the app with friends and promising faster download speeds:

Figure 9. “Share the app” parameters provided by the control server.

The control server also sends the parameter “is_forced_blacklisted,” which manually blacklists the device if the value is “true”—to prevent the execution of the hidden app.

Mysterious functionality

In addition to reporting an infected device’s location and configuration, Grabos checks if specific social and Google apps are installed using the method isPackageInstalled and the app package name. Depending whether an app is currently installed, the corresponding value is set to true or false and that information is encrypted and reported to the control server:

Figure 10. Social and Google apps reported to the control server.

We reported this finding to Google, who are investigating. At this point we do not know the purpose of this app reporting. However, we believe this information could be very useful to malware authors because Grabos has implemented several mechanisms to trick users into installing applications provided by the remote server. Let’s look into those functions.

Custom Push Notifications and Additional Apps

After the initial settings are obtained from the remote server, the AsyncTask ShowNotificationIfNeeded is executed to check if the parameters n_title, n_description, and n_package were provided by the control server. If that is the case, Grabos checks if the app is available on Google Play (if “pack” is a name and not a URL) or on a remote server (if “pack” starts with HTTP).

If the application is not installed and is available, Grabos gathers additional parameters (for example, icon and bigicon) from the remote server response to create a custom notification and trick the user into installing the app:

Figure 11. Parameters provided by the control server to create a custom notification.

Grabos also checks if the remote server provided the following parameters:

  • interstitial_letang_options: provides values to delay and repeat the display of an activity (initial_delay and min_interval)
  • interstitial_letang: includes the following remote commands:
    • admob: executes method “showAdmobInterstitial”
    • nothing
    • grabos_direct

If the command is grabos_direct, Grabos gets the title, package, and max_times_shown values in the parameter grabos_direct_interstitial to open the app in Google Play or trigger a download:

Figure 12. Downloading an APK from a URL or open app on Google Play.

Both the notification and the interstitial_letang methods, to trick the user into downloading or installing apps, are executed in the background every time there is a connectivity change. However, Grabos also implements another app delivery method when the music downloader executes. This method, ShowGrabosIfNeeded, is very similar to interstitial_letang in that it checks if the required parameters are present and the app is available as well as checking if the app should be opened without the user’s consent:

Figure 13. Grabos checking whether the installed app should be opened.

As soon as Grabos confirms that the device is online, the app is available either on Google Play or a remote server, and the package is not installed, the malware gets the following parameters from the remote server response to create an AlertDialog and trick the user into downloading another app:

Figure 14. Grabos parameters to create an AlertDialog.

Flying Under the Radar: Evading Analysis

In addition to the multiple efforts to detect if the app is being dynamically analyzed (emulator, adb, development settings) and the encryption of the injected code, Grabos updates its remote settings every 24 hours (unless it is in test mode). This restriction can be easily bypassed by changing the date and time of the device used to analyze the app. However, recent versions of Grabos include checks to detect if the automatic date and time and time zone are enabled:

Figure 15. Grabos checks if automatic date and time and time zone are enabled.

The status of this setting is reported to the control server in the fields time_is_auto and time_timezone_is_auto. Although this check is not used in the Grabos code, the information could be used to determine if the app is being dynamically analyzed and decide if an additional payload should be delivered.

The URLs used as control servers indicate that Grabos tries to masquerade its network traffic as legitimate. At first sight the URLs appear to belong to familiar adware companies; the names are identical. However, instead of finishing with .com, Grabos uses domains such as .link and .click, which are not registered by the company.

Finally, Grabos defines an additional mechanism, currently not implemented, to blacklist or whitelist a specific device. For example, the device could be blacklisted or whitelisted in a future version depending on the country code or configured language of the infected device:

Figure 16. Blacklist and whitelist functions based on language and country code.

Grabos also defines (but does not implement) methods to blacklist a device based on IP address:

Figure 17. Blacklist functions based on IP address information.


During our analysis of this threat, the control servers always provided empty parameters for the custom notifications to trick users into installing applications. Taking into account the functionality to display ads and the high number of downloads, we believe the main purpose of Grabos is to make money by promoting the installation of apps.

Grabos gained popularity on Google Play because it allowed users to download music for free while constantly asking them to rate the app. However, users were not aware of the hidden functionality that comes with those apps, exposing them to custom notifications to download and install additional apps and open them without their consent.

Considering that Grabos also reports the presence of specific social and Google apps on infected devices, cybercriminals could use that information to deliver additional apps by tricking users into installing them using any of the notification methods implemented in the code. Although during our analysis the remote servers did not deliver the required parameters to trigger custom notifications, the devices remain exposed to the download of additional Android apps.

McAfee Mobile Security detects this threat as Android/Grabos. To protect yourselves from threats like this on Google Play, employ security software on your mobile devices, check user reviews, and avoid installing suspicious apps with screenshots or functionality that do not correspond to the name of the app.

We would like to thank Sebastian Porst and Jason Woloz from Google’s Android Security for their helpful contributions on this research.

List of Grabos Package Names

  • com.picklieapps.player
  • com.musicaplayer.stonetemples
  • com.mp3musicplayer.playmusicmp3
  • com.densebutter.musicplayer
  • com.airplaneapps.soundmeter
  • com.dinosaursr.musicplayer
  • com.tenuousllc.humneate
  • com.astropie.musicplayer
  • info.chargeshoes.videoplayer
  • com.callsaver.doubtful
  • com.unfestenedsail.freeapp
  • com.extendmilk.freeplayer
  • com.excellentlossapps.playermusic
  • com.mp3player.musicplayer.freelocalmusicplayer
  • com.afromusicplayer.fremediaplayer
  • com.info_astro.glider_player
  • com.illfatednotice.humdrum
  • com.headybowl.musicplayer
  • com.naturityllc.mp3player
  • com.startdancingapps.callrecorder
  • com.sportingapps.copyleft_music.player
  • com.auto_call_recorder.freeapp
  • com.freenewsreader.rssfeed
  • com.mp3musicplayer.local_files_player
  • com.nobodybeats.musicplayer
  • com.file.manager.pronessbest
  • com.aneeoboapps.playlistmanager
  • com.local_music_player.free_mp3_player
  • com.greenlinellc.voicechanger
  • com.toporganizer.fileorganizer
  • com.thumb.webbrowse
  • com.aspirator.ringtones.player
  • com.freevideoplayer.musicplayer
  • com.vimfast.videodl
  • com.truckneat.freeapp
  • com.crowdedarmy.volume.controller
  • com.arnold_legal.mp3.musica
  • com.descent.shutterfly
  • com.thankyou.arrowplayer
  • com.pocahantasapps.musicplayer
  • com.astroplayer.freee
  • com.couchpotato.musica.play_stream
  • com.abstractly.musica.player
  • com.matsumoto.mp3player
  • com.musicequalizer.freeequalizer
  • com.lifesbad.fileexplorer
  • com.streamerplayer.stream_videos
  • info.voicerecorder.recordvoice
  • com.snip.browser
  • com.checkrein.musicapp
  • com.mp3musicplayer.freemusicplayer.playmusic
  • com.jadedprogram.mp3player
  • com.preoral.freeborn
  • com.voice.changer.freeappsapp
  • com.localmp3music.freeplayer
  • com.drummachine.machinedrums
  • com.coloringbook.freetrynow
  • com.videodownloader.social_video_download
  • com.ElephantApps.FileManager
  • com.rooseveltisland.mp3player
  • com.mindprogram.musicf
  • com.freeborn.sdkintegration
  • com.koseapps.tubemusica
  • info.adeptly.forgoneapp
  • com.miniaturef.swanky
  • com.anchor.musicplayer
  • com.repeate.mp3musicplayer
  • com.FeisalLLC.MusicPlayer
  • com.shelfshare.freeapp
  • info.simple.streamer.player
  • com.streamplayer.freearnold
  • com.cowherd.freeapp
  • com.localmp3musicplayer.local_player
  • com.scaricare.apps.musica
  • com.silymove.freeapp
  • com.pinkphone.funfreetube
  • info.tissuepaper.freemusic
  • com.chopsuey.musicplayer
  • com.branchnotice.musicplayer
  • com.fradcip.MasterApp
  • com.spelldoom.comeup
  • com.bailymusic.player
  • com.sportifco.musicplayer
  • com.coupleweeks.modcium
  • com.unbecomingllc.videodownloader
  • com.macdrop.apptool
  • com.callsaver.recorderfreeapp
  • com.arnie_legal.mp3.musica
  • com.kikiapps.freeplayer
  • com.pintaapps.expensetracker
  • com.marble.musicequalizer
  • com.artproject.searcher
  • com.UnitTest.FreeApp
  • com.exudedplayer.freemusicplayer
  • com.blackballed.player
  • com.mp3player.decisiveapps
  • com.rusticd.musicplayer
  • com.byunhyeong.jungfree
  • com.voicelessapps.mp3musicplayer
  • com.localmp3player.freeplayer
  • com.socialvideo.downloader_vim
  • com.disarmbit.reache
  • com.crackerbalancellc.mp3converter
  • info.vaskollc.jpfree
  • com.freemusicplayer.musicplayfreetoolpalyer
  • com.combustionapps.musique
  • com.arnold.mp3.musica
  • com.purpleheadphones.audioplayer
  • com.freefile.organizerfree
  • com.mp3uncle.musiccamera


Author: Carlos Castillo

  • 0

Self-Signed Certificates Can Be Secure, So Why Ban Them?

Category : McAfee

In many organizations the use of self-signed certificates is forbidden by policy. Organizations may ban the use of self-signed certificates for several reasons: It is trivially easy to generate a certificate’s key pair without reasonable entropy, to fail protect the private key of the key pair appropriately to its use, to poorly validate the certificate when used, and to misuse a self-signed certificate when a certificate authority should have been used instead. However, when properly and appropriately used, a self-signed certificate provides acceptable security in some situations.

There is a broadly held misunderstanding that self-signed certificates are inherently bad security. We offer this explanation to expand your understanding of certificate use. At the same time, we explain the circumstances under which McAfee’s use of a self-signed certificate in one of our products provides adequate security for our customers.

For many uses of public key infrastructure (PKI), the correct method for signing a certificate is to use a well-known, trusted third party, a certificate authority (CA). “In a CA-based PKI system, the CA must be trusted by both parties. This is usually accomplished by placing the CA certificates in a whitelist of trusted certificates,” says Wikipedia.

Indeed, self-signed certificates have several key limitations. Most important among these are:

  • Self-signed certificates cannot be revoked.
  • Self-signed certificates never expire.

However, there are cases for which a self-signed certificate may be sufficient, and perhaps a better choice than a certificate that has been signed by a CA.

In a public key infrastructure, in which parties to a communication are unknown to each other (and thus untrusted), the limitations of self-signed certificates presented above are important.

Consider browser-to-website connections. Users, via the browser, must ensure that the site to which they are connecting is indeed the intended site. In this case, having a trusted third party, the CA, is critical to validate that the web server in the connection is the one for which the certificate has been issued.

Establishing website-to-browser identity is the standard certificate use that transport layer security (TLS) pre-encryption authentication employs as well as the typical example for the use of certificates in general. This use case is also the driver for many organizational security policies in which the use of self-signed certificates is forbidden.

In the case where both sides of the communication know each other—often within the same entity—self-signing limitations become advantages. In this case, we can think of the certificate as a credential used to identify a particular entity to itself. This case is not entirely the same as attempting to establish trust between unknown parties.

In fact, when a certificate is used between two components in the same entity—that is, both sides are establishing that the other side is the one, intended component—the certificate is a form of shared secret, like a rather complex password.

In this case, there is no need for a third party to act as a root of trust. All that is required is that the key pair match—or, more precisely, that the public key can be used to verify that the certificate was signed with its private key mate (often called certificate pinning). Any public/private key pair will perform this function; an X.509 certificate happens to be a convenient and well understood “package” for the interaction.

The preceding self-signed use case presupposes that the private key of the certificate’s key pair has been and will continue to be protected with great care, similar to any important credential. One of the advantages of using an X.509 certificate for authentication is that the private key need not be installed (and thus is highly protected!) along with the certificate. The private key is used to generate the certificate. After generation, the private key is no longer needed to validate the certificate; only the public key is required.

Of course, a certificate when used as a credential requires sufficient protection, just as with any form of credential. Still, without the private key, the certificate becomes a one-of-a-kind credential; it can be reused if stolen, but it cannot be regenerated without access to the private key.

A self-signed certificate used for intercomponent authentication for TLS must be protected so that the likelihood of theft is very low. At McAfee, we provide layers of self-protection against the theft and reuse of products authentication certificates.

X.509 is nearly ubiquitous and has a great deal of programming and processing support. Hence, it is faster to deliver authentication based upon certificates than to build alternate software to validate key pairs. Besides, in the case of TLS, the protocol specifies X.509 certificates; certificates must be used to take advantage of TLS’ built-in authentication mechanism.

Because a self-signed certificate cannot be revoked and it does not expire, this reduces update and patching complexities in a connection between components built by the same entity and intended to be used solely within that closed context. However, to replace a certificate, for whatever reason, requires a software update because each self-signed certificate is the credential, rather than relying on trust of a certificate authority.

If the self-signed certificate’s private key were to become compromised in some manner, software could be updated with a new set of certificates and new keys. The compromised certificate would be tossed out, removed from service because it could not be used to establish trust between the parties. Because the old certificate is self-signed, it also will not work for other uses, such as the TLS server-side authentication we have described.

Essentially, once removed from its intended use, a self-signed certificate is useless to any party, malicious or otherwise.

At McAfee, we take our customer’s security seriously. We analyze each cryptography case carefully to identify the best solution that will help to ensure our customers continued protection. The use of self-signed certificates in McAfee products is appropriate to the use to which the self-signed certificate has been applied.


Author: Brook Schoenfield and Ramnath Venugopalan

  • 0

Expiro Malware Is Back and Even Harder to Remove

Category : McAfee

File infector malware adds malicious code to current files. This makes removal tricky because deleting infections results in the loss of legitimate files. Although file infectors were more popular in the 1990s and early 2000s, they still pose a significant threat. The complex disinfection process is usually leveraged by malware authors to ensure systems stay infected for a long period. This may explain why complex file infectors such as W32/VirRansom, W32/Sality, W32/Xpaj, and Expiro are still active today.

The Expiro virus is has been around for more than a decade, and the authors continue to update it with more features. Expiro is unique in that it infiltrates executable files on both 32- and 64-bit Windows systems by appending its viral code to the host. It can be used to install malicious browser extensions, lower browser security settings, and steal account credentials.

Recently we discovered a new variant of Expiro with a significant change in its infection routine. In previous variants, Expiro modified and stole code at the entry point and appended the viral payload only at the end of the original file, typical of an appender virus.

The new variant, however, changes the size of the base relocation table and encrypts the addresses inside, causing traditional appender virus repair routines to corrupt files unless they correctly restore the original base relocation table. By adding the encryption, Expiro increases the complexity of analysis and requires a customized repair routine, which makes it hard to combat.

The following screenshots demonstrate this point: The base relocation table of a file infected by the old variant of Expiro is unaffected and the contents are untouched.

Figure 1: The relocation table remains intact when infected by the old Expiro variant.

Figure 2: The relocation table contents are not modified by the old Expiro variant.

The new variant reduces the size of the base relocation table and encrypts portions of it (outlined in red).

Figure 3: The latest Expiro variant reduces the size of the relocation table.

Figure 4: The relocation table encrypted by the latest Expiro variant.

To fix relocations prior to the execution of the original file’s code, the Expiro virus first executes its own malicious payload. It then decrypts the relocation table and dynamically reloads all addresses to make sure the original file can run correctly.

Decryption involves a simple XOR operation with a key hardcoded within the sample.

Figure 5: Relocation table being decrypted using a hardcoded XOR key.

After the decryption, the rest of original base relocation table is recovered.

Figure 6: The EDI register now contains decrypted relocation data.

In recovery step 2, Expiro computes the address that contains the relocation address using the formula Relocation_Address = NewImageBase + Offset + VirtualAddress.

Figure 7: Calculation of the address to be relocated in Expiro’s code.

As we see in the following screenshot, the formula leads to Relocation_Address = 0x950000 + 0x354 + 0x1000, so the address in 0x951354 should be relocated (stored in eax).

Figure 8: Relocation address being calculated.

In recovery step 3, Expiro computes the relocation value using the formula Relocation_Value = OldValue + (NewImageBase – OldImagebase).

Figure 9: Relocation value being computed by Expiro.

In this case, the formula is Relocation _Value = 0x01001354 + (0x00950000 – 0x01000000), so the relocation value is 0x00951354.

Figure 10: Expiro performing relocations on its own.

Using this technique, we can decrypt and repair the entire relocation table of the files infected by Expiro. This also helps us to calculate and replace the relocation table size in an executable’s optional header with the correct values. These changes ensure the infected files can run properly after removing the malicious payload.


McAfee products detect Expiro as W32/Expiro.gen.rd and W64/Expiro.d and repair infected files from DAT Version 8665. Users can find additional information at this McAfee Labs Threat Advisory.

SHA-256 hash

  • f15b8fc3ca117ab38e3074adc6208666b2189259e447db8202ef85b9bbfc4537


Author: Xiaobing Lin

  • 0

Code Execution Technique Takes Advantage of Dynamic Data Exchange

Category : McAfee

Email phishing campaigns are a popular social engineering technique among hackers. The idea is simple: Craft an email that looks enticing to users and convince them to click on a malicious link or open a malicious attachment. Weight-loss and other health-related phishing emails are common. Package deliveries, bank notices and, in the case of spear phishing, even emails from your coworkers can contain malicious links or documents. With new research related to old Microsoft Office technologies, hackers have found new techniques that makes phishing all that more effective.

Microsoft’s Dynamic Data Exchange (DDE) has been around since 1987. Its purpose is to facilitate data transfers between applications that do not require ongoing user interaction. For example, if you have an item in a document that needs to have up-to-date data from an external source such as financial data, you can use DDE to kick start a process to collect that information. In Word, this could update charts and graphs of your financial data every time you open the document. Its functionality has been superseded by other technologies, notably Object Linking and Embedding (OLE), released in 1990, but due to compatibility reasons DDE is still supported by current Windows versions and Office products. (Microsoft advises that you disable DDE.)

On August 23 SensePost told Microsoft what they saw to be a security concern, if not a vulnerability, in the behavior of DDE. Microsoft determined that DDE behaved as expected and that the issue would be considered for a next-version candidate bug. On September 10 SensePost reported their findings.

The holy grail of phishing is to get arbitrary code execution on the target box. Once attackers can execute code, the hard part is done. At this stage they can load any malicious code on the target box to steal data or hold it for ransom. The Necurs botnet, which delivers the notorious Locky ransomware, has implemented a DDE-based phishing attack. Necurs delivers crafted Word documents, using the DDE protocol upon loading, that infect systems with Locky. (For more technical details on the Necurs botnet please refer to the McAfee Labs Threat Report, June 2017.)

Exploiting DDE for code execution is relatively simple. Attackers insert a calculated field and change the field codes to proper DDE syntax. They can use the DDEAUTO or DDE field identifier to launch executables. A proof of concept shows PowerShell giving an attacker a lot of control. The user is presented with two messages. The first appears innocuous: “This document contains links that may refer to other files. Do you want to update this document with the data from the linked files?” The second message, which hopefully raises more suspicion, identifies the executable being called. However, attackers have some control over this message and may be able to reduce suspicion by changing how they launch the executable. At this time, the user must click “Yes” on both pop-ups for the attack to succeed.

Not only Word documents support this technique. Researchers have shown that Outlook Calendar invites can be crafted to exploit the DDE code execution technique, removing the need to attach a malicious file. An Outlook attack can begin when users merely open their invites.

Attackers are always innovating to trick users and bypass protections. Even old technologies can play a role in new attack techniques. It is important to educate your users on phishing attempts and to pay attention to security messages asking for access to system resources. With the simplicity of this technique and quick adoption from large malware players, we can assume that many new phishing campaigns will implement DDE for initial code execution, delivering both known malware, such as Locky, and new malware to the victims.

For technical details, see “Configuring McAfee ENS and VSE to Prevent Macroless Code Execution in Office Apps.”


Author: Charles McFarland

  • 0

Ransomware Decryption Framework – Now Available

Category : McAfee

How do I get my files back?  This is probably the first question asked when ransomware strikes. Of course, the answer will depend on whether there is a backup available. Or if a decryption tool exists on the website.

Developing these tools invariably involve significant effort to identify the decryption keys, but also create a tool that can be tested, hosted and then made freely available to help victims of ransomware. Today however we are pleased to announce the availability of McAfee Ransomware Recover (Mr 2), this framework will allow for the rapid incorporation of decryption keys and custom decryption logic (when they become available) and get help to victims of ransomware a lot quicker.

Now, whilst the availability of a framework is important its probably not something you would say deserves the fanfare of the communications we have produced. However, the key difference here is that this framework is free to use for the security community. So if security researchers have identified decryption keys and custom decryption logic for a ransomware variant, and do not want to spend the time to produce their own tool then McAfee Ransomware Recover (Mr 2) is available to freely use.

Over the course of the next few weeks we will produce more guidance on the tool, including webcasts by the development team. Also, we will remain committed to working with our public and private sector partners to get our hands on as many decryption keys as possible.


Author: Raj Samani


  • 0

Go with the flow! Automating and streamlining workflows with OpenDXL

Category : McAfee

Date: Wednesday, October 11, 2017
Time: 3:00PM BST | 4:00PM CEST

We all need some time hacks to help us get more done in our days. We need technologies that work together for faster detection and remediation. Programmatic workflows can help by automating repetitive and time sensitive tasks, as well as sharing intelligence from disparate sources.

Automating IOC ingestion using OpenDXL can tell more than just where those IOCs live in your environment. Integrating with McAfee Threat Intelligence Exchange (TIE) enables faster action across your environment. And integration with McAfee Active Response (MAR) enables automated searches that result in faster remediation.

Join McAfee OpenDXL Developer Advocate Parker Crook to learn more about how OpenDXL can help you make the most of your time and secure better outcomes for your enterprise.


  • 0

The Hack Back, A Double-Edged Sword

Category : McAfee

Global cyberattacks like Mirai, WannaCry and Petya have left victims feeling helpless and eager to gain back the data they’ve lost at the hands of cybercriminals. This modern threat landscape has everyone looking towards new solutions and strategies—any way they can help protect others while staying secure themselves. So, it’s no surprise that the idea of the “hack back” is gaining some traction. The hack back, a notion that came to light in various congressional proposals that are intended to put tools in the hands of victims to identify alleged attackers, halt an alleged attack, and potentially recover or delete stolen information.

This legislation, first proposed back in May, features policies intended to empower victims of a cyberattack, while still trying to ensure accountability. It states a mandatory reporting requirement for entities that use active-defense techniques, which is intended to help federal law enforcement ensure defenders use these tools responsibly. It also includes an exemption allowing the recovery or destruction of one’s own data if it’s located using the active-defense techniques permitted by this bill and does not result in the destruction of data belonging to another person.

While the objective of the legislation is laudable, helping companies improve their ability to defend themselves, we have to consider some of its risks that could include actions that may well cause damage to parties that either innocently were part of an attack, or through false flag operations that have no direct involvement. For instance, we’ve recently seen that the emerging intent from many attackers is to point the source of attacks to another party, such as was witnessed during the Operation Troy attacks. The use of hacking back in this scenario would have caused damage to a third party.

Our approach, and one we would recommend to others, is to take direct action against malicious actors by utilizing the expertise of law enforcement. A strong partnership between the public and private sector to hold cybercriminals accountable is essential in maintaining a safer society. So, if you do undergo a cyberattack, your first action should be contacting the authorities immediately. From there, experts will handle the situation in a way that ensures safety for all innocent parties involved.

There is a lesson to be learned from the notion of hacking back, however. Instead of hacking back, rather learn how to think like a hacker in order to identify cyberattacks and flag them before the damage is done. By thinking proactively, the need to take reactive measures lessens and the power shifts back to where it belongs: with you.


Author: Raj Samani

  • 0

McAfee Demos Ease of Exploiting Recent Apache Struts Vulnerability

Category : McAfee

A series of exploitable conditions have been uncovered in Apache Struts. One of these, CVE-2017-9805, allows unauthenticated execution of attacker code (aka remote code execution). This issue has already been weaponized into attack kits such as Metasploit and exploitation has been seen “in the wild”; that is, attackers are attempting to take advantage of the flaw.

Apache Struts is a popular open-source component that is used in numerous websites across the Internet, which makes a remote code execution vulnerability very concerning. Speculation is widespread about this issue’s exploitation.

CVE-2017-9805 describes a vulnerability in Apache Struts 2.5.12 that could be subject to a malware attack or other vector of attack designed to take advantage of the vulnerability. To our knowledge, Apache Struts 2.5.12 is not used in McAfee enterprise products as delivered by McAfee.

To demonstrate how easy it is to exploit the vulnerability, we created a little demo in which we take ownership of a vulnerable system. You can watch the video here.

To have an indication of the volume of attacks, the Advanced Threat Research (ATR) team set up a “honeypot” system to attract attack attempts. After less than two hours online, the ATR honeypot system recorded two attacks. One of the attackers attempted to run the Windows command line (cmd.exe) on our Linux box; the other attacker attempted to create a reverse shell toward his machine. If that had been successful, he could have gained full control of our system. Of course, our honeypot setup does not allow a compromise.

McAfee handles reported vulnerabilities in accordance with our product security practices. McAfee adheres to international product incident practices, including CVSS Version 3.0 calculation and CVE assignment.

McAfee actively encourages customer engagement and welcomes specific requests for clarification about our software security process.  There are some things we do not disclose, such as lists of vulnerabilities found through internal investigations or automated testing tools.

For external communications, we publish a security bulletin to all customers of an affected McAfee product as soon as McAfee’s security vulnerability team has confirmed that the vulnerability is critical, and after McAfee has determined appropriate mitigation for the vulnerability. (“Critical” means greater than or equal to CVSS 8.5.) The bulletin may address mitigations, workarounds, and updates. Please see McAfee’s Product Security Bulletins for more information.


This post was written by Brook Schoenfield and the Advanced Threat Research Team.

  • 0

One year later, McAfee ESM

Category : McAfee

We have two SIEMs in the Labs and we use them slightly differently. The McAfee ESM is our workhorse. We use the version 10 and we really like the new html5 user interface. This SIEM started life as the NitroView and it was, at that time, unquestionably the best analyst’s SIEM available. Today, Nitro having been acquired by McAfee, sold to Intel, and returned to McAfee, the product has undergone many changes, all of them very positive from our perspective. Perhaps the most important change is its personality. It still is a great analyst’s tool but it has become far more user-friendly over the years. Today it is a fine SOC engineer’s tool without losing any of its analytical chops.

This is a highly configurable tool and we stretch it constantly. It is so feature-rich that we would be hard-pressed to address everything that it can do in a single review. The easy way to introduce yourself to the ESM, once you have it installed and configured in your environment, is just to turn it on and look the default dashboard over. Without any fancy manipulation, you are presented with lots of important and useful information. From that point, you can select any of dozens of views concentrating on just about anything from malware to user activity to compliance. It comes pre-configured with special dashboards for just about any compliance task you can think of.

The power doesn’t stop there, though. The dashboards consist of collections of views that select elements that go together and place those collections in windows that you can edit and move around, adding your own elements and creating entire new collections for truly custom dashboards. For any given task, you start by selecting the dashboard you want and then performing drill-downs. This gives you a custom-designed threat hunting environment. This lets the SIEM do double duty: as a correlator of sensors with the job of alerting on suspicious behavior, and as a first-rate threat hunting tool.
Here in the Labs we are engaged mostly in research and testing. We let our SIEMs watch the Internet directly with no firewall. So, this is like drinking, not from a firehose, but from Niagara Falls. Add to that, we have a honeynet, deception network and a TOR exit node. We don’t have the SIEM configured precisely the same as you might in a production environment in your enterprise. That speaks volumes about the versatility of the device.

In a typical enterprise environment, you would be feeding it from every log source you could find – and it will accept them all, most out of the box, but you may need to do a bit of fiddling for odd or unusual log and flow sources. The tool looks at all events and flows, correlates them and plays them against standards you configure to get to risk. So, at the end of the day, with the addition of vulnerability and weighting data, ESM becomes a risk measuring machine.
McAfee has provided, automatically, a collection of threat intelligence feeds but you can add your own easily as well. Some are as easy as adding a simple command for execution with a single click. For example, we use several web sites to analyze intelligence on an IP address. We added those feeds to the ESM and now when we select an IP address we can select a threat feed we want to send it to as well. This returns intelligence on that IP – perhaps it is on a block list or has a bad reputation. We get all of this with a click of the mouse. Setting it up took about two minutes per threat intelligence site.

We have used the ESM in enterprise situations where we have been able to analyze logs such as domain controller and active directory server logs and correlate those data with others we may have found. This adds significantly to the threat hunt.
We have found support to be exceptional. The product is available as a virtual appliance or a physical one. There are specific support programs for each one. Support packages at the gold level include all updates for rules, signatures and content packs. Since you can build out your own content packs that is pretty powerful. Support at that level is 24X7. Documentation is everything it should be and pricing is very reasonable for the power the SIEM delivers.
IT should go without saying that this will be SC Lab Approved for another year, but just to avoid confusion, it has a home in the Labs for the next 12 months.