Compromise of SWIFT and Payment Transfer

Used Tools

Remmina

Windows Remote Desktop

Mimikatz

Summary

Our initial project goal was to place a fraudulent payment and have it captured and approved. So we look into any existing groups referring to the roles and find several users. On enumerating the WORK machine and the JMP machine, we find notes, stating that the passwords of the captures are just replicated from the AD to the capturers account. The approvers are not replicated.

From the JMP machine, we are able to reach out to the portal of the swift transaction backend.

Starting the process of proofing the compromise of the SWIFT Payment transfer at 10.200.XXX.250 gives us the necessary user accounts.

We are able to retrieve the hashes of the users from each role on the JMP machine running Mimikatz there. Several passwords have not been changed, and are similar. Cracking the hashes reveals the necessary credentials.

Logging in as an approver on the JMP machine, we are able to check out the password manager integrated with Google Chrome, secured by the standard credentials of the user we already cracked.

We log in as our source user to initial the fraudulent transaction and enter the pin we received via mail.

Next, we prove our access as capturer by RDP into the JMP machine and log in there as the user within the group of capturers of the same credentials. We capture the provided example transaction and our fraudulent transaction.

Finally, we prove our access as an approver by RDP into the JMP machine as an approver user and log in to the portal with the credentials we found in the Google Chrome password vault. There we approve the provided example transaction and our fraudulent transaction.

Recap of the Project Goal

Project Goal

The purpose of this assessment is to evaluate whether the corporate division can be compromised and, if so, determine if it could compromise the bank division. A simulated fraudulent money transfer must be performed to fully demonstrate the compromise.

To do this safely, TheReserve will create two new core banking accounts for you. You will need to demonstrate that it's possible to transfer funds between these two accounts. The only way this is possible is by gaining access to SWIFT, the core backend banking system.

Note: SWIFT (Society for Worldwide Interbank Financial Telecommunications) is the actual system that is used by banks for backend transfers. In this assessment, a core backend system has been created. However, for security reasons, intentional inaccuracies have been introduced into this process. If you wish to learn more about actual SWIFT and its security, feel free to go do some research! To put it in other words, the information that follows here has been made up.

To help you understand the project goal, the government of Trimento has shared some information about the SWIFT backend system. SWIFT runs in an isolated secure environment with restricted access. While the word impossible should not be used lightly, the likelihood of the compromise of the actual hosting infrastructure is so slim that it is fair to say that it is impossible to compromise this infrastructure.

However, the SWIFT backend exposes an internal web application at http://swift.bank.thereserve.loc/, which TheReserve uses to facilitate transfers. The government has provided a general process for transfers. To transfer funds:

1. A customer makes a request that funds should be transferred and receives a transfer code.

2. The customer contacts the bank and provides this transfer code.

3. An employee with the capturer role authenticates to the SWIFT application and captures the transfer.

4. An employee with the approver role reviews the transfer details and, if verified, approves the transfer. This has to be performed from a jump host.

5. Once approval for the transfer is received by the SWIFT network, the transfer is facilitated and the customer is notified.

Separation of duties is performed to ensure that no single employee can both capture and approve the same transfer.

Investigation

As the rootdc user on the bankdc machine we check out all groups represented there.

We have a group of Payment Approvers and Payment Capturers.

Checking out the members of Payment Approvers we have a.holt, a.turner, r.davis and s.kemp.

Next we check out the members of Payment Capturers. There we have a.barker, c.young, g.watson, s.harding and t.buckley.

On the rootdc we check the Users directory of the machine work. There we have to user a.barker.

Enumerating the users folder on work1 we find a note that states that the AD password is replicated to the swift application.

Next, on the rootdc we check the Users directory of the machine Jmp. There we have the users a.holt and a.turner.

Like with a.barker we check the documents folder of the users at Jmp and find a similar note with a different content. This time it states that the AD credentials won’t be replicated. So in this case we have to figure out another way to get on the credentials of approver of the swift application.

The next step is to retrieve the credentials of the capturers and approvers. This allows us, at least for the capturer to log in to the swift application as a capturer and capture our fraudulent transaction and the transaction to prove the access as a capturer. But on the corpdc we won’t have any luck.

So we move further and RDP into the Jmp machine of the bank domain as our user 0xb0b which we created on the bankdc.

From there, we deactivate the AV through an elevated PowerShell with

set-mppreference -disablerealtimemonitoring $true

Now we just copy our mimikatz.exe from the corpdc to the Jmp machine through RDP, by activating shared folders.

Running Mimikatz lsadump::dcsync /users:namk\a.barker to retrieve its hash to crack it, to be able to log in as that user to the Jmp machine and login to the swift application.

