Introduction: The Epoch of Exposure

For over half a century, the global financial system and federal infrastructure operated under a doctrine of Security by Obscurity. The Common Business-Oriented Language (COBOL), while powering the world's most critical ledgers and master files, remained largely impenetrable to the modern threat actor. This was not due to inherent cryptographic strength, but rather a "knowledge moat" the dwindling population of engineers capable of navigating its unique syntax, EBCDIC encoding, and monolithic structures.

That era ended in February 2026.

With the emergence of agentic AI models specifically the breakthrough in Claude's automated code reasoning the "black box" of legacy computing has been rendered transparent. Systems that once required decades of institutional knowledge to understand can now be mapped, decompiled, and analyzed for logic flaws in a matter of seconds.

The threat is no longer theoretical. It is operational.

The Objective of This Manual

This field manual is designed for the modern cybersecurity investigator. It acknowledges that we are no longer defending "stable legacy systems"; we are defending an exposed attack surface. This document provides the technical protocols required to:

1.     Detect "Logic Drifts": Identifying when an adversary has used AI to subtly alter mathematical intent within a COBOL binary.

2.     Investigate "Ghost Logic": Uncovering malicious routines hidden within the "slack space" of ancient mainframe memory maps.

3.     Harden the Core: Implementing defensive coding standards that assume the adversary already has a full copy of the source code.

4.     Perform Forensic Triage: Managing the immediate aftermath of a compromise in high-concurrency environments like CICS and DB2.

The New Reality: Post-Obscurity Defense

In the post-2026 landscape, the primary vulnerability of a system is no longer its age, but its predictability. Because AI can now "reason" through the business logic of a COBOL program, it can predict how a system will react to corrupted inputs.

As an investigator, your mindset must shift from perimeter defense to logic integrity. You must assume that the "Greybeard" knowledge you once relied on is now in the hands of every threat actor with an API key.

The Investigator's Creed

•        Trust Nothing: If a program has not been cryptographically verified against a "Gold Standard" binary in the last 24 hours, assume it has been tampered with.

•        Verify Intent: Every MOVE, COMPUTE, and REWRITE must be audited not just for syntax, but for business logic alignment.

•        Protect the Ledger: The code is the weapon, but the Master File is the target. All investigation leads back to data integrity.

 

Chapter 1: The Mechanics of COBOL

To investigate or defend a legacy system, you must understand that COBOL is not just a programming language; it is a static memory-management system masquerading as English prose. It is deterministic, rigid, and operates on the principle of physical space rather than abstract objects.

Section 1.1: Structural Foundations (Identification & Environment Divisions)

Every COBOL program begins with a rigid hierarchy. These two divisions define the "Who" and "Where" of the program, providing the first trail for forensic investigators.

•        Identification Division: This is the program's legal ID.

◦        Forensic Detail: While mostly metadata, the PROGRAM-ID is what the operating system (z/OS) uses to link the code to a Load Module. If an investigator finds a mismatch between the PROGRAM-ID and the actual member name in the PDS (Partitioned Data Set) library, it is a primary indicator of an unauthorized module swap.

•        Environment Division: This acts as the bridge between the program's internal logic and the external hardware.

◦        The INPUT-OUTPUT SECTION: Here, the program maps "Logic Names" (used in code) to "External Names" (used in JCL).

◦        Investigation Vector: An attacker can perform File Redirects by subtly changing the ASSIGN clause. For example, redirecting the MASTER-ACCOUNT-FILE to a SCRATCH-FILE allows an adversary to siphon or manipulate data without updating the primary database.

Section 1.2: Memory Architecture (The Data Division)

In COBOL, memory is not dynamic. It is a pre-allocated grid. The Data Division is where the investigator looks to understand the "shapes" in memory that an attacker might try to "overflow".

•        FILE SECTION: Defines the layout of records as they sit on the disk.

•        WORKING-STORAGE SECTION: This is the program's internal RAM. Variables here are contiguous.

◦        The Contiguity Risk: If you have 01 USER-NAME PIC X(10) followed immediately by 01 IS-ADMIN PIC X VALUE 'N', a 12-character input into USER-NAME will physically overwrite IS-ADMIN.

•        LINKAGE SECTION: This is the "Transfer Zone." It handles data passed from other programs or from JCL via the PARM field.

◦        The "Shadow Memory" Attack: Because the Linkage Section doesn't "own" memory (it just points to memory owned by a calling program), an attacker can use a Size Mismatch to read memory outside the intended buffer.

The REDEFINES Hazard

The REDEFINES clause allows the same physical memory to be viewed as two different types of data.

Example: You define a 10-byte field as a string, then REDEFINE it as a series of numbers. Forensic Use: AI-assisted attackers use this to bypass input validation. They might pass "clean" text through a filter, then use a REDEFINES clause to treat that same text as executable logic or a manipulated numeric balance.

Section 1.3: Logic and Execution (The Procedure Division)

This is the engine room. Unlike modern languages with complex standard libraries, COBOL uses a small set of "Verbs".

•        The MOVE Verb: The most dangerous tool in the language. It doesn't just copy data; it performs implicit conversion. If you MOVE a string to a numeric field, the mainframe will attempt to "pack" it, which can be exploited to cause a "Data Exception" (S0C7 abend) to crash a system or hide a malicious calculation.

•        PERFORM and Logic Flow: COBOL uses "Paragraphs" instead of functions.

◦        The "Infinite Loop" Denial of Service (DoS): An attacker can manipulate a PERFORM UNTIL condition by targeting the counter variable in memory. Because variables are contiguous (Section 1.2), an overflow in an unrelated field can change the loop counter, locking the mainframe thread and driving up CPU costs.

•        Reference Modification: This allows you to address a specific part of a variable: VAR-NAME (offset:length).

◦        Investigation Detail: This is a "surgical" buffer overflow. An investigator must scan for any reference modification where the length or offset is a variable rather than a hard-coded number, as this is where AI agents "probe" for memory leaks.

Section 1.4: Computational Physics (PICTURE, USAGE, and COMP-3)

To a COBOL investigator, the hex-dump is the only source of truth. Understanding how data is physically encoded is essential for finding "hidden" logic.

The PICTURE (PIC) Clause

The PIC clause is a physical blueprint. PIC X is one byte of alphanumeric data. PIC 9 is one byte of "Zoned Decimal" numeric data.

The COMP-3 (Packed Decimal) Standard

Financial data is rarely stored as plain text. It uses Computational-3 (Packed Decimal), which compresses two digits into one byte to save space.

•        The Encoding Logic:

◦        Each digit is 4 bits (a nibble).

◦        The last nibble of the field is reserved for the Sign.

◦        C or F = Positive, D = Negative.

•        The Storage Formula: The physical size in bytes for a PIC S9(n) field is calculated as: ⌈(n + 1) / 2⌉

