가짜 Mac 충돌 보고서가 암호를 요구한다면 절대 입력하지 마세요

Mac 화면에 시스템 충돌 보고서와 똑같이 생긴 창이 떠서, 사라지기 전에 로그인 암호를 입력하라고 요구합니다. 입력하지 마십시오. 2026년 7월, Jamf Threat Labs는 CrashStealer라고 이름 붙인 macOS 인포스틸러에 대한 분석을 공개했습니다. 이 악성코드가 하는 일이 정확히 그것입니다. 평범한 macOS 시스템 도구인 척하면서, 사용자가 건네준 암호를 그대로 수집합니다. 이미 암호를 입력하셨다면 이 페이지 아래쪽의 대응 런북으로 바로 넘어가 순서대로 진행하십시오.

이 사건은 특이한 제로데이 취약점에 관한 이야기가 아닙니다. 해킹당한 것도 없고, 보안 결함이 악용된 것도 아니며, 어떤 업데이트로도 막을 수 없었을 공격입니다. 이 공격 전체는 단 하나에 기대고 있습니다. 대부분의 Mac 사용자는 수년간의 정상적인 사용 경험을 통해, macOS가 띄운 것처럼 보이는 창이라면 어디든 암호를 입력하도록 길들여져 있다는 사실입니다. CrashStealer는 그럴듯한 창을 그려낼 뿐이고, 나머지는 사용자가 알아서 합니다.

그래서 이 문제는 소프트웨어가 아니라 지식으로 실제 해결할 수 있는 문제입니다. 아래에서는 대부분의 기사에서 찾아볼 수 없는 두 가지를 다룹니다. 진짜 macOS 인증 요청창과 앱이 그려낸 모조품을 구별하는 실전적인 방법, 그리고 이미 암호를 입력했다는 사실을 깨달은 순간을 위한 침착하고 순서가 정해진 대응 런북입니다. 앞부분은 예방에 관한 내용이고, 뒷부분은 새벽 2시의 피해 통제에 관한 내용입니다. 사람들이 이 사실을 깨닫는 시각은 대개 그때쯤입니다.

핵심 요약

• 진짜 macOS 충돌 보고 도구는 절대 암호를 요구하지 않습니다. 충돌 보고서, 진단 도구, 시스템 업데이터를 자처하는 창이 로그인 암호를 요구한다면, 그 창은 macOS가 아니라 어떤 응용 프로그램이 그린 것입니다.
• 픽셀보다 맥락이 중요합니다. 마음먹은 공격자는 스크린샷과 구별되지 않는 완벽한 모조품을 만들 수 있습니다. 하지만 위조할 수 없는 것이 하나 있습니다. 진짜 요청창이 나타나는 이유입니다. 진짜 macOS 인증 대화상자는 사용자가 방금 취한 동작에 뒤따라 나타납니다. 아무 맥락 없이 불쑥 나타난 요청창은 여러분이 가진 가장 강력한 경고 신호입니다.
• 공증(notarization)은 보안 감사가 아닙니다. Jamf Threat Labs의 보고에 따르면 CrashStealer를 유포한 응용 프로그램은 유효한 Apple Developer ID로 서명되고 공증되어 있었으며, 그래서 Gatekeeper를 통과했습니다. Apple은 이후 해당 인증서를 폐기했지만, 폐기는 예방이 아니라 사후 정리입니다.
• 암호를 입력했다면 로그인 Keychain도 함께 뚫렸다고 가정하십시오. Jamf의 보고에 따르면 이 악성코드는 입력된 암호를 로컬에서 검증하고, 암호가 맞으면 그것으로 로그인 Keychain을 잠금 해제해 입력한 것보다 훨씬 더 많은 것에 접근할 수 있습니다.
• 복구 순서가 중요합니다. 감염되지 않은 다른 신뢰할 수 있는 기기에서 Apple Account 암호를 먼저, 그다음 비밀번호 관리자의 마스터 암호, 그다음 이메일, 그다음 금융, 그다음 나머지 전부 순으로 처리하십시오. 암호화폐 시드 구문은 이미 소실된 것으로 취급하십시오.

Jamf Threat Labs가 실제로 보고한 내용

Jamf Threat Labs는 2026년 7월 중순에 CrashStealer 분석을 공개했고, 이후 며칠에 걸쳐 9to5Mac, MacRumors, Help Net Security, Malwarebytes, Infosecurity Magazine, SecureMac 등이 이를 인용해 보도했습니다. 실제로 보고된 내용과 이후 모호한 경고문으로 바뀌어 퍼진 내용을 구분해 볼 필요가 있습니다.

유포 경로: 내가 찾던 것이 아닌 디스크 이미지

Jamf의 분석 글에 따르면 이 악성코드는 Werkbit Setup이라는 이름의 디스크 이미지 안에 담겨 전달됩니다. 피해자는 DMG를 마운트하고, 자신이 찾던 소프트웨어라고 믿는 것을 설치합니다. 이 단계에서는 아무것도 이상해 보이지 않습니다. 이 단계에서는 아직 아무것도 이상한 것을 요구하지 않기 때문입니다.

여기서 중요한 단서는 이름의 불일치입니다. 여러분이 검색한 것은 A인데, 다운로드 폴더에 도착한 디스크 이미지의 이름은 B입니다. 이 간극은 무언가가 실행되기 전에 얻을 수 있는 몇 안 되는 신뢰할 만한 신호이며, 습관으로 만들어 둘 가치가 있습니다. Finder 사이드바에 표시된 디스크 이미지의 이름을 먼저 읽고 나서 그 안의 것을 밖으로 끌어내십시오.

미끼: 스스로를 CrashReporter라 부르는 앱

Jamf의 보고에 따르면 설치가 끝나면 이 악성 응용 프로그램은 스스로를 CrashReporter.app으로 내세우며, 정상적인 macOS 시스템 구성 요소의 이름과 전반적인 외형을 그대로 빌려 씁니다. 그리고 정식 macOS 시스템 대화상자처럼 꾸민 암호 입력 요청창을 표시합니다.

이것이 좋은 위장인 데에는 구체적인 이유가 있습니다. 충돌 보고서는 macOS가 사용자의 요청 없이 스스로 띄우는 몇 안 되는 창 중 하나입니다. 앱은 실제로 충돌하고, macOS는 실제로 보고를 제안하며, 대부분의 사용자는 그 대화상자를 자세히 읽지도 않고 수십 번 닫아 왔습니다. 이 악성코드는 그 익숙함을 빌려 씁니다. 예상치 못한 시스템 창이 떠도 이상하게 느껴지지 않을 순간을 골라 나타나서, 진짜 대화상자는 절대 요구하지 않는 단 한 가지를 요구합니다.

암호를 입력하면 벌어지는 일

이 부분이 CrashStealer를 단순한 피싱 창보다 훨씬 나쁘게 만듭니다. Jamf의 보고에 따르면 이 악성코드는 입력된 암호를 로컬에서 검증하며, 암호가 맞으면 그것으로 로그인 Keychain을 잠금 해제할 수 있습니다.

이것이 실제로 무엇을 의미하는지 생각해 보십시오. 여러분이 입력한 암호 자체가 전리품이 아닙니다. 그것은 나머지 모든 것이 들어 있는 금고의 열쇠입니다. 로그인 Keychain은 macOS가 Wi-Fi 암호, 앱 자격 증명, 인증서, 보안 메모를 저장하는 곳이며, 많은 사람에게는 저장된 웹사이트 로그인 정보가 길게 쌓여 있는 곳이기도 합니다. Keychain을 잠금 해제하는 순간, 훔친 문자열 하나가 전체 자격 증명 덤프로 바뀝니다.

보고된 표적 목록도 이와 정확히 들어맞습니다. 브라우저에 저장된 자격 증명, 비밀번호 관리자 데이터, 브라우저 지갑 확장 프로그램을 포함한 암호화폐 지갑 데이터, 그리고 로그인 Keychain 내용입니다. 저희가 Mac 암호는 단순한 화면 잠금이 아니라고 계속 강조하는 이유가 궁금하셨다면, 바로 이것이 그 이유입니다. Mac 암호는 자격 증명 트리의 뿌리에 있습니다. 악의적이지 않은 평상시 상황에서 그 Keychain이 계정 암호와 얼마나 단단히 묶여 있는지는 macOS가 로그인 Keychain 암호를 계속 요구하는 이유 가이드에서 설명합니다.

알아 둘 만한 두 가지 기술적 특징

