Saturday, July 12, 2025

GPUHammer: New RowHammer Attack Variant Degrades AI Models on NVIDIA GPUs

Jul 12, 2025Ravie LakshmananAI Security / Vulnerability

NVIDIA is urging customers to enable System-level Error Correction Codes (ECC) as a defense against a variant of a RowHammer attack demonstrated against its graphics processing units (GPUs).

"Risk of successful exploitation from RowHammer attacks varies based on DRAM device, platform, design specification, and system settings," the GPU maker said in an advisory released this week.

Dubbed GPUHammer, the attacks mark the first-ever RowHammer exploit demonstrated against NVIDIA's GPUs (e.g., NVIDIA A6000 GPU with GDDR6 Memory), causing malicious GPU users to tamper with other users' data by triggering bit flips in GPU memory.

The most concerning consequence of this behavior, University of Toronto researchers found, is the degradation of an artificial intelligence (AI) model's accuracy from 80% to less than 1%.

RowHammer is to modern DRAMs just like how Spectre and Meltdown are to contemporary CPUs. While both are hardware-level security vulnerabilities, RowHammer targets the physical behavior of DRAM memory, whereas Spectre exploits speculative execution in CPUs.

RowHammer causes bit flips in nearby memory cells due to electrical interference in DRAM stemming from repeated memory access, while Spectre and Meltdown allow attackers to obtain privileged information from memory via a side-channel attack, potentially leaking sensitive data.

In 2022, academics from the University of Michigan and Georgia Tech described a technique called SpecHammer that combines RowHammer and Spectre to launch speculative attacks. The approach essentially entails triggering a Spectre v1 attack by using Rowhammer bit-flips to insert malicious values into victim gadgets.

GPUHammer is the latest variant of RowHammer, but one that's capable of inducing bit flips in NVIDIA GPUs despite the presence of mitigations like target refresh rate (TRR).

In a proof-of-concept developed by the researchers, using a single-bit flip to tamper with a victim's ImageNet deep neural network (DNN) models can degrade model accuracy from 80% to 0.1%.

Exploits like GPUHammer threaten the integrity of AI models, which are increasingly reliant on GPUs to perform parallel processing and carry out computationally demanding tasks, not to mention open up a new attack surface for cloud platforms.

To mitigate the risk posed by GPUHammer, it's advised to enable ECC through "nvidia-smi -e 1." Newer NVIDIA GPUs like H100 or RTX 5090 are not affected due to them featuring on-die ECC, which helps detect and correct errors arising due to voltage fluctuations associated with smaller, denser memory chips.

"Enabling Error Correction Codes (ECC) can mitigate this risk, but ECC can introduce up to a 10% slowdown for [machine learning] inference workloads on an A6000 GPU," Chris (Shaopeng) Lin, Joyce Qu, and Gururaj Saileshwar, the lead authors of the study, said, adding it also reduces memory capacity by 6.25%.

The disclosure comes as researchers from NTT Social Informatics Laboratories and CentraleSupelec presented CrowHammer, a type of RowHammer attack that enables a key recovery attack against the FALCON (FIPS 206) post-quantum signature scheme, which has been selected by NIST for standardization.

"Using RowHammer, we target Falcon's RCDT [reverse cumulative distribution table] to trigger a very small number of targeted bit flips, and prove that the resulting distribution is sufficiently skewed to perform a key recovery attack," the study said.

"We show that a single targeted bit flip suffices to fully recover the signing key, given a few hundred million signatures, with more bit flips enabling key recovery with fewer signatures."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/ijlatKc
via IFTTT

Over 600 Laravel Apps Exposed to Remote Code Execution Due to Leaked APP_KEYs on GitHub

Cybersecurity researchers have discovered a serious security issue that allows leaked Laravel APP_KEYs to be weaponized to gain remote code execution capabilities on hundreds of applications.

"Laravel's APP_KEY, essential for encrypting sensitive data, is often leaked publicly (e.g., on GitHub)," GitGuardian said. "If attackers get access to this key, they can exploit a deserialization flaw to execute arbitrary code on the server – putting data and infrastructure at risk."

The company, in collaboration with Synacktiv, said it was able to extract more than 260,000 APP_KEYs from GitHub from 2018 to May 30, 2025, identifying over 600 vulnerable Laravel applications in the process. GitGuardian said it observed over 10,000 unique APP_KEYs across GitHub, of which 400 APP_KEYs were validated as functional.

APP_KEY is a random 32-byte encryption key that's generated during the installation of Laravel. Stored in the .env file of the application, it's used to encrypt and decrypt data, generate secure, random strings, sign and verify data, and create unique authentication tokens, making a crucial security component.

GitGuardian noted that Laravel's current implementation of decrypt() function introduces a security issue wherein it automatically deserializes decrypted data, thereby opening the door for possible remote code execution.

"Specifically in Laravel applications, if attackers obtain the APP_KEY and can invoke the decrypt() function with a maliciously crafted payload, they can achieve remote code execution on the Laravel web server," security researcher Guillaume Valadon said.

"This vulnerability was first documented with CVE-2018-15133, which affected Laravel versions prior to 5.6.30. However, this attack vector persists in newer Laravel versions when developers explicitly configure session serialization in cookies using the SESSION_DRIVER=cookie setting, as demonstrated by CVE-2024-55556."

It's worth noting that CVE-2018-15133 has been exploited in the wild by threat actors associated with the AndroxGh0st malware, after scanning the internet for Laravel applications with misconfigured .env files.

Further analysis has found that 63% of APP_KEY exposures originate from .env files (or their variants) that typically contain other valuable secrets, such as cloud storage tokens, database credentials, and secrets associated with e-commerce platforms, customer support tools, and artificial intelligence (AI) services.

More importantly, approximately 28,000 APP_KEY and APP_URL pairs have been concurrently exposed on GitHub. Of these, approximately 10% have been found to be valid, rendering 120 applications vulnerable to trivial remote code execution attacks.

Given that the APP_URL configuration specifies the application's base URL, exposing both APP_URL and APP_KEY creates a potent attack vector that threat actors can leverage to directly access the app, retrieve session cookies, and attempt to decrypt them using the exposed key.

Simply scrubbing secrets from repositories isn't enough—especially when they've already been cloned or cached by third-party tools. What developers need is a clear rotation path, backed by monitoring that flags every future reappearance of sensitive strings across CI logs, image builds, and container layers.

"Developers should never simply delete exposed APP_KEYs from repositories without proper rotation," GitGuardian said. "The proper response involves: immediately rotating the compromised APP_KEY, updating all production systems with the new key, and implementing continuous secret monitoring to prevent future exposures."

These types of incidents also align with a broader class of PHP deserialization vulnerabilities, where tools like phpggc help attackers craft gadget chains that trigger unintended behaviors during object loading. When used in Laravel environments with leaked keys, such gadgets can achieve full RCE without needing to breach the app's logic or routes.

The disclosure comes after GitGuardian revealed that it discovered a "staggering 100,000 valid secrets" in Docker images publicly accessible on the DockerHub registry. This includes secrets associated with Amazon Web Services (AWS), Google Cloud, and GitHub tokens.

A new Binarly analysis of over 80,000 unique Docker images spanning 54 organizations and 3,539 repositories has likewise uncovered 644 unique secrets that encompassed generic credentials, JSON Web Tokens, HTTP Basic Authorization header, Google Cloud API key, AWS access tokens, and CircleCI API tokens, among others.

"Secrets appear in a wide variety of file types, including source code, configuration files, and even large binary files, areas where many existing scanners fall short," the company said. "Moreover, the presence of entire Git repositories inside container images represents a serious and often overlooked security risk."

But that's not all. The rapid adoption of Model Context Protocol (MCP) to enable agentic workflows in enterprise-driven AI applications has opened up brand new attack vectors – a concerning one being the leakage of secrets from MCP servers published to GitHub repositories.

