SWIFT МТ103

Annotation

Recently, the internet has seen a surge in scammers who exploit people’s lack of knowledge to swindle them out of significant amounts of money. When examining payments in the SWIFT system, offers about manual download of payments (manual download) are particularly common. Hackers set these up (as they will explain their work to you), and at most, you receive a PDF file with a confusing set of symbols that looks logical but has nothing to do with SWIFT. This article describes procedures that will genuinely help you compose a payment message capable of passing compliance checks for amounts up to 500,000 euros, thanks to trusted relationships within the SWIFT system. You will also understand the general principle of how the SWIFT system operates and will be able to conduct preliminary checks of messages to detect forgeries.

Prologue

Everything described in this article is presented for informational purposes. All data related to companies and individuals in the article are generalized, edited, or altered. The article does not encourage illegal actions. It is presented for educational purposes only.

Let’s get to the point:

Typical hacker attacks related to the SWIFT system, which we can observe in police reports or mass media, include the following:

1. Compromising the institution’s network;
2. Exploiting critical bugs in the payment system;
3. Compromising SWIFT payment operator credentials;
4. Accessing the institution’s SWIFT message exchange interface;
5. Authorizing payment messages using compromised payment operator accounts and message exchange interface;

To execute this attack vector, you would need to compromise multiple users and systems, understand how the target application works, bypass two-factor authentication, hide access logs to avoid alerts from legitimate operators, set up malware, etc.—which even in brief description sounds VERY complicated.

Therefore, we’ll start from simple to complex and describe the overall system arrangement to help you understand how the SWIFT system works. We’ll analyze a standard payment instruction and then study each attack vector more closely.

General Parameters

First, you need to fully understand and figure out the specific “section” of the payment system (SWIFT) in the target institution. We’ll simply call it SWIFT.

SWIFT accepts data in an arbitrary format and outputs initial payment instructions in ISO 15022 / RJE / SWIFT MT format.

We’ll focus on compromising the MT103 payment instruction, namely:

• MT – “message type”
• 1 – category 1 (customer payments and cheques)
• 0 – group 0 (financial institution transfer)
• 3 – type 3 (notification)

Altogether, this is classified as MT103 “Single Customer Credit Transfer” (SCCT).

Besides the message type, we need to understand how this payment is processed. It’s quite typical for such types of transfers and looks like this:

1. The system (SWIFT application) accepts data from the user in a format convenient for them (e.g., by filling fields in the application’s graphical interface). Then the system outputs the initial payment instruction in SWIFT MT format;
2. The system sends this message further to a component called Middleware (MW), which converts (if necessary) the received message into a modern SWIFT format understandable by the system. Essentially, it’s a message broker provided for non-institutional financial organizations.
3. The MW sends the formed message to the Institutional Financial Institution (Bank, Credit Organization, or other, hereafter referred to as Bank for convenience) for processing.
4. The Bank checks the content of the message, conducts a series of checks (whether the company is on a blacklist, passes anti-money laundering system checks, verifies the legality of the operation for high volumes, makes a request to the antitrust authority or currency control if such options exist in the country where the Bank is located)
5. If the message is correctly formed and passes internal bank checks, it is sent to the Swift Alliance Gateway, where it is signed and sent to the recipient organization/bank via SwiftNet.

Let’s delve a bit deeper into this technology.

Understanding Data Exchange Details

Let’s ask the question: how are these messages transmitted between all these systems?

Most often, any Payment System uses Message Queues (MQ) to transmit messages between various components.

There are various “adapters” that can be used between systems that exchange data directly with the Swift Alliance Gateway:

• Remote Host Adapter API (HAPI)
• Message Queue Host Adapter (MQHA)
• Host Adapter Web Services (WSHA)

From the SWIFT CSP requirements, you can learn that to maintain Message Queues, you need a dedicated Queue Manager server, where various Message Queues (MT1xx, MT2xx, etc.) will be located, from which systems will send and retrieve messages.

The requirements also strictly state that there must be at least two queue administrators. One manages queues in the SWIFT Work Zone, and the other for communication in the corporate network and/or other institution systems (e.g., intra-bank operations must be SEPARATE from operations related to the SWIFT system, as well as operations in other payment systems like VISA, MASTERCARD, or SEPA).

Identifying a Viable Vector for Implementation

It’s time to define the task: “Insert a payment instruction into the queue and have it successfully processed in all systems (pass validation)“

The task is simple, so let’s ask the right questions to help with implementation:

1. How to get write access to the desired queue?
2. What protects messages in the queues?
3. What protects the message in transit?
4. In what format are the messages?
5. How to compose a syntactically correct message for the chosen format? (goal: 0 errors)
6. Where is the PKI (Public Key Infrastructure)? How, where, and when are messages signed and verified?
7. Is there any way to bypass the message signature?
8. Which values in the messages are dependent on / controlled by / determined by the system processing them outside my control (or someone else’s)?
9. What is the maximum amount I can transfer without alerting the institution / without requiring manual verification?

Now let’s detail the task further, point by point:

1. Competently write a payment instruction for 500,000 euros;
2. Insert this payment instruction into the queue;
3. The message must pass the syntax check (ACK or NACK);
4. The message must pass all additional checks, including AML (Anti-Money Laundering) checks;
5. The message must be successfully signed;
6. Pass validation when checked by SWIFTNet rules;

From a hacker’s perspective, it looks like this:

1. Compromise the institution’s network;
2. Gain access to the Queue Manager administrator’s workstation;
3. Obtain the necessary company details;
4. Carry out the required work.

The following should be avoided:

1. An attack involving the SWIFT payment operator (the system itself);
2. An attack using access to the SWIFT application (direct access to the official banking application);
3. The need to compromise signature keys (forging digital keys);
4. The need to compromise SWIFTNet operator accounts or certificates.

Analyzing the MT103 Body

We need to figure out how to make the simplest payment instruction in MT103 format. Typically, a bank operator (or any other SWIFT system user/operator) writes payment messages just like we do, but using a convenient graphical interface (e.g., Alliance Access). In raw form, it looks something like this:

:20:TRANSACTIONMT103

:23B:CRED

:32A:200707EUR500000,00

:50K:/GB22EBNK88227712345678

JOHN DOE

JOHN'S BUSINESS LTD

21 JOHN STREET, LONDON, GB

:59:/FR20FBNK88332287654321

ALICE SMITH

ALICE'S COMPANY

10 ALICE STREET, PARIS, FR

:70:12345-67890

:71A:OUR

Let’s examine each field highlighted :LIKE THIS: in detail.

:20: Transaction Reference Number

16x—this field can only be 16 characters long. Using this reference, your bank can identify the message within its network, just like the sending bank.

:23B: Bank Operation Code

4!c—four uppercase letters indicating the operation. In our case, it’s CRED—credit to the beneficiary.

:32A: Date / Currency / Amount

6!n3!a15d—the field is filled in strict sequence. First the date (year/month/day), then the currency in uppercase letters (e.g., EUR, USD, RUB), then the amount in arbitrary digit order.

Also, for example, if the commission in field 71A is specified as BEN, then field 33B is added, indicating the exact amount to be credited to the account.

:50K: Customer

This field contains the details of the ordering party (legal entity, individual, bank). The field is used in messages MT103, MT103+ with options “A”, “K”, “F”. Depending on the option, the filling changes from bank to bank.

:59: Beneficiary

This field specifies the details of the beneficiary client in whose favor the payment is made:

– client’s account number at the beneficiary bank (When transferring funds in favor of bank clients from countries supporting the EU Directive on mandatory IBAN indication, specifying the account number in IBAN format is mandatory (indicated without any separators))

– client’s name;

– address (if available);

– city, country.

:70: Payment Information

This field, sized 4 lines of 35 characters each, specifies payment information, including: purpose of the transfer (payment of a contract/agreement/training/travel voucher, financial assistance, etc.), number and date of the contract/agreement, commercial documents, description of performed works/services provided, goods, etc.

:71A: Details of Charges

Specifies who bears the charges when making the transfer. One of the possible options is indicated:

– OUR – the total amount of charges of the client’s bank, as well as charges of other banks involved in the payment process, are paid by the payer client (field 50A,K or F).

In this case, there is a possibility that funds may not be fully credited to the beneficiary.

– SHA – the total amount of charges of the client’s bank is paid by the payer client (field 50A,K or F), and charges of other banks involved in the payment process are deducted from the transfer amount;

– BEN – the total amount of charges of the client’s bank, as well as charges of other banks involved in the payment process, are deducted from the transfer amount specified in field 33B.

Now, having a valid message body, if we had access to the SWIFT Alliance Access operator, we could insert this message into the raw message creation interface and make the transfer. All that remains is to add the BIC codes of the sender and receiver and choose the bank departments from and to where.

But it’s not enough to study the message body itself (you must remember that all fields must be filled STRICTLY according to the instructions, which most scammers ignore when they draw up payment orders, violating elementary document filling rules). Therefore, we’ll move on to the next part and analyze the complete message, not just its body.