Mac이 터미널 붙여넣기를 차단했다: 그 경고의 진짜 의미

누군가 터미널에 명령어를 붙여넣으라고 했을 겁니다. 어떤 지원 페이지가 그렇게 하면 문제가 해결된다고 했을 수도 있고, 어떤 인증 화면이 그래야 사람이라는 걸 증명할 수 있다고 했을 수도 있고, 어떤 다운로드 페이지가 그게 가장 빠른 설치 방법이라고 했을 수도 있습니다. 그래서 복사하고, Terminal을 열고, Command-V를 눌렀는데, Mac이 보안 경고를 띄우며 여러분을 멈춰 세웠습니다.

거의 모든 사람의 첫 반응은 macOS가 과민하게 군다는 것입니다. 때로는 그 반응이 맞습니다. 정상적인 소프트웨어도 실제로 명령어를 붙여넣으라는 설치 안내를 제공하고, 공격자를 잡으려고 조정된 보호 기능은 그런 정상적인 경우도 일부 함께 걸러냅니다. 하지만 어떤 때는 그 경고가 낯선 사람과 여러분의 Apple Keychain, 브라우저에 저장된 비밀번호, 그리고 그 Mac에 보관 중인 암호화폐 사이에 남아 있는 마지막 방어선입니다.

이 글은 여러분이 둘 중 어느 상황에 있는지 알려줍니다. Apple이 추가한 세 가지 보호 기능 전부, 각 경고가 실제로 뜻하는 것, 무시하고 진행할 수 있는지와 그 대가, 왜 개발자 친구는 한 번도 못 봤다는 경고가 여러분에게는 떴는지, iTerm2나 Ghostty 같은 서드파티 터미널에서는 어떻게 되는지, 그리고 셸 문법을 몰라도 30초면 적용할 수 있는 판단 기준을 다룹니다. 이미 붙여넣고 실행해 버렸다면, 아래쪽에 차분하고 순서대로 정리된 대응 절차가 있습니다. 거기부터 보고 설명은 나중에 읽어도 됩니다.

핵심 요약

• 보호 기능은 하나가 아니라 셋입니다. Apple의 플랫폼 보안 문서는 Terminal Paste Protection, Pasteboard Command Blocking, AppleScript 검사를 macOS 26.4 이상에서 도입된 별개의 메커니즘으로 설명합니다. 어느 것이 작동했는지 알면 얼마나 심각하게 받아들여야 할지가 정해집니다.
• 무시할 수 있는 경고와 없는 경고는 전혀 다른 의미입니다. 휴리스틱 일치는 진행할 방법을 제공합니다. 알려진 악성코드 시그니처 일치는 그렇지 않고, 메모리에서 실행되는 스크립트도 마찬가지입니다. Mac이 진행 버튼을 아예 주지 않는다면, 그건 우회해야 할 버그가 아닙니다.
• 서드파티 터미널은 경고창을 잃지만 최후 방어선은 유지합니다. Apple은 붙여넣기 경고를 Terminal 앱의 기능으로 문서화하지만, pasteboard 명령어 차단은 결과 프로세스 트리에 대해 XProtect 수준에서 동작하기 때문에 서드파티 애플리케이션을 포함한 모든 터미널 에뮬레이터를 명시적으로 포괄한다고 밝힙니다.
• 이 보호 기능이 막으려는 공격은 방문자마다 다른 페이지를 보여줍니다. 2026-08-05에 보고된 Microsoft Threat Intelligence 연구는 방문자를 핑거프린팅하고 보안 연구자를 찾아내는 페이지를 사용하는 macOS ClickFix 작전을 설명했습니다. 즉, 여러분이 직접 링크를 확인해 봤다는 사실은 다른 사람이 무엇을 봤는지에 대해 아무것도 증명하지 못합니다.
• 잃는 것은 비밀번호 하나가 아니라 자격 증명 전체입니다. Huntress 연구진은 브라우저 비밀번호 데이터베이스, 쿠키, Apple Keychain을 노리는 Go 기반 macOS 스틸러를 설명했습니다. 이 악성코드에는 잔액의 1%까지 조정할 수 있는 암호화폐 탈취 기능이 있어 도난이 조용히 진행됩니다. 모니터링 중이던 어느 Mac은 아무도 알아채기 약 3개월 전에 이미 감염돼 있었습니다.

세 가지 보호 기능, 그리고 방금 걸린 것은 어느 쪽인가

Apple의 플랫폼 보안 문서 중 터미널 및 스크립트 보호 페이지는 macOS 26.4 이상에서 도입된 세 가지 메커니즘을 설명합니다. 이들은 흔히 하나의 기능인 것처럼 이야기되는데, 그래서 혼란이 큽니다. 셋은 동작 방식이 다르고, 적용 대상 소프트웨어가 다르며, 일부만 무시하고 진행할 수 있기 때문입니다.

이 섹션을 먼저 읽으세요. 셋 중 무엇에 걸렸는지 알고 나면 이 글의 나머지 내용을 적용하기가 훨씬 쉬워집니다.

보호 1: Terminal Paste Protection

Mac이 붙여넣기를 막았다고 할 때 대부분의 사람이 가리키는 것이 바로 이것입니다. 공격자가 명령어를 전달할 때 흔히 사용하는 부류의 출처 애플리케이션, 즉 웹 브라우저, Messages, Mail, Preview, 메신저 앱에서 복사한 텍스트를 붙여넣을 때 Apple의 Terminal 앱이 표시하는 경고 대화상자입니다.

핵심 단어는 경고입니다. 이 보호 기능의 목적은 사회공학 공격이 벌어지는 그 순간을 끊는 것입니다. 여러분이 받은 지시와 실행하려던 행동 사이에 과속방지턱을 놓는 것이고, 그 지점은 정확히 이 공격이 여러분이 멈춰 서서 생각하지 않는다는 데 의존하는 지점입니다.

Apple은 이 보호 기능이 작동하기 위해 모두 충족되어야 하는 구체적인 조건들을 문서화하고 있습니다. 의도적으로 좁게 설계되어 있고, 그래서 대부분의 사람은 이 경고를 본 적이 없습니다. 이 조건들은 곧 자세히 짚어보겠습니다. 이 기능에 대해 가장 많이 나오는 질문, 즉 왜 어떤 사람에게는 뜨고 어떤 사람에게는 전혀 뜨지 않는지에 대한 답이 바로 거기 있기 때문입니다.

보호 2: Pasteboard Command Blocking

이것은 완전히 다른 계층에서 동작하며, 대부분의 보도가 그 중요성을 과소평가하는 보호 기능입니다.

Apple 문서에 따르면, 사용자가 서드파티 터미널 애플리케이션을 포함한 모든 터미널 에뮬레이터에 텍스트를 붙여넣으면 XProtect가 그 결과로 생성된 프로세스 트리를 추적하고 동작을 검사합니다. 그다음 두 가지 일이 일어납니다. 네트워크 아티팩트가 Apple의 Safe Browsing Service와 대조되고, 알려진 악성 출처와 일치하는 프로세스는 차단됩니다. 이와 별개로, 동작 패턴이 알려진 악성코드 기법과 대조되어 평가됩니다.

이 설명이 무엇에 의존하지 않는지 보세요. 터미널이 대화상자를 띄우는 것에 의존하지 않습니다. 그 터미널이 Apple 제품인 것에 의존하지 않습니다. 여러분이 경고를 받았는지에 의존하지 않습니다. 검사는 명령어가 실행되기 시작한 뒤에, 결과 프로세스가 무엇을 하고 어디로 연결하는지 관찰하는 방식으로 이뤄집니다. 그래서 이 보호 기능은 Apple이 만들지 않은 소프트웨어까지 포괄할 수 있습니다.

보호 3: AppleScript 및 JXA 검사

세 번째 보호 기능은 XProtect를 OpenScripting 프레임워크에 통합합니다. 이 프레임워크는 macOS에서 AppleScript와 JavaScript for Automation, 보통 줄여서 JXA라고 부르는 것을 실행하는 부분입니다. 두 언어의 스크립트 모두가 검사 대상이며, 알려진 악성 시그니처와 일치하면 실행이 차단되고 사용자에게 알림이 갑니다.

