Volatile Kernel Rootkit hidden process detection in cloud computing

Abstract

The rootkit industry has advanced significantly in the last decade. Attackers want to leave a backdoor for quick reoccurring exploits rather than launching the traditional one-time worm/virus attacks. Meanwhile, as intrusion detection technologies improve, rootkits have grown in popularity. For the attackers to succeed, stealth becomes critical. The primary function of rootkits is to provide stealth. The modifications a rootkit makes conceal the presence of a rootkit. Determining the presence of mutation rootkits was quite challenging. Attackers can silently alter volatile (processes) and non-volatile (files) with the aid of rootkits without being noticed. We suggested the VKRHPDV (Volatile Kernel Rootkit Hidden Process Detection) framework to find the hidden techniques. This system includes process monitors, process comparison analysts, and contaminated process data gathering. Process monitoring is nothing more than clean process collection in the absence of rootkits, whereas pure process collection has been corrupted by rootkit injection. The process analyzer compares clean and tainted processes, some of which were concealed. VKRHPDV can identify process hiding behaviors in all datasets in the shortest period, according to the findings of an extensive performance analysis carried out on 64 rootkit datasets for each UNIX and Windows kernel in a cloud environment.

Introduction

The purpose of rootkits is to penetrate a computer system or network without authorization and take control of it. While operating, they want to remain undetected by the user and other security software. Rootkits [1] frequently target a system's "root" or administrative level, which gives them a wide range of rights and power. They can alter or replace essential system files, listen to system calls, and change how the operating system behaves. This enables them to avoid detection by standard security measures and antivirus software. It needs detection for target systems. There are different types of rootkit detection, like Signature-based detection [2], Heuristic-based detection, Memory analysis, Rootkit [3] scanning tools, System integrity checking, and Network monitoring. These types of rootkit detection detect only a limited number of rootkits, but it does not update the new mutation rootkit. This work includes Process comparison analysts, process monitors, and data collection on tainted processes. In the absence of rootkits, process monitoring is nothing more than clean process collection, but clean process collection has been tainted by rootkit injection. Process analyzers compare pure and tainted processes, some of which were hidden. According to the results of a complete performance investigation performed on 64 rootkit datasets for each UNIX and Windows kernel in a cloud environment, VKRHPDV can detect process-hiding behaviors in all datasets in a short period.

Related work

Rootkit [4]: This is associated with "criminals waiting to rob you while you are away in the upstairs room." Many specialists advise entirely wiping your hard drive and starting over because it is the hardest malware to detect and remove. Allowing other details computer viruses into your computer so that it can collect identification information from it without your understanding is recommended. Individuals trying to access the PC for financial gain create such malware. Rootkit [5, 6] identification in distributed computing management anticipates a crucial job. This inquiry is related to a few previous studies on distributed computing [7], structure, and acknowledgment systems in general.

These techniques are described in the most recent rootkit disclosures [8], which cover signature, conduct, cross-view, respectability, and equipment. The way to distinguish rootkits that is most frequently employed is the mark-based location method [9]. When antivirus software detects malware, it recognizes a "sign" specific to the pathogen's byte case and saves those antecedents in a DBMS. Location-based coding compares examples from the framework to database markers [10].

The system's two distinct views of the system are presented differently to detect contrasts in cross-view rootkit discovery. This process obtains an unusual state perspective of the framework from a vulnerable malware control area. Whatever the rootkit conceals will not be detected by the strange state. Because it presents a genuine perspective on the template rather than assuming that the framework reports are essential, this methodology recognizes the external view as the framework's verified perspective. The most excellent strategy for dealing with stealth malware is clean booting, which prevents the infection from hiding. Given that the OS and the malware are not functioning, it cannot protect records or techniques from an external source. For Windows 2000 systems, the fresh boot method uses the setup wizard to launch the framework into Disk OS mode and examine the archive structure. The framework must be established in Disk OS mode using external tools when Windows 8.1 is first booted.