•        Forensic Investigation of COMP-3: If you see a hex-dump ending in 01 23 4C, it represents the number +1234. If an attacker changes that C to a D, they have flipped the sign of a transaction. Because this happens at the nibble level, it is invisible to most standard text-based logging systems. This is where "Salami Slicing" fraud is hidden.

 

Chapter 2: Forensic Triage and Investigating Memory Overwrites

In a legacy environment, a "security event" rarely looks like a modern malware alert. Instead, it manifests as a system Abend (Abnormal End) or, more dangerously, as Silent Data Corruption. This chapter provides the field protocols for triaging a compromised COBOL environment and identifying the specific memory overwrites used to subvert logic.

Section 2.1: Immediate Triage; The "Abend" as a Forensic Signal

When a COBOL program crashes on a mainframe, the system generates a completion code. In the post-2026 landscape, these codes are the primary indicators that an AI-assisted attack is probing the system's boundaries.

I. The S0C7 (Data Exception)

This is the most common forensic signal. It occurs when a numeric operation (like ADD or COMPUTE) attempts to process data that is not in a valid numeric format (usually a "Sign" error in a COMP-3 field).

•        The Investigator's View: An S0C7 is often the result of a failed buffer overflow. The attacker attempted to move a string into a numeric field to overwrite an adjacent variable, but the program attempted to perform math on that string before the "payload" reached its target.

•        Triage Step: Capture the Storage Dump immediately. Identify the specific line in the PROCEDURE DIVISION that triggered the exception and map the hex values of the input data.

II. The S0C4 (Protection Exception)

This occurs when the program attempts to access a memory address outside its assigned range.

•        The Investigator's View: This is a "Boundary Breach." It suggests an attempt to exploit the LINKAGE SECTION or use Reference Modification to read unauthorized memory segments (such as the CICS system areas).

•        Triage Step: Examine the registers at the time of the crash. If Register 13 or Register 1 contains an address far outside the program's memory map, you are looking at an active memory-injection attempt.

Section 2.2: Detecting "Variable Bleed" (Buffer Overflows)

Because COBOL memory is contiguous and lacks modern "Canary" values, a "Variable Bleed" is the attacker's preferred method for escalating privileges or diverting funds.

The Anatomy of the Bleed

Consider the following WORKING-STORAGE definition:

05 USER-INPUT-BUFFER    PIC X(20).

05 TRANSACTION-LIMIT   PIC 9(05) VALUE 00100.

05 AUTHORIZED-FLAG     PIC X     VALUE 'N'.

If an investigator detects that a transaction was processed for a user beyond their limit, the "Bleed" is the primary suspect.

•        Red Team Tactic: Input a 21-character string into USER-INPUT-BUFFER. The 21st character will physically overwrite the first digit of TRANSACTION-LIMIT. If that character is a '9', the limit is now 90100.

•        Blue Team Investigation:

◦        Variable Shadowing: Use a forensic AI agent to compare the "Expected Value" of TRANSACTION-LIMIT (00100) with its "Live Value" at the moment of the WRITE operation.

◦        Hex-Pattern Matching: Look for ASCII/EBCDIC text appearing in memory locations defined as PIC 9 (numeric).

Section 2.3: Hexadecimal Forensics and Bit-Level Analysis

In legacy systems, the "Truth" is not in the source code; it is in the Hex Dump. An investigator must be proficient in reading EBCDIC (Extended Binary Coded Decimal Interchange Code).

I. Identifying "Salami Slicing" in COMP-3

As established in Chapter 1, COMP-3 stores numbers in nibbles.

•        The Forensic Marker: An attacker may modify a "Rounding Module" to move fractions of a cent into a hidden field.

•        The Investigation: Perform a Bit-Check on the "Sign Nibble." If a calculation that should result in a positive balance (x'C') suddenly results in a negative (x'D') without a corresponding business logic trigger, the math has been tampered with at the binary level.

II. The "Ghost MOVE" Detection

Attackers use AI to identify code paths that are rarely executed (e.g., "End of Year" or "Disaster Recovery" paragraphs).

•        Investigation Protocol: Use Logic Topology Mapping. Compare the "Control Flow Graph" of the running binary against the source code. If the binary contains a MOVE or PERFORM branch that does not exist in the source, you have identified injected machine code.

Section 2.4: The 2026 "Digital Twin" Triage Method

Directly investigating a live mainframe is high-risk. In 2026, the standard protocol is to use AI-Assisted Emulation Triage.

5.     The Capture: Snapshot the entire memory state (the "Core Dump") of the suspicious transaction.

6.     The Replay: Load the dump into a containerized mainframe emulator (a "Digital Twin").

7.     Agentic Debugging: Deploy a reasoning agent (like Claude Code) into the emulator. Command: "Identify all instances where a MOVE operation resulted in a length-mismatch between source and target fields in the last 1,000 cycles."

8.     Isolation: Once the "Poisoned Variable" is identified, the investigator can "Air-Gap" that specific module by updating the JCL to route traffic through a sanitization wrapper.

Summary: Triage Checklist

Step	Action	Forensic Goal
1	Identify Abend Code (S0C7/S0C4)	Determine if the attack was a Logic or Boundary breach.
2	Map Contiguous Variables	Identify which variables sit "downstream" from user inputs.
3	Audit COMP-3 Sign Nibbles	Detect sign-flipping or fractional currency theft.
4	Run Digital Twin Replay	Isolate the exact microsecond the memory overwrite occurred.

 

Chapter 3: Investigating CICS and Middleware Vulnerabilities

If the COBOL program is the "Brain," the Customer Information Control System (CICS) is the high-speed nervous system. CICS is the transaction server that allows the mainframe to handle thousands of concurrent users, managing their memory, security, and data access. In the post-2026 environment, CICS is the primary battleground where AI-driven exploits attempt to "hop" between isolated bank accounts or federal records.

Section 3.1: The COMMAREA Leakage and "Residual Memory" Hijacking

The COMMAREA (Communication Area) is the legacy mechanism used to pass data between COBOL programs. Because it is a shared memory block, it is the #1 target for "lateral movement" within a mainframe session.

•        The Vulnerability: When one program finishes and passes control to another (via EXEC CICS RETURN), the data in the COMMAREA remains in memory. If the subsequent program does not explicitly overwrite this area, a "residual" fragment of the previous user's data; such as a Social Security Number or an API Token can be read by the next task.

•        Investigative Protocol:

◦        Search for DFHCOMMAREA Initialization: Audit the PROCEDURE DIVISION. Every program must begin with an INITIALIZE DFHCOMMAREA or a MOVE LOW-VALUES command.

◦        Detection of "Over-Reading": Identify instances where a program's LINKAGE SECTION defines a COMMAREA larger than the one passed to it. This "size mismatch" is used by attackers to peek into adjacent memory buffers.

•        Modern Defense: Transition all systems to Channels and Containers. Unlike the COMMAREA, which is limited to 32KB and is single-block, Channels allow for multiple named "Containers" of data, providing much stricter isolation and eliminating the "residual memory" risk.