여기에는 중요한 비대칭이 있고, Apple은 그것을 분명하게 밝힙니다. 사용자는 파일 기반 스크립트에 대한 차단은 무시하고 진행할 수 있지만, 메모리에서 실행되는 스크립트에 대해서는 그럴 수 없습니다. 이 구분은 자의적인 것이 아닙니다. 파일에 들어 있는 스크립트는 결정을 내리기 전에 열어서 읽어볼 수 있는 대상입니다. 디스크에 검사할 파일 하나 없이 메모리에서 곧바로 실행되는 스크립트는 흔적을 남기지 않으려는 악성코드와 강하게 연관된 패턴이고, macOS는 그런 경우 아예 통과를 허용하지 않습니다.

macOS를 겨냥한 스크립트 기반 공격에는 긴 역사가 있고, 이 보호 기능이 존재하는 이유 중 하나가 바로 그것입니다. 현재 활동 중인 Mac 악성코드 계열과 침투 경로를 다룬 글에서, 이 생태계가 소프트웨어 취약점 공격보다 스크립팅에 얼마나 크게 의존하는지 폭넓게 살펴봤습니다.

여러분이 본 경고를 작동한 보호 기능에 대응시키기

빠르게 정리하면 이렇습니다.

• Apple의 Terminal에 붙여넣었고, 아무것도 실행되기 전에 경고가 떴으며, 진행할 수 있는 방법이 있었다: Terminal Paste Protection.
• 붙여넣었더니 뭔가 시작되었고, 그다음 중단되었다. 서드파티 터미널일 수도 있다: Pasteboard Command Blocking.
• 경고가 붙여넣기가 아니라 스크립트를 언급했다: AppleScript 검사. 무시하고 진행할 수 있는지는 그 스크립트가 파일이었는지 메모리에서 실행되었는지에 달려 있습니다.

어느 쪽인지 확신이 서지 않는다면, 다음 섹션에서 각 경고를 더 자세히 다룹니다.

각 경고 해석하기

시작하기 전에 문구에 대한 참고 사항이 있습니다. Apple은 If your Mac blocks a Terminal command paste or script라는 제목의 일반 사용자용 지원 문서를 support.apple.com/en-us/127377에서 제공하며, 그 페이지가 Mac이 보여주는 정확한 문자열에 대한 표준 참고 자료입니다. 이 글을 쓰면서 해당 페이지의 본문을 직접 읽지는 못했기 때문에, 아래의 경고 제목들은 Apple의 문구를 그대로 인용한 것이 아니라 언론 보도에서 전해진 문구로 제시합니다. 여러분이 본 것이 조금 다르다면, 이 글을 포함한 어떤 간접 설명보다도 여러분의 화면과 Apple의 문서를 신뢰하십시오.

정확한 문자열보다 훨씬 중요한 것은 그 경고가 속한 범주이며, 그 범주들은 잘 문서화되어 있습니다.

Possible malware, Paste blocked (악성코드 가능성, 붙여넣기 차단됨)

언론 보도는 이 경고 제목을 휴리스틱 일치에 대응하는 것으로 전합니다. 휴리스틱이란 macOS가 특정한 알려진 위협을 인식한 것이 아니라는 뜻입니다. 악성 붙여넣기가 대체로 작동하는 방식과 닮은 행동의 형태를 인식한 것입니다.

이 경고는 Paste Anyway(그래도 붙여넣기) 선택지를 제공한다고 전해지며, Apple은 진행할 경우 여전히 Mac과 개인정보가 위험에 처할 수 있다고 경고합니다.

그 버튼이 무슨 의미인지 스스로에게 솔직해지십시오. 그것은 "macOS가 틀렸다"라고 말하는 버튼이 아닙니다. "이 일에 대한 책임을 내가 지겠다"라고 말하는 버튼입니다. 일치가 시그니처 기반이 아니라 휴리스틱 기반이므로 오탐은 실제로 가능하고, 흔치 않지만 정상적인 명령어를 붙여넣는 개발자가 여기에 걸릴 수 있습니다. 무시하고 진행하는 선택지가 존재하는 이유가 정확히 그것입니다. 하지만 오탐을 가능하게 하는 바로 그 성질 때문에, 이 경고는 명령어 자체에 대해 안심할 만한 정보를 전혀 주지 못합니다. 시스템은 패턴을 표시했을 뿐입니다. 이제 판단은 여러분이 보태야 하고, 이 글 뒤쪽의 판단 기준은 정확히 이 순간을 위해 설계되었습니다.

절대 하지 말아야 할 한 가지는 Paste Anyway를 형식적으로 클릭하고 지나가는 것입니다. 반사적으로 그 버튼에 손이 간다면, 멈추고 판단 기준 섹션의 질문들에 먼저 답하십시오. 30초면 됩니다.

Malware Detected, Paste Blocked (악성코드 탐지됨, 붙여넣기 차단됨)

언론 보도는 이 경고 제목을 알려진 악성코드 시그니처와의 일치에 대응하는 것으로 전하며, 무시하고 진행할 방법이 없다고 전합니다.

이것은 휴리스틱 경고와는 질적으로 다른 메시지입니다. 휴리스틱 경고는 "이건 보통 나쁜 부류처럼 보인다"라고 말합니다. 이 경고는 "우리는 이걸 전에 본 적이 있고, 그게 무엇인지 안다"라고 말합니다. 버튼이 없는 이유는, 확인된 알려진 위협과 일치한 상황에서 평범한 사용자가 평범한 명령어를 붙여넣으며 계속 진행해도 되는 합리적인 시나리오가 존재하지 않기 때문입니다.

이 경고를 받았다면 올바른 대응은 우회 방법을 찾는 것이 아닙니다. 그 명령어를 준 출처를 적대적인 것으로 간주하고, 닫고, 조금이라도 실행된 게 있다면 격리 단계로 넘어가는 것입니다. pasteboard 검사를 피하려고 명령어를 손으로 다시 타이핑하지 마십시오. 다른 터미널에서 시도하지 마십시오. 다른 사람에게 전달해서 대신 해보게 하지 마십시오. 여러분이 풀어야 할 문제는 그 명령어가 아니라, 그것을 건네준 페이지나 메시지입니다.

Malicious Script Blocked (악성 스크립트 차단됨)

언론 보도는 이 경고 제목을 세 번째 보호 기능, 즉 AppleScript 및 JXA 검사 경로에 대응하는 것으로 전합니다. OpenScripting 프레임워크가 내용이 알려진 악성 시그니처와 일치하는 스크립트를 실행하라는 요청을 받았을 때 나타납니다.

이 경고를 무시하고 진행할 수 있는지는 그 스크립트가 어디에 있는지에 달려 있고, Apple은 그 규칙을 분명히 문서화하고 있습니다. 파일 기반 스크립트는 사용자가 무시하고 진행할 수 있습니다. 메모리에서 실행되는 스크립트는 전혀 그럴 수 없습니다.

여러분이 직접 작성한 자동화 스크립트를 실행하거나 신뢰하는 소프트웨어가 함께 제공한 스크립트를 실행하는 등 정당한 작업 중에 이 경고를 보고 있다면, 파일 기반 스크립트에 대한 진행 경로는 존재하며 사용할 수 있습니다. 다만 그전에 당연한 일을 먼저 하십시오. 텍스트 편집기로 스크립트 파일을 실제로 열어보는 것입니다. 읽을 수 있는 스크립트는 평가할 수 있는 스크립트이고, macOS가 파일에는 진행을 허용하고 메모리에는 허용하지 않는 이유 전체가 파일의 경우에는 여러분에게 그 선택지가 주어지기 때문입니다.

무시하고 진행하면 실제로 어떻게 되는가

진행을 선택한다고 해서 그 명령어가 안전한 것으로 표시되지는 않습니다. macOS에게 여러분이 신뢰할 만한 사용자라고 학습시키지도 않습니다. 다른 보호 기능들의 적용에서 면제되지도 않습니다. 구체적으로, Terminal 경고에서 Paste Anyway를 클릭해도 pasteboard 명령어 차단은 비활성화되지 않습니다. 그것은 프로세스가 시작된 뒤 XProtect 수준에서 동작하는 별개의 메커니즘입니다. 경고를 무시하고 진행했는데 그 결과 프로세스가 알려진 악성 대상에 접근하려다 잠시 뒤 차단될 수도 있습니다.

