블록체인 DNS와 IDN(퓨니코드)¶

이 페이지에서 다루는 것

압수를 피하려는 블록체인 DNS(EmerDNS, ENS, 게이트웨이, EtherHiding)와 탐지 기회, 다른 나라 글자로 만든 가짜 도메인(IDN 호모글리프)과 퓨니코드 읽는 법, 메일·모바일 앱 속 IDN과 실제 공격 사례.

표기

[보충] = 꼭 알아야 할 실무 보충, [정정] = 흔히 잘못 알려진 내용 정정, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. 전체 흐름은 DNS 개요에서, 기록 한 줄을 판별하는 순서는 판별표에서 볼 수 있습니다.

블록체인 DNS¶

공격자는 도메인 압수를 피하려고 블록체인 DNS를 씁니다. 대신 일반 DNS로는 조회가 안 되는 약점이 생기고, 그 약점이 탐지 기회입니다.

공격자와 방어자의 주고받기¶

단계	악성코드에 넣는 것	방어자 대응	결과
1	IP 주소(하드코딩)	IP 차단·서버 제거	감염 PC가 새 주소를 몰라 공격자가 전부 잃음
2	도메인 이름	IP 차단	공격자가 A 레코드만 바꾸면 감염 PC 전체가 새 서버로(짧은 TTL로 빠르게) → 두더지 잡기
3	도메인 이름	도메인 압수·싱크홀	이름 자체가 사라짐 → 방어자 유리
4	블록체인 도메인	압수 불가	일반 DNS로 조회가 안 되는 약점을 탐지

핵심¶

블록체인 DNS는 레코드를 공개 블록체인에 저장 → 중앙 관리자가 없어 신고·압수 불가. 단 압수 불가한 것은 이름 → IP 대응뿐, 서버는 일반 인터넷에 있어 서버 제거·IP 차단은 가능
EmerDNS TLD: .coin, .emc, .lib, .bazar(BazarLoader/BazarBackdoor가 C2에 사용한 것으로 널리 보고)
ICANN 루트 밖이라 회사 DNS·8.8.8.8 모두 NXDOMAIN. 쓰려면 특수 소프트웨어·악성코드 자체 조회·대체 DNS(OpenNIC) → 결국 허가되지 않은 DNS·특이 흔적
탐지: 블록체인 TLD 조회, IANA 공식 TLD 목록에 없는 TLD 조회(내부 이름 .local/.corp, 오타, Chrome 하이재킹 테스트는 예외), 비인가 DNS, 소프트웨어·프로토콜 통제

복습 Q&A

피할 수 있는 것: 도메인 정지·압수·싱크홀. 피할 수 없는 것: 서버 제거·IP 차단, 그리고 "일반 DNS로 조회 안 됨"이라는 흔적
node3.bazar NXDOMAIN을 "실패했으니 문제없음"으로 닫으면 안 됨: 조회 자체가 PC 안의 악성코드 증거. 실패 후 다른 경로(대체 DNS, DoH, IP 직접)로 재시도했을 수 있음 → 같은 PC의 비인가 DNS·853·DoH·직접 IP 접속, 조회 프로그램(Sysmon 22), 다른 PC 조회 여부, 시작 시점 확인 후 격리
"IANA 목록에 없는 TLD" 규칙의 정상 오탐: 내부 이름(.local, .corp, .lan, .home.arpa는 공식), 오타, 점 없는 한 단어(Chrome 테스트·NetBIOS식 짧은 이름), 일부 VPN·개발 도구. 못 잡는 것: 게이트웨이 경유(.eth.limo, ipfs.io), EtherHiding(블록체인 노드 API를 일반 HTTPS로), DoH로 감싼 조회, 공식 TLD를 쓰는 블록체인 서비스

2026년 관점

OpenNIC은 2019년경 악성 악용 때문에 EmerDNS 연결을 끊은 것으로 알려짐(예전 자료의 설명은 낡았을 가능성)
주인공 교체: ENS(.eth), Unstoppable Domains(.crypto 등), Handshake + IPFS
게이트웨이: 블록체인 이름을 평범한 웹 주소로 바꿔주는 중간 사이트(vitalik.eth.limo, ipfs.io/ipfs/Qm...). 회사 DNS를 정상적으로 거치고 공식 TLD라 "낯선 TLD" 규칙 우회. 내리기 어려운 피싱에 악용 → 게이트웨이 도메인 목록 관리, 업무상 불필요하면 차단, 메일 클릭 직후 접속 주목
EtherHiding(Guardio, 2023): 스마트 컨트랙트(지울 수 없는 공개 게시판 칸)에 C2 주소·악성 코드를 저장하고 블록체인 노드 API를 일반 HTTPS로 읽음. DNS 판별표를 거의 다 통과 → 누가·어떤 프로그램·그다음(API 조회 직후 DNS 없이 IP 직접 접속)을 보는 맥락·행동 탐지

