Synology의 C3RB3R 랜섬웨어: 기원, 복구 및 안전하게 지키는 방법

C3RB3R 랜섬웨어 2026년 10월 28일경 Synology NAS 기기에서 나타나기 시작했으며, 하루 만에 r/synology의 유일한 화제가 되었습니다. 파일 이름 뒤에 L0CK3D 확장자(영문자 O가 아닌 숫자 0)가 붙어 이름이 변경되고, 모든 폴더에는 read-me3.txt 랜섬노트가 생성되며, Tor 포털에서 비트코인을 요구합니다. 가장 빠르고 유용한 정보는 영어 뉴스 사이트에서 나오지 않았습니다. Synology의 거대한 사용자 기반이 있는 중화권 포럼과, 실제로 데이터를 복구했거나 복구가 불가능함을 증명한 피해자들이 작성한 3개의 GitHub 리포지토리에서 나왔습니다. 이 가이드는 지금까지 확인된 C3RB3R 랜섬웨어에 대한 정보, 즉 출처, 침투 방식, 작동했던 유일한 복구 경로, 그리고 이러한 공격이 발생했을 때 랜섬머니 대신 복구 비용만 들도록 하는 백업 설계 방식을 정리합니다.

업데이트 (2026년 10월 31일): Synology는 이제 침입 경로를 확정했습니다. 10월 30일 고객에게 보낸 이메일에서, C3RB3R 랜섬웨어가 2024년 12월에 패치된 Synology-SA-24:20에서 해결된 취약점만 악용하며 해당 캠페인은 같은 달에 패치된 PHP2Shell 취약점과 관련이 없음을 확인했습니다. 저희는 Synology의 자체 4단계 체크리스트, 해당 시점에 공격이 발생한 이유에 대한 저희의 분석, 그리고 대부분의 소유자가 이미 이용 중인 추가 보호 계층인 Active Insight 랜섬웨어 보호 기능을 추가했습니다.

SynoPower Club 포인트:중국 NAS 그룹의 한 피해자는 단일 장비에 50 TB가 넘는 데이터를 보유하고 있었고 스냅샷은 없었습니다. 암호화 진행 속도가 충분히 느려 2024년 사진만 피해를 입었고, 다행히 해당 사진들은 클라우드 드라이브에 콜드 카피가 있었습니다. 또 다른 피해자는 RAID 6와 3개의 백업이 모두 동일한 머신에 존재했기 때문에 5년간의 비공개 GitLab 리포지토리를 잃었습니다. C3RB3R 랜섬웨어가 그들의 스토리지에 승리한 것이 아니라, 그들의 백업 설계를 무너뜨린 것입니다. 저희는 공개 사이트를 Virtual DSM 내부의 Docker로 실행하고, 호스트에서 게스트 전체를 스냅샷으로 찍어 두 번째 NAS로 복제하며, 일정에 따라 USB 및 클라우드로 내보냅니다. 오늘 밤 게스트가 암호화되더라도 마지막 스냅샷으로 롤백하면 공격자는 아무것도 얻지 못합니다.

C3RB3R 랜섬웨어란 무엇인가요?

C3RB3R 랜섬웨어는 2016년부터 존재해 왔으며 수년간 NAS 장치를 간헐적으로 노려온 Cerber 패밀리의 Linux 빌드입니다. 360은 2026년 10월 Synology를 겨냥한 공격의 원인으로 이를 지목했습니다. 감염된 DSM 장비에서 C3RB3R 랜섬웨어 암호화 프로그램은 정적 링크 및 UPX 패킹된 x86-64 바이너리로 실행되며 이름은 다음과 같습니다: libgld실행 후 자체 파일을 삭제하므로 실행 중인 프로세스는 실행 파일 경로 옆에 (삭제됨) 가 표시됩니다.

C3RB3R 랜섬웨어의 피해를 입은 장비 소유자에게 나타나는 증상은 모든 보고서에서 일치합니다:

• 파일 이름이 다음과 같이 변경됨: name.ext.L0CK3D일부 보고서에서는 LOCK3D로 표기하기도 하지만, GitHub 분석에서는 숫자 0으로 인용합니다.
• 다음과 같은 이름의 랜섬노트가 read-me3.txt 모든 암호화된 폴더에 생성되며, C3RB3R INSTRUCTIONS라는 제목이 표시됩니다.
• C3rb3r Decryptor라는 제목의 Tor 페이지. 한 피해자의 스크린샷에 따르면 5일 이내에 지불할 경우 0.03696 BTC(약 US$2,952), 그 이후에는 카운트다운 타이머와 함께 0.07392 BTC(약 US$5,904)로 두 배가 되었습니다.
• 다음 항목과 일치하는 cron 항목을 통한 지속성 유지: /etc/cron.d/synot*, 이 항목들은 스스로 재생성되며 최소 한 사례에서는 DSM 업그레이드 후에도 남아 있었습니다.
• Hyper Backup 대상 및 데이터베이스 덤프를 포함하여 동일한 볼륨에 있는 백업 파일이 다른 모든 파일과 함께 암호화됨.