이런 계층화는 중복이 아니라 설계 의도입니다. 각 보호 기능은 나머지가 실패할 수 있다고 가정합니다.

왜 나에게는 경고가 뜨고 개발자 친구에게는 한 번도 안 뜨는가

이것은 붙여넣기 경고를 둘러싼 가장 흔한 혼란의 원인인데, 답은 신비로운 것이 아니라 문서에 적혀 있습니다.

Apple의 플랫폼 보안 문서는 Terminal Paste Protection이 다음 조건이 모두 성립할 때만 작동한다고 밝힙니다.

• 사용자가 30일 넘게 Terminal 앱을 열지 않았다.
• 시스템에서 일반적인 개발자 도구가 감지되지 않는다.
• 붙여넣기가 특정 앱에서 비롯되었다.

또한 초기 설정 후 24시간의 유예 기간이 있어서, 막 구입한 Mac을 구성하는 중인 사람이 정당하게 환경을 세팅하고 있는 도중에 경고 세례를 받지는 않습니다.

이 조건들을 다시 읽고 그것이 무엇을 묘사하는지 보십시오. 위험한 명령어를 묘사하지 않습니다. 사람을 묘사합니다.

30일 조건

Terminal을 정기적으로 사용한다면 이 보호 기능은 사실상 여러분에게 보이지 않습니다. 첫 번째 조건이 절대 성립하지 않기 때문입니다. 30일 안에 한 번이라도 Terminal을 열면 트리거 범위 밖에 머무를 수 있습니다. 그래서 개발자, 시스템 관리자, 셸 안에서 사는 사람들은 Mac을 쓰는 내내 이 대화상자를 한 번도 못 볼 수 있습니다.

Terminal을 거의 열지 않는데 오늘은 무언가가 시키는 대로 열고 있다면, 여러분이야말로 이 조건이 묘사하는 바로 그 사람입니다.

개발자 도구 조건

두 번째 조건은 시스템에 일반적인 개발자 도구가 있는지를 봅니다. 실제 개발 환경이 갖춰진 기기는 업무의 일부로 명령어를 붙여넣는 사람의 것이고, 그런 사람에게 붙여넣기마다 경고를 띄우면 읽지도 않고 닫는 습관을 들이게 만들어 보호 기능을 무의미하게 만들 것입니다.

이 조건은 경고가 성가시다고 느끼는 개발자들에게 줄 수 있는 솔직한 답이기도 하며, 문제 해결 섹션에서 다시 다루겠습니다. 해결책이 사람들이 보통 요구하는 그런 것이 아니기 때문입니다.

출처 앱 조건

세 번째 조건은 붙여넣은 텍스트가 어디에서 왔는지에 관한 것입니다. Apple은 이 보호 기능이 흔한 공격 경로, 즉 웹 브라우저, Messages, Mail, Preview, 메신저 앱에서의 붙여넣기를 대상으로 한다고 설명합니다. 여러분이 직접 쓴 문서나 다른 터미널 창에서 복사한 텍스트는, 웹 페이지나 낯선 사람의 메시지가 클립보드에 올려놓은 텍스트와는 다른 상황입니다.

이는 의미 있는 구분입니다. ClickFix의 전달 경로는 거의 언제나 그 채널들 중 하나이기 때문입니다. 명령어는 어떻게든 여러분에게 도달해야 하고, 그 도달 경로는 다른 사람이 쓴 것을 읽을 때 사용하는 앱들입니다.

왜 이런 표적화가 올바른 설계인가

세 조건을 합치면, 평소 Terminal을 쓰지 않고, 개발 환경도 없으며, 방금 브라우저나 메시지에서 명령어를 복사한 사람에게 작동하는 필터가 됩니다. 그것은 운 나쁜 파워 유저에 대한 묘사가 아닙니다. 그것은 ClickFix 피해자에 대한, 그것도 정밀도가 매우 높은 묘사입니다.

이것은 사람들을 답답하게 만드는 현상도 설명해 줍니다. 두 사용자가 동일한 명령어를 붙여넣었는데 한 명만 경고를 받는 일 말입니다. 명령어에는 아무 변화가 없습니다. 평가 대상은 내용만이 아니라 정황입니다. 이 경고 하나를 넘어 Terminal이 실제로 무엇을 위한 도구인지 이해하고 싶다면 macOS Tahoe의 Terminal 완벽 가이드가 시작하기 좋은 곳이고, 솔직히 말해 Terminal을 의식적으로 쓰는 사람이 되는 것이 어떤 대화상자보다도 나은 장기적 방어책입니다.

iTerm2, Warp, Ghostty는 어떻게 되는가

바로 여기서 대부분의 논의가 어긋나는데, 그것도 실제로 중요한 방식으로 어긋납니다.

흔한 결론은 이렇습니다. 이건 Apple의 Terminal만 보호하니까 iTerm2를 쓰면 아무 혜택도 못 받는다. 절반은 맞고 절반은 틀렸으며, 그 구분이 아마 이 글에서 가장 쓸모 있는 내용일 것입니다.

붙여넣기 경고는 Apple의 Terminal 앱에 한정됩니다. Apple 문서는 Terminal Paste Protection을 사용자가 Terminal에 붙여넣을 때 표시되는 경고로 설명합니다. iTerm2, Alacritty, Warp, Ghostty, Kitty, WezTerm을 비롯한 나머지 전부는, 각자의 개발자가 동등한 기능을 구현하지 않는 한 그 대화상자를 보여주지 않습니다. iTerm2 안에서 산다면 경고를 기대해서는 안 되고, 경고가 없다는 것을 이상 없음의 신호로 해석해서도 안 됩니다.

pasteboard 명령어 차단은 Apple의 Terminal에 한정되지 않습니다. Apple의 표현은 이 지점에서 명시적입니다. 사용자가 서드파티 터미널 애플리케이션을 포함한 모든 터미널 에뮬레이터에 텍스트를 붙여넣으면 XProtect가 그 결과 프로세스 트리를 추적하고 동작을 검사합니다. 터미널의 사용자 인터페이스를 지켜보는 것이 아닙니다. 붙여넣기가 생성한 프로세스가 실제로 무엇을 하는지 지켜보면서, 네트워크 아티팩트를 Apple의 Safe Browsing Service와 대조하고 동작을 알려진 악성코드 기법과 대조해 평가합니다.

그러니 정확한 표현은 이렇습니다. 서드파티 터미널 사용자는 경고를 잃고 최후 방어선은 유지합니다. 사회공학 공격 도중에 여러분을 멈춰 세우도록 설계된, 사람을 향한 과속방지턱을 잃습니다. 그 이후에 실행되는, 기계를 향한 검사는 유지합니다.

이 맞바꿈은 어깨를 으쓱하고 넘길 것이 아니라 이해해 둘 가치가 있습니다. 두 보호 기능이 잡아내는 실패 지점이 다르기 때문입니다. 경고는 아무것도 실행되기 전에, 즉 틀렸을 때의 비용이 0인 시점에 여러분을 잡아줍니다. 최후 방어선은 프로세스가 이미 시작된 뒤에 잡아내므로, 틀렸을 때의 비용이 0이 아닙니다. 차단이 걸리기 전에 이미 어느 정도의 코드가 실행된 뒤이기 때문입니다.

행동 방식에 대한 실질적 함의도 있습니다. 서드파티 터미널을 쓴다면, 아래의 판단 기준이 가장 중요한 사람이 바로 여러분입니다. 붙여넣는 그 순간에 운영체제가 여러분을 멈춰 세워 주지 않기 때문입니다. 스스로가 대화상자가 되어야 합니다.

이 중 어느 것도 iTerm2나 Ghostty에 대한 비판이 아닙니다. 훌륭한 도구들이고, 그 사용자들은 어차피 개발자 도구 조건 때문에 붙여넣기 경고 대상에서 제외되었을 개발자 집단인 경우가 많습니다. 다만 보호 프로필이 많은 사람이 가정하는 것과 양방향으로 다르다는 뜻입니다.

ClickFix란 정확히 무엇인가

