This step is an important one for the attacker. To transfer this into the real world, you can imagine that a burglar managed to get inside a jewelry, at night time, no one knows about him being there, and he is facing all those jewels behind secure glass. Well, he has several ways to become the "boss" of the jewelry and gain access to these nice colored stones.

- Exploit workstation weaknesses

This case is unfortunately not rare. Some system administrators do forget configuration files, testing scripts, on workstations. These files can contain passwords to databases, to shared networks, etc.

Penetration testers can also forget to "clean" computers after they've done a security audit. They can leave scripts, domain controller data, tools, whatever they have used during their mission, which could be useful to an attacker.

Finally, some services or software can leave passwords on the file system or sometimes in the registry. It might contain clear passwords, or passwords with a very weak encryption.

- Inappropriate writing rights

Some workstation's folders must be handled so that they cannot be written. The sole possibility of being able to write there is a severe security hole. As an example, no user of the company should be allowed to write in the "system32" or in the "SysWOW64" folder of his machine. If these folders are not protected, it is possible to replace legitimate files with malicious ones, or create new files there. We frequently discover systems where sethc.exe legitimate binary has been replaced by a malware or even by a legitimate cmd.exe file. These folders are protected by default on Microsoft Windows systems, yet there are other folders which could be used by an attacker who only has user privileges. Such a folder could be the "startup" folders of every user on the machine. On Windows systems, every user has such a folder, which is tasked to run different programs at the opening of the session. There is also a "global" startup folder, for all users. If a user without particular privileges can write there, it could be possible for an attacker to elevate his privileges. The most common technique is to place a malware or a tool there, and wait for an administrator to connect to that machine. The attacker's tool could then be executed with higher privileges.

- Applications misconfiguration

Some applications are critical for companies and do need to be up all the time on production servers. These applications are often never "touched" or patched and often badly configured. A good example is IIS, Microsoft's web server, which is often running with SYSTEM privileges. Such a configuration can be used by the attacker to elevate his privileges.

- Windows services running as SYSTEM

Several services do run with these privileges but their entries in the registry or even their files are sometimes badly protected. It is therefore possible for an attacker to gain SYSTEM rights by exploiting some vulnerabilities/misconfigurations. Some DLL injection can also be done here to have code being executed with higher privileges.

- Other methods

The goal of this blog post is not to expose a complete list of the different ways to elevate one's privileges. It can be as easy as using the "at" command on older Windows systems sometimes.

Vulnerabilities are discovered all the time, and exploits are written to take advantage of it. Unpatched software, vulnerable code, on software, libraries, kernel, can all lead to privilege escalation.

Being a local administrator helps the attacker to install malware,RATs and tools without any limitations. Within these tools, one category shows up in nearly every APT attack: password dumping tools.


Collecting user's passwords is mandatory for an attacker. Users often use the same passwords everywhere. Sad but true, some people do use the same password for their e-mail account, for their Facebook account, for their LinkedIn account, etc. In the professional world, it is a bit more difficult for them because the company's password policy often forces them to change their password every second or third month. One might think that this is safe, yet often the password policies allow the user to change just one byte in the password, and that's where the vulnerable point is. How many users do use a password like "Qwerty1", then when they need to change it it becomes "Qwerty2", "Qwerty3", or "Qwerty11" etc. ? Do these users have the same password to access their professional e-mail address, or to connect to other machines, or to initiate remote connections ? Unfortunately, they generally do.

An attacker with one or several users passwords becomes even more dangerous, because he can usurpate users identity and pretend to be them on the network, making it even harder to be detected.


Local passwords are stored on the user's computer. They are useful to authenticate the user on different activities: Internet browsing (he can store all his passwords for every site needing one locally), E-mail reading, etc.

The most interesting passwords for the APT attacker are the e-mail address password, and the Windows authentication password. More generally, any password related to the network of the company will be interesting for the attacker.

Dumping the password hashes for the local accounts can be done by accessing the SAM (Security Account Manager) registry, using tools such as samdump2, creddump or fgdump for example. These tools must be run with SYSTEM rights. Therefore, the attacker must have elevated his privileges on the compromised workstation.


Several different password types have been used through the years in Microsoft's Windows systems. LM Hash (or LanMan/LAN Manager hash) has been used for Windows versions prior to Windows NT. A transition has been done on Windows XP SP2, which still intergrates LM hashes for compatibility purposes. Next Windows versions have maintained that compatibility but the LM hashes are desactivated by default on these systems.

