How to bypass Windows security

How to bypass Windows security

It was once thought that Windows Local Security was like a wrought iron gate with a tricky lock standing in the middle of a blank field: it looked formidable, but its effectiveness was questionable. Times change, and the winds’ security mechanisms have evolved little by little. Today, we will talk about how security is organized in modern versions of Windows.

How Windows security system is set up

Security system essence

In Windows, all active entities that can be authenticated by the operating system (users or groups) are called security principals. All security principals have a unique variable length identifier, the Security ID (SID). The SID structure is as follows – S-R-IA-SA-RID, for example S-1-5-21-1687231434-1254558764-1544283289-1004, where:


    • .

    • S – literal prefix, indicates that the identifier is a SID (it’s just a naming convention);
    • R is a single-byte value of the version or revision (revision) SID. So far only version 1;


    • IA – issuing authority, six-byte value. Indicates in whose area of responsibility the SID was issued (literally authority means “authority”). Almost always has a value of 5 (SECURITY_NT_AUTHORITY), except for the SIDs we will talk about later. For example, 1 means SECURITY_WORLD_SID_AUTHORITY and refers to the well-known group Everybody;
    • SA – authorized center (sub-authority). The unique (within the IA) value consists of four parts: a 4-byte number that indicates who issued the identifier (domain controller or local computer) and a 12-byte value that is divided into three parts and identifies the specific object that issued the identifier. The meaning of this field is that if there are multiple domains in the forest, objects in different domains will have a unique SA;


  • RID – relative identifier (Relative-ID), 4-byte value, serves to separate objects within a domain. For built-in accounts RID will always be the same (e.g. for an administrator account RID = 500).

To be more precise, there are machine SIDs and domain SIDs. And the SID itself is a basic identifier (S, R, IA, SA) + RID.

There are also standard so called well-known SID for users and groups. They have the same SID on any system (e.g. group Everyone or user System).

You can search for the SID using the utility PsGetsid.exe from the Sysinternals package. And you can read more about the structure of the SID, for example, in these publications:


It is also possible to have a small defect in the administration due to seat duplication. Sometimes it affects security or functionality (for example, when the operating system is deployed simply by copying a disk). You can read more about this in Mark Russinovich’s article, one article and in VMware knowledge base.

The SID, in turn, is part of the so-called access token – a program object (structure in the Windows kernel), which is attached to the session (logon session) of security participants after authorization. The issuance of the token, as well as authentication, is the responsibility of LSASS (local security authority subsystem).

Among other things, the token includes the SID of the user and his groups as well as mechanism privilege to perform any actions (e.g. debug privilege, which by the way is used in mimikatz to access the system processes).

Once the last token associated with a session is removed, LSASS also removes the session itself – thus ending the user session. You can learn more about the structure of the access token in the kernel debugger with the command dt_TOKEN. In general, if you can’t google the details of the Windows internals, you can examine the structure yourself using the debugger tools. Details can be found in Microsoft documentation. Privileges can be associated, for example, with things like bypass traverse checking.

Windows Security Access Markers

Access tokens can also have security problems. Here are a few links to learn more:

In turn, for “passive” objects, which are designed to provide external access to them (they are called securable objects), used SD – security descriptor. This is a descriptor to control access to these objects (for example, the process may have SD or SD can be bound to a file in NTFS). SD also, by the way, have security descriptor with security.

Security descriptor includes ACL (access control list), which are of two types – SACL (needed to log access to the object) and DACL (needed directly for access control). In turn, ACLs include an ACE (access control entry) – each ACE is designed for the specific subject that is being accessed and contains the type (deny or allow) and access mask. Properly configured ACLs allow to block unauthorized access to objects within the system.

However, if someone boots up on such a computer in Linux or pulls out a hard drive from a Windows machine and installs it in the same Linux, they can read the data. In Windows, you will only be able to access the data from someone else’s NTFS media if the user or his group on another system has the same SID – for example, if there are too many rights to the groups in the ACL.

Only encryption can protect against this, but you should be more careful when choosing and using the tool (see articles on encrypted container problems VeraCrypt and BitLocker and NAS vulnerabilities).

In the Windows kernel, ACL checks are performed using security reference monitor and object manager. Granting access looks like this: the subject (user) after authorization receives an access token, then the subject accesses the file, the system compares the necessary data from the access token with the corresponding ACEs in the DACL object, and depending on the permissions the subject receives access or denial.

Get access

You can read more about ACL/ACE at Microsoft or at Also the mechanism Mandatory Integrity Control, which checks access to the object by the level of reliability of the one who requests it.

