The attack started conventionally with a phishing email, followed by a sophisticated real-time AI Deepfake video conference call.

The victim employee receives a phishing email, purportedly from the company’s UK-based Chief Financial Officer (CFO). In the following video conference call, the finance employee saw and heard people who looked and sounded like the CFO boss and some other colleagues. Interestingly enough, all participants on the call, apart from the victim, were AI-generated deepfakes.

The victim employee was initially suspicious of the email, but the hyper-realistic, multi-person video call convinced them the request was legitimate. The visual and auditory cues convinced them the transaction was legitimate and sanctioned by top management.

During the call, the deepfake participants instructed the finance employee to execute a series of high-value money transfers, keeping it as a "confidential transaction."

Upon discovery, Arup took immediate action, notifying the Hong Kong police about the incident of fraud in January 2024.

But it was too late to interrupt, wasn’t it?

The heist has been successful. The money is gone.

“Seeing is Believing” is an Obsolete Narrative

AI capabilities are getting powerful each passing day. Plus, it is accessible to all of us, and attackers, more than ever before.

Attackers are finding new ways to attack, because we already have so many defenses against known ways of attacks. Those are mostly predictable and technical with some human applied social engineering techniques.

And you can easily spot these types of social engineering attacks by “believing what you’re seeing”. Easy technical defenses are good enough to defend against them as well.

Plus, training people to prevent phishing attacks is a proven defense mechanism most organizations use. But these technical defenses and old training don’t work on modern AI-assisted Social Engineering attacks.

It’s now possible for attackers to craft deepfake social engineering attacks using Artificial Intelligence (How? See the Vibe Hacking section below).

That’s what happened with Arup’s finance employee.

Attackers tricked them to transfer the money using a deepfake video conference call. And the big mistake, Arup’s employee believed what they saw.

But deepfake attack techniques are designed to fool even an eagle’s eye.

Human senses fail checks against these types of attacks because deception happens in real-time using faces and voices of the people you trust the most.

Vibe Hacking: When AI Starts Hacking Alone

On 13th November 2025, Anthropic reported the first major cyberattack run by an anonymous AI agent. Here’s the report: https://assets.anthropic.com/m/ec212e6566a0d47/original/Disrupting-the-first-reported-AI-orchestrated-cyber-espionage-campaign.pdf

The attack is linked to a Chinese state-sponsored group (GTG-1002). They’re using the popular AI coding tool Anthropic Claude Code. The agent executed 80% to 90% of the hacking steps, finding information, finding weak spots, stealing passwords, and analyzing data without a human constantly telling it what to do.

This is the key change.

We’ve moved from people using AI as an assistant to AI being the hacker by itself. This increases the speed and tanks the size of attacks drastically. These attacks bypass biometric liveness checks and human verification layers as well.

Reports show that in the first three months of 2025 alone, the number of confirmed deepfake incidents was more than the total number in all of 2024.

This shows how quickly hackers are using this technology.

Financial losses from these scams in just Q1 2025 passed $200 million. Imagine the kind of destruction these standalone AI agents could cause in the near future.

We’re moving from AI-assisted Social Engineering to Standalone AI Agent Social Engineering.

How can we still prevent future attacks?

The Double-Check Rule

Rule: If a request comes via video or email, the employee must call the person on a known desk extension or send a quick text on a different, internal chat system.

Protocol: Treat all urgent, secret, or high-money requests as a possible deepfake. Never confirm the request using the same app or method it was received on.

The Two-Person Rule

Change how financial approvals work to make sure at least two people approve major transactions (called a four-eyes principle), no matter who the boss is on camera.

Principle: No one person, even the CFO, should have the power to approve giant money transfers by themselves. This simple rule makes it much harder for a single deepfake attack to succeed.

Train the Staff

Train employees to use simple, personal verification questions that an attacker who only scraped public videos (or is a basic AI) cannot answer.

