Hacking maritime IFTFCC messaging for invoice fraud

Stealing money by diverting shipping cargo payments

If you haven’t read our other blogs on UN/EDIFACT message manipulation, they would be a good place to start. This piece is about extending that work and looking at the financial messaging exchanged between ports, shipping lines, transport companies and terminals.

EDIFACT supports the ability to communicate electronic invoicing details. Payments are also possible, but usually routed through 3rd party systems.

We know that conventional invoice fraud through scam email is highly successful, so could similar techniques be used to exploit a lack of message and payment detail validation in cargo shipping?

Exploiting IFTFCC

IFTFCC comes from “International Forwarding and Transport message – Freight Costs and other Charges” and is a message typically sent from a shipping company to the receiver (or at least whoever is paying for the shipment).

Its format is set by standards defined by UN/EDIFACT – these documents are not easy reading!

INVOIC is another electronic invoicing messaging type and is much less well defined than IFTFCC. There’s no point covering INVOIC here, as one simply has to work out the messaging format used by each company and tamper with it.

However, IFTFCC has specific formats that are very interesting to those trying to steal money.

The message

Various compulsory and optional fields are set for this message format. Here’s an overview of the structure. There are related sample messages here if you want to go through the detail.

Most of the message covers information about currencies, values, tax etc.

One could cause chaos by switching around values so that invoices weren’t paid correctly. Organisations are put on ‘credit hold’ unnecessarily as they paid the wrong amount unintentionally and the whole shipping system gums up a little.

However, look at Group 11: deep in the message is the goldmine: ‘FII’:

FII stands for Financial Institution Information. Interesting!

FII is a component of message segment group 11: 0450 NAD–FII–LOC-SG12-SG13

0460 NAD: Name and address

Covering party’s name, address and function, such as message sender, message receiver, payee, payer, ordering party.

0470 FII: Financial institution information

A segment identifying the financial institution such as a bank and account numbers for the payee only

0480 LOC: Place/location identification

A segment to indicate the place of registry (for payee).

Dig deeper and we find everything fraudsters need

Here in the FII group C078 is what we’re looking for; account details:

Elements 3192 & 3194 contain it. Manipulate this data and the payment is misrouted – the consignee pays the wrong account and the funds are stolen.

FINANCIAL INSTITUTION INFORMATION

Bill of Lading

There should however be a cross-check that limits the ability to carry out fraud. Hopefully, the shipping company and consignee will ensure that the FII details match the Bill of Lading – this is effectively a contract specifying who/what/where/how much etc – everything involved in the billing and shipping process.

However, how many times have you seen security breaches as a result of assumptions made by various parties about security? Who double checked, or did they just trust the data in the system?

Consider a regular invoice fraud email: the accounts payable department at the consignee receives a change of banking details letter. They change the bank details, the payment is misrouted and stolen.

It was assumed that the email was genuine. No-one checked the validity of the change request. If no-one checks that the EDI message involving FII and account detail is genuine, then payments can be stolen.

Advice

I can’t determine how widely banking information is transmitted over EDI. From various messages I’ve seen, it is clear that some banking information IS transmitted though.

So often, users make assumptions about security: ‘I thought EDI messages were secure’ or similar, with no knowledge of message transport security, authentication and integrity processes.

Irrespective, any user of EDI messaging for anything financial, maritime or not, would do well to check that their systems are secured from message manipulation and related invoice fraud.