SAP password hash hacking Part V: optimizing the attack speed

This blog series will explain the process of hacking SAP password hashes: also know as SAP password hacking. The process of hacking will be explained and appropriate countermeasures will be explained.

In this fifth blog we will focus on optimizing the speed of attack. The preventive measures will focus on reducing the attack speed.

For the first blog on attacking the SAP BCODE hash click here.

For the second blog on attacking the SAP PASSCODE has click here.

For the third blog on attacking the SAP PWDSALTEDHASH has click here.

For the fourth blog on advanced topics, like the rule based attack, click here.

For more on extended word lists, click here.

Questions that will be answered in this blog are:

  • How to optimize the attack speed?
  • How to optimize getting hashes converted into real passwords?

Optimizing the attack

First check if you can get hold of PASSCODE or preferably BCODE hashes. These ones are 10 to 20 times faster to hack than PWDSALTEDHASH codes.

Assuming the administrators have done their work and only PWDSALTEDHASH remains, there are still options to speed up the attack.

Get faster graphical card(s)

Don’t do password hacking on a laptop. The graphical card in any laptop is simply too slow. Use a gaming specification graphical card or cards (cost range is about 300 to 500 dollar or Euro per card).

Preparation of the attack

First thing to do is to get the password rules. Most common is 1 letter, 1 digit, 1 special and minimum length of 8. But differences occur. If for example minimum length is 10, you can adjust your dictionaries to remove all small words that will not comply.

Check the language: use the webster dictionary for English in all cases, but based on language of the company, you must use German, French, Spanish, Italian, Dutch, etc dictionaries as well.

If possible filter out high potential targets from you list. It is best to have a high value administrator or CEO, then a warehouse person who can do simple movements and write time.

Sequence of attacks

Start first with your library of most frequently used passwords. Maybe there is already a hit.

You will be surprised that about 1% will hit.

Second run is with a list of company, product and department names. If you want to target company called TARGET with product name PRODUCT, make a special file with names like:

Target2021!

Product2021!

Use the password rulebooks to generate as many variations as possible (examples are T@rget2021, Pr0duct2021!).

You will be surprised that about another 1% will hit. Who is using these simple to guess passwords? More people than you think!

Third run should be dictionary run with rulebook. Start with English and primary language of the company. Most successful Rule is word plus digit plus special.

You will be surprised that about another 1 to 3% will hit.

Pending on the speed and sizes the rulebook is a very good one to run for a longer time (consider 1 week constantly running this).

Fourth run should be a keyboard walk rulebook. The keyboard walk contains passwords like QWERtyui1234%^&*, or 1qaz@WSX (walk on keyboard…).

You will be surprised that about another 1% will hit.

Re-using the output file to generate new attack: fingerprint attack

When your first attacks are done, there is one final surprisingly successful last attack possible. For this you take your file with all the passwords you have already cracked.

These passwords you now cut into 2. Example Target2021! is cut into:

T and arget2021!

Ta and rget2021!

….

Target2021 and !

And the word itself Target2021!

Now you have 2 files. Use these into a combinator attack mode (see hashcat wiki for the exact syntax to use).

This procedure is called a fingerprint attack.

This might give surprising results like TargetProduct2021!

This attack will bring a surprising high number of hits. The better the first passwords you have cracked, the better the result here. Save this attack till last, since it can be a very lengthy one, and a lot of duplication with the previous attacks can happen.

Strengthening password technical strength

The ABAP password can be made more strong by technical means, by increasing the hash salt size. This will take longer time to crack. OSS notes:

Read more in this dedicated blog on password hash strengthening.

BI queue deletion

During a SPAM import or during application of a TCI OSS note using SPAM, you can get errors due to BI queues. This blog will explain how to delete these queues.

Questions that will be answered in this blog are:

  • How to clean up the BI queues in case SPAM or TCI note is being blocked by it?

qRFC clean up

First start in transaction SMQ1 to delete the MCEX BI outbound queues:

SMQ1 BI outbound queues

Select all queues and press the delete button.

More blocks

If it is still blocking run program RMCEXCHK:

RMCEXCHK result

Look for the application number(s) that is blocking. In this example 04. For V3 updates read 2886816 – Supplement to Note 652310 & 67014 & 1083709 about error ‘due to open V3 proc not changed’.

Now start transaction LBWG to delete the setup for this application:

LBWG transaction

Details behind LBWG are explained in OSS note 1752439 – Explanation of transaction LBWG.

