According to Microsoft’s security release notes, any system created, or which has updated its OMI package, after Aug. 11, 2021, should automatically be patched.


The four critical vulnerabilities discovered by security researchers from Wiz include one unauthenticated remote code execution (RCE) and three privilege escalation vulnerabilities.  Dubbed OMIGOD, the four vulnerabilities were found to directly affect Azure cloud instances using the following Azure services:  Prisma Cloud Compute Defender agents can detect whether any Azure system is vulnerable to any of the four CVEs.


Additionally, Prisma Cloud users can also build a custom vulnerability detection rule to identify if any system is running an OMI package with a version previous to 1.6.8.1.


To build a custom vulnerability detection rule, open Prisma Cloud and navigate to the following page:  name,type,package,minVersionInclusive,maxVersionInclusive,md5 OMIGOD,package,omi,*,1.6.8.0,  Palo Alto Networks Azure-based VM- and CN-Series Firewall instances do not use the OMI package and are not vulnerable to the OMI critical vulnerabilities.


Prisma Cloud will create an alert for any system which maintains an OMI package vulnerable to the OMI critical vulnerabilities.


Should a system be identified as vulnerable, the following steps should be taken for that Azure Cloud Instance:


On Sept. 14, 2021, security researchers from Wiz released a report detailing the findings of four critical vulnerabilities affecting the Microsoft Azure package OMI.


Dubbed OMIGOD, the four vulnerabilities were found to directly affect Azure Cloud Instances.


Palo Alto Networks Azure-based VM and CN Series Firewall instances do not use the OMI package and are not vulnerable to the OMI critical vulnerabilities.


Customers of Prisma Cloud have the ability to create alerts to detect vulnerabilities.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Use-after-free bugs have affected Internet Explorer for years.


In the past year alone, Microsoft patched 122 IE vulnerabilities, the majority of which were use-after-free bugs.


This year Microsoft has already patched 126 IE vulnerabilities to date.


Of those vulnerabilities, 4 were actively being exploited in the wild.


These 4 exploits (CVE-2014-1815, CVE-2014-1776, CVE-2014-0322, CVE-2014-0324) were all based on use-after-free bugs.


To deal with the increasing number of use-after-free bugs and associated exploits, Microsoft introduced a series of new control mechanisms in the most recent Internet Explorer patches.


In June, Microsoft introduced a new isolated heap mechanism to solve the usage issue of use-after-free exploitation.


They followed that up In July by implementing a deferred free method to solve the freeing issue of use-after-free bugs.


The main concept of an isolated heap is simple.


It allocates a dedicated heap for select critical objects to use that is separate from other heaps that a user can directly access.


The heap block will not be occupied by user-controlled data after the critical objects are freed.


This mechanism prevents precise control of the data of a freed object from further exploitation.


Figure 1. _g_hIsolatedHeap handle used for isolated heap


The isolated heap was applied to many but not all internal objects, leaving some still vulnerable.


To address this, Microsoft introduced another protection method of deferred free named ProtectedFree.


They encapsulate this method and apply it to almost every object in mshtml.dll.


In IE9, for example, it has been applied to every object through MemoryProtection::HeapFree as shown in figure 2.


Figure 2.


References of MemoryProtection::HeapFree


The main idea of this protection mechanism is to delay the freeing action so that the intruder is unable to determine when they can occupy the freed object using controlled data.


In this new patch, every time Internet Explorer tries to free an object, it is not freed immediately.


Instead, the block to be freed is marked and filled with 0x00 data and added to a pool.


When the size of the pool hits a predefined threshold, which is currently 100k (0x186A0 as highlighted in figure 3), it performs the real freeing operation (ReclaimUnmarkedBlocks).    Figure 3.


C++ style pseudo code of ProtectedFree function


Microsoft stores the to-be-freed blocks in a structure called st_ProtecFreeManageHeap.


This structure is created in the function MemoryProtection::CMemoryProtector::ProtectCurrentThread and is used to manage deferred free heap blocks.


Figure 4 shows an example of the structure in memory.


Figure 4. st_ProtecFreeManageHeap  Figure 5 provides an alternate view of the structure in a C style code block.


Figure 5. C style code of st_ProtecFreeManageHeap


If we were able to make the size of the current heap block in this structure larger than the threshold of 0x186A0 bytes and trigger CMemoryProtector::ProtectedFree, it is still possible to force a true freeing action and occupy the freed object with other data as we show in the following piece of javascript code in figure 6.    Figure 6. Javascript proof of concept to force freeing  When creating the anchor element, the debug logs are shown in figure 7.


The address of the anchor element is 0x0c3b3f98.


Figure 7:


Before free  We then manually decrease the reference number, so the CMemoryProtector::ProtectedFree function will fill the block with 0’s, but the object is still not freed.


Figure 8: decrease the reference number, not yet freed


Finally we make the size of the CMemoryProtector::ProtectedFree management structure larger than 0x186a0 forcing the freeing operation.


Figure 9: field “TotalMemorySize” of st_ProtecFreeManageHeap is greater than threshold


The anchor element is now actually freed as shown in figure 10.


Figure 10: object is in the free list now


From a researchers' point of view, deferred free created a few problems, one of the major ones being that the page heap feature may not work correctly.


Page heap is a useful feature for debugging.


When page heap is turned on, the system allows only one object in one memory page.


Once this object is freed the whole page is marked as invalid.


So the next time IE tries to access a freed object an invalid address exception would be raised.


This mechanism is extremely helpful when researchers are trying to find use-after-free bugs.


With the introduction of the deferred free patch the object is no longer truly freed, so the page still exists.


In this situation the researcher is no longer able to determine whether a use-after-free behavior has occurred because no exception would be thrown out.


To reduce the impact of the deferred free patch, a research may consider patching the mshtml.dll in memory.


For example, you can call MemoryProtection::CMemoryProtector::UnprotectProcess before you perform any fuzzing tasks.


The recent patches and introduction of isolated heap and deferred free are strong signs that Microsoft plans to address the fundamentals of use-after-free exploitation in a preventative manner rather than to passively patch the vulnerabilities as they are discovered.


From the results of our research, applications of such methods can effectively stop unpatched use-after-free attacks.


It can also make the exploitations of heap overflows or type confusion bugs significantly more difficult.


But this is not the end.


For the foreseeable future, Microsoft may introduce more defensive mechanisms against use-after-free bugs or even heap fengshui to reduce the risk of being exploited.


Could it be game over for use-after-free exploitation, or it is just the beginning of another cat and mouse game?


Time will tell.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Today we’re releasing a new Unit 42 white paper titled “Credential-Based Attacks: Exposing the Ecosystem and Motives Behind Credential Phishing, Theft and Abuse.”


In this paper, we look at the problem of credential theft by exploring how it happens, what attackers do with credentials once they’ve stolen them, and what you can do to help prevent credential-based attacks.


Credentials and authentication have become synonymous, with valid credentials allowing access to sensitive resources.


Adversaries are increasingly stealing and using credentials as part of their playbooks; impersonating legitimate users to access a company’s most sensitive information, erase data on servers, and reconfigure them so that they can’t boot; and undertake other malicious activities.


Stolen credentials underpin some of the most critical and damaging attacks out there; both Shamoon 2 and the Sofacy threat actor group, for example, have made detailed use of credential theft.


Credential theft today can happen in many ways, but the most notable are through credential phishing and the use of malware like keyloggers (both staples of the Sofacy group), as well as password reuse.


The impact of a successful credential theft is, ultimately, access and authorization.


Attackers will use credential theft for remote access to an organization, to access cloud-based resources (which may have weaker credential protections than network-based resources), or to move laterally within an organization once they’ve gained entry.


The most sophisticated attacks can – and do – blend these actions together, sometimes using multiple stolen credentials to penetrate networks, move laterally within them, elevate privileges, and then access and steal data.  Prevention of credential theft is too often overlooked.


Organizations should continue with user education to help users better spot and not fall for phishing and spam attacks.


You and your employees can also use password managers to make unique, complex passwords for each site not just a goal but a reality.


Technology is also catching up; recent advances in two-factor/multi-factor authentication (2FA/MFA) and one-time passwords (OTP) represent the best long-term approaches to preventing credential theft.


(Our newest release, PAN-OS 8.0, also includes protections to significantly limit or eliminate password reuse.)


Get your copy of our white paper here.


Ignite '17 Security Conference: Vancouver, BC June 12–15, 2017  Ignite '17 Security Conference is a live, four-day conference designed for today’s security professionals.


Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry.


Visit the Ignite website for more information on tracks, workshops and marquee sessions.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  In January 2020, during the first Patch Tuesday of the new year, Microsoft released patches for 17 new vulnerabilities including one for CVE-2020-0601 known as Curveball.


The vulnerability exists in the Windows CryptoAPI (Crypt32.dll) and specifically relates to the method used for Elliptic Curve Cryptography (ECC) certificate validation.


At the time of release, Microsoft affirmed that they had not yet seen the vulnerability exploited in the wild (ITW).


Researcher Tal Be’ery released a blog titled “Win 10 Crypto Vulnerability: Cheating in Elliptic Curve Billiard 2” that does a fantastic job at explaining this bug.


The patch provided by Microsoft included the typical release of operating system patches, but this time a new Application Programming Interface (API) function was added.


The new CveEventWrite function can be used to publish events when an attempt to exploit security vulnerabilities in user-mode applications occurs.


