…you will get burned. That is pretty much how you could sum up the lesson to be drawn from the scenario we are going to describe below. If you are aware of the risk of using weak password hashes and do nothing, you shouldn’t be surprised by the damage that can result. The following story illustrates just how quickly things can unfold.
It is the one morning in mid-August 2017, when Pjotr Melnikov turns off his alarm clock, then gets up and puts the coffee on, just as he does every morning. The next action is another well-practiced one that he has performed many times before: reaching out for the remote control and switching on the TV. He has soon tuned into the morning news and leaves it on in the background, like every morning. Pjotr was born in Moscow, but has been working in Germany for over 15 years. Now, however, his future hangs in the balance, because the company for which he has worked for so many years is threatened with insolvency. Suddenly, something makes him sit up and pay attention. A story about his company is being reported in the morning news. The report makes him stunned and angry at the same time.
His former boss, whom he had never even met, is going to be paid his salary plus bonuses and compensation for another 4 years.
It is at this point that Pjotr makes a decision and calls his long-time friend in Minsk. Together they draw up a plan that will soon be put into practice. Pjotr drives to work a few days after making the phone call, knowing that his days at the company are numbered. The end is apparently near and no-one can tell him what his future is going to be after that. It is the perfect opportunity for him to let his anger and disappointment off the leash.
After the security check at the entrance to the company premises, he makes a small detour into the coffee room to hear the latest rumors from his colleagues. So far, nothing new. The feeling of uncertainty has long since spread to all his colleagues. So Pjotr carries on and then stops for a moment, deep in thought, in front of the sign on his door:
Pjotr Melnikov
Accounting Department
SAP Accounting
Today is the day the plan is to be put into practice. As usual, he opens the logon pad of SAP and logs on to SAP. Previous projects required an authorization for the SE16 transaction, which was never withdrawn from him and this is what Pjotr is going to make use of today. He has always had a certain affinity for IT and, after talking to his friend in Minsk, he has learned a lot. He knows from the phone call that all SAP users, including the hashed passwords, are in the USR02 table. However, he doesn’t just want to crack any old passwords at random. He has a clear goal in mind.
From one of his projects, he can remember the discussion about the application for “SAP_ALL” permissions and the associated risks. At that time, the discussion had even been escalated to the CTO, who was, however, well known to have a pretty short attention span and to grant extensive “SAP_ALL” authorizations very readily. One of the admins then simply had to grit their teeth and go ahead and set the user up.
Using his knowledge and the permissions he had gained in the past, Pjotr had absolutely everything he needed to put into his plan into practice. Consequently, he was only interested in the SAP users with an “SAP_ALL” profile. From the phone call with his friend, he had also learned that the profiles he was looking for can be found in UST04 table (User Management, Permissions). As a loyal reader of the zapliance blog, he also knows about the transaction code “SQVI”, which can be used to join SAP tables.
To facilitate subsequent analysis of the data, he uses additional selection fields, such as the profile name and the code version, based on his previous knowledge, to make sure only users with the “SAP_ALL” profile and password hashes are displayed in the result. What the code version has to do with it and why the table join of the two tables has to be limited to it had immediately become clear to him when reading the Dr. Strangelove blog post.
A few minutes later, the entire list of results was displayed in SAP, so that Pjotr could easily export a list of all the SAP users with an “SAP_ALL” profile, along with the weak password hashes, as an Excel file and send it to his friend in Minsk via end-to-end encrypted Messenger. He did this to make sure that a fraud investigation would be made more difficult afterwards. The friend was already waiting for the list and, as a software developer, knew how to use his experience working with the Amazon AWS Cloud to optimum effect. After a short Google search, he also ended up on zapliance’s blog and followed the instructions for hacking SAP passwords. After successfully setting up HashCat in the Amazon AWS Cloud and uploading the list of password hashes, it was only a matter of time until the first passwords appeared in plain text.
Due to the immense computing power available in the cloud, Pjotr didn’t even have to wait until the end of the day for his friend from Minsk to provide him with three combinations of a username and password.
So what does Pjotr do with the login details next?
Pjotr continues to do his best to ensure that he doesn’t leave any too obvious traces in the SAP system, so that the subsequent investigation will take as long as possible and not be so quick to trace things back to him. From a workshop with zapliance on investigating various findings in zap Audit, he knew about the suppliers with high invoice amounts. Using the hacked login details, and the FK02 transaction, for example, he now simply changes the bank details of a supplier and enters the data of his straw man instead, which he had found through shady contacts. Then it’s just a matter of waiting and drinking his tea until the department transfers one of the most recent invoices to the changed account. No separation of duties and hardly any trace to his user account, except for extracting the password hashes. The company surely has plenty of other important issues on its plate at the moment anyway, so Pjotr will have plenty of time before the fraud is discovered. In the meantime, he’ll be long gone, safe in a foreign country somewhere, where all traces of any flow of funds simply disappear into the sand. You already know how the story ends – Pjotr was never seen again.
