Fingerprints … Why? I Have Your Printer Drivers!

By Stephen Evans ·

For the purposes of clarification herein, “analysis profile” is a structure of evidence that is combined in such a fashion as to support or refute the investigator’s hypothesis. The profile I want to address is remote access. Remote access evidence can potentially identify the who, how and even the when of an investigation. There are vast iterations of remote access evidence that can be analyzed. The purpose of this article is to provide what I consider a new and innovative approach toward analyzing a Remote Desktop Protocol (RDP) session. The specifics of the evidence are not new or innovative, but the application of the evidence is where you should see a twist in conventional thinking.

First, I must set the background. This approach is based on the following hypothesis: “An individual gained unauthorized remote access to a computer system using a standard RDP session.” Given this hypothesis, a great place to start digging is in the event logs of the system. In looking through the event logs, I noticed a pattern of error logs with event ID 1006:

For those unfamiliar with this pattern, it is a typical brute force attempt on user credentials. The attacker queries the target system, extensively attempting to identify the password and gain access to the system. In many instances, terminal services will identify this attack pattern and disconnect the user, but the attacker only has to wait a period of time and make another attempt. Now some of you might say brute forcing a password doesn’t work anymore, and I would tend to agree with you. In my experience, “exhaustive brute forcing” and “dictionary attacks” are less than successful, but the attacker might have some additional insight that leads toward a more accurate dictionary of passwords. Regardless of the efficacy of brute forcing theories, the attacker gains remote access to the target system.

How do I know that? Well, it’s simple: I identified the attacker’s print driver. Now this is where I anticipate many of you looking slightly puzzled — as did I when I first tested this theory. So let me explain how the process works.

Digging deeper into the event logs, I noticed another pattern emerging. I saw multiple errors with event ID 1111:

Research into the error identifies it as a failure to load a print driver. Many of you might simply ignore the event as coincidental, but I dug deeper. Plotting out the errors, a larger pattern emerged. I noticed that the printer driver errors occurred after a successful authentication request and the drivers were consistently grouped together. In other words, I noticed the same five printer driver errors each time. Here is where the professional investigator steps in and admits that coincidence just isn’t good enough.

After doing some research online and in various forums, I found others identifying a similar pattern. In one such location, I found the most curious of explanations:

"On your RDP connection, you have enabled the local printers so the server is attempting to map that printer. Therefore, you can print locally from within the RDP session. The server does not have that printer driver installed, henceforth the error. You need either to uncheck allowing local printers, install that printer driver, or leave it as is and know what the error is indicating."

Those of you who are more advanced in investigations probably just realized the full impact of this explanation and may stop at this point. However, I urge you to continue as there are some other “golden nuggets” we can get out of this data. For the rest of you, let me help shed light on the situation. Let’s step back a bit and look at what we have:

- Logs that show evidence of a potential brute force attack

- Successful remote login evidence after the brute force attack

- Printer driver errors that are in consistent groups of the same printers and occur right after a successful remote login

If you are still puzzled, here is the answer. The attacker was able to compromise remote access credentials. Then each time the attacker logged in via RDP or terminal services, the attacker’s computer was attempting to load the “local” print drivers from the attacker’s computer onto the target system. The target system did not have the drivers needed to support the printer, so an error occurred each time the attacker logged in.

Let’s return to some of our original questions:

- Q: How?

  • A: An RDP session using a compromised account.

- Q: Who?

  • A: An unauthorized user leveraging a compromised account.

At this point we have provided some solid evidence to support our hypothesis, but there are still questions that remain. Digging deeper into the actual event details I noticed that there was some additional metadata that could be extracted. The easiest of which was time. I have mentioned references to events and time in a relative fashion, but once I identified the patterns and correlated the patterns to my hypothesis I was able to use the exact values of time. This is because the legitimate user doesn’t have the exact same printers installed as the attacker. In essence, the quantity of printers, and make and model of each printer combine to form a pseudo “printer drivers fingerprint.” That fingerprint is what I could use to accurately extract events related to the attack from legitimate usage events.

Looking back at each error individually, I noticed that some of the names of the printer drivers actually provided details about the attacker’s computer. For example, let’s look at the following event:

I highlighted the name of the printer driver, which includes the following text:

“Auto Send to OneNote 2007 on

For security reasons, I obfuscated the computer reference. Through testing, I found that the computer reference varied. Some printer driver names would include the computer network name, while others would include secondary data such as the make or model of the computer. How the computer reference is created will be held for another discussion on another day, but the end result is additional metadata about the attacker’s system.

The following is another example of computer reference in the printer driver name:

Those of you who are detail-oriented will notice that this is a different error than previously. I did this purposely to present another interesting piece of evidence. Rather than string you through the process, I’ll cut straight to the answer. This event is an error that is generated when the RDP session attempts to delete the printer driver from the target system. When the remote user issues a “logout” request, the RDP session attempts to remove any printer drivers that were loaded. Fortunately, the session is not smart enough to realize the drivers were never loaded. Instead the session just issues a blind request to delete the drivers regardless of availability. The target system then creates this event to log the error in deletion. Now we have both login and logout of the remote RDP session, giving us not only the exact time when the attacker logged into the target system but the length of time they remained logged in and the exact time of logout. I must warn you, though; this evidence is not as consistent as the login events. Testing showed a higher level of consistency when the remote user issued the logout request, rather than simply closing the RDP session locally and allowing for the inactivity timeout to stop the terminal service.

In summary, let’s do a quick recap of what we know in relation to our original questions:

- Q: How?

  • A: RDP session using a compromised account. The account was likely compromised through a brute force, dictionary or targeted dictionary attack.

- Q: When?

  • A: The errors in loading the printer drivers provide us exact times when the attacker logged in. The errors in deleting the printer drivers provide us exact times when the attacker logged out; therefore, giving us the duration of unauthorized access sessions.

- Q: Who?

  • A: An unauthorized individual. From evidence within the logs, we can potentially gain details such as installed software (OneNote Auto Sender), computer name, computer make or model, and various other pieces of metadata leaked through various printer driver naming conventions.

The answering of questions related to what, why and where will be saved for another day. However, I will give you a hint: If you know when the remote session starts and ends, then finding out what they did isn’t too tricky.

Lastly, I must provide my disclaimer. This analysis profile is based on my personal experience and opinions. References to data and screen shots were provided by using a controlled environment to test and validate the opinions provided herein.