스미싱(SMS 피싱)이란 무엇입니까?

스미싱은 점점 더 인기를 얻는 사이버 범죄 형태입니다. Proofpoint의 2024년 피싱 현황 보고서에 따르면 2023년에 조직의 75%가 스미싱 공격을 경험했습니다.¹

스미싱이 증가하는 데에는 여러 가지 요인이 있습니다. 우선, '스미셔'라고도 불리는 이러한 공격을 수행하는 해커는 피해자가 다른 링크보다 문자 메시지를 클릭할 가능성이 높다는 사실을 알고 있습니다. 동시에 스팸 필터의 발전으로 이메일과 전화 통화와 같은 다른 형태의 피싱은 표적에 도달하기가 더 어려워졌습니다. 

Bring Your Own Device(BYOD)와 원격 근무 조치의 증가로 인해 직장에서 모바일 디바이스를 사용하는 사람이 늘어나면서 사이버 범죄자들이 직원의 휴대폰을 통해 회사 네트워크에 더 쉽게 액세스할 수 있게 되었습니다.

스미싱 공격은 사기꾼이 가짜 메시지와 악성 링크를 사용하여 사람들을 속여 휴대폰, 은행 계좌 또는 개인 데이터를 손상시키는 다른 유형의 피싱 공격과 유사합니다. 가장 큰 차이점은 매체입니다. 스미싱 공격에서 사기꾼은 이메일이나 전화 통화 대신 SMS 또는 메시징 앱을 사용하여 사이버 범죄를 수행합니다.

사기꾼은 여러 가지 이유로 다른 유형의 피싱 공격보다 스미싱을 선택합니다. 연구에 따르면 사람들은 문자 메시지의 링크를 클릭할 가능성이 더 높습니다. Klaviyo는 SMS 클릭률이 8.9%에서 14.5% 사이를 맴돌고 있다고 보고합니다.² 이에 비해 Constant Contact에 따르면 이메일의 평균 클릭률은 2%입니다.³

또한, 사기범들은 대포폰으로 전화번호를 스푸핑하거나 소프트웨어를 사용하여 이메일로 문자를 보내는 등의 수법을 사용하여 스미싱 메시지의 출처를 숨기고 있습니다.

또한 휴대폰에서 위험한 링크를 발견하기가 더 어렵습니다. 컴퓨터에서 사용자는 링크 위로 마우스를 가져가서 링크가 어디로 연결되는지 확인할 수 있습니다. 하지만 스마트폰에서는 그런 옵션이 없습니다. 또한 사람들은 은행과 브랜드가 SMS로 연락하고 문자 메시지로 단축된 URL을 수신하는 데 익숙합니다.

2020년에 연방통신위원회(FCC)는 통신 회사가 STIR/SHAKEN 프로토콜을 채택하도록 의무화했습니다. STIR/SHAKEN은 전화 통화를 인증하기 때문에 일부 휴대폰은 이제 의심스러운 번호로 전화를 걸면 "사기 가능성" 또는 "스팸 가능성" 메시지를 표시합니다.

이 규칙을 통해 사기 전화를 더 쉽게 발견할 수 있지만 문자 메시지에는 동일한 효과가 없었기 때문에 많은 사기꾼이 스미싱 공격에 초점을 맞추게 되었습니다.

다른 형태의 소셜 엔지니어링과 마찬가지로 대부분의 스미싱 공격은 가짜 스토리를 사용하여 피해자의 감정을 조작하고 사기꾼의 명령을 따르도록 속이는 구실을 사용합니다.

사기꾼은 피해자의 은행으로 위장하여 계좌에 문제가 생겼을 때 종종 가짜 알림을 통해 경고를 보낼 수 있습니다. 피해자가 링크를 클릭하면 PIN, 로그인 자격 증명, 비밀번호, 은행 계좌 또는 신용 카드 정보와 같은 민감한 금융 정보를 훔치는 가짜 웹 사이트 또는 앱으로 이동합니다.

연방거래위원회(FTC)에 따르면 은행 사칭은 가장 흔한 문자 메시지 사기로 모든 스미싱 메시지의 10%를 차지합니다.⁴

사기꾼은 경찰관, IRS 대표자 또는 기타 정부 기관 공무원으로 위장할 수 있습니다. 이러한 스미싱 문자는 피해자가 벌금을 내야 한다거나 정부 보조금을 받기 위해 어떤 조치를 취해야 한다고 주장하는 경우가 많습니다.

예를 들어, 2024년 4월 미국 연방수사국(FBI)은 미국 운전자를 대상으로 하는 스미싱 사기에 대한 경고를 발표했습니다.⁵ 사기꾼은 통행료 징수 기관에서 온 것처럼 가장하고 대상에게 미납 도로 통행료를 지불해야 한다고 주장하는 문자 메시지를 보냅니다. 메시지에는 피해자의 돈과 정보를 훔치는 가짜 사이트에 대한 링크가 포함되어 있습니다.

공격자는 Amazon, Microsoft 또는 피해자의 무선 서비스 제공업체와 같은 신뢰할 수 있는 브랜드 및 소매업체의 고객 지원 상담원으로 위장합니다. 그들은 보통 피해자의 계정에 문제가 있거나 청구되지 않은 보상 또는 환불에 문제가 있다고 말합니다. 일반적으로 이러한 문자는 피해자를 신용 카드 번호나 은행 정보를 도용하는 가짜 웹사이트로 보냅니다.

