Malicious code and the Windows integrity mechanism

Introduction

Ask any expert who analyzes malicious code for Windows which system privileges malware works with and wants to acquire and, without a second thought, they’ll tell you: “Administrator rights”. Are there any studies to back this up? Unfortunately, I was unable to find any coherent analysis on the subject; however, it is never too late to play Captain Obvious and present the facts for public evaluation.

My goal wasn’t to review the techniques of elevating system privileges; the Internet already has plenty of articles on the subject. New mechanisms are discovered every year, and each technique deserves its own review. Here, I wanted to look at the overall picture and talk about the whole range of Windows operating systems in all their diversity dating back to Windows Vista, but without discussing specific versions.

Step Back in Time

The Windows XP security model differs significantly from the security model of Windows Vista and newer operating systems. There are two types of user accounts in Windows XP: a standard account and an administrator account. The vast majority of users worked with administrator rights, despite the fact that they didn’t need the rights for everyday tasks. These people infected their systems with malicious software that acquired the rights of the current user and, more often than not, they were administrator rights. As a result, the malicious software did not encounter any serious problems acquiring elevated privileges in a system running Windows XP.

This mechanism was used until the release of the Windows Vista family, where Microsoft introduced a new security model: Windows integrity mechanism.

Integrity Level in Windows 10

Roughly speaking, the two aforementioned user account types are present in the new mechanism; however, the operating system now utilizes the Admin Approval Mode. Yes, that very same, our “beloved” UAC (User Access Control). As soon as there is a need for elevated privileges, a UAC dialog pops up and prompts the user for permission to perform a certain action.

The human factor is one of the primary security problems, and that is why placing responsibility on a user who doesn’t know the first thing about computer security is, to say the least, a questionable decision. Microsoft itself has issued the following statement on the topic: “One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all. UAC helps most by being the prompt before software is installed.” For those interested in Microsoft’s position on the matter, I recommend reading the following blog posts: User Account Control, User Account Control (UAC) – quick update, Update on UAC.

The Windows Integrity Mechanism

The new Windows integrity mechanism is the main protection component of the Windows security architecture. The mechanism restricts access permissions of applications that run under the same user account, but that are less trustworthy. Put more simply, this mechanism assigns an integrity level to processes as well as other securable objects in Windows. The integrity level restricts or grants access permissions of one object to another.

I won’t go into detail about the operation of the integrity mechanism. We only need one table to simplify interpretation of the gathered statistics: the table shows the connection between integrity levels and SID security identifiers (see Table 7) that identify the user, group, domain, or computer accounts in Windows.

Most applications launched by a standard user are assigned a medium integrity level. Administrators get a high integrity level; services and the kernel receive system integrity. A low integrity level will be assigned to an App Container, for example. This is a typical level for modern browsers that protect the operating system from possible malware intrusions from malicious websites.

Basically, the high level and the levels above it are the ones that malicious software aims for.

Lies, Damned Lies, and Statistics

Contemporary anti-virus products implement a comprehensive approach to system security. That’s why they use dozens of components that prevent malicious code from infecting the system at various stages. Those components may include Web antivirus, script emulators, cloud signatures, exploit detectors, and much more. Data entering the system goes through numerous scans initiated by the different components of an antivirus product. As a result, a huge number of malicious programs do not get to the execution stage and are detected “on takeoff”. As for me, I was interested in malware that did manage to get to the execution stage. A contemporary antivirus product continues to track the potentially malicious object, in that even in the event of its execution, behavioral stream signatures (BSS) of the Kaspersky System Watcher component can be triggered.

So, I asked our Behavior Detection group to assist me in collecting statistics for system privilege levels used for execution by active malware, and which can be detected with the help of BSS.

Within 15 days, I managed to gather data on approximately 1.5 million detections with the help of Kaspersky Security Network. The entire range of Windows operating systems, starting with Windows Vista up to Windows 10, was included in the statistics. After filtering out some events and leaving only unique ones as well as those that do not contain our test signatures, I ended up with 976,000 detections. Let us take a look at the distribution of integrity levels for active malicious software during that period.

Distribution of Integrity Levels

By summing up Untrusted, Low, Medium, as well as High and System, it is possible to calculate a percentage ratio, which I called “OK to Bad”. Although, I assume, the creators of malware would not view this ratio as being so bad.

“OK to Bad” Ratio

Conclusions

What’s the reason for these horrifying statistics? To be honest, I can’t say for certain just yet; a deeper study is required. Sure enough, virus writers employ different methods to elevate privileges: autoelevation and bypassing the UAC mechanism, vulnerabilities in Windows and third-party software, social engineering, etc. There is a non-zero probability that many users have UAC completely disabled, as it irritates them. However, it is obvious that malware creators encounter no problems with acquiring elevated privileges in Windows; therefore, threat protection developers need to consider this problem.