Browser-to-Shell Threat Hunting: Investigating Unexpected Child Processes

A browser launching a command interpreter deserves context. It can be an approved protocol handler or a sign that a downloaded file or web-delivered workflow crossed into local execution.

Hunting Data Theft Before the Ransom Note: Detecting Pre-Ransomware Exfiltration

Your backups did their job. The encrypted servers are restored in 36 hours, the ransom never gets paid, and the incident report closes with a win. Then, three weeks later, your company's customer database shows up on a leak site, and legal starts the breach-notification clock you never planned for.

That sequence is now the normal outcome of a ransomware incident, not the exception. Zscaler's ThreatLabz 2026 Ransomware Report, published today, puts a hard number on it: ransomware data theft grew more than 275% year over year, reaching 896.2 terabytes of exfiltrated data. Blockchain-tracked payments hit $328 million, and the average payment rose 5.3% to $431,995. Their summary is worth quoting directly: "Successful ransomware extortion is shifting away from file encryption that often causes business disruptions to less visible, but more damaging data theft attacks."

The practical consequence for defenders is this: by the time your EDR fires on an encryptor, the attack has already succeeded. The theft — the stage that creates the breach notification, the regulatory exposure, the actual leverage — happened days earlier, quietly, with tools that look boring on a wire. This hunt is about catching that stage.

The problem: encryption is the distraction

Walk through the modern ransomware playbook and notice where the leverage actually sits:

1. Initial access. Compromised credentials, an exploited VPN or firewall (BlackFog's recent analysis of Gunra affiliates cites internet-facing VPN and firewall systems as the way in), or a phishing foothold.
2. Quiet hands-on-keyboard time. Operators work manually: Impacket, SMB, RDP, SSH tunneling for lateral movement, credential gathering, and data collection. Gunra crews, for example, spend significant time collecting data and targeting backups before encryption ever starts.
3. Staging and exfiltration. Files get collected, compressed (7-Zip is a fixture here), and moved with dual-use tools — Rclone, MEGA, FileZilla, OneDrive, SharePoint, WinSCP — into attacker-controlled storage. In the Osiris case, operators used Rclone to push staged data into Wasabi cloud buckets. All of this happens before the encryptor deploys.
4. Encryption. The noisy part. This is what pages you at 3 a.m.

Defenses are still optimized for stage 4 and almost blind to stage 3. And stage 3 is the one you cannot undo. Backups restore encrypted systems; nothing restores stolen data.

The second uncomfortable truth: the exfil channels are trusted infrastructure. Zscaler flags that actors increasingly abuse Microsoft Teams and Quick Assist for social engineering, lateral movement, and data theft. When the transfer rides a sanctioned collaboration platform to a "normal" cloud destination, your perimeter-oriented exfil monitoring never blinks.

The hypothesis

If a ransomware affiliate is preparing for double-extortion, then we will find data staging and exfiltration precursors — large archives appearing in staging directories, execution of dual-use transfer tools with cloud destinations, or unusual outbound volume to file-sharing services — before any encryption-stage indicators exist. Catching any of these early is worth more than any encryptor rule.

Mapped techniques: T1560 Archive Collected Data, T1048 Exfiltration Over Alternative Protocol, T1567 Exfiltration Over Web Service, T1020 Automated Exfiltration.

Data you'll need

Log source	Table / index	What it gives you
Microsoft Defender for Endpoint	DeviceProcessEvents	Execution of exfil tools + full command lines
Microsoft Defender for Endpoint	DeviceFileEvents	Archive creation in staging directories
Microsoft Defender for Endpoint	DeviceNetworkEvents	Outbound connections to file-sharing domains
Sysmon	EventCode 1 / 11 / 3 (or Splunk index)	Process, file-creation, and network events on non-Defender estates
Proxy / firewall logs	Web proxy or NGFW logs	Per-user upload volumes and destinations, including from trusted apps

Worked example 1: the exfil tool that shouldn't be running

Ransomware crews love Rclone because it's a legitimate, signed binary that speaks dozens of cloud protocols, and it does not look like malware. The tell is not the binary — it's the arguments and the context.

Sigma — Rclone execution with exfiltration indicators:

title: Rclone Execution With Cloud Exfiltration Indicators
id: 5f2c1a8b-4d3e-4f6a-9c1b-2e5f8a3d6b9c
status: experimental
description: Detects rclone (possibly renamed) executing with arguments consistent
  with pushing data to attacker-controlled cloud storage.
logsource:
  category: process_creation
  product: windows
detection:
  selection_binary:
    Image|endswith: '\rclone.exe'
  selection_renamed:
    CommandLine|contains:
      - 'rclone'
      - '--config'
      - ' copy '
      - ' sync '
      - 'mega:'
      - 's3:'
      - 'ftp:'
      - '--bwlimit'
  filter_legit:
    InitiatingProcessFileName:
      - 'sccm*'
      - 'intune*'
    ParentImage|contains: 'legit-backup-svc'
  condition: (selection_binary or selection_renamed) and not filter_legit
falsepositives:
  - IT administrators using rclone for sanctioned cloud sync; tune with allow-listed
    service accounts and destinations.
level: high
tags:
  - attack.exfiltration
  - attack.t1048

Notes on the logic: matching rclone.exe alone misses renamed copies, which is why the command-line arm catches copy, sync, mega:, s3:, ftp:, and --bwlimit — a flag that shows up in practice because attackers throttle uploads to stay under the radar. That last one is almost never in legitimate admin usage. The filter arm exists because the only honest response to this rule firing in most environments is "find out whether IT did this," and a one-line allow-list for your backup service accounts keeps the rule honest instead of noisy.

KQL — same hunt in Defender:

// Hunt: dual-use transfer tools with exfil indicators, ranked by risk
let ExfilTools = dynamic(["rclone.exe", "winscp.exe", "megasync.exe", "filezilla.exe", "azcopy.exe"]);
let ExfilArgs = dynamic(["mega:", "s3:", "ftp:", "--bwlimit", " copy ", " sync ", "wasabi"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName in~ (ExfilTools)
   or (ProcessCommandLine has_any (ExfilArgs) and FileName endswith ".exe")
| extend RanFromStaging = ProcessCommandLine has_any (@"\Temp\", @"\ProgramData\", @"C:\Windows\Temp"),
         HasExfilArgs = ProcessCommandLine has_any (ExfilArgs)
| extend SuspicionScore = (iff(FileName in~ (ExfilTools), 2, 0)
   + iff(HasExfilArgs, 2, 0) + iff(RanFromStaging, 1, 0))
| where SuspicionScore >= 2
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, SuspicionScore
| order by SuspicionScore desc, TimeGenerated desc

SPL — for Splunk shops running Sysmon:

index=wineventlog EventCode=1
| eval Tool=case(match(Image, "(?i)rclone\.exe$"), "rclone",
                 match(Image, "(?i)winscp\.exe$"), "winscp",
                 match(Image, "(?i)megasync\.exe$"), "mega")
| where isnotnull(Tool)
| stats count, values(CommandLine) as cmds, values(ParentImage) as parents
    by host, Tool, User
| where count > 0

Pair it with this: sysmon EventCode 3 (network connection) from the same process GUID within minutes, with a DestinationHostname in a file-sharing service, tells you the upload actually happened.

Worked example 2: the staging pile

Before data leaves, it gets collected — swept from file servers into one place, compressed, often password-protected. Attackers stage in predictable locations: C:\ProgramData\, C:\Windows\Temp\, user temp folders, world-writable shares. An archive that appears in one of these and then never moves is just a backup; an archive that appears and is followed by outbound transfer traffic is a case.

Sigma — large archive created in a staging directory:

title: Large Archive Created in Staging Directory
id: 8a7d2f1e-6b4c-4a9d-8e2f-1c5b7a9d3e6f
status: experimental
description: Detects creation of archive files in directories commonly used by
  ransomware operators to stage data before exfiltration.
logsource:
  category: file_create
  product: windows
detection:
  selection:
    TargetFilename|endswith:
      - '.7z'
      - '.zip'
      - '.rar'
      - '.tar.gz'
    TargetFilename|contains:
      - '\Temp\'
      - '\ProgramData\'
      - '\AppData\'
      - '\Windows\Temp\'
  condition: selection
falsepositives:
  - Legitimate backup and software-installation archives; correlate with process
    context (who created it) and subsequent network activity.
level: medium
tags:
  - attack.collection
  - attack.t1560.001

The real hunt chains these two together: archive created in staging directory → exfil tool executed within hours on the same host → outbound connection to a file-sharing domain. Each step is medium confidence alone; the chain is what makes an investigation.

Worked example 3: the trusted-app blind spot

Zscaler's report specifically calls out Microsoft Teams being abused for data theft. A KQL angle that works here: look for upload volume anomalies from Teams or other collaboration tools per user, rather than trying to detect "Teams doing Teams things":

// Hunt: unusual upload volume per user through collaboration tools
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("Teams.exe", "ms-teams.exe")
| where ActionType == "ConnectionSuccess"
| summarize TotalBytesSent = sum(BytesSent),
            DistinctDestinations = dcount(RemoteUrl)
    by DeviceName, InitiatingProcessAccountName, bin(TimeGenerated, 1d)
| where TotalBytesSent > 5000000000  // 5 GB: tune to your environment's baseline
| order by TotalBytesSent desc

Five gigabytes is a starting threshold, not a law — the point is to establish your own baseline first. A finance analyst pushing 2 GB a day through Teams is normal; the same analyst pushing 40 GB at 2 a.m. from a host they've never used is a phone call.

What a true positive looks like

Putting the chain together from a lab-style example:

• Tue 02:14 — 7z.exe runs on WS-FIN-0233 under a service account that has never launched it before, creating C:\ProgramData\svc_backup\archive_01.7z (38 GB).
• Tue 02:31 — a process named sysupdate.exe (hash doesn't match anything in your baseline, but the strings match Rclone) runs with --config pointing at a config file in the same directory and copy to a mega: remote.
• Tue 02:33–03:10 — sustained TLS sessions from sysupdate.exe to MEGA infrastructure, ~38 GB egress.
• Thu 09:02 — the encryptor deploys across the finance VLAN.

Everything before Thursday morning is your window. The shadow-copy deletion hunt I wrote about previously catches the pre-encryption moment; this chain catches the moment before that, when the data still exists only in your hands and theirs.

Defensive takeaways

1. Hunt the chain, not the step. An exfil tool execution alone is a triage ticket. Staging + exfil tool + outbound volume from the same host within hours is an incident. Write the correlation into your SIEM, not just the individual detections.
2. Baseline outbound volume per user and per app. You can't detect "unusual" uploads without knowing usual. Trusted-app exfil (Teams, OneDrive, SharePoint) is invisible to binary-blacklist thinking — volume baselines are the control that catches it.
3. Treat staging directories as tripwires. Large archives appearing in C:\ProgramData\, C:\Windows\Temp\, or world-writable shares are cheap to monitor and almost never belong to normal users.
4. Allow-list your exfil-class tools. Rclone, AzCopy, WinSCP, and the AWS CLI are legitimate admin tools and the ransomware exfil toolkit. Know which accounts are allowed to run them, from which hosts, to which destinations — then alert on everything else.
5. Backups are necessary and insufficient. They recover you from encryption. They do nothing about the leak site. Your IR runbook needs an exfiltration-assessment step (check for rclone/WinSCP/MEGA/cloud-storage activity on every ransomware call) before you declare victory, because the breach-notification clock starts when data leaves, not when you notice the leak.

Further reading

• Zscaler ThreatLabz 2026 Ransomware Report (press release, Sep 30 2026): Zscaler ThreatLabz 2026 Ransomware Report
• BlackFog — Gunra ransomware threat intel brief (exfil tooling observed: OneDrive, SharePoint, MEGA, Rclone, FileZilla): Gunra ransomware threat intel brief
• Double Extortion Ransomware: What It Is, How It Works, and How to Defend (2026 guide, includes the Osiris Rclone to Wasabi case): Double Extortion Ransomware 2026 guide
• MITRE ATT&CK: T1048 Exfiltration Over Alternative Protocol, T1567 Exfiltration Over Web Service, T1560 Archive Collected Data

Daily Cyber Threat Brief — September 30, 2026: FBI addresses massive FBIJobs.gov breach

🗂️ CASE FILE — September 30, 2026

Lead story: The FBI is now publicly addressing the ShinyHunters breach of its FBIJobs.gov recruitment portal — a cybersecurity incident the bureau says it will pursue the hackers over. The group claims 2–3 TB of data on nearly all ~38,000 agents and job applicants (names, home addresses, SSNs, duty assignments, even family details), stolen via an Oracle PeopleSoft flaw, and demanded the FBI retract a May 2026 advisory by a Monday deadline. FBIJobs.gov remains offline.

Also covered: Zscaler ThreatLabz 2026 Ransomware Report — data theft up 275%+ year-over-year (896.2 TB), $328M in payments, 62% of attacks hitting manager-level targets and above, Microsoft Teams abused for exfiltration · Bitget details how attackers used a zero-day in third-party security products to steal $387.5M from hot/warm wallets in a ~3-hour window · Citrix NetScaler zero-day (CVE-2026-88772) exploited for 3+ weeks against government, finance, education, and telecom orgs across North America and Europe · Prisoner medical records at two Suffolk County, MA jails hit in an EHR-platform incident at vendor Computer Systems Integrated Inc. · Ransomware claims: LegalWise (South Africa, 350K+ members), Tekko Enterprises (interlock, U.S. defense contracts data), Polikem (emperador, Colombia).

Sources: 6 linked at the end of this brief.

Today's top stories

The ShinyHunters–FBI standoff dominates today's wire: the bureau is now on the record addressing the FBIJobs.gov breach, vowing to pursue the hackers, while the group's one-week deadline for retracting the FBI's May advisory has come and gone with no confirmed mass publication of the stolen data. Alongside it, hard numbers from Zscaler's new ransomware report confirm 2026 as the year extortion went full data-theft-first (+275% exfiltration), and Bitget finally explained how its wallets were drained — a zero-day in third-party security products, the supply-chain attack pattern that keeps working. The NetScaler exploitation saga and a prison-health EHR incident round out a day heavy on infrastructure and health-sector targeting.

FBI confirms cybersecurity incident after ShinyHunters breaches FBIJobs.gov; hackers vow to pursue retraction deadline

The FBI has publicly confirmed it is addressing a massive data breach, with NPR reporting on September 30 that the bureau is vowing to go after the hackers it believes responsible. The breach centers on FBIJobs.gov, the bureau's primary recruitment portal since 2017, which has been offline since it was defaced around September 21–22 — first with a Pokémon mascot and a "This site has been seized by ShinyHunters" banner, then replaced by a maintenance message.

ShinyHunters claims to have exploited a vulnerability in Oracle PeopleSoft — a flaw family tracked as CVE-2026-35273, which the group has been linked to since June — to steal 2–3 terabytes of data described as "very sensitive data on almost ALL FBI Agents and individuals who filed an application with the FBI for a job." The group shared a sample of roughly 5,000 records with journalists including 404 Media and Reuters: names, home addresses, phone numbers, Social Security numbers, duty assignments, job classifications (special agents, intelligence analysts, attorneys, student trainees), and in some cases names of spouses, siblings, and other family members. Reuters partially verified the sample against credit-bureau records — at least 10 matches, including the FBI director — though it could not confirm the data came from FBI systems. ShinyHunters names the affected systems as Criminal Justice (CJ), HR, MedLink, PEGA, PHIRE, and FBIJobs.

The motive is political, not financial: ShinyHunters says it wants the FBI to retract or amend its Private Industry/Public Service Announcement PSA260515 (May 2026), which described the group's harassment, swatting threats, and exaggerated-access extortion tactics and linked its activity to attacks on the Canvas LMS — allegations the group calls disinformation. The deadline reported was one week from the incident (Monday, September 28). One report on September 30 claimed the group says it will not publish the stolen FBI data — "to make a point and dispute the allegations" rather than to extort — though that cannot be independently verified.

Separately, the saga keeps intersecting with the Dutch ShinyHunters arrest: Pepijn van der Stap appeared before the Rotterdam District Court on September 29; the group denies any connection to him, and police have not confirmed membership.

🔍 Investigation notes — defender takeaway (click to expand)

Take the retaliation framing seriously: extortion groups breaching a federal law-enforcement agency over a written advisory is an escalation in adversary posture, not just another breach. Defenders should note: (1) PeopleSoft is everywhere in government, higher education, and large enterprise — if your organization runs it, treat CVE-2026-35273 remediation and PeopleSoft attack-surface review as urgent, not routine; (2) family-member and home-address exposure is a targeting gold mine for foreign actors and a physical-safety risk — former FBI cyber official Cynthia Kaiser flagged both the counterintelligence and short-term safety angles; (3) watch whether the post-deadline posture holds — no confirmed mass leak as of September 30, but groups like this often escalate in stages. The bureau vowing to pursue the hackers publicly adds a manhunt dynamic to a story that was already a counterintelligence event.

Zscaler ThreatLabz 2026 Ransomware Report: data theft up 275%+, 896 TB stolen, $328M paid

Zscaler released its ThreatLabz 2026 Ransomware Report on September 30 with headline numbers that confirm ransomware's pivot to data-theft-first extortion. Key findings:

• Ransomware data theft increased more than 275% year over year, reaching 896.2 terabytes of exfiltrated data — roughly 90 times the Library of Congress's print collection.
• Blockchain transactions associated with ransomware payments reached $328 million; the average ransom payment rose 5.3% YoY to $431,995.
• 62% of attacks targeted manager-level titles and above — employees with privileged roles and business influence.
• Threat actors are increasingly using trusted workplace tools, including Microsoft Teams, to enable data theft and lateral movement.
• GenAI is accelerating operations — from reconnaissance to negotiation, AI-assisted attackers are moving faster at every stage.

🔍 Investigation notes — defender takeaway (click to expand)

The 275% exfiltration jump is the number that reframes every IR plan: destruction is secondary now — data is the weapon, and backup alone no longer limits blast radius. Two shifts to act on: (1) the targeting of privileged-role employees pairs with AI-accelerated social engineering — executive spear-phishing and deepfake-assisted pretexting need their own detection use cases, not just generic phishing controls; (2) trusted-tool abuse (Teams, etc.) defeats perimeter- and network-centric exfiltration monitoring — data-loss controls need to cover collaboration platforms' file-sharing and API paths, where volume anomalies (896 TB doesn't move quietly) should be detectable if you baseline them.

Bitget reveals attackers used zero-day in third-party security products to steal $387.5M

Bitget has disclosed new technical details on its $387.5 million breach (first reported September 25): attackers used a zero-day in third-party security products to compromise the exchange's wallet infrastructure. According to BleepingComputer and SlowMist on-chain analysis, the earliest theft transfer occurred at 02:31 (UTC+8) and the last at 05:23 — a nearly three-hour window spanning the Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, and Base chains, draining ETH, XRP, BNB, AVAX, USDT, USDC, and other tokens from hot and warm wallets.

CEO Gracy Chen said attackers breached a critical backend system within Bitget's wallet infrastructure that was then used to spoof transaction data, triggering the exchange's authorization process to move funds out of the compromised wallets — effectively turning the wallet's own security tooling into the authorization path for the theft. Chen blamed North Korean hackers, citing IP behavior patterns and on-chain analysis — consistent with the DPRK-linked Bybit heist ($1.5B) earlier this year. Bitget has launched a Recovery Bounty Program offering 5% bounties for help recovering or freezing stolen funds. A Bitget spokesperson did not immediately answer BleepingComputer's questions about the specific zero-day flaw and which third-party products were compromised.

🔍 Investigation notes — defender takeaway (click to expand)

Supply-chain zero-days keep winning because security tooling sits on the trust path: compromising the tool that authorizes transactions turns every downstream control into theater. The three-hour window is the operational lesson — on-chain theft at this scale moves in minutes-per-chain; exchanges and custodians need real-time anomaly triggers on authorization paths, not batch reconciliation. Also note the deliberate opacity around which third-party products were hit: everyone in the wallet-tooling ecosystem should be treating this as their incident until the products are named. North Korean attribution, if it holds, keeps the 2026 crypto-heist tally firmly in DPRK hands.

Citrix NetScaler zero-day CVE-2026-88772 exploited for 3+ weeks across government, finance, education, telecom

A report published September 30 describes exploitation of a critical zero-day in Citrix NetScaler — identified as CVE-2026-88772 — allegedly active for more than three weeks before detection. The reported incidents hit organizations across government, financial services, education, telecommunications, and legal services in North America and Europe. Because NetScaler sits at the network perimeter (remote access, application delivery, connectivity), a successful compromise can open paths to internal systems — and the three-week dwell means stolen access may have been laundered into deeper persistence. The report cautions that the full extent, victim count, attacker identities, and techniques have not been independently established.

This extends a September NetScaler saga this brief has been tracking: earlier this week, separate reporting covered active NetScaler exploitation in the wild and the broader defender response.

🔍 Investigation notes — defender takeaway (click to expand)

Three weeks of undetected perimeter exploitation is the pattern of the month — patch windows for edge appliances keep proving too slow. For defenders: (1) hunt, don't just patch — with that dwell time, unpatched-at-the-time instances must be assumed compromised until forensic evidence says otherwise; check for web shells, persistence, and lateral movement; (2) segment and monitor edge-appliance access paths — a compromised NetScaler is a remote-access goldmine, so treat its logs as primary evidence; (3) the cross-sector spread (government, finance, education, telecom) suggests opportunistic scanning rather than targeted selection — internet-facing inventory hygiene is the control that shrinks the exposure surface fastest.

Prisoner medical records exposed in EHR vendor incident at two Suffolk County, MA jails

DataBreaches reports a "cybersecurity incident" involving the electronic health record system for Suffolk County, Massachusetts's two jails. The provider, Computer Systems Integrated Inc. — which runs the EHRs-C platform holding prisoner health data and medical records — confirmed it is aware of and investigating the incident, per reporting by masslive.com's Hadley Barndollar on September 30. Details on scope, the nature of the unauthorized access, and whether data was exfiltrated have not yet been disclosed.

Health-sector and carceral data is among the most sensitive exposure categories: prisoner medical records combine identity data with protected health information, and the affected population has limited ability to self-protect. Watch for a vendor breach-notification filing and the county's disclosure for scale.

Ransomware leak-site claims roundup

Fresh claims from the last 24 hours. None are independently confirmed; treat each as a threat-actor claim, not a confirmed breach:

• LegalWise listed (discovered September 30). South Africa's leading legal-expenses insurance provider (350,000+ members, 1.1M people covered, 400–800 staff) appeared in ransomware.live tracking with an estimated attack date of September 29. The associated gang listing is The Gentlemen — the same group behind the recent Veradigm patient-data claim. If confirmed, this is a large PII exposure set: insurance member data typically includes IDs, addresses, and legal-case details.
• interlock hits Tekko Enterprises, Inc. (Sept 29). The U.S. company is listed with claims of leaked confidential information including utility system drawings/specifications (fuel and HVAC), crane-related materials, employee personal data, security clearances and ID cards, and sensitive bids and financials tied to multiple U.S. defense and infrastructure contracts. The claim cites alleged security negligence and violations of the False Claims Act, DFARS, FISMA, and the Privacy Act.
• emperador claims Polikem (Sept 29). The Colombian chemical-products manufacturer (industrial and automotive applications) is listed with claimed exposure of financial status, inventory records, and other internal data.

🔍 Investigation notes — defender takeaway (click to expand)

Today's claims skew defense-adjacent: Tekko's alleged exposure of security-clearance ID cards and defense contract bids is the one with national-security-adjacent implications — if any of those contracts are in your supply chain, proactively ask for incident status rather than waiting for disclosure. LegalWise is the volume play — 1.1M covered individuals is a South African-scale exposure. As always: claims precede confirmation, some listings are bluffs or recycled access, and none of these are verdicts.

Incident timeline

Date	Event	Status
Sept 21–22	ShinyHunters defaces FBIJobs.gov ("This site has been seized") via suspected Oracle PeopleSoft flaw; data theft begins (2–3 TB claimed)	Confirmed defacement; data-theft claim partially verified via sample
Sept 24	FBI confirms it is investigating ShinyHunters' claims; FBIJobs.gov stays offline	Confirmed
Sept 28	ShinyHunters' one-week deadline for FBI retraction of May advisory passes; no confirmed mass data publication as of Sept 30	Claim/deadline; outcome unconfirmed
Sept 29	Pepijn van der Stap appears before Rotterdam court in ShinyHunters-investigation arrest; Tekko Enterprises (interlock) and Polikem (emperador) claims published; LegalWise claim estimated dated	Court: confirmed; claims: unconfirmed
Sept 30	FBI publicly addressing the massive breach, vows to pursue hackers (NPR); Zscaler ThreatLabz 2026 Ransomware Report released (896.2 TB, $328M); Bitget details third-party zero-day behind $387.5M theft; NetScaler zero-day CVE-2026-88772 reported exploited 3+ weeks; Suffolk County jails EHR vendor confirms incident	Confirmed / disclosed
Oct 2	N0n data-release deadline for Precision Facades claim (from yesterday's roundup)	Upcoming
Oct 5	DoomMageddon data-release deadline for Chem Process Systems claim (from yesterday's roundup)	Upcoming

Sources

1. FBI investigating massive data breach of the bureau's job portal — NPR (September 30, 2026)
2. New Zscaler Report Reveals AI-Assisted Attackers Move to Massive Data Theft — Zscaler/GlobeNewswire
3. Bitget hacked via zero-day in third-party security products — BleepingComputer
4. Data breach incident targets prisoner medical records at 2 Mass. jails — DataBreaches via Malware News
5. Citrix NetScaler Zero-Day Exploited for More Than Three Weeks — Undercode News
6. Ransom! Tekko Enterprises, Inc — HendryAdrian (interlock claim)

Daily Cyber Threat Brief — September 30, 2026: CISA Retires Its Weekly Vulnerability Bulletin

CISA is retiring its weekly Vulnerability Bulletin. Teams that depend on the roundup should review their information sources and make sure actionable advisories still reach the people responsible for affected systems.

The DC That Phoned Home: Hunting DCSync Credential Theft

Case file TH-008. The domain admin passwords were changed on Friday. By Monday, the attacker was back in with full domain dominance — and nobody had phished anyone or exploited anything new over the weekend. The evidence was hiding in plain sight in the directory replication logs: a helpdesk workstation in HR had been quietly asking the domain controller for every password hash in the domain, and the domain controller had been politely handing them over.

This is DCSync. An attacker who holds the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights — on the domain object, on a user, or via membership in a privileged group — can impersonate a domain controller and request replication of credentials, including the krbtgt account. Mimikatz's lsadump::dcsync turned this into a one-liner years ago, and it remains the quietest way to steal an entire directory: no LSASS access, no malware on the DC, just a legitimate protocol doing exactly what it was designed to do.

This hunt looks for replication that comes from somewhere it shouldn't.

The hypothesis

If an attacker is stealing credentials via DCSync, then directory replication traffic will originate from a host or account that is not a legitimate domain controller or sync engine — and that source will have no historical baseline of replication activity, or will suddenly replicate far outside its normal pattern.

Data you'll need

Source	What it gives you
IdentityDirectoryEvents (ActionType == "Directory Services replication")	Defender for Identity's view of every replication request: source device, IP, and actor account.
SecurityEvent, Event ID 4662 on DCs	Object-access audit showing the replication extended rights GUIDs being exercised — the ground truth.
Defender for Identity alerts	"Suspected DCSync attack (replication of directory services)" — useful, but don't rely on it alone.
Splunk: index=wineventlog	Forwarded DC security logs; filter 4662 on the two replication GUIDs below.

Prerequisite that decides everything: Event 4662 only fires if Audit Directory Service Access is enabled on your domain controllers. If it isn't, the KQL hunt on IdentityDirectoryEvents is your primary lens — verify the auditing gap and fix it as part of the response.

Hunting with KQL

This query builds a 30-day baseline of who replicates normally, then flags any replication in the last day from a source with no such history — excluding your known DCs and sync accounts.

// Hunt H-DCSYNC-01: replication from sources with no historical baseline
let KnownDCs = dynamic(["DC01", "DC02"]);              // <-- fill in yours
let KnownSyncAccounts = dynamic(["MSOL_", "ADSync", "svc-backup"]);
let Baseline =
    IdentityDirectoryEvents
    | where Timestamp between (ago(30d) .. ago(1d))
    | where ActionType == "Directory Services replication"
    | extend Actor = tostring(parse_json(AdditionalFields)["ACTOR.ACCOUNT"])
    | summarize SyncCount = count(), ActiveDays = dcount(startofday(Timestamp))
        by DeviceName, IPAddress, Actor
    | where SyncCount > 10 or ActiveDays > 5;
IdentityDirectoryEvents
| where Timestamp > ago(1d)
| where ActionType == "Directory Services replication"
| extend Actor = tostring(parse_json(AdditionalFields)["ACTOR.ACCOUNT"])
| where isnotempty(Actor)
| where DeviceName !in (KnownDCs)
| where not(Actor has_any (KnownSyncAccounts))
| join kind=leftanti (Baseline) on DeviceName, IPAddress, Actor
| summarize Syncs = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            Targets = make_set(DestinationDeviceName, 20)
        by DeviceName, IPAddress, Actor
| order by Syncs desc

What this does, in plain English: it learns what normal replication looks like for a month — domain controllers replicating with each other, Entra Connect syncing — and then asks a simple question about the last 24 hours: who replicated that has never (or barely ever) done so before, and isn't on the allowlist? DCSync from an attacker's workstation has no baseline. Legitimate replication always does.

Walkthrough: how the query reads the evidence

• ActionType == "Directory Services replication" is Defender for Identity's normalized record of a replication request hitting a DC — the exact operation DCSync abuses.
• parse_json(AdditionalFields)["ACTOR.ACCOUNT"] extracts the account performing the replication. In a DCSync attack, this is the compromised account, not a machine account.
• The Baseline subquery is the false-positive killer: anything that replicated more than 10 times (or on more than 5 days) in the last month is, by definition, part of normal operations.
• join kind=leftanti keeps only current replication sources absent from the baseline — the statistical definition of "new and unexpected."
• The allowlists (KnownDCs, KnownSyncAccounts) handle your environment's known-good replicators; the baseline handles everything else, including the sync tool you forgot was installed.

Example: what a true positive looks like

Field	Value	Why it matters
DeviceName / IPAddress	WS-HR-114 / 10.4.18.62	An HR workstation — not a DC, not a sync server, never replicated before
Actor	svc-print	A print service account with replication rights it should never have
Syncs / window	4,812 requests in 20 minutes, 02:10–02:30	Bulk pull of the directory at 2 AM — the signature of a full DCSync dump
Targets	DC01	Replication requested from the primary domain controller

Hunting with Splunk

The ground-truth version: Windows Event 4662 on the domain controllers, filtered on the two extended-right GUIDs that DCSync must exercise. No GUID match, no replication — this is as close to definitive as log-based detection gets.

index=wineventlog EventCode=4662
| where like(Properties, "%1131f6aa-9c07-11d1-f79f-00c04fc2dcd2%")
     OR like(Properties, "%1131f6ad-9c07-11d1-f79f-00c04fc2dcd2%")
| rename ComputerName as dc, SubjectUserName as requestor, IpAddress as src_ip
| stats count as replication_requests, earliest(_time) as first_seen,
        latest(_time) as last_seen, values(dc) as dcs by requestor, src_ip
| where NOT match(requestor, "(?i)^(MSOL_|ADSync|svc-backup)")
| sort - replication_requests

What this does, in plain English: it scans DC security logs for anyone exercising the DS-Replication-Get-Changes (...f6aa...) or DS-Replication-Get-Changes-All (...f6ad...) rights, then rolls the events up by requesting account and source IP. High request counts from a non-sync account are DCSync until proven otherwise.

Example hit

requestor=svc-print  src_ip=10.4.18.62  replication_requests=4812
first_seen=2026-09-27 02:10:04  last_seen=2026-09-27 02:30:41  dcs=DC01

Validating the hit

1. Confirm the source isn't legitimate. Is the device a DC, an Entra Connect server, or a backup product with replication rights? If yes, tune the allowlist. If it's a workstation, escalate.
2. Interrogate the actor account. How did svc-print get replication rights? Check the DACL on the domain object and group memberships — attackers grant themselves Get-Changes-All via DCSync-enabling ACEs, and the grant itself is logged in 4662/5136.
3. Look for what came after. DCSync is a means, not an end: hunt for Golden Ticket indicators (TGTs with anomalous lifetimes, krbtgt logons from unusual hosts), new privileged accounts, and lateral movement from the source workstation.
4. Scope the theft. A successful DCSync yields every hash, including krbtgt. Assume full directory compromise for any account that existed during the replication window — scope the response accordingly, not optimistically.

Tuning out false positives

• Entra Connect / AD Connect sync: the MSOL_ and ADSync accounts replicate constantly by design — allowlist them permanently.
• DC-to-DC replication: both endpoints are domain controllers replicating on schedule; the baseline subquery absorbs this automatically.
• New DC promotions: a freshly promoted DC replicates heavily for the first time and has no baseline. Correlate with change records before panicking.
• Backup and DR tools: some backup products request replication rights. They replicate on a schedule from known hosts — allowlist by host and account, never by account alone.

What to do next

• Isolate the source host immediately and disable the compromised account. Treat the workstation as fully compromised.
• Reset the krbtgt password twice to invalidate any Golden Tickets, then force a full password reset across the domain — DCSync means every hash is burned.
• Remove the attacker's foothold: strip the rogue replication ACEs from the domain object DACL and audit privileged group memberships for additions made during the intrusion window.
• Find the entry point: determine how the actor account was compromised in the first place (the DCSync is step three of the attack, not step one) and hunt for persistence — scheduled tasks, new services, shadow credentials.
• Close the visibility gap: enable Audit Directory Service Access on all DCs if it wasn't on, and promote this hunt to a scheduled detection rule.

When the directory itself is the credential store, replication is exfiltration. Watch who asks. — Amit Vijayan

Patient Zero on a Stick: Hunting USB-Borne Malware and Autorun Artifacts

Case file TH-007. The workstation was fully patched, EDR was healthy, and email filtering had caught every phishing attempt that month. The malware still got in — carried through the front door on a USB stick someone found in the parking lot. Within two minutes of the drive being plugged in, a file named autorun.inf appeared in its root, and a registry Run key was created pointing at E:\RECYCLER\sys.exe. The endpoint rebooted that night, the payload ran at logon, and the hunt began.

USB-borne malware never went away; it just stopped being fashionable to talk about. Worms like Raspberry Robin still spread through removable media, and targeted operators use USB drops against air-gapped or high-security networks precisely because everyone assumes the vector is dead. The forensic trail is distinctive and short-lived: a mount event, a file drop, a persistence write, and execution from the removable volume. If you know the sequence, you can hunt it in minutes.

The hypothesis

If removable media is being used to deliver or persist malware, then endpoints will show USB mount events closely followed — within minutes — by autorun-style artifacts: autorun.inf drops, Run/RunOnce or Winlogon persistence pointing at the removable volume, or process execution from a removable drive letter.

Data you'll need

Source	What it gives you
DeviceEvents (UsbDriveMounted)	Every USB insertion: drive letter, serial number, volume, user, timestamp.
DeviceRegistryEvents	Run-key and Winlogon persistence writes and the process that made them.
DeviceFileEvents	autorun.inf drops and payload staging on the removable volume.
DeviceProcessEvents	Execution with an image path on the removable drive.
Splunk: index=wineventlog + Sysmon	Event 6416 (new external device), Sysmon 11 (file create), Sysmon 13 (registry set).

Hunting with KQL

This query anchors on the mount event and then looks for persistence writes on the same device within 30 minutes. The 30-minute window is deliberate: worms persist fast, before the user unplugs the drive.

// Hunt H-USB-01: persistence written within 30 minutes of a USB mount
let Mounts =
    DeviceEvents
    | where Timestamp > ago(7d)
    | where ActionType == "UsbDriveMounted"
    | extend P = parse_json(AdditionalFields)
    | project DeviceId, DeviceName, DriveLetter = tostring(P.DriveLetter),
              Serial = tostring(P.SerialNumber), MountTime = Timestamp;
let Persistence =
    DeviceRegistryEvents
    | where Timestamp > ago(7d)
    | where RegistryKey has @"\Microsoft\Windows\CurrentVersion\Run"
       or RegistryKey has @"\Microsoft\Windows NT\CurrentVersion\Winlogon"
    | where RegistryValueData matches regex @"(?i)^[D-Z]:\\"
    | project RegTime = Timestamp, DeviceId, DeviceName, RegistryKey,
              RegistryValueName, RegistryValueData, InitiatingProcessFileName,
              InitiatingProcessCommandLine;
Mounts
| join kind=inner (Persistence) on DeviceId
| where RegTime between (MountTime .. MountTime + 30m)
| project MountTime, DeviceName, DriveLetter, Serial, RegistryValueName,
          RegistryValueData, InitiatingProcessFileName
| order by MountTime desc

What this does, in plain English: it lists every USB drive plugged in over the last week, then checks whether anything wrote an auto-start entry pointing at a non-system drive letter (D: through Z:) on that same machine within half an hour of the mount. Legitimate installers persist from C:\; malware staging from a thumb drive persists from E:\ or F:\ — and that distinction is the whole hunt.

Walkthrough: how the query reads the evidence

• ActionType == "UsbDriveMounted" gives you the anchor: the exact moment and drive letter of each insertion, plus the device serial for pivoting.
• The registry filter targets the classic persistence locations — Run, RunOnce, and Winlogon — where USB worms have written themselves for twenty years.
• matches regex @"(?i)^[D-Z]:\\" keeps only persistence pointing at removable-style drive letters, excluding C:\. This one line removes roughly 99% of benign Run-key noise.
• The between (MountTime .. MountTime + 30m) temporal join is the causality test: persistence that appears right after a mount is evidence; persistence from last month is coincidence.
• InitiatingProcessFileName tells you what wrote the key — explorer.exe or a script host launched from the drive is far more suspicious than msiexec.exe.

Bonus triage query — sweep for the classic worm marker file across the fleet:

DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName =~ "autorun.inf"
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName,
          InitiatingProcessCommandLine, SHA256
| order by Timestamp desc

Example: what a true positive looks like

Field	Value	Why it matters
DeviceName	DESKTOP-FIN03	Finance workstation — data worth stealing
MountTime / DriveLetter	2026-09-19 09:41:02 / E:	Unknown serial, never seen in the fleet before
RegistryValueName / RegistryValueData	"WindowsUpdate" / E:\RECYCLER\sys.exe	Run key written 3 minutes after mount, masquerading as a system component
InitiatingProcessFileName	explorer.exe	Written via shell interaction with the drive — the classic worm behavior

Hunting with Splunk

Same chain, built from Windows event logs and Sysmon: device arrival (6416), then file and registry writes tied to the same host inside a 30-minute window.

index=wineventlog EventCode=6416 (ClassName="USB*" OR DeviceDescription="*USB*")
| rename ComputerName as host, _time as mount_time
| stats earliest(mount_time) as mount_time values(DeviceDescription) as usb_device by host
| join host [
    search index=wineventlog (EventCode=11 TargetFilename="*autorun.inf")
        OR (EventCode=13 TargetObject="*\\CurrentVersion\\Run*")
    | rename ComputerName as host
    | stats earliest(_time) as artifact_time values(TargetFilename) as files
            values(TargetObject) as reg_keys by host
]
| where artifact_time > mount_time AND (artifact_time - mount_time) < 1800
| table host, usb_device, mount_time, artifact_time, files, reg_keys

What this does, in plain English: it finds every host where a USB device arrived, then checks whether an autorun.inf file or a Run-key registry write appeared on that same host within 30 minutes (1800 seconds) of the arrival. Hosts passing both tests go on the investigation list.

Example hit

host=DESKTOP-FIN03  usb_device="USB Mass Storage Device"
mount_time=2026-09-19 09:41:02  artifact_time=2026-09-19 09:44:17
files=E:\autorun.inf  reg_keys=HKLM\...\Run\WindowsUpdate -> E:\RECYCLER\sys.exe

Validating the hit

1. Identify the drive. Pivot on the serial number across DeviceEvents — has this physical stick touched other endpoints? A serial appearing on five machines in a day is a worm spreading, not a one-off.
2. Recover and analyze the payload. Pull the hash of the referenced executable and detonate it in a sandbox. Check whether it beaconed — look at DeviceNetworkEvents from the host in the hour after the mount.
3. Reconstruct the execution chain. In DeviceProcessEvents, walk from the mount forward: what launched the payload, did it spawn children (cmd.exe, powershell.exe, rundll32.exe), and did it touch credentials?
4. Check the human. Who was logged on at mount time, and where did the drive come from — parking lot, vendor, conference swag? The source shapes the whole response.

Tuning out false positives

• Corporate deployment media: IT's imaging and software-install USBs write Run keys legitimately. Allowlist known serials and volume labels.
• Encrypted corporate drives: BitLocker-to-Go and sanctioned encrypted sticks mount constantly — exclude devices matching your standard volume label pattern.
• Vendor installer artifacts: some hardware vendors still ship an autorun.inf on driver media. A file created at mount time by a user process is suspicious; one that arrived with the factory image is not.
• Portable apps and user habits: users running portable tools from personal drives generate mount events all day. The query only fires on persistence writes, so most of this noise is already filtered — keep it that way.

What to do next

• Isolate the host and physically secure the USB stick — it is evidence now, not office supplies.
• Block the device by serial in Defender device control so it cannot mount anywhere else in the fleet.
• Reimage the endpoint rather than "cleaning" it; assume credential exposure for any account that logged on after the mount and rotate accordingly.
• Sweep the fleet for the same serial number and the same payload hash — worms do not stop at one machine.
• Fix the policy gap: enforce device control (deny-by-default for removable storage, allowlist exceptions), disable AutoRun/AutoPlay via GPO, and run the parking-lot-USB security reminder. It works better than you'd think.

The cheapest initial access in the world still fits in a pocket. Hunt the mount, not the malware. — Amit Vijayan

Daily Cyber Threat Brief — September 29, 2026: Times Car breach hits 6.6M accounts; ShinyHunters suspect faces court

🗂️ CASE FILE — September 29, 2026

Lead story: Japanese car-sharing giant Times Car confirmed a data breach affecting ~6.6 million user accounts — names, addresses, dates of birth, phone numbers, emails, driver's license information including images of identity documents, and account passwords (stored in "a form that cannot be restored"). Credit card data was not affected. The intrusion began at the start of September, was disclosed September 25, and was blocked September 26.

Also covered: Dutch police confirm a 24-year-old Amsterdam man was arrested in the ShinyHunters investigation — reported to be previously convicted hacker Pepijn van der Stap ("Umbreon"); court appearance today in Rotterdam · UpGuard: 16,326 misconfigured Supabase databases expose readable tables with PII, passwords, and auth tokens; tables created by AI coding agents lack row-level security by default · Microsoft details JadePuffer/Storm-3168 agent-driven attacks that deleted 100+ Azure storage accounts in a seven-minute destructive burst · Apple patches CoreGraphics zero-day CVE-2026-86950 exploited in "extremely sophisticated" targeted attacks · Kiteworks patches its critical flaw and lifts the shutdown warning · CISA publishes its first Wärtsilä FOS-Onboard advisory · Ransomware claims: lockbit5 hits camorim.com.br; Ulose lists newyjh.com; ThreeAM lists St James (WA); M3rx hits somasolucoes.com; DoomMageddon names Chem Process Systems; N0n claims Precision Facades.

Sources: 9 linked at the end of this brief.

Today's top stories

Japan's mobility sector takes the day's heaviest hit: Times Car put a number on its September intrusion — 6.6 million accounts, with driver's license images and ID documents in the exposure set, a combination built for identity fraud. Meanwhile the ShinyHunters saga reached a Dutch courtroom, with the previously convicted "reformed hacker" Pepijn van der Stap facing a judge today as police confirm he was arrested in the ShinyHunters investigation — while the group itself denies any connection. Two research-driven stories round out the top tier: UpGuard's finding of 16,326 wide-open Supabase databases (a misconfiguration crisis where AI coding agents are a recurring ingredient) and Microsoft's disclosure that the agentic JadePuffer operation turned two compromised Azure service principals into a seven-minute destruction spree. On the defensive wire: an Apple zero-day under active exploitation, a Kiteworks patch that ends a tense shutdown warning, and CISA's first advisory for Wärtsilä's maritime software.

Times Car confirms data breach affecting 6.6 million user accounts

Japanese car-sharing service Times Car — operated by Times Mobility, part of the Park24 Group — confirmed in a September 28 update that a cyberattack disclosed late last week compromised approximately 6.6 million user accounts. The company had announced the incident on September 25, saying a third party had accessed its systems at the beginning of the month; Times Car took action to block the unauthorized access on September 26, and has now confirmed the data theft.

The intrusion affects current and former Times Car members as well as current and former members of the Times Business Service corporate account program. According to the update, the exposed information includes:

• Full name (plus department name for corporate members)
• Physical address, date of birth, telephone number, email address
• Driver's license information and identity verification document information, such as images of driver's licenses
• Account passwords — stored in "a form that cannot be restored," suggesting hashing or encryption, though details were not provided
• Linked service IDs

The investigation confirmed that credit card information remained unaffected, and there is currently no evidence that the stolen data has been distributed online. Times Car is conducting a forensic investigation with external experts and will notify affected customers individually in stages. Services continue to operate normally, and the company urged members to be cautious about emails, SMS, and phone calls claiming to come from Times Car.

Scale context: Times Car claims 4 million active members as of August 2026, with 84,000 vehicles bookable at 29,000 stations across all 47 Japanese prefectures. This is one of the largest consumer breaches disclosed in Japan this year, and the ID-document exposure set makes it an identity-fraud time bomb rather than a simple credential reset.

🔍 Investigation notes — defender takeaway (click to expand)

The roughly month-long dwell between initial access (early September) and blocking (September 26) is the number to focus on — the attackers had weeks inside before containment. For defenders: (1) driver's license images plus names, addresses, and phone numbers is a complete identity kit — expect phishing and social-engineering lures impersonating Times Car to hit victims fast, in Japanese and targeted at the corporate Times Business Service accounts whose department names were also exposed; (2) "a form that cannot be restored" is reassuring language for the password hashes, but force rotation anyway — hash strength is unverified and reused passwords are the downstream risk; (3) staged notification means a long tail of confused customers — prime social-engineering conditions for scammers offering "help" with the breach. Any breach-notification comms should include a short, fixed verification script victims can check.

Dutch police confirm arrest in ShinyHunters investigation; suspect faces court today

Dutch police (Politie Landelijke Opsporing en Interventies) confirmed on Monday that a 24-year-old Amsterdam man arrested earlier this month was detained as part of an investigation into the ShinyHunters hacking group. Police said the suspect will appear before the Rotterdam District Court on Tuesday, September 29, when further information will be released.

The suspect has been identified by KrebsOnSecurity and DataBreaches as Pepijn van der Stap, a Dutch hacker previously known online as "Umbreon". Reuters adds the human dimension: van der Stap was the widely covered "reformed hacker" who had been hired as offensive security lead at Amsterdam-based Neo Security. CEO Benjamin Korper confirmed his employee's identity, said Dutch forensic investigators visited the office on September 15 — the same night van der Stap was arrested in a raid with flash-bang grenades on the Amsterdam home he shared with his mother — and said an outside firm hired to check whether van der Stap had compromised Neo Security or its customers has so far found no evidence he acted against his employer or clients.

Van der Stap was previously arrested in January 2023 and charged with hacking and blackmailing more than a dozen companies in the Netherlands and worldwide. He pleaded guilty and was sentenced to four years in prison (one suspended), followed by a three-year probationary period — and was on supervised release after serving three years when re-arrested, per SecurityWeek. The "Umbreon" Pokémon alias, which he used on BreachForums as early as 2021, connects to recent ShinyHunters activity: the group used the same Pokémon character in its FBI breach and in the defacement of the Clop ransomware gang's leak site. ShinyHunters, however, denies any association with van der Stap. Separately, DataBreaches reports the voice in the audio clip Dutch police released of a Dutch-speaking man in the Odido hack (6.2 million people's data) is not van der Stap's.

🔍 Investigation notes — defender takeaway (click to expand)

The contested attribution here is the story: police confirmed an arrest in a ShinyHunters investigation, not a confirmed ShinyHunters membership. Three things to hold at once: (1) van der Stap's employers' own forensic review found no insider compromise of Neo Security or its clients so far — hiring a convicted hacker carries exactly this tail risk, and the vetting evidence matters more than the headline; (2) ShinyHunters publicly denying the connection is itself notable — extortion groups usually claim credit, not disavow it, suggesting they see the arrest as leverage against them; (3) regardless of the individual outcome, the underlying ShinyHunters campaign — FBI personnel data theft via the Oracle PeopleSoft zero-day (CVE-2026-35273), WAF bypasses, the Odido voice clip — remains active and unarrested. Watch today's Rotterdam hearing for whether prosecutors name charges tied to specific ShinyHunters incidents or to unrelated new activity.

UpGuard: 16,326 misconfigured Supabase databases expose PII, passwords, and auth tokens

Researchers at cyber risk management firm UpGuard found more than 16,000 misconfigured Supabase databases exposing readable tables with personally identifiable information, passwords, or authentication tokens. Supabase — the open-source PostgreSQL-based backend platform — has become a favorite among developers building with AI tools, and BleepingComputer reports that AI-assisted development now accounts for more than 60% of newly created databases, with researchers calling AI coding agents a common thread in these exposures.

UpGuard analyzed roughly 300,000 domains showing signs of Supabase use, querying for common table names like "users" (and following hints from API error messages when other table names were accessible). They confirmed 16,326 databases with publicly readable tables. Schema analysis — performed with an AI classifier rather than by reading records, to avoid turning the study into a scraping incident — indicated that more than half contained PII indicators, a smaller subset showed signs of passwords or authentication tokens, and a very small number showed possible credit card data.

Confirmed examples from the spot-checked cases:

• A U.S. valet service exposed 100,000+ customer records — contact details, license plates, visit history.
• A Canadian immigration service exposed ~5,000 user records, including 884 plaintext passwords.
• An India-based adult creator platform exposed sensitive identity and payment account data plus 100,000+ private messages.
• A Philippines-based OTP service exposed 2,000+ users and 100,000+ SMS messages, including apparently unrelated person-to-person communications.
• An African consulate exposed migrants' emergency housing locations.

The root cause is misconfiguration, not a Supabase vulnerability. The safeguard is Postgres row-level security (RLS): tables created through the Supabase Dashboard Table Editor get RLS enabled automatically, but tables created via SQL or programmatically — including by AI coding assistants — do not. Supabase calls this a shared-responsibility matter. UpGuard notified organizations behind the most severe exposures.

🔍 Investigation notes — defender takeaway (click to expand)

UpGuard's framing is the right one: data leaks are the multiplicative product of how easy a platform makes misconfiguration and how large its user base is — and AI-assisted development is multiplying both. Actions: (1) if your organization ships anything on Supabase, audit every table created outside the Dashboard editor for RLS — assume AI-generated migrations left it off; (2) never distribute service_role keys to clients and shorten secret lifespans; (3) add automated RLS policy testing to CI for any AI-assisted database work. The OTP-service exposure is the case study to internalize: a one-time-password provider with publicly readable tables is a credential-theft multiplier, not just a privacy incident.

Microsoft details JadePuffer's agent-driven Azure attacks: 100+ storage accounts deleted in seven minutes

Microsoft Security Research has detailed two JadePuffer attacks from June in which the AI-driven ransomware operator targeted Azure tenants with agent-driven intrusions that mapped environments, stole credentials, and destroyed cloud resources. Microsoft tracks the actor as Storm-3168.

The operation ran about 18 hours using two compromised service principals belonging to the same tenant — the application identities used to access cloud resources. One handled reconnaissance and resource discovery (about 15.5 hours mapping VMs, subscriptions, and resource groups, with 300+ successful read operations); the other "performed discovery, destructive operations, and credential collection," enumerating VMs and resource groups across two subscriptions in five seconds. Roughly 16 hours later, the destructive stage began: more than 100 attempts to delete storage accounts — most succeeding — plus a deleted Azure Key Vault, Function App, and App Service plan. Attempts to delete SQL databases failed on an unsupported API version — a compatibility bug that acted as a safeguard. About 30 minutes after the destruction, the actor returned with 30+ successful ListKeys requests to retrieve storage access keys. Attempts to remove backup and recovery (Site Recovery) locks were also observed. Microsoft reported no confirmed financial demand and no confirmed data theft in the observed cases, though the destructive pattern supports a ransomware extortion hypothesis.

Context: JadePuffer was first documented by Sysdig in July as the first ransomware operation run end-to-end with a large language model, initially exploiting a Langflow flaw (CVE-2025-3248), and later expanding to AI assets — training datasets and vector databases — with a Go-based ransomware strain called EncForge built for AI infrastructure. A note of caution from follow-up reporting: Microsoft found strong evidence of automated/scripted execution but did not establish that an AI model directed every action in this Azure intrusion. Credentials for one compromised identity had appeared in a public GitHub issue — edited to remove the secret but still visible in edit history — though Microsoft could not confirm that as the entry point.

🔍 Investigation notes — defender takeaway (click to expand)

The seven-minute destructive burst after 16 hours of slow reconnaissance is the signature to hunt for: patient, automated discovery followed by compressed, parallelized destruction. Defenses that mattered here: (1) Azure resource locks and storage account-level protections saved some resources — treat delete-protection as a control, not a checkbox; (2) service principal hygiene is the new credential hygiene — audit service principals for over-permissioning, rotate secrets, and alert on ListKeys at scale and cross-subscription enumeration in seconds (the five-second enumeration is a machine-speed indicator no human admin replicates); (3) the GitHub edit-history detail is a process warning — redacting a secret in-place without revoking it is worse than useless, and Git history is now threat-actor telemetry. This follows yesterday's OpenAI disclosure about misaligned agents on government sites: agent-driven infrastructure abuse is now arriving from both lab accidents and criminal operations.

Apple patches CoreGraphics zero-day CVE-2026-86950 exploited in "extremely sophisticated" targeted attacks

Apple released security updates fixing a zero-day vulnerability exploited in "extremely sophisticated" targeted attacks on iOS devices. Tracked as CVE-2026-86950 and discovered by Meta Product Security, the flaw is an out-of-bounds write in CoreGraphics — the framework for 2D vector graphics, image rendering, and text drawing across iOS, macOS, iPadOS, watchOS, and tvOS. Processing a maliciously crafted file could lead to arbitrary code execution.

Apple said the flaw "may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 27." The fix landed in iOS 26.7.1, iPadOS 26.7.1, macOS Tahoe 26.7.1, and macOS Sequoia 15.8.1, with an extensive device list including iPhone 11 and later, iPad Pro, iPad Air 3rd generation and later, iPad 8th generation and later, and iPad mini 5th generation and later. This is Apple's second zero-day of the year — the first, a dyld arbitrary code execution flaw (CVE-2026-20700), also exploited in "extremely sophisticated" targeted attacks, was patched in February.

Kiteworks patches critical flaw, lifts shutdown warning; CISA publishes first Wärtsilä advisory

Kiteworks follow-up: the file-sharing vendor has patched the critical vulnerability behind its weekend shutdown warning and is bringing customer systems back online. Kiteworks still has not assigned a CVE ID or shared technical details. Threat watchdog Shadowserver tracks nearly 400 internet-exposed Kiteworks instances (234 in the US). Recall: on September 26, Kiteworks urged customers worldwide to shut down servers for six hours over credible intelligence — passed on by federal authorities, per CISO Frank Balonis — of a possible imminent attack, likely a zero-day. Historical context sharpens the worry: the Clop gang exploited legacy Kiteworks (then Accellion) zero-days in 2020–2021, breaching fewer than 100 of 300 customers but hitting high-profile victims including Qualys, Shell, the Reserve Bank of New Zealand, and Kroger. Organizations running exposed instances should confirm they are patched and check for indicators of compromise before resuming full operations — file-sharing platforms are extortion-gang favorites for data-theft-first attacks.

CISA advisory: CISA published ICSA-26-258-02, its first advisory for Wärtsilä, covering CVE-2026-78225 and CVE-2026-81855 in Wärtsilä FOS-Onboard (Fleet Optimisation Solution, voyage and fleet operations software) version 5.07.0923.01, rated critical with CVSS v4 scores of 9.5 and 9.3. Found by Cydome's maritime cyber research team, the flaws involve a hard-coded cryptographic key that could let a remote unauthorized user deliver unauthorized updates to the FOS system, execute code, or extract credentials to impersonate a privileged client. Wärtsilä confirmed a patch has been developed and is available. Wärtsilä claims solutions on one in every three vessels sailing — maritime OT research is scarce, which is exactly what makes a first-time critical advisory in this sector worth a maritime operator's immediate attention.

Ransomware leak-site claims roundup

A busy 24 hours of new leak-site listings. None are independently confirmed; treat each as a threat-actor claim, not a confirmed breach:

• lockbit5 hits camorim.com.br. Camorim Serviços Marítimos — 30+ years in the maritime sector — appeared on lockbit5's listings on September 29. (Second maritime-sector name in today's brief, after the Wärtsilä advisory.)
• Ulose lists newyjh.com. New entry September 29 via ThreatMon; no details on intrusion method or data volume.
• ThreeAM lists St James (stjames.wa.edu.au). A Western Australian educational institution, listed September 28. Schools hold student PII and remain frequent extortion targets.
• M3rx hits somasolucoes.com. The Brazil-based professional services firm appeared on M3rx's leak site September 29. M3rx is a double-extortion operator with 46 confirmed victims in the tracking database.
• DoomMageddon lists Chem Process Systems Pvt. Ltd. Listed September 28 with a data-release deadline of October 5.
• N0n claims Precision Facades Ltd. Listed September 29 with a deadline of October 2.

🔍 Investigation notes — defender takeaway (click to expand)

The claims cluster skews Brazilian and British this cycle, with maritime and construction/professional-services exposure. As always with leak-site data: claims precede confirmation, some listings are bluffs or recycled access, and none of these are verdicts. The practical signal: if any of these names are in your supply chain — especially the maritime firm and the professional-services companies with client data — ask for their incident status proactively rather than waiting for a disclosure email.

Incident timeline

Date	Event	Status
Early Sept	Third party first accesses Times Car systems	Confirmed by company (intrusion start)
Sept 15	Dutch tactical police unit arrests Pepijn van der Stap in Amsterdam raid, seizes devices; Neo Security office visited	Confirmed (Reuters/police)
Sept 25	Times Car publicly discloses intrusion; Kiteworks urges global six-hour shutdown over imminent-attack intelligence	Confirmed by companies
Sept 26	Times Car blocks unauthorized access; begins forensic investigation with external experts	Confirmed by company
Sept 28	Times Car confirms 6.6M accounts breached (ID documents, passwords exposed; credit cards unaffected); Dutch police confirm ShinyHunters-investigation arrest; UpGuard's Supabase study (16,326 databases), Microsoft's JadePuffer/Storm-3168 research, Apple CoreGraphics zero-day patch (CVE-2026-86950), Kiteworks patch, and CISA Wärtsilä advisory all published	Confirmed / disclosed
Sept 28–29	Leak-site claims: ThreeAM → St James (WA); DoomMageddon → Chem Process Systems; lockbit5 → camorim.com.br; Ulose → newyjh.com; M3rx → somasolucoes.com; N0n → Precision Facades	Claims — unconfirmed
Sept 29	Van der Stap appears before Rotterdam District Court; police expected to release further information	Upcoming today
Oct 2	N0n data-release deadline for Precision Facades claim	Upcoming
Oct 5	DoomMageddon data-release deadline for Chem Process Systems claim	Upcoming

Sources

1. Times Car confirms data breach affecting 6.6 million user accounts — BleepingComputer
2. Dutch police confirm arrest in ShinyHunters hacking investigation — BleepingComputer
3. Over 16,000 Supabase databases expose PII, passwords, auth tokens — BleepingComputer
4. JadePuffer agentic AI attacks target Azure, destroy cloud resources — BleepingComputer
5. Apple patches CoreGraphics zero-day flaw exploited in attacks — BleepingComputer
6. Kiteworks patches critical flaw, brings customer systems online — BleepingComputer
7. CISA publishes first Wärtsilä advisory after Cydome finds critical flaws — EIN Presswire
8. Dutch Police Arrest Convicted Hacker in ShinyHunters Investigation — SecurityWeek
9. Two new ransomware victims appear on the dark web: Ulose and ThreeAM claims surface — Undercode News

Daily Cyber Threat Brief — September 29, 2026: NetScaler Exploitation and the Defender’s Response

Citrix has confirmed exploitation of two NetScaler vulnerabilities. Today’s brief follows the September 27 advisory with a practical distinction: upgrading an affected appliance and investigating possible earlier compromise are separate tasks.

The Consent Trap: Hunting Malicious OAuth App Grants in Microsoft 365

Case file TH-006. Nobody installed anything. No malware hit the disk, no suspicious logon tripped an alert, and the user's MFA is intact. Yet for three weeks, every email that landed in Priya's inbox was quietly copied to an external server. The entry point was a single click on a link that looked like a DocuSign request. The prompt said "Invoice Portal wants to read your mail — Accept?" She accepted. That was the whole attack.

This is the illicit consent grant pattern, and it is one of the hardest intrusions to spot with traditional endpoint telemetry. The attacker never touches the workstation. They register an application in their own Entra tenant, dress it up with a trustworthy name and logo, and phish your users into granting it delegated permissions to your data — Mail.ReadWrite, Files.ReadWrite.All, offline_access. From then on, the app talks to the Microsoft Graph API with a perfectly valid OAuth token. No password, no MFA prompt, nothing for the firewall to see.

This hunt looks for exactly that moment of consent — and for the consents that should never have happened.

The hypothesis

If an attacker has phished users into granting OAuth consent to a malicious application, then the Entra audit log will show user-level (non-admin) consent grants to apps requesting high-privilege Graph permissions — especially mail and file scopes — from apps with unverified publishers, recent registrations, or consents clustered around a phishing lure.

Data you'll need

Source	What it gives you
AuditLogs (Sentinel, Azure AD connector)	Every consent grant: OperationName == "Consent to application", the consenter, the app, and the scopes granted.
CloudAppEvents (Defender for Cloud Apps)	What the app did after consent — Graph calls, mail reads, file downloads by the service principal.
IdentityInfo	Department/title of the consenter — attackers love finance and executive assistants.
Splunk: index=ms365 (O365 add-on)	Unified Audit Log: Workload="AzureActiveDirectory", Operation="Consent to application*".

Hunting with KQL

This query surfaces consent grants where the app asked for scopes an attacker would actually want. Consent type matters: AllPrincipals means an admin consented tenant-wide (higher blast radius), while Principal means a single user clicked accept (the classic phishing pattern).

// Hunt H-OAUTH-01: user consent grants to apps requesting attacker-grade scopes
let RiskyScopes = dynamic([
    "Mail.ReadWrite", "Mail.Send", "Files.ReadWrite.All", "Sites.FullControl.All",
    "Directory.ReadWrite.All", "RoleManagement.ReadWrite.Directory",
    "Application.ReadWrite.All", "DelegatedPermissionGrant.ReadWrite.All",
    "User.ReadWrite.All", "Calendars.ReadWrite", "offline_access"
]);
AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName == "Consent to application"
| extend Consenter   = tostring(InitiatedBy.user.userPrincipalName),
         AppId      = tostring(TargetResources[0].id),
         AppName    = tostring(TargetResources[0].displayName),
         RawTargets = tostring(TargetResources)
| extend ConsentType = extract(@"ConsentType[^A-Za-z]*([A-Za-z]+)", 1, RawTargets),
         Scopes      = extract(@"ConsentAction\.Permissions[^A-Za-z]*([^\]]+)", 1, RawTargets)
| where Scopes has_any (RiskyScopes)
    or (ConsentType == "AllPrincipals" and Scopes has "Mail.")
| project TimeGenerated, Consenter, AppName, AppId, ConsentType, Scopes, CorrelationId
| order by TimeGenerated desc

What this does, in plain English: it pulls two weeks of Entra audit logs, keeps only consent-grant events, and reconstructs who consented, to which app, and which permissions were handed over. It then keeps the grants that match known-dangerous Graph scopes — or any tenant-wide admin consent touching mail. Sort newest-first, because in a live intrusion the freshest consent is usually the attacker's.

Walkthrough: how the query reads the evidence

• OperationName == "Consent to application" is the exact audit footprint of an OAuth consent. No consent prompt accepted, no event.
• InitiatedBy.user.userPrincipalName identifies the human who clicked Accept — the phishing victim.
• TargetResources[0] holds the app's identity and a modifiedProperties bag containing ConsentType (user vs. tenant-wide) and the granted permission list.
• The extract() calls pull those two values out of the JSON without brittle positional parsing.
• Filtering on RiskyScopes is the triage shortcut: a calendar-sync app asking for Calendars.Read is noise; the same app asking for Mail.ReadWrite + offline_access is a case.

Example: what a true positive looks like

Field	Value	Why it matters
TimeGenerated	2026-09-21 14:03:11 UTC	40 minutes after a reported phishing email to the same user
Consenter	priya.nair@contoso.com (Finance)	High-value mailbox, non-admin user consent (Principal)
AppName / AppId	"Invoice Portal" / 3f9a…c21d	App registered 6 days ago, publisher unverified
Scopes	Mail.ReadWrite, Files.ReadWrite.All, offline_access	Silent, persistent mailbox + file access; no legitimate need for an "invoice" app

Hunting with Splunk

The equivalent hunt against the Microsoft 365 Unified Audit Log. This version leans on rarity: apps that almost nobody in the tenant has consented to are where the malicious grants hide.

index=ms365 Workload="AzureActiveDirectory" Operation="Consent to application*"
| eval risky=if(match(Parameters,"(?i)Mail\.ReadWrite|Mail\.Send|Files\.ReadWrite\.All|Directory\.ReadWrite\.All|RoleManagement\.ReadWrite\.Directory|Application\.ReadWrite\.All"),"yes","no")
| stats count as consents, values(UserId) as consenters, values(ClientIP) as src_ips,
        earliest(_time) as first_seen, latest(_time) as last_seen,
        values(risky) as touched_risky_scopes by ObjectId
| where consents <= 3 AND touched_risky_scopes="yes"
| sort - first_seen

What this does, in plain English: for every app object that received consent, it counts how many consent events exist and who granted them. Apps consented to three times or fewer that also requested attacker-grade scopes bubble to the top — that is the profile of a targeted phishing lure, not an enterprise rollout.

Example hit

ObjectId=3f9a…c21d  consents=1  consenters=priya.nair@contoso.com
src_ips=203.0.113.44  first_seen=2026-09-21 14:03:11  touched_risky_scopes=yes

One user, one consent, risky scopes, source IP in a consumer ISP range rather than the corporate egress — open the case.

Validating the hit

1. Inspect the app in Entra. Check publisher verification, app registration age, homepage URL, and whether the consent was user-level or admin-level. A 6-day-old app with an unverified publisher and a lookalike name is damning.
2. Interview the consenter (gently). Ask whether they remember the prompt and what link led them there. Correlate with phishing reports and the user's inbox around the consent timestamp.
3. Follow the app's hands, not just the consent. In CloudAppEvents, filter on the service principal and look for Graph reads of mail and file downloads after the consent time. Consent without subsequent API abuse is still a finding, but consent with mailbox reads is an incident.
4. Measure the blast radius. Search for other consent events to the same AppId — including AllPrincipals grants. One phished user is a compromise; a tenant-wide grant is a breach.

Tuning out false positives

• Verified enterprise SaaS (Zoom, Salesforce, ServiceNow, DocuSign): verified publishers with admin-consented, tenant-wide grants are expected. Maintain an allowlist of known AppId values.
• Admin-consented rollouts: a spike of consents to one app on one day usually means IT deployed something. Correlate with change tickets before opening a case.
• Low-risk scopes: User.Read, openid, profile are the background radiation of modern SaaS — filter them out of the triage view, not out of the data.
• Microsoft first-party apps: Teams, Outlook add-ins, and Power Platform connectors generate consent events constantly; exclude publisher Microsoft Corporation after one sanity check.

What to do next

• Revoke the consent immediately — in Entra admin center under Enterprise Applications, or via Graph: delete the oAuth2PermissionGrant and disable the service principal so existing tokens die.
• Contain the consenter's account: revoke sessions, rotate credentials, and review mailbox rules and forwarding the attacker may have planted.
• Block the pattern: tighten the user-consent policy (e.g., allow only verified publishers or require admin consent workflow), and block the app's AppId tenant-wide.
• Hunt the lure: find the phishing message that delivered the consent link and pull it from every inbox it reached — then search for other consent grants in the same time window.

The evidence is always in the audit log — the attacker just bets you never look at it. — Amit Vijayan