Section 3.2: CICS Command Injection and the AEYD Abend

Just as web applications suffer from SQL injection, CICS programs suffer from Command Injection. This occurs when an attacker manipulates an input field that is subsequently used as a parameter in an EXEC CICS command.

•        The Vulnerability: If a program uses a variable to determine which file to open (e.g., EXEC CICS READ DATASET(WS-FILE-NAME)), and that variable is populated directly from a user terminal, an attacker can "inject" a different dataset name to access unauthorized files.

•        The Forensic Signal (AEYD): When Command Storage Protection is active, CICS validates that the program has "write access" to the storage it is trying to modify. If an injection attempt tries to force CICS to write into a protected system area, the task will crash with an AEYD abend.

•        Investigation: Use AI to scan for any EXEC CICS commands where the DATASET, PROGRAM, or TRANSID parameters are not hard-coded constants. These are the "pivot points" for an exploit.

Section 3.3: Task Isolation and the S0C4 Protection Exception

In a standard configuration, multiple transactions run in the same "Address Space." Without Transaction Isolation (TRANISO), one transaction can accidentally (or maliciously) overwrite the memory of another.

•        The Architecture: Modern mainframes use MVS Subspaces to give each CICS task its own "virtual room." If a program tries to reach through the "wall" into another task's memory, the hardware triggers a Protection Exception (S0C4).

•        Red Team Tactic: Using AI to find "Storage Keys" that are set to CICS-key instead of User-key. Programs running in CICS-key have the authority to overwrite system control blocks, effectively giving the attacker "Root" access to the mainframe.

•        Investigative Protocol:

◦        Check EXECKEY in RDO: Audit the Resource Definition Online (RDO). Any application program defined with EXECKEY(CICS) should be treated as a critical security risk.

◦        Analyze ASRA Abends: In CICS, an S0C4 is reported as an ASRA abend. Use the CICS Trace facility to identify the exact instruction that attempted the cross-memory access.

Section 3.4: The Gateway Gap (Middleware Forensics)

The mainframe is rarely attacked directly. The breach usually begins at the Middleware Layer, the CICS Transaction Gateway (CTG) or MQSeries which connects the web to the COBOL core.

•        The 2026 Crisis (CVE-2026-0977): Recent vulnerabilities in CICS Gateways have exposed an "Improper Access Control" flaw. Attackers can bypass the gateway's authentication and send raw "Binary Payloads" directly to the mainframe, bypassing the web-layer's security filters.

•        Investigation of the "Protocol Break":

◦        Audit CTG Logs: Look for "Unmatched Payloads" transactions where the size of the data sent from the web doesn't match the size of the data received by CICS.

◦        Identity Spoofing: In a gateway breach, the mainframe sees the transaction as coming from the "Middleware User ID" rather than the "End User ID."

•        Defensive Protocol: Implement Identity Propagation. Ensure that the original user's credentials (RACF/ACF2) are carried through the gateway and re-validated by CICS for every single program call.

Summary: Middleware Security Table

Component	Primary Risk	Forensic Signature
COMMAREA	Data Leakage	Residual PII in hex-dumps.
EXEC CICS	Parameter Injection	AEYD Abend / Unauthorized File Access.
Transaction	Cross-Task Contamination	ASRA / S0C4 Protection Exceptions.
Gateway (CTG)	Identity Spoofing	Transactions running under "System" IDs.

 

Chapter 4: Investigating the "Silent Edit" in Master File Forensics

The "Master File" whether a VSAM dataset or a DB2 table is the ultimate authority in legacy environments. It represents the final, persisted state of a taxpayer's history, a bank's ledger, or a citizen's benefits. In the post-2026 "Transparent Code" era, attackers no longer aim for system crashes; they aim for Silent Data Corruption. This chapter provides the field protocols for detecting and attributing unauthorized modifications to these critical records.

Section 4.1: VSAM Forensic Auditing (SMF Type 64 and Record-Level Monitoring)

VSAM (Virtual Storage Access Method) files are the bedrock of mainframe data storage. Because they are not relational databases, they lack the "Trigger" and "Log" structures common in modern SQL environments.

I. The SMF 64 "Fingerprint"

The System Management Facility (SMF) writes a Type 64 record every time a VSAM cluster is closed.

•        Investigative Protocol: Compare the SMF64TME (Time) and SMF64JOB (Job Name) against the official Batch Schedule.

•        The Forensic Marker: If a Type 64 record exists for a high-value dataset (e.g., PAYMENT.MASTER.KSDS) but there is no corresponding record in the job scheduler, a "Ghost Job" or a manual TSO edit has occurred.

II. Record-Level Monitoring (RLM)

For "Level 1" critical files, standard SMF logging is insufficient. Investigators must utilize Record-Level Monitoring (e.g., IBM Guardium S-TAP).

•        The Attack: An adversary uses a COBOL "Z-module" to perform a surgical REWRITE on a single record, changing a routing number.

•        The Detection: RLM captures the Before and After image of the record. Use AI to scan RLM logs for "Out-of-Pattern Updates" instances where a record was modified outside of standard business hours or by a User ID that typically only has READ access.

Section 4.2: DB2 Accounting and Audit Forensics (SMF 101/102 and IFCIDs)

DB2 for z/OS provides robust auditing through Instrumentation Facility Component IDs (IFCIDs), but these logs are massive. AI-assisted filtering is required to find the "Silent Edit."

I. The IFCID 141/142 Audit

These IFCIDs track DML (Data Manipulation Language) operations: INSERT, UPDATE, and DELETE.

•        Forensic Protocol: Activate Audit Policies on sensitive tables. Use an AI agent to correlate IFCID 141 records with COBOL Host Variables.

•        The "Silent Edit" Signature: Look for "Predicate Mismatches." If the COBOL source says WHERE ACCT-ID = :HV-ACCT, but the DB2 trace shows an additional, unauthorized clause (e.g., OR 1=1), an SQL Injection has occurred via an un-sanitized COBOL input.

II. Analyzing SMF 101 (Accounting Records)

SMF 101 records provide the "Resource Signature" of a transaction.

•        Investigation: If a transaction that normally processes 10 rows suddenly touches 10,000 rows, it is a sign of a "Bulk Exfiltration" or a "Mass Logic Update" attack.

Section 4.3: Detecting the "Silent Edit" (Logic vs. Ledger)

The "Silent Edit" is a discrepancy between the Program Logic and the Final Ledger. Detecting it requires a three-way comparison.

The "Triple-Point" Audit Protocol

9.     Source Code Audit: What the program claims to do (e.g., ADD 1 TO BALANCE).

10.  Binary Integrity Check: Use AI to decompile the live Load Module. Does the machine code match the source? (Checking for "Ghost Logic").

11.  Data Consistency Check: Compare the DB2 table against its mirrored VSAM backup.

Red Team Tactic (The "Hidden MOVE"): An attacker uses a MOVE statement to shift a value into a "Filler" area of a DB2 Host Variable. This data is never displayed on a screen but is written to the database, where a second malicious program later "harvests" it.