In July 2024, a smart Ferrari executive stopped a deepfake voice-clone of their CEO, Benedetto Vigna.

The attacker was demanding an urgent transfer. The alert executive simply interrupted:

"Sorry, Benedetto, but I need to identify you,"

and asked a question based on a recent, private talk:

"What book did you recommend to me recently?"

The AI attacker couldn't answer and immediately hung up the call.

Conclusion

AI Deepfake Social Engineering and Standalone Hacking AI Agent attacks are real attack vectors to most organizations in the year 2025 and beyond. Ignoring this fact could prove to be destructive action. Because if your organization doesn’t evolve and adapt to the evolution of attack techniques, then being a number target of these attacks is inevitable.

Recently, during an engagement, I discovered a subtle yet critical vulnerability: An Insecure Direct Object Reference (IDOR) that exposed user data.

Easy to overlook, but could have serious business consequences.

Here’s what happened.

I was examining an API endpoint that returned user details.

I noticed that it used a GET request.

At first glance, everything seemed secure. Changing the ID in the URL returned either the correct user’s data or an error for invalid IDs.

It looked solid. But wait…

Security isn’t about what appears to be, right?

By simply switching the request method from GET to POST and adjusting the ID in the payload, I suddenly had access to another user’s name and email, data that should have been strictly isolated.

Why does this matter?

• Small tweaks can bypass controls: Security measures often assume certain usage patterns. Changing the request type might seem trivial, but for IDOR vulnerabilities, it can completely bypass access checks.

• Exposing user data damages trust: A user’s name or email can be leveraged for social engineering, phishing attacks, or account takeover.

• SMEs are prime targets: Attackers know that smaller organizations often rely on default security logic. Simple IDORs can quickly become gateways to larger breaches.

Takeaway:

Don’t just secure endpoints. You have to validate access rigorously for every type of request, whether GET, POST, PATCH, DELETE or PUT.

Every ID should be verified against the user’s session and role.

If your application assumes that changing the method is harmless, that assumption is a vulnerability.

I recommend practical, high-impact fixes:

1. Enforce server-side access control on every request. Never rely on client-side checks or request type assumptions.

2. Implement ID mapping or token-ization so internal IDs aren’t exposed externally.

3. Get your API pentested with real-world attack simulations. Small changes like request method tweaks can reveal hidden weaknesses.

Security isn’t just about preventing breaches, it is more about staying ahead of the attacker’s mindset.

During a recent web application penetration test, I discovered a Stored Cross-Site Scripting (XSS) vulnerability by uploading a malicious SVG file containing inline JavaScript.

This blog outlines how the vulnerability was discovered, exploited, and responsibly disclosed.

What Is Stored XSS?

Stored XSS occurs when user-supplied input is stored by the server (e.g., in a database or file) and later rendered in a way that executes code in other users’ browsers. In this case, the payload was stored as an SVG file and served back to users with insufficient sanitization or CSP.

Vulnerable Functionality

The application allowed users to upload image files, including SVGs. These images were later rendered directly into the DOM using an <img> tag.

Example HTML:

htmlCopyEdit<img src="/uploads/user-image.svg">

Here’s the catch: the server preserved the Content-Type header of the uploaded file (e.g., image/svg+xml), and served the file inline without sanitization or restrictive CSP headers.

The Malicious SVG Payload

I crafted a minimal SVG file with embedded JavaScript:

xmlCopyEdit<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="2" fill="red"/>
</svg>

• The onload event on the <svg> element triggers when the image is rendered.

• The payload triggers a simple alert() , in a real scenario, this could be replaced with data exfiltration.

Proof of Concept

1. Upload the malicious .svg file through the image upload feature.

2. Note the image is embedded using <img src="/uploads/user.svg">.

3. When any user visits the page containing the uploaded image, the onload JavaScript runs in their browser.

📸 Result: JavaScript executes in the victim’s browser —> a stored XSS.

Why This Works

• SVG is not sanitized.

• SVG allows inline JavaScript and event handlers.