이러한 스미싱 메시지는 FedEx, UPS 또는 US Postal Service와 같은 배송 회사에서 보낸 것이라고 주장합니다. 피해자에게 패키지 배달에 문제가 있다는 사실을 알리고 "패키지 배송비"를 지불하거나 자신의 계정에 로그인하도록 요청합니다. 물론 사기꾼은 돈이나 계좌 정보를 가지고 달아납니다. 이러한 사기는 많은 사람이 패키지를 기다리는 연말연시에 흔히 있습니다.

비즈니스 문자 침해(비즈니스 이메일 침해와 유사하지만 SMS 메시지를 통한 침해는 제외)의 경우 해커는 긴급한 업무에 도움이 필요한 상사, 동료 또는 동료(예: 공급업체, 변호사)로 가장합니다. 이러한 사기는 종종 즉각적인 조치를 요구하고 피해자가 해커에게 돈을 보내는 것으로 끝납니다.

사기꾼은 피해자가 아닌 다른 사람을 위한 것으로 보이는 문자를 보냅니다. 피해자가 사기꾼의 '실수'를 바로잡으면 사기꾼은 피해자와 대화를 시작합니다.

이러한 잘못된 번호 사기는 사기꾼이 몇 달 또는 몇 년에 걸쳐 반복적인 연락을 통해 피해자의 우정과 신뢰를 얻으려고 하는 장기적인 경향이 있습니다. 사기꾼은 피해자에게 낭만적인 감정을 키우는 척 할 수도 있습니다. 목표는 가짜 투자 기회, 대출 요청 또는 이와 유사한 이야기를 통해 피해자의 돈을 훔치는 것입니다.

다단계 인증(MFA) 사기로 불리는 이 사기에서는 피해자의 사용자 이름과 비밀번호를 이미 알고 있는 해커가 피해자의 계정에 액세스하는 데 필요한 인증 코드 또는 일회용 비밀번호를 훔치려고 시도합니다.

해커는 피해자의 친구 중 한 명으로 가장하여 Instagram이나 Facebook 계정이 잠겨 있다고 주장하고 피해자에게 코드를 받도록 요청할 수 있습니다. 피해자는 실제로 자신의 계정을 위한 MFA 코드를 받아 해커에게 제공합니다.

일부 스미싱 사기는 피해자를 속여 파일 관리자, 디지털 결제 앱, 심지어 바이러스 백신 앱과 같이 합법적으로 보이는 앱을 다운로드하도록 유도하지만 실제로는 멀웨어 또는 랜섬웨어입니다.

피싱은 사회 공학을 사용하여 피해자를 속여 돈을 지불하게 하거나 민감한 정보를 넘겨주거나 악성 코드를 다운로드하도록 하는 사이버 공격을 가리키는 광범위한 용어입니다. 스미싱과 비싱은 해커가 피해자에게 사용할 수 있는 피싱 공격의 두 가지 유형일 뿐입니다.

다양한 피싱 공격 유형의 주요 차이점은 공격을 수행하는 데 사용되는 매체입니다. 스미싱 공격에서 해커는 문자 메시지나 SMS를 사용하여 피해자를 표적으로 삼습니다. 비싱 공격("보이스 피싱"의 줄임말)에서 해커는 전화 통화 및 음성 메일과 같은 음성 통신을 사용하여 합법적인 조직으로 가장하고 피해자를 조작합니다.

스미싱 사기를 방지하기 위해 FCC는 사용하지 않거나 유효하지 않은 전화번호를 포함하여 의심스러운 번호로 전송되는 스팸 문자를 차단하도록 하는 새로운 규정을 채택했습니다.⁶

그러나 완벽한 스팸 필터는 없으며 사이버 범죄자들은 항상 이러한 조치를 우회하기 위한 방법을 찾고 있습니다. 개인과 조직은 스미싱 공격에 대한 방어를 강화하기 위해 다음과 같은 추가 조치를 취할 수 있습니다.

안드로이드와 iOS 운영 체제에는 승인되지 않은 앱을 차단하고 의심스러운 텍스트를 스팸 폴더로 필터링하는 등의 내장 보호 및 기능이 있습니다.

조직 수준에서 기업은 통합 엔드포인트 관리(UEM) 솔루션과 사기 탐지 도구를 사용하여 모바일 보안 제어를 설정하고 보안 정책을 시행하며 악의적인 활동을 차단할 수 있습니다.

조직은 비정상적인 전화번호, 알 수 없는 발신자, 예상치 못한 URL, 긴박감 고조와 같은 사이버 공격 및 스미싱 시도의 경고 신호를 인식하도록 직원을 교육하여 더 많은 사기를 막을 수 있습니다.

많은 조직에서는 직원들이 새로운 사이버 보안 기술을 연습할 수 있도록 스미싱 시뮬레이션을 활용합니다. 이러한 시뮬레이션은 보안 팀이 비즈니스를 사기에 노출시키는 컴퓨터 시스템 및 조직 정책의 취약성을 발견하는 데 도움이 될 수 있습니다.

조직에서는 위협 탐지 도구를 민감한 데이터 처리, 결제 승인, 요청 확인을 위한 정책과 결합한 다음 조치를 취하면 이러한 취약성을 해결할 수 있습니다.