Dormant GitHub Accounts 공격 표면: 휴면 계정 기반 조직 매핑 대응 가이드

도입

Dormant GitHub 계정은 더 이상 단순한 계정 정리 대상이 아니다. Datadog Security Labs가 2026년 7월 공개한 분석에 따르면, 2025년 10월 이후 50개 이상의 오래된 GitHub 계정이 여러 기업 조직과 저장소, 사용자 정보를 API로 열람하는 데 동원됐다. 이 계정들은 생성된 지 2~5년이 지났고 장기간 활동이 없던 이른바 ghost 계정이었다.

이 공격의 핵심은 GitHub 계정 하나를 탈취해 곧바로 관리자 권한을 얻는 방식이 아니다. 오래된 계정과 정상 API 호출을 이용해 조직 구조, 저장소 이름, 구성원, 외부 협업자, 공개 기여 이력, gist, 팔로워 관계를 조용히 모은 뒤, 노출된 OAuth 토큰이나 Personal Access Token(PAT)이 결합되는 순간 비공개 저장소 접근으로 확장하는 흐름이다. 따라서 개발 조직은 휴면 계정을 인사 시스템의 잔여 계정 문제가 아니라 코드, CI/CD, 공급망 보안을 흔드는 정찰 인프라로 봐야 한다.

이번 사안은 CVE가 부여된 제품 취약점이 아니다. 그러나 공개 정보 수집만으로 끝나면 Medium 수준의 정찰 위험에 가깝더라도, 실제 관측 사례처럼 노출된 토큰과 결합해 private repository clone, ZIP 다운로드, API 접근으로 이어질 수 있다는 점에서 개발 조직 관점의 위험도는 High로 분류할 수 있다.

핵심 분석

공격자는 먼저 오래전에 생성됐거나 탈취된 GitHub 계정을 장기간 방치해 신규 계정 탐지 기준을 피해 간다. 이후 REST API와 GraphQL API를 사용해 기업 GitHub 조직을 반복적으로 조회한다. Datadog 분석에서 확인된 User-Agent에는 GitHubAnalytics/1.5, GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0, GitHub-Commit-Fetcher/1.3, GitHub-Event-Fetcher/2.2, repo-dumper, githarvester/1.0, request 등이 포함됐다.

대부분의 활동은 공개 API를 통한 조직 매핑이다. 공개 저장소 목록, 조직 구성원, 외부 협업자 흔적, 공개 커밋, gist, 팔로워 관계를 모으면 공격자는 기업의 개발 조직도를 상당 부분 재구성할 수 있다. 어느 팀이 핵심 제품을 담당하는지, 어떤 개발자가 릴리스 권한을 가질 가능성이 높은지, 내부 시스템명과 패키지명이 어떻게 구성되는지도 추론할 수 있다.

더 큰 문제는 공개 정찰이 토큰 악용과 연결될 때 발생한다. Datadog은 일부 캠페인에서 노출되거나 탈취된 OAuth 토큰과 PAT를 이용해 private repository commit path를 탐색하거나, 드문 사례에서는 private repository에 대한 git.clone 및 API 접근이 관측됐다고 설명했다. 즉 공격자는 처음부터 권한 있는 내부 계정처럼 보이지 않아도, 공개 조직 지도를 만든 뒤 유효한 토큰을 만나면 비공개 코드 영역으로 이동할 수 있다.

GitHub Enterprise Cloud의 dormant user 기준도 운영자가 오해하기 쉬운 지점이다. GitHub 문서상 Enterprise Cloud에서 휴면 사용자는 기본적으로 30일 이상 활동이 없는 사용자로 설명된다. 그러나 PAT, SSH key, GitHub App을 통한 접근이나 private repository clone/pull 같은 일부 Git 작업은 dormant user activity로 보지 않는 항목이 있다. 따라서 dormant user report만 보고 "문제가 없다"고 판단하면 실제 API 접근이나 토큰 기반 접근을 놓칠 수 있다.