시작된 곳: r/synology 및 중화권 포럼

C3RB3R 랜섬웨어는 2026년 10월 28일과 29일경 피해자들이 약 하루 간격으로 글을 올리면서 r/synology에 영어로 처음 수면 위로 떠올랐습니다. 몇 시간 만에 서브레딧을 새로고침할 때마다 새로운 스레드가 나타난다는 반응이 이어졌습니다. 이 중 세 개의 스레드는 각각 다른 단서를 제공하므로 전문을 읽어볼 가치가 있습니다:

• 포렌식 분석글. 인터넷에서 웹 인터페이스에 접근 가능한 DSM 7.2.1-69057 Update 5 환경의 DS918+ 소유자는 장비를 종료하고 Proxmox 호스트에서 디스크를 읽기 전용으로 검사했습니다. DSM 인증 로그에는 계정 필드에 주입된 LD_PRELOAD 그리고 LD_DEBUG_OUTPUT 줄과 인코딩된 셸 명령, 그리고 다음 위치 아래의 파일이 포함된 로그인 요청이 남아 있었습니다: /etc/cron.d이는 공개된 CVE-2024-10441 기법과 일치합니다. 3-2-1 백업 덕분에 이 공격은 랜섬머니가 아닌 복구 작업만으로 해결되었습니다. 여기에서 읽어보세요: 결국 일이 터졌습니다. 제 첫 실제 랜섬웨어 사고입니다..
• Synology Photos만 사용하는 사용자. 이 소유자는 DSM이 최신 상태라고 믿었고 Synology Photos만 사용했지만, 공유기의 UPnP가 켜져 있었습니다. 모드 2 리셋 후 Snapshot Replication으로 보호된 폴더는 복구되었습니다. 스냅샷이 없는 폴더는 복구되지 않았으며, 로컬 Hyper Backup USB 드라이브는 NAS와 함께 암호화되었습니다. 여기에서 읽어보세요: 오늘 아침 c3rb3r 랜섬웨어에 감염되었습니다.
• QuickConnect 관련 논의. 원글 작성자는 DSM이 성능 저하되고 재설치 후 암호화된 파일이 드러난 후에야 이를 감지했습니다. 답글에서 강력한 암호, 2FA 및 QuickConnect를 활성화한 다른 독자도 피해를 입었다고 전했으며, 다른 이들은 앱 전용 사용자의 경우 QuickConnect에서 DSM 접근을 완전히 끌 수 있다고 지적했습니다. 여기에서 읽어보세요: C3RB3R 랜섬웨어에 감염되었습니다.

종합해 보면 패턴은 명확합니다. C3RB3R 랜섬웨어는 접근 가능한 DSM 로그인 페이지가 필요했을 뿐입니다. 익스플로잇이 인증 전에 실행되기 때문에 암호나 2FA는 도움이 되지 않았습니다. 포렌식 분석글에서 분명히 밝혔듯이, 요청이 취약한 애플리케이션에 도달했으므로 또 다른 암호 프롬프트가 있었다 해도 이를 해결할 수는 없었을 것입니다.

더 깊이 있는 기술적 분석 작업은 중국어로 진행되었습니다. WeChat과 Xiaohongshu 그룹의 피해자들은 랜섬노트를 게시하고, 타임라인을 비교하며, 아래에서 다루는 GitHub 리포지토리를 서로 공유했습니다. Facebook의 대만 Synology 커뮤니티도 동일한 복구 링크를 수집했습니다 현지 사용자들을 위해. 이는 당연한 결과입니다. Synology는 대만 기업이고 가장 큰 사용자 커뮤니티가 중화권에 형성되어 있으므로, C3RB3R 랜섬웨어 피해 사례가 가장 많이 집중되었고 이에 따라 가장 빠르게 패턴 파악이 이루어진 것입니다.

Synology 자체에서도 보안 권고를 발표했습니다 2026년 10월 29일에 2024년 12월에 패치된 취약점을 이전 버전 DSM을 대상으로 악용하는 위협 행위자를 확인했다고 발표하며, 모든 사용자에게 즉시 업데이트할 것을 강력히 권고했습니다.

C3RB3R 랜섬웨어 침투 경로

처음 이틀 동안은 두 가지 침입 경로 후보가 있었습니다. Synology는 이후 더 오래된 취약점이었음을 확인했습니다. 10월 30일 이메일에 따르면 이 공격은 Synology-SA-24:20에서 해결된 취약점만을 악용하며 C3RB3R 랜섬웨어는 PHP2Shell과 전혀 관련이 없습니다. 아래 표는 논의되었던 두 후보를 모두 보여줍니다. 360 쌍은 여전히 패치할 가치가 있기 때문입니다.

	Synology 발표	360 발표
