[MITRE ATT&CK] Discovery — 공격자가 내부 환경을 어떻게 ‘읽는가’

◎ 개요

• Discovery는 공격자가 내부에 발판을 확보한 뒤 다음 행동(권한 상승, 횡적 이동, 자원 수집 등)을 결정하기 위해 환경을 조사하는 전술입니다. 
• ATT&CK에서는 System Discovery, Network Discovery, Remote System Discovery, Cloud Resource Discovery 등 다양한 Technique로 이 전술을 구체화하고 있으며, 이 과정에서 공격자는 자신의 목표·경로·리스크를 판단합니다.
• Discovery는 단순 정보 수집이 아니라 이후 공격 성공률을 결정짓는 ‘결정적 의사결정 과정’이므로, 이를 어떻게 탐지·차단하느냐가 SOC의 관건입니다.

 

◎ System Discovery — 내부 시스템을 파악하는 방법과 흔적

 - 공격자는 먼저 현재 점유한 호스트의 구성과 제약을 파악합니다. 

 - 대표적인 System Discovery 기법은 다음과 같습니다.

  > 호스트 정보 수집

• OS 버전, 패치 수준, 설치된 소프트웨어, 서비스·드라이버 목록, 파일 시스템 구조, 사용자 계정·그룹 정보 등입니다.
• 이런 정보는 systeminfo, hostname, wmic, /proc 조회, uname -a, lsblk, ps 등 명령으로 수집됩니다.
• 공격자는 이 정보로 취약점 존재 여부와 권한 상승 가능성을 판단합니다.

  > 계정 및 권한 파악

• 로컬 관리자/도메인 관리자 여부, sudoers 설정 확인, 서비스 계정 존재 여부를 확인합니다.
• Windows의 경우 whoami /priv, net user, 이벤트 로그 조회가 쓰이고, Linux는 id, sudo -l, /etc/passwd//etc/shadow 접근으로 확인합니다.
• 프로세스·서비스·포트 파악: 어떤 프로세스가 실행 중인지, 어떤 서비스가 관리자 권한으로 운영되는지, 열려 있는 포트와 바인딩 정보 등을 살펴 이후 악용 가능한 타깃을 찾습니다.

  > 실무적 탐지 포인트

• 프로세스·서비스 목록 조회가 평소 업무에서 빈번히 발생하지 않는 계정에서 실행될 경우, 또는 단일 호스트에서 짧은 시간 안에 다수의 시스템 정보 수집 명령이 실행될 경우 의심해야 합니다.
• 또한 정상 관리 스크립트가 아닌 도구(예: 임의의 PowerShell/ Bash 스크립트)가 시스템 정보를 수집하면 경보로 연결해야 합니다.

 

◎ Network Discovery — 내부 네트워크 구조와 연결점 파악

 - 공격자는 내부 네트워크의 토폴로지와 통신 패턴을 알아야 횡적 이동 및 고가치 자원(파일 서버, 도메인 컨트롤러, 데이터베이스 등)을 식별할 수 있습니다. 

 - 주요 수법은 다음과 같습니다.

  > 네트워크 연결 열람

• netstat, ss, ipconfig/ifconfig 등을 통해 현재 열려 있는 연결과 리스닝 포트를 확인합니다.
• 이 정보로 내부 서비스의 위치와 통신 흐름을 추정합니다.

  > ARP/네트워크 스캔

• arp -a, nmap, masscan, arp-scan 등을 이용해 가용 호스트 목록을 획득하고, 네트워크 세그먼트별 장비를 파악합니다.
• 네트워크 트래픽 관찰(스니핑): 패킷 캡처(예: tcpdump, Wireshark, Zeek)를 통해 프로토콜·서비스 식별, 인증 플로우(예: SMB, LDAP), 비정상 트래픽(외부 C2, 데이터 전송 경로) 등을 확보합니다.

  > Active Directory·서비스 탐색

• 도메인 환경에서는 LDAP 쿼리·Kerberos 티켓 현황·도메인 컨트롤러 위치·공유 폴더 정보를 수집합니다.
• 이는 향후 자격 증명 수집·레인섬 공격 루트 선정에 결정적입니다.

  > 실무적 탐지 포인트