The current view of memory or the file system is compared to a trusted standard obtained when the system was flawless. Any improvements could reveal a rootkit's capabilities on the system. Because external equipment is unlikely to compete for resources with the backdoor, equipment-based rootkit discovery was born as software identification does. External hardware, like external programming, reduces framework activity. The benefit of equipment rootkit discovery is that the rootkits cannot alter the equipment because it uses an external OS. This research shows a bridge clean boot-based discovery technique that detects some of the rootkit's persistent systems. The proposed system aims to see rootkit-hidden records.

Methods and materials

Rootkit applications available on the Amazon web services stage typically attempt to conceal some information while they are running. In any case, execution has only been seen rarely in current software. The system's boot-up time is reduced as a result of this. From this point forward, it is crucial to separate the protest hiding behavior, which is fundamentally classified as a rootkit behavior and significantly impacts the execution of Amazon web services cloud setup, especially in over-the-top load assignments. It is crucial to identify the covered documents to improve the heap characteristics and net execution of the current cloud configuration. The proposed rationale defines a transparent system for identifying non-unstable rootkits.

In light of the study, it is crucial to create and alternately examine the clean process list and contaminated process list to separate the covered documents automatically. It is sometimes challenging to obtain the appropriate segment document list since the presence of rootkits rapidly alters the framework's direction. Even with minimal structural information, guessing the optimum parcel record list is still possible. The gauge is consistently trusted to reflect reality and is never given access to rootkits. Accordingly, rootkits known as the tainted process list occasionally trade-off and control what the client sees.

P1 stands for the clean process list, and U1 for the contaminated process list due to the catalog. The clean process list P reflects reality and is unaffected by rootkit manipulation. The corrupted process list U indicates the user's perspective, which is open to rootkit attacks. U R1 (Time1) refers to the set of corrupted process collections of type R1 that are shown to the user at time Time1, and PR1 (Time1) represents the set of pure process lists of type R1 at time Time1.

Assume Entry1 is an entity (or process)

$$\mathrm{Time T}1,\mathrm{ Entry}1\mathrm{ st}.,\mathrm{ R}1=\mathrm{R}1 (\mathrm{Entry}1)$$

(1)

When object Entry1 is concealed, then

$$\mathrm{PR}1 (\mathrm{Time}1) \bigwedge \notin \mathrm{ U R}1 (\mathrm{Time}1)$$

(2)

else If

$$\mathrm{P }(\mathrm{pure\, process})\mathrm{ R}1 \,(\mathrm{T}1) \backslash \mathrm{ U }(\mathrm{corrupted\, process})\mathrm{ R}1\, (\mathrm{T}1) = \oint$$

(3)

RE stands for every form of system entity that could exist, including files, processes, ports, etc.

$$\forall \mathrm{R}1 \in \mathrm{ REntry }\{\mathrm{ T}1\mathrm{\, for\, All \,Time}\}$$

(4)

About each kind of R1's efficient system,

The results P and U can be obtained as follows to enable the detection

$$\mathrm{P}=\cup \mathrm{R}0\in \mathrm{R P R}1 (\mathrm{T}1) \{\mathrm{ Time T}1\}$$

(5)

$$\mathrm{U}=\cup \mathrm{R}0\in R U\mathrm{ R}1 (\mathrm{T}1) \{\mathrm{ Time T}1\}$$

(6)

The problem is solved by employing cross-view-based identification. In this approach, separate lists are created and analyzed for clean and contaminated processes as part of cross-view-based detection.

Systems design

The proposed system VKRHPDV design, which is depicted in Fig. 1, is used to detect the existence of hidde processes.

Fig. 1

The Architecture of Volatile Kernel Rootkit Hidden Process Detection View (VKRHPDV)

User mode is also known as user space or Ring 3. It is a restricted execution mode where user applications and processes are run. Examples of user mode activities include the execution of applications, files being opened, network resources being accessed, and interaction with the user through the graphical user interface. Kernel mode is also known as privileged mode, supervisor mode, or Ring 0. Unrestricted access to hardware is granted to the kernel, allowing it to execute any instruction and access any memory location. Critical system operations, such as memory management, interrupt handling, task scheduling, and hardware device control, are performed in kernel mode.