Jamf는 디스어셈블러를 만질 일이 없는 사람에게도 방어 관점에서 의미가 있는 두 가지 특성을 짚었습니다.

첫째, CrashStealer는 네이티브 **C++**로 작성되었습니다. 지난 몇 년간 등장한 Mac 스틸러 상당수는 AppleScript에 크게 의존했습니다. AppleScript는 상대적으로 들여다보기 쉽고, 보안 도구가 패턴으로 잡아내기 쉬우며, macOS 자체가 자동화 권한으로 통제하기도 쉽습니다. 네이티브 바이너리는 생태계가 편안하게 의존해 온 탐지 방식의 한 범주를 통째로 우회합니다. 일반 사용자에게 주는 실질적 교훈은 이렇습니다. "악성 앱은 자동화 권한을 요구한다" 같은 경험칙은 기댈 수 있는 규칙이 아닙니다.

둘째, 그리고 더 중요하게도, 유포에 사용된 응용 프로그램은 유효한 Apple Developer ID로 서명되고 공증되어 있었습니다. 그래서 Gatekeeper는 대부분의 사람이 신뢰할 수 없는 소프트웨어에서 겪는 마찰 없이 이 앱을 통과시켰습니다. 이 이야기는 뒤에서 다시 다루겠습니다. "그래도 공증받았잖아"라는 말이 많은 사람의 위협 모델에서 근거 없이 너무 많은 일을 떠맡고 있기 때문입니다.

시간 흐름

Jamf에 따르면 미완성이거나 아직 개발 중인 것으로 보이는 초기 샘플은 2026년 5월경에 나타났습니다. 실제로 동작하는 실전 배포 버전은 2026년 7월 초에 탐지되었고, 공개 분석은 7월 13일에서 15일경에 뒤따랐습니다.

미완성 샘플과 실전 배포 사이의 두 달 간격은 흔한 일이며, 공개된 분석 하나를 이야기의 끝으로 여기지 말아야 할 이유이기도 합니다. 스틸러는 계속 개량됩니다. 디스크 이미지 이름, 앱 이름, 요청창의 정확한 문구는 이 작전에서 가장 쉽게 갈아치울 수 있는 부분입니다. 지속되는 것은 기법이고, 배워 둘 가치가 있는 것도 기법입니다.

핵심 개념: 암호 요청창은 증거가 아니라 주장입니다

체크리스트로 넘어가기 전에, 그 모든 항목을 기억하기 쉽게 만들어 주는 개념 하나를 짚고 가겠습니다.

화면에 나타나 암호를 요구하는 창은 자신이 누구인지에 대해 하나의 주장을 하고 있습니다. macOS라고 주장하는 것입니다. 창의 외형 중 어떤 것도 그 주장을 입증하지 못합니다. 화면에 무언가를 그릴 권한이 있는 응용 프로그램이라면 무엇이든 그릴 수 있고, 여기에는 시스템 대화상자의 완벽한 복제본도 포함되기 때문입니다. 서체, 여백, 자물쇠 아이콘, 배경 재질의 정확한 색조, 버튼 배치, 구석의 작은 앱 아이콘까지 전부 그저 픽셀일 뿐이고, 전부 복제 가능합니다.

그러므로 질문은 결코 "이게 진짜처럼 보이는가?"가 아닙니다. 질문은 "진짜라면 지금 여기 나타날 이유가 있는가?"입니다.

이 관점의 전환이 이 글의 나머지 전부가 딛고 선 토대입니다. 시각적 점검에도 여전히 가치가 있고, 아래에는 허술한 위조품을 실제로 잡아내는 구체적인 확인법이 있습니다. 하지만 시각적 점검은 필터이지 판결이 아닙니다. 판결을 내리는 것은 맥락입니다.

시각적 감별: 진짜 macOS 요청창 대 앱이 그린 가짜

실제로 확인할 수 있는 항목들을, 각 항목에 얼마만큼의 비중을 둘 만한지 대략적인 순서로 정리했습니다.

1. 인증이 필요한 동작을 방금 하셨습니까?

이것이 압도적으로 가치가 높은 확인법이며, 비용은 전혀 들지 않습니다.

진짜 macOS 인증 요청창은 결과물입니다. 무언가를 설치했습니다. System Settings에서 자물쇠가 달린 설정을 변경했습니다. 시스템 확장을 승인했습니다. 상위 권한이 필요한 명령을 실행했습니다. Keychain 항목을 잠금 해제했습니다. 네트워크 설정을 변경했습니다. 이 모든 경우에 여러분은 1~2초 전에 의도적인 동작을 수행했고, 요청창은 그 동작을 명시합니다.

macOS는 정상 작동 중에 여러분이 웹 페이지를 읽거나 동영상을 보고 있을 때 스스로 판단해 로그인 암호를 요구하지 않습니다. 암호 요청창이 나타났는데 그것을 유발한 방금 전의 동작을 짚어낼 수 없다면, 그렇지 않다는 것이 증명되기 전까지 적대적인 것으로 취급하십시오. "아마 괜찮겠지"가 아닙니다. 적대적입니다.

여기서 따라 나오는 결론은 불편하지만 사실입니다. 이 점을 아는 공격자는 여러분이 한 동작에 맞춰 가짜 요청창의 타이밍을 잡으려 할 것이고, 그 동작은 대개 자신들의 앱을 설치한 직후입니다. 방금 다운로드한 소프트웨어를 연 직후에 나타난 요청창은 안심할 만한 맥락이 아닙니다. 그 순간이 바로 CrashStealer의 요청창이 나타나는 순간입니다.

2. 지금 요구하는 그것이 요구할 자격이 있습니까?

일부 시스템 구성 요소는 일상적으로 암호를 요구합니다. 일부는 절대 요구하지 않습니다.

macOS 충돌 보고 도구는 확실하게 "절대 요구하지 않음" 범주에 속합니다. 앱이 충돌하면 진짜 대화상자는 앱이 예기치 않게 종료되었다고 알리고, 다시 열거나, 무시하거나, Apple에 보고서를 보낼 것을 제안합니다. 이 대화상자는 암호가 필요 없습니다. Apple에 충돌 로그를 보내는 데 관리자 권한이 필요하지 않기 때문입니다. 진짜 충돌 보고 도구가 인증을 요구하는 구성은 존재하지 않습니다.

단순히 정보를 보여 주기만 하는 대부분의 창에도 같은 원칙이 적용됩니다. 앱이 충돌했다고 알리는 창, 사용 가능한 업데이트에 관한 알림, 문서 저장에 실패했다는 대화상자, 드라이브 연결이 끊겼다는 메시지 등은 어느 것도 로그인 암호를 요구할 정당한 이유가 없습니다. 정보성 메시지가 갑자기 인증 요청으로 바뀐다면, 문제가 있는 것은 여러분의 Mac이 아니라 그 창입니다.

실제로 암호를 요구하는 범주는 이렇습니다. 홈 폴더 바깥에 파일을 쓰는 소프트웨어 설치, System Settings에서 자물쇠가 걸린 패널 잠금 해제, 커널 확장이나 시스템 확장 승인, FileVault나 시동 보안 설정 변경, 그리고 특정 저장 항목에 대한 Keychain 접근입니다. 눈앞의 창이 이 중 어느 것도 하고 있지 않다면, 그 창은 요구해서는 안 됩니다.

3. 실제로 어느 앱이 요구하는지 밝혀내십시오

가짜 요청창에도 그것을 띄운 프로세스가 있습니다. 요청창이 화면에 떠 있는 동안 그 프로세스를 찾아낼 수 있습니다.

메뉴 막대를 확인하십시오. 포인터를 화면 맨 위로 옮기십시오. Apple 메뉴 옆의 응용 프로그램 이름이 현재 최전면에 있는 앱을 알려 줍니다. 시스템 대화상자를 자처하는 창이 떠 있는데 메뉴 막대에 방금 다운로드한 어떤 앱의 이름이 표시된다면, 답은 나왔습니다.

Command-Tab을 눌러 보십시오. 요청창에서 다른 곳으로 전환할 수 있고 그 창이 여느 일반 앱 창처럼 다른 창 뒤로 물러난다면, 그것은 앱에 속한 창입니다. 일부 진짜 시스템 대화상자는 모든 것 위에 떠 있습니다. 앱이 그린 가짜는 그렇지 못한 경우가 많고, 떠 있는 경우에는 다른 방식으로 정체를 드러냅니다.