Analysts can collect alerts on the Application Message “CVE-2020-0601” as a means to hunt for attempted exploitation of this vulnerability on patched systems.


We also recommend users of the Chrome browser to update to version 79.0.3945.130 as they recently released an update to fix the TLS issue.  Palo Alto Networks customers running Traps are now safeguarded from the Windows CryptoAPI Spoofing vulnerability, regardless of whether they are running an unpatched Microsoft Windows 10 system.


Additionally, Palo Alto Networks offers multiple, additional complementary protections:


As a member of the Microsoft Active Protections Program (MAPP) program, Palo Alto Networks received early details of the vulnerability, providing greater understanding of the threat, which helps us implement strong product coverage.


As always, we recommend keeping your Microsoft products up to date with the latest patches to mitigate this vulnerability.


Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.  CVE-2020-0601: The ChainOfFools/CurveBall Attack Explained POC  Win10 Crypto Vulnerability: Cheating in Elliptic Curve Billiards 2  NSA Cybersecurity Advisory  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


In the months since the WanaCrypt0r/WannaCry and the Petya/NotPetya attacks, security researchers have delved into the nuts and bolts these incidents and the malware involved.


One key thing that research into these security incidents shows is that these attacks used a relatively new and unknown technique called kernel APC attacks as part of their toolkit.


Kernel APC attacks occur in a way that increases the “stealth” factor and makes standard detection and prevention very difficult.


And kernel APC attacks do this while still maximizing the power and control that the code has on the target system.


While kernel APC attacks aren’t well known and can be hard to understand, their proven success in WanaCrypt0r/WannaCry and the Petya/NotPetya make them an important threat to understand because proven attack techniques are quickly adopted widely.


And understanding is a first step to prevention.


To understand what makes kernel APC attacks so dangerous, it’s important to understand what they are.  The kernel is the heart of the operating system.


When talking about operating systems with security permissions and controls like Windows or UNIX/Linux, the kernel operates with the highest level of control.


Because of this, attacks against the kernel are used to gain complete control over a system, generally as part of an “elevation or privilege” (EoP) or “privilege escalation” attack.


Typically, attacks against the kernel are used in conjunction with code execution attacks so that an attacker can target a limited privilege user but ultimately gain full control over the system.


Privilege escalation attacks against the kernel have been around for some time and are well-known and can be well protected against.  Kernel APC attacks however are a different class of attack.


These don’t attack the kernel to gain privileges.


Instead kernel APC attacks already have kernel privileges and use them to further carry out their attack.


In this case by making legitimate programs execute malicious code rather than their own legitimate code.


Kernel APC attacks do this using their control over the kernel to redirect APCs: “Asynchronous Procedure Calls”.


APCs can basically be thought of as places in line for the CPU that the kernel gives access to.


In a kernel APC attack, the attacker gives a legitimate program’s place in line to the attacker’s code.


The crux of what makes this attack technique so important is how the technique uses this level of control to have legitimate programs run illegitimate commands.


It’s easier to detect and prevent illegitimate programs (malware) from executing commands.


But when legitimate programs execute illegitimate commands, it’s harder to detect and prevent: it’s not always clear whether a command is legitimate or not, and interfering with commands from legitimate programs can have significant (sometimes catastrophic) unintended consequences.


And finally because of ways that kernel APC attacks are carried out, it doesn’t leave the usual fingerprints you find after an attack making detection harder still.


Taken altogether, these make kernel APC attacks an effective and sophisticated technique.


And while this technique alone isn’t solely responsible for the damaging power of WanaCrypt0r/WannaCry and Petya/NotPetya it is certainly an important contributing factor.


Perhaps more importantly, it’s a piece of those attacks that has escaped relative notice outside of some specialized parts of the research community.


New effective attack techniques that escape notice are always inviting for other copycat attackers.


A good way to defend against this is to understand and be aware of the thread: forewarned is forearmed.


If you want a more detailed understanding of kernel APC attacks as they occurred in WanaCrypt0r/WannaCry, two good resources are Microsoft’s MMPC blog “WannaCrypt ransomware worm targets out-of-date systems” and Countercept’s “DOUBLEPULSAR Usermode Analysis: Generic Reflective DLL Loader”.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


In recent years, ransomware families are often glamorized as being some of the most dangerous types of malware.


They’ve certainly caused a wealth of damage to end users with some of the more prominent malware families, such as CryptoLocker, CryptoWall, TorrentLocker, and TeslaCrypt infecting millions of users overall.


For readers that might be unfamiliar with ransomware, it’s a type of malware that is responsible for encrypting a user’s files with a key known only to the attackers.


Examples of files that might be encrypted include financial documents, home movies, photos, or business-related files.


In order to decrypt these files, the victim must provide a ransom, or payment, to the attacker, often in the form of a digital currency.


While ransomware is often thought to be bullet-proof, it is certainly not always the case.


In early 2015, Emnisoft identified a new family of malware named PClock.


At the time, the malware was riddled with issues, specifically in the way it encrypted files.


It used a simple XOR encryption routine with a static key, allowing victims to easily recover their files without paying a ransom.


In August, we started detecting updated copies of PClock, which has been improved upon by the malware author.


We set out to determine if this updated version of PClock holds up to some of the more prominent families.


For the sake of clarity, I will refer to this newer version of PClock as PClock2 going forward.


The following sample is used for analysis:  Figure 1.


analysis sample  PClock2 is written in Visual Basic.


For a copy of this file’s IDA Pro database (idb), please refer here.


When initially executed, PClock2 performs a very simple anti-analysis check where it will sleep for a random amount of time and compare the time spent sleeping against a set value.


This check is essentially looking for sandbox systems where the sleep function accelerates analysis.


Figure 2. Check by PClock2 for hooking of sleep function  A simple check is performed to determine if the malware is running with administrative privileges.


Once completed, the malware sends the result via an HTTP POST request to a remote server.


All data sent via HTTP POST requests is sent in the clear.


Figure 3. HTTP POST request containing administrative privileges


The ‘P0’ is statically set by the malware in the above request.


The ‘1828’ represents the thread ID (TID) of the malware, while the ‘rnd’ GET variable is randomly generated.


Throughout the runtime of PClock2, it makes multiple HTTP POST requests to a remote server using the same characteristics, including the ‘PO[TID]’ and the current time.


Additionally, the user-agent used by the entire PClock family, including PClock2, is consistent across samples.


PClock2 proceeds to copy itself with the name “winjab.exe” in the following path.


While this particular sample is seen installing itself to the %ALLUSERSPROFILE% path, other samples have been witnessed using %APPDATA% instead.


PClock2 also enables persistence by setting the following registry key.


All instances of the entire PClock family have been found to use this particular registry key.


After installation is complete, the malware makes another HTTP POST containing the various file paths it used.


Figure 4. HTTP POST request containing file paths of malware  After installation, PClock2 will also set the following registry key with a value of ‘INSTALL_OK’.


This particular registry key is used to hold the latest state of the malware.


Other messages that might be present in this key include the following.


The following registry keys are also used within the CLOCK sub-path by PClock2:  PClock2 proceeds to use the API from blockchain.info to generate a unique Bitcoin (BTC) wallet identifier, which is configured to automatically forward payments to a hardcoded wallet identifier of ‘1MRfkK134ErfbcadUSoSUCBahngCqoBKju’.


The following HTTPS request accomplishes this.


PClock2 will also make a request to the following blockchain.info address to determine the current value of BTC.


This information is stored in the ‘\BData\B’ registry key as previously stated.


The malware proceeds to generate a unique key that will be used in subsequent file encryption using the following data:  This data is concatenated to form a string similar to the following:  Figure 5.


Data collected to be used in formation of unique key  This data is then hashed using the SHA256 algorithm to generate a unique key.


This key is stored in the ‘\CData\C’ registry key as previously stated.


This key is also sent via a HTTP POST request.


Figure 6.


HTTP POST request containing unique SHA256 key  PClock2 scans the file system of the victim in order to identify files that are to be encrypted.


The following paths are ignored:  Additionally, for a list of targeted file types, please see the following link.


Once files are identified, PClock will begin encrypting them, one-by-one.


Unlike the original version of PClock, this variant has forgone the simple XOR encryption routine in place of using RC4.


The RC4 key is generated by concatenating the SHA256 value previously generated with the path to the file being encrypted.


250dd811187959220220574a185ccf669e06c0ee3926773a7cb94750c401812cC:\Documents and Settings\Administrator\Desktop\Form1.cs


It should be noted that PClock takes a very long time to encrypt these files.


On a test sandbox, the malware took upwards of 20 minutes to complete encryption, which is less than ideal for an attacker as it gives the victim time to notice the infection and stop it.


By comparison, the latest version of the CryptoWall malware family takes roughly 1-3 minutes to complete its encryption routine.


It’s also interesting to note that each time PClock2 scans a directory or encrypts a file, it makes an HTTP POST request to the C2 server.


Figure 7. HTTP POST request indicating a folder is being scanned  This resulted in over 1,000 requests being made on a sandbox machine, which contained little data of interest.


After it finished the encryption routine, PClock2 generates a VBScript file in the following directory:


This script file contains the following commands, which will delete shadow copies on the Windows operating system.


