1. Advancing Infosec, Keynote Presentation

마이크로소프트 위협 인텔리전스 센터 총 책임자인 존 램버트가 키노트를 잡았다. 전통적인 방어와 최근 방어의 차이를 설명했으며, 마이크로소프트에는 One Hunt라는 것이 있다고 설명했다. One Hunt는 레드팀, 블루팀 모두 하나의 공통 과제를 제공하고 이 과제를 해결하는 프로젝트를 의미하는 것 같았다. 아무래도 공격과 방어의 인사이트를 공유하여 융합되도록 하는데 있어 중요한 부분인 것 같다. 

위협 정보 공유하는 것은 매우 중요하다고 언급하며 지속적으로 컨퍼런스 발표, 블로그 운영, 트위터 활동, 도구 제작 및 오픈소스로 공개 그리고 멘토링을 통해 다른 팀이나 다른 사람들과 함께 성장하도록 장려한다고 말한다. 그러면서 이러한 결과가 ATT&CK Matrix가 만들어지지 않았나 라고 말하는 것 같다. 그러면서 다음 오픈소스들을 언급했다.

  • atomic red team - https://github.com/redcanaryco/atomic-red-team
    - 얜 ATT&CK를 공부하면서 알게된 녀석인데 실제 공격에 사용된 코드를 살펴볼 수 있어서 기억하고 있는 오픈소스다.
  • sigma - https://github.com/Neo23x0/sigma
    - 얜 HELK였나 무슨 오픈소스에서 시그니처 부분에 sigma를 적극 도입한다고 이야기해서 알게되었고, Neo23x0은 워낙 유명한 사람이라 놀랐던 오픈소스다.
  • jupyter - https://jupyter.org/
    - 한번 봤었다가 뭐야 이거 하면서 넘겼던 녀석인데 브라우저에서 코딩하는 IDE 오픈소스 같다.
  • binder - https://mybinder.org/
    - 얜 이번에 처음 봤는데 주피터 노트북이 있는 깃헙 주소를 바인더에 넣으면 브라우저에서 실시간으로 컴파일(인터프리터)해서 결과를 보여주는 도구 같다.

이러한 오픈소스를 적재적소에 사용하여 위협 인텔리전스를 수행하는 것이 매우 중요하며, 깃허브화(Githubification)을 진행하여 함께 할 수 있도록 구성하는 것이 중요하다고 언급하며 끝났다. (야레야레 깃헙 이제 MS 꺼잖아 소스코드 올리면 누구 좋으라는거야? 깃랩에 올리자 가용성이 조금 불안하지만..)

2. How Did We Get Here?

MITRE의 ATT&CK 리더인 Blake Storm과 인터뷰 내용이다. 처음엔 엑셀로 정리하면서 ATT&CK 프로젝트를 시작했고, 공격 정보를 토대로 방어를 할 수 있길 바랬다고 말한다. 이후 질문들이 이어지는데, 기억에 남는 질문이 ATT&CK의 단편적인 내용으로만 대응을 진행하면 오탐율이 많아지는데, 맥락(Context)적인 내용도 추가할 예정인지 물어본다. 이에 대한 답변으로 기존에 진행하는 방법론에 ATT&CK를 섞어 쓰는게 어떤가를 이야기한다. 플랫폼에 클라우드를 추가하는게 어떤가에 대한 질문에는 당연히 어렵다고 말한다. 각 TTPs에 심각도를 추가하는 것이 어떤가에 대한 질문에는 각 환경이 상이하기에 위협의 크기를 수치화하기가 힘들다고 답변한다. 그 외 다음 도구에 대한 질문이 꽤나 있었다. 아무래도 근거 자료로 매우 중요한 프로젝트이기 때문인듯 하다.

  • CAR - https://car.mitre.org/
    Cyber Analytics Repository의 약자로 공격에 대한 분석 결과를 저장한 저장소 같은 역할을 담당한다. CVE 처럼 별도의 식별 키워드로 CAR를 사용한다.

3. Operationalizing ATT&CK

SCYTHE사의 CEO인 Bryson Bort가 발표했다. 이 회사는 ATT&CK 프레임워크를 이용하여 레드 팀과 블루 팀을 컨설팅하는 회사다. 5분짜리 영상인 점을 보았을 때 핵심만 골라서 이야기한거 같다. 한마디로 "ATT&CK를 원소 주기율표의 원소들 처럼 이리섞고 저리섞어 활용해야 한다."로 요약할 수 있다.

4. Summiting the Pyramid of Pain: Operationalizing ATT&CK

General Electric의 인텔리전스 분석가 EMMA와 사고 분석가 JUSTIN이 발표했다. 일단 위협 인텔리전스 활동이 얼마나 고통스러운지 파이어아이의 고통의 피라미드(Pyramid of Pain)을 가지고 나왔다. 특히나 IDD(Intelligence Driven Defense)를 수행할 때 인텔리전스 팀과 침해사고 대응팀의 임시적 대화(ad hoc communication)이 가장 큰 고통이며, 이 간극이 인텔리전스 팀이 생산하는 데이터와 침해사고대응팀이 생산하는 데이터에 간극을 일으킨다고 언급한다. 이를 해결하기 위해 선택한 것이 스프레드시트로 데이터를 정립해 운영하는 것이었으나 이 또한 720개가 넘어가는 TTP를 분류하는 점에서 또 다른 고통(Spreadsheet of Pain)으로 이야기를 한다. 

고통에서 해방하고자 만든 자체적인 프로세스인 Tiamat을 소개했다. 한 기업이 위협 인텔리전스를 수용하려면 이러한 고통을 이겨냈을 때 성과가 발현될 듯 싶지만, 전문적이고 지속적으로 활동 가능한 침해사고대응팀부터 만들어야 하지 않을까 싶다. 

5. ATT&CK: All the Things

미공군인 USAA의 정보보안 전문가 Neelsen Cyrus와 디텍션 리더인 David Thompson의 발표다. 사이버 킬체인은 낡은 방법론이고 ATT&CK는 최신 방법론으로 이야기한다. 따라서 ATT&CK로 분석하기 위해 데이터를 수집하여 관리하는데 이를 kafka 메시징 수집기를 이용하고 Logstash를 통해 로그를 분류한다. 90일 데이터는 Elasticsearch 데이터베이스에 기록하고, 1년의 데이터는 Hadoop 파일 시스템을 이용하여 기록한다. 그리고 위협 인텔리전스를 하기 위해 자체적으로 생태계를 구축한 이야기를 한다.

  • DMR(Detection Management Reporting) - 흔히 말하는 대시보드 같은 역할을 하는 기능으로 보인다.
  • DSP(Defense Security Posture) - 탐지 방법을 설정하면 DMR에 반영되고, DMR에서 우선순위를 정하면 DSP에 반영된다. 탐지 방법을 반영하기에 ATT&CK의 TTPs를 여기에 적용한다.
  • GWH - 시그니처 기반으로 큐를 돌려 헌팅되면 그 결과를 보여준다.
  • PAX - 억제 엔진으로 ATT&CK의 모든 정보를 단순히 탐지하는 형태로 사용하면 오탐이 많을 수 있기에 이를 억제하기 위해 사용하는 기능으로 보여진다.
  • AST(A Simulation Tool) - Canaries나 PoC 실행, 공격 명령어 등 공격을 시뮬레이팅할 수 잇는 기능이다.
  • MIST(Malicious Intel Search Tool) - IoC 정보를 수집하거나 인터넷에 공개된 다양한 위협 정보를 수집하는 기능이다.
  • SHP(Secure Hub Portal) - 공격을 매트릭스 형태로 관리하고, 보고서를 생산하는 등 기능을 가진다.

군에서 솔루션을 직접 구축해 운영하고, 그 구축에 필요하다면 오픈소스를 적극 활용하면서 이를 컨퍼런스에서 다양한 전문가에게 공개하고 토론하는 문화가 신기했다.

6. Agile Continuous Improvement Using ATT&CK

음 캘리포니아 치과 의사 협회(Delta Dental of California)? 여기에 사이버 위협 관리자인 Matthew Stiak와 컨설팅 업체인 Level Nine Group의 Jason Sinchak이 발표했다. 주된 내용은 조직에 ATT&CK를 적용하는데 필요한 고찰에 관한 이야기다. 탐지(Detection), 방지(Prevention), 대응(Response) 영역은 꾸준이 발전하고 있으니 식별 영역으로 넘어가자는 의미를 가지고 있다. 이를 위해서 ATT&CK를 고민했는데, 새로운 방법론을 도입할 때 고충은 기존 방법론과의 마찰이다. 이 마찰을 다음과 같이 정의했다.

  • 구조적 제한
  • 교육이 필요
  • 한정된 자원과 시간 관리

이를 해결하기 위해 선택한 방법으로 다음을 제안한다. 제안의 핵심은 애자일이다.

  • 애자일 방법론을 이용하여 장접을 부곽시킨다.
  • 미시적 관점까지 살펴볼 수 있는 퍼플 팀을 창설한다.
  • 각 항목별 평가 지표를 구성한다.

애자일 방법론은 이야기만 들어봤지 구체적으로 무엇인지 모른다. 오늘 퇴근길에 당장 서점에 들려서 애자일 관련 책 중 가장 많이 판매된 책을 한권 구매해서 읽어봐야 할것 같다. 퍼플 팀은 여섯 번째 영상에서 처음 나온 단어인데, 레드 팀과 블루 팀의 소통의 부재를 연결짓고 매니징하는 관리직으로 보면 된다. 다만 여기서 제안하는 'micro' 퍼플 팀은 레드 팀과 블루 팀의 활동의 단편적인 한 블록 단위로 평가를 하는 미시적인 평가를 진행하는 형태로 표현한다. 이 집단에 의해 만든 평가 지표로 객관적인 평가를 구성하여 효과성을 증명하는 것으로 이야기가 마무리된다.

이전 까지는 레드 팀과 블루 팀만 언급나왔다면 처음으로 퍼플 팀에 관한 이야기를 했다. 분야가 다른 두 전문 분야를 섞었을 때 마찰은 커진다. 우리나라는 그 조율을 각 분야의 상급자가 조율했다면, 외국의 경우 여유가 있는지 없는지는 모르겠으나 중재자 역할을 하는 조직을 별도로 운영하는 것으로 알고 있다. 이 점을 미루어 보았을 때 퍼플 팀은 매우 중요한 교두보 효과를 억제할 수 있다고 생각한다.

7. Vendor Panel Discussion

ATT&CK를 이용하는 밴더사 패널이다. Tag Cyber는 처음 보는 회사고 나머지 회사는 요즘 핫한 트렌드에 발맞춰 움직이는 회사들이다. 팔로알토는 다른 회사에 비해 전통성이 있지만.. 토론에 참여한 밴더사는 영상을 보는 기준 왼쪽부터 순서대로 다음과 같다.

  • Tag Cyber - 컨설팅, 교육, eBook 간행물 등을 진행하는 회사다. 이 패널 토의에서 Tag Cyber의 Ed Amoroso 박사는 진행자 역할을 한다.
  • ATTACKIQ - BAS(Breach and Attack Simulation) 솔루션으로 유명한 회사다. 알려진 유출 및 공격 시나리오를 기반으로 자사의 위험성을 판단하는 솔루션으로 특히나 ATTACKIQ에서는 ATT&CK의 분류 방식을 포함하여 광범위한 유출과 공격 시나리오를 제공한다.
  • Endgame - 얼마전에 ATT&CK 시나리오를 에뮬레이팅할 수 있는 솔루션 소개 영상을 보고 감탄한 회사다. 그것 보다 사실 어벤저스 엔드게임을 빨리 보고 싶다.
  • Cybereason - 이스라엘에 본사가 위치한 정보보안 업체로 국내에도 이 회사의 솔루션을 많이 검토하고 사용한다. 이 회사의 대표적인 솔루션은 EDR(Endpoint Detection & Response)로 엔드포인트에서 탐지하고 대응하기 위한 수 많은 로그 분석을 진행하고, 당연히 제품에는 ATT&CK를 활용하고 있는 것으로 알려져있다.
  • Unit 42 at PaloAlto Networks - 팔로알토 네트웤스의 Unit 42는 APT 공격을 전문적으로 분석하고 CTI화하여 운영하는 대표적인 조직 중 하나다.

첫 번째 질문은 ATT&CK 프레임워크에 대한 생각을 물어봤다. 요약하자면 다음과 같다.

  • Unit 42의 Jen은 ATT&CK 프레임워크를 가지고 환경에 적용해보고 그 결과를 통해 방어하는 방법을 다루는 것이 좋다고 언급한다. 특히 오픈소스를 사용하는 경우가 많은데 능력있는 공격자는 오픈소스를 많이 사용하기에 문제되지 않는다고 말한다. 
  • Cybereason의 Ross는 ATT&CK 프레임워크가 로제타 스톤과 비유했는데, 그 이유는 이 프레임워크를 통해 기술적인 것들을 공통된 언어로 사용하여 소통할 수 있었기 때문이다고 말한다. (로제타 스톤은 고대 이집트의 법전이 새겨진 비석인데, 이 비석이 발견되면서 이집트의 상형 문자를 해독하여 이집트 역사를 이해할 수 있게 되었기 때문에 이를 비유한 것으로 보여진다.) 그 외 사이버 보안의 문제로 공격자가 방어자보다 늘 우위에 있는 이유는 많은 시간을 가질 수 있기 때문이라고 말한다. 그렇기에 방어자는 제한된 시간 안에 방어를 유지해야하고, 이러한 상황에 필요한건 효율적인 방어 전략이라고 말한다. 
  • Endgame의 Devon은 수 많은 위협을 어떻게 분류할 것인가, 분류한 것을 어떻게 이해시킬 것인가에 많은 방법이 있는 만큼 많은 고민이 필요하다고 말한다. 이런 고민에 있어서 현지화된 정보만으로는 한계가 있고, 다양한 정보가 공유되어 활용되어야 하는데 ATT&CK 프레임워크가 큰 한몫을 한 것으로 이야기한다. 게다가 ATT&CK는 실제 활용되고 있기에 매우 긍정적으로 이야기한다. 
  • 마지막으로 ATTACKIQ의 Carl은 보안을 경제적으로 접근했다. 방어에 비해 공격자가 100배 정도 되는 금액을 더 많이 소비하여 공격한다고 이야기한다. 이런 비대칭적인 소비에 집중하여 이런 문제를 해결할 수 있는 방법을 찾는 것이 좋지 않을까 이야기한다. 또한 ATT&CK 프레임워크는 더욱 가공되어야 한다고 말한다. 예시로 클라우드 침해에 관한 내용인데, 이 부분은 프레임워크에 포함된 TTPs가 없음을 이야기했다.

마지막에 Carl이 말한 클라우드 침해에 관한 이야기 때문에 중반 이후부터는 일반적인 보안 트렌드와 패널 질문(보안의 고충)에 대한 이야기를 한다. 이 이야기 안에 핵심으로 손꼽을만한 이야기를 한다면 바로 경제 관점에서 바라보는 보안이다. 과거에 공격자는 단순히 Spray-and-pray 모델로 공격을 통한 수익을 노렸다면, 지금은 시스템화되어 있고 기술력있게 공격하여 얼마만큼의 수익을 가질 것인가를 생각한다고 말한다. 

자본주의 시대에 충분히 고려해볼 문제다. 공격자가 방어자의 방어를 뚫는데 많은 시간과 돈(시간이 곧 돈이지)이 든다면 부담감을 느끼거나, 만만하게 시작했다면 손해볼 수 있을 것이다. 그러면 다음 공격은 더 큰 자본을 가지지 않는 이상 쉽지 않을 것이다. 이러한 관점이 경제 관점에서 바라보는 보안으로 이야기할 수 있을 것이다.

8. VCAF: Expanding the ATT&CK Framework to cover VERIS Threat Action Varieties



9. Playing Devil’s Advocate to Security Initiatives with ATT&CK



10. From Red VS Blue to Red Loves Blue



11. Helping Your Non-Security Executives Understand ATT&CK in 10 Minutes or Less



12. ATT&CK as a Teacher



13. Detection Philosophy, Evolution & ATT&CK



