보안 침해사고 분석
사이버 보안 침해사고가 발생하면 기업은 내부적으로 침해사고분석을 통해 공격자의 흔적을 찾아내고, 공격 당시 사건을 재구성하여 시스템에 발생한 피해를 파악 합니다.
시스템에 침해가 발생하기 까지는 많은 일들이 발생 합니다. 공격자가 시스템을 공격하고 장악하기 위해 정보 수집 과정을 거치게 됩니다. 이 과정에서 공격자는 대상 시스템의 서비스 종류, 시스템 현황, OS종류, IP대역, 포트정보, 취약점 정보 등 많은 정보를 수집하게 됩니다.
외부의 공격자가 정보 수집을 통해 충분히 공략할 대상 시스템의 약점을 파악했으면 취약점을 이용해 공격에 들어가게 됩니다. 보통 이 과정에서 많은 수의 공격이 탐지되고 차단이 됩니다. 공격자는 가능한 모든 방법을 동원해 탐지되지 않기 위해 우회 시도를 하고, 100번의 공격 중 1번의 공격이 성공하게 되면 공격 성공 단계에 이르게 됩니다. 바로 이 단계가 침해가 발생되는 시점 입니다.
시스템 장악에 성공하면 공격자는 자신의 목적에 따라 시스템에 악성코드를 설치하거나 시스템의 정보를 유출하는 행위가 이뤄지고, 많은 경우 침해사고 발생에 대한 인지는 정보 유출 또는 시스템 변조가 발생되고 이뤄지게 됩니다.
보안팀은 공격을 탐지하고 예방하기 위해 다양한 방법을 이용해 침입시도에 대해 모니터 합니다. 주로 네트워크에서 발생되는 정보를 활용하게 됩니다. 가장 많이 사용되는 정보는 침입탐지시스템에서 제공하는 정보 입니다. 시스템에 가해지는 공격시도나 공격행위에 대해 네트워크 레벨에서 사전에 분석해 파악하고, 차단하면 시스템 침해를 예방할 수 있습니다.
최근 보안 사고가 연속적으로 발생하고 이로 인한 개인정보유출과 랜섬웨어로 인한 피해가 발생 하였습니다. 공격자가 공격 대상의 약점을 악용해서 큰 피해로 이어지게 만들었던 사례입니다.
개인정보 유출 사례의 경우 공격자는 제로데이 공격이 아닌 이미 알려진 악성코드를 사용했던 것으로 확인되었고, 공격자가 취약한 시스템을 알려진 악성코드를 이용해 공격이 성공하였습니다.
보안 사고 사례: BPFDoor 유즈케이스
개인정보 유출 시 사용된 공격 프로그램은 BPFDoor라 불리는 리눅스 운영체제 기반의 백도어 프로그램 입니다. 해당 공격에 사용된 악성코드는 Elastic 보안 연구소에서 2022년 보안 블로그를 통해 동작 방식 및 예방 방법에 대해 공유 하였습니다.
Elastic Security Blog: A peek behind the BPFDoor, 13 July 2022 블로그 등록
작성자: Jake King, Colson Wilhoit
- 위협 그룹: Red Menshen (중국계 APT)
- 도구명: BPFDoor – 리눅스 대상 백도어
- 주요 기능: BPF 기반 정찰 및 암호화된 명령 수신
- 분석 주제: ‘BPFDoor Scanner’ 도구는 감염 의심 호스트의 활성화를 감지하도록 설계됨
BPFDoor 는 Linux용으로 특별히 제작된 백도어 입니다. 이 백도어의 목적은 공격 대상 환경에 반복적으로 재진입하기 위해 장기간 시스템에 숨겨진 백도어 역할을 수행 합니다. 특히 BPF를 비롯한 여러 기술을 활용하여 최대한 은밀하게 작동하도록 설계 되어 있습니다.
패시브 형태로 백도어가 동작하기 때문에 평상시 가동 시간이 높은 서버나 기기, IoT/SCADA, 또는 인터넷에 접속 가능한 클라우드 시스템에 설치되도록 설계되었습니다. 특히 서비스 특성 상 메인터넌스나 재부팅이 어려운 시스템에 지속적으로 상주하여 공격자의 백도어 역할을 수행 합니다. 공격 프로그램에서 사용하는 파일은 임시 폴더에 저장되므로 서버가 재부팅 되거나 종료될 경우 백도어가 손실됩니다.
이 악성코드가 시스템에서 발견될 경우, 초기 접근(1단계) 또는 사후 공격(2단계) 페이로드가 여전히 존재하고 환경의 다른 곳에서 활성화되어 있을 가능성이 높다고 가정해야 합니다. 이 백도어는 은밀하게 침투하여 탐지되지 않을 모든 기회를 포착합니다. 샘플 코드를 통해 확인된 BPFDoor의 동작 과정 입니다.
예외 샘플 분석
주목할 점은 1~4단계가 나타나지 않는 샘플이 하나 있다는 것입니다 . 이 샘플은 초기 이름을 하드코딩된 값으로 변경하지 않고, 배치된 위치에서 실행하며, 그 외에는 동일한 동작을 모델링합니다.
- 실행 시 바이너리는 자신을 /dev/shm/에 복사합니다. 임시 파일 시스템인 /dev/shm은 공유 메모리를 의미하며, 프로세스 간 효율적인 통신 수단으로 사용되는 임시 파일 저장 공간입니다.
- 프로세스 이름을 하드코딩된 프로세스 이름인 kdmtmpflush로 변경합니다.
- -init 플래그로 자신을 초기화하고 자신을 fork합니다. Linux에서 fork는 호출 프로세스를 복제하여 새 프로세스를 생성하는 것을 의미합니다.
- 호출된 원본 바이너리를 제거하여 자신을 삭제합니다. 포크된 프로세스는 계속 실행됩니다.
- 포크된 프로세스의 생성 및 수정 시간 값을 변경합니다. 이를 타임스톰핑 이라고도 합니다.
- 자신을 위한 새로운 프로세스 환경을 생성하고 기존 프로세스를 제거하며, 새 프로세스 이름을 설정(스푸핑)합니다. 마치 마스크를 쓴 것처럼 시스템에 나타나는 방식을 변경합니다. 프로세스는 여전히 kdmtmpflush이지만, ps를 실행하면 설정된 값을 볼 수 있습니다.
- /var/run에 프로세스 ID(PID) 파일을 생성합니다. PID 파일은 연관된 프로그램의 프로세스 정보를 담고 있는 텍스트 파일로, 다중 시작을 방지하고, 상주 상태를 표시하며, 프로그램이 스스로를 중지하는 데 사용됩니다. 이 파일은 또 다른 임시 파일 저장 공간인 /var/run에 있습니다.
- 원시 네트워크 소켓을 생성합니다. Linux에서 소켓은 네트워크 통신의 엔드포인트로, 패킷의 모든 섹션을 세부적으로 지정할 수 있도록 하여 사용자가 인터넷(IP) 수준에서 자체 전송 계층 프로토콜을 구현할 수 있도록 합니다.
- 원시 소켓에 BPF 필터를 설정합니다. BPF를 사용하면 사용자 공간 프로그램이 모든 소켓에 필터를 연결하여 특정 유형의 데이터가 소켓을 통해 들어오도록 허용하거나 거부할 수 있습니다.
- 들어오는 패킷을 관찰합니다
- BPF 필터와 일치하고 필요한 데이터를 포함하는 패킷이 관찰되면 처리를 위해 백도어로 전달됩니다.
- 현재 프로세스를 다시 포크합니다.
- 포크된 프로세스의 작업 디렉토리를 /로 변경합니다.
- 포크된 프로세스의 이름을 하드코딩된 값으로 변경(스푸핑)합니다.
- “매직 패킷”에 전송된 비밀번호 또는 비밀번호의 존재 여부에 따라 백도어는 역방향 셸을 제공하거나 바인드 셸을 설정하거나 ping을 다시 보냅니다.
아래에서 Elastic의 Analyzer View를 활용하여 BPFDoor 프로세스 트리를 시각적으로 확인할 수 있습니다. 첫 번째 이미지는 백도어(즉, 리버스 셸, 바인드 셸 또는 핑백)가 실제로 사용되기 전의 트리를 보여주고, 두 번째 이미지는 리버스 셸이 연결되고 익스플로잇 후 활동을 수행한 후의 트리를 보여줍니다.