이 보호 기능들이 존재하는 이유는 구체적이고 대단히 성공적인 사회공학 패턴 때문입니다. 그것은 ClickFix라 불리며 때로는 pastejacking이라고도 설명되는데, 이것을 이해하는 편이 어떤 경고 문자열을 외우는 것보다 더 잘 보호해 줍니다.

패턴은 단순합니다. 웹 페이지나 메시지가 여러분에게 명령어를 복사해 Terminal에 붙여넣도록 설득합니다. 포장은 거의 언제나 다음 중 하나입니다.

• 가짜 인증 단계. CAPTCHA나 사람 확인 챌린지처럼 꾸며진 화면이 보이는데, 신호등 사진을 클릭하는 대신 명령어를 실행해 인증을 완료하라는 안내를 받습니다. 가장 흔한 변종이며, 인증 챌린지가 모두에게 이상한 지시를 의심 없이 따르도록 훈련시켜 놓았기 때문에 잘 통합니다.
• 해결책이 딸린 가짜 오류. 어떤 구성 요소가 없다거나, 코덱이 오래됐다거나, 드라이버가 실패했다고 알리면서 친절하게 그것을 해결할 명령어를 제공하는 페이지입니다. 오류는 허구입니다. 해결책이 페이로드입니다.
• 가짜 설치 프로그램. 실제로 존재하고 사람들이 원하는 소프트웨어의 다운로드 페이지가, 보통 평범해 보이는 다운로드 버튼 옆에 명령어를 빠른 설치 방법으로 제시합니다.
• 가짜 회의 앱 업데이트. 회의 링크를 클릭했더니 참여하기 전에 화상회의 앱을 업데이트해야 한다는 안내와 함께 실행할 명령어를 받습니다. 이미 늦은 회의라는 시간 압박이 나머지를 해결해 줍니다.

왜 신중한 사람에게도 통하는가

ClickFix는 지능 테스트가 아닙니다. 평범한 경계심을 무력화하는 세 가지 성질이 있습니다.

첫째, 행동을 여러분이 직접 수행합니다. 차단되는 다운로드도, 나타나는 Gatekeeper 프롬프트도, 격리되는 미서명 앱도 없습니다. 그런 보호 기능들이 기대하는 방식으로는 아무것도 다운로드되지 않았기 때문입니다. 공격은 여러분의 손으로 직접 입력된 셈입니다. Mac 사용자가 의지하는 방어 수단 중 상당수는 다른 문을 지키고 있습니다.

둘째, 포장이 이유를 제공합니다. 모든 변종은 "내가 왜 이걸 하고 있지"라는 질문을 여러분이 던지기도 전에 답해 줍니다. 인증. 누락된 구성 요소. 더 빠른 설치. 사람은 설명이 딸린 지시에는, 특히 그 설명이 지루할수록 저항하지 않습니다.

셋째, 정당한 관행의 권위를 빌려 옵니다. 실제 소프트웨어도 진짜로 이 명령어를 붙여넣으라는 안내를 제공합니다. 이 공격은 뭔가 특이한 것인 척하지 않습니다. 정상적인 것을 흉내 냅니다.

마지막 지점은 관련된 다른 계열의 공격이 통하는 이유이기도 합니다. 비밀번호를 요구하는 가짜 시스템 대화상자가 성공하는 것도 같은 이유이며, 이는 가짜 Mac 충돌 보고서 비밀번호 프롬프트를 다룬 글에서 자세히 살펴봤습니다. 밑바탕의 속임수는 같고 표면만 다릅니다.

Microsoft Threat Intelligence 연구, 그리고 그것이 링크 검증 방식을 바꾸는 이유

2026-08-05에 보고된 Microsoft Threat Intelligence 연구는 250개가 넘는 프런트엔드 도메인에 걸친 macOS ClickFix 작전을 추적했습니다. 규모만으로도 잠시 멈춰 볼 만하지만, 중요한 것은 메커니즘입니다.

그 연구에 따르면, 작은 JavaScript 스니펫이 방문자마다 핑거프린트를 수집한 뒤 무엇을 보여줄지 결정합니다. 보고된 신호에는 플랫폼 문자열, 화면 및 창 크기, WebGL 데이터, 시간대, 페이지가 iframe 안에 있는지 여부, 터치 지원 여부가 포함됩니다. 또한 브라우저 개발자 콘솔이 열려 있는 동안 값이 증가하는 카운터를 사용해 보안 연구자를 특정해 찾아냅니다. 분석가 자신의 도구를 탐지 신호로 바꿔 버리는 영리한 수법입니다.

표적 프로필에 맞지 않는 방문자는 빈 페이지나 무관한 사이트를 받습니다. 조건을 충족하는 방문자, 즉 실제 사람처럼 보이는 Mac 사용자는 Download for macOS 선택지를 제공하는 GitHub 테마 페이지를 받는데, 여기에는 위조된 Verified Publisher 배지까지 붙어 있습니다. 그 연구에서 보고된 페이로드는 MacSync와 Atomic Stealer, 흔히 AMOS로 줄여 부르는 것이었습니다.

여기서 실제로 여러분의 행동을 바꿔야 하는 결론이 나오고, 이것은 단도직입적으로 말할 가치가 있습니다.

페이지가 방문자마다 다른 내용을 보여주기 때문에, "내가 확인해 봤는데 멀쩡했다"는 증거로서 아무 가치가 없습니다. "친구가 열어봤는데 아무 일도 없었다"도 마찬가지입니다.

여러분이 평가하는 대상은 고정된 무언가가 아닙니다. 누가 보고 있는지에 따라 자기가 무엇이 될지 결정한 대상을 평가하는 것입니다. Windows 기기에서, 혹은 개발자 도구를 연 브라우저에서, 혹은 다른 시간대에서 그 링크를 연 동료는 완전히 빈 페이지를 보고 링크가 무해하다고 정직하게 보고했을 수 있습니다. 그 보고는 여러분에게 무엇이 표시되었는지에 대해 아무것도 말해 주지 않습니다.

위조된 Verified Publisher 배지도 언급할 가치가 있습니다. 신뢰 배지는 픽셀입니다. 정상적인 사이트가 표시할 수 있는 것은 무엇이든 악성 사이트가 똑같이 복사할 수 있습니다. 배지는 주장이지 증거가 아니며, 그것을 증거로 취급하는 것은 macOS가 그린 것처럼 보인다는 이유로 비밀번호 프롬프트를 믿는 것과 같은 범주의 실수입니다.

실제로 무엇이 걸려 있는가

이 모든 것을 추상적으로 읽기 쉬우니, ClickFix가 성공했을 때 그 반대편의 악성코드가 실제로 무엇을 하는지 정리하겠습니다.

2026-08-06에 보고된 Huntress 연구는 정상적인 macOS 구성 요소를 사칭하며 ClickFix를 통해 전달되는 Go 기반 macOS 스틸러를 설명했습니다. 그 연구가 서술한 표적은 브라우저 비밀번호 데이터베이스, Apple Keychain, 쿠키, 자격 증명 파일입니다.

Keychain이 핵심이다

잠시 Keychain에 집중해 보십시오. 피해 범위를 결정하는 것이 바로 그것이기 때문입니다. 로그인 Keychain은 비밀번호 하나가 아닙니다. Wi-Fi 자격 증명, 앱 자격 증명, 인증서, 보안 메모, 그리고 많은 사람에게는 수년에 걸쳐 쌓인 웹사이트 로그인 정보입니다. Keychain에 도달한 무언가는 비밀번호 하나를 훔친 것이 아닙니다. 세트 전체를 훔친 것입니다.

그래서 감염이 의심될 때의 솔직한 조언은 결코 "입력했던 비밀번호를 바꿔라"가 아닙니다. 그 기기에 존재했던 모든 자격 증명을 노출된 것으로 취급해야 합니다.

DRAIN 함수와 1% 설계

Huntress 연구는 그 스틸러에서 **DRAIN**이라는 이름의 함수도 설명했습니다. 이 함수는 Bitcoin, Litecoin, Dogecoin, Ethereum, XRP 지갑 형식을 탐색하고, DRAIN_PCT 변수로 제어되는 비율만큼 잔액을 전송할 수 있습니다. 그 변수는 1%까지 낮춰 설정할 수 있습니다.

그 숫자를 곱씹어 보십시오. 지갑을 통째로 비우는 공격자는 즉시 발각됩니다. 피해자가 알아채고 사건이 시작되기 때문입니다. 1%를 가져가는 공격자는 영영 발각되지 않을 수도 있습니다. 이 설계는 의도적으로 조용하며, 한 번의 큰 수확이 아니라 계속 눌러앉는 데 최적화되어 있습니다.

여러분에게 주는 실질적 결론은 이렇습니다. "잔액이 맞아 보인다"는 깨끗하다는 증거가 아닙니다. 눈치채지 못할 만큼 작게 설계된 도난은 실제로 눈치채지 못하고 지나갑니다. Mac에서 뭔가 실행되었다고 믿을 만한 이유가 있다면, 눈에 띄는 손실이 없다는 사실을 이상 없음의 신호로 삼지 마십시오.

3개월

Huntress 연구는 모니터링 중이던 어느 Mac이 탐지되기 약 3개월 전에 이미 감염되어 있었다고 보고했습니다.

3개월간의 웹 서핑. 3개월간의 로그인, 세션, 쿠키, 그리고 그 기기를 거쳐 간 모든 것. 아래 대응 절차가 얼마나 급한지 가늠하고 싶다면, 그 숫자가 기준입니다. 이런 감염은 요란하지 않습니다. 아무것도 튀어나오지 않습니다. Mac이 여러분이 알아챌 만한 방식으로 느려지지도 않습니다. 이 사업 모델 전체가 여러분이 들여다보지 않는다는 데 기대고 있습니다.

실제로 쓸 수 있는 판단 기준

여기가 이 글의 실용적인 핵심입니다. 좋은 결정을 내리기 위해 셸 문법을 유창하게 읽을 필요는 없습니다. 다섯 가지 질문에 정직하게 답하면 됩니다.

질문 1: 내가 찾아 나선 것인가, 무언가가 실행하라고 시킨 것인가?

이것은 압도적으로 신호 대 잡음비가 높은 질문이고, 답하는 데 아무 비용도 들지 않습니다.

내가 찾아 나섰다: 특정 도구를 설치하기로 결정했고, 그 도구의 공식 문서로 직접 이동했으며, 거기서 설치 명령어를 찾았다. 의도가 나에게서 출발했습니다.

무언가가 시켰다: 어쩌다 도착한 페이지, 내가 찾지 않은 오류, 누군가 보낸 메시지, 또는 인증 화면이 그 지시를 만들어 냈다. 의도가 다른 곳에서 출발했습니다.

거의 모든 ClickFix 피해자는 두 번째 범주에 있습니다. 거의 모든 정당한 붙여넣기는 첫 번째 범주에 있습니다. 두 번째 범주에 있다면 기본 답은 아니오이며, 아래의 모든 내용은 그 기본값을 뒤집을 만한 충분한 근거가 있는지에 관한 것입니다.

질문 2: 이 명령어의 모든 부분이 무엇을 하는지 아는가?

대략적인 요지가 아닙니다. 모든 부분입니다.

답이 아니오라면 선택지는 둘입니다. 실행하기 전에 그것이 무엇을 하는지 배우거나, 실행하지 않는 것입니다. 어떤 페이지가 괜찮다고 장담했다는 이유로 이해하지 못하는 것을 실행하는 세 번째 선택지는 없습니다. 명령어가 길거나, 난독화되어 있거나, base64로 인코딩되어 있거나, 설명할 수 없는 문자로 가득하다면, 그 난독화 자체를 답으로 받아들이십시오. 정상적인 설치 명령어는 보통 읽기 어렵게 만들려고 애쓰지 않습니다.

질문 3: 다운로드한 것을 곧바로 셸에 파이프로 넘기는가?

주의해야 할 형태는 네트워크에서 무언가를 가져와 즉시 실행하는 명령어이고, 보통 다운로드 도구의 출력을 sh나 bash로 파이프하는 모양입니다. 이 패턴은 한 번도 본 적 없는 코드를, 어떤 서버로부터, 도착하는 그 순간에 실행한다는 뜻입니다.

이 패턴이 자동으로 악성인 것은 아닙니다. 실제 프로젝트들도 사용하며, 다음 섹션에서 그 점을 솔직하게 다루겠습니다. 다만 이는 여러분이 실행하는 코드가 그 순간 그 서버가 보내기로 결정한 무엇이든이라는 뜻이고, 방문자 핑거프린팅에 대한 Microsoft Threat Intelligence의 발견을 감안하면 그것이 다른 사람에게 보내는 것과 반드시 같지는 않습니다.

질문 4: sudo와 비밀번호를 요구하는가?

sudo로 실행하는 것은 관리자 권한을 넘겨주는 일입니다. 정상적인 설치 프로그램 중에도 그것이 필요한 것이 많으니 자동으로 잘못된 일은 아니지만, 틀렸을 때의 결과가 나쁜 정도에서 심각한 정도로 바뀝니다. 그에 비례해 검증 수준을 높이십시오. 보증할 수 없는 출처에서 온, root 권한을 원하는 명령어는 고민할 문제가 아닙니다.

함께 들여 둘 만한 습관: 관리자 비밀번호는 여러분이 시작한 동작에 대한 응답으로 입력하는 것이지, 저절로 나타난 프롬프트에 응답해 입력하는 것이 아닙니다.

질문 5: 출처가 그 프로젝트 자체의 공식 문서이고, 내가 직접 찾아간 것인가?

가장 강력한 신호는 두 가지의 조합입니다. 지시가 그 소프트웨어 프로젝트 자체의 사이트나 저장소에 있다는 것, 그리고 누군가 건네준 링크를 따라간 것이 아니라 여러분이 직접 이동해서 거기에 도달했다는 것입니다.

이 조합이 중요한 이유는 어느 한쪽만으로는 약하기 때문입니다. 페이지는 프로젝트의 문서와 똑같아 보일 수 있습니다. 링크는 무엇을 표시하든 어디로든 향할 수 있습니다. 프로젝트 이름을 직접 검색해 넣고, 도메인이 실제 프로젝트와 일치하는지 확인하고, 설치 안내가 있어야 할 문서에서 그것을 찾아내는 일은, 무엇을 실행하라고 알려준 페이지로 클릭해 들어가는 것과는 의미상 전혀 다른 행위입니다.

실행하기 전에 명령어를 읽는 방법

어떤 명령어가 아마도 정당하다고 판단했지만 희망이 아니라 검증으로 확인하고 싶다면, 방법은 이렇습니다.

Terminal이 아니라 텍스트 편집기에 붙여넣으십시오. 일반 텍스트 편집기는 아무것도 실행하지 않습니다. 이것만으로도 이 공격이 의존하는 패턴, 즉 Return 키를 누르면 실행되는 곳에 붙여넣게 만드는 패턴이 즉시 깨집니다.

화면 밖으로 밀려난 부분까지 전체를 보십시오. 정말 고약한 수법 중 하나는 공백이나 줄바꿈으로 채워 넣어, 보이는 부분은 무해하고 페이로드는 훨씬 오른쪽이나 다음 줄에 놓이게 하는 명령어입니다. 자동 줄바꿈을 켠 텍스트 편집기는 전부 보여줍니다. Terminal은 그렇지 않습니다.

끝에 줄바꿈이 있는지 확인하십시오. 복사한 텍스트가 줄바꿈으로 끝나면, 셸에 붙여넣는 순간 읽어볼 틈도 없이 바로 실행됩니다. 이것은 의도적인 기법입니다. 그리고 붙여넣기 경고가 존재하는 이유이기도 합니다.

다운로드 후 실행하는 설치 프로그램이라면 단계를 나누십시오. 다운로드를 셸로 곧장 파이프하는 대신, 스크립트를 파일로 내려받고, 그 파일을 텍스트 편집기로 열어 읽은 다음, 그런 뒤에야 실행하십시오. 90초 정도가 들지만 믿음의 행위를 검사의 행위로 바꿔 줍니다. 그 스크립트가 도저히 평가할 수 없는 수천 줄의 빽빽한 로직이라면, 적어도 여러분이 얼마나 큰 신뢰를 내주고 있는지에 대해 실질적인 것을 하나 배운 셈입니다.