14. Decision Analysis Applications in Threat Analysis Frameworks



15. Building an Atomic Testing Program



16. 5 Ways to Screw Up Your Security Program with ATT&CK



17. ATT&CK + OSQuery = Love



18. An ATT&CK Review of 200 Hybrid-Analysis Submissions



19. From Technique to Detection



20. Hunters ATT&CKing with the Data



21. Analyzing Targeted Intrusions Through the Lens of the ATT&CK Framework



22. End User Panel Discussion



23. Sofacy 2018 and the Adversary Playbook



24. From Automation to Analytics



25. The Use of Game Theory with MITRE ATT&CK


'Information Security > CTI & Threat Hunting' 카테고리의 다른 글

MITRE ATT&CKcon 2018 review - 진행 중  (1) 2018.12.21
  1. corehack 2019.05.24 15:27

    좋은 자료 감사합니다.

개요

2013년 FBI는 마약 밀매 사건을 조사를 위해 피조사자의 이메일 수집 영장을 발부받아 마이크로소프트에 데이터를 요청했지만 거부당했다. 마이크로소프트는 통신저장법에 의거 미국이 아닌 타국(아일랜드)에 저장된 데이터이기 때문이었다. 이에 마이크로소프트와 미연방과 다툼이 있었다.

과거에도 유사한 문제가 있었기에 데이터가 저장된 서버의 위치가 영장의 범위를 벗어나는 문제를 개선하고자 시도했던 LEADS(Law Enforcement Access to Data Stored Abroad) Act나 ICPA(International Communications Privacy Act) 모두 통과하지 못했었다. 

도널드 트럼프 대통령은 2018년 종합세출법안(omnibus appropriations bill)을 통과시켰고, 동년 3월 23일 법안에 서명했다. 이 법안에 합법적인 해외 데이터 활용의 명확화를 위한 법률(Clarifying Lawful Overseas Use of Data Act)이 포함되었다. 이로 인해 본격적으로 타국에 저장된 데이터를 압수할 수 있게 되었다. 결국 CLOUD Act에 근거한 새로운 영장을 발부받아 마이크로소프트에 집행했고 CLOUD Act로 새로 발부 받은 영장의 효력을 대법원이 인정했다.

CLOUD Act의 주요 내용

개정 배경

이 법안은 다양한 국가적 범죄(테러, 마약, 불법 거래 등)로 부터 공공을 보호하기 위함과 시대적 상황을 고려하였다.

(1) 통신 서비스 제공 업체가 보유한 전자적 데이터에 적시에 접근할 수 있는 것은 것은 테러를 포함한 심각한 범죄로 부터 공공을 보호하고 대처하기 위한 정부 노력의 본질적인 구성 요소다.

(2) 미국 정부의 이러한 노력은 미국 관할권에 속하는 통신 서비스 제공자의 보호, 통제 또는 소유하는 미국 이외의 지역에 저장된 데이터에 접근할 수 없기에 방해 받고있다.

(3) 타국 정부 또한 심각한 범죄를 대처하기 위한 미국의 통신 서비스 제공자가 보유한 전자 데이터에 대한 접근성을 점점 더 높여나가야 한다.

(4) 통신 서비스 제공자는 미국 법에 의해 공개할 수 없는 전자적 데이터를 타국 정부가 요청할 때 잠재적으로 상충되는 법적 의무에 직면하게 된다.

(5) 통신 서비스 제공자가 미합중국법전 제18편 제121장(일반적으로 “Stored Communications Act”로 알려짐)에 의거 전자 자료 공개를 요구하는 경우 Foreign 법에 의해 통신 서비스 제공자가 공개하는 것을 금지되는 경우도 있어 상충되는 법적 의무가 발생할 수 있다.

(6) 국제 협약은 미국 정부와 타국 정부가 시민의 특권과 프라이버시 보호하는 법규를 공유하는 공통된 약속을 통해 상충될 수 있는 법적 의무를 해결하기 위한 방법을 제공한다.

역외 압수 신설

18 U.S. Code § 2713을 Chapter 121에 신설하여 역외 압수의 명시적 근거를 마련했다.

“전자 통신 서비스나 원격 컴퓨팅 서비스 공급자는 미국 내외에 관계없이 제공자의 보호, 통제 또는 소유에 있는 고객이나 가입자와 관련된 유선이나 전자 통신의 내용 그리고 모든 기록이나 기타 정보를 보존, 백업 또는 공개할 의무를 이 규정에 따라 준수해야 한다.”.

서비스 제공자의 영장 각하신청 제도 개정

18 U.S. Code § 2703(h)(2)를 다음 내용으로 개정하여 서비스 제공자의 영장 각하신청 제도를 개정했다.

“(2) 각하 신청이나 변경 요청 ㅡ (A) 타국의 전자 통신 서비스나 원격 컴퓨팅 서비스를 포함하는 공공 또는 원격 컴퓨팅 서비스에 대한 전자 통신 서비스 제공자는 가입자나 고객의 전선이나 전자 통신 내용을 이 섹션에 의거하여 발급된 법적 절차에 따라 공개해야하며, 공급자가 합리적으로 믿을 만한 법적 절차를 수정하거나 각하할 수 있는 동의서를 제출할 수 있다.

행정협정 체결을 통한 외국 정부에 정보제공의 법적 상충 해결

18 U.S. Code § 2511(2)에 (j)를 추가하여 정보제공을 명시화했다.

“(j) 집행 협약의 대상이되는 외국 정보의 명령에 따라 유선이나 전자 통신 내용을 공개하는 공공이나 원격 컴퓨팅 서비스를 운영하는 통신 서비스 제공 업체는 이 섹션에 의거 위배되지 않도록 법무부 장관이 의회에 섹션 2523을 만족한다고 결정했다”

또한 18 U.S. Code § 2523을 Chapter 119에 신설하여 외국 정부가 데이터 접근에 대한 협약을 마련했다.

집행 협정 요구사항 ㅡ Chapter 119, 121, 206의 목적 상 외국 정부가 데이터에 접근하는 규율을 집행하는 협약은 이 챕터의 요구사항을 충족해야하며, 만약 국무부 장관의 동의와 함께 법무부 장관이 결정하고 (1), (2), (3) 그리고 (4)의 서면 증명과 고려사항에 대한 설명을 포함하여 서면 증명서를 의회에 제출한다.

생각

아무리 CLOUD Act가 활성화 되었다고 하더라도, 타국에 위치한 데이터를 압수하기 위해 영장심의가 없으면 불가능하다. 다시 말해서 합당한 법적 근거가 마련되지 않으면 언제나 편하게 데이터를 살펴볼 수 없다는 것이다. 참고로 CLOUD Act가 승인되면서 구글, 마이크로소프트, 애플의 생각이 포스팅되기도 했다. 이들이 이 법안을 처음부터 지지했는지, 아니면 통과된 법안이기에 어쩔 수 없이 수용하고 앞으로 어떻게 대응할 것인지에 대한 부분은 각자가 판단할 몫이다.

참조 사이트


'Information Security > Digital Forensics' 카테고리의 다른 글

CLOUD Act  (0) 2018.12.19

자격증

취득하면 취소선 그어버립니다~ 물론 다 획득할 생각은 없.. 비싸.. 기타 자격증은 댓글로 부탁드립니다.


국내 자격증

정보보안기사

디지털포렌식전문가 2급

  • 국내 치곤 조금 비쌈(직장인 그저, 학생 비쌈)
  • 디지털 포렌식을 제대로 공부할 수 있는 시험
  • 사이트 - https://forensickorea.org/exam/

IEQ 인터넷윤리자격

  • 국가 공인 자격증으로 3급, 2급, 지도사 이렇게 세 종류로 구분
  • 지도사가 좀 어렵고, 2급이 쉬운편인데 보안이 살짝 들어가있고, 윤리 시험이라서 도덕, 철학 문제가 나옴
  • 2급은 취득했고 지도사 준비중
  • 사이트 - https://license.kpc.or.kr/nasec/qlfint/qlfint/selectIeqinfomg.do

CPPG 개인정보관리사

PIP 개인정보보호사


해외 자격증

EC-Council

국제 전자상거래 컨설턴트를 위한 국제위원회로 민간 자격증을 운영하는 곳으로 자격증 취득하면 액자에 걸면 간지 뿜뿜 할 수 있는 라이선스를 국제 배송으로 보내준다. 영어로 시험쳐야 하고 국제 공인은 아니가 그냥 민간 자격증이라 국내에서는 크게 인정해주지 않는 분위기다.

CND (Certified Network Defender)

  • 네트워크 위협, 분석, 정책 등 네트워크 기반 보안 자격증

CEH (Certified Ethical Hacker)

  • EC-Council의 대표적인 자격증으로 해커 윤리를 강조
  • 우리나라의 IEQ와 달리 도덕과 철학 문제는 없음

ECSA(EC-Council Certified Security Analyst)

  • 침투테스터를 위한 자격증

CHFI(Computer Hacking Forensic Investigation)

  • 컴퓨터 해킹 수사를 위한 자격증으로 미국 법이 나오는걸로 알려져있음

CCISO(EC-Council’s Certified Chief Information Security Officer)

  • CISO 자격증으로 도메인이 거버넌스, 리스크 관리, 보안 전략 기획 이런거 시험침
  • 강의듣고 시험쳐서 획득하는 자격증으로 수료증과 진배없음

CTIA(Certified Threat Intelligence Analyst)

  • 이 자격증 보고 트렌드에 EC-Council은 민감한 곳이구나 싶었다.
  • 강의듣고 시험쳐서 획득하는 자격증으로 수료증과 진배없음

ISACA(Information Systems Audit and Control Association)

IT 거버넌스에 초점을 둔 국제 전문 협회로 국제공인 자격증을 운영하는 곳으로 국내에서도 많이 인정하는 자격증을 운영한다. 특히 국내에서 인기있는 자격증으로 CISA가 있다.

CISA(Certified Information Systems Auditor)

CISM(Certified Information Security Manager)

  • CISA가 정보 시스템 감사 자격증이라면 얜 정보 보호 관리자 자격증
  • 국내에서 CISA 보다 상대적으로 인정을 덜 받는 자격증
  • 사이트 - http://www.isaca.or.kr/info/cism.asp

(ISC)² (International Information System Security Certification Consortium)

