If you read this series, you already know enough about SAP ERP Security to discover a real impact of having insecure SAP implementation.

Recently, Crowd Research Partners have released ERP Cybersecurity Survey 2017, which was conducted across almost 2000 respondents of different roles from various industries. According to this research, 89% of security professionals predict that the number of attacks on SAP systems will increase. Moreover, the average damage of an SAP security breach is estimated at $5 million. It’s unthinkable, isn’t it?

Take a glance at the statistics:

The average ERP security breach cost

Then what about real examples?

If you still do not believe that SAP is a juicy target for hackers and suppose there were no incidents concerning this area, sorry, but I have to disappoint you. In fact, they were.

I’ll tell you about 5 most notorious ones happened the last 5 years.

SAP Security Incident in Geek finance ministry

The earliest infamous cyber-attack on SAP systems occurred on October 30, 2012, when perpetrators from Anonymous allegedly leaked the confidential files and credentials belonging to Greek Ministry of Finance. The document from AnonPaste declares that the motives behind the attack was protesting against the Greek economic conditions, which was becoming worse. The group posted a compressed file with credentials purportedly valid and said they had accessed IBM servers and possessed an SAP 0-day exploit. This attack wasn’t approved or declined by any authority. Whether or not the attack was actually performed, the incident indicates that hackers are interested in exploiting SAP systems.

Lessons learned from Greece finance ministry attack

Such attacks should be viewed thoroughly since all types of sensitive information are kept in SAP systems (e.g., credit card data, clients and partners lists, trade secrets, and bank account numbers). Find the examples of espionage attacks on SAP and don’t underestimate their severity.

SAP Malware Incident

A noteworthy SAP incident took place in November 2013, when a new Trojan program variant addressing online banking accounts appeared to contain code to discover if the infected computers had SAP client applications installed. It implied that malicious actors might target SAP systems later on.

To net information, the program applied a traffic analyzer, a system monitoring web banking activities, and a screen grabber. Sending the data obtained from window forms and secure workflow systems to the hackers’ server was considered an objective. The Trojan revealed that the workstation had an SAP client installed after having accessed the infected workstation, therefore, it gained access to the SAP server. The malicious software could make screenshots of logins into the SAP system, collect sensitive system data, and steal passwords input during login. The gathered information allows carrying out malicious actions on an SAP server. Moreover, perpetrators could sell the information on the black market.

Lessons learned from SAP Malware

Here comes the second lesson: the secure perimeter is not a panacea. In the new cloud and mobile devices realm, a company’s perimeter turned out to be more transparent and as a result less secure. The firewall was a sufficient measure until recently. You have to accept the idea that your perimeter is insecure by default. There are other ways for hackers to break into SAP systems, besides Trojan programs, for instance, an attack on SAP Internet-based services (e.g., SAP Portal, SAP CRM or SAP SRM) that either fully or partially available for remote access. Vulnerabilities in these systems may be used to get access to company’s internal infrastructure. Another way is to exploit vulnerable SAProuter installations or other administrative SAP services exposed to the Internet. Scan your SAP systems for unnecessary services and configure strict access control to protect them.

SAP Security Incident with South West One

November was notable for yet another curious incident.
The review of South West One AP IT Controls (a company, which runs IT and other services for Commercial and Government companies) revealed that auditors identified severe security issues. Weaknesses in SAP security controls would permit non-police staff members to access the force’s administrative database. The three authorities shared an SAP database, and users with administrative rights were able to directly access the database or OS. For administrators, it may be the simplest implementation option but is definitely insecure one. “It is likely to be the lowest cost model because of this,” says Grant Thornton. “However, it is the least secure method to manage legal entities that have no relation to each other.”

Lessons learned from South West One audit

The lesson is the following: access separation between systems.
Separating data could be achieved through several methods. It’s not recommended to store information about different organizations on a single application server. Furthermore, there is an additional layer of data separation, so-called Production, Test, and Development system. There should be at least 3 systems with strict access control inside one company. Even admins should not have any access to critical commands in SAP such as access to OS. It’s recommended that you disable the transactions at all.