• Uploaded file was served with Content-Type: image/svg+xml.

• No Content Security Policy (CSP) to restrict inline scripts.

• Rendering the SVG in an <img> tag does not prevent JavaScript execution in SVGs.

Note: Despite common belief, <img src="malicious.svg"> can execute JS in some SVGs, especially in legacy or improperly configured browsers.

Takeaway

Even "image" files like SVGs can carry dangerous payloads. Always assume that uploaded files are hostile and sanitize or sandbox them appropriately.

There were constraints which stopped me to perform further attacks.

Before the AI revolution, Hackers were using manual and automated ways to attack systems. They had to put a lot of effort into the craft of attacks. From researching the target to final exploitation, it took way too long. Along that journey, there was also a possibility for the hacker to hit a tough roadblock.

All in all, Hacking before the AI revolution was a tough game. The barrier to entry for a normal person to become a hacker was really high.

AI is not Sci-fi anymore.

Anyone can learn to use GenAI and derivatives. Due to this, most businesses will see a rise in AI based cyber attacks. There’s already a lot of successful AI-enhanced attacks by hackers, without roadblocks on their journey. It’s getting easier for people to learn AI and AI-enhanced hacking. So, cyber attacks are increasing at an insane pace.

A day will come when anyone with a mobile phone will be able launch an AI based cyber attack with the tap of a button. It’s not that far, considering what products are currently available in the market.

Existing defenses against cyber attacks won’t work anymore. You can monitor your systems endlessly with 24/7 Security Operations Centers (SOC). But that costs a lot and it’s not foolproof.

So, how to beat AI?

What about using AI in SOC? Aside from it being an expensive solution, it will not mitigate the security flaws that your system has.

Malicious actors are using AI-powered tools like PentestGPT, thanks to it being open-source. I have pointed out how Chinese hackers are using advanced systems to pentest in my post here on 𝕏. Imagine making that system AI powered.

In my opinion, our best weapon to beat AI based cyber attacks is AI-enhanced Penetration Tests.

Developers are already using AI to develop systems and fix vulnerabilities. So, using AI to enhance performance of a manual penetration tester can be extremely fruitful.

In this scenario, businesses deserve quick and high-quality pentest results, which is only possible using AI-powered tools. The PentestGPT is a great example of what an AI-powered penetration testing tool looks like. It can help penetration testers perform with higher quality and speed than ever before.

The question of the year 2025 is: Are you using AI to secure your business?

With 2025 in full swing, cyber threats are more sophisticated, pervasive, and damaging than ever before.

Businesses, governments, and individuals are all at risk, and the stakes are higher as technology becomes more integrated into our lives.

In this blog we're going to talk all top 10 emerging cybersecurity threats including Deepfakes and Quantum Computing ones.

1. AI-Powered Cyberattacks

As artificial intelligence becomes more advanced, hackers are using AI to launch smarter and faster cyberattacks.

These attacks can quickly bypass traditional security systems, making it harder for businesses and individuals to protect themselves.

The speed and complexity of these AI-driven threats mean that even the most secure systems can become vulnerable. The more advanced the AI, the harder it is to predict and stop these attacks before they cause damage.

It's time to implement AI-powered cybersecurity systems that can identify and block potential threats in real time. Read more about preventing ➼ AI-powered Cyber Threats.

2. Ransomware Attacks

Ransomware attacks lock up your files or systems and demand payment in exchange for restoring access. These attacks can bring businesses to a halt and cost millions in lost data and productivity.

Attackers often target vulnerable systems or exploit human error to gain access.

Once inside, they can encrypt your files and hold them hostage, leaving you with little choice but to pay the ransom or lose your valuable information.

3. Data Breaches

Data breaches expose sensitive information, like personal details, financial data, or login credentials, putting individuals and companies at risk for identity theft and financial fraud.

A single breach can affect millions of people and severely damage a company's reputation.

Even after the breach is fixed, the stolen data may be used to harm victims long after the attack.

4. Internet of Things (IoT) Vulnerabilities

Many everyday devices, like smart thermostats, cameras, and wearables, connect to the internet, but these devices often lack robust security.

Hackers can exploit vulnerabilities to gain access to personal or business networks.

As more devices become interconnected, the number of potential entry points for hackers grows.

A single unsecured device can act as a gateway to your entire system, making it easier for attackers to infiltrate.

5. Phishing and Social Engineering

Phishing attacks trick users into revealing personal information by posing as legitimate organizations or individuals. These attacks often come in the form of emails, phone calls, or messages that look trustworthy.

One click on a malicious link or attachment can lead to devastating consequences, like identity theft or a full system compromise.

Social engineering techniques make these attacks even harder to detect, as they exploit human psychology.

It's good to educate users about recognizing phishing attempts and always verify the sender's identity before clicking on links or providing personal information.

6. Cloud Security Risks

As businesses and individuals increasingly rely on cloud services, the risk of security breaches grows.

Misconfigured cloud settings or weak access controls can expose sensitive data to hackers.

If your cloud storage or applications aren't secured properly, attackers can easily access sensitive files or even tamper with your data.

Cloud providers can’t always guarantee your security, especially if you're not taking necessary precautions.

7. Insider Threats

Sometimes, the greatest security threat comes from within your organization.

Employees with access to sensitive data can intentionally or unintentionally compromise your systems.

Whether it's a disgruntled employee or someone simply making a mistake, insider threats can cause enormous damage. These attacks are often harder to detect because insiders have legitimate access to the systems they compromise.

Remember Edward Snowden?

8. Supply Chain Attacks

Cybercriminals are increasingly targeting the suppliers and third-party vendors of businesses.

If a vendor's system is compromised, it can provide a backdoor into your company’s network.

These attacks can be hard to defend against because they exploit trusted relationships.

If a supplier’s systems are breached, attackers can then infiltrate your organization without directly targeting you.

I can protect your organization today from Supply Chain Attacks by simulating real-world attacks on your organization's systems.

9. Deepfake Technology

Deepfake technology allows attackers to create highly convincing fake videos, audios, and images. This can be used for identity theft, spreading misinformation, or tricking individuals into transferring money or disclosing personal information.

The more convincing these deepfakes become, the harder it is to distinguish real from fake.

This poses serious risks to individuals and organizations, especially if malicious actors use them to impersonate trusted figures.

10. Quantum Computing Threats

Quantum computing has the potential to break many of the encryption methods we rely on for securing data.

Once these systems become widely available, sensitive information could be exposed to cybercriminals.

As quantum computers advance, they could render current security protocols obsolete, leaving systems vulnerable to attacks.

Hackers with access to quantum computing could decrypt protected data at unprecedented speeds.

It was pleasure for me to reveal my analysis of Top 10 Cyber Threats for year 2025.

Here's the list of all those vulnerabilities, so that you won't have to scroll down to know them all:

1. Broken Access Control

2. JSON Web Token (JWT)

3. NoSQL injection

4. File Upload

5. SSRF

6. XXE

7. Broken Autentication

8. XSS

9. Sensitive Data Exposure

10. Business Logic Failure

1. Broken Access Control

Role-Based Access Control comes into play where there's a hierarchy in an application. Just like any organisation's hierarchy, applications have their own set of roles. These roles allow users to have privileges.

Each role has its own set of privileges in an application. There's two types of Broken Access Control: Horizontal and Vertical.

To perform Horizontal BAC, you need to perform actions that another user, of same role as your user, can perform.

To perform Vertical BAC, you need to perform actions that another user, of a higher role than your user, can perform.

That's the simplest BAC explanation I could ever give. Here's few pages that you can to go down deeper into BAC:

https://owasp.org/Top10/A01_2021-Broken_Access_Control/

https://owasp.org/www-community/Broken_Access_Control

https://hackerone.com/reports/1323406

