GSocket 백도어: PHP, cPanel, Apache 호스트의 침해 여부 점검

무슨 일이 있었나

2026년 11월 11일 Microsoft는 침해된 Linux 서버에 GSocket을 설치하는 여러 독립적인 공격자 그룹에 대한 연구를 발표했습니다. BleepingComputer는 2026년 11월 12일 이를 보도했습니다. GSocket은 정당한 오픈소스 원격 접속 도구입니다. 서버에서 실행되면 서버와 공격자 모두 공개 중계 서비스인 Global Socket Relay Network로 아웃바운드 연결을 만듭니다. 중계 서비스는 두 연결을 묶어 암호화된 세션을 만듭니다. 서버에는 열린 포트나 공인 IP 주소가 필요하지 않습니다. 공격자는 자체 인프라를 운영하지 않으므로 차단할 공격자 IP 주소나 도메인이 없습니다.

이는 GSocket의 취약점이 아닙니다. 공격자는 먼저 공개된 웹 애플리케이션에 침입한 뒤 접근을 유지하기 위해 GSocket을 설치합니다. GSocket은 애플리케이션과 별도로 실행되므로 애플리케이션을 패치해도 GSocket은 제거되지 않습니다. Microsoft는 2026년 3월부터 8월 사이 자사 텔레메트리에서 GSocket 관련 탐지가 356.2% 증가했다고 밝혔습니다.

Microsoft가 설명한 공격 방식은 다음과 같습니다.

• 공격자는 웹 애플리케이션을 공격하고 curl을 사용해 설치 스크립트를 내려받아 실행합니다.
• 스크립트는 GSocket 클라이언트를 /dev/shm처럼 쓰기 가능하거나 메모리 기반인 경로에 배치합니다.
• 프로세스는 커널 스레드처럼 보이는 이름(예: [kaluad])이나 systemd-remount-d, /usr/bin/defunct와 같은 시스템 이름으로 위장됩니다.
• 지속성은 cron 작업, systemd 서비스, 셸 시작 파일, 워치독, 추가 복사본을 통해 설정됩니다. 이후 임시 파일은 삭제되고 파일 타임스탬프는 과거로 변경됩니다.
• 일부 사례에서 공격자는 Linux 커널 취약점 CVE-2026-43284("Dirty Frag")를 이용해 root 권한을 얻으려 했습니다.

영향을 받는 대상

과거 어느 시점에 침해된 공개 웹 애플리케이션을 실행하는 Linux 서버가 해당됩니다. Microsoft의 데이터에 따르면 사고의 87.1%가 웹 애플리케이션과 호스팅과 관련되었습니다. 이 가운데 PHP 웹 애플리케이션과 cPanel 호스팅이 63.9%, Apache가 24.3%를 차지했습니다. Microsoft는 Java 및 Node.js 웹 애플리케이션에서 셸이 시작된 경우의 경고도 나열했습니다. 최근 웹 애플리케이션 취약점이 발견되어 패치된 서버는 공격자가 패치 이전에 침입했을 수 있으므로 특히 점검이 필요합니다.

웹 애플리케이션이 한 번도 침해되지 않은 서버는 영향을 받지 않습니다. 내부 팀이 의도적으로 설치한 GSocket은 그 자체로 침해의 징후가 아닙니다.

지금 해야 할 일

