mrmoor/cyber-threat-intelligence huggingface dataset:
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.
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.
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.
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.
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.
While running the btdaemon process also inspects whether there is an ".IptabLes" or ".IptabLex" local process, and sends back status for monitoring purposes.  If the "disablerun" command is sent the backdoor will download a file named "run.txt" from one of the following URLs:  The file data is in the format "exe_path_1 | exe_path_2 | ... | exe_path_N".  If none of the paths is correct then a "getsetup.rar" file is downloaded and run.
This is an ELF file and there are various encrypted portions within it.
There exist two embedded zlib-encrypted blocks at file offset 0x8C0C0 and 0xE6B40 respectively.
When run if the filename does not include the "IptabLes" string then the data is decrypted, written to disk, and then executed, installing itself as a startup service on the machine and place itself in one of the following locations:  The second encrypted block is configuration data, which includes some IP addresses and DNS data which is used when it writes the first decrypted block to a file.
"dns.po888.com|122.228.242.51|119.145.148.56|162.221.13.82".
If the file is run in a path including the "IptabLes" string then it installs itself as a startup service and proceeds into its main loop.
Either path the "getsetup.rar" file takes is meant to ensure that it is installed as a startup service, ensuring persistence.   Once the file is running it creates a process identifier (PID) so that only one instance is running at any given time.
The file will connect to an IP and port configured from the configuration data and sends along information that includes the cpu and memory information.
If the file does not receive any data within 30 seconds it will send a "xy" response back to the server.
If the file does receive data from the server in excess of 20 bytes it will be in the following format:  <2 byte data length><0xABCDEF88><zlib-encrypted data>  The decrypted data will contain the following fields:  The attack type field is used to determine if a SYN DDoS or DNS DDoS is used in an attack.
The Src IP Begin and End are the start and ending IP ranges used as a fake src addresses in the DNS DDoS.  The IP range can also be controlled by global variables within the binary itself as well.
If the received data has 0x22 as the first set of bytes then the received data will be in the following format:  <0x22><IP Address 1(4bytes)><IP Address 2 (4bytes)>  It will also do the following UDP connection test:  If the first value in the packet is 0xC8 then the file will set "g_mainsrvinfo.srandipb" and "g_mainsrvinfo.srandipe" and "g_mainsrvinfo.udpport" to the passed in values.
If the first value in the packet is 0xCC then the file will set "g_mainsrvinfo.srandipb" and "g_mainsrvinfo.srandipe".  If the first value in the packet is 0x33 the file will use tcp to download a file and execute it.
If the first value in the packet is 0x20 the file will delete all DDoS tasks.
If the first value in the packet is 0x10 then the file will send back the current socket handle as a response back.
Currently these IP addresses are alive and active.
Palo Alto Networks strongly recommends you inspect your systems and update your firewall rules and IPS systems.  Palo Alto Networks customers with active subscriptions to Threat Prevention are protected against these threats automatically, signature #13469 was released to protect against this specific threat.
Similar to any other malware family or threat, Palo Alto Networks customers should use the entire security framework for threat mitigation and threat prevention coverage.  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!
This post is also available in:      日本語 (Japanese)  In July 2020, Microsoft released a security update, CVE-2020-1350 | Windows DNS Server Remote Code Execution Vulnerability, for a new remote code execution (RCE) vulnerability.
This vulnerability exists within the Microsoft Windows Domain Name System (DNS) Server due to the improper handling of certain types of requests, specifically over port 53/TCP.
Exploitation of this vulnerability is possible by creating an integer overflow, potentially leading to remote code execution.
This vulnerability only affects Windows DNS and the following builds of the Microsoft Windows operating system (OS):
As always, we recommend our customers patch their systems as soon as possible.
Microsoft also provided a workaround in cases where patches are not immediately possible.
Please review KB4569509: Guidance for DNS Server Vulnerability CVE-2020-1350 for more details.
Palo Alto Networks Threat Prevention and Cortex XDR provide protection against the exploitation of this vulnerability:  Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
Overview Palo Alto Networks Unit 42 threat research team has just uncovered a new set of attacks by the Sofacy group using malicious emails targeting foreign affairs agencies and ministries in North America and Europe, including a European embassy in Moscow.
Given the significant activity attributed to Sofacy, and the new evidence directly targeting the diplomatic community, Palo Alto Networks wants to ensure that foreign affairs agencies around the world understand how the attacks are carried out, and what agencies and personnel can do to protect themselves.
The Sofacy Group (AKA APT28, Grizzly Steppe, Fancy Bear, STRONTIUM, Sednit, Tsar Team, Pawn Storm) is a well-known hacking organization widely reported to be associated with Russia by the US Intelligence Community, numerous media reports and other cybersecurity companies.
Sofacy Group has been associated with many attacks against targets around the world, including the International Olympic Committee (IOC) in 2018, the World Anti-Doping Agency in 2016, the Dutch Safety Board in 2015, and German, French, Ukrainian, and Dutch political and military targets throughout 2014 through 2018.
How the Attacks are Carried Out: Via Email
These attacks begin with an email sent to a carefully chosen target in the agency.
The recent spoofed emails we have seen are forged to appear to come from Jane’s 360 Defense Events to tell the recipient about events coming up in 2018.
The figure below shows an example.
Once the recipient opens the Excel spreadsheet, she or he does have trouble viewing the document: it opens as a blank spreadsheet.