Section 4.4: Master File Integrity Standards (2026 X-Force Protocol)

To defend against the surge in AI-enabled vulnerability discovery (documented in the 2026 IBM X-Force Threat Index), the following standards are mandatory for Master File protection:

•        Cryptographic Commitment: Every write-operation to a Master File must generate a unique hash of the Record + User ID + Program Name. This "Integrity Token" is stored in a separate, immutable log.

•        Protocol Breaking Gateways: Ensure no direct SQL access from web-facing applications. All Master File updates must pass through a "Sanitization Microservice" that uses AI to verify the transaction's semantic intent before "throwing" it to the mainframe.

•        CVE-2026-3856 Alert: Investigators must immediately patch IBM Db2 Recovery Expert (v5.5 IF 2), which was found to lack integrity checks during data transmission, allowing for man-in-the-middle data corruption.

Summary: Master File Forensic Table

Data Type	Primary Forensic Tool	Key Record/ID	Risk Level
VSAM KSDS	IDCAMS / Guardium	SMF Type 64	Critical
DB2 Tables	DB2 Audit Trace	IFCID 141/142	High
Batch Jobs	SMF Type 30	STEP-CPU-TIME	Medium
Security (RACF)	SMF Type 80	ERR-CODE 13	Critical

 

Chapter 5: JCL Forensics & Logic Bomb Investigation

While COBOL is the "Brain," Job Control Language (JCL) is the "Orchestrator." It defines the execution environment, allocates the data, and dictates the sequence of operations. In the 2026 threat landscape, JCL has moved from a background utility to a primary attack vector. If an adversary can manipulate the JCL, they can subvert a perfectly secure COBOL program without changing a single line of its source code.

Section 5.1: The Red Team Perspective; Orchestrating the "Invisible" Exploit

For a Red Team, JCL is the tool of choice for Persistence and Evasion. Because JCL is often treated as "infrastructure" rather than "code," it frequently bypasses traditional application security audits.

I. The JCL Logic Bomb (Conditional Execution)

The primary goal is to hide malicious activity within legitimate batch flows using conditional parameters like COND or the more modern IF/THEN/ELSE/ENDIF constructs.

•        The Tactic: Insert a "Dormant Step" that executes a malicious utility (e.g., an unauthorized data transmitter) only when a specific, rare condition is met.

•        The Trigger:

// IF (STEP01.RC = 777) THEN

//   EXFIL  EXEC PGM=REXX-EXTRACT,PARM='OFFSHORE-IP'

// ENDIF

•        Exploit Logic: The attacker ensures STEP01 only returns RC=777 on a specific date (e.g., a holiday) or when a specific "Trigger File" exists. To a human auditor, the EXFIL step looks like a dormant recovery routine.

II. "Ghost Job" Submission via the Internal Reader (INTRDR)

The most sophisticated Red Team technique involves submitting jobs through the Internal Reader without leaving a trace in the job scheduler (like CA-7 or IWS).

•        The Tactic: A compromised CICS transaction or a running COBOL program writes raw JCL lines directly to the SYSOUT=(A,INTRDR) file.

•        The Exploit: This bypasses the standard submission pipeline. The "Ghost Job" runs under the Authority of the Submitting Task (often a highly privileged Service ID), allowing for unauthorized Master File updates that appear to be "system-generated."

Section 5.2: The Blue Team Perspective; Forensic Reconstruction

The Blue Team must treat every JCL script as a signed manifest. In an era where AI can generate thousands of JCL variants to probe for misconfigurations, defenders must rely on System Management Facility (SMF) logs to reconstruct the truth.

I. Tracing the "Ghost" via SMF Type 30 and 26

When a job is submitted via the Internal Reader, it still generates SMF records.

•        Forensic Protocol:

◦        SMF Type 26 (JES2/JES3 Job Purge): This record identifies the Submitter ID and the Input Source. If the source is an internal address rather than a known scheduler, it is a high-priority flag.

◦        SMF Type 30 (Work Unit Initiation/Termination): This provides the "Execution Signature." Compare the STEPNAMEs in the Type 30 record against the official Production Library version of that JCL. Any mismatch indicates a JCL Override occurred at runtime.

II. AI-Assisted Manifest Verification

In 2026, Blue Teams utilize Holographic JCL Baselines.

•        Defense Protocol: An AI agent maintains a cryptographic hash of every production JCL member. At submission time, the "Live JCL" is compared against the "Gold Manifest."

•        Detection: If the AI detects an unauthorized //PROCLIB or //JOBLIB override which could redirect the program to execute a malicious version of a COBOL module the job is automatically moved to a HOLD status for manual review.

Section 5.3: JCL Vulnerability Matrix

Feature	Red Team (Exploitation)	Blue Team (Investigation)
COND / IF	Hiding "Logic Bombs" in conditional branches.	Use AI to map the "Full Logic Tree" and identify un-called paragraphs.
INTRDR	Submitting "Ghost Jobs" from within trusted tasks.	Audit SMF Type 26 for non-scheduler submission sources.
JOBLIB / STEPLIB	Redirecting execution to unauthorized binary libraries.	Enforce RACF/ACF2 protection on all production Load Libraries.
PARM Field	Passing encrypted commands to a "Trojan" COBOL program.	Use SMF Type 30 Subtype 4 to capture the raw PARM string for every step.

Section 5.4: Forensic Checklist for JCL Investigation

12.  Check for TYPRUN=SCAN Failures: Attackers often test JCL syntax using SCAN to avoid execution logs.

13.  Audit SYSOUT Redirection: Look for jobs that write sensitive data to SYSOUT=* instead of a protected dataset, making it viewable in the spool (SDSF).

14.  Identify "Utility Abuse": Search for unauthorized use of powerful utilities like IDCAMS, IKJEFT01 (TSO in batch), or ADRDSSU (Data Set Services) which can be used for bulk exfiltration.

Operational Note: In a 2026 environment, a JCL change is a System Configuration Change. No JCL should be allowed to execute in production without a verified hash matching its source-controlled version.

 

Chapter 6: Recovering from a Compromised Ledger

In a legacy environment, the greatest threat is not a system crash, but a successful, undetected logic breach. Standard Disaster Recovery (DR) is designed for hardware failure or site loss; it assumes the data is "good" but "unavailable." Forensic Recovery assumes the data is "available" but "poisoned."

This chapter outlines the protocols for identifying the "Point of Infection" and restoring the integrity of the Master File without re-introducing the malicious logic that corrupted it.

Section 6.1: The Integrity Gap; Functional vs. Forensic Recovery

When an AI-assisted "Silent Edit" occurs, your standard backups are likely compromised. If a logic bomb has been siphoning funds for three days, your last 72 hours of backups contain the "Poisoned Ledger."

