The Feed 2025-03-24

alt text

AI Generated Podcast

https://open.spotify.com/episode/1G6LkGEMv494tLFnkzcLWM?si=ikHgRovURmGJwOKkKi48Zw

Summarized Stories

  • Next.js and the corrupt middleware: the authorizing artifact: This article describes a critical vulnerability (CVE-2025-29927) in Next.js middleware that allows attackers to bypass authentication and other middleware functionalities by manipulating a specific HTTP header, affecting all versions and potentially leading to significant security issues, along with the discovery, impact, and patching of this flaw.

  • New GitHub Action supply chain attack: reviewdog/action-setup: This article discusses a supply chain attack that compromised the tj-actions/changed-files GitHub Action (potentially originating from reviewdog/action-setup), leading to the exposure of sensitive CI/CD secrets in workflow logs and highlighting the risks of third-party dependencies in software development pipelines.

  • The Biggest Supply Chain Hack Of 2025: 6M Records For Sale Exfiltrated from Oracle Cloud Affecting over 140k Tenants: This article reports a claim by a threat actor to have exfiltrated 6 million records from Oracle Cloud’s SSO and LDAP, potentially through a vulnerability in the login endpoint, and the actor’s attempts to sell this data, while Oracle denies any such breach occurred.

  • Microsoft Trust Signing service abused to code-sign malware: This article reports on the abuse of Microsoft’s Trusted Signing service by cybercriminals to sign malware with short-lived certificates, allowing it to appear legitimate and potentially evade security measures, and Microsoft’s efforts to detect and revoke these certificates.

  • Arcane stealer: We want all your data: This article details the discovery of a new stealer malware named Arcane, distributed via YouTube game cheat promotions and a loader, which collects extensive account information and system data using various techniques and has replaced a previous stealer, VGS, in targeting primarily Russian-speaking users.

Next.js and the corrupt middleware: the authorizing artifact

Summmary

This article details a critical security vulnerability, identified as CVE-2025-29927, found in the middleware of the popular JavaScript framework Next.js. The vulnerability allows attackers to bypass authentication and authorization mechanisms implemented within the middleware layer by manipulating the x-middleware-subrequest HTTP header. This bypass affects all versions of Next.js starting from 11.1.4 up to the patched versions, with no specific preconditions required for exploitation. The article explains the evolution of the vulnerability across different Next.js versions, the techniques used to exploit it, and the potential impacts, including authorization bypass, CSP bypass, and denial-of-service via cache poisoning. The discoverers reported the vulnerability, and patches and workarounds have been released by the Next.js team. Security advisories have been issued, and hosting platforms like Vercel and Netlify have implemented mitigations.

Technical Details

The core of the vulnerability lies in how Next.js middleware, which allows running code before a request is completed to modify the response or request, handles a specific HTTP header: x-middleware-subrequest. The purpose of this header was to determine whether or not the middleware should be applied to a given request.

Versions Prior to 12.2: In older versions of Next.js (before 12.2), when middleware was configured, the runMiddleware function would retrieve the value of the x-middleware-subrequest header. This header’s value was split into a list using the colon (:) as a separator. The system would then check if this list contained middlewareInfo.name, which was the path where the middleware file was located. Before version 12.2, middleware files had to be named _middleware.ts and placed within the pages directory due to the exclusive use of the pages router at that time.

Therefore, to bypass the middleware in these older versions, an attacker could include the x-middleware-subrequest header in their request with a value equal to pages/_middleware. This would trick the runMiddleware function into thinking the request was an internal sub-request for the middleware itself, causing it to be ignored and the original request to proceed to its destination without middleware intervention.

For applications with nested routes and multiple middleware files, the middlewareInfo.name would correspond to the directory path of the specific _middleware.ts file relative to the pages directory. For example, for /dashboard/panel/admin protected by middleware, the x-middleware-subrequest header could be pages/dashboard/_middleware or pages/dashboard/panel/_middleware depending on where the relevant middleware was located.

Versions 12.2 and Later: Starting with version 12.2, significant changes were made to middleware conventions. Middleware files were renamed to middleware.ts (without the underscore) and were no longer required to be located in the pages folder. Notably, the introduction of the app router in version 13, which could have complicated the exploit, was circumvented by this change in middleware location.

In these versions, the middlewareInfo.name became simply middleware if the middleware was in the root directory, or src/middleware if the application utilized the optional /src directory. Thus, the bypass payload for these versions became x-middleware-subrequest: middleware or x-middleware-subrequest: src/middleware.

More Recent Versions (e.g., 15.1.7): In even more recent versions, the logic was slightly modified to prevent recursive requests. While the x-middleware-subrequest header was still used and its value split by colons, the condition for bypassing the middleware changed. A constant MAX_RECURSION_DEPTH was introduced (set to 5), and a depth counter was incremented for each value in the subrequests list (derived from the x-middleware-subrequest header) that matched params.name (the path to the middleware, either middleware or src/middleware).