내부 스캔 툴의 실행, 단기간의 대규모 포트 스캔, 비정상 ARP/네트워크 브로드캐스트, 로컬에서의 패킷 캡처(권한 있는 비관리 프로세스에서 수행된 경우) 등은 네트워크 정찰 시그널입니다.

내부 트래픽의 정상 기준(베이스라인)을 정의하고, 그 기준을 벗어나는 스캔·스니핑 행위를 탐지해야 합니다.

 

◎ Cloud Resource Discovery — 클라우드 환경에서의 탐색

 - 클라우드 환경에서는 전통적 네트워크 토폴로지 탐색 대신 API 호출·리소스 나열·권한·정책 정보 수집이 주가 됩니다. 

 - 구체적 예시는 다음과 같습니다.

  > API 기반 리소스 나열

• AWS(aws iam list-*, aws ec2 describe-*), Azure(az resource list, az ad user list), GCP(gcloud compute instances list) 등으로 계정·인스턴스·정책·버킷·역할 전반을 확인합니다.

  > IAM/권한 구조 파악

• 어떤 역할이 어떤 권한을 갖고 있는지, 신뢰 관계(trust relationship), 역할 전환 가능성, 서비스 계정의 권한 범위를 확인합니다.

  > 메타데이터 서비스 조사

• 클라우드 인스턴스의 메타데이터(IMDS)를 통해 인스턴스 프로필·임시 자격증명·사용자 데이터 등을 조회합니다(이를 통한 권한 획득 시나리오가 존재).

  > SaaS 및 Identity Provider 탐색

• 애플리케이션 목록, OAuth 애플리케이션 동의, 토큰 정보, 엔터프라이즈 애플리케이션 설정 등을 조사해 지속적 접근(토큰·API키)을 확보할 수 있는 지점을 찾습니다.

  > 실무적 탐지 포인트

• 짧은 시간 내 다량의 리소스 열람 API 호출, 평소 사용하지 않던 권한범위의 IAM 조회, 메타데이터 접근(특히 외부 IP에서 내부 인스턴스 메타데이터 호출이 의심스러운 상황)은 의심 신호입니다.
• 또한 콘솔·API 호출의 출발지가 의심스러운지(새로운 IP, 비정상적 지역)도 함께 보아야 합니다.

 

 

◎ 공격자의 환경 인식 전략 — ‘왜’·‘어떻게’ 생각하는가

 - Discovery 과정은 공격자가 ‘무엇을 노리는가(목적)’와 ‘어떻게 목표를 달성할 수 있는가(경로)’를 결합해 다음 행동을 선택하는 인지 과정입니다. 

 - 공격자는 다음 관점으로 환경을 분석합니다.

  > 목표 우선순위(가치 판단)

• 어떤 자산이 목표 가치(데이터 민감도, 시스템 관리자 권한, 백업·운영 영향 등)가 높은지 판단합니다.
• 예: 백업 서버·AD DC·CI/CD 자산·클라우드 관리자 계정 등.

  > 공격 비용·리스크 평가

• 특정 공격 기법(취약점 익스플로잇, 계정 탈취, 권한 상승 등)을 시도했을 때 들키거나 실패할 확률을 계산합니다.
• 탐지 위험이 높다면 stealthy 방식(토큰 남용, LOTL)으로 방향을 튼다.

  > 경로 최적화

• 발견한 정보를 기반으로 가장 효율적(빠르고 낮은 탐지 가능성)인 이동 경로를 설계합니다.
• 예: 엔드포인트 → 관리 콘솔 → 서비스 계정 → 데이터 저장소.

  > 방어/감시 지점 회피

• 로그 수집체계, EDR 배치, 네트워크 분리 지점 등을 파악해 탐지를 피할 수 있는 시나리오를 선택합니다.
• 예: 보안 로그 미수집 호스트를 우회 경로로 이용.

 - 공격자는 위 관점을 빠르게 반복하면서 변화하는 환경(패치, 권한 변경, 로컬 보안 설정 등)에 적응합니다.

 - 그렇기 때문에 Discovery는 정찰 단계가 아니라 적응적 의사결정 루프(피드백 루프)의 일부로 보셔야 합니다.

 

