[관점]
침해사고 조사 보고서에서 반복되는 문장이 있다. 「공격자는 별도 악성코드를 설치하지 않고 시스템에 기본 포함된 유틸리티를 사용하였다.」 이 문장을 여러 번 읽고 나면 대응 방향이 하나로 모인다. 무엇이 실행되었는지가 아니라 무엇이 무엇을 실행했는지를 봐야 한다는 것이다.
그런데 국내 SOC 룰의 상당수는 여전히 바이너리 이름과 인자 패턴에 걸려 있다. 알려진 목록에 의존하는 구조이고, 목록이 커지는 속도가 룰을 갱신하는 속도보다 빨라지면 커버리지는 가만히 있어도 떨어진다.
이 리서치가 던지는 실질적 질문은 「새 LOLBin 이 몇 개 더 나올 것인가」가 아니다. 「우리 탐지가 목록에 의존하고 있는가, 관계에 의존하고 있는가」다.
공격자가 시스템에 기본 포함된 정상 바이너리를 악용하는 기법은 새롭지 않다. LOLBin(Living off the Land Binary)이라는 이름도, GTFOBins 같은 공개 목록도 오래되었다. Pentera Labs 의 이 리서치가 다루는 것은 기법이 아니라 발굴 속도다.
문제의 출발점
기존의 신규 LOLBin 발굴은 숙련된 연구자가 바이너리를 직접 분석해 하나씩 찾아내는 작업이었다. radare2 같은 도구로 실행 관련 함수를 찾고, 호출 관계를 거슬러 올라가고, 인자가 어디에서 오는지 추적한다. 정확하지만 느리고, 사람 수에 비례한다.
리서치는 이 수작업의 각 단계를 자동화한다. 실행 계열 함수(execvp, popen, system 등)를 바이너리에서 자동 검출하고, AI 로 후보를 분류·우선순위화한 뒤, 실행 지점에서 메인 함수까지 역호출 그래프를 구성한다. 마지막으로 인자의 출처를 명령행 인수까지 되짚어 실제로 명령이 실행되는 경로인지 확인한다.
규모의 전환
핵심은 이 파이프라인을 개별 바이너리가 아니라 디렉터리 전체에 돌렸다는 점이다. Ubuntu 22.04 의 /usr/bin 약 1,000개 바이너리가 대상이었고, 결과로 /usr/bin/chrt 와 /usr/bin/i386 의 실행 경로가 제시된다.
발견 개수 자체는 리서치에 명시되어 있지 않다. 그러나 방어자에게 의미 있는 것은 개수가 아니라 단가다. 한 사람이 며칠 걸리던 분석이 배치 작업이 되면, 아직 목록에 없는 후보가 훨씬 빠르게 증가한다. 리서치가 마지막 절에서 강조하는 것도 이 지점이다 — 기존 기술을 AI 로 증폭하는 방법론 자체가 일반적 가치를 갖는다는 것.
리서치에는 방어 측 권고가 명시적으로 제시되지 않는다. 아래는 이 결과를 SOC 운영에 옮길 때의 판단이다.
국내 적용 관점
탐지의 축을 목록에서 관계로 옮겨야 한다. 알려진 바이너리 이름과 인자 패턴에 기반한 룰은 목록에 있는 것만 검출한다. 목록 밖 후보가 증가하는 만큼 커버리지는 자동으로 낮아진다. 룰을 잘못 만들어서가 아니라 전제가 바뀌었기 때문이다. 대안은 세 가지다. 어떤 바이너리가 실행되었는지보다 어떤 프로세스가 그것을 실행했는지를 보는 관계 기반 탐지, 실행 시각·계정 유형·호스트 역할을 조합하는 맥락 기반 탐지, 그리고 탐지를 늘리는 대신 실행 가능 범위 자체를 줄이는 허용 목록 축소다. 세 가지를 동시에 시작하지 않는 편이 낫다. 허용 목록 축소가 가장 확실하고 오탐이 없으므로 먼저 하고, 관계 기반 룰은 그다음이다. 맥락 기반 탐지는 앞의 둘이 자리를 잡은 뒤에 얹는다.
국내 업무 환경에서 관계 기반 룰은 오탐이 많다. 결재·인증·보안 목적의 클라이언트 프로그램이 다수 상주하고, 이들이 정상적으로 자식 프로세스를 생성한다. 룰을 전사에 그대로 켜면 경보가 감당할 수 없이 증가한다. 현실적인 순서는 자산군을 좁혀 시작하는 것이다. 서버군, 특히 외부 노출 서비스가 있는 구간부터 적용하면 정상 패턴의 다양성이 훨씬 적어 오탐 관리가 가능하다. 여기서 확보한 기준선을 사무용 단말로 확장하는 편이, 전사 일괄 적용 후 룰을 끄는 것보다 결과가 낫다. 기준선 확보에는 최소 2~4주가 필요하다. 그 기간의 정상 패턴을 수집하지 않고 룰을 켜면 첫 주에 경보가 폭증하고, 대개 룰 자체가 꺼진 채 잊힌다. 한 번 꺼진 룰은 다시 켜지지 않는다.
리눅스 구간의 탐지 공백이 이 리서치로 드러난다. 분석 대상이 Ubuntu 의 /usr/bin 이었다는 점을 짚어 둘 만하다. 국내 조직의 EDR 배포는 대체로 윈도우 단말과 서버에 집중되어 있고, 리눅스 서버는 도입 범위에서 빠지거나 최소 구성으로만 들어가는 경우가 많다. 그런데 외부 노출 서비스와 컨테이너 워크로드는 대부분 리눅스 위에 있다. 목록 밖 LOLBin 이 증가하는 상황에서 이 구간이 비어 있으면, 탐지 룰의 정교함과 무관하게 그 서버는 관측되지 않는다. 확인은 에이전트 배포 여부가 아니라 프로세스 생성 이벤트가 실제로 수집되는지로 해야 한다. 에이전트가 설치되어 있어도 해당 이벤트가 성능을 이유로 수집 대상에서 빠져 있는 경우가 있다. 이 상태는 대시보드상 정상으로 보인다.
자사 EDR 이 실제로 무엇을 막는지부터 확인해야 한다. 어떤 원격 실행·측면 이동 기법이 차단되고 어떤 것이 통과하는지를 검증해 두면 룰 개발의 우선순위가 정해진다. 차단되는 기법에 탐지 룰을 겹쳐 쓰는 것보다, 통과하는 기법에 자원을 쓰는 편이 효율적이다. 이 확인은 룰을 쓰기 전에 해야 순서가 맞는다.
점검 항목
질문 1 LOLBin 탐지 룰이 바이너리 이름 목록에 의존하는가?
그 목록은 무엇을 근거로 갱신되는가?
질문 2 부모-자식 프로세스 관계 기반 룰이 어느 자산군에 적용되어 있는가?
질문 3 리눅스 서버에서 프로세스 생성 이벤트가 실제로 수집되는가?
에이전트 배포 여부가 아니라 이벤트 수집 여부로 확인하였는가?
질문 4 자사 EDR 이 차단하는 기법과 통과시키는 기법을 검증한 기록이 있는가?출처 · Pentera Labs, LOLBins Against the Machine: Reverse Engineering at Machine Speed (2026-02-20, Matan Abutbul)