Introduction
There are several ways to steal someone account when it comes to web applications. In this article we will dive into main six of them and show on the living example that even Multi Factor Authentication or very complicated password sometimes is not enough to make ourself safe.
Fundamental types of attacks
When it comes to taking over accounts we can distinguish 2 basic types of attacks:
- User Oriented Attacks (You are the attacker's target)
- System Oriented Attacks (Web Application is the attacker's target)
In the next chapters we will analyze these types and discover 3 techniques under each of them.
User Oriented Attacks
In this type of attack the Victim is completly responsible for being hacked (in opposition to the System Oriented Attacks) due to his/hers lack of awareness or lazy approach when it comes to enforcing security on their accounts.
Password Stealers / Remote Access Trojans Delivery
The first example is concentrated onto manipulating our victim to execute malicious program. Despite many techniques available at the moment we will dive into impersonation of downloading resources from legitimate site.
In the picture below we are able to identify the website which tells us our web browser is outdated and we should proceed to downloading new version.
After clicking the button we are redirected to Google Chrome Main Page (the legit one) and after short time the download starts automatically.
In the downloaded zip file we are able to find Password Stealer which extracts passwords saved in the web browser and sends them to the attacker after its execution.
In this case we saw malware being downloaded from legitimate site. How?
The first step was to create the HTML Page with warning and big button at the center. After that was done we had to redirect the victim to another site (in a new card) using JavaScript.// Open new tab
setTimeout(() => {
window.open("https://www.google.com/chrome/", "_blank", "noopener");
}, 10);Thats where our trick is hidden. First we open a new tab with legitimate Google Chrome website. Then our JavaScript did not complete - We deliberately delayed download execution which triggers after victim sees the other site (See Poc below).
// Trigger a download for a local 7z file in the same folder
setTimeout(() => {
const a = document.createElement("a");
a.href = "./ChromeSetup.7z"; // The file must be in the same folder
a.download = "";
document.body.appendChild(a);
a.click();
a.remove();
btn.textContent = "Download started";
}, 2000);
});The result is simple -> Victim thinks the Google Chrome website triggered the download which is not the case. In reality our malicious website is downloading the file even if the focus in the browser is set to Chrome site.
If you are to take one thing away from this article, please do not store your passwords in the web browser. There are plenty of password managers out there which are a lot safer alternative.
Impersonating legitimate sites with evilginx2
What if I would tell you that sometimes even MFA does not protect ourselfs from the attacks? This is exactly the case with usage of tool known as evilginx2.
Imagine that we encounter the fake o365 somewhere in the internet. If we will try to log in we will move to the application without problems. But there is one small import dentatail.
Despite succesfully logging in we also shared our credentials, MFA code and o365 cookies with an attacker! As you may know when we have session cookie the MFA is not threat to us anymore - we have the session stolen from other user.
But how exactly does it work?
Evilginx2 serves as a proxy between a browser and phished website. That allows man-in-the-middle attack.
Image Source: https://breakdev.org/evilginx-2-next-generation-of-phishing-2fa-tokens/
When victim log in to the web page through our tool we are able to capture session tokens, inject them into our web browser and succesfully hijack the account.
How can we prevent this?
Unfortunately there is not many recommendations but among the most useful there are:
Credentials exposed in data breaches
In today’s interconnected digital landscape, data breaches have become a constant background noise. Despite data breaches being usually caused by System Oriented Attacks I have decided to place this type of attack at the User Oriented Attacks. The reason is simple and straightforward - we are responsible for protection against these types of attacks.
Let's start from the beginning.
Imagine the same user has identical credentials to system A and B.
When one of them (In our case A) is hacked and confidential account information is exposed to internet / listed for sale on darkweb other people from around the world are able to obtain our credetnials and reuse them to other applications in which we have the account.
If we do not use MFA for B application our account can be hijacked by cyber-bad-guy.
How can I tell if my accounts are in danger?
If you want the information linked to your email has been compromised you can visit https://haveibeenpwned.com
Remember, even if your accounts have not been compromised yet you should follow best practises and use different password for each service. If remembering that information is too much for you consider usage of well known and trusted password managers.
System Oriented Attacks
In this type of attack the owner of the system is completly responsible for being hacked (in opposition to the User Oriented Attacks) due to his/hers lack of security testing, employment of unskilled people or neglecting software updates.
OAuth Misconfigurations
We are all familiar with the Log in with Google/Apple button. But what if the site implemented this feature in unsecure manner?
Usually after clicking the OAuth button browser sends the request to web server and the web server redirects us to authorization server with the following three parameters:
Regular flow request to provider.
After that user is forced to log in or just click authorize button if he is already logged in.
Regular flow processing.
When all actions between the user and authorization server are completed user is redirected back to original site with the following two parameters:
REMEMBER! Returned token is one time use only.
The most important thing for us here is the code parameter which can be exchanged for session cookie.
As an attacker we can try to tamper with redirect_uri parameter. If it is possible to make the web server accept our own web server instead of the applications one we can send the link to the victim and grab their code resulting in account takeover.
In the old days even straightforward putting attackers URL worked but right now we have to be more creative. That's where we can combine this technique with open redirection vulnerability.
Outdated technique.
Works depending on the implemented validation.
If on the site there is a funcionality that redirects us to any specified website and its implemented in a way where we can do this using GET request there is high chance that if we will provide this URI to redirect_uri parameter the attack will succeed.
Of course this is simplified version and flows regularly look more complitated but that example perfectly explains what we are looking for in the general auth process.
Insecure Password Reset Implementation
What other techniques might attackers use to take over an account? Examples include abusing account recovery processes or using social-engineering to trick users into revealing credentials.
When it comes to creating password reset in the web applications we have to be very careful since this particular vulnerability is critical to security of our customers. Along the road many things can go wrong and we may be vulnerable to attacks such as Weak or Predictable Token Generation, Host Header Password Reset Poisoning, User Enumeration or Token reuse.
In this article we will cover very simple case of unsecure password reset funcionality allowing poisoning the function. However if you want to explore more advanced techniques I advise you to watch my YouTube video: [Hackers Loves Pseudorandomness] https://www.youtube.com/watch?v=U8Zg2QqJk08
In the applications created by less experienced developers we often can find strange bugs. Below you can find the perfect example where host header allows an attacker to hijack victim's password. Let's see how is that done.
In the regular flow of the application we just provide email of the user. After that application sends password reset link to that email which is able to set new password for our account.
Resetting the password:
Email result:
But what if the application uses host header to determine which domain should be provided in the password reset email? During regular flow we make one small change to the request in our intercepted request. We change original Host Header to attacker's one.
As we are able to observe the email reflects our malicious input.
How can we exploit this vulnerability?
In this scenario attack is very simple:
- We reset the password for our victim using their email.
- We intercept the request and set the Host Header to our domain.
- After victim click the password reset button and reset password in our website providing us with two main things:
- password reset tokens which can be used by us to create new password for the other user account,
- their new password which also can be useful during attack on the other applications in which the victim has accounts.
SQL Injection
Absolute classic in the cybersecurity space - SQL Injection. If you reached this part of the article then you are probably familiar with this vulnerability. Nevertheless I will quickly explain how does it work for our less experienced readers.
Referring to the main topic of the article: If application is vulnerable to this kind of attack we can extract hashed passwords of another users, crack them and them log in to their account but in this case this is definitely not the most dangerous scenario.
SQL Injection occurs when the web application does not treat the user input just as a text but the part of SQL command itself.
How does it work and why does it happen?
In the regular application flow user during some action provides text which is interpreted by web server and sent to the database.
The problem shows up when user create malicious request imitating the rest of the SQL command.
The main problem here is using untrusted / incompetently filtered input which is concatenated to the original part of the SQL command. You can find example of vulnerable code below:
<?php
$pdo = new mysqli("localhost", "user", "pass", "db");
$username = $_GET['user']; // untrusted input
$sql = "SELECT * FROM users WHERE username = '$username'";
$result = $pdo->query($sql);
?>It is worth mentioning that SQL Injections across the time happens less and less often. Despite that we have to beware for this type of vulnerability since even 1 point of injection can cause data breach in our application.
Modern applications are often safe from SQL injection due to usage of parameterized queries, prepared statements, and Object-Relational Mapping (ORM) frameworks that automatically handle user input safely.
Can we do more than extracting password from database?
Of course, depending on the database we can list / read files on the system and most importanty gain control over the server itself.
When we found SQLi in the web application with MSSQL database we can use the following command to gain shell.
EXECUTE xp_cmdshell 'whoami';In some cases this kind of exploitation will not work. How to know that we in fact are able to execute commands?
Even if it does not work at the first try it is worth checking if we have administrator privileges since then we can turn on xp_cmdshell ourselfs:
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'xp_cmdshell', 1;
RECONFIGURE;EXECUTE xp_cmdshell 'whoami';
Image Source: https://infinitelogins.com/2020/09/06/enabling-xp_cmdshell-in-sql-server/
Conclusion
Account takeover is rarely a single-vector problem — it’s an ecosystem failure where human habits, application design, and operational choices all interact. In this article we walked through six practical attack techniques (three user-oriented and three system-oriented) and showed that even defenses like complex passwords or MFA can be bypassed when attackers exploit human trust, poor implementation, or gaps in process. Practical checklist (quick wins)
- Stop storing credentials in browsers; adopt a password manager.
- Enforce unique passwords and enable MFA everywhere it’s supported.
- Harden OAuth integrations
- Review password-reset flows
- Run regular security testing, keep dependencies and servers patched.
