Abstract: A system, and method are disclosed for securing a computing system against malicious activity. In its various embodiments the invention presents more reliable “activity” based detection of malicious code and computing system exploits such as rootkits. The computer security system has a module for anomalous activity at the basic abstraction layer of the computing system. Loading of operating system exploits may be halted based on a defined rule-set to prevent the computing system against malicious activity and exploits.
FORM 2
THE PATENTS ACT, 1970 (39 of 1970)
&
THE PATENS RULES, 2003
PROVISIONAL SPECIFICATION
[See section 10, Rule 13]
SYSTEM FOR USING BEHAVIOURAL ANALYSIS TO DETECT, REMOVE AND INNOCULATE AGAINST ROOTKIT TECHNOLOGY;
MIEL E-SECURITY PVT. LTD., A COMPANY INCORPORATED UNDER THE COMPANIES ACT, 1956, WHOSE ADDRESS IS C- 611 / 612, FLORAL DECK PLAZA, MIDC CENTRAL ROAD, ANDHERI (E), MUMBA! 400 093, MAHARASHTRA, INDIA.
THE FOLLOWING SPECIFICATION DESCRIBES THE INVENTION.
FIELD
This invention comes under the field of computer security, specifically the detection of a certain class of software known as root kits.
BACKGROUND OF THE INVENTION
One of the largest threats to computer security comes from so-called malicious code or malware. Anti-virus and content filtering technologies have proved inadequate at preventing the barrage of malware that regularly infects and installs itself on systems in the enterprise. To quote from the Symantec Internet Security Threat Report of September 2005,
"Over the first half of 2005, Symantec documented more than 10,866 new Win32 viruses and worms, an increase of 48% over the 7,360 documented in the second half of 2004. It is also an increase of 142% over the 4,496 documented in the first half of 2004.
This trend is also important because it signifies a shift away from broadly disseminated threats, such as mass-mailing worms, and towards malicious code that is modular and customizable."
Sophisticated forms of malware are now being seen in the wild. This malware can among other things be used to spy on the infected system to gain personal and confidential information, turn systems into botnet 'zombies', or send sDam. Malicious code that exposes confidential information re analyzed.
Of all types of malicious code, 'rootkit' technology represents the cutting edge or most highly evolved type of threat. The feature set of a modern rootkit is designed to make it completely invisible, from conventional detection mechanisms, either native to the operating system, or provided by conventional security products such as anti-virus and anti-spyware technology. The techniques used by rootkits to remain hidden are complex and methodology of detecting such software is continuously evolving to meet new threats. There is an increasing use of rootkit and rootkit-like technology in not just malicious code but even benign commercial products (for example, the case of Sony BMG issuing digital rights managed audio CD's protected with rootkit-like technology).
The application of conventional detection techniques such as signature based analysis is insufficient to deal with the threat posed by rootkits which have not yet been seen in the wild (custom designed rootkits, private rootkits or new rootkits). This necessitated the development of a system that is capable of identifying both known as well as unknown rootkits.
Such a system must be based on an analysis of the behaviour of programs, on the protected computer system. This implies monitoring the behaviour of all programs and system parameters to detect behaviour that would be exhibited by a rootkit. This behaviour includes taking control of vital system functions, hiding logical files, cloaking running program information etc. The advantage of such a system is that it does not rely on a static database of signatures for operation and is capable of detecting unknown rootkits by virtue of the fact that they exhibit rootkit-like behaviour.
SUMMARY OF THE INVENTION
The system disclosed is designed to detect, remove (disable malicious features) and innoculate (prevent installation of) rootkit technology on the Microsoft Windows™ family of computer operating systems using the comparison of system parameters and process behaviour against a 'known good' system state. Deviations from the optimal known good state are identified as potential rootkit activity.
Microsoft Windows™ operates all processes in one of two access-levels known as 'rings'. Ring 3 is where conventional user programs run. This is known as 'user mode' or 'userland'. Logically closer to the hardware is what is known as ring 0, where the Windows kernel and device drivers that control the hardware operate. The drivers run in what is called 'kernel mode' that gives them the same privileges as Windows itself, and are not subject to any of the access control mechanisms that we see in userland applications (administrator accounts, file permissions etc).
Modern rootkits operate in ring 0 so that they can bypass any access restrictions and hide their existence from Windows itself. Since anti-virus programs and other monitoring tools run in user mode at ring 3, the rootkit can subvert all their probes to remain invisible.
The system described will operate a component at ring 0, probing for rootkits at their own level. It will be able to detect rootkits that hide processes, files on disk, open network ports, and other system activity that signifies the existence of malicious code.
Upon detecting suspicious activity, the system component running at ring 0 will communicate via a pre-determined protocol to what is called the UMDC
(user mode detection and communications) module, this is the userland component of the system that will handle the alert, and give the user the appropriate information. Furthermore, the UMDC module will talk across a network to the centralized administrative server called the CACM (central administrative and communications module). This is the central management console, and it can store the alert in a database, and query the configuration of the system that generated the alert to ascertain whether this threat is serious or not. The base architecture diagram below illustrates the relationship between all the components:
BASE ARCHITECTURE
The system disclosed will have 2 basic modes - 'on demand scanning' and 'background scanning'. On demand scanning mode will poll the system parameters once upon being manually selected by the user. This presents a snapshot of the systems current state. Such a snapshot may be saved to compare against a later date, for example to determine whether a particular
software has modified the system parameters by taking a before and after snapshot using the on demand scan.
The background scanning mode will continuously poll the system parameters at regular intervals to determine whether the system state has been modified. The system can then be relegated to the background and the user can continue working. If potential rootkit activity is detected, a graphical alert will be generated to call the users attention to the problem.
Further to detecting potential rootkit activity, the system disclosed will present the user with the ability to disable the rootkit technology that has been detected. If the user chooses to do so, the system will attempt to revert the operating environment to the known good state previously described. This involves restoring system functions, unhiding hidden files, processes, ports and registry keys.
A further feature of the system disclosed is the ability to innoculate the user's computer system against the installation of rootkits by preventing access to system functions used by rootkits to install their code into the operating system.
The system also provides the user with the ability to 'protect' chosen application programs from modification. Protected applications will load with a component of the system that analyzes their integrity at process startup. Upon detection of changes to the program integrity, the system will generate an alert to the user revealing the potential danger of using the tainted application as well as providing an option to restore the application integrity. If the user elects to restore the integrity, the system will attempt to revert the application to it's known good state.
The system disclosed will rely on multiple methods of determining behaviour. The information retrieved from all these methods will be compared to determine deviations. This ensures that a rootkit that successfully cloaks itself from one behaviour check will be detected through comparison against the other multiple checks which will yield conflicting information signifying an anomaly.
Dated this 19th day of May, 2006.
(TORAL DINESH SANGHAVI) KRISHNA & SAURASTRI
FOR MIEL E-SECURITY PVT. LTD. By their Agent
| # | Name | Date |
|---|---|---|
| 1 | 764-MUM-2006- PUBLICATION REPORT.pdf | 2021-12-14 |
| 1 | 764-MUM-2006_EXAMREPORT.pdf | 2018-08-09 |
| 2 | 764-mum-2006-abstract(16-5-2007).pdf | 2018-08-09 |
| 2 | 764-mum-2006-general power of attorney(24-5-2006).pdf | 2018-08-09 |
| 3 | 764-mum-2006-form-5.pdf | 2018-08-09 |
| 3 | 764-mum-2006-claims(16-5-2007).pdf | 2018-08-09 |
| 4 | 764-mum-2006-form-3.pdf | 2018-08-09 |
| 4 | 764-mum-2006-correspondance-received.pdf | 2018-08-09 |
| 5 | 764-mum-2006-form-2.pdf | 2018-08-09 |
| 5 | 764-mum-2006-correspondance-send.pdf | 2018-08-09 |
| 6 | 764-MUM-2006-CORRESPONDENCE(12-5-2010).pdf | 2018-08-09 |
| 7 | 764-mum-2006-form-1.pdf | 2018-08-09 |
| 7 | 764-mum-2006-correspondence(16-5-2007).pdf | 2018-08-09 |
| 8 | 764-mum-2006-form 5(16-5-2007).pdf | 2018-08-09 |
| 8 | 764-mum-2006-correspondence(ipo)-(29-5-2006).pdf | 2018-08-09 |
| 9 | 764-MUM-2006-CORRESPONDENCE(IPO)-(AB21)-(30-3-2016).pdf | 2018-08-09 |
| 9 | 764-mum-2006-form 2(title page)-(provisional)-(19-5-2006).pdf | 2018-08-09 |
| 10 | 764-MUM-2006-CORRESPONDENCE(IPO)-(FER)-(19-3-2015).pdf | 2018-08-09 |
| 10 | 764-mum-2006-form 2(title page)-(complete)-(16-5-2007).pdf | 2018-08-09 |
| 11 | 764-MUM-2006-CORRESPONDENCE(IPO).pdf | 2018-08-09 |
| 11 | 764-mum-2006-form 2(16-5-2007).pdf | 2018-08-09 |
| 12 | 764-mum-2006-description (provisional).pdf | 2018-08-09 |
| 12 | 764-MUM-2006-FORM 18(12-5-2010).pdf | 2018-08-09 |
| 13 | 764-mum-2006-description(complete)-(16-5-2007).pdf | 2018-08-09 |
| 13 | 764-mum-2006-form 1(24-5-2006).pdf | 2018-08-09 |
| 14 | 764-mum-2006-drawing(16-5-2007).pdf | 2018-08-09 |
| 15 | 764-mum-2006-description(complete)-(16-5-2007).pdf | 2018-08-09 |
| 15 | 764-mum-2006-form 1(24-5-2006).pdf | 2018-08-09 |
| 16 | 764-mum-2006-description (provisional).pdf | 2018-08-09 |
| 16 | 764-MUM-2006-FORM 18(12-5-2010).pdf | 2018-08-09 |
| 17 | 764-mum-2006-form 2(16-5-2007).pdf | 2018-08-09 |
| 17 | 764-MUM-2006-CORRESPONDENCE(IPO).pdf | 2018-08-09 |
| 18 | 764-MUM-2006-CORRESPONDENCE(IPO)-(FER)-(19-3-2015).pdf | 2018-08-09 |
| 18 | 764-mum-2006-form 2(title page)-(complete)-(16-5-2007).pdf | 2018-08-09 |
| 19 | 764-MUM-2006-CORRESPONDENCE(IPO)-(AB21)-(30-3-2016).pdf | 2018-08-09 |
| 19 | 764-mum-2006-form 2(title page)-(provisional)-(19-5-2006).pdf | 2018-08-09 |
| 20 | 764-mum-2006-correspondence(ipo)-(29-5-2006).pdf | 2018-08-09 |
| 20 | 764-mum-2006-form 5(16-5-2007).pdf | 2018-08-09 |
| 21 | 764-mum-2006-correspondence(16-5-2007).pdf | 2018-08-09 |
| 21 | 764-mum-2006-form-1.pdf | 2018-08-09 |
| 22 | 764-MUM-2006-CORRESPONDENCE(12-5-2010).pdf | 2018-08-09 |
| 23 | 764-mum-2006-correspondance-send.pdf | 2018-08-09 |
| 23 | 764-mum-2006-form-2.pdf | 2018-08-09 |
| 24 | 764-mum-2006-correspondance-received.pdf | 2018-08-09 |
| 24 | 764-mum-2006-form-3.pdf | 2018-08-09 |
| 25 | 764-mum-2006-form-5.pdf | 2018-08-09 |
| 25 | 764-mum-2006-claims(16-5-2007).pdf | 2018-08-09 |
| 26 | 764-mum-2006-general power of attorney(24-5-2006).pdf | 2018-08-09 |
| 26 | 764-mum-2006-abstract(16-5-2007).pdf | 2018-08-09 |
| 27 | 764-MUM-2006_EXAMREPORT.pdf | 2018-08-09 |
| 27 | 764-MUM-2006- PUBLICATION REPORT.pdf | 2021-12-14 |