Warning on Recent Unauthorized Access to Japanese Organizations

Summary

A series of unauthorized access incidents targeting Japanese organizations has now been observed, mainly leading to leakage of personal information. The activity includes exploitation of known software vulnerabilities, unauthorized API manipulations, SQL injection in Metabase, and deployment of web shells through WAR files. These cases appear aimed at management systems, BI tools, and internal applications never meant for public exposure.

Investigation

JPCERT/CC has identified multiple attack vectors, including API endpoint exploitation, NoSQL injection, and the use of specific malicious IP addresses. The investigation shows attackers are scanning for known vulnerabilities and misconfigurations, such as unprotected configuration or backup files. Recent updates specifically highlight the web shells embedded in .war files used to execute shell commands via query parameters.

Mitigation

Suggested mitigations include rate limiting on sensitive API endpoints, strict access controls, and security patches for vulnerable software such as Metabase. Organizations should apply the principle of least privilege to API tokens and restrict service availability to particular geographic regions. Hardening management and BI tools so they are not exposed to the public internet is strongly advised.

Response

After detection, organizations should immediately revoke compromised API tokens, block access from identified malicious IPs, and look for any possible lateral movement. Reviewing web server logs for unusual GET/POST requests and checking for unauthorized .war or .jsp file deployments is advised. Organizations should also prepare communication plans to notify affected customers of potential secondary damages.

Simulation Execution

• Attack Narrative & Commands: An adversary is performing reconnaissance and vulnerability scanning (T1595.002) against the organization’s public-facing API. To evade detection, the attacker typically uses a pool of proxies; however, for this validation, we will simulate the attacker using one of the specific IPs defined in the threat intelligence blacklist (e.g., 20.210.128.125). The goal is to simulate an inbound connection attempt that hits the firewall, triggering the rule based on the source IP.

• Regression Test Script:

  # This script simulates a network connection from a blacklisted IP.
  # Note: In a real simulation, this would be performed by a controlled 
  # external source. For local testing, we inject a log entry into the 
  # logging pipeline to mimic the firewall seeing this traffic.
  
  echo "$(date '+%b %d %H:%M:%S') firewall-01 filter: inbound permit tcp 20.210.128.125 44332 -> 192.168.1.50 443 tcp dport=443 spt=44332 state=NEW" >> /var/log/firewall.log
  
  echo "Simulation: Log entry injected for blacklisted IP 20.210.128.125"

• Cleanup Commands:

  # Remove the simulated log entry to restore baseline
  sed -i '/20.210.128.125/d' /var/log/firewall.log
  echo "Cleanup: Simulated log entry removed."