'Project Mayhem' Hacks Accounting Software

Researchers today unleashed proof-of-concept code that would allow an attacker to basically write himself a check from the victim organization's account.

The Python-based tool is just one example of the type of advanced financial fraud that could be perpetrated against accounting applications and databases, according to SecureState researchers, who at Black Hat Abu Dhabi demonstrated their tool and findings on threats to accounting software. They focused their efforts on Microsoft's Dynamics Great Plains application, but they say the same types of attacks could also be aimed at other accounting packages.

No vulnerabilities were discovered or exploited in the Microsoft product, either: The attacks demonstrate how cybercriminals or malicious insiders could easily have their way with an organization's financial systems and do some serious harm. "We're not exposing any kind of vulnerabilities in Microsoft Dynamics Great Plains. What makes this interesting is that it basically uses the technique we see a lot in malware that does injection and hooking," says Tom Eston, manager of SecureState's penetration testing team, one of the researchers behind the so-called Project Mayhem research.

The Mayhem script detects that the Microsoft software is running, and creates a backdoor for the attacker to remotely make SQL queries and commit all types of financial fraud. "It doesn't even need to install a traditional piece of [Trojan] backdoor malware like" most financial fraud malware does today, says Eston, who demo'ed the tool today with research partner Brett Kimmell, manager of the risk management group at SecureState.

"We compare it with a banking Trojan that hijacks ACH and wire transfers without the user's knowledge, but this time we're looking at the accounting system instead of the online banking session," Eston says.

Microsoft's accounting program isn't the only potential victim here. "You could take this same concept and apply it to MAS 90, Peachtree, Oracle, and even SAP," Eston says.

The research is a rare drill-down into the risks of attackers and insiders performing damaging financial fraud via the victim's own financial systems, but it's not the first look at ERP application security. Two years ago at Black Hat Europe, researchers at Onapsis demonstrated how an attacker could inject rootkits and backdoors into an SAP ERP system to intercept automated payments, for example.

"As we always pointed out, this is a common problem among all ERP systems -- traditional security controls have become obsolete to protect against the modern cyberthreats that affect these business-critical platforms," says Mariano Nunez, CEO of Onapsis. "From Onapsis, we have been raising awareness on how SAP and Oracle ERPs, such as JD Edwards and Siebel, are also prone to these attacks and how companies can protect themselves."

[Black Hat Europe researcher demonstrates techniques for inserting 'backdoors' into popular enterprise resource planning apps that aren't properly secured. See SAP, Other ERP Applications At Risk Of Targeted Attacks.]

Project Mayhem goes the heart of financial best practices. Even with all of the defense-in-depth best practices, this type of attack could succeed, the researchers say. "All it takes is for one of those controls to fail, and the accounting system can be compromised with fraud," Eston says. "This highlights that back-end controls in accounting systems ... and what the controller or CFO is doing in account reconciliation is even more important that just trying to stop an attacker from getting the machine and compromising credentials."

Unlike banking Trojans, the script used in Mayhem doesn't require admin rights or downloading new malware. It's basically old-school hacking: "It just opens up that channel into database queries to make modifications," he says.

An attacker would need to have some accounting software knowledge to pull off these attacks, however, such as knowing server naming conventions and database tables for specific software systems running in the targeted organization.

Eston and Kimmell say their project required a team effort of various expertise sets: Eston is a penetration tester, Kimmell, a former CFO familiar with the Microsoft software, and SecureState colleague and coder Spencer McIntyre.

"Anybody who gets hold of this code would need somebody with an accounting background and who knows GP Dynamics," Kimmell says.

"The PoC we've put together adds a vendor record to GP" so that the attacker could pay himself from the victim organization's accounts payable, Eston says. "It just adds their record as a 'vendor' ... We're hoping this summer to have a second, more powerful version of the PoC."

An attacker could employ this PoC either via malware or a phishing attack to steal user credentials. Or he could also directly attack the database server, the researchers say.

What can organizations do today to protect themselves since there's no "patch?"

Next Page: Protecting your accounting system