Attacks against massive and proprietary enterprise accounting systems, in particular financial software such as SAP and Oracle, have been few and far between. That changed at this week’s Black Hat Abu Dhabi conference where a pair of researchers presented proof-of-concept code that could change the dynamic of the financially motivated attack landscape.
The attack, dubbed Project Mayhem, could enable an attacker to divert funds from a company’s accounting and financial systems without immediate detection. In addition to code, the attacker would be relying on the fact that midsized companies in particular, do not have complete control or visibility into financial processes or individual transactions, and are likely to miss fraud at first glance.
“Getting caught depends on the skills and resources available and whether an audit is performed or not,” wrote Tom Eston and Brett Kimmel of SecureState in a white paper explaining Project Mayhem in detail.
Eston and Kimmel’s presentation at Black Hat focused on Microsoft Dynamics Great Plains software, in particular targeting Dynamics’ SQL database, SQL server, or hijacking an account via a process injection attack. Microsoft Dynamics is used primarily in midsized companies. The duo said their motivation in developing this attack was to help penetration testers efforts in examining the defenses of these systems. SecureState is a consultancy provide security services such as pen-testing.
“If an attacker can control and manipulate the accounting system of the company to commit mass systems fraud, changing or manipulating financial data is just the beginning. As professional penetration testers, we must demonstrate more advanced attacks to show real impact to the business,” said Eston.
The key to the attack is to stealthily modify entries in the accounting system to commit fraud, i.e., transfer funds to an outside account. They began by doing some reconnaissance online to learn the names and structures of the Dynamics GP software’s database tables, as well as other pertinent identifiers in the tables. Knowing this helps an attacker target a particular segment of the database, the paper said.
An attacker could also hijack accounts by targeting GP users, again by doing reconnaissance online in social networks or searches in LinkedIn profiles, and then crafting a spear phishing attack that would convince the target to either visit a site hosting the Project Mayhem malware, or open an attachment infected with the code. The malware is then used to pivot internally to target GP processes.
The proof-of-concept code, developed by SecureState researcher Spencer McIntyre, uses function hooking and library injection to exploit the application’s front end.
“The goal is for the malware to open a channel back to a malicious attacker and allow them to issue commands specific to GP through the Dynamics GUI front end,” the white paper said. “The proof of concept code needs to be injected at run time but well known patching techniques could be employed to have the necessary components loaded automatically at run time.”
The malware hooks in to key locations, the paper said, and intercepts function calls, in particular those to the ODBC32 library; the malware creates function calls that interact with the database, a valid copy of legitimate handles that can inject malicious SQL commands as a legitimate user. Using a backdoor to the attacker’s server, SQL commands can be issued without detection and without the need for a password.
Once inside and manipulating the system, an attacker could manipulate existing vendor records forcing the system to remit payments to the attacker or a mule, rather than a vendor, or create new vendor entries, new manual check entries, increase customer credit limits, modify accounting records, create negative customer balances that force automated refunds, or simply steal credit card data, customer data or private financial records.
Such an attack against a financial system puts money and customer records at risk, but implicates compliance requirements, company reputation and harms customer relationships.
“Even with proper bank reconciliation, funds can be diverted without immediate detection. Fraud attacks like the ones described in our talk and whitepaper could last for months or years. Uncovering a fraud depends on the skills and resources available and whether an audit is performed or not,” said Kimmell.