그림 BPFDoor 초기 호출 프로세스 트리의 Elastic Analyzer 뷰

그림 Reverse Shell연결 및 공격 성공 후 BPFDoor의 Elastic Analyzer 뷰
<동작 방식 요약>
- BPFDoor는 단순 트래픽보다 은밀한 스텔스 정찰 기법을 사용합니다:
- BPF 필터 활용: Berkeley Packet Filter를 통해 커널 레벨에서 ‘매직 패킷’을 감지
- 원격 스캔 방식: TCP, UDP, ICMP 혼합 방식으로 포트 연결 시도 (예: 68/UDP → 53/UDP)
- 포트리스닝 없는 역접속 방식: 백도어는 포트를 열지 않고 “매직 패킷” 수신 시명령 실행
- 은폐 기법: 프로세스 이름 위장, 표준 스트림 닫기, 루트 권한으로 메모리 상 실행
Elastic Security Team은 BPFDoor 맬웨어를 분석하는 데 도움이 되는 몇 가지 도구를 만들었습니다. BPFDoor 스캐너를 사용하면 BPFDoor 맬웨어에 감염된 호스트를 스캔할 수 있으며, BPFDoor 구성 추출기를 사용하면 맬웨어의 구성이나 하드코딩된 값을 추론하여 추가 분석, 추가 시그니처 개발 또는 클라이언트를 활용한 백도어 연결에 사용할 수 있는 추가 관찰 결과를 얻을 수 있습니다.
Elastic Defend (EDR): BPFDoor 악성코드 예방
BPFDoor 백도어가 왜 그렇게 오랫동안 사용되면서 숨겨진 채로 남아 있었는지를 알기 위해 동작 방식을 설명 했습니다. Linux 운영체제의 이상 프로세스 대해 잘 모르거나 자세히 살펴보지 않았다면 쉽게 탐지되지 않을 것입니다. 탐지를 피하기 위해 은밀하게 동작하지만, 행위 기반 탐지 방식과 시그니처 기반 탐지 방식을 통해 충분히 탐지와 차단이 가능 합니다.
Elastic Endpoint 제품인 Elastic Defend에서 대응 과정을 살펴 보겠습니다.
악성코드 초기 실행 시 관찰된 동작에 주목 합니다. 특히 이상행위는 공유 메모리 위치인 /dev/shm 디렉터리에서 발견 되었습니다. 이 디렉터리는 Linux의 기본 임시 파일 시스템 위치로, RAM을 저장 공간으로 사용하며, 이 디렉터리에서 바이너리가 실행되거나 네트워크 연결을 생성하는 것은 실제로 매우 드뭅니다.
Elastic 탐지 Rule #1 Binary Executed from Shared Memory Directory BPFDoor는 실행 중에 /dev/shm에서 기존 파일을 제거하고 자신을 복사합니다. 디렉터리에 루트 권한으로 바이너리를 실행하는 경우 이를 감지할 수 있습니다 (이 디렉터리에 쓰고 읽으려면 루트 권한이 있어야 합니다). 테스트를 통해 Elastic Defend를 통해 Exploit이 실행되는 과정이 보안 경보를 통해 탐지 되었습니다. 탐지 Rule은 Elastic SIEM Rule 중 ” 공유 메모리 디렉터리에서 실행된 바이너리(Binary Executed from Shared Memory Directory)” 로 공개되어 있습니다 .
Elastic 탐지 Rule #2 Abnormal Process ID or Lock File Created
두 번째로 /var/run에 특정 PID 파일이 생성을 통해 악성코드 탐지 및 예방 입니다. Osquery 통합 기능을 통해 /var/run 디렉터리에 드랍된 PID 파일이 완전히 비어있는 것을 발견했습니다. 드랍 파일 자체가 악의적인 것은 아니지만, PID 파일 크기가 0이거나 10바이트 정도인 경우는 드물기 때문에 이러한 비정상적인 동작을 탐지하기 위한 추가 탐지 Rule을 만들었습니다.
“비정상 프로세스 ID 또는 잠금 파일 생성(Abnormal Process ID or Lock File Created)” 탐지 Rule은 일반적인 PID 파일을 무시하고 하위 디렉터리 없이 /var/run의 기본 디렉터리에 PID 파일을 생성하는 것을 식별합니다.
Elastic Defend (EDR): Triage(사고대응) 가이드
악의적인 행위에 대한 침입 탐지 및 차단 외에도 보안 대응 과정에도 다양한 EDR 정보가 필요 합니다. 특히 침해사고 발생으로 인한 사고 조사 과정에서 시스템 로그는 중요한 단서가 됩니다. Elastic에서 제공하는 사고대응 메뉴에 대해 살펴 보겠습니다.
Elastic Explore 메뉴 활용해 모든 이벤트 발생 내역 분석 및 조사를 수행할 수 있습니다.
<Elastic 사고 분석 관련 Triage 기능 소개>
- 메뉴: Security > Explore > Host / Network / Users
- 기능: Elastic Defend에서 제공하는 엔드포인트 로그 분석 활용
Explore 메뉴를 통해 보안 사고 조사를 진행 합니다. 특정 호스트에서 발생한 모든 행위 분석을 진행 합니다. EDR (Elastic Defend) 를 통해 수집 하는 이벤트 종류는 다음과 같습니다.
- API (윈도우 계열 운영체제)
- DLL and Driver Load (윈도우 계열 운영체제)
- DNS (윈도우 계열 운영체제)
- File
- Network
- Process
- Registry (윈도우 계열 운영체제)
- Security (윈도우 계열 운영체제)



