IFS exposure to network-share-originated ransomware encryption

What Happened

The Integrated File System can be mapped as a network share and accessed like any other Windows file share. Ransomware that compromises a Windows endpoint holding a mapped IFS share encrypts the content of that share exactly as it encrypts local files, and it never runs natively on IBM i at any point.

That last detail is why the platform's reputation works against you here. It is broadly true that IBM i does not catch Windows malware, because the malware cannot execute on it. It is also completely irrelevant to this exposure. The malware does not need to run on the machine. It needs write access to files over SMB, which is precisely what a mapped drive provides, and the operating system's integrity has nothing to do with it.

People also underestimate what is actually sitting in the IFS, because decades of thinking in libraries does not transfer. Depending on the shop it holds save files, spooled output archives, documents, web server content, integration staging directories, and reports. On a meaningful number of systems it also holds backups.

The mapping itself is usually the weakest part. A drive letter mapped automatically at logon, pointed at a broad directory or the root, using a profile with wide IFS authority, on a workstation that also reads email and browses the web. Every one of those decisions was made for convenience and none of them were reviewed together.

Why It Matters

This is an observed attack route rather than a theoretical one. IBM i is not infected and does not need to be. The data is encrypted and held anyway, which is the only part that matters to the business asking when it can trade again.

The cruel version is what happens to recovery. If save files live in the IFS, and the IFS is reachable from the compromised endpoint, then the ransomware can reach your recovery as well as your production data. That single overlap is what turns a contained incident into a genuine crisis, and it is common precisely because putting save files in the IFS is convenient.

Detection is weak by default too. Thousands of IFS objects being rewritten over SMB in ten minutes looks like ordinary file activity from the system's point of view. There is no native alert waiting to tell you that mass encryption is in progress, so unless something is specifically watching for that behaviour, the first notification is a person saying the files look strange.

Authority is the control that actually constrains this, and it is the one most often skipped in the IFS. *PUBLIC on an IFS directory deserves exactly the scrutiny *PUBLIC on a production library deserves. Ransomware can only encrypt what the compromised account was allowed to write.

Recommended Actions

• Inventory which IFS directories are shared and which Windows accounts and machines are able to map them, then reconcile that against who genuinely needs the access
• Remove broad always-on mappings and scope each share to a specific directory rather than the root, using a specific account rather than a general one
• Apply object authority to IFS directories with the same rigour used on libraries, *PUBLIC included, since that is what bounds the damage
• Confirm save files are not sitting in a shared IFS directory, because that is the overlap that puts production data and its recovery behind the same compromised account
• Keep offline or immutable copies of critical IFS content, reachable only by a route the ransomware on a workstation cannot traverse
• Deploy IFS-aware anti-ransomware or file integrity monitoring that watches for mass encryption behaviour rather than for known signatures
• Alert on unusual volumes of IFS object change as it happens, rather than discovering the pattern in a log afterwards
• Test a restore of IFS content. An untested backup is a plan, and what you need during an incident is a demonstrated capability

Sources

• IBM i Integrated File System documentation
• IBM i IFS object authority reference