SAP Security Incident with NVIDIA

What else was remarkable in the world of SAP hacks?
In January 2014, NVIDIA customer service website was allegedly attacked. A man who found the drawback was from China. Finger, as he called himself, said that notified NVIDIA of the issue on November 21, 2013 (almost simultaneously with the 3 previous cyber-attacks happened), however, did not receive any reply from the company and decided to draw attention to this issue.

The description was posted on the Chinese vulnerability forum WooYun.org on January 5, 2014, and reposted on Fulldisclosure. The status of the bug was “unable to contact the vendor or actively neglected by the vendor.” 3 years prior to the incident the NetWeaver loophole was patched by SAP; nonetheless, NVIDIA didn’t implement the fix. The customer service website was taken offline for a two-week period for investigation on January 8, 2014, and the company never commented its results. Although data was not supposedly leaked, the fact of Customer Care Portal shutdown affected the company image.

Lessons learned from NVIDIA attack

The new lesson: Patch Management is essential. As dramatic as this may be, not only NVIDIA didn’t patch the issues. Numerous companies consider patching process to be time-consuming and expensive thus don’t implement SAP Security Notes. SAP released almost 4000 SAP Security notes
during the period when the hacking attack could happen to close SAP vulnerabilities, most of which can be exploited only with access to the corporate network. However, some of them are remotely exploitable over the web. Therefore, it’s recommended to update them in due time if a company uses web-based systems. Also, keep in mind that SAP Systems are very complex having thousands of different web services (Portal, CRM, SRM, etc.), and applications with unauthorized access, as well as multiple technologies (i.e. JSP, Web Dynpro, BSP, HANA XS applications, Portal iViews). All of them have their own set of security mechanisms. Analyze web services and disable unnecessary ones.

Ethical Hacking Training – Resources (InfoSec)

SAP Security Incident with USIS

Now prepare for a really impressive incident. Compared to it, other attacks are like fairy tales for kids.

It happened on May 11, 2015, and the news about a USIS breach blew up the media. As it was claimed, the attack was waged by China-backed hackers via a vulnerability in SAP software.

USIS used to be the largest commercial provider of background investigations to the federal government. It has more than 5,700 employees providing services in all 50 states of the U.S. territories and overseas.

In 2013, USIS was hacked through an exploit in an SAP system controlled by a third party. It ended up compromising of more than 27,000 employees.

As the result of this breach, USIS lost the contract with OPM as its main client as well as $3 billion and cut 2500 jobs (almost half of all the stuff). The owner of USIS filed for bankruptcy. Imagine, just one vulnerability in an SAP system can lead to such dire consequences.

Lessons learned from USIS attack

What lessons can we learn from this unfortunate experience? We should care about the security of all connections between business-critical applications both inside the company and with third parties. To automate business processes, different SAP modules have to be interconnected. ERPScan’s research discovered an average of 50 connections in a typical SAP system, 30% of which store credentials. Perpetrators will be able to access all the synced systems in case they infiltrate the weakest SAP module. Therefore, all kinds of connections between SAP systems should be reviewed.

This is how the connection map looks like for a small landscape. Imagine how complex it can be.

The typical connection called RFC is not the only possible way. There are at least 20 other options how different SAP systems can interact with each other: shared passwords, trust connections, industry-specific applications (e.g., xMII or Plant Connectivity) that can be used to get unauthorized access from one SAP system to another.

So, what about the USIS incident? The most remarkable fact revealed in June 2015 is that it may hit other government agencies – Customs and Border Protection, US Capitol Police and even OPM. The reason for that is a single vulnerability in SAP System of a contractor, which might cause espionage, sabotage, and fraud. You should pay attention to the interconnections and remember that a single insecure component may ruin the whole business.


As usual, there are some sources where you can find the detailed information about attacks we discussed.