u/socradario

Pavel Durov announced on Aug 18 that Telegram applied to ICANN for a .gram top-level domain. If approved, Telegram usernames could double as web domains, with AI-generated websites spun up from a single prompt.

A few things stood out from a security research angle:

Telegram is already deeply embedded in the threat ecosystem. A .gram TLD would let that content move from Telegram channels to actual browsable, indexable websites phishing pages, fake logins, malware delivery with no infrastructure setup required.

There's also a DNS-level impersonation problem: whoever holds a brand's username on Telegram controls that brand's .gram domain. Most companies aren't even present on Telegram, so this is a blind spot most brand protection programs haven't accounted for.

The bigger structural shift: Telegram would become the registry operator for .gram, not just a registrant. In July 2026, t(.)me went offline for ~19 hours after an OFAC sanctions filing triggered a registry-level serverHold something Telegram couldn't undo itself because it didn't control the .me registry. Owning .gram removes that external dependency, but it also puts all abuse-handling and takedown decisions in Telegram's hands.

Worth noting: research from Interisle Consulting has found new gTLDs make up a small share of the domain market but account for a disproportionate share of reported cybercrime domains abuse tends to concentrate early, right after a TLD opens for registration.

Still early days but if you're on a CTI or brand protection team, this is worth adding to your radar now rather than after it launches.

NIST is looking into how AI, automation, and machine-readable data can help the National Vulnerability Database (NVD) scale up. We all know the CVE backlog has been a massive headache lately, and AI-driven vuln discovery is only going to make that mountain higher.

But it’s not just about raw speed. If we want the NVD to keep providing the timely alerts we need to strengthen our posture, they have to nail accuracy, provenance, and prioritization all while keeping a human in the loop.

Do you think AI is the silver bullet for the NVD's backlog, or are we just going to end up dealing with hallucinated vulnerabilities and bad data? https://hubs.la/Q04tkXb40

• RDWeb access allegedly for sale, linked to an Italian cloud/IT provider
• 500K GBCSA records claimed for sale
• 280K+ BullyPedex customer records
• A 70M-record SCHUFA credit dataset
• 47.9M-record FLY Firebase exposure, allegedly including sensitive customer and payment data

None of this is verified yet, but if even part of it holds up, the fallout could hit ransomware, fraud, and identity theft angles. Curious if anyone's tracking these listings independently.

Wanted to flag this since it's a significant shift and hasn't gotten much discussion here yet.

On August 12, 2026, a National Security Presidential Memorandum authorized private "Participating Companies" to conduct offensive cyber operations against foreign Cyber-Enabled Transnational Criminal Organizations, under DOJ/DHS direction. Two operation types are covered: → Cyber Surveillance Operations (covert intel collection) → Cyber Effects Operations (disruption, degradation, destruction of systems) Companies need a DOJ/DHS contract, vetting, disclosure of commercial relationships, and a $1M+ bond. Operations risking loss of life or rising to "armed attack" under international law are barred. Every operation needs prior approval.

This isn't a new statute. It builds on the CFAA (1986). A similar effort, the Active Cyber Defense Certainty Act, died in committee in both 2017 and 2019, opposed by NSA, DOJ, and much of the industry over misattribution, collateral damage, and escalation risk with state actors.

What's interesting is the parallel to private military companies. Executive Outcomes, Blackwater, Wagner all started under government contract with real oversight, and all eventually built revenue independent of the state that created them. Wagner's 2023 mutiny is the clearest illustration of what that independence eventually produces.

The LiteLLM supply chain attack exposure data is in, and the 40-minute PyPI window everyone reported was the last act, not the whole story.

Our record-level analysis of 2,188 organization records found:

→ 95% of affected orgs show collection activity before the poisoned LiteLLM packages even reached PyPI on March 24
→ The actual compromise chain started 5 days earlier, tracing back to a hijacked Trivy scanner in LiteLLM's build pipeline
→ Exposure spans 6 CI/CD platforms, not just GitHub Actions
→ The credential mix goes well beyond AI keys: Stripe payment keys, Twilio/SendGrid tokens, and npm/Docker publishing credentials all turned up in the dataset
→ Harvested data is already being brokered on Telegram, bundled with two other TeamPCP campaign stages

