月光愛靑狼

1. 개요

• 한국정보보호산업협회(KISIA)는 2025년 1월 2일 뉴스레터 발송 과정에서 수신자 이메일 주소 10,592건이 유출되는 사고를 겪었습니다.
• 해당 오류는 발송 시스템에서 수신자 주소 분리 설정이 적용되지 않아 발생했으며, 유출 사실을 확인한 협회는 즉시 메일 서버를 강제 중단하고 발송 프로그램을 교체하는 등 긴급 조치를 실시했습니다.

2. 피해범위

• 총 10,592건의 이메일 주소가 노출되었으며, 피해 대상은 KISIA 뉴스레터 구독자로 국내 보안 기업 관계자 및 공공기관 담당자가 다수를 차지했습니다.
• 이메일 유출로 인한 스팸 메일 증가 및 협회 사칭 피싱 공격 등 2차 피해 우려가 제기되었습니다.

3. 유출항목

• 유출된 개인정보는 구독자 이메일 주소로 한정되었습니다.
• 다만, 수신자 정보가 공개적으로 노출되어 악성 메일 발송 또는 신뢰성 기반의 표적형 공격으로 악용될 가능성이 있습니다.

4. 원인

• 사고 원인은 휴먼 에러로 확인되었습니다.
• 뉴스레터 발송 담당자가 수신자 주소 분리 설정을 적용하지 않은 채 메일을 발송하는 과정에서 기술적 오류가 발생했으며, 이는 내부 관리 및 확인 절차 미흡에서 비롯된 것으로 판단되었습니다.

5. 대응

• KISIA는 사고 발생 직후 메일 서버를 강제 중단하고 발송 프로그램을 교체했습니다.
• 구독자에게는 유출 사실을 공지하며 해당 메일 삭제를 요청했고, 향후 발송 절차 강화를 약속했습니다.
• 또한 내부 직원 교육 강화 및 시스템 점검을 통해 재발 방지에 나섰습니다.

6. 문제점

• 보안 전문기관의 관리 소홀: 정보보호 산업을 주도하는 협회에서 기본적인 발송 절차 검증이 이뤄지지 않아 신뢰성 추락이 발생했습니다.
• 2차 피해 리스크 대응 미비: 유출된 이메일 주소가 보안 전문가를 대상으로 한 점을 고려할 때, 표적형 피싱 공격 등 고위험 상황에 대한 선제적 대응이 부족했습니다.
• 인적 요인 통제 실패: 시스템 오류가 아닌 인력 과실로 사고가 발생하며, 내부 프로세스 개선 필요성이 드러났습니다.
• KISIA는 사과문을 발표하고 보안 체계 강화를 약속했으나, 정보보호 기관으로서의 책임성 강화가 요구되는 상황입니다.

1. 개요

• 2025년 1월 1일, 하이트진로는 랜섬웨어 공격을 받아 고객 개인정보 유출이 의심되는 사고를 겪었습니다.
• 해당 공격으로 암호화된 정보가 외부로 유출된 정황이 확인되었으며, 회사는 즉시 관련 기관에 신고하고 시스템 정상화 조치를 진행했습니다.

2. 피해범위

• 유출 규모는 정확히 파악되지 않았으나, 마케팅 활동을 통해 수집된 고객 데이터베이스가 주요 타겟이었습니다. 
• 하이트진로 측은 "암호화된 정보라 실질적 피해 가능성은 낮다"고 밝혔으나, 보안 전문가들은 해독 가능성을 경고했습니다.

3. 유출항목

• 성명, 전화번호, 이메일, 주소, 생년월일 등 5개 항목의 개인정보가 유출되었습니다.
• 해당 정보는 피싱 및 스미싱 등 2차 피해로 악용될 우려가 있습니다.

4. 원인

• 공격 경로는 정확히 밝혀지지 않았으나, 랜섬웨어 감염 경로로는 악성 링크 클릭 또는 취약점 공격이 추정됩니다.
• 최근 랜섬웨어 조직의 공격 방식이 고도화되어 정보 유출을 병행하는 특징을 보였습니다.

5. 대응

• 하이트진로는 사고 발생 직후 고객에게 사전 안내하고 비밀번호 변경을 권고했습니다.
• 또한 의심 파일 삭제 및 시스템 복구를 완료했으며, 경찰과 한국인터넷진흥원(KISA)과 협조해 조사 중입니다.

6. 문제점

• 암호화된 정보의 잠재적 위험: 오래된 암호화 솔루션 사용으로 해독 가능성이 제기되었습니다.
• 2차 피해 우려: 유출된 정보를 활용한 피싱, 신분 도용 등 추가 범죄 발생 가능성이 있습니다.
• 기업 보안 투자 부족: 공공·제조 분야의 보안 취약점이 노출되며, 이는 관련 기업들의 대책 마련 필요성을 시사합니다.
• 하이트진로는 향후 보안 체계 강화와 지속적 모니터링을 약속하며, 고객들에게 각종 사기 수단에 대한 주의를 당부했습니다.

Ubuntu를 처음 설치하면 SSH 서버가 자동으로 설치되어 있지 않습니다. 이 글에서는 그 이유와 함께, OpenSSH 서버 설치 및 구성, 설정 파일 백업 방법, 그리고 과거의 SSH 키 재사용 해킹 이슈를 방지하기 위한 안전한 키 관리 방법까지 단계별로 안내합니다.

1. Ubuntu에서 SSH 서버가 기본 설치되지 않는 이유
 - 보안 강화
  > SSH 서버는 원격 접속을 허용하는 서비스입니다. 설치 직후 자동으로 활성화되어 있으면, 네트워크에 연결된 모든 장치에서 접속 시도가 가능해져 불필요한 보안 위협(예: 무차별 대입 공격)에 노출될 수 있습니다. 이를 방지하기 위해 Ubuntu는 SSH 서버를 기본으로 설치하지 않습니다.
 - 필요한 사용자만 설치
  > 모든 사용자가 원격 접속 기능을 필요로 하는 것은 아니기 때문에, 필요할 때만 사용자가 직접 설치하도록 설계되어 있습니다.

2. OpenSSH 서버 설치 및 활성화
 - Step 1. 터미널 열기
  > 단축키: Ctrl + Alt + T
  > 또는 앱 메뉴에서 "Terminal" 검색 후 실행
 - Step 2. 패키지 목록 업데이트

 - Step 3. OpenSSH 서버 설치

또는

 - Step 4. SSH 서비스 시작 및 자동 실행 설정

  > 서비스 상태 확인:

  > Active: active (running)이 표시되면 정상 실행 중입니다.

 - Step 5. 방화벽(ufw) 설정 (선택 사항)

  > 방화벽을 사용 중이라면 SSH 포트(기본 22번)를 허용해야 합니다.

  > 직접 포트를 변경했다면, 해당 포트 번호로 허용해야 합니다.

3. OpenSSH 설정 파일 백업 방법
 - 설정 변경 전에는 항상 백업을 권장합니다.
 - 설정 파일 백업

  > /etc/ssh/sshd_config.factory-defaults 파일은 읽기 전용으로 만들어 두면, 언제든지 원본 설정을 복원할 수 있습니다.

 - 복원 방법

4. OpenSSH 주요 보안 설정 및 구성 방법
 - 설정 파일을 편집하여 보안을 강화할 수 있습니다.
 - 설정 파일 열기

 - 주요 설정 항목
  > 포트 변경 (예: 2222)

  > 루트 로그인 금지

  > 비밀번호 인증 비활성화 (키 인증만 허용)

  > 인증 실패 횟수 제한

  > 특정 사용자만 허용

  > 강력한 암호화 알고리즘 지정

 - 설정 적용

5. SSH 키 관리 및 과거 해킹 이슈 방지 방법
 - 과거에 동일한 SSH 키 쌍이 여러 시스템에서 재사용되어 해킹되는 사례가 있었습니다. 이를 방지하려면 다음과 같은 방법을 적용해야 합니다.
 - 각 시스템마다 고유한 SSH 키 쌍 생성

(각 서버/사용자별로 별도의 키 쌍을 생성하고, 동일한 키를 여러 곳에 재사용하지 않습니다).

 - 키 주기적 교체(로테이션) 및 관리
  > 일정 주기로 SSH 키를 변경하고, 더 이상 사용하지 않는 키는 authorized_keys에서 삭제합니다.
  > 조직에서는 중앙 집중식 SSH 키 관리 솔루션을 사용하는 것이 좋습니다.
 - 키 백업 및 보안 저장
  > SSH 키(특히 private key)는 안전한 위치에 암호화하여 백업합니다.
  > 백업 파일 접근 권한을 제한하고, 필요시만 복원합니다.
 - 비밀번호 인증 비활성화
  > 키 인증만 허용하여 무차별 대입 공격 위험을 줄입니다.
 - 2단계 인증(2FA) 적용
  > Google Authenticator, Duo Security 등과 연동하여 추가 인증 절차를 적용합니다.

6. 자동화된 백업에 OpenSSH 활용
 - OpenSSH 키 인증을 활용하면 rsync, tar, dump 등과 연동해 안전하게 자동 백업을 할 수 있습니다. 예시:
 - 원격 서버에서 로컬로 백업:

 - 로컬에서 원격으로 백업:

(sudo 비밀번호 프롬프트가 보이지 않을 수 있으니 주의).

정리
Ubuntu는 보안을 위해 SSH 서버를 기본 설치하지 않습니다. OpenSSH 서버 설치 후에는 반드시 설정 파일을 백업하고, 포트 변경, 루트 로그인 금지, 키 인증 사용, 2FA 적용 등 다양한 보안 설정을 적용해야 합니다. 과거의 SSH 키 재사용 해킹 이슈를 방지하려면 각 시스템별로 고유한 키를 사용하고, 주기적으로 키를 교체하며, 키를 안전하게 백업·관리해야 합니다. OpenSSH의 키 인증 기능을 활용하면 안전하고 효율적으로 자동화된 백업도 구현할 수 있습니다

1. 개요

• 여러 보험사 상품을 판매하는 하나금융지주 GA (보험대리점) 하나금융파인드와 대형 GA 유퍼스트 보험대리점 2곳에서 해킹 사고가 발생. 금융당국과 금융보안원이 현황 파악 시작.
• 보험대리점(GA) 솔루션 제공업체 지넥슨 플랫폼 프로그램에 악성코드가 감염되어 GA 시스템에 해킹이 발생한 것으로 추정.
• 현재 보험계약자의 개인정보 유출 여부는 추가 조사가 필요하며, 개인정보 유출 시 대규모 유출로 이어질 수 있음.

2. 내용

• 해커가 GA 관리 시스템에 접근할 수 있는 관리자 계정 정보를 확보한 후, 다크웹과 비공개 텔레그램 채널을 통해 이를 유포하였습니다. 실제로 7개 GA의 접속 주소와 공용 계정 정보가 노출되었으며 그 중 2개 GA에서 로그인 시도 발생하였습니다.
• 해커는 A사의 프로그램을 통해 GA 시스템에 접근한 것뿐만 아니라, 한 프로그램 개발자의 개인 PC에 악성코드를 심어 관리자 패스워드를 훔쳤고, 이를 통해 시스템에 접근한 정황이 발견되었습니다.
• 금융보안원, 금융감독원(FSS) 한국인터넷진흥원(KISA) 등이 포렌식 분석을 진행 중이며 결과는 약 4주 후에 나올 예정입니다.
• GA 전산망이 보험사 시스템과 연계되어 있어 해킹이 확산될 경우 보험사 내부망에 영향을 미칠 수 있기때문에 보험사들은 자체 보안 점검을 강화하고, GA 파트너사와의 연결 시스템에 대한 재검토를 시작하였습니다.
• 국정원이 지난 4월 다크웹에서 신원 미상의 해커가 GA의 개인정보를 탈취·공개하려는 정황을 확인하면서 2개 GA의 해킹 정황이 최초로 인지되었습니다.
• 금융보안원이 GA 및 보험영업 지원 IT업체를 조사·분석한 결과 해당 IT업체 개발자가 해외의 이미지 공유사이트를 이용하는 과정에서 악성코드 링크를 클릭했고, 이 때문에 개발자 PC가 악성코드에 감염된 것으로 확인되었습니다.
• 해당 개발자 PC에는 고객사인 GA의 웹서버 접근 URL과 관리자 ID·비밀번호가 저장돼 있어 이 PC에 저장돼 있던 GA 14개사의 웹서버 접근 URL과 관리자 ID·비밀번호가 유출된 것으로 추정됩니다.

3. 대응

• 사고 직후 A사 프로그램 관리업체는 외부 보안 전문기관과 협력하여 긴급 점검을 진행하였습니다. 공용 관리자 계정을 전면 폐지하고, 담당자별 개인 계정으로 전환했으며 2차 인증, 로그 기록 강화, 파일 다운로드 통제 등 보안 강화 조치가 이뤄졌습니다.
• 금융당국은 GA 전산망에 대한 점검을 강화하며, GA들이 보유한 민감한 개인정보 유출 여부를 파악 중입니다. 유출이 확인될 경우, 관련된 보험계약자에게 신속히 통지할 계획입니다.
• GA와 보험사에 보안 취약점 점검을 요청하고, 불필요한 고객정보 삭제 및 보안 취약점 점검을 강화하도록 요구하였습니다.
• 정보 유출이 발생할 경우, 금감원은 2차 피해 신고 및 관련 제도 안내를 위한 종합상담센터를 설치하여 보험소비자 피해를 최소화할 방안을 마련하고 있습니다.
• 금감원은 "12개사의 유출량은 매우 적은 것으로 추정되나 정확한 실태파악을 위해 금융보안원을 통해 추가 검증을 실시할 예정"이라며 "해당 IT업체의 서비스를 사용 중인 다른 GA 43개사에 대해서도 이상 IP 접속 확인이 필요하다"고 설명했습니다.

4. 문제점

• GA와 보험사들이 외부 프로그램에 의존하는 경우가 많아 보안 관리가 취약하다는 지적이 있으며 일부 보험사나 지주사는 사전 조치를 취했지만, 대부분의 회사는 보안에 취약한 상태입니다.
• 최근 해킹 시도가 소규모 금융회사와 자산운용사를 대상으로 증가하고 있으며, 이에 대한 추가적인 대응이 필요하다는 지적이 나오고 있습니다.
• 일부 신용정보를 포함해 고객 및 임직원 1천여명의 개인정보가 유출된 것으로 확인되었습니다.
  - 대형 GA인 유퍼스트보험마케팅에서는 고객 349명의 성명·주민등록번호·전화번호 등이, 임직원·설계사 559명의 성명·전화번호 등이 유출됐다. 일부 고객정보(128명)의 경우 가입한 보험계약의 종류, 보험사 증권번호, 보험료 등 보험가입 내용을 판단할 수 있는 신용정보도 포함된 것으로 확인되었습니다.
  - 하나금융파인드에서는 고객 199명의 개인정보가 유출됐으나 고객의 보험계약에 관한 거래정보 등의 유출은 없었던 것으로 파악되었습니다.
  - 해당 IT업체의 고객사인 나머지 12개사에 대해서도 로그기록을 분석한 결과 1개사에서 개인정보 유출 정황이 확인됐고, 2개사에서는 침해 정황이 확인됐으나 개인정보 유출 정황은 없는 것으로 파악되었습니다.

5. 기타

• GA ERP 시스템을 제공하는 지넥슨의 대표 인터뷰가 기사에 실린것으로 보아 이번 사고와는 관련이 없는 것으로 보입니다?????

2025.07.04 민관합동조사단, SK텔레콤 침해사고 최종 조사결과 발표

 
1. 개요 

• 국내 대표 이동통신사업자 가운데 하나인 SK텔레콤(SKT)에서 고객 유심(USIM) 정보 유출사고 발생

2. 타임라인

3. 요약

• 2025년 4월 18일, SK텔레콤(SKT)은 외부로의 가입자인증서버(HSS)와 과금정보관리서버(WCDR) 사이 이상 트래픽 증가를 감지하였습니다. 하며 잠재적 사이버 위협을 인지했습니다. 이는 APT(Advanced Persistent Threat)의 목표달성(데이터 유출) 단계로 초기 징후로 보입니다.

※ APT 공격은 대체로 아래와 같이 7단계에 걸쳐 체계적으로 수행됩니다.
초기침투 > 거점확보 > 권한상승 > 내부정찰 > 내부이동 > 지속실행 > 목표달성

• 4월 19일 오후 11시에 과금정보관리서버(WCDR)에서 악성코드 감염 및 가입자인증서버(HSS: Home Subscriber Server)에서 유심(USIM) 정보 유출이 확인되었습니다.
• 유출된 데이터는 9.82기가바이트(가입자당 유심(USIM) 관련 정보는 100~300 킬로바이트(Kbyte) 수준)에 이르고 전화번호, 유심(USIM) 인증 코드(Ki), 이동가입자식별번호(IMSI, International Mobile Subscriber Identity), 단말기고유식별번호(IMEI, International Mobile Equipment Identity) 총 2695만 7749건을 포함(SKT 가입자(알뜰폰 포함) 총숫자인 2천500만여 명보다 조금 많지만, 사물인터넷(IoT) 회선 등이 합쳐진 숫자로 추정됩니다.)하며, 1차 보고 당시 이름, 주민등록번호 등 민감한 정보는 유출되지 않았다고 밝혔습니다.

※ 조사 초기 IMEI가 저장된 서버 38대를 점검했을 당시에는 악성코드 감염이 확인되지 않아 유출 가능성을 배제했지만, 이후 진행된 전수조사에서 IMEI가 서비스 중 임시로 저장된 서버들이 추가로 발견됐습니다.

• 현재까지 2차 피해는 보고되지 않았습니다. 으나, 신원 도용, 복제폰 제조, SIM 스와핑 등의 위험이 존재합니다.
• SKT는 사고 발견 즉시 악성 코드를 삭제하고 서버를 격리했으며, 4월 20일 한국인터넷진흥원(KISA)에 신고하고, 4월 22일 개인정보보호위원회에 보고하면서 경찰 수사를 요청했습니다.
• 서울지방경찰청 사이버수사대는 4월 23일부터 수사에 착수했으며, 해커의 신원과 침투 경로를 조사 중입니다. SKT는 고객 보호를 위해 무료 유심(USIM) 보호 서비스 가입을 권고하고, 불법 유심(USIM) 기기 변경 및 비정상 인증 시도를 실시간으로 차단하는 시스템(FDS, Fraud Detection System) 정책을 최고 수준으로 격상해 운영하고 있습니다.
• 그러나 4월 18일 밤 해킹 공격을 받은 사실을 최초로 확인했음에도 관계기관에 '사고 인지 24시간 이내' 신고해야 한다는 규정 위반 논란이 발생했습니다.
• 5월 19일 개인정보보호위원회는 SKT 개인정보 유출 건 조사 과정에서 기존 유출경로로 확인된 가입자인증서버(HSS) 등 5대 외에도, 통합고객시스템(ICAS) 서버 2대를 포함 총 18대 서버에 악성코드가 추가 감염된 것을 확인했다고 밝혔습니다.

※ ICAS(Integrated Customer Authentication System)는 티월드 등 SKT 내부 시스템과 사전 인가된 협력사를 대상으로 가입자의 가입 상태, 개인정보 및 가입 상품 정보를 조회할 수 있는 애플리케이션 프로그래밍 인터페이스(API)를 제공하는 시스템입니다.

• 해당 서버에는 이름, 생년월일, 휴대전화 번호, 이메일, 주소, 단말식별번호(IMEI) 29만 1천831건, 가입자식별번호(IMSI) 등 고객의 중요 개인정보를 포함해 총 238개 정보(칼럼값 기준)가 암호화되지 않은 상태로 저장돼 있으며, 개인정보위는 악성코드에 최초 감염된 시점이 오래된 점을 고려해 감염경위, 유출정황 등을 면밀히 조사하고 있다고 설명했습니다.
• 서버에 저장된 29만 1천831건의 IMEI는 지난해 12월 3일부터 올해 4월 24일까지는 유출되지 않은 것으로 확인됐지만, 최초로 악성코드가 설치된 시점인 2022년 6월 15일부터 2024년 12월 2일까지는 로그기록이 남아있지 않아 유출 여부가 불확실하다고 합니다.

※ 정보통신망법은 정보통신서비스 제공자가 침해사고가 발생한 것을 알게 된 때로부터 24시간 이내에 침해사고의 발생 일시, 원인 및 피해 내용 등을 과학기술정보통신부장관이나 한국인터넷진흥원(KISA)에 신고해야 한다고 규정하고 있습니다.
※ 개인정보보호법은 1천 명 이상의 민감정보 또는 고유식별정보가 유출됐을 경우 72시간(2일) 이내 개인정보보호위원회나 한국인터넷진흥원(KISA)에 신고해야 한다고 규정하고 있습니다.

4. 공격 정보

• 피해 대상:
  2025.04.25 : 3종, 5대 서버
  2025.05.19 : 25종(BPFDoor계열 24종+웹셸 1종)
  2025.06.17: 7종 추가발견, 총 32종
• 해킹 목적: 전문가들과 민관합동 조사단이 특정 국가의 정보전 차원 해킹으로 잠정 결론을 내렸습니다.
• 해킹 원인: 통상 가입자 정보를 관리하는 네트워크는 방화벽을 두고 외부 인터넷프로토콜(IP)에서 접속이 불가능한 구조로 설계되어 이론상 해킹이 불가하지만, 불가피하게 외부 인터넷망과 연결된 과금정보관리서버(WCDR)를 통해 가입자인증서버(HSS)로 침투하여 유심(USIM) 관련 데이터가 유출되었습니다. 2차 발표에 따르면 웹셸 이후 BPF도어(BPFDoor) 악성코드가 설치됐다고 합니다.
• 유출 경로: 가입자인증서버(HSS)에 있던 정보가 과금정보관리서버(WCDR)를 통해 싱가포르 IP로 넘어간 흔적이 있었다고 합니다.
• 유출 정보: 가입자 전화번호, 이동가입자식별번호(IMSI) 등 유심(USIM) 복제에 활용될 수 있는 4종과 유심(USIM) 정보 처리 등에 필요한 SKT 관리용 정보 21종 등(여기에 단말기고유식별번호(IMEI) 정보는 없었다는 게 과학기술정보통신부의 설명)입니다. 5월 19일 민관합동조사단 2차 발표에 따르면 감염이 확인된 서버 중 2대는 통합고객인증 서버와 연동되는 기기들로 고객 인증을 목적으로 호출된 단말기 고유식별번호(IMEI)와 개인정보가 일정 기간 임시로 관리되는 서버로 밝혀졌습니다. 개인정보는 이름, 생년월일, 전화번호, 이메일 등 휴대전화 가입 시 남기는 정보들로 추정되고 있습니다. 1차 발표 때 IMEI 정보 유출은 없다와는 다르게 IMEI 정보 유출 여부는 알 수 없다고 밝혔습니다. 6월 16일 CDR(Call Detail Record,통화상세기록)이 보관된 서버에서도 악성코드가 발견되었고 CDR이 제대로 암호화되어 있지 않은 사실도 확인되어 통화 내역 유출 가능성이 제기되고 있습니다.

※ SKT는 이번에 해킹을 당한 가입자인증서버(HSS) 외 단말장치 등록기(EIR: Equipment Identity Register, 단말기의 정보를 저장하는 서버)에서 단말기고유식별번호(IMEI)를 관리하고 있습니다. 단말기고유식별번호(IMEI)는 제조사가 단말기를 제작할 때 부여하는 15자리 숫자로 된 번호이며 단말기 제조사와 모델, 일련번호 등의 정보를 담고 있습니다. 

※ 유심(USIM·가입자식별장치) 관련 정보: SKT 가입자 정보를 분산한 서버는 총 14대이며, 기본적으로 전화번호, 유심(USIM) 인증키(Ki), 이동가입자식별번호(IMSI), 유심(USIM) 카드 식별자(ICCID), 서비스 가입 정보가 들어가 있습니다. 회사에 따라 단말기고유식별번호(IMEI)가 들어가기도 합니다. 통신사는 이동가입자식별번호(IMSI)와 단말기고유식별번호(IMEI) 두 가지 정보를 결합해서 가입자를 인증하고 과금합니다. 유심 정보를 알면 가입자의 요금 정보나 로밍 기록을 확인할 수 있습니다. 다만 이용자의 금융 계좌 비밀번호나 공동인증서 비밀번호 등은 유심(USIM)에 저장되지 않습니다.

• 침투 방식: 이반티(Ivanti) VPN 장비 취약점(CVE-2025-22457)을 통해 이뤄졌을 가능성이 보안업계에서 제기되고 있습니다(한국인터넷 진흥원 보안공지(2025.04.04): Ivanti 제품 보안 업데이트 권고). CVSS Base Score가 10점 만점에 9.8점으로 시스템에 치명적인 영향을 미칠 수 있기 때문에 Pulse Connect Secure 9.X의 경우 24년 12월 31일 EoL(End Of Life, 제품의 수명이 끝남)되었음에도 패치를 제공한 것을 볼 수 있습니다.
  - 아래는 OSINT(Open Source Intelligence, 공개적으로 접근 가능한 정보원을 활용하여 정보를 수집하고 분석하는 과정) 결과입니다. 2025.05.07 기준 무료 OSINT로 취약버전 사용여부 확인은 어렵지만 이반티(Ivanti) VPN 장비 사용여부는 찾을 수 있었습니다. 그러나 history 정보를 제공하는 유료 OSINT에서 4월 16일 기준 EoL 버전 정보를 확인할 수 있었습니다.
  - OSINT 정보에 따르면 Ivanti VPN 장비의 버전은 9.1.14.25049(9.1R14.5)이며
  한국인터넷 진흥원 보안공지(2024.02.15): Ivanti 제품 보안 업데이트 권고는 패치,
  한국인터넷 진흥원 보안공지(2024.04.04): Ivanti 제품 보안 업데이트 권고는 미패치,
  한국인터넷 진흥원 보안공지(2025.01.13): Ivanti 제품 보안 업데이트 권고는 EoL로 패치 지원 종료 안내,
  한국인터넷 진흥원 보안공지(2025.04.04): Ivanti 제품 보안 업데이트 권고는 EoL 대상도 긴급 보안 업데이트를 제공하였으나 미패치로 보입니다.

※ 개인적으로 보안장비 로그인 웹 페이지 title 정보를 통해 장비정보가 노출되지 않도록 이를 제거하거나 수정하면 좋겠다는 생각을 해봅니다.

• 해외 보안업체 분석(Rapid7, Mandiant)에 따르면 CVE-2025-22457 취약점은 당시 Ivanti가 이 문제에 대해 제대로 이해하지 못했기 때문에 저위험 서비스 거부(DoS) 취약점으로 간주되었으며 제품 버그로 식별되었습니다. 그리고 2025년 2월 11일 출시된 Ivanti Connect Secure 버전 22.7R2.6에서 보안 취약점이 아닌 제품 버그로 패치되었습니다. 그러나 4월 3일, Ivanti는 일부 고객 환경에서 지원되는 Ivanti Connect Secure 및 지원 종료된 Pulse Connect Secure 어플라이언스에서 원격 코드 실행을 위한 알려진 악용 사례를 공개적으로 인정했습니다.
• CVE-2025-22457 익스플로잇(exploit) 은 2025년 3월 중순에 발견되었습니다. 중국과 연계된 위협 행위자가 2025년 2월 복잡성에도 불구하고 패치를 리버스 엔지니어링하여 취약점을 발견하고, 원격 코드 실행에 성공적으로 취약점을 악용한 것으로 드러났습니다.(CVE-2025-22457 PoC, Github)

※ 익스플로잇(exploit): 시스템이나 애플리케이션의 취약점을 이용하는 코드나 프로그램으로, 공격자가 시스템을 제어하거나 데이터를 탈취하는 데 사용됩니다. 쉽게 말해, 프로그램의 버그나 보안 취약점을 이용해 공격을 가하는 방법이라고 할 수 있습니다. 

• 또한 애플리케이션 취약점을 통한 침투 시나리오도 거론되고 있으며 한국인터넷진흥원(KISA)이 SAP의 '넷위버'에서 파일 업로드 취약점(CVE-2025-31324)을 발견했다고 합니다(한국인터넷 진흥원 보안공지(2025.04.28): SAP 제품 보안 업데이트 권고). 그리고 폐쇄망이라고 하여 리눅스 커널 업데이트를 진행하지 않았다면 권한상승 취약점(CVE-2025-21756)이 존재할 것으로 보입니다(한국인터넷 진흥원 보안공지(2025.04.30): 리눅스 커널 보안 업데이트 권고). 악성 코드가 내부 시스템에 삽입된 것으로 확인되었으나, 정확한 침투 경로는 조사 중입니다. 예를 들어, VPN 취약점이나 기타 취약점이 활용되었을 가능성이 제기되었으나, 구체적으로 확인되지 않았습니다.

※ SKT는 2000년부터 SAP의 ERP를 도입, 현재 S/4HANA라는 ERP 제품을 프라이빗 클라우드 환경에서 사용하고 있습니다. 

• 공격 기술: 리눅스 기반 시스템에 침투해 BPF를 악용하여 보안 장비의 탐지를 우회하고, 외부 명령을 수신해 민감 정보를 유출하는 고도화된 BPFDoor 백도어 악성코드를 통한 데이터 유출이 주요 수법으로 확인되었습니다. 으나, 구체적으로 확인되지 않았습니다.
• 침투 시점: 침투 시점은 명확하지 않으나 3월 중순에 익스플로잇(exploit)이 발견된 것과 3월 중순에 SKT 내 이상 트래픽 있었다는 제보에 따르면 3월경으로 보입니다. 민관합동조사단 2차 발표(2025.05.19)에 따르면 악성코드 설치시점은 2022년 6월 15일로 확인되었습니다. 며, APT 특성상 장기간 잠복했을 가능성이 제기되었으나, 구체적으로 확인되지 않았습니다.

5. SKT의 대응 조치

5.1 대응조치

• 4월 19일 악성 코드 삭제 및 서버 격리.
• 4월 20일 한국인터넷진흥원(KISA) 신고, 4월 22일 개인정보보호위원회 보고 및 경찰 수사 요청.
• 4월 22일 무료 USIM 보호 서비스 가입 권고.
• 불법 USIM 기기 변경 및 비정상 인증 시도 차단 강화.
• 피해 의심 징후 발견 시 즉각적인 이용 정지 및 고객 안내.
• 휴대전화가 꺼져있더라도 비정상 인증 시도 차단 시스템(FDS)을 통해 불법 유심(USIM) 기기 변경 시도 최대한 차단.
• 전체 시스템 전수 조사
• 기관 및 경찰과 사고 분석 협력.
• 4월 28일 전고객 유심(USIM) 무상교체 실시, 기교체 고객은 비용 환급
• 5월 8일 해킹과 관련해 피해가 우려되는 서버 3만 3000대 3차례 조사(민관합동조사단이 4차 조사)
• 5월 9일 2564만 명에 유심 해킹 관련 개인정보 유출 가능성 통지
• 5월 12일 SW로 유심(USIM) 데이터 초기화 실시
• 5월 14일 해외 로밍 포함 전 고객 유심(USIM) 보호서비스 자동 가입 완료
• 5월 18일 불법유심복제와 IMEI를 도용한 불법 복제폰 피해까지 차단할 수 있는 FDS 2.0으로 고도화해 운영 시작
• 5월 23일 리눅스 보안에 EDR·백신 도입

5.2 문제점

• 알림 지연: 사고 발생 후 45시간 지연으로 사이버 침해사고 발생을 알게 된 때부터 24시간 이내 신고 의무 위반
• 고객 불만: 유출 사실 미통지 및 T-World 사이트 접속 지연으로 가입자 불만 증가
• 주요정보통신기반시설 미지정: 해킹 피해를 입은 SKT의 과금정보관리서버(WCDR), 가입자인증서버(HSS), 가입자 인증키 저장 시스템, 유심(USIM) 관련 핵심 서버 등은 '국가·사회적으로 보호가 필요한 주요정보통신기반시설'로 지정되지 않은 상태. 현재 KT와 LG유플러스도 동일하게 관련 서버가 포함돼 있지 않은 상황.
• 축소 신고 : 신고당시 해킹 '의심정황'으로 축소 신고 
• 한국인터넷진흥원(KISA) 지원거부 : 신고당시 한국인터넷진흥원(KISA)의 피해지원서비스·후속조치 지원 등 일체의 기술적 지원을 거부한 것으로 파악
• 로그보관주기: 방화벽 로그 기록을 5개월 여로 짧게 보관한 점
• 개인정보 평문저장: 통합고객시스템(ICAS) 서버에 이름, 생년월일, 휴대전화 번호, 이메일, 주소, 단말식별번호(IMEI) 29만 1천831건, 가입자식별번호(IMSI) 등 고객의 중요 개인정보를 포함해 총 238개 정보(칼럼값 기준)가 암호화되지 않은 평문 상태로 저장
• CDR(Call Detail Record,통화상세기록) 이 제대로 암호화되어 있지 않음

 6. 이슈

• 보안 투자 감소: SKT는 2025년 해킹 사태 이전에 사이버보안 예산을 감축한 것으로 나타났습니다. SKT는 2년 동안 사이버보안 지출을 4% 줄였으며, 이는 경쟁사 KT와 LG유플러스에 비해 낮은 투자 수준입니다. 이 감소는 보안 인프라 강화 부족으로 이어졌을 가능성이 있으며, 전문가들은 예산 삭감이 보안 취약점을 간접적으로 악화시켰을 수 있다고 우려합니다.
• 한국인터넷진흥원(KISA) 무마의혹: SKT가 4월 20일 신고서를 접수할 때 해킹 인지 시점을 18일 오후 11시 20분으로 제출하려고 했지만, 한국인터넷진흥원(KISA)에서 4월 20일 오후 3시 30분으로 신고하도록 안내한 사실이 밝혀졌습니다. 제출된 신고서에 따르면 해킹을 인지한 지 1시간 16분 만에 신고했기 때문에 법 위반으로 인한 과태료 3000만 원을 납부할 필요가 없습니다. 한국인터넷진흥원(KISA) 측은 SKT의 해킹 신고를 접수하는 과정에서 회사 보안 책임자가 신고하자고 결정한 시점을 사고 인지 시점으로 보고 사전 접수 실무자가 시간을 정정했다며 해명했습니다.
• 국정원 전문인력 투입 검토: 과학기술정보통신부는 4월 23일 최우혁 정보보호네트워크정책관을 단장으로 한국인터넷진흥원(KISA)과 보안업계 민간 전문가 등으로 구성된 민관합동조사단을 꾸리고 사고 원인 파악과 피해 확산 방지책 마련에 돌입했습니다. 조사단은 당초 11명에서 5명을 추가로 투입해 16여 명으로 구성됐습니다. 정보통신망법에 따라 국정원은 직접 조사에 참여할 수 없고, 조사된 정보를 공유받을 수는 있습니다. 당초 국정원은 SKT 조사에 기술 지원을 하겠다고 밝혔지만, 과학기술정보통신부에서 법에 따라 거절했습니다. 국가정보원법(국가정보원의 설치 및 운영에 관한 법률)에 따르면 국정원은 ① 국가안전보장에 관련되는 정보 및 보안업무 ② 국외 정보 및 방첩 업무 ③ 테러, 사이버 위협 등 국가안보에 대한 위협 대응 ④ 그 밖에 대통령령으로 정하는 직무가 가능해, ‘국가안보 차원에서의 사이버 위협’에 대응하는 업무만 할 수 있기 때문입니다. 이에 따라 개별 민간기업의 해킹 사건은 국가안보 사안으로 판단되지 않는 한 직접 조사하거나 개입할 권한이 없습니다.
• 해킹 한 달 전 비정상 트래픽 감지: SKT 내부 인증서버에선 3월 12일부터 20일 사이 비정상 트래픽이 발생했으나 조치를 취하지 않았다는 제보가 있었다고 합니다. SKT는 "해당 기간 이상 징후가 없었던 것으로 확인됐다"는 입장을 전했다고 합니다.
• 민관합동조사단의 SKT 침해사고 조사결과 2차 발표에 따르면 해킹 공격이 3년 전부터 시작되었다고 합니다. 총 29만 1831건의 IMEI가 담긴 서버에 2022년에 심어진 악성 코드가 있었다는 사실이 발견되었으며 1차 발표 때와는 다르게 단말고유식별번호(IMEI)와 개인정보 유출여부는 확인이 어렵다고 하였습니다.

◎ 한국인터넷진흥원 보안공지(2025.04.25) : 최근 해킹공격에 악용된 악성코드, IP 등 위협정보 공유 및 주의 안내 □ 침해사고 위협정보  1. 공격 IP : 165.232.174[.]130  AbuseIPDB 에서는 0%, CriminalIP 에서는 99% Score를 나타냅니다.(2025.04.25) 디지털오션(DigitalOcean) 클라우드 서비스 제공 업체 소유로 165.232.32[.]0 ~ 165.232.191[.]255 대역을 사용하고 있으며 악성행위와 관련된 이력이 많습니다.
2. 악성코드 해시값 및 파일정보 hpasmmld: hpasmcli와 유사하게 정상적인 HP 서버 관리 서비스로 위장한 것으로 보입니다. - size : 2,265KB - SHA256 : c7f693f7f85b01a8c0e561bd369845f40bff423b0743c7aa0f4c323d9133b5d4 - MD5 : a47d96ffe446a431a46a3ea3d1ab4d6e smartadm: smartctl과 유사하게 시스템 관리 도구로 위장한 것으로 보입니다. - size : 2,067KB - SHA256 : 3f6f108db37d18519f47c5e4182e5e33cc795564f286ae770aa03372133d15c4 - MD5 : 227fa46cf2a4517aa1870a011c79eb54 - behavior HTTP requests: hxxp://169.254.169[.]254/latest/meta-data/ami-id는 정상적인 경우 AWS(아마존 웹 서비스) EC2 인스턴스에서 자신의 메타데이터에 접근하기 위해 사용하는 표준 주소입니다. 하지만 BPFdoor 악성코드로 인해 발생했다면, 그 목적은 정상적인 메타데이터 조회가 아닌, 시스템 정찰 및 공격 준비 단계일 가능성이 높습니다. hald-addon-volume: hald-addon-acpi와 유사하게 데몬(HAL)의 구성 요소로 위장한 것으로 보입니다. - size : 2,071KB - SHA256 : 95fd8a70c4b18a9a669fec6eb82dac0ba6a9236ac42a5ecde270330b66f51595 - MD5 : f4ae0f1204e25a17b2adbbab838097bd dbus-srv-bin.txt: dbus-daemon과 유사하게 D-Bus와 관련된 파일로 위장한 것으로 보입니다. - size : 34KB - SHA256 : aa779e83ff5271d3f2d270eaed16751a109eb722fca61465d86317e03bbf49e4 - MD5 : 714165b06a462c9ed3d145bc56054566 - behavior HTTP requests: hxxp://169.254.169[.]254/latest/meta-data/ami-id는 정상적인 경우 AWS(아마존 웹 서비스) EC2 인스턴스에서 자신의 메타데이터에 접근하기 위해 사용하는 표준 주소입니다. 하지만 BPFdoor 악성코드로 인해 발생했다면, 그 목적은 정상적인 메타데이터 조회가 아닌, 시스템 정찰 및 공격 준비 단계일 가능성이 높습니다. - behavior IP Traffic: 185.125.188[.]59(AbuseDBIP, CriminalIP)는 우분투(Ubnutu) 리눅스 OS를 개발하고 배포하는 영국의 소프트웨어 회사인 Canonical IP 이며, api.snapcraft[.]io는 Snap 패키지를 관리하고 배포하는 Snapcraft 서비스에서 사용되는 API 서버의 주소입니다. ※ BPFDoor는 쉽게 재컴파일되어 해시가 자주 변경될 수 있기 때문에 해시 기반 탐지는 신뢰도가 낮으며, EDR 장비를 활용한 행위기반 탐지가 필요하겠습니다.(해시 IoCs) ※ 이번 위협정보는 AWS Linux에 BPFDoor 악성코드가 발견돼 공지된 것으로 보여집니다. SKT는 AWS와 전략 파트너쉽을 맺었습니다.

1. BPFDoor 악성코드 개요
1.1 BPFDoor
리눅스 및 솔라리스 시스템을 타깃으로 하는 스텔스형 백도어 악성코드로, 2017년경부터 약 5년간 탐지되지 않았습니다. 2021년 PwC 연구진에 의해 발견되었으며, 중국 기반 APT 그룹 Red Menshen(Trend Micro에서는 Earth Bluecrow로 추적)에 연관된 것으로 알려져 있습니다. 주요 특징은 다음과 같습니다:

• Berkeley Packet Filter(BPF) 활용: C&C 서버에 먼저 접속할 필요가 없고, BPF를 사용하여 네트워크 패킷을 모니터링하고 매직 바이트 시퀀스(예: 0x7255, 0x5293)를 사용해 특정 "매직 패킷"을 받으면 활성화됩니다. 이는 기존 포트(예: 22, 80, 443)를 활용해 추가 포트를 열지 않고도 작동 가능해 탐지가 어렵습니다.
• 스텔스 기법: 프로세스 이름을 일반적인 리눅스 데몬(예: dbus-daemon, hald-addon-acpi 등)으로 위장하고, /dev/shm 경로에 자신을 복사하여 메모리 기반으로 동작하며, 파일을 삭제하고 타임스탬프를 조작(예: 14년 전으로 설정)해 포렌식 분석을 방해합니다.
• 리버스쉘(Reverse Shell): 공격자가 원격으로 시스템에 접근할 수 있는 암호화된 리버스쉘을 생성하며, 42391~43390 포트 범위에서 쉘을 제공합니다.
• 다양한 프로토콜 지원: iptables를 조작하여 공격자의 접근을 허용하며 TCP, UDP, ICMP를 통해 C2 서버 없이도 명령을 수신할 수 있습니다.
• 최근 변종: 2023년 변종은 정적 라이브러리 암호화, 리버스쉘 통신, 하드코딩된 명령 제거로 탐지를 더욱 어렵게 만들었습니다.
• BPFDoor는 주로 통신, 정부, 물류, 교육, 금융, 소매 산업을 타깃으로 하며, 한국, 홍콩, 미얀마, 말레이시아, 이집트 등에서 활동이 관찰되었습니다.

1.2 SKT 해킹 사태와 BPFDoor

• 트렌드마이크로의 2025년 4월 14일 보고서: BPFDoor는 한국, 홍콩, 미얀마, 말레이시아, 이집트의 통신, 금융, 소매 산업을 타깃으로 한 공격에 사용되었습니다. 원문에서는 SKT를 명시적으로 언급하지 않고 한국 통신사에서의 악성코드 트래픽만 언급했습니다. SKT의 HSS 서버에서 발견된 악성 코드는 BPFDoor일 가능성이 있지만, 이는 아직 추정 단계이며 공식 확인이 필요합니다. SKT의 과금정보관리서버(WCDR)에서 발견된 악성 코드는 BPFDoor입니다. BPFDoor는 리눅스 기반 그리고 가입자인증서버(HSS)와 과금정보관리서버(WCDR) 사이 9.82기가바이트(GB)에 이르는 데이터를 이동하여 가입자인증서버(HSS)에서 유심(USIM) 관련 데이터를 유출하였습니다. 유출할 수 있는 능력을 갖추고 있으며, 이는 SKT 사건의 특성과 일치할 수 있습니다.

2. BPFDoor 사례
BPFDoor는 2017년경부터 활동이 시작된 것으로 추정되며, 2021년 PwC에 의해 처음 공개되었습니다. 2024년과 2025년의 주요 사례는 다음과 같습니다:

2024년 한국 및 동남아시아 공격:

• 트렌드마이크로에 따르면, BPFDoor는 한국(2024년 7월, 12월), 홍콩(2024년 1월), 미얀마(2024년 12월), 말레이시아, 이집트의 통신, 금융, 소매 산업을 타깃으로 했습니다.
• 공격자는 /tmp/zabbix_agent.log, /bin/vmtoolsdsrv, /etc/sysconfig/rhn/rhnsd.conf와 같은 경로를 사용해 악성코드를 은폐했습니다.
• 새로운 컨트롤러가 발견되었으며, 이는 리버스쉘을 통해 네트워크 내 측면 이동을 가능하게 했습니다.

 
2021~2022년 중동 및 아시아 공격:

• Red Menshen은 중동과 아시아의 통신, 정부, 물류, 교육 부문을 타깃으로 BPFDoor를 사용했습니다. 피해는 미국, 한국, 홍콩, 터키, 인도, 베트남, 미얀마 등에서 확인되었습니다.
• 공격은 주로 월요일~금요일 01:00~10:00 UTC에 이루어져, 조직적인 작업 패턴을 보였습니다.

 
솔라리스 시스템 공격:

• 2019년 솔라리스 시스템을 타깃으로 한 변종이 2022년까지 탐지되지 않았으며, CVE-2019-3010 취약점을 악용한 것으로 확인되었습니다.

※ 트렌드마이크로 BPFDoor 분석 보고서(2025.04.14) 

3. BPFDoor 기술적 분석
BPFDoor는 다음과 같은 기술적 특징을 갖습니다:

3.1 동작 방식
초기 실행:

• 실행 시 /var/run/initd.lock 파일을 생성해 런타임 락을 설정합니다.
• 포크(Fork) 프로세스를 생성해 부모 프로세스는 패킷 모니터링을, 자식 프로세스는 C2 통신을 담당합니다.
• 다양한 OS 시그널(SIGKILL 등)을 무시해 종료를 방지합니다.

 
패킷 스니핑:

• BPF 필터를 사용해 TCP, UDP, SCTP 트래픽(포트 22, 80, 443)을 모니터링합니다.
• 매직 바이트 시퀀스(예: 0x7255, 0x5293, 0x39393939)를 검색해 특정 패킷을 식별합니다.

 
명령 실행:

• 매직 바이트가 포함된 패킷을 수신하면, 하드코딩된 비밀번호를 확인 후 명령을 실행합니다.
• 지원 명령: 바인드 쉘(포트 42391~42491), 리버스쉘, iptables 규칙 수정 등.

 
은폐:

• 실행 후 바이너리를 삭제하고, /dev/shm/kdmtmpflush로 이름을 변경해 타임스탬프를 조작합니다.
• 프로세스 이름을 일반적인 리눅스 데몬으로 위장합니다.

 
3.2 탐지 회피

• 포트 비사용: 새로운 포트를 열지 않고 기존 서비스 포트를 활용합니다.
• C2 불필요: 특정 IP나 C2 서버 없이도 패킷을 통해 명령을 수신합니다.
• 암호화: 2023년 변종은 정적 라이브러리 암호화를 사용하며, 하드코딩된 명령을 제거해 시그니처 기반 탐지를 회피합니다.
• 안티-포렌식: 프로세스 환경 변수를 삭제하고, 메모리에 상주해 파일 스캔을 방지합니다.

 
3.3 취약점 악용
BPFDoor는 초기 침투를 위해 취약점을 악용하거나 사회공학적 기법을 사용합니다. 예:

• 솔라리스 시스템에서 CVE-2019-3010 취약점 활용.
• SysVinit 스크립트 수정으로 지속성을 확보합니다.

 
4. 탐지 및 대응
4.1 탐지 방법
네트워크 모니터링:

• TCP 패킷에서 24바이트 페이로드 시작 부분의 0x5293, UDP 패킷에서 0x7255 매직 바이트를 검색합니다.
• ss -0pb 명령어로 BPF 필터의 매직 넘버(0x7255, 0x5293, 0x39393939, 0x4430cd9f)를 확인합니다.

※ 주의: ss -0pb 명령어를 관리자 권한이 아닌 일반 유저권한으로 실행하면 bpf filter 값이 안보입니다.

       - HEX 7255: DEC 29269
       - HEX 5293: DEC 21139
       - HEX 39393939: DEC 960051513
       - HEX 4430cd9f: DEC 1144049055

 
변종 대비 리눅스 시스템의 전체 소켓 상태를 조회하여 확인하는 것도 방법이겠습니다.

프로세스 분석:

• /proc/*/stack에서 packet_recvmsg, wait_for_more_packets 함수 호출을 검색합니다.
• 의심스러운 프로세스 이름(예: hald-addon-acpi)을 확인합니다.
• TCP 포트 42391~43391 바인딩을 확인합니다.

파일 및 로그:

• /var/run/haldrund.pid 또는 /dev/shm/kdmtmpflush 파일 존재 여부를 확인합니다.
• iptables의 비정상적인 리디렉션 규칙을 점검합니다.

 
4.2 대응 방안

• 패치 관리: CVE-2019-3010과 같은 알려진 취약점을 패치합니다.
• BPF 분석: Radare2와 같은 도구를 사용해 BPF 바이트코드를 분석합니다.
• 보안 솔루션: Trend Micro Vision One과 같은 AI 기반 플랫폼을 활용해 실시간 위협 탐지를 수행합니다.
• 자동화 스캔: Sandfly와 같은 도구로 패킷 소켓을 사용하는 프로세스를 자동 스캔합니다.
• 기 탐지 BPFDoor 악성코드: ss -0pb 명령어로 알려 매직 바이트 시퀀스 값을 찾거나 매직 바이트 시퀀스 값으로 열린 포트를 Github에 공개된 스캐너로 스캔하면 탐지가 가능합니다 (bpfdoor-scanner, Github) . 알려진 악성 프로세스명 검색. 알려진 Snort Rules 생성.
• 변종 BPFDoor 악성코드: 관리자 권한으로 ss -0pb 명령어를 실행하여 BPF 필터가 조회되는 전체 프로세스에 대한 점검. 재컴파일, 매직 바이트 시퀀스 변경 시 스캔 무의미, Snort Rules 무의미, EDR 솔루션이 없다면 시스템에서 lsof 명령어로 외부통신 프로세스 직접 점검(이것도 점검시점에 외부 통신이 없다면 무의미) 및 의심스러운 프로세스 이름을 하나하나 점검하는 것 외 대응 방안 없음. 
  - 아래 점검스크립트를 만들어서 관리자 권한으로 실행해 보시기 바랍니다.

bpf filter를 사용하는 프로세스가 존재하고, 파일이 삭제되지 않았다면 아래처럼 보일 겁니다.

1. 가입자인증서버(HSS)이란? 가입자인증서버(HSS,Home Subscriber Server)는 이동통신망에서 가입자 데이터를 관리하고 인증 및 권한 부여를 수행하는 중앙 집중형 데이터베이스입니다. 4G(LTE), 5G, IMS(IP Multimedia Subsystem) 네트워크에서 사용되며, 2G/3G 네트워크의 HLR(Home Location Register)와 AuC(Authentication Center) 기능을 통합합니다. 주요 기능은 다음과 같습니다: 가입자 데이터 저장: IMSI, MSISDN, IMPU(IMS Public Identity), IMPI(IMS Private Identity), 서비스 프로필, 서비스 트리거 등. 인증 및 권한 관리: 가입자 인증(EAP-AKA), 권한 부여, 세션 관리. 위치 정보 관리: 가입자의 현재 위치 등록 및 업데이트. 과금 데이터 처리: 서비스 사용에 따른 과금 정보 제공. IMS 및 EPC 연동: IMS 네트워크의 AS(Application Server), CSCF(Call Session Control Function), 4G/5G 네트워크의 MME(Mobility Management Entity)와 협력. HSS는 통신망의 핵심 인프라로, 보안이 무너지면 네트워크 전체에 심각한 위협을 초래할 수 있습니다.
2. HSS 서버 아키텍처 HSS는 중앙 집중형 데이터베이스로 설계되어 모든 가입자 정보를 단일 노드에 저장합니다. 주요 특징은 다음과 같습니다: 데이터 저장소: 가입자 데이터를 저장하며, Nokia의 One-NDS(One Network Directory Server) 또는 SDL(Shared Data Layer) 같은 솔루션을 통해 분산형 저장소로 확장 가능. 다중 HSS 지원: SLF(Subscriber Location Function)를 통해 가입자 정보를 적절한 HSS로 매핑, 대규모 네트워크 확장성 제공. IMS 네트워크 통합: AS, CSCF 등 IMS 엔티티와 연동하여 음성 및 데이터 세션 처리. MME 연동: 4G/5G 네트워크에서 MME와 협력하여 인증 및 세션 관리. HSS는 2G/3G의 HLR/AuC를 대체하며, 4G/5G 네트워크의 복잡성을 지원하기 위해 향상된 기능과 확장성을 제공합니다.
3. HSS 서버 통신 방식 HSS는 다양한 네트워크 엔티티와 통신하며, 주로 Diameter 프로토콜을 사용합니다. Diameter는 RFC3588에 정의된 AAA(Authentication, Authorization, Accounting) 프로토콜로, RADIUS의 후속입니다. 3.1 주요 인터페이스 및 프로토콜 Diameter 프로토콜: Sh 인터페이스: 3GPP 벤더 ID 10415, 애플리케이션 ID 16777217. 명령어는 UDR/UDA(데이터 조회), PUR/PUA(프로필 업데이트), SNR/SNA(알림 구독), PNR(알림 푸시) 등. Cx 인터페이스: S-CSCF가 HSS에서 가입자 프로필을 조회하거나 등록 요청을 처리. 동작 모드: 데이터 처리(Pull/Update) 및 구독/알림(Subscriptions/Notifications). 기타 프로토콜: SIP: IMS 네트워크의 주요 시그널링 프로토콜로, Gm, Mw, ISC 인터페이스에서 사용. H.248: Mn, Mp, P1 인터페이스에서 사용. HTTP: Sr, Ut 인터페이스에서 데이터 교환에 활용. 3.2 통신 취약점 이동통신망은 Diameter 프로토콜 등을 통해 HSS와 MME, AS 간 통신을 수행합니다. 이러한 프로토콜은 암호화 부족이나 인증 메커니즘의 약점으로 인해 보안 취약점을 가질 수 있습니다.
4. HSS 서버 인증 방식 HSS는 가입자 인증 및 권한 부여를 담당하며, LTE 및 IMS 네트워크에서 다음과 같은 인증 메커니즘을 사용합니다: 4.1 EAP-AKA 인증 과정: UE(사용자 장비)가 네트워크에 연결 시, MME가 HSS에 인증 요청을 전송. HSS는 USIM에 저장된 키를 사용하여 인증 벡터를 생성, MME에 전달. M1ME와 UE 간 AKA(Authentication and Key Agreement) 알고리즘을 통해 상호 인증 수행. 특징: 4G/5G 네트워크에서 표준 인증 방식으로, USIM 카드 기반 보안 제공. 4.2 Diameter 기반 AAA 과정: Sh 인터페이스에서 AS의 권한을 확인하기 위해 Permission List(Sh-Pull, Sh-Update, Sh-SubNotif)를 사용. Cx 인터페이스에서 S-CSCF가 HSS에 가입자 인증 요청을 전송. 실패 코드: 영구적 실패: DIAMETER_ERROR_OPERATION_NOT_ALLOWED(5101), DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED(5103). 일시적 실패: 요청이 나중에 성공할 가능성 있음.   4.3 보안 메커니즘 IPsec/TLS: P-CSCF가 UE와의 통신에서 IPsec 또는 TLS를 사용하여 스푸핑 및 리플레이 공격 방지. 약점: 초기 IMS 보안은 네트워크 부착 절차로 가입자 프로필과 IP 주소를 바인딩했으나, 시그널링 보호 부족으로 취약. 대체 인증: 일부 기기가 USIM/ISIM을 지원하지 않아 Digest-MD5와 같은 대체 인증 사용.

Zero Trust User Access

XSS(Cross-Site Scripting)

XDR vs SIEM

Wpscan

Wireshark Display Filter