mrmoor/cyber-threat-intelligence huggingface dataset:
Palo Alto Network customers running Cortex XDR version 7.3 with the latest content update are protected from “Pass-the-Ticket” attacks using the standard Windows API.
Customers running Cortex XDR Pro with analytics enabled will get alerted on related suspicious activities and specifically on a delegation from or to a protected user.  Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
Sign up to receive the latest news, cyber threat intelligence and research from us
Situation Overview
On August 22, 2018, the Apache Foundation released a critical security update for CVE-2018-1176, a remote code execution vulnerability affecting Apache Struts versions 2.3 to 2.3.34 and 2.5 to 2.5.16.
The Apache Foundation has urged everyone to apply the security updates as soon as possible.
This blog is to provide information to help organizations assess their risk of the vulnerability and to inform Palo Alto Networks customers of protections in place that can help mitigate their risk until they can apply the security updates.
Palo Alto Networks customers who have deployed the latest vulnerability signatures released on August 24, 2018, are protected.
Vulnerability Information
According to both the Apache Foundation and security researcher Man Yue Mo, this vulnerability can enable remote code execution on a server running a vulnerable version of Apache Struts.
The method of attack would be through a specially crafted URL sent to the vulnerable system.
In most cases, this means no authentication is required to exploit the vulnerability.
A successful attack would run code in the security context that Struts is using.
In some cases, this could effectively lead to a total compromise of the system.
It’s important to note, however, that the vulnerability is not exploitable in default configurations.
The following two conditions must both be met for a system to be vulnerable to attack:  If your Struts application does not meet both of these conditions, your application may still be vulnerable but not (currently) exploitable via CVE-2018-11776.
In particular, if your application uses the popular Struts Convention plugin, it appears to potentially increase your risk of exploitability vis-à-vis other Struts implementations that do not use that plugin.
Threat Environment Information
The vulnerability was disclosed on August 22 in conjunction with security updates that address it.
There is detailed information about the vulnerability and how to exploit it available currently.
There is also proof of concept (PoC) code available already.
As noted above, the PoC works only against systems that are vulnerable and meet both conditions for exploitability.
Some have noted that a previous critical Struts vulnerability was actively attacked last year only three days after the release of the security update and vulnerability information.
There are no known active attacks at this time and the current requirement that two, non-default conditions need to be met for the vulnerability to be exploitable makes for a different threat environment.
However with active PoC available we can expect at the minimum probing, if not active exploitation of this vulnerability in the near term.
Organizations should focus their risk assessments for possible attack until they can patch on four things:  Guidance and Protections for Palo Alto Networks Customers
All organizations running vulnerable versions of Apache Struts should deploy the security updates as soon as possible.
Organizations can and should prioritize scheduling and deployment of the security updates based on their security policy and risk assessment, and  on currently available information.
Palo Alto Networks customers who have deployed vulnerability signatures in content release version 8057 released on August 24, 2018, which include ID 33948 Name: Apache Struts 2 Remote Code Execution Vulnerability, are protected against currently known exploits against that vulnerability.
Our customers should still deploy the security update as recommended above, but can and should deploy the latest vulnerability signature immediate for additional protection.
With this addition protection available, our customers can and should include that as part of their decisions around security and deployment of the security updates and their risk assessment of the vulnerability and threat environment.
As always, we are monitoring the situation closely and will provide additional details as they become available.  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.
On May 27, 2022, details began to emerge of malicious Word documents leveraging remote templates to execute PowerShell via the ms-msdt Office URL protocol.
The use of this technique appeared to allow attackers to bypass local Office macro policies to execute code within the context of Word.
Microsoft has since released protection guidance and assigned CVE-2022-30190 to this vulnerability.
Due to the amount of publicly available information, ease of use, and the extreme effectiveness of this exploit, Palo Alto Networks is providing this threat brief to make our customers aware of this critical vulnerability and the options available to ensure proper protections are put into place until a patch can be issued by Microsoft.  The vulnerability enables remote code execution with the same privileges as the calling application and there are proof-of-concept examples of zero-click variants.
Therefore, exploits for this vulnerability have potential to be of high impact.
We highly recommend following Microsoft’s guidance to protect your enterprise until a patch is issued to fix the problem.
All known samples and URLs associated with this attack have been flagged in the Palo Alto Networks product suite so customers can receive protections.  Attack Details for CVE-2022-30190 CVE-2022-30190 in the Wild Conclusion  On May 27, 2022, a cybersecurity research team out of Tokyo, Japan, nao_sec, uncovered a malicious Word document uploaded to VirusTotal from an IP in Belarus.
The document was abusing the Microsoft Word remote template feature to retrieve a malicious HTML file that subsequently used the ms-msdt Office URI scheme to execute PowerShell within the context of Word.
On May 30, Keven Beaumont wrote an article detailing the specifics of the initial incident.
The important thing to note here is that the decoy Word document had nothing inherently malicious outside of the link to the template hosted at hxxp://xmlformats[.]com, allowing it to bypass EDR solutions.
The HTML code from the remote template is shown in Figure 1 below.
The JavaScript embedded within the HTML uses the ms-msdt schema to invoke the PCWDiagnostic pack, to reference the IT_BrowseForFile to execute the base64-encoded PowerShell Invoke-Expression command.  The base64-decoded text within the PowerShell Invoke-Expression is shown in Figure 2 below.
This code does a few things.
First it kills the msdt.exe process.
Then the code loops through the files within a .rar archive looking for a CAB file (TVNDRgAAAA base64 decodes to MSCF, which is the magic header of a CAB file).
It then stores it in a file called 1.t. 1.t, which gets base64 decoded to 1.c, expanded to rgb.exe and then finally executed.
None of the reports we’ve seen have recovered the final payload.
Therefore, the contents are unknown.
The use of remote templates to deliver malicious documents is not new, however, historically they’ve been used to host .docm or dotm (macro-enabled Word documents), which would still be affected by the local systems’s Word macro policy.
Therefore, the vulnerability of particular note in this attack lies in calling the Microsoft Support Diagnostic Tool (MSDT) using the ms-msdt URL Protocol within Word via the remotely loaded template file.
This allows execution of code within the context of Microsoft Word, even if macros are disabled.
Protected View was triggered during execution of the nao_sec example, however, John Hammond demonstrated you can bypass Protected View by using an RTF file instead.
This allows the attack to succeed even if the user simply views the file in the preview pane – with no clicks on the document necessary – making the attack much more dangerous.
They provided a workaround to disable the MSDT URL protocol, however, this may break other diagnostic tools that rely on the MSDT URL protocol to operate.
They also recommend ensuring cloud-delivered protections and automatic sample submission for Microsoft Defender are enabled.
Microsoft recommends that customers of Microsoft Defender for Endpoint enable the attack surface reduction rule BlockOfficeCreateProcessRule.
So far, Palo Alto Networks is only seeing indications of testing within our customer telemetry indicated by final payload execution of benign executables such as calc.exe and notepad.exe.
Palo Alto Networks and Unit 42 will continue to monitor for evidence of exploitation and further novel use cases.
Based on the amount of publicly available information, the ease of use and the extreme effectiveness of this exploit, Palo Alto Networks highly recommends following Microsoft’s guidance to protect your enterprise until a patch is issued to fix the problem.
Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription can automatically block sessions related to this vulnerability using Threat ID 92623 (Application and Threat content update 8575).  WildFire and Cortex XDR categorize all known samples we’ve come across as malware.
Cortex XDR Agent 7.5 and higher (with content version 540-92526) prevents attempts to exploit this vulnerability with the Behavioral Threat Protection module.
The Cortex XSOAR “CVE-2022-30190 - MSDT RCE” playbook helps speed up the discovery and remediation of compromised hosts within the network.
The playbook can be found on the XSOAR marketplace.
Additionally, all encountered URLs have been flagged as malware within PAN-DB, the Advanced URL Filtering URL database.
Customers can leverage this service with best practice configuration for further protection.
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:  As further information or detections are put into place, Palo Alto Networks will update this publication accordingly.
Updated June 3, 2022, at 3:30 p.m. PT.
Palo Alto Networks recently identified a new campaign targeting the transportation sector in Europe with ties to the Dark Seoul and Operation Troy campaigns that took place in 2013.
This new campaign used updated instances of the Tdrop malware family discovered in the Operation Troy campaign.
For more information on the new campaign discovered by Unit 42, please refer to our recent blog post.
In this attack, attackers embedded the TDrop2 malware inside a legitimate video software package hosted on the software distributor’s website.
By doing this, they were able to target organizations that relied on the distributor’s security camera solution and infect their systems with malware.
They created a true Trojan horse, which sneaks into a network as a gift, but when opened, the attacker’s army leaps out.
The malware used for the attempted infection purported to be a legitimate video player, providing viewing software for security camera solutions.
The following two unique file names were involved in the attack.
The difference between the files involves the specific video player that was dropped and executed during runtime.
Each file would drop and execute the full or light version of the legitimate video player respective to the file name.
Both the legitimate copy of the video player, as well as a malicious executable were bundled into a single executable.
These files were added to the end of the Trojan executable, as seen below.
When initially run, the malware checks to see if its parent process is either explorer.exe or cmd.exe.
In the event the malware is not running in the context of either of these processes, it will exit.
This check exists in a number of the subsequent processes/executables used by the TDrop2 malware variant.
Subsequently, the malware proceeds to extract both the video player and the embedded malware using a series of calls to CreateFile, CreateFileMapping, GetFileSize, and MapViewOfFile.
Once extracted, the file writes it to a new file on disk prior to executing it.
The video player is written to one of the following locations, based on the original filename:  The malware itself is written to the %TEMP% directory as well.
The filename is derived by randomly choosing an executable name from the system32 directory.
The randomly chosen executable must not contain any of the following strings:  This dropped malware begins by performing the same parent process check witnessed in the original sample.
In the event the malware is not running within the parent process of cmd.exe or explorer.exe, it will exit immediately.
This malware sample will also dynamically load a number of functions and libraries.
After the kernel32.dll and ntdll.dll libraries are loaded via calls to GetModuleHandle, the following process takes place:
In total, the following 14 functions are loaded during runtime:
After these functions are loaded, the malware will randomly select an executable from the system32 using the same routine witnessed in the earlier sample.
The malware proceeds to spawn a new process of the selected executable and performs a technique called process hollowing to hide itself inside a legitimate executable.
This leads us to the next stage of our malware  This particular stage of malware acts as a downloader.
The parent process check is not used in this particular sample.
The malware initially attempts to download a file from the following location:
While the link above shows a file extension of an image, the transferred file is in fact a modified executable file.  The downloaded file has the first two bytes of the PE file format replaced with the characters ‘DW’, instead of the usual ‘MZ’.
After the download occurs, the malware immediately corrects the first two bytes with the ‘MZ’ characters prior to writing the file to disk.
The downloaded file is dropped to the system32 folder.
The malware selects a randomly chosen DLL from this directory.
The base name of this DLL is used to write the downloaded file.
As an example, in the event apcups.dll was selected, the malware would write the downloaded file to apcups.exe in the same folder.
The downloader then proceeds to execute this downloaded file in a new process.
As we’ve seen in previous samples, this executable file begins by checking the parent process for the presence of ‘cmd.exe’ or ‘explorer.exe’.
It proceeds to randomly select an executable file in the system32 folder, and performs process hollowing against it.
The injected executable contains the last stage of the TDrop2 malware variant.
Upon execution, we once again see the parent process check to determine if the malware is running within the ‘cmd.exe’ or ‘explorer.exe’ parent process.
It continues to dynamically load a number of libraries and functions for later use.
A feature that has yet to be seen is that of string encryption.
Strings are encrypted using the following function, represented in Python:
After dynamically loading functions and libraries, the malware iterates through the running processes and attempts to determine if the ‘V3lite.exe’ process is running.
This process name is associated with the South Korean-based AhnLab security software provider.
In the event this process is running, the malware will attempt to kill the process’ class window.
The final payload proceeds to generate the following mutex to ensure only one copy of the malware is running concurrently:  Global\SPPLMUTEX  The payload then spawns two threads—one to maintain persistence and another to gather victim information and perform command and control operations.
Persistence is achieved by setting the following registry key:  HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run  The name of the registry key in the above instances is derived from the basename of the supplied argument.
In the event the supplied argument was C:\malware.exe, the registry key would be named ‘malware’, and the path for this key would be ‘C:\malware.exe’.  The persistence thread runs in a loop where the registry keys are set every 60 seconds, ensuring persistence even in the event an administrator manually deletes the registry keys.
The other thread begins by collecting information about the victim, such as the following:  These data points are used to generate a unique victim ID, which is stored in the following registry key:  HKCU\SOFTWARE\Microsoft\HY08A\Build  The malware will continue to decrypt and store embedded C2 URLs.
The following URLs have been identified:
The final payload proceeds to enter its command and control loop.
It initially performs a DNS check against microsoft.com to ensure it has Internet connectivity.
After this check is performed, it enters an infinite loop, with a sleep interval set at a default of 30 minutes.
The malware will periodically poll the C2 server and determine if any commands are received.
The initial POST request contains a unique victim identifier that was previously generated.
The optional response by the C2 server is both encoded and encrypted.  The data is first encrypted using an unidentified algorithm.
The two keys used for this encryption are generated using another unidentified algorithm.
The following Python script can be used to generate the keys.
A default salt of ‘FFFFFFFF’ is used.
Additionally, the following Python script can be used for encryption/decryption
After the data is encrypted, it is then base64-encoded using a custom alphabet.
The following alphabet is used:  3bcd1fghijklmABCDEFGH-J+LMnopq4stuvwxyzNOPQ7STUVWXYZ0e2ar56R89K/
When the previously mentioned C2 response is both decoded and decrypted, we are presented with the following data:  The command structure of the C2 response always begins with the string ‘tick’
The number following this string is most likely a unique command identifier.
The malware will store these command identifiers in the following files:  In the event the number after the tick was previously witnessed, the command from the C2 will be ignored.
The remaining lines are then parsed.
The following commands are supported:  Once again, using the previous example, the malware will first ensure that the command was not previously parsed/executed.
In the event it is new, it will proceed to execute the various reconnaissance commands found on line #2.
The results of these commands are uploaded to the C2 server.
As we can see in the above network traffic, the malware attempts to disguise the data as a .gif image.
Finally, the malware will parse the third line, which instructs the malware to modify the wait interval to a value of ‘60’.
This interval value is set in the following registry key:  HKCU\Software\Microsoft\HY08A\Policy  Additionally, in the event the C2 response instructs the malware to update C2 URLs, it will be in the following format:  1001; [unique_identifier] [url]  The malware will encrypt the URL string with a 4-byte XOR key of “\x01\x02\x03\x04” and store this data in the following registry key:  HKCU\Software\Microsoft\HY08A\[unique_identifier]  The TDrop2 malware family that was witnessed in a recent attack against a European transportation company provided a minimal set of commands to the attackers.
It was most likely used to establish a foothold, perform reconnaissance and deploy further malware into the victim’s network.
While the malware lacked a large set of capabilities, it had a wealth of interesting and advanced features, such as the custom encryption/encoding witnessed in the network traffic, the use of process hollowing against a randomly selected Microsoft Windows binary, and the downloading component that attempted to bypass network security measures by modifying the executable header.
We created the AutoFocus tag TDrop2 to identify samples of this new variant and added known C2 domains and hash values to the Threat Prevention product set.
At this time, WildFire is able to correctly identify the samples associated with this campaign as malicious.
Stage 1  Stage 2  Stage 3  Stage 4  Stage 5
This bulletin includes coordinated influence operation campaigns terminated on our platforms in Q1 2022.
It was last updated on May 12, 2022.
Google TAG actively monitors threat actors and the evolution of their tactics and techniques.
We use our research to continuously improve the safety and security of our products and share this intelligence with the community to benefit the internet as a whole.
As announced today, Google has taken action to disrupt the operations of Glupteba, a multi-component botnet targeting Windows computers.
We believe this action will have a significant impact on Glupteba's operations.
However, the operators of Glupteba are likely to attempt to regain control of the botnet using a backup command and control mechanism that uses data encoded on the Bitcoin blockchain.
Glupteba is known to steal user credentials and cookies, mine cryptocurrencies on infected hosts, deploy and operate proxy components targeting Windows systems and IoT devices.
TAG has observed the botnet targeting victims worldwide, including the US, India, Brazil and Southeast Asia.
The Glupteba malware family is primarily distributed through pay per install (PPI) networks and via traffic purchased from traffic distribution systems (TDS).
For a period of time, we observed thousands of instances of malicious Glupteba downloads per day.
The following image shows a webpage mimicking a software crack download which delivers a variant of Glupteba to users instead of the promised software.
While analyzing Glupteba binaries, our team identified a few containing a git repository URL: “git.voltronwork.com”.
This finding sparked an investigation that led us to identify, with high confidence, multiple online services offered by the individuals operating the Glupteba botnet.
These services include selling access to virtual machines loaded with stolen credentials (dont[.]farm), proxy access (awmproxy), and selling credit card numbers (extracard) to be used for other malicious activities such as serving malicious ads and payment fraud on Google Ads.
This past year, TAG has been collaborating with Google’s CyberCrime Investigation Group to disrupt Glupteba activity involving Google services.
We’ve terminated around 63M Google Docs observed to have distributed Glupteba, 1,183 Google Accounts, 908 Cloud Projects, and 870 Google Ads accounts associated with their distribution.
Furthermore, 3.5M users were warned before downloading a malicious file through Google Safe Browsing warnings.
In the last few days, our team partnered with Internet infrastructure providers and hosting providers, including Cloudflare, to disrupt Glupteba’s operation by taking down servers and placing warning interstitial pages in front of the malicious domain names.
During this time, an additional 130 Google accounts associated with this operation were terminated.
Parallel to the analysis, tracking, and technical disruption of this botnet, Google has filed a lawsuit against two individuals believed to be located in Russia for operating the Glupteba Botnet and its various criminal schemes.
Google is alleging violations under the Racketeer Influenced and Corrupt Organizations Act (RICO), the Computer Fraud and Abuse Act, the Electronic Communications Privacy Act, the Lanham Act, and tortious interference of business relationships, and unjust enrichment.
While these actions may not completely stop Glupteba, TAG estimates that combined efforts will materially affect the actor’s ability to conduct future operations.
The command and control (C2) communication for this botnet uses HTTPS to communicate commands and binary updates between the control servers and infected systems.
To add resilience to their infrastructure, the operators have also implemented a backup mechanism using the Bitcoin blockchain.