By the way, DACL privilege escalation was used in last year’s vulnerability CVE-2019-0841. A patch released in a crooked fashion is a familiar rake. Also in 2018 there was a vulnerability CVE-2018-1036 related to permission traversal.

In addition to privileges, there is another way to control user actions that require administrator rights. A well known UAC (User Access Control). Of course, this is not ideal, so here are some old links for further study of UAC traversal techniques.



Authentication and authorization

As mentioned earlier, LSASS is responsible for authentication. In fact, of course, it looks more complicated than that. Here is a schematic of the authentication mechanism for older versions of Windows.

Briefly it works this way: LSASS receives authentication data (password, biometrics, etc.), then Windows performs authentication. The hash from the authentication data is stored in the SAM and the user process is assigned an access token. The known problems is that it is possible saved hashes to surrender (for example with the help of the well-known mimikatz) and conduct a pass-the-hash attack.

On Windows 10 added Credential Guard (by the way, there is a new process with it – Lsalso.exe). This mechanism was supposed to protect, in particular, from using mimikatz. But for each trickster there is a different witness.

First of all, Credential Guard is an optional function that can be disabled. Since Credential Guard is based on the Virtual Secure Mode (VSM) mechanism, which in turn is based on the CPU virtualization mechanisms, we should not forget hardware vulnerabilities that allow us to bypass Credential Guard.

Finally, you should remember that the password you entered traverses some path before being saved in the computer for subsequent authorization. This means that it can be obtained with a keylogger or a custom SSP (security support provider). The latter is possible using mimikatz – the recent article. Apart from mimikatz, the password can be captured by Empire, SharpSploit or PowerSploit, which essentially uses an integrated mimikatz. An alternative to PowerSploit is the following commands:

Import-Module .\PowerSploit.psm1
Install-SSP -Path .\mimilib.dll

For general development, it will be useful to read the pass-the-hash presentation for Windows 10 presented by the institute SANS, and learn the basic methods protections against mimikatz in an Active Directory domain.

Naturally, social engineering methods will also allow you to bypass Windows security systems. For example, you can use msf and msfvenom to get a reverse-shell, upload it to the target system special executable file to simulate the authorization window and then run it from the shell. The user will see a window like when logged in – the tool checks to see if the password is correct.

By the way, there is old trick to bypass the login window, which surprisingly can work in Windows 10. The essence of this method is that you need to replace sethc.exe with cmd.exe by simply renaming it, and then call sethc.exe by pressing the Shift key five times. After that you can change the user password. Back in Windows 10, you can do something like this:

    1. Paste bootable USB, reboot the computer, then press Shift + F10 to open cmd.exe.
    2. Enter move D:\windows\Sstem32\utilman.exe D:\windows\system32\utilman.exe.bak.
    3. Type cmdto utilmanto enter the command copy D:\windows\system32\cmd.exe D:\windows\System32\utilman.exe.


    1. Reboot the computer without bootable USB.
    2. Click “Special features” after downloading (next to the power off button in the authorization window).
    3. To create a new user, enter the command net user youruser /add.


    1. To add a new user to the administrator groups, use the command net localgroup administrators youruser /add.


You can achieve this effect if you already have access to a system with registry editing rights. In this case you need to add a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ add a utilman.exe section where you can write a key with the type String Value and a value as a path to the desired program. This program will start when you try to open the special features window.

Again, disk encryption saves you from this. To prohibit changing the password of a certain user, you can use a Microsoft account instead of a local one. You can also disable utilman.exe and sethc.exe for all users. And additionally enable Secure Boot and put the password on BIOS/UEFI. By the way, this trick was shown in the series Mr.Robot in the third episode of the fourth season.

Also for the login window bypass there is old, but still a working tool (Windows 10 supported) called kon-boot. However, it works with some limitations (e.g. it is not supported with secure boot). To protect against it, you need to enable functions in your system that the tool does not support. And of course, we should not forget about HID attacks.


Post Operation

It often happens that exploitation of the vulnerability leads to access, for example, to a web server account rather than to an administrator account. There are two ways to do this: increase privileges and look for interesting information that you have access to. If you’re talking about a domain computer, you can also get useful information from a recent article collecting information in the domain. There are many scripts in the compromised system to find interesting information, for example winPEAS, Seatbelt, Powerless, Privesc, Sherlock, JAWS, Watson and SharpUp.

But you should consider that such scripts are “noisy”. Especially programs requiring .NET may not work if the system is configured with White list software.

WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Do NOT follow this link or you will be banned from the site!
Would love your thoughts, please comment.x

Spelling error report

The following text will be sent to our editors: