사기의 바다를 건너는 등대: 한국편

사례·심리·대응·회복, 우리에게 필요한 한 권. 10장

Part II. 공격 벡터별 플레이북(한국 현장 대본 포함)

10장. 웹·모바일: 가짜 정부24/금융앱·악성 APK·BiTB(브라우저 속 창)

10.0 서문 — 손안의 세상, 손안의 위험

아침 7시 32분.
알람을 끄자마자 우리는 화면을 켠다.
은행 잔액을 확인하고, 정부24에서 가족관계증명서를 내려받고, 배달앱으로 커피를 주문한다.
우리의 하루는 손바닥 위에서 시작된다.

하지만 — 그 화면의 **‘진짜와 닮은 가짜 창’**을 떠올려본 적이 있을까?
정부24의 로고도 같고, 주소창도 https로 반짝인다.
그러나 그 안쪽 코드 한 줄은 이미 당신의 이름과 주민번호, 공인인증서 비밀번호를 삼킨다.
그들은 현실을 복제하고, 당신의 신뢰를 코드로 연기한다.

이제 범죄자는 총을 들지 않는다.
그들은 UI(User Interface), 즉 ‘사용자의 눈’을 겨냥한다.
‘로그인 창’으로 위장한 악성 APK,
‘은행 앱’을 가장한 피싱 웹뷰,
‘브라우저 속 또 다른 브라우저(Browser-in-the-Browser, BiTB)’ —
그 안에서 사람들은 진짜와 가짜의 경계를 잃는다.

모바일은 우리의 지갑이자 열쇠이며, 서명도장이다.
그만큼, 그것은 오늘날 가장 매력적인 공격 표적이다.
우리는 손안에 세상을 쥐었지만,
그 세상이 우리를 어떻게 열어젖히는지는 잊고 산다.

10장은 바로 그 이야기다.
화면의 미소 뒤에 숨은 덫,
보안의 이름으로 위장한 ‘친절한 사기’의 기술을 해부한다.

10.1 가짜 정부·공공 서비스 페이지 — ‘공권력의 가면’

짧은 우화
아침에 온 문자는 공손했다.
“[정부24] 긴급 통지: 주민등록등본 갱신 필요 — 아래 링크에서 확인하세요.”
로고는 친숙했고, 주소창에는 자물쇠가 반짝였다.
그녀는 북마크 대신 메시지를 탭했고, 로그인 창이 열리자 아무 생각 없이 정보를 입력했다.
그날 오후, 은행에서 걸려온 전화는 낯설게도 친절했다.
“고객님, 최근에 본인 확인을 위해 등록하신 기기와 다른 기기에서 접근이 감지되어…”
그녀는 깨달았다. 그 ‘공문’은 진짜가 아니었다. 공권력의 얼굴을 한 ‘연극’이었다.

실전 해설
공공기관의 형식(로고·문체·도장)은 사람의 마음을 금방 신뢰로 이끈다.
사기꾼은 그 점을 안다. 그래서 **‘공권력의 가면’**을 만들어 당신을 무장해제시킨다.
몇 가지 기술적 수법이 자주 쓰인다.

도메인 유사성: gov.kr처럼 보이지만, 철자가 한 글자 다르거나 서브도메인으로 교묘히 위장되어 있다.

SSL 자물쇠의 오해: 자물쇠(HTTPS)는 통신 암호화를 나타내지만, 자물쇠 = 신뢰의 보증은 아니다. 공격자도 HTTPS를 쓸 수 있다.

URL 단축·리다이렉션: 단축주소나 광고 트래킹을 거치며 진짜 주소를 숨긴다. 클릭 한 번으로 가짜 페이지로 넘어간다.

요지는 단순하다 — ‘보이는 것’이 진짜임을 보장하지 않는다.
우리가 믿어야 할 것은 ‘이미지’가 아니라, ‘출처’와 ‘검증 가능한 경로’다.

탐지·대응 포인트 (즉시 적용 가능한 실전 체크리스트)

URL을 직접 입력하거나 북마크로 이동하라. 문자·카톡의 링크는 절대 클릭하지 않는다. 공식 포털은 직접 주소를 입력하거나 저장된 북마크로 접근한다.

주소창 전체를 확인하라. 자물쇠만 보지 말고, 도메인 전체(예: hometax.go.kr)를 끝까지 읽어라. gov, go, co 등 유사 문자열에 주의.