Set UAC = CreateObject("Shell.Application") UAC.ShellExecute "vssadmin", "Delete Shadows /All /Quiet", "", "runas", 1  On Windows XP, the following dialog box appears to the victim when this script runs, making it fairly apparent that something suspicious is occurring:  Figure 8.


Dialog box that appears to victim when VBS attempts to run


After running the clean up script the malware overwrites the ‘\CData\C’ registry key with a value of zero, which removes the unique SHA256 key.


Finally, the malware changes the victim’s wallpaper and generates a GUI instructing the victim how they can provide payment and retrieve their files.


This dialogue mimics the more-capable “CryptoLocker” malware family and provides instructions in both English and Spanish.


Figure 9.


Ransom demand


I originally wished to determine if the new version of PClock, PClock 2, included enough improvements to compete with some of the larger ransomware malware families, such as CryptoWall, TeslaCrypt, or TorrentLocker.


In truth, this version has made a number of improvements, such as adding more file types to target, ignoring certain directories, and using a better encryption routine.


However, a number of strong issues still plague this malware family, such as the following:  While this version is an improvement, it still lacks many of the features and stealth that are currently present in the larger ransomware families.


While ransomware is a large problem for users, it’s important to realize that not all malware families are created equal.


Like most things in life, malware comes in many shapes and forms, from the more elegant and robust solutions, to those that come up lacking.


All PClock malware family samples are properly classified as malicious by WildFire.


AutoFocus users can find more information on samples and indicators related to this attack by viewing the PClock tag.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Mobile app creators are often looking for ways to monetize their software.


One of the most common ways to do this is by displaying advertisements to users or by offering in-app purchases (IAPs).


Mobile monetization platforms create software libraries that authors can embed into their apps to start earning money quickly.


We previously highlighted the dangers of installing apps that enable IAPs using SMS messages, as these apps typically have access to all SMS messages sent to the phone.


While not all SMS-based IAP applications steal user data, we recently identified that the Chinese Taomike SDK has begun capturing copies of all messages received by the phone and sending them to a Taomike controlled server.


Since August 1, Palo Alto Networks WildFire has captured over 18,000 Android apps that contain this library.


These apps are not hosted inside the Google Play store, but are distributed via third party distribution mechanisms in China.


Background  WildFire captures many samples of mobile malware that intercept and upload SMS messages.


Most of these are created by malware authors who set up command and control (C2) servers with third party hosting providers and frequently update their locations to avoid detection.


Among these malware we have found many that are created by “mobile monetization” companies who distribute apps that provide little value but have a high cost to the user.


These apps are often installed by tricking users into clicking a pop-up, only to find later that a charge has appeared on their phone bill.


Antivirus programs typically identify these apps as malware, the topic of this blog is something different and harder to detect.


Taomike is a Chinese company that aims to become the biggest mobile advertisement solution platform in China.


They provide an SDK and services to help developers display rich advertisements with a high pay rate.


Taomike has not previously been associated with malicious activity, but a recent update to their software added SMS theft functionality.


The apps this library is embedded in may be legitimate and have significant functionality, but their developer’s choice to use this library has put them at risk.  Technical Details:


SMS Theft


Not all apps that use the Taomike library steal SMS messages.


Our analysis indicates that only samples that contain the embedded URL, hxxp://112.126.69.51/2c.php have this functionality.


This is the URL to which the software uploads SMS messages, and the IP address belongs to the Taomike API server used by other Taomike services.


We have captured around 63,000 Android apps in WildFire that include the Taomike library but only around 18,000 include the SMS theft functionality.


We believe there are different versions of the Taomike SDK and only some of them include SMS uploading behavior.


Based on our data, the version that contains the SMS stealing functions is newer and was released around August 2015.


Apps that use earlier versions of the library appear to be safe.


The Taomike library is called “zdtpay” and is a component of Taomike’s IAP system.  Because Android apps are required to list the permissions they need in their manifest file, we can see that this library requires both SMS and network related permissions.


The library also registers a receiver named com.zdtpay.Rf2b for both the SMS_RECEIVED and BOOT_COMPLETED actions with highest priority of 2147483647.


Figure 1.


Registered receiver for SMS_RECEIVED  The registered receiver Rf2b reads SMS messages whenever they arrive.


The message body and sender phone number are collected as shown in Figure 2.  Figure 2.


SMS body and sender number read


If the device has just booted, it will start the service MySd2e, which then registers a receiver for Rf2b as shown in Figure 3.


Figure 3.


MySd2e Service registers receiver for Rf2b


SMS information collected by the receiver is saved in a hashmap with “other” as the key and sent to a method that uploads the message to 112.126.69.51 as shown in Figure 4.


Figure 4. Information uploaded to IP Address used by api.taomike.com


All SMS messages sent to the phone are uploaded, not just those that are relevant to Taomike’s platform.


Figure 5 shows a packet capture of a test message upload.


The message content is “hey test msg” as circled with dashed red box.


Figure 5.


SMS uploaded via HTTP in pcap  The Taomike library makes contact with the following URLs, but only the “2c.php” path is used to capture SMS messages.


The rest appear to be used for other parts of the IAP functionality in the library.


Risks and Mitigation


We have captured over 18,000 samples that contain the SMS stealing library since August 2015, meaning the number of affected users is considerable.


We expect the number of affected apps and users to increase as more developers incorporate the newer version of Taomike library.


The infected apps are not limited to a single developer or third party store as many developers appear use the Taomike library.


Some of the infected apps purport to contain or display adult content.


We do not know how Taomike is using the stolen SMS messages, but no library should capture all messages and send them to a system outside the phone.


In version 4.4 of Android (KitKat) Google began preventing apps from capturing SMS messages unless they were defined as the “default” SMS app.


Users outside of China and those that only download apps from the official Google Play store are not at risk from this threat.


To protect Palo Alto Networks customers from the Taomike SMS stealer, we’ve made the following protections available:


Conclusion  Even popular third party monetization platforms are not always trustworthy.


When developers incorporate the libraries into their apps they need to carefully test them and monitor for any abnormal activities.


Identifying monetization and advertising platforms that behave poorly and abuse their users is something that our industry must to do ensure the safety of all mobile devices and their users.


Acknowledgement  We greatly appreciate the help from Rongbo Shao from Palo Alto Networks in working on the Threat Prevention signature.


We would also like to thank Ryan Olson, Benjamin Small, Richar Wartell, and Chris Clark from Palo Alto networks in publishing the discovery.


Related Sample Hash Values  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Recently, we found email accounts from top universities across the world being sold on Taobao, the largest consumer-to-consumer (C2C) e-commerce platform in China.


Advertised uses for these accounts included registering for special accounts under software developer programs, receiving student discounts or coupons from retailers, and obtaining access to academic databases.


This post describes the scope, associated risks, and implications of this activity.


Our investigation began with a Chinese language search for "edu mailbox" in Taobao, which returned 99 results related to stolen university email accounts.


The most expensive account was listed at ¥2400 RMB ($390.80 USD), while the cheapest was only ¥0.98 RMB ($0.16 USD).  Figure 1: Results for Chinese language "edu mailbox" search on Taobao.


These accounts, which include an education (EDU) top-level domain email address with valid password, represent 42 of the world’s top universities, across 10 countries:


Australia:  Canada:  China:  Denmark:  Italy:  Singapore:  Sweden:  Switzerland:  United Kingdom:  United States:  The sellers guaranteed that all email accounts were valid, accessible, and active.


The descriptions for these items proposed three main uses for buyers:


1. Registering for special accounts under software developer programs:


For example, the most popular account type, which has been bought at least 569 times, was advertised as a Microsoft’s student Windows Phone 7 and 8 developer account.


By using this kind of account, a user can perform a developer unlock on their Windows Phone devices without incurring a fee.


Most reviews of this package were favorable, with comments like "very good to use" or "with seller’s help I can unlock my phone now."


Figure 2: The most popular account type has sold at least 569 times.


2. Receiving student discounts or coupons from retailers:


Some accounts advertised candidacy towards registration for student discount at retailers such as Amazon, BestBuy, Apple, and Dell.


For example, the standard annual fee for Amazon Prime is $99 USD; however, with the student discount, a buyer could enjoy it for free the first six months and then renew at half price for subsequent years.


Figure 3: The seller showed how to register for student discount accounts.


3. Obtaining access to academic databases:


Accounts for big universities (e.g., MIT, Stanford, etc.) are mainly used to access respective library services and resources, "including research help, study spaces, print and electronic books/journals and more."


Figure 4:


A seller advertises how an MIT account can be used to access online library resources.


We talked with some sellers through AliWangWang, an instant message (IM) system developed by Taobao for online trading.


A well-stocked seller told us that every account he sold belonged to an active student at the respective university.


He claimed that once the account was sold, only the one buyer and the legitimate user would have access.


He recommended not changing the account password to avoid detection by the legitimate user.


Another seller offered to provide real identity information for a stolen account so the buyer could change the corresponding password and security questions.


This type of account access was the most expensive and least flexible in terms of customization (i.e., username, institution, etc.).


Additionally, it should be noted that there is value beyond the EDU account itself for password and security question information, in the event they are shared across other online accounts for the legitimate user.


Other sellers were also able to offer customizable email accounts from a specific domain/institution.


Figure 5: A seller advertising a customizable “xxx.edu” email account.


In the above advertisement, the seller describes the ability to choose an account under a subdomain (academia, student, me, email, or contact) of the requested domain.