인코딩된 것은 디코딩하십시오. 명령어의 일부가 base64나 16진수라면, 실행하지 말고 디코딩해서 결과를 읽으십시오. 정상적인 설치 프로그램이 자기 내용을 여러분에게 숨겨야 한다면, 그건 질문할 만한 일입니다.

의심스러우면 하지 마십시오. 정당한 명령어를 실행하지 않았을 때의 비용은 뭔가를 더 느린 방법으로 설치하는 것입니다. 악성 명령어를 실행했을 때의 비용은 앞 섹션에 있습니다.

Homebrew 방식 설치 프로그램이 공격과 똑같아 보이는 이유

불편한 부분을 솔직하게 다룰 시간입니다. 그러지 않으면 이 글이 쓸모없어지기 때문입니다.

이 문제가 진짜로 어려운 이유는 정당한 패턴과 공격 패턴이 같은 형태이기 때문입니다. Homebrew의 설치 프로그램이 대표적인 예입니다. 공식적으로 문서화된 설치 방법이 스크립트를 다운로드해 실행하는 명령어를 터미널에 붙여넣는 것입니다. Homebrew는 잘못한 게 없습니다. 널리 쓰이고 널리 신뢰받는 프로젝트이며, 그 설치 방식은 10년 넘게 표준 관행이었습니다. 존중받는 다른 도구들도 많이 같은 방식을 씁니다.

그러므로 "터미널에 명령어를 절대 붙여넣지 마라"로 요약되는 조언은 Homebrew를 설치하지 말라는 조언이 되고, 사람들은 그것을 무시하는 게 맞습니다. 이 규칙의 절대주의 버전이 실패하는 이유는 일상적인 정당한 관행과 모순되기 때문이며, 사람들이 지킬 수 없는 규칙은 아무도 보호하지 못합니다.

두 경우를 실제로 갈라놓는 것은 명령어가 아닙니다. 그 주변의 맥락입니다.

그 지시에 어떻게 도달했는가. Homebrew의 경우, 여러분이 Homebrew를 설치하기로 결정했고, Homebrew 사이트에 갔고, 설치 안내를 읽었습니다. ClickFix의 경우, 여러분이 찾지도 않은 페이지가 그 페이지를 보기 전까지는 있는 줄도 몰랐던 문제를 해결하려면 뭔가를 실행하라고 시켰습니다. 의도의 방향이 반대이고, 그 역전이 결정적 단서입니다.

도메인이 그 프로젝트 자체의 것인가. 명령어는 프로젝트의 실제 사이트나 실제 저장소에 있어야 합니다. 미러도, 블로그 글도, 단축 링크도, 브랜딩만 프로젝트와 비슷한 페이지도 아닙니다. 페이지의 로고를 보지 말고 도메인을 직접 보고 확인하십시오. Microsoft Threat Intelligence 연구는 위조된 Verified Publisher 배지를 단 GitHub 테마 페이지를 설명했는데, 이는 시각적 브랜딩이 검증이 아닌 이유를 정확히 보여주는 사례입니다.

명령어가 공개되고 교차 확인된 안내와 일치하는가. 프로젝트의 설치 명령어를 독립적으로 찾아보십시오. 건네받은 것이 프로젝트가 공개한 것과 다르다면 답이 나온 것이고, 그 답을 얻기까지 셸 문법을 한 글자도 이해할 필요가 없었습니다.

포장에 긴박함이나 인증이 끼어 있는가. 정당한 설치 문서는 사람임을 증명하려면 뭔가를 실행해야 한다거나, 그래야 회의가 시작된다고 말하지 않습니다. 긴박함과 인증이라는 포장은 거의 순수하게 공격자의 신호입니다.

간단히 말해, Homebrew의 명령어가 안전한 이유는 그 명령어의 내용 때문이 아니라 여러분이 그것을 어디에서 찾았고 어떻게 거기 도달했는지 때문입니다. 다른 모든 것에도 같은 기준을 적용하면 이런 판단의 대부분을 맞힐 수 있습니다.

이미 붙여넣고 실행해 버렸다면

명령어가 이미 실행되었다면, 순서대로 진행하십시오. 모든 걸 한꺼번에 하려 들지 말고, 마지막의 극단적인 단계로 건너뛰지도 마십시오.

1. 해당 Mac을 네트워크에서 분리하십시오. Wi-Fi를 끄고 이더넷을 뽑으십시오. 스틸러는 네트워크로 데이터를 유출하므로, 연결을 끊으면 아직 빠져나갈 수 있는 것이 제한됩니다. 속도가 진짜로 중요한 단계는 이것 하나입니다.

2. 당황해서 재부팅하지 말고, 아무거나 지우기 시작하지 마십시오. 재부팅은 지속성 메커니즘을 제거하지 못하며, 무슨 일이 있었는지에 대한 유용한 증거를 없앨 수 있습니다. 숨을 고르십시오. 다음 60초보다 다음 단계들이 더 중요합니다.

3. 다른, 신뢰할 수 있는 기기에서 비밀번호를 변경하십시오. 사람들이 틀리는 단계가 이것이고, 여기서 틀리면 나머지가 무의미해집니다. 감염됐을 수 있는 Mac에서 비밀번호를 바꾸면, 여전히 지켜보고 있을지 모르는 기기에 새 비밀번호를 입력하는 셈입니다. 이 사건과 한 번도 접촉하지 않은 휴대폰, 태블릿, 또는 다른 컴퓨터를 사용하십시오. 순서도 중요합니다. Apple 계정 먼저, 그다음 비밀번호 관리자의 마스터 비밀번호, 그다음 이메일, 그다음 금융 계정, 그다음 나머지 전부입니다.

4. Keychain에 있는 모든 것을 노출된 것으로 간주하고 교체하십시오. Huntress는 Apple Keychain을 명시적 표적으로 서술했습니다. 이는 Wi-Fi 비밀번호, 앱 자격 증명, 저장된 로그인, 보안 메모를 뜻합니다. 지루한 작업입니다. 돈, 신원, 또는 다른 계정에 대한 접근을 보호하는 것부터 우선하십시오.

5. 가능한 모든 곳에서 활성 세션을 해지하십시오. 탈취된 쿠키는 공격자가 비밀번호를 아예 건너뛰게 해 주므로, 기존 세션을 끝내지 않고 비밀번호만 바꾸면 공격자를 로그인 상태로 남겨둘 수 있습니다. 주요 서비스 대부분에는 "모든 기기에서 로그아웃" 또는 활성 세션 관리 기능이 있습니다. 각 비밀번호를 변경한 뒤에 사용하십시오.

6. 깨끗한 기기에서 생성한 시드로 새 지갑을 만들고 암호화폐를 옮기십시오. 지갑이 그 Mac에 있었다면 시드는 유출된 것이고, 같은 기기에서 새 지갑을 만드는 것은 문제를 그대로 재현하는 일입니다. 신뢰하는 기기에서 생성한 뒤 자금을 옮기십시오. 그리고 Huntress가 서술한 DRAIN_PCT 설계를 감안하면, 잔액이 맞아 보인다는 이유로 이 단계를 건너뛰지 마십시오.

7. 로그인 항목과 백그라운드 항목을 확인하십시오. 시스템 설정의 일반에서 로그인 항목과 백그라운드 항목 목록을 살펴보고, 알아볼 수 없거나 설명할 수 없는 항목이 있는지 확인하십시오.

8. 구성 프로파일을 확인하십시오. 시스템 설정의 일반에서 기기 관리로 들어가, 설치한 적 없는 프로파일이 있는지 찾아보십시오. 설치한 적 없는 프로파일은 심각한 발견입니다. 프로파일은 시스템 동작을 광범위하게 바꿀 수 있기 때문입니다.

9. 평판 좋은 검사 도구를 실행하십시오. 검사 도구는 알려진 계열을 잡아내고 두 번째 의견을 얻는 데 유용하지만, 진짜로 새로운 페이로드에는 가장 취약합니다. Mac용 백신 프로그램 가이드에서 이런 도구들이 현실적으로 무엇을 잡고 무엇을 못 잡는지 다뤘습니다.

