company logo

Product

Our Product

We are Reshaping the way Developers find and fix vulnerabilities before they get exploited.

Solutions

By Industry

BFSI

Healthcare

Education

IT & Telecom

Government

By Role

CISO

Application Security Engineer

DevsecOps Engineer

IT Manager

Resources

Resource Library

Get actionable insight straight from our threat Intel lab to keep you informed about the ever-changing Threat landscape.

Subscribe to Our Weekly Threat Digest

Company

Contact Us

Have queries, feedback or prospects? Get in touch and we shall be with you shortly.

loading..
loading..
loading..
Loading...

Cyberattack

Data Theft

loading..
loading..
loading..

40,000 Employees Exposed! Prudential Hacked, Data Stolen!

Prudential Breach Alert! 40,000 Employee Data Exposed, Investigation Ongoing. Protect Yourself Now!

15-Feb-2024
2 min read

No content available.

Related Articles

loading..

Radius

RCE

Cisco warns of a CVSS 10.0 flaw in Firewall Management Center—unauth RCE via RAD...

A maximum-severity remote code execution bug in Cisco Secure Firewall Management Center (FMC) lets unauthenticated attackers run shell commands with elevated privileges if **RADIUS authentication is enabled** for FMC’s web UI or SSH. Patches are available; if you can’t patch immediately, **disable RADIUS on FMC** and use an alternative authentication method. Cisco says it hasn’t seen exploitation yet. Cisco disclosed **CVE-2025-20265 (CVSS 10.0)** in FMC’s **RADIUS subsystem**. An attacker can send **crafted credentials during authentication** and get arbitrary command execution on the management appliance with high privilege. No prior auth is needed, but **FMC must be configured to use RADIUS** for the web console, SSH, or both. Why this is special: FMC is the **central brain** for Secure Firewall deployments—policy, logging, upgrades, everything. Compromise here can cascade into rule tampering, defense blind spots, or lateral movement into the rest of the network. ## What Cisco and others say (and what that means) * **Affected:** FMC **7.0.7** and **7.7.0** **when RADIUS is enabled** for web/SSH management. * **Root cause:** **Insufficient input handling** in the RADIUS authentication flow, enabling command injection. * **Discovery & exploitation status:** Found internally (credited to **Brandon Sakai**); **no known in-the-wild exploitation** as of publication. * **Fixes:** **Free software updates** are available via normal channels. * **Mitigation if you cannot patch now:** **Disable RADIUS authentication** on FMC and switch to **local accounts, LDAP, or SAML SSO**. Cisco notes this worked in testing, but you must validate in your environment. [Cisco](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-radius-rce-TNBKf79) also bundled this disclosure into its **August 14, 2025** Secure Firewall advisory rollup (29 vulns across ASA/FTD/FMC). That event page confirms the CVSS 10.0 rating for CVE-2025-20265 and the multi-product patch drop. ## Why defenders should care (beyond “it’s a 10.0”) 1. **Pre-auth RCE on the management plane:** Attackers don’t need accounts—just a reachable management interface that uses RADIUS. Exposed management planes or jump-box pivoting become particularly risky. 2. **Policy authority:** With FMC access, an adversary could push permissive rules, drain logs, or disable inspections—quietly degrading controls before moving elsewhere. (This is the classic “turn off the cameras” move.) 3. **Rapid commoditization risk:** Bugs with deterministic input paths often attract scanning and PoC release. Third-party write-ups already flag the attractiveness of this vuln to threat actors. Patch windows should be measured in **hours/days**, not weeks. ## A prioritized playbook **Now (0–24 hours)** 1. **Identify exposure:** Inventory all FMC instances; note **version** and **whether RADIUS auth is enabled** for web/SSH. (If you don’t use RADIUS, your risk for this CVE is dramatically lower.) 2. **Patch where possible:** Apply Cisco’s fixed releases for affected tracks. 3. **If you cannot patch immediately:** **Disable RADIUS** on FMC and move to **local/LDAP/SAML**. Test admin logins and break-glass flows before and after the change. 4. **Reduce blast radius:** * Ensure FMC management **is not internet-reachable**. * Restrict access via **VPN + MFA**, **IP allowlists**, and **jump hosts**. * Review admin group memberships and **rotate credentials** shared with RADIUS backends. **Next (24–72 hours)** 5\) **Hunt & monitor:** * Look for **failed/odd FMC login attempts** with unusual username strings (payload-like characters), followed by new admin sessions or command execution. * Correlate with RADIUS server logs for **credential fields containing special characters**. (Exploit attempts may show up as authentication failures.) * Watch for **sudden rule/policy changes** or disabled inspections. 6. **Backups & integrity:** Validate FMC backups/golden configs; compare **running vs. approved** policies for drift. **Sustain (this week)** 7\) **Post-patch validation:** Confirm FMC build numbers and that RADIUS remains disabled (if used as mitigation) until you can re-enable safely. 8\) **Management-plane hygiene:** Segment FMC, require MFA, and log **every** admin action to a remote SIEM. ## Related Cisco fixes you shouldn’t ignore Alongside CVE-2025-20265, Cisco shipped fixes for **multiple high-severity issues** affecting ASA/FTD/FMC (largely **denial-of-service** and management-interface bugs). Highlights include **Snort 3 DoS (CVE-2025-20217)**, **IPv6 over IPsec DoS (CVE-2025-20222)**, **Remote Access VPN DoS (CVE-2025-20244)**, **IKEv2 DoS set (CVE-2025-20224/-20225)**, and more. Cisco notes **no workarounds** for most of these—**except** for **CVE-2025-20127**, where removing a **TLS 1.3 cipher** is advised. Patch priority should consider your features in use and exposure of web/VPN endpoints. *A non-exhaustive list from Cisco’s and community summaries:* CVE-2025-20217, -20222, -20148, -20244, -20133/-20243, -20134, -20136, -20251, -20224/-20225, -20263, -20127 (TLS 1.3), among others in the August bundle. Review Cisco’s matrix to determine which of your exact devices run on it. ## Key facts at a glance * **CVE:** 2025-20265 (CWE-74 command injection) * **Product:** Cisco **Secure FMC** (management plane) * **Versions impacted:** **7.0.7** and **7.7.0**, **when RADIUS auth is enabled** for web/SSH * **Impact:** **Pre-auth RCE** → **elevated shell commands** on FMC * **Status:** **Patches available**; **no active exploitation** reported by Cisco at disclosure * **Fallback mitigation:** **Disable RADIUS** on FMC; use **local/LDAP/SAML** (validate locally) * **First published:** **August 14, 2025** (Cisco bundle); **news coverage Aug 15, 2025**

loading..   16-Aug-2025
loading..   5 min read
loading..

Fortinet

Coordinated brute-force campaigns against Fortinet SSL VPN and FGFM services in ...

A sharp, two-stage spike in brute-force activity against Fortinet infrastructure—first battering FortiOS SSL VPNs, then pivoting to FortiManager’s FGFM service—has raised alarms across the security community about potential undisclosed flaws and an impending vulnerability disclosure window. GreyNoise, which observed over 780 unique IPs in the initial surge, notes that such vendor-focused scanning/brute-forcing historically precedes new CVEs about 80% of the time, with most disclosures occurring within six weeks. The timing overlaps with separate Fortinet advisories on other products and exploit code surfacing in the wild, increasing urgency without proving causation. ## Timeline: Two Waves, Two Signatures - August 3, 2025: A record surge in brute-force attempts targeted Fortinet SSL VPNs, with more than 780 unique IPs triggering GreyNoise’s Fortinet SSL VPN Bruteforcer tag and aligning with the FortiOS profile—indicating deliberate vendor-specific targeting rather than opportunistic scanning. - August 5, 2025: Activity pivoted to FortiManager’s FGFM service with a different TCP/client “meta signature,” while still tripping the Fortinet SSL VPN Bruteforcer tag—suggesting either the same operator/tooling shifting targets or coordinated infrastructure reuse. GreyNoise emphasizes this behavioral split: long-running brute-forcing tied to a consistent TCP signature contrasted with a sudden, concentrated burst with a distinct signature and a service pivot. ## JA4+ Fingerprints JA4+ encrypted traffic fingerprinting linked the August 3 spike to traffic seen in June that bore a client signature resolving to a FortiGate device on a residential ISP block (Pilot Fiber Inc.), hinting at tooling reuse or residential proxying; attribution remains unconfirmed. This cross-wave clustering suggests evolution rather than noise, reinforcing the assessment that this is not benign researcher activity, which tends to be broader, slower, and avoids credential brute-forcing. ## Indicators of Malicious Infrastructure GreyNoise published a set of IPs associated with the campaign’s post-August 5 meta signature, recommending defensive blocks while monitoring for ongoing evolution. The list includes: - 31.206.51.194; 23.120.100.230; 96.67.212.83; 104.129.137.162; 118.97.151.34; 180.254.147.16; 20.207.197.237; 180.254.155.227; 185.77.225.174; 45.227.254.113. Multiple outlets have echoed the imperative to restrict exposure and harden authentication while treating this as a precursor rather than failed attempts against old bugs. ## Patterns that Precede Pain GreyNoise’s longitudinal analysis shows vendor-specific surges often foreshadow vulnerability disclosures—about 80% see a CVE within six weeks—making this not just an anomaly but a statistical warning bell. In parallel, Fortinet recently disclosed a critical FortiSIEM flaw (CVE-2025-25256) with working exploit code in the wild, and separate reporting highlights long-running risks around FortiManager and FGFM exposure; however, GreyNoise cautions there’s no proven causal link between the brute-force waves and the FortiSIEM disclosure. The confluence of signals argues for immediate hardening—without assuming a single root cause. ## What’s Being Targeted and How - Primary services: FortiOS SSL VPN initially; rapid pivot to FortiManager FGFM. - TTPs: High-volume credential brute-forcing, adaptive testing, evolving TCP/client signatures, tight vendor/service focus rather than scattershot probing. - Geography and scope: Over 780 unique IPs participating; sources reported across multiple countries with targets spanning the U.S., Hong Kong, Brazil, Spain, and Japan in observed telemetry. - Researcher vs. adversary: The depth and cadence—credential abuse, meta-signature clustering, service pivot—fit adversarial intrusion attempts, not rate-limited safety-scoped research scanning. ## Defensive Actions: Do This Now - Block and restrict - Block the published malicious IPs at network perimeters and device ACLs; maintain dynamic blocks as tooling evolves. - Remove public exposure of FortiGate/FortiManager admin interfaces; allowlist trusted management IPs and gate via VPN/ZTNA. - Harden authentication - Enforce MFA on SSL VPN and admin accounts; rotate privileged credentials and eradicate weak/reused passwords. - Patch and mitigate - Apply the latest FortiOS, FortiManager, FortiProxy, and FortiSIEM updates; where patching lags, disable or strictly limit HTTP/HTTPS management and FGFM reachability. - Monitor and hunt - Alert on spikes in failed logins, Fortinet SSL VPN Bruteforcer patterns, and FGFM service hits; baseline and watch for new JA3/JA4+ anomalies and the noted meta signatures. - Review devices for unauthorized accounts, group changes, and unexpected config/policy modifications. ## Industry Signals and Adjacent Risk Coverage from major outlets and vendor advisories underscores that exploitation risk around Fortinet ecosystems is persistent, multifaceted, and often overlaps with management-plane exposure. Tech media and defenders are flagging the elevated likelihood of a Fortinet-adjacent CVE following this surge, while cautioning against conflating separate product advisories with the brute-force campaigns in the absence of direct evidence. ## Extended Excerpt: Inside the GreyNoise Assessment “Spikes like this often precede the disclosure of new vulnerabilities affecting the same vendor — most within six weeks,” GreyNoise warned, tying the August 3 SSL VPN spike and the August 5 FGFM pivot together via TCP/client meta signatures and JA4+ clustering that connected the August wave to June activity linked to a FortiGate on a residential ISP block. The firm emphasized the focused nature of the activity—targeting FortiOS and then FortiManager profiles—contrasting it with typical research scanning patterns and advising defenders to treat the waves as credible intrusion attempts requiring immediate access restriction and authentication hardening. ## Preparing for the “Six-Week Window” The most consequential detail isn’t the brute-force volume; it’s the historical correlation to disclosure cadence and the rapid service pivot that suggests adversaries are probing control planes, not just user edges. Whether or not a specific zero-day surfaces, the attacker attention signals perceived payoff in Fortinet’s management and remote access surfaces, and the cost of waiting is asymmetric: hardening now carries low operational risk compared to the potential blast radius of a management-plane compromise. ## Sensational Headline Candidates - “Two-Wave Ambush: Fortinet SSL VPNs and FortiManager Pummeled as Zero-Day Fears Surge” - “From VPN to Control Plane: Fortinet Brute-Force Blitz Triggers Six-Week Zero-Day Watch” - “JA4+ Trail to a Residential FortiGate: Inside the Fortinet Brute-Force Spikes Rattling Defenders” ## At-a-Glance: The Critical Touch Pointers - Two distinct waves: Aug 3 (FortiOS SSL VPN) and Aug 5 (FortiManager FGFM), different TCP/client signatures. - 780+ unique IPs in the initial wave; all classified malicious. - JA4+ fingerprints link August activity to June traffic tied to a residential ISP FortiGate; attribution remains unconfirmed. - Historical pattern: ~80% of such vendor-focused spikes precede a CVE disclosure within six weeks. - Immediate actions: block listed IPs, restrict management exposure, enforce MFA, patch broadly, monitor for FGFM hits and brute-force patterns. - Context: Parallel Fortinet advisories (e.g., FortiSIEM CVE-2025-25256 with exploit code) heighten urgency but do not establish direct causation with the brute-force campaigns. Treat this as a pre-incident phase: restrict surfaces, raise authentication bars, and watch for service-specific anomalies while preparing for a probable disclosure window that historically follows such surges. > “This was not opportunistic — it was focused activity,” GreyNoise said, urging defenders to block malicious IPs and harden external access rather than assuming these are failed attempts against patched, legacy flaws.