The price for this custom account was only ¥27 RMB ($4.40 USD); for an extra ¥13 RMB ($2.12 USD), the buyer can request a custom username at any subdomain for the given institution.


To further assess this threat, we purchased a customized, new account from a seller on Taobao.


Four hours later, we received confirmation that the custom email address "claud@student.cnri.edu" was active.


Navigating to CNRI’s webmail page, we were then able to successfully access and send an email from that account.


Figure 6: Sending an email through a newly bought customized EDU account.


Another noteworthy trend we observed was that some sellers provided email addresses with customizable usernames at "californiacolleges.edu".


In fact, anyone can do the same by visiting the California Colleges Create an Account page.


Accounts made through this site "can be used to apply [for] related memberships of Amazon Prime, Microsoft Developer, Adobe and Apple by some secret ways," one seller said.


Figure 7: Using a newly created California Colleges account.


As with most criminal enterprises, not all sellers on Taobao use their real identity, presenting a challenge in tracking down the individuals behind this activity.


In order to sell anything on Taobao, a seller must at least create a valid Alipay account (similar to PayPal) linked to a valid Chinese citizen ID number (similar to a U.S. Social Security number), and then associate it with a valid Chinese bank account under the same citizen ID.


However, identity theft is a global concern and the Chinese citizen ID is no exception, allowing for potential sellers to simply purchase a usable identity online.


Based on our investigation, we believe that stolen accounts for these universities are actively selling on Taobao.


On August 27, we reported our findings to Taobao.


Their response was that they were addressing this issue and have already removed a number of these items, with the remainder requiring further investigation.


However, this malicious seller activity may also reveal a larger scale problem within university systems.


Through the types of accounts advertised on Taobao, an attacker can steal a student or staff account, assume their identity, and gain unauthorized access to standard university resources.


More sophisticated and nefarious uses include leveraging accounts in social engineering/phishing attacks or exploiting access to high-value university systems (e.g., personnel, financial, research) to steal information.


Fortunately, a number of the institutions impacted by this activity have already implemented two-factor authentication for high-value resources, reducing the risk of the latter.


Yet, we believe the residual risk and exposure call for further action.


The following are our suggestions for discovering and mitigating risks associated with this activity:  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  Today, Palo Alto Networks Unit 42 researchers are announcing details on a new high- severity vulnerability affecting the Google Android platform.


Patches for this vulnerability are available as part of the September 2017 Android Security Bulletin.


This new vulnerability does NOT affect Android 8.0 Oreo, the latest version; but it does affect all prior versions of Android.


There is some malware that exploits some vectors outlined in this article, but Palo Alto Networks Unit 42 is not aware of any active attacks against this particular vulnerability at this time.


Since Android 8.0 is a relatively recent release, this means that nearly all Android users should take action today and apply updates that are available to address this vulnerability.


What our researchers have found is a vulnerability that can be used to more easily enable an “overlay attack,” a type of attack that is already known on the Android platform.


This type of attack is most likely to be used to get malicious software on the user’s Android device.


This type of attack can also be used to give malicious software total control over the device.


In a worst-case attack scenario, this vulnerability could be used to render the phone unusable (i.e., a “brick”) or to install any kind of malware including (but not limited to) ransomware or information stealers.


In simplest terms, this vulnerability could be used to take control of devices, lock devices and steal information after it is attacked.


An “overlay attack” is an attack where an attacker’s app draws a window over (or “overlays”) other windows and apps running on the device.


When done successfully, this can enable an attacker to convince the user he or she is clicking one window when, in fact, he or she is actually clicking another window.


In Figure 1, you can see an example where an attacker is making it appear that the user is clicking to install a patch when in fact the user is clicking to grant the Porn Droid malware full administrator permissions on the device.


Figure 1: Bogus patch installer overlying malware requesting administrative permissions


You can see how this attack can be used convince users to unwittingly install malware on the device.


This can also be used to grant the malware full administrative privileges on the device.


An overlay attack can also be used to create a denial-of-service condition on the device by raising windows on the device that don’t go away.


This is precisely the type of approach attackers use with ransomware attacks on mobile devices.


Of course, an overlay attack can be used to accomplish all three of these in a single attack:  Overlay attacks aren’t new; they’ve been discussed before.


But until now, based on the latest research in the IEEE Security & Privacy paper, everyone has believed that malicious apps attempting to carry out overlay attacks must overcome two significant hurdles to be successful:  These are significant mitigating factors and so overlay attacks haven’t been reckoned a serious threat.


However, our new Unit 42 research shows that there is a way to carry out overlay attacks where these mitigating factors don’t apply.


If a malicious app were to utilize this new vulnerability, our researchers have found it could carry out an overlay attack simply by being installed on the device.


In particular, this means that malicious apps from websites and app stores other than Google Play can carry out overlay attacks.


It’s important to note that apps from websites and app stores other than Google Play form a significant source of Android malware worldwide.


The particular vulnerability in question affects an Android feature known as “Toast.” “Toast” is a type of notification window that “pops” (like toast) on the screen.


“Toast” is typically used to display messages and notifications over other apps.


Unlike other window types in Android, Toast doesn’t require the same permissions, and so the mitigating factors that applied to previous overlay attacks don’t apply here.


Additionally, our researchers have outlined how it’s possible to create a Toast window that overlays the entire screen, so it’s possible to use Toast to create the functional equivalent of regular app windows.


In light of this latest research, the risk of overlay attacks takes on a greater significance.


Fortunately, the latest version of Android is immune from these attacks “out of the box.”


However, most people who run Android run versions that are vulnerable.


This means that it’s critical for all Android users on versions before 8.0 to get updates for their devices.


You can get information on patch and update availability from your mobile carrier or handset maker.


Of course, one of the best protections against malicious apps is to get your Android apps only from Google Play, as the Android Security Team aggressively screens against malicious apps and keeps them out of the store in the first place.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Mutex analysis is an often overlooked and useful tool for malware author fingerprinting, family classification, and even discovery.


Far from the hypothesized "huge amount of variability" in mutex names, likely hypothesized due to the seemingly random appearance of them, practical mutex usage is embarrassingly consistent.


In fact, over 15% of all collected worms share a single mutex [2gvwnqjz].


This blog was sourced from the data generated by the WildFire Analytics cloud, which processes thousands of samples a day and provides insights into various characteristics and behaviors of malware worldwide.


But before we get into the details, here is a quick overview of mutexes and why they exist in the first place.


The mutex is the fundamental tool for managing shared resources between multiple threads (or processes).


If you think of the threads as a whole bunch of people in a meeting, all trying to talk at once, a mutex is the baton that gets passed from one person to the next so that there’s only one person talking at a time.


The important thing to understand is what the mutex is really protecting.


In the above example, the resource being protected isn’t the right to speak, as many might think, but rather the ability to listen.


Here’s a more technical example.


Lets say you want to update an Internet Explorer (IE) cookie file, adding a unique identifier for use later.


Naively, what you need to do is read the cookie file in, add your data to what you’ve read, and write the file back to disk.


But what if IE is running and also updating that file?


The worst case, for you, is that both you and IE read the file at the same time but you write your edits first.


This is because IE will completely destroy your edits when it writes its new version of the file over yours.


The solution to this problem is to use a mutex to protect the integrity of the cookie file.


A process that has the mutex knows that while it holds that mutex no other process will be accessing the cookie file.


It can then read, tweak, and write the file without fear of any clobbering by other processes.


Since each shared resource can only have a single mutex effectively protecting it, leveraging that mutex is indication that a program will be using said resource.


In the cookie file example above, just referencing the mutex protecting that file indicates, with extremely high probability, that functionality to change the file exists somewhere in the program.


Any given mutex, and protected functionality, can then be thought of as an independent library of sorts.


Note that while the technical implementation may not expose said functionality as a normal library, such exposure is not necessary for the types of analysis performed here.


That library’s usage can be analyzed in terms of who uses it.


Simply put: malware writers leverage malware specific libraries and groups of like actors will reuse these core libraries when able.  The needle in a haystack problem forever plagues malware research: it’s extremely difficult to find reliable information with malware writers constantly working to undermine or eliminate that information.


But, in the case of mutex analysis, the useful information pretty well slapped us in the face.


As can be clearly seen, mutex 2gvwnqjz1 is strongly associated with malware.


In fact, we have only seen it in malware.


As is equally obvious, not all mutexes offer such dramatic insight.


There are many common mutexes shared across both benign software and malware.


What’s more, they don’t all share millions of uses across both sides of the fence.


In cases such as these the common approach is to use sets of the data, in this case sets of mutexes, to create fingerprints of each sample and then leverage those fingerprints to extract higher confidence classification decisions.


While this avenue of research is being pursued, it suffers from all the traditional challenges of big data research.


In other words, it’s slow going.


In parallel, and to inform better hypothesis for the fingerprint generation, research is being done to determine how far single mutex analysis can take us.


The research is ongoing but the initial results are extremely promising.


The number of times any single mutex is used drops rapidly from the millions of samples down to thousands and from there, even further.


Tens of thousands of the mutexes have been seen in only a single sample each.


This results in a few hundred thousand individual mutexes available for further analysis.


What quickly becomes apparent is that a large majority of the mutexes provide no obvious means to automatically classify them as necessarily indicative of good or bad behavior.


And, unfortunately, the ones, which are reasonably easy for a human to identify, are so for significantly different reasons.


