루트킷(rootkit)은 컴퓨터 소프트웨어 중에서 악의적인 것들의 모음으로써, 자신의 또는 다른 소프트웨어의 존재를 가림과 동시에 허가되지 않은 컴퓨터나 소프트웨어의 영역에 접근할 수 있게 하는 용도로 설계되었다.[1] 루트킷이라는 용어는 "루트"(유닉스 계열 시스템에서 권한을 가진 계정의 전통적인 이름)와 "kit"(툴을 구현하는 소프트웨어 구성 요소를 가리킨다.)의 합성어이다. "루트킷"이라는 용어는 악성 소프트웨어와의 연관으로 인해 부정적인 의미를 함축하고 있다.[1]
루트킷의 설치는 자동으로 이루어지거나 공격자가 루트 권한이나 관리자 접근을 획득하였을 때 설치될 수 있다. 이 접근을 획득하는 것은 알려진 취약점(권한 확대 같은)을 공격하는 것이나 암호(크래킹 또는 사회공학을 통해 획득한)를 통한 직접적인 권한의 결과이다. 한 번 설치되면, 권한을 가진 접근을 유지할 뿐만 아니라 침입을 숨길 수도 있다. 중요한 점은 루트 또는 관리자 접근이다. 시스템에 대한 완전한 제어는 존재하는 소프트웨어가 수정되었을 수 있다는 것을 의미한다.
루트킷 탐지는 이것이 자신을 찾으려 하는 소프트웨어를 뒤집어 엎을 수 있기 때문에 어려운 일이다. 탐지 방법은 대체적이고 신뢰성 있는 운영 체제나 행동 기반 방식, 특징(signature) 스캐닝 그리고 메모리 덤프 분석 등이 있다. 제거는 복잡하거나 심지어 실질적으로 불가능할 수 있는데 특히 루트킷이 커널에 거주할 때 더 그렇다; 운영 체제의 재설치가 문제 해결의 유일한 해결법이 될 수 있다.[2]펌웨어 루트킷의 경우, 제거하기 위해서 하드웨어 교체나 특별한 장비가 필요할 수 있다.
용도
현대 루트킷들은 접근을 상승시키지 않고,[3] 대신 숨겨진 기능을 추가함으로써 다른 소프트웨어 페이로드를 탐지하지 못하게 하는 용도로 사용된다.[3] 대부분의 루트킷들은 악성 소프트웨어로 분류되는데, 그들과 함께 번들된 페이로드가 악의적이기 때문이다. 예를 들면 페이로드는 은밀하게 사용자 계정, 신용 카드 정보, 컴퓨팅 자원을 훔치거나 다른 비인가된 행동을 수행할 수 있다. 소수의 루트킷들은 자신의 사용자에 의해서 유틸리티 애플리케이션으로 여겨질 수 있다.
루트킷과 그것의 페이로드는 많은 용도를 갖는다.
공인되지 않은 접근을 허용함으로써 공격자가 백도어를 통해 완전한 접근을 할 수 있게 한다. 이것을 이행하는 방법 중 하나로 유닉스 계열 시스템의 경우에는 /bin/login 프로그램, 윈도우의 경우에는 GINA 같은 로그인 메커니즘을 뒤집어 엎는 것이 있다. 이 대체는 정상적으로 동작하는 것처럼 보이지만 비밀 로그인 조합을 받아들여서 공격자가 시스템에 관리자 권한으로 직접 접근하게 한다. 이것은 표준 인증 그리고 인가 메커니즘을 우회함으로써 가능해 진다.
에뮬레이션 소프트웨어와 보안 소프트웨어를 강화한다.[7]데몬 툴즈가 시큐롬 같이 복사 방지 메커니즘을 무산시키는데 사용되는 악의적이지 않은 루트킷의 상업용 예시이다. 카스퍼스키 안티바이러스도 또한 악의적인 행동으로부터 자신을 보호하기 위한 루트킷과 비슷한 기법을 사용한다. 이것은 시스템 활동을 가로채기 위해서 자신의 드라이버를 로드하며, 다른 프로세스들이 자신에게 해로운 행동을 하는 것을 예방한다. 이 과정들은 감추어져 있지는 않지만 표준적인 방식으로 종료할 수는 없다.
도난 방지 보호: 노트북은 BIOS 기반 루트킷을 가짐으로써 주기적으로 감시하고 도난된 후에도 정보가 사라지지 않게 해준다.[8]
루트킷에는 적어도 5가지의 종류가 존재하며, 가장 낮은 레벨인 펌웨어부터(가장 높은 권한을 가진) 가장 높은 권한을 갖는 링 3의 사용자 기반까지의 범위를 갖는다. 이것들의 하이브리드 형태는 사용자 모드에서 커널 모드까지에 걸친 것이다.[10]
사용자 모드
컴퓨터 보안 링 (링 -1이 보이지 않는다는 점에 주의하라)
사용자 모드 루트킷은 저수준 시스템 프로세스가 아니라 링 3에서 돌아간다.[11]이들은 API의 표준 행동을 가로채고 수정하기 위한 가능한 수많은 설치 매개들을 갖는다. 몇몇은 DLL을 다른 프로세스에 삽입함으로써 어느 대상 프로세스에서도 실행될 수 있게 한다; 다른 충분한 권한을 가진 것들은 간단하게 대상 애플리케이션의 메모리를 덮어쓴다. 삽입 메커니즘은 다음을 포함한다.[11]
벤더에서 제공된 애플리케이션 확장 사용. 예를 들면 윈도우 익스플로러는 써드파티가 기능을 확장하게 해주는 공용 인터페이스를 갖는다.
실행되는 프로세스나 파일 시스템에 존재하는 파일을 숨기기 위한 함수 후킹 또는 주로 이용되는 API의 패치.[12]
커널 모드
커널 모드 루트킷은 커널과 디바이스 드라이버 같은 코어 운영 체제의 한 부분에 코드를 추가하거나 대체함으로써 높은 운영 체제 권한(링 0)과 함께 실행된다. 대부분의 운영체제들은 운영체제 자신과 같은 권한에서 실행되는 커널 모드 디바이스 드라이버를 지원한다. 이러한 많은 커널 모드 루트킷들은 리눅스에서 적재 가능 커널 모듈, 그리고 윈도우에서 디바이스 드라이버 형태로 개발된다.[13] 이 복잡함은 버그가 흔한 상태로 만들며, 동작하는 코드의 어느 버그도 시스템 안정성에 심각한 영향을 미쳐서 루트킷이 발견되게 한다.[13]
커널 루트킷들은 운영체제 자신과 같은 보안 수준에서 동작하기 때문에 특히 탐지하고 제거하기가 어려우며, 그로인해 가장 신뢰되는 운영 체제 동작을 가로채고 전복시킬 수 있다. 바이러스 검사 소프트웨어 같은 시스템과 같이 돌아가는 어떤 소프트웨어도 똑같이 취약하다.[14] 이 경우에 시스템의 어떤 부분도 신뢰할 수 없게 된다.
루트킷은 DKOM(Direct Kernel Object Manipulation)으로 알려진 기법을 사용하는 윈도우 커널에서 데이터 구조를 수정할 수 있다.[15] 이 방식은 프로세스들을 숨기는데 사용될 수 있다. 커널 모드 루트킷은 또한 시스템 서비스 서술자 테이블 (SSDT)을 후킹하거나, 자신을 가리기 위해 사용자 모드와 커널 모드 사이의 게이트를 수정할 수 있다.[16] 비슷하게 리눅스 운영 체제에서도, 루트킷은 커널 기능을 전복시키기 위해 시스템 호출 테이블을 수정할 수 있다.[17] 루트킷이 다른 악성코드나 감염된 파일의 원본을 숨기긴 곳에서 감춰진 암호화된 파일 시스템을 생성한다는 것은 흔한 일이다.[18]
운영 체제들은 커널 모드 루트킷의 위협에 대응하도록 진화하고 있다. 예를 들면 마이크로소프트 윈도우의 64비트 버전은 신뢰하지 않은 코드를 높은 권한으로 실행하는 것을 어렵게 하기 위해 현재 모든 커널 수준 드라이버들의 의무적인 표시를 구현하고 있다.[19]
부트킷
부트킷이라고 불리는 커널 모드 루트킷의 변형은 마스터 부트 레코드(MBR), 볼륨 부트 레코드(VBR) 또는 부트 섹터 같은 시작 코드를 감염시켜서 전체 디스크 암호화를 공격하는데 사용될 수 있다. 일반적으로 악성코드 로더는 커널이 로드될 때 보호 모드로 이행하려고 하며, 그로 인해 커널을 전복시킬 수 있다.[20][21][22][23]
부트킷 공격에 대한 유일한 알려진 방어는 시스템에 대한 비인가된 물리적 접근의 예방 또는 부트 경로를 보호하기 위한 신뢰 플랫폼 모듈의 사용이다.[24]
하이퍼바이저 레벨
학문적으로 타입2 하이퍼바이저 형태로 생성된 루트킷은 기술 검증용으로서 만들어져 왔다. 인텔 VT 또는 AMD-V 같은 하드웨어 가상화 특징을 익스플로잇함으로써 이 타입의 루트킷은 링 -1에서 실행되고 가상 머신으로서 대상 운영 체제를 호스트하며, 이로써 루트킷이 원래 운영 체제에 의해 만들어진 하드웨어 호출을 가로챌 수 있게 한다.[25] 일반적인 하이퍼바이저와는 달리, 이들은 운영 체제 전에 로드될 필요가 없고, 가상 머신에 프로모트하기 전에 운영 체제에 로드될 수 있다.[25] 하이퍼바이저 루트킷은 전복시키기 위해 대상의 커널을 수정할 필요가 없다; 하지만 이것이 게스트 운영 체제에 의해서 탐지될 수 없다는 것을 의미하지는 않는다. 예를 들면 CPU 명령어에서 시간 차이가 탐지될 수 있다.[25]
2009년에 마이크로소프트와 노스캐롤라이나 주립 대학교의 연구원들은 Hooksafe라고 불리는 하이퍼바이저 계층 안티 루트킷을 입증하였으며, 이것은 커널 모드 루트킷에 대한 일반적인 보호를 제공한다.[26]
윈도우 10은 "디바이스 가드"라고 불리는 새로운 특징을 도입하였으며, 이것은 루트킷 형식의 악성코드에 대한 운영 체제의 독립적인 외부 보호를 제공하기 위해 가상화의 장점을 이용한다.[27]
펌웨어와 하드웨어
펌웨어 루트킷은 하드웨어에서 일관적인 악성코드 이미지를 생성하기 위해 라우터, 네트워크 카드,[28] 하드 디스크 드라이브 또는 시스템 바이오스[11] 같이 디바이스나 플랫폼 펌웨어를 사용한다. 펌웨어가 일반적으로 코드 무결성 검사가 이루어지지 않기 때문에 루트킷은 펌웨어에 숨는다.
설치와 은폐
루트킷들은 시스템의 제어를 얻기 위해 다양한 기법들을 사용한다. 가장 일반적인 기법은 은밀한 권한 확대를 달성하기 위해 보안 취약점을 사용하는 것이다. 다른 접근법으로 컴퓨터 사용자가 루트킷의 설치 프로그램을 믿게하기 위해 트로이 목마를 사용하는 것이 있다.[13] 설치 작업은 만약 최소 권한 원칙이 적용되지 않았다면 더 쉬운데, 이것은 루트킷이 명시적으로 권한 확대를 요청할 필요가 없기 때문이다. 다른 종류의 루트킷은 오직 대상 시스템에 물리적으로 접근함으로써 설치될 수 있다. 어떤 루트킷은 사용자에 의해 직원 감시용으로 설치될 수도 있다.[29]
루트킷은 한번 설치되면 호스트 시스템 내에서 자신의 존재를 알리지 않기위한 수단으로 표준 운영 체제 보안 툴과 진단, 스캐닝, 감시를 위한 API들을 전복시키거나 회피하는 등의 동작을 수행한다. 루트킷들은 다른 프로세스들에 코드를 로딩하고 드라이버나 커널 모듈들을 설치하거나 수정하는 방식을 통해서 운영 체제의 중요한 부분의 행동을 수정함으로써 이것을 달성한다. 난독화 기법은 시스템 감시 메커니즘으로부터 실행 중인 프로세스들을 숨기고 시스템 파일들과 다른 설정 데이터를 숨기는 것을 포함한다.[30] 공격의 증거를 숨기기 위해 루트킷이 운영 체제의 이벤트 로깅 능력을 비활성화시키는 것은 흔하지는 않은 일이다. 이론적으로 루트킷들은 어떠한 운영 체제 활동도 전복시킬 수 있다.[31] "완벽한 루트킷"은 "완전범죄"로 여겨질 수 있다.
루트킷들은 또한 안티 바이러스 소프트웨어로부터 탐지되거 제거되는 것에 대한 생존을 위해 여러 방식을 사용하는데, 일반적으로 링 0(커널 모드)에 설치되는 것이 그것이다. 이곳은 시스템에 대한 완전한 접근이 가능하다. 이것들은 다형성, 은폐 기법, 재생, 안티 바이러스 소프트웨어 비활성화 같은 것들을 포함한다.[32] 그리고 연구자들에 의해서 쉽게 발견되고 분석될 수 있는 가상 머신에 설치되는 것을 거부하는 방식도 있다.
탐지
루트킷을 발견하는데 근본적인 문제는 만약 운영 체제가 전복되었다면, 특히 커널 수준 루트킷에 의해서, 자신 또는 자신의 구성 요소들에게 비인가된 수정이 신뢰된다는 것이다.[31] 실행 중인 프로세스들의 목록이나 디렉토리의 파일을 요청하는 것 같은 행동은 예상과 같이 행동한다고 신뢰될 수 없다. 즉 감염된 시스템에서 동작 중인 루트킷 탐지기들은 단지 커널에서 루트킷보다 낮은 수준에서 실행될 때 탐지할 수 있다.[13] 컴퓨터 바이러스 같이 루트킷의 탐지와 제거는 이 때문에 더욱 힘들어지고 있다.[31]
탐지는 여러 가지 접근법을 가질 수 있는데 시그니처(안티 바이러스 소프트웨어), 무결성 검사(디지털 서명), 차이 기반 탐지(예상 결과와 실제 결과와의 비교) 그리고 행위 기반 탐지(CPU 사용이나 네트워크 트래픽 감시)가 있다. 커널 모드 루트킷들에서 탐지는 상당히 복잡한데, 악성코드가 시스템 행위를 전복시키는 곳에서 후킹된 함수들을 찾기 위한 시스템 호출 테이블과 숨겨진 프로세스들을 가리키는 패턴에 대한 메모리의 포렌식 스캐닝의 철저한 검토를 요구한다.
유닉스 루트킷 탐지는 Zeppoo[33], chkrootkit, rkhunter 그리고 OSSEC를 제공한다. 윈도우에서, 탐지 툴들로는 마이크로소프트 시스인터널스 RootkitRevealer,[34]어베스트! 안티바이러스, Sophos 안티-루트킷,[35]F-시큐어,[36] Radix,[37] GMER,[38] 그리고 WindowsSCOPE가 있다.
의심되는 운영 체제가 가동중이지 않을 때 저장소를 검사함으로써 탐지하는 것은 루트킷이 활성화되지 않아서 루트킷을 인식하는 것을 실패할 수 있다. 가동중인 루트킷과 함께 돌아가는 일반적인 안티 바이러스 소프트웨어는 루트킷이 자신을 효과적으로 숨기면 실패할 수 있다.
대안이 되는 신뢰되는 매체
운영 체제 수준 루트킷을 탐지하는 가장 신뢰되는 방법은 의심되는 컴퓨터를 끄고 대안이 되는 신뢰되는 매체(CD-ROM, USB 플래스 드라이브)에서 부팅함으로써 이것의 저장소를 검사하는 것이다.[39] 이 기법은 루트킷이 자신이 실행 중이지 않을 때에는 자신의 존재를 숨길 수 없기 때문에 효과적이다.
행위 기반
루트킷을 탐지하기 위한 행위 기반 접근법은 루트킷이라고 여겨질만한 행동을 찾음으로써 루트킷의 존재를 추론할 수 있다. 예를 들면 시스템을 프로파일링하고 전체 CPU 활용에서 API 호출의 빈도와 타이밍이 다를 때 루트킷으로 여겨질 수 있다. 이 방식은 복잡하고 긍정 오류의 높은 발생으로 방해받는다. 루트킷을 처리하는 것은 종종 시스템에 매우 명백한 변화를 줄 수 있다. Alureon 루트킷은 코드에 설계 결함을 가진 보안 업데이트 이후 윈도우 시스템을 충돌시켰다.[40][41]
비록 보안 소프트웨어 벤더들이 루트킷 탐지를 위해 제품에 추가하여도 안티바이러스 제품들은 공개 테스트에서 모든 바이러스들을 잡아내지는 못한다. 루트킷은 안티바이러스 스캔 시에 숨겨지려 하며 은폐 탐지기는 알아챌 수 있다. 만약 루트킷이 임시적으로 자신을 시스템에서 언로드시킨다면 시그니처 탐지는 찾아낼 수 있을 것이다. 이 결합된 접근법은 공격자가 대응 메커니즘을 구현하게 했는데 이것은 안티바이러스 프로그램을 종료시키는 것이다. 시그니처 기반 탐지 방식들은 공개된 루트킷에는 효과적이지만, 특별히 커스톰화된 루트킷들에는 약한 경향이 있다.[31]
차이 기반
루트킷을 탐지하는 다른 방식으로는 "신뢰된" raw 데이터와 API가 반환하는 "오염된" 내용을 비교하는 것이다. 예를 들면 디스크에 존재하는 바이너리들은 메모리의 복사본과 비교될 수 있거나 파일 시스템 또는 윈도우 레지스트리 API에서 나온 결과들은 물리 디스크에서의 raw 구조와 함께 검사될 수 있다[31]—그러나, 전자의 경우 몇몇 유효한 차이점들은 메모리 재배치 같은 운영 체제 메커니즘에 의해서 도입될 수도 있다. 루트킷은 이러한 차이 기반 스캐너나 가상 머신의 존재를 탐지하고, 자신의 행동을 차이없게 해서 탐지되지 않게 할 수도 있다. 차이 기반 탐지는 소니 DRM 루트킷을 탐지하기 위한 마크 러시노비치의 RootkitRevealer 툴에서 사용되었다.[1]
무결성 검사
rkhunter 유틸리티는 SHA-1 해시들을 사용해서 시스템 파일들의 무결성을 검증한다.
코드 사이닝은 파일이 배포자에 의해 디지털 서명화된 이후로 수정되었는지를 검증하기 위해서 공개 키 기반 구조를 사용한다. 대체적으로, 시스템 소유자나 관리자는 디스크의 코드 라이브러리들에 대한 비인가된 변화를 탐지하기 위해 암호화 해시 함수를 사용할 수도 있다.[42] 그러나 정교하지 않은 방식들은 단지 코드가 설치 이후로 변경되었는지만 검사한다. 핑거프린트는 반드시 각 시간의 변화를 설정해야 한다. 해쉬 함수는 메시지 다이제스트를 생성하는데, 이것은 파일의 각 비트에서 계산된 상대적으로 짧은 코드이다. 설치된 파일의 메시지 다이제스트를 재계산하고 비교하는 것은 탐지되고 감시될 수 있다. 더 정교한 루트킷들은 디스크가 아니라 메모리에서 코드를 수정함으로써 이 검증 과정을 전복시킬 수 있다. 이 기법은 그러므로 단지 정교하지 않은 루트킷에 효과적이다.
비슷하게 펌웨어에서의 탐지는 펌웨어의 암호화 해시를 계산하고 이것을 예상되는 값들의 화이트리스트와 비교하거나, 해시 값을 TPM(신뢰 플랫폼 모듈) 설정 레지스터(이후에 기대 값의 화이트리스트와 비교되는)로 확장함으로써 달성될 수 있다.[43] 해시, 비교 또는 확장 연산을 수행하는 코드는 반드시 보호되어야 한다. 이 문맥에서 immutable root-of-trust 의 개념은 가장 처음 코드를 가지고 자신의 가장 기초 수준에서 루트킷 또는 부트킷이 시스템과 타협하지 않게 하는 것을 보장하게 하기 위한 시스템의 보안 속성을 측정한다.[44]
메모리 덤프
가상 메모리의 완전한 덤프를 가능하게 하는 것은 활성화된 루트킷(또는 커널 모드 루트킷의 경우 커널 덤프)을 잡게하고, 결과 덤프 파일에 대해 오프라인 포렌식 분석을 디버거로 수행할 수 있게 한다. 여기서 루트킷은 자신을 은폐할 수 없다. 이 기법은 고도로 전문적이며 공개되지 않은 소스 코드나 디버그 심볼에 대한 접근을 요구한다. 운영 체제에 의해 초기화된 메모리 덤프들은 항상 메모리를 읽기 위한 가장 낮은 수준의 시도를 가로채고 전복시키는 하이퍼바이저 기반 루트킷을 탐지하는데 사용될 수 없다.[25] 마스크할 수 없는 인터럽트를 구현하는 것 같은 하드웨어 장치는 이 시나리오에서 덤프 메모리를 요구할 수 있다.[45][46] 하이퍼바이저 아래의 가상 머신들 또한 위태로운 머신의 메모리를 분석하는 것을 쉽게할 수 있어서, 몇몇 루트킷들은 이 이유로 가상 머신을 감염시키는 것을 피한다.
제거
루트킷을 직접 제거하는 것은 일반 컴퓨터 사용자들에게 매우 어렵지만,[11] 많은 보안 소프트웨어 벤더들이 자동으로 루트킷을 탐지하고 제거하는 툴들을 제공한다. 2005년, 마이크로소프트의 월간 윈도우 악성 소프트웨어 제거 툴이 몇몇 종류의 루트킷들을 탐지하고 제거할 수 있게 되었다.[47][48] 몇몇 안티바이러스 스캐너들은 루트킷에 의해 조작될 수 있는 취약점을 가진 파일 시스템 API들을 우회할 수 있다. 대신 이것들은 raw 파일시스템 구조에 직접적으로 접근하고, 루트킷에 의해 유발되는 어떤 차이점도 식별하기 위해 이 정보를 시스템 API의 결과를 유효화하는데 사용한다.[49][50][51][52]
루트킷을 제거하는 신뢰성있는 유일한 방법은 운영 체제를 신뢰되는 매체에서 재설치하는 것이라고 믿는 전문가들이 있다.[53] 이것은 감염된 시스템에서 실행 중인 안티바이러스와 악성코드 제거 툴들이 잘 쓰여진 커널 모드 루트킷들에는 효과적이지 않기 때문이다. 신뢰되는 매체에서 대체 운영 체제를 부팅하는 것은 감염된 시스템 볼륨이 마운트되고 잠재적으로 안전하게 제거되었으며 중요한 데이터가 복사되었다는 것이다. 또는 대안으로 포렌식 검사가 수행되었거나.[10]윈도우 사전 설치 환경 같은 경량 운영 체제들은 이 목적으로 사용될 수 있으며 시스템을 깨끗하게 해준다.
비록 루트킷의 본성과 종류가 알려졌지만, 직접 이것을 복구하는 것은 비현실적이며, 운영 체제를 재설치하는 것이 훨씬 쉽고 빠르다.[53]
대중적 이용 가능성
공격자에게 사용되는 악성코드들처럼, 많은 루트킷 구현들은 인터넷에서 공유되고 쉽게 사용 가능하다.[10]
대부분의 루트킷들은 인터넷에서 기반한 컴퓨터 시스템에서 숨기고, 비인가된 제어를 하는 것을 입증하기 위한 익스플로잇 또는 학문적으로 "개념 증명"으로서 사용 가능하다.[54] 종종 은폐를 위해 완벽하게 최적화되지 않은 루트킷들은 자신의 존재에 대한 의도치 않은 증거를 남겨놓는다. 그렇더라도, 이러한 루트킷들이 공격에 사용될 때는 매우 효과적일 수 있다.
방어
루트킷이 설치되는 것을 막는 시스템 하드닝은 루트킷을 방어하는 첫번째 계층 중 하나이다.[55] 보안 패치, 최소 권한 원리 등은 모든 종류의 악성코드를 막는데 효과적인 방식이다.[56]
통일 확장 펌웨어 인터페이스 같은 새로운 보안 부트 명세는 부트킷의 위협 때문에 설계되었지만, 자신이 제공하는 특징이 사용되지 않는다면 더 취약하다.[57]
↑ 가나다라마Davis, Michael A.; Bodmer, Sean; LeMasters, Aaron (2009년 9월 3일). 〈Chapter 10: Rootkit Detection〉(PDF). 《Hacking Exposed Malware & Rootkits: Malware & rootkits security secrets & solutions》 (PDF)|format=은 |url=을 필요로 함 (도움말). New York: McGraw Hill Professional. ISBN978-0-07-159118-8. 2012년 3월 8일에 원본 문서(PDF)에서 보존된 문서. 2010년 8월 14일에 확인함.
Blunden, Bill (2009). 《The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System》. Wordware. ISBN978-1-59822-061-2.
Hoglund, Greg; Butler, James (2005). 《Rootkits: Subverting the Windows Kernel》. Addison-Wesley Professional. ISBN0-321-29431-9.
Grampp, F. T.; Morris, Robert H., Sr. (October 1984). “The UNIX System: UNIX Operating System Security”. 《AT&T Bell Laboratories Technical Journal》 (AT&T) 62 (8): 1649–1672.