Force Quit을 여십시오. Command-Option-Escape를 누르십시오. Force Quit(강제 종료) 창은 실행 중인 응용 프로그램을 이름으로 나열합니다. 알아볼 수 없는 것, 요청창이 뜬 것과 같은 시점에 목록에 나타난 것, 이름이 시스템 구성 요소와 수상할 정도로 비슷한 것을 찾으십시오. 문제의 앱을 종료하면 대개 요청창이 사라지는데, 그것 자체가 여러분이 찾던 확증입니다.

Activity Monitor를 여십시오. Applications > Utilities > Activity Monitor는 백그라운드 프로세스를 포함한 더 긴 목록을 보여 줍니다. CPU나 프로세스 이름으로 정렬해 최근에 등장한 항목을 살펴보십시오. Force Quit보다 손이 많이 가고 헛짚기도 쉽습니다. macOS 자체가 이상한 이름의 백그라운드 프로세스를 정상적으로 많이 실행하기 때문입니다. 다만 Force Quit에서 아무것도 나오지 않을 때 들여다볼 곳이 바로 여기입니다.

솔직한 한계도 있습니다. 잘 만든 가짜는 프로세스 이름을 무해하게 지을 수 있고, 여러분이 수백 개의 정상 프로세스 사이에서 악성 이름을 반드시 알아본다는 보장도 없습니다. 이 확인법은 게으른 가짜는 확실히 잡아내고, 정교한 가짜는 가끔 잡아냅니다.

4. 드래그 테스트

이 방법은 정말로 유용하며, 한 방향으로만 작동합니다.

요청창을 화면 이곳저곳으로 끌어 보십시오. 화면 가장자리 끝까지 밀거나, 보조 디스플레이가 있다면 그쪽으로 옮겨 보십시오. 진짜 시스템 대화상자는 그 자체가 독립된 창이므로 데스크탑 어디로든 옮길 수 있습니다. 반면 다른 창 안쪽에 그려진 가짜는 부모 창의 경계를 벗어나지 못합니다. 웹 페이지, Electron 앱, 전체 화면 뷰 안에 사는 가짜가 흔히 이렇습니다. 요청창이 잘리거나, 원위치로 튕겨 돌아가거나, 다른 앱의 창에 해당하는 사각형 밖으로 나가기를 거부한다면 그것은 가짜입니다. 예외 없습니다.

한 방향으로만 작동한다는 뜻은 이렇습니다. 요청창이 화면 어디로든 자유롭게 끌린다고 해서 아무것도 증명되지 않습니다. 네이티브 앱은 시스템 대화상자와 똑같이 움직이는 테두리 없는 부동 창을 만들 수 있습니다. 드래그 테스트를 통과했다고 무죄가 확정되는 것은 아닙니다. 실패하면 유죄가 확정되는 것입니다.

관련된 변형도 있습니다. 창 크기를 조절해 보거나, 담긴 내용에 비해 크기가 미묘하게 어긋난 창이 있는지 살펴보십시오. 웹 뷰로 만든 가짜는 디스플레이 해상도를 바꾸거나 배율이 다른 디스플레이 사이를 오갈 때 이상하게 확대·축소되는 경우가 있습니다.

5. 타이핑 대신 Touch ID를 사용하십시오

Mac에 Touch ID가 있고 여러분이 실제로 시작한 동작에 대해 인증을 요구받고 있다면, 키보드 대신 지문 센서를 사용하십시오.

Touch ID를 시각적으로 흉내 낼 수 없어서가 아닙니다. 앱은 Touch ID 스타일의 요청창을 표시할 수 있습니다. Touch ID가 도움이 되는 이유는 더 직접적입니다. 지문 인증은 여러분의 암호를 앱에 넘기지 않습니다. 진짜 Touch ID 인증은 Secure Enclave를 통해 이루어지고 요청한 프로세스에는 예/아니오 답만 돌아갑니다. 아무것도 암호를 입력하지 않으므로 아무것도 암호를 가로챌 수 없습니다. 그 창이 가짜였다면, 여러분은 그 창이 자격 증명으로 바꿔 쓸 수 없는 지문 스캔 하나를 준 셈입니다.

여기에는 두 번째 신호도 있습니다. Mac에서 평소 Touch ID를 제안하는 동작을 하고 있는데 유독 이 요청창만 Touch ID 선택지 없이 암호 입력을 고집한다면, 그 이유를 자문해 보십시오. 진짜 요청창 중에도 암호 입력을 요구하는 것이 있으므로 이것은 적색이 아니라 황색 신호이지만, 다른 확인법과 겹치면 의미가 쌓입니다.

6. Escape를 누른 뒤 무슨 일이 벌어지는지 보십시오

Escape를 누르거나 취소를 클릭하십시오. 그리고 지켜보십시오.

진짜 인증 요청창은 깔끔하게 취소되고, 여러분이 수행하던 동작은 납득이 가는 방식으로 실패합니다. 설정 패널을 잠금 해제하려 했다면 그 패널은 잠긴 채로 남습니다. 무언가를 설치하려 했다면 설치 프로그램이 계속할 수 없다고 알립니다.

가짜는 대개 계속 조릅니다. 몇 초 뒤에 다시 나타나거나, 데스크탑을 클릭할 때마다 다시 나타나거나, 다음 로그인에 다시 나타나거나, 아예 완전히 사라지지 않습니다. 취소에도 굴하지 않는 집요함은 강력한 단서입니다. 이 악성코드의 가치 전부가 결국 암호를 받아내는 데 달려 있기 때문입니다. 계속 묻도록 만들어져 있습니다. 진짜 시스템 대화상자는 그러지 않습니다.

이 확인법에는 대가가 따릅니다. 다시 나타나는지 보려면 기다려야 하고, 그동안 여러분은 원치 않는 무언가가 실제로 돌아가고 있을지 모르는 Mac 앞에 앉아 있게 됩니다. 이 방법을 쓰되, 네트워크 차단을 대신하는 용도로는 쓰지 마십시오.

7. 문구를 읽되 비중은 낮게 두십시오

허술한 가짜는 여러 가지를 틀립니다. macOS라면 특정 앱이나 특정 동작의 이름을 명시할 자리에 들어간 일반적인 문구, 살짝 어긋난 대소문자, 지금 사용 중인 것과 맞지 않는 버전 번호나 제품명, 기계 번역처럼 읽히는 문법, macOS 관례와 어긋난 버튼 순서, 현재 시스템 아이콘보다 살짝 옛 버전인 아이콘 같은 것들입니다.

이 모든 것은 눈여겨볼 가치가 있지만, 어느 것도 의지할 가치는 없습니다. 시스템 대화상자의 타이포그래피는 스크린샷 한 장과 반나절의 시간이 있는 공격자에게는 이미 해결된 문제입니다. 문구의 어색함은 다른 확인법으로 넘어갈 근거로 삼으십시오. 최후의 방어선으로 삼아서는 안 됩니다.

시각적 점검의 한계를 솔직하게 인정하십시오

위의 모든 확인법은 충분히 세심한 공격자라면 무력화할 수 있습니다. 그럴듯한 순간에 나타나고, 자유롭게 끌리며, 정확한 문구를 쓰고, 취소하면 사라지는 잘 만든 네이티브 가짜는 이 글의 모든 시각적 테스트를 통과할 것입니다.

그렇다고 확인을 건너뛰라는 뜻은 아닙니다. 이 확인법들이 무엇을 위한 것인지 이해하라는 뜻입니다. 이들은 현실에서 마주치는 가짜의 대다수를 잡아냅니다. 대다수는 무한한 공을 들여 만들어지지 않기 때문입니다. 다만 그 아래에 깔린 층, 공격자의 솜씨에 좌우되지 않는 층은 행동에 관한 것입니다.

솜씨에 좌우되지 않는 행동 규칙

다음은 가짜가 완벽할 때에도 성립하는 규칙들입니다.

규칙 1: 내가 불러내지 않은 요청창에는 절대 암호를 입력하지 마십시오. 그것을 유발한 동작을 짚어낼 수 없다면 답은 "아니오"입니다. "좀 더 자세히 보자"가 아닙니다. 아니오입니다.

규칙 2: 의심스러우면 취소하고 스스로 의도적으로 다시 시작하십시오. 정말로 무언가를 승인해야 한다면, 요청창을 닫고, 앱을 종료하고, 신뢰하는 경로에서 그 동작을 직접 시작하십시오. System Settings를 직접 열어 자물쇠를 클릭하십시오. 설치 프로그램을 Finder에서 직접 실행하십시오. 그 결과로 요청창이 방금 클릭한 동작의 직접적인 결과로 나타난다면, 그것이 진짜일 가능성은 훨씬 높습니다. 남이 건네준 맥락을 받아들인 것이 아니라 여러분이 맥락을 만들었기 때문입니다.