자문	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, 시스템 플러그인 데몬에서의 인증되지 않은 원격 코드 실행	CVE-2026-13639 (로그인 로직) 및 CVE-2026-13684 (SCGI), 모두 CVSS 9.8
패치 완료	2024년 11월 ~ 12월	2026년 9월 18일
수정된 빌드	DSM 7.2.2-72806 업데이트 1, 7.2.1-69057 업데이트 6, 7.2-64570 업데이트 4, 7.1.1-42962 업데이트 7	DSM 7.4-90075, 7.3.2-86009 업데이트 4, 7.2.2-72806 업데이트 9, 7.2.1-69057 업데이트 12

포렌식 증거는 최소한 일부 피해자의 경우 이전 버그를 가리키고 있습니다. 가장 상세한 Reddit 분석 글에서는 살아남은 시스템 로그를 공개된 CVE-2024-10441 익스플로잇과 대조하는 한편, Synology가 이를 공식 확인하지 않았고 해당 기기가 SA-26:13 수정 버전 미만이었다는 점도 언급했습니다. soimy의 분석 글에 따르면 감염된 게스트의 메모리 로그는 DSM 로그인 플러그인을 통한 환경 변수 주입을 가리키며, 이는 CVE-2024-10441과 일치하고, 공격 발생 수일 전 로그인 사용자 이름 필드를 악용하는 공개 개념 증명(PoC)이 GitHub에 등장했습니다. 기록된 3건의 복구 사례 중 2건은 DS918+ 부트로더를 사용한 비정품 하드웨어에서 실행 중이었으며, 그 중 하나는 CVE-2024-10441 패치에서 정확히 업데이트 1회가 부족한 DSM 7.2-64570 Update 3 버전이었습니다. 클론 하드웨어는 공식 업데이트를 쉽게 적용할 수 없기 때문에 가장 취약한 표적이 됩니다.

실질적인 결론은 변하지 않았습니다. 두 보안 권고를 모두 적용하는 빌드로 업데이트하고 DSM을 인터넷에 노출하는 것을 중단하십시오. 그러나 한 가지 의문이 남았습니다. 2024년 12월에 취약점이 패치되었다면, 왜 2026년 10월의 동일한 이틀 동안 최신 상태라고 믿었던 일부 소유자의 장치를 포함하여 그토록 많은 기기가 C3RB3R 랜섬웨어에 감염되었을까요?

미리 심어져 신호에 맞춰 터지다

저희의 해석(Synology의 공식 입장이 아닌 저희의 해석)에 따르면, C3RB3R 랜섬웨어의 침입과 암호화는 별개의 두 사건입니다. 증거가 이를 뒷받침합니다:

• 백도어가 먼저 생성되었습니다. 아래의 샤오홍슈(Xiaohongshu) 사례에서는 단 하나의 파일도 암호화되기 37일 전에 이미 백도어 셸이 NAS에 상주하며 root 권한으로 telnet을 활성화해 두었습니다.
• 이는 업데이트 후에도 남아있습니다. 다음 경로의 cron 항목들은 /etc/cron.d/synot* 스스로 재생성되며, 최신 DSM으로 업그레이드한 후에도 여전히 남아 있는 것을 확인한 피해자가 최소 한 명 이상 있습니다. 업데이트로 보안 취약점은 차단되었지만 침입자는 내부에 그대로 남았습니다.
• 랜섬웨어 발동은 동시 다발적으로 이루어졌습니다. 서로 다른 시기, 서로 다른 빌드에서 침해당한 C3RB3R 랜섬웨어 감염 장치들이 약 48시간 이내에 거의 동시에 암호화를 시작했습니다.

이러한 패턴은 공격자가 몇 달 동안 패치되지 않은 장치에 C3RB3R 랜섬웨어 임플란트를 심어두고 원격으로 실행할 시점을 선택했음을 시사합니다. 그들이 선택한 시점은 모든 Synology 관리자가 패치 작업으로 분주하고, 많은 장치가 막 업데이트되었으며, 소유자들이 패치를 완료했기에 안전하다고 느끼던 PHP2Shell 주간이었습니다. Synology는 PHP2Shell이 침입 경로가 아니었음을 명확히 밝혔습니다. 그것은 위장에 불과했습니다. 패치되지 않은 상태로 노출되었던 장치는 점검을 받기 전까지 침해된 것으로 간주해야 한다는 것이 교훈이며, 이는 Synology’s 체크리스트 1단계에서 요구하는 바와 정확히 일치합니다.

4단계로 알아보는 C3RB3R 랜섬웨어 최초 대응 방법

지금 바로 L0CK3D 파일이 발견되었다면, 이후 10분간의 조치 순서가 복구 가능 여부를 결정합니다. 파일 암호를 해제하는 키는 실행 중인 C3RB3R 랜섬웨어 프로세스 메모리 안에만 존재합니다. 재부팅, kill -9 명령 또는 DSM 재설치는 키를 완전히 파괴합니다.

2단계와 3단계에 사용되는 명령어는 다음과 같습니다. 실행 바이너리에 따라 세부 사항이 달라질 수 있으므로 실행 전 리포지토리를 반드시 읽어보세요.

# 2단계: 암호화 프로세스 찾기 (실행 파일이 deleted로 표시됨)

복구 가능할까요? GitHub에 공유된 3가지 복구 사례