The middleware is bypassed if the depth becomes greater than or equal to MAX_RECURSION_DEPTH. This means an attacker needs to provide the x-middleware-subrequest header with at least five repetitions of the correct middleware path to bypass it:

  • x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
  • x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Exploitation Examples: The article provides examples of how this vulnerability can be exploited in real-world scenarios.

  • Authorization/Rewrite Bypass: An application protecting /admin/login with middleware that rewrites unauthenticated requests to another page can be bypassed by including the crafted x-middleware-subrequest header, allowing unauthorized access to the protected endpoint.
  • CSP Bypass: Middleware used to set Content Security Policy (CSP) headers and cookies can be entirely bypassed, leaving the application vulnerable to various client-side attacks.
  • DoS via Cache-Poisoning: If a site uses middleware for path rewriting based on geolocation and lacks a resource on the root path (/), bypassing the middleware can lead to a 404 error on the root. If this 404 response is cached by a CDN due to a crafted request with the bypass header, it can render the site unusable.

Detection and Remediation: Publicly disclosed checks for this vulnerability often rely on the presence of specific headers like x-middleware-rewrite, x-middleware-next, or x-middleware-redirect in the response, which may not always be present, especially in cases where middleware performs redirects. Assetnote’s research identified that sending the x-nextjs-data: 1 header can coerce Next.js to respond with an internal header x-nextjs-rewrite or x-nextjs-redirect even during a middleware redirect, providing a more reliable detection method. They also devised a polyglot payload for the X-Middleware-Subrequest header to cover various potential bypass cases in a single request: X-Middleware-Subrequest: src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware

The recommended remediation is to upgrade Next.js to the patched versions:

  • Next.js 15.x: Upgrade to 15.2.3 or higher
  • Next.js 14.x: Upgrade to 14.2.25 or higher
  • Next.js 13.x: Upgrade to 13.5.9 or higher

If upgrading is not immediately feasible, the recommended workaround is to prevent external user requests containing the x-middleware-subrequest header from reaching the Next.js application.

Industries

The article mentions that Next.js is widely used across critical sectors, including banking services and blockchain. This suggests that organizations in these and potentially many other industries relying on Next.js for their web applications could be affected.

Recommendations

  • Upgrade Next.js: Immediately update to the patched versions: 15.2.3+ for 15.x, 14.2.25+ for 14.x, and 13.5.9+ for 13.x.
  • Implement Workaround (if patching is infeasible): Prevent external requests with the x-middleware-subrequest header from reaching your Next.js application. This can be done at the web server or CDN level.
  • Review Middleware Usage: Understand how middleware is used in your Next.js application, especially for sensitive functions like authentication and authorization.
  • Monitor for Suspicious Headers: Implement monitoring to detect requests containing the x-middleware-subrequest header, especially with unexpected or malicious values.

Hunting methods

The Assetnote team suggests the following HTTP requests for detecting the vulnerability:

Initial Detection Request:

GET / HTTP/2
Host: target
Accept-Encoding: gzip, deflate, br
X-Nextjs-Data: 1
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
Connection: close
Cache-Control: max-age=0

Logic: This request includes the X-Nextjs-Data: 1 header to potentially elicit an x-nextjs-redirect, x-middleware-rewrite, or x-nextjs-rewrite header in the 307 redirect response if middleware is active and performing a redirect or rewrite.

Exploit Payload Request: If the initial request indicates the presence of middleware redirection or rewriting, the following request can be sent to attempt the bypass:

GET / HTTP/2
Host: target
Accept-Encoding: gzip, deflate, br
X-Nextjs-Data: 1
X-Middleware-Subrequest: src/middleware:nowaf:src/middleware:src/middleware:src/middleware:src/middleware:middleware:middleware:nowaf:middleware:middleware:middleware:pages/_middleware
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
Cache-Control: max-age=0

Logic: This request includes the X-Middleware-Subrequest header with a polyglot payload designed to cover various potential middleware configurations and bypass the logic in different Next.js versions. A successful bypass might result in a HTTP 200 OK response on a protected resource.

General Hunting: Security teams can monitor web server logs and network traffic for the presence of the x-middleware-subrequest header in incoming requests. Unexpected or excessively long values for this header, especially those containing repetitions of “middleware”, “src/middleware”, or “pages/_middleware”, should be investigated.

IOC

No specific IPs, domains, or file hashes are mentioned in the article related to malicious activity. The IOC is primarily the vulnerable component itself (Next.js versions) and the method of exploitation (the x-middleware-subrequest header manipulation).

Original links:
https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware

https://slcyber.io/assetnote-security-research-center/doing-the-due-diligence-analysing-the-next-js-middleware-bypass-cve-2025-29927

New GitHub Action supply chain attack: reviewdog/action-setup

Summmary