The reason for abandoning the LM hashes is that it is very vulnerable. The passwords can only be 14 characters long, and the passwords which are bigger than 7 characters are split in two parts, after having been uppercased. This makes these passwords very vulnerable to any brute-force attack. These hashes are also calculated without any salt, so that an attacker can see when different users do use the exact same password.

LM hashes passwords can be found by using brute-force attacks in some hours, or even some seconds with good rainbow tables|en].

NTLM (NT LAN Manager) is a protocol introduced in NT 3.1, used in Windows XP SP2 and further versions, to correct the LM hashes weaknesses.

NTLM does exist in two versions, NTLMv1 and NTLMv2. Passwords are hashed using the MD4 algorithm, they are case sensitive, and they can be as long as 256 characters. While this represents a very big positive evolution compared to LM Hashes, NTLM hashes are not salted either.


Screenshot showing the output from fgdump tool on a system

The results obtained by the fgdump tool are structured this way:

User name :SID :LM Hash:NTLM Hash :::

In this example, we can see that the system does not use LM hashes, which is good. Yet we can see that the NTLM hashes for users CPE and FRIENDLYUSER are the same, which means they use the exact same password (no salt). Please be aware that in some tools, the LM hash result shows the following hash: "aad3b435b51404eeaad3b435b51404ee". This hash stands for "Empty String" and it means the system is not using LM hashes.

- LSA SECRETS (Local Security Authority)

This is part of the registry (to be precise, it is HKEY_LOCAL_MACHINE\Security\Policy\Secrets) in which various information is stored, some being very interesting for an attacker:

  • RAS/VPN passwords (Remote Access Services/Virtual Private Network)
  • "Autologon" passwords
  • Services accounts passwords
  • Several other passwords (example: Internet Explorer, SQL, Cisco, etc.)

Several tools allow to dump the LSA secrets informations: LSASecretsDump, or Abel & Cain, only to mention these.

One big vulnerability here shows up when a service runs as a real user, which allows to get his password in clear text in the LSA Secrets. Worst, Some system administrators do run somes services using privileged accounts, which greatly compromises the system security.


In big companies, a lot of workstations are connected permanently to several domains. What happens when these workstation loose the network connectivity ? Does the user need to wait for it to be fixed to log in the workstation ? The answer is negative, the user can still authenticate on the system. This Windows functionnality comes from the cached domain logon information and is active by default since Microsoft Windows XP systems.


Domain cache parameters on a Windows 7 operating system

