Securing PowerShell: How to Stop Prompt Injection Attacks, Part 3Securing PowerShell: How to Stop Prompt Injection Attacks, Part 3Securing PowerShell: How to Stop Prompt Injection Attacks, Part 3

The third part of this five-part series on stopping prompt injection attacks describes how an attacker can use prompt injection exploits to reveal hidden database structure.

Picture of Brien Posey

Brien Posey , Technology Analyst

August 7, 2025

5 Min Read

magnifying glass

Alamy

[Editor's Note: This is Part 3 of our comprehensive five-part series examining strategies to prevent prompt injection attacks. For readers interested in the complete context, we recommend reviewing Parts 1 , 2 , 4, and 5 .]

In Part 2 of this series , I provided a really simple example of a prompt injection attack , and I set a few ground rules for performing a full-blown attack against my demo PowerShell script .

To sum up those ground rules, I am going to pretend that I know nothing about the script or the database other than what I can learn through observing its behavior.

Observing the Behavior of the PowerShell Script

That last part (observing the script's behavior) is important because it will act as the starting point for our attack. The attacks that I'll be showing you are based on the SQL UNION command, which basically combines two queries. To use the UNION command, however, the UNION query has to match the number of columns used for the original query. In other words, the script is designed so that you can enter a username and get that user's email address.

It's a pretty safe bet, therefore, that the query (the SQL SELECT statement) is pulling data from a single column (the email address column). This is important because it means that any UNION statement that I write would also be limited to examining a single column of data. The good news from an attacker's point of view is that we can examine any column of data that we want.

[フレーム]

Before I show you how this works, let me answer an important question. Suppose I was trying to attack a script and had no idea how many columns of data it was reading. How would I construct a UNION statement in that situation? The best way to approach a situation like this would be to use trial and error until you determine how many columns are being used. You can use null values or even fake data for this purpose. Here's how this works.

As previously mentioned, my PowerShell script queries a single column of data, but let's suppose that I don't know that. My first move in such a situation would be to try to figure out how many columns of data are being queried. To do so, I could use a prompt injection like this one:

' OR 1=1 UNION SELECT '','

This prompt injection attempts to supply two null values to the UNION SELECT statement. Since the UNION SELECT statement has to reference the same number of columns as the original SELECT statement, this command returns an error stating that all queries combined using a UNION, INTERSECT, or EXCEPT operator must have an equal number of expressions in their target lists. You can see what this error looks like in Figure 1.

UNION statement produces an error

Figure 1. My attempt at using a UNION statement produced an error.

How Attackers Can Take Advantage of Errors

As admins, we are often conditioned to think of errors as being a bad thing. For an attacker, however, errors can be helpful because they often convey useful information. In this case, the error tells us that the SQL SELECT statement that is embedded within the script does not select two columns of information. An attacker could then repeat the attempt, using a different number of null columns each time, until they figure out how many columns are using by the script's SELECT statement. Once the number of columns is known, the exploration process begins.

As an attacker, let's assume that I have determined that the script contains an embedded SELECT statement that queries a single column of data. Our goal in attacking the script is to extract information from other columns. The problem, however, is that we know nothing about the database's schema. Therefore, the next step in the process is to derive the database schema. This can be done through a series of simple prompt injections.

The first thing that an attacker would probably do in a situation like this is to try to determine the names of the tables used by the database. That can be done through this prompt injection:

' UNION SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES --

In this case, we are using a UNION statement to append a query that extracts the table names from the INFORMATION_SCHEMA table, which is native to the database. As you can see in Figure 2, this technique reveals that the database contains two tables: Admins and Users.

prompt injection revealed the names of the tables contained within the database

Figure 2. This prompt injection revealed the names of the tables contained within the database.

Before I move on, I want to address an important point. As previously mentioned, a UNION SELECT statement requires you to use the same number of columns as the original SELECT statement. In this case, however, my UNION SELECT statement needed only to return a single column's worth of data. That's convenient since the script's SELECT statement also queries a single column of data.

But what might an attacker do if there were a mismatch? For example, suppose that the original SELECT statement queried 10 columns of data, but I only needed my UNION SELECT statement to query a single column? In a situation like this, you can design the UNION SELECT statement to use null values or nonsense values to take up space so that the number of columns will match, even if the UNION SELECT statement is referencing non-existent columns.

So far in our prompt injection attack, we have determined the number of columns queried by the script's SQL SELECT statement, and we have figured out the names of the tables stored within the database.

In Part 4 of this series , we acquire additional information about the database structure and gain access to data hidden within it.

About the Author

Brien Posey

Technology Analyst

Brien Posey is a bestselling technology author, a speaker, and a 20X Microsoft MVP. In addition to his ongoing work in IT, Posey has spent the last several years training as a commercial astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space.

https://brienposey.com/

See more from Brien Posey

Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

Newsletter Sign-Up