Wordfence와 클라우드웨이즈에서 악성코드가 탐지됐을 때 99% 해결하는 방법을 정리했습니다.
Wordfence를 설치한 사이트가 해킹당하는 사례가 지금도 계속 보고되고 있습니다. 저도 처음 이 이야기를 들었을 때 솔직히 반신반의했습니다. 보안 플러그인 1위라는 타이틀을 달고 있는 Wordfence인데, 설치하고도 뚫린다는 게 쉽게 납득이 되지 않았거든요. 그런데 실제로 서비스를 운영하면서 보안 경보를 받아본 경험이 생기고 나서야, 그 이유를 조금씩 이해하게 되었습니다.
악성코드 탐지가 실패하는 이유, 오탐지 구분법과 실제 감염 시 대처법 공개
Wordfence가 악성코드를 탐지하는 방식은 기본적으로 시그니처 기반 탐지(Signature-based Detection)입니다. 여기서 시그니처 기반 탐지란, 이미 알려진 악성코드의 패턴을 데이터베이스에 저장해 두고, 파일을 스캔할 때 그 패턴과 일치하는지 비교하는 방식입니다. 경찰이 지명수배 사진을 들고 범인을 찾는 것과 비슷한 원리입니다.
문제는 그 수배 사진에 없는 범인은 잡을 수 없다는 점입니다. 제로데이 취약점(Zero-day Vulnerability)이 바로 그런 경우입니다. 여기서 제로데이 취약점이란, 아직 공개되지 않아 보안 업체도 패치도 없는 상태의 취약점으로, 공격자가 먼저 발견하고 악용하는 상황을 가리킵니다. 이런 공격은 Wordfence의 패턴 데이터베이스에 등록되기 전이라 그냥 통과됩니다.
실제로 저도 팀 프로젝트에서 오픈소스 패키지의 보안 취약점 알림을 받은 적이 있는데, 막상 확인해 보니 인증 우회나 원격 코드 실행(RCE, Remote Code Execution)처럼 심각한 문제가 포함되어 있었습니다. 여기서 원격 코드 실행이란, 외부 공격자가 서버에 직접 접근하지 않고도 악의적인 명령어를 원격으로 실행할 수 있는 취약점을 말합니다. 그때 저는 보안 스캐너에서 아무 경고가 없었기 때문에 처음에는 대수롭지 않게 생각했습니다. 이게 시그니처 기반 탐지의 전형적인 한계였습니다.
Wordfence가 놓칠 수 있는 대표적인 위협을 정리하면 다음과 같습니다.
- 신규 변종 악성코드: 패턴 데이터베이스에 등록되지 않아 탐지 불가
- 난독화(Obfuscation) 코드: 악성 코드를 일부러 읽기 어렵게 변형해 스캐너를 회피
- 데이터베이스(DB) 기반 악성코드: 파일이 아닌 DB 내부에 심어진 악성 스크립트
- 정상 파일로 위장한 백도어: 기존 시스템 파일과 유사한 이름·구조를 사용
플러그인 취약점, 실제 해킹은 여기서 시작됩니다
그렇다면 실제 공격자는 어디를 노릴까요? 워드프레스 코어(WordPress Core), 즉 워드프레스 본체보다 플러그인과 테마에서 훨씬 많은 취약점이 발견된다는 사실은 학술 연구로도 뒷받침됩니다. arXiv에 게재된 연구 "A Demand-Side Viewpoint to Software Vulnerabilities in WordPress Plugins"에 따르면, 사용자 수가 많은 대형 플러그인일수록 취약점이 발견될 가능성이 높아지는 경향이 있습니다(출처: arXiv).
2025년에 실제로 보고된 사례를 봐도 이 흐름은 뚜렷합니다. UpdraftPlus 공급망 공격(Supply Chain Attack), Sneeit Framework 취약점을 통한 관리자 계정 생성 및 원격 코드 실행 등 870만 건이 넘는 공격이 플러그인 취약점에서 비롯되었습니다(출처: TechRadar). 공급망 공격이란, 신뢰받는 소프트웨어나 서비스를 통해 악성코드를 배포하는 방식으로, 사용자가 공식 경로로 설치한 플러그인에 이미 악성 코드가 심겨 있는 경우입니다.
제가 직접 경험한 상황도 이와 크게 다르지 않았습니다. 프로젝트 초기에는 기능 구현이 급했기 때문에 오픈소스 라이브러리와 플러그인을 검증 없이 빠르게 도입했습니다. 그런데 나중에 취약점 공지를 받고 살펴보니, 문제는 항상 제가 직접 짠 코드가 아니라 외부에서 가져온 패키지에서 시작되고 있었습니다. 공격자는 서비스 자체보다 외부 의존성의 약한 고리를 먼저 노린다는 것을 그때 체감했습니다.
이런 경험 이후 저는 GitHub Dependabot처럼 자동화된 의존성 취약점 감지 도구를 활용하기 시작했고, CVE(Common Vulnerabilities and Exposures) 데이터베이스를 주기적으로 확인하는 습관을 들였습니다. 여기서 CVE란, 공개된 보안 취약점에 고유 번호를 붙여 관리하는 국제 표준 취약점 데이터베이스입니다. 이 데이터베이스를 참고하면 사용 중인 라이브러리에 어떤 위험이 존재하는지 빠르게 파악할 수 있습니다.
보안 플러그인이 있어도 관리가 필요한 이유
"Wordfence 설치했으니 이제 괜찮겠지"라는 생각, 한 번쯤 해보신 적 있지 않으신가요? 저도 처음엔 그렇게 생각했습니다. 그런데 보안 스캐너에서 이상 없다는 결과가 나와도 실제로 안전한 것은 아닐 수 있습니다. 보안 플러그인은 경비원 역할을 합니다. 경비원이 있다고 해서 잠금장치를 안 해도 되는 건 아니지 않습니까.
Wordfence가 방화벽(WAF, Web Application Firewall)과 로그인 공격 차단, 알려진 취약점 경고 기능을 제공하는 것은 맞습니다. 여기서 WAF란 웹 애플리케이션으로 들어오는 트래픽을 필터링해 SQL 인젝션, 크로스사이트 스크립팅(XSS) 같은 공격을 차단하는 보안 장치입니다. 그러나 알려지지 않은 공격이나 DB 내부에 심어진 악성 스크립트는 WAF도 탐지하기 어렵습니다.
결국 보안의 실질적인 방어선은 운영자의 주기적인 관리입니다. 워드프레스 사이트가 감염되었는지 빠르게 확인할 수 있는 체크 항목을 정리하면 다음과 같습니다.
- 관리자 계정에 본인이 만들지 않은 계정이 추가되어 있는지 확인
- 설치한 기억이 없는 플러그인이나 테마가 생겼는지 점검
- 사이트 접속 시 외부 URL로 리다이렉트(Redirect)가 발생하는지 확인
- Google Search Console에서 보안 문제 경고가 뜨는지 검토
- Wordfence 스캔 후 알 수 없는 파일 변경 이력이 있는지 검사
이 중 하나라도 해당된다면 즉시 서버 로그를 확인하고, 최신 백업 파일로 복구를 검토해야 합니다.
보안이라는 건 한 번 설정하고 끝나는 것이 아니라 꾸준히 관리하는 과정입니다. 저도 이 경험을 통해 기능 개발과 보안 점검을 별개로 보지 않게 되었습니다. Wordfence는 분명 유용한 도구입니다. 하지만 그 도구의 한계를 정확히 알고, 정기 업데이트와 백업, 접근 권한 관리를 함께 실천할 때 비로소 실질적인 보안 수준을 확보할 수 있습니다. 앞으로는 AI 기반 이상행위 탐지(Anomaly Detection) 기술이 워드프레스 보안에도 접목될 가능성이 높습니다만, 지금 당장 가장 확실한 방법은 운영자 스스로 주기적으로 점검하는 것입니다.