月光愛靑狼

1. 개요

• MKYU는 2026년 9월 16일 오후 6시 42분쯤 회원정보 일부가 외부로 다운로드된 사실을 확인했습니다.
• 외부 접근 및 추가 회원정보 조회 정황도 있어, MKYU는 일부 회원정보가 외부에 노출됐을 가능성을 조사하고 있습니다.
• 현재 확인되는 사고는 MKYU가 운영하는 성인 대상 교육플랫폼의 회원정보 관련 사고이며, 공격 주체와 구체적인 침입 방식은 확인되지 않았습니다.

2. 피해범위

• 회원정보 일부가 외부로 다운로드된 사실이 확인됐습니다. 
• MKYU는 다운로드된 정보에 포함된 회원에게 개별적으로 안내했다고 밝혔습니다.
• 추가적인 회원정보 조회 정황과 외부 접근 가능성도 확인되어, 다른 회원에게도 안내를 진행하고 있다고 설명했습니다.
• 전체 피해 회원 수와 실제 정보가 외부로 반출된 회원 수는 확인되지 않았습니다.
• MKYU는 당시 확인된 다운로드 건 외에는 추가 유출 사실이 확인되지 않았다고 밝혔습니다.
• 따라서 현재 확인 가능한 피해규모는 “일부 회원” 수준이며, 정확한 인원은 확인되지 않았습니다.

3. 유출항목

 - 외부 다운로드 건에는 다음 정보가 포함된 것으로 확인됐습니다.

이름

전화번호

이메일 주소

 - 다만 다운로드된 파일 또는 정보는 내용을 확인할 수 없는 상태였다고 MKYU가 설명했습니다.

 - 다음 정보는 해당 외부 다운로드 건에 포함되지 않았다고 밝혔습니다.

• 비밀번호
• 카드번호
• 계좌번호

 - 주민등록번호, 주소, 생년월일 등 다른 개인정보의 포함 여부는 확인되지 않았습니다. 

4. 원인

• 현재 확인된 내용만으로는 사고의 구체적인 원인이나 공격 방식이 밝혀지지 않았습니다.
• MKYU는 접속기록을 확인하면서 정확한 경위를 조사하고 있다고 밝혔습니다.
• 따라서 관리자 계정 탈취, 시스템 취약점 악용, 내부자 접근 등 구체적인 원인은 현재 확인되지 않은 내용으로 구분해야 합니다.

5. 대응

 - MKYU가 밝힌 대응 내용은 다음과 같습니다.

• 외부 다운로드가 발생한 회원에게 개별 안내
• 추가 조회 및 외부 접근 가능성이 있는 회원에 대한 안내
• 관계기관 신고
• 개인정보보호위원회 신고
• 접속기록 확인을 통한 사고 경위 조사
• MKYU 사칭 문자·이메일·전화에 대한 주의 당부

 - MKYU의 공식 안내문 검색 결과에는 비정상적인 외부 접속과 관련 발송을 차단하고 관리자 계정의 보안 설정을 변경했다는 내용도 확인됩니다.

6. 문제점

 - 현재 확인 가능한 내용에서 지적할 수 있는 문제점은 다음과 같습니다.

• 회원정보 일부가 외부에서 다운로드될 수 있었던 접근통제 문제가 발생했습니다.
• 일부 정보의 실제 유출 여부와 추가 조회 범위가 사고 확인 시점에 명확히 확정되지 않았습니다.
• 전체 피해 회원 수와 실제 반출된 정보의 범위가 공개적으로 확인되지 않았습니다.
• 사고의 근본 원인과 공격자의 접근 경로가 아직 확인되지 않았습니다.
• 회원정보 유출과 함께 MKYU를 사칭한 문자·이메일·전화 등 2차 피해 가능성이 제기됐습니다. 

1. 개요

• 레벨13은 2026년 9월 16일 오후 3시경 미확인 계정을 발견했으며, 같은 날 오후 5시 30분경 관련 시스템의 접근을 차단했다고 이용자들에게 안내했습니다.
• 회사 측은 데이터 분석 도구인 메타베이스(Metabase)의 보안 취약점이 악용되어, 해당 도구에 연결된 고객정보에 비인가 접근이 발생한 것으로 조사하고 있습니다.
• 다만 공격자의 신원, 최초 침투 시점과 구체적인 악용 취약점 정보는 확인되지 않았습니다.

2. 피해범위

 - 현재 확인되는 피해범위는 다음과 같습니다.

• 룩핀 이용자 개인정보 일부
• 전체 피해 이용자 수: 확인되지 않음
• 모든 이용자에게 동일한 정보가 유출되었는지 여부: 확인되지 않음
• 비밀번호 해시 유출 여부: 공지 대상 항목에 포함됨
• 일부 이용자에 한해 휴대폰 번호와 접속 IP 유출 가능성 확인

 - 따라서 현재 공개된 내용만으로는 전체 회원 규모나 실제 피해 이용자 수를 산정할 수 없습니다.

3. 유출항목

 - 전체 또는 주요 유출항목

• 이메일 주소
• 비밀번호 해시 등연락처)
• 주문내역
• 배송지(수령인/주소)
• 휴대폰 번호
• 접속 IP 주소
• 키
• 몸무게 등

 - 원문은 비밀번호 원문이 아닌 비밀번호 해시가 유출된 것으로 설명하고 있습니다.

• 다만 해시 알고리즘, 솔트 적용 여부, 해시 강도 및 비밀번호 원문 복원 가능성은 확인되지 않았습니다.

4. 원인

• 회사 측의 현재 조사 결과에 따르면, 메타베이스의 보안 취약점이 악용된 것이 원인으로 파악되고 있습니다.

 - 메타베이스와 연결된 고객정보가 비인가 접근을 통해 유출된 것으로 설명되었지만, 다음 사항은 확인되지 않았습니다.

• 악용된 취약점의 CVE 또는 취약점명
• 공격자가 사용한 구체적인 공격 기법
• 취약점의 최초 발생 및 방치 기간
• 메타베이스 접근권한 설정의 구체적인 문제
• 외부 계정 탈취 여부
• 데이터베이스 자체가 직접 침해되었는지 여부

 - 따라서 확인된 원인은 “메타베이스 보안 취약점 악용”까지로 한정하는 것이 적절합니다.

5. 대응

 - 레벨13은 다음 조치를 진행하거나 완료했다고 밝혔습니다.

• 9월 16일 오후 5시 30분경 관련 시스템 접근 차단
• 관련 시스템의 접속 비밀번호 변경 또는 사용 중지
• 인증정보 변경 또는 사용 중지
• 침해사고 신고
• 개인정보 유출 신고
• 관련 증거 보존
• 관계기관 조사 및 요청에 협조
• 이용자에게 비밀번호 변경 요청
• 유출정보를 악용한 피싱 공격 주의 당부

 - 회사 측은 침해사고 신고와 개인정보 유출 신고를 각각 한국인터넷진흥원에 완료했다고 밝혔습니다.