loading..   14-Aug-2025
loading..   6 min read
loading..

Debian

Backdoor

Over a year later, 35 Docker Hub images still hide the critical XZ backdoor, ris...

A highly sophisticated backdoor (CVE‑2024‑3094) was discovered in the Linux XZ‑Utils compression library—specifically in the `liblzma.so` component of versions 5.6.0 and 5.6.1. The compromised code was carefully introduced by a contributor known as “Jia Tan,” exploiting the glibc IFUNC mechanism to hijack OpenSSH's `RSA_public_decrypt` function. If triggered—via having the right Ed448 private key—this flaw could grant remote root access over SSH to affected systems. Debian, Fedora, OpenSUSE, Red Hat, and others shipped packages containing this backdoor, though thankfully—due to its early detection—it largely avoided widespread deployment into production systems. ## Discovery of the Compromise ### How the Backdoor Was Detected Andres Freund—a developer at Microsoft and contributor to PostgreSQL—first noticed anomalous SSH behavior on Debian Sid. SSH sessions were triggering unusually high CPU consumption and Valgrind errors, prompting deeper investigation. Freund traced the issue back to `liblzma`, revealing the malicious injection. He promptly reported the issue to the oss‑security mailing list on March 29, 2024. ### How the Injection Unfolded Over roughly two years, a contributor using multiple pseudonyms—including “Jia Tan” and “JiaT75”—slowly gained trust in the XZ‑Utils project. Once granted maintainer privileges, this actor published version 5.6.0 containing the backdoor, followed by 5.6.1, which attempted to conceal test anomalies. The malicious payload resided in specially crafted test files and a manipulated `build-to-host.m4` script, packaged with release tarballs but not present in the source repository, ensuring stealth during builds for x86-64 via dpkg or RPM. Security experts have noted the operation’s sophistication and speculate a possible state‑sponsored effort given its duration, obfuscation tactics, and high operational security, citing parallels to APT29/[Cosy Bear](https://www.secureblink.com/cyber-security-news/how-russian-hackers-leveraged-spyware-exploits-from-nso-group-and-intellexa-in-watering-hole-attacks). ## Docker Hub's Backdoor Persistence ### Transitive Infection in Container Ecosystems Fast forward to August 2025, and the backdoor problem has resurfaced in a new form: Docker Hub images. Binarly researchers uncovered at least 35 publicly accessible Docker images—including Debian base images—that still embed the compromised XZ‑Utils libraries. Even more concerning, derivative images built on these bases are transitively infected. A recent issue raised on GitHub further confirmed this: 10 official Debian base image tags were identified as still containing the backdoor, urging their removal. ### Debian’s Controversial Decision: Retain Rather Than Remove Rather than removing these compromised images, Debian claimed they serve as historical artefacts and advised users to avoid using outdated image tags. Binary criticised this decision, noting that such photos could be unknowingly pulled or used in CI/CD pipelines, continuing the risk. ### A Vulnerability Concealed in Trust and Transparency This incident highlights vulnerabilities that arise when open-source maintenance ecosystems trust contributors implicitly. The backdoor’s insertion relied on a long game: gaining commit and release rights, then hiding malicious code in build artefacts. This strategy eluded typical code review and repository audit mechanisms. ### Container Systems Amplifying the Risk Docker’s popularity and convenience—especially using base images from trusted sources—can inadvertently propagate deep‑rooted supply chain threats. Once an infected base is published, every descendant container becomes compromised, often without scrutiny. ### Immediate Mitigation Steps Security agencies like CISA swiftly recommended downgrading to safe XZ‑Utils versions. Red Hat, SUSE, Debian, and others reverted to pre‑backdoor builds. Canonical delayed Ubuntu 24.04 LTS beta to conduct a full binary rebuild, ensuring no compromised packages slipped through. Scanners from Binarly, Kaspersky, and others were made available to help detect the backdoor in systems and container images.

loading..   13-Aug-2025
loading..   4 min read