The three crucial components of VKRHPDV are Process Monitor, Compare Process Analyzer, and Process Enumerator. System calls are received and interpreted by the OS libraries to perform process activities, and these system calls are utilized to maintain an excellent and up-to-date sequence collection. The process collection is then revived, stored in the index, and provided to the detection method as needed. The refreshed list can be retrieved by the userland program running on the Amazon Web Services Windows 2022 new host.

The initial process without the injected rootkit, which falls under the process monitor, forms the clean process collection. This process is then repeated with the injection of the rootkit, resulting in a group of tainted methods gathered in the process enumerator. In the comparing process analyzer, the contaminated process collection and clean process collection are compared, where some processes may be hidden. The detection of hidden processes occurs in the AWS Ubuntu Server 22.04 LTS (HVM) operating system with SSD volume type.

Designing the clean process list

Process Monitor is the first module in the Volatile Kernel Rootkit Hidden Process Detection View. In AWS, the Windows operating system is launched. Clean process collection is one of the operations performed in Process Monitor.

• 1. Initialize the clean process list when the Aamzon web service-Windows 2022 server instance has been initiated.

• 2. add a new procedure to the collection for every new process.

• 3. For each new process, update the clean process collection.

From the procedure, the accompanying activities were inferred:

No attack occurs while launching new AWS Windows instances because the rootkit is not injected. The process is collected and referred to as clean process collection. This process falls under the purview of the Process Monitor. This method generates the pure process list T1, which contains dynamic processes using low-processing system call information. It is based on the knowledge that the operating system uses specific system calls (in this case, AWS-Windows 2022 Server) to carry out both new and legacy functions.

On Windows, for instance, several Win32 APIs, such as Build System and WinExec, are frequently used in the client space to create new methods. Thus, these abnormal condition APIs are called a collection of low-level frameworks. It is also possible to explicitly use system calls to construct processes. The process manages creation by responding to those system calls in any scenario. As a result, by collecting these associated system calls, a process can screen its beginning and end. Rootkits must never change the trusted view. Given this premiere, the growth of trusted opinion should be as minimal as possible given the normal situation.

The information used for reliable perspective is limited enough that rootkits cannot significantly impact or overtake it. From one perspective, it is challenging to create a procedure with only an operating system because these system calls are attacked and, in general, unrecognized, regardless of whether it is possible to develop a technique without declaring any abnormal state Windows APIs. This dramatically expands on current rootkit design ideas as a rootkit must execute particular Windows operating system components to evade these system calls. Of course, terminating a process is less demanding than creating one, and it may be possible to complete an operation without a regular cycle. False positives could happen if those system calls for process termination are followed through with. In any case, rootkits will benefit from using such frameworks because they cannot conceal any system.

Tainted process collection

The Tainted Process Collection is the second module in the Volatile Kernel Rootkit Hidden Process Detection View. In AWS, the Windows operating system is launched. Tainted process collection is one of the operations performed in Process Enumerator. To detect all rootkit-hidden records, create an infected process list and differentiate it from the clean process list. The corrupted process list contains processes that are unmistakable to system clients; therefore, it is critical that every covered report be avoided. On a fundamental level, there are three places to get the tainted process list system:

• The tainted operating system itself

• The corrupted operating system's kernel space

• The contaminated operating system's client space

The primary option is navigating the corrupted operating system's dynamic simulation list to determine the operating procedures. However, this list also includes operations that client-level rootkits and snare [10, 11] based kernel-level rootkits cover-up. Because these procedures are typically invisible to clients, there may be Zero negatives when comparing the polluted OS process list to the clean process list.

The catalog record rundown of the compromised operating system would include a few documents hidden by client data rootkits [12] and specific kernel-level rootkits, leading to Zero negatives for the second option. As a result, it is decided to create a process list of the corrupted operating system in the user space of the corrupted operating system. In contrast to the clean process collection, the process collection of a contaminated operating system does not expect to be unaffected by rootkits, and its development should be as abnormal as possible, with the end goal of completely exposing all rootkit controls.