규칙 3: 무언가를 설치한 직후에 나타나는 요청창이 가장 위험한 요청창입니다. CrashStealer가 사는 곳이 바로 거기입니다. 새 소프트웨어가 관리자 암호를 요구하는 것은 정당할 수 있지만, 동시에 이 공격의 형태 그 자체이기도 합니다. 그 소프트웨어를 처음 이용해 보는 사이트에서 방금 다운로드했다면, 인증하기 전에 멈춰서 지금 무엇을 설치하고 있는지 다시 생각해 보십시오.

규칙 4: Touch ID가 제공될 때는 언제나 우선 사용하십시오. "암호를 넘겨줬다"를 "아무것도 넘겨주지 않았다"로 바꿔 줍니다.

규칙 5: 무언가 이상하게 느껴지면 먼저 연결을 끊고 나중에 생각하십시오. Wi-Fi를 끄는 데는 아무 비용도 들지 않고 2초면 됩니다. 가능한 가장 값싼 조치이면서, 데이터 유출을 멈추는 유일한 조치입니다.

이미 입력하셨다면: 유출 이후 대응 런북

이 절은 최악의 상황을 전제로 합니다. 지금은 가짜라고 판단되는 요청창에 로그인 암호를 입력하셨습니다. 지금 심정은 짜증과 진짜 공포 사이 어딘가일 것입니다. 아래 순서대로 진행하십시오. 효과가 가장 큰 조치가 앞에 오도록, 그리고 스트레스 상황에서 어떤 판단도 새로 내리지 않아도 되도록 설계했습니다.

단계에 들어가기 전에 두 가지 전제를 짚겠습니다.

첫째, 데이터 유출은 이미 일어났다고 가정하십시오. 인포스틸러는 속도를 위해 만들어집니다. 수집하고 전송합니다. 데이터가 실제로 나갔는지 판별하는 데 처음 10분을 쓰지 마십시오. 나갔다는 전제 위에서 그 10분을 쓰십시오.

둘째, 로그인 Keychain이 뚫렸다고 가정하십시오. Jamf의 보고에 따르면 올바른 암호는 CrashStealer가 Keychain을 잠금 해제하게 해 줍니다. 즉 이 사고의 범위는 "암호 하나"가 아닙니다. "그 암호가 보호하던 모든 자격 증명"입니다.

1단계: Mac을 네트워크에서 분리하십시오. 지금 즉시.

메뉴 막대에서 Wi-Fi를 끄십시오. 이더넷을 쓰고 있다면 케이블을 뽑으십시오. 확실히 하고 싶다면 Wi-Fi와 Bluetooth를 모두 꺼서 비행기 모드에 준하는 격리 상태로 만드십시오.

이 조치는 두 가지 일을 합니다. 악성코드가 수집했지만 아직 보내지 않은 데이터의 추가 전송을 막고, 원격 명령 채널을 끊습니다. 이미 나간 것을 되돌리지는 못하며 아래의 자격 증명 교체를 대신할 수도 없지만, 공짜이고 즉시 효과가 있으며 피해 범위를 한정해 줍니다.

아직 Mac을 종료하지는 마십시오. 곧 이 기기를 점검해야 하는데, 다시 부팅해야 하는 시스템보다 켜져 있는 시스템이 점검하기 쉽습니다. 점검할 생각이 전혀 없고 바로 전체 지우기로 갈 계획이라면 종료해도 괜찮습니다.

2단계: 그 기기에서 자격 증명 입력을 중단하십시오

이것은 앞으로 몇 시간 동안 지켜야 할 규칙이며, 사람들이 자기도 모르게 어기는 규칙이기도 합니다.

의심스러운 활동을 확인하겠다고 그 Mac에서 이메일에 로그인하지 마십시오. 암호를 바꾸겠다고 그 기기에서 비밀번호 관리자를 열지 마십시오. 거래 내역을 보겠다고 그 기기에서 은행에 로그인하지 마십시오. 침해되었다고 믿는 기기에 입력하는 모든 자격 증명은 두 번째로 넘겨주는 자격 증명입니다. 당장 확인하고 싶은 본능은 강렬하지만 정확히 잘못된 행동입니다.

무엇을 할지 결정하기 전까지 그 Mac을 읽기 전용 범죄 현장으로 취급하십시오.

3단계: 다른 신뢰할 수 있는 기기를 확보하십시오

휴대폰, 태블릿, 다른 컴퓨터, 가족의 기기 중 무엇이든 좋습니다. 필요한 것은 이번 사고와 무관한 기기입니다.

한 가지 주의점이 있습니다. 휴대폰이 같은 계정에 로그인되어 있고 동기화된 비밀번호 관리자가 설치되어 있더라도, 그 휴대폰은 여전히 복구에 사용 가능한 기기입니다. 침해된 것은 자격 증명이지 휴대폰 자체가 아니기 때문입니다. 다만 같은 악성 설치 프로그램이 두 대 이상의 기기에 손을 댔다고 의심할 이유가 조금이라도 있다면 다른 기기를 쓰십시오.

4단계: Apple Account 암호를 가장 먼저 변경하십시오

다른 무엇보다 먼저, 신뢰할 수 있는 기기에서 하십시오.

Apple Account는 트리의 뿌리입니다. iCloud Keychain, 나의 찾기, iCloud 백업, 기기 인증, 구입 내역을 통제하며, 많은 경우 다른 계정의 복구 경로이기도 합니다. 공격자가 이것을 손에 넣으면, 침해된 Mac에 저장한 적도 없는 것들까지 도달할 수 있습니다.

iPhone이나 iPad에서는 설정 > 사용자 이름 > 로그인 및 보안 > 암호 변경으로 들어가십시오. 웹에서는 appleid.apple.com입니다. 들어간 김에 신뢰하는 기기 목록을 검토하고, 알아볼 수 없거나 더 이상 사용하지 않는 기기는 제거하십시오.

어디에서도 쓴 적이 없는 암호를 고르고, 예전 암호의 패턴을 변형해 쓰지 마십시오.

5단계: 비밀번호 관리자의 마스터 암호를 두 번째로 변경하십시오

1Password, Bitwarden, Dashlane, KeePass 또는 비슷한 도구를 사용한다면 그 마스터 암호가 두 번째 뿌리입니다. Jamf는 비밀번호 관리자 데이터가 CrashStealer의 표적에 포함되어 있다고 보고했으므로, 보관함이 노출되었다고 간주하십시오.

신뢰할 수 있는 기기에서 마스터 암호를 변경한 다음, "모든 기기에서 로그아웃"이나 "모든 세션 인증 해제"에 해당하는 기능을 찾아 실행하십시오. 많은 비밀번호 관리자는 비밀 키나 계정 키 개념도 제공합니다. 사용 중인 제품이 그 키의 교체를 지원한다면 그것도 함께 하십시오.

사고 당시 그 Mac에서 비밀번호 관리자가 잠금 해제 상태였거나 데이터가 로컬에 캐시되어 있었다면, 보관함 내용이 공격자에게 알려졌다고 가정하십시오. 기분이 나쁜 상황이지만 동시에 정확한 할 일 목록을 주기도 합니다. 보관함 안의 모든 것을 교체해야 합니다. 우선순위는 다음 단계를 따르십시오.

6단계: 이메일, 그다음 금융, 그다음 나머지 전부를 교체하십시오

이 순서는 임의가 아닙니다. 피해 반경을 따릅니다.

이메일이 먼저입니다. 여러분의 이메일을 통제하는 사람은 나머지 대부분의 계정을 재설정할 수 있습니다. 보유한 모든 이메일 계정의 암호를 변경하되, 암호 재설정 메일을 받는 계정부터 시작하십시오. 그다음 각 계정의 보안 설정에서 활성 세션이나 인증된 기기 목록을 찾아 알아볼 수 없는 것을 전부 해지하십시오. 만든 적 없는 전달 규칙과 필터도 확인하십시오. 침해 이후 흔히 쓰이는 수법이 보안 알림을 조용히 전달하거나 자동 보관 처리해서 경고를 아예 보지 못하게 만드는 것입니다.

