삭제한 내용은 파일 안에 여전히 남아 있습니다

2026년 9월 25일, Microsoft는 Storm-3168으로 추적하는 침입에 대한 보고를 발표했습니다. 이 침입은 JADEPUFFER가 실행한 것으로, Sysdig가 2026년 7월에 발견하고 최초로 문서화된 agentic ransomware operation이라고 보고한 행위자입니다. 이 글의 대부분은 클라우드 테넌트 내부에서 기계 속도로 무슨 일이 일어났는지에 관한 것입니다. 약 15시간 30분 동안의 열거, 300건이 넘는 성공적인 읽기 작업, 그 다음에는 약 7분 동안 이어진 파괴적 시퀀스가 있었고, 여기에는 스토리지 계정을 삭제하려는 100건이 넘는 시도가 포함되었습니다.

가져갈 만한 부분은 그 모든 일보다 앞선 시작 부분에 있습니다.

공격자는 서비스 프린시펄의 client ID, client secret, tenant ID를 가지고 있었습니다. 이 값들은 영향을 받은 조직의 직원이 공개 GitHub issue에 평문으로 게시한 것이었습니다. Microsoft의 표현에 따르면, "issue는 나중에 secret을 제거하도록 수정되었지만, secret은 issue의 공개 편집 기록을 통해 계속 접근 가능했다".

관련된 누구도 특별한 일을 하지 않았습니다. issue tracker가 편집 기록을 보관하는 이유는 사람들이 스레드가 어떻게 바뀌었는지 보고 싶어 하기 때문입니다. secret을 제거한 사람은 그것을 보기에서 제거했습니다. 컨테이너에서 제거하는 것은 다른 작업이며, 그 작업에는 버튼이 없습니다.

문서도 같은 방식으로 동작합니다

이것은 issue tracker의 속성이 아닙니다. 자기 자신의 기록을 저장하는 모든 것의 속성이며, 조직이 사용하는 문서 형식은 설계상 기록으로 가득합니다.

추적된 삭제는 폐기되지 않고 저장됩니다. 변경 내용 추적을 켠 상태에서 Word 문서의 단락을 삭제하면, 나중에 검토하거나 복원할 수 있도록 해당 텍스트가 수정 표시로 파일 안에 남습니다. 이것이 바로 이 기능의 목적입니다. 수정 내용이 그대로 들어 있는 상태로 파일이 밖으로 나가는 순간, 그것은 더 이상 기능이 아닙니다.

해결된 댓글도 여전히 댓글입니다. 검토자의 메모를 해결 처리하면 처리되었다고 표시됩니다. 그렇다고 메모 자체나, 작성자의 이름이나, 누군가가 이의를 제기한 시점을 보여 주는 타임스탬프가 사라지는 것은 아닙니다.

자르기는 표시 지시일 뿐입니다. 사진의 가장자리에 있던 내용을 없애기 위해 이미지를 자르면, 기본적으로 원본 이미지 데이터는 파일에 그대로 남습니다. 자르기는 애플리케이션에 어떤 부분을 표시할지 알려 줄 뿐입니다. Office가 별도의 압축 옵션을 제공하는 이유도, 잘라낸 영역을 삭제하는 것은 누군가가 명시적으로 선택해야 하는 별개의 작업이기 때문입니다.

PDF는 다시 쓰기보다 추가 쓰기를 허용합니다. 이 형식은 증분 업데이트를 허용합니다. 변경 사항을 파일 끝에 기록할 수 있으므로 이전 객체는 그대로 남습니다. 이것이 전체 문서를 다시 쓰지 않고도 서명과 주석이 동작하는 방식입니다. 눈에 보이는 결과는 새 버전입니다. 이전 버전도 같은 파일 안에 여전히 있을 수 있습니다.

검은 사각형은 사각형일 뿐입니다. 이름 위에 채워진 도형을 그리면 읽는 사람에게는 가려지지만, 그 외의 누구에게도 가려지지 않습니다. 아래의 텍스트 객체는 여전히 텍스트이며, 여전히 선택 가능하고, content stream을 읽는 어떤 라이브러리로도 추출할 수 있습니다.

이 중 어느 것도 난해한 내용이 아니며, 취약점도 아닙니다. 이런 동작은 모두 누군가가 합리적인 이유로 원했기 때문에 존재합니다. 그리고 이것들이 모여 릴리스 프로세스가 거의 고려하지 않는 하나의 사실을 만듭니다. 당신이 보내는 문서는 당신이 보고 있는 문서가 아닙니다.

송신 단계의 통제가 이를 잡아내지 못하는 이유

조직을 떠나는 문서를 실제로 검사하는 것이 무엇인지 물어보십시오.

데이터 손실 도구는 패턴을 일치시키는데, 주로 파일이 보여 주는 텍스트, 즉 계좌 번호, 주민등록번호, 분류 표시, 키워드를 대상으로 합니다. 사람 검토자는 파일을 열어 렌더링된 페이지를 읽습니다. 승인 워크플로는 특정 이름의 사람이 자신이 본 내용에 대해 승인했다는 기록을 남깁니다.

이들 모두는 보기를 읽고 있습니다. 보기는 제거된 콘텐츠가 절대 존재하지 않는다고 보장되는 유일한 장소입니다. 보기에 없다는 것이 바로 모두가 달성하려고 했던 제거의 정의이기 때문입니다.

민간요법 같은 방법도 있고, 그 점은 솔직하게 말할 가치가 있습니다. 평면화된 PDF로 내보내면 이런 자료의 상당 부분이 실제로 사라집니다. 그래서 많은 릴리스 프로세스가 print-to-PDF 단계로 끝납니다. 하지만 동시에 작업 파일도 파괴합니다. 수식, 레이어, 좌표, 하위 시스템이나 상대방의 자체 도구가 필요로 하는 구조까지 사라집니다. 예측 가능한 결과는 수신자가 원본을 요청하게 되고, 그 원본이 평면화 단계가 대신하고 있던 통제 밖으로 보내진다는 것입니다.

APAC 관점

두 지역은 그 결과를 분명하게 보여 주며, 어느 쪽도 발신자의 의도에는 관심이 없습니다.

Singapore. Personal Data Protection Act는 보호 의무를 조직에 부과하며, 조직이 보유하거나 통제하는 personal data를 포함합니다. 또한 무단 공개는 누군가 공개하려는 의도가 있었는지와 무관하게 무단 공개입니다. 수정 이력에 이전 입찰자의 수치가 들어 있는 입찰 응답은 그 수치를 공개한 것입니다.

South Korea. 개정 Personal Information Protection Act는 2026년 3월 Act No. 21445로 공포되었고, 주요 조항은 2026년 9월 11일에 시행되었습니다. Hunton Andrews Kurth가 개정안 분석에서 보고했듯이, 중대한 위반 사례에서는 회사 총매출의 최대 10%까지 행정 벌금을 부과할 수 있도록 하며, 이는 조직이 문서에 그대로 두려는 personal data의 양에 대한 계산을 바꿉니다. 특정 controller에 대해 ISMS-P certification을 의무화하는 조항은 2027년 7월 1일부터 적용되며, 이는 기술적 보호조치를 주장하는 것이 아니라 입증할 수 있어야 하는 시점에 기한을 부여합니다.

더 자세한 control 매핑은 국가 페이지에서 확인할 수 있습니다. Singapore 및 South Korea.

무엇이 도움이 되고, 무엇은 그렇지 않은가

control은 view가 아니라 file layer에서 작동해야 합니다. 실제로는 두 가지를 의미합니다.

첫째는 형식이 기본적으로 보존하는 것, 즉 metadata, revision history, comments, document properties를 제거하는 것입니다. Glasswall Find and Redact는 문서가 저장되거나 공유되기 전에 명명된 데이터 패턴을 제거하며, 이는 조직이 사전에 설명할 수 있는 콘텐츠를 다룹니다.

둘째는 재생성입니다. Content Disarm and Reconstruction은 파일을 구성 요소로 분해하고, 각 부분을 제조업체가 공개한 specification과 대조해 검증한 다음, 그 중간 표현으로부터 새 파일을 만듭니다. 원본 바이트는 통과하지 않으며, 이것이 rebuild와 clean-up의 차이입니다. 또한 출력물이 specification에 없는 구조를 물려받지 않는 이유이기도 합니다.

이제 솔직한 한계를 말하겠습니다. 사람들이 자신의 control을 과신한다고 지적하는 글이 끝에서 우리 것을 과신하라고 요구해서는 안 되기 때문입니다. 어느 control도 무엇이 sensitive한지 결정하지 않습니다. 절대 작성되었어서는 안 될 눈에 보이는 문단은 사람의 문제이며, 그대로 남습니다. 문서에서 personal data를 제거하는 것은 어떤 법적 의미에서도 anonymisation이 아니며, 누구도 그것을 마치 그런 것처럼 regulator에게 제시해서는 안 됩니다. 그리고 control은 결국 자신을 통해 라우팅된 파일에만 도달하며, 대부분의 조직에서는 그 범위가 도표가 시사하는 것보다 더 작습니다.

제거되는 것은 아무도 거기에 있는 줄 몰랐던 부분입니다. 문서가 실제로 조직을 떠나는 방식을 보면, 바로 그 부분이 원래 있어서는 안 될 곳에 도착하곤 합니다.

릴리스 프로세스를 책임지는 사람에게 던질 만한 질문은 이번 주 안에 답할 수 있을 만큼 충분히 좁습니다. 문서가 나갈 때 무엇이 그것을 검사합니까, 그리고 그 검사는 파일을 읽습니까, 아니면 페이지를 읽습니까?