Cybersecurity companies Wiz and Palo Alto Networks reported a supply chain attack that compromised the tj-actions/changed-files GitHub Action, impacting over 23,000 repositories. Attackers injected malicious code into tagged releases by modifying them to point to a dangling commit containing a payload designed to extract CI/CD secrets from the runner’s memory and expose them in workflow logs. This was facilitated by the compromise of a GitHub Personal Access Token (PAT) belonging to the @tj-actions-bot account and a lack of security controls in the repository, such as the absence of signed commits and branch/tag protection rules. The compromise is believed to have originated from a prior compromise of the reviewdog/action-setup repository, which indirectly impacted tj-actions/changed-files through its dependency on tj-actions/eslint-changed-files , leading to the compromise of additional actions within the reviewdog organization. The malicious activity occurred between 9 a.m. PT March 14, 2025, and 3 p.m. PT March 15, 2025, affecting workflows using vulnerable tags or branches of the compromised actions. The exposed secrets, printed double-encoded in Base64 in public workflow logs, could grant attackers unauthorized access and the ability to tamper with code. The attack also targeted Coinbase, with an unsuccessful attempt to compromise their agentkit repository. The maintainers of tj-actions disclosed that a compromised GitHub PAT was the root cause. The malicious commits and the associated GitHub gist have been reverted/deleted. The primary risk of continued exposure lies in the secrets within the logs of affected public repositories. The v1 tag of the reviewdog/action-setup GitHub Action was compromised earlier, around March 11, 2025. This incident is tracked as CVE-2025-30066 for tj-actions/changed-files and CVE-2025-30154 for reviewdog/action-setup. Immediate action is necessary to mitigate credential theft and CI pipeline compromise.

Technical Details

alt text alt text The attack on tj-actions/changed-files involved manipulating historical version tags to point to a malicious commit with the SHA1 hash 0e58ed8671d6b60d0890c21b07f8835ace038e67. This was achieved by leveraging a leaked GitHub Personal Access Token (PAT) associated with the @tj-actions-bot account. The attackers also impersonated the renovate[bot] user to make the malicious commit appear legitimate. The success was facilitated by the lack of security controls in the tj-actions/changed-files repository, specifically the absence of required signed commits and branch and tag protection rules.

The malicious commit contained a Python script designed to extract CI/CD secrets from the memory of the GitHub Actions runner. These secrets were then printed directly into the workflow logs, double-encoded in Base64 text. The types of secrets potentially exposed include API keys, access tokens, deployment credentials, and the unique GITHUB_TOKEN generated for each workflow run. A GITHUB_TOKEN with ‘write’ permissions could allow an attacker to push malicious code.

The attack chain suggests an initial compromise of the reviewdog/action-setup action. Malicious code was pushed to this action, which was an indirect dependency of tj-actions/changed-files via the tj-actions/eslint-changed-files action. This implies that tj-actions/eslint-changed-files was also compromised. The v1 tag of reviewdog/action-setup was pointed to a malicious commit on March 11th between 18:42 and 20:31 UTC before being reverted. The attacker might have force-pushed back to the older commit to conceal the compromise. The payload in the compromised reviewdog/action-setup action was distinct from the tj-actions/changed-files payload and was base64 encoded and directly inserted into the install.sh file used by the workflow. This payload also aimed to dump CI runner memory containing workflow secrets.

The malicious activity on tj-actions/changed-files occurred between 9 a.m. PT March 14, 2025, and 3 p.m. PT March 15, 2025. The impact was limited to workflows referencing tj-actions/changed-files or tj-actions/eslint-changed-files and pointed to vulnerable tags or branches within this timeframe, as well as any actions created by the reviewdog organization.

Wiz identified GitHub identities related to the attack, indicating the attacker is active in the crypto ecosystem, French and English speaking, and with working hours aligned to Europe or Africa. A commit on tj-actions/changed-files from March 13th contained a payload variant explicitly targeting Coinbase repositories. A workflow log in coinbase/agentkit from March 14th showed a parallel compromise attempt by the same actor. The removal of changelog.yml in tj-actions/changed-files, a workflow using the compromised action, occurred shortly before public disclosure.

The maintainer of reviewdog identified and remediated the compromised user account that led to the action-setup incident with assistance from GitHub. This account was itself compromised, not maliciously added.

Industries

The attacker’s activity and payload targeting suggest an interest in the cryptocurrency industry, specifically targeting Coinbase. The widespread use of GitHub Actions implies that many other industries utilizing the affected actions could also be at risk.

Recommendations

Immediate Steps for Affected Users:

  • Identify usage: Search repositories for the use of tj-actions/changed-files and other mentioned actions. The other mentioned actions are: reviewdog/action-setup@v1, reviewdog/action-shellcheck, reviewdog/action-composite-template, reviewdog/action-staticcheck, reviewdog/action-ast-grep, and reviewdog/action-typos.
  • Review workflow logs: Examine past workflow runs for evidence of secret exposure, particularly if logs are public, looking for Base64 encoded text. Specifically, for reviewdog/action-setup@v1, check the “Run reviewdog/action-setup@v1” step for a line titled “🐶 Preparing environment …” and a double-encoded base64 string within.
  • Rotate secrets: Revoke and regenerate any credentials that may have been exposed, including API keys, access tokens, and deployment credentials.
  • Investigate malicious activity: If there are signs of the compromised action being executed, investigate further for any other indicators of malicious activity.
  • Stop using the impacted actions immediately and replace them with safer alternatives if possible.
  • Remove all references to the actions across all branches of your repositories.
  • Consider downloading workflow logs from the exposure window before deleting them.