• 다만 신고 접수 시각, 취약점 제거 완료 여부, 피해 이용자별 개별 통지 범위 및 추가 보안 조치의 완료 여부는 확인되지 않았습니다.

6. 문제점

 - 확인된 내용에 근거하면 다음과 같은 문제점이 제기됩니다.

• 고객정보에 연결된 데이터 분석 도구에서 보안 취약점이 악용되었습니다.
• 메타베이스와 고객정보 간 연결 구조가 공격을 통해 개인정보 접근으로 이어졌습니다.
• 미확인 계정이 발견되기 전까지 비인가 접근이 발생한 사실이 탐지되지 않았습니다.
• 유출된 비밀번호 해시가 악용될 가능성에 대비해 이용자들이 별도로 비밀번호를 변경해야 하는 상황이 발생했습니다.
• 이메일 주소와 일부 이용자의 휴대폰 번호가 함께 유출되어 피싱·사칭 공격에 악용될 위험이 있습니다.

1. 개요

• 영어 전문 교육 그룹 DYB교육(운영 브랜드: 초등 창의·표현 영어 CREO, 초·중·고 내신·입시 전문 최선어학원)의 입학테스트 예약 시스템이 국내외 서버를 통한 대규모 해킹 공격을 받아 일부 회원의 개인정보가 유출된 정황이 확인되었습니다.
• DYB교육 측은 문제 인지 후 비정상 접근 경로를 차단하고 악용된 계정을 정지하는 등 보안 조치를 완료했다고 밝혔습니다.

2. 피해범위

• 구체적인 피해 인원(명) 또는 레코드 수에 대한 수치가 명시되지 않았습니다.
• 유출 경로 및 영향 범위는 “입학테스트 예약 시스템 내 일부 회원”으로만 기술되어 있어 정확한 규모는 확인되지 않았습니다.

3. 유출항목

 - 알려진 유출 정보는 다음과 같습니다.

• 이름, 학교, 학년, 생년월일, 성별
• 학부모 연락처와 주소, 우편번호
• 테스트 예약 정보

 - DYB교육 측은 주민등록번호 등 고유식별정보, 비밀번호 원문, 결제 및 카드정보는 처음부터 수집하지 않아 유출되지 않았다고 설명했습니다.

4. 원인

• “국내외 서버를 통한 대규모 해킹 공격”으로 표현되었으나, 구체적인 공격 기법(예: 웹 취약점, 계정 탈취, 악성코드 등)에 대한 기술적 원인은 기사에 명시되지 않았습니다.
• 따라서 원인은 확인되지 않음으로 표기합니다.

5. 대응

 - DYB교육 측은 사고 인지 후 다음과 같은 조치를 취했다고 밝혔습니다.

• 비정상 접근 경로 차단
• 악용된 계정 정지
• 보안 패치 완료

6. 문제점

 - 직접적인 문제점은 확인되지 않았으나, 다음과 같은 사항을 확인할 수 있습니다.

• 입학테스트 예약 시스템이 해킹에 노출되어 개인정보 유출이 발생했다는 점에서 예약 시스템의 접근제어 및 보안 관리 강화 필요성이 제기됩니다.
• 유출 항목에 학부모 연락처·주소 등 민감한 연락처 정보가 포함되어 있어, 학원 업계 전반의 개인정보 처리 및 저장 체계에 대한 점검 필요성이 부각됩니다.

1. 개요

• 팬심 운영사 일리오는 2026년 9월 19일 오전 2시쯤 개인정보 노출 관련 제보를 접수한 뒤 점검에 착수했습니다. 
• 이후 후기 작성 계정의 닉네임과 실명이 제3자에게 조회될 수 있는 경로와 외부의 무단 조회 정황을 확인한 것으로 확인되었습니다.
• 팬심은 같은 날 오후 2시부터 서비스 점검에 들어갔으며, 공식 홈페이지에서는 점검 중 문의·상담이 어렵다고 안내하고 있습니다.
• 개인정보 유출 여부를 이용자가 직접 확인할 수 있는 별도 페이지도 제공하고 있습니다.
• 현재 확인되는 사건은 회원 전체 데이터베이스가 외부 공격으로 탈취된 사건이라기보다, 후기 작성 계정의 닉네임과 실명이 비정상적으로 조회·노출된 개인정보 접근 사고로 정리하는 것이 적절합니다.

2. 피해범위

• 확인된 피해범위는 팬심에서 후기를 작성한 계정 일부입니다.
• 후기 작성 계정의 닉네임과 실명이 노출된 것으로 제시되어 있으나, 전체 피해자 수나 전체 계정 수는 공개되지 않았습니다.
• 피해대상: 후기 작성 계정 일부
• 확인된 피해규모: 정확한 인원 미공개

3. 유출항목

 - 확인된 유출 또는 노출 항목은 다음과 같습니다.

• 후기 작성 계정의 닉네임
• 후기 작성자의 실명

 - 위 두 항목이 현재까지 확인된 노출 정보로 제시되어 있습니다.

• 이메일 주소, 전화번호, 주소, 결제정보, 비밀번호, 계정 인증정보 등이 함께 유출됐다는 내용은 확인되지 않았습니다.
• 따라서 현재 기준으로는 닉네임과 실명 외의 개인정보는 확인되지 않음으로 표시해야 합니다.
• 팬심의 개인정보 처리방침에는 회원가입 및 서비스 제공 과정에서 성명, 이메일주소, 휴대폰번호, SNS 닉네임 등 여러 정보가 수집될 수 있다고 명시되어 있지만, 이는 평상시 수집항목에 대한 설명일 뿐 이번 사고에서 실제 유출된 항목을 의미하지는 않습니다.

4. 원인

• 일리오는 후기 작성 계정의 닉네임과 실명이 권한 없는 제3자에게 조회될 수 있는 경로가 있었다고 확인했습니다. 
• 또한 외부의 무단 조회 정황을 조사 중인 것으로 기사에 나타나지만, 취약한 API, 접근제어 오류, 인증 우회, 데이터베이스 침해 등 구체적인 기술적 원인은 공개되지 않았습니다.

 - 따라서 현재 확인 가능한 원인은 다음과 같습니다.

• 후기 작성 계정 정보가 권한 없는 제3자에게 조회될 수 있는 노출 경로 존재
• 외부에서 해당 정보를 무단 조회한 정황
• 구체적인 취약점과 공격 방식: 확인되지 않음
• 데이터베이스 전체 침해 여부: 확인되지 않음
• 공격자 또는 유포자 신원: 확인되지 않음

 - 팬심 홈페이지가 2026년 9월 19일 오후 2시부터 서비스 점검에 들어간 사실은 확인되지만, 점검 사유와 특정 기술 취약점의 연관성은 공식적으로 상세 공개되지 않았습니다.

