Detection Engineering
이 사례는 아래 순서로 보면 배경, 판단 기준, 산출물 흐름이 가장 자연스럽게 이어집니다.
접근 로그에서 피싱 피해 신호를 직접 설계
피싱은 사용자가 어디서 들어왔고 이후 어떤 로그인 행동을 했는지에 흔적을 남깁니다. 이 작업은 접근 로그의 referrer와 로그인 이벤트를 조합해, 기존 탐지 체계가 놓칠 수 있는 피해 가능성을 찾아낸 사례입니다. 문자열 유사도와 도메인 패턴으로 후보를 선별하고, 로그인 데이터까지 확인해 사용자 알림으로 연결했습니다.
작은 로그 단서에서 피해 가능 사용자까지 추적하는 탐지 흐름을 만들었습니다.
피싱 탐지 파이프라인
피싱 도메인만 찾는 것이 아니라, 의심 referrer에서 실제 서비스 로그인까지 이어진 사용자를 좁혀 조치 가능한 단위로 만들었습니다.
서버 접근 로그와 로그인 이벤트를 수집해 접속 경로와 계정 활동을 함께 확인
수집접근 로그에서 referrer, host, path, user-agent, IP 등 피싱 단서를 추출
추출정상 도메인과 유사한 문자열, 오탈자, 위장 도메인 패턴을 비교
유사도의심 referrer 이후 로그인 데이터와 사용자 계정을 연결해 피해 가능성 확인
상관분석피해 의심 사용자를 식별하고 알림·확인 절차로 연결
조치피싱 탐지는 의심 URL 목록에서 끝나면 부족합니다. 실제 로그인 흔적과 연결해 누가 영향을 받았는지까지 좁혀야 합니다.
탐지 로직
서버 접근 로그와 로그인 이벤트 수집
접근 경로와 referrer 데이터 추출
문자열 유사도와 도메인 패턴으로 의심 후보 선별
피해 가능 사용자 로그인 데이터 분석
의심 사용자에게 알림과 확인 절차 연결
탐지 데이터 구조
사용자가 어느 referrer에서 서비스로 들어왔는지 추출해 피싱 유입 가능성을 확인합니다.
정상 도메인과 유사한 문자열, 오탈자, 하위 도메인 위장, 브랜드 오용 패턴을 후보로 잡습니다.
의심 경로 이후 실제 로그인 성공·실패, IP, 사용자 정보를 조합해 피해 가능성을 좁힙니다.
도메인 탐지에서 끝내지 않고 피해 가능 사용자를 특정해 안내와 확인으로 연결합니다.
탐지 설계 포인트
referrer처럼 평소에는 지나칠 수 있는 필드를 공격 흔적으로 재해석했습니다.
정확히 일치하지 않아도 유사 도메인과 오탈자 패턴을 후보로 잡았습니다.
도메인 탐지에서 끝내지 않고 실제 피해 가능 사용자까지 좁혔습니다.
접근 경로와 로그인 이벤트를 조합해 단일 로그로는 보이지 않는 피해 가능성을 확인했습니다.
기성 탐지에만 의존하지 않고 서비스 로그 구조에 맞춰 직접 탐지 로직을 만들었습니다.
탐지 결과를 사용자 알림과 확인 절차로 연결해 실제 대응으로 마무리했습니다.
피싱 피해 가능성 판단
의심 도메인 하나만으로 피해를 단정하지 않고, referrer 유사도와 로그인 흔적을 함께 판단했습니다.
유사 도메인 referrer와 로그인 성공이 연결되면 피해 가능 사용자로 분류합니다.
유사도는 높지만 로그인 증거가 약하면 추가 로그 확인 대상으로 둡니다.
의심 referrer만 반복되면 차단·모니터링 후보로 관리합니다.
사용자 영향이 확인되면 알림과 계정 보호 절차로 연결합니다.
이 페이지는 솔루션 운용자가 아니라 detection engineer처럼 생각할 수 있다는 증거입니다. 로그를 보고, 공격 가설을 세우고, 탐지 로직과 사용자 조치까지 연결했습니다.