Long-Term Security Improvements:

  • Govern third-party services in use: Implement vetting procedures to ensure external actions are approved before integration.
  • Implement strict Pipeline-Based Access Controls (PBAC): Reduce permissions granted to GitHub Actions workflows to the minimum necessary and use fine-grained, short-lived tokens instead of long-term, broadly scoped secrets.
  • Pin GitHub actions: Instead of referencing by tag or branch (e.g., @v3 or @main), pin actions to a full-length commit SHA-1 hash to ensure code immutability.
  • Use verified actions.
  • Restrict the usage of GitHub actions allowed in the repository/organization, potentially limiting them to Enterprise actions.
  • Avoid defining read-all or write-all permissions for the GITHUB_TOKEN in pipeline configurations.
  • Avoid using insecure long-term credentials for cloud provider access from GitHub Actions.
  • Utilize OpenID Connect (OIDC) authentication to replace long-term credentials with short-lived access tokens for interacting with cloud providers.
  • Audit past workflow runs for suspicious activity, checking for unusual outbound network requests.
  • Use GitHub’s allow-listing feature to block unauthorized GitHub Actions from running and configure GitHub to allow only trusted actions.

Palo Alto Networks customers are advised to refer to specific out-of-the-box policies in their Prisma Cloud or Cortex Cloud environments related to unpinned GitHub actions, unrestricted usage of GitHub actions, and excessive pipeline permissions.

If the only exposed secrets were GitHub tokens beginning with the prefix ghs_, these are short-lived and automatically expire within 24 hours or once the workflow job is completed, limiting long-term risk. Workflows that do not explicitly reference custom secrets are also less likely to have been significantly compromised.

Hunting methods

The provided GitHub query can be used to find references to the affected GitHub Actions in an organization’s repositories:

org:<yourorg> (reviewdog/action-setup@v1 OR reviewdog/action-shellcheck OR reviewdog/action-composite-template OR reviewdog/action-staticcheck OR reviewdog/action-ast-grep OR reviewdog/action-typos) AND secrets. language:yaml path:/^\.github\/workflows\//

Logic: This query searches within files under the .github/workflows/ directory (where GitHub Actions workflows are defined) for the specified compromised actions from the reviewdog organization. It also looks for the keyword “secrets” within these files, which might indicate where secrets are being used in conjunction with the vulnerable actions. Replacing <yourorg> with the actual GitHub organization name will scope the search to that organization.

Security teams should also examine past workflow runs for evidence of secret exposure, looking for double-encoded Base64 strings in the logs, especially for public repositories. For reviewdog/action-setup@v1, the presence of the “🐶 Preparing environment …” line followed by a double-encoded Base64 string indicates malicious payload execution.

Auditing past workflow runs for suspicious activity, such as unusual outbound network requests, is also recommended. Prioritize reviewing repositories where CI runner logs are publicly accessible.

IOC

File Hashes:

0e58ed8671d6b60d0890c21b07f8835ace038e67

GitHub Accounts:

@tj-actions-bot
renovate[bot]
haya14busa

Compromised GitHub Actions:

tj-actions/changed-files
reviewdog/action-setup@v1
tj-actions/eslint-changed-files
reviewdog/action-shellcheck
reviewdog/action-composite-template
reviewdog/action-staticcheck
reviewdog/action-ast-grep
reviewdog/action-typos

CVEs:

CVE-2025-30066
CVE-2025-30154

Original links:
https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack

The Biggest Supply Chain Hack Of 2025: 6M Records For Sale Exfiltrated from Oracle Cloud Affecting over 140k Tenants

Summmary

On March 21, 2025, CloudSEK discovered a threat actor named “rose87168” offering to sell 6 million records allegedly exfiltrated from Oracle Cloud’s Single Sign-On (SSO) and Lightweight Directory Access Protocol (LDAP) systems. The stolen data reportedly includes JKS files, encrypted SSO passwords, key files, and enterprise manager JPS keys, affecting over 140,000 Oracle Cloud tenants. The threat actor claims to have exploited a possible undisclosed vulnerability on the Oracle Cloud login endpoint login.(region-name).oraclecloud.com to gain unauthorized access. They are incentivizing decryption of the stolen passwords and demanding payment for the removal of affected companies’ data. While Oracle has denied any breach of their cloud services, the threat actor has provided evidence suggesting access to at least one subdomain, login.us2.oraclecloud.com. CloudSEK assesses this threat as High in severity due to the sensitive nature of the exposed data. The threat actor, despite being new, exhibits high sophistication.

Technical Details

The threat actor, “rose87168,” claims to have exfiltrated approximately 6 million records from Oracle Cloud’s SSO and LDAP. The compromised data allegedly includes sensitive authentication-related information such as JKS files, encrypted SSO passwords, key files, and enterprise manager JPS keys. The threat actor claims to have gained access by hacking the login endpoint login.(region-name).oraclecloud.com. Specifically, they claimed to have compromised the subdomain login.us2.oraclecloud.com, which they state has since been taken down.