Comparing the process analyser

Comparing process analyzer is used to compare clean process collection and tainted process collection. While comparing the process, if there is a difference, the process is hidden or not hidden. When instructed by the procedure, the compare process analyzer [13] adapts the contaminated process collection from the correspondence support in the corrupted operating system. It is decoded, and its validity is checked before the corrupted process list is compared to the unmistakable segment record shown. If the confirmation stops working, a notification message shows a potential attack on the contaminated operating system.

The breakdown report analyzer looks at the two document lists once the clean process collection and the tainted process collection are ready. The record analyzer searches the folder collection of corrupted Operating Systems for each document list in the spotless segment record list. If the report is also found in the corrupted OS's process collection, it continues with the accompanying document in the clean process collection until all records are dealt with. If any description from the pure process collection is missing from the catalog of tainted OS, it is considered a covered archive. The record analyzer then refers to the covered report and provides more information about it. When hidden processes are found, rootkits may have infiltrated that process.

The following algorithm-1compares the clean and tainted process lists to identify hidden processes:

Algorithm 1. cmpCPL-PLT

Algorithem :1

The rootkit was injected into the machine with the clean operating system. The term clean process collection was given to the process collected from this operating system, which is kept in the process monitor. The same machine was corrupted and became known as having a tainted operating system after the rootkit was introduced. The process was collected and updated by the impaired operating system. After an update, when the clean process collection and tainted process collection are compared, if there is a difference, the process should be hidden; otherwise, it should not be hidden.

The issue declaration states that the two perspectives under consideration, T1 and U1, must be created simultaneously. In any case, there could be a brief delay between stages three and four; as a result, this methodology examines two nonconcurrent sees developed on separate occasions. This may be fine on an inactive framework. Still, it may impact the identification result of a functioning system where processes are created regularly. Check to see if this will cause any zero positives or zero negatives.

The clean process collection at time1 is distinguished from the tainted group at time2. This recognition calculation deduces that time2 comes after (time1 time2). When a system starts, it is indicated by an A timep1; when it ends, it is stated by a T'p1. Within the day and age, the following things could happen between time1 and time2.

• If ∄p1 time1 < timep1 < time2 or time1 < time'p1 < time2 is made or ended somewhere in the scope of time1 and time2, then the time qualification can essentially be ignored because the system remains the same, and the outcome of the discovery is unaffected.

• If ∃p1 the procedure P1, which starts before time1 and ends somewhere between t1 and t2, happens with the true objective that time1 < timep1 < time2 or time1 < time'p1 < time2, Recognize that if p1 is actually not one of the covered documents, p1 ∈ T1 anyway p1 ∉ U may produce a false positive.

• If ∃p1, which is made and ended at between time1 and time2, has the main objective that time1 < timep1 < time2 < time'p1 < time2. Recognize that p1 ∉ T1 regardless of p1 ∉U, so the outcome is unaffected. In any case, p1 may have a zero negative if the record is covered.

• The procedure ∃p1, which is performed there between time1 and time2, has the ultimate goal of time1 < timep1 < time2 < time' p1 < time2. The calculation shows that the result is unaffected by p1 ∉ T1 regardless of p1 ∉U. However, a false negative is possible if p1 is a covered document.

Based on the above examination, the identification may result in zero positives or zero negatives. When the following scenario happens, the trusted in view (clean fragment file collection) would be renewed and would appear differently in comparison to another most tainted process list. This refreshing and contrasting would continue until the system became consistent, as it was in the initial condition. The likelihood of false positive focuses in the second scenario is low because the time interval between time1 and time2 is close to zero, and there is no reason to think that false negatives will be a problem. For starters, potential results for the last two conditions are limited because the break between time1 and time2 is practically nothing. As shown in the third condition, a brief strategy does not need to be concealed: the client will most likely not see whether it is covered. According to the definition, this is not a rootkit procedure in this case. As a result, zero negatives, in this case, will be insignificant before long.

Implementation

