내 웹사이트나 서버가 해킹됐는지 확인하는 법: 공유 호스팅, WordPress, VPS별 점검 순서와 발견했을 때 먼저 할 일

대상: 공유 호스팅, WordPress, VPS에서 사이트를 운영하는 개인이나 소규모 사업자로, 지금 "해킹당한 걸까?" 하고 걱정하는 사람. 이 가이드는 내 사이트와 서버를 스스로 확인하는 순서를 다룬다. WordPress.org, WP-CLI, Google 검색 센터의 공식 문서, 각 명령의 매뉴얼 페이지, 일본 IPA와 JPCERT/CC, GDPR을 바탕으로 했다. 공격 기법은 다루지 않는다.

침입을 의심해야 할 징후

다음 중 하나라도 해당하면 아래의 환경별 점검으로 넘어간다. WordPress.org의 "FAQ My site was hacked"도 검색 엔진의 차단 목록에 오르는 것, 호스팅 업체가 사이트를 정지하는 것, 새 사용자가 생성되는 등의 무단 동작을 해킹의 분명한 징후로 든다.

환경별 점검

내 환경에 맞는 행을 확인한다. 공유 호스팅에서 WordPress를 운영한다면 처음 두 행이 모두 해당한다.

공유 호스팅

SSH가 없어도 제어판에서 대개 다음 세 가지는 확인할 수 있다(이름은 업체마다 다르다).

• 파일 관리자에서 공개 폴더를 열고 수정 날짜순으로 정렬한다. 손대지 않은 날에 바뀐 파일, 의미 없는 이름의 PHP 파일, uploads 같은 이미지 폴더 안의 PHP 파일에 주의한다
• 액세스 로그와 오류 로그를 내려받아 관리 화면 요청(WordPress라면 /wp-login.php와 /wp-admin/)이 어디서 언제 왔는지, 모르는 URL로의 요청이 없는지 확인한다
• 메일 발송 건수나 기록을 볼 수 있다면 내가 보내지 않은 대량 발송이 없는지 본다

.htaccess도 확인한다. WordPress.org는 감염 유형과 관계없이 가장 자주 변조·악용되는 파일 중 하나로 .htaccess를 꼽으며, index.php, header.php, footer.php는 모든 페이지 요청에 영향을 주므로 가치가 높은 표적이라고 설명한다.

WordPress

대시보드에서 두 곳을 확인한다.

• Users > All Users(사용자 > 모든 사용자): 만든 적 없는 Administrator(관리자) 역할의 사용자가 있는가?
• Plugins > Installed Plugins(플러그인 > 설치된 플러그인): 설치하지 않은 플러그인이 있는가? Appearance > Themes(외모 > 테마)도 같은 방식으로 확인한다

서버에서 WP-CLI(WordPress 공식 명령줄 도구)를 쓸 수 있다면, 파일을 공식 릴리스와 자동으로 대조할 수 있다.

# Check WordPress core files against WordPress.org checksums
wp core verify-checksums
# Also warn about non-WordPress files in the WordPress root directory
wp core verify-checksums --include-root
# Verify plugins distributed on WordPress.org
wp plugin verify-checksums --all
# List administrator accounts with their registration dates
wp user list --role=administrator

문제가 없으면 Success: WordPress installation verifies against checksums.가 출력된다. 일치하지 않는 파일이 있으면 Warning: File doesn't verify against checksum: 뒤에 파일 이름이 출력된다. 플러그인 검증은 WordPress.org의 체크섬과 대조하므로 유료 플러그인이나 직접 만든 테마는 이 방법으로 확인할 수 없다. 이런 것은 같은 버전을 공급처에서 다시 내려받아 비교한다.

VPS(Linux)

VPS에서는 침입자가 다시 들어오려고 남겨 두는 것을 찾는다. 공개 키, 예약 작업, 새 사용자, 접속을 기다리는 프로그램이다. 모두 내 서버에서 관리자로 실행한다.

# SSH login records (the unit is ssh on Debian/Ubuntu, sshd on RHEL-family)
sudo journalctl -u ssh --since "2026-10-01"
# Recent logins (on Debian 13, use wtmpdb last instead; install the wtmpdb and libpam-wtmpdb packages)
last -a
# Each user's last login (on Debian 13, use lastlog2 instead; install the lastlog2 and libpam-lastlog2 packages)
lastlog
# SSH public keys: the current user's (other users: /home/*/.ssh/authorized_keys) and root's
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys
# Scheduled jobs (per user and system-wide)
crontab -l
sudo crontab -l -u root
sudo cat /etc/crontab
sudo ls -la /etc/cron.d
# Users, and the group with admin rights (wheel on RHEL-family)
getent passwd
getent group sudo
# Listening TCP ports and the programs behind them
sudo ss -tlnp
# Files in the web root whose contents changed in the last 7 days
sudo find /var/www -type f -mtime -7
# Have package files changed since they were installed?
sudo debsums -s      # Debian/Ubuntu (needs the debsums package)
sudo rpm -Va         # RHEL-family

결과를 읽는 법:

• journalctl 출력에서 성공한 로그인(Accepted)의 출발지 IP가 내 것이 아닌 주소인지 확인한다. 아무것도 나오지 않으면 유닛 이름이 다를 수 있으니 systemctl list-units --type=service로 SSH 서비스 이름을 확인한다
• authorized_keys에서 추가한 적 없는 공개 키를 찾는다. 서버에 접근할 수 있는 키의 관리는 SSH 키 최소 권한에서 다룬다
• cron에서 모르는 URL에서 무언가를 내려받아 실행하는 줄을 찾는다
• ss 목록에서 내가 실행하지 않은 프로그램이 리스닝하고 있지 않은지 본다
• debsums -s는 문제가 있는 파일만 보고한다. rpm -Va는 변경된 파일에 크기(S), 다이제스트(5), 수정 시각(T) 같은 코드를 붙인다

Google Search Console

사이트가 아직 Search Console에 등록되어 있지 않다면, 먼저 추가하고 소유권을 확인한다.

• 보안 문제 보고서에서 문제가 표시되어 있는지 본다. 문제는 크게 해킹된 콘텐츠, 멀웨어 및 원치 않는 소프트웨어, 소셜 엔지니어링의 세 범주로 나뉘며, 보통 샘플 URL이 함께 나온다. 샘플 URL 없이 나오는 문제도 있는데, Google은 이것이 영향을 받은 페이지가 없다는 뜻은 아니라고 설명한다
• Google에서 site:내도메인으로 검색해 만든 적 없는 페이지를 찾는다. Google은 이 검색이 해커가 추가했을 수 있는 페이지를 포함해 내 사이트의 페이지를 보여 준다고 설명한다
• 의심스러운 페이지를 URL 검사 도구에 넣어 Google이 어떻게 보는지 확인한다

용어를 정리하면, 위와 같이 이미 일어난 침해의 흔적을 IOC(침해 지표)라고 한다. IOC란?을 참고하고, 진행 중인 공격을 행동으로 알아채는 방법은 IOA란?을 참고한다.

무언가 발견했을 때 먼저 할 일

순서를 틀리면 증거를 없애 버리거나, 공격자의 침입 경로가 열린 채로 사이트를 복구하게 된다. 위에서부터 진행한다.

개인정보가 유출됐을 수 있다면

사업으로 개인정보를 다루고 있고 문의 양식 제출 내용이나 회원 기록이 유출됐을 수 있다면, 운영하는 곳의 규칙을 확인한다.

• EU와 영국(GDPR 제33조): 개인정보 침해를 알게 된 뒤 지체 없이, 가능한 경우 72시간 이내에 감독기관에 통지한다. 다만 사람들의 권리와 자유에 위험이 생길 가능성이 낮으면 예외다. 제34조는 당사자에게도 알려야 하는 경우를 다룬다
• 일본: 개인정보보호위원회(PPC)는 보고 대상을 네 가지로 든다. 민감 정보, 재산상 피해의 우려, 부정한 목적의 의심, 1,000명 초과다. 무단 접속으로 인한 유출은 부정한 목적 범주의 예로 들고 있다. 속보는 발견 후 3~5일 이내, 확정 보고는 30일 이내(부정한 목적 범주는 60일 이내)에 제출하며, 당사자에게도 알려야 한다
• 그 밖의 지역: 자국의 개인정보 보호 감독기관을 확인한다

도움을 받을 수 있는 곳

출처(공식)

• WordPress.org: FAQ My site was hacked — wordpress.org
• WordPress.org: Administration Screens — wordpress.org
• WP-CLI: wp core verify-checksums — developer.wordpress.org
• WP-CLI: wp plugin verify-checksums — developer.wordpress.org
• WP-CLI: wp user list — developer.wordpress.org
• Google: 보안 문제 보고서(Search Console 고객센터) — support.google.com
• Google: How do I know if my site was hacked? (web.dev) — web.dev
• Google: Fix the cloaked keywords and links hack (web.dev) — web.dev
• Google 검색 센터 블로그: Detect and get rid of unwanted sneaky mobile redirects(2015년 10월) — developers.google.com
• Google 검색 고객센터: Report a problem with Google Search("이 사이트는 해킹되었을 수 있습니다" 표시 관련) — support.google.com
• Debian 매뉴얼 페이지: journalctl(1), last(1), lastlog(8), sshd(8), crontab(1), cron(8), ss(8), find(1), debsums(1) — manpages.debian.org
• RPM: rpm(8)(--verify 출력 읽는 법) — rpm.org
• Debian 13(trixie) 릴리스 노트: last, lastb, lastlog 명령의 대체 — debian.org
• GDPR(규칙 (EU) 2016/679) 제33조와 제34조 — eur-lex.europa.eu
• 일본 개인정보보호위원회: 유출 등 보고와 본인 통지의 의무화(일본어) — ppc.go.jp
• 일본 개인정보보호위원회: 유출 등 사안이 발생한 경우의 대응(일본어) — ppc.go.jp
• JPCERT/CC: 인시던트 대응 의뢰(일본어) — jpcert.or.jp
• IPA: 컴퓨터 바이러스·무단 접속 신고(일본어) — ipa.go.jp

다음으로 읽기

• 개인 계정이라면: 누군가 내 계정에 접속했는지 확인하는 법
• 호스팅 업체 자체가 침해됐을 때: 웹 호스팅 업체가 침해됐을 때 고객이 할 일(내 설정으로는 막을 수 없는 일에 대비)
• 파일 위치 점검: 공개 디렉터리에 비밀 파일을 두지 않았는가? / 공유 호스팅에서 .env를 공개되지 않게 지키기
• WordPress: WordPress 보안 — 운영 환경 강화 레퍼런스 / 흔한 침입 경로: 파일 업로드 취약점
• 용어: IOC란? / IOA란? / 백도어란? / 멀웨어란?
• 복구: 백업의 기본