We repeat that process for the user a.holt

Cracking the hash for user a.holt was without success. Mode 1000 was used for the NTLM hash.

And repeat the process for the user a.turner.

Flag-17: Access to SWIFT application

Both users a.barker and a.turner share the same hash. Cracking this reveals that they might not have changed their passwords and shared the same password Password! As with user svcBackups, just rockyou.txt was used for the wordlist. For this password, the created password file won’t work, because the rule w,as too weak, and created a password list with the base appending a digit and a special character.

fbdcd5041c96ddbd82224270b57f11fc

a.barker:Password!

a.turner:Password!

Flag approval for writeup used to recreate the screenshot of creating a new transaction. The other screenshots are from the initial compromise. So IDs and IPs will differ.

So now that we have the credentials of the capturers and approvers we are partly able to carry out our fraudulent transaction. Due to the fact that we have access to the Jmp machine and still miss the credentials of an approver.

So to initiate the process for the fraudulent transaction we need two user accounts with credits provided by our client. Those we get by accessing 10.200.XXX.250 and submitting our proof of compromise of the SWIFT Web Access.

In order to proof that you have access to the SWIFT system, dummy accounts have been created for you and you will have to perform the following steps to prove access.

Account Details: Source Email: [e-mail] Source Password: xwT6P-dYn2Unag Source AccountID: 6473d523c4f9af7c44865574 Source Funds: $ 10 000 000

Destination Email: [e-mail] Destination Password: fF0eo0UwGKRyog Destination AccountID: 6473d525c4f9af7c44865575 Destination Funds: $ 10

From the recap of the project goal we know the application is available at http://swift.bank.thereserve.loc/. We are able to access the site from the Jmp machine.

Entering our credentials provided by the challenge we are able to log in.

Flag-20: Simulated fraudulent transfer made Part 1

Via Make a Transaction! we fill out the necessary information with the sender and receiver id and the required amount of 10.000.000 and submit our request.

Successfully submitted our transaction. Next, we have to enter the pin we received after submitting our transaction via email.

The following screenshots were from the first approach and refer to different sender and receiver ids as well as different pins and IPs.

In order to proof that you have access to the SWIFT system, dummy accounts have been created for you and you will have to perform the following steps to prove access.

Account Details: Source Email: [e-mail] Source Password: hC3c3xpGiWe0ig Source AccountID: 646a0b117fc0891499e7bc5b Source Funds: $ 10 000 000

Destination Email: [e-mail] Destination Password: Tn9sdbbQ2xK26g Destination AccountID: 646a0b877fc089169cbe80c4 Destination Funds: $ 10

Using these details, perform the following steps:

Go to the SWIFT web application

Navigate to the Make a Transaction page

Issue a transfer using the Source account as Sender and the Destination account as Receiver. You will have to use the corresponding account IDs.

Issue the transfer for the full 10 million dollars

Once completed, request verification of your transaction here (No need to check your email once the transfer has been created).

Once you have performed the steps of building your transaction, please enter Y to verify your access. If you wish to fully exit verification and try again please, please enter X. If you wish to remove this verification attempt, please enter Z Ready to verify? [Y/X/Z]:

We submit the pin to make our transaction complete.

Flag-18: Access to SWIFT application as capturer

To prove that we have access as a capturer we have to login as one of those to the application and capture a transaction provided by 10.200.XXX.250. At the same time, we can capture our fraudulent transaction of 10.000.000. First, we tried a.barker but this user did not work in the first approach. I don’t know if it was possible to change the password for the application and someone else did but we are able to login with the same credentials as c.young.

c.young:Password! did work

Next we forward the 1$ example transaction of 10.200.XXX.250

And do the same with our 10.000.000 fraudulent transaction.

Flag-20: Simulated fraudulent transfer made Part 2

Capture fraudulent transaction.

Flag-19: Access to SWIFT application as approver

The last step is to approve the example transaction of 10.200.XXX.250 and our fraudulent transaction. But we are missing the credentials of an approver of the application. To investigate further we log in using a.turners credentials on the Jmp machine and check out the stored password in google chrome.

At the password manager in google chrome we see that there is a password hidden.

Using the same credentials of the AD account a.turner:Password! we are able to unlock the password manager and get the credentials for the application.

[e-mail]:reallycantguessthis1@

With those we log in to the application.

Head right to the transaction and approve the example transaction of 10.200.XXX.250.

Flag-20: Simulated fraudulent transfer made Part 3

At the same time, we approve our fraudulent transaction of 10.000.000 and reached the targeted project goal.