A root account must be created in the Amazon Web Services Management Console to activate Amazon Web Services. Then, choose "Launch Instance" on the Amazon Elastic Compute Cloud Dashboard to build and customize your virtual computer. You can configure your instance features in this wizard. Initializing your instance could take some time. SSH, PUTTY, and RDP are all options for connecting AWS instances. By choosing the Elastic Compute Cloud instance, clicking "Actions," then "Instance State," and lastly, "Terminate."

Figure 2 demonstrates the implementation process. In this trial, rootkit tests for VKRHPDV are being run in a cloud environment provided by Amazon Web Services. To begin, run the VKRHPDV on an Amazon-provided (first event tainted OS) Microsoft Windows Server 2022 Full Locale English AMI with an Intel Xeon Family 3.70 GHz CPU and 16GB RAM. With administration pack First, the framework is a standard foundation. Second, use another example AWS Ubuntu Server 22.04 LTS (HVM) with an Intel Xeon Family 3.70 GHz CPU and 16GB RAM to run the VKRHPDV.

Fig. 2

Deployment of Volatile Kernel Rootkit Hidden Process Detection View (VKRHPDV)

VKRHPDV contains three essential components: Process Monitor, Comparing Process Analyzer, and the process collection of spoiled OS (process Enumerator). The OS libraries use these template calls to maintain a perfect, fresh segment collection by obtaining and decoding them when performing process actions. When the approach seems novel, the process rundown will be renewed and saved in the repository. The created list is evaluated using the corrupted OS's archive analyzer. The procedure screen maintains the dynamic processes and the apparent segment record list. How the process screen is configured depends on the operating system to handle system calls related to operations. It screens process workouts comprising the procedure creation and the end to keep the archive visible.

The rootkit was first presented in Windows, and its popularity will keep rising when it is made available on the internet. While detached, the rootkit's behavior is minimal. After the window is closed, the limit (volume) envelope is mounted to Ubuntu. The lead will be distinguished when setting up into another OS. Based on these qualifications, distinct proof of covered documents is created, a process known as VKRHPDV discovery. A clean boot is an identification technique that keeps malicious processes from hiding. Because the rootkit operates while the operating system is in use, it protects archives or operations from being accessed from external sources. For the Windows 2000 system, the ideal boot procedure, for instance, tests the file structure while booting the system into disc operating system mode from the boot menu. This assignment turns off a few rootkit features, which suggests that the certified positive rate should rise from 68.421% while the false positive rate stays at 0%.

Proposed algorithm

The three essential components of VKRHPDV are Process Monitor, Comparing Process Analyzer, and the tainted process list (process Enumerator). System calls are acquired and interpreted by the OS libraries to execute procedures, and these requirements and support are utilized to maintain a pristine collection of processes. Once the method is completed, the process list is updated and stored in the index. Once the technique is operational, the process list will be updated and stored in the index. This index is utilized to construct the collection of contaminated OS processes, aiming to maintain maximum irregularity within the given conditions to represent the view observed by consumers accurately. The resulting group is then analyzed using the tainted OS report analyzer, which establishes process relationships. Maintaining these dynamic procedures and the distinct process collection is entrusted to the process display. When configured, the operating system handles system calls related to methods. The process display monitors various process activities, such as initiating and completing procedures, to maintain a visible record. As a result, regular feedback is provided. The implementation of this model, as depicted in Fig. 2 VKRHPDV, elucidates the process. The model is used for performance analysis and seamlessly integrated into the Amazon Web Services cloud environment. Accuracy, P precision, recall, F score, and G mean are accuracy parameters. In terms of efficiency, this model surpasses its predecessors.

Begin the EC2 Windows example setup. Create a procedure in VKRHPDV that looks like a clean segment document and a tainted process list. Display the rootkit in the tainted OS's index rundown. One by one, annex the 3TB/5TB/ 7TB volumes to the Windows model. The Windows envelope is moved to 3TB/ 5TB /7TB volume one by one, and then the Windows precedent is closed, limiting the 3TB/5TB/7TB volume from Windows cases one by one. Start the EC2 Ubuntu instance. Join the three tb/5tb/7tb volume to the Ubuntu model individually. Install Ubuntu on the three tb/5tb/7tb volume. The clean and tainted processes are examined, and what makes a difference is discovered. If there is a distinction, it is a direct result of the covered documents.

