비밀번호를 훔치지 않아도 계정을 빼앗는다…러시아 연계 해킹 조직의 새 수법

클러스터별 공격 수법

UNC6293: 국무부 사칭과 앱 비밀번호·OAuth 악용

UNC6293은 미국 국무부 관계자와 기타 신뢰할 수 있는 연락처를 사칭한 것으로 전해졌습니다. 공격자는 표적에게 앱 전용 비밀번호를 만들고 이를 공유하도록 유도했습니다. 앱 전용 비밀번호는 일반적인 추가 인증 절차를 거치지 않고도 계정에 접근하는 데 악용될 수 있습니다. 또한 비밀번호 자체를 훔치는 대신 OAuth 승인 토큰을 확보하려는 ‘동의 피싱’도 활용한 것으로 GTIG는 설명했습니다.

GTIG는 UNC6293이 구글이 과거 APT29로 알려진 공격자를 지칭하는 명칭인 ICE RELIC의 초기 침투 하위 클러스터일 가능성을 ‘중간 수준의 신뢰도’로 평가했습니다.

UNC7005·STORM-2945: 왓츠앱 기기 연결과 다단계 유인

UNC7005는 상황에 따라 수법을 바꾸며 여러 공격 방식을 사용한 것으로 보고됐습니다.

• 왓츠앱 기기 연결 사기: 피해자가 공격자 소유 기기를 자신의 왓츠앱 계정에 연결하도록 유도했습니다.
• 가짜 음성 통화와 암호화 메신저 초대: 먼저 통화나 대화를 통해 신뢰를 쌓은 뒤 악성 링크나 코드를 전달했습니다.
• 기관을 사칭한 연락: 핀란드 운영센터(Finnish Operations Center)를 언급한 가짜 안내와 함께 위조된 마이크로소프트 로그인 페이지를 사용했습니다.
• OAuth와 악성코드 결합: 구글 OAuth 흐름으로 토큰이나 계정 접근 권한을 노리는 동시에 VIDAR, ATOMIC 인포스틸러를 배포했습니다.

UNC7005의 기술과 공격 인프라는 UNC6293과 달랐습니다. 두 클러스터가 비슷한 표적과 인증 기능 악용 방식을 보였지만, GTIG가 별개의 작전으로 분류한 이유입니다.

UNC5976: 방산·군사 표적을 겨냥한 OAuth 피싱

UNC5976은 군사·항공우주·방산 관련 인력과 조직을 주로 노린 것으로 전해졌습니다. 우크라이나와 아르메니아에 연관된 표적도 포함됐으며, OAuth 피싱을 통해 피해자의 계정이나 데이터에 접근할 수 있는 권한을 얻으려 했습니다.

러시아 연계성은 어떻게 평가됐나

GTIG는 전체 활동이 러시아와 연관돼 있을 가능성을 ‘높은 신뢰도’로 평가했습니다. 다만 이는 전체 작전의 배후에 러시아 관련성이 있다고 판단했다는 의미이며, 각 클러스터의 관계나 모든 세부 작전이 같은 수준으로 입증됐다는 뜻은 아닙니다.

일부 활동과 ICE RELIC·APT29 사이의 연관 가능성도 제기됐습니다. 다만 UNC6293과 ICE RELIC의 연결은 ‘중간 수준의 신뢰도’ 평가이며, 각 클러스터는 서로 다른 기술과 인프라를 사용하기 때문에 별도로 추적되고 있습니다.

다중인증만으로는 충분하지 않은 이유

다중인증은 여전히 중요한 보안 수단입니다. 그러나 공격자가 사용자를 속여 잘못된 동작을 승인하게 만들면 보호 기능이 오히려 공격자의 접근을 합법화하는 통로가 될 수 있습니다.

예상하지 못한 OAuth 동의 화면, 앱 비밀번호 생성 요청, 왓츠앱 기기 연결 코드가 나타났다면 비밀번호를 도난당하지 않았더라도 계정 탈취 시도일 수 있습니다. 인증 화면이 익숙한 서비스 안에 표시된다는 이유만으로 안전하다고 판단해서는 안 됩니다.

GTIG가 권고한 대응책

공격자가 서두르게 만드는 절차를 잠시 멈추고, 요청의 출처와 내용을 따로 확인하는 것이 핵심입니다.

• 로그인하거나 OAuth 접근 권한을 승인하기 전 브라우저 주소창의 전체 URL을 확인합니다.
• 학회 초대, 음성 통화, 암호화 메신저 요청, 정부·기관 관계자를 사칭한 메시지는 기존에 알고 있는 연락처를 통해 독립적으로 재확인합니다.
• 앱 비밀번호, 일회용 인증 코드, QR 코드, 기기 연결 코드를 다른 사람에게 절대 전달하지 않습니다. 예상하지 못한 로그인이나 OAuth 요청도 승인하지 않아야 합니다.
• 왓츠앱 등 메신저의 연결된 기기 목록을 정기적으로 확인하고 모르는 기기는 삭제합니다.
• 조직은 보안 키나 패스키 같은 피싱 방지형 다중인증을 우선 도입하고, 가능하다면 위험한 OAuth 애플리케이션과 앱 전용 비밀번호 사용을 제한해야 합니다.

이번 사례가 보여주는 교훈은 간단합니다. 익숙한 브랜드나 실제 로그인 페이지, 서비스에 정식으로 포함된 인증 기능도 요청의 정당성을 보장하지 않습니다. 로그인과 승인, 기기 연결을 요청한 사람과 조직이 실제로 누구인지까지 확인해야 계정을 지킬 수 있습니다.