https://hackerone.com/reports/493324

2. JSON Web Token (JWT)

JSON Web tokens can be used in a wide range of functionality where integrity is a main requirement. Most common use is in Authorization of a user. Authorizing a user into an application is a task that requires rigid parameters, so that the user can only perform the tasks that it's supposed to.

JWT tokens have below structure:

[Signature information].[DATA].[Signature]

Signature information: It defines the algorithm that has been used to generate the Signature.

DATA: This part of JWT has the data that contains information about the user and the session.

The Signature is always created with the algorithm specified in the Signature information and a secret key which is stored on the server. The server verifies the Signature of the JWT token by using this secret key into the reverse algorithm and ensures the integrity of data.

There are a lot of attacks which could be performed to misuse JWT tokens. All the type of attacks and their recipes are mentioned in this page: https://book.hacktricks.xyz/pentesting-web/hacking-jwt-json-web-tokens

Have fun ripping apart the tokens.

3. NoSQL injection

There are various types of NoSQL databases. Most commonly used is MongoDB. But the techniques to attack these databases is almost similar.

Unlike regular SQL queries, NoSQL queries are constructed using JSON objects:

{
    object: String, 
    q: Expression, 
    fields: Array of String, 
    groupBy: Array of String, 
    aggregation: Object mapping fields to aggregate functions 
}

This simple query retrieves the name and salary of all employees in position of "Sales Manager":

{ 
    "object": "employees",
    "q": { 
        "position" : "Sales Manager"  
    },
    "fields": ["name", "salary"] 
}

Queries can also be used to compare an object's fields to constant values using common comparison operators. For example, to retrieve all fields for all employees under the age of 25, you can use the following query:

{ 
    "object": "employees",
    "q": {
        "age": { "$lt" : 25 } 
    }  
}

In an application, normal authentication would look like:

{
    "username": "admin",
    "password": "password"
}

An example of successful exploitation of that authentication would be:

{
    "username": {"$in": ["admin", "administrator", "superadmin"]},
    "password": {"$ne": ""}
}

All possible attack scenarios are explained by below references:

https://book.hacktricks.xyz/pentesting-web/nosql-injection

https://portswigger.net/web-security/nosql-injection

4. File Upload

File upload functionalities are most likely to be vulnerable in a Web Application, due to a lot of factors involved such as file name, extension, content, etc...

The first thing I do when I see a file upload functionality is that I check for what file names, extensions and contents are allowed. The best way to deal with this is to always use a wordlist to fuzz parameters of the endpoint.

After fuzzing, you should be able to figure out what is allowed and what is not. And according to that, it's good to conclude whether there's a way in which you could somehow upload a file with malicious content.

Now the malicious uploaded file doesn't have to be executing at the moment, because this very file could be used as a backdoor and can be used successfully to further exploit the application server.

Here's few pages that you can refer to:

https://portswigger.net/web-security/file-upload

https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload

5. SSRF

Backend's of modern applications usually communicate with third-party API's to exchange data, to fulfill the requirements of the application's functionality as a whole.

If this type of communication is somehow exposed by the backend to the frontend of the application, then it could be possible to manipulate the connection and make the backend to connect to attacker's server instead of the supposed connection to third-party API.

This connection to attacker's server could be used by the attacker to maliciously use the third-party service to exchange data or possibly perform remote code execution on the backend. This could compromise the whole application.

Here's the few pages for references:

https://portswigger.net/web-security/ssrf

https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

6. XXE

When an XML document containing malicious External Entity gets parsed through XML parser, it executes according to attacker's intent, then it's called XML External Entity vulnerability.

This attack could lead to several types of impacts including Server Side Request Forgery (SSRF) and Remote Code Execution (RCE).

Below is an example of non-malicious XML:

<?xml  version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE note>
<note>
<to>John</to>
<from>Doe</from>
<heading>TODO</heading>
<body>Send an email to Donald</body>
</note>