Elastic Defend (EDR): Triage(사고대응) 유즈케이스
악성코드 감염 또는 의심 호스트에 대한 상세 분석 과정을 Explore 메뉴를 통해 분석 합니다. 각 과정을 스크린 캡처와 분석 화면을 통해 설명 합니다.
1) 의심 대상 호스트에 대한 EDR 이벤트 분석을 위해 특정 호스트에 대한 필터를 적용 합니다. 예) “gs-demo”

2) 감염 의심 정보 분석을 위해 해당 호스트의 프로세스 정보를 분석 합니다. 분석을 위해 수집된 이벤트 종류 중 process 관련 로그를 제외한 다른 정보를 Filter를 적용 합니다.

의심 행위가 발생한 시간 대역을 적용해 해당 시간의 연관된 프로세스 로그를 분석 합니다

필터 적용 이 완료되면 프로세스 이벤트를 시간순으로 확인해 연관 프로세스 정보를 분석 합니다.

특정 파일 이벤트가 발생한 시간 동안에 네트워크 패킷 로그를 동시에 확인하기 위해 2개 메시지 타입의 로그를 분석 합니다.

Elastic Defend에서 수집하는 로그 필드 정보를 ECS 필드 정보를 참고할 수 있습니다.
https://www.elastic.co/guide/en/integrations/current/endpoint.html