10. 진정한 해결은 초기화뿐임을 이해하십시오. 이것이 솔직한 부분입니다. Mac을 지우고 macOS를 재설치한 뒤, 사건 이전 시점의 백업에서 데이터를 복원하는 것만이 알려진 정상 상태로 실제로 되돌리는 유일한 조치입니다. 그보다 못한 것은 정리가 아마 충분했을 거라고 여러분이 판단하는 것에 불과합니다. 복원에는 주의하십시오. 사건 이후의 백업에서 애플리케이션이나 시스템 설정을 복원하면 문제를 그대로 다시 들여올 수 있습니다. 문서를 복원하고, 애플리케이션은 각 출처에서 다시 설치하십시오.

11. 필요하다고 느끼는 것보다 더 오래 계정을 주시하십시오. Huntress 연구에서 모니터링 중이던 Mac이 탐지까지 약 3개월이 걸렸다는 점을 감안하면, 조용한 한 주는 거의 아무 의미가 없습니다. 금융 계정과, 공격자가 즐겨 쓰는 지속성 수법인 이메일 전달 규칙을 한동안 계속 살펴보십시오.

이 목록을 다 훑고 나서 더 폭넓은 보안 강화를 하고 싶어졌다면, Mac 보안 및 개인정보 보호 가이드에서 불이 나지 않은 평소에 바꿔 둘 만한 설정들을 다룹니다.

이 보호 기능들이 막아주지 못하는 것

한계를 분명히 하는 것은 비관이 아닙니다. 믿고 의지할 수 있는 방어와, 사람을 다치게 하는 안전에 대한 착각을 가르는 차이입니다.

백신 프로그램이 아닙니다. 이것들은 하나의 전달 기법을 겨냥한 표적형 보호 기능입니다. 범용 악성코드 검사기가 아니고, 보안 제품처럼 시스템 전체를 지속적으로 감시하지 않으며, 애초에 그렇게 설계되지도 않았습니다.

직접 타이핑한 것은 검사하지 않습니다. Terminal Paste Protection은 붙여넣기에 관한 것입니다. 공격자가 여러분을 설득해 명령어를 한 글자씩 손으로 입력하게 만든다면, 붙여넣기 경고는 작동할 대상이 없습니다. pasteboard 명령어 차단은 여전히 결과 프로세스의 동작을 지켜보지만, 사람을 향한 과속방지턱은 사라집니다.

평범하게 다운로드한 설치 프로그램에는 도움이 되지 않습니다. DMG나 PKG를 내려받아 일반적인 방식으로 실행한다면, 그것은 Terminal 붙여넣기의 영역이 아니라 Gatekeeper와 공증의 영역입니다. 서로 다른 실패 양상을 가진 다른 메커니즘이며, 앱이 손상되었다는 오류와 Gatekeeper 격리를 다룬 글에서 살펴봤습니다.

새로운 공격은 알려진 시그니처와 일치하지 않습니다. 시그니처 대조는 정의상 이미 관찰된 것을 잡아냅니다. 동작 평가와 Safe Browsing 검사가 그 범위를 넓혀 주지만, 진짜로 새로운 인프라를 사용하는 진짜로 새로운 페이로드는 이 모든 것을 빠져나갈 수 있습니다. 경고가 없다는 것은 안전하다는 증거가 아닙니다.

붙여넣기 경고는 대부분의 사람에게 뜨지 않습니다. 설계상 그렇습니다. 문서화된 조건은 지난 30일 안에 Terminal을 연 사람이나 개발자 도구가 설치된 사람을 제외합니다. 이 보호 기능이 자신을 지켜준다고 가정한 개발자라면, 그렇지 않으며 그것은 의도된 것입니다.

서드파티 터미널은 경고를 표시하지 않습니다. 앞에서 다뤘지만 한계 섹션에서 다시 반복할 가치가 있습니다. 누군가를 다치게 할 가능성이 가장 큰 가정이기 때문입니다.

어느 것도 근본 원인을 다루지 않습니다. 근본 원인은 낯선 사람이 여러분을 설득해 자기 코드를 실행하게 했다는 것입니다. 소프트웨어는 그것을 중단시킬 수 있습니다. 대신 결정해 줄 수는 없습니다.

자주 겪는 문제 해결하기

정당한 설치 명령어가 차단됩니다

Problem: 공식 문서에 따라 실제 소프트웨어를 설치하는 중인데, 붙여넣기가 차단되거나 경고가 뜹니다.

Solution: 먼저 정당하다고 가정하지 말고 독립적으로 확인하십시오. 이 공격의 핵심 자체가 정당하게 느껴진다는 것이기 때문입니다. 프로젝트를 직접 검색하고, 공식 사이트나 저장소로 이동해, 공개된 설치 명령어와 여러분이 가진 것을 비교하십시오. 일치하고 여러분이 직접 이동해 문서에 도달했다면, 이는 휴리스틱 오탐일 가능성이 높고 무시하고 진행하는 선택지는 정확히 이런 경우를 위해 존재합니다. 경고가 진행 선택지를 제공하지 않는다면 우회하지 마십시오. 진행 불가 경고는 휴리스틱 추정이 아니라 알려진 위협과의 일치를 뜻하기 때문입니다. 붙여넣기 방식 대신 프로젝트의 패키지나 설치 프로그램을 통해 설치하는 것을 고려하십시오.

경고에 진행 버튼이 없습니다

Problem: Paste Anyway 선택지도 없고 진행할 뚜렷한 방법도 없습니다.

Solution: 이것을 버그가 아니라 의도된 결과로 받아들이십시오. 언론 보도는 진행 불가 경고를 알려진 악성코드 시그니처 일치와 연결하고, Apple은 메모리에서 실행되는 스크립트는 전혀 무시하고 진행할 수 없다고 문서화하고 있습니다. 명령어를 손으로 다시 타이핑하지 말고, 다른 터미널에서 시도하지 말고, 어떤 것도 비활성화하지 마십시오. 그 명령어를 준 출처를 닫고 적대적인 것으로 간주하십시오. 차단이 걸리기 전에 일부라도 실행되었다면, 네트워크 분리부터 시작해 위의 대응 절차를 진행하십시오.

같은 명령어에 대해 경고가 계속 뜹니다

Problem: 경고를 닫고 다시 시도했는데, 매번 다시 나타납니다.

Solution: 이 보호 기능들은 명령어별 허용 목록을 유지하지 않으므로, 누적되는 기억된 결정이 없습니다. 반복되는 경고는 반복된 평가가 같은 결론에 도달했다는 뜻이며, 이는 오작동이 아니라 정보입니다. 휴리스틱 경고이고 출처를 제대로 검증했다면, 진행 선택은 시도할 때마다 이뤄집니다. 알려진 위협 경고라면, 반복은 시스템이 같은 참인 사실을 다시 말해 주는 것입니다. 그 소프트웨어가 정말 필요하다면 다른 방법으로 설치하십시오. 서명된 설치 패키지, 이미 신뢰하는 패키지 관리자, 또는 있다면 App Store 버전을 이용하십시오.

아무것도 붙여넣어지지 않았는데 차단된 것인지 알 수 없습니다

Problem: Command-V를 눌렀는데 아무것도 나타나지 않았고, 보이는 경고도 없습니다.

Solution: 시시한 원인부터 배제하십시오. Terminal이 실제로 키보드 포커스를 가지고 있는지 확인하고, 일반 텍스트 편집기에 붙여넣어 복사가 성공했는지 확인하고, 경고창이 다른 창 뒤나 다른 디스플레이에 열려 있는지 확인하십시오. 텍스트 편집기에는 잘 붙여넣어지는데 Terminal에서는 안 된다면 보호 기능이 합리적인 용의자이고, 이제 그 텍스트 편집기가 여러분이 실행하려던 것을 읽어볼 기회를 줍니다. 다시 시도하기 전에 거기서 읽어보십시오. 붙여넣기는 됐는데 Return을 누른 뒤 아무 일도 일어나지 않은 것 같다면, pasteboard 명령어 차단 가능성으로 보고 활성 상태 보기에서 낯선 프로세스를 확인하십시오.

개발자인데 경고가 그만 뜨게 하고 싶습니다

Problem: 붙여넣기 경고가 평소 작업을 방해합니다.