5. 대응

• 팬심 운영사는 2026년 9월 19일 오전 2시쯤 제보를 접수한 뒤 사실관계 확인에 착수했습니다. 
• 이후 서비스 점검을 진행하고, 개인정보 유출 여부를 확인할 수 있는 별도 페이지를 제공했습니다.

 - 확인된 대응 내용은 다음과 같습니다.

• 개인정보 노출 제보 접수
• 사실관계 및 외부 무단 조회 정황 조사
• 2026년 9월 19일 오후 2시부터 서비스 점검
• 이용자가 개인정보 유출 여부를 확인할 수 있는 페이지 제공
• 점검 중 문의 및 상담 제한

 - 개인정보보호위원회 신고 여부, 한국인터넷진흥원 신고 여부, 피해 이용자 개별 통지 여부, 유출 정보 삭제·회수 조치, 비밀번호 초기화 또는 2차 피해 방지 조치 등은 확인된 뉴스 기사에서 구체적으로 확인되지 않았습니다.

6. 문제점

• 현재 기준으로 확인되는 핵심 문제는 후기 작성자의 실명과 닉네임이 권한 없는 제3자에게 조회될 수 있었다는 점입니다. 
• 팬심 홈페이지는 “개인정보 노출 없이 안전하게 선물을 주고받을 수 있다”고 서비스 특성을 소개하고 있어, 실제 이용자 식별정보가 노출된 사실이 확인될 경우 서비스의 개인정보 보호 설계와 운영에 중대한 문제가 제기될 수 있습니다.

 - 구체적으로는 다음 사항이 문제로 확인됩니다.

• 후기 작성 계정의 실명·닉네임에 대한 접근통제 미흡 가능성
• 권한 없는 제3자의 개인정보 조회 가능 경로 존재
• 외부에서 개인정보를 대량 또는 반복 조회했을 가능성
• 사고 발생 후 정확한 피해자 수와 추가 유출항목이 아직 공개되지 않음
• 기술적 원인과 외부 조회 방식이 아직 확인되지 않음
• 관계기관 신고, 개별 통지, 정보 삭제·회수 여부가 공개적으로 확인되지 않음

 - 다만 위 항목 중 “접근통제 미흡”은 기사에서 확인된 비정상 조회 가능성을 보안상 문제로 표현한 것이며, 구체적인 코드 결함이나 설정 오류가 공식적으로 확정된 것은 아닙니다.

1. 개요

• 미국 FBI와 해안경비대는 2026년 8월, 텍사스행 유조선 2척의 네트워크 침해 정황을 확인하고 선박에 승선해 조사했습니다. 
• 그중 한 척이 현대글로비스 소유의 VL Prosperity로 확인됐고, 미국 쪽에서는 이란 또는 이란 연계 세력의 사이버 공격 가능성을 살펴봤습니다.
• 이 사건은 현대글로비스 소유, HMM오션서비스가 안전 관리를 맡은 VL 프로스페리티가 중심이며, 국내 기업들도 관련 질의를 받은 것으로 확인됐습니다.

※ VL 프로스페리티(VL Prosperity)호는 라이베리아 선적의 초대형 원유운반선(VLCC)으로 VesselFinder, 2026년 8월 지브롤터 해협을 통과하던 중 배후가 이란으로 의심되는 대규모 사이버 공격(해킹)을 받아 국제적인 주목을 받은 선박입니다. 이 선박의 기술 및 안전 관리는 한국의 해운 기업인 HMM 오션서비스가 맡고 있습니다

2. 피해범위

• 확인된 직접 피해는 통신 두절 약 30시간과 항해·추진·기관·화물 시스템 일부에 대한 침해 정황입니다.
• 해경/FBI가 적어도 한 척에서 기관실 시스템 침투로 엔진 냉각수 흐름 저하, 엔진 회전 속도 증가, 연료·엔진오일 탱크 기능 마비 가능성이 조사했지만, 실제 운항 차질·선박 불안정·인명 피해·환경 피해는 보고되지 않았다고 합니다.
• 피해 규모를 금액으로 특정한 내용은 확인되지 않았습니다.

3. 유출항목

• 명시적으로 확인된 것은 악성코드 감염 정황, 일부 데이터 삭제 정황, 그리고 선박 운영 시스템 관련 침투 정황입니다.
• 데이터 유출보다 시스템 조작 정황입니다. 구체적으로 엔진룸 시스템 침투, 냉각수 흐름 저하, 엔진 속도 증가, 연료·엔진오일 시스템 간섭이 언급됐지만, 어떤 파일이나 개인정보가 밖으로 유출됐는지는 확인되지 않았습니다. 
• 따라서 현재로서는 “운항 관련 시스템 침해 및 데이터삭제 정확 확인, 구체적 유출항목은 확인되지 않음”으로 정리하는 것이 적절합니다.

4. 원인

• 미국 당국은 공격 장소와 목적지를 근거로 이란 또는 이란 연계 세력의 소행 가능성을 살펴보고 있습니다. 
• 다만 공격 주체를 자처한 해킹 조직은 아직 없고, 최종 배후는 확정되지 않았습니다. 
• 따라서 현재까지의 원인은 “이란 연계 가능성이 제기된 선박 사이버 공격” 정도로만 확인됩니다.

5. 대응

• 미국 해안경비대와 FBI는 8월 21일과 24일에 각각 선박에 승선해 OT와 IT 시스템 무결성을 점검했습니다. 
• 선박은 미국 당국의 항만국통제 성격 검사도 받은 것으로 전해졌습니다.
• 현대글로비스는 운항 전 악성코드 감염 및 데이터 일부 삭제 정황을 신고했다고 밝혔습니다.
• 미국 해안경비대에 따르면 관련 조사는 “외국 사이버 행위자에 의한 네트워크 침해 정황”을 근거로 진행됐고, 해당 사건으로 운항 안전성 훼손이나 선원 위험, 환경 피해는 보고되지 않았다고 설명했습니다.

6. 문제점

• 이번 사건은 선박의 OT·IT 시스템이 실제 공격 대상이 될 수 있음을 보여준 점이 핵심 문제입니다. 
• 또 IMO 사이버보안 의무 적용 범위와 시점 때문에, 현재 운항·건조 중인 선박이 제도적 사각지대에 놓일 수 있다는 지적이 나왔습니다. 또 한 척만이 아니라 2척이 동시에 의심 대상이었고, 그중 최소 1척은 한국 회사가 관련돼 있었다는 점에서 영향 범위가 넓었습니다.
• 다만 데이터 유출 여부, 공격 주체, 최종 손해액은 끝내 확인되지 않았습니다.