For example,  “autoproto_*”  -- More than 20 mutexes share that preface, offering a natural fingerprint.


“global\setup_028746_mutexitem” -- Associated solely with known malware digital signers.


“defined_setnocandy”  -- After reading mutex names for a few hours this just sticks out like a sore thumb.


Only the first of the examples had the mutex associated with a vast majority of malware samples.


This implies that any fully automated association of a mutex to either benign or malware samples will itself require complex fingerprinting and confidence models.


Full automation is always the ideal but it isn’t always necessary.


With the appropriate tools it’s possible to enable a single researcher to continually review and categorize new mutexes.


The initial classifications to be used are “benign”, “malware”, or “statistical”.


Meaning that the mutex either itself indicates a benign or malware sample, or that the mutex alone is not enough to make a determination and the statistical ratio of benign to malware is the best it can offer.


The backlog of already collected mutexes is too great for a small team of researchers to meaningfully tackle without some kind of ranking system.


Luckily, the most objective piece of data collected about each mutex, how many samples were classified benign vs. malware, has all the information necessary to ensure that the researchers’ tackle the low hanging fruit first.


With over hundreds of thousands of malware associations, this specific mutex is associated exclusively with the Net-worm:W32/Allaple malware family which has been around since 2006 but continues to propagate and reinvent itself through the years.


Though the fact that the malware writer obviously named the mutex by rolling their face on the keyboard made it obvious before we'd done any further analysis that we’d found a unique identifier within the binaries.


This malware is well documented as a powerful polymorphic worm that encrypts itself differently every time it propagates.


The evasive nature of this malware family leads to a different file hash, import hash, and only a 20% average SSDeep hash overlap between the samples.


But because the mutex name is set at compile time, the mutex itself offers a common thread between all of the samples we collected and analyzed.


However, this particular mutex was associated with only a recent subset of the Allaple family.


Unlike many other avenues of research and classification, mutex name based associations provides an almost trivial means of uniquely identifying common code blocks and thereby malware families.


The first thing our researchers noticed was the similarity between this mutex name and the previous one.


While programmatic analysis would have a hard time associating the two, it's obvious to a human that the same face rolling technique was used to name this mutex.


The author simply rolled around a bit more.


Quick follow up analysis revealed that this mutex was also associated with the Allaple malware family.


More interestingly, it was another, non-overlapping, subset of the Allaple family.


Several hypotheses followed directly from this observation.


Absolute proof for a few of these hypotheses may never be realized.


However, and lucky for us, the malware author was arrested in 2010 so several of the hypothesis can be verified.


The first is very likely due to the similarities present in the order of keys hit.


Both begin with “jhd”.


“jh” itself is more common than would be expected given that, with fingers on the home row, it requires the right index finger to move and press another key before any other key is struck.


And “jh” is always followed by a key from the left side of the keyboard.


These unique consistencies make it extremely improbable that two different people named these mutexes.


The second mutex appears to be a concerted effort to make the mutex seem “more random” than the first.


It's immediately obvious that the author didn't move his fingers/hands much while typing the first.


It’s obvious enough that the author likely noticed it when reworking this section of code.


It's highly improbable that one would see the second mutex and make a concerted effort to make it appear “less random”.


And, as can be quickly verified by searching through standard virus detection logs, the mutexes did in fact appear in the hypothesized order.


The third is likely due to the lack of overlap between mutex names.


However, the research necessary to conclusively prove this hypothesis would be very time consuming and provide little other benefit.


The fourth is likely due to the mutexes only appearing in a single malware family.


If this functionality were available in some more open source setting, and was of even moderate quality, we would expect to see it used in other malware families as well.


As this functionality has not migrated outside the Allaple family, either the quality of the code is bad (see: face rolling), or it's simply not available to other malware developers.  The fifth is very likely as a change to the specific functionality these mutexes protect, with every change to any functionality, is simply not a practical method of development.


And indeed, as with the second hypothesis, standard virus detection logs prove that each of these mutexes do span multiple variants of the worm.


Mutex names provide a window into the entire development process and timeline for malware.


Idiosyncrasies of the malware author become apparent, the evolution can be traced, the availability or quality of code deduced, and reuse of functionality made clear with a simple mutex.


No other currently used method of analysis offers such a personal view into malware development.


Mutex name analysis as a whole offers a unique look into the results of any sample classification system and the malware therein.


While the research may never result in a fully automated decision system, it has been proven that researchers employing a hybrid approach to analysis will be able to provide critical and timely information to support the continual improvement of the classification system as a whole.


From edge case to systematic misclassifications, mutex usage is even more generally the canary in a coal mine than was previously realized.  While tedious and time consuming, combing through mutex names did come with more than a few good laughs.


After nearly as much debate as some of the real research, we’ve whittled the list down to our favorites (For the curious, these are all malware mutexes).


Enjoy.


Pluguin - When penguins and wall sockets mate.


Development environments don’t have spell check but, maybe they should.


senna spy rock in rio 2001 virus - Subtlety.


Overwhelming.


There were many variations on this one, Senna’s obviously proud of his work.


chinese-hacker-2 - We’re not sure which is worse: that this is a legitimate signature or a sad frame job.


Either way, somebody needs their computer privileges revoked.


mutexpolesskayaglush*.*svchost.comexefile\shell\open\command %1 %*@ - Putting shell code in a mutex name is right on the border of brilliant and insane.


We’ll leave that determination to the reader.


mr_coolface - Really, not so much, no.


don't stop me!


i need some money!


- http://www.monster.com/ - don’t say we never did anything for you.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


In-App Purchase (IAP) has become a popular way to sell services and virtual items through mobile applications.


In the Android ecosystem, in addition to the official IAP service by Google, there are many third-party IAP Software Development Kits (SDKs) spread around the world.


Some of these third-party SDKs provide IAP services based on existing online payment platforms.


However, an increasingly popular method uses premium SMS.


A primary reason for the popularity of SMS-based IAP is that it does not require Internet connectivity, just cell service.


While this is more convenient for both users and developers, there are significant security concerns with using SMS-based IAP on Android.


These concerns are detailed below.


Installing an Android app with SMS-based IAP is almost equivalent to installing an “SMS manager” (or even a “contacts manager”) app on the phone.


The reason is because most SMS-based IAP SDKs include comprehensive functionalities to monitor, manage, and even intercept a user’s SMS communication silently in the background, without any user interaction or knowledge.


This is a critical point: these SMS-based IAPs are able to independently send, receive, or block any SMS to/from any cellphone on which they are installed, without the user having any idea this is occurring.


This can include receiving instructions from a cloud server under the control of the SDK author.


Palo Alto Networks Wildfire, through custom SMS blocking policies, recently discovered eight different SMS-based IAP SDKs with this abusive functionality.


Further investigation shows that these SDKs have been used in at least 25 different Android games in two third-party app markets, JoloPlay and Wanyx.


17 of the top 50 games in JoloPlay contain at least one of these IAP SDKs.


According to JoloPlay’s website, these 17 games have been downloaded and installed more than 1.7 million times.


Most of them are pirated or repackaged from famous Android games, such as Plants vs. Zombies 2, Jewels Maze, Fishing Joy, and Where's My Water.


According to Wanyx’s website, 12 of the 50 games in Wanyx’s suggested games column contain the discussed IAP SDKs.


In Wildfire, we classify apps using these IAP SDKs as Potentially Unwanted Applications (PUA).


The reason they are not marked as malware is because all SDKs require user interaction when making a purchase (e.g. user clicks on the agreement).  However, these IAP SDKs are very dangerous to users because of what they are doing with a user’s SMS without his or her knowledge.


Below are the details of eight SMS-based IAP SDKs discovered by Wildfire:


All of the identified IAP SDKs use premium SMS to provide the IAP service.


They implement code that will send SMS to pre-defined premium numbers (Figure 1).


This code implementation is also abstracted in an interface for developers.


However, in addition to sending, all of these IAP SDKs also implement a BroadcastReceiver and register it for SMS_RECEIVED actions (Figure 2).  In addition, Umpay, WiPay, and NgstreamPay will also register a ContentObserver to monitor all changes in an SMS inbox (Figure 3).


After an SMS is received, these receivers and observers will check the originating number and/or message body, and block the SMS by some policies (Figure 3 and Figure 4).


For example, in Figure 4, the policy is defined as deleting SMS satisfying two conditions at the same time:  1. Message comes from the phone number “+8610658008” or “10658008”  2.


The message body contains the term “You will use” (translated from Chinese shown in Figure 4).


Some of these policies are hard-coded in the SDKs, e.g., in UmPay; but others are pre-fetched from cloud servers that are operated by the SDKs’ providers (Figure 5).


Again, all the functions mentioned above run silently in the background.


Except for LinkSMSPayment, all the IAP SDKs listed in this post do not notify the user in any way that they are taking actions against the user’s daily SMS communication.


Users have no idea if an SMS was blocked or if it was delivered.


All of the IAP SDKs in this post target Chinese users.


Both SMS sending and SMS blocking will only affect Android phones with a valid Chinese mobile phone number.


Some of them will even check which SIM operator a user is using (Figure 6).


However, we’ve found Android games using these IAP SDKs being downloaded by users in other Asia Pacific areas.


An interesting observation is that half of these IAP SDKs implement the send and block SMS functions in separate codes.


More specifically, the code was separated into two parts.


