Is that ransomware on your mainframe?

Next week at SHARE – San Jose, I’m giving a talk on ransomware on z/OS.  I’ve been asked multiple times if I thought ransomware could happen on Z, is it possible: Unequivocally yes.  Come see this talk and watch a live demonstration of how this might work.   If you are responsible for mainframe security, work for a company with a mainframe, or just want to better understand the landscape of this particularly insidious threat, don’t miss this talk.

Ransomware is a combination of 3 basic moving parts:

  1. A delivery mechanism (Phishing email, infected web page, malicious program).
    • This infects the user’s machine – allowing for sniffing of credentials and network traffic.  It can then upload a payload to the host system.
  2. File cataloging and encrypting.
    • Just what it sounds like – find files of interest, encrypt them in place, destroy the local copy of the key.
  3. Some type of Command & Control (or at least reporting) – centralized server.
    • Some means of transferring the keys out to the bad guys. Also, a way for the affected users to connect and pay ransom. (This is not strictly required, but does have precedent.  Steps #1 & #2 can happen regardless of the system’s ability to ‘phone home’ ).

We will also look at how to attempt to mitigate this catastrophic event, as well as ideas about how to recover from it.  Items such as two-factor authentication, proper ICSF / RACF security controls, egress filtering and intrusion detection.

SHARE 2016 Atlanta – Presentation – Mainframe exploits

This is a co-presentation I did with Brian Marshall and Mark Wilson.

My slides are the last few, where I demonstrate 3 distinct exploits on the mainframe.  First, off-the-shelf Java with Jboss.  Second, TN3270 SSL MITM (using SETn3270 – thx to @mainframed767) and then use the stolen creds in a mainframe Metasploit module to get a shell.   And third, the final stages of what was a malicious SMP/E payload – demonstrated by an IPL that has an already inserted malicious SMF exit module installed (IEFU29).

Hope you enjoy it! PS – The animated GIFs that show the actual demonstrations don’t work in the deck via slideshare, so I’ve posted them separately below.

02-ssl-creds-msf 02-java-jexboss

Updated JCL in Metasploit Functionality

Recently updated my work in Metasploit to allow for editing of the JCL JOB card, in PR7221.

What this means for you senior and aspiring z/OS pentesters, is that you can tailor JCL you submit with valid CLASS,MSGCLASS,NOTIFY,ACCOUNTING etc.

This will allow for more success running jobs on different systems and, out of the box, it is set with defaults that will run quiet on most systems.

Next MSF project is a TN3270 layer, which will allow for scripted information gathering and attacks on systems – using the TN3270/TSO interface.

Mainframes – Java – Deserialization

I was asked a week or so ago whether or not I thought z/OS would be susceptible to the types of Java deserialization attacks we’ve seen (a great primer from Fox Glove Security).   Of course!, I replied.  However, I don’t like unsubstantiated claims – so I built this POC:


It uses the basic ysoserial payload generator found on Github.   The file I use to test is from a blog here:

The source is simple:

Simple enough right?    Java on the mainframe is basically Java anywhere.  The only major gotcha (which should come as no surprise to anyone) are with issues of character translation  EBCDIC<->ASCII.   In this case, the ysoserial jarfile I built on x86 and just binary copied it to OMVS and that worked out of the box.

Other times I’ve had to use an a2e / e2a custom decoder – just depends on the implementation.  Currently working to test the JBoss exploits and modify them, if need be, in MSF for z/OS.  More as that unfolds!


While testing this POC first on x86, I kept running into an error like this:

The above mentioned blog helped – Basically Java 1.8u72 (since last December) needs to have the most current version of ysoserial, and use the CommonsCollections5 in order to work (and it does).   Prior versions of Java work just fine with the Release Version (0.04) of ysoserial.

Also, aside from fixes that are library based (like the Adobe Commons Collections one used here), most fixes to this bug have to happen in customized code, often written by organizations.   That makes this vulnerability particularly ugly and potentially difficult to mitigate.

Things I’ve Learned (and things to come)

I started writing a list of topics I’ve learned, some in excruciating detail, some just enough to know where to look for further details (trust me, that is no small feat).

I’m writing this not only as a way of keeping me honest on those days when nothing goes right, but also as a way to incentivize those among you who, like myself, have an insatiable desire to learn – and the tenacity to “figure it out.”

In most organizations, the below is accomplished by teams of people.   Some of the items (gen’ing a system from scratch, for instance – or setting up SMP/E, SMS, etc. from scratch – might never be a part of even a very senior mainframer’s repertoire).  I wanted to see what it would take to go it alone.

My plan is to build this page out with good links to relevant data – and/or if I get really ambitious build some how-tos on the finer points, if there is interest.  Real language how and wherefores.

THINGS I’VE LEARNED  (since I started a deep technical dive into mainframes)

  • RACF
    • password construction / algorithms
    • user profile management
    • using callable services
    • TSO commands for many common elements
    • building certificates
    • importing certificates
    • user certificates
  • Storage Management
    • Configuring SMS from scratch
    • Initializing devices
    • using DFDSS to move, backup and restore files
    • using IDCAMS for catalog and VSAM file management
    • what the eff a VSAM file is
    • how to allocate datasets
    • different access methods (qsam, bdam, etc)
    • what the hell a cylinder (or track) is
    • How big a mod 3,9,27,54 EAV are
    • Initializing volumes
    • labeling and initializing tapes
    • troubleshooting space abends (D37,B37,E37)
  • System Programming
    • SMP/E updates, installation, management
    • Building jcl from scratch
    • Configruing IPL parms, parmlibs, and startup shutdown procs from scratch
    • checking system resources
    • How apf authorization works
    • building a lnklist
    • building an lpalib
    • building a multi-tier catalog system
    • taking SVC dumps
    • Getting a trace of a component
    • reading said trace
    • using IPCS
    • troubleshooting failed ipls
  • z/OS crypto
    • keychain management
    • key management
    • password configuration
  • Assembler Programming
    • What a load module is
    • What a program module is
    • how to disassemble them
    • writing assembly
    • using 4 different debuggers
    • patching programs the hard way
    • building a ZAP
    • Using Macros
    • Compiling, Linking
    • Callable service usage
    • What the hell Language Environment is
  • SDSF
    • Jes2 job management
    • Reading a job log
    • managing output
    • managing active jobs
    • reconfiguring SDSF screens
  • JES2
    • NJE
    • Job management
    • Configuration files
    • parmlib entries
  • TCP/IP
    • TN3270 configuration
    • FTP configuration
    • FTP/S configuration
    • TN3270 + ssl configuration
    • Policy Agent configuration
    • TSO / USS tcp/ip commands
    • creating zfs filesystems
    • dbx debugger
    • compiling and linking with xlc
    • What the hell Language Environment is
  • z/OS operations
    • Many console commands (devices, stg)
    • How to research a WTOR
    • Vtam commands
    • tcpip commands
    • device commands
  • ISPF
    • Panel customization
    • DDLIST wizardry
    • Editor fine-tuning
    • Keylist modification
    • using the editor – line & main command sets


  • VTAM
  • REXX
  • memory areas and control blocks in depth
  • So much more (work in progress)
  • SMF
  • z/OMSF
  • policy agent
  • ATTLS (in depth)
  • Coding Exits
  • Hardware configuration
  • Cross memory operations (PC, SRB, etc)
  • much more

A logical first step

The first z/OS exploit module in the Metasploit Framework, landed last Friday.

This is an exploit which takes advantage of a default or poorly configured FTP server. And, it requires valid credentials.  However, given this (and it’s a very common configuration), you will be presented with a very nice Unix shell – allowing for deeper testing of the system.

This is how it begins:  attackers look for low hanging fruit. The evolution of pentesting tools for the mainframe has to start somewhere, and this is the first concrete milestone in what has been an ongoing journey. Many x86 exploits are simply taking advantage of default configurations or poorly written code. z/OS is no different – it can suffer from neglected configurations and defaults like all other OS’s. So, that’s where I started. From here, we’ll build on default configuration exploits and work up and on through binary / code exploitation. Baby steps.

At any rate – I’m very proud of how this turned out. Thanks to those who helped in the prototyping phases (SoF & others noted within the exploit) – and as always, the super helpful folks on the MSF teams. For those of you testing mainframe systems – hopefully it’ll help red teamers with an easy win and start the conversation on securing the big iron.

There are more goodies in the queue, so stay tuned!

PR # 6834 – Authorized FTP JCL exploit for z/OS

JCL Scripting for Metasploit-Framework

# update 3/31 – added Reverse Shell JCL – this can be used by any direct-to-JES2 delivery method (e.g. FTP, NJE, etc)

PR #6737

In continuation of adding more mainframe functionality to Metasploit, I’ve built (and am in the process of incorporating) JCL (job control language)-based payloads (and exploits which use them) within the framework.

Once these updates are complete, Metasploit users with credentials (or some other type of vulnerability exploit), will be able to submit jobs directly to JES2 via ftp(/s) or NJE (hats off to Soldier of Fortran, for the python prototype of NJE).

I’ll keep a running tally of the Pull Requests here, along with demonstrations and updates.

The first PR is simply a basic JCL cmd payload, that does nothing but submit a job which always returns a code 0 (success).

PR #6717

Here’s a screenshot of one of the finished exploit modules that will be submitted for inclusion soon:ftp_exploit

More to come!