랜섬웨어는 백업부터 노렸다: 3AM 학교 사고 열흘로 본 백업 공격 경로와 점검 5가지

보안업체 Bitdefender가 11월 3일 영국 한 학교 법인의 랜섬웨어 사고 조사 결과를 공개했어요. 공격자는 서비스형 랜섬웨어 3AM의 제휴 조직이에요. 9월 10일부터 19일까지 열흘 동안 머물렀고, 마지막 날 아침 약 37대를 암호화했어요.

눈여겨볼 대목은 순서예요. 공격자는 첫날 백업 서버부터 털었고, 마지막 날 백업을 지웠어요. Bitdefender도 공격자가 백업 층을 처음과 마지막에 쳤다고 정리했어요.

1. 열흘 동안 일어난 일

• 9월 10~11일: 공개된 PowerShell 도구를 고친 스크립트로 Veeam 백업 서버 3대에 저장된 계정 정보를 꺼내 해독했어요. 백업 서버 한 대에는 SYSTEM 권한으로 도는 예약 작업도 만들었어요.
• 12~13일: 도메인 구조를 정찰했어요.
• 14~15일: Mimikatz 등으로 계정을 더 빼냈어요. 도메인 관리자 계정 2개(library, svc_bkpmon)를 새로 만들었고, 15일에는 자료를 밖으로 빼냈어요. svc_bkpmon은 백업 감시 계정처럼 보이는 이름이에요.
• 18일: 원래 따로 있던 도메인 3개를 양방향 신뢰로 묶어 한 번에 닿게 했어요.
• 19일 05:07~05:33: 약 40대에 실행 파일을 깔았고, 닿은 약 50대 가운데 약 37대가 암호화됐어요. 암호화 단계에서 시스템 상태 백업도 지웠어요. 보안 에이전트를 지우려던 시도는 변조 방지 기능에 막혔어요.

처음 들어온 경로는 끝내 밝혀지지 않았어요. Bitdefender는 명령이 40~100초 간격으로 조금씩 바뀌며 되풀이된 점을 들어 AI가 만든 명령일 가능성을 봤어요. 쓴 모델은 확인하지 못했고, 한 사례일 뿐이라고 덧붙였어요.

2. 왜 백업부터 노렸나

• 계정이 모인 곳: 백업 소프트웨어는 여러 서버에 접속해 자료를 가져와야 해요. 그래서 각 서버의 관리자 계정을 저장해 둬요. 백업 서버 한 곳을 열면 다른 서버 열쇠가 한꺼번에 나와요.
• 눈에 덜 띄는 계정: 백업 계정은 밤마다 여러 서버에 접속해요. 공격자가 같은 계정으로 돌아다녀도 평소 움직임과 잘 구분되지 않아요. 새로 만든 svc_bkpmon도 이 점을 노린 이름이에요.
• 복구를 끊는 곳: 백업이 살아 있으면 피해 기관은 몸값 없이 되살려요. 공격자가 마지막에 백업을 지운 이유예요.

백업 서버가 표적이 되는 구조는 지난 11월 5일 더존 백업 서버 분석에서도 다뤘어요. 그때는 여러 고객사 데이터가 모인 서비스였고, 이번에는 한 기관 안의 백업 서버예요. 두 사고 모두 백업 서버가 운영망에 상시 연결돼 있었어요.

3. 우리 회사 백업, 지금 확인할 5가지

