보안 제품 이름까지 흉내 낸 BPFDoor 변종 — 이름이 아니라 동작으로 리눅스 서버를 점검해야 하는 이유

리눅스 서버의 프로세스 목록에 익숙한 보안 제품 이름이 보인다면, 그대로 믿어도 될까요? 보안 기업 Rapid7은 2026년 9월 말 공개한 분석에서 한국·대만의 통신사와 네트워크 장비를 노린 리눅스 백도어가 현지에서 널리 쓰이는 이메일 보안 제품의 이름과 실행 흔적까지 흉내 냈다고 밝혔습니다. 국내 표적에서는 새로운 BPFDoor 변종이 확인됐습니다. 이름만으로 정상 프로세스를 판단하던 점검 방식을 다시 살펴볼 때입니다.

핵심 요약

Rapid7에 따르면 한국 표적에서 발견된 BPFDoor 변종은 국내 스팸 차단 제품의 PID 파일을 흉내 내고, 리눅스 데몬 이름 10개를 번갈아 쓰며 정상 프로세스처럼 위장했습니다. 백도어를 깨우는 신호(매직 패킷)는 일반 HTTPS POST 요청 안에 숨겨 기존 심층 패킷 검사를 피할 수 있게 했고, 활성화되면 원격 셸과 파일 업로드·다운로드를 지원합니다. 대만 장비에서는 메일 전송 프로토콜(SMTP, TCP 25번 포트)을 명령·제어 통로로 쓰는 새 임플란트 AVERAT도 발견됐습니다. 프로세스 이름이 아니라 실제 동작(패킷 필터·원시 소켓·통신 대상)을 기준으로 서버를 점검하고, 서버·장비 관리 접근을 좁히는 것이 핵심 대응입니다.

무슨 일이 있었나

Rapid7은 2026년 9월 29일(현지 시각) 블로그 글 "SMTP is the key: BPFDoor and AVERAT hitting the network edge"에서 통신 환경의 소프트웨어·장비 관행에 맞춰 위장한 리눅스 악성코드 묶음을 공개했습니다. 여기에는 새로 관측된 BPFDoor 변종, 한국 표적에서 쓰인 BPF 기반 Rekoobe 빌드, 그리고 대만 장비에 배포된 AVERAT 임플란트와 설치용 드로퍼가 포함됩니다. The Hacker News는 10월 6일 이 분석을 보도하며, BPFDoor가 그간 Red Menshen(Earth Bluecrow 등으로도 불림)이라는 위협 그룹과 연관 지어 분석돼 왔다고 전했습니다.

위장 방식은 구체적입니다. Rapid7은 한국 시스템을 노린 BPFDoor 변종이 국내 스팸 차단 제품인 스팸스나이퍼(SpamSniper)의 PID 파일을 흉내 내고, 리눅스 데몬 이름 10개를 돌려 가며 사용했다고 설명했습니다. 이는 해당 제품의 취약점이 아니라 이름과 실행 흔적을 빌린 위장입니다. 다른 샘플은 오라클 데이터베이스의 백그라운드 프로세스 이름 규칙을 흉내 낸 'ora_ppmond'라는 이름을 썼습니다. Rekoobe 기반 백도어도 25번 포트의 트래픽을 가로채며 프로세스 이름을 같은 제품 구성요소처럼 지었습니다.

탐지 회피 방식도 진화했습니다. 보안 업체들이 이상 패킷을 잡는 네트워크 시그니처를 만들자, 공격자는 매직 패킷을 평범한 HTTPS POST 요청에 감싸고 통신 환경에서 흔한 SSL 오프로딩을 이용해 감염 서버까지 전달하는 방식으로 바꿨다는 것이 Rapid7의 분석입니다.

왜 지금 주목해야 하나

BPFDoor는 평소에는 포트를 열지 않고 들어오는 트래픽을 조용히 엿보다가 특정 신호를 받을 때만 동작하는 백도어입니다. 그래서 일반적인 포트 스캔이나 방화벽 점검만으로는 잘 드러나지 않습니다. 이번 분석은 여기에 '현지 맞춤형 위장'이 더해졌다는 점에서 의미가 큽니다. 표적 시스템에서 실제로 쓰는 보안 제품이나 데이터베이스 이름을 그대로 빌리면, 관리자가 프로세스 목록을 훑어볼 때 오히려 정상 구성요소로 보이기 쉽습니다.

또한 Rapid7은 공격자가 공개된 탐지 기법에 맞춰 도구를 계속 고치고 있다고 봤습니다. 한 번 만든 시그니처나 점검 스크립트에 의존하는 방식만으로는 다음 변종을 놓칠 수 있다는 뜻입니다. 국내 통신·네트워크 환경이 직접 거론된 만큼, 리눅스 서버와 경계 장비를 운영하는 조직이라면 이번 사례를 남의 일로 보기 어렵습니다.

