Have you ever think about what rights your created file has, or what access rights I can use, what is UAC at all, how does "As Administrator" launch right work, and how to abuse it all?

In this article, I will describe how to bypass the security solutions of the system itself, thereby improving or adding more access to our program.

If you are a proficient programmer who has already written some tools, or was thinking about accessing or interfering with the system, you have surely encountered a problem of access rights. But what are these rights and how to circumvent them?

The system itself runs in several modes, which I have described in the past. The lowest is the Kernel, the layer from which the drivers are started. The top layer is the Application Layer, a classic run under the desktop.

A great description of the layers is in the image from the page (http://minnie.tuhs.org):




Unlike XP, the current MicroSoft OSs have UAC (User Account Control).
It is a technology that limits the rights of applications that want to modify the system in some way. UAC modes allow the OS to set into several modes, from shutdown to continuous polling.
More on UAC- >> Article <<

UAC itself can be nicely destroyed through registers. However, access to the registry can be disabled for the first time before we want to access it.

Windows Integrity Levels

Windows Integrity Levels are access levels available for example Win8, Vista.
These levels are for accessing processes or threads (interesting for hooking or jamming).
As you write your apps, you need to learn about the barriers that these levels bring.
There are 5 levels of access - from the lowest level: Untrusted, Low integrity, Medium integrity, High integrity, System integrity.

The principle of levels is that lower-level objects are not authorized to access higher-level objects.
A process running with a Medium Integrity level cannot query for a higher level process / thread, for example, System Integrity.
Querying access would end with an Access_Denied event.

If you run the application as usual, it runs in Medium Integrity Level.
The application that you run "As Administrator" or in "Elevate" mode will run at Hight Integrity Level.

However, is it possible for a program running in Hight Integrity to normally access System Integrity Level processes or threads? ... Not ...


If not, how can you write an application that will access this level?

Run as Administrator

Sure everyone knows the possibility <right mouse click> --> Run as Administrátor.
This launch option allows us to launch the application as an administrator, so we confirm to the system that we know what the application is.

The application will run in mode Hight Integrity.

But how can we tell the system itself that we want to mark our program as directly executable with admin privileges?


ELEVATE right settings

Unlike the "run as administrator" option, this option differs from the icon that appears at the program icon:

How to set this option for our program consists of setting directly in the Visual Studio development environment:
Project properties, (not solutions!) --> Configuration Properties --> Linker --> Manifest File.
Setting:

And:
Manifest Tool --> Input and Output





Maybe I supprise you, but this is not enough. This is not enough if we want to write applications that have even more access rights than just an administrator.

Yes, If we want rights Authority SYSTEM, we will write and install own driver.
This will be shown in another article.

However, it has never happened to any of you that he wrote a program in Visual Studio, such as accessing through WinAPI, which he had via startup from Visual Studio full rights(worked as it should), with doubleclick  under desktop or
"as Administrator", had rights limited, could he not have access to resources he could access through Visual?


We access to System Integrity Level

Normally, applications, processes, or threads should not initially access System Integrity objects.  System Integrity. Unless it is a driver or part of a system introduced as a service. The running process itself does not have such strong characteristics as the driver loaded before the actual loading of layers higher than the kernel and cannot take control of eg antiviruses or hide in the system, infect the system core files, etc. . Maybe we'll see later.

However, WinAPI can gain System Integrity Level privileges for hoc processes running under the desktop and access top-level objects.
Most have already learned that in this way we can write applications that can take control of these objects, and it is clear that throwing / jamming / hooking is just a small amount of what we can do.

Obviously, the subsequent use of WinAPI is dangerous for the abovementioned options:

When accessing the highest level, the so-called right is used - SeDebugPrivilege



I write a function that uses SeDebugPrivil. Gives the highest level of access for the application:

int DebugPrivilege()
    {
      HANDLE dHandle;
      TOKEN_PRIVILEGES dPrivileges;
      TOKEN_ELEVATION dElevation;
      LUID dLuid;

      if (!::OpenProcessToken(::GetCurrentProcess(),TOKEN_ADJUST_PRIVILEGES|TOKEN_QUERY,&dHandle)) 
      {
        return ::GetLastError();
      }

      if (!::LookupPrivilegeValue(NULL,SE_DEBUG_NAME,&dLuid)) 
      {
        return ::GetLastError();
      }

      dPrivileges.PrivilegeCount = 1;
      dPrivileges.Privileges[0].Luid = dLuid;
      dPrivileges.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

      if (!::AdjustTokenPrivileges(dHandle, FALSE, &dPrivileges,sizeof(dPrivileges),NULL,NULL))
      {
        return ::GetLastError(); 
      } 

      ::CloseHandle(dHandle);   
    } 

The function returns a possible error value.

-----------------------------------------------------------------

Whole function is included in header WinAPI.h ►WinAPI.h◄

#include "WinAPI.h" //https://www.netbot.sk/en/14-blog-headers/44-winapi-en

int _cdecl main (void) 
{
  ::Diall_WinApi::WinApi::GetInstance()->SystemIntegrity(::Diall_WinApi::Privilege::ENABLE); 

   return 0;
}

​