Forging SWIFT MT Payment Messages for fun and pr... research!

Before we begin: This research is based on work we performed in close-collaboration with one of our clients; however, the systems, architecture, and payment-related details have been generalized / redacted / modified as to not disclose information specific to their environment.

With that said... *clears throat*

The typical Tactics, Techniques and Procedures (TTPs) against SWIFT systems we see in reports and the media are - for the most part - the following:

1. Compromise the institution's network;
2. Move laterally towards critical payment systems;
3. Compromise multiple SWIFT Payment Operator (PO) credentials;
4. Access the institution's SWIFT Messaging Interface (MI);
5. Keys in - and then authorize - payment messages using the compromised PO accounts on the MI.

This attack-path requires the compromise of multiple users, multiple systems, an understanding of how to use the target application, bypass of 2FA, attempts to hide access logs, avoid alerting the legitimate operators, attempts to disrupt physical evidence, bespoke malware, etc. – so, quite involved and difficult. Now that’s all good and fine, but having reviewed a few different payment system architectures over the years, I can’t help but wonder:

“Can't an attacker just target the system at a lower level? Why not target the Message Queues directly? Can it be done?”

Well, let's find out! My mission begins!

So, first things first! I needed to fully understand the specific “section” of the target institution's payment landscape I was going to focus on for this research. In this narrative, there will be a system called “Payment System” (SYS). This system is part of the institution's back-office payment landscape, receiving data in a custom format and output's an initial payment instructions in ISO 15022 / RJE / SWIFT MT format.  The reason I sought this scenario was specifically because I wanted to focus on attempting to forge an MT103 payment message - that is:

• MT – “Message Type” Literal;
• 1 – Category 1 (Customer Payments and Cheques);
• 0 – Group 0 (Financial Institution Transfer);
• 3 – Type 3 (Notification);
• All together this is classified as the MT103 “Single Customer Credit Transfer”.

Message type aside, what does this payment flow look like at a high level? Well I’ve only gone and made a fancy diagram for this!

Overall this is a very typical and generic architecture design. However, let me roughly break down what this does:

1. The Payment System (SYS) ingests data in a custom - or alternative - message format from it's respective upstream systems. SYS then outputs an initial payment instruction in SWIFT MT format;
2. SYS sends this initial message downstream to a shared middelware (MID) component, which converts (if necessary) the received message into the modern MT format understood by SWIFT - Essentially a message broker used by a range of upstream payment systems within the institution;
3. MID forwards the message in it's new format on to the institution's Messaging Interface (let's say its SAA in this instance) for processing;
4. Once received by SAA, the message content is read by the institution's sanction screening / Anti-money laundering systems (SANCT).
5. Given no issues are found, the message is sent on to the institution's Communication Interface (SWIFT Alliance Gateway), where it's then signed and routed to the recipient institution over SWIFTNet.

OK, so now I have a general understanding of what I'm up against. But if I wanted to exploit the relationships between these systems to introduce a  fraudulent payment without targeting any payment operators, I was going to need to dig deeper and understand the fundamental technologies in use!

So how are these messages actually "passed" between each system? I need to know exactly what this looks like and how its done!

More often than not, Message Queues (MQ) are heavily used to pass messages between components in a large payment system. However, there are also various “Adapter” that may be used between systems communicating directly with the SAG (Such as SAA or other bespoke/3rd party systems). These are typically the:

• Remote API Host Adapter (RAHA);
• MQ Host Adapter (MQHA);
• Web Services Host Adapter (WSHA).

Having identified that MQ was in use, my initial assumption was that there was most likely a dedicated Queue Manager (QM) server somewhere hosting various queues that systems push and pull messages from? However, due to SWIFT CSP requirements, this would most likely - at a minimum - take the form of two Queue Managers. One which manages the queues within the SWIFT Secure Zone, and another that manages queues for the general corporate network and back office systems.

Let's update that diagram to track / represent this understanding:

Now I could research how this "messaging" worked!

There are multiple ways to configure Message Queues architectures, in this case there were various dedicated input and output queues for each system, and the message flow looks something like this:

Full disclosure, turns out it’s hard to draw an accurate - yet simple - MQ flow diagram (that one was basically my 4th attempt). So it’s... accurate "enough" for what we needed to remember!

Now I had a good understanding of how it all worked, it is time to define my goal: "Place a payment message directly on to a queue, and have it successfully processed by all downstream systems".

This sounds simple, just write a message to a queue, right? But there are a few complications!

1. Why are there few indications of this attack vector in the wild?
2. How do I even gain “write” access to the right queue?
3. What protects the message on the queues?
4. What protects the messages in transit?
5. What format are the messages in?
6. What is the correct syntax for that message format at any particular queue (0 margin for error)?
7. Where does PKI come in? How / where / when are the messages signed?
8. Can I somehow get around the message signing?
9. What values in the messages are dependent / controlled / defined by the system processing them (out of my control)?
10. What is the maximum amount I can transfer using Straight Through Processing, without alerting the institution / requiring manual validation?

But OK, there's no point dwelling on all of that right now, I'll just clearly define what I want to do!

The goal:

1. Successfully write a payment instruction for 500,000 GBP;
2. Inject that message directly onto a specific queue;
3. Have the message pass environment-specific validation rules;
4. Have the message pass sanctions and AML checks.
5. Have the message successfully signed;
6. Have the message pass SWIFTNet-specific validation rules;

What I was not interested in doing for this research - yet needed to understand nevertheless for a full attack chain was:

1. How to compromise the institution's network;
2. How to gain access to the MQ admin's workstation;
3. How to obtain the pre-requisite credentials.

What I wanted to 100% avoid at all costs:

1. The attack involving SWIFT payment operators in any way;
2. The attack involving SWIFT application access in any way;
3. A need to compromise signing keys / HSMs;
4. A need to compromise SWIFTNet operator accounts or certificates or any type of PKI;.

The message “body” is referred to as “block 4” (aka the “Text Block”) within the SWIFT MT standard. As suggested by the name, there is probably also a block 1-3. This is correct; and these blocks are typically generated by the payment processing applications - such as SWIFT Alliance Access - and not necessarily input by the operators. A "complete" MT103 message consists of 6 blocks:

• Block 1 – Basic Header
• Block 2 – Application Header
• Block 3 – User Header
• Block 4 – Text Block
• Block 5 – Trailer
• Block 6 – System block

So it looked like I was going to need to learn how to craft these various “blocks” from scratch.

To place a message on a queue, I was going to need two things:

• Access to the correct queue manager;
• Write access to the correct queues.

Depending on the environment and organisation, access to queue managers could be quite different and complex. However a bare-bones setup may take the following form:

• An MQ Administrator accesses their dedicated workstation using AD credentials;
• They then remotely access a dedicated jump server via RDP which only their host is whitelisted to access;
• This may be required as the queues may make use of Channel Authentication Records, authorizing specific systems and user accounts access to specific queues;
• The channels may further be protected by MQ Message Encryption (MQME) which encrypts messages at rest based on specific channels. As such, even if someone was a “super duper master admin” they would only be able to read / write to queues specifically allocated to them within the MQME configuration file (potential target for another time?);
• The MQ Admin can then use tools such via the Jump Server to read/write to their desired message queues.

So, in this scenario, to gain access to the message queues I - as an attacker - would need to compromise the MQ admin’s AD account and workstations, then use this to gain access to the jump host, from where I could then access the message queues given I knew the correct channel name and was configured with authorization to access it... and maybe throw some MFA in there...

That is understandably a significant requirement! However, when discussion sophisticated attacks against Financial Market Infrastructure (FMI), it is more than reasonable to accept that an Advanced Persistent Threat (APT) would see this as a feasible objective - We don't need to dig into the history of how sophisticated attacks targeting SWIFT systems can be.

Next, it was time to finally identify a feasible attack vector for message forgery.

Now with an idea of how to gain the right access, as well as an understanding of the various technologies and security controls in place; I update my diagram:

You may have noticed I've added something called “LAU” around the SAA-to-SAG adapter, and another “LAU” to the MID-to-SAA MQ channels, which I have yet to explain.  “Local Authentication” (LAU) is a security control implemented by SWIFT to authenticate messages using a pair of shared keys between two systems. These keys are combined and used to generate a SHA256 HMAC of the message and append it to the S block. This can then be validated by the recipient system. Effectively, this validates the origin and authenticity of a message. As such, even if an attacker was in position to introduce a fraudulent payment, they'd first need to compromise both the left and the right LAU signing keys, generate the correct HMAC, and append it to the message in order to have it accepted / processed successfully.

But LAU aside, I now just needed to figure out which queue to target! There were a lot of queues to work with as each system essentially has multiple “input” and “output” queues. With that in mind, it was important to note that: an incoming message would require being in the format expected by the target system (from a specific upstream system) and an outgoing message would need to be in the format “produced” by one target system and “expected / ingested / processed” by its respective downstream system. So to figure this out, I worked backwards from the Gateway.

So at this point I believe I had everything I needed in order to execute the attack:

• The target system!
• The message format!
• The queue manager!
• The queue!
• The access requirements!
• The generously granted access to a fully functional SWIFT messaging architecture! (that’s a good one to have!)
• The extra-generously granted support of various SMEs from the target institution! (This was even better to have!)

So that's that really...

With a bit of research and support I was able to demonstrate a PoC for introducing a fraudulent payment message to move funds from one account to another, by manually forging a raw SWIFT MT103 single customer credit transfer message, and leveraging various system trust relationships to do a lot of the hard work for me!

As mentioned briefly in the introduction, this is not something I have really seen or heard of happening in practice or in the "wild". Perhaps because it clearly takes a lot of work... and there is a huge margin for error. However, if an adversary has spent enough time inside your network and has had access to the right documentation and resources, this may be a viable attack vector. It definitely has its benefits:

• No need to compromise multiple payment operators;
• No requirement to compromise - or establish a foothold within - the SWIFT Secure Zone;
• No requirement to bypass MFA and gain credentials for a messaging interface;
• No generation of application user activity logs;
• No payment application login alerts;
• No bespoke app-specific and tailored malware;
• And all the other things associated with the complex task of gaining and leveraging payment operator access.

All an attacker may need to do is compromise one specific user on the corporate network: a Message Queue administrator.

The industry is spending a lot of time and effort focused on securing their payment systems, applications, processes, and users to keep - among other things - payment operators safe, Messaging Interfaces locked down, and SWIFT systems isolated. But the reality is,; the most valuable and most powerful individual in the entire model, might just be a single administrator!

As always, a security model is only as strong as its weakest link. If you're not applying the same level of security to your wider institution, there may very well be many weak links within the wider network which chain together and lead to the comrpomise of systems which feed into your various payment environment.

I think the main thing to remember when reflecting on this research is that it did not abuse any vulnerabilities within the target institution's systems, or even vulnerabilities or weaknesses within the design of their architecture. It simply leverages the legitimate user access of the Message Queue administrators and the trust relationships that exist by design within these types of large-scale payment processing systems.

So the harsh reality is, there is no particular list of recommendations for preventing this type of attack in itself. However, the main point to drive home is that you must ensure the security of your users - and overall organisation - is of a high enough standard to protect your highest privileged users from being compromised. Things such as:

• Strong monitoring and alerting controls for anomalous behaviour;
• Requirements for Multi-Factor authentication for access to critical infrastructure;
• Segregation of critical infrastructure from the wider general IT network;
• Strong password policies;
• Well rehearsed incident detection and incident response policies and procedures;
• Frequent high-quality security awareness training of staff;
• Secure Software Development training for your developers;
  
• Routine technical security assessments of all critical systems and components;
• The use of 3rd party software from reputable and trusted vendors;

However, in the context of Message Queues, there is one particular control which I think is extremely valuable: The implementation of channel specific message signing! This, as demonstrated by SWIFT's LAU control, is a good way in which to ensure the authenticity of a message.

As discussed, LAU is - as far as I know at the time of writing - a SWIFT product / message partner specific control. However it's concept is universal and could be implemented in many forms, two of which are:

• Update your in-house application's to support message signing, natively;
• Develop a middleware component which performs message signing on each system, locally.

This is a complex requirement as it requires considerable effort on the client’s behalf to implement either approach. However, SWIFT provides guidance within their Alliance Access Developers guide on how to implement LAU in Java, Objective C, Scala and Swift;

1. Strip any S block from the FIN message input. Keep only blocks 1: through 5;
2. Use the FIN message input as a binary value (unsigned char in C language, byte in Java). The FIN message input must be coded in the ASCII character set;
3. Combine the left LAU key and the right LAU key as one string. The merged LAU key must be used as a binary value (unsigned char in C language, byte in Java). The merged LAU key must be coded in the ASCII character set;
4. Call a HMAC256 routine to compute the hash value. The hash value must also be treated as a binary value (unsigned char in C language, byte in Java). The HMAC size is 32 bytes;
5. Convert the HMAC binary values to uppercase hexadecimal printable characters.

An example of how this may work in the more flexible middleware solution proposed is where the original service is no longer exposed to the network, and is altered to only communicate directly with the custom "LAU-eqsue" service on its local host. This service would then sign and route the message to its respective queue.

When received, the core of the recipient payment service would seek to retrieve its messages from the queues via the "LAU-esque" signing middleware, which would retrieve the message and subsequently verify its origin and authenticity by re-calculating the signature using their shared (secret) keys. Key-pairs could further be unique per message flow. This design could allow for the signing to be used as a way to validate the origin of a message even if it had passed through multiple [local] intermediary systems.

As a final bit of creative effort, I made yet another diagram to represent what this could perhaps look like - if life was as easy as a diagram:

If you made it this far thanks for reading all... ~6k words!? I hope you found some of them interesting and maybe learned a thing or two!

I'd like express our gratitude to the institution who facilitated this research, as well as specifically to the various SMEs within that institution who gave their valuable time to support it throughout.

Fineksus - SWIFT Standard Changes 2019

https://fineksus.com/swift-mt-standard-changes-2019/

Paiementor - SWIFT MT Message Structure Blocks 1 to 5

https://www.paiementor.com/swift-mt-message-structure-blocks-1-to-5/

SEPA for corporates - The Difference between a SWIFT ACK and SWIFT NACK

https://www.sepaforcorporates.com/swift-for-corporates/quick-guide-swift-mt101-format/

SEPA for corporates - Explained: SWIFT gpi UETR – Unique End-to-End Transaction Reference

https://www.sepaforcorporates.com/swift-for-corporates/explained-swift-gpi-uetr-unique-end-to-end-transaction-reference/

M DIBA - LAU for SWIFT Message Partners

https://www.linkedin.com/pulse/lau-swift-message-partners-mohammad-diba-1/

Prowide - About SWIFT

https://www.prowidesoftware.com/about-SWIFT.jsp

Microsoft - SWIFT Schemas

https://docs.microsoft.com/en-us/biztalk/adapters-and-accelerators/accelerator-swift/swift-schemas

SWIFT FIN Guru - SWIFT message block structure

http://www.swiftfinguru.com/2017/02/swift-message-block-structure.html