Algorithm 2 a. a Function VKRHPD for Windows

Algorithem-2 a

An AWS account was created, and Windows instances were launched into the AWS account. For testing purposes, seventy-four rootkits were used. The clean process collection and tainted process collection were collected. One by one, 3TB/5TB/7TB were attached to the Windows instances. First, 3TB was connected, and the Volatile Kernel Rootkit Hidden Process Detection View was executed. The clean process collection and tainted process collection were compared. The process was hidden if there was any difference; otherwise, it was not hidden. The time taken to detect this was known as the Rootkit detection time, and then 3TB was detached. Next, 5TB was attached, and the detection time was calculated before detaching. Finally, 7TB was connected, the detection time was calculated, and the detection time varied based on the storage capacity (3TB/5TB/7TB). If the storage was minimum, the detection time was also minimum; if it was high, the detection time was also increased. The calculated detection time results are shown in Table 3.

Algorithm 2 b. b VKRHPD for Ubuntu

Algorithem-2 b

An AWS account was created, and Ubuntu instances were launched into the AWS account. For testing purposes, seventy-four rootkits were used. The clean process collection and tainted process collection were collected. One by one, 3TB/5TB/7TB were attached to the Ubuntu instances. First, 3TB was connected, and the Volatile Kernel Rootkit Hidden Process Detection View was executed. The clean process collection and tainted process collection were compared. The process was hidden if there was any difference; otherwise, it was not hidden. The time taken to detect this was known as the Rootkit detection time, and then 3TB was detached. Next,5TB was attached, and the detection time was calculated before detaching. Finally, 7TB was connected, the detection time was calculated, and the detection time varied based on the storage capacity (3TB/5TB/7TB). If the storage was minimum, the detection time was also minimum; if it was high, the detection time was also increased. The calculated detection time results are shown in Table 3.

In the Ubuntu instance, the detection time was significantly less when compared with the Windows instance. The compared detection times of Ubuntu and Windows instances are shown in Fig. 3 (a, b, c).

Fig. 3

Rootkit detection time for Windows and Ubuntu. a Detection Time of 3 TB. b Detection Time of 5 TB. c Detection Time of 7 TB

Performance analysis

VKRHPDV was tested on a model set consisting of nineteen rootkit tests, most freely available on the internet [14], to determine the feasibility of an outcross view and clean boot-based rootkit identification system. Table 1 [15] summaries the characteristics of the data parameter rootkit tests based on if they are a portion of a user space string, as well as which systems (catching and DKOM) they change during the cover process.

Table 1 Parameter information

The experiment is run on the perfect boot system in Win 2022 against 74 rootkits, with each test failing to delineate the cloud. The rootkit is presented for each test and run against a fresh boot system. This system produces no false positives (zero false positives, 100% certified negatives). We anticipate that the ideal Windows instance system will remain pristine.

In this research, 74 rootkits were tested for rootkit detection. Six rootkits are in the validation set, while the other 68 are invalid. True positive 13 rootkits of the 68 rootkits(55 are added with 13) are distinguished, while the additional 55 are not. True positive 13 rootkits are added with false negative six rootkits, and together, 19 rootkits were tested and listed above in Table 2. This result is 23.63% obvious positive and 76.36% false negative. An erroneous rootkit installation setup caused the false negative. Assailants learn how to install the rootkit perfectly, and the false negative rate decreases. The limitation of rootkit-covered records is illustrated in Table 1. (legal and ill-legal rootkits).

Table 2 Ambiguity matrix of VKRHPDV examination