금융이 두 번째입니다. 은행, 증권사, 결제 앱, 카드가 등록된 모든 서비스입니다. 암호를 변경하고, 최근 활동을 확인하고, 이상한 것이 있으면 해당 기관에 전화하십시오. 많은 은행은 사고 사실을 알리면 계정에 기록해 두고 일정 기간 심사를 강화합니다.

그다음 나머지 전부입니다. 업무 계정, 클라우드 저장소, 소셜 미디어, 쇼핑 사이트, 개발자 플랫폼, 도메인 등록 기관, VPS 제공업체, API 키가 있는 모든 것입니다. 도메인 등록 기관과 클라우드 콘솔은 대부분의 사람이 두는 것보다 이 목록에서 훨씬 위에 있을 자격이 있습니다. 도메인이나 클라우드 계정에 대한 통제권은 그 하위의 모든 것에 대한 지렛대가 긴 공격이기 때문입니다.

이 모든 것을 한자리에서 다 하려 하지 마십시오. 이메일과 금융은 지금, 오늘 밤에 하십시오. 나머지 긴 목록은 며칠에 걸쳐 비밀번호 관리자의 목록을 보며 처리하십시오.

7단계: 어디서든 세션과 기기를 해지하십시오

암호를 바꾼다고 기존 세션이 항상 끊기지는 않습니다. 많은 서비스는 명시적으로 종료하지 않는 한 이미 인증된 세션을 암호 변경 이후에도 그대로 유지합니다.

중요한 계정마다 활성 세션, 로그인된 기기, 연결된 응용 프로그램을 나열하는 보안 페이지를 찾아 정리하십시오. Google, Microsoft, Apple, GitHub, Slack, Discord 및 대부분의 주요 서비스가 이 기능을 제공합니다. 알아볼 수 없는 서드파티 앱 권한도 함께 해지하십시오. OAuth 토큰은 암호 변경에도 살아남는 지속성 확보 수단이기 때문입니다.

들어간 김에 브라우저 동기화 세션도 확인하십시오. 브라우저 프로필이 침해된 기기와 동기화되어 있었다면, 모든 동기화 세션에서 로그아웃하고 깨끗한 기기에서 동기화를 다시 설정하는 편이 번거로움을 감수할 가치가 있습니다.

8단계: 암호화폐 시드 구문은 유출된 것으로 취급하십시오

그 Mac의 소프트웨어 지갑이나 브라우저 지갑 확장 프로그램에 암호화폐를 보유하고 있었다면, 이 부분의 마감 시한은 며칠이 아니라 몇 분 단위입니다.

Jamf는 브라우저 지갑 확장 프로그램을 포함한 암호화폐 지갑 데이터가 CrashStealer의 표적에 포함되어 있다고 보고했습니다. 그 기기에 존재했던 시드 구문, 개인 키, 지갑 파일은 모두 이미 알려졌다고 가정하십시오.

취해야 할 조치는 "지갑 암호 변경"이 아닙니다. 지갑 암호는 로컬 파일을 보호할 뿐이고, 시드 구문 자체가 계정입니다. 시드가 유출되었다면 여러분이 Mac에서 무엇을 하든 세계 어디에서나 자금에 접근할 수 있습니다.

깨끗한 기기에서 새로운 시드 구문을 가진 새 지갑을 생성하고 자금을 그쪽으로 옮기십시오. 기기 자체에서 시드를 생성하는 하드웨어 지갑이 있거나 구할 수 있다면 그것이 올바른 이동 목적지입니다. 옛 시드 구문을 "보호하겠다"며 어떤 기기에도 다시 입력하지 마십시오. 보호할 것이 남아 있지 않습니다. 유출 여부를 확인해 주겠다는 어떤 도구나 웹사이트에도 입력하지 마십시오. 그것 자체가 흔한 사기 수법입니다.

그 Mac의 메모, 스크린샷, 텍스트 파일, 비밀번호 관리자에 시드 구문을 저장한 적이 있다면 동일하게 적용됩니다. 앞으로 그런 보관 방식을 다시 생각해 볼 좋은 계기이기도 합니다.

9단계: 지원되는 모든 곳에 이중 인증을 활성화하십시오

이메일과 금융 계정에 이미 2단계 인증을 사용하고 계셨다면, 이번 사고는 그렇지 않은 경우보다 훨씬 덜 나쁩니다. 훔친 암호만으로는 그 문이 열리지 않기 때문입니다.

사용하고 계시지 않았다면, 각 암호를 교체하면서 지금 켜십시오. SMS보다는 인증 앱이나 하드웨어 보안 키를 우선하십시오. SMS 2단계 인증은 없는 것보다 확실히 낫고, 다른 대안보다는 확실히 못합니다. SIM 스와핑 공격이 이미 성숙한 산업이기 때문입니다.

이 상황에 특유한 주의점이 하나 있습니다. 인증 앱의 백업이 침해된 Keychain에 암호가 들어 있던 클라우드 계정에 저장되어 있었다면, 기존 설정이 안전하다고 가정하지 말고 2단계 인증을 다시 등록하십시오.

10단계: 이제 Mac 자체를 점검하십시오

깨끗한 기기에서 자격 증명 교체가 진행되는 동안, 다시 이 기기로 돌아오십시오. 점검하는 내내 네트워크에서 분리된 상태를 유지하십시오.

로그인 항목과 백그라운드 항목. System Settings > General > Login Items & Extensions를 여십시오. 읽어 볼 가치가 있는 목록이 두 개 있습니다. 로그인 시 열리는 앱, 그리고 실행이 허용된 백그라운드 항목입니다. 두 번째 목록이 흥미로운데, 각 백그라운드 에이전트를 책임지는 개발자 이름이 표시되기 때문입니다. 설명이 되지 않는 항목은 조사해 볼 가치가 있습니다. 정상적인 소프트웨어도 여기에 항목을 등록하므로 반사적으로 전부 삭제하지는 마십시오. 조치 전에 개발자 이름을 검색해 보십시오.

구성 프로파일. System Settings > General > Device Management를 여십시오. 회사나 학교에 등록되지 않은 개인용 Mac에서는 이 패널이 아예 나타나지 않는 것이 보통입니다. 이 패널이 나타나고 설치한 적 없는 프로파일이 목록에 있다면 그것은 심각한 발견입니다. 구성 프로파일은 DNS 설정을 바꾸고, 인증서를 설치하고, 정책을 강제할 수 있으며, 대부분의 사용자가 이곳을 들여다보지 않는다는 바로 그 이유 때문에 선호되는 지속성 확보 수단입니다.

날짜순으로 정렬한 응용 프로그램 폴더. Finder에서 응용 프로그램 폴더를 열고 목록 보기로 전환해 추가한 날짜나 수정한 날짜 순으로 정렬하십시오. 사고 시점 즈음에 도착한 것은 무엇이든 눈여겨볼 가치가 있습니다. 사용자 수준의 응용 프로그램 폴더가 있다면 거기에도 같은 작업을 하십시오.

브라우저 확장 프로그램. 각 브라우저의 확장 프로그램 페이지를 열고 의도적으로 설치하지 않은 것은 전부 제거하십시오. 이번 건과 직접 관련된 지갑 확장 프로그램, 그리고 모든 사이트의 데이터를 읽을 수 있는 광범위한 권한을 가진 것에 특히 주의를 기울이십시오.

최근 다운로드. 다운로드 폴더에서 이 사건을 시작한 디스크 이미지나 설치 프로그램을 찾아보십시오. 다시 열지는 마십시오. 파일 이름을 알아 두면 같은 미끼가 다시 나타났을 때 알아볼 수 있습니다.

무언가를 찾아 제거했더라도 이제 깨끗해졌다고 결론 내리지 마십시오. 찾아낸 조각을 제거했다는 사실은 찾아내지 못한 조각에 대해 아무것도 말해 주지 않습니다.

11단계: 지우고 다시 설치할지 결정하십시오

에두르지 않고 솔직한 답을 드리겠습니다. 가짜 시스템 요청창에 로그인 암호를 입력했다면, 지우고 다시 설치하는 것이 올바른 판단입니다.

그 근거는 제거가 불가능해서가 아닙니다. 검증이 불가능하기 때문입니다. 여러분의 관리자 암호를 손에 쥔 정체불명의 네이티브 바이너리를 실행한 기기에서는 없음을 증명할 수 없습니다. 수동 정리는 "다른 것을 찾지 못했다"까지만 데려다주며, 이는 "다른 것이 없다"와 같지 않습니다. 여러분의 업무, 이메일, 돈을 담고 있는 기기라면 그 간극이 중요합니다.