자물쇠 클릭 후 인증서 발급자 확인(간단) 브라우저의 자물쇠 아이콘을 누르면 발급자 정보가 나온다. 발급자가 ‘국가기관’이라고 쓰여 있진 않지만, 낯선 발급자나 무료 인증서(예: Let’s Encrypt만 반복 사용)는 의심 포인트다.

단축URL·리디렉션 경로 의심 단축URL을 받았다면 미리보기(확장 서비스)로 원본 주소를 확인하거나, 메시지 보낸 이에게 직접 문의한다.

공공포털의 2단계 인증 경로 확인 공공서비스는 고유한 2단계(공동인증서/공인인증서·모바일 인증 등)를 제공한다. 로그인 흐름이 그 경로와 다르면 중단하라.

의심되면 캡처 → 오프라인 확인 페이지를 캡처해 저장하고, 공공기관 고객센터(공식 번호)로 문의해 진위 여부 확인.

실전 과제: ‘가짜/진짜 페이지 구별 챌린지’ (팀 워크숍용, 15분)

준비물: 랜덤으로 섞은 8개의 페이지 스크린샷(4개 진짜, 4개 가짜).

미션: 각 페이지의 URL·인증서·문구·작동 흐름을 60초 내에 점검해 ‘진짜/가짜’ 판정.

토론 포인트: 왜 가짜로 의심했는가? 어떤 근거로 진짜라 판단했는가?

학습 목표: ‘자물쇠 착시’와 ‘도메인 전부 읽기’가 습관이 되게 한다.

한 줄 기억

“공권력의 얼굴은 쉽게 빌려줄 수 있어도, 진짜 권한은 오직 검증된 손에만 맡길 수 있다.”

10.2 가짜 금융앱·앱 스푸핑 — ‘지갑을 닮은 가면’

짧은 우화
퇴근길, 지하철 난간에 붙은 할인 광고를 스크롤하다가 눈에 들어온 문구.
“이달의 특별 혜택 — 공식 은행 앱 업데이트(빠른 설치)”
링크를 누르니 앱 아이콘은 낯익고, 설명도 친절하다.
설치하고 로그인하니 잔액 조회 화면이 반짝였다.
다음 날, 문자로 이상한 이체 알림이 오고, 고객센터는 이미 연결되지 않았다.
그가 설치한 것은 ‘지갑을 닮은 가면’이었다 — 겉보기엔 은행 앱, 속은 훔치기 위한 도구.

실전 해설
모바일은 지갑이자 서명 도구다.
공식 스토어 밖에서 유통되는 APK(안드로이드 패키지)나, 스토어에 근사하게 모방된 앱은 사용자의 인증 정보·토큰·권한을 노린다.
주요 수법은 세 가지다.

사이드로딩(외부 APK 설치) — 공식 스토어를 거치지 않고 설치되므로 검증과 보호가 없다.

서명 우회·패키지명 복제 — 개발자 서명이나 패키지명을 흉내 내 공격자는 앱이 ‘정상’으로 보이게 한다.

앱 내 UI 위조(오버레이) — 합법 앱 위에 악성 화면을 덮어 실제 버튼을 가로채거나 입력 정보를 훔친다.

사람은 편리와 긴급, 혜택 앞에서 방심한다. 사기꾼은 그 방심을 ‘설치’로 연결한다.
따라서 모바일 보안은 단지 “앱을 깔지 않는 것”이 아니라, ‘무엇을, 어디서, 왜’ 깔았는지를 아는 습관이다.

탐지·대응 포인트 (즉시 적용 가능한 체크리스트)

설치 출처 확인 Android: 개발자 옵션에서 “출처 불명 앱 설치 허용” 권한이 켜져 있지 않은지 확인. iOS: 애플은 사이드로딩을 기본적으로 막지만, 프로파일 설치 요구 시 즉시 의심.

앱 권한 검토 금융 앱이 SMS·전화·연락처 등 과도한 권한을 요구하면 즉시 의심. 권한 요청은 기능과 일치해야 한다(잔액 조회에 연락처 접근은 불필요).

앱 서명·개발사 정보 확인 Play Store/앱스토어에서는 개발사명·리뷰·설치수 확인. Android APK는 서명자가 누구인지(개발자 키) 확인 가능(기업용 MDM 환경에서는 자동 확인).

Play Protect·공식 스토어 우선 사용 공식 스토어의 ‘검증 마크’와 리뷰를 신뢰하되 완전한 안전 보장은 아님을 인지. 스토어 외 출처는 원칙적으로 금지.

의심 앱 행동 감시 설치 직후 과도한 트래픽·배터리 소모·알림 스팸이 발생하면 제거 및 포렌식 조사.