Evidence provided by the threat actor includes an Internet Archive URL showing the upload of a text file containing their ProtonMail address (rose87168@proton.me) to the login.us2.oraclecloud.com server. Analysis of the login.us2.oraclecloud.com subdomain via the Wayback Machine indicates that it was hosting Oracle Fusion Middleware 11G and was last captured on February 17, 2025. Further investigation using FOFA suggests that the Oracle Fusion Middleware server was last updated around September 27, 2014.

CloudSEK identified a critical vulnerability, CVE-2021-35587, affecting Oracle Access Manager (OpenSSO Agent) within Oracle Fusion Middleware. The affected versions include 11.1.2.3.0, 12.2.1.3.0, and 12.2.1.4.0. This vulnerability is described as easily exploitable by an unauthenticated attacker with network access via HTTP, potentially leading to a complete takeover of Oracle Access Manager (OAM). CVE-2021-35587 was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog in December 2022.

The threat actor informed BleepingComputer that they compromised a vulnerable version of Oracle Cloud servers using a public CVE that currently lacks a public Proof-of-Concept (PoC) or exploit. However, CloudSEK’s analysis points towards the exploitation of the older CVE-2021-35587, for which a known public exploit exists, possibly due to a lack of patch management. The successful exploitation of this vulnerability aligns with the types of data allegedly leaked.

The threat actor has been active since January 2025 and has no prior history on hacking forums, but their methods and the data shared suggest a high level of sophistication. They are attempting to extort affected companies by demanding a “fee” for data removal before potentially selling it on the BreachForums hacking forum. They are also seeking assistance in decrypting the SSO passwords and cracking the LDAP hashes, offering to share data in return. The threat actor created an X (formerly Twitter) page and started following Oracle-related accounts.

Industries

The attack potentially affects over 140,000 tenants using Oracle Cloud services, implying a wide range of industries could be impacted. The screenshot of the threat actor’s X account shows them following accounts of major companies like Tesla, Chase, Adidas, Nike, Mastercard, Visa, Oracle Digital Experience, Oracle Press, Oracle Analytics, and Oracle Exadata, suggesting a broad targeting or at least an awareness of prominent Oracle customers.

Recommendations

The following mitigation steps are recommended:

Immediate Security Measures:

  • Reset Passwords: Immediately reset passwords for all compromised LDAP user accounts, with a focus on privileged accounts like Tenant Admins. Enforce strong password policies and Multi-Factor Authentication (MFA).
  • Update SASL Hashes: Regenerate SASL/MD5 hashes or migrate to a more secure authentication method.

Tenant-Level Credential Rotation:

  • Contact Oracle Support immediately to rotate tenant-specific identifiers (e.g., orclmttenantguid, orclmttenantuname) and discuss necessary remediation steps.

Regenerate Certificates and Secrets:

  • Regenerate and replace any SSO/SAML/OIDC secrets or certificates associated with the compromised LDAP configuration.

Audit and Monitoring:

  • Review LDAP logs for suspicious authentication attempts.
  • Investigate recent account activities to detect potential unauthorized access.
  • Implement continuous monitoring to track unauthorized access and anomalous behavior.

Enhanced Security Protocols:

  • Immediate Credential Rotation: Rotate all SSO, LDAP, and associated credentials, ensuring strong password policies and enforcing MFA.
  • Incident Response & Forensics: Conduct a comprehensive investigation to identify potential unauthorized access and mitigate further risks.
  • Threat Intelligence Monitoring: Continuously monitor dark web and threat actor forums for discussions related to the leaked data.
  • Engage with Oracle Security: Report the incident to Oracle for verification and to seek patches or mitigations.
  • Strengthen Access Controls: Implement strict access policies, adopt the principle of least privilege, and enhance logging mechanisms to detect anomalies and prevent future breaches.

Hunting methods

The sources do not explicitly provide specific Yara, Sigma, KQL, SPL, or other hunting queries. However, based on the technical details, the following hunting strategies can be employed:

  • LDAP Log Analysis: Review LDAP logs for unusual authentication patterns, failed login attempts from unexpected sources, or successful logins to accounts that have not been recently accessed. Look for activity originating from IPs not associated with normal user activity.
  • Authentication Log Analysis: Monitor SSO and application logs for suspicious activity following the timeframe of the alleged breach (around 40 days prior to March 21, 2025). Look for successful logins from unusual geolocations or using unusual user-agents.
  • Network Traffic Monitoring: Analyze network traffic for any communication with known threat actor infrastructure (if any emerges) or unusual outbound traffic patterns, especially to external or untrusted destinations.
  • Endpoint Monitoring: Investigate any unusual processes or access to sensitive key files (JKS, JPS keys) on systems associated with Oracle Cloud management.
  • Monitoring for Credential Dumping Tools: Look for the presence or execution of tools commonly used for credential dumping on systems that might have been compromised.

The logic behind these methods is to identify any anomalies or indicators of compromise resulting from the alleged unauthorized access to Oracle Cloud environments. This involves looking for deviations from normal behavior in authentication patterns, network traffic, and endpoint activity.

IOC

Email Addresses:

  • rose87168@proton.me

Domains:

  • login.(region-name).oraclecloud.com
  • login.us2.oraclecloud.com

CVEs:

  • CVE-2021-35587

Original links:
https://cloudsek.com/blog/the-biggest-supply-chain-hack-of-2025-6m-records-for-sale-exfiltrated-from-oracle-cloud-affecting-over-140k-tenants

https://www.bleepingcomputer.com/news/security/oracle-denies-data-breach-after-hacker-claims-theft-of-6-million-data-records

Microsoft Trust Signing service abused to code-sign malware

Summmary

Cybercriminals are abusing Microsoft’s Trusted Signing platform to sign their malware executables using short-lived, three-day certificates. Threat actors seek code-signing certificates to make their malware appear legitimate and bypass security filters. While Extended Validation (EV) certificates offer greater trust, they are harder to obtain and are usually revoked after malware campaigns. The Microsoft Trusted Signing service, launched in 2024, offers an easier way for developers to sign their programs with Microsoft-managed certificates. Threat actors are exploiting this service to obtain certificates issued by “Microsoft ID Verified CS EOC CA 01”. These certificates, though valid for only three days, allow signed malware to be considered valid until revocation. This abuse has been observed in malware campaigns, including those involving Crazy Evil Traffers crypto-theft and Lumma Stealer. Microsoft offers the Trusted Signing service as a $9.99 monthly subscription, providing security features like short-lived, easily revocable certificates and a SmartScreen reputation boost. While Microsoft implements checks to prevent abuse, such as requiring companies to be in business for three years for certificates under their name, individuals can get approved more easily. Researchers believe this shift towards Microsoft’s service is due to its convenience and ambiguity surrounding changes to EV certificates. Microsoft states they actively monitor for and mitigate abuse by revoking certificates and suspending accounts.

Technical Details

Threat actors are leveraging the Microsoft Trusted Signing service, a cloud-based platform launched in 2024, to code-sign malware. The service is designed to provide developers with an easy way to sign their executables using certificates managed by Microsoft. This abuse circumvents the traditional challenges of obtaining code-signing certificates, especially Extended Validation (EV) certificates, which require rigorous verification or theft and are often quickly revoked after malicious use.

The key TTP observed is the exploitation of Microsoft’s own legitimate code-signing infrastructure. Instead of acquiring or stealing certificates directly, threat actors are utilizing the Trusted Signing service to generate short-lived (three-day) code-signing certificates issued by “Microsoft ID Verified CS EOC CA 01”. This allows their malware to appear as if it’s signed by a Microsoft-verified entity, potentially bypassing security filters and gaining trust from cybersecurity programs, including a potential SmartScreen reputation boost.

While the certificates are only valid for three days, executables signed with them remain valid until the certificate is explicitly revoked by the issuer (Microsoft). This short validity period likely reduces the risk to the threat actors, as the certificates would expire relatively quickly even if not revoked. Furthermore, Microsoft states that these certificates provide a similar SmartScreen reputation boost to those signed directly by Microsoft.

The researchers observed this technique in multiple ongoing malware campaigns, including those distributing Crazy Evil Traffers (a crypto-theft malware) and Lumma Stealer (an information stealer). This indicates that the abuse of the Microsoft Trusted Signing service is not an isolated incident.

A cybersecurity researcher known as ‘Squiblydoo’ suggests that the shift towards using Microsoft’s certificates is driven by convenience and the unclear future of EV certificates. The verification process for Microsoft’s service is considered substantially easier than that for EV certificates.

Microsoft’s Trusted Signing service is offered through a $9.99 monthly subscription. It aims to enhance security by using short-lived certificates that are not directly issued to developers, reducing the risk of certificate theft. To mitigate abuse, Microsoft has implemented a policy requiring companies to be in business for three years to obtain certificates under their name, while individuals can be approved more easily for certificates issued under their own name.

Microsoft has stated that they use active threat intelligence monitoring to detect and respond to misuse of their signing service by revoking certificates and suspending accounts. They confirmed that the identified malware samples are detected by their antimalware products and that they have taken action to revoke the associated certificates and prevent further account abuse.

Industries

Not explicitly mentioned in the sources. However, the fact that the signed malware includes crypto-theft and information-stealing capabilities suggests a broad potential impact across various industries that may be targeted by such malware.

Recommendations

The sources do not contain specific technical recommendations for defense against this particular abuse. However, general recommendations based on the observed TTPs would include:

  • Maintain up-to-date endpoint detection and response (EDR) solutions and antivirus software: Microsoft states that their antimalware products detect the malicious samples. Ensuring these solutions are current is crucial.
  • Continue to scrutinize signed executables: While a valid signature can increase trust, it should not be the sole factor in determining the legitimacy of a file. Analyze the behavior and origin of signed executables, especially those with short-lived certificates or issued by unexpected entities.
  • Monitor for executables signed by “Microsoft ID Verified CS EOC CA 01”: While legitimate developers might use this service, a sudden increase in executables signed by this issuer, especially if associated with unusual or suspicious activity, could be an indicator of abuse.
  • Implement robust application control policies: Consider using application whitelisting or other application control mechanisms to restrict the execution of unapproved or suspicious signed executables.
  • Stay informed about threat intelligence: Keep abreast of emerging TTPs and indicators related to the abuse of code-signing services.

