Threat Watch Feed
🚩 – IOCs Added
The red flag indicates that Indicators of Compromise (IOCs) have been added to SRA’s Threat Feed used by CyberSOC clients. Articles may not be flagged if IOCs are not available at the time or are not applicable to the article.
Fortinet reports continued in-the-wild abuse of FortiOS SSL VPN 2FA bypass (CVE-2020-12812) tied to LDAP case-sensitivity behavior
Fortinet reports recent real-world abuse of FG-IR-19-283 / CVE-2020-12812, a FortiOS/FortiGate SSL VPN issue first patched in July 2020, where attackers can bypass FortiToken-based 2FA in certain LDAP-backed configurations. The core condition is a mismatch in username case-sensitivity (FortiGate treats usernames as case-sensitive by default while many LDAP directories do not), which can allow authentication to succeed without prompting for a second factor when the username casing is altered. Fortinet’s latest advisory emphasizes this is being exploited based on specific configurations, rather than being universally exploitable on every FortiGate with SSL VPN enabled. Technically, the bypass can occur when an organization has local user entries on the FortiGate with 2FA enabled that reference LDAP, those same users are members of an LDAP group, and that LDAP group is configured/used in an authentication policy (e.g., SSL VPN, IPsec VPN, or admin authentication). In Fortinet’s example, logging in as jsmith matches the local 2FA user and prompts for a token, but logging in as Jsmith (or other casing variants) fails the local match and can fall through to other configured authentication policies (including a “secondary” LDAP group), allowing authentication without 2FA if credentials are valid.
Impact: In impacted configurations, CVE-2020-12812 can undermine 2FA protections for VPN and/or administrative access by letting an attacker authenticate with only the primary credential (e.g., AD/LDAP password) when username casing differs from the local FortiGate user entry. Practically, this increases the likelihood of unauthorized remote access where organizations rely on SSL VPN plus FortiToken 2FA as a primary control; once access is obtained, follow-on activity may include internal reconnaissance, credential access, configuration changes, and broader network compromise depending on the account’s privileges and segmentation controls. Fortinet notes that if this behavior has occurred, organizations should treat the system configuration as potentially compromised and reset relevant credentials.
Recommendation: Organizations should first confirm whether they meet the specific prerequisite conditions for exploitation, including the use of local FortiGate users with 2FA that reference LDAP, membership of those users in LDAP groups, and the presence of LDAP groups in active authentication policies (SSL VPN, IPsec VPN, or administrative access). Where applicable, systems should be upgraded to FortiOS versions that include the July 2020 mitigation (6.0.10, 6.2.4, 6.4.1, or later supported releases), and username case sensitivity should be explicitly disabled (username-sensitivity disable) to prevent authentication fall-through caused by casing mismatches. Administrators should review and remove unnecessary secondary LDAP group configurations that may be used when local authentication fails, as Fortinet has identified this as a contributing factor in observed abuse. From a monitoring and response perspective, teams should review VPN and administrative authentication logs for successful logins that bypass expected 2FA workflows or show repeated username casing variations, and investigate any anomalous access patterns. If abuse is suspected, Fortinet advises treating the device configuration as potentially compromised, rotating VPN and directory credentials, reviewing recent configuration changes, and tightening management access paths as part of incident containment and recovery.
MongoBleed (CVE-2025-14847) Actively Exploited to Leak MongoDB Secrets from Tens of Thousands of Servers
A severe vulnerability in MongoDB Server, tracked as MongoBleed (CVE-2025-14847), is being actively exploited in the wild with more than 80,000 exposed instances identified on the public internet, according to reporting by BleepingComputer. The flaw results from improper handling of zlib-compressed network packets: rather than returning the length of decompressed data, MongoDB may reveal portions of in-memory buffers. Because compression happens before authentication, attackers can trigger this behavior with no credentials simply by sending a malformed query and begin leaking sensitive information including credentials, API keys, session tokens, internal logs, and configuration data. Public proof-of-concept exploit code has been confirmed usable by researchers, and platforms like Wiz report that a significant fraction of visible cloud environments run vulnerable MongoDB versions. Exploitation appears opportunistic, and unverified claims suggest threat actors have used the vulnerability in other high-profile breaches. Vendors have released patches for all supported branches, but many self-hosted deployments remain unprotected and susceptible to remote data leakage if reachable from the internet.
Impact: Successful exploitation may result in exposure of sensitive in-memory secrets, including database usernames and passwords (stored in plaintext in memory), cloud credentials (e.g., AWS access keys), API tokens, session material, configuration data, internal paths, and potentially PII. Given the pre-auth nature of the vulnerability, any exposed MongoDB instance running an affected version should be considered potentially compromised. Beyond data theft, leaked credentials can enable secondary compromise, including lateral movement, cloud account abuse, data exfiltration, or follow-on ransomware and extortion activity.
Recommendation: Organizations running affected MongoDB Server versions should immediately upgrade to a fixed release (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30). Because MongoBleed allows unauthenticated memory disclosure prior to authentication, defenders should assume that secrets may already be exposed on any internet-facing vulnerable instance. After patching, all database credentials, application secrets, API keys, cloud access keys, and session tokens associated with affected MongoDB workloads should be rotated as a precautionary measure. MongoDB instances should be removed from public internet exposure and restricted behind firewalls, private networking, or strict IP allowlists. Where immediate patching is not possible, administrators should temporarily disable zlib compression on the server to reduce exposure.
LangChain serialization injection flaw enables secret extraction during deserialization (CVE-2025-68664)
A critical serialization injection vulnerability has been disclosed in LangChain, affecting dumps() and dumpd() functions in langchain-core. The flaw stems from improper escaping of user-controlled dictionaries containing lc keys, which LangChain internally uses to identify serialized objects. When such data is later deserialized with load() or loads(), attacker-supplied structures are treated as legitimate LangChain objects rather than plain data, enabling object injection within trusted namespaces. This issue impacts versions <1.2.5 (>=1.0.0) and <0.3.81 and has been assigned CVE-2025-68664 with a CVSS 3.1 score of 10.0. In vulnerable configurations, attackers can exploit this behavior through user-influenced fields such as additional_kwargs, response_metadata, or cached LLM outputs, including streaming paths like astream_events(version=”v1″) and Runnable.astream_log(). When secrets_from_env is enabled (the previous default), crafted payloads can extract environment variables during deserialization. Beyond secret exposure, the bug allows instantiation of Serializable subclasses within LangChain’s trusted namespaces, potentially triggering side effects such as network calls or file operations, depending on class behavior.
Impact: Successful exploitation can result in exposure of sensitive environment secrets (for example API keys) and unintended object instantiation during normal application workflows that trust their own serialization output. Because LLM responses and metadata can be influenced via prompt injection, the attack surface is broader than direct user input, increasing risk in production systems that rely on streaming, caching, or message history features.
Recommendation: Upgrade to patched versions langchain-core 1.2.5 or 0.3.81. Review applications for any deserialization of untrusted data and avoid enabling secrets_from_env unless explicitly required. Use the new allowed_objects allowlist to restrict deserializable classes and keep the default init_validator enabled to block Jinja2 templates unless serialized data is fully trusted. Audit usage of vulnerable APIs such as astream_events(version=”v1″), legacy caches, and message history loaders, and migrate to safer alternatives (for example version=”v2″) where applicable.
🚩 MacSync Stealer Variant Bypasses macOS Gatekeeper Through Signed Applications
A new variant of MacSync Stealer employs a code-signed and notarized Swift application to bypass macOS Gatekeeper protections. The malware distributes through a fake installer for “zk-Call & Messenger” downloaded via web browser, eliminating the right-click-and-open workarounds required by previous variants. The installer binary is legitimately code-signed and notarized with an associated Apple Developer Team ID, allowing users to execute it through a simple double-click without triggering Gatekeeper warnings. The 25.5MB disk image is artificially inflated with decoy PDF files to mimic legitimate installer volumes. The notarized application itself does not contain malicious code, instead functioning as a first-stage dropper that retrieves a second-stage payload from a remote server after passing Gatekeeper checks. This architecture separates the trusted, notarized component from the actual malware, making detection during Apple’s notarization process significantly more difficult. Once executed, the dropper downloads and installs the encoded MacSync Stealer payload, which exhibits standard indicators associated with previous MacSync campaigns. Jamf Threat Labs reported the associated Developer Team ID to Apple, resulting in certificate revocation, though code directory hashes were not added to Apple’s revocation list at the time of reporting.
Impact: Organizations face increased risk from this attack method because it exploits the trust relationship users place in Apple’s notarization system. The legitimate code signature eliminates the visual security warnings that typically prompt user caution, increasing successful infection rates compared to earlier variants requiring manual Gatekeeper bypasses. The separation of the notarized dropper from the actual malware payload allows attackers to update malicious components without resubmitting for notarization, extending the operational lifespan of each signed dropper. Organizations experience credential theft, cryptocurrency wallet compromise, and unauthorized access to corporate systems when the stealer exfiltrates browser data and authentication tokens. The attack’s reliance on social engineering through fake installer distribution means users downloading applications from sources outside the Mac App Store face elevated exposure. The delayed addition of code directory hashes to Apple’s revocation list creates a window during which already-distributed samples continue functioning even after certificate revocation, prolonging organizational exposure to active infections.
Recommendation: Users should restrict application installations to the Mac App Store and trusted developer websites, verifying developer identity before downloading. Organizations should maintain awareness of what applications are being installed and from which sources, as notarized applications can still pose threats when they download secondary payloads. Keep macOS updated to receive the latest security patches and certificate revocation lists. Deploy endpoint monitoring to detect applications making network connections immediately after installation to download additional components. Conduct user training emphasizing digital hygiene practices and caution when installing software outside official app stores, even when applications appear properly signed and notarized.
🚩WebRAT Malware Abuses Fake GitHub Proof-of-Concept Exploits to Infect Developers and Security Researchers
Threat actors actively distribute WebRAT malware through fraudulent GitHub repositories that masquerade as proof-of-concept exploits for recently disclosed vulnerabilities. Kaspersky researchers identified 15 malicious repositories targeting security professionals and developers with fake exploits for vulnerabilities including CVE-2025-59295 (Windows MSHTML buffer overflow), CVE-2025-10294 (WordPress OwnID authentication bypass), and CVE-2025-59230 (Windows RasMan privilege escalation). The attackers craft repository content using artificial intelligence to generate authentic-appearing vulnerability descriptions, mitigation guidance, and technical documentation. Each repository delivers a password-protected ZIP archive containing a dropper executable (rasmanesc.exe) alongside decoy files. The dropper escalates privileges, disables Windows Defender, and retrieves WebRAT from a hardcoded command-and-control server. WebRAT maintains persistence through Windows Registry modifications, Task Scheduler entries, and system directory injection while executing its payload to steal credentials from Steam, Discord, Telegram, and cryptocurrency wallets, capture screenshots, and conduct webcam surveillance.
Impact: Organizations face significant risk when security teams and developers download these fraudulent exploits to test vulnerability patches or assess organizational exposure. A successful WebRAT infection compromises sensitive authentication credentials across multiple platforms, potentially granting attackers access to corporate communication channels, development environments, and financial assets. The malware’s webcam and screenshot capabilities enable adversaries to conduct surveillance on security personnel, capturing sensitive information displayed during incident response activities, security assessments, or confidential meetings. Organizations whose researchers operate in elevated privilege contexts face additional risk, as WebRAT establishes SYSTEM-level persistence and disables endpoint protection, complicating detection and remediation efforts. The targeting of security professionals creates a particularly dangerous scenario where the individuals responsible for defending organizational assets become initial access vectors, potentially exposing vulnerability research, security tooling, and incident response procedures to adversaries.
Recommendation: Organizations should treat all exploit code from unverified sources as untrusted and restrict testing to isolated, controlled environments such as offline virtual machines. Security teams should educate users about the risks of downloading proof-of-concept exploits from unknown GitHub accounts, particularly those tied to recently publicized vulnerabilities. Endpoint protection tools should remain enabled and monitored for tampering attempts, and organizations should implement application control policies to limit the execution of unauthorized binaries. Over the long term, organizations should establish clear procedures for evaluating third-party code, rely on reputable security researchers and vendors for exploit validation, and continuously monitor threat intelligence for emerging malware campaigns that abuse trusted platforms.
🚩 Browser-Based e-Challan Phishing Campaign Targets Indian Users via Shared Fraud Infrastructure
Cyble researchers identified an active phishing campaign targeting Indian vehicle owners through fraudulent e-Challan notifications delivered via SMS. Unlike earlier RTO-themed campaigns that relied on Android malware, this wave operates entirely through browser-based phishing, lowering the barrier for victim compromise. Victims are lured with messages claiming overdue traffic fines and redirected to cloned portals impersonating official government transport services. The phishing infrastructure dynamically generates fake challan records regardless of user input and forces victims into card-only payment flows, harvesting full credit and debit card details. Analysis shows the same backend infrastructure is reused across government, logistics, and banking-themed scams, indicating a scalable and professionalized fraud operation rather than isolated activity.
Impact: Successful interaction results in direct financial fraud through card data theft, with potential downstream impacts including unauthorized transactions and identity abuse. The reuse of shared infrastructure across multiple scam themes increases campaign resilience and complicates takedown efforts. Browser warnings are frequently bypassed due to urgency cues, increasing victim susceptibility.
Recommendation: Organizations and users should verify traffic fines only through official government portals and avoid clicking unsolicited SMS links. Security teams should monitor for lookalike domains abusing government and logistics branding and track shared phishing infrastructure rather than individual domains.
Sign up here!
To receive the TIGR Threat Watch email bulletin and critical vulnerability notifications, simply complete the form below.
Follow on Twitter
@SRA_ThreatWatch will keep you up to date with the most recent posts on your social media feed.
Subscribe to the RSS
Just copy and add this link to your RSS app and be notified immediately when new intel is posted.
How to use RSS
Following the RSS feed is easy. RSS can be added in your Outlook desktop app, and there are many free RSS readers available for your mobile device.
To follow using Outlook:
- In Outlook, right-click the RSS Feeds folder and choose Add a New RSS Feed.
- In the New RSS Feed dialog box, enter the URL of the RSS Feed: https://sra.io/category/tigr/feed
(click here for detailed instructions and additional options for Outlook)
Popular mobile RSS reader apps include:
- Feedly
- NewsBlur
- RSS Reader
- Inoreader
After installing your preferred RSS reader, you will be able to add this feed by entering the URL: https://sra.io/category/tigr/feed
Threat Bulletin Archive
About TIGR Threat Watch
Our Threat Intelligence Gathering & Research (TIGR) team is focused on threat intelligence and curates a daily intelligence report, TIGR Threat Watch, with information collected from several industry intel sources. We also create and publish ad-hoc critical vulnerability notifications in case of critical and time-sensitive vulnerabilities or threats. These notifications include details and recommendations for mitigation/remediation.