1. 저장된 계정 목록: 백업 소프트웨어에 어떤 서버의 어떤 계정이 들어 있는지 뽑아 봐요. 도메인 관리자 계정이 들어 있으면 그 서버에 필요한 권한만 가진 계정으로 바꿔요.
2. 도메인과 떼기: 백업 서버와 백업 관리 계정을 운영 도메인에 묶지 않아요. 도메인이 여럿이면 백업 계정도 도메인마다 따로 둬요. Bitdefender도 백업 계정을 도메인별로 나누고 백업 서버를 격리하라고 권했어요.
3. 새 계정·예약 작업: 최근 만들어진 도메인 관리자 계정, 백업 서버의 낯선 예약 작업, 새로 생긴 도메인 신뢰를 이번 주에 한 번 훑어요. 이번 사고에서는 셋 다 암호화 며칠 전에 생겼어요.
4. 같은 장비 안 백업: 시스템 상태 백업이나 같은 서버 안의 사본은 관리자 권한을 빼앗기면 명령 한 줄로 지워져요. 이것만 믿지 않아요.
5. 지울 수 없는 사본 하나: 어떤 도메인 계정으로도 바꾸거나 지울 수 없는 곳에 복구 사본을 하나 둬요. 연 1회 이상 그 사본으로 실제 복구를 해 봐요.

4. 어느 층에서 막혀야 했나

이번 사고에서 백업은 두 번 뚫렸어요. 첫째는 백업 서버에 저장된 계정이 공격자의 열쇠가 된 층이에요. 둘째는 관리자 권한만 있으면 백업을 지울 수 있던 층이에요. 1~4번 점검은 이 두 층을 좁혀요. 침입 경로가 끝내 밝혀지지 않은 것처럼 입구는 다 막지 못해요. 그래서 마지막 층은 「도메인을 통째로 빼앗겨도 되살릴 수 있느냐」로 따로 세워야 해요.

운영망이 뚫려도, 백업은 디포트리스가, 내부망은 엔포트리스가 물리적 단방향 경계로 지키도록 설계했습니다. 락게이트코어 D-FORTRESS는 데이터 트랜지스터 기술로 백업 데이터를 한 방향으로만 보내, 네트워크로는 바꾸거나 지울 수 없는 영역에 복구 사본을 둬요. 도메인 관리자 계정이나 백업 서버 계정을 빼앗겨도 그 사본에는 닿는 길이 없도록 설계했어요. 복구는 승인 절차를 거쳐 따로 해요. 백업 계정 정리와 접근 통제를 대신하지는 않아요.

5. 자주 묻는 질문

Q1. Veeam 취약점 때문에 생긴 사고인가요?

Bitdefender 보고서는 특정 취약점을 지목하지 않았어요. 공격자는 백업 서버에 저장된 계정 정보를 꺼내 해독했어요. 업데이트는 그대로 하고, 백업 서버에 어떤 계정이 들어 있는지도 함께 봐야 해요.

Q2. Veeam을 쓰지 않으면 상관없나요?

백업 소프트웨어는 대개 여러 서버에 접속하려고 계정을 저장해요. 제품이 달라도 백업 서버에 관리자 계정이 모여 있으면 같은 질문이 남아요.

Q3. 지울 수 없게 설정한 저장소가 있으면 충분한가요?

큰 도움이 돼요. 그 설정을 바꿀 수 있는 관리 계정이 운영 도메인과 이어져 있으면 그 계정을 빼앗길 때 함께 위험해져요. 관리 계정을 운영망과 떼어 두세요.

Q4. 처음 침입 경로를 모르면 대비할 수 없지 않나요?

이번 사고도 침입 경로는 밝혀지지 않았어요. 입구를 다 알 수 없으니 백업 계정 범위를 줄이고, 계정을 빼앗겨도 닿지 않는 복구 사본을 따로 두는 대비가 필요해요.

6. 정리

• 3AM 제휴 조직은 첫날 백업 서버 계정을 꺼내고, 마지막 날 백업을 지운 뒤 약 37대를 암호화했어요.
• 백업 서버는 다른 서버의 열쇠가 모인 곳이라 먼저 노려져요.
• 백업 계정 범위를 줄이고, 도메인 계정으로 지울 수 없는 복구 사본을 하나 둬요.

참고자료 (기준일 2026-11-08)

• Bitdefender, 3AM Hits European Schools: A Hybrid AI Ransomware Attack, 2026-11-03
• BleepingComputer, UK school estate hit by 3AM ransomware in suspected AI-assisted attack, 2026-11-03

태그

• 3AM랜섬웨어
• 백업서버보안
• Veeam
• 도메인관리자
• 복구사본
• 심층분석