One piece is embedded into Android apps or games for developers as a part of the source code.


The other piece is included separately in the assets directory in APK files, and will be invoked by Java reflection in runtime (Figure 7).


For example, JoloPay, WiPay, TPADPay and EgamePay follow this design exactly.


AstepPay implements both sending and blocking in the “assets/astep.bin” file.


This separation of functions may be intended to avoid detection by security products.


SMS should not be used in payment or authentication for e-finance transactions.


On the existing Android platforms it is very easy for any installed apps to send, intercept, or even forward SMS messages in background without any user knowledge or interaction.


Previous attack cases, such as Zitmo and Cardbuyer, showed the risk of using SMS for payment authentication.


For instance:  To improve the security of IAP, some payment platforms try to add a verification step in order to confirm an SMS was really sent by the user, for example, it will ask the user to reply with certain text that was sent to a phone number specified by the user.


However, two months ago, WildFire discovered a new Android malware, Cardbuyer, that circumvents this verification technique.


Cardbuyer targets 11 different online payment platforms, as well as stolen prepaid cards, by parsing their verification SMS and automatically replying.


The good news is this technique might be partially mitigated in Android KitKat (version 4.4), where Google introduced a security enhancement around SMS security.


A user can set a system-wide default SMS app as the only app with permission to send and receive SMS.


However, other installed apps are still allowed to receive SMS and upload the content via Internet.


But as of June 4, 2014, only 13.6% of worldwide users had installed Android 4.4 or above.


This means more than 86% of Android users do not benefit from this enhancement and are vulnerable.


However, Palo Alto Networks users are protected from these PUAs by subscribing to WildFire and GlobalProtect services.


SMS-based IAP SDKs have become a gray zone that needs close attention.


Because of convenience and popularity, SMS-based IAP will likely continue to spread and increase in worldwide use.


However, users need to be protected from PUAs and malware that abuses the SMS-based IAP.


Also, developers need to be aware that SMS cannot meet security requirements (e.g. authentication) during the payment transactions.


We would like to thank Kyle Sanders for his contribution to this work.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  Palo Alto Networks Unit 42


used the AutoFocus threat intelligence service to identify a series of phishing attacks against Japanese organizations.


Using AutoFocus to quickly search and correlate artifacts across the collective set of WildFire and other Palo Alto Networks threat intelligence, we were able to associate the attacks with the group publicly known as “DragonOK.”


[1] These attacks took place between January and March of 2015.


DragonOK has previously targeted Japanese high-tech and manufacturing firms, but we’ve identified a new backdoor malware, named “FormerFirstRAT,” deployed by these attackers.


See the “Malware Details” section for analysis of the three RATs and two additional backdoors deployed in this persistent attack campaign.


This campaign involved five separate phishing attacks, each carrying a different variant of Sysget malware, also known as HelloBridge.


The malware was included as an attachment intended to trick the user into opening the malware.


This included altering the icon of the executable to appear as other file types (Figure 1) as well as decoy documents to trick users into thinking they had opened a legitimate file.


Figure 1. Icons used by malicious Sysget attachments.


All of the Sysget files used in this campaign communicate with a single command and control (C2) server, hosted at biosnews[.]info.


Sysget communicates with this server using the HTTP protocol; see the Malware Details section for specifics of the command and control traffic.


All five phishing campaigns targeted a Japanese manufacturing firm over the course of two months, but the final campaign also targeted a separate Japanese high-tech organization.


(Figure 2)


Figure 2.


Five Sysget samples used to target two Japanese organizations.


Four of the five Sysget variants included a form of decoy document to trick users into believing they had opened a legitimate file rather than malware.


Two of the executables used decoy documents that included information about obituaries.


Figure 3 shows a GIF file containing an obituary notice for a woman, while Figure 4 shows a Microsoft Word document containing the obituary of a man.


Figure 3. Japanese decoy document containing an obituary notice for a woman.


Figure 4. Japanese decoy document containing an obituary notice for a woman.


The Sysget sample with a PDF icon created a second executable, named Adobe.exe, which simply displayed the following warning.


Figure 5. Error message generated by Adobe.exe


The final Sysget sample used a Microsoft Excel icon and opened an Excel document that contained cells filled with “XXXXXX.”


(Figure 6)  Figure 6.


Excel spreadsheet with Xs in multiple rows and columns.


These Sysget variants appear to be a first stage payload in these attacks.


During analysis of this threat, we identified five additional backdoor tools hosted on biosnews[.]info which may be downloaded by the Sysget variants once the attackers have established a foothold.


Three of the backdoors, NFlog, PoisonIvy, and NewCT have previously been publicly associated with DragonOK.


Additionally, the actors have now added the popular PlugX backdoor to their toolkit.


An additional backdoor appears to be a new, custom-built tool, which we have not previously associated with DragonOK or any other attack group.


We’ve named this tool “FormerFirstRAT” as it appears to be the names used by the developers to refer to their creations.


Figure 7 shows the relationship between these backdoors and their respective command and control servers.


Figure 7. Relationship between five additional backdoors used by DragonOK and their C2 servers in this campaign.


The following section details the functionality of the malware deployed in this campaign.


Sysget/HelloBridge


In this campaign, Sysget samples were attached to e-mails and used various icons to trick users into infecting their systems.


The majority of these samples are self-extracting executables that contain both a malicious downloader, along with a legitimate file.


When the self-extracting executable is launched, the downloader and legitimate file are typically dropped in one of the following directories and then executed:  When the malicious downloader is executed, it begins by creating the 'mcsong[]' event in order to ensure one instance is running.


It then spawns a new instance of 'C:\\windows\\system32\\cmd.exe' with a window name of 'Chrome-Update'.


It attempts to obtain a handle to this window using the FindWindowW API call and then proceeds to send the following command to this executable.


This allows the malware to indirectly execute a command within the cmd.exe process.


This registry key will ensure an executable that it later downloads is configured to persist across reboots.


It then sends the 'exit' command to this executable, which will kill this particular process.


The malware then attempts to read the following file.


This file is used to store a key that is later used to decrypt data received during network communications.


If the file does not exist, it will make the following GET request:  The filename and name parameters are statically set in the above request.


The server responds with data similar to the following:  The first two pieces of data ('17' and 'gh204503254') are then written to the ibmCon6.tmp file referenced earlier.


The malware will copy itself to the %TEMP% directory with the executable name of 'notilv.exe'.


Due to the previously written registry key, this file will execute when the machine is restarted and the current user logs in.


The malware then makes the following request:  The filename and uid parameters are statically set in the above request.


The response data is decrypted using the RC4 cryptographic stream cipher.


The 'gh204503254' data that was previously downloaded is used as the key.


The following Python code can be used for decryption, using the 'gh204503254' key:  At this stage, the remote server can send a number of different responses.


The following example response will instruct the malware to download a remote executable file:  'filename.exe' is the path where the downloaded file will be stored, and '01234567890123456789012345678901' is the value supplied in the subsequent HTTP request.


When this command is received, the following example request is made:


At this point, the remote server will respond with an unencrypted file that the malware saves to the system.


The remote server can also send the following example response.


This response will instruct the malware to upload the specified file:


An example upload request can be seen below:  The remote server can also send the following example response.


This response will instruct the malware to execute the given command:  The results of this -execution are stored in a temporary text file in the %TEMP% directory.


These results are encrypted using the same technique mentioned previously.


An example upload of these results can be seen below:  PlugX  PlugX is a backdoor that is often used by actors in targeted attacks.


This version of PlugX attempts to disguise itself as a Symantec product.


The following icon is present in this sample:  Figure 8.


PlugX file uses Symantec logo icon.


Upon execution, the malware will install itself as a service with the following parameters:  It may also set the following registry key for persistence:


PlugX is a well-studied malware family with a long history of use in targeted attacks.


More information on its history is available at the following links.


FormerFirstRAT  This remote administration tool (RAT) is referred to as “FormerFirstRAT” by its authors.


FormerFirstRAT communicates using unencrypted HTTP over port 443; the use of mismatching ports and communication protocols is not uncommon in targeted attack campaigns.


In addition, port / protocol mis-match traffic can be an indicator of bad activity.


When the malware starts, it writes the following registry key to ensure persistence:  The malware then proceeds to send an HTTP POST request with information about the victim system.


The following information is collected:


The following settings are used for command and control:  The malware encrypts network communication using the AES128 encryption cipher.


It uses the MD5 of 'tucwatkins' in order to generate the key.


All data is sent via HTTP POST requests.


While not a distinct TTP, the author of this malware may be a soap-opera fan.


The following code demonstrates how you can decrypt the malware communications using Python:  The malware then enters a loop where it will send out periodic requests to the remote server.


The remote server has the ability to respond and provide instructions to the RAT.


We have identified the following functionalities:


An example HTTP POST request can be seen below.  NFlog  When loaded inside of a running process, NFlog begins by spawning a new thread.


This new thread is responsible for all malicious activities produced by this DLL.


Initially, the malware will set the following registry key:  Where [current_executable_filename] is the path to the current running executable, which is acquired via a call to GetModuleFileNameA.


This registry key ensures that the malware will persist across reboots when the current user logs in.


Multiple string obfuscation routines are included in this malware sample.


Strings contained in the binary are decrypted via a simple binary XOR against a single byte key of 0x25.


The malware proceeds to create a named event object of 'GoogleZCM' and uses this event in order to ensure only one instance of this malware is running at a given time.