기업 영향

첫 번째 영향은 비공개 코드와 메타데이터 노출이다. 저장소 이름, 브랜치 구조, 커밋 경로, 내부 API 명칭, 인프라 코드, 배포 스크립트, 패키지명은 그 자체로 공격 경로를 좁히는 단서가 된다. 여기에 hardcoded secret이나 오래된 CI/CD 토큰이 남아 있으면 정찰은 침투로 전환된다.

두 번째 영향은 사람 중심 공격의 정밀도 상승이다. 조직 구성원, 외부 협업자, 기여 이력, 릴리스 담당자를 매핑하면 공격자는 핵심 개발자와 운영자를 겨냥한 피싱, OAuth 앱 승인 유도, 가짜 보안 알림, 가짜 패키지 초대 같은 공격을 더 자연스럽게 설계할 수 있다.

세 번째 영향은 공급망 공격 가능성이다. 공개 저장소와 비공개 저장소의 명명 규칙, 내부 패키지명, GitHub Actions 워크플로우, 배포 경로를 알면 typosquatting, dependency confusion, 악성 pull request, CI/CD 토큰 탈취 시도가 더 정교해진다.

특히 위험한 조직은 SAML SSO만 운영하고 SCIM 자동 해지를 쓰지 않는 조직, classic PAT를 허용하는 조직, 외부 협업자 정리가 느린 조직, GitHub audit log streaming을 SIEM에 연결하지 않은 조직이다. SAML SSO는 인증을 강화하지만, SCIM 없이 퇴사자나 계약 종료자의 GitHub 접근을 자동으로 제거해 주지는 않는다. 토큰과 세션이 남아 있으면 조직은 계정 정리 완료로 보이는 상태에서도 접근 잔여 위험을 가질 수 있다.

탐지/점검 항목

우선 private repository 대상 성공 이벤트를 중심으로 봐야 한다. 공개 API 조회는 정상 활동과 섞이기 쉽고 HTTP 200으로 끝나는 경우가 많아 실패 로그인 중심 탐지만으로는 충분하지 않다. GitHub audit log에서 api.request, git.clone, repo.download_zip 이벤트를 private repository 기준으로 필터링하고, programmatic_access_type, user_agent, actor, repository, repository_public 또는 public_repo 필드를 함께 확인한다.

점검해야 할 대표 로그 조건은 다음과 같다.

• evt.action:api.request, status_code:2*, public_repo:false, programmatic_access_type:(OAuth OR Personal access token classic OR Fine-grained personal access token)
• evt.action:git.clone, repository_public:false, programmatic_access_type:(OAuth OR Personal access token classic OR Fine-grained personal access token)
• evt.action:repo.download_zip, public_repo:false, programmatic_access_type:(OAuth OR Personal access token classic OR Fine-grained personal access token)

User-Agent는 단독 차단 기준이 아니라 우선순위 신호로 사용한다. GitHub-Company-Scraper, GitHub-Scraper-Tool/1.0, GitHub-Commit-Fetcher/1.3, GitHub-Event-Fetcher/2.2, repo-dumper, githarvester/1.0, request 같은 문자열이 평소 사용 패턴과 맞지 않으면 actor, IP 대역, 접근 저장소, 토큰 유형을 함께 확인한다.

계정 점검에서는 조직 멤버와 outside collaborator를 분리하지 말고 함께 본다. 30일 이상 비활동 사용자, 퇴사자와 계약 종료자, SAML identity와 GitHub 계정 매핑이 불명확한 사용자, 장기 미사용 외부 협업자, 승인되지 않은 fine-grained PAT 요청, classic PAT 사용 계정이 우선 점검 대상이다.

운영 체크리스트는 다음 순서로 정리한다.