FIORI search setup

FIORI search is a very powerful tool for the end users. It enables a google like search on the business data.

Questions that will be answered in this blog are:

  • How does FIORI search work from the end user perspective?
  • How to set up FIORI search?
  • How to authorize search data?

FIORI search from end user perspective

From the end user perspective: open the search glass and key anything. Just like in Google:

Now wait for the search engine to give results:

Now you can select a record, or select a related app (with the … you get more options):

Set up of FIORI search

In the FIORI launchpad configuration parameters (see SAP help) make sure that the enableSearch is set to true. Otherwise the search icon does not appear.

In case you run a FIORI hub, make sure to setup the web dispatcher rules properly to the backend (see SAP help).

Next step is to activate the search models and the backend (see blog). The search setup for FIORI launchpad is fully dependent on the backend search.

Some apps use related links. For these related links, the related FIORI app or FIORI factsheet must be activated. See this blog on how to fast activate complete groups of FIORI apps.

FIORI search authorizations

FIORI search relies on the authorizations of the end user. First make sure that the general authorization for the search is active in this IMG node:

The setting Model Authorization must be set to Check:

In the search cockpit (transaction ESH_COCKPIT), make sure that the user authorizations are indexed. In case of doubt run it under the Actions button, and select Index User Authority:

If one end user gets results and the other one does not get the same result: the main reason might be difference in authorizations.

Useful OSS notes

For specific use cases the following OSS notes might be relevant:

Setting up trusted RFC connection

This blog will explain how to set up trusted RFC connection.

Questions that will be answered are:

  • How to setup a trusted RFC connection?
  • How to edit generated RFC in SM59 using the TOGL function?

     

Setting up trusted RFC

Start in transaction SM59 to create an RFC to the destination system:

Trusted RFC with user name

Fill out your own user ID first. Make sure your user ID is existing in the destination system and is having sufficient S_RFCACL rights in the destination system. See OSS note 128447 – Trusted/trusting systems for the details.

Test the connection including the remote logon.

If that is ok, start transaction SMT1 and start the roadmap for setting up the trusted connection:

SMT1 enter destination

Enter the destination and finish the roadmap:

SMT1 complete roadmap

Complete the roadmap. 

Now return to SM59 for the destination and remove the user ID, tick the box “Current User” and switch the Trust Relationship to Yes:

Trusted RFC with trust setting

Now test again. All should work.

Background SAP wiki can be found in this link.

Background notes:

Testing trusted RFC

A trusted RFC can be tested via the Remote Logon button:

If you now can jump from the current system to the connected system without password prompt: then all is fine.

If it is not working: check in the target system in ST22 for a remote logon failure dump. Must likely your user does not have sufficient rights in the target system.

RFC security settings

For checking RFC security settings, read this dedicated blog.

RFC Access Control List

In the newer S4HANA versions, you can switch from an authorization check towards a full Access Control List setup. Use transaction SMTACL and select the trust connection:

Switch here to Access Control List Check.

RFC hacking

Be aware that RFC’s and especially trusted RFC’s can be misused for hacking. Read this dedicated blog on how, and how to protect.

Checking which systems you trust

With transaction SMT2 you can check which systems have a trusted system setup towards the system you are currently logged in to.

Editing trusted connections

Trusted connections are generated. In case of emergency you might need to edit this, in the command bar enter keyword TOGL to go to SM59 edit mode:

See note 3212943 – How to edit the settings of unchangeable RFC destinations.

Trusted systems and installation number changes

If you have trusted systems and want to change an installation number of one of the systems, carefully read this OSS note: 2849941 – SMT1/SMT2 configuration after SID or installation number change.

Issues with trust certificates

In exceptional cases you might face issues with cache refresh of replaced certificates. See OSS note 2947038 – Error SOAP:1033 CheckPSE occurs in STRUST/STRUSTSSO2. Solution is to run program SRT_CFG_CLEAR_DESIGNTIME_CACHE.

Trusted RFC security note 3157268

Unfortunately SAP released security note 3157268 – How-To-Guide: Migration of Trusted/Trusting Relationships. Along with the FAQ note 3281854 – FAQ for Security Note 3089413. If you did not migrate your existing trusted RFC’s to the new setup, do it fast within reasonable time (which includes proper testing).

After migration is done, or when you have a new setup, make sure you have set parameter rfc/allowoldticket4tt to the value no.