C3RB3R 랜섬웨어용 범용 복구 프로그램은 존재하지 않으며, 이를 판매한다는 것은 사기일 가능성이 높습니다. 대신 어떤 조건에서 복구가 가능한지 정확히 보여주는 3가지 상세 사례 연구가 있습니다.

리포지토리	기기/환경	결과	이유
soimy/c3rb3r-rescue	Proxmox VE 가상 머신에서 GitLab을 실행 중인 DSM	복구 성공	게스트 RAM의 16 GiB 복사본에 48바이트 세션 키가 남아 있었습니다. GitLab의 프로젝트 80개 및 LFS 개체 9,253개가 복구되었습니다.
Benjamin-zlt/c3rb3r-baremetal-rescue	베어메탈 DS918+ 클론, DSM 7.2	복구 성공	실행 중인 암호화 프로세스를 SIGSTOP으로 동결하고 약 2 GB의 메모리를 덤프했습니다. 2.5시간 만에 84,500개 파일(약 940 GB)이 복구되었습니다.
lllong1377/c3rb3r-never-rebooted-still-no-key	DS918+ 클론, DSM 7.2-64570 Update 3, 가동 시간 149일	복구 실패	암호화 프로그램은 이미 약 30시간 전에 종료된 상태였습니다. 전체 RAM 및 스왑 스캔 결과 키를 찾지 못했습니다.

세 번째 리포지토리가 읽어야 할 가장 중요한 곳입니다. 제목 자체가 교훈이기 때문입니다: '재부팅하지 않았다고 해서 복구 가능한 것은 아니다'. 중요한 것은 C3RB3R ransomware 프로세스가 여전히 실행 중인지 여부입니다. 프로세스가 종료되면 키 버퍼를 0으로 덮어쓰므로 키가 사라집니다. 한 피해자에게서 복구한 키는 다른 피해자에게 무용지물입니다. 실행될 때마다 새 세션 키가 생성되기 때문입니다.

왜 키가 메모리에만 존재하는가

Benjamin-zlt 분석은 C3RB3R ransomware 파일 형식을 자세히 설명하며, 이것이 작동하는 이유와 보통 작동하지 않는 이유를 모두 설명합니다.

• 각 파일에는 고유한 임의의 ChaCha8 키가 할당됩니다. 해당 키는 AES-256-CBC를 사용하는 세션 마스터 키로 래핑되어 파일 끝의 588바이트 트레일러에 저장됩니다.
• 세션 마스터 키는 48바이트입니다: 16바이트 IV와 32바이트 AES 키로 구성됩니다. 디스크에 절대 기록되지 않으며, 실행 중인 프로세스 내부의 전역 포인터가 이를 가리킵니다.
• 트레일러에는 공격자의 공개 키로 래핑된 블롭(blob)도 포함되어 있습니다 (RSA-2048), 따라서 실행 중인 프로세스가 없으면 공격자만 세션 키를 복구할 수 있습니다.
• 모든 파일이 완전히 암호화되는 것은 아닙니다. 400개 파일 샘플 중 약 56%는 분할(segmented) 모드를 사용했고, 31%는 처음 1 MiB만 암호화되었으며, 13%는 처음부터 끝까지 전체가 암호화되었습니다. 부분적으로 암호화된 파일도 여전히 읽을 수 없지만, 푸터(footer) 검수를 통해 남은 부분을 확인할 수 있습니다.

따라서 C3RB3R ransomware의 약점은 한정적이며 시간 제약이 있습니다. 암호화 프로그램은 전체 세션 동안 마스터 키를 메모리에 유지합니다. 실행 중일 때 프로세스를 동결(freeze)하면 키를 추출할 수 있습니다. 그 기회를 놓치면 해독 불가능하도록 설계된 공개 키 블롭만 남게 됩니다.

피해 사례: 50 TB와 스냅샷 부재

2026년 10월 29일 Xiaohongshu에 柯基爱好者 사용자가 올린 상세한 기록은 그들의 NAS 그룹 멤버 한 명의 밤사이를 다루고 있습니다. 그는 C3RB3R ransomware 랜섬노트를 발견하고 C3RB3R INSTRUCTIONS 헤더를 확인한 후 비트코인을 구매하기 직전이었으나, 그룹 멤버들이 GitHub 사례를 안내해 주었습니다.

그런 다음 그는 SSH를 통해 AI 코딩 어시스턴트를 사용하여 조사했습니다. AI는 암호화 프로그램을 찾아내 동결시켰고, 그 시점 이후에는 새로 암호화된 파일이 없었습니다. 또한 백도어 셸 추정 프로그램이 NAS에 37일 동안 상주하면서 root로 telnet을 활성화했다는 사실을 발견했습니다. 이는 최초 침입과 암호화 실행 사이에 한 달 이상의 차이가 있었음을 의미합니다. AI는 증거 수집 스크립트를 작성하고 root 권한으로 실행하기 전에 올바르게 그의 확인을 기다렸습니다.

다행히도 C3RB3R ransomware는 속도가 느렸습니다. 50 TB가 넘는 데이터를 암호화해야 했기에 암호화 프로그램은 2024년 사진에만 도달한 상태였고, 해당 사진은 클라우드 드라이브에 콜드 카피가 존재했습니다. 그는 작업 데이터를 더 작은 NAS로 옮기고 암호화된 볼륨을 나중을 위해 보관해 두었습니다. 그의 자체 요약은 단호했습니다. 그에게는 스냅샷이 없었으며, 스냅샷이 있었다면 쉽게 해결할 수 있었을 것입니다. X의 또 다른 피해자는 반대 입장에서 같은 교훈을 요약했습니다: RAID 6에 3개의 백업 세트가 모두 동일한 장비에 있어 함께 암호화되었다고 말입니다.

C3RB3R Ransomware로부터 백업을 안전하게 보호하는 방법

위의 모든 데이터 손실 사례는 동일한 양상을 보입니다. 손상된 기기에서 백업에 접근할 수 있었다는 점입니다. C3RB3R ransomware는 침해된 DSM이 쓸 수 있는 모든 것을 암호화하므로, 해결책은 DSM이 전혀 쓸 수 없는 장소에 최소 하나의 복사본을 보관하는 것입니다. 이것이 우리가 호스팅하는 사이트에 적용하는 방식이며 3-2-1-1-0 규칙에 대응합니다.

규칙	의미	당사의 적용 방식
3	데이터 복사본 3개	실행 중인 VM, 두 번째 NAS의 복제본 및 예약된 내보내기
2	2가지 유형의 미디어	NAS 볼륨에 더해 USB 드라이브 및 클라우드 드라이브
1	1개의 오프사이트 복사본	Cloud Sync를 통해 Google Drive로 동기화된 내보내기
1	1개의 오프라인 또는 불변(immutable) 복사본	게스트가 건드릴 수 없는 호스트 측 VM 스냅샷 및 연결 해제된 USB 내보내기
0	복구 시 오류 0건	호스트 간에 VM을 이동할 때 실제로 복제본에서 복구하고 부팅함

호스트가 아닌 Virtual DSM 내부에서 Docker 실행

당사의 WordPress 컨테이너는 물리적 NAS에서 실행되지 않습니다. Virtual DSM 게스트 내부에서 실행되며, 게스트는 호스트의 Virtual Machine Manager에 의해 보호됩니다. C3RB3R ransomware가 게스트 내부에서 root 권한을 획득하더라도 해당 게스트만 점령할 뿐 다른 곳에는 접근할 수 없습니다. 게스트의 스냅샷은 게스트 파일 시스템 외부인 호스트 스토리지에 존재하므로 VM 내부의 랜섬웨어가 이를 보거나 암호화 또는 삭제할 수 없습니다. 복구는 단 몇 분 만에 완료되는 스냅샷 롤백입니다.

VMM Pro는 이를 진정한 백업으로 전환하는 기능을 추가합니다. VM의 스냅샷을 찍고 클러스터의 두 번째 NAS로 복제하는 보호 계획을 제공하여 호스트 장애도 대비할 수 있습니다. 당사의 클러스터는 서로 복제하는 DS1621xs+ 및 DS1525+로 구성되어 있습니다. 당사는 예약된 내보내기 및 Google Drive로의 Cloud Sync 부분을 별도로 작성했으며, 무료 VMM 대 VMM Pro 비교 에서 어떤 부분에 라이선스가 필요한지 설명합니다.

DSM에서 직접 Docker를 실행하는 경우 불변(immutable) 스냅샷 사용

모든 사람이 VM 레이어를 원하는 것은 아닙니다. 컨테이너가 호스트에서 직접 실행되는 경우 C3RB3R 랜섬웨어에 대한 방어책은 변경 불가능한 스냅샷입니다. 컨테이너 데이터를 보관하는 공유 폴더에 대해 Snapshot Replication에서 이 기능을 활성화하세요. DSM 7.2 이상 및 Btrfs 볼륨이 필요하며, 잠금 기간 동안에는 공격자가 탈취한 관리자 계정을 포함해 그 누구도 이를 삭제할 수 없습니다. 성패를 좌우하는 두 가지 세부 사항은 다음과 같습니다:

• 공유 폴더로 바인드 마운트 사용 예: /volume1/docker/app. Docker 이름 지정 볼륨은 다음 아래에 위치합니다: /volume1/@docker, 이 경로는 공유 폴더가 아니므로 스냅샷을 전혀 생성할 수 없습니다.
• 스냅샷을 찍기 전에 데이터베이스를 파일로 덤프하세요. 실행 중인 MariaDB의 스냅샷은 강제 전원 차단 순간의 복사본과 같습니다. 예약된 mysqldump 동일한 공유 폴더로 백업하면 스냅샷이 잠그는 깨끗한 복구 지점을 얻을 수 있습니다.
• 공격자가 조용히 잠복할 수 있는 기간보다 긴 잠금 기간을 선택하세요. 위의 피해자는 암호화가 시작되기 전 37일 동안 백도어가 설치되어 있었습니다. 7일간의 불변 스냅샷으로는 깨끗한 상태로 되돌릴 수 없었을 것입니다.