Feature	Functional DR (Standard)	Forensic DR (Integrity-Focused)
Primary Goal	Minimize Downtime (RTO).	Minimize Data Corruption.
Assumption	The latest backup is the best.	The latest backup is a crime scene.
Method	Restore to most recent point.	Restore to "Last Known-Good" (LKG).
Validation	Does the system start?	Does the math match the business rules?

Section 6.2: Determining the Point of Infection (PoI)

Before any data is restored, the investigator must identify the exact moment the logic was subverted.

15.  The Metadata Audit: Scan SMF Type 30 (Job Start) and SMF Type 80 (RACF/Security) records. Look for the first instance of an unauthorized Load Module execution or a JCL override.

16.  The Balance Divergence: Use a Reconciliation Agent (AI tool) to compare the General Ledger against its "Check-and-Balance" sub-files. The moment the totals deviate even by a fraction of a cent is your Point of Infection (PoI).

17.  Forward Log Analysis: Once the PoI is found, analyze the DB2 Logs or VSAM Forward Recovery Logs. These logs contain every single change made after the infection. You will need these to "sift" the legitimate transactions from the fraudulent ones.

Section 6.3: Point-in-Time Recovery (PITR) Protocol

Recovery is a "surgical" operation. You are not just restoring a file; you are reconstructing the truth.

Step 1: The "Gold Copy" Restore

Restore the Master File from a backup created prior to the PoI. This is your "Clean Base."

Step 2: Log Replay and Filtration

You cannot simply "replay" the logs, as the logs contain the attacker's transactions.

•        The Protocol: Use an Identity-Based Filter. Replay all logged changes to the Master File, but automatically block any change originated by the compromised User ID or the malicious COBOL module identified in the investigation.

•        Validation: If the log replay encounters a record that was modified by a "tainted" process, that record is moved to a Suspense File for manual human audit.

Section 6.4: The "Logic Scrub" Preventing Re-Infection

A common mistake in legacy recovery is restoring the "good data" onto a system that still contains the "bad code."

•        Binary Sanitization: Before the restored ledger is brought online, every Load Module in the production libraries must be re-compiled from verified, source-controlled code. This ensures that no "Ghost Logic" remains in the executables.

•        JCL Manifest Lockdown: All JCL used for the recovery must be "Hardened." This means removing all STEPLIB or PROCLIB overrides that an attacker could use to re-pivot the system back to their malicious libraries.

Section 6.5: Post-Recovery Validation (The "Truth" Test)

Once the ledger is restored and the logs are replayed, the Blue Team must perform a Holographic Audit.

18.  Checksum Comparison: Run a batch job to calculate a 256-bit hash of the entire Master File. Compare this hash against a "Synthetic Model" a version of the ledger created by an AI agent that simulated the last 48 hours of business activity using only verified, legitimate inputs.

19.  Shadow Execution: For the first 4 hours of post-recovery operation, run the system in "Shadow Mode." Every output is mirrored to a secondary file and checked for "Logic Drift" before being sent to the live network or the clearinghouse.

Summary: The Forensic Recovery Checklist

Priority	Action	Responsibility
1	Identify Point of Infection (PoI)	Forensic Investigator
2	Isolate and Quarantine the "Poisoned" Backup	Storage Admin
3	Restore "Gold Copy" from Archive	Backup Operator
4	Filter and Replay Transaction Logs	DB2/VSAM Admin + AI Agent
5	Re-Compile all Production Binaries	DevSecOps / Author
6	Final Reconciliation Audit	Financial Auditor

Final Note: Recovery from a logic breach is not about speed; it is about certainty. In the 2026 landscape, a "fast" recovery that leaves behind a single corrupted bit is a failure that will eventually result in the total collapse of the institution's credibility.

 

Chapter 7: RACF/ACF2 Security Auditing

In the mainframe environment, the COBOL program is the "Actor," but the Security Server most commonly RACF (Resource Access Control Facility) or ACF2 is the "Director." It decides which program can see which data and which user can execute which job. For an investigator, the security logs are the ultimate record of intent.

Section 7.1: The Gatekeeper's Ledger; Understanding SMF Type 80

Every time a user or a program attempts to access a protected resource (a dataset, a CICS transaction, or a Load Module), RACF generates an SMF Type 80 record. This record is the single most important forensic artifact for detecting Privilege Escalation and Unauthorized Data Exfiltration.

I. The Structure of a Type 80 Record

•        SMF80USR: The User ID associated with the request.

•        SMF80DES: The Resource Name (e.g., the name of the VSAM file or the DB2 plan).

•        SMF80EVT: The Event Code (defining what happened).

•        SMF80REA: The Reason Code (defining why it was allowed or denied).

II. Key Event Codes for Investigators

Event Code	Name	Forensic Significance
01	JOBINIT	Detects unauthorized job submissions or "Ghost Jobs."
02	ACCESS	Critical. Detects attempts to read or write to a Master File.
13	COMMAND	Detects the use of TSO commands (like DELETE or ALTER) on system files.
34	SETROPTS	Detects an attacker trying to turn off system-wide auditing.

Section 7.2: Identifying "Access Violations" vs. "Successful Exploits"

The most common mistake in legacy forensics is only looking for Access Denied errors. In a 2026 AI-driven attack, the adversary often has already compromised a valid User ID.

I. Analyzing the Result Code (Return Code)

•        Return Code 0 (Success): This is where the "Silent Edit" lives. An investigator must look for Successful Access to a sensitive file (Event 02) by a User ID that does not usually perform that task. Example: A "Systems Programmer" ID accessing a "Payroll Master" file.

•        Return Code 8 (Insufficient Authority): This indicates a "Probing" attempt. If an AI agent is scanning the mainframe for vulnerabilities, you will see a rapid-fire sequence of RC 8 errors across multiple datasets in the SMF logs.

II. The "Violation" Bit

Inside the Type 80 record, the Relocate Section contains a "Violation Bit." If this bit is set, it means the access was allowed only because the user has the SPECIAL or OPERATIONS attribute.

•        Forensic Protocol: Any record where the violation bit is set for a Master File access must be treated as a high-priority "Internal Threat" event.

Section 7.3: Investigating Privilege Escalation (ACF2 and RACF)

In 2026, attackers use AI to map the "Permission Tree." They look for "Broad Profiles" security rules that use wildcards (e.g., FINANCE.**) which might inadvertently grant access to sensitive sub-files.

I. The "Inheritance" Attack

Attackers look for programs that run with Authorized Program Facility (APF) status.

•        The Exploit: An APF-authorized program can "bypass" security checks. If an investigator finds an unauthorized COBOL module in an APF-authorized library (identified via SMF Type 30), the security of the entire mainframe is compromised.

•        Forensic Step: Use the SETROPTS LIST command (or the ACF2 equivalent) to audit all APF-authorized libraries. Cross-reference this list with the SMF 80 records to see if any non-standard programs were executed from those libraries.

II. Detecting "Surrogate" Submissions

Attackers often use the SURROGAT class in RACF to submit jobs as another user.