1. 인터넷에 노출된 모든 Linux 웹 서버를 점검하십시오. 다음 섹션의 단계를 따르십시오. 최근 몇 달 사이 웹 애플리케이션, CMS, 플러그인 또는 호스팅 패널의 취약점이 패치된 서버부터 시작하십시오.
2. GSocket이 발견되면 해당 서버를 침해된 것으로 간주하십시오. 프로세스를 중지하십시오. 이후 바이너리, 모든 복사본, 모든 자동 시작 항목(cron, systemd 유닛, 셸 시작 파일, 워치독 스크립트)을 제거하십시오. Microsoft는 지속성 메커니즘이 여러 겹으로 구성되는 경우가 많아 프로세스만 종료해서는 접근이 차단되지 않는다고 설명합니다. 공격자가 CVE-2026-43284 등을 통해 root 권한을 얻었을 가능성이 있다면, 가장 안전한 방법은 깨끗한 이미지나 침해 이전에 만든 백업으로 서버를 재구축하는 것입니다.
3. 영향을 받은 서버의 자격 증명을 변경하십시오. 데이터베이스 비밀번호, 애플리케이션 비밀 값, API 키, SSH 키가 대상입니다. 또한 authorized_keys에 알 수 없는 항목이 있는지 확인하십시오.
4. 침입 경로를 찾아 차단하십시오. 웹 애플리케이션, CMS 플랫폼, 플러그인, 애플리케이션 서버를 업데이트하십시오. 사용하지 않는 구성 요소를 제거하고 파일 업로드 및 관리자 경로를 제한하십시오.
5. 배포판의 커널 업데이트를 적용해 CVE-2026-43284("Dirty Frag")를 패치하고, 새 커널로 재부팅하십시오.
6. 아웃바운드 트래픽을 제한하십시오. 가능한 경우 아웃바운드 연결을 기본적으로 차단하고 서버에 필요한 목적지만 허용하십시오. GSocket 트래픽은 아웃바운드만 발생하므로 인바운드 방화벽 규칙으로는 탐지되지 않습니다.
7. 임시 디렉터리를 강화하십시오. 실제로 가능한 경우 /tmp와 /dev/shm을 noexec 옵션으로 마운트하십시오.
8. 조치 후 확인하십시오. 서버가 GSocket 중계 서비스나 아래 나열된 도메인에 더 이상 연결되지 않는지 확인하십시오.

영향 여부 확인 방법

다음 점검은 root 권한으로 실행하십시오. 일치 결과가 있다고 해서 그것만으로 침해가 확정되지는 않지만, 반드시 조사해야 합니다.

Microsoft가 지정한 파일 및 경로:

ls -la /dev/shm/.gs-* /tmp/.gsn_ora /tmp/systemd-remount-d /usr/bin/systemd-remount-d /usr/bin/defunct 2>/dev/null
find / -xdev \( -name 'gs-netcat*' -o -name 'defunct.service' -o -name 'defunct' -o -name 'systemd-remount-d' \) 2>/dev/null

실행 중인 프로세스:

ps -eo pid,ppid,user,args | grep -Ei 'gs-netcat|gsocket|defunct|remount-d' | grep -v grep

실제 커널 스레드에는 실행 파일이 없습니다. [kaluad]처럼 대괄호로 묶인 이름의 프로세스가 파일을 가리키고 있다면 의심스럽습니다.

for p in /proc/[0-9]*; do n=$(cat $p/cmdline 2>/dev/null | tr '\0' ' '); case "$n" in \[*) e=$(readlink $p/exe 2>/dev/null); [ -n "$e" ] && echo "${p#/proc/} $n -> $e";; esac; done

지속성 설정:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
systemctl list-unit-files --type=service | grep -Ei 'defunct|remount'
grep -sEl 'gs-netcat|gsocket|defunct|GS_' /etc/profile /etc/profile.d/* /etc/bash.bashrc /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile

그럴듯해 보이지만 직접 만들지 않은 systemd 유닛은 주의 깊게 확인하십시오. www-data, apache, nobody와 같은 웹 서비스 계정의 홈 디렉터리와 cPanel 사용자의 홈 디렉터리도 점검하십시오.

Microsoft가 제시한 알려진 파일 해시(SHA-256):

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

네트워크 및 로그: DNS, 프록시, 방화벽 로그에서 gsocket.io, cdn.gsocket.io, gsgg.b-cdn.net을 검색하십시오. 이 도메인들은 도구를 내려받는 데 사용됩니다. 또한 셸 기록과 웹 서버 로그에서 curl로 gsocket.io/y 또는 gsocket.io/install.sh를 가져오는 명령을 검색하십시오. 웹 서버나 PHP 프로세스가 시작한 셸도 확인하십시오. ss -tnp로 어떤 프로세스가 아웃바운드 연결을 유지하는지 확인하고, 설명할 수 없는 프로세스는 자세히 조사하십시오. 공격자는 임시 파일과 명령 기록을 삭제하므로, 한 곳에서 흔적이 보이지 않는다고 해서 서버가 깨끗하다고 단정할 수는 없다는 점을 유념하십시오.

출처

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/