The IBM AS400 (now officially IBM i) has long been considered one of the most stable and secure computing platforms. Its integrated architecture, object-based design, and minimal attack surface earned it a reputation for robustness. But in 2025, stability alone is no longer synonymous with security.
Many enterprises still rely on AS400 systems to run core business applications—ERP, inventory, banking transactions, or legacy data management—but overlook the very real risks posed by poor configuration, outdated patching, and increased network exposure. As attack surfaces expand and interconnectivity deepens, even the most “trusted” systems can become viable entry points for attackers.
This is where modern AS400 penetration testing becomes not only relevant but essential.
The fallacy of “secure by design”
The AS400’s design—heavily object-oriented with built-in security controls—was revolutionary in the late 1980s. Access control was granular, auditing was integrated, and system-level menus enforced operational discipline. However, these features were conceived in an era with fundamentally different threat models: no cloud, no remote work, no zero-day exploitation.
Today, AS400 systems are often:
-
Connected to cloud-based frontends via APIs or middleware
-
Accessible remotely by admins, developers, or support teams
-
Integrated with hybrid infrastructure through data pipelines or web services
These integrations create new vectors of attack. More importantly, the assumption that “nobody targets AS400” leads to under-resourcing security controls, skipping audits, and overlooking privilege escalations.
What modern pentesting on AS400 looks like
Penetration testing on AS400 requires hybrid expertise: deep knowledge of the IBM i architecture and a modern attacker mindset. Unlike standard Linux or Windows assessments, there’s no Nmap + Metasploit quick win here. The process is layered, methodical, and highly contextual.
A thorough engagement often includes:
1. Reconnaissance and enumeration
Mapping out all exposed interfaces (Telnet, FTP, SSH, database ports, remote command ports) and collecting banner/version data for services like Remote Command (RMTCMD), ODBC, or DRDA. Special attention is paid to public IP exposure and internal network segmentation.
2. Credential and session abuse
Many AS400 deployments still use weak or default passwords on service accounts (e.g., QSECOFR, QPGMR). Brute-force and dictionary attacks, particularly on Telnet and 5250 emulation interfaces, can reveal critical entry points. If MFA is not enforced—and often it isn’t—attackers can establish persistent access undetected.
3. Privilege escalation
Once inside, testers assess object authorities, user profile hierarchies, and command menu permissions. Common misconfigurations—like ALLOBJ authority granted unnecessarily or public authority settings left at CHANGE—can lead to rapid escalation to full system control.
4. Lateral movement
Since AS400s often integrate with backend databases, LDAP servers, or reporting tools, attackers can pivot to or from the AS400 host. Insecure scripting, shared service accounts, or hardcoded credentials in CL programs may enable this.
5. Logging, detection, and response testing
The audit journal (QAUDJRN) and system values like QAUDLVL are evaluated to determine logging completeness. Can malicious activity be detected? Is there alerting in place? Many environments lack any real-time log correlation for IBM i systems.
Common vulnerabilities in the wild
Real-world testing often reveals:
-
Telnet enabled with no session encryption
-
Unused but enabled user profiles with *ALLOBJ
-
CL scripts containing plaintext credentials
-
Insecure exit programs and poorly managed exit points
-
Lack of proper patching on components like IBM Navigator for i
-
Hardcoded FTP batch jobs with sensitive info
In some cases, the attack surface is significantly increased due to third-party applications that bypass or weaken native IBM i security controls.
Why scanning isn’t enough
While vulnerability scanners may detect outdated firmware or open ports, they cannot replicate human exploitation logic. Most tools also have limited support for AS400-specific configurations, meaning the real risks—misused authorities, menu-level privilege issues, improperly secured objects—are left unassessed.
This is why automated audits must be supplemented by expert-led penetration testing. It’s not about how many vulnerabilities exist—it’s about whether they can be chained together into an exploit path.
Compliance, downtime, and business risk
Failing to secure AS400 environments has serious operational consequences. PCI DSS, ISO/IEC 27001, and other standards now require demonstrable testing of all systems storing or processing sensitive data—including legacy platforms. A compromise can lead not only to fines and investigations, but also critical downtime.
An unpatched AS400 exposed via VPN may be a silent liability—until a ransomware actor figures it out.
Choosing a partner with real platform expertise
Penetration testing AS400 systems isn’t just about running scripts. It’s about understanding how IBM i operates: from QSYS to QGPL, from user classes to authority collections. Generic pentesters won’t suffice.
That’s where www.superiorpentest.com comes in. Their team blends deep platform knowledge with advanced offensive security tactics, ensuring every test is relevant, risk-aware, and actionable.
They don’t just “scan and report”—they think like attackers, test like engineers, and report like professionals.
Legacy does not mean exempt
In a threat landscape where attackers seek the path of least resistance, legacy platforms like AS400 must no longer be considered secure by default. Instead, they must be scrutinized, tested, and defended like any other mission-critical component.
Modern penetration testing is not a luxury—it’s a necessity.