추가적인 방어층: 암호화 시작 시 Active Insight가 스냅샷을 촬영합니다

대부분의 가이드에서 간과하는 레이어가 바로 이것입니다. Synology 클라우드 모니터링 서비스인 Active Insight는 공유 폴더의 파일 활동을 감시할 수 있으며, 랜섬웨어 감염으로 판단되면 자동으로 대응합니다. Synology는 이 기능을 자체 NAS 보안 가이드에 설명하고 있습니다: 랜섬웨어 이벤트가 감지되면 Active Insight는 이벤트 알림을 보내고 공유 폴더의 스냅샷을 자동으로 촬영하며, 이를 지원하는 모델에서는 해당 스냅샷이 변경 불가능(immutable) 상태로 보호됩니다.

이것이 C3RB3R 랜섬웨어 대응에 특히 중요한 이유는 C3RB3R 랜섬웨어의 암호화 속도가 느리기 때문입니다. 50 TB 이상의 데이터를 보유한 한 피해자는 2024년 사진 폴더가 암호화되던 중에야 이를 알아챘습니다. 암호화 패턴이 처음 나타날 때 촬영된 스냅샷은 아직 손상되지 않은 모든 파일(볼륨의 대부분일 수 있음)을 동결하여 보존합니다. 또한 로그인 페이지가 아닌 파일의 변화 추이를 감시하기 때문에 C3RB3R 랜섬웨어가 어떤 경로로 침입했는지와 상관없이 작동합니다. 저희 DS1621xs+의 파일 활동 페이지에서는 랜섬웨어 보호 기능이 '보호됨'으로 표시됩니다.

이 기능에 의존하기 전에 제한 사항을 확인하세요. 이는 Synology’s 파일 활동 설명서:

• 파일 활동 모니터링은 기본적으로 비활성화되어 있습니다. 제어판에서 NAS를 Active Insight에 등록한 다음, Active Insight 포털에서 각 호스트에 대한 모니터링을 활성화하세요.
• Snapshot Replication이 필요하며, DSM 7.2 이상, Active Insight 3.0.2 이상, 최소 1 GB 메모리, 그리고 해당 NAS에 할당된 Active Insight 라이선스가 필요합니다.
• 공유 폴더당 하루 최대 1회의 자동 스냅샷만 지원됩니다. 이는 감지 후 실행되는 안전장치이며, 정기적인 예약 변경 불가 스냅샷을 대체할 수는 없습니다.
• 적용 대상 제외: Surveillance Station 녹화 폴더 및 외부 USB 드라이브의 공유 폴더.
• 변경 불가능(Immutability) 여부는 모델에 따라 다릅니다. 변경 불가 스냅샷을 지원하지 않는 모델의 경우, root 권한을 가진 공격자가 자동 스냅샷을 삭제할 수 있으므로 앞서 언급한 변경 불가 스냅샷 일정과 함께 구성해야 합니다.

동일한 설정을 구성하시겠습니까? SynoPower Club은 두 구성 요소에 대한 정품 라이선스를 판매합니다: Virtual DSM (VDSM) 라이선스 격리된 게스트에서 Docker 서비스를 실행하기 위한 라이선스 및 VMM Pro 라이센스 보호 계획, 이종 NAS 간 복제 및 라이브 마이그레이션을 위한 라이선스. 라이선스 키는 이메일로 전달됩니다.

더 많은 공식 자료를 찾을 수 있는 곳

작성 시점 기준으로 Synology의 C3RB3R 랜섬웨어는 공개된 지 이틀밖에 되지 않았으며 아직 공식 영상 설명이 없으므로, 이 섹션에서는 가이드 대신 기본 출처를 나열합니다.

• Synology 보안 권고 2026년 10월 29일 자 권고안에서는 이전 버전 DSM 사용자에게 즉시 업데이트하고 자동 업데이트를 활성화할 것을 안내했으며, 이어서 10월 30일 고객 이메일을 통해 SA-24:20이 관련된 유일한 취약점임을 확인했습니다.
• Synology-SA-24:20 그리고 Synology-SA-26:13 버전 테이블입니다. 제어판 > 업데이트 및 복구에서 빌드를 확인하고 두 테이블과 모두 비교하세요.
• lllong1377/c3rb3r-never-rebooted-still-no-key 여기에 다루지 않은 사례를 포함하여 알려진 모든 사례를 정리한 가장 좋은 색인이자, 메모리 포렌식이 무의미한 시점에 대한 가장 명확한 설명입니다.
• 위에서 링크한 세 개의 r/synology 스레드, 특히 단계별 읽기 전용 디스크 조사 명령어가 포함된 포렌식 분석 보고서: 결국 터지고야 말았습니다.

Synology’s 자체 체크리스트 (2026년 10월 30일)

Synology가 고객에게 보낸 이메일은 4단계 조치 사항으로 마무리됩니다. 내용은 간단하지만, C3RB3R 랜섬웨어 방어에 모두 매우 중요합니다:

1. 침입자 확인. C3RB3R 랜섬웨어는 지속성을 유지하기 위한 예약 작업을 남겨두므로, Security Advisor 검사를 실행한 후 작업 스케줄러에서 직접 생성하지 않은 스크립트가 있는지, 사용자 및 그룹에서 직접 추가하지 않은 관리자 계정이 있는지 확인하세요. 의심스러운 점이 있으면 Synology 지원팀에 문의하세요.
2. 모든 항목 업데이트. 제어판의 '업데이트 및 복원'에서 최신 DSM을 설치한 다음, 패키지 센터에서 모든 패키지를 업데이트하세요.
3. 자동 업데이트 켜기 '업데이트 및 복원'에서 설정하여 향후 보안 패치가 출시되는 즉시 적용되도록 하세요.
4. 외부 백업 유지. Hyper Backup 및 Snapshot Replication을 사용하여 별도의 장소에 복사본을 보관하고, 백업 작업이 실제로 정상 완료되는지 정기적으로 확인하세요.

1단계는 사람들이 가장 흔히 건너뛰는 단계입니다. 2024년 12월 패치 전 인터넷에서 NAS에 접근할 수 있었다면 C3RB3R 랜섬웨어가 이미 거점을 확보했을 수 있으며, 오늘 업데이트를 진행하더라도 내부에 침입자가 있는지 여부는 알 수 없습니다.

점검을 대신 실행해 주는 무료 도구

터미널 사용이 익숙하시다면, 1단계는 이제 단 하나의 명령어로 가능합니다. synology-nas-cli는 독립 개발자인 Akari Sora가 2026년 10월 30일에 공개한 MIT 라이선스 기반의 오픈소스 커맨드라인 도구입니다. 웹 API를 통해 DSM에 로그인하여 이 캠페인(위협)에 대해 시스템을 감사합니다. 이 프로젝트는 GitHub에 있습니다: akari-sora/synology-nas-cli.

링크를 게재하기 전에 해당 코드를 직접 검토했습니다. 이 도구는 Python 표준 라이브러리만 사용하며, 사용자의 NAS, Synology 다운로드 서버, PyPI 및 soimy 복구 툴킷 외에는 어떠한 서버와도 통신하지 않습니다. 텔레메트리를 전송하지 않으며, 기본 감사는 읽기 전용으로만 동작합니다. 점검 항목은 다음과 같습니다:

• 패치 수준. 이전 SA-24:20 수정 사항도 포함하는 Synology-SA-26:13 기준 DSM 빌드 버전, 그리고 SA-26:14 기준 설치된 패키지 검사.
• 외부 노출 상태. QuickConnect, 라우터의 UPnP 포트 포워딩, DSM 방화벽, 자동 차단(AutoBlock), SMB1 및 기본 제공 admin 계정.
• C3RB3R 랜섬웨어의 흔적. 연결 로그에 주입된 로그인 문자열, /etc/cron.d/synot* 항목, libgld 그리고 qnetd 바이너리, 추가 root 계정, SSH 키 및 공유 폴더 내 랜섬노트.
• 스냅샷. 작동 중인 스냅샷 일정이 없는 공유 폴더.

이 도구는 발견된 문제 대부분을 직접 수정할 수도 있습니다. 현재 파일이 암호화되는 중이라면 `contain` 명령어가 SIGSTOP으로 암호화 프로그램을 동결시킵니다. 이는 당사의 초기 대응 목록 2단계와 동일한 조치입니다. 이후 `rescue` 명령어가 soimy 툴킷을 실행하여 메모리를 캡처하고 키를 검색합니다.

nas incident                 # 읽기 전용 감사

nas incident --deep # 임플란트 탐색도 함께 수행 (읽기 전용 root 스크립트 1개)

• nas incident fix --dry-run # 적용될 모든 변경 사항을 나열하며, 실제로 아무것도 변경하지 않음. 변경 사항을 적용하기 전에 다음 주의사항을 읽어보세요:.
• 최신 도구입니다. 이 프로젝트는 공개된 지 며칠 되지 않았으며, 개인 개발자가 제작하였고 Synology와 제휴되지 않았으며 외부 검토가 거의 이루어지지 않았습니다. 먼저 읽기 전용 감사 및 dry-run(시뮬레이션)으로 시작하세요.
• 방화벽 수정 시 접속이 차단될 수 있습니다. 사용자가 지정한 네트워크를 제외한 모든 접속을 거부하도록 DSM 방화벽을 변경합니다. 동일한 LAN 환경의 컴퓨터에서 실행하고, RESET 버튼의 위치를 미리 확인해 두세요.
• QuickConnect를 끕니다. 이는 더 안전한 설정이지만, 가족 구성원이 QuickConnect를 통해 Synology Photos나 Surveillance Station에 접속하는 경우 먼저 VPN이나 Tailscale을 설정하세요.
• 정밀 검사, contain 및 rescue 기능은 root 권한으로 실행됩니다. root 전용 로그를 읽고 프로세스를 동결시키는 유일한 방법이기 때문에 임시 작업 스케줄러(Task Scheduler) 작업을 통해 작동합니다.
• README에서는 AI 에이전트에 작업을 위임하는 방안을 제안합니다. AI 에이전트를 사용할 경우, 비밀번호를 채팅에 입력하지 말고 비밀번호 관리자에 보관하며 조치 사항을 직접 확인하세요.

