In June, 2026, Syngnia published an analysis of an AI-enabled cyber attack that successfully compromised an AWS cloud instance. The methods used to exploit AWS with AI provide insight into common IBM i vulnerabilities, demonstrating the need for security modernization.
We recommend reading through Sygnia's analysis before proceeding:
Inside an AI-Assisted Cloud Attack: Familiar Techniques at Unfamiliar Speed
At the heart of the AWS attack is fairly simple pathway that is in no way unique to AWS:
What makes this case noteworthy is that AI did not introduce new techniques. Instead, it allowed the attacker to execute this familiar attack path much faster and in parallel across multiple identities and systems, compressing what might have taken weeks into roughly 72 hours.
Here are 5 attack-path-focused takeaways from the Sygnia investigation that are highly applicable to IBM i, Windows, Linux, cloud, and other enterprise platforms, not just AWS:
Initial access came from an exposed application weakness, then immediately pivoted to credential theft. The attacker first exploited a weakness in an internet-facing application and obtained credentials. Those credentials became the real enabler of the attack. The lesson for IBM i and other systems is that application vulnerabilities often serve only as the entry point—the real objective is acquiring accounts, API keys, service credentials, or other secrets that allow expansion.
Every newly acquired credential triggered a new attack cycle. Rather than following a simple linear path, the attacker repeatedly used newly discovered credentials to restart the same process: reconnaissance, privilege discovery, secrets harvesting, persistence creation, data access, and impact actions. This "credential-hopping" pattern is platform-independent and mirrors how attackers move through IBM i user profiles, service accounts, shared credentials, and trusted connections.
Secrets and credentials were the primary targets throughout the intrusion. The attacker systematically searched for credentials wherever they might exist—environment variables, configuration files, databases, secrets stores, CI/CD systems, and storage repositories. The broader lesson is that attackers treat every system as a potential credential repository. On IBM i, this translates to protecting user profiles, service accounts, application connection strings, API tokens, FTP credentials, and embedded passwords in CL programs or scripts.
Persistence was established at multiple layers, not just one. The threat actor created multiple backdoors and alternate access paths, including new accounts, additional credentials, modified deployment files, reverse shells, and elevated application users. The key takeaway is that attackers do not trust a single foothold. On any platform, including IBM i, defenders should assume an adversary will attempt to maintain access through multiple mechanisms simultaneously.
The ultimate goal was operational control and business disruption, not just data theft. After gaining broad access, rather than the traditional ransomware attack where data is encrypted, the attacker demonstrated the ability to disrupt services, restrict access, alter configurations, and impact operations. Data theft occurred, but controlling critical business functions created the real leverage. For IBM i environments running core ERP, manufacturing, finance, or distribution workloads, an attacker who gains administrative control could achieve a similar outcome through account lockouts, subsystem disruption, job manipulation, configuration changes, or application interference including data manipulation.
Most, if not all, of the IBM i systems on which we've performed security discovery services would have been easily exploited by an attack of this nature - only much faster. Let's take a look at how commonly found "legacy" security configurations expose IBM i:
Network-facing weakness
The biggest weakness we see, by far, is unencrypted connections and TELNET connections in particular. When connections are unencrypted, your user names and passwords are sent over the network in the clear. Network sniffing technology can easily detect these credentials and make them available to attackers. You might as well not have passwords! Other weaknesses include IFS root shares, DDM connections that don’t require a password, and unsecured API endpoints.
Credential discovery
There is still a shockingly high proliferation of default passwords across the IBM i install base. A default password is a password that is the same as the user name. As we can see from this attack, AI can automate and speed up "brute force" login attempts. Default passwords just make it easier.
Privilege escalation
Two legacy configurations on IBM i facilitate privilege escalation. The first is *PUBLIC authority to powerful user profiles. Unfortunately, our discovery services often discover this vulnerability. Where it exists, an attacker can submit a job using a more powerful profile, create their own powerful profile and gain full access to the system. The other configuration is from Job Descriptions that name powerful profiles, which is one of the vulnerabilities of a system running QSECURITY level 30.
Data access
Many legacy IBM i configurations have wide-open production data. A holdover from the old ‘menu security” days, it’s very common to discover thousands of *FILE objects set to *PUBLIC authority *CHANGE or *ALL. An attacker only needs to download the (free) ACS client from IBM and launch it to download, modify or clear the data in these files. No need for the attacker to be familiar with IBM i – a simple prompt to any AI model lists the exact ACS feature to use and commands to run to exploit unsecured IBM i data.
Understand your weaknesses and address them before an attacker exploits them. Security Discovery services from Kisco Systems will tell you everything you need to know.
Monitor everything, with email/SMS alerts. Don't let attackers quietly try to access your system. IBM i monitoring solutions for QAUDJRN and exit points can notify you for things like:
Introduce new controls. Exit point software, like Kisco's SafeNet, can lock down system access through SQL, FTP, IFS and many more interfaces, even if your core object authorities are wide open. A good solution can also shut down the CL command vulnerability in FTP and SQL.
There's a good chance your IBM i system is highly vulnerable to any targeted attack, much less a fast-moving AI-enabled attack. Contact Kisco Systems for an assessment and/or penetration test.
RELATED POSTS
BROWSE KISCO U
PRODUCT CONTENT