Solution: 솔직히 말하면, Apple은 이 보호 기능들에 대한 사용자용 스위치를 제공하지 않으며, 이 글은 그것을 무력화하는 방법을 설명하지 않을 것입니다. 다만 문서화된 동작이 이미 여러분의 문제를 해결해 줍니다. 붙여넣기 경고는 사용자가 30일 넘게 Terminal을 열지 않았고 그리고 일반적인 개발자 도구가 감지되지 않으며 그리고 붙여넣기가 특정 앱에서 왔을 때만 작동합니다. 여러분이 이 경고를 자주 만난다면, 유용한 질문은 왜 여러분의 기기가 시스템에게 개발 기기처럼 보이지 않는가입니다. 평범한 개발자 도구를 갖춰 두고 Terminal을 평소 작업 흐름의 일부로 사용하는 것이 이 경고에서 벗어나는 의도된 경로이지, 숨겨진 설정이 있는 것이 아닙니다.

이미 Paste Anyway를 눌렀고 지금 후회하고 있습니다

Problem: 경고를 무시하고 진행했고, 명령어가 실행되었으며, 그 뒤에 출처를 의심하기 시작했습니다.

Solution: 위의 대응 절차로 가서 1단계, 즉 Mac을 네트워크에서 분리하는 것부터 시작하십시오. 눈에 보이는 증상을 기다리지 마십시오. Huntress 연구에서 설명한 악성코드는, 잔액의 1%까지 조정 가능한 암호화폐 탈취 기능을 포함해 증상을 만들지 않도록 특별히 설계되었기 때문입니다. 먼저 다른 기기에서 자격 증명을 변경하십시오. 경고를 무시하고 진행해도 pasteboard 명령어 차단은 비활성화되지 않으므로 그 뒤에 프로세스가 중단되었을 가능성도 있지만, 증거 없이 그렇다고 가정해서는 안 됩니다.

자주 묻는 질문

어떤 macOS 버전에 이 보호 기능들이 있나요?

Apple의 플랫폼 보안 문서는 Terminal Paste Protection, pasteboard 명령어 차단, AppleScript 검사를 macOS 26.4 이상에서 도입된 것으로 설명합니다. 그 이전 버전에는 없습니다. 더 오래된 버전을 쓰면서 Terminal에 명령어를 붙여넣는다면, 여기서 설명한 동작 중 어느 것도 여러분의 기기에는 해당되지 않습니다.

iTerm2, Warp, Ghostty에서도 작동하나요?

부분적으로만 그렇습니다. Apple은 붙여넣기 경고를 Terminal 앱의 기능으로 문서화하므로, 서드파티 터미널은 개발자가 동등한 기능을 만들지 않는 한 그것을 표시하지 않습니다. 하지만 Apple은 XProtect가 결과 프로세스 트리를 추적하기 때문에 pasteboard 명령어 차단이 서드파티 애플리케이션을 포함한 모든 터미널 에뮬레이터를 포괄한다고 밝힙니다. 경고는 잃고, 최후 방어선은 유지합니다.

이 보호 기능들을 끌 수 있나요?

Apple은 이에 대한 사용자용 스위치를 제공하지 않으며, 이 글은 우회 방법을 설명하지 않습니다. 오탐을 겪는 개발자라면 문서화된 트리거 조건이 답입니다. 붙여넣기 경고는 일반적인 개발자 도구가 설치된 기기나 지난 30일 안에 Terminal을 연 기기에서는 작동하지 않습니다.

Paste Anyway가 올바른 선택인 경우도 있나요?

네, 한 가지 상황에서 그렇습니다. 여러분이 그 소프트웨어를 직접 찾아 나섰고, 직접 이동해 공식 문서에 도달했으며, 명령어가 프로젝트가 공개한 것과 일치하는 경우입니다. 그것은 실제 오탐 시나리오이고, 무시하고 진행하는 선택지는 그것을 위해 존재합니다. 여러분이 찾아간 것이 아닌 페이지가 명령어를 건네준 것이라면, 답은 아니오입니다.

아무것도 차단되지 않았다면 그 명령어는 안전한 건가요?

아닙니다. 이 보호 기능들은 알려진 시그니처와 인식된 동작 패턴을 잡아내므로, 새로운 인프라를 쓰는 진짜로 새로운 공격은 아무것도 작동시키지 않고 통과할 수 있습니다. 침묵은 보증이 아닙니다. 이 글의 판단 기준, 특히 그 명령어를 여러분이 찾아 나섰는지에 대한 질문이 여전히 주된 방어책입니다.

뭔가 통과했다면 제가 어떻게 알 수 있나요?

대개는 알 수 없고, 그것이 불편한 부분입니다. Huntress는 모니터링 중이던 Mac이 탐지되기 약 3개월 전에 감염되었다고 보고했고, 피해자가 눈치채지 못하도록 1%까지 조정 가능한 암호화폐 탈취 기능을 설명했습니다. 증상을 기다리지 말고 로그인 항목, 구성 프로파일, 계정 세션을 확인하십시오.

결론

Mac이 붙여넣기를 차단했습니다. 그것은 작고 시시한 사건이지만, 때로는 그해 그 기기에 일어난 가장 중요한 일로 밝혀집니다.

유용한 사고 모형은 계층입니다. Terminal Paste Protection은 사람 계층으로, 평소 Terminal을 쓰지 않고 방금 브라우저나 메시지에서 뭔가를 복사한 사람을 겨냥해 의도적으로 좁게 설계된 개입입니다. Pasteboard 명령어 차단은 기계 계층으로, 서드파티를 포함한 모든 터미널 에뮬레이터에 대해 결과 프로세스 트리를 XProtect 수준에서 다룹니다. AppleScript 및 JXA 검사는 스크립팅 경로를 담당하며, 파일 기반 스크립트에는 진행 선택지가 있고 메모리에서 실행되는 스크립트에는 전혀 없습니다. 각 계층은 나머지가 실패할 수 있다고 가정하며, 그것이 올바른 가정입니다.

하지만 이 보호 기능들은 범위가 좁고, 그 한계를 솔직하게 요약하면 이렇습니다. 백신이 아니고, 손으로 타이핑한 것은 읽지 않으며, 알려진 시그니처가 없는 새로운 페이로드는 잡지 못하고, 설계상 대부분의 개발자에게는 절대 작동하지 않습니다. 반면 이들이 막으려는 공격은 자금이 넉넉하고 잘 만들어져 있습니다. Microsoft Threat Intelligence는 방문자를 핑거프린팅하고 연구자를 찾아내는 250개가 넘는 프런트엔드 도메인을 보고했습니다. Huntress는 눈치채는 문턱 아래에 머물도록 조율된 탈취 기능으로 Apple Keychain을 노리는 스틸러를 설명했습니다.

그래서 다시 소프트웨어가 대신해 줄 수 없는 그 한 가지로 돌아옵니다. 터미널에 무언가를 붙여넣기 전에, 질문 하나에 답하십시오. 내가 이 명령어를 찾아 나선 것인가, 아니면 무언가가 실행하라고 시킨 것인가? 찾아 나선 것이라면, 도메인이 그 프로젝트 자체의 것인지와 명령어가 프로젝트가 공개한 것과 일치하는지 확인한 뒤 진행하십시오. 무언가가 시킨 것이라면 기본값은 아니오이고, 입증 책임은 시킨 쪽에 있습니다. 그 질문은 5초면 되고, 과거와 미래를 통틀어 이 공격의 모든 변종에 통하며, 셸 코드를 한 줄도 읽을 필요가 없습니다.

명령어가 이미 실행되었더라도 자책의 소용돌이에 빠지지 마십시오. 네트워크에서 분리하고, 다른 기기에서 자격 증명을 변경하고, Keychain에 있는 모든 것을 교체하고, 암호화폐는 깨끗한 기기에서 생성한 지갑으로 옮기고, 초기화를 계획하십시오. 이 공격은 설득력 있도록 설계되었습니다. 거기에 넘어간 것은 인격의 결함이 아니고, 복구는 재앙이 아니라 하나의 목록입니다.

관련 읽을거리: 비밀번호를 요구하는 가짜 Mac 충돌 보고서? 절대 입력하지 마세요