On October 8, 2026, JPCERT/CC — Japan's national coordination center for computer security incidents — issued an alert warning of a sharp rise in personal data leaks at Japanese organizations. The campaign pattern is notable for two reasons: attackers are abusing the APIs that power mobile applications rather than attacking the apps themselves, and they are exploiting known vulnerabilities in Metabase, the popular open-source business intelligence and analytics platform frequently deployed to expose internal data.
This is a defender's worst-case combination. Mobile APIs are often built on the flawed assumption that "only our app will call this endpoint," leaving them without proper authorization checks, rate limiting, or bot detection. Metabase, meanwhile, sits directly on top of production databases — a compromised Metabase instance is functionally equivalent to handing an attacker a SQL client into your data warehouse. If your organization exposes either of these to the internet, treat this alert as actionable intelligence, not regional noise. These techniques are globally applicable and trivially portable.
Technical Analysis
Attack Vector 1: Mobile API Abuse
JPCERT/CC's reporting indicates attackers are reverse-engineering mobile applications, extracting the API endpoints and request structures the apps use, and then calling those APIs directly — outside the app — at scale. The typical failure modes we see in incident response engagements match this pattern:
- Broken Object Level Authorization (BOLA / IDOR): Endpoints like
/api/v1/users/{id}/profileaccept a numeric or sequential identifier. The app enforces authorization in the UI layer only; the API trusts whatever ID the client sends. Attackers enumerate IDs sequentially and harvest entire user tables. - Excessive Data Exposure: API responses return full database rows — including fields the mobile UI never displays (dates of birth, phone numbers, internal identifiers). Attackers collect the full payload even though the app shows only a fraction of it.
- Missing Rate Limiting / Anti-Automation: The API was designed for one human tapping a screen, not a script making thousands of requests per minute. Without throttling, bulk enumeration of a national customer base takes hours.
- Hardcoded Secrets and Predictable Tokens: API keys embedded in the mobile binary, or session tokens that never expire, are extracted from the APK/IPA and replayed from attacker infrastructure — often cloud VPS or residential proxies well outside the expected client geography.
From a detection standpoint, the signature is high-volume, sequential, programmatic access to authenticated API endpoints from client fingerprints that do not match the official mobile app — wrong user agent, wrong TLS fingerprint, wrong ASN, impossible request cadence.
Attack Vector 2: Metabase Exploitation
Metabase is a Java-based analytics platform commonly deployed on-premises or in cloud VMs, often with broad read access to production databases. It has a documented history of pre-authentication remote code execution flaws, and JPCERT/CC confirms attackers are targeting known, already-patched software flaws — meaning the victims are running outdated, internet-exposed instances.
The exploitation chain for the known Metabase attack class typically looks like this:
- Reconnaissance: Attackers scan for internet-exposed Metabase instances (default port 3000, identifiable by the
/api/session/propertiesendpoint and distinctive login page). - Exploitation of a known flaw: Unauthenticated requests to internal API endpoints (including legacy setup endpoints) allow the attacker to manipulate the embedded H2 database connection or inject a payload achieving code execution in the context of the Metabase JVM.
- Post-exploitation: The Java process spawns a shell (
/bin/sh,bash,cmd.exe) to establish persistence, pull down tooling, or directly query the connected databases. - Data theft: Because Metabase holds database connection credentials — often with broad read scope — the attacker either queries data through Metabase's own API or extracts the stored connection strings from its application database and connects directly.
Exploitation status: JPCERT/CC confirms active, in-the-wild exploitation tied to confirmed personal data breaches. This is not theoretical. The defining IOC of successful Metabase compromise is the java process spawning command shells or making unexpected outbound connections — behavior no legitimate Metabase instance ever exhibits.
Why These Two Vectors Appear Together
Both attack classes share a root cause: internet-facing data services that trust their callers. Mobile APIs trust that only the official app will call them. Metabase trusts that only authenticated admins will reach its API — until an unauthenticated flaw breaks that assumption. In both cases the prize is the same: bulk personal data reachable through a single service.
Detection & Response
Sigma Rules
The following rules target the two highest-fidelity behaviors: Metabase post-exploitation (Java spawning shells) and probing of Metabase's internal API surface. Both are low-noise in any environment where Metabase is deployed deliberately.
---
title: Metabase Java Process Spawning Shell or Command Interpreter
id: 8f3a2b41-7c1e-4d9a-b5f6-2e8c1a4d7b90
status: experimental
description: Detects the Metabase JVM spawning command shells or scripting interpreters, a hallmark of post-exploitation following known Metabase RCE flaws. Legitimate Metabase operation never spawns child shells.
references:
- https://attack.mitre.org/techniques/T1190/
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/09
tags:
- attack.initial_access
- attack.t1190
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\java.exe'
- '\javaw.exe'
selection_cmdline:
ParentCommandLine|contains:
- 'metabase'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\certutil.exe'
- '\curl.exe'
- '\bitsadmin.exe'
condition: selection_parent and selection_cmdline and selection_child
falsepositives:
- Extremely rare; custom Metabase plugins or wrappers invoking external tools
level: critical
---
title: Metabase JVM Spawning Shell on Linux
id: 3c7e9d52-4a8b-4f21-9c63-1b5d7e2a8f34
status: experimental
description: Detects a Java process associated with Metabase spawning shells or download utilities on Linux, indicating successful exploitation of a known Metabase vulnerability.
references:
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/10/09
tags:
- attack.initial_access
- attack.t1190
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentCommandLine|contains:
- 'metabase'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/curl'
- '/wget'
- '/python'
- '/python3'
- '/nc'
- '/ncat'
condition: selection_parent and selection_child
falsepositives:
- Rare; container healthchecks or orchestration wrappers that exec into the Metabase container
level: critical
---
title: External Probing of Metabase Internal API Endpoints
id: 5b1d8f73-2e4a-4c96-a7d8-9f3b6c1e5a27
status: experimental
description: Detects HTTP requests to Metabase setup and session properties endpoints from external sources, consistent with pre-exploitation reconnaissance against internet-exposed instances.
references:
- https://attack.mitre.org/techniques/T1190/
- https://attack.mitre.org/techniques/T1595.002/
author: Security Arsenal
date: 2026/10/09
tags:
- attack.reconnaissance
- attack.t1595.002
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_uri:
cs-uri|contains:
- '/api/setup'
- '/api/session/properties'
- '/api/util/password_check'
selection_status:
sc-status:
- 200
- 401
- 403
condition: selection_uri and selection_status
falsepositives:
- Legitimate Metabase admin access from internal networks (filter by source IP range)
- Authorized vulnerability scanning
level: high
KQL (Microsoft Sentinel / Defender)
The first query hunts for bulk API enumeration consistent with mobile API abuse — sequential object access at machine speed from a single client. The second hunts Metabase reconnaissance and exploitation attempts in web/firewall logs ingested via CEF or IIS logs.
// Hunt 1: Mobile API abuse — bulk sequential enumeration of object identifiers
// Tune ApiPathRegex to your actual API route structure (e.g. /api/v1/users/)
let ApiPathRegex = @"/api/[^\s]*/[0-9]{3,}";
let Threshold = 200;
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where RequestURL matches regex ApiPathRegex
| summarize RequestCount = count(),
DistinctIds = dcount(tostring(extract(ApiPathRegex, 0, RequestURL))),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by SourceIP, RequestUserAgent, RequestURL
| where RequestCount > Threshold
| extend RequestsPerMinute = RequestCount / max_of(1.0, datetime_diff("minute", LastSeen, FirstSeen))
| where RequestsPerMinute > 10
| project FirstSeen, LastSeen, SourceIP, RequestCount, RequestsPerMinute, RequestUserAgent, RequestURL
| order by RequestCount desc;
// Hunt 2: Metabase reconnaissance and exploitation attempts in IIS / web logs
// Works against W3CIISLog (AMA) or CommonSecurityLog from a reverse proxy/WAF
W3CIISLog
| where TimeGenerated > ago(7d)
| where csUriStem has_any ("/api/setup", "/api/session/properties", "/api/util/password_check")
or csUriQuery has_any ("jdbc", "h2", "ALLOW_LITERALS", "INIT RUNSCRIPT")
| summarize Hits = count(), DistinctURIs = dcount(csUriStem),
StatusCodes = make_set(scStatus),
UserAgents = make_set(csUserAgent)
by cIP, Computer
| project cIP, Computer, Hits, StatusCodes, DistinctURIs, UserAgents
| order by Hits desc;
// Hunt 3: Metabase JVM spawning shells — Defender for Endpoint
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("java.exe", "javaw.exe", "java")
| where InitiatingProcessCommandLine has "metabase"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "sh", "bash", "curl", "wget", "nc")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;
Velociraptor VQL
Deploy this hunt across servers running Metabase to surface post-exploitation artifacts: shells spawned by the JVM, unexpected network listeners, and the default Metabase port exposed where it shouldn't be.
-- Hunt: Metabase compromise indicators — JVM child processes and network exposure
-- Run against servers hosting Metabase instances
-- Part 1: Shells or tooling spawned by the Metabase Java process
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)java' AND CommandLine =~ '(?i)metabase')
OR (Ppid IN (
SELECT Pid FROM pslist()
WHERE Name =~ '(?i)java' AND CommandLine =~ '(?i)metabase'
))
-- Part 2: Listening ports — flag Metabase default port 3000 and unexpected listeners
SELECT Pid, Name, Status,
Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ 'LISTEN'
AND (LocalPort = 3000
OR Name =~ '(?i)java')
-- Part 3: Outbound connections from the Metabase JVM (egress C2 or data theft)
SELECT Pid, Name, Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort, Status
FROM netstat()
WHERE Name =~ '(?i)java'
AND Status =~ 'ESTABLISHED'
AND NOT (RemoteIP =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.)')
Remediation and Hardening Script
Run this on Linux hosts running Metabase to verify version posture, confirm the setup endpoints are no longer reachable, and enforce egress restrictions that blunt post-exploitation.
#!/bin/bash
# Metabase exposure and hardening verification — run as root or via sudo
set -e
echo "=== [1] Identify Metabase version and process ==="
METABASE_JAR=$(find /opt /srv /home /usr/local -name "metabase.jar" 2>/dev/null | head -1)
if [ -n "$METABASE_JAR" ]; then
echo "Found: $METABASE_JAR"
unzip -p "$METABASE_JAR" metabase/version.properties 2>/dev/null || echo "Version unreadable — check release notes against your deployed build"
else
ps aux | grep -i metabase | grep -v grep || echo "No Metabase process detected"
fi
echo ""
echo "=== [2] Check if Metabase is internet-exposed on default port ==="
ss -tlnp | grep -E ':(3000|80|443)' || echo "No listeners on common web ports"
echo ""
echo "=== [3] Verify setup endpoints are unreachable (should return 404/403) ==="
for endpoint in /api/setup /api/session/properties /api/util/password_check; do
code=$(curl -sk -o /dev/null -w "%{http_code}" --max-time 5 "http://localhost:3000${endpoint}")
echo "${endpoint} -> HTTP ${code}"
done
echo ""
echo "=== [4] Detect JVM spawning shells (post-exploitation IOC) ==="
METABASE_PID=$(pgrep -f "metabase" | head -1)
if [ -n "$METABASE_PID" ]; then
echo "Metabase PID: $METABASE_PID"
ps --ppid "$METABASE_PID" -o pid,comm,args 2>/dev/null || echo "No child processes (expected)"
fi
echo ""
echo "=== [5] Enforce egress restriction for the metabase user ==="
# Block outbound internet access for the Metabase service account while
# permitting database traffic. Adjust DB subnet/ports to your environment.
METABASE_USER=$(ps -o user= -p "$METABASE_PID" 2>/dev/null || echo "metabase")
iptables -C OUTPUT -m owner --uid-owner "$METABASE_USER" -p tcp --dport 443 -j DROP 2>/dev/null || \
iptables -A OUTPUT -m owner --uid-owner "$METABASE_USER" -p tcp --dport 443 -j DROP
iptables -C OUTPUT -m owner --uid-owner "$METABASE_USER" -p tcp --dport 80 -j DROP 2>/dev/null || \
iptables -A OUTPUT -m owner --uid-owner "$METABASE_USER" -p tcp --dport 80 -j DROP
echo "Egress blocked for HTTP/HTTPS from user: ${METABASE_USER}"
echo ""
echo "=== [6] Audit reverse proxy: deny legacy setup endpoints ==="
cat <<'EOF'
Add to your nginx/Apache config in front of Metabase:
location ~ ^/api/(setup|util/password_check) {
deny all;
return 404;
}
Also enforce: Metabase must sit behind SSO-authenticated reverse proxy,
never directly on the internet.
EOF
echo ""
echo "=== DONE. Update Metabase to the latest release immediately if out of date. ==="
Remediation
For Metabase deployments:
- Patch immediately. Upgrade to the latest Metabase release from the official vendor site (
https://www.metabase.com/docs/latest/operations-guide/upgrading-metabase). JPCERT/CC's alert confirms attackers are exploiting known flaws — unpatched instances are the target set. Verify your running build against Metabase's security advisory page (https://github.com/metabase/metabase/security/advisories). - Remove internet exposure. Metabase should never be directly internet-facing. Place it behind an authenticated reverse proxy or VPN/ZTNA gateway. Audit DNS and cloud security groups for port 3000 exposure.
- Block legacy endpoints at the proxy. Deny external access to
/api/setup,/api/util/password_check, and any administrative API routes regardless of patch state. - Restrict egress. The Metabase service account should only reach its configured database hosts. Blocking outbound 80/443 neutralizes payload retrieval and C2 in the post-exploitation phase.
- Rotate database credentials stored in Metabase on any instance that was ever internet-exposed — assume connection strings have been harvested.
- Hunt retroactively. Pull web access logs for the past 90 days and search for requests to
/api/session/propertiesfrom unfamiliar sources, plus any JVM child process executions.
For mobile APIs:
- Enforce object-level authorization server-side. Every API request must validate that the authenticated principal owns the requested object ID. UI-layer checks are not security controls. Map this against OWASP API Security Top 10 (API1:2023 — BOLA).
- Minimize response payloads. Return only the fields the client renders. Strip internal identifiers, PII, and database-native fields at the serialization layer.
- Rate limit per identity and per IP. Bulk enumeration requires volume. Throttle aggressively on endpoints returning personal data, and alert — don't just reject — when thresholds trip.
- Detect non-app clients. Enforce attestation (Play Integrity / App Attest), validate expected user-agent and TLS fingerprint patterns, and flag requests from data-center ASNs against a mobile-first API.
- Rotate any secrets shipped in the mobile binary. Assume every embedded API key has been extracted; design the API so a leaked client secret grants nothing beyond what a logged-in user could already do.
Organizational actions:
- Inventory every internet-facing service with a database behind it — analytics tools, BI dashboards, and mobile backends first.
- Subscribe to JPCERT/CC alerts (
https://www.jpcert.or.jp/) and your national CERT equivalent; regional campaigns like this one routinely go global within weeks. - Tabletop the combined scenario: API enumeration of your customer base plus a BI platform compromise. The forensic and notification obligations overlap, and your IR plan should cover both.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.