Using IFS exit point data to identify ransomware attacks

In our previous article “Anatomy of IBM i IFS and Windows network shares” we looked closely at the IBM i File Server exit point QIBM_QPWFS_FILE_SERV.  We performed various actions such as connecting to a Netserver share, creating new files, and reading/updating/deleting and renaming existing files. Kisco’s SafeNet/i exit point security software captured details about these transactions as they came through the exit point, and we reviewed what those transactions “looked like” from the exit point perspective.

In today’s article we will build on that knowledge and apply it to understand the Anatomy of a Ransomware Attack.

For a ransomware attack to impact the IBM i directly, the attack must come through some type of host where the ransomware code can execute, and where the IBM i IFS is accessible. The most common scenario is a Windows workstation with a network drive mapped to the IBM i Netserver.

The Netserver is commonly used to make parts (or the entirety) of the IFS accessible to Windows users. A connection can be made from the Windows host and the files/folders in the IFS will be easily accessible via Windows Explorer and other parts of the Windows user interface. This can be very convenient for users if you’re storing files (xlsx, pdf, etc) in the IFS of your IBM i server. However, it can also serve as a very convenient entry point for ransomware.

What does ransomware actually do?  Below are common actions that ransomware will try to perform:

• Encryption – This is the classic “ransomware” attack. It encrypts your files so the attackers can demand a ransom payment in order to provide you with the decryption key.
• Exfiltration – This type of attack involves stealing a large amount of your company’s sensitive data and threatening to release the data unless a ransom payment is made.
• Targeted – An attack where specific files or filenames are targeted. Files with “interesting” names like “financial_report.xlsx” or “employee_data.csv” can be targeted specifically.

What do each of these attacks look like from the File Server exit point perspective?

Encryption:
Encryption of your files requires the ransomware process to read existing files and then rewrite an encrypted version of that data over your existing files (or create new files and delete the originals). At the exit point there will be a marked increase in create / read / write / rename / delete operations. Below is a snip taken from SafeNet for each of those operations.

Exfiltration:
Reads are the primary transaction in this type of attack. The ransomware will open and read IFS files rapidly. On the infected Windows host where the ransomware is executing, it will be pushing that data out of your network and into the hands of the attackers. Therefore, a burst of read events from one user profile in a short period of time could indicate an exfiltration ransomware attack.

Targeted:
An attack that is hunting for files based on filename can be less obvious. The ransomware isn’t necessarily opening and reading from many files. Rather, the attack is more selective and might be encrypting or exfiltrating a small number of files based on name patterns. A common strategy is to set out a “trap” for attackers — a file with an alluring name like “payroll” that would never be accessed in any normal business workflow. This file should be monitored closely and ANY access attempt would be treated as an attack. This is commonly referred to as a “honeypot” file.

What can we do to protect ourselves?
Traditional security practices still apply.  You should control users’ permissions to the IFS, Limit (or eliminate) Netserver shares, and use authorization lists to secure the Netserver and the shares that you need to maintain.  You can also run antivirus/antiransomware software on your companies’ Windows systems, including user workstations.  Network-level threat detection can identify mass data exfiltration and raise alerts or even proactively stop the data transfer.  The conventional wisdom of “defense in layers” is the right approach.

Can the exit point data collected by SafeNet provide additional insights, or even another layer of defense against these sorts of attacks?  Stay tuned!

Contributed by:
Steve Riedmueller
IBM i Security Services Director
Kisco Systems