지우기를 합리적으로 건너뛸 수 있는 경우는 이렇습니다. 요청창을 보았지만 아무것도 입력하지 않았고, 앱을 종료하고 제거했으며, 그 이후로 이상하게 동작한 것이 없는 경우입니다. 반드시 지워야 하는 경우는 이렇습니다. 암호를 입력한 경우, 무엇을 설치했는지 재구성할 수 없는 경우, 이해할 수 없는 지속성 항목을 발견한 경우, 또는 그 기기가 다른 사람에 대해 여러분이 책임지는 무언가에 접근할 수 있는 경우입니다.

최신 Mac에서 제대로 수행하는 방법은 다음과 같습니다.

1. 깨끗한 기기에서 자격 증명 교체를 먼저 끝내십시오. 계정을 통제하기 전에 지우지 마십시오. 지우기는 계정 문제를 해결해 주지 않습니다.
2. 응용 프로그램이나 전체 시스템 이미지가 아니라 문서를 백업하십시오. 필요한 파일을 외장 드라이브에 복사하십시오. 사진, 문서, 프로젝트, 소스 코드 등 여러분이 만들어 낸 모든 것입니다.
3. Apple 실리콘과 T2 Mac에서는 모든 콘텐츠 및 설정 지우기(System Settings > General > Transfer or Reset)를 사용하고, 그 외에는 macOS 복구에서 재설치하십시오.
4. Mac을 새 기기로 설정하십시오. 감염 이후에 만든 Time Machine 백업에서 복원하지 마십시오. 그리고 마이그레이션 지원을 사용해 침해된 상태의 응용 프로그램과 시스템 설정을 옮겨오지 마십시오. 사람들이 스스로 재감염되고 나서 악성코드가 탐지 불가능했다고 결론 내리는 경로가 바로 이것입니다.
5. 응용 프로그램은 Mac App Store나 각 개발자의 공식 사이트에서 새로 다시 설치하십시오.
6. 외장 드라이브에서 문서를 다시 복사해 오십시오.
7. 다시 로그인하고 이중 인증을 재등록하십시오.

네, 저녁 시간 하나를 잃습니다. 하지만 그 끝에는 실제로 신뢰할 수 있는 기기가 남으며, 그것은 저녁 하나보다 더 값집니다.

왜 공증은 이번 사건에서 아무도 구하지 못했는가

이 사건에서 가장 교훈적인 부분은 모든 것이 설계대로 작동했는데도 사용자가 당했다는 점입니다.

공증이 실제로 무엇인지

개발자가 App Store 밖에서 Mac 앱을 배포할 때는 Apple의 공증 서비스에 앱을 제출합니다. Apple은 자동화된 검사를 수행합니다. 이미 알려진 악성 콘텐츠를 검사하고, 코드 서명을 확인하고, 유효한 Developer ID로 서명되었는지 점검하고, 일련의 하드닝 요구 사항을 충족하는지 확인합니다. 통과하면 Apple은 티켓을 발급하고, 그 티켓이 앱에 부착됩니다.

이 목록을 다시 읽고 거기에 없는 것이 무엇인지 보십시오. 사람이 하는 심사가 없습니다. 사용자가 앱을 실행했을 때 그 앱이 무엇을 하는지에 대한 행위 분석이 없습니다. 앱의 목적이 정직한지에 대한 판단이 없습니다. 공증이 답하는 질문은 좁습니다. 이 바이너리가 우리가 이미 악성이라고 알고 있는 무언가를 포함하고 있는가, 그리고 신원이 확인되는 개발자에 의해 제대로 서명되었는가입니다.

그럴듯한 암호 입력창을 그리고 거기서 가로챈 것을 전송하는 앱은, 특히 그것이 새로 만들어진 네이티브 바이너리라면, 스캐너가 찾는 의미의 "알려진 악성 콘텐츠"를 포함하고 있지 않습니다. 무사히 통과합니다.

Gatekeeper가 약속하는 것과 약속하지 않는 것

Gatekeeper는 여러분의 Mac에서 이를 집행하는 계층입니다. 다운로드한 앱을 열면 Gatekeeper는 그것이 서명되고 공증되었는지, 공증 티켓이 유효한지 확인합니다. 유효하다면 앱은 최소한의 마찰로 열립니다. 그렇지 않다면 Mac 사용자에게 익숙한 경고와 차단이 나타나는데, 여기에는 Gatekeeper 및 격리 문제 해결 가이드에서 다루는 "앱이 손상되어 열 수 없습니다" 메시지도 포함됩니다.

Gatekeeper가 약속하는 것은 안전이 아니라 책임 추적 가능성입니다. Gatekeeper는 이렇게 말하고 있습니다. 이 소프트웨어는 Apple에 등록하고 Developer ID 비용을 지불했으며 바이너리를 스캔받은 개발자로부터 왔습니다. 즉 만약 이것이 악성으로 판명되면, Apple은 누구의 인증서를 폐기해야 할지 압니다. 그것은 Apple이 이 앱이 여러분의 신뢰를 받을 자격이 있는지 평가했다는 뜻이 아닙니다.

이 두 가지 사이의 간극이 이 공격 범주 전체가 살고 있는 곳입니다. 그리고 새로운 일도 아닙니다. 저희는 2025년 12월에 MacSync Stealer가 유효한 Apple 공증을 이용해 Gatekeeper를 우회했을 때 같은 패턴에 대해 썼습니다. 그 교훈은 자리 잡지 못했습니다. 대부분의 사람에게 "공증받음"은 여전히 "승인됨"으로 읽히기 때문입니다.

폐기는 보호가 아니라 사후 정리입니다

Apple은 CrashStealer에 사용된 인증서를 폐기했습니다. 올바른 대응이며 실제로 효과가 있습니다. 폐기 여부를 확인하는 Mac에서는 그 앱이 더 이상 실행되지 않고, 같은 인증서로 다음 빌드에 서명할 수도 없습니다.

하지만 폐기는 분석 이후에 일어나고, 분석은 감염 이후에 일어납니다. 7월 초 배포 시점과 폐기 시점 사이의 기간에 당한 모든 사람은 그 조치로부터 아무 혜택도 받지 못했습니다. 인증서 폐기는 면역계의 장벽이 아니라 면역계의 기억입니다. 한편 새 Developer ID를 확보하는 일은 의욕적인 운영자에게는 풀 수 있는 문제이며, 그래서 같은 패턴이 다른 인증서를 달고 계속 반복됩니다.

여러분을 위한 실질적 결론은 이렇습니다. Gatekeeper를 사용하고, 켜 둔 채로 유지하고, 무언가를 실행하기 위해 끄라는 말을 들었다고 해서 절대 끄지 마십시오. 그리고 Gatekeeper를 앱을 신뢰하는 이유로 삼지 마십시오. "서명되었는가?"라는 질문은 "이것을 개발자에게서 받았는가, 아니면 검색 결과에서 받았는가?"보다 훨씬 덜 중요합니다.

이런 설치 프로그램은 어디에서 오는가

실제로 악성 디스크 이미지가 사용자에게 도달하는 경로는 몇 가지로 좁혀지며, 그 전부가 같은 순간을 노립니다. 어떤 소프트웨어를 쓰기로 마음먹고 어디서 다운로드할지 찾고 있는 순간입니다.

검색 광고. 누군가 잘 알려진 앱을 검색하고 첫 번째 결과를 클릭하는데, 그것이 유사 사이트를 가리키는 유료 광고입니다. 광고 문구는 정확하고, 랜딩 페이지는 잘 만든 복제품이며, 다운로드 버튼도 작동합니다. 압도적으로 가장 물량이 많은 경로이며, 검색 결과 페이지의 최상단이 권위 있게 느껴지기 때문에 통합니다.

유사 다운로드 사이트. 한 글자만 다른 도메인, 그럴듯한 단어가 하나 붙은 도메인, 또는 다른 TLD를 쓰는 도메인입니다. 진짜 소프트웨어를 자체 설치 프로그램으로 감싸는 "다운로드 포털" 생태계 전체도 여기에 포함됩니다. 그런 사이트가 악성코드를 유포하지 않는 경우에도, 그들은 변조된 설치 프로그램을 유포하고 있으며 그것은 들이지 않는 편이 좋은 습관입니다.

채팅과 포럼에 올라온 링크. Discord 서버, Telegram 그룹, Reddit 스레드, 지원 포럼의 댓글 등입니다. 누군가 친절하게 미러 링크를 올려 줍니다. 진짜 도움을 주려는 사람일 때도 있고 아닐 때도 있는데, 메시지만 보고는 구별할 수 없습니다.

