mrmoor/cyber-threat-intelligence huggingface dataset:
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).
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.
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).
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.
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)
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.
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.
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.