Here is a theoretical setup:

  • You have a web server running Windows Server with IIS
  • You have a website running here which connects to a database
  • This website can start automatically when the server starts
  • The database connection is done using trusted windows authentication
  • A malicious party gets the hard drive from your web server

Is it possible for the malicious party to get access to the database?

As far as I am aware, trusted authentication uses the user that the website is running as. Therefore, there must be some sort of automatic login for this user. Is this the area that can be exploited? Is there some complication because of the domain controller?

Please don't post answers like "Yes, of course it's possible" or "No, it's 100% secure". I would like explanations as to what extent this is secure and why.


2 Answers 2


When Windows machines are part of an Active Directory domain, Kerberos is used to manage authentication. With Kerberos, the domain controller is the game master: everybody trust it, and none other. Which means that when the Web site connects to the database, the machine which contains the Web site (let's call it "WWW") talks to the domain controller ("DC") and uses a secret value, stored in the entrails of WWW, to convince DC that it is exactly that machine, sane and sound of spirit and body: the secret value is accessible only to the most privileged process in WWW.

Once DC is convinced, it honours the request from WWW which is: "give me a ticket which I can show to the database, proving that I am user 'SomeDomain\SomeAccount' trying to connect to the database under that name". That ticket is the result of a cryptographic computation that the database server (DB) will verify by talking to the DC ("Is this ticket valid right now ?"). Tickets embed a timeout and are short-lived.

What does it mean for our problem ? It means that an attacker obtaining a full copy of the hard disk of WWW learns the secret value that WWW uses to authenticate to the DC. This does not give him any secret which would be sufficient to connect to the DB directly. Indeed, the DB trusts only DC. So, in order to actually connect to DB, the attacker has to pose as WWW, i.e. boot a machine on the same network, which will use its knowledge of the hard disk contents of WWW to convince DC that it is the rightful WWW, and obtain a connection ticket which will please DB. Moreover, in order to achieve that, the genuine WWW machine will have to be shut down or at least disconnected from the network, because if the DC sees two machines simultaneously, both claiming to be WWW and knowing the WWW-specific secret to that effect, then the DC is likely to go irate and cease to talk to both.

Summary: In your scenario, the theft of a copy of the complete disk of the Web server will allow rogue connections to the database only in case of an active attack in which the attacker runs a fake machine in lieu of the genuine Web server. This is equivalent to taking administrator-level control of the Web server (whether the attacker switches the hardware or not is actually irrelevant). To succeed in connecting to the database, the domain controller must still be involved.

  • 1
    Can a malicious party acquire access to the data in the database by analyzing the file system directly?
    – David Mah
    Apr 14, 2013 at 14:51

Yes, there is a way: You just put the hard disk contents into a machine of your control and boot it. You now have a process running there that can access the database.

Now you manipulate the memory of that process so that it does what you want. You can either force access to Windows using an offline password reset for an unrelated admin account, or just use direct memory access hardware (USB Sticks exploiting NTFS bugs, PCI-E cards, ...). Then you can cut into the living brain of that process and make it execute arbitrary queries.

  • Depends a lot on what account is the application configured to run as. The attacker may have to obtain first a physical connection to corpnet to be able to see the domain and possibly have to join the compromised hdd host in the domain. Apr 13, 2013 at 19:03
  • @RemusRusanu you might have a point there. AFAIK you can log into any domain account without being connected to the DC. This is evidence that the relevant credentials are stored locally and are available as the service starts up. Also, if the DC was necessary to obtain credentials this would be an availability risk (DC down => all websites down!). I cannot imagine this being the case.
    – usr
    Apr 13, 2013 at 19:17
  • Only cached credentials (users that had previously logged in interactively) can log in, and the password is not stored anywhere for those. Service password are stored encrypted in DPAPI and cannot be brute forced. Don't get me wrong, physical possession of the HDD is not to be brushed aside, it can posses serious threats. BitLocker can offer a simple mitigation to any threat, perceived or real. Apr 13, 2013 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .