사이버 사고는 ‘계정이 해킹당했습니다’라는 메시지로 시작되는 경우가 드뭅니다. 보통 첫 번째 신호는 기업 계정에 대한 의심스러운 로그인 시도, 예기치 않은 이메일 전달 규칙, 비활성화된 EDR 에이전트, 접속 불가한 서버, 또는 다단계 인증에 대한 비정상적인 요청을 받은 직원의 신고 등입니다.

이 시점에서 조직은 아직 공격의 규모를 파악하지 못합니다. 하지만 바로 이 초기 대응이 해당 사건이 국지적인 문제로 그칠지, 아니면 비즈니스 중단, 데이터 손실, 평판 손상을 동반한 수 주에 걸친 위기로 번질지를 결정합니다.

이러한 결정을 내릴 수 있는 시간은 점점 줄어들고 있습니다. Unit 42가 조사한 가장 빠른 사례에서, 공격자들은 초기 접근부터 확인된 데이터 유출에 이르기까지 72분이 걸렸습니다. 이는 1년 전보다 약 4배 더 빠른 속도입니다. 이는 모든 공격의 평균 시간이 아니라 가장 빠른 사례들을 나타낸 것이지만, 이 수치는 방어 담당자들에게 주어진 시간이 얼마나 크게 줄어들었는지를 잘 보여줍니다. 저희가 진행한 조사에서도 AWS 인프라를 대상으로 한 10분 미만의 공격 사례를 목격한 적이 있습니다. 공격자는 키를 확보하자마자 즉시 데이터 유출을 시작했습니다. 회사 버킷에서 데이터를 유출하기 시작하는 데 단 6분밖에 걸리지 않았습니다.

2026년에 올바른 대응이란 당직 팀의 영웅적인 분주함이 아닙니다. 이는 사전에 준비되고 체계적으로 관리되는 프로세스로, 이를 통해 공격자의 활동을 신속하게 제한하고, 증거를 보존하며, 핵심 운영을 유지하며, 시스템이 재침해되지 않도록 복구하여 정상 가동을 재개할 수 있습니다.

2026년이 되면 무엇이 달라질까

공격은 더 이상 단일 시스템에만 국한되지 않습니다

현대적인 공격자는 로컬 인프라, 클라우드 계정, 기업 이메일, SaaS 애플리케이션 및 외부 협력업체의 접근 권한을 동시에 활용할 수 있습니다.

감염된 노트북을 격리한 후에도 다음과 같은 요소가 남아 있을 수 있습니다:

  • 활성화된 클라우드 세션;
  • 리프레시 토큰;
  • OAuth 권한;
  • API 키;
  • 해킹당한 서비스 계정;
  • 위임된 관리자 권한;
  • 합법적인 클라우드 서비스를 통한 백업 관리 채널.

Unit 42의 자료에 따르면, 조사된 사고의 87%에서 사건 경위를 파악하기 위해 최소 두 곳의 서로 다른 출처에서 나온 증거를 대조해야 했으며, 가장 복잡한 경우에는 열 곳의 출처에서 나온 증거를 대조해야 했습니다. 이는 조사를 더 이상 단일 컴퓨터나 단일 이벤트 로그로만 제한할 수 없음을 의미하며, 신원, 엔드포인트, 네트워크, 클라우드 및 SaaS 데이터를 동시에 분석해야 함을 시사합니다. (Unit 42)

“악성 파일을 찾아 삭제하고 컴퓨터를 재설치한다”는 방식은 더 이상 충분한 방어 효과를 보장하지 못합니다.

신원 정보와 취약점은 똑같이 중요합니다

현대적인 보안 사고에는 단 하나의 보편적인 침투 경로가 존재하지 않습니다.

Unit 42의 데이터에 따르면, 해당 기관의 조사에서 확인된 초기 침입 사례의 65%는 신원 기반 기법과 관련이 있었습니다: 도난당한 인증 정보, MFA 조작, 세션 탈취, 지원 담당자로 위장하거나 합법적인 원격 접속 권한을 악용하는 경우 등이 포함됩니다. (Unit 42)

한편, Verizon DBIR 2026은 소프트웨어 취약점 악용을 표본에서 가장 주요한 초기 침투 경로로 꼽았습니다. 이는 유출 사건의 31%에서 나타났으며, 도난당한 인증 정보를 처음으로 앞질렀습니다.

실무적 결론: 신원 보호와 취약점 관리 중 하나를 선택해서는 안 됩니다. 성숙한 대응 프로그램은 두 가지 방향을 모두 아우러야 한다. 팀은 토큰과 세션을 동시에 회수하고, 특권 접근을 분석하며, 취약한 외부 서비스를 차단하고, 공격자가 정확히 어떤 경로를 이용했는지 파악할 수 있어야 한다.

공급업체가 공격 표면의 일부가 되었다

Verizon DBIR 2026에 따르면, 제3자가 48%의 정보 유출 사건에 연루되었으며, 이는 전년 대비 60% 증가한 수치입니다. 소프트웨어 공급업체, MSP, 통합업체, 클라우드 서비스 또는 합법적인 접근 권한을 가진 계약업체가 침입 경로가 될 수 있습니다.

조직은 사전에 다음 사항을 파악해야 합니다:

  • 누가 공급업체의 로그를 제공할 수 있는지;
  • 해당 공급업체의 접근 권한을 얼마나 빨리 철회할 수 있는지;
  • 텔레메트리 데이터가 얼마나 오래 보관되는지;
  • 계약상 어떤 조치가 허용되는지;
  • 누가 의사소통을 담당하는지;
  • 타사의 인프라에서 증거를 어떻게 보존할 수 있는지.

이러한 질문들이 공격 도중에 처음으로 제기된다면, 팀은 이미 결정적인 시간을 놓치고 있는 셈이다.

몸값 요구는 더 이상 암호화를 필요로 하지 않습니다

인프라 암호화는 여전히 심각한 위협이지만, 더 이상 랜섬웨어 공격의 필수 요소는 아닙니다. 공격자들은 데이터를 탈취한 후, 전통적으로 보안 수단이 대응하도록 설정된 대규모 암호화 사건을 일으키지 않고도 즉시 데이터 유출이나 판매를 위협할 수 있습니다.

Verizon DBIR 2026에서 검토한 정보 유출 사건의 거의 절반에서 랜섬웨어가 확인되었습니다. 그러나 암호화된 서버가 없다고 해서 해당 사고가 사소하다는 의미는 아닙니다. 이메일, CRM, 파일 저장소 또는 클라우드 환경에 대한 무단 접근은 이에 상응하는 재정적 및 평판상의 결과를 초래할 수 있습니다.

AI는 양측 모두를 가속화합니다

AI는 공격자가 공격 표면을 더 빠르게 분석하고, 사회 공학을 적용하며, 취약점을 탐색하고, 악성 코드를 생성하는 데 도움을 줍니다. Verizon DBIR 2026은 생성형 AI를 통해 이미 강화되고 있는 15가지 공격 기법을 제시합니다.

반면 방어 측에서는 모델을 활용하여 이벤트 간 상관관계를 분석하고, 타임라인을 구축하며, 경보를 그룹화하고, 위협 탐지(threat hunting)를 위한 쿼리를 준비합니다.

하지만 자동화가 검증 가능한 프로세스를 대체할 수는 없습니다. 위기 상황에서 성급한 오판은 느린 대응만큼이나 위험할 수 있습니다.

새로운 프레임워크: 대응은 사고 발생 전부터 시작된다

2025년 4월, NIST는 2012년 지침을 대체하는 SP 800-61 Revision 3을 발표했습니다.

주요 변경 사항은 인시던트 대응(incident response)이 더 이상 경보 발생 후 시작되는 별도의 선형 프로세스로 간주되지 않는다는 점입니다. 이는 NIST CSF 2.0의 전반적인 사이버 위험 관리 모델에 통합되어 있으며, 다음 여섯 가지 기능 모두와 연계되어 있습니다:

Govern, Identify, Protect, Detect, Respond 및 Recover.

역할 관리, 자산 목록 작성, 세그멘테이션, 백업, 공급업체 계약 및 로깅은 보조 조치가 아니라 사고 대비의 일부입니다. (NIST 컴퓨터 보안 리소스 센터)

2026년 6월 11일, NIST는 또한 CSF 2.0을 기반으로 한 랜섬웨어 위험 관리의 업데이트된 프로필인 IR 8374 Revision 1을 발표했습니다. 이 문서는 준비, 보호, 대응 및 복구를 하나의 통합된 위험 관리 주기로 연결합니다. (NIST 컴퓨터 보안 리소스 센터)

주요 결론은 간단합니다:

올바른 대응은 첫 번째 경보가 발생하기 훨씬 전에 시작됩니다.

사고 발생 전에 조직은 역할과 권한을 정의하고, 네트워크 외부의 통신 경로를 마련하며, 충분한 로그 저장을 보장하고, 백업 데이터를 보호하며, 복구 절차를 점검해야 합니다. 또한 랜섬웨어, 기업 이메일 침해, 클라우드 계정 탈취, 데이터 도난 및 하청업체를 통한 공격에 대한 별도의 대응 매뉴얼이 필요합니다.

훈련은 특히 중요합니다. 문서상으로만 존재하고 시간적 압박 속에서 단 한 번도 검증되지 않은 계획은 가정에 불과할 뿐, 방어 수단이 될 수 없습니다.

첫 60분: 무턱대고 시스템을 복구하지 마십시오

사고 발생 초기에는 팀이 거의 항상 불완전한 정보만을 가지고 있습니다.

이 순간에는 공격자의 행동뿐만 아니라 방어 측의 충동적인 결정도 위험합니다. 서버를 대량으로 끄거나, 시스템을 성급하게 정리하거나, 무분별하게 비밀번호를 변경하거나, 검증되지 않은 백업본으로 즉시 복구하는 행위 등이 이에 해당합니다.

1. 사고 대응 책임자를 지정하십시오

혼란스러운 전화 통화, 개인 메시지, 수십 개의 병행 채팅을 통해서는 철저한 조사를 진행할 수 없습니다.

통합된 대응 체계(response bridge)와 지정된 사고 대응 책임자(Incident Commander)가 필요합니다.

이 책임자는 직접 포렌식 작업을 수행할 의무가 없습니다. 그의 임무는 프로세스를 관리하는 것입니다:

  • 통합된 계획을 유지하고;
  • 과제 담당자를 지정하고;
  • 우선순위 충돌을 해소하고;
  • 결정을 확정하고;
  • 기술적 흐름과 관리적 흐름을 조율하고;
  • 승인된 상태를 정기적으로 갱신하고;
  • 중요 조치의 조율을 관리합니다.

기술적으로 가장 뛰어난 전문가가 반드시 전체 인시던트를 지휘해야 하는 것은 아닙니다. 분석가들은 공격을 조사하고, 인시던트 지휘관(Incident Commander)은 조사가 조율되지 않은 일련의 조치로 변질되는 것을 방지합니다.

2. 신뢰할 수 있는 통신 채널로 전환하십시오

기업 이메일, 인증 시스템 또는 메신저가 침해되었을 가능성이 있다면, 해당 채널 내에서 조사에 대해 논의해서는 안 됩니다.

미리 준비해 둔 아웃-오브-밴드(out-of-band) 채널을 사용하십시오. 잠재적으로 침해된 시스템을 통해 다음 내용을 전송해서는 안 됩니다:

  • 격리 계획;
  • 조사 가설;
  • 새로운 비밀번호;
  • 키 및 토큰;
  • 수집된 증거;
  • 공격자와의 통신 내역;
  • 경영진의 내부 결정.

팀의 활동을 파악한 공격자는 전술을 변경하고, 흔적을 지우며, 대체 접근 경로를 미리 준비할 수 있게 됩니다.

3. 사고를 확인하고 초기 규모를 파악하십시오

대응을 시작하기 위해 전체적인 상황을 파악할 때까지 기다릴 필요는 없습니다.

초기 평가에서는 최소한 다음 다섯 가지 질문에 답해야 합니다:

  1. 정확히 무엇이 발견되었는가?
  2. 어떤 사용자, 기기 및 서비스가 영향을 받을 수 있는가?
  3. 공격자의 활동이 계속되고 있는가?
  4. 중요 프로세스가 중단될 위험이 있는가?
  5. 데이터 유출, 백업 데이터 파괴 또는 특권 접근 권한 침해의 징후가 있는가?

조사 진행에 따라 분류는 변경될 수 있습니다. 중요한 것은 가능한 한 빨리 작업 가설을 수립하고 우선순위를 정하는 것입니다.

확인된 사실, 가능성이 높은 결론, 검증되지 않은 가설, 그리고 알려지지 않은 상황을 즉시 구분해 두는 것이 유용합니다. 이는 한 분석가의 추측이 파괴적인 경영 결정의 근거가 될 위험을 줄여줍니다.

4. 증거를 분리하되, 파기하지 마십시오

격리와 차단은 같은 것이 아닙니다.

감염된 호스트는 일반적으로 EDR, NAC, VLAN, 스위치 또는 클라우드 정책을 통해 네트워크에서 차단해야 합니다. 하지만 불필요한 경우 즉시:

  • 전원을 끄거나 재부팅해서는 안 됩니다;
  • 파일을 삭제하지 마십시오;
  • 바이러스 백신 검사를 실행하지 마십시오;
  • 운영 체제를 재설치하거나;
  • 표면적인 검사 후 장치를 다시 가동하는 것.

메모리에는 암호화 키, 활성 네트워크 연결, 침투된 프로세스, 액세스 토큰, 기록되지 않은 명령어 및 공격자의 도구 흔적이 남아 있을 수 있습니다.

시스템을 계속 가동하는 것이 사람, 중요 인프라 또는 비즈니스에 용납할 수 없는 위협을 초래하는 경우에는 예외가 있을 수 있습니다. 그러나 이러한 결정은 신중하게 내려져야 하며, 사고 기록부에 기록되어야 합니다.

5. 통합 타임라인을 작성하십시오

모든 중요한 사건을 기록하십시오:

  • 첫 번째 신호가 감지된 시간;
  • 탐지 출처;
  • 시스템 상태 변화;
  • 관리자의 명령;
  • 장치 격리;
  • 계정 잠금;
  • 로그 내보내기;
  • 스냅샷 생성;
  • 내린 결정;
  • 조치를 담당하고 승인한 사람.

단일 시간대(가급적 UTC)를 사용하십시오. 원본 로그를 작업 사본과 별도로 보관하고, 수집된 파일의 체크섬을 계산하며, 누가 언제 증거 자료를 처리했는지 기록하십시오.

시간 축이 없으면 조사는 금세 모순된 기억들의 집합으로 변해버립니다.

6. 백업 사본을 보호하십시오

랜섬웨어 사고 발생 시 백업 시스템은 종종 공격자의 첫 번째 표적이 됩니다.

다음 사항이 명확히 확인되기 전까지는 대량 복구를 시작하지 마십시오:

  • 공격자가 백업 콘솔에 접근할 수 있는지;
  • 운영자의 계정이 해킹당했는지;
  • 스냅샷이 삭제되었는지;
  • 저장 정책이 변경되었는지;
  • 초기 침입이 언제 발생했을 것으로 추정되는지;
  • 선택된 복사본에 고정 메커니즘이 포함되어 있는지;
  • 격리되거나 변경 불가능한 복사본이 남아 있는지.

마지막 백업 작업의 성공 여부는 단지 백업 사본이 생성되었음을 확인해 줄 뿐입니다. 이는 해당 사본이 깨끗하고 안전한 복구에 적합하다는 것을 보장하지는 않습니다.

사고가 진행 중인 경우, DFIR 팀인 PWN-ALL이 기술적 조정을 담당할 수 있습니다: 초기 억제, 증거 보존, 침해 규모 파악 및 안전한 복구 계획 수립. 이 회사의 실무 팀은 랜섬웨어, 데이터 유출, BEC, 계정 탈취 및 클라우드 환경 침해 사건을 다루고 있습니다.

대응은 여러 단계에서 동시에 진행되어야 합니다

흔히 저지르는 실수는 먼저 기술적 조사를 완료한 후에야 경영진, 변호사, 보험사 및 사업주를 참여시키는 것입니다.

실제 사고 상황에서는 이러한 프로세스가 동시에 진행되어야 합니다.

기술적 대응 흐름

팀은 공격자의 위치를 파악하고, 초기 침투 경로를 추정하며, 영향을 받은 자산과 신원을 확인하고, 침투 메커니즘을 찾아내고, 가능한 데이터 유출을 평가하며, 안전한 복구를 준비해야 합니다.

경영 흐름

경영진과 프로세스 소유자는 비즈니스에 미치는 영향을 평가하고, 복구 우선순위를 설정하며, 허용 가능한 가동 중단 기간을 결정하고, 핵심 프로세스를 중단시킬 수 있는 조치를 협의해야 합니다.

법률 및 커뮤니케이션 워크플로우

이와 병행하여 영향을 받은 데이터의 소유자를 파악하고, 계약상 의무를 확인하며, 적용 가능한 통지 요건을 설정하고, 보험사와 연락하며, 내부 및 대외 공지를 준비해야 합니다.

구체적인 요건은 산업 분야, 계약 및 관할권에 따라 다릅니다. 따라서 법적 평가는 최종 포렌식 보고서를 기다려서는 안 됩니다.

DFIR 팀의 임무는 이 절차에 검증 가능한 기술적 사실, 즉 타임라인, 영향을 받은 자산 목록, 확인된 지표, 초기 접근 평가 및 잠재적 정보 유출에 대한 정보를 제공하는 것입니다. 최종적인 법적 판단은 조직 내 해당 분야 전문가들에게 맡겨져야 합니다.

Identity takeback: 신원 통제권 회복

하이브리드 인프라에서는 서버를 복구하는 것만으로는 충분하지 않습니다. 먼저 조직은 자체 신원 확인 시스템을 다시 통제하고 있는지 확인해야 합니다.

다음 항목에 대한 검증이 필요합니다:

  • 특권 및 비상용 계정;
  • 활성 세션 및 리프레시 토큰;
  • 신규 또는 변경된 MFA 방식;
  • OAuth 애플리케이션 및 부여된 권한;
  • 서비스 주체 및 워크로드 ID;
  • 연동 규칙;
  • 조건부 액세스 정책;
  • 위임된 관리자 액세스;
  • API 키, 인증서 및 CI/CD 비밀;
  • 메일 전달 규칙;
  • 등록된 기기;
  • 계약업체의 접근 권한.

비밀번호를 변경한다고 해서 항상 진행 중인 클라우드 세션이 종료되는 것은 아닙니다. 따라서 자격 증명 로테이션을 수행할 때는 토큰 회수, 세션 종료 및 신뢰할 수 있는 애플리케이션 확인을 함께 수행해야 합니다.

특히, 보안이 침해된 관리 환경에서 대량 인증 정보 갱신을 수행하는 것은 매우 위험합니다.

먼저 검증된 기기, 별도의 통신 채널, 통제된 계정 및 독립적인 로깅 기능을 갖춘 깨끗한 작업 영역을 생성합니다. 그 후에야 비로소 ‘coordinated identity takeback’이 시작됩니다.

클라우드 및 SaaS에는 별도의 대응 매뉴얼이 필요합니다

클라우드 사고는 일반적인 워크스테이션 감염 사례처럼 조사할 수 없습니다.

일부 증거는 서비스 제공자의 로그에만 존재하며, 제한된 기간 동안만 보관될 수 있습니다. 사고 발생 초기 몇 시간 동안 다음 사항을 반드시 확보해야 합니다:

  • 로그인 및 감사 로그;
  • IAM 변경 내역;
  • 컨트롤 플레인 로그;
  • 메일 및 협업 이벤트;
  • 정책 및 네트워크 규칙 변경 내역;
  • 키 및 토큰 생성 내역;
  • 디스크 및 구성 스냅샷;
  • SSO 또는 OAuth를 통해 연결된 SaaS 애플리케이션 데이터.

이와 별도로, 새로운 관리자 생성, 페더레이션 변경, 장기 유효 토큰 발급, OAuth 동의 권한 부여, 보안 정책 비활성화, 새로운 클라우드 리소스 시작 및 데이터 내보내기를 확인해야 합니다.

서비스 제공업체에 대한 긴급 에스컬레이션 절차, 당사자의 권한 및 텔레메트리 보존 절차는 사전에 정의되어야 합니다.

PWN-ALL은 Microsoft 365, Google Workspace, 클라우드 인프라 및 기업 계정의 침해 사고 조사를 위해 별도의 프로세스를 사용합니다. 이를 통해 기존 엔드포인트에서는 흔적을 남기지 않았을 수 있는 활동을 분석할 수 있습니다.

조사 과정에서 AI를 활용하는 방법

AI는 다음을 가속화할 수 있습니다:

  • 이벤트 정규화;
  • 경고 그룹화;
  • 타임라인 구축;
  • 위협 탐지(threat hunting)를 위한 쿼리 준비;
  • 지표 대조;
  • 이상 징후 탐지;
  • 대규모 로그 분석;
  • 중간 보고서 작성.

그러나 모델은 잠재적 피해가 큰 결정을 독자적으로 내려서는 안 됩니다.

안전한 프로세스에는 통제된 환경의 활용, 민감한 데이터의 최소화, 쿼리 및 응답의 로깅, 분석가에 의한 결론 검증, 그리고 각 가설을 원본 텔레메트리 데이터에 연계하는 것이 포함됩니다.

추가적인 협의 없이는 모델에게 중요 세그먼트의 중단, 계정 삭제, 비밀 정보의 대량 교체, 아티팩트 파기, 고객 대상 공지 게시 또는 정보 유출이 없다는 최종 결론을 내리는 작업을 위임해서는 안 됩니다.

AI는 조사 방향을 제안할 수 있습니다. 결론에 대한 책임은 여전히 인간에게 있습니다.

복구는 단순히 이전 상태로 되돌리는 것이 아닙니다

사고 발생 시 가장 위험한 문구는 다음과 같습니다.

“그냥 백업에서 전부 복원하면 되겠네요.”

이전의 아키텍처와 함께 기존 취약점, 유출된 기밀 정보, 구성 오류까지 그대로 복원한다면 공격자가 다시 침투할 수 있습니다.

안전한 복구는 단계적으로 수행됩니다:

  1. 깨끗한 관리 환경을 구축합니다.
  2. 신원 관리 권한을 되찾습니다.
  3. 초기 침투 경로를 차단합니다.
  4. 고정 메커니즘을 제거합니다.
  5. 비밀, 키, 토큰 및 인증서를 갱신합니다.
  6. 백업본을 확인합니다.
  7. 중요한 종속 관계가 복원됩니다.
  8. 시스템이 통제된 그룹별로 연결됩니다.
  9. 각 단계마다 보안 및 가동 상태를 점검합니다.
  10. 가동 후에도 강화된 모니터링이 지속됩니다.

비즈니스 소유자는 서비스의 기능성을 확인하고, 보안 팀은 지속적인 침해의 알려진 징후가 없는지 확인합니다.

시스템 가용성이 확보되었다고 해서 인시던트가 종료된 것은 아닙니다.

복구 과정에서 PWN-ALL은 깨끗한 백업본, 시스템 재구축 가능성, 사용 가능한 암호 해독 및 키 복구 옵션을 평가한 후, 인프라를 다시 가동할 우선 순위를 정합니다. 결과는 랜섬웨어 계열, 시스템 상태, 보존된 증거 및 백업 품질에 따라 달라지므로, 모든 데이터의 완전한 복호화 또는 복구는 보장될 수 없습니다.

조직이 몸값 지불을 고려하는 경우

랜섬웨어에 대한 전문적인 접근 방식은 어떠한 상황에서도 몸값 지불을 배제한다는 전제에서 출발해서는 안 됩니다.

때로는 경영진이 인명의 위협이나 안전 문제, 핵심 프로세스의 중단, 사용 가능한 백업의 부재, 비즈니스의 돌이킬 수 없는 손실 위험, 또는 장기간의 가동 중단으로 인한 극도로 높은 비용 등의 이유로 이를 고려하기도 합니다.

공식 권고 사항은 몸값 지불을 지지하지 않습니다. 몸값 지불은 데이터에 대한 접근 권한 회복, 악성 코드의 제거, 또는 도난당한 정보의 삭제를 보장하지 않기 때문입니다. 게다가 몸값을 지불한 조직은 다시 표적이 될 수 있습니다.

동시에 몸값 지불은 기술적 조치가 아니라 위기 상황에서 내려지는 예외적인 경영적 결정입니다.

먼저 대안을 검토해야 합니다

결정을 내리기 전에 다음 사항을 평가해야 합니다:

  • 백업의 유용성;
  • 부분적 복구 가능성;
  • 핵심 서비스의 재구축 가능성;
  • 임시 수동 프로세스;
  • 사용 가능한 복호화 도구의 유무;
  • 다른 소스에서 데이터를 복구할 수 있는 가능성;
  • 허용 가능한 비상 운영 기간.

악의적인 공격자가 제시하는 ‘지불이 유일한 해결책’이라는 주장은 독립적인 기술적 검증 없이는 받아들여서는 안 됩니다.

PWN-ALL은 인프라 및 백업의 실제 상태를 평가하고, 복호화 또는 키 복원의 가능성을 조사하며, 경영진에게 가능한 시나리오를 비교 분석하여 제시할 수 있습니다. 최종 결정권은 피해 조직의 권한을 위임받은 대표자에게 있습니다.

실제적인 결과를 파악해야 합니다

몸값 규모와 복구 비용만을 비교하는 것만으로는 충분하지 않습니다.

사람들에게 미치는 영향, 가동 중단 기간, 임시 프로세스의 안정성, 고객 및 파트너에 대한 영향, 데이터 유출 가능성, 안전한 복구 비용, 평판 손상을 고려해야 합니다.

결정은 단순한 약속이나 공격자의 카운트다운 타이머에만 의존해서는 안 되며, 검증된 사실에 근거해야 한다.

법적 및 제재 관련 제한 사항은 별도로 평가됩니다

수취인, 관련 조직, 중개자 또는 사용되는 결제 인프라는 제재 또는 기타 제한의 대상이 될 수 있습니다.

공식 제재 당국은 랜섬웨어 지불을 조장하는 기업에 대한 위험을 명시적으로 경고하고 있습니다. 따라서 어떠한 조치를 취하기 전에 자격을 갖춘 법률 및 제재 전문가들이 적용 가능한 제한 사항을 검토해야 합니다.

PWN-ALL은 프로세스의 기술적 측면을 담당합니다: 공격자의 인프라에 대한 데이터를 수집하고, 공격자의 주장을 검증하며, 통신 내용을 문서화하고, 해당 자료를 보험사 및 관련 전문가들에게 제공합니다. 법적 평가 및 거래 결정은 해당 조직과 그 권한을 위임받은 자문가들에게 달려 있습니다.

공격자와의 소통은 통제된 방식으로 이루어져야 합니다

갈취범과 독자적으로 서신을 주고받는 것은 개별 시스템의 취약성, 조직의 내부 상황 또는 조직의 역량 한계를 노출시킬 수 있습니다.

적절한 협의 하에 PWN-ALL은 통제된 의사소통을 지원하며 다음을 도울 수 있습니다:

  • 공격자가 주장한 데이터를 실제로 보유하고 있는지 확인하거나;
  • 테스트용 복호화를 요청하고;
  • 복호화기의 작동 상태를 평가하고;
  • 요구 사항의 기술적 타당성을 확인;
  • 추가 시간을 확보할 수 있도록;
  • 메시지 및 결정 사항의 전체 이력을 보존합니다.

이러한 지원은 법적 검토를 대체하지 않으며, 지불을 권장하는 것을 의미하지도 않고, DFIR 팀에게 고객을 대신하여 결정을 내릴 권한을 부여하지도 않습니다.

공격자의 주장은 반드시 검증해야 합니다

최종 결정에 앞서, 제한된 파일 세트에 대한 테스트 복호화, 주장된 데이터에 대한 접근 증거, 제안된 도구의 작동 확인을 요청할 수 있습니다.

그러나 검증이 성공적으로 이루어지더라도 완전한 복구가 보장되지는 않습니다.

공격자는 불안정한 복호화 도구를 전달하거나, 데이터의 일부만 복호화하거나, 훔친 정보를 보관하거나, 다른 참여자에게 정보를 전달하거나, 남아 있는 접근 권한을 통해 다시 침입할 수 있습니다.

제공받은 도구는 격리된 환경에서 분석하고 테스트해야 합니다.

협상은 수사를 중단시키지 않습니다

공격자와의 소통은 대응 조치를 대체하지 않습니다.

이와 병행하여 다음을 계속해야 합니다:

  • 위협 격리;
  • 초기 침투 경로 파악;
  • 침해된 세션의 종료;
  • 비밀 정보의 주기적 교체;
  • 백업 데이터 보호;
  • 증거 수집;
  • 클라우드 환경 점검;
  • 고정 메커니즘 탐색;
  • 안전한 복구 준비.

지급이 완료된 후에도 사고는 종결된 것으로 간주되지 않습니다. 시스템은 여전히 정리하거나 재구축해야 하며, 유출된 접근 데이터는 교체하고, 고정 메커니즘은 제거해야 합니다.

배상금은 위기 상황의 한 가지 요소를 바꿀 수는 있지만, 침해 자체를 제거하지도 않고 안전한 복구를 대체하지도 않습니다.

사고 발생 중에는 다음을 해서는 안 됩니다

계획 없이 전체 인프라를 중단해서는 안 됩니다

이는 휘발성 증거를 소멸시키고, 분석을 복잡하게 하며, 영향을 받지 않은 프로세스를 중단시킬 수 있습니다. 격리는 특정 지점이나 세그먼트 단위로 이루어져야 하며, 위험 평가를 기반으로 해야 합니다.

데이터 수집 전에 시스템을 재설치하는 것

급하게 포맷하면 공격자의 초기 접근, 정착 및 이동 흔적이 삭제됩니다.

악성코드를 제거한 후 승리를 선언하는 것

악성 파일은 수많은 도구 중 하나일 뿐일 수 있습니다. 신원, 클라우드 세션, 토큰, 원격 액세스, 이메일 규칙, SaaS 애플리케이션 및 관리 인프라를 반드시 확인해야 합니다.

비밀번호 변경을 완전한 차단으로 간주하기

공격자에게 활성 세션, 리프레시 토큰, OAuth 권한 또는 대체 MFA 방법이 남아 있을 수 있습니다.

침해된 통신 채널 활용

공격자는 팀 메시지를 읽거나, 전술을 조정하거나, 흔적을 지울 수 있습니다.

협박범과 직접 연락하기

준비되지 않은 소통은 협상 입지를 약화시키거나, 시스템의 취약점을 노출시키거나, 추가적인 법적 및 운영상의 위험을 초래할 수 있습니다.

침입 경로가 차단되기 전에 시스템을 복구하기

그렇지 않으면 복구 과정에서 또 다른 사고가 발생할 수 있습니다.

암호화가 없다는 것을 정보 유출이 없다는 것으로 간주

데이터 도난은 랜섬웨어의 전형적인 징후를 남기지 않고 합법적인 클라우드 서비스나 활성 사용자 세션을 통해 발생할 수 있습니다.

검증 없이 백업본을 신뢰하기

백업본은 가독성뿐만 아니라 무결성, 청결성, 그리고 저장된 고정 메커니즘이 없는지 여부도 확인해야 합니다.

확인되지 않은 결론을 공개하는 것

조사를 통해 확인되기 전까지는 유출이 없다는 것을 약속해서는 안 됩니다.

새로운 경보가 없다는 이유만으로 환경이 안전하다고 선언하기

사건이 발생하지 않았다고 해서 공격자가 없다는 뜻이 아니라, 가시성이 부족하다는 의미일 수 있습니다.

준비 상태를 측정하는 방법