기업·보안 담당자에게 미치는 영향

가장 큰 영향은 '이름으로 판단하는 점검'의 한계입니다. 프로세스 이름, PID 파일 위치, 설치 경로가 정상 소프트웨어와 같아 보여도 실제로는 패킷 필터를 붙이거나 외부와 메일 포트로 통신하는 악성 프로세스일 수 있습니다. 특히 이메일 보안 게이트웨이처럼 네트워크 경계에서 많은 트래픽을 보는 장비는 공격자에게 정보 수집에 유리한 위치라는 점도 이번 분석에서 다시 확인됐습니다.

백도어가 활성화되면 공격자는 원격 셸로 서버에 들어와 파일을 올리거나 내려받을 수 있습니다. 결국 침투 이후 공격자가 서버 안에서 무엇을 실행하고 어디로 이동하는지를 통제하고 기록할 수 있는지가 피해 규모를 가르게 됩니다. 서버·장비의 관리 접근 경로가 넓게 열려 있거나 접속·명령 기록이 남지 않는 환경이라면, 침해 사실을 알아채기도, 영향 범위를 설명하기도 어렵습니다.

리눅스 서버·경계 장비, 지금 점검할 것

• 패킷 캡처가 필요 없는 서버의 BPF 필터·원시 소켓 확인: 패킷 캡처 용도가 아닌 리눅스 서버에 예상하지 못한 원시 패킷 소켓이나 BPF 필터가 붙어 있는지 점검합니다(Rapid7 권고).
• 메일 서비스가 아닌 프로세스의 25번 포트 외부 통신 감사: 메일 서버가 아닌 프로세스가 외부 TCP 25번 포트로 연결하는 경우가 있는지 확인합니다(Rapid7 권고).
• 정상 데몬·보안 제품으로 위장한 프로세스 점검: 이름만 보지 말고 실행 파일 경로, 해시, 부모 프로세스, 패키지 설치 이력과 대조해 실제로 설치된 정상 구성요소인지 확인합니다.
• 경계 장비 관리 접근 제한: 라우터·보안 게이트웨이 등 경계 장비와 서버의 관리 접근을 허용된 경로와 인원으로 좁힙니다(Rapid7 권고).
• 서버 접속·명령 기록 보존: 누가 어떤 경로로 서버에 접속해 무엇을 실행했는지 기록을 남겨, 이상 징후가 보였을 때 영향 범위를 추적할 근거를 확보합니다.
• 최신 침해지표 반영: 공개된 분석의 침해지표와 탐지 정보를 보안 운영 도구에 반영하고, 과거에 만든 점검 스크립트가 새 변종을 놓치지 않는지 다시 확인합니다.

BPFDoor의 기본 동작 원리와 위험성은 이전에 정리한 BPFDoor, 왜 위험하고 어떻게 막을 수 있나?와 BPFDoor 대응 리포트 FAQ 모음집에서도 확인할 수 있습니다.

PNPSECURE의 대응 방향 — 무료 서버 위험 탐지 툴로 직접 점검

이번 사례의 핵심은 '이름이 아니라 동작으로 봐야 한다'는 것입니다. 다만 위에서 정리한 BPF 필터·원시 소켓, 25번 포트 외부 통신, 위장 프로세스 같은 항목을 서버마다 손으로 확인하기는 번거롭습니다. PNPSECURE는 이런 점검을 자동화한 Server Threat Detector를 누구나 쓸 수 있도록 무료로 제공합니다. 관리자 권한만 있으면 서버에서 바로 실행되며, BPFDoor와 그 변종뿐 아니라 공격자가 은밀하게 손대는 시스템·네트워크 설정 조작까지 함께 점검합니다.

점검 항목에는 RAW Socket·네트워크 인터페이스 필터, SSH 터널 구성과 SSHD 설정 이상, iptables 포워딩·NAT 룰 조작, auditd·firewalld 상태, 로컬 포트 사용 현황과 비인가 통신 포트 탐지가 포함됩니다. 이는 이 글에서 짚은 점검 포인트와 그대로 맞닿아 있어, 변종의 이름이 바뀌더라도 실제 동작을 기준으로 위험 징후를 확인할 수 있습니다.

운영 중인 리눅스 서버가 BPFDoor 변종에 노출돼 있는지 지금 직접 확인하고 싶다면, PNPSECURE Server Threat Detector를 무료로 내려받아 서버 상태를 점검해 보세요. 별도의 상담 절차 없이도 현재 보안 상태를 스스로 파악하고, 필요한 보안 조치를 계획하는 출발점으로 삼을 수 있습니다.