Specifically, GitGuardian found that 202 of them leaked at least one secret, accounting for 5.2% of all the repositories – a number that the company said is "slightly higher than the 4.6% occurrence rate observed on all public repositories," making MCP servers a "new source of secret leaks."

While this research focuses on Laravel, the same root problem—unguarded secrets in public repositories—applies to other stacks. Organizations should explore centralized secret scanning, Laravel-specific hardening guides, and secure-by-design patterns for managing .env files and container secrets across frameworks.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/7lSnV89
via IFTTT

Friday, July 11, 2025

PerfektBlue Bluetooth Vulnerabilities Expose Millions of Vehicles to Remote Code Execution

Cybersecurity researchers have discovered a set of four security flaws in OpenSynergy's BlueSDK Bluetooth stack that, if successfully exploited, could allow remote code execution on millions of transport vehicles from different vendors.

The vulnerabilities, dubbed PerfektBlue, can be fashioned together as an exploit chain to run arbitrary code on cars from at least three major automakers, Mercedes-Benz, Volkswagen, and Skoda, according to PCA Cyber Security (formerly PCAutomotive). Outside of these three, a fourth unnamed original equipment manufacturer (OEM) has been confirmed to be affected as well.

"PerfektBlue exploitation attack is a set of critical memory corruption and logical vulnerabilities found in OpenSynergy BlueSDK Bluetooth stack that can be chained together to obtain Remote Code Execution (RCE)," the cybersecurity company said.

While infotainment systems are often seen as isolated from critical vehicle controls, in practice, this separation depends heavily on how each automaker designs internal network segmentation. In some cases, weak isolation allows attackers to use IVI access as a springboard into more sensitive zones—especially if the system lacks gateway-level enforcement or secure communication protocols.

The only requirement to pull off the attack is that the bad actor needs to be within range and be able to pair their setup with the target vehicle's infotainment system over Bluetooth. It essentially amounts to a one-click attack to trigger over-the-air exploitation.

"However, this limitation is implementation-specific due to the framework nature of BlueSDK," PCA Cyber Security added. "Thus, the pairing process might look different between various devices: limited/unlimited number of pairing requests, presence/absence of user interaction, or pairing might be disabled completely."

The list of identified vulnerabilities is as follows -

  • CVE-2024-45434 (CVSS score: 8.0) - Use-After-Free in AVRCP service
  • CVE-2024-45431 (CVSS score: 3.5) - Improper validation of an L2CAP channel's remote CID
  • CVE-2024-45433 (CVSS score: 5.7) - Incorrect function termination in RFCOMM
  • CVE-2024-45432 (CVSS score: 5.7) - Function call with incorrect parameter in RFCOMM

Successfully obtaining code execution on the In-Vehicle Infotainment (IVI) system enables an attacker to track GPS coordinates, record audio, access contact lists, and even perform lateral movement to other systems and potentially take control of critical software functions of the car, such as the engine.

Following responsible disclosure in May 2024, patches were rolled out in September 2024.

"PerfektBlue allows an attacker to achieve remote code execution on a vulnerable device," PCA Cyber Security said. "Consider it as an entrypoint to the targeted system which is critical. Speaking about vehicles, it's an IVI system. Further lateral movement within a vehicle depends on its architecture and might involve additional vulnerabilities."

Earlier this April, the company presented a series of vulnerabilities that could be exploited to remotely break into a Nissan Leaf electric vehicle and take control of critical functions. The findings were presented at the Black Hat Asia conference held in Singapore.

"Our approach began by exploiting weaknesses in Bluetooth to infiltrate the internal network, followed by bypassing the secure boot process to escalate access," it said.

"Establishing a command-and-control (C2) channel over DNS allowed us to maintain a covert, persistent link with the vehicle, enabling full remote control. By compromising an independent communication CPU, we could interface directly with the CAN bus, which governs critical body elements, including mirrors, wipers, door locks, and even the steering."

CAN, short for Controller Area Network, is a communication protocol mainly used in vehicles and industrial systems to facilitate communication between multiple electronic control units (ECUs). Should an attacker with physical access to the car be able to tap into it, the scenario opens the door for injection attacks and impersonation of trusted devices.

"One notorious example involves a small electronic device hidden inside an innocuous object (like a portable speaker)," the Hungarian company said. "Thieves covertly plug this device into an exposed CAN wiring junction on the car."

"Once connected to the car's CAN bus, the rogue device mimics the messages of an authorized ECU. It floods the bus with a burst of CAN messages declaring 'a valid key is present' or instructing specific actions like unlocking the doors."

In a report published late last month, Pen Test Partners revealed it turned a 2016 Renault Clio into a Mario Kart controller by intercepting CAN bus data to gain control of the car and mapping its steering, brake, and throttle signals to a Python-based game controller.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/v7u6D2j
via IFTTT

Build a GenAI App With Java Using Spring AI and Docker Model Runner

When thinking about starting a Generative AI (GenAI) project, you might assume that Python is required to get started in this new space. However, if you’re already a Java developer, there’s no need to learn a new language. The Java ecosystem offers robust tools and libraries that make building GenAI applications both accessible and productive.

In this blog, you’ll learn how to build a GenAI app using Java. We’ll do a step-by-step demo to show you how RAG enhances the model response, using Spring AI and Docker tools. Spring AI integrates with many model providers (for both chat and embeddings), vector databases, and more. In our example, we’ll use the OpenAI and Qdrant modules provided by the Spring AI project to take advantage of built-in support for these integrations. Additionally, we’ll use Docker Model Runner (instead of a cloud-hosted OpenAI model), which offers an OpenAI-compatible API, making it easy to run AI models locally. We’ll automate the testing process using Testcontainers and Spring AI’s tools to ensure the LLM’s answers are contextually grounded in the documents we’ve provided. Last, we’ll show you how to use Grafana for observability and ensure our app behaves as designed. 

Getting started 

Let’s start building a sample application by going to Spring Initializr and choosing the following dependencies: Web, OpenAI, Qdrant Vector Database, and Testcontainers.

It’ll have two endpoints: a “/chat” endpoint that interacts directly with the model and a   “/rag” endpoint that provides the model with additional context from documents stored in the vector database.

Configuring Docker Model Runner

Enable Docker Model Runner in your Docker Desktop or Docker Engine as described in the official documentation.

Then pull the following two models:

docker model pull ai/llama3.1
docker model pull ai/mxbai-embed-large
  • ai/llama3.1 – chat model
  • ai/mxbai-embed-large – embedding model

Both models are hosted at Docker Hub under the ai namespace. You can also pick specific tags for the model, which usually provide different quantization of the model. If you don’t know which tag to pick, the default one is a good starting point.

Building the GenAI app

Let’s create a ChatController under /src/main/java/com/example, which will be our entry point to interact with the chat model:

@RestController
public class ChatController {

        private final ChatClient chatClient;

        public ChatController(ChatModel chatModel) {
                this.chatClient = ChatClient.builder(chatModel).build();
        }

        @GetMapping("/chat")
        public String generate(@RequestParam(value = "message", defaultValue = "Tell me a joke") String message) {
                return this.chatClient.prompt().user(message).call().content();
        }

}


  • ChatClient is the interface that provides the available operations to interact with the model. We’ll be injecting the actual model value (which model to use) via configuration properties.
  • If no message query param is provided, then we’ll ask the model to tell a joke (as seen in the defaultValue).

Let’s configure our application to point to Docker Model Runner and use the “ai/llama3.1” model by adding the following properties to /src/test/resources/application.properties

spring.ai.openai.base-url=http://localhost:12434/engines
spring.ai.openai.api-key=test
spring.ai.openai.chat.options.model=ai/llama3.1

spring.ai.openai.api-key is required by the framework, but we can use any value here since it is not needed for Docker Model Runner.

Let’s start our application by running ./mvnw spring-boot:test-run or ./gradlew bootTestRun and ask it about Testcontainers:

http :8080/chat message=="What’s testcontainers?"

Below, we can find the answer provided by the LLM (ai/llama3.1)

Testcontainers is a fantastic and increasingly popular library for **local testing with containers**. Let's break down what it is, why it's useful, and how it works:

**What is Testcontainers?**

Testcontainers provides a way to run real, fully functional containerized services (like databases, message queues, web servers, etc.) directly within your tests. Instead of relying on mocked or stubbed versions of these services, you're using the *actual* services, which leads to much more realistic and reliable test results.

**Why Use Testcontainers?**

* **Realistic Testing:** This is the biggest benefit.  Mocking databases or message queues can be brittle and difficult to maintain.  Testcontainers provides a service that behaves exactly like the real thing, leading to tests that more accurately reflect how your application will perform in production.
* **Simplified Test Setup:**  Forget about manually setting up and configuring databases or other services on your test machine. Testcontainers automatically handles the container creation, configuration, and cleanup for you.
* **Faster Tests:** Because the services are running locally, there’s no network latency involved, resulting in significantly faster test execution times.
* **Consistent Environments:**  You eliminate the "it works on my machine" problem. Everyone running the tests will be using the same, pre-configured environment.
* **Supports Many Services:** Testcontainers supports a huge range of services, including:
    * **Databases:** PostgreSQL, MySQL, MongoDB, Redis, Cassandra, MariaDB
    * **Message Queues:** RabbitMQ, Kafka, ActiveMQ
    * **Web Servers:**  Tomcat, Jetty, H2 (for in-memory databases)
    * **And many more!**  The list is constantly growing.


**How Does It Work?**

1. **Client Library:** Testcontainers provides client libraries for various programming languages (Java, Python, JavaScript, Ruby, Go, .NET, and more).
2. **Container Run:** When you use the Testcontainers client library in your test, it automatically starts the specified container (e.g., a PostgreSQL database) in the background.
3. **Connection:** Your test code then connects to the running container using standard protocols (e.g., JDBC for PostgreSQL, HTTP for a web server).
4. **Test Execution:**  You execute your tests as usual.
5. **Cleanup:**  When the tests are finished, Testcontainers automatically shuts down the container, ensuring a clean state for the next test run.

**Example (Conceptual - Python):**

```python
from testcontainers.postgresql import PostgreSQLEnvironment

# Create a PostgreSQL environment
env = PostgreSQLEnvironment()

# Start the container
env.start()

# Connect to the database
db = env.db()  #  This creates a connection object to the running PostgreSQL container

# Perform database operations in your test
# ...

# Stop the container (cleanup)
env.shutdown()
```

**Key Concepts:**

* **Environment:**  A Testcontainers environment is a configuration that defines which containers to run and how they should be configured.
* **Container:**  A running containerized service (e.g., a database instance).
* **Connection:** An object that represents a connection to a specific container.

**Resources to Learn More:**