유료 소프트웨어의 크랙 버전과 "무료" 버전. 설명이 필요 없는 경로이며, 여전히 스틸러에 감염되는 가장 확실한 방법 중 하나입니다.

네 가지 모두에 대한 방어는 같습니다. 검색하기 전에 어디서 다운로드할지 정해 두십시오. 개발자의 실제 도메인으로 가십시오. 그 도메인은 대개 앱 자체, 기존 설치본, 북마크, 개발자의 App Store 목록, 또는 인증된 소셜 계정을 통해 확인할 수 있습니다. 그런 다음 거기서 다운로드하십시오. 검색 결과 페이지가 여러분 대신 출처를 고르게 하지 마십시오.

실제로 효과가 있는 예방 조치

효과가 큰 순서에 가깝게 정리한 짧은 목록입니다.

Mac App Store에 있는 앱은 App Store에서 설치하십시오. App Store 앱은 샌드박스에서 실행되고 심사를 거치며, 이것은 공증과는 실질적으로 다른 기준입니다. 완벽하지는 않지만 공격 표면이 훨씬 좁습니다.

App Store에 없는 앱은 개발자의 인증된 자체 사이트에서 받으십시오. 도메인을 직접 입력하거나, 북마크를 쓰거나, 개발자의 App Store 목록에서 이동하십시오. 광고를 클릭하지 마십시오.

설치하기 전에 디스크 이미지 이름을 읽으십시오. 한 제품을 검색했는데 마운트한 DMG의 이름이 전혀 상관없는 것이라면 멈추십시오. 이 습관 하나만으로도 CrashStealer를 문 앞에서 잡아냈을 것입니다.

macOS를 최신 상태로 유지하십시오. XProtect 시그니처와 폐기 데이터는 업데이트 메커니즘을 통해 전달되며 전체 OS 업데이트를 설치하지 않아도 도착하지만, 최신 상태를 유지하면 모든 계층이 지원되는 상태로 유지됩니다. macOS Tahoe 26.6 업데이트 가이드에서 현재 릴리스에 무엇이 포함되어 있고 어떻게 깔끔하게 설치하는지 다룹니다.

다른 어디에도 존재하지 않는 마스터 암호를 쓰는 비밀번호 관리자를 사용하십시오. Mac 로그인 암호와도 다르고, Apple Account 암호와도 다르며, 둘 중 어느 것의 변형도 아니어야 합니다. 자격 증명 하나가 무너졌을 때 피해 반경을 제한해 주는 것이 바로 이것입니다.

로그인 Keychain을 제대로 된 암호 뒤에 잠가 두십시오. 입력하기 귀찮다고 계정 암호를 약하게 만들지 말고, Keychain의 보호 기능을 끄지 마십시오. 강력한 암호가 매일의 세금이 되지 않도록 하려고 Touch ID가 존재합니다.

FileVault를 켜고 백업하십시오. FileVault는 기기를 분실했을 때 저장된 데이터를 보호합니다. 백업은 "지우고 다시 설치"를 재앙이 아니라 두 시간짜리 번거로움으로 만들어 줍니다. 두 가지 모두 Mac 보안 및 개인 정보 보호 가이드에서 더 자세히 다룹니다.

필요해지기 전에 이중 인증을 켜 두십시오. 훔쳐 간 암호를 견딜 수 있게 만들어 주는 통제 수단입니다.

Mac에서 백신 프로그램이 실제로 도움이 되는가

특정 제품을 권하지 않고 솔직하게 답하겠습니다.

macOS의 악성코드 스캐너는 특정한 역할에 유용합니다. 이미 분석되고 목록화된 것을 알아보는 일입니다. 알려진 스틸러 계열이 기기에 도착하면 잘 관리된 스캐너가 잡아낼 가능성이 매우 높고, 그것은 결코 사소한 일이 아닙니다. 대부분의 감염은 새로운 것이 아니기 때문입니다. 스캐너는 사고 이후, 기기에 무엇이 있는지 파악하려 할 때 제2의 의견으로도 실질적인 도움이 됩니다.

스캐너가 덜 잘하는 것이 바로 이 글의 사례입니다. CrashStealer는 유효한 인증서를 가진 개발자 계정에서 나온 네이티브 바이너리였고, 핵심적인 악성 행위는 창 하나를 띄우고 사용자가 입력한 것을 읽는 일이었습니다. 새 계열이 등장한 시점과 탐지가 따라잡는 시점 사이에는 시간 간격이 있고, 그 기간 동안 시그니처 기반 도구에는 대조할 것이 없습니다. 행위 기반 탐지는 도움이 되지만 마법은 아닙니다.

macOS에 이미 여러 겹의 보호 장치가 탑재되어 있다는 솔직한 반론도 있습니다. Gatekeeper, XProtect, XProtect Remediator, 공증 확인, System Integrity Protection, 그리고 App Store 소프트웨어에 대한 앱 샌드박스입니다. 다운로드 습관이 좋은 신중한 사용자에게는 서드파티 백신이 다른 플랫폼에서만큼 보태 주는 것이 적습니다.

명확하게 도움이 되는 경우는 이렇습니다. 덜 신중한 사람과 Mac을 공유하는 경우, 다른 사람의 데이터를 다루는 경우, 규정 준수 요구 사항이 있는 환경에서 일하는 경우, 또는 이미 한 번 사고를 겪고 한 쌍의 눈을 더 두고 싶은 경우입니다. 덜 도움이 되는 경우는 이렇습니다. 앞 절의 습관을 대체하는 용도로 쓰는 경우입니다. 어떤 스캐너도 여러분이 창에 암호를 입력하기로 결정하는 것으로부터 여러분을 지켜 주지 못합니다.

더 긴 비교를 원하신다면 2026년 Mac 백신 가이드에서 장단점을 자세히 다룹니다.

자주 발생하는 문제 해결

문제: 암호 요청창이 떠서 취소를 눌렀고 아무것도 입력하지 않았습니다. 괜찮은가요? 해결: 암호 자체에 대해서는 거의 확실히 괜찮습니다. 취소 클릭은 아무것도 노출하지 않습니다. 하지만 그 요청창을 그린 앱은 여전히 Mac에 있고 여전히 실행 중입니다. Force Quit에서 종료한 다음 찾아서 삭제하고, Login Items & Extensions와 Device Management에서 그 앱이 남긴 것이 있는지 확인하십시오. 요청창이 다시 나타나는지 지켜보십시오. 다시 나타난다면 무언가가 여전히 남아 있다는 뜻입니다. 출처를 찾을 수 없거나 재시동 후에도 요청창이 다시 나타난다면 현재 진행 중인 감염으로 취급하고 런북의 10단계부터 진행하십시오.

문제: 요청창이 진짜인지 정말로 판단할 수 없는데, 정당한 작업을 승인해야 합니다. 해결: 요청창을 완전히 닫은 다음, 맥락을 직접 만드십시오. 앱을 종료하십시오. System Settings나 Finder를 직접 열고 원하던 동작을 거기서 시작하십시오. 신뢰하는 곳에서 클릭한 것의 즉각적인 결과로 요청창이 나타난다면 진짜일 가능성이 훨씬 높습니다. 실제로 인증할 때는 Touch ID가 제공되면 그것을 사용해서 어느 쪽이든 암호가 입력되지 않게 하십시오. 여러분이 아무것도 시작하지 않았는데 요청창이 계속 나타난다면, 그 모호함 자체가 답입니다. 가짜입니다.

문제: 이미 암호를 입력했습니다. 처음 60초 동안 무엇을 해야 합니까? 해결: Wi-Fi를 끄거나 이더넷 케이블을 뽑으십시오. 그 Mac에서 자격 증명이 관련된 모든 작업을 중단하십시오. 휴대폰이나 다른 컴퓨터를 들고 Apple Account 암호를 변경한 다음 비밀번호 관리자 마스터 암호를 변경하십시오. 그다음 이메일, 그다음 금융 계정입니다. 그 Mac에 암호화폐를 보유하고 있었다면 다른 무엇보다 먼저 깨끗한 기기에서 자금을 옮기십시오. 시드 구문 노출에는 되돌리기가 없기 때문입니다. 전체 순서는 위의 런북 절에 있습니다. 즉흥적으로 대응하지 말고 그 순서대로 진행하십시오.