1. 개요

• 나인하이어는 2026년 9월 15일 회원 정보를 저장하는 서버에 외부의 허가되지 않은 접근이 발생했고, 이후 개인정보 유출 사실을 확인했습니다. 
• 이 사고는 채용관리 솔루션에서 기업회원 정보가 유출된 사례로, 유출된 이메일이 피싱이나 계정 탈취 시도에 악용될 가능성이 함께 지적되었습니다.

2. 피해범위

• 확인된 피해 범위는 기업회원 사용자의 이름과 계정 이메일 주소입니다. 
• 회원별 유출 여부는 로그인 후 본인에게만 안내된다고 했으므로, 전체 피해 인원 수는 확인되지 않습니다.
• 지원자 개인정보는 유출되지 않은 것으로 회사가 파악했다고 밝혔습니다.

3. 유출항목

• 확인된 유출항목은 기업회원의 이름과 계정 이메일 주소입니다. 
• 반대로 유출되지 않은 항목으로는 비밀번호, 로그인 인증 정보, 휴대전화번호, 결제 정보, 나인하이어가 관리하는 지원자 개인정보가 명시되었습니다.

4. 원인

• 회사 설명에 따르면, 원인은 회원 정보를 저장하는 서버에 대한 외부의 허가되지 않은 접근입니다. 
• 다만 침입에 사용된 구체적 취약점, 공격 기법, 최초 침투 경로는 확인되지 않습니다.
• 따라서 기술적 세부 원인은 아직 공개되지 않은 상태입니다.

5. 대응

• 나인하이어는 사고 확인 뒤 공격에 사용된 접근 경로를 차단하고, 악용된 회원 조회 기능의 사용을 중지했으며, 관련 서버를 격리했습니다. 
• 또한 한국인터넷진흥원과 개인정보보호위원회에 유출 사실을 신고했고, 추가 유출 여부 점검과 접근 통제·이상 행위 탐지 체계 강화를 진행 중이라고 밝혔습니다. 
• 이용자에게는 사칭 메일과 계정 탈취 시도에 주의하라고 안내했습니다.

6. 문제점

• 첫째, 기업용 채용 SaaS가 보관하는 기업회원 정보가 외부에 노출되면서, 이메일 주소가 후속 피싱의 출발점이 될 수 있다는 점이 문제로 지적됩니다. 
• 둘째, 기사 기준으로는 사고의 정확한 침입 경로와 취약점이 공개되지 않아 재발 방지 관점의 기술적 투명성이 제한적입니다. 
• 셋째, 지원자 개인정보는 유출되지 않았다고 했지만, 채용 서비스 특성상 민감정보를 다루는 만큼 접근통제와 조회 기능 관리가 더 중요하다는 점이 부각됩니다.

1. 개요

• 사고 대상은 생각하는황소의 입학·편입시험 예약 사이트입니다.
• 학원 측은 2026년 9월 17일 사이트에 해커가 침입한 사실을 확인했습니다.
• 해커가 사이트의 “모든 자료를 확보 중”이라는 취지의 내용을 알린 것으로 확인되어, 시험예약 이력이 있는 학생과 학부모의 개인정보가 유출됐을 가능성이 제기되었습니다.
• 학원은 사고 사실을 관계 기관에 신고했으며, 개인정보보호위원회는 9월 17일 오후 9시쯤 신고를 접수하고 피해 규모 등을 확인하고 있습니다.

2. 피해범위

• 시험예약 사이트를 이용한 이력이 있는 학생과 학부모가 피해 대상일 가능성이 있습니다.
• 학원은 전국 약 80개 지점을 운영하고 있으며, 관련 시험에는 매년 약 1만 명의 초등학생이 응시하는 것으로 소개되었습니다.
• 다만 이 수치는 전체 시험 이용 규모에 대한 설명이며, 이번 사고의 실제 피해자 수를 의미하지는 않습니다.
• 2026년 2월 특정 시험 과정의 응시자가 5,712명이었다지만, 해당 인원이 이번 사고로 피해를 입었다는 내용은 확인되지 않았습니다.
• 정확한 피해자 수와 유출된 레코드 수는 9월 18일 기준 확인되지 않았습니다.
• 개인정보보호위원회가 피해자 규모를 파악 중이라고 설명했습니다.

3. 유출항목

 - 유출 가능 정보는 다음과 같습니다.

• 학생 이름.
• 학생의 학교.
• 학생의 학년.
• 학생의 생년월일.
• 학부모 전화번호 또는 연락처.

 - 개인정보보호위원회 관계자는 성적표와 결제정보 같은 정보는 없는 상황이라고 설명했습니다.

4. 원인

• 현재 확인된 직접적인 원인은 정체불명의 해커가 시험예약 사이트에 침입한 것입니다.
• 해킹에 사용된 취약점, 계정 탈취 여부, 악성코드 사용 여부, 관리자 권한 획득 경로, 내부 시스템으로의 추가 침투 여부는 확인되지 않았습니다.
• 개인정보가 실제로 어느 범위까지 외부로 반출됐는지도 조사가 진행 중입니다.
• 따라서 보안 설정 미흡, 취약한 비밀번호, 소프트웨어 취약점 등 구체적인 원인을 현재 단계에서 단정할 수 없습니다.

5. 대응

 - 학원과 관계 기관의 대응으로 확인된 내용은 다음과 같습니다.

• 시험예약 사이트를 임시 폐쇄했습니다.
• 관계 기관에 개인정보 유출 사실을 신고했습니다.
• 해당 학부모에게 문자메시지로 사고 사실을 안내했습니다.
• 경찰 수사를 요청하기 위한 자료를 준비하고 있습니다.
• 재발 방지를 위한 조치를 완료한 뒤 시험예약 사이트를 다시 운영하겠다고 밝혔습니다.
• 학원은 유출정보가 보이스피싱 등 2차 피해에 악용될 수 있다며, 의심스러운 연락이나 문자메시지에 개인정보를 제공하지 말고 링크를 클릭하지 말라고 안내했습니다.

6. 문제점

• 시험예약 사이트에 학생의 이름·학교·학년·생년월일과 학부모 연락처 등 학생과 보호자를 식별할 수 있는 정보가 함께 저장되어 있었던 것으로 보입니다.
• 이번 사고의 실제 피해자 수와 유출 범위가 신속하게 확정되지 않았습니다.
• 침입 경로와 공격 방식이 공개되지 않아 동일한 취약점이 해소됐는지 외부에서 확인하기 어렵습니다.
• 해킹 사실 확인 후 사이트를 임시 폐쇄하고 재발 방지 조치 후 재개하겠다고 했지만, 구체적인 기술적 조치 내용은 확인되지 않았습니다.
• 학생 정보와 학부모 연락처가 결합될 경우, 학원·시험·자녀 정보를 미끼로 한 보이스피싱이나 스미싱에 악용될 위험이 있습니다.
• 다만 실제 2차 피해가 발생했다는 내용은 확인되지 않았습니다.
• 피해규모, 실제 반출 데이터, 해커의 신원과 목적, 침투 경로 등 핵심 사항은 관계 기관 조사 결과가 나와야 확정될 것으로 보입니다.