Once again, it is possible to get the content of this cache with different tools. Cain & Abel or Quarks PwDump can be used for example. Please note that it is not possible to use the obtained hashes in a "pass the hash" attack (we'll come to that later), but it is possible to crack them (brute-force attack) and then use them to authenticate on other machines in the concerned domain.


Several couples of identifiers/passwords are stored here by the operating system. If Windows asks you if you want to store a password for a future use and you reply positively, it is stored here.

Here is an incomplete list of credentials stored there:

  • Identifier/Password for other computers in the same LAN.
  • E-mail account passwords for Microsoft Exchange servers.
  • Internet websites passwords stored by Internet Explorer.
  • Windows Messenger passwords.

This list cannot be complete since it is possible for the user to add information there, or use third parties applications storing information there.

These passwords are encrypted using the DPAPI (Data Protection API) but it is possible to get a clear version with tools like Network Password Recovery.


Network Password Recovery launched on a Windows XP system on the current logged-on user (clickable)


This is another place for identifiers/passwords, which was used on Windows systems up to Windows Vista. This is still an interesting store for attackers when they are on Windows XP systems for example.

The data stored there is the same as for the Credential Manager Store and can be accessed with tools such as Protected Storage PassView.


Protected Storage PassView output for current logged-on user


Windows does store logon information (user account connection on the machine) in memory, it's called logon sessions. This is written in memory by LSA (Local Security Authority).

Informations stored there are:

  • User name
  • Domain name or work group
  • LM Hash
  • NTLM Hash

LSA writes in memory the informations linked to the local session but also remote RDP (Remote Desktop Protocol) sessions. Information on processes run by the "RunAs" command are also stored, and so are services launched by user accounts.

On systems prior to Windows Vista, the logon information stays in memory, even if the user has closed the session. From Vista on, these informations are removed a few minutes after the disconnection.

Once an attacker has local administrator privileges, it is possible for him to dump these informations. Once again, no need to code anything, there are tools for that, like Windows Credential Editor for example.


WCE output : options and successful dump for a local account


From the network point of view, several different authentication mechanisms are available on Windows systems.


  • LM Challenge/Response

Warning: the LM challenge/response here should not be mixed up with the LM hashes from the SAM database. The hashes in the SAM are used by the local system, while the LM challenge/response is an authentication via the network to access domains/servers.

This challenge/response derives from the LM hash though. The client initiates the authentication, the server responds with the challenge, then the client answers by completing the LM hash up to 21 characters, then divide it in 3 pieces of 7 bytes, using each as a DES key to encrypt the challenge.<LINK>

  • NTLMv1 Challenge/Response

This is the same challenge/response than for LM, except that the inition is not made with the LM hash but with the NTLM hash.

  • NTLMv2 Challenge/Response

A strong effort from Microsoft has been deployed here, to upgrade the security of the challenge/response.

The client initiates the authentication, the server sends the challenge back, then the client sends the answer: creation of a HMAC-MD5 hash based on username and domain name, with the NT hash as the key. The result of this operation is the "NTLMv2 one-way function (OWF)". The response is then created based on the HMAC-MD5 hash, the timestamp, and other items, using the NTLMv2 OWF as key.

- Kerberos

Kerberos is a network authentication protocol. It is based on a secret key mechanism and the use of tickets. No password is sent in clear text, avoiding the risk of any interception of the clear version of the password.

It is yet still possible for an attacker to generate particular Kerberos tickets to gain domain administrator privileges. These special tickets allow authentication even if the admin password changes. A famous tool within the security community, named Mimikatz, features "Golden Tickets" for Kerberos, see on the website for more information.


NTLM hashes do take much more time to be brute-forced than LM hashes, we have briefly seen why. Yet an attacker does not necessarily need the clear version of a user's password to usurpate his identity on the system: he only needs the hashed version of the password, which he could obtain from the SAM registry database or from the logon sessions.

With the password hash, the attacker can launch a "pass the hash" attack on the compromised system. Windows Credential Editor is once again useful here, as long as it is launched with local admin rights:


Screencapture showing a logon session dump and a successful Pass the Hash attack


Once the attacker has gained local administrator privileges, he will probably try to become a domain administrator for one or several domains. This will allow him to have full access to extend his compromise and acquire whatever he wants.

Often, attackers do browse through several local machines, collecting passwords, and hoping to fall on a domain administrator password. Companies generally do have naming policies for the computers in the network, helping the attacker to find "interesting" machines to which administrators would connect to.

A tool like keimpx helps checking credentials validity gained from one machine on all the network, but it can be detected easily.

APT attackers do generally prefer a manual exploration of the network, since they do have the time for it and it is more discreet.

Pentesters do have some interesting tricks, based on social engineering, because they have less time to compromise the whole system. As an example, they can call the HelpDesk, usurpate an employee's identity, explain they have a problem on the computer, and wait for the HelpDesk to connect to it remotely. If the HelpDesk uses an administrator account, the game is over.

We have to be aware that once the attacker is inside and has local administrator privileges, he will soon enough probably gain access to domain admin. The most difficult is generally to get the local admin from an unprivileged user.


Attackers do nearly all the time aim for the Active Directory (AD), which is a kind of Graal in their quest for high privileges and control of the whole network. Obtaining a complete dump of the AD is the goal.

In order to achieve this, the attacker will try to gain access to one or several domain controllers, being at least local administrator there, to dump the famous ntds.dit file.


Once the attacker has all needed accesses at hand, he's ready to explore the internal network of the targeted company. While this operation can be quite time-consuming, it is not always the case : sometimes the attackers only aim at particular employees which allows them to obtain all the information they want, sometimes even with the usual user privileges.

When they decide to go for a large network exploration, they do use the obtained credentials from the precedent phase:

- Use of particular user accounts - Use of domain administrator accounts or system administrator, when needed

The dump of the AD generally provides some interesting information to explore the network. The attackers often use psexec at this point to hop from one computer to another and go on exploring the network.

Attackers also often do use simple BAT scripts on a large amount of machines, to collect system informations automatically and help focus on interesting computers or servers.


When the attacker has a complete dump of the Active directory, there is no limit to his power. This comfortable situation allows him to explore the whole network and add different backdoors on several different machines. The attackers generally use different malware/backdoors, just in case one family is discovered by the target: they still would have another discreet point of entry to come back.

The phase of lateral movements is generally time-consuming for the attackers, but need very few computer skills. Therefore, it can be done by a "junior" profile who only needs to know the basics of command lines and how to use the deployed malwares.