문제: Force Quit이나 응용 프로그램 폴더에서 알아볼 수 없는 앱을 발견했습니다. 해결: 열지 마십시오. 조치하기 전에 다른 기기에서 정확한 이름을 검색해 보십시오. 정상적인 보조 앱 중에도 이상한 이름을 가진 것이 많기 때문입니다. 낯설고 사고 시점 즈음에 나타난 것이라면 종료하고, 휴지통으로 옮기고, 휴지통을 비운 다음, Login Items & Extensions에서 대응하는 백그라운드 항목이 있는지 확인하고 그것도 제거하십시오. 구성 요소 하나를 찾았다고 전부를 찾은 것은 아니므로, 점검 단계를 계속 진행하고 지우기 여부도 고려하십시오.

문제: System Settings에 설치한 적 없는 구성 프로파일이 표시됩니다. 해결: 회사나 학교가 관리하지 않는 개인용 Mac에서는 Device Management 패널이 아예 존재하지 않는 것이 보통입니다. 이 패널이 존재하고 낯선 프로파일이 나열되어 있다면 침해의 강력한 지표이며, 프로파일은 DNS를 우회시키거나 트래픽을 가로챌 수 있는 인증서를 설치할 수 있습니다. System Settings > General > Device Management에서 제거한 다음, 네트워크 설정에서 DNS 서버가 변경되지 않았는지 확인하십시오. 프로파일이 할 수 있는 일을 감안하면, 이 발견은 전체 지우기 및 재설치 쪽으로 강하게 기울게 합니다.

문제: Mac이 이제 로그인 Keychain 암호를 계속 요구하는데 무엇을 입력해도 통하지 않습니다. 해결: 이는 전혀 악의 없는 이유로도 발생할 수 있으며, 대개 암호 재설정 이후 계정 암호와 Keychain 암호가 어긋났을 때 생깁니다. 보안 사고 뒤에 따라올 수도 있습니다. 악성코드를 의심할 이유가 조금이라도 있다면 깨끗한 기기에서 자격 증명을 먼저 교체한 다음 문제를 해결하십시오. 어떤 사고와도 무관하다고 확신한다면, Mac이 로그인 Keychain 암호를 반복해서 요구하는 문제 가이드에서 Keychain을 안전하게 재동기화하거나 재설정하는 방법을 안내합니다.

자주 묻는 질문

진짜 macOS 충돌 보고 도구가 암호를 요구하는 경우가 있습니까?

없습니다. 앱이 충돌하면 macOS는 다시 열기, 무시하기, Apple에 보고서 보내기를 제안합니다. 충돌 로그를 보내는 데는 관리자 권한이 필요하지 않으므로, 진짜 충돌 보고 도구가 인증을 요구하는 구성은 존재하지 않습니다. 로그인 암호를 요구하는 충돌 보고서 창은 예외 없이 가짜입니다.

Mac을 최신 상태로 유지했는데 악성코드가 어떻게 Gatekeeper를 통과했습니까?

Jamf Threat Labs는 유포에 사용된 앱이 유효한 Apple Developer ID로 서명되고 공증되어 있었다고 보고했습니다. 공증은 알려진 악성 콘텐츠와 서명 문제를 찾는 자동화된 검사이지 사람이 하는 보안 심사가 아니므로, 새로운 네이티브 바이너리는 통과할 수 있습니다. Gatekeeper는 유효한 티켓을 존중했습니다. Apple은 이후 해당 인증서를 폐기했습니다.

암호를 입력했다면 그 암호만 유출된 것입니까?

아닙니다. 그리고 이것이 핵심입니다. Jamf의 보고에 따르면 CrashStealer는 암호를 로컬에서 검증하고, 맞으면 로그인 Keychain을 잠금 해제할 수 있습니다. Keychain에는 Wi-Fi 암호, 앱 자격 증명, 인증서, 저장된 로그인 정보가 들어 있습니다. 입력한 암호 하나가 아니라 그 Mac에 저장된 모든 자격 증명이 노출된 것으로 취급하십시오.

Mac을 지우면 그것만으로 문제가 해결됩니까?

아닙니다. 지우기는 기기에서 악성코드를 제거하지만 이미 기기를 떠난 자격 증명에 대해서는 아무것도 하지 못합니다. 깨끗한 기기에서 Apple Account와 비밀번호 관리자부터 시작해 암호를 먼저 교체한 다음 지우십시오. 또한 감염 이후의 백업에서 복원하거나 응용 프로그램을 이전해 오는 것은 문제를 다시 불러올 수 있으므로 피하십시오.

겉모습만으로 가짜 요청창을 구별할 수 있습니까?

가끔은 가능하고, 항상 가능하지는 않습니다. 끌어 보십시오. 다른 앱의 창을 벗어나지 못하는 요청창은 확실히 가짜입니다. 메뉴 막대와 Force Quit을 확인해 어느 앱이 요구하고 있는지 보십시오. 하지만 잘 만든 네이티브 가짜는 모든 시각적 테스트를 통과할 수 있으며, 그래서 신뢰할 수 있는 규칙은 겉모습이 아니라 맥락입니다. 불러내지 않은 요청창은 적대적입니다.

이번 일을 겪은 뒤 Mac에 백신을 설치해야 합니까?

도움이 될 수 있습니다. 주로 알려진 악성코드 계열을 잡아내는 용도와 사고 이후 제2의 의견을 얻는 용도입니다. 백신이 가장 약한 지점이 바로 이 시나리오, 즉 서명된 새 바이너리가 그럴듯한 창으로 공격하는 경우입니다. 좋은 다운로드 습관, 다른 어디에도 쓰지 않는 비밀번호 관리자 마스터 암호, 이중 인증이 어떤 스캐너보다 여러분을 더 잘 지켜 줍니다.

결론

CrashStealer는 오래된 발상을 잘 실행한 사례입니다. Jamf Threat Labs는 Werkbit Setup이라는 이름의 디스크 이미지로 전달되어 CrashReporter.app을 자처하는 앱을 설치하고, 시스템 대화상자로 위장한 암호 요청창을 띄우고, 입력된 것을 검증하고, 올바른 암호로 로그인 Keychain을 잠금 해제해 브라우저 자격 증명, 비밀번호 관리자 데이터, 암호화폐 지갑에 도달하는 네이티브 C++ 인포스틸러를 보고했습니다. 이 앱은 유효한 Apple Developer ID로 서명되고 공증되어 있었기에 Gatekeeper가 통과시켰고, Apple은 사후에 인증서를 폐기했습니다.

세부 사항을 걷어내면 남는 것은 단 하나의 결정 지점입니다. 창 하나가 여러분의 암호를 요구했고, 여러분은 그것을 줄지 말지 결정했습니다. 그 결정은 기술적인 것이 아닙니다. 습관이며, 습관은 만들 수 있습니다. 만들어 둘 가치가 있는 습관은 새벽 1시에도 기억날 만큼 간단합니다. 암호가 필요한 동작을 하지 않았다면 암호를 입력하지 마십시오. 취소하고, 어느 앱이 요구하는지 알아내고, 신뢰하는 곳에서 그 동작을 직접 다시 시작하십시오. Touch ID가 제공되면 사용하십시오. 지문은 입력된 문자열처럼 훔칠 수 없기 때문입니다.

이미 암호를 입력한 뒤에 이 글을 읽고 계시다면, 상황은 복구 가능하며 중요한 것은 순서입니다. Mac의 연결을 끊으십시오. 다른 기기로 옮기십시오. Apple Account가 첫 번째, 비밀번호 관리자가 두 번째, 이메일이 세 번째, 금융이 네 번째입니다. 암호화폐는 깨끗한 기기에서 즉시 옮기고 시드 구문은 소실된 것으로 취급하십시오. 세션을 해지하고, 로그인 항목과 구성 프로파일을 확인한 다음, 침해된 상태를 복원하는 대신 지우고 새로 설정하십시오. 모든 것을 한꺼번에 해결하려 하지 말고 목록을 따라 내려가십시오.

아무것도 불타고 있지 않은 지금, 이번 주에 15분을 내어 예방에 해당하는 부분을 해 두십시오. 이메일과 금융 계정에 이중 인증이 켜져 있는지 확인하고, 비밀번호 관리자의 마스터 암호가 다른 어디에도 존재하지 않는지 확인하고, 작동하는 백업이 있는지 점검하고, macOS가 최신인지 확인하십시오. 그런 다음 이 페이지를 북마크해 두십시오. 다음번 가짜 요청창은 다르게 생겼겠지만, 규칙은 같을 것입니다.