The malware proceeds to make an attempt at binding to the local host on port 1139.


The malware attempts to ensure Internet connectivity by making a request to www.microsoft.com.


An example request is shown below.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  Beginning on Jan. 14, 2022, reports began emerging about a series of attacks targeting numerous Ukrainian government websites.


As a result of these attacks, numerous government websites were found to be either defaced or inaccessible.


As a result of this, the government of Ukraine formally accused Russia of masterminding these attacks against their websites.


A day later, public reporting outlined new malware called WhisperGate that originally was observed on Jan. 13, 2022.


This malware disables Windows Defender Threat Protection, is destructive in nature and was discovered to have targeted multiple organizations in Ukraine.


Microsoft has publicly attributed the use of this custom malware to a threat actor they refer to as DEV-0586.


Though both attacks have targeted Ukrainian organizations, the two threats have so far been implemented in separate situations.


As a result of these events, Palo Alto Networks researchers took immediate action to ensure that customers anywhere in the world can be appropriately protected against these reported threats, however they may be exploited.


These attacks ultimately resulted in the investigation of the following two threats:  Palo Alto Networks customers can use Xpanse or Threat Prevention for the Next-Generation Firewall to identify vulnerable and/or internet-facing instances of OctoberCMS.


Protections against WhisperGate malware have been included in Cortex XDR, as well as in the WildFire and Advanced URL Filtering subscriptions for the Next-Generation Firewall.


There is a Cortex XSOAR pack available to assist with detecting and mitigating both threats.


CVE-2021-32648 Vulnerability WhisperGate Malware Family Mitigation Actions Hunting for WhisperGate Conclusion Additional Resources


The CVE-2021-32648 vulnerability lies within the OctoberCMS platform prior to version 1.0.472 and results in an attacker gaining access to any account via a specially crafted account password reset request.


This vulnerability is believed to have allowed threat actors to gain access to the underlying websites leveraged by the Ukraine government.


Once the vulnerability was discovered, Palo Alto Networks threat researchers quickly began reverse-engineering the patch that remediated this vulnerability and were able to produce a working proof of concept (PoC) in a very short time.


Later that day, a public PoC surfaced, allowing organizations to better understand this vulnerability and how it is exploited.


Using our PoC, we created the following demonstration video of how a malicious actor would exploit the CVE-2021-32648 vulnerability, log into the compromised OctoberCMS account and to deface a web page hosted by the server:


To determine how this vulnerability was exploited, we analyzed the patch that developers added to OctoberCMS version 1.0.472 to mitigate the CVE-2021-32648 vulnerability.


We discovered that the vulnerable code existed in the Auth/Models/User.php file within the October Rain library of OctoberCMS.


The code that exposes this vulnerability is within a function named checkResetPasswordCode, specifically, line 281 in User.php.


The following line of code attempts to validate the inbound password reset request by comparing the reset code submitted within the HTTP request with the reset code generated by OctoberCMS during a legitimate reset process:  To exploit this vulnerability, the actor would simply supply a boolean true value as the reset code within a custom-crafted HTTP request to reset the password of an account.


By supplying the boolean true, the comparison between boolean true and the reset code string results in a boolean true, even though the two variables have different types.


This effectively validates the actor’s inbound password reset request, which allows the actor to then change the password  To fix this vulnerability in version 1.0.472, the OctoberCMS developer changed the line of code above to use === instead of == when comparing the values of the reset code provided by the user via an HTTP POST request.


The difference between === and == involves the === comparing the value and type of value of the variable, not just the value, as happens when using ==.


To demonstrate the difference, the following two commands run PHP code to show that a comparison of the string code with boolean true using == results in a boolean true, while the same comparison using === results in a boolean false:  As a result of the analysis of the CVE-2021-32648 vulnerability, various product protections were created or enhanced.


More information about these protections can be found within the Mitigation Actions section of the briefing.


First observed by Microsoft on Jan. 13, 2022, WhisperGate malware is computer network attack (CNA) malware aimed at deleting Microsoft Windows Defender and corrupting files on the target.


It consists of two samples: One appears as ransomware while the other is a beaconing implant used to deliver an in-memory Microsoft Intermediate Language (MSIL) payload.


The in-memory code uses Living Off the Land Binaries (LOLBINs) to evade detection and also performs anti-analysis techniques, as it will fail to detonate when certain monitoring tools exist.


At the time of writing, there are two known samples identified as WhisperGate: Stage1.exe and Stage2.exe.


Stage1.exe purports to be ransomware, as it overwrites the target’s master boot record with 512 bytes and upon reboot displays the following ransom note:  Stage2.exe is a beaconing implant that performs an HTTPS connection to download a JPG file hosted on Discord’s content delivery network (CDN).


Discord’s CDN is a user-created service that allows users to host attachments and is not malicious.


The hosted file is retrieved from the following URL:  hxxps://cdn.discordapp[.]com/attachments/928503440139771947/930108637681184768/Tbopbh.jpg


File Tbopbh.jpg is the malicious payload that is in-memory loaded and kicks off the destructive capabilities.


The following patterns of activities are associated with this payload:  1. File InstallUtil.exe is copied to the host’s %TEMP% directory, e.g. C:\Users\[USERNAME]\AppData\Local\Temp.


This file is a legitimate Microsoft Windows binary.


Two instances of PowerShell are spawned with an encoded command to sleep for 10 seconds, e.g. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -enc UwB0AGEAcgB0AC0AUwBsAGUAZQBwACAALQBzACAAMQAwAA== 3.


A Visual Basic Script (VBS) is created in C:\Users\[USERNAME]\AppData\Local\Temp named: Nmddfrqqrbyjeygggda.vbs  4. Process wscript.exe is used to execute the VBS script in step 3.


The VBS script is used to call PowerShell to set Windows Defender exclusion path to C:\ e.g. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" Set-MpPreference -ExclusionPath 'C:\'  5. AdvancedRun.exe is created and written to the C:\Users\[USERNAME]\AppData\Local\Temp directory.  6.


AdvancedRun.exe is used to execute PowerShell.exe to delete and stop Windows Defender.


The following command parameters are passed to AdvancedRun:  "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" /WindowState 0 /CommandLine "rmdir 'C:\ProgramData\Microsoft\Windows Defender' -Recurse" /StartDirectory "" /RunAs 8 /Run  "C:\Users\USERNAME]AppData\Local\Temp\AdvancedRun.exe" /EXEFilename "C:\Windows\System32\sc.exe" /WindowState 0 /CommandLine "stop WinDefend" /StartDirectory "" /RunAs 8 /Run  7.


PowerShell process used to delete Windows Defender, e.g. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe rmdir 'C:\ProgramData\Microsoft\Windows Defender' -Recurse  8. File InstallUtil.exe running from C:\Users\[USERNAME]\AppData\Local\Temp directory.


The in-memory payload (Tbopbh.jpg) is running within the context of the InstallUtil.exe process  9. Multiple instances of cmd.exe calling Ping.exe to delete file InstallUtil.exe, e.g. cmd.exe /min /C ping 111.111.111[.]111 -n 5 -w 10 > Nul & Del /f /q %TEMP%\InstallUtil.exe  10. File AdvancedRun.exe is deleted from the C:\Users\[USERNAME]\AppData\Local\Temp directory by the stage2.exe binary.  11. ICMP traffic to host: 111.111.111[.]111  12.


All files and directories, including those on mounted USB drives, excluding the floppy drive (A:) are targeted.


The following file extensions are overwritten with a one-byte value of 0xCC.


13. Targeted files greater than one megabyte are truncated to one megabyte when overwritten.


14. Virus & Threat protection is no longer available from Windows Security.


Organizations running OctoberCMS prior to Build 472 and v1.1.5 are encouraged to update to the latest version.


Additionally, in order for this vulnerability to be exploited, the web server must be running PHP below 7.4.


Palo Alto Networks customers receive protections against the OctoberCMS vulnerability in the following ways:  Palo Alto Networks customers receive protections against WhisperGate malware in the following ways:  The Cortex XSOAR "WhisperGate & CVE-2021-32648'' pack can help automatically detect and mitigate the two threats.


Read more on the XSOAR marketplace.


If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call North America Toll-Free: 866.486.4842 (866.4.UNIT42), EMEA: +31.20.299.3130, APAC: +65.6983.8730, or Japan: +81.50.1790.0200.


Palo Alto Networks Cortex XDR customers may leverage the following XQL queries, written by the Cortex Managed Threat Hunting service experts, to hunt their datasets for indicators related to WhisperGate malware:  The Unit 42 Threat Intelligence team remains vigilant in monitoring this evolving situation, is actively hunting for known indicators from recent events and is ready to put protections in place to thwart attacks against our customers.


Product-specific protections have been implemented as a result of research performed in recent days, and those protections will be augmented as needed as more details come to light.


Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.


Updated March 4, 2022, at 6:15 a.m. PT.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


At 06:47 PST on May 20 Palo Alto Networks WildFire detected the start of the latest Kuluoz spam campaign.


The total number of e-mails detected quickly rose to over 30,000 per hour around noon PST and had not begun to slow down as of 1:30PM PST.


Kuluoz is a descendant of the Asprox malware and spreads by sending copies of itself as an e-mail attachment.


As the malware infects more systems, the systems begin sending more e-mails which leads to more infections.