•        The Investigation: Look for Event Code 01 (JOBINIT). Check if the "Submitter ID" matches the "Execution ID." If they differ, and there is no pre-approved surrogate relationship, an attacker has "assumed the identity" of a high-privilege account.

Section 7.4: The 2026 Bi-Polar Security Stack

Security Event	RACF (SMF 80)	ACF2 (Logings)	TSS (Top Secret)
User Login	Event 01	ACF2 Journal	TSS Audit Record
Dataset Access	Event 02	DSN Trace	Resource Access
Privilege Change	Event 34	Security Admin Log	Admin Changes
Command Use	Event 13	CMD Trace	Command Audit

Section 7.5: Practical Field Scripting; The "SMF 80 Scraper"

When arriving on-site at a compromised institution, a "Quick Scan" of the security logs is required. Investigators use a REXX script or an AI agent to extract a "Summary of Interest."

The Investigation Logic

20.  Filter SMF 80 records for the last 24 hours.

21.  Extract all Event 02 (Access) records for datasets starting with SYS1.** or PROD.MASTER.**.

22.  Flag any record where the Return Code is not 0 OR where the User ID is a Service Account performing an ALTER or DELETE operation.

23.  Correlate these flags with the CICS Trace (Chapter 3) to see if a specific web-transaction triggered the security event.

Summary: The Security Audit Checklist

•        SMF 80 Event 02: Did a user touch a file they shouldn't have?

•        SMF 80 Event 34: Did someone try to turn off the "cameras" (auditing)?

•        APF Audit: Are there any "stranger" programs in the authorized libraries?

•        Surrogate Check: Is the person who sent the job the same person who ran the job?

Operational Note: RACF/ACF2 logs are the "truth" of the mainframe. While an attacker can manipulate COBOL logic or JCL scripts, it is nearly impossible to delete an SMF record once it has been written to the system's protected log stream. Always follow the SMF 80 trail.

 

Chapter 8: AI-Assisted Modernization & the Migration Security Problem

As established in the February 2026 Epoch of Exposure, the sudden transparency of COBOL has triggered a "Gold Rush" toward modernization. Organizations are using agentic AI to translate decades of legacy logic into modern languages like Java, C#, and Python at unprecedented speeds.

However, for the investigator and the defender, this migration creates a Secondary Security Crisis. Translating code is not the same as translating security. This chapter identifies the "Migration Gaps" where attackers exploit the transition between the mainframe and the cloud.

Section 8.1: The "Functional Equivalence" Trap

AI models excel at "Functional Translation" ensuring that the output of a Java program matches the output of a COBOL program. They frequently fail at "Security Equivalence."

•        The Problem: COBOL security often relies on the physical architecture of the mainframe (e.g., Storage Keys, RACF, and isolated Address Spaces). When that logic is moved to a cloud-native environment (Kubernetes, AWS Lambda), those hardware-level protections disappear.

•        The Vulnerability: A COBOL program might have a "Buffer Overflow" that is physically impossible to exploit on a mainframe due to MVS Subspace Isolation. When translated to C++ or Java, that same logic becomes a textbook, high-risk vulnerability in the heap memory of a modern server.

•        Investigation Protocol:

◦        Cross-Architecture Audit: Identify every REDEFINES or OCCURS clause in the source COBOL.

◦        Check the Translation: Verify how the AI handled these clauses in the target language. If the AI used a simple "Array" without bounds checking, it has introduced a Remote Code Execution (RCE) vulnerability that did not exist in the legacy version.

Section 8.2: Injected Modern Vulnerabilities (The "Translation Leak")

When an AI model translates COBOL, it often pulls from modern coding patterns found in its training data. This can inadvertently introduce "Modern" flaws into "Old" logic.

I. SQL and Command Injection

COBOL often uses static, hard-coded file names. AI models, attempting to "modernize" the code, often introduce dynamic variables to make the code more flexible.

•        The Risk: An AI might take a static COBOL READ and turn it into a dynamic SQL query in Java. If the AI does not properly parameterize the input, it creates an SQL Injection point that was physically impossible in the original flat-file VSAM structure.

II. The "Library Bloat" Vulnerability

AI-generated modernization often relies on third-party libraries (e.g., Spring Boot, Log4j, or specific EBCDIC-to-JSON converters).

•        Forensic Protocol: Every modernized module must undergo a Software Bill of Materials (SBOM) audit. Attackers target the converters used during migration, knowing that organizations are so focused on the logic that they ignore the "plumbing" libraries.

Section 8.3: The "Twin-Verify" Protocol (Holographic Parity)

To defend against migration-based corruption, investigators must implement the Twin-Verify Protocol. This ensures that the new system is as resilient as the old one.

The Methodology

24.  Parallel Execution: Run the legacy COBOL and the modernized Java module in a "Side-by-Side" container.

25.  Deterministic Comparison: Feed both systems the same 1,000,000 historical transactions.

26.  The Parity Check: Use an AI reasoning agent to compare the outputs. If the outputs match, but the Execution Time or Memory Footprint of the new system varies wildly, it indicates "Inefficient Logic" that can be exploited for Resource Exhaustion (DoS) attacks.

Section 8.4: Decommissioning and the "Zombie Mainframe"

The final stage of modernization is often the most dangerous: the period when the old and new systems coexist.

•        The "Zombie" Threat: Many organizations keep the mainframe in a "Read-Only" state for historical auditing. Because it is "Read-Only," security monitoring is often reduced.

•        The Exploit: Attackers use the "Zombie Mainframe" as a staging ground. They compromise the legacy core (which still has access to the Master Files) and use it to feed "Poisoned Data" into the new modernized system.

•        Forensic Step: Ensure that once a module is "Migrated," the corresponding COBOL module is not just "Unused," but Physically Scratched from the Load Library. Audit the RACF logs (Chapter 7) for any access to "Decommissioned" datasets.

Section 8.5: Red vs. Blue Analysis of AI Modernization

Migration Step	Red Team (Attacker)	Blue Team (Investigator)
Logic Extraction	Identifies "Undocumented Features" to exploit in the new cloud environment.	Uses AI to generate documentation for the "Black Box" logic before migration.
Code Translation	Probes for "Implicit to Explicit" errors (e.g., missing sign checks in Java).	Implements "Strong Typing" and "Boundary Guards" in the target code.
Library Inclusion	Targets the "Converters" for supply-chain attacks.	Performs SBOM audits on every modernization dependency.
Decommissioning	Uses the "Forgotten Mainframe" as a persistent backdoor.	Implements "Final-State" RACF lockdowns on all legacy libraries.

Summary: The Modernization Security Checklist

•        Parity: Does the Java output match the COBOL output to the last bit?

•        Sanitization: Did the AI add SQL parameterization where there was once only a VSAM READ?

•        Isolation: Does the cloud environment provide the same "Task Isolation" as a CICS Subspace?

•        Cleanup: Is the legacy "Zombie" code truly deleted, or just hidden?