보안 강화 작업의 나머지 부분에 대해서는 다음 가이드를 참조하세요: Synology NAS에서 공개 웹사이트 운영하기 및 Threat Prevention이 감지할 수 있는 항목과 감지할 수 없는 항목 네트워크 측면을 다루며, PHP2Shell 패치 가이드 같은 주에 발생한 다른 치명적인 문제를 다룹니다.

C3RB3R 랜섬웨어 한계 및 보안 참고 사항

업데이트를 한다고 해서 기존 감염 상태가 제거되지는 않습니다. 최신 DSM으로 업그레이드한 후에도 cron 지속성이 여전히 남아 있음을 발견한 피해자가 최소 한 명 이상 있었습니다. 패치되지 않은 상태로 노출되었다면 다음 항목을 확인하세요: /etc/cron.d, 작업 스케줄러, 시작 스크립트 및 telnet과 같은 활성화된 서비스를 점검하고 모든 자격 증명을 변경하세요.

최신 상태가 곧 안전한(깨끗한) 상태를 의미하지는 않습니다. 한 Reddit 피해자는 DSM이 최신 상태라고 믿었고, 또 다른 피해자는 2FA와 강력한 비밀번호가 설정된 상태에서도 피해를 입었습니다. 패치 적용 전에 침해된 장치는 이후의 모든 업데이트에서도 악성 코드(implant)를 유지할 수 있습니다. 의도적으로 설정하지 않은 UPnP로 인해 노출된 로그인 페이지를 포함하여, 인터넷에서 접근 가능한 모든 DSM 로그인 페이지를 공격 목표로 간주하십시오. 원격 액세스에는 VPN이나 Tailscale을 사용하고 라우터에서 UPnP를 끄십시오.

RAID 및 로컬 백업은 C3RB3R 랜섬웨어에 대비한 백업이 아닙니다. 침해된 DSM이 쓰기 권한을 가진 모든 데이터는 동일한 기기의 Hyper Backup 대상 및 마운트된 네트워크 공유를 포함하여 암호화됩니다.

사례들을 읽기 전에 대가를 지불하지 마세요. C3RB3R 랜섬웨어 유포자에게 대가를 지불하는 것은 다음 공격 자금을 대주는 것일 뿐 아무것도 보장하지 않습니다. 암호화 프로그램이 아직 실행 중이라면 무료 메모리 포렌식이 최선의 방법입니다. 그렇지 않다면 현실적인 방법은 기기 외부에 보관된 자체 백업본뿐입니다.

AI 어시스턴트에 붙여넣는 내용에 주의하세요. AI 도구가 여러 피해자에게 도움이 되었지만 비밀번호, 복구된 키, 전체 메모리 덤프 또는 비즈니스 데이터를 제공해서는 안 됩니다. AI가 명령어를 제안하도록 하고, root 권한이 필요한 모든 작업은 직접 실행하세요.

클론(비정품) 하드웨어는 추가적인 위험을 초래합니다. 기록된 피해자 중 몇몇은 공식 업데이트를 적용하기 어렵거나 불가능한 비정품 하드웨어에서 DSM을 실행하고 있었습니다. 해당 환경이라면 패치되지 않은 것으로 간주하고 인터넷 접속을 완전히 차단하세요.

참고문헌

• DSM 랜섬웨어 공격에 대한 Synology 보안 권고, 2026년 10월 29일.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 및 수정된 DSM 빌드.
• Synology-SA-26:13 DSM, CVE-2026-13639 및 CVE-2026-13684, 2026년 9월 18일 발표.
• Benjamin-zlt C3RB3R 랜섬웨어 베어메탈 복구, 파일 형식, 키 레이아웃 및 SIGSTOP 워크플로.
• 메모리 복구는 암호화 프로그램이 실행 중일 때만 작동합니다., GitHub의 3가지 사례와 동일한 규칙이 적용됩니다.
• C3RB3R 캠페인에 대한 IT-Connect 분석, 360 속성 분석 및 타임라인 요약.
• Synology 지식 센터: Synology NAS 보안 강화하기, Active Insight가 랜섬웨어를 감지했을 때 공유 폴더의 스냅샷을 생성하는 방식을 포함합니다.

자주 묻는 질문

다음 C3RB3R 랜섬웨어 공격의 대가가 몸값이 아닌 단순 복원이 되도록 하세요. Virtual DSM 내에서 Docker 서비스를 실행하고 두 번째 NAS로 복제되는 VMM Pro 보호 계획으로 전체 게스트를 보호하세요. SynoPower Club은 이 두 가지 모두에 대한 정품 라이선스를 판매하며, 키는 이메일로 발송됩니다.