Kuluoz makes money for its owner by installing other malware, such as crimeware or fake antivirus programs.


Kuluoz e-mails often trick the reader into thinking they are delivery notifications (such as UPS or Fedex), or notices from airlines or payment processors.


In this case the e-mails claim to contain a document about a court case.


Subject: Hearing of your case in Court


From: Notice of Appearance  Pretrial Notice, Please, download the copy of the court notice attached herewith to read the details.


Note: The case may be heard by the judge in your absence if you do not come.


Truly yours, Clerk to the Court.


Olivia Smith


Each e-mail carries one of the following attachments:  These attachments are different versions of the malware that has been packed to evade antivirus engines.


Twelve of the 53 scanners on virustotal.com now detect the first variant of the malware, but only three detect the latest version.


To determine where the highest number of infected nodes are, we mapped the sending IP address for each of the attach e-mails to their rough geographic location.


While there are infected systems around the world, the largest concentration is in North America, particularly the United Stats and Canada.


Geographic Distribution of Koluoz Spam Nodes in North America  Thus far we’ve detected the following command and control servers in use.


The network traffic generated by each Trojan uses the HTTP protocol, and despite its use of port 443, is not encrypted with SSL.


As with most fast-spreading malware, antivirus engines will typically begin detecting the files a day or two after the spread has begun.


While we haven’t seen any indication that the spam volume has begun to slow down, we do expect the campaign to wind down in the next 24 hours, but a new campaign will probably be close behind.


WildFire users can rest assured that they’ll be protected from whatever Kuluoz has in-store next.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Following a recent study of apps in the Google Play Store, let’s discuss several security risks caused by the bad certificate management practiced in many Android apps, from social to mobile banking.


All Android apps must be digitally signed with a certificate from the developer.


As described in Google’s official document, the app developer is required to create a keystore with a set of private keys, and then use the private key to generate a signed version of apps.


This key has to be valid for at least 25 years.


These certificates do not have to be generated by a certificate authority and can instead be self-signed.


Because this is simpler and allows the author to retain the private key, the majority of Google store apps use self-signed certificates.


This means it is the developer’s responsibility to keep the private key safe, whether that developer is a 13-year-old or a multi-national company.


As this means the security protecting private keys varies widely, the security risks of bad certificate management cannot be ignored and must be identified, and where necessary, mitigated.


Security researchers are starting to take note and publish on this subject.


For example, BlueBox recently revealed the Fake ID vulnerability, which exploits an app’s certificate verification process within the Android OS.


If they haven’t already


, soon attackers and malware authors will turn their attention to exploiting vulnerabilities surrounding Android app certificates.


When an app is published to the Google Play Store, the certificate information is included within the APK file.


To view the certificate information just open the given APK file as a zip file.


The certificate information is stored within the certificate’s  “/META-INF” folder.


You can use keytool or openssl tools to view the certificate information.


An example taken from the popular Angry Birds app is shown in Figure 1.


The certificate fingerprints (circled in red) are what can be used to uniquely identify a certificate.


Figure 1  These digital certificates, self-signed or not, are the keys to updating apps in the Android ecosystem.


It is a primary reason the expiration dates are set so far into the future and developers are able to self-sign certificates.


The only way to update an app is for the developer to sign the update with the same digital certificate originally used to publish the app.


If a developer wants to use a different certificate, they must publish the update separately as a new app.


Furthermore, all Android apps published using the same certificate have a trust relationship between them.


Android allows apps signed by the same certificate to run in the same process and treats them as one single application instead of separate ones.


It also allows multiple apps with the same certificate, if using signature-based permission checks, to expose functionality and exchange code and data amongst themselves.


This is convenient for developers, which is great, but it is also convenient for hackers, which is not.


Losing control of a certificate’s private key, or using an insecure private key, can have severe security consequences.


For example, if an attacker obtained the private key of an app, he or she could create a fake APK file, sign it using the same certificate as the legitimate app, and replace the targeted app with fake app on the device silently using the “Application upgrade” procedure.


In addition, if the attacker can’t create an app with the same name as the targeted app, he or she can still check the “SharedUserId” option.


This allows apps with different package names but signed with the same certificate to share permissions and stored data.


Because of this, app developers should be extremely careful about re-using certificates when signing their apps.


Ideally, an app developer should generate a unique private key for each unique app they post in the Google Play Store.


Unfortunately, during our study of apps posted in the Google Play Store we collected approximately 246,000 Android apps but only 11,681 certificates.


The distribution of the number of apps sharing the same key is shown below.


The X-axis is the number of apps sharing the same certificate.


The Y-axis is the number of certificates.


For example, the number of certificates used by only one app is 1,323.


About 6,925 certificates are used to sign between 6 and 19 different apps.


Figure 2


As we see in this distribution, a lot of developers sign different apps with the same certificate.


We further investigated the following cases:


1. Signing apps with a publicly known private key  Many key pairs are well known in the development community.


The most famous set of key pairs would be the key pairs included within the AOSP source files (in Table 1, below).


More key pairs can be found in developer forums and academic research.


Table 1  If one app is signed using the publicly known private keys, it is easy for other apps on the same device to replace this vulnerable app with another APK file, silently with no user knowledge or interaction.


We scanned our inventory of APK files downloaded from the Google Play Store and found at least 87 apps using the “testkey” in Table 1.


According to the Google Play Store, these 87 apps have been downloaded more than 1.6 million times.


For security reasons we are not posting the names of any of these apps.


Under no circumstances should developers ever use private keys that are publicly available, nor should users download them.


However, it isn’t easy for users to know the app they’re downloading is using a compromised private key – the onus for this is squarely on developers.


2. Mobile banking apps sharing one single key  Mobile banking apps are particularly sensitive with significant security concerns, which is why we were surprised to discover one certificate was used to sign more than 300 mobile banking apps in the Google Play Store.


This practice is not necessarily dangerous, as long as the developer does not share the key with the various banks that contracted the applications.


We’ve contacted the developer to confirm they have retained sole custody of the keys.


Of course, even with out-sourced application development, app owners should prefer to hold their own key.


Whoever controls the key controls updates for the application forever, and a key shared between applications in this way can never be transferred to a financial institution without compromising the security of all of the other apps signed with it.


The developer is aware of this concern and plans to encourage more of its customers to sign their own applications in the coming year.


In addition to our research, the Baidu Security team in China recently found 23 mobile banking apps sharing the same certificate hosted by a third party app developer and reported the discovery to the CNCERT in China.


3. Third party app developers using the same key for all apps generated for all customers


The app developer industry is booming.


These developers help customers build mobile apps for their businesses easily and quickly.


They serve an important role for the majority of businesses that do not have in-house developers.


Unfortunately, we uncovered some of these developers using the same certificate for every app.


Again, using the same private key is probably due to the convenience in app management.


But as we noted earlier, apps signed by the same certificate can automatically grant sharing relationships amongst themselves.


This means all of the apps created by these developers, regardless of intended use, could be used maliciously.


Table 2 shows select top app developers using the same certificate in signing all their apps.


For security reasons, we have masked the names.


Table 2  Digital certificates are a critical component of the security of Android apps.


Unfortunately, many app developers in the Google Play Store have ignored these concerns in favor of convenience.


While in some cases that may be justified – the app may not contain any important or identifying information – in many of the cases we discovered it is not.


This poses great potential security risks to both app users and app owners.


We encourage developers to reconsider their stance on this issue and where necessary make changes before a significant security event happens.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


A backdoor implant is an increasingly common mechanism for maintaining unauthorized access and control over a computer asset.


The terms remote administration tool (RAT) and trojan downloader are often used synonymously with such implants.


Once installed (i.e. implanted on a system), the modern backdoor typically offers much more than simple (i.e. command line) access to a system.


Depending on the backdoor’s specialization and sophistication, it can also capture keystrokes, take screenshots, scrape memory for valuable information, search for files meeting certain criteria, query databases, download files and additional malware, exfiltrate data and files, and even serve as an attack platform.


Effectively, a backdoor implant affects loss of control over a computer asset.


The tangible and intangible impacts of this loss of control vary based on respective backdoor capabilities, and may include the following: leakage of authentication credentials, loss of intellectual property, exposure of sensitive information, negative standing or reputation, and various levels of liability for actions executed on or from the compromised asset.


Recently Palo Alto Networks discovered a backdoor program ( md5: b826fb1253a52a3b53afa3b7543d7694, sha256: 6bedd1b0716fe7632188932451f75295346836545e6d2bfee1b56121e02ca110 ) that is used to control a linux operating system.


This particular linux backdoor will install itself to "/usr/bin/btdaemon" and create a startup service at "/etc/init.d/bluetoothdaemon" with symbolic links so that it will run in any startup mode.  The file contents are a simple bash script that runs the original btdaemon file.


The backdoor when run will create threads for each connection listed in its config file.  The sample that was caught by our systems contains 3 IP addresses in its config file.


For each IP address the btdaemon service will attempt to make a connection on UDP ports 53, 80, 110, and 443.


Upon successful connection it will send the string "¡°MlCROS0FT|1.2 Apr 26 2014  02:37:05|Linux Kernel Version¡±" and will wait for an "Auth" packet from the server.


If the backdoor receives a packet in the form of a "cmdType|cmdBody" it will check the cmdType list and execute the equivalent instruction.  Valid instructions are between 0-9 and there functionality varies depending on the command.