Operational Note: Modernization is the greatest opportunity for security, but it is also the greatest window of vulnerability. As an investigator, your job is to ensure that the "Resilience of the Mainframe" is successfully transplanted into the "Agility of the Cloud."

 

Appendix A: How COBOL Coding Works at a Basic Level

To investigate COBOL, one must speak its language. Unlike modern free-form languages like Python or Java, COBOL is a positional language born from the era of 80-column punch cards. Every character must sit in its designated "margin," or the compiler will reject the entire program.

A.1 The Fixed-Format Layout (The 80-Column Rule)

A COBOL source file is historically divided into specific columns. If a forensic investigator sees code shifted even one space to the left or right, it is a sign of a broken build or an improperly injected "Logic Bomb."

Columns	Name	Purpose
1–6	Sequence Number	Historically used to keep punch cards in order. Now largely ignored.
7	Indicator Area	Used for comments (*), debugging (D), or continuing a literal (-).
8–11	Area A	Where Divisions, Sections, Paragraphs, and Level 01 headers must start.
12–72	Area B	Where the actual logic (verbs, statements, and level numbers > 01) sits.
73–80	Identification	Used for program names or version tracking. Ignored by the compiler.

A.2 Defining Data: The Level Numbers

COBOL organizes data in a hierarchy using Level Numbers. This is how a "Master Record" is constructed.

•        01: The Record Level (The entire block of memory).

•        05–49: Group or Elementary items (Sub-parts of the memory block).

•        77: Independent items (Variables that stand alone).

•        88: Condition names (Special "True/False" flags).

Example of a Memory Map

01 WS-TRANSACTION-RECORD.

   05 WS-TRANS-ID       PIC X(10).

   05 WS-TRANS-AMOUNT   PIC 9(05)V99.

   05 WS-TRANS-STATUS   PIC X.

      88 TRANS-SUCCESS  VALUE 'S'.

      88 TRANS-FAILED   VALUE 'F'.

A.3 The "PIC" Clause Building Blocks

•        PIC X (Alphanumeric): Accepts any character.

•        PIC 9 (Numeric): Accepts only digits (0–9).

•        PIC V (Assumed Decimal): Tells the compiler where the decimal point should be. It does not store a physical "." in memory (saving space).

•        PIC S (Sign): Tells the compiler the number can be positive or negative.

A.4 The Basic Verbs (Logic Operations)

COBOL logic reads like a technical manual. There are no brackets {}; instead, statements end with a period . or an explicit scope terminator (like END-IF).

1. The MOVE Statement

MOVE WS-INPUT-DATA TO WS-OUTPUT-AREA.

•        Forensic Note: If the target is smaller than the source, COBOL simply truncates the data. If it is larger, it pads with spaces or zeros.

2. Arithmetic Operations

ADD 1 TO WS-COUNTER.

COMPUTE WS-TOTAL = (WS-PRICE * WS-QUANTITY) + WS-TAX.

•        Forensic Note: The COMPUTE verb is where complex logic is hidden. Investigators look for unauthorized multipliers added to these lines.

3. Conditional Logic

IF WS-TRANS-AMOUNT > 1000.00

   PERFORM 2000-HIGH-VALUE-AUDIT

ELSE

   PERFORM 3000-PROCESS-NORMAL

END-IF.

4. The PERFORM Statement

PERFORM 1000-OPEN-FILES THRU 1000-EXIT.

A.5 A Minimalist COBOL Template

IDENTIFICATION DIVISION.

PROGRAM-ID. HELLO-WORLD.

ENVIRONMENT DIVISION.

CONFIGURATION SECTION.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-MESSAGE   PIC X(12) VALUE 'HELLO ANTHONY'.

PROCEDURE DIVISION.

0100-START-LOGIC.

    DISPLAY WS-MESSAGE.

    STOP RUN.

A.6 Forensic Summary for Beginners

•        The Period . is King: Missing a period, or putting one in the wrong place, can change the entire logic flow of an IF statement.

•        Fixed Length: Variables never grow or shrink. They are static boxes in memory.

•        EBCDIC vs ASCII: On a mainframe, the character 'A' is hex C1, not hex 41. Modern investigators must always check the encoding of the environment.

 

Appendix B: Advanced Syntax, Expressions, and Object-Orientation

To perform a forensic deep-dive, an investigator must understand the mathematical and logical "grammar" of COBOL. This appendix covers the mechanics of how data is manipulated, how logic branches are evaluated, and how modern Object-Oriented (OO) structures are implemented in the 2026 legacy environment.

B.1 Arithmetic Expressions and the COMPUTE Verb

While COBOL provides simple verbs like ADD, SUBTRACT, MULTIPLY, and DIVIDE, the COMPUTE statement is the primary engine for complex calculations. It is also a high-value target for logic-tampering.

I. The Syntax of COMPUTE

COMPUTE WS-INTEREST-DUE ROUNDED = (WS-PRINCIPAL * WS-RATE * WS-DAYS) / 365.

II. The ROUNDED and SIZE ERROR Clauses

•        ROUNDED: Without this, COBOL simply truncates any digits that exceed the PIC definition. An attacker might remove the ROUNDED clause to create "Salami Slicing" opportunities.

•        ON SIZE ERROR: This is the primary defensive trap. If a calculation results in a number larger than the PIC clause allows, this block executes.

•        Forensic Protocol: Scan for COMPUTE statements lacking an ON SIZE ERROR clause. These are prone to arithmetic overflows that can crash a system or flip numeric signs.

B.2 Conditional Expressions and Class Tests

I. Relation Conditions

These compare two values using operators like EQUALS, LESS THAN, or GREATER THAN.

•        Investigation Note: COBOL comparisons are based on the Collating Sequence (usually EBCDIC). In EBCDIC, letters come before numbers. An AI-assisted exploit might leverage this difference to bypass a filter designed for ASCII environments.

II. Class Conditions (The Forensic Shield)

•        IF WS-INPUT IS NUMERIC: Checks if the data contains only digits.

•        IF WS-INPUT IS ALPHABETIC: Checks if the data contains only A–Z and spaces.

•        Forensic Use: Always look for these tests before a MOVE or COMPUTE. If an investigator finds a raw input being moved to a numeric field without a NUMERIC class test, they have found a potential S0C7 (Data Exception) exploit point.

III. The EVALUATE Statement (Modern Case Logic)

EVALUATE TRUE

   WHEN WS-AMT > 10000  PERFORM 900-REPORT-FINCEN

   WHEN WS-AMT > 5000   PERFORM 800-SENIOR-APPROVAL

   WHEN ANY             PERFORM 700-PROCESS-NORMAL

END-EVALUATE.

B.3 Intrinsic Functions: The 2026 Toolkit

Function	Purpose	Forensic Value
FUNCTION CURRENT-DATE	Returns YYYYMMDDHHMMSS.	Used to timestamp unauthorized modifications.
FUNCTION REVERSE	Reverses a string.	Often used by attackers to "obfuscate" simple strings.
FUNCTION SUM	Totals a series of variables.	Used for rapid reconciliation audits of Master Files.
FUNCTION NUMVAL	Converts a string to a number.	A target for "Type Confusion" attacks.

B.4 Object-Oriented COBOL (OO-COBOL)

While traditional COBOL is procedural, modern mainframes support OO-COBOL. This is often where legacy systems interface with web services (Java/Python).

I. The REPOSITORY Paragraph

REPOSITORY.

   CLASS MY-CLASS AS 'com.bank.SecurityCheck'.

II. Defining a Class and Method

CLASS-ID. SECURITY-GATEWAY.

IDENTIFICATION DIVISION.

...

METHOD-ID. "VALIDATE-TOKEN".

DATA DIVISION.

LINKAGE SECTION.

01 LS-TOKEN   PIC X(64).

01 LS-RESULT  PIC 9.

PROCEDURE DIVISION USING LS-TOKEN RETURNING LS-RESULT.

*> Logic to verify token integrity

GOBACK.

END METHOD "VALIDATE-TOKEN".

END CLASS-ID. SECURITY-GATEWAY.

•        Investigation Detail: In OO-COBOL, objects are managed by the "Java-COBOL Interoperability" layer. If an investigator suspects a "Middle-man" attack, they must audit the Object-Storage areas, which are often not captured by standard COBOL dump tools.

B.5 Advanced Program Flow: CALL and CANCEL

•        Static CALL: The program name is hardcoded (CALL 'PROG1'). The link is resolved at compile time.

•        Dynamic CALL: The program name is a variable (CALL WS-PROG-NAME).

◦        The Vulnerability: If an attacker can overwrite WS-PROG-NAME in memory, they can redirect the execution flow to a malicious "Trojan" module they have uploaded to a temporary library.

•        The CANCEL Verb: This removes a sub-program from memory.

◦        Forensic Use: If an attacker uses CANCEL, they are likely trying to "wipe the tracks" of a malicious module so it cannot be found in a later memory dump.

Summary: The "How-To" Coding Checklist for Defenders

27.  Always use COMPUTE with ON SIZE ERROR.

28.  Explicitly test every user input with IF DATA IS NUMERIC.

29.  Use END-IF, END-PERFORM, and END-EVALUATE instead of the period . whenever possible to avoid "Dangling Logic" bugs.

30.  Avoid Dynamic CALL statements unless the variable is strictly validated against a hardcoded whitelist.

 

Appendix C: Glossary of Terms and Abend Codes

In the high-pressure environment of a mainframe forensic investigation, clear communication and rapid diagnostic interpretation are critical. This appendix serves as a field-ready reference for the terminology and system failure codes encountered when triaging a compromised legacy core.

C.1 Key Mainframe & COBOL Terminology

Term	Definition	Forensic Context
Abend	Abnormal End. A program crash or system-level termination.	The primary "smoke" signal of an active memory-injection attempt.
APF	Authorized Program Facility. A list of libraries allowed to bypass standard security checks.	If an attacker places a malicious COBOL binary in an APF library, they gain system-wide authority.
CICS	Customer Information Control System. Middleware that manages high-volume transactions.	The "Transaction Gateway" where web-based exploits often enter the mainframe.
Copybook	A reusable block of COBOL code (usually DATA DIVISION definitions).	Attackers may compromise a shared Copybook to inject vulnerabilities into dozens of different programs simultaneously.
EBCDIC	Extended Binary Coded Decimal Interchange Code. The 8-bit character encoding used by mainframes.	Forensic tools must be set to EBCDIC; viewing a mainframe dump in ASCII will result in unreadable data.
JCL	Job Control Language. The scripting language used to run batch jobs on z/OS.	Used to "Orchestrate" an attack by redirecting files or libraries.
Load Module	The compiled, executable version of a COBOL program.	The target for "Binary Patching" or "Ghost Logic" injection.
RACF / ACF2	Mainframe Security Servers (Access Control).	The "Truth" of the system; records every access attempt in the SMF logs.
SMF	System Management Facility. The logging engine of the mainframe.	The "Black Box" of the investigation. Contains the SMF 30 and SMF 80 records.
VSAM	Virtual Storage Access Method. The high-performance file system for legacy data.	The physical location of the "Master Files" and the target of "Silent Edits."

C.2 Common Abend Codes for Investigators

System Abends (Sxxx)

•        S0C1 (Operation Exception): The CPU attempted to execute an invalid instruction. Forensic Signal: Often indicates that an attacker has successfully overwritten the PROCEDURE DIVISION with malicious machine code, but the code is malformed.

•        S0C4 (Protection Exception): The program tried to access memory it does not own. Forensic Signal: A clear sign of a Boundary Breach or an attempt to "hop" from a user task to a system task.

•        S0C7 (Data Exception): A numeric operation failed due to invalid data (usually in a COMP-3 field). Forensic Signal: The signature of a Failed Buffer Overflow. The attacker pushed a string into a numeric field, but the program tried to perform math on it before the exploit could complete.

•        S806: A requested Load Module could not be found. Forensic Signal: May indicate that an attacker has deleted a legitimate module or is attempting to trigger a "Fail-Open" state.

CICS Abends (Axxx)

•        ASRA: The CICS version of an S0C1, S0C4, or S0C7. Forensic Signal: Look for the Offset in the CICS trace to find the exact line of COBOL code that was compromised.

•        AEYD: A security violation during an EXEC CICS command. Forensic Signal: Indicates a Command Injection attempt where the program tried to access a protected file or transaction.

•        AZI6: A problem with a distributed program link (DPL). Forensic Signal: Often triggered when an attacker attempts to intercept data between the web-gateway and the mainframe core.

C.3 The "Red-Flag" Correlation Matrix

Detected Signal	Potential Intent	Investigative Priority
Recurring S0C7 in Batch	Brute-force probing of COMP-3 boundaries.	High
SMF 80 Event 02 (RC=8)	Unauthorized dataset reconnaissance.	Medium
Sudden JCL COND Changes	Insertion of a Logic Bomb or "Dormant" routine.	Critical
CICS COMMAREA Over-read	Identity theft or session hijacking.	Critical
STOP RUN in Mid-Paragraph	Manual interruption of a transaction to "freeze" memory.	High

C.4 Final Field Checklist

31.  Identify the User ID: Was the crash triggered by a Human ID or a System Service ID?

32.  Locate the Load Library: Is the program running from the production library (PROD.LOAD) or a temporary library (TEMP.LOAD)?

33.  Capture the Hex: Do not rely on "translated" logs. Always pull the raw hex-dump of the memory at the time of the Abend.

34.  Check the Date: Was the logic modified recently? Compare the DATE-COMPILED in the IDENTIFICATION DIVISION against the authorized Change Management log.

Final Note: This glossary is a living document. As AI models continue to discover new ways to "bend" legacy logic, new Abend patterns will emerge. Always trust the Binary Truth over the source code documentation.