◎ 들어가기전에

• 최근 공개된 PEEP는 Chrome과 Microsoft Edge를 원격접근 도구처럼 사용하는 Chromium 기반 포스트 익스플로이테이션 툴킷입니다. 
• 특히 감염 후 TCP 5001과 5002를 이용한 외부 통신, 30초 주기의 평문 HTTP 비콘, Native Messaging 기반 호스트 명령 실행이 함께 관찰되어 브라우저 확장 프로그램을 단순한 편의 기능이 아닌 하나의 공격 표면으로 봐야 합니다.
• 이 글에서는 PEEP의 구조와 주요 기능, 5001·5002 트래픽의 의미, 엔드포인트 및 네트워크 탐지 방법, 사고 대응 절차와 방어 정책을 순서대로 설명하겠습니다.

◎ PEEP의 배경과 개요

• PEEP는 “Smart Bookmarks”라는 이름의 브라우저 확장 프로그램으로 위장하며, Chrome과 Edge에 설치된 뒤 브라우저를 공격자의 지속적인 접근 지점으로 활용합니다. 
• 공개 분석에 따르면 PEEP는 최초 침투 도구라기보다, 공격자가 이미 관리자 권한이나 코드 실행 권한을 확보한 뒤 설치하는 사후 침투형 백도어입니다.
• PEEP는 RedExt라는 브라우저 확장 기반 C2 프레임워크와 기술적 연관성을 보입니다.
• RedExt는 Manifest V3 확장 프로그램과 Flask 기반 C2 서버로 구성된 공개 레드팀 프레임워크이며, PEEP는 여기에 Native Messaging, 지속성, 호스트 명령 실행, 브라우저 데이터 수집 기능을 추가한 운영형 파생 도구로 분석됩니다.
• 따라서 PEEP 감염은 “악성 확장 하나를 삭제하면 끝나는 사건”으로 판단해서는 안 됩니다.
• 확장 프로그램, 브라우저 프로필, Windows 레지스트리, Native Messaging 호스트, C2 통신, 탈취된 세션까지 함께 조사해야 합니다.

◎ 주요 변경 사항과 기술적 특징

• PEEP가 기존 브라우저 악성 확장보다 위험한 이유는 브라우저 내부 데이터 수집을 넘어 운영체제 영역으로 연결된다는 점입니다.

• 위 확장 ID와 파일명은 변종이나 재빌드 과정에서 달라질 수 있으므로, 단일 IOC만으로 탐지를 종료해서는 안 됩니다.
• 특히 공개된 PEEP 소스와 운영 인프라가 노출된 만큼, 동일한 구조를 이용한 변종이나 복제본이 등장할 가능성도 고려해야 합니다.

◎ 브라우저에서 운영체제로 이어지는 구조

• PEEP의 핵심 구성은 브라우저 확장 프로그램과 Native Messaging 호스트의 결합입니다.
• Chrome과 Edge는 확장 프로그램이 로컬 애플리케이션과 통신할 수 있도록 Native Messaging API를 제공합니다.
• 정상적인 비밀번호 관리자, 문서 편집기, 원격지원 프로그램 등도 이 기능을 사용할 수 있지만, PEEP는 이를 악용해 브라우저 샌드박스 밖에서 명령을 수행합니다.
• PEEP는 다음과 같은 등록 정보를 이용하는 것으로 분석되었습니다.

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.peep.lab
HKCU\Software\Microsoft\Edge\NativeMessagingHosts\com.peep.lab

• 이 레지스트리 항목은 Native Messaging 매니페스트 파일의 위치를 가리키며, 확장 프로그램이 연결을 요청하면 nm_host.exe가 실행되는 구조입니다. 
• nm_host.exe는 현재 로그인한 사용자의 권한으로 동작하므로, 그 계정이 접근할 수 있는 파일과 프로세스에 영향을 줄 수 있습니다.

 - 공개 분석에서 확인된 기능은 다음과 같습니다.

• 셸 명령 실행
• 파일 목록 조회, 읽기, 쓰기, 삭제
• 프로세스와 서비스 열거
• 브라우저 탭 및 페이지 정보 수집
• 방문 기록, 북마크, 다운로드 기록 수집
• 쿠키와 활성 세션 정보 탈취
• JavaScript 삽입
• 활성 페이지 캡처
• 브라우저 프록시 설정 변경
• 추가 확장 프로그램 또는 구성요소 업데이트

 - 특히

• 활성 세션 쿠키가 탈취되면 공격자가 사용자의 비밀번호를 직접 확보하지 않아도 이미 로그인된 웹 서비스에 접근할 수 있습니다.
• 이 경우 MFA가 활성화되어 있어도 기존 세션이 재사용될 수 있으므로, 감염이 의심되면 비밀번호 변경뿐 아니라 모든 세션과 토큰을 폐기해야 합니다.

◎ TCP 5001과 5002의 의미

 - TCP 5001: C2 제어 패널과 에이전트 통신

• 공개된 분석에 따르면 PEEP의 C2 서버는 TCP 5001에서 Flask·SQLite 기반 제어 패널을 운영하며, 평문 HTTP를 사용합니다. 
• 공격자는 이 서버를 통해 감염된 에이전트를 관리하고 명령을 전달할 수 있습니다.
• PEEP 에이전트가 사용하는 것으로 분석된 API 경로는 다음과 같습니다.

/api/register
/api/commands
/api/agents/<agent-id>/task_result
/api/exfil
/api/extension_update/
/api/extension_crx/

  > 모든 환경에서 동일한 URL이 유지된다고 단정할 수는 없지만, 방화벽·프록시·NDR 로그에서 다음 패턴을 우선 확인할 수 있습니다.

• 브라우저 프로세스에서 외부 IP의 TCP 5001 연결
• 약 30초 간격으로 반복되는 HTTP 요청
• POST 요청과 응답의 반복
• 브라우저 프로필 정보나 호스트 식별정보가 포함된 요청
• 비표준 HTTP 헤더 또는 장기간 유지되는 동일한 User-Agent
• 업무상 필요하지 않은 외부 서버와의 일정한 비콘

  > PEEP의 비콘은 약 30초 주기로 명령을 확인하고 수집 데이터를 전달하는 것으로 분석되었습니다.

