Ransomware and information leakage
Ransomware is widely known for encrypting files used in business and making them unavailable. However, incidents can also involve stealing information and threatening to publish it. Using Ikegami Tsushinki’s announcements as a starting point, this article explains the difference between restoring operations and responding to information leakage.
What changed in Ikegami Tsushinki’s updates
On 30 September, Ikegami Tsushinki announced that it had confirmed encryption of some files on its servers and was continuing to keep its internal network disconnected [1]. In its third update on 2 October, the company stated that it had confirmed the publication, on an attacker’s leak site, of information believed to have been held by the company, and was examining its contents and scope [2]. Both encryption and publication of information were reported, but these announcements alone did not establish the full extent of the information involved or the route of entry.
Recovery and leakage response require different preparations
Encryption makes files unreadable and prevents their use in business. Information leakage concerns information reaching people who are not authorised to receive it. Restoring files from backups does not necessarily allow information disclosed outside the organisation to be retrieved. Misuse of confidential information, impersonation targeting business partners and handling enquiries may continue to place demands on the organisation after operations resume. IPA’s lessons-learned publication also addresses preparations for the exposure of stolen data and the difficulty of proving that no leakage occurred [3]. Organisations need to know where information is stored, who is responsible for it and what they would explain to whom.
Reduce the information that could be taken
Priorities include avoiding the continued retention of unnecessary information and limiting access to what people need for their work. If customer information and past project records are gathered in a broadly accessible shared location, review its users, retention periods and administrator. Detection also requires records that can support investigation of unusual bulk access or outbound transfers. However, keeping records alone does not prove whether information was leaked. We suggest checking retention periods, the systems covered and whether the level of detail is sufficient for an investigation.
Separate confirmed facts from what remains unknown
When the scope of a possible leak is unclear, distinguish confirmed facts, unresolved questions and measures currently under way. Logs provide records for investigation, but their coverage and retention periods have limits. It is important not to interpret an absence of evidence as proof that no leakage occurred. Establish contact details for specialist advice before an incident. As a first step, choose one shared location containing customer information and review its purpose, the information it needs to hold, access permissions and retention periods.
Next to read
Where Should You Start with Cybersecurity? — A Learning Path for Beginners
Consider a learning route from the fundamentals towards practical work.
How to Learn Cybersecurity Systematically — Using CyBOK as a “Map”
Use Knowledge Areas to locate your learning within the wider field and identify related topics.
References
[3] IPA, Lessons learned from ransomware incidents, updated 10 September 2026 (in Japanese).