실전 과제: ‘앱 권한 리뷰 워크숍’ (팀 단위·60분)

준비물: 실제 앱 권한 화면 캡처 10종(금융·유틸·게임 혼합)

미션: 각 앱의 권한 요청을 보고 ‘정상/과도/의심’(3단계)로 분류하고, 그 이유를 기록한다.

토론 포인트: 이 앱이 왜 이 권한을 요구할까? 만약 회사에서 사용하라고 권한다면 어떤 검증을 요구할 것인가?

발표: 팀별 상위 3개 의심 앱과 대응 절차(삭제·신고·포렌식 요청)를 발표.

학습 목표: 권한의 의미를 해석하는 눈을 기르고, 설치 전 최소 3가지 확인을 습관화(출처·개발사·권한).

한 줄 기억

“지갑을 닮은 앱일수록, 그 속에 든 손을 먼저 의심하라 — 편리의 얼굴 뒤엔 종종 훔치려는 손이 있다.”

10.3 악성 APK와 사이드로딩 — ‘백도어를 품은 파일’

짧은 우화
어느 날, ‘업데이트 필요’라는 작은 알림이 떴다.
친절한 안내문엔 “보안 향상”과 “사용자 편의 개선”이 적혀 있었다.
그녀는 버튼을 눌렀고, 파일 하나가 내려앉았다 — 이름은 평범했지만, 속은 달랐다.
그 파일은 조용히 백그라운드 서비스를 띄우고, 기억 속 토큰과 메시지를 훔쳐갔다.
밤이 되자, 그녀의 계정은 낯선 기기에서 로그인되었고, 알림은 이미 늦은 뒤였다.

실전 해설
APK는 안드로이드의 ‘프로그램 상자’다.
공식 스토어를 통하면 적어도 누군가가 그 상자를 검수하지만, 사이드로딩(외부 설치)은 그 상자를 직접 받아 손에 쥐는 행위다.
공격자는 ‘업데이트’와 ‘편의 기능’이라는 친절한 말로 손을 내민다.
그 상자를 설치하면, 앱은 단순한 화면 표시를 넘어 **서비스(백그라운드 프로세스)**로 깔리고, 토큰·키·SMS·알림을 수집해 외부로 전송할 수 있다.
사실상 그것은 눈에 보이지 않는 **뒷문(백도어)**이며, 당신의 기기를 관찰·조종하는 원격 콘솔이 된다.

핵심은 단 하나다: 설치의 주체가 신뢰 가능한가?
편리함 뒤의 파일은, 때로는 당신의 지갑과 프라이버시의 문을 열어젖힌다.

탐지·대응 포인트 (즉시 적용 가능한 행동지침)

외부 APK 절대 설치 금지(원칙) 회사 정책으로 ‘출처 불명 앱 설치 금지’ 명문화. 개인 기기라도 업무용 앱은 공식 경로만 허용.

APK 해시·서명 확인 APK를 수동으로 받을 경우, 제공자가 알려준 공식 서명·해시값과 비교(해시 불일치 시 절대 설치 금지).

설치 전 권한·행동 예측 설치 화면에서 요구하는 권한이 앱 기능과 일치하는지 확인(예: 계산기에 SMS 권한은 불필요).

모바일 EDR(Endpoint Detection & Response) 도입 검토 엔터프라이즈 환경에선 모바일 EDR로 이상 행위(비정상 통신, 루트 시도, 과도한 권한 사용) 탐지 설정.

앱 샌드박싱·네트워크 분리 의심 앱은 격리된 네트워크에서 실행하거나, 회사 정책상 테스트 디바이스에서 먼저 검증.

로그·네트워크 모니터링 강화 설치 후 비정상 DNS 쿼리, 장기 유지되는 백그라운드 연결, 과도한 업로드 트래픽 감지 시 즉시 제거 및 포렌식.

긴급 대응 절차 의심 설치 확인 시: 네트워크 분리 → 앱 제거(가능 시) → 메모리/디스크 이미지 확보 → 보안팀 신고 → 계정·토큰 리셋.

실전 과제: ‘안전한 설치 체크리스트’ 제작 및 배포 (팀 워크숍용)

목표: 사용자가 설치 전 7가지 항목을 스스로 점검하는 습관을 만들기.

체크리스트 (A4 1장 요약용)

출처 확인 이 앱은 공식 스토어(Play Store) 또는 회사 공식 배포 채널에서 제공되었는가? (Y/N)

제공자 검증 개발사 명과 배포자의 연락처/도메인이 공식과 일치하는가? (Y/N)