A few other rootkits conceal transparent files, while others hide files and folders. Before testing, virus total examines each rootkit [16] and assigns a specific name from K7, Symantec, McAfee, and others. Table 1 shows that the first six rootkits are in the confirmation set, while the remaining rootkits from 7 to 19 are not. Agent WXK, Form.fam, Virus.Boot.ASBV, W32/Trojan2.NFKE,NYB, and HackTool/Perl are six Win32 rootkits. CleanLog encloses all of the files, and the rootkits are validly set.

In the analyses, VKRHPDV has viably recognized covered records for all the models. The acknowledgment results are shortened in Table 3. VKRHPDV can distinguish hid documents if a rootkit test can viably cover them. This examination assumes that the limit volume remains reliable; thus, the invention time will be shorter. The storage is 3 TB, 5 TB, and 7 TB. In this case, the 3 TB volume exceeded the other two volumes regarding area time.

Table 3 True positive rootkit detection time

In Fig. 3 (a, b, c) illustrate how as volume size grows, so does time consumption. This system has high accuracy and a short rootkit [17, 18] recognition time compared to other rootkit methodologies, such as the point tactic and the device location procedure. The revelation time will be reduced if this examination's limit volume remains constant. The storage capacities are 3 TB, 5 TB, and 7 TB. The discovery system recognizes rootkit [19] shapes by creating and differentiating two unmistakable points of view. The advancement of the tainted process list is done in the customer measurement of the infected OS [20]. On the other hand, as in a contaminated Operating System, the advancement of the clean process list and the relationship of the two points of view are carried out (before the present rootkit). On the tainted OS [21], there are a manageable number of processes running. Our view examination calculation provides a small workload with the infected OS [22].

VKRHPDV dynamically maintains an archive list to generate the clean process list by retrieving and interpreting specific framework-specific system calls. The additional work may add to the runtime overhead.

Specification of detection

This template has five performance metrics in this measure. The first metric is the detection accuracy of the rootkit, which is written as

$$\mathrm{Accuracy}=\frac{\mathrm{Rootkit \,Tested}-\mathrm{True\, Positives}-\mathrm{False \,Negatives}}{\mathrm{Rootkit \,Tested}}$$

(7)

$$\mathrm{Precision}=\frac{True\, Positives}{\mathrm{True\, Positives }+\mathrm{False\, Positives}}$$

(8)

$$\mathrm{Recall}=\frac{True \,Positives}{True\, Positives \,+\,False\, Negatives}$$

(9)

$$\mathrm{Fscore }= 2\mathrm{ x}\left(\frac{Precision\, Recall}{Precision\,+\,Recall}\right)$$

(10)

$$\mathrm{G mean}=\sqrt{\mathrm{Precision }*\mathrm{Recall}}$$

(11)

Precision measures how many positive classifications are correct, i.e., the probability that a detected anomaly variance has been correctly classified. In contrast, accuracy is the degree to which the detector correctly classifies any newly tested data sample. The recall metric assesses the detector's capability to recognize variances accurately or the probability that an abnormal model will be appropriately identified. The final two metrics, the harmonic mean (F score) and geometric mean (G mean) give a more comprehensive picture of a detector's performance by partially accounting for all of the results (Fig. 4).

Fig. 4

Performance Measure

Conclusions and future work

This paper uses an original thought of the Volatile Kernel rootkit hidden process detection View (VKRHPDV) of a procedure to rootkit [23] recognition. This procedure's accuracy is excellent, and the rootkit [24, 25] ecognition time is fast compared to other rootkit finding techniques like mark-based systems and equipment-based recognition techniques. The discovery time will be reduced if the limit volume in this examination remains constant. The storage is 3TB, 5TB, and 7 TB. In this case, the acknowledgment time in the 3 TB volume is shorter than in the other two volumes. Despite maintaining a 0% false positive rate, the cross-view fresh boot procedure detects 68.421% of rootkit attempts on Windows Server 2022. The not recommended rootkit foundation does not cover records and envelopes. Furthermore, rootkits that distinguish Amazon Web service cloud condition have a high false negative rate. Because the attacker will present the rootkit adequately on the cloud case, the false negative rate should decrease in this action. Future work will be based on distinguishing open ports and memory levels in cloud conditions.