LiteLLM is a transitive dependency of MLflow, CrewAI, DSPy, OpenHands, and Arize Phoenix, so plenty of orgs in the dataset never knowingly installed it.

Full breakdown with IOCs, remediation steps, and the exposure dataset methodology on our blog.

If your remote access infrastructure relies on Cisco ASA or FTD, it’s time to move this to the top of your queue. CVE-2026-20349 is officially seeing active exploitation.

The TL;DR: Threat actors are sending crafted HTTP requests that force the devices to reload. No authentication needed. If you have internet-facing SSL VPN, IKEv2, or ZTNA, you are in the blast radius.

Yes, it’s a DoS and not an RCE, but we all know that perimeter availability is critical. Nobody wants to explain to the C-suite why the entire remote workforce just got booted offline.

Getting timely alerts on this stuff is the only way to mitigate the risk before it hits your edge. Patching now strengthens your posture and saves you a massive headache later. Link in comments.

The LiteLLM supply chain attack exposure data is in, and the 40-minute PyPI window everyone reported was the last act, not the whole story.

Our record-level analysis of 2,188 organization records found:

→ 95% of affected orgs show collection activity before the poisoned LiteLLM packages even reached PyPI on March 24
→ The actual compromise chain started 5 days earlier, tracing back to a hijacked Trivy scanner in LiteLLM's build pipeline
→ Exposure spans 6 CI/CD platforms, not just GitHub Actions
→ The credential mix goes well beyond AI keys: Stripe payment keys, Twilio/SendGrid tokens, and npm/Docker publishing credentials all turned up in the dataset
→ Harvested data is already being brokered on Telegram, bundled with two other TeamPCP campaign stages

LiteLLM is a transitive dependency of MLflow, CrewAI, DSPy, OpenHands, and Arize Phoenix, so plenty of orgs in the dataset never knowingly installed it.

Full breakdown with IOCs, remediation steps, and the exposure dataset methodology on our blog.

Hey everyone, just a heads-up if you've ordered hardware from Steam in Europe recently. CEVA Logistics took a hit from a cyberattack.

Before anyone panics—Valve/Steam itself wasn't breached. Your passwords, Steam Guard codes, and credit cards are totally fine. You don't need to go reset your credentials.

However, the threat actors likely grabbed names, physical addresses, phone numbers, and specific order details.

The real threat here is social engineering. Scammers now have the exact context of your order to make their fake "customs fee" or "missed delivery" texts look incredibly convincing. Knowing about this ahead of time mitigates the chance of falling for a slick phishing text.

A guilty plea in the 2024 Snowflake customer-account breach case just confirmed the actual scale of the incident, and it's bigger than most initial reporting suggested:

→ 165+ organizations affected
→ 100 million+ individuals had data exposed
→ Billions of records breached in total
→ The threat actor is facing up to 32 years in prison at sentencing

What stands out to me is how this wasn't a Snowflake platform vulnerability, it was compromised customer credentials (stolen via infostealer malware) combined with a lack of MFA enforcement on those accounts. Classic identity/access failure, not an infrastructure one.

Curious how others here think this should change how orgs approach cloud identity security is MFA enforcement by the platform provider the right fix, or does it still come down to customer configuration?

https://hubs.la/Q04s5DtD0

A guilty plea in the 2024 Snowflake customer-account breach case just confirmed the actual scale of the incident, and it's bigger than most initial reporting suggested:

→ 165+ organizations affected
→ 100 million+ individuals had data exposed
→ Billions of records breached in total
→ The threat actor is facing up to 32 years in prison at sentencing

What stands out to me is how this wasn't a Snowflake platform vulnerability, it was compromised customer credentials (stolen via infostealer malware) combined with a lack of MFA enforcement on those accounts. Classic identity/access failure, not an infrastructure one.

Curious how others here think this should change how orgs approach cloud identity security is MFA enforcement by the platform provider the right fix, or does it still come down to customer configuration?

https://hubs.la/Q04s5DtD0

Came across an interesting phishing kit while looking into F1 ticketing scams. Wanted to share the technical breakdown since it's a good example of how far phishing-as-a-service has evolved.

What's different here:

The kit isn't a single fake page, it's a full 134-page clone of an official Grand Prix ticketing site, spread across an 11-domain cluster impersonating the Singapore and Spanish GPs. All the domains share the same backend hosting.