Below is an example of malicious XML:

<?xml  version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM  "file:///dev/random" >]>
<foo>&xxe;</foo>

An XML document with correct syntax is called "Well Formed". An XML document validated against a DTD (Document Type Definition) is both "Well Formed" and "Valid". The DTD should be defined to the parser by the application developer. If not properly defined, then it could lead to XXE attack.

Here's few pages for reference:

https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing

https://www.hackerone.com/knowledge-center/xxe-complete-guide-impact-examples-and-prevention

7. Broken Authentication

Entrypoints of most applications is an authentication mechanism which let's legitimate users use session of the application after using their credentials.

But when this mechanism is not properly implemented, then the application is vulnerable to a lot of authentication attacks including use Default Credentials, broken MFA and Brute-force attacks.

The impact of this vulnerability depends on the domain of the application, as this may allow money laundering, social security fraud, and identity theft, or disclose legally protected highly sensitive information.

Here's few pages for reference:

https://portswigger.net/web-security/authentication

https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication

8. XSS

Cross-site Scripting (XSS) attack involves executing arbitrary Javascript code on victim's browser. This could help attacker to steal victim's account information or to perform actions on behalf of victim in an application.

There are 3 types of XSS:

• Reflected Cross-site Scripting

• Stored Cross-site Scripting

• DOM-based Cross-site Scripting

Reflected XSS

Attacker crafts and sends an exploit URL to the victim using social engineering. This exploit URL contains malicious characters with arbitrary javascript code in the parameter's value. Now this arbitrary javascript code get's executed when victim clicks that URL.

Stored XSS

The attacker crafts an exploit similar to Reflected XSS but instead of sending exploit URL to victim, the attacker inserts it into an information storing function in the application or third-party application which is retrievable through another function of the application. When victim uses the retrieve function, the malicious Javascript executes.

DOM-based XSS

DOM stands for Document Object Model of browsers. DOM has a source and a sink. A DOM source serves function of retrieving data from user's input and DOM sink serves the function of processing the retrieved data. Javascript takes data from sources and passes it to the sink. This attack happens when an attacker inserts malicious characters and arbitrary Javascript code into DOM source, and this code is later processed by DOM sink and the arbitrary Javascript code is executed.

Here's few pages for reference:

https://portswigger.net/web-security/cross-site-scripting

https://owasp.org/www-community/attacks/xss/

9. Sensitive Data Exposure

Everyone has to do their own research about where to look for this bug class, because every web application is made for a specific business logic.

All it takes to figure out where to look, is understanding the business logic. But some of the places are generally usable for every type of web application:

- Social Media

- Search engines: https://github.com/T43cr0wl3r/OSINT-RECON/blob/master/Dorking.md

- Quick Hits: https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/quickhits.txt

- Github - Employee's/Contractor's property (Social Media, Portfolio etc...)

- Other OSINT methods

- Web App Errors

- AI dumps: (i.e. ChatGPT share leaks)

- WayBack Machine

10. Business Logic Failure

Business Logic Flaws are simply failure of the application to follow the rules of business. This bug class is diverse and huge enough to understand without an example.

So, here's an example:

An e-commerce bookstore web application is designed to handle discount code. For example, there's a discount run by the company for 20% discount. An attacker tries to use the same discount code twice on total cart value of $1000, on the first try, the discount code works as expected and gives the final price to be $800.

Then, the attacker applies the discount code again and the application gives discount of 20% again, so the final price becomes $640. In this example, the application fails to check whether the discount code has been already used on the cart.

Here's few pages for reference:

https://portswigger.net/web-security/logic-flaws

https://owasp.org/www-community/vulnerabilities/Business_logic_vulnerability

Conclusion

These vulnerabilities are a huge challenge for any organization looking forward to make their web applications secure. Hopefully, this post by me provided you an insight on Top 10 vulnerabilities in this era of web applications. Thank you for reading and stay tuned on my 𝕏 for more posts and content like this.