IDN과 퓨니코드¶

영어와 똑같이 생긴 다른 나라 글자로 만든 가짜 도메인은 사람 눈으로는 구분이 안 되지만, DNS 기록에는 반드시 xn--로 시작하는 퓨니코드로 남습니다.

핵심¶

yоutube.com은 마우스를 올려도 똑같이 보이지만 두 번째 o가 키릴 문자(U+043E) → "링크에 마우스 올리기" 교육으로 못 잡음
DNS는 원래 영어 소문자·숫자·하이픈만 → 다른 글자는 퓨니코드로 변환해 DNS에 넣음(IDN). 예: Καλημέρα.gr = xn--ixahbwnhi5b.gr, 한국.kr = xn--3e0b707e.kr
키릴 О, 영어 O, 그리스 Ο처럼 모양이 같은 글자로 속이는 것 = 호모글리프(호모그래프) 공격. 철자 바꾸기(micros0ft)·글자 쌍(rnicrosoft)과 달리 자세히 봐도 구분이 안 될 수 있음
퓨니코드 구조: xn-- + 영어 글자 모음 + - + 영어 아닌 글자 정보. 예: xn--yutube-wqf.com. 모든 IDN은 xn--로 시작(하위 이름·TLD 등 어느 덩어리에도 올 수 있음) → 기록에서 xn-- 검색으로 찾음
두 번째 부분과 원래 브랜드를 비교하면 빠진 글자 = 바꿔치기한 자리. 예: xn--pypal-4ve.com → pypal은 paypal에서 첫 번째 a가 빠짐 → pаypal.com(키릴 а U+0430). 두 번째 a를 바꾸면 xn--paypl-7ve.com
변환은 외부 사이트 대신 내 컴퓨터에서: python3 -c "print(b'xn--yutube-wqf.com'.decode('idna'))", 영어 아닌 글자 번호는 ord(c) > 127로 확인
xn--가 곧 악성은 아님: 한 문자 체계로만 된 자연스러운 이름(한국.kr, münchen.de)은 대개 정상. 영어 이름 흉내 + 문자 체계 섞임이 강한 신호(аррӏе.com은 a·p·p·l·e 전부 키릴)

복습 Q&A

"마우스 올리기" 교육이 안 통하는 이유: 링크 텍스트와 실제 주소가 둘 다 같은 가짜 주소이고 화면 표시가 진짜와 같음. 퓨니코드가 아니라 원래 글자로 보이는 것이 문제. 방어자 대책: xn-- 조회 경보, 브랜드 IDN 변형 감시(crt.sh), 메일 보안의 IDN 링크 퓨니코드 표시·경고, 패스키·보안 키(도메인을 기계가 정확히 비교)
"xn-- 전부 차단"은 정상 다국어 사이트를 막음. 더 정확한 기준: 문자 체계(스크립트)가 섞인 IDN은 차단·경보, 한 문자 체계 IDN은 허용하되 풀었을 때 유명 브랜드·우리 도메인과 비슷한 것은 경보. 주의: ɡ(U+0261)처럼 같은 라틴 문자 체계 안의 비슷한 글자는 "섞임" 규칙에 안 걸림 → 브랜드 비교가 함께 필요. 반대로 "영어 + 비영어 글자" 전부 차단은 münchen.de 같은 정상 이름을 막음

2026년 관점

2017년 аррӏе.com 시연 후 브라우저들이 섞인 문자·흉내 낸 이름은 주소창에 퓨니코드로 표시, Chrome은 유사 사이트 경고 화면도 있음(세부 조건은 버전마다 다름)
[주의] 그래도 메일·채팅·문서 안에서는 원래 글자로 보여 클릭 전 단계는 여전히 취약. 앱 내장 브라우저는 규칙이 다를 수 있음
TLD 운영 기관마다 "문자 체계 섞기 금지" 등 등록 제한이 있으나 제각각. ᏚĖCUREBANK.com = xn--curebank-3db3419b.com(체로키 Ꮪ U+13DA + ė U+0117)
근본 대책: 패스키·FIDO2 보안 키

앱 속 IDN과 실제 공격¶