Hunting methods

The sources do not provide specific hunting queries. However, the following hunting strategies can be employed to detect potential abuse of the Microsoft Trusted Signing service:

  • Monitor for newly observed executables signed by “Microsoft ID Verified CS EOC CA 01”: Implement telemetry to track the appearance of new signed executables within your environment and identify those signed by this specific issuer. Investigate any unexpected or unusual occurrences.
    • Logic: Threat actors are using these specific short-lived certificates. Identifying new instances of these signatures can help detect potential malware.
  • Correlate short-lived certificates with suspicious process execution: Look for executables signed by “Microsoft ID Verified CS EOC CA 01” that exhibit suspicious behavior shortly after their first appearance in your environment.
    • Logic: Malware signed with these certificates will still perform malicious actions. Correlating the signature with behavior can identify malicious use.
  • Analyze the network traffic of executables signed by “Microsoft ID Verified CS EOC CA 01”: Monitor network connections initiated by processes signed with these certificates for any communication with known malicious infrastructure or unusual destinations.
    • Logic: Malware often communicates with command-and-control servers. Analyzing network traffic can reveal malicious activity even if the executable is signed.
  • Investigate endpoints where multiple newly signed executables with short validity periods are observed: Threat actors might be deploying various malicious tools signed using this method. A high volume of such executables appearing on a single endpoint could be suspicious.
    • Logic: This could indicate a compromised system where multiple signed malware samples are being dropped.

IOC

Issuing Certificate Authority:

  • Microsoft ID Verified CS EOC CA 01

Malware Families (Observed Abusing the Service):

  • Crazy Evil Traffers
  • Lumma Stealer

Original link: https://www.bleepingcomputer.com/news/security/microsoft-trust-signing-service-abused-to-code-sign-malware/

Arcane stealer: We want all your data

Summmary

A new information stealer named Arcane was discovered at the end of 2024, distributed through YouTube videos promoting game cheats. This malware collects a wide range of data, including account information from VPN and gaming clients, as well as various network utilities. The initial distribution involved password-protected archives downloaded from links in the YouTube videos, containing a batch file (start.bat) and the UnRAR.exe utility. The batch file was obfuscated and used PowerShell to download and unpack another password-protected archive, which ultimately contained a miner and the Arcane stealer executable. The stealer, named after ASCII art in its code, superseded a previously used stealer variant called VGS (a rebranded Phemedrone Trojan) in the same campaign. Later in the campaign, the threat actors shifted to promoting a loader called ArcanaLoader, supposedly for downloading cheats and cracks, but which also delivered the Arcane stealer. The threat actors appear to be targeting a Russian-speaking audience based on the language used in their communications and the geographic distribution of victims.

Technical Details

The initial infection vector involved YouTube videos advertising game cheats. These videos contained links to password-protected ZIP or RAR archives hosted on file-sharing services or cloud storage. Upon extraction, users would find a start.bat batch file in the root and UnRAR.exe in a subfolder. The obfuscated start.bat file’s primary function was to use PowerShell to download another password-protected archive from a specified URL (in one instance, a Dropbox link is mentioned) and unpack it using the included UnRAR.exe utility with the password embedded within the batch script.

A key aspect of the start.bat script was its attempt to disable Windows SmartScreen. It achieved this by:

  • Adding every drive root folder to SmartScreen filter exceptions using PowerShell’s Add-MpPreference -ExclusionPath $_.Root command.
  • Resetting the EnableWebContentEvaluation registry key in HKCU\Software\Microsoft\Windows\CurrentVersion\AppHost to 0.
  • Setting the SmartScreenEnabled registry key in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer to "Off" using the reg.exe utility.

The downloaded archive (black.rar in the report example) invariably contained two executables: a miner and the Arcane stealer (which replaced the earlier “VGS” stealer). The “VGS” stealer was identified as a rebranded Phemedrone Trojan variant, which included a logo with the name “VGS” in its activity reports.

The Arcane stealer, which appeared later in 2024, collects a significant amount of data. It targets:

  • VPN clients: OpenVPN, Mullvad, NordVPN, IPVanish, Surfshark, Proton, hidemy.name, PIA, CyberGhost, ExpressVPN.
  • Network clients and utilities: ngrok, Playit, Cyberduck, FileZilla, DynDNS.
  • Messaging apps: ICQ, Tox, Skype, Pidgin, Signal, Element, Discord, Telegram, Jabber, Viber.
  • Email clients: Outlook.
  • Gaming clients and services: Riot Client, Epic, Steam, Ubisoft Connect (ex-Uplay), Roblox, Battle.net, various Minecraft clients.
  • Crypto wallets: Zcash, Armory, Bytecoin, Jaxx, Exodus, Ethereum, Electrum, Atomic, Guarda, Coinomi.
  • Browser data (Chromium and Gecko-based): logins, passwords, credit card data, tokens, cookies.

Arcane also gathers extensive system information, including OS version, installation date, system activation key, username, computer name, location, CPU, memory, graphics card, drives, network and USB devices, and installed antimalware and browsers. Additionally, it takes screenshots, obtains lists of running processes and saved Wi-Fi networks, and retrieves the passwords for those networks.