The interesting part is the backend:

40 PHP files split between checkout logic and a fraud-verification module. The verification module reads the victim's card BIN, identifies the issuing bank, and serves a matching branded phishing page. 8 banks are pre-configured (Emirates NBD, RAKBank, HSBC, and others).

Attack flow:

• Ticket selection → mirrors the real catalog and pricing
• Patron details form → collects name, email, phone, billing address
• Payment page → shows the victim's actual live cart total (adds credibility)
• Exfiltration → card data + IP + user-agent sent to a C2 server, session token issued via cookie

The real target isn't the card — it's 2FA:

Once the card is captured, the kit dynamically serves OTP, push-approval, or balance-check screens depending on flags in the URL (?g, ?b, ?p, ?i). There's a polling endpoint (action=get to /api/record/step) that lets a human operator decide which screen to show next in real time. This is a manned fraud operation, not a static kit.

IOCs and full writeup:

https://socradar.io/blog/formula-1-phishing-campaign/

Curious if anyone's seen similar BIN-routing behavior in other regional ticketing phishing clusters the naming convention here (f1-ticket-[region]) seems like a reusable template.

SOCRadar STRU tracked down a new Loader-as-a-Service platform we're calling DOUBLECUP, active since June 2026. Sharing the technical details since the C2 resolution method is worth knowing about.

How it works:

DOUBLECUP hides its second-stage code inside a steganographic PNG that gets cached in the browser. The payload decryption key is derived from the victim's public IP address — so if you're detonating this in a sandbox on an unexpected network, decryption just fails. No error, no payload, nothing to analyze.

Delivery is via spoofed CRM login pages (NetSuite, Odoo, HubSpot, Salesforce) using ClickFix-style clipboard hijacking.

Two payloads observed:

CountLoader v4.5p — moved from HTA/VBScript to fully fileless PowerShell. Notable new trick: it copies legitimate Windows binaries (powershell.exe, mshta.exe, conhost.exe), renames them, and patches their PE headers (OriginalFilename, InternalName, FileDescription) to impersonate trusted apps like OneDrive. Persistence runs on a 25-minute cycle where the process executes briefly, checks in, and exits — making it harder for behavioral engines to catch a "long-running" malicious process.

DeviceManager — previously undocumented RAT. Instead of a hardcoded C2 domain, it queries an Ethereum/Polygon smart contract to resolve its actual C2 address (EtherHiding). This means the operator can push different C2 addresses to different victims based on device fingerprint, or serve nothing to suspected sandboxes, all without touching DNS infrastructure that could get sinkholed. Primary transport observed was DNS tunneling disguised as microsoft(.)com subdomains.

Full writeup with IOCs and MITRE mapping: https://socradar.io/blog/doublecup-clickfix-loader-devicemanager-rats/

If you've been trying to track China-nexus espionage operations, you've probably run into this headache. There are more than a dozen names for what is essentially the same threat actor (active since at least 2012).

Not every researcher treats the labels as perfectly synonymous—some track distinct subclusters, which makes following their TTPs across different vendor reports incredibly frustrating.

We put together a Dark Web Profile on Mustang Panda that consolidates all the documented intel. It cuts through the naming noise so you can actually use the data to get timely alerts, mitigate the risk, and strengthen your network's posture without having to cross-reference ten different aliases.

You can read the full consolidated profile here: https://socradar.io/blog/dark-web-profile-mustang-panda/

Threat actors mess up their OPSEC too.

Our research team recently found an open directory hosting a C2 server for an ongoing espionage campaign we're calling Operation Talked. We were able to pull 8,436 files, including their tools, target lists, credentials, and session logs.

The logs revealed 14 months of dual-track activity. On one hand, they are running mass exploitation (scanning 1.1M+ internet-facing targets across 19+ CVEs). On the other hand, they are running highly targeted breaches against Ukrainian defense, aerospace, and aviation contractors—including stealing full Git repos from drone manufacturers. We even found a live shell still open on a railway logistics operator.

Based on TTP overlaps and Russian-language artifacts left in their shell history, this is highly likely a Russia-nexus actor (overlapping with UAC-0056 / UAC-0114).

The takeaway for defenders: This campaign is not closed. If your org uses FortiGate, Sophos XG, WordPress, F5 BIG-IP, SAP NetWeaver, or Roundcube, treat those known CVEs as actively weaponized.

Grab the IOCs and remediation steps from the report to mitigate the risk and strengthen your external posture before they find you in their next mass scan.

Just a quick heads-up for the virtualization admins out there.

Broadcom just released VMSA-2026-0006. It covers five flaws, but three of them are critical issues affecting vCenter and ESX. The impact list is basically a worst-case scenario for hypervisors: authentication bypass, remote code execution, and potential VM escape.

The recommended triage path is to patch any exposed vCenter systems immediately, and then prioritize your ESX hosts that are using VMXNET3.

You'll want to get these updates rolling to mitigate the risk and strengthen your environment's posture before automated scanners and threat actors start having a field day with this one. https://socradar.io/blog/critical-vmware-vcenter-esx-flaws/

We just pulled the data for the Japan Cyber Threat Landscape, and there are some wild shifts in how threat actors are operating in the region.

A few standout stats from the report:

• The padlock is a lie: 77.6% of phishing pages use HTTPS. Training users to "look for the lock" is officially outdated advice.
• Manufacturing is getting hammered: It accounts for nearly 41% of all dark web exposure in Japan.
• Ransomware is weirdly split: The Qilin group absolutely dominates (41.5%), but almost half (46.5%) of all activity comes from random, smaller groups rather than the big named cartels.
• Phishing is for espionage: National Security and International Affairs is the most phished sector (19.49%), showing a heavy lean toward intelligence gathering over just financial theft. (Though Crypto/NFTs and Banking still make up a combined ~34%).
• Data is king: Over 66% of all dark web threats in the region are focused purely on data breaches and compromises.

If your org has a footprint in Japan, you need to adjust your threat models to mitigate these risks and strengthen your posture.

You can read the full report and check out the charts here: https://socradar.io/resources/report/japan-threat-landscape-report-2026/

Are any of you defending manufacturing environments in APAC seeing this spike in activity firsthand?

Just a heads-up for the network and security admins out there.

Threat actors are actively exploiting CVE-2026-20316 against Cisco Secure FMC. The vulnerability relies on static credentials, giving unauthenticated attackers low-privilege access directly to the management interface.

Even though it's low-privilege access, it exposes sensitive data and is a perfect launchpad for follow-on attacks deeper into the network.

Cisco has hotfixes available. Get those applied, restrict your FMC access to trusted IPs only, and check your logs for any weird access patterns. It's a quick win to mitigate the risk and strengthen your infrastructure's posture. Don't let a hardcoded password be your weak link today. https://socradar.io/blog/cve-2026-20316-cisco-secure-fmc-static/

Stay sharp!

We're tracking a loud new player on the dark web called Section9. They popped up on July 26 and completely skipped the usual quiet build-up phase. Within 48 hours, they claimed victims across 12 countries and 20 industries.

A few interesting takeaways from their debut:

• Brazil is the primary target right now, making up about 44% of their claimed victims.
• They are targeting cybersecurity firms. This is a pretty common tactic for new RaaS groups trying to flex and build credibility with potential affiliates quickly.
• It might be a bluff. We haven't seen a confirmed encryptor or intrusion chain yet. There is a very real chance they are inflating their victim list to build hype.

Even if they are inflating their numbers, it's worth reviewing their profile. You want to ensure you have timely alerts configured to mitigate the risk and strengthen your posture just in case they are the real deal.

You can read our full Dark Web Profile on them here: https://socradar.io/blog/dark-web-profile-section9-ransomware/

Pavel Durov is currently wanted by France (for not moderating) and Russia (for not censoring). But looking at the actual cybercrime ecosystem on Telegram, nothing has really changed.

Despite removing 43.5 million channels in 2025, threat actors just used backup channels and invite-only gating to keep operations humming. One group even tried moving to SimpleX, realized their audience wouldn't follow, and came right back.

The takeaway? Telegram isn't getting safer. If you do threat intel, treat it as a primary source. Monitoring for stealer logs and IAB listings is the only way to get timely alerts, mitigate risk, and strengthen your posture. The takedown numbers look great, but the adversaries aren't leaving.