• GitHub Enterprise 또는 Organization audit log streaming이 SIEM으로 들어오는지 확인한다.
• private repository 대상 api.request, git.clone, repo.download_zip 성공 이벤트를 정기 룰로 만든다.
• dormant users report와 실제 audit log 접근 기록을 함께 대조한다.
• classic PAT 허용 여부와 fine-grained PAT 승인 정책을 확인한다.
• SAML SSO와 SCIM이 함께 구성돼 있는지 확인한다.
• outside collaborator의 저장소별 권한과 마지막 사용 시점을 검토한다.
• 비정상 clone/download가 확인된 저장소는 secret scan, dependency 점검, CI/CD 토큰 회전을 수행한다.

대응 우선순위

1순위는 로그 가시성 확보다. GitHub audit log streaming을 SIEM에 연결하고 private repository 성공 이벤트를 기준으로 탐지 룰을 만든다. 공개 API 열람 전체를 모두 차단하기는 어렵기 때문에, 비공개 저장소 접근과 토큰 기반 접근을 빠르게 식별하는 것이 현실적인 출발점이다.

2순위는 토큰 정책 정리다. classic PAT 사용을 제한하고, fine-grained PAT는 관리자 승인 정책을 강제한다. OAuth 앱과 GitHub App 권한도 주기적으로 검토해 실제 업무에 필요한 범위보다 넓은 권한을 제거한다. 장기 미사용 토큰은 폐기하고, private repository 접근 권한을 가진 토큰은 더 짧은 주기로 검토한다.

3순위는 SSO와 SCIM을 함께 운영하는 것이다. SAML SSO만으로는 사용자 생명주기 관리가 완성되지 않는다. 퇴사, 부서 이동, 계약 종료가 IdP에서 GitHub 조직 접근 해지로 자동 반영되도록 SCIM을 활성화하고, 예외 계정과 외부 협업자 계정은 별도 목록으로 관리한다.

4순위는 휴면 멤버와 외부 협업자 정리다. dormant user report를 내려받아 조직 멤버뿐 아니라 outside collaborator까지 포함해 정리한다. 저장소 단위 최소 권한 원칙을 적용하고, 오랫동안 사용되지 않은 collaborator는 제거한다. 단순히 계정이 오래됐다는 이유만으로 악성으로 볼 수는 없지만, 오래된 계정이 토큰 접근과 결합되면 위험이 급격히 커진다.

5순위는 사고 대응 절차 확정이다. private repository clone, ZIP 다운로드, 비정상 API 접근이 확인되면 해당 계정의 토큰 폐기, 세션 종료, GitHub App/OAuth 승인 회수, 관련 저장소 secret scan, CI/CD 토큰 회전, 접근 IP와 actor 기준 확산 조사를 한 번에 진행해야 한다. 코드 유출 가능성이 있는 경우에는 저장소 자체보다 빌드 파이프라인, 릴리스 키, 클라우드 자격 증명까지 영향 범위에 넣어야 한다.

결론적으로 휴면 GitHub 계정 관리는 계정 위생 작업이 아니라 개발 조직의 공격 표면 관리다. 공격자는 GitHub의 정상 API와 오래된 계정의 신뢰도를 이용해 조직 지도를 만들고, 토큰 하나가 발견되는 순간 정찰을 침투로 전환한다. 방어 측은 dormant report, audit log, SSO/SCIM, PAT 정책, 외부 협업자 정리를 하나의 운영 루프로 묶어야 한다.

참고자료

• Datadog Security Labs, Coordinated GitHub API enumeration and access token abuse: https://securitylabs.datadoghq.com/articles/coordinated-github-api-enumeration/
• The Hacker News, Dormant GitHub Accounts Help Attackers Blend In While Mapping Corporate Orgs: https://thehackernews.com/2026/07/dormant-github-accounts-help-attackers.html
• GitHub Docs, Managing dormant users: https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/managing-dormant-users
• GitHub Docs, Audit log events for your organization: https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization
• GitHub Docs, Audit log events for your enterprise: https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise
• GitHub Docs, Setting a personal access token policy for your organization: https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization
• GitHub Docs, About SCIM for organizations: https://docs.github.com/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.