• HTTPS가 아닌 평문 HTTP라면 프록시나 네트워크 센서에서 URI, 헤더, 일부 본문 구조를 직접 확인할 수 있다는 점이 탐지 측면에서는 유리합니다.

 - TCP 5002: 노출된 개발·스테이징 서비스

• TCP 5002는 일반적인 사용자 에이전트 통신 포트라기보다, 특정 PEEP C2 인프라에서 개발 저장소와 빌드 산출물, 로그, 유틸리티 등이 노출된 포트로 관찰되었습니다. 
• 일부 분석에서는 이 위치에 확장 프로그램 소스 코드와 확장 ID에 사용되는 개인 키까지 노출된 것으로 설명합니다.

  > 따라서 5002 outbound 연결은 다음 두 가지 가능성을 모두 고려해야 합니다.

• PEEP 감염 호스트가 공격자의 개발·배포 인프라에 접근하는 경우.
• PEEP 변종 또는 다른 도구가 같은 포트를 이용하는 경우.

  > 즉, “5002 연결 = 반드시 PEEP”라고 단정해서는 안 되지만, 브라우저 프로세스 또는 nm_host.exe가 외부 TCP 5002로 연결하면 고위험 이벤트로 분류해 조사하는 것이 적절합니다.

◎ 네트워크 탐지 방법

• 네트워크 탐지는 IP·도메인 IOC와 행위 기반 탐지를 함께 적용해야 합니다.
• 공개 자료에서 언급된 인프라는 다음과 같습니다.

206.237.30[.]232
xfjcc[.]fun
new.xfjcc[.]fun
newadmin.xfjcc[.]fun
newapi.xfjcc[.]fun

• 이 값들은 공개 분석 시점의 IOC이므로 방화벽, DNS, 프록시, EDR, SIEM에 등록할 수 있지만, 향후 변경될 수 있습니다.

 - 방화벽·프록시 점검 항목

• 외부 TCP 5001 및 TCP 5002 연결
• Chrome 또는 Edge 프로세스의 직접 외부 연결
• 30초 전후의 규칙적인 반복 통신
• 업무상 설명되지 않는 평문 HTTP 통신
• 동일한 외부 IP로 장시간 반복되는 POST 요청
• 브라우저 프로세스에서 발생했지만 일반 웹 브라우징으로 설명되지 않는 URI
• 단말 간 동일 C2 주소와 동일한 시간 간격을 보이는 연결

  > 다음과 같은 개념의 탐지 규칙을 SIEM 또는 NDR에 구현할 수 있습니다.

IF
  process IN (chrome.exe, msedge.exe)
  AND destination_port IN (5001, 5002)
  AND destination NOT IN approved_web_services
THEN
  alert "Possible PEEP browser backdoor communication"

  > 30초 주기 탐지는 고정값 일치보다 일정 시간 창 안의 반복성을 확인하는 방식이 좋습니다.

동일 단말·동일 외부 목적지에 대해
5분 동안 30초 전후 간격의 HTTP 연결이 5회 이상 발생
AND 목적지 포트가 5001 또는 5002
AND 브라우저 프로세스에서 연결 발생

• 단, Chrome과 Edge는 정상적으로 여러 외부 서버에 반복 연결할 수 있으므로 포트, 목적지 평판, 프로세스 트리, 레지스트리 변경 이벤트를 함께 결합해야 오탐을 줄일 수 있습니다.

◎ 엔드포인트와 브라우저 탐지

 - 확장 프로그램 확인

• 관리 대상 단말에서는 Chrome과 Edge의 확장 목록을 수집해 승인된 기준선과 비교해야 합니다. 
• “Smart Bookmarks”라는 이름이나 알려진 확장 ID가 확인되면 우선 조사 대상이지만, 이름과 ID가 변경된 변종도 고려해야 합니다.
• Chrome 사용자는 다음 주소에서 수동 확인할 수 있습니다.

chrome://extensions

• Edge에서는 다음 주소를 사용합니다.

edge://extensions

• 다만 PEEP는 개발자 모드 경고를 피하거나 정책 기반 설치를 악용할 수 있으므로, 브라우저 화면에 보이는 목록만 믿어서는 안 됩니다. 
• 브라우저 정책 레지스트리와 프로필의 Preferences, Secure Preferences, 확장 폴더를 함께 조사해야 합니다.

 - Native Messaging Host 확인

• Windows에서는 다음 경로를 우선 조사합니다.

HKCU\Software\Google\Chrome\NativeMessagingHosts
HKLM\Software\Google\Chrome\NativeMessagingHosts

HKCU\Software\Microsoft\Edge\NativeMessagingHosts
HKLM\Software\Microsoft\Edge\NativeMessagingHosts

• 다음 PowerShell 명령은 관련 레지스트리 경로를 확인하는 예시입니다.

$paths = @(
  "HKCU:\Software\Google\Chrome\NativeMessagingHosts",
  "HKLM:\Software\Google\Chrome\NativeMessagingHosts",
  "HKCU:\Software\Microsoft\Edge\NativeMessagingHosts",
  "HKLM:\Software\Microsoft\Edge\NativeMessagingHosts"
)

foreach ($path in $paths) {
    if (Test-Path $path) {
        Get-ChildItem $path | Select-Object PSPath, PSChildName
    }
}

• 다음 문자열이 존재하면 고위험 IOC로 취급해야 합니다.

com.peep.lab
nm_host.exe

• 그러나 정상적인 Native Messaging 호스트도 존재할 수 있으므로, 발견 즉시 삭제하기보다 서명, 파일 경로, 설치 주체, 해시, 생성 시각, 연결하는 확장 ID를 확인하는 절차가 필요합니다.

 - 프로세스 관계 탐지

• 정상적인 브라우저도 여러 하위 프로세스를 생성하지만, nm_host.exe 또는 출처가 불명확한 실행 파일이 Chrome·Edge와 함께 동작하는 것은 중요합니다.

  > 탐지 기준은 다음과 같습니다.

• chrome.exe 또는 msedge.exe가 nm_host.exe를 실행
• 브라우저 프로세스가 PowerShell, cmd, wscript, cscript를 생성
• 브라우저 프로필 파일을 PowerShell이나 비정상 프로세스가 수정
• 브라우저 프로세스가 파일 검색·압축·삭제 명령과 연결
• 브라우저 프로세스 트리에서 외부 C2 연결과 명령 실행이 동시에 발생

  > 예시적인 EDR 상관 조건은 다음과 같습니다.

Browser process
  -> nm_host.exe
  -> powershell.exe or cmd.exe
  -> file access / registry modification / network connection

• 브라우저에서 직접 셸 명령을 실행하는 흐름은 업무용 확장 프로그램에서도 드물기 때문에, 고위험 탐지 규칙으로 운영할 수 있습니다.

 - Secure Preferences 변조 확인

