A methodology to detect and characterize kernel level rootkit exploits involving redirection of the system call table

Levine, John G.; Grizzard, J.B.; Owen, Henry L.

doi:10.1109/iwia.2004.1288042

Cited by 21 publications

(14 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Via VFS, Linux could avoid the great difference between the various functions and operations of file systems and access them in the same way. VFS ultimately call for the function of actual file system to complete the user requests [7]. Hooking VFS function can be more subtle than directly modify the system call pointer.…”

Section: A Control Flow Hijackingmentioning

confidence: 99%

Kernel Malware Core Implementation: A Survey

Zhang

Tang

2015

2015 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery

View full text Add to dashboard Cite

Kernel Malware resides and performs malicious functions in the operating system kernel space. It is more difficult to be detected and cleared than the malwares implemented in the user space because of its higher authority. It also has better flexibility compared with the malware based on the firmware. As a result, the kernel malware is one of the challenging threats in information security. This paper analyzes the universal working model of the kernel malware and the attack vector, investigates the core implementation technologies. It focuses on the hook, patch and debug-based control flow hijacking and DKOM techniques. Then, the implementation details of these core technologies are analyzed by studying several typical Linux kernel malware. Finally, we summarize the detection methods of kernel malware, point out their main defects, and discuss the new direction of the malware detection.

show abstract

Section: A Control Flow Hijackingmentioning

confidence: 99%

Kernel Malware Core Implementation: A Survey

Zhang

Tang

2015

2015 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery

View full text Add to dashboard Cite

show abstract

“…Instead of gathering context information for argument similarity checks, all the return addresses associated with indirect calls seen during the learning phase are collected and compiled into trust lists that are used as whitelists for validating control flows. While location-based verification is not a particularly groundbreaking approach (e.g., the technique has been used in [50][51][52]), it helps determine whether or not a current control flow is trustworthy.…”

Section: Simplified Checks For Indirect Function Callsmentioning

confidence: 99%

Intrusion detection for resource-constrained embedded control systems in the power grid

Reeves

Ramaswamy

Locasto

et al. 2012

International Journal of Critical Infrastructure Protection

View full text Add to dashboard Cite

“…While location-based verification is nothing new (defensive tools such as s0ftpj.org KSTAT and KSEC offered it at least since 2000 [36]; academic treatment can be found in, e.g., Levine, Grizzard, and Owen [14]), it allows us to make a simple decision about whether the current control flow is trustworthy or not. For this technique, we collect the return addresses that we encounter at each probe during the learning phase, then use the collected data to build trusted location lists that we can verify against in the detection phase.…”

Section: Trusted Location Listsmentioning

confidence: 99%

Lightweight Intrusion Detection for Resource-Constrained Embedded Control Systems

Reeves

Ramaswamy

Locasto

et al. 2011

Critical Infrastructure Protection V

View full text Add to dashboard Cite

Today's power grid depends on embedded control systems to function properly. Securing these systems presents a unique challenge, since on top of the resource restrictions inherent to embedded devices, SCADA systems must accommodate strict timing requirements that are nonnegotiable, and their massive scale greatly amplifies costs such as power consumption. Together, these constraints make the conventional approach to host intrusion detection-namely, using a hypervisor to create a safe environment from which a monitoring entity can operate-too costly or impractical for embedded control systems in such critical infrastructure.In this paper, we introduce Autoscopy, an experimental host intrusion detection mechanism that operates from within the kernel and leverages its built-in tracing framework to look for control-flow anomalies, which are most often caused by rootkits hijacking kernel hooks. In initial testing on a standard laptop system, our prototype was able to detect a representative selection of control-flow hijacking rootkit techniques while imposing less than 5% performance overhead for the majority of our benchmark tests. We argue that its design and effectiveness make it both feasible for and uniquely suited to intrusion detection for SCADA systems, and are currently porting Autoscopy to actual power hardware to test our hypothesis. Being situated in the kernel, Autoscopy needs some hardware (e.g., memory immutability) or software protection (i.e., kernel hardening) measures in place for its own protection; however, such protective measures would cost less than full-blown reference monitor isolation via hardware virtualization at the core of hypervisor-based proposals.

show abstract

A methodology to detect and characterize kernel level rootkit exploits involving redirection of the system call table

Cited by 21 publications

References 2 publications

Kernel Malware Core Implementation: A Survey

Kernel Malware Core Implementation: A Survey

Intrusion detection for resource-constrained embedded control systems in the power grid

Lightweight Intrusion Detection for Resource-Constrained Embedded Control Systems

Contact Info

Product

Resources

About