* **Official Website:** [https://testcontainers.io/](https://testcontainers.io/) - This is the best place to start.
* **GitHub Repository:** [https://github.com/testcontainers/testcontainers](https://github.com/testcontainers/testcontainers) -  See the source code and contribute.
* **Documentation:** [https://testcontainers.io/docs/](https://testcontainers.io/docs/) - Comprehensive documentation with examples for various languages.

**In short, Testcontainers is a powerful tool that dramatically improves the quality and reliability of your local tests by allowing you to test against real, running containerized services.**

Do you want me to delve deeper into a specific aspect of Testcontainers, such as:

*   A specific language implementation (e.g., Python)?
*   A particular service it supports (e.g., PostgreSQL)?
*   How to integrate it with a specific testing framework (e.g., JUnit, pytest)?

We can see that the answer provided by the LLM has some mistakes, for example, PostgreSQLEnvironment doesn’t exist in testcontainers-python. Another one is the links to the docs, testcontainers.io doesn’t exist. So, we can see some hallucinations in the answer.

Of course, LLM responses are non-deterministic, and since each model is trained until a certain cutoff date, the information may be outdated, and the answers might not be accurate.

To improve this situation, let’s provide the model with some curated context about Testcontainers!

We’ll create another controller, RagController, which will retrieve documents from a vector search database.

@RestController
public class RagController {

        private final ChatClient chatClient;

        private final VectorStore vectorStore;

        public RagController(ChatModel chatModel, VectorStore vectorStore) {
                this.chatClient = ChatClient.builder(chatModel).build();
                this.vectorStore = vectorStore;
        }

        @GetMapping("/rag")
        public String generate(@RequestParam(value = "message", defaultValue = "What's Testcontainers?") String message) {
                return callResponseSpec(this.chatClient, this.vectorStore, message).content();
        }

        static ChatClient.CallResponseSpec callResponseSpec(ChatClient chatClient, VectorStore vectorStore,
                        String question) {
                QuestionAnswerAdvisor questionAnswerAdvisor = QuestionAnswerAdvisor.builder(vectorStore)
                        .searchRequest(SearchRequest.builder().topK(1).build())
                        .build();
                return chatClient.prompt().advisors(questionAnswerAdvisor).user(question).call();
        }

}

Spring AI provides many advisors. In this example, we are going to use the QuestionAnswerAdvisor to perform the query against the vector search database. It takes care of all the individual integrations with the vector database.

Ingesting documents into the vector database

First, we need to load the relevant documents into the vector database. Under src/test/java/com/example, let’s create an IngestionConfiguration class:

@TestConfiguration(proxyBeanMethods = false)
public class IngestionConfiguration {

        @Value("classpath:/docs/testcontainers.txt")
        private Resource testcontainersDoc;

        @Bean
        ApplicationRunner init(VectorStore vectorStore) {
                return args -> {
                        var javaTextReader = new TextReader(this.testcontainersDoc);
                        javaTextReader.getCustomMetadata().put("language", "java");

                        var tokenTextSplitter = new TokenTextSplitter();
                        var testcontainersDocuments = tokenTextSplitter.apply(javaTextReader.get());

                        vectorStore.add(testcontainersDocuments);
                };
        }

}


testcontainers.txt under /src/test/resources/docs directory will have the following content  specific information. For a real-world use case, you would probably have a more extensive collection of documents.

Testcontainers is a library that provides easy and lightweight APIs for bootstrapping local development and test dependencies with real services wrapped in Docker containers. Using Testcontainers, you can write tests that depend on the same services you use in production without mocks or in-memory services.

Testcontainers provides modules for a wide range of commonly used infrastructure dependencies including relational databases, NoSQL datastores, search engines, message brokers, etc. See https://testcontainers.com/modules/ for a complete list.

Technology-specific modules are a higher-level abstraction on top of GenericContainer which help configure and run these technologies without any boilerplate, and make it easy to access their relevant parameters.

Official website: https://testcontainers.com/
Getting Started: https://testcontainers.com/getting-started/
Module Catalog: https://testcontainers.com/modules/

Now, let’s add an additional property to the src/test/resources/application.properties file.

spring.ai.openai.embedding.options.model=ai/mxbai-embed-large
spring.ai.vectorstore.qdrant.initialize-schema=true
spring.ai.vectorstore.qdrant.collection-name=test

ai/mxbai-embed-large is an embedding model that will be used to create the embeddings of the documents. They will be stored in the vector search database, in our case, Qdrant. Spring AI will initialize the Qdrant schema and use the collection named test.

Let’s update our TestDemoApplication Java class and add the IngestionConfiguration.class

public class TestDemoApplication {

        public static void main(String[] args) {
                SpringApplication.from(DemoApplication::main)
                        .with(TestcontainersConfiguration.class, IngestionConfiguration.class)
                        .run(args);
        }

}

Now we start our application by running ./mvnw spring-boot:test-run or ./gradlew bootTestRun and ask it again about Testcontainers:

http :8080/rag message=="What’s testcontainers?"

This time, the answer contains references from the docs we have provided and is more accurate.

Testcontainers is a library that helps you write tests for your applications by bootstrapping real services in Docker containers, rather than using mocks or in-memory services. This allows you to test your applications as they would run in production, but in a controlled and isolated environment.

It provides modules for commonly used infrastructure dependencies such as relational databases, NoSQL datastores, search engines, and message brokers.

If you have any specific questions about how to use Testcontainers or its features, I'd be happy to help.

Integration testing

Testing is a key part of software development. Fortunately, Testcontainers and Spring AI’s utilities support testing of GenAI applications. So far, we’ve been testing the application manually, starting the application and performing requests to the given endpoints, verifying the correctness of the response ourselves. Now, we’re going to automate it by writing an integration test to check if the answer provided by the LLM is more contextual, augmented by the information provided in the documents.

@SpringBootTest(classes = { TestcontainersConfiguration.class, IngestionConfiguration.class },
                webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class RagControllerTest {

        @LocalServerPort
        private int port;

        @Autowired
        private VectorStore vectorStore;

        @Autowired
        private ChatClient.Builder chatClientBuilder;

        @Test
        void verifyTestcontainersAnswer() {
                var question = "Tell me about Testcontainers";
                var answer = retrieveAnswer(question);

                assertFactCheck(question, answer);
        }

        private String retrieveAnswer(String question) {
                RestClient restClient = RestClient.builder().baseUrl("http://localhost:%d".formatted(this.port)).build();
                return restClient.get().uri("/rag?message={question}", question).retrieve().body(String.class);
        }

        private void assertFactCheck(String question, String answer) {
                FactCheckingEvaluator factCheckingEvaluator = new FactCheckingEvaluator(this.chatClientBuilder);
                EvaluationResponse evaluate = factCheckingEvaluator.evaluate(new EvaluationRequest(docs(question), answer));
                assertThat(evaluate.isPass()).isTrue();
        }

        private List<Document> docs(String question) {
                var response = RagController
                        .callResponseSpec(this.chatClientBuilder.build(), this.vectorStore, question)
                        .chatResponse();
                return response.getMetadata().get(QuestionAnswerAdvisor.RETRIEVED_DOCUMENTS);
        }

}

  • Importing ContainerConfiguration, Qdrant will be provided.
  • Importing IngestionConfiguration, will load the documents into the vector database.
  • We’re going to use FactCheckingEvaluator to tell the chat model (ai/llama3.1) to check the answer provided by the LLM and verify it with the documents stored in the vector database.

Note: The integration test is using the same model we have declared in the previous steps. But we can definitely use a different model.

Automating your tests ensures consistency and reduces the risk of errors that often come with manual execution. 

Observability with the Grafana LGTM Stack

Finally, let’s introduce some observability into our application. By introducing metrics and tracing, we can understand if our application is behaving as designed during development and in production.

Add the following dependencies to the pom.xml

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-otlp</artifactId>
</dependency>
<dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>
<dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-exporter-otlp</artifactId>
</dependency>
<dependency>
        <groupId>org.testcontainers</groupId>
        <artifactId>grafana</artifactId>
       <scope>test</scope>
</dependency>

Now, let’s create GrafanaContainerConfiguration under src/test/java/com/example.

@TestConfiguration(proxyBeanMethods = false)
public class GrafanaContainerConfiguration {

        @Bean
        @ServiceConnection
        LgtmStackContainer lgtmContainer() {
                return new LgtmStackContainer("grafana/otel-lgtm:0.11.4");
        }

}

Grafana provides the grafana/otel-lgtm image, which will start Prometheus, Tempo, and OpenTelemetry Collector, and other related services, all combined into a single convenient Docker image.

For the sake of our demo, let’s add a couple of properties at /src/test/resources/application.properties to sample 100% of requests.

spring.application.name=demo
management.tracing.sampling.probability=1

Update the TestDemoApplication class to include GrafanaContainerConfiguration.class

public class TestDemoApplication {

        public static void main(String[] args) {
                SpringApplication.from(DemoApplication::main)
                        .with(TestcontainersConfiguration.class, IngestionConfiguration.class, GrafanaContainerConfiguration.class)
                        .run(args);
        }

}

Now, run ./mvnw spring-boot:test-run or ./gradlew bootTestRun one more time, and perform a request.

http :8080/rag message=="What’s testcontainers?"

Then, look for the following text in logs.

o.t.grafana.LgtmStackContainer           : Access to the Grafana dashboard: 
http://localhost:64908

The port can be different for you, but clicking on it should open the Grafana dashboard. This is where you can query for metrics related to the model or vector search, and also see the traces.

Testcontainers GenAI figure 1

Figure 1: Grafana dashboard showing model metrics, vector search performance, and traces

We can also display the token usage metric used by the chat endpoint.

Testcontainers GenAI figure 2 1

Figure 2: Grafana dashboard panel displaying token usage metrics for the chat endpoint

List traces for the service with name “demo”, and we can see a list of operations executed as part of this trace. You can use the trace ID with the name http get /rag to see the full control flow within the same HTTP request.

Testcontainers GenAI figure 3

Figure 3:  Grafana dashboard showing trace details for a /rag endpoint in a Java GenAI application

Conclusion

Docker offers powerful capabilities that complement the Spring AI project, allowing developers to build GenAI applications efficiently with Docker tools that they know and trust. It simplifies the startup of service dependencies, including the Docker Model Runner, which exposes an OpenAI-compatible API for running local models. Testcontainers help to quickly spin out integration testing to evaluate your app by providing lightweight containers for your services and dependencies.  From development to testing, Docker and Spring AI have proven to be a reliable and productive combination for building modern AI-driven applications.

Learn more



from Docker https://ift.tt/4AFdWGn
via IFTTT

Securing Data in the AI Era

Jul 11, 2025The Hacker NewsData Security / Enterprise Security

The 2025 Data Risk Report: Enterprises face potentially serious data loss risks from AI-fueled tools. Adopting a unified, AI-driven approach to data security can help.

As businesses increasingly rely on cloud-driven platforms and AI-powered tools to accelerate digital transformation, the stakes for safeguarding sensitive enterprise data have reached unprecedented levels. The Zscaler ThreatLabz 2025 Data Risk Report reveals how evolving technology landscapes are amplifying vulnerabilities, highlighting the critical need for a proactive and unified approach to data protection.

Drawing on insights from more than 1.2 billion blocked transactions recorded by the Zscaler Zero Trust Exchange between February and December 2024, this year's report paints a clear picture of the data security challenges that enterprises face. From the rise of data leakage through generative AI tools to the undiminished risks stemming from email, SaaS applications, and file-sharing services, the findings are both eye-opening and urgent.

The 2025 Data Risk Report sheds light on the multifaceted data security risks enterprises face in today's digitally enabled world. Some of the most noteworthy trends include:

  • AI apps are a major data loss vector: AI tools like ChatGPT and Microsoft Copilot contributed to millions of data loss incidents in 2024, particularly social security numbers.
  • SaaS data loss is surging: Spanning 3,000+ SaaS apps, enterprises saw more than 872 million data loss violations.
  • Email remains a leading source of data loss: Nearly 104 million transactions leaked billions of instances of sensitive data.
  • File-sharing data loss spikes: Among the most popular file-sharing apps, 212 million transactions saw data loss incidents.

There has never been a more critical time to rethink your enterprise's approach to data security. The 2025 ThreatLabz Data Risk Report offers a comprehensive look at where risks lie, what drives them, and how organizations can respond effectively to secure their sensitive data in today's rapidly evolving, AI-driven ecosystem.

To learn more about Zscaler Zero Trust Architecture and Zero Trust + AI, visit zscaler.com/security

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/npQ7JXx
via IFTTT

Critical Wing FTP Server Vulnerability (CVE-2025-47812) Actively Being Exploited in the Wild

Jul 11, 2025Ravie LakshmananCyber Attack / Vulnerability

A recently disclosed maximum-severity security flaw impacting the Wing FTP Server has come under active exploitation in the wild, according to Huntress.

The vulnerability, tracked as CVE-2025-47812 (CVSS score: 10.0), is a case of improper handling of null ('\0') bytes in the server's web interface, which allows for remote code execution. It has been addressed in version 7.4.4.

"The user and admin web interfaces mishandle '\0' bytes, ultimately allowing injection of arbitrary Lua code into user session files," according to an advisory for the flaw on CVE.org. "This can be used to execute arbitrary system commands with the privileges of the FTP service (root or SYSTEM by default)."

What makes it even more concerning is that the flaw can be exploited via anonymous FTP accounts. A comprehensive breakdown of the vulnerability entered the public domain towards the end of June 2025, courtesy of RCE Security researcher Julien Ahrens.

Cybersecurity company Huntress said it observed threat actors exploiting the flaw to download and execute malicious Lua files, conduct reconnaissance, and install remote monitoring and management software.

"CVE-2025-47812 stems from how null bytes are handled in the username parameter (specifically related to the loginok.html file, which handles the authentication process)," Huntress researchers said. "This can allow remote attackers to perform Lua injection after using the null byte in the username parameter."

"By taking advantage of the null-byte injection, the adversary disrupts the anticipated input in the Lua file which stores these session characteristics."

Evidence of active exploitation was first observed against a single customer on July 1, 2025, merely a day after details of the exploit were disclosed. Upon gaining access, the threat actors are said to have run enumeration and reconnaissance commands, created new users as a form of persistence, and dropped Lua files to drop an installer for ScreenConnect.

There is no evidence that the remote desktop software was actually installed, as the attack was detected and stopped before it could progress any further. It's currently not clear who is behind the activity.

Data from Censys shows that there are 8,103 publicly-accessible devices running Wing FTP Server, out of which 5,004 have their web interface exposed. The majority of the instances are located in the U.S., China, Germany, the U.K., and India.

In light of active exploitation, it's essential that users move quickly to apply the latest patches and update their Wing FTP Server versions of 7.4.4 or later.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/JmnMG13
via IFTTT

Iranian-Backed Pay2Key Ransomware Resurfaces with 80% Profit Share for Cybercriminals

An Iranian-backed ransomware-as-a-service (RaaS) named Pay2Key has resurfaced in the wake of the Israel-Iran-U.S. conflict last month, offering bigger payouts to cybercriminals who launch attacks against Israel and the U.S.

The financially motivated scheme, now operating under the moniker Pay2Key.I2P, is assessed to be linked to a hacking group tracked as Fox Kitten (aka Lemon Sandstorm).

"Linked to the notorious Fox Kitten APT group and closely tied to the well-known Mimic ransomware, [...] Pay2Key.I2P appears to partner with or incorporate Mimic's capabilities," Morphisec security researcher Ilia Kulmin said.

"Officially, the group offers an 80% profit share (up from 70%) to affiliates supporting Iran or participating in attacks against the enemies of Iran, signaling their ideological commitment."

Last year, the U.S. government revealed the advanced persistent threat's (APT) modus operandi of carrying out ransomware attacks by covertly partnering with NoEscape, RansomHouse, and BlackCat (aka ALPHV) crews.

The use of Pay2Key by Iranian threat actors goes back to October 2020, with the attacks targeting Israeli companies by exploiting known security vulnerabilities.

Pay2Key.I2P, per Morphisec, emerged on the scene in February 2025, claiming over 51 successful ransom payouts in four months, netting it more than $4 million in ransom payments and $100,000 in profits for individual operators.

While their financial motives are apparent and doubtless effective, there is also an underlying ideological agenda behind them: the campaign appears to be a case of cyber warfare waged against targets in Israel and the U.S.

A notable aspect of the latest variant of Pay2Key.I2P is that it's the first known RaaS platform to be hosted on the Invisible Internet Project (I2P).

"While some malware families have used I2P for [command-and-control] communication, this is a step further – a Ransomware-as-a-Service operation running its infrastructure directly on I2P," Swiss cybersecurity company PRODAFT said in a post shared on X in March 2025. The post was subsequently reposted by Pay2Key.I2P's own X account.

What's more, Pay2Key.I2P has observed posting on a Russian darknet forum that allowed anyone to deploy the ransomware binary for a $20,000 payout per successful attack, marking a shift in RaaS operations. The post was made by a user named "Isreactive" on February 20, 2025.

"Unlike traditional Ransomware-as-a-Service (RaaS) models, where developers take a cut only from selling the ransomware, this model allows them to capture the full ransom from successful attacks, only sharing a portion with the attackers who deploy it," Kulmin noted at the time.

"This shift moves away from a simple tool-sale model, creating a more decentralized ecosystem, where ransomware developers earn from attack success rather than just from selling the tool."

As of June 2025, the ransomware builder includes an option to target Linux systems, indicating that the threat actors are actively refining and improving the locker's functionality. The Windows counterpart, on the other hand, is delivered as a Windows executable within a self-extracting (SFX) archive.

It also incorporates various evasion techniques that allow it to run unimpeded by disabling Microsoft Defender Antivirus and deleting malicious artifacts deployed as part of the attack to minimize forensic trail.

"Pay2Key.I2P represents a dangerous convergence of Iranian state-sponsored cyber warfare and global cybercrime," Morphisec said. "With ties to Fox Kitten and Mimic, an 80% profit incentive for Iran's supporters, and over $4 million in ransoms, this RaaS operation threatens Western organizations with advanced, evasive ransomware."

The findings come as the U.S. cybersecurity and intelligence agencies have warned of retaliatory attacks by Iran after American airstrikes on three nuclear facilities in the country.

Operational technology (OT) security company Nozomi Networks said it has observed Iranian hacking groups like MuddyWater, APT33, OilRig, Cyber Av3ngers, Fox Kitten, and Homeland Justice targeting transportation and manufacturing organizations in the U.S.

"Industrial and critical infrastructure organizations in the U.S. and abroad are urged to be vigilant and review their security posture," the company said, adding it detected 28 cyber attacks related to Iranian threat actors between May and June 2025.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/Byv2Uk6
via IFTTT

Evolving Tactics of SLOW#TEMPEST: A Deep Dive Into Advanced Malware Techniques

Executive Summary

In late 2024, we discovered a malware variant related to the SLOW#TEMPEST campaign. In this research article, we explore the obfuscation techniques employed by the malware authors. We deep dive into these malware samples and highlight methods and code that can be used to detect and defeat the obfuscation techniques.

Understanding these evolving tactics is essential for security practitioners to develop robust detection rules and strengthen defenses against increasingly sophisticated threats.

We focus on the following techniques used by the threat actors for the SLOW#TEMPEST campaign:

  • Control flow graph (CFG) obfuscation using dynamic jumps
  • Obfuscated function calls

Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Anti-analysis, DLL sideloading

Background

In this article, we analyze a more recent variant of the malware sample (SHA256 hash: a05882750f7caac48a5b5ddf4a1392aa704e6e584699fe915c6766306dae72cc) from the SLOW#TEMPEST campaign. The attackers distribute the malware as an ISO file, which is a common technique used to bundle multiple files to potentially evade initial detection. This ISO file contains 11 files; two are malicious, and the remainder are benign.

The first malicious file is zlibwapi.dll, which we’ll refer to as loader DLL, decrypts and executes the embedded payload. The payload is not integrated into the loader DLL in a typical manner. Instead, it is appended to the end of another DLL named ipc_core.dll.

The loader DLL is executed via DLL side-loading by a legitimate signed binary named DingTalk.exe. DLL side-loading is a technique where attackers use a legitimate program to load a malicious DLL file, causing the legitimate program to execute the attacker's code. Separating the payload from the loader DLL complicates detection, as the malicious code will only execute if both the loader and payload binaries are present.

In the following sections, we dive deeper into the anti-analysis techniques used by the malware authors to obfuscate the code in the loader DLL.

Control Flow Graph (CFG) Obfuscation Using Dynamic Jumps

CFG obfuscation alters the execution order of program instructions, making static and dynamic analysis more difficult. This makes it harder to understand the program’s logic, identify malicious functionality and create effective signature-based detection.

For static analysis, traditional tools relying on linear sequences or predictable control flow become ineffective. Dynamic analysis also becomes more challenging because misleading execution paths obscure actual malicious operations. CFG obfuscation breaks the mapping between the original source or compiled code and runtime execution, making it significantly more difficult to create reliable detection rules.

To demonstrate this technique, we analyze the application of CFG obfuscation, specifically using dynamic jumps to the loader DLL's main function. Figure 1 illustrates the CFGs of this function, both with and without obfuscation. Once we remove the obfuscation, the continuous code flow becomes apparent, marked by two colored lines:

  • Green for True branches
  • Red for False branches
Two vertical diagrams comparing an obfuscated function and the same function with obfuscation removed. Both diagrams feature lines and boxes representing functional elements, connected by vertical and horizontal lines to show their interactions. The left diagram labeled "Obfuscated Function" is more complex with many boxes linked by yellow lines. The right diagram labeled "Obfuscation Removed" is simplified with fewer elements. There are fewer boxes and the lines interconnecting them are red and green. The green line is only on the right of the diagram and multiple red lines appear on both the left and the right.
Figure 1. CFGs of the main function for the loader DLL with and without obfuscation.

This function is extensive, comprising over 17,000 lines of assembly instructions. Given the size of the main function for the loader DLL, we turned to the Hex-Rays decompiler to speed up analysis. However, the Hex-Rays decompiler was only able to generate 10 lines of pseudocode for the same main function, as shown in Figure 2.

Screenshot of code in an Integrated Development Environment, featuring C++ syntax with functions and conditional statements highlighted in various colors.
Figure 2. Pseudocode generated by Hex-Rays of the main function for the loader DLL.

The reason for the incomplete Hex-Rays decompiler output is because the sample used dynamic jump instructions. Dynamic jumps are where target addresses in code are computed at runtime.

Unlike direct jumps to fixed addresses, dynamic jumps make it impossible for the decompiler to determine the execution flow without actually running the program. This lack of a clear, predetermined path severely hinders the decompiler's ability to reconstruct the original high-level code, often leading to incomplete or inaccurate decompilation results.

Figure 3 shows one of the dynamic jumps using the JMP RAX instruction near the entry point of the main function of the loader DLL. The JMP instruction will cause the execution flow to be diverted to a different target address.

The target address depends on factors like memory contents, register values and the results of conditional checks performed during execution. In this case, it is computed at runtime by a sequence of preceding instructions and stored in the CPU register RAX.

A screenshot of a computer screen displaying colorful assembly language code in a text editor, with various operations and hexadecimal values highlighted. JMP is highlighted in pink.
Figure 3. One dynamic jump in the main function for the loader DLL.

We countered CFG obfuscation employing dynamic jumps by first identifying all instances of these jumps using the IDAPython script shown in Figure 4.

Screenshot of computer code in an IDE, featuring functions and loops written in Python.
Figure 4. Code to locate dynamic jumps.

Using the above script, we identified 10 dynamic jumps in the main function of the loader DLL.

The dynamic jump target is determined by a preceding sequence of nine instructions, termed a “dispatcher,” before each JMP RAX instruction. These 10 dispatchers, found within the loader DLL's main function, share a similar structure. However, each dispatcher uses a distinct set of instructions to compute the jump's destination address, effectively hiding the program's control flow.

Imagine the program is a complex dance routine. Normally, the dancers move predictably from one step to the next. However, in this case, the program has hidden "jump points." Before each jump, there's a mini-routine, like a secret handshake, that decides exactly where the next jump will land. These secret handshakes are all a bit different, making it very hard to predict the dance's true path, almost like the dancers are improvising where they'll go next, even though it's all pre-programmed.

Each dispatcher implements a two-way branching mechanism. The code path taken depends on the state of the Zero Flag (ZF) or the carry flag (CF) when the dispatcher is entered. These flags, which are set by previous instructions to indicate the result of an operation (e.g., zero or overflow), determine which branch is taken. Each dispatcher has a pair of conditional move (CMOVNZ) or set (SETNL) instructions and an indirect jump (JMP RAX). This creates a dynamic control flow that depends on runtime conditions and memory contents, making static analysis difficult.

ZF and CF are CPU status flags that reflect arithmetic and logical operation outcomes. These flags act as internal switches, enabling dynamic program execution based on prior computation results. Each conditional move or set instruction has two possible target addresses: one for a true condition and the other for a false condition. For example, the conditional move if not zero (CMOVNZ) instruction will only move data if the ZF is 0, indicating that the previous operation did not result in 0. If the ZF is 1 (meaning the previous result was 0), the CMOVNZ instruction will not move the data, and execution will continue to a different target address.

Figure 5 shows one of the dispatchers. We annotated the instructions to explain how the destination addresses are computed.

Screen capture of computer code in an IDE, showing various assembly language instructions and memory addresses with comments explaining their functionality.
Figure 5. CPU instructions of one dispatcher.

Using Unicorn — a multi-platform, multi-architecture CPU emulator framework — automates the identification of destination jump addresses. We achieve this by executing the nine instructions preceding each JMP RAX in a controlled manner, rather than running the entire binary. This allows us to determine the jump addresses for each dispatcher.

To extract the bytecodes of these instructions, we use the code shown in Figure 6.

Screenshot of a code snippet, including a function named 'setup_emulate (JMP_RAX)' with comments and hexadecimal conversions.
Figure 6. Code to extract the bytecodes of the dispatchers.

Next, we emulate each dispatcher. Since each dispatcher uses a two-way branching mechanism with two target addresses, the emulation process must be repeated twice for each dispatcher to determine both destination addresses. Figure 7 shows the code used to emulate the dispatchers.

A screenshot of computer code including various programming-related texts, symbols, and functions. The image shows code related to data segment initialization and memory manipulation functions as well as destination address computation.
Figure 7. Code to emulate the dispatcher to determine the destination addresses.

After computing the two destination addresses, we replaced the dispatcher instructions with direct jump instructions to those addresses, effectively removing the CFG obfuscation. This allowed us to see the original code flow easily in IDA Pro. Figure 8 shows the code to patch the instructions in the IDA database.

Screenshot of code displaying functions related to memory address manipulation, including use of hex values and byte handling.
Figure 8. Code to patch the dispatchers with de-obfuscated jump instructions.

Finally, we forced IDA Pro to re-analyze the entire function that was patched using the code shown in Figure 9. This was to trigger IDA Pro to update its CFG based on the de-obfuscated instructions.

Screenshot of a script in an integrated development environment, showing a function named 'fix_function' with code involving loops and operations for item deletion and instruction creation using the IDA Pro APIs.
Figure 9. Code to force IDA Pro to re-analyze the patched functions.

After executing this script, the Hex-Rays decompiler successfully decompiled the main function within the loader DLL. Figure 10 shows part of the decompilation output.

A screenshot of a computer screen displaying complex programming code in an IDE, with highlighted syntax in various colors including yellow, blue, and white on a dark background.
Figure 10. Decompiled output of the main function in the loader DLL.

However, we observed that further obfuscation remained in the code. Specifically, most functions were called dynamically, and we did not observe any direct Windows API calls. This made it challenging to immediately discern the code's purpose, as the actual functionality was obscured by indirect function resolution.

Obfuscated Function Calls

Obfuscated function calls use indirect calls, where the function's address is calculated dynamically at runtime and then called through a pointer, instead of directly invoking the function by its name. Attackers use this technique to hinder static analysis, as the actual target function is not immediately apparent in the code. This makes it more difficult to understand the program's behavior and identify malicious actions.

Analysis of the main function's assembly code reveals the presence of multiple obfuscated function calls. The Call RAX instruction is a key indicator, as it signifies that the function address is being dynamically determined at runtime rather than being directly specified in the code. Similar to dynamic jumps, the target addresses of these function calls were calculated at runtime. We were not able to determine the target addresses without executing the binary. Figure 11 shows some of the obfuscated function calls.

Image showing a section of coding with assembly language instructions. The text is highlighted in various colors including blue, green, and orange on a dark background for clarity. All of the calls in the code are highlighted.
Figure 11. Instructions of multiple obfuscated function calls.

To determine the target address of obfuscated function calls, we applied a similar approach to the one we used for dynamic jumps. This is because both techniques involve calculating target addresses at runtime.

Our script successfully calculated the destination addresses of these obfuscated function calls. However, we observed that IDA Pro failed to identify the arguments of standard Windows APIs even though the destination addresses were correctly resolved, as Figure 12 shows. This is because there was missing function signature information linking the addresses of the Windows APIs with the obfuscated function calls.

Screenshot of computer code featuring various operations such as mov, add, and lea with hexadecimal values and register names.
Figure 12. Destination addresses of the obfuscated function calls resolved.

To enable IDA Pro to correctly identify the function arguments, rename local variables and perform proper analysis, we needed to explicitly set the “callee” address for each obfuscated function call using the code shown in Figure 13. This provides IDA Pro with the necessary information to recognize the function as a known Windows API.

Screen capture displaying script for IDA Pro related functions involving memory addresses and internal metadata management. The text is shown in a coding interface with syntax highlighting.
Figure 13. Code to set the “callee” address to each obfuscated function call.

After adding the code shown in Figure 13 to set the callee address, IDA Pro will automatically label function arguments and rename local variables for each obfuscated function call. This significantly improved our ability to read and analyze the code, allowing us to understand the function's purpose more easily. Figure 14 shows some of the function arguments that IDA Pro labeled.

A screenshot displaying a section of assembly language code viewed in a text editor, containing various operation commands and parameters.
Figure 14. Function arguments and local variables renamed for the obfuscated function calls.

After executing this script, we successfully de-obfuscated both the control flow and the function calls within the loader DLL. With the code now significantly more readable and the Windows API calls properly identified, we could proceed with analyzing its core functionality. In the final section, we examine the main purpose of the loader DLL.

Loader DLL Analysis

After removing the obfuscation using the scripts emu_call_rax_idapython.py and emu_call_rax_idapython.py, we easily located the main functionality of the loader DLL.

First, we observed an anti-sandbox check that uses the Windows API GlobalMemoryStatusEx to determine the total physical memory available on the system. The loader DLL will only unpack its payload and execute it in memory if the target machine has at least 6 GB of RAM. Figure 15 shows the pseudocode of the core components of the loader DLL.

A screenshot of a computer screen displaying a segment of code in a text editor, with various functions and variables. The text is sharp and easily readable against a dark background and uses syntax highlighting.
Figure 15. Pseudocode of the core components of the loader DLL.

Conclusion

​​The SLOW#TEMPEST campaign's evolution highlights malware obfuscation techniques, specifically dynamic jumps and obfuscated function calls. This illustrates the importance for security practitioners to adopt advanced dynamic analysis techniques (e.g., emulation) alongside static analysis to effectively dissect and understand modern malware.

The success of the SLOW#TEMPEST campaign using these techniques demonstrates the potential impact of advanced obfuscation on organizations, making detection and mitigation significantly more challenging. Understanding how threat actors leverage these methods is crucial for developing robust detection rules and strengthening defenses against increasingly complex threats.

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Advanced WildFire can detect the malware samples discussed in this article.
  • Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module. The Cortex Shellcode AI module can help detect and prevent shellcode attacks.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 00080005045107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

  • SHA256 hash: a05882750f7caac48a5b5ddf4a1392aa704e6e584699fe915c6766306dae72cc
  • File size: 7.42 MB
  • File description: ISO file distributed in the SLOW#TEMPEST campaign
  • SHA256 hash: 3d3837eb69c3b072fdfc915468cbc8a83bb0db7babd5f7863bdf81213045023c
  • File size: 1.64 MB
  • File description: DLL used to load and execute the payload
  • SHA256 hash: 3583cc881cb077f97422b9729075c9465f0f8f94647b746ee7fa049c4970a978
  • File size: 1.64 MB
  • File description: DLL with encrypted payload in the overlay segment


from Unit 42 https://ift.tt/R5BmD7S
via IFTTT

Thursday, July 10, 2025

​​Forrester names Microsoft a Leader in the 2025 Zero Trust Platforms Wave™ report

We are proud to share that Forrester has named Microsoft a Leader in The Forrester Wave™: Zero Trust Platforms, Q3 2025 report, ranking us highest in the strategy category.

The Forrester Wave: Zero Trust Platforms, Q 3 2025 report.

With so many strong vendors and solutions in the Zero Trust space, you need solid data to make the right choice for your organization. That’s why Forrester’s analysis matters. They provide detailed comparisons of vendor capabilities and strategic vision, helping security leaders evaluate which platforms are best equipped to meet today’s evolving challenges.

Your decision matters now more than ever. The security landscape is evolving rapidly with the rise of generative and agentic AI—where intelligent agents can create and collaborate with other agents, collaborate autonomously, and scale faster than traditional models can keep up. Systems once built for human identities must now manage a growing web of machine identities, each with its own access and risk profile.

In this landscape, adhering to the principles of Zero Trust is critical for protecting sensitive resources, so you can:

  • Expand visibility across your digital environment to reduce security vulnerabilities.
  • Secure your most critical assets while ensuring compliance.
  • Deploy generative AI with confidence.

Microsoft’s end-to-end, integrated approach to Zero Trust

The Forrester report cited our vision for proactive security architecture powered by innovative AI agents that automate complex security, IT, and productivity tasks. But what we believe really caught their attention was our integrated approach—how we bring together capabilities across security, compliance, identity, device management, and privacy, all informed by more than 84 trillion threat signals a day.1 As they noted, “Microsoft excels at tool consolidation and integration, helping reduce costs and overhead.”

Customers interviewed for the report recognized that our “deep cross-platform integration” delivers “real business value” without making customers stitch different solutions together manually. This integration spans the entire Microsoft Security portfolio—Microsoft Defender, Microsoft Purview, Microsoft Intune, Microsoft Sentinel, and Microsoft Entra—to provide a unified platform that secures identities, endpoints, data, apps, infrastructure, and AI. At the heart of this integration are the strong identity management capabilities of Microsoft Entra, which Forrester noted for “deliver[ing] effective least-privilege access enforcement” while enabling data security controls and endpoint management.

Picture a typical attack pattern. Malicious activity in an on-premises system might be detected by Defender for Identity, a compromised device flagged by Defender for Endpoint, and risky insider behavior identified by Purview. These signals converge in Entra conditional access, your centralized policy engine, enabling real-time, risk-based access controls that adapt to emerging threats and, when necessary, block access automatically.

Powered by AI and threat intelligence, our unified security platform surfaces high-priority incidents and recommends next actions, transforming security from a collection of tools into a cohesive defense. You can work within our unified platform to prevent, detect, and respond to incidents across a single integrated system—no jumping between dashboards or correlating signals manually. All of this comes together with Microsoft Security Exposure Management to give full visibility into all your assets and help you proactively reduce risk.

An integrated approach doesn’t mean using only Microsoft solutions. We believe security is a team sport. In fact, the Forrester report recognized the maturity and scale of our global partner ecosystem. We’ve invested heavily in these partnerships because they provide additional signals and specialized protections that make the entire security community stronger. The report also cited our standout community, which provides education, training, and guidance on building Zero Trust architectures to ensure customers have the support they need at every step.

Our commitment to customers and the industry

Through our Secure Future Initiative, we continuously evaluate and strengthen our own security posture, improve the security of our products to better protect customers, and share progress and learnings with the industry. We are also committed to standards, guidelines, and best practices from the National Institute of Standards and Technology (NIST), The Open Group, the Cybersecurity and Infrastructure Security Agency (CISA), and MITRE—not as compliance checkboxes, but because they provide proven frameworks and common vocabulary for implementing effective security.

Take action to improve your security posture

Threats are evolving faster than ever, but so are defenses. With the right Zero Trust security strategy, you can embrace AI’s transformative power while keeping your organization secure. Microsoft’s leadership in Zero Trust, as reflected for us in the latest Forrester Wave™, highlights our commitment to helping you meet these security demands.

For more information on this recognition, check out the full Forrester Wave™: Zero Trust Platforms, Q3 2025 report.

Ready to evaluate your Zero Trust readiness for the AI era? Start with our Zero Trust assessment, host an implementation workshop, or dive into our step-by-step implementation guides.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.


The Forrester Wave™: Zero Trust Platforms, Q3 2025, Joshep Blankenship, Faith Born, and Peter Harrison. July 10, 2025. 

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read about Forrester’s objectivity here .

1Based on Microsoft internal data. Accurate as of July 2025.

The post ​​Forrester names Microsoft a Leader in the 2025 Zero Trust Platforms Wave™ report appeared first on Microsoft Security Blog.



from Microsoft Security Blog https://ift.tt/k0tMI95
via IFTTT

Four Arrested in £440M Cyber Attack on Marks & Spencer, Co-op, and Harrods

Jul 10, 2025Ravie LakshmananCybercrime / Ransomware

The U.K. National Crime Agency (NCA) on Thursday announced that four people have been arrested in connection with cyber attacks targeting major retailers Marks & Spencer, Co-op, and Harrods.

The arrested individuals include two men aged 19, a third aged 17, and a 20-year-old woman. They were apprehended in the West Midlands and London on suspicion of Computer Misuse Act offenses, blackmail, money laundering, and participating in the activities of an organized crime group.

All four suspects were arrested from their homes and their electronic devices have been seized for further forensic analysis. Their names were not disclosed.

"Since these attacks took place, specialist NCA cybercrime investigators have been working at pace and the investigation remains one of the Agency's highest priorities," Deputy Director Paul Foster, head of the NCA's National Cyber Crime Unit, said in a statement.

"Today's arrests are a significant step in that investigation but our work continues, alongside partners in the U.K. and overseas, to ensure those responsible are identified and brought to justice."

According to the Cyber Monitoring Centre (CMC), the April 2025 cyber attacks targeting Marks & Spencer and Co-op have been classified as a "single combined cyber event" with a financial impact of anywhere between £270 million ($363 million) and £440 million ($592 million).

The NCA did not name the "organized crime group" the individuals are part of, but it's believed that some of these attacks have been perpetrated by a decentralized cybercrime group called Scattered Spider, which is notorious for its advanced social engineering ploys to breach organizations and deploy ransomware.

"While ransomware is an ever-present threat, Scattered Spider represents a persistent and capable adversary whose operations have been historically effective even against organizations with mature security programs," Grayson North, Senior Security Consultant at GuidePoint Security, told The Hacker News.

"The success of Scattered Spider is not exactly the result of any new or novel tactics, but rather their expertise in social engineering and willingness to be extremely persistent in attempting to gain initial access to their targets."

The majority of individuals associated with the financially driven group are young, native English speakers which gives them an edge when attempting to gain trust with their targets by making fake calls to IT help desks posing as employees.

Scattered Spider is part of The Com, a larger loose-knit collective that's responsible for a wide range of crimes, including social engineering, phishing, SIM swapping, extortion, sextortion, swatting, kidnapping, and murder.

"Scattered Spider demonstrates a calculated and opportunistic targeting strategy, rotating across industries and geographies based on visibility, payout potential, and operational heat," Halcyon pointed out.

Google-owned Mandiant said Scattered Spider has a habit of focusing on a single sector at a time, while keeping their core tactics, techniques, and procedures (TTPs) consistent. This includes setting up phishing domains that closely mimic legitimate corporate login portals and are designed to trick employees into revealing their credentials.

"This means that organizations can take proactive steps like training their help desk staff to enforce robust identity verification processes and deploying phishing-resistant MFA to defend against these intrusions," said Charles Carmakal, CTO, Mandiant Consulting at Google Cloud.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/fcbuw10
via IFTTT

New ZuRu Malware Variant Targeting Developers via Trojanized Termius macOS App

Jul 10, 2025Ravie LakshmananEndpoint Security / Vulnerability

Cybersecurity researchers have discovered new artifacts associated with an Apple macOS malware called ZuRu, which is known to propagate via trojanized versions of legitimate software.

SentinelOne, in a new report shared with The Hacker News, said the malware has been observed masquerading as the cross‑platform SSH client and server‑management tool Termius in late May 2025.

"ZuRu malware continues to prey on macOS users seeking legitimate business tools, adapting its loader and C2 techniques to backdoor its targets," researchers Phil Stokes and Dinesh Devadoss said.

ZuRu was first documented in September 2021 by a user on Chinese question-and-answer website Zhihu as part of a malicious campaign that hijacked searches for iTerm2, a legitimate macOS Terminal app, to direct users to fake sites that tricked unsuspecting users into downloading the malware.

Then in January 2024, Jamf Threat Labs said it discovered a piece of malware distributed via pirated macOS apps that shared similarities with ZuRu. Some of the other popular software that has been trojanized to deliver the malware include Microsoft's Remote Desktop for Mac, along with SecureCRT and Navicat.

The fact that ZuRu primarily relies on sponsored web searches for distribution indicates the threat actors behind the malware are more opportunistic than targeted in their attacks, while also ensuring that only those looking for remote connections and database management are compromised.

Like the samples detailed by Jamf, the newly discovered ZuRu artifacts employ a modified version of the open-source post-exploitation toolkit known as Khepri to enable attackers to gain remote control of infected hosts.

"The malware is delivered via a .dmg disk image and contains a hacked version of the genuine Termius.app," the researchers said. "Since the application bundle inside the disk image has been modified, the attackers have replaced the developer's code signature with their own ad hoc signature in order to pass macOS code signing rules."

The altered app packs in two extra executables within Termius Helper.app, a loader named ".localized" that's designed to download and launch a Khepri command-and-control (C2) beacon from an external server ("download.termius[.]info") and ".Termius Helper1," which is a renamed version of the actual Termius Helper app.

"While the use of Khepri was seen in earlier versions of ZuRu, this means of trojanizing a legitimate application varies from the threat actor's previous technique," the researchers explained.

"In older versions of ZuRu, the malware authors modified the main bundle's executable by adding an additional load command referencing an external .dylib, with the dynamic library functioning as the loader for the Khepri backdoor and persistence modules."

Besides downloading the Khepri beacon, the loader is designed to set up persistence on the host and checks if the malware is already present at a pre-defined path in the system and employs("/tmp/.fseventsd") and if so, compares the MD5 hash value of the payload against the one that's hosted on the server.

A new version is subsequently downloaded if the hash values don't match. It's believed that the feature likely serves as an update mechanism to fetch new versions of the malware as they become available. But SentinelOne also theorized it could be a way to ensure that the payload has not been corrupted or modified after it was dropped.

The modified Khepri tool is a feature-packed C2 implant that allows file transfer, system reconnaissance, process execution and control, and command execution with output capture. The C2 server used to communicate with the beacon is "ctl01.termius[.]fun."

"The latest variant of macOS.ZuRu continues the threat actor's pattern of trojanizing legitimate macOS applications used by developers and IT professionals," the researchers said.

"The shift in technique from Dylib injection to trojanizing an embedded helper application is likely an attempt to circumvent certain kinds of detection logic. Even so, the actor's continued use of certain TTPs - from choice of target applications and domain name patterns to the reuse of file names, persistence and beaconing methods - suggest these are offering continued success in environments lacking sufficient endpoint protection."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/kCtI8S3
via IFTTT