해시/서명 확인(수신 APK일 경우) 제공자가 제시한 SHA256 해시/서명과 파일이 일치하는가? (Y/N)

권한 적합성 검토 요청 권한이 앱 기능과 논리적으로 일치하는가? (예: 계산기에 SMS 권한 불필요) (Y/N)

리뷰·평판 확인 공식 스토어의 리뷰·평점·설치 수가 자연스러운 수준인가? (Y/N)

네트워크·트래픽 예측 이 앱이 네트워크 통신(백그라운드 포함)을 필요로 하는가? 필요 시 예상 목적과 일치하는가? (Y/N)

사후 행동 계획 수립 설치 후 이상 징후 발견 시(배터리 과다 소모·과도한 데이터 사용 등) 즉시 취할 조치(격리·삭제·보안팀 신고)를 알고 있는가? (Y/N)

활용법:

모든 직원에게 ‘앱 설치 전 7문항’ 체크를 의무화.

모바일 업무기기(또는 BYOD 등록 기기)에 체크리스트 스티커 부착 또는 디지털 팝업으로 노출.

월 1회 랜덤 점검(IT팀)이 체크리스트 준수 여부 확인.

한 줄 기억

“파일 하나 내려받는 손끝이, 때로는 백도어의 열쇠가 된다.
그러니 설치 전엔 꼭, ‘누가, 왜, 어떻게’인지 묻는 습관을 들이자.”

10.4 BiTB(브라우저 인더브라우저) — ‘창 속의 창, 함정의 심장’

짧은 우화 — 창 하나가 둘로 보이는 순간
늦은 밤, 쇼핑 앱에서 상품을 결제하려던 준호는 결제 버튼을 눌렀다.
순간, 화면 위에 부드러운 창 하나가 떠올랐다. 주소창도 있고, 자물쇠도 반짝였다.
“안전한 결제창 — 결제 정보를 입력하세요.”라는 문구는 너무나 친절했다.
준호는 비밀번호를 넣고, 카드 정보를 입력했다.
다음 날, 카드사에선 그 결제가 ‘외국’에서 이뤄진 것으로 찍혔고, 결제 취소는 이미 불가능했다.

그 창은 진짜 브라우저의 일부처럼 보였다.
하지만 보이는 창 속엔 또 다른 창이 숨어 있었고, 그 안의 입력란은 이미 누군가의 손에 복제되어 있었다.

설명 — BiTB가 왜 위험한가
Browser-in-the-Browser, 줄여서 BiTB는 시각적 기만의 정수다.
사용자는 ‘브라우저의 주소창·자물쇠·URL’을 신뢰의 신호로 보아 입력을 한다.
공격자는 그 신뢰 심리를 역이용해, 앱 내부(또는 페이지 내부)에 브라우저처럼 보이는 가짜 창을 띄워 정보를 가로챈다.

주요 기법:

iframe / webview 오용: 앱·페이지 안에서 실제 브라우저 UI를 흉내내는 레이어를 띄운다.

스크립트 입력 가로채기: 입력란에 타이핑되는 정보를 JS로 훔쳐서 외부로 전송한다.

시각적 신뢰 조작: 주소창·자물쇠·심지어 URL 일부를 복제해 사용자의 ‘무의식적 신뢰’를 유발한다.

결국 문제는 ‘보이는 것’만으로는 더 이상 충분치 않다는 사실이다.
우리는 이제 **“어떤 창이 진짜 브라우저인지”**를 구분할 줄 알아야 한다.

탐지·대응 포인트 — 실전 체크리스트

주소창 일관성 확인 결제·로그인 요청이 뜨면, 브라우저의 전체 주소창(프로토콜 포함) 을 읽어라. 주소창이 앱 내부에 떠있고, 시스템(브라우저) 주소창과 모양·위치가 다르다면 의심.

자물쇠 착시 경계 자물쇠가 보여도 안전을 보장하지 않는다. 자물쇠 클릭 → 인증서 정보 확인(가능하면). 앱 내부에 떠 있는 ‘자물쇠 아이콘’은 시각 요소일 뿐이다.

결제·인증의 오프체널 확인 결제 과정에서 ‘문자 인증’이나 ‘앱 전환’ 요구가 있을 때, 직접 결제 앱(은행·카드사 앱)을 열어 동일 내역이 표시되는지 확인.

브라우저 전체 주소창과의 불일치 감지 모바일 전환 시(앱→웹뷰) 상단 상태표시(시스템 바)·네비게이션 바의 유무를 확인. ‘뒤로 가기’·탭 전환 시 창의 반응이 자연스러운지 살핀다(비정상 딜레이는 합성 신호).