여기도 국제 공인으로 사이버 보안 전문가를 위해 교육이나 자격증을 전문으로 운영하며 세계적으로도 인정받는 자격증으로 CISSP이 있다. 호주에 영어시험이랑 CISSP 자격증만 들고가도 기술자로 대우 받으며 영주권 획득 가능하다는 소문이 있었으나 조금만 찾아보면 가산점 부여 되는 정도.. 기술시험도 쳐야한다고.. (http://www.hojujota.com/marn/acs)

CISSP(Certified Information Systems Security Professional)

CCFP(Certified Cyber Forensics Professional)

SSCP(Systems Security Certified Practitioner)

CCSP(The Industry’s Premier Cloud Security Certification)


SANS

1989년에 설립하여 전통있는 정보보안 교육과 자격증을 함께 장사하는 곳으로 교육을 들어야 자격증을 딸 수 있다. 그렇다고 교육의 질이 나쁘거나 자격증 인정 여부가 나쁜 편은 아니다. 뭘해도 비싼 조직 글로벌 강사의 꿈의 조직이다. 엄청나게 많은 자격증을 운영하는데 그 중에 GIAC를 가장 쳐준다.

GIAC 외 기타 자격증 리스트 - https://www.giac.org/certifications/categories

GIAC(Global Information Assurance Certification)


기타

도구 개발한 회사가 자기 도구를 이용한 자격증 시험을 운영하는 곳이다.

ACE(AccessData Certified Examiner)

EnCE(EnCase Certified Examiner)

EnCEP(EnCase Certified eDiscovery Partitioner)

CFSR(Certified Forensic Security Responder)

  • 엔케이스로 하는건 아닌거 같은데 엔케이스에서 운영하는 듯
  • 침해사고대응 쪽 자격증
  • 사이트 - https://www.opentext.com/products-and-solutions/services/training-and-learning-services/course-catalogue/encase-training/forensic-security-responder-certification


개요

대중적으론 악성코드보단 바이러스라는 용어를 더 일상적으로 사용하고, 정보보안을 공부한 사람이라면 악성코드란 용어를 더 친숙하게 받아들인다. 악성코드란 무엇일까. 지금까지 우리는 악성코드란 단어를 의구심 없이 받아 들일뿐 물음표를 던져본적이 없었던 것 같다. 그래서 Malware란 단어를 살펴보기 앞서 악성코드 단어를 분해해보려 한다.

정의 파악

악성(惡性)이란 악한 성질로 이 성질 파악의 주체는 사람의 목적이다. 날카로운 칼이 있다. 이 칼은 어떤 성향을 가진 사람 손에 들려져 있는가에 따라 맛있는 요리를 할 수 있지만, 누군가를 해칠 수도 있다. 어떤 용도로 사용하지 않으면 그냥 물건일 뿐이다. 누군가를 해칠 수도 있다는 가능성이 실현되는 것은 그 주체자의 의도와 행동에 따르기에 물체인 칼은 악한 성질을 가지고 있다고 판단할 수 없다.

코드(Code)란 기호를 의미하며 컴퓨터에서만 사용하는 용어는 아니다. 하지만 여기서는 컴퓨터에서 사용하는 코드를 의미한다. 컴퓨터에서 코드란 하드웨어에서 실행되는 소프트웨어의 요소 중 하나다. 프로그래밍 언어를 이용해 사람은 소스코드를 작성한다. 작성한 소스코드는 컴파일러나 인터프리터에 의해 하드웨어인 CPU가 해석할 수 있는 기계어 코드로 변환된다.

두 정의를 통해 살펴본 것 처럼 악성코드란 악한 성질을 가진 컴퓨터 코드로 볼 수 있다. 앞서 악성의 정의를 살펴본 것 처럼 컴퓨터의 관점에서 악성은 실행되지 않는 코드일 뿐이다. 불편함을 초래하거나 귀찮게하거나 놀리거나 금전적 손실을 일으키거나 컴퓨터를 못쓰게 만드는 등 사람의 입장에서 "이 소프트웨어 나쁘네" 하면 악성코드가 된다.

문제 의식

코드 정의에서 살펴봤듯이 소프트웨어가 하드웨어에서 실행되는 요소 중 하나가 코드며 소개 안한 다른 요소는 데이터다. CPU도 코드 세그먼트(CS)와 데이터 세그먼트(DS)가 따로이 운영되고, 이들이 운영되는 큰 이유인 분할 메모리 모델에서 코드 영역과 데이터 영역이 따로 구분되어 관리될 정도로 중요한 요소다. 데이터는 가공되지 않은 정보다. 데이터는 코드가 동작하는 과정에 사용된 의미를 찾을 수 있으며, 사용자가 데이터를 보고 해석하여 의미를 찾을 수 있다. 이렇게 찾게된 의미를 정보라 부른다.

그렇다면 악성코드는 있는데, 악성 데이터는 없을까? 악성 코드가 동작하기 위해 필요한 데이터는 당연히 악성 데이터다. 이 데이터가 없으면 해당 코드가 동작하지 않으니까. 사용자는 데이터만 보고 악성으로 해석하기 힘들 수 있지만 이미 악성으로 판단된 상황에서 찾은 데이터는 악성으로 해석할 수 있다. 대표적인 경우가 .pdb 파일이다.

.pdb 파일은 Program DataBase의 약자로 프로그램을 개발할 때 다양한 정보가 저장되는 데이터 파일이다. 어떤 악성 소프트웨어를 분석하는 과정에서 .pdb 파일의 경로를 만나게 되거나 운좋게 .pdb 파일을 찾게 된다면 이 파일을 분석하여 컴파일러에 관한 정보, 디버깅에 관한 정보 등 확인할 수 있으며, 이는 분석한 악성 소프트웨어 정보와 결합하여 악성 정보로써 관리된다.

결론

그렇다면 정말 악성코드로 불리는게 맞는 것일까? 현재 우리가 부르는 악성코드와 매핑되는 영단어는 Malware다. 이 단어도 합성어인데 악성을 의미하는 Malicious와 소프트웨어(software)의 조합이다. 소프트웨어는 다시 코드와 데이터와 같은 요소로 이루어져 있다고 정의했었다. 다시 말해서 악성코드와 악성 데이터를 합쳐야 멀웨어가 되는 구조를 가지게 맞다. 앞으론 멀웨어나 악성 소프트웨어로 쭉 써야할 것 같다.

기타

추가로 악성코드란 한국어 명칭이 처음 사용된 것이 언제인지 찾아봤다. 인터넷에서 찾아볼 수 있는 가장 오래된 정보로는 안철수 대표가 1999년 정보보호 심포지움에서 "컴퓨터 바이러스와 악성코드의 현황 및 대책"이란 발표인 것 같다. 아쉽게도 이 제목은 CIH 바이러스 분석 및 대책 논문의 레퍼런스에서 찾아 볼 수 있었을 뿐 발표 자료나 내용은 찾을 수 없었다. 1년이 지난 2000년 한국정보보호센터로 불리던 시절의 KISA에서 발간한 KISA-2000 정보시스템 해킹 바이러스 현황 및 대응 보고서에서 악성코드와 바이러스는 의미가 혼용되어 사용된다. 분명 그 전에 악성코드란 단어가 사용되었던 적이 있었을 것 같다. 정보보안 역사를 경험한 대선배님들과 대화할 기회가 온다면 한번은 물어봐야 할 것 같다.

레퍼런스


'Information Security > Malware' 카테고리의 다른 글

Is malware same mean Korean word 악성코드?  (0) 2018.12.14
랜섬웨어 대응방안  (5) 2017.05.17
[보고서] Mirai Botnet  (0) 2016.12.26
도메인 쉐도잉 (Domain Shadowing)  (0) 2015.03.17
Sweet Orange exploit kit  (0) 2014.09.02
공다팩(Gondad EK) 분석 #04  (2) 2014.08.14

2018년 11월 24일 제 12회 디지털 포렌식 전문가 2급 실기를 쳤다. 11회때 칠 수 있었는데, 형사소송법이랑 증거 수집 절차 같은거 지하철에서 공부하면서 가다가 지하철역 지나쳐버려서 못쳤고, 이번엔 일찍 일어나서 느긋하게 걸어갔다. 시험장소는 동국대 경영관이었고 눈보라 헤쳐가며 한 시간이나 일찍 도착했다. 그때 시험 친 지인들의 이야기를 들어보면 주로 침해사고조사가 베이스인 디지털 포렌식이 시험이었다고 한다. 이번에는 수사를 베이스로한 디지털 포렌식 시험을 칠 꺼라고 이야기 들렸다. 일전에 짬내서 공부했던 것과 시험치기 직전에 벼락으로 살펴봤던 내용 그리고 시험 내용은 다음과 같다.


1. 이미징

전체를 이미징하는 것과 선별적으로 이미징하는 것은 차이가 있다. 최근 이미징의 대부분은 선별적 이미징을 한다고 들었고, 이러한 이유로 물리 드라이브보다 논리 드라이브를 이미징하는 경우가 많다고 하나 이를 시험에 낼것 같진 않았다. FTK Imager나 EnCase를 이용한 이미징을 수행하는 것은 매 실기 시험에 기본 소양으로 알려져 있다. 학교 덕분에 EnCase를 다뤄볼 일이 있고, 물어볼 친구가 있어 간단하게 쓰기 방지와 캐싱 그리고 캐싱에서 이미징하는 것을 두 번 연습했었다. FTK Imager를 주력으로 쓴다면, 레지스트리 기반으로 쓰기 방지를 진행하고, EnCase를 이용한다면 Fast Bloc 기능을 이용한다. 쓰기 방지 설정 후에 USB를 삽입해야 한다. 대부분 시험장은 백신이 동작해서 원본이 손상되니 꼭! 쓰기방지 후에 진행하는 것을 추천한다.

2. 조사

문제에서 요구하는 조건에 맞게 정보와 데이터를 찾을 수 있어야 할 것 같았다. 이전에 자격증을 취득한 분들께 들어보면 문제에서 찾고자하는 무언가에 대한 정보가 불명확한 형태로 문제를 냈었다고 했었다. 다행이도 이번엔 명확하게 무엇을 찾아야 할지 문제에 적혀있어 앞으로 시험을 치룰 사람이면 파일 시스템의 유형이나 용량부터 파일 이름, 해시 등 찾는 방법을 알아두면 좋을 것 같다. 다행이도, 개인적으로 문제에서 요구하는 내용은 사전에 연습하지 않아도 될 만큼 모두 이해할 수 있는 수준의 데이터 유형이었고, 나머지는 어떤 도구에서 어떻게 찾아야 하는가인데, EnCase의 Report와 Process 기능을 알고 있어서 그나마 쉽게 끝낼 수 있었다.

3. 분석

문제에 시나리오가 주어진 상황이었다. 이메일로 주고 받은 내용과 시나리오를 통합해보면 댓글 알바를 통해 대외 이미지를 만들고 이를 통해 당선되는 선거법위반 시나리오 였다. 아쉽게도 이메일 확장자인 .pst, .eml, .ost 같은 것은 알아도, EnCase에서 검색하는 방법을 몰랐다. 간만에 노가다했다. 윈도우 시스템의 폴더 구조를 가지고 있어 User 폴더의 사용자 계정을 추측하고, 디폴트로 많이 사용하는 Download, Documents, Appdata 같은 위치를 찾아봤다. 별도로 설치된 응용프로그램은 보이지 않아 Appdata는 무시하고 Download와 Documents에 있는 정보들을 살펴보다 보니, .eml 파일들이 있었다. 주로 분석할 때 헥사 도구를 자주 사용하는 편이라서 내용을 보려고 EnCase의 Hex 기능으로 살펴보다가 바로 닫았다. Email UTF-8 인코딩이 되어있고, 인터넷이 차단된 상황이기에 온라인 디코더를 이용할 수 없어서 고민하던 찰나, EnCase에 이것저것 만지다 보니 자동으로 디코딩해서 잘 보여주는 기능이 있었다. 이렇게 삽질하면서 하나하나 문제를 해결했다.

4. 법률

법률은 좀 어려웠다. 첫 번째로 동일성의 원칙을 지키기 위해 어떻게 해야하는가에 대한 질문엔 해시라는 키워드를 이용해 기술했다. 두 번째로 증거능력에 대한 문제였는데, 나중에 지인들과 이야기를 하다보니 내가 쓴 답은 증명력에 대한 내용이었다. 증거 능력이 직접 증거와 간접 증거 모두 증거로써 능력을 가진다면 증거능력이 있다는 것이었는데, 이메일로 주고 받은 내용은 간접 증거로써 증거 능력이 있다. 세 번째로 불법 수집한 증거에 대한 증거 능력에 대한 내용인데 이는 형사소송법 제308조의2에 의거 증거능력이 될 수 없다고 적으려다가 기억하는게 잘못되었을 수 있어서 제308조의2를 뺐고 작성했다. 그 외 기억나지 않는 문제에 기술한 답 중에 몇 가지 기억나는 키워드로는 사법공조협조가 있었다. 수사를 하면서 만나는 데이터는 곧 증거이기에 디지털 포렌식 수사에 있어 필히 공부해야할 법률은 증거법이면 충분할 것 같다.

5. 보고서 작성 및 보고

보고서는 템플릿은 자율이었고, 파일 유형은 .docx, .hwp, .pdf로 제작하면 별 문제 없다고 공시되어 있었다. 그냥 그대로 작성하면 된다. 굳이 잘 쓸 필요는 없으나 문제의 답이 되는 내용은 모두 스크린샷이 있는 것이 중요해 보인다. 모든 답안은 CD/DVD에 꿉어서 제출하는데, 한번 기록하면 지울 수 없어 USB 형태를 선택하고 답안을 기록하여 제출했다. 이게 문제될지 안될지는 13회 실기 후기 포스팅이 올라오면 무조건 꿉어서 제출해야 한다는 것이니 시간이 답을 줄듯 싶다.


4시간 동안 친구들이랑 즐겁게 게임하는 느낌이었다. 꼭 그럴땐 시간이 얼마만큼 흘렀는지 모를만큼 집중했기에 마지막 문제까지 작성하고 시계를 보고 깜짝 놀랬다. 30분 밖에 남지 않아서. 몇 개 문제를 잘못 해석해 오답을 썼지만, 비록 CD를 꿉지 않았지만 붙었으면 좋겠다.

  1. Kuncap 2019.07.25 01:31

    실기는 공부를 어떻게 하셨나요??

목차

1. 요약

2. 개요

3. 관리적 대응방안

3.1. 예방 관리

3.1.1. 소프트웨어 보안 업데이트

3.1.2. 레거시 시스템 제거

3.1.3. 백신 소프트웨어 운영

3.1.4. 랜섬웨어에 특화된 소프트웨어 사용

A. 앱체크(AppCheck)

B. NAR(Nuri Anti-Ransom)

3.1.5. 이메일 관리

3.1.6. 운영 관리

A. 원격 접속 프로그램의 기본 접속 계정과 비밀번호 변경

B. 지속적인 보안공지 확인과 권고 이행

3.2. 대비 관리

3.2.1. 백업 관리

A. 물리적 시스템을 이용한 백업

B. 클라우드 시스템을 이용한 백업

3.2.2. 복원 관리

3.2.3. 차단 및 대응

4. 결론

5. 추가 내용

A. 결제해도 파일을 복구해주지 않는다.

B. 복구 업체는 복구할 수 있다.

C. 감염되면 절대 복구할 수 없다.



    1. 요약

    • 소프트웨어 보안 업데이트 - 필수로 사용
    • 레거시 시스템 제거 - 비용 고려하여 최대한 제거, 그렇지 않다면 확실한 접근제어를 구현
    • 백신 소프트웨어 운영 - 인터넷 시큐리티 버전 추천, 유료 상품을 이용
    • 랜섬웨어에 특화된 소프트웨어 사용 - 앱체크 추천
    • 이메일 관리 - 외부 사설 이메일 사용 자제, 실행파일 첨부 자제 문화 형성
    • 운영 관리 - 원격 접속 프로그램의 기본 계정과 비밀번호 변경, 보안 전문업체나 한국인터넷진흥원의 권고 사항 지속적 이행
    • 백업 관리 - 물리 시스템 사용 시 백업 후 연결 끊기, 클라우드 사용 시 브라우저를 통해서만 이용, 자체 클라우드의 경우 동기화 프로그램을 제공하는 서비스를 이용하여 백업
    • 복원 관리 - 복원 시스템 운영하는 것을 추천하나 100% 신뢰하진 않음
    • 차단 및 대응 - 80, 443 포트 외 모든 포트를 차단 후 윈도우 업데이트

    2. 개요

    현재 가장 뜨거운 감자인 워너크라이(WannaCry) 랜섬웨어는 감염된 이후 대응방안은 애매하다. 이미 볼모로 잡힌 디지털 자산들을 해결할 수 있는 방안이 없기 때문이다. 하지만, 악성코드에 감염되기 전 유포는 충분히 대응 가능하다. 앞으로 꾸준히 이슈가 될 랜섬웨어의 핵심 대응방안을 기록해본다. 내용중 일부는 랜섬웨어뿐만 아니라 대다수의 악성코드를 대응하는 방안이 될 수 있다.

    3. 관리적 대응방안

    컴퓨터 시스템을 체계적으로 관리하는 것만으로도 충분히 대응할 수 있다. 관리적 대응방안에는 다음 두 가지 형태로 분류할 수 있다. 예방 관리는 말 그대로 랜섬웨어 감염으로부터 예방할 방안이며, 대비 관리는 랜섬웨어에 감염된 후에 대비할 방안이다.

    3.1. 예방 관리

    3.1.1. 소프트웨어 보안 업데이트

    주로 듣는 질문들을 정리해보면 다음과 같다.

    • 어떻게 랜선만 꼽혀있는데 악성코드에 감염되나요?
    • 웹 사이트 서핑만 했는데 악성코드에 감염될 수 있나요?
    • 문서를 열고 스크립트와 같은 추가 기능을 차단했는데도 악성코드에 감염될 수 있나요?

    위 질문의 대답은 "" 이다. 이러한 악성코드 감염이 가능한 이유는 소프트웨어 취약성(Vulnerability) 때문이다. 취약성을 정확한 개념은 아니지만 쉽게 설명하면 "공격자 마음대로 명령한다." 정도로 볼 수 있다. 이는 네트워크 기준으로 로컬인가, 근거리인가, 원거리인가는 중요하지 않다. 어느 기준이든 위험한 공격 방식이며, 당연한 이야기지만 셋 중에서 원거리 네트워크로 사용할 수 있는 취약성이 가장 위험하다.

    어? 너 취약하네? 너 내가 가리키고 있는 저 파일 다운로드하고 실행해!

    이번 이슈에 접목시켜보면 원거리 공격자가 SMB 버전1 프로토콜에 명령을 던졌을 때 취약하다면 랜섬웨어를 다운로드하고 실행하도록 명령할 수 있다. 물론 취약성이 존재하더라도 공격자가 시스템을 실제 운영하는 사용자만큼 명령을 전달할 수는 없다. 지속적이고 좀 더 용이하게 공격 명령을 구성하거나 이미 모든 명령을 포함한 형태로 한번에 명령하기 위해 악성코드를 감염시킨다. 따라서 취약성을 막는다면 악성코드 감염으로 부터 자유로울 수 있다.

    취약성을 막을 수 있는 가장 안전한 방법은 보안 업데이트를 통한 문제가 되는 소프트웨어의 패치를 진행하는 것이다. 이미 컴파일 된 파일을 패치하는 것은 매우 어렵다. 소스코드를 가지고 있는 회사에서 진행할 수 밖에 없기에 제조사의 보안 패치를 진행하는 것이 중요하다. 이번 워너크라이에 사용된 취약성은 마이크로소프트에서는 MS17-010, MITRE 기준으로 CVE-2017-0144로 명명되어 있다. 이 취약성은 2017년 3월 14일에 보안 패치를 진행했다. 정기적 보안패치나 자동 보안패치를 사용하며 다음 운영체제를 사용하는 사용자라면 이번 이슈에 영향을 받지 않았을 것이다.

    • 윈도우 XP Embedded (POSReady 2009 버전)
    • 윈도우 비스타
    • 윈도우 7
    • 윈도우 8.1
    • 윈도우 10 버전과 
    • 윈도우 서버 2008 & R2, 
    • 윈도우 서버 2012 & R2
    • 윈도우 서버 2016

    대규모 공격에 사용되는 취약성은 패치가 나와있는 취약성을 주로 사용한다. 간혹 패치되기 전에 취약성을 이용한 공격코드가 공개되었을 땐 네트워크 연결을 하지 않는 것이 답이 될 수 있지만, 이러한 상황은 아주 흔하지 않기에 보안 업데이트만 꾸준히해도 대부분의 공격을 막을 수 있다. 취약성을 사용하는 공격중에 웹을 이용한 대규모 공격은 드라이브-바이 다운로드(Drive-by Download) 공격이, 네트워크를 이용한 대규모 공격은 웜(Worm) 공격이 대표적인 케이스다.

    추가로 웹 사이트를 통한 감염의 대응방안에는 자바(Java), 어도비 플래시 플레이어(Adobe Flash Player) 등 마이크로소프트의 제품이 아닌 소프트웨어의 보안 업데이트도 필수로 진행한다.

    3.1.2. 레거시 시스템 제거

    레거시 시스템이란 정품을 사용하더라도 더 이상 서비스를 제공하지 않는 시스템을 의미한다. 예를 들어, 삼성의 마이마이 카세트 플레이어를 사용하고 있다해도 고장나면 삼성 서비스 센터에 카세트를 맡길 수 없다. 이미 오래된 제품이기 때문이다. 

    출처 - 위키트리

    운영체제 서비스가 종료된 버전은 앞으로도 취약성에 의해 문제가 발생할 것이고, 제품을 제작한 회사도 사건이 발생해야 보안 패치를 내놓을 것이다. 말 그대로 서비스가 종료되었기 때문이다. 다음 운영체제는 서비스가 종료된 운영체제로 워너크라이가 이슈가 되었던 13일 당일에 보안 패치할 수 있는 파일을 공개했다.

    • 윈도우 XP SP2
    • 윈도우 XP SP3
    • 윈도우 서버 2003
    • 윈도우 8

    결론적으로 서비스가 중단된 레거시 시스템을 사용하지 않는 것이 중요하다. 어쩔 수 없이 사용해야만 한다면, 확실한 접근제어가 필요하다. 레거시 시스템을 사용하는 아이피와 포트를 면밀히 조사하여 접근을 허용하고 그 외 아이피와 포트는 모두 차단한다.

    3.1.3. 백신 소프트웨어 운영

    백신 소프트웨어 운영을 무시해서는 안된다. 분명 백신은 악성코드 샘플이 수집되어야 분석한 정보를 바탕으로 차단할 수 있기 때문이다. 다르게 이야기하면 경험기반 차단으로 볼 수 있다. 랜섬웨어의 경우 감염된 이후 대응은 의미없을 수 있다. 하지만, 만약 백신 회사에서 미리 악성코드를 분석해 차단했다면 감염되지 않았을 것이다. 그 가능성에 기대해 운영한다.

    또 다른 백신 회사에서는 위에서 언급한 취약성 코드도 차단하기도 한다. 이미 네트워크단에서 차단하기에 감염이 발생하지 않는다. 이 경우 백신 회사에서 운영체제 깊은 부분까지 손봐야하기에 고도의 작업이 동반될 수 있다. 이 부분을 안정적으로 개발하지 않는다면 운영체제가 망가질 수 있기 때문이다. 이러한 제품군은 기존의 백신 제품들 보다 2배 정도 더 비싸다. 하지만 이러한 종류의 백신 가격은 평균적으로 1년 기준 5만원 안팍의 가격을 하기에 투자할만하다. 참고로 이런 형태의 제품군을 업체에서는 인터넷 시큐리티라고 부른다.

    세상에는 참 많은 백신이 있다. 국내 동향에 맞는 악성코드도 좋지만 다양한 차단 방법을 제시하는 해외 기업의 제품을 이용하는 것도 좋다. 사용자마다 언급하는 백신의 장단점이 다르기에 이 포스트에서는 특정 제품을 언급하지는 않는다. 2017 안티바이러스 TOP 10으로 선정한 다음 블로그를 참고해보는 것도 좋다. 아래 그림을 클릭하면 링크로 이동한다.

    3.1.4. 랜섬웨어에 특화된 소프트웨어 사용

    트로이목마나 스파이웨어 등 특정 악성코드에 특화된 솔루션이 존재한다. 랜섬웨어도 동일하게 특화된 솔루션이 있다. 여기서 소개하는 제품은 국내 제품이다. 안티 익스플로잇 제품이나 안티 랜섬웨어 제품은 개인적인 생각으로 국내 제품을 이용하는 것이 좋다. 오랜기간 서비스한 제품이 아닌 경우가 많기에 문제가 야기되면 제작자와 직-간접적으로 소통하여 문제를 해결하기 쉽기 때문이다.

    A. 앱체크(AppCheck)

    앱체크는 CheckMAL에서 만든 제품으로 일반 제품은 무료로 이용할 수 있고, 더 기능이 많은 Pro 버전은 1PC 1년 기준 22,000원이다. 다만 랜섬웨어에 특화되어 있기에 백신 제품과 함께 써야한다. 아래 링크를 클릭하면 홈페이지로 이동한다.

    B. NAR(Nuri Anti-Ransom)

    NAR은 누리랩에서 만든 제품으로 아직 공개되진 않았지만 랜섬웨어에 특화된 차단하는 솔루션이다. 감염행위는 일어나지만 이를 탐지와 동시에 악성 행위와 그 산출물에 관련있는 파일을 신속히 삭제하고 일부 암호화된 파일은 복구하는 구조를 가진다. 자세한 내용과 이번 워너크라이 차단 영상은 케이엘테크놀로지 사이트에서 확인할 수 있으며, 1 PC 1년 기준 가격과, 무료 및 유료 정책, 그리고 무료와 유료로 구분된다면 이 둘의 기능적 차이가 어떨지 기대된다.

    3.1.5. 이메일 관리

    이메일 보안 솔루션을 이용하는 것도 좋으며, 의심스러운 파일은 모두 무시하는 것이 중요하다. 모르는 사람에게 온 이메일은 미리보기 기능을 이용하는 것도 좋다. 첨부파일을 다운로드 받을 경우 확장자 검증을 확실히 해야한다. 확장자 검증은 다음 이미지의 "알려진 파일 형식의 파일 확장명 숨기기"가 기본으로 활성화되어 있기에 해제한 후 사용한다.

    대중적인 구글, 네이버, 다음으로 들어온 메일은 기본적으로 필터링하는 것이 좋다. 기본적으로 실행파일을 첨부하는 것을 자제하는 문화가 정착되는 것이 중요하다.

    3.1.6. 운영 관리

    A. 원격 접속 프로그램의 기본 접속 계정과 비밀번호 변경

    아직 발생하진 않았지만, 원격 접속 프로그램(텔넷, SSH)을 통해 로그인하여 랜섬웨어를 설치하는 웜 형태가 나타날 수 있다. 이러한 이슈는 이미 사물인터넷을 이용한 DDoS 공격으로 유명한 미라이(Mirai) 봇넷이 있다. 만약 공격자가 DDoS 공격을 위한 좀비 악성코드가 아닌 랜섬웨어를 설치하려 했다면 충분히 가능한 내용이다.

    로그인이 가능한 이유는 취약성은 아니다. 사용자가 제대로 설정하지 않은 기본 계정과 비밀번호로 접근하기 때문이다. 공장에서 혹은 제조사에서 제조한 새로운 서비스나 시스템을 구매하여 사용할 경우 필히 이를 변경한다.

    B. 지속적인 보안공지 확인과 권고 이행

    정보보안 전문업체나 국가 기관에서 지속적으로 사이버 위협을 조사하고 대응할 수 있는 방안을 권고한다. 이를 지속적으로 확인하고 이행하는 것이 안전한 시스템을 운영하는데 도움된다. 우리나라에서는 보호나라를 이용하는 것을 추천한다. 아래 그림을 클릭하면 보호나라 사이트로 이동한다.

    3.2. 대비 관리

    3.2.1. 백업 관리

    중요 파일 백업은 항상 들어오던 말이다. 문제는 대부분의 대응방안에서 정기적으로 백업하라고 하지만, 백업한 디바이스랑 연결은 어떻게 해야할지, 클라우드 백업은 어떻게 해야하는지 설명하지 않는다. 

    A. 물리적 시스템을 이용한 백업

    먼저 랜섬웨어는 연결되어 있는 모든 파일시스템을 읽고 암호화하기에 백업이 끝난 물리적 디바이스와 연결을 끊어야 한다. 아무리 백업을 잘해 놓았더라도 백업시스템 마저 랜섬웨어로 피해를 받는다면 복구할 방법은 희박하다. 공유 폴더도 안전하지 않으며, 매번 접근하기 위해 아이피나 도메인을 외우기도 힘들다. 적어도 계정 정보는 기억시켜두고, 패스워드를 입력하여 접근후 백업하고, 백업이 끝나면 연결 해제하는 것을 추천한다.

    B. 클라우드 시스템을 이용한 백업

    클라우드 시스템은 대중적으로 가장 많이 사용하는 원드라이브, N클라우드, 구글 클라우드를 조사했다. 



    먼저 마이크로소프트 원 드라이브에 대해 알아보자. 일부 사용자는 오피스 문서만 작성하여 원 드라이브에 저장하고, 문서를 작성할 때 마다 버전관리를 했기에 복구할 수 있다고 자신할 수 있지만, 문서 버전관리를 이용한 복구는 문서를 열람해서 진행하기에 열리지 않는 암호화된 문서에서는 사용할 수 없는 기능이다. 또 다른 기능으로 로컬에서 삭제했더라도, 클라우드의 휴지통에 가면 삭제된 데이터를 복구할 수 있다. 이러한 형태를 이용하면 복구 가능성은 높아진다. 암호화된 새로운 파일을 생성하고 암호화되지 않은 파일을 삭제하는 형태로 동작하는 랜섬웨어도 존재하기 때문이다. 확률로 계산해야 하기에 도박으로 선택할 필요는 없다. 원 드라이브를 사용하는 사용자 입장에서 가장 좋은 방법은 원 드라이브 소프트웨어를 설치하여 운영하지 않고, 귀찮더라도 브라우저를 통해서만 이용하는 것을 추천한다.

    네이버의 N드라이브는 어떨까.

    N드라이브에도 원 드라이버처럼 버전관리가 가능하다. 다행이도 오피스군에만 한정되어 있진 않지만, 내용을 읽을 수 있는 파일에 한해서만 제공한다. 예를 들어 설치 파일이나 압축 파일은 버전관리로 복구할 수 없다. 다시 말해서 랜섬웨어에 의해 암호화된 파일은 복구할 수 없다. 원 드라이브와 마찬가지로 랜섬웨어가 암호화된 파일을 생성하고 원본 파일을 삭제한다면 휴지통에서 복구할 수 있다. 결론은 위에 동일하기에 N드라이브도 소프트웨어를 설치하여 운영하지 않고, 귀찮더라도 브라우저를 통해서만 이용하는 것을 추천한다.

    구글 드라이브도 위에 동일하다. 동일하게 소프트웨어 형태로 설치하지 않고 브라우저를 통해 이용하는 것을 추천한다. NAS를 자체 클라우드로 분류한다면, 자체 클라우드를 구매할 때 동기화 프로그램을 제공하는 서비스 이용을 추천한다.

    3.2.2. 복원 관리

    시스템 복원을 대응방안으로 제시하는 경우도 있지만, 100% 신뢰할 수 없다. 시스템 복원은 윈도우 비스타 이후 볼륨 섀도우 카피(Volume Shadow Copy)를 사용하는데, 일부 랜섬웨어는 이 볼륨 섀도우 카피를 삭제하는 명령을 포함한다. 이런 랜섬웨어를 만났다면 롤백을 이용한 복구를 할 수 없다. 

    그렇다고해서 무조건 사용하지 않는다는 것은 아니다. 복원할 수 있는 상황도 있을 수 있으니 하나의 대응책으로 사용하는 것이 좋다.

    3.2.3. 차단 및 대응

    이번 워너크라이 랜섬웨어의 취약성 대응방안으로 SMB 프로토콜이 사용하는 UDP 포트 137, 138 TCP 포트 139, 445 포트를 차단하고 네트워크를 연결하도록 설명한다. 그리고 여러 업체의 대응방안에서 포트도 차단하고 SMB 서비스도 사용 중단하여 대응하도록 언급 하지만, 둘 중에 하나만 진행해도 무방하다. 취약한 서비스를 사용하지 않는다면 취약성을 이용한 공격을 사용할 수 없기 때문이다.

    만약 어떤 포트를 차단해야할지 모른겠다면, 80 포트와 443 포트를 기억하자. 이 두 포트는 HTTP와 HTTPS 프로토콜이 사용하는 포트로 윈도우 업데이트는 이 포트를 사용한다. 따라서 이 두 포트를 제외한 모든 포트를 차단하고, 윈도우 업데이트를 진행한 다음 차단을 해제하는 것도 하나의 방법이다.

    4. 마무리

    지금까지 이야기한 대응방안은 랜섬웨어에 포커싱 맞춰 이야기했지만, 다른 악성코드를 대응하는 것에도 도움이 되는 방안이다. 만약 잘못된 대응방안, 현실을 고려하지 않은 상황들, 놓친 대응 방안을 댓글로 남겨주시면 포스팅 내용에 추가하여 이 글을 자세히 읽은 분들에게 도움이 될 수 있도록 하겠다.

    혹시나 늦게라도 MS17-010 취약성을 점검하고 대응하고 싶다면, 다음 사이트를 이용하길 바란다.

    5. 추가 내용

    랜섬웨어에 대한 여러 소문들이 있다. 가장 많이 들은 이야기는 다음 두개이며, 댓글로 문의하시면 답변하겠다. 재미있는 질문은 지속적으로 수정하고 추가할 예정이다.

    A. 결제해도 파일을 복구해주지 않는다.

    일부 사실이다. 하지만 약 80~90% 비율로 해제해 주는 공격자가 더 많다. 그 이유는 시장경제 논리에 따르는데, 랜섬웨어에 감염된 피해자가 결제를 통해 해제를 하지 않는 문화가 자리잡으면 신뢰받지 못해 결제를 하지 않게된다. 자연스레 공격자는 수익이 줄어들 수 밖에 없에 기를 쓰고 복구해주려고 노력한다. 재미있는 사례중 하나로 복구에 실패하면 비용을 환급해주기도 한다. 하지만 왜 이런 이야기를 언론에서 이야기하는가 하면, 수익을 통해 더욱 강력한 악성코드나 공격에 재활용되어 악순환 구조가 만들어지기 때문이다.

    이번 워너크라이의 지불과 관련한 기사가 있으니 참고하기 바란다.

    B. 복구 업체는 복구할 수 있다.

    사실이 아니다. 이슈가 될 정도로 강력한 랜섬웨어의 경우 기술적으로 복구할 수 있는 방법이 안타깝지만 없다. 결국 랜섬웨어 복구 업체의 대부분은 자체적인 방법으로 복구하는 것이 아닌, 공격자에게 결제하여 복구하는 서비스로 위장한다. 물론 결제를 해야만하는 상황이고, 결제하는 방법이 어렵다면 대행 업체를 이용하는 것도 좋다. 그간 결제를 대행하면서 친절히 복구해주는 그룹과 먹튀하는 그룹을 기업 내부적으로 목록화해서 관리하고 있기 때문이다.

    복구업체에 관한 부정적인 기사가 있으니 참고하기 바란다.

    C. 감염되면 절대 복구할 수 없다.

    사실이 아니다. 랜섬웨어의 피해를 복구할 수 있는 방법은 여러가지 있다. 이 방법에는 백업이나 복원 그리고 지불을 통한 복구는 언급하진 않는다.

    • 랜섬웨어 분석을 통해 암호키를 추출 - 랜섬웨어 제작자의 실력 부족으로 나타나는 현상으로 파일 암호키를 파일로 작성하거나 메모리에 암호키가 기록된 경우 그리고 개발자가 고정된 암호키를 사용하는 경우 추출 가능하다.
    • 국제적 민관 합동으로 암호키를 수집한 경우 - 국제적 수사기관이 랜섬웨어 유포자를 검거하고, 유포자가 가지고 있는 키관리 서버를 얻게되면 보안전문업체에게 키를 제공하여 파일을 복구할 수 있는 도구를 제작하는 구조를 가진다. 이 경우 언제 체포될지 모르고, 체포되더라도 서버를 파괴시킬 수도 있기에 언제까지 기다리고 있을 수 만은 없다. 이와 관련하여 대표적인 사이트는 nomoreransom가 있다.


    'Information Security > Malware' 카테고리의 다른 글

    Is malware same mean Korean word 악성코드?  (0) 2018.12.14
    랜섬웨어 대응방안  (5) 2017.05.17
    [보고서] Mirai Botnet  (0) 2016.12.26
    도메인 쉐도잉 (Domain Shadowing)  (0) 2015.03.17
    Sweet Orange exploit kit  (0) 2014.09.02
    공다팩(Gondad EK) 분석 #04  (2) 2014.08.14
    1. Favicon of https://tasda.tistory.com BlogIcon Threat Collector 2017.05.18 06:13 신고

      kall 점검관련 https://securityonline.info/exploit-windows-machine-ms-17-10-easy-like-ms08_067/ 링크도 도움이 될듯합니다.

    2. Favicon of https://tasda.tistory.com BlogIcon Threat Collector 2017.05.18 07:04 신고

      덕분에 좋은 정보 많이 얻어갑니다. 감사합니다.

    3. Favicon of http://moneycoach.kr/ BlogIcon 소액결제 현금화 2017.12.07 03:35

      감사합니다 ~~~

    목차

    1. 개요

    2. 설치

    2.1. 기본 패키지 설치

    2.2. CVE-Search 다운로드

    2.3. 파이썬3 라이브러리 설치

    3. 운영

    1. 개요

    정보보안 인텔리전스에서 CVE는 어떤 위협이 존재하며 이러한 위협이 위험으로써의 가능성을 파악하기에 중요한 자원이다. CVE는 Common Vulnerabilities and Exposures의 약자로 취약점을 식별하고 관리하기 위한 고유 스키마를 의미한다. 여기서 설치하려는 CVE-SEARCH는 이미 HKWT-2016-0001에서 다룬적이 있지만, 일부 잘못된 내용과, 버전 업그레이드가 되었기에 이 문서에서 다시 정리한다.

    게스트 스펙 - CVE-Search Server

    • 운영체제: 우분투 16.04.02 서버 AMD64
    • CPU: 가상 CPU 4코어
    • 메모리: 1GBB
    • 아이피: 192.168.0.

    2. 설치

    2.1. 기본 패키지 설치

    CVE-Search는 기본으로 파이썬3를 사용한다. 따라서 라이브러리 설치할 때 파이썬3에 설치한다. 데이터베이스는 몽고DB를 사용하는데 설치할 버전은 2.X 버전이다. 우분투 기본 저장소에서 2.X 버전을 제공하니 단순하게 설치할 수 있다.

    sudo apt-get install vim git mongodb python3-pip redis-server

    2.2. CVE-Search 다운로드

    이제 git을 이용하여 CVE-Search 소스코드를 다운로드한다. Latest Release가 안정적이니 이 버전을 다운로드한다.

    git clone -b v2.1 https://github.com/cve-search/cve-search

    잘 다운로드 받았는지 확인하려면 git 명령으로 확인한다. commit에 있는 해시값의 앞 18247fd가 아래 그림의 내용과 동일하다는 것을 알 수 있다.

    cd ~/cve-search

    git show

    commit 18247fd56fca63ebbe29303a0b47e8626f47984c

    Merge: 1fe9fa2 46cca81

    Author: Alexandre Dulaunoy <a@foo.be>

    Date:   Mon Jun 13 16:58:31 2016 +0200


        Merge pull request #170 from adulau/master


        Many fixes

    2.3. 파이썬3 라이브러리 설치

    파이썬3 라이브러리는 cve-search 디렉터리의 requirements.txt를 이용하여 설치한다.

    sudo pip3 install -r ~/cve-search/requirements.txt

    설치하는 파이썬3 라이브러리는 다음과 같다.

    • PyMongo
    • Flask
    • Flask-PyMongo
    • Flask-Login
    • Tornado
    • Whoosh
    • Redis
    • Python-dateutil
    • passlib
    • feedformater
    • Whoosh
    • irc
    • sleekxmpp
    • Werkzeug
    • Jinja2
    • itsdangerous
    • click

    3. 운영

    이제 CVE-Search에서 사용될 정보를 가져와서 몽고DB에 저장하는 작업을 진행한다. 먼저 데이터베이스를 생성한다. -p 옵션을 사용하며, 이를 통해 뼈대가되는 CVE 코드를 2002년부터 최신까지 가져온다. 데이터베이스에 데이터를 업데이트하거나 제어하는 과정은 cve-search/sbin 디렉터리에 있는 파이썬 코드로 진행한다. 

    ~/cve-search/sbin/python3 db_mgmt.py -p

    Database population started

    Importing CVEs for year 2002

    Importing CVEs for year 2003

    Importing CVEs for year 2004

    Importing CVEs for year 2005

    Importing CVEs for year 2006

    Importing CVEs for year 2007

    Importing CVEs for year 2008

    Importing CVEs for year 2009

    Importing CVEs for year 2010

    Importing CVEs for year 2011

    Importing CVEs for year 2012

    Importing CVEs for year 2013

    Importing CVEs for year 2014

    Importing CVEs for year 2015

    Importing CVEs for year 2016

    Importing CVEs for year 2017

    다음으로 CPE 딕셔너리를 다운로드한다. CPE 딕셔너리는 Common Platform Enumeration 약자로 컴퓨터 시스템에 존재하는 응용 프로그램, 운영 체제, 하드웨어 장치 등의 클래스를 설명하고 식별하기 위해 표준화한 것이다. CPE는 2.2 버전과 2.3 버전을 제공하며 XML 스키마로 정보를 공식적으로 제공한다.

    ~/cve-search/sbin/python3 db_mgmt_cpe-dictionary.py

    마지막으로 다양한 사이트에서 CVE와 연관있는 정보를 가져온다.

    ~/cve-search/sbin/db_updater.py -c

    CVE와 연관있는 데이터는 다음과 같은 사이트에서 가져온다.

    • cves (Common Vulnerabilities and Exposure items) - source NVD NIST
    • cpe (Common Platform Enumeration items) - source NVD NIST
    • vendor (Official Vendor Statements on CVE Vulnerabilities) - source NVD NIST
    • cwe (Common Weakness Enumeration items) - source NVD NIST
    • capec (Common Attack Pattern Enumeration and Classification) - source NVD NIST
    • ranking (ranking rules per group) - local cve-search
    • d2sec (Exploitation reference from D2 Elliot Web Exploitation Framework) - source d2sec.com
    • MITRE Reference Key/Maps - source MITRE reference Key/Maps
    • ms - (Microsoft Bulletin (Security Vulnerabilities and Bulletin)) - source Microsoft
    • exploitdb (Offensive Security - Exploit Database) - source offensive security
    • info (metadata of each collection like last-modified) - local cve-search
    • via4 VIA4CVE cross-references.



    'Information Security > OpenSource' 카테고리의 다른 글

    CVE-SEARCH v.REV  (0) 2017.05.12
    How to install Cuckoo Sandbox 2.0.x  (31) 2017.05.08
    CVE-SEARCH  (1) 2016.06.29
    How to install Viper 1.3-dev  (0) 2016.04.04
    Mobile Security Framework  (0) 2016.03.02
    Cuckoo Sandbox 2.0 RC1 Release  (0) 2016.01.22

    목차

    1. 개요

    이 문서는 볼라티리티(Volatility)를 이용한 메모리 분석에서 악성코드를 찾기 위한 방법 중 하나로, 화이트리스트 기반으로 메모리 이미지를 구성하고 변경사항을 찾는 방법으로 메모리의 기준점(Baseline)을 구성하기 위한 내용이다. 아직 기준점 구성을 해보지 않았지만, SANS에서 잘 정리된 문서가 있어 이를 번역했다. 참고로 이 문서는 2014년에 작성되어 있기에 최신 볼라티리티 버전과 상이하여 실습에 문제가 발생할 우려가 있다.

    원문 - https://www.sans.org/reading-room/whitepapers/forensics/creating-baseline-process-activity-memory-forensics-35387

    2. 소개

    SANS의 고급 포렌식 분석과 침해사고 과정(Lee & Tilbury, 2013)은 침해 지표 확인을 위한 메모리 검사 프로세스를 정의한다. 불량 프로세스 식별, 프로세스 객체 분석, 네트워크 아티팩트 검토, 코드 삽입의 증거 찾기, 루트킷의 흔적 확인 그리고 의심스러운 프로세스와 드라이버를 덤프하는 총 6 단계로 구성된다. 

    분석가는 불량 프로세스를 식별과 함께 실행중인 프로세스, 부모 프로세스 그리고 시작 지점을 확인한다. 다음과 같은 질문을 생각하며 확인해보자.

    • 프로세스가 있어야만 하나요?
    • 부모 프로세스는 무엇이며 예상되는 동작은 무엇인가요?
    • 운영체제가 시작할 때 프로세스가 함께 시작하나요?

    프로세스 객체를 분석할 때 분석가는 실행 파일의 이름, 실행 파일의 경로, 프로세스 시작에 사용되는 커맨드라인 매개변수 그리고 이와 관련된 보안 식별자를 검사한다. 다음과 같은 질문을 생각하며 검사한다. 

    • 실행 파일이 예상했던 디렉터리에서 시작했나요?
    • 커맨드라인 매개변수는 예상할 수 있는 매개 변수인가요?
    • 프로세스가 실행되는 상황은 예상했는가요?
    • 이러한 실행은 시스템 권한으로 실행되었나요?
    • 아니면 사용자로 실행되었나?

    분석가는 메모리에 로드된 동적 링크 라이브러리(DLL)와 커널 모듈로 볼 수 있다.

    그런 다음 분석가는 estableshed로 연결된 네트워크와 이를 처리하는 프로세스를 검사한다. 

    • 비정상적인 네트워크 연결이 있나요?
    • 프로세스와 관련된 네트워크 연결이 시작되었나요?

    다음과 같은 의문을 가지고 위 세가지에서 공통적으로 이상한점을 찾는다.

    • 어떤 것이 비정상적이다는 것을 알 수 있을까?
    • 자문자답을 위해, 추측하는 것을 어떻게 알 수 있을까?

    문헌과 웹을 통한 검색은 출발지점만 제공받을 수 있다. 한 가지 해결책은 예상되는 것의 기준점을 수립하고, 이 기준점에 부합하는지 알아보는 것이다. 이러한 기준선을 사용하여 예상되는 프로세스를 필터링하여 예상하지 못한 부분에 집중할 수 있다.

    이 문서는 다음과 같은 책을 참고하여 기준점을 수립하는데서 시작한다.

    그런 다음 일련의 Windows 2008 R2 서버의 기준점을 테스트하여 유효성을 검사하고 수정한다.

    3. Windows Server 2008 R2 기준점 생성과 유효성 검사

    3.1. 데이터 수집 접근법

    3.1.1. 메모리 확보

    메모리 분석은 메모리 이미지를 확보하는 것에서 시작한다. 메모리를 확보하는데 사용할 수 있는 여러 도구가 있다. 여기서는 MoonSols의 win66dd.exe를 사용한다. 가장 좋은 방법은 수집 프로세스가 분석중인 시스템에 미치는 영향을 최소화하기 위해 외부 장치를 이용하여 메모리 이미지를 수집하는 것이다. 조사 대상 시스템의 디스크에 이미지를 생성하면 중요한 데이터를 덮어쓰거나 잃을 수 있다. 수집되는 메모리의 양을 감안할 때 기가 바이트 이상의 데이터에 해당할 수 있다. 이 문서의 분석은 디스크 내용이 아닌 메모리 이미지에만 관심이 있으므로 서버의 하드 드라이브에 있는 c:\tmp 디렉터리에서 win66dd.exe를 실행하여 메모리를 확보한다.

    3.1.2. 메모리 분석

    메모리 이미지를 분석하는데 사용할 수 있는 여러 도구가 있다. 이 문서에서는 파이썬으로 작성된 오픈소스 메모리 분석 프레임워크인 볼라티리티(Volatility Wiki, 2013)를 선택했다. 볼라티리티는 윈도우 XP 서비스팩 2 메모리 이미지(Volatility Wiki, 2013)를 분석하는 것을 제외하고, 명령을 실행 할 때 메모리 이미지 형식을 정의해야 한다. 분석에 사용된 형식인 Win2008R2SP1x64는 vol.py -f mem.img imageinfo 명령을 실행하여 정의한다. 여기서 mem.img는 분석하려는 이미지 파일의 이름이다. 모든 볼라티리 명령에 이미지 형식을 포함하는 대신 다음과 같이 VOLATILITY_PROFILE를 환경변수에 설정하여 사용할 수 있다.

    export VOLATILITY_PROFILE=Win2008R2SP1x64

    3.1.3. 서버 설치

    Windows Server 2008 R2는 Vmware Tools를 설치한 VMware Workstation 9.0에 설치했다. Windows의 모든 변형은 하나의 설치 ISO 이미지로부터 설치했다. systeminfo | find "OS" 명령을 사용하여 Windows Server 2008 R2 버전이 6.1.760 서비스팩 1 빌드 7601인 것을 알 수 있다. 운영체제 업데이트는 적용하지 않았다.

    3.2. 초기 기준점 구축

    메모리에서 프로세서의 기준점을 구성하기 위한 시작은 부팅할 때 운영체제가 로드하는 핵심 프로세스와 사용자가 로그인할 때 로그되는 프로세스에 대한 기본적인 이해가 필요하다. 이는 Windows Internals 6th Part 1, 2 (Russinovich, Solomon & Ionescu, 2012a, 2012b)에서 자세히 설명되어 있다. 중요한 윈도우 프로세스의 요약은 The Art of Memory Forensics (Ligh, Case, Levy, and Walters, 2014), Windows Processes or Die Trying (Olsen, 2014) literature 뿐만 아니라 SANS DFIR Digital Forensics and Incident Response Poster (Pilkington & Lee, 2014) 문서에서 찾을 수 있다.

    메모리에서 프로세스 목록에 나타나는 첫 번째 프로세스는 시스템이다. 시스템은 커널 프로세서를 위한 컨테이너다. (Ligh, Case, Levy 그리고 Walters, 2014) 정적 프로세스 ID가 4이고 부모 프로세스는 없다. 시스템이 세션 관리자(smss.exe)를 시작한다. (Olsen, 2014)

    smss.exe는 부팅 시퀀스의 첫 번째 사용자 모드 프로세스다. 세션 생성과 관련있다. 부팅 시 두 개의 세션이 생성된다. 세션 0은 시스템과 윈도우 서비스가 소유한 프로세스를 포함한다. 세션 2는 사용자가 소유한 프로세스를 포함(Ligh, Case, Levy 그리고 Walters, 2014)한다. smss.exe는 각 세션에 대해 클라이언트/서버 런타임 하위 시스템(csrss.exe)을 복사하는데서 시작한다. 윈도우 초기화 프로세스 (wininit.exe)를 시작하여 세션 0을 초기화하고 윈도우 로그온 프로세스(winlogon.exe)를 시작하여 사용자 세션을 초기화한다. 각 사용자 로그온에는 로그온할 때 만들어지는 고유한 세션 ID가 있다. 새 세션을 만들 때, smss.exe는 자체적으로 세션을 초기화하고 종료하는 자식 인스턴스를 만든다. 이러한 이유로, csrss.exe, wininit.exe 그리고 winlogon.exe의 부모 프로세스 아이디(PPID)는 메모리에 있는 프로세스(Pikington & Lee, 2014)의 프로세스 ID (PID)로 다시 매핑되지 않는다. 

    Wininit.exe는 세션 0에서 실행되는 사용자 모드 초기화 프로세스를 수행한다. 여기에는 로컬 보안 기관 (lsass.exe), 세션 관리자 서비스 로드(lsm.exe), 그리고 시스템 제어 관리자(service.exe)가 포함된다. lsass.exe는 로컬 보안 정책을 담당한다. lsm.exe는 새 세션을 시작할 때 smss.exe를 호출하여 터미널 서버 세션을 관리한다. (Olsen, 2014)

    윈도우는 대부분의 운영체제처럼 대화형 사용자와 관련없는 프로세스가 있다. 대신 사용자 로그온과 독립적으로 실행된다. 이들은 서비스라고 부르고, services.exe에 의해 실행된다. 윈도우는 각 서비스를 자체 프로세스로 실행하지 않는다. 대신 서비스를 공통적인 특성과 함께 서비스 그룹으로 그룹화한다. 이러한 서비스 그룹은 svchost.exe라는 일반 프로세스를 사용하여 시작된다. 여러 svchost.exe가 메모리에서 실행되는 것을 볼 수 있다. svchost.exe는 실행될 서비스 그룹을 지정하는 -k 매개 변수와 함께 시작된다. 표 1에 나열된 내용은 Windows Internals Part 1 (Russinovich, Solomon & Ionescu, 2012a)에 정의된 주요 시스템 그룹으로 초기 기준점을 채운다.

    윈도우 부팅 프로세스에 대한 설명에서 볼 수 있듯이 프로세스 메모리 분석을 위한 초기 기준점을 구축할 수 있다. 표 2는 메모리 덤프에서 찾을 수 있는 세션 0에 관한 프로세스를 요약한다.

    대화형 로그온 프로세스의 책임은 Winlogon.exe가 가진다. 이는 LoginUI.exe 프로세스 실행으로 사용자 로그온 상호 작용, 암호 변경 그리고 워크스테이션 잠금과 해제를 관리한다. (Russinovich, Solomon & Ionescu, 2012a).  사용자가 성공적으로 인증되면 레지스트리 값 HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\shell에 정의된 쉘 프로세스가 시작된다. 기본 쉘 프로세스는 Explorer.exe다. 이는 Userinit 프로세스에 의해 시작되고, explorer.exe가 시작되면 끝난다. 따라서, 부모 프로세스 실행을 찾을 수 없다. 원격 데스크톱을 통해 로그인한 사용자의 경우, 콘솔이 아닌 사용자의 세션과 관련된 rdpclip.exe 프로세스가 메모리에서 발견된다.

    사용자 세션은 다음과 같은 세 가지 상태를 가진다.

    • 사용자가 로그인되어 있지 않다

    • 사용자가 콘솔로 로그인되어 있다

    • 사용자가 원격으로 로그인 되어 있다

    표 3은 이러한 각각의 상태에서 볼 수 있는 프로세스를 보여준다. 이는 사용자 로그온 프로세스를 위한 기초 기준점을 구성한다. 부모 프로세스의 종류가 등재되지 않기에 PPID는 메모리에서 프로세스로 다시 추적하지 않는다. 사용자 세션이 세션 1, 세션 2 등 될 수 있기 때문에 모든 세션을 사용자 세션으로 참조한다.

    프로세스뿐만 아니라 메모리 포렌식에 대한 기준점을 만들려면 동적 링크 라이브러리, 모듈 그리고 드라이버에 대해 생각해봐야 한다. 동적 링크 라이브러리(DLLs)가 가지는 코드와 자원은 여러 프로세스 사이에 공유된다. 모듈은 운영체제 커널에서 로드되는 코드다. 마지막으로 드라이버는 하드웨어 장치와 통신할 수 있게 컴퓨터에서 허용하는 코드다. (Ligh, Case, Levy, 그리고 Walters, 2014). 이러한 각각의 아티팩트는 많은 수의 객체로 구성되기에, 검색보다는 실제 시스템을 분석하여 기준점을 만드는 것을 추천한다.

    포렌식 분석가가 관심을 갖는 또 다른 속성은 프로세스에 의해 개방되어 연결되는 네트워크다. 이들은 netscan 플러그인을 사용하여 볼 수 있다. 기준점의 네트워크 연결 부분은 실제 시스템에서 데이터를 수집한 다음 분석하여 구성한다.

    3.3. 일반적인 윈도우 서버 2008 R2에 대한 기본점 테스트

    초기 메모리 기준점을 만들었으므로, 실제 시스템에서 수집한 메모리 이미지와 비교하여 유효성을 검사하고 개선할 수 있다. 첫 번째 Windows 2008 R2 서버는 작업 그룹의 일부인 일반 표준 설치를 사용하여 구축했다. Windows 미디어를 이용한 새로운 설치이기에 "깨끗"한 것으로 간주한다.

    3.3.1. 불량 프로세스 식별

    메모리 분석 방법론의 1 단계는 불량 프로세스 찾는 것으로 시작한다. 깨끗한 서버이기에 불량 프로세스가 없어야 하므로 초기 기준점에 포함되지 않은 프로세스를 찾는다.

    아래 출력은 볼라티리티의 pslist 플러그인을 사용하여 출력한 프로세스 목록이다. 페이지에 맞추기 위해 cut 명령을 사용하여 관련이 없는 출력은 제거했다. 부팅 프로세스를 로그온 프로세스와 분리하기 위해 이들 사이에 시간차를 두었다. 이는 아래에 표시된 시작 시간 열에서 볼 수 있다.

    $ vol.py -f win2008r2-01-a.img pslist | cut -c 20-76,84-104
    Volatility Foundation Volatility Framework 2.3.1
    Name                    PID   PPID   Thds     Hnds   Sess Start
    -------------------- ------ ------ ------ -------- ------ --------------------
    System                    4      0     76      460 ------ 2014-06-22 13:26:36
    smss.exe                232      4      2       29 ------ 2014-06-22 13:26:36
    csrss.exe               324    316      9      335      0 2014-06-22 13:26:42
    csrss.exe               376    368     10      189      1 2014-06-22 13:26:43
    wininit.exe             384    316      3       79      0 2014-06-22 13:26:43
    winlogon.exe            420    368      3       96      1 2014-06-22 13:26:43
    services.exe            480    384      8      189      0 2014-06-22 13:26:44
    lsass.exe               488    384      6      530      0 2014-06-22 13:26:45
    lsm.exe                 496    384     10      145      0 2014-06-22 13:26:45
    svchost.exe             588    480     11      345      0 2014-06-22 13:26:48
    svchost.exe             656    480      6      233      0 2014-06-22 13:26:49
    svchost.exe             744    480     13      288      0 2014-06-22 13:26:49
    svchost.exe             788    480     26      824      0 2014-06-22 13:26:49
    svchost.exe             836    480     10      508      0 2014-06-22 13:26:50
    svchost.exe             884    480      7      198      0 2014-06-22 13:26:51
    svchost.exe             928    480     16      429      0 2014-06-22 13:26:51
    svchost.exe             216    480     17      289      0 2014-06-22 13:26:53
    spoolsv.exe             904    480     13      313      0 2014-06-22 13:26:54
    svchost.exe            1040    480      3       46      0 2014-06-22 13:26:56
    vmtoolsd.exe           1096    480      9      253      0 2014-06-22 13:26:56
    TPAutoConnSvc.         1292    480     10      140      0 2014-06-22 13:26:59
    dllhost.exe            1456    480     13      194      0 2014-06-22 13:27:01
    msdtc.exe              1612    480     12      147      0 2014-06-22 13:27:03
    svchost.exe            1752    480      5       67      0 2014-06-22 13:29:01
    taskhost.exe           1276    480      5      118      1 2014-06-22 13:34:03
    TPAutoConnect.         1328   1292      5      126      1 2014-06-22 13:34:03
    conhost.exe            1556    376      1       30      1 2014-06-22 13:34:03
    dwm.exe                1116    884      3       65      1 2014-06-22 13:34:03
    explorer.exe            848    968     15      478      1 2014-06-22 13:34:03
    vmtoolsd.exe           2012    848      7      184      1 2014-06-22 13:34:06
    cmd.exe                 332    848      1       20      1 2014-06-22 13:39:31
    conhost.exe            1228    376      2       36      1 2014-06-22 13:39:31
    win64dd.exe             868    332      2       49      1 2014-06-22 13:52:33

    위에 굵게 표시된 줄은 기준점에 존재하지 않은 프로세스를 의미한한다. 이들은 더욱 면밀히 조사해야할 대상이다.

    서버는 Vmware Workstation에서 실행되므로, 일반적인 윈도우 설치의 일부가 아닌 VMware와 관련된 프로세스가 존재할 수 있다. 이와 관련해서 실제로 TPAutoConnSvc.exe, TPAutoConnect.exe 그리고 vmtoolsd.exe 세 프로세스를 볼 수 있다. VMware와의 관계에 관한 단서는 프로세스 정보를 자세히 검토할 때 제공받는다. 이 프로세스들은 각각 dlllist 플러그인을 통해 출려된 것 처럼 C:\Program Files\VMware\VMware Tools\  디렉터리에서 실행된다.

    $ vol.py -f win2008r2-01-a.img dlllist -p 1096 | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    vmtoolsd.exe pid: 1096
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
    $ vol.py -f win2008r2-01-a.img dlllist -p 1292 | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    TPAutoConnSvc. pid: 1292
    Command line : "C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe"
    $ vol.py -f win2008r2-01-a.img dlllist -p 1328 | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    TPAutoConnect. pid: 1328
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30

    VMware Knowledge base (2014)는 가상 인쇄 모듈이 설치될 때 TPAutoConnect.exeTPautoConnSvc.exe가 시작되는 것으로 설명한다. 세션 0의 서비스 제어 관리자(SCM)가 TPAutoConnSvc.exe를 시작하는 것을 pslist 출력에서 확인할 수 있다. TPAutoConnect.exe는 세션 1을 초기화 할 때 TPAutoConnSvc.exe에 의해 시작된다. VMware 도구 서비스 (vmtoolsd.exe)는 게스트 윈도우 운영 체제 (VMware, 2011)에 설치된다. pslist 결과에서 세션 0과 세션 1 모두에서 실행중인 vmtoolsd.exe의 인스턴스가 있음을 알 수 있다. 따라서 이러한 프로세스는 기준점에 추가된다.

    일부 메모리 아티팩트는 사용자 로그온에 의해 도입된다. LogonUI.exe는 사용자가 로그인했기에 존재하지 않는다. 대신 taskhost.exe, conhost.exe 그리고 dwm.exe를 포함하여 로그인 성공과 관련된 여러 프로세스를 볼 수 있다. 이러한 프로세스는 초기 기준점의 일부가 되지 않는다. 표 4는 사용자가 로그온 할 때 시작되는 프로세스의 수정된 목록을 제공한다.

    또 다른 그룹의 아티팩트는 실제 메모리 획득과 관련있다. cmd.exewin64dd.exe (PID 868)가 메모리 이미지 수집을 위해 시작하기 위해 관리 모드(PID - 332)로 실행 되었다. cmd.exe가 실행되면 윈도우는 지원 프로세스인 콘솔 호스트(conhost.exe - PID 1228)도 실행된다. 이러한 마지막 그룹은 프로세스 기준점의 일부는 아니지만 메모리 이미지를 분석 할 때 고려해야할 사항이다.

    spoollvc.exe, dllhost.exe 그리고 msdtc.exe 프로세스가 초기 기준점의 일부가 아닌 services.exe에 의해 시작되었다. dllhost.exe는 COM(Component Object Model) 개체 (Startup Programs Database, 2014c) 관리와 연결된다. msdtc.exe는 분산 트랙잭션 코디네이터 (Startup Programs Database, 2014d)다. spoolsvc.exe는 스풀러 서비스이며 인쇄와 관련있다. (Startup Programs Database, 2014e)

    3.3.2. 프로세스 개체 분석

    메모리 분석 방법론의 2 단계는 프로세스 개체를 검사하는 것이다. 볼라티리티 플러그인으로 dlllist을 사용할 것이다. 매우 장황하기 때문에 명령을 통해 smss.exe라는 하나의 프로세스 (PID는 232)로 제한했다. 이 명령의 출력은 아래에서 볼 수 있듯이 프로세스를 시작하는데 사용된 명령과 프로세스와 관련된 DLL에 대한 정보를 제공한다.

    $ vol.py -f win2008r2-01-a.img -p 232 dlllist
    Volatility Foundation Volatility Framework 2.3.1
    ************************************************************************
    smss.exe pid:    232
    Command line : \SystemRoot\System32\smss.exe
    
    Base                         Size      LoadCount Path
    ------------------ -------------- -------------- ----
    0x0000000047a50000        0x20000         0xffff \SystemRoot\System32\smss.exe
    0x0000000077120000        0x1a9000        0xffff C:\Windows\SYSTEM32\ntdll.dll

    관심 가져야할 부분은 프로세스 이름, 프로세스 ID 그리고 프로세스를 시작하는데 사용된 커맨드라인이므로 dlllist 플러그인에서 grep을 사용하여 커맨드라인을 출력하여 축약된 결과물을 생성할 수 있다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    smss.exe pid: 232
    Command line : \SystemRoot\System32\smss.exe
    --
    csrss.exe pid: 324
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    csrss.exe pid: 376
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    wininit.exe pid: 384
    Command line : wininit.exe
    --
    winlogon.exe pid: 420
    Command line : winlogon.exe
    --
    services.exe pid: 480
    Command line : C:\Windows\system32\services.exe
    --
    lsass.exe pid: 488
    Command line : C:\Windows\system32\lsass.exe
    --
    lsm.exe pid: 496
    Command line : C:\Windows\system32\lsm.exe
    --
    svchost.exe pid: 588
    Command line : C:\Windows\system32\svchost.exe -k DcomLaunch
    --
    svchost.exe pid: 656
    Command line : C:\Windows\system32\svchost.exe -k RPCSS
    --
    svchost.exe pid: 744
    Command line : C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
    --
    svchost.exe pid: 788
    Command line : C:\Windows\system32\svchost.exe -k netsvcs
    --
    svchost.exe pid: 836
    Command line : C:\Windows\system32\svchost.exe -k LocalService
    --
    svchost.exe pid: 884
    Command line : C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted
    --
    svchost.exe pid: 928
    Command line : C:\Windows\system32\svchost.exe -k NetworkService
    --
    svchost.exe pid: 216
    Command line : C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork
    --
    spoolsv.exe pid: 904
    Command line : C:\Windows\System32\spoolsv.exe
    --
    svchost.exe pid: 1040
    Command line : C:\Windows\system32\svchost.exe -k regsvc
    --
    vmtoolsd.exe pid: 1096
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
    --
    TPAutoConnSvc. pid: 1292
    Command line : "C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe"
    --
    dllhost.exe pid: 1456
    Command line : C:\Windows\system32\dllhost.exe /Processid:{02D4B3F1-FD88-11D1-
    960D-00805FC79235}
    --
    msdtc.exe pid: 1612
    Command line : C:\Windows\System32\msdtc.exe
    --
    svchost.exe pid: 1752
    Command line : C:\Windows\system32\svchost.exe -k
    LocalServiceAndNoImpersonation
    --
    taskhost.exe pid: 1276
    Command line : "taskhost.exe"
    --
    TPAutoConnect. pid: 1328
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
    --
    conhost.exe pid: 1556
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    dwm.exe pid: 1116
    Command line : "C:\Windows\system32\Dwm.exe"
    --
    explorer.exe pid: 848
    Command line : C:\Windows\Explorer.EXE
    --
    vmtoolsd.exe pid: 2012
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
    --
    cmd.exe pid: 332
    Command line : "C:\Windows\system32\cmd.exe"
    --
    conhost.exe pid: 1228
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    win64dd.exe pid: 868
    Command line : win64dd /f win2008r2-01-a.img

    프로세스를 시작하고 services.exe에서 시작한 서비스 그룹을 식별하는데 사용되는 명령의 유효성을 검사하기 위해 dlllist 플러그인의 출력을 기준점과 비교한다. 이를 통해 DcomLaunch, PRCSS 그리고 regsvc의 세 가지 서비스 그룹을 신속하게 파악할 수 있다. 이들 모드 기준점에 존재하지 않아 추가될 필요가 있다.

    프로세스 분석 단계에는 프로세스가 예외 계정으로 실행중인지 확인하는 작업을 포함한다. 이 정보는 볼라이티리 플러그인 getsid를 통해 작업할 수 있다. 아래의 예는 PID가 488인 하나의 프로세스에 대한 출력을 보여준다.

    $ vol.py -f win2008r2-01-a.img -p 488 getsids
    Volatility Foundation Volatility Framework 2.3.1
    lsass.exe (488): S-1-5-18 (Local System)
    lsass.exe (488): S-1-5-32-544 (Administrators)
    lsass.exe (488): S-1-1-0 (Everyone)
    lsass.exe (488): S-1-5-11 (Authenticated Users)
    lsass.exe (488): S-1-16-16384 (System Mandatory Level)

    볼라티리티 출력은 아래와 같이 uniq 명령을 사용하여 축약할 수 있다. 다음은 각 프로세스와 그 프로세스를 실행시킨 계정의 목록이다. uniq 명령은 완벽하지 않다. 시스템에 몇 줄의 중복 선이 표시되지만 분석 프로세스는 여전히 단순하다.

    $ vol.py -f win2008r2-01-a.img getsids | uniq -w 18
    Volatility Foundation Volatility Framework 2.3.1
    System (4): S-1-5-18 (Local System)
    System (4): S-1-1-0 (Everyone)
    System (4): S-1-5-11 (Authenticated Users)
    System (4): S-1-16-16384 (System Mandatory Level)
    smss.exe (232): S-1-5-18 (Local System)
    csrss.exe (324): S-1-5-18 (Local System)
    csrss.exe (376): S-1-5-18 (Local System)
    wininit.exe (384): S-1-5-18 (Local System)
    winlogon.exe (420): S-1-5-18 (Local System)
    services.exe (480): S-1-5-18 (Local System)
    lsass.exe (488): S-1-5-18 (Local System)
    lsm.exe (496): S-1-5-18 (Local System)
    svchost.exe (588): S-1-5-18 (Local System)
    svchost.exe (656): S-1-5-20 (NT Authority)
    svchost.exe (744): S-1-5-19 (NT Authority)
    svchost.exe (788): S-1-5-18 (Local System)
    svchost.exe (836): S-1-5-19 (NT Authority)
    svchost.exe (884): S-1-5-18 (Local System)
    svchost.exe (928): S-1-5-20 (NT Authority)
    svchost.exe (216): S-1-5-19 (NT Authority)
    spoolsv.exe (904): S-1-5-18 (Local System)
    svchost.exe (1040): S-1-5-19 (NT Authority)
    vmtoolsd.exe (1096): S-1-5-18 (Local System)
    TPAutoConnSvc. (1292): S-1-5-18 (Local System)
    dllhost.exe (1456): S-1-5-18 (Local System)
    msdtc.exe (1612): S-1-5-20 (NT Authority)
    svchost.exe (1752): S-1-5-19 (NT Authority)
    taskhost.exe (1276): S-1-5-21-2236604341-3981238657-2714753860-1000
    TPAutoConnect. (1328): S-1-5-21-2236604341-3981238657-2714753860-1000
    conhost.exe (1556): S-1-5-21-2236604341-3981238657-2714753860-1000
    dwm.exe (1116): S-1-5-21-2236604341-3981238657-2714753860-1000
    explorer.exe (848): S-1-5-21-2236604341-3981238657-2714753860-1000
    vmtoolsd.exe (2012): S-1-5-21-2236604341-3981238657-2714753860-1000
    cmd.exe (332): S-1-5-21-2236604341-3981238657-2714753860-1000
    conhost.exe (1228): S-1-5-21-2236604341-3981238657-2714753860-1000
    win64dd.exe (868): S-1-5-21-2236604341-3981238657-2714753860-1000

    위 출력에서 한 가지 주의 사항은 두 개의 SID가 볼라티리티에 의해 NT Authority로 나열된다는 것이다. S-1-5-19는 로컬 서비스로 변환되고 S-1-5-20은 네트워크 서비스(Microsoft Knowledge Base, 2013a)로 변환된다. "-1000"으로 끝나는 긴 번호를 가진 SID는 사용자와 연결된다. 따라서 taskhost.exe, cmd.exe 그리고 win64dd.exe와 같은 프로세스는 사용자 컨텍스트에서 실행 중이다.

    예상대로 svchost를 사용하여 시작된 여러 서비스에는 서비스 그룹의 요구사항에 따라 다른 SID가 존재한다. 또한 로그온 한 사용자와 관련된 프로세는 사용자 SID와 연결된다.

    분석할 또 다른 메모리 아티팩트는 DLL이다. dlllist 플러그인으로 생성된 DLL의 전체 목록은 다소 길다. 앞에서 설명한 것 처럼 DLL 외에 다른 정보를 포함한다. DLL을 나열하는 각 행은 "0x"로 시작하고 dlllist 플러그인의 출력은 DLL만 나열하도록 생성하는 장점을 이용할 수 있다. 다음 명령은 DLL이 들어있는 행을 나열한 다음 계산한다. 전체적으로 1,411개의 DLL이 확인되었다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep "^0x" | cut -c 20-37,57- | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    1411

    DLL 목록을 검사하면, 여러 프로세스가 동일한 DLL을 사용하기에 중복되어 있다는 사실이 명확해진다. 목록을 정렬한 다음 고유한 행만 표시하고 대소문자를 무시함으로써 목록을 상당히 줄일 수 있다. 아래의 명령은 메모리 이미지에서 370개로 축소한 것을 보여준다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    370

    기준점에서 370개 항목을 나열하는 표를 작성하는 대신 다른 메모리 이미지에서 실행된 동일한 명령의 출력과 비교할 수 있는 파일을 작성하여 기준점에 나열되지 않은 DLL을 찾는다. 파일은 속하지 않은 항목이 없는지 확인하기 위해 검토되어야 한다. 하나의 항목인 win64dd.exe는 메모리 수집 프로세스의 일부로 도입되었기에 제거해야 한다. DLL 기준점을 만드는데 사용되는 명령은 다음과 같다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i > dll-baseline-01.lst
    Volatility Foundation Volatility Framework 2.3.

    유사하게, 볼라티리티는 모듈이라고 불리는 커널 모듈을 메모리에 나열할 수 있게 플러그인을 제공한다. 출력된 결과를 검토하면 메모리에 147개의 모듈이 있다. 비슷한 접근 방식을 사용하여 아래와 같이 모듈의 기준점을 작성한다.

    $ vol.py -f win2008r2-01-a.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    147
    $ vol.py -f win2008r2-01-a.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i > module-base-01.lst
    Volatility Foundation Volatility Framework 2.3.1
    $ cat module-base-01.lst | wc -l
    147

    파일은 속하지 않은 항목이 없는지 확인하기 위해 검토헤애 한다. Win64dd.sys는 메모리 수집 프로세스의 아티팩트이기에 제거되었다.

    3.3.3. 네트워크 아티팩트 검토

    Windows Vista와 Windows Server 2008부터 마이크로소프트는 IANA 권장 사항(Microsoft Knowledge Base, 2013c)에 따라 동적 포트 범위 할당을 1025부터 5000을 49152에서 65535로 변경했다. 볼라티리티의 netscan 플러그인은 열린 포트 목록과 해당 포트를 소유한 프로세스 목록을 제공한다. 각 svchost.exe 인스턴스를 소유하고 있는지 확인하기 위해 추가 분석을 수행한다. 예를 들어 다음을 고려한다.

    $ vol.py -f win2008r2-01-a.img netscan | cut -c 12-18,21-40,51-63,88-92,94-112 | uniq -w 20
    Volatility Foundation Volatility Framework 2.3.1
    Proto  Local Address        Foreign Addr  Pid      Owner
    TCPv4  0.0.0.0:49156        0.0.0.0:0     480      services.exe
    TCPv6  :::49156             :::0          480      services.exe
    TCPv4  0.0.0.0:445          0.0.0.0:0     4        System
    TCPv6  :::445               :::0          4        System
    TCPv4  0.0.0.0:47001        0.0.0.0:0     4        System
    TCPv6  :::47001             :::0          4        System
    TCPv4  0.0.0.0:49153        0.0.0.0:0     744      svchost.exe
    TCPv6  :::49153             :::0          744      svchost.exe
    TCPv4  0.0.0.0:49154        0.0.0.0:0     788      svchost.exe
    TCPv4  192.168.139.129:139  0.0.0.0:0     4        System
    TCPv4  0.0.0.0:135          0.0.0.0:0     656      svchost.exe
    TCPv6  :::135               :::0          656      svchost.exe
    TCPv4  0.0.0.0:49152        0.0.0.0:0     384      wininit.exe
    TCPv6  :::49152             :::0          384      wininit.exe
    TCPv4  0.0.0.0:49155        0.0.0.0:0     488      lsass.exe
    TCPv6  :::49155             :::0          488      lsass.exe
    TCPv4  0.0.0.0:49154        0.0.0.0:0     788      svchost.exe
    TCPv6  :::49154             :::0          788      svchost.exe
    UDPv4  0.0.0.0:5355         *:*           928      svchost.exe
    UDPv4  0.0.0.0:0            *:*           928      svchost.exe
    UDPv6  :::0                 *:*           928      svchost.exe
    UDPv4  0.0.0.0:123          *:*           836      svchost.exe
    UDPv6  :::123               *:*           836      svchost.exe
    UDPv4  0.0.0.0:123          *:*           836      svchost.exe
    UDPv4  0.0.0.0:0            *:*           836      svchost.exe
    UDPv6  :::0                 *:*           836      svchost.exe
    UDPv4  0.0.0.0:0            *:*           836      svchost.exe
    UDPv4  192.168.139.129:137  *:*           4        System
    UDPv4  0.0.0.0:5355         *:*           928      svchost.exe
    UDPv6  :::5355              *:*           928      svchost.exe

    표 5는 netscan 플러그인으로 식별되는 Windows Server 2008 R2가 여는 포트 목록이다. 이 목록은 초기 기준점을 설정하며 SMB(Server Message Block)와 NETBIOS를 비롯하여 보안상의 이유로 조직에서 사용하지 않도록 설정할 수 있는 일부 서비스를 포함한다.

    3.4. 연결된 윈도우 서버 2008 R2 부속 도메인에 대한 기준점 테스트

    다른 시스템에 대해 새롭게 수정한 기준점을 사용하여 프로세스를 반복적으로 검증하여 세부 사항을 조정한다. 기준점을 테스트하기 위해 두 번재 Windows Server 2008 R2는 도메인에 연결되어 있고 원격 로그온 사용을 통해 어떤 차이가 있는지 알 수 있는 예외와 함께 첫 번째 구성과 동일한 구성을 사용하여 만들었다. 이 이미지에서 두 명의 사용자는 원격으로 서버에 로그인하고 마이크로소프트 터미널 서버 연결(mstsc)을 사용하며 콘솔을 통해 하나를 사용한다. 메모리 이미지는 원격 사용자에 의해 생성했다.

    3.4.1. 불량 프로세스 식별

    우리의 분석은 불량 프로세스를 식별할 수 있도록 pslist 플러그인을 실행하여 프로세스 목록을 얻는 것에서 시작한다. 다음 사항을 고려한다.

    $ vol.py -f win2008r2-03-s1.img pslist | cut -c 20-53,70-76,84-114
    Volatility Foundation Volatility Framework 2.3.1
    Name                    PID   PPID   Sess Start
    -------------------- ------ ------ ------ ------------------------------
    System                    4      0 ------ 2014-07-28 01:26:59 UTC+0000
    smss.exe                224      4 ------ 2014-07-28 01:26:59 UTC+0000
    csrss.exe               316    308      0 2014-07-28 01:27:04 UTC+0000
    wininit.exe             368    308      0 2014-07-28 01:27:04 UTC+0000
    services.exe            472    368      0 2014-07-28 01:27:05 UTC+0000
    lsass.exe               480    368      0 2014-07-28 01:27:05 UTC+0000
    lsm.exe                 488    368      0 2014-07-28 01:27:05 UTC+0000
    svchost.exe             584    472      0 2014-07-28 01:27:10 UTC+0000
    svchost.exe             660    472      0 2014-07-28 01:27:11 UTC+0000
    svchost.exe             740    472      0 2014-07-28 01:27:11 UTC+0000
    svchost.exe             796    472      0 2014-07-28 01:27:11 UTC+0000
    svchost.exe             848    472      0 2014-07-28 01:27:12 UTC+0000
    svchost.exe             888    472      0 2014-07-28 01:27:12 UTC+0000
    svchost.exe             932    472      0 2014-07-28 01:27:13 UTC+0000
    svchost.exe             236    472      0 2014-07-28 01:27:14 UTC+0000
    spoolsv.exe             324    472      0 2014-07-28 01:27:15 UTC+0000
    svchost.exe            1092    472      0 2014-07-28 01:27:16 UTC+0000
    vmtoolsd.exe           1148    472      0 2014-07-28 01:27:16 UTC+0000
    svchost.exe            1412    472      0 2014-07-28 01:27:18 UTC+0000
    svchost.exe            1472    472      0 2014-07-28 01:27:18 UTC+0000
    TPAutoConnSvc.         1508    472      0 2014-07-28 01:27:19 UTC+0000
    dllhost.exe            1776    472      0 2014-07-28 01:27:22 UTC+0000
    msdtc.exe              1896    472      0 2014-07-28 01:27:23 UTC+0000
    svchost.exe            1204    472      0 2014-07-28 01:29:19 UTC+0000
    sppsvc.exe             1068    472      0 2014-08-02 20:10:58 UTC+0000
    TrustedInstall          252    472      0 2014-08-02 20:11:00 UTC+0000
    csrss.exe              3020   2956      1 2014-08-02 20:16:53 UTC+0000
    winlogon.exe           2896   2956      1 2014-08-02 20:16:53 UTC+0000
    taskhost.exe           1264    472      1 2014-08-02 20:17:25 UTC+0000
    dwm.exe                2328    888      1 2014-08-02 20:17:25 UTC+0000
    explorer.exe           1284   3068      1 2014-08-02 20:17:25 UTC+0000
    vmtoolsd.exe           1556   1284      1 2014-08-02 20:17:25 UTC+0000
    TPAutoConnect.         2712   1508      1 2014-08-02 20:17:25 UTC+0000
    conhost.exe            2856   3020      1 2014-08-02 20:17:25 UTC+0000
    csrss.exe              2232    376      2 2014-08-02 20:18:27 UTC+0000
    winlogon.exe           2124    376      2 2014-08-02 20:18:27 UTC+0000
    taskhost.exe           2116    472      2 2014-08-02 20:18:29 UTC+0000
    rdpclip.exe            2108   1412      2 2014-08-02 20:18:29 UTC+0000
    dwm.exe                2088    888      2 2014-08-02 20:18:29 UTC+0000
    explorer.exe           2708   1388      2 2014-08-02 20:18:29 UTC+0000
    vmtoolsd.exe           1124   2708      2 2014-08-02 20:18:29 UTC+0000
    TPAutoConnect.         2012   1508      2 2014-08-02 20:18:30 UTC+0000
    conhost.exe             672   2232      2 2014-08-02 20:18:30 UTC+0000
    cmd.exe                1268   2708      2 2014-08-02 20:18:40 UTC+0000
    conhost.exe            2904   2232      2 2014-08-02 20:18:40 UTC+0000
    win64dd.exe            2836   1268      2 2014-08-02 20:19:53 UTC+0000

    services.exe에 의해 시작된 두 개의 새 프로세스 sppsvc.exeTrustedInstall이 세션 0에 나타난다. sppsvc.exe는 마이크로소프트의 소프트웨어 보호 서비스며 윈도우와 마이크로소프트 응용 프로그램(Startup Programs Database, 2014a)을 위한 디지털 라이선스를 관리하는 것과 관련있다. TrustedInstaller.exe는 윈도우 모듈 설치 프로그램이며 윈도우 업데이트(Startup Programs Database, 2014b)와 관련있다. 이 프로세스는 시스템 부팅 직후에 만들어 졌으므로 추가 기준점에 표시되지 않았을 수 있다.

    두 개의 사용자 세션 1과 2를 검사할 때 기본 세션과 일관성 있음을 알 수 있다.

    3.4.2. 프로세스 개체 분석(Analyze Process Objects)

    다시 한번 dlllist 플러그인을 실행하여 프로세스 오브젝트 분석을 시작한다.

    $ vol.py -f win2008r2-03-s1.img dlllist | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    smss.exe pid: 224
    Command line : \SystemRoot\System32\smss.exe
    --
    csrss.exe pid: 316
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    wininit.exe pid: 368
    Command line : wininit.exe
    --
    services.exe pid: 472
    Command line : C:\Windows\system32\services.exe
    --
    lsass.exe pid: 480
    Command line : C:\Windows\system32\lsass.exe
    --
    lsm.exe pid: 488
    Command line : C:\Windows\system32\lsm.exe
    --
    svchost.exe pid: 584
    Command line : C:\Windows\system32\svchost.exe -k DcomLaunch
    --
    svchost.exe pid: 660
    Command line : C:\Windows\system32\svchost.exe -k RPCSS
    --
    svchost.exe pid: 740
    Command line : C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
    --
    svchost.exe pid: 796
    Command line : C:\Windows\system32\svchost.exe -k netsvcs
    --
    svchost.exe pid: 848
    Command line : C:\Windows\system32\svchost.exe -k LocalService
    --
    svchost.exe pid: 888
    Command line : C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted
    --
    svchost.exe pid: 932
    Command line : C:\Windows\system32\svchost.exe -k NetworkService
    --
    svchost.exe pid: 236
    Command line : C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork
    --
    spoolsv.exe pid: 324
    Command line : C:\Windows\System32\spoolsv.exe
    --
    svchost.exe pid: 1092
    Command line : C:\Windows\system32\svchost.exe -k regsvc
    --
    vmtoolsd.exe pid: 1148
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
    --
    svchost.exe pid: 1412
    Command line : C:\Windows\System32\svchost.exe -k termsvcs
    --
    svchost.exe pid: 1472
    Command line : C:\Windows\system32\svchost.exe -k
    NetworkServiceNetworkRestricted
    --
    TPAutoConnSvc. pid: 1508
    Command line : "C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe"
    --
    dllhost.exe pid: 1776
    Command line : C:\Windows\system32\dllhost.exe /Processid:{02D4B3F1-FD88-11D1-
    960D-00805FC79235}
    --
    msdtc.exe pid: 1896
    Command line : C:\Windows\System32\msdtc.exe
    --
    svchost.exe pid: 1204
    Command line : C:\Windows\system32\svchost.exe -k
    LocalServiceAndNoImpersonation
    --
    sppsvc.exe pid: 1068
    Command line : C:\Windows\system32\sppsvc.exe
    --
    TrustedInstall pid: 252
    Command line : C:\Windows\servicing\TrustedInstaller.exe
    --
    csrss.exe pid: 3020
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    winlogon.exe pid: 2896
    Command line : winlogon.exe
    --
    taskhost.exe pid: 1264
    Command line : "taskhost.exe"
    --
    dwm.exe pid: 2328
    Command line : "C:\Windows\system32\Dwm.exe"
    --
    explorer.exe pid: 1284
    Command line : C:\Windows\Explorer.EXE
    --
    vmtoolsd.exe pid: 1556
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
    --
    TPAutoConnect. pid: 2712
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
    --
    conhost.exe pid: 2856
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    csrss.exe pid: 2232
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    winlogon.exe pid: 2124
    Command line : winlogon.exe
    --
    taskhost.exe pid: 2116
    Command line : "taskhost.exe"
    --
    rdpclip.exe pid: 2108
    Command line : rdpclip
    --
    dwm.exe pid: 2088
    Command line : "C:\Windows\system32\Dwm.exe"
    --
    explorer.exe pid: 2708
    Command line : C:\Windows\Explorer.EXE
    --
    vmtoolsd.exe pid: 1124
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
    --
    TPAutoConnect. pid: 2012
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
    --
    conhost.exe pid: 672
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    cmd.exe pid: 1268
    Command line : "C:\Windows\system32\cmd.exe"
    --
    conhost.exe pid: 2904
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    win64dd.exe pid: 2836
    Command line : win64dd /f win2008r2-03-s1.img

    메모리 이미지에 두 개의 새로운 서비스, termsbcs와 서비스 그룹 NetworkServiceNetworkRestricted이 나타난다. 원격 데스크톱을 사용하도록 설정하면 이러한 문제가 발생할 수 있다. 다른 프로세스는 모두 기준점에 있고 실행 파일 경로는 정확하다.

    getsids 플러그인을 실행하면 프로세스가 실행중인 계정을 제공한다. termsvcs와 서비스 그룹 NetworkServiceNetworkRestricted은 네트워크 서비스에서 실행 중이다. 다른 모든 프로세스는 예상되는 계정에서 실행된다.

    $ vol.py -f win2008r2-03-s1.img getsids | uniq -w 18
    Volatility Foundation Volatility Framework 2.3.1
    System (4): S-1-5-18 (Local System)
    System (4): S-1-1-0 (Everyone)
    System (4): S-1-5-11 (Authenticated Users)
    System (4): S-1-16-16384 (System Mandatory Level)
    smss.exe (224): S-1-5-18 (Local System)
    csrss.exe (316): S-1-5-18 (Local System)
    wininit.exe (368): S-1-5-18 (Local System)
    services.exe (472): S-1-5-18 (Local System)
    lsass.exe (480): S-1-5-18 (Local System)
    lsm.exe (488): S-1-5-18 (Local System)
    svchost.exe (584): S-1-5-18 (Local System)
    svchost.exe (660): S-1-5-20 (NT Authority)
    svchost.exe (740): S-1-5-19 (NT Authority)
    svchost.exe (796): S-1-5-18 (Local System)
    svchost.exe (848): S-1-5-19 (NT Authority)
    svchost.exe (888): S-1-5-18 (Local System)
    svchost.exe (932): S-1-5-20 (NT Authority)
    svchost.exe (236): S-1-5-19 (NT Authority)
    spoolsv.exe (324): S-1-5-18 (Local System)
    svchost.exe (1092): S-1-5-19 (NT Authority)
    vmtoolsd.exe (1148): S-1-5-18 (Local System)
    svchost.exe (1412): S-1-5-20 (NT Authority)
    svchost.exe (1472): S-1-5-20 (NT Authority)
    TPAutoConnSvc. (1508): S-1-5-18 (Local System)
    dllhost.exe (1776): S-1-5-18 (Local System)
    msdtc.exe (1896): S-1-5-20 (NT Authority)
    svchost.exe (1204): S-1-5-19 (NT Authority)
    sppsvc.exe (1068): S-1-5-20 (NT Authority)
    TrustedInstall (252): S-1-5-18 (Local System)
    csrss.exe (3020): S-1-5-18 (Local System)
    winlogon.exe (2896): S-1-5-18 (Local System)
    taskhost.exe (1264): S-1-5-21-4249217695-1663262354-3778214704-1110
    dwm.exe (2328): S-1-5-21-4249217695-1663262354-3778214704-1110
    explorer.exe (1284): S-1-5-21-4249217695-1663262354-3778214704-1110
    vmtoolsd.exe (1556): S-1-5-21-4249217695-1663262354-3778214704-1110
    TPAutoConnect. (2712): S-1-5-21-4249217695-1663262354-3778214704-1110
    conhost.exe (2856): S-1-5-21-4249217695-1663262354-3778214704-1110
    csrss.exe (2232): S-1-5-18 (Local System)
    winlogon.exe (2124): S-1-5-18 (Local System)
    taskhost.exe (2116): S-1-5-21-4249217695-1663262354-3778214704-1109
    rdpclip.exe (2108): S-1-5-21-4249217695-1663262354-3778214704-1109
    dwm.exe (2088): S-1-5-21-4249217695-1663262354-3778214704-1109
    explorer.exe (2708): S-1-5-21-4249217695-1663262354-3778214704-1109
    vmtoolsd.exe (1124): S-1-5-21-4249217695-1663262354-3778214704-1109
    TPAutoConnect. (2012): S-1-5-21-4249217695-1663262354-3778214704-1109
    conhost.exe (672): S-1-5-21-4249217695-1663262354-3778214704-1109
    cmd.exe (1268): S-1-5-21-4249217695-1663262354-3778214704-1109
    conhost.exe (2904): S-1-5-21-4249217695-1663262354-3778214704-1109
    win64dd.exe (2836): S-1-5-21-4249217695-1663262354-3778214704-1109

    두 번째 이미지에서 DLL을 분석하기 위해 위에서 사용한 동일한 방법으로 1,990개의 인스턴스를 식별한다. 다시 말하자면, 이 숫자는 중복을 분류하고 제거하여 신경써야할 부분을 크게 줄일 수 있다.

    $ vol.py -f win2008r2-03-s1.img dlllist | grep "^0x" | cut -c 20-37,57- | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    1990
    $ vol.py -f win2008r2-03-s1.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    397

    다음으로 DLL 기본 파일과 동일한 형식으로 397개의 DLL을 포함하는 파일을 생성한다. 다시 검사할 때 wc를 사용하여 라인 수를 계산했다.

    $ vol.py -f win2008r2-03-s1.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i > dll-03.lst
    Volatility Foundation Volatility Framework 2.3.1
    $ cat dll-03.lst | wc -l
    397

    DLL 목록에서 기준점에 적용하여 검토할 DLL의 수를 37개로 줄일 수 있다. 이는 1,990개를 검토하는 것 보다 효율적이다.

    $ cat dll-03.lst dll-baseline-01.lst dll-baseline-01.lst | sort | uniq -iu | wc -l
    37

    분석에서, uniq 명령의 여러 속성을 활용하여 비교했다. -i 매개 변수는 대소 문자를 무시하도록 사용했다. -u 매개 변수는 uniq에게 고유한 행만 출력하도록 사용했다. 고유성이 dll-03.lst 파일의 내용에 의한 것인지 확인하기 위해, 기준점 파일은 두번 추가하여 사용했다.

    37개의 DLL을 검토하는 과정은 합리적으로 보인다. win64dd.exe 하나의 항목만 메모리 수집 프로세스에 의해 소개되었으므로 제거한다. 깨끗한 이미지에서 나온 것이므로 두 목록을 병합하여 DLL에 대한 새로운 기준점을 생성할 수 있다.

    $ cat dll-03.lst dll-baseline-01.lst | sort | uniq -i | wc -l
    406
    $ cat dll-03.lst dll-baseline-01.lst | sort | uniq -i > dll-baseline-02.lst
    $ cat dll-baseline-02.lst | wc -l
    406

    도메인 첨부 메모리 이미지에서 모듈의 개수를 확인하는 과정에서 153개의 모듈이 발견되었다. DLL과 동일한 방법을 사용하여 기준점에 없는 모듈 7개로 좁힐 수 있다. 관리할 수 있는 모듈 수를 조사할 수 있다.

    $ vol.py -f win2008r2-03-s1.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    153
    $ vol.py -f win2008r2-03-s1.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i > module-03.lst
    Volatility Foundation Volatility Framework 2.3.1
    $ cat module-03.lst | wc -l
    153
    $ cat module-03.lst module-base-01.lst module-base-01.lst | sort | uniq -iu | wc -l
    7

    기준점에 없었던 모듈은 아래와 같다. Win64dd.sys는 메모리 수집 프로세스의 아티팩트며 아래에 표시된 것 처럼 기준점에 속하지 않는다. 그 외 모듈은 다음과 같다.

    $ cat module-03.lst module-base-01.lst module-base-01.lst | sort | uniq -iu
    RDPDD.dll 0x48000 \SystemRoot\System32\RDPDD.dll
    rdpdr.sys 0x2e000 \SystemRoot\System32\drivers\rdpdr.sys
    RDPWD.SYS 0x39000 \SystemRoot\System32\Drivers\RDPWD.SYS
    spsys.sys 0x71000 \SystemRoot\system32\drivers\spsys.sys
    tdtcp.sys 0xb000 \SystemRoot\system32\drivers\tdtcp.sys
    tssecsrv.sys 0xf000
    \SystemRoot\System32\DRIVERS\tssecsrv.sys win64dd.sys 0x11000 \??\C:\temp\windd\win64dd.sys

    3.4.3. 네트워크 아티팩트 검토

    네트워크 아티팩트 분석은 netscan 플러그인을 사용하여 진행한다.

    $ vol.py -f win2008r2-03-s1.img netscan | cut -c 12-18,21-40,50-63,86-112 | sort | uniq -w 20
    Volatility Foundation Volatility Framework 2.3.1
    Proto  Local Address         Foreign Addr       Pid       Owner
    TCPv4  0.0.0.0:135           0.0.0.0:0          660       svchost.exe
    TCPv4  0.0.0.0:3389          0.0.0.0:0          1412      svchost.exe
    TCPv4  0.0.0.0:445           0.0.0.0:0          4         System
    TCPv4  0.0.0.0:47001         0.0.0.0:0          4         System
    TCPv4  0.0.0.0:49152         0.0.0.0:0          368       wininit.exe
    TCPv4  0.0.0.0:49153         0.0.0.0:0          740       svchost.exe
    TCPv4  0.0.0.0:49154         0.0.0.0:0          796       svchost.exe
    TCPv4  0.0.0.0:49173         0.0.0.0:0          472       services.exe
    TCPv4  0.0.0.0:49174         0.0.0.0:0          1472      svchost.exe
    TCPv4  0.0.0.0:49178         0.0.0.0:0          480       lsass.exe
    TCPv4  -:0                   24.217.239.1       480       lsass.exe
    TCPv4  192.168.139.102:139   0.0.0.0:0          4         System
    TCPv6  -:0                   18d9:ef0d:80:ffff:0 CLOSED                  48
    TCPv6  :::135                :::0               660       svchost.exe
    TCPv6  :::3389               :::0               1412      svchost.exe
    TCPv6  :::445                :::0               4         System
    TCPv6  :::47001              :::0               4         System
    TCPv6  :::49152              :::0               368       wininit.exe
    TCPv6  :::49153              :::0               740       svchost.exe
    TCPv6  :::49154              :::0               796       svchost.exe
    TCPv6  :::49173              :::0               472       services.exe
    TCPv6  :::49174              :::0               1472      svchost.exe
    TCPv6  :::49178              :::0               480       lsass.exe
    UDPv4  0.0.0.0:0             *:*                1472      svchost.exe
    UDPv4  0.0.0.0:123           *:*                848       svchost.exe
    UDPv4  0.0.0.0:4500          *:*                796       svchost.exe
    UDPv4  0.0.0.0:500           *:*                796       svchost.exe
    UDPv4  0.0.0.0:5355          *:*                932       svchost.exe
    UDPv4  127.0.0.1:57762       *:*                480       lsass.exe
    UDPv4  127.0.0.1:65282       *:*                796       svchost.exe
    UDPv4  192.168.139.102:137   *:*                4         System
    UDPv6  :::0                  *:*                1472      svchost.exe
    UDPv6  :::123                *:*                848       svchost.exe
    UDPv6  :::4500               *:*                796       svchost.exe
    UDPv6  :::500                *:*                796       svchost.exe
    UDPv6  :::5355               *:*                932       svchost.exe

    netscan의 결과를 기준으로 기준점과 비교해 보면 세 가지로 구분할 수 있다. 

    • 포트는 일반 포트, 
    • 서버가 도메인에 연결되어 있지 않을 때 사용되는 포트 그리고 
    • 서버가 도메인에 연결될 때 사용되는 포트로 나눌 수 있다. 

    이러한 내용은 표 6에 요약되어 있다. 이 목록의 유효성을 검사하기 위해 IIS 서버, 도메인 컨트롤러 그리고 SQL 서버를 포함한 추가 구성을 사용하는 추가 작업이 필요하다.

    기준점에서 네트워크 포트를 사용할 때 주의할 점이 있다. 동적 포트 범위의 포트를 찾을 때 다른 프로세스가 이미 포트를 사용하고 있는 경우, 다른 서버 구성에 따라 동적 포트가 할당될 수 있다.

    4. 결론

    이 문서는 메모리 분석을 위한 기준점을 구축하는 방법을 설명했다. 이 방법은 시작일 뿐이다. 추가로 다른 Windows Server 2008 R2 구성을 사용하여 유효성을 검사하고 빌드하려면 더 많은 작업을 수행해야 한다. 유사한 방법을 사용하여 Windows 7, Windows 8 그리고 Windows Server 2012을 위한 기준점을 구축할 수 있다.

    기준점의 가치는 빌딩과 테스트하는 과정에서 입증되었다. 예상되는 프로세스를 문서화하여 기준점에 없지만 있어야 했던 프로세스를 신속하게 식별할 수 있었다. 예기치 않은 시스템을 식별하기 위해 손상된 시스템의 메모리 이미지에 기준점을 쉽게 사용할 수 있다. 이를 통해 찾은 프로세스와 DLL 목록으로 의심스러운 프로세스에 신속하게 집중할 수 있다. 기준점의 사용 가치는 검사할 DLL을 1,990개에서 37개로 줄이고 검사할 모듈을 153개에서 7개의 줄여 훨씬 더 효율적임을 증명한 것에 있다.

    일반적으로 기준점은 여러 소스의 메모리 이미지를 일반적으로 분석하는 것에 유용할 수 있다. 조직의 경우 표준 구성으로 맞춘 기준점을 사용하면 분석에 많은 시간을 절약할 수 있다. VMware Workstation에서 서버를 구현함으로써 생성된 아티팩트가 기준점에 영향을 주는 것을 확인했다. 이러한 확인을 확장하여 안티 바이러스 소프트웨어와 같은 조직의 표준 구성에 대해 다른 아티팩트를 생각해야 한다. 따라서 이러한 형태의 아티팩트를 기준점에 설정하면 분석에 상당한 시간을 절약할 수 있다.

    5. 참고 자료


    'Information Security > Incident Response' 카테고리의 다른 글

    Baseline Memory Analysis(번역)  (0) 2017.05.10

    + Recent posts