A notable technique used by Arcane is its handling of browser data encryption keys. While it utilizes the Data Protection API (DPAPI), common among stealers, it also employs a separate executable named Xaitax to crack browser keys. This utility is dropped to disk, executed covertly, and its console output containing the cracked keys is retrieved by the stealer.

Furthermore, Arcane uses a unique method for extracting cookies from Chromium-based browsers. It secretly launches a copy of the browser with the “remote-debugging-port” argument, connects to this debug port, and sends commands to visit a predefined list of websites to steal their cookies. The list of targeted websites includes popular services like Gmail, Google Drive, YouTube, Steamcommunity, and various Russian-language platforms.

The threat actors also developed ArcanaLoader, a loader with a graphical interface that purports to download and run cheats and cracks. However, the main ArcanaLoader executable was found to contain the Arcane stealer. The loader included links to a Discord server for news, support, and downloads. The actors were also actively recruiting bloggers on their Discord server to promote ArcanaLoader.

Countries

  • Russia
  • Belarus
  • Kazakhstan

Industries

While the primary lure is game cheats, the wide range of targeted applications (VPN, network utilities, messaging, email, gaming, crypto wallets) suggests that various user segments and potentially related industries could be affected. No specific industries are explicitly mentioned.

Recommendations

  • Be wary of ads for shady software like cheats and cracks.
  • Avoid clicking on links from unfamiliar bloggers.
  • Use strong security software to detect and disarm rapidly evolving malware.

Hunting methods

No specific hunting queries (Yara, Sigma, KQL, SPL) are provided in the source. However, the following hunting strategies can be considered based on the observed TTPs:

  • Monitor for execution of start.bat scripts downloaded from suspicious sources, especially if they contain obfuscated PowerShell commands and attempts to disable SmartScreen via registry modifications (reg add).
    • Logic: The initial infection involves a batch script that performs specific actions to prepare the system for malware deployment. Detecting these actions can indicate an early stage of the attack.
  • Look for processes launching UnRAR.exe followed by suspicious PowerShell commands that download and execute files from external URLs.
    • Logic: The batch script uses UnRAR.exe to unpack downloaded archives, and PowerShell is used to fetch subsequent payloads.
  • Monitor for the creation and execution of a utility named Xaitax.exe in temporary or hidden directories, especially if followed by browser data access.
    • Logic: Arcane uses this specific utility to crack browser encryption keys. Its presence and execution are strong indicators of Arcane infection.
  • Detect instances of Chromium-based browsers being launched with the --remote-debugging-port command-line argument, particularly if the originating process is not a legitimate browser management tool.
    • Logic: Arcane abuses the debug port functionality to steal cookies. Detecting this specific launch parameter can reveal this technique.
  • Analyze network traffic for connections to the specific list of websites used by Arcane for cookie theft (gmail.com, drive.google.com, photos.google.com, mail.ru, rambler.ru, steamcommunity.com, youtube.com, avito.ru, ozon.ru, twitter.com, roblox.com, passport.yandex.ru) originating from newly spawned or suspicious browser processes.
    • Logic: After launching the browser with the debug port, Arcane navigates to these sites to steal cookies. Unusual access patterns to these sites from sandboxed or unexpected browser instances could be suspicious.
  • Monitor for processes attempting to read data from the configuration files and data directories of the VPN, gaming, network, messaging, email, and crypto wallet applications listed in the report.
    • Logic: Arcane’s primary function is data exfiltration from these specific applications. Anomalous file access patterns to these locations could indicate Arcane activity.

IOC

File Names (related to distribution):

  • start.bat
  • UnRAR.exe
  • black.rar
  • Run.exe (likely the miner)
  • reload.exe (likely the stealer, potentially VGS or Arcane)
  • ArcanaLoader (name of the later stage loader executable)
  • Xaitax.exe (utility used for cracking browser keys)
  • Information.txt (file where Arcane stores device info)

Domains/URLs (related to distribution and C2):

  • Links in YouTube videos (likely to file-sharing services or cloud storage)
  • https://pastebin.com/raw/<redacted> (example URL for downloading an intermediate payload)
  • https://www.dropbox.com/scl/fi/<redacted>/black.rar?rlkey=<redacted>&st=<redacted>&dl=1 (example URL for downloading the archive containing the miner and stealer)
  • URLs of the YouTube channels distributing the malware
  • Discord server invite links for ArcanaLoader developers
  • https://gmail.com \
  • https://drive.google.com \
  • https://photos.google.com \
  • https://mail.ru \
  • https://rambler.ru \
  • https://steamcommunity.com \
  • https://youtube.com \
  • https://avito.ru \
  • https://ozon.ru \
  • https://twitter.com \
  • https://roblox.com \
  • https://passport.yandex.ru \

Registry Keys (modified by start.bat):

  • HKCU\Software\Microsoft\Windows\CurrentVersion\AppHost\EnableWebContentEvaluation
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\SmartScreenEnabled

Original link: https://securelist.com/arcane-stealer/115919/