브라우저는 페이지가 열린 뒤에 퓨니코드를 보여주지만, 메일·문서·휴대폰 화면에서는 원래 글자로 보여 클릭 전에 막기 어렵습니다. 실제 공격에는 같은 라틴 문자 체계 안의 바꿔치기도 많습니다.

앱 속 IDN¶

시간 순서: 메일에 원래 글자로 보임 → 클릭 → 페이지 열림(이때 주소창에 퓨니코드) → 사용자 의심. 브라우저 보호는 페이지가 열린 뒤 작동하므로 악성 파일·취약점 공격은 이미 시작했을 수 있음
같은 IDN도 앱마다 다르게 보임: Outlook 데스크톱, Gmail 웹, Outlook·Gmail 모바일, iOS 알림. 글꼴에 따라 속는 정도가 다르고, 글꼴은 앱·기기가 정함
휴대폰이 특히 취약: 작은 글씨, 주소 숨김, 마우스 올리기 불가, 알림에서 바로 클릭
대책은 사용자 화면 도달 전: 메일 보안(퓨니코드 표시·경고·격리), 링크 재작성과 클릭 시점 검사, DNS 단계 차단, 패스키·보안 키

실제 공격¶

화면 모습	DNS 기록	바뀜 글자	문자 체계 섞임?
`ᏚĖCUREBANK.com` (예시)	`xn--curebank-3db3419b.com`	Ꮪ U+13DA(체로키), ė U+0117	예(라틴+체로키)
`ḟacebook.com`	`xn--acebook-js3c.com`	ḟ U+1E1F	아니오(라틴만)
`morɡanstanley.com`	`xn--moranstanley-0df.com`	ɡ U+0261	아니오(라틴만)
`lloydsbankingɡroup.com`	`xn--lloydsbankingroup-0ch.com`	ɡ U+0261	아니오(라틴만)

대상은 Facebook·모건스탠리·로이드·유나이티드헬스 등 돈·개인정보와 직결된 기업
같은 라틴 체계 바꿔치기는 "문자 체계 섞임" 규칙에 안 걸림 → 브랜드 유사 비교(헷갈리는 글자를 기본 영어로 바꾼 뒤 브랜드 목록과 비교, UTS #39 confusables). 퓨니코드 두 번째 부분이 브랜드에서 한두 글자 빠진 형태(moranstanley)면 강한 신호
슬래시 모양 글자: bankofamerica.com∕index.jp의 진짜 등록 도메인은 com∕index.jp, bankofamerica는 하위 이름. U+2215를 쓰면 DNS에는 bankofamerica.xn--comindex-0f7d.jp. 오른쪽부터 읽기의 극단적 사례(연구자 소유)

복습 Q&A

함정: xn--micrsoft-07a.com처럼 그럴듯해 보여도 실제로 풀면 miăcrsoft.com(ă U+0103)일 수 있음. 키릴 o 예: micrоsoft.com(첫 o가 키릴) = xn--micrsoft-qbh.com, microsоft.com(두 번째 o) = xn--microsft-sbh.com. 두 번째 부분으로 브랜드·빠진 글자는 추측 가능하지만, 어떤 문자 체계인지는 풀어서 유니코드 번호를 봐야만 알 수 있음(키릴 о인지 라틴 ö인지)
"브라우저가 퓨니코드를 보여주는데 왜 안심 금지": 메일(원래 글자) → 클릭 → 페이지 열림 → 그제서야 주소창 퓨니코드. 대책: 메일 단계 퓨니코드 표시·격리, 클릭 시점 검사, DNS 차단, 패스키
paypal.com/login.secure-check.co: /가 가짜 슬래시면 전체가 도메인 → 등록 도메인 secure-check.co(하위 이름 paypal.com∕login). 진짜 슬래시면 등록 도메인 paypal.com, 뒤는 경로. 화면은 똑같아도 주인이 완전히 다름

2026년 관점

슬래시 트릭: 옛 규칙(IDNA2003)은 변환하지만 현재 규칙(IDNA2008/UTS #46)은 U+2215·U+2044를 거부(직접 확인) → 대부분 막힘. 같은 체계 바꿔치기(ɡ, ḟ)는 현재 규칙에서도 허용 → 실무에서 더 중요
클릭 시점 검사(Safe Links 등) 표준화, 단 클로킹에 약함
SMS·메신저 피싱 증가 → 메일 보안 밖. MDM·모바일 Protective DNS
교육은 "주소를 잘 봐라"에서 "메시지 링크로 로그인하지 말라, 패스키를 써라"로