• PEEP는 Chromium의 확장 무결성 검사를 우회하기 위해 Secure Preferences 파일의 무결성 값을 조작하는 것으로 분석되었습니다. 
• 따라서 브라우저가 정상적으로 실행된다는 사실만으로 확장의 무결성을 신뢰해서는 안 됩니다.

  > 다음 이벤트를 모니터링하십시오.

• 브라우저 외 프로세스의 Secure Preferences 쓰기
• PowerShell, cmd, Python, 임시 실행 파일의 브라우저 프로필 수정
• protection.macs, super_mac 관련 변경
• 확장 설치 시점과 무관한 프로필 파일 수정
• 프로필 내 새로운 확장 디렉터리 생성
• LocalAppData\PEEP와 유사한 신규 경로 생성

◎ 사고 대응 절차

• PEEP가 의심되면 먼저 네트워크와 세션을 차단한 뒤 증거를 보존해야 합니다.

1단계: 격리

• EDR의 네트워크 격리 기능으로 단말 격리
• 단말의 외부 5001·5002 통신 차단
• 감염 단말에서 업무용 SaaS와 관리자 계정 접근 중지
• 단순히 브라우저만 종료하지 말고 프로세스·예약 작업·정책을 함께 확인

2단계: 증거 보존

• 다음 정보를 삭제 전에 수집합니다.
• 현재 네트워크 연결과 DNS 캐시
• Chrome·Edge 확장 목록
• Native Messaging 레지스트리
• nm_host.exe 파일과 해시
• 브라우저 프로필의 Preferences, Secure Preferences
• EDR 프로세스 트리
• 프록시·방화벽·DNS·웹 게이트웨이 로그
• 브라우저 쿠키와 세션 탈취 가능성을 보여주는 감사 로그

3단계: 지속성 제거

• 조사 결과가 확인된 뒤에는 다음 항목을 제거합니다.
• 비인가 확장 프로그램
• com.peep.lab Native Messaging 등록
• nm_host.exe 및 관련 실행 파일
• 확장 강제 설치 정책
• 브라우저 프로필 내 잔여 확장 디렉터
• LocalAppData\PEEP와 같은 스테이징 경로
• 예약 작업, 시작 프로그램, 임시 스크립트
• 공격자가 추가한 프록시 설정

 - 브라우저 UI에서 확장만 제거하는 방식은 충분하지 않습니다. Native Messaging 등록이나 강제 설치 정책이 남아 있으면 재설치될 수 있기 때문입니다.

4단계: 세션과 계정 보호

 - PEEP는 활성 세션 쿠키를 노릴 수 있으므로 다음 조치를 수행해야 합니다.

• 감염 단말에서 사용한 계정의 모든 세션 강제 종료
• 이메일, VPN, 클라우드, 관리자 계정의 토큰 폐기
• 중요 계정 비밀번호 재설정
• FIDO2 또는 WebAuthn 기반 피싱 방지 MFA 적용
• 의심 기간의 로그인·토큰 사용 기록 확인

 - 동일 세션에서 수행된 파일 다운로드, 메일 전달 규칙, OAuth 앱 승인 점검

비밀번호를 변경하는 것만으로는 이미 탈취된 세션 토큰을 무효화하지 못할 수 있으므로, 서비스별 세션 폐기 절차를 함께 수행해야 합니다.

◎ 방어 정책과 예방 조치

 - 확장 프로그램 허용 목록 운영

• Chrome Enterprise 정책의 ExtensionInstallForcelist는 지정된 확장 프로그램을 사용자 개입 없이 설치하는 기능이며, 사용자가 브라우저에서 제거하거나 비활성화하기 어렵게 만들 수 있습니다. 
• 공격자가 이 정책을 악용할 수 있으므로 정책 변경 자체를 감사해야 합니다.

  > 권장 정책은 다음과 같습니다.

• 기본적으로 확장 설치 차단
• 업무상 필요한 확장만 허용 목록 등록
• 허용 목록 변경 시 승인 절차 적용
• ExtensionInstallForcelist와 ExtensionSettings 변경 감사
• 개발자 모드와 외부 사이드로딩 제한
• 승인되지 않은 확장 설치 시 EDR 알림
• 확장 ID, 게시자, 버전, 업데이트 URL 기준선 관리

 - Native Messaging 최소화

  > Native Messaging은 필요한 프로그램만 허용해야 합니다.

• NativeMessagingAllowlist 사용
• NativeMessagingBlocklist와 허용 목록 병행
• 사용자 수준 Native Messaging Host 등록 제한 검토
• Native Messaging 매니페스트의 실행 파일 경로와 서명 검증
• 새 레지스트리 등록을 SIEM에 전송
• 브라우저에서 Native Host로 이어지는 프로세스 관계 감시

  > 정상적인 Native Messaging 프로그램이 있는 조직에서는 무조건 전체 차단하기보다 승인된 호스트만 허용하는 방식이 현실적입니다.

 - 네트워크 이그레스 통제

• 외부 TCP 5001·5002 기본 차단
• 업무상 필요한 경우 목적지와 프로세스 기준으로 제한
• 평문 HTTP 외부 통신 감시
• 브라우저의 직접 인터넷 연결을 프록시 정책으로 통제
• DNS 보안과 신규 도메인 평판 검사 적용
• 30초 주기 비콘 탐지
• IP·도메인 IOC를 방화벽, DNS, EDR, SIEM에 동시 반영

  > IP 차단만으로는 새로운 C2를 사용하는 변종을 막기 어렵습니다.

• 따라서 알려진 IOC 차단과 함께 주기성, 포트, 프로세스, 요청 패턴을 결합해야 합니다.

◎ MITRE ATT&CK 관점

 - PEEP는 다음 ATT&CK 기술과 연관해 분석할 수 있습니다.

 - 이 매핑은 단순 분류보다 탐지 설계에 유용합니다.

• 예를 들어 T1176만 감시하면 확장 설치만 확인하게 되지만, T1176·T1112·T1057·T1071을 결합하면 “확장 설치 → 레지스트리 지속성 → 프로세스 탐색 → C2 비콘”이라는 공격 흐름을 식별할 수 있습니다.

◎ 마무리

• PEEP의 핵심 위험은 브라우저 확장 프로그램이 브라우저 안에 머무르지 않고 Native Messaging을 통해 운영체제 명령 실행으로 이어진다는 점입니다. 
• 특히 외부 TCP 5001·5002 통신, 30초 주기의 평문 HTTP 비콘, com.peep.lab, nm_host.exe, 확장 강제 설치 정책, Secure Preferences 변조를 함께 확인해야 정확한 판단이 가능합니다.

 - 방어의 우선순위는 다음과 같습니다.