해결된 경보의 수는 조직이 심각한 공격을 견뎌낼 수 있는 능력에 대해 거의 아무것도 말해주지 않습니다.

더 유용한 지표:

  • 사고 확인까지 걸린 시간;
  • 인시던트 지휘관(Incident Commander)이 지정되기까지 걸린 시간;
  • 첫 번째 격리 조치까지 걸린 시간;
  • 침해된 세션이 종료되기까지 걸린 시간;
  • 클라우드 로그 수신까지 소요된 시간;
  • 깨끗한 백업본 검증 소요 시간;
  • 충분한 텔레메트리 데이터를 보유한 중요 시스템의 비율;
  • 타임라인의 완전성;
  • 초기 공격 경로를 제거하는 데 소요된 시간;
  • 사후 검토(post-incident review) 후 이행된 조치의 비율.

속도뿐만 아니라 해결책의 질도 측정하는 것이 중요합니다:

  • 담당자가 지정되지 않은 상태에서 수행된 조치의 수;
  • 로그에 기록되지 않은 변경 사항의 수;
  • 어떤 증거가 분실되었는지;
  • 몇 개의 시스템을 재복구해야 했는지;
  • IR 계획의 어떤 가정이 틀렸는지.

사고 발생 후에는 형식적인 ‘면담 실시’ 문서가 아니라, 담당자, 기한 및 검증 기준이 명시된 구체적인 개선 계획이 필요합니다.

2026년 조직의 최소 준비 상태

사고 발생 전까지 회사는 다음을 갖추어야 합니다:

  • 승인된 IR 계획;
  • 역할 및 권한 매트릭스;
  • 오프라인 통신 채널;
  • 주요 시나리오별 별도 대응 매뉴얼;
  • 핵심 시스템 및 상호 의존성 지도;
  • 충분한 로그 보관 기간;
  • 변경 불가능하고 검증 가능한 백업 사본;
  • 증거 보존 절차;
  • 청정 관리 환경;
  • 외부 DFIR 팀의 연락처;
  • 내부 및 외부 메시지 템플릿;
  • 갈취자의 요구 사항 검토 절차;
  • 정기적인 테이블톱 및 기술 훈련.

기술 팀뿐만 아니라 다른 부서도 점검해야 합니다. 훈련에는 경영진, IT, 보안, 비즈니스 프로세스 소유자, 법무 및 커뮤니케이션 부서, 보험사, 주요 공급업체, 외부 DFIR 파트너가 참여해야 합니다.

시간적 제약이 있는 상황에서 단 한 번도 검증되지 않은 계획은 가정에 불과하며, 방어 수단이 될 수 없습니다.

대응이란 불확실성을 관리하는 것입니다

공격이 진행되는 동안 모든 해답을 즉시 얻는 경우는 드뭅니다.

강력한 팀은 절대적인 확신을 기다리지 않으면서도 동시에 무턱대고 행동하지 않습니다. 사실과 가설을 구분하고, 가능한 경우 되돌릴 수 있는 결정을 내리며, 파괴적인 조치를 조율하고, 증거를 보존하며, 통일된 타임라인을 유지하고, 기술적 및 비즈니스 위험을 병행하여 관리합니다.

사고를 완전히 예측 가능하게 만들 수는 없습니다.

하지만 팀의 업무는 예측 가능하게 만들 수 있습니다.

외부 대응 팀이 필요한 경우

PWN-ALL은 속도, 증거 보존, 통제된 복구가 중요한 사고에 대응합니다:

  • 랜섬웨어 및 암호화 없는 갈취;
  • 데이터 유출 및 공개;
  • BEC 및 기업 이메일 침해;
  • 계정 탈취;
  • Microsoft 365 및 Google Workspace 침해;
  • 클라우드 인프라 공격;
  • 웹 애플리케이션 및 서버 해킹;
  • 공급업체 및 하청업체를 통한 사고.

업무에는 긴급 대응, 디지털 포렌식, 침해 범위 파악, 증거 수집 및 보존, 복호화 방안 검토, 백업 확인, 통제된 통신에 대한 기술 지원, 안전한 복구, 보고서 작성 및 후속 보안 강화 등이 포함될 수 있습니다. PWN-ALL은 진행 중인 사고에 대해 별도의 24시간 대응 프로세스를 운영하고 있습니다.

사고 발생 시:

영향을 받은 시스템을 끄지 말고, 증거물을 삭제하지 말고, 공격자에게 직접 응답하지 말고, 초기 평가가 완료되기 전까지 대대적인 복구를 시작하지 마십시오.

첫 번째 과제는 조사, 의사 결정 및 비즈니스의 안전한 정상화 운영에 필요한 정보를 훼손하지 않으면서 공격자의 활동을 제한하는 것입니다.