의심 징후 즉시 통화/중단 결제창의 디자인이 갑자기 바뀌거나, 의도와 다른 추가 입력을 요구하면 즉시 중단하고 공식 앱·사이트로 직접 접속.

기술적 권고(서비스 운영자용)

웹뷰 보안 정책 강화: allowFileAccess, JavaScriptInterface 등 위험 옵션 비활성화. 외부 콘텐츠 로딩 시 CSP(Content Security Policy) 적용.

인증 스택 노출 최소화: 실제 브라우저 주소창과 별개로, 결제/로그인 시 시스템 브라우저(External browser)로 열도록 설계 권장.

UI 무결성 표시: 공식 결제창은 고유한 “검증 배지”를 보여주고, 배지를 탭하면 서버측 검증 정보를 보여주도록 구현.

이상행위 모니터링: 결제 실행 전후 URL 불일치, iframe 사용 빈도, 의심스러운 스크립트 동작을 로깅·알람.

실전 과제 — BiTB 탐지 시연 (30분 워크숍)

데모 준비 A: 정상 결제 흐름(시스템 브라우저) 녹화 영상 B: BiTB 공격 데모(앱 내 webview로 가짜 브라우저 창 띄우기) 녹화 영상

식별 연습(15분) 참가자들에게 A/B를 섞어 보여주고, 화면의 어떤 요소가 ‘가짜’인지 60초 내에 적게 한다. 확인 항목: 주소창 전체(프로토콜 포함) 유무, 자물쇠 동작(클릭 반응), 뒤로가기 반응, 화면 레이아웃의 미세한 불일치.

토론(10분) 왜 사람들이 가짜 창을 진짜로 믿었는가? 어떤 UI 신호가 가장 설득력이 있었나? (색상, 위치, 문구 등)

매뉴얼 작성(5분) 각자 ‘결제 전 확인 5단계’ 한 줄 문구를 작성하여 공유: 예) “주소창 끝까지 읽기 → 자물쇠 클릭 → 팝업이 아닌 시스템 브라우저로 열기 → 결제 앱 확인 → 입력 전 3초 멈춤”

즉시 적용 가능한 3문장 대응 문구 (사용자용)

“이 창이 앱 내부에 떠 있다면, 결제는 멈추고 공식 앱을 직접 열어 확인하세요.”

“자물쇠가 보여도 안심하지 마세요 — 자물쇠를 탭해 인증서를 확인하거나, 시스템 브라우저로 열어 검증하세요.”

“조금이라도 이상하면 즉시 캡처하고 결제 중단, 공식 고객센터로 연락하세요.”

한 줄 기억

“창이 둘로 보일 때, 믿음이 반으로 쪼개진다.
진짜 브라우저는 당신에게 숨을 쉬는 시간을 준다 — 그 시간을 잃지 말라.”

10.5 인앱 오버레이·권한 오용 — ‘화면을 덮는 거짓’

짧은 우화 — 손가락이 닿기도 전에
민아는 은행 앱으로 송금을 하려 했다.
화면을 터치하자 친절한 안내창이 떠올랐다.
“추가 인증을 위해 화면을 터치하세요.”
그 창은 버튼을 크게 보여주었고, 민아는 아무 의심 없이 눌렀다.
잠시 후, 알림이 쉴 새 없이 울렸고 계좌 잔액은 빠르게 줄었다.
알고 보니 그 ‘안내창’은 앱 위에 덧씌워진 가짜 레이어였다.
진짜 버튼은 숨겨졌고, 그녀의 입력은 다른 곳으로 흘러갔다.

해설 — 왜 오버레이는 이렇게 교묘한가
오버레이(overlay)는 본래 접근성 보조나 유틸리티에서 쓰이는 기능이다.
하지만 공격자는 그 유용함을 악용한다.
앱 위에 덮어지는 창은 사용자의 시선을 빼앗고, 손가락의 경로를 재설정한다.
특히 접근성 권한이 허용된 앱은 화면을 덮고 입력을 가로채거나 버튼을 재배치할 수 있다.

문제의 핵심은 다음과 같다.

시각적 신뢰의 전유물화: 우리가 ‘보는 것’에 주는 신뢰를 이용한다.

권한의 역습: 접근성·오버레이 권한이 한 번 허용되면, 앱은 화면을 마음대로 꾸밀 수 있다.

자동화된 착시: 사용자는 자연스럽게 큰 버튼을 누르고, 그 행동은 공격자에게 전달된다.