• 외부 TCP 5001·5002와 알려진 C2 차단
• 30초 주기 브라우저 HTTP 비콘 탐지
• Chrome·Edge 확장 허용 목록 운영
• Native Messaging Host 등록과 브라우저 자식 프로세스 감시
• Secure Preferences 및 확장 강제 설치 정책 변경 감사
• 감염 시 브라우저 확장뿐 아니라 호스트와 세션 전체를 조사
• 쿠키·토큰 폐기와 피싱 방지 MFA 적용

 - PEEP는 특정 확장 ID나 IP 하나만 차단하는 방식보다, 브라우저 행위·Native Messaging·레지스트리·네트워크 주기성·세션 보호를 결합한 탐지 체계가 효과적인 사례입니다.

1. 개요

• 온라인 강의 플랫폼 라이브클래스를 운영하는 주식회사 퓨쳐스콜레는 2026년 9월 15일 자체 보안 점검 과정에서 수강생 정보 조회 기능에 대한 외부의 무단 접근을 확인했고, 이로 인해 회원 개인정보가 유출됐다고 판단해 관계당국에 신고하고 이용자에게 안내·사과 메일을 발송했습니다.

2. 피해범위

• 라이브클래스의 누적 수강신청 수가 821,970명이라고하나, 이는 서비스 전체 누적 수치이며 실제 유출 피해 인원은 기사에서 명시되지 않았습니다.
• 따라서 피해범위(유출된 고유 이용자 수)는 확인되지 않음으로 보는 것이 적절합니다.

3. 유출항목

 - 기업 공지 및 기사에 따르면 유출된 개인정보 항목은 다음과 같습니다.

• 이름
• 수강신청자명
• 이메일주소
• 휴대전화번호
• 프로필 이미지 주소
• 서비스 내부 식별번호

 - 반면 카드·계좌번호 등 결제정보와 비밀번호 등 로그인 관련 정보는 유출되지 않은 것으로 확인됐다고 반복해 안내했습니다.

4. 원인

• 외부의 악의적인 공격으로 수강생 정보 조회 기능에 무단 접근이 발생한 것을 원인으로 제시하고 있습니다.
• 다만 구체적인 침투 경로(예: 계정 탈취, 취약점 악용 등)나 기술적 세부사항은 공개되지 않아 확인되지 않았습니다.

5. 대응

 - 퓨쳐스콜레는 유출 확인 후 다음과 같은 조치를 시행했다고 안내했습니다.

• 무단 조회에 사용된 계정 정지
• 수강생 정보 조회 기능의 접근 권한 검증 강화 및 서비스 반영
• 관련 조회 기능 점검과 보안 보완
• 관계당국에 유출 신고 완료
• 경찰청 사이버수사대 신고 진행 중

 - 또한 이용자에게 사칭 전화·문자·이메일 주의, 출처 불분명 링크·첨부파일 미클릭, 개인정보·인증번호·송금 요구 응대 금지 등 2차 피해 예방 수칙을 안내하고, 문의·피해 접수 창구(고객성공팀 전화·이메일·채팅)와 개인정보침해신고센터·개인정보분쟁조정위원회 등 권리구제 경로를 함께 제시했습니다.

6. 문제점

 - 현재 공개된 정보를 기준으로 볼 때 다음과 같은 한계가 있습니다.

• 유출 시점이 9월 11일과 14일로 복수로 제시됐으나, 두 날짜가 각각 어떤 의미(첫 접근·추가 접근 등)인지는 명확히 설명되지 않았습니다.
• 피해 규모(유출된 고유 이용자 수)가 공개되지 않아 피해 영향 평가가 어렵습니다.
• 외부 공격의 구체적 방법과 보안 취약점이 공개되지 않아 재발 방지 관점의 교훈 도출이 제한적입니다.

1. 개요

• 카카오게임즈는 2026년 9월 12일 22시 44분경 ‘파트너스’와 ‘RINK’ 서비스에 대한 외부의 비정상적 접근을 처음 인지했고, 내부 조사 결과 9월 14일 00시 50분 일부 고객 140명의 개인정보가 외부로 유출된 사실을 확인했다고 공지했습니다.
• 공격은 9월 12일 22시 44분부터 9월 13일 19시 37분 사이 진행된 것으로 추정되며, 외부 공격자가 두 서비스 시스템의 취약점을 이용해 비인가 접근한 것으로 파악되었습니다.
• 카카오게임즈는 이상 징후 확인 직후 접근 경로를 차단하고 개인정보보호위원회 등 관계기관에 신고했으며, 외부 보안 전문기관과 함께 원인과 피해 범위를 조사 중이라고 밝혔습니다.

2. 피해범위

• 유출 피해가 확인된 이용자는 총 140명이며, 대상은 ‘파트너스’와 ‘RINK’ 서비스 이용자입니다.
• 추가 피해 규모에 대한 다른 수치는 확인되지 않았습니다.

3. 유출항목

• 파트너스: 외부 연동용 타사 식별코드 또는 타사 아이디가 유출된 것으로 확인되었습니다.
• RINK: 카카오게임즈 자사 식별코드(내부 식별값/PID 등) 와 일부 국가코드가 유출된 것으로 확인되었습니다.
• 이름, 주소, 성별, 연락처, 비밀번호 등 중요도가 높은 개인정보는 유출되지 않은 것으로 확인되었다고 회사 측은 설명했습니다.

4. 원인

• 외부 공격자가 ‘파트너스’와 ‘RINK’ 시스템의 취약점을 이용해 비정상적으로 접근한 것으로 확인되었습니다.
• 구체적인 취약점 유형(예: 웹 취약점, 인증·인가 로직 문제 등) 에 대해서는 공개된되지 않아 확인되지 않았습니다.

5. 대응

• 이상 징후 인지 즉시 비정상 접근 경로를 차단하고 관련 시스템을 점검했습니다.
• 개인정보보호위원회 등 관계기관에 신고하고, 외부 보안 전문기관과 함께 사고 원인과 정확한 피해 범위 조사를 진행 중이라고 밝혔습니다.
• 홈페이지를 통해 이용자에게 유출 사실과 예방 조치 안내 공지를 게시하고, 재발 방지를 위한 추가 보호조치와 대책 마련을 약속했습니다.

6. 문제점

• 시스템 취약점을 통한 비인가 접근이 발생한 점, 그리고 유출 사실이 인지된 시점(9월 12일 22시 44분) 과 유출 확인 시점(9월 14일 00시 50분) 사이에 시간 차이가 발생한 점은 직접적인 “문제점”으로 규정되지는 않았으나, 침해 탐지·대응 프로세스와 취약점 관리 측면에서 점검이 필요한 사안으로 해석됩니다.
• 유출 항목이 식별코드 위주라 악용 위험은 낮다고 설명되었으나, 식별코드만으로도 일부 서비스 연동·추적 등에 활용될 수 있다는 점은 명시적으로 논의되지는 않아 확인되지 않았습니다.