◎ 실무적 대응 — Discovery를 이용해 방어를 개선하는 방법

 - Discovery 단계의 탐지는 이후 공격 전개를 차단할 수 있는 ‘가장 효율적’인 시점입니다. 

 - 실무에서 권장하는 접근은 다음과 같습니다.

  > 데이터 수집과 상관관계 강화

• 엔드포인트(EDR), 호스트 로그(Sysmon/Windows Event), 네트워크(Zeek/NSM), 클라우드(Audit/CloudTrail), IdP 로그를 시간축으로 결합해 정찰 활동의 흔적(다수의 정보 수집 API 호출, 내부 스캔, 프로세스 기반 정보 수집 등)을 찾아냅니다.
• 단일 이벤트가 약해도, 서로 다른 로그에서 연쇄적인 정찰 신호가 보이면 탐지 신뢰도가 급격히 올라갑니다.

  > 정상 베이스라인(행동 프로파일) 수립

• 평상시 관리자 스크립트, 자동화 작업, 백업·모니터링 툴의 정상 호출 패턴을 정의해 ‘정상 정찰’과 ‘악의적 정찰’을 구분합니다.
• 예컨대 특정 사용자·서비스 계정이 정기적으로 리소스 열람을 한다면 허용하되, 동일한 작업을 다른 계정이나 다른 시간대에서 대량으로 수행하면 경보화합니다.

  > 최소권한·자격 증명 분리

• 공격자가 계정으로 쉽게 리소스를 ‘나열’·‘탈취’하지 못하도록 권한 최소화와 서비스 계정 분리를 강화합니다.
• 클라우드에서는 역할 기반 접근제어(RBAC), 임시 자격증명(짧은 세션 수명), 세션 모니터링을 적극 활용합니다.

  > 탐지 룰과 헌팅 가설 마련

• Discovery 관련 헌팅 규칙(예: API 리소스 열람의 급증, 내부 네트워크 스캔, 권한 관련 명령의 반복 실행)을 미리 규정하고, ATT&CK 매핑을 통해 우선순위를 둡니다.
• ATT&CK Navigator로 Discovery 관련 Technique의 커버리지(어디가 보이고 어디가 비어있는지)를 시각화하면 투자 우선순위를 정할 때 도움이 됩니다.

  > 방어 작전(Contain & Deceive)

• 침해 의심 시 즉시 추가 수집(포렌식적 메모리 덤프, 네트워크 세션 캡처)을 실행해 빠르게 환경 인식을 확보하고, 의심 자산을 분리·격리합니다.
• 트랩(허니토큰, 허니계정)을 배치하면 공격자의 Discovery 결과를 교란하거나 공격자를 유인해 탐지 기회를 만들 수 있습니다.

 

◎ 사례로 보는 공격자 관찰 루틴 (간단 시나리오)

• 초기 발판 확보(예: 피싱) → 로컬 System Discovery(계정, 프로세스, 서비스 파악) → 네트워크 Discovery(내부 스캔, 열려 있는 SMB/SSH 포트 식별) → 크레덴셜 획득 시도(LSASS 덤프 또는 키로깅) → 획득한 자격 증명으로 Cloud/IdP 접근 → Cloud Resource Discovery(권한·역할 파악) → 역할 전환·영구 토큰 확보 → 중요 데이터 접근/유출.
• 이 흐름의 핵심은 공격자가 작은 정보(서비스 목록, 권한, 열린 포트)를 바탕으로 자신에게 유리한 ‘다음 단계’를 선택한다는 점입니다. 이를 끊는 것이 바로 Discovery 단계에서의 방어 목표입니다.

 

◎ 마무리

 - Discovery를 방어의 중심에 두어야 하는 이유

• Discovery는 공격자가 ‘무엇을 할 것인가’를 결정하는 정보적 초석입니다.
• 정찰 신호를 빨리 포착하면 공격자의 의사결정 루프를 교란하고, 후속 공격(권한 상승·횡적 이동·유출)을 미연에 방지할 수 있습니다. 
• 반대로 Discovery가 성공하면 공격자는 자신에게 유리한 경로를 골라 빠르게 확장합니다. 
• 따라서 SOC·헌팅·CTI는 Discovery 관련 로그·행동·API 호출을 우선적으로 모니터링하고, ATT&CK 기반으로 커버리지를 정기 점검하시길 권합니다.