이전 포스팅에 이어 2020년 초 파이어아이가 탐지한 SUNBURST 백도어 추가 기술 정보를 알아보겠습니다. 이 맬웨어는 UNC2452라고 이름 붙인 위협 행위자에 의해 배포된 것이며 2020년 초 이후 지금까지 파이어아이는 이들의 활동을 면밀히 추적하고 있습니다.

SUNBURST는 SolarWinds의 IT 모니터링 및 관리 플랫폼인 Orion의 플러그인(SolarWinds.Orion.Core.BusinessLayer.dll)입니다. 이 플러그인에는 HTTP를 통해 타사 서버와 통신하는 백도어가 포함되어 있습니다. 최대 2주의 휴면 기간이 지나면 SUNBURST는 백도어에 파일 전송, 파일 실행, 시스템 프로파일링, 시스템 재부팅 및 시스템 서비스 비활성화를 지시하는 명령을 검색하고 실행할 수 있습니다. 악성 코드의 네트워크 트래픽은 OIP(Orion Improvement Program) 프로토콜을 모방하여 합법적인 SolarWinds 활동과 섞이려 시도합니다. 백도어는 여러 난독화된 차단 목록을 사용해 포렌식 및 안티 바이러스 도구 관련 프로세스, 서비스, 드라이버를 식별합니다. 본 포스팅에서는 다음 내용을 더 자세히 알아보겠습니다.

• 분석 방지 환경 검사 및 차단 목록
• 도메인 생성 알고리즘 및 변형
• DNS A 및 CNAME 레코드에 대한 명령 및 제어(C2) 동작
• 맬웨어 작동 모드

분석 방지 환경 검사

C2 서버에 접근하기 전에 SUNBURST는 분석 도구가 없는지 확인하기 위해 검사를 수행합니다. 진행 전에 프로세스 이름, 파일 쓰기 타임스탬프 및 액티브 디렉토리(AD) 도메인을 확인합니다. 파이어아이는 이런 접근이 백도어 배포 후 7개월 동안 안티 바이러스 소프트웨어 및 포렌식 전문가 탐지를 피하는 데 도움이 되었다고 보고 있습니다.

백도어는 먼저 현재 프로세스 소문자 이름이 solarwinds.businesslayerhost인지 확인합니다. UNC2452는 문자열 해시를 계산하고 결과를 64비트 숫자인 17291806236368054941과 비교하며, 문자열을 소스 코드에 직접 포함하지 않습니다. 해시 값은 64비트 숫자 6605813339339102567로 계산하는데, 추가 XOR이 있는 표준 FNV-1A 64비트 해시로 계산됩니다.

백도어는 .NET 어셈블리 SolarWinds.Orion.Core.BusinessLayer.dll의 파일시스템 마지막 쓰기 시간이 현재 시간보다 최소 12~14일 이전인 경우만 실행됩니다. 정확한 임계 값은 무작위로 선택됩니다. 즉, SUNBURST는 2주 동안 숨어 지냅니다. 타임스탬프 검사가 실패하면 백도어가 합법적인 반복 백그라운드 작업에 의해 호출될 때 무작위로 다시 실행됩니다. 입계 값이 충족되면 583da945-62af-10e8-4902-a8f205c72b2e 파이프라인을 생성하여 백도어의 한 인스턴스만 실행되도록 합니다.

SUNBURST는 해당 구성을 합법적인 SolarWinds.Orion.Core.BusinessLayer.dll.config 파일에 저장합니다. 그리고 appSettings 섹션의 두 가지 기존 설정인 ReportWatcherRetry 및 ReportWatcherPostpone을 다시 사용합니다. 초기화 중 백도어는 ReportWatcherRetry 설정 값이 3인지 확인합니다. 이 값은 맬웨어가 비활성화되었으며 더 이상 네트워크 활동을 수행하지 않음을 나타냅니다. 참고로 UNC2452 행위자는 백도어가 스스로 비활성화되도록 명령할 수 있습니다. SUNBURST에 의해 손상된 시스템들을 조사할 때 이 설정을 검토해 백도어가 비활성화되었는지 확인하십시오. 이 값의 존재는 행위자가 SUNBURST를 비활성화기 전에 환경을 더 이상 손상시키지 않았다는 증거를 제공하지는 않습니다.

또한, 백도어는 시스템이 액티브 디렉토리 도메인에 가입되어 있는지 확인하고 해당하는 경우 도메인 이름을 검색합니다. 시스템이 액티브 디렉토리 도메인에 가입되어 있지 않으면 실행이 중지됩니다. SUNBURST는 차단 목록에 대해 액티브 디렉토리 도메인 이름을 확인하고 다음 값 중 하나가 포함된 경우 실행을 중지합니다.

이러한 하드 코딩된 액티브 디렉토리 도메인은 UNC2452가 피하고 싶어 했던 SolarWinds 내부 도메인일 수 있습니다. 마지막으로 SUNBURST는 DNS 이름 api.solarwinds.com을 확인할 수 있는지 확인하여 시스템이 인터넷에 연결되어 있는지 알아봅니다. 연결되어 있지 않으면 실행이 중지되고 나중에 임의로 다시 시작합니다.

분석 방지 차단 목록

SUNBURST의 동작은 맬웨어 분석 및 보안 소프트웨어의 존재에 영향을 받습니다. 따라서 UNC2452 행위자는 보안 도구를 검색하는 데 사용하는 문자열을 위장하기 위해 각 문자열에 대한 해시 값을 계산하고 포함했습니다. 백도어가 해시 된 프로세스 이름의 존재를 확인하는 것은 사소한 일이지만 해시 값이 포함되어 있는 문자열을 결정하는 것은 많은 계산이 필요합니다. 다행히 정보 보안 커뮤니티 구성원들의 노력 덕에 해시 목록 및 문자열을 정리할 수 있었고, 이는 파이어아이 깃허브 페이지에서 볼 수 있습니다. .

SUNBURST는 앞서 설명한 바와 같이 FNV-1A와 XOR 알고리즘을 사용해 시스템의 각 프로세스 이름, 서비스 이름, 드라이버 파일 이름의 해시를 계산합니다. 차단 목록에 있는 프로세스나 드라이버 이름이 발견되면 SUNBURST는 일시 중지되고 나중에 다시 시도합니다. 백도어는 차단 목록의 프로세스나 드라이버가 없는 경우만 검사를 통과합니다.

차단된 서비스가 발견되면 SUNBURST는 윈도우 레지스리트에서 서비스 구성을 조작하여 차단된 서비스를 비활성화하려고 합니다. 레지스트리 값 HKLM \ SYSTEM \ CurrentControlSet \ services \ \ Start를 SERVICE_DISABLED에 해당하는 값 4로 설정합니다. 그 결과 차단 목록에 있는 서비스는 다음 번 시스템 전원을 다시 꺼고 켜는 주기에서 비활성화됩니다. 즉, 손상된 호스트에 차단된 서비스가 있다고 해서 SUNBURST에 영향을 받지 않는다고 볼 수 없습니다.

레지스트리를 수정한 후 SUNBURST는 비활성화된 서비스를 반영하도록 ReportWatcherPostpone 구성 값을 업데이트합니다. 그런 다음 백도어는 나중에 프로세스 및 서비스 차단 목록 검사를 일시 중지하고 다시 시도합니다. 후속 서비스 차단 목록 검사는 ReportWatcherPostpone 구성 키에 이미 있는 서비스를 건너 뜁니다. SUNBURST는 비활성화한 서비스를 더 이상 차단 목록의 구성원으로 취급하지 않습니다. 따라서 사고 대응 중에 포렌식 팀은 구성 키를 복구 및 디코딩 하여 SUNBURST가 비활성화려고 시도한 서비스를 구문 분석해야 합니다.

도메인 생성 알고리즘

이제 SUNBURST가 C2 코디네이터를 사용해 최종 C2 서버를 검색하는 방법을 알아보겠습니다. C2 코디네이터는 백도어에 비커닝을 계속하거나 중지하도록 지시합니다. 또한, DNS CNAME 레코드를 통해 SUNBURST를 최종 C2 서버로 리다이렉션합니다.

C2 코디네이터는 avsvmcloud [.] com 도메인에 대한 권한이 있는 DNS 서버로 구현됩니다. C2 코디네이터와 통신하기 위해 SUNBURST는 DGA(Domain Generation Altorithm)을 사용하여 avsvmcloud [.] com의 하위 도메인을 구성하고 시스템 DNA 클라이언트를 사용하여 FQDN(fully qualified domain names)을 확인합니다. 백도어는 DNS 응답을 특이한 방식으로 해석하여 C2 코디네이터로부터 주문을 받습니다. DGA는 다음 DNS 접미사를 사용하여 하위 도메인을 생성하여 FQDN을 만듭니다.

• .appsync-api.eu-west-1[.]avsvmcloud[.]com
• .appsync-api.us-west-2[.]avsvmcloud[.]com
• .appsync-api.us-east-1[.]avsvmcloud[.]com
• .appsync-api.us-east-2[.]avsvmcloud[.]com

Udpate라는 메소드는 임의의 C2 하위 도메인 생성을 위해 암호화 헬퍼를 초기화하는 역할을 합니다. 하위 도메인은 인코딩된 사용자 ID를 시스템 도예인 이름의 인코딩과 연결하여 생성됩니다. C2 코디네이터는 인코딩된 데이터에서 피해자 도메인 이름을 복구할 수 있으며, 이를 사용하여 SUNBURST를 최종 C2 서버로 라우팅을 할 수 있습니다. 사용자 ID는 다음 세 가지 값을 기반으로 생성됩니다.

• 사용 가능한 첫 번째 논루프백(non-loopback) 네트워크 인터페이스의 MAC 주소
• 도메인 이름
• HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Cryptography \ MachineGuid 값

SUNBURST는 이러한 결합된 값의 MD5 해시를 가져와 사용자 지정 XOR 체계를 사용해 인코딩합니다. 이 값은 UNC2452에서 고유한 피해자를 추적하는 데 사용됩니다. SUNBURST는 백도어의 작동 모드를 나타내기 위해 네 가지 다른 형태의 하위 도메인을 사용합니다. 각 양식에는 약간 다른 정보가 포함되어 있습니다. 포렌식 조사관은 두 가지 형태로 조직의 도메인 이름을 복구할 수 있습니다. DNS 로그를 검토하여 SUNBURST C2 코디네이터 트래픽에 피해자의 도메인이 있는지 확인하는 것이 좋습니다.

SUNBURST가 초기 모드에 있을 때 DGA 생성 도메인 접두사에 피해자 조직의 도메인을 포함합니다. 맬웨어가 "active' 모드로 전환되면 맬웨어는 다른 두 가지 형태의 하위 도메인을 사용합니다. 여기에는 액티브 디렉토리 도메인이 포함되지 않지만 대신 실행 및 중지된 서비스 목록 또는 타임스탬프의 인코딩이 포함됩니다.

오픈 소스 커뮤니티는 많은 하위 도메인 형식을 리버스 엔지니어링 하는 작업을 수행했습니다. 가능한 네 가지 인코딩을 모두 뒤집는 공용 디코더 스크립트를 알아 내진 못했지만 대부분의 디코더는 가장 유용한 정보인 하위 도메인에 포함된 사용자 ID 및 도메인 이름을 복구하는 데 유용합니다. DNS 로그에 대한 접근 권한이 있는 피해자 조직의 사고 대응자는 이러한 도구를 사용하여 액티브 디렉토리 도메인이 SUNBURST 생성 DNS 하위 도메인에 포함되어 있지 않은지 확인하는 것이 좋습니다. 도메인 디코딩 관련해 다음 리소스를 참조 바랍니다.

• https://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/
• https://github.com/RedDrip7/SunBurst_DGA_Decode
• https://blog.cloudflare.com/a-quirk-in-the-sunburst-dga-algorithm/

액터 작업 및 SUNBURST 사용 다이어그램

명령 및 제어

SUNBURST는 DNS와 HTTP를 모두 포함하는 두 부분으로 구성된 C2 프로토콜을 사용합니다. "passive" 모드에서 백도어는 DNS를 통해 C2 코디네이터와 통신하고 상태에 대한 높은 수준의 업데이트를 수신합니다. 예를 들어 C2 코디네이터는 백도에 슬립 또는 실행 모드로 전환하는 것을 지시할 수 있습니다. 백도어가 "active" 모드에 있으면 HTTP를 통해 최종 C2 서버로 통신하고 “spawn a process” 또는 “transfer a file” 같은 세부 명령을 받습니다.

DNS C2 및 C2 코디네이터 프로토콜

C2 코디네이터와 통신할 때 백도어는 DGA를 통해 지속해서 도메인을 생성합니다. 백도어는 도메인 생성을 임의 간격으로 지연합니다. 경우에 따라 최대 9시간이 지연됩니다. C2 코디네이터가 DNS A 레코드로 응답하면 SUNBURST는 하드코딩 된 IP 주소 블록 목록에 대해 확인된 주소를 확인합니다. 주소가 블록에 속하면 백도어가 관련 모드로 전환됩니다. 백도어는 전환이 될 때까지 DNS를 통해 차단 목록, 절전 및 비콘을 확인하는 것 외에도 아무것도 하지 않는 "passive" 모드에서 시작됩니다. 다른 모드는 맬웨어가 HTTP를 통해 통신하는 "active" 모드와 맬웨어가 영구적으로 비활성화되는 "disabled" 모드입니다.

C2 코디네이터는 DNS CNAME으로 응답할 수도 있습니다. 이 경우 맬웨어는 HTTPS C2 통신을 위해 CNAME 응답의 지정 대상 도메인을 사용합니다. SUNBURST는 스레드를 시작하여 명령 실행 및 추가 C2 HTTP(S) 콜아웃을 처리합니다.

악성 코드는 DNS CNAME 응답을 받기 직전에 다음 서브넷 중 하나를 가리키는 DNS A 레코드 응답을 받아야 합니다. 그렇지 않으면 CNAME 확인이 무시되고 오류로 처리됩니다. 또한, 이러한 서브넷의 경우 A 레코드 IP 주소의 최하위 바이트를 구문 분석하여 사용할 프록시 메소드, 사용할 RUI 체계 및 HTTP 스레드에서 사용되는 지연 값과 같은 구성 데이터를 가져옵니다.

다음 서브넷 범위의 후속 DNS A 레코드 응답으로 인해 DGA 비커닝이 계속됩니다.

그렇지 않으면 다음 서브넷 범위 후속 DNS A 레코드 응답으로 SUNBURST가 종료되고 구성 키를 추가 실행하는 것을 방지하는 값으로 업데이트합니다. 이것은 킬 스위치입니다.

"active" 모드에 있는 동안 DGA 하위 도메인 인코딩에는 피해자 컴퓨터 도메인 이름 정보가 포함되지 않습니다. 대신 DGA 하위 도메인은 타임스탬프 또는 중지/실행 중인 서비스 목록을 인코딩합니다. "passive" 모드로 다시 전환하기 위해 맬웨어 운영자는 다음 IP 범위 내에서 A 레코드를 확인하도록 DNS 서버를 설정할 수 있습니다.

맬웨어가 "active" 모드에서 "passive" 모드로 다시 전환되면 맬웨어 운영자는 악성 코드를 다시 활성화하기 위해 C2 코디네이터 활성화 프로세스를 반복해야 합니다.

HTTP(S) C2

SUNBURST는 통신할 새 호스트에서 CNAME DNS 응답을 받은 후 새 스레드를 시작해 HttpHelper.Initialize 메소드를 실행합니다. 이 메소드는 C2 통신 및 디스패치를 담당합니다. HTTP 스레드는 SetTime 명령으로 제어되는 구성 가능한 시간 동안 지연되는 것으로 시작됩니다. HTTP 스레드는 콜아웃 사이에 최소 1분 동안 지연됩니다. 악성 코드는 HTTP GET 또는 POST 요청을 사용합니다.

악성 코드는 임의의 하위 문자열 선택에서 HTTP GET 또는 POST 요청 URI를 구성합니다. 사용되는 체계는 CNAME DNS 응답 직전에 받은 A 레코드에 따라 다릅니다. GET 요청을 보낼 때 악성 코드는 인코딩된 사용자 ID를 포함하는 "If-None-Match" HTTP 헤더를 추가합니다. 이렇게 하면 C2 서버가 요청을 생성한 SUNBURST 설치를 확인할 수 있으므로 단일 서버에서 C2 스트림의 멀티플렉싱이 가능합니다.

파이어아이가 관찰한 트래픽에서 C2 서버는 스테가노그래피(steganography)를 사용해 HTTP 응답 본문 내의 데이터를 숨기고 .NET 어셈블리와 관련된 무해한 XML로 표시하려고 합니다. 명령 데이터는 여러 GUID 및 16 진수 문자열에 분산되어 있습니다. 다음 정규식을 사용해 16진수 문자열을 검색해 HTTP 응답 본문에서 명령을 추출합니다. "\{[0-9a-f-]{36}\}"|"[0-9a-f]{32}"|"[0-9a-f]{16}". 응답에 일치하는 부분 문자열은 16진수가 아닌 문자에 대해 필터링 되고 함께 결합되고 16진수로 디코딩 됩니다. 작동 모드에 따라 맬웨어는 스테가노그래피를 건너 뛰고 인코딩된 응답을 HTTP 응답 본문으로 보낼 수 있습니다.

XML GUID에 명령을 포함하는 C2 응답

수신된 C2 응답에서 첫 번째 DWORD 값은 메시지의 실제 크기를 나타냅니다. 이 값 바로 뒤에 선택적 정크 바이트가 추가된 메시지가 옵니다. 추출된 메시지는 메시지의 첫 번째 바이트를 사용하여 1바이트 XOR 디코딩 됩니다. 결과는 DEFLATE 압축 해제됩니다. 압축 해제된 데이터의 첫 번째 문자는 공백 문자로 구분된 선택적 추가 명령 인수와 함께 명령 ID에 매핑되는 ASCII 정수입니다. 지원되는 명령은 다음과 같습니다.

SUNBURST는 UTF-8 문자열과 추가된 4바이트 오류 DWORD 및 8바이트 사용자 ID로 구성된 프로토콜을 사용하여 C2 서버로 메시지를 다시 보냅니다. 길이가 10,000 이하인 메시지 페이로드는 SolarWinds에서 합법적으로 사용하는 OIP(Orion Improvement Program) 메시지와 유사한 JSON 문서로 변환됩니다. 10,000 바이트 보다 큰 메시지는 HTTP 요청 본문에 있는 그대로 전송됩니다. 가짜 OIP 문서에는 다음 필드가 포함됩니다.

• userId – 피해자 컴퓨터의 고유 식별자
• sessionID – 각 HTTP 스레드에 대해 새로운 임의 GUID를 저장합니다.
• steps – Timestamp , Index , EventType , EventName , DurationMs , Succeeded 및 Message 키를 포함하는 개체의 배열입니다.

JSON 키 이벤트 타입은 Orion 그리고 EventManager에 하드 코딩된 EventName에 하드코딩 됩니다. C2 서버로 보낼 인코딩된 메시지는 Base64로 인코딩된 임의 범위로 분할되고 steps 배열에 있는 개체의 Message 필드에 저장됩니다. 단계 배열의 모든 개체가 맬웨어 응답에 기여하는 것은 아닙니다. Timestamp 필드의 정수는 메시지 필드의 내용이 맬웨어 응답에 사용됨을 나타내기 위해 0x2 비트를 설정해야 합니다. 0x2 비트가 명확한 단계의 개체 Timestamp 필드에는 임의의 데이터가 포함되며 맬웨어 응답을 조합할 때 삭제됩니다. 이는 분석을 방해하려는 시도로 보입니다.

HTTP 콜 아웃은 OIP 프로토콜로 가장

작동 모드

DGA 섹션에서 설명했듯이 맬웨어에는 A 레코드가 확인하는 IP 블록과 CNAME 레코드 있는지에 따라 구성된 여러 작동 모드가 있습니다. 다음 모드는 맬웨어의 내부 작업을 제어합니다.

모든 값은 백도어 구성 키 ReportWatcherRetry에 기록됩니다. 조사자는 맬웨어 구성을 복구하고 이 구성 값을 검사하여 맬웨어의 마지막 실행 모드를 확인할 수 있습니다. 다음 전환은 IP 블록 범위가 실행 모드로 변환되는 방식을 제어합니다.

다음 다이어그램은 HTTP 기반 C2 비커닝이 시작되기 전에 SUNBURST의 DGA DNS 응답이 맬웨어를 제어하는 모드 전환 역할을 하는 방법에 대한 설명입니다.

다음은 일련의 DNS 확인이 맬웨어 모드를 전환하는 방법을 보여주는 주석이 달린 네트워크 로그입니다.

킬 스위치를 활성화하는 ImpLink IP 블록과 같은 경우에는 보안 연구원이 발견하지 못하도록 공격자가 범위를 특별히 선택했을 가능성이 있습니다. NetBios 및 특별한 NetBios IP 블록과 같은 경우 이러한 블록이 리졸브 되는 회사는 관련성이 없다고 볼 수 있습니다.

다음 다이어그램은 맬웨어 실행에 대한 전체 그림입니다. 내부적으로 SUNBURST는 앞서 설명한 것과 같이 모드 및 전환 세트를 사용합니다. 이러한 모드 및 전환의 이름은 의미가 없습니다. 악성 코드 작성자는 의도적으로 난독화의 한 형태로 선택했습니다.

이상으로 SUNBURST의 기술적 특징을 자세히 살펴보았습니다. 본 내용과 관련해 자주 묻는 질문은 다음 내용을 참조 바랍니다.

Q: 차단 목록에 있는 프로세스, 서비스, 드라이버를 실행하는 시스템은 안전합니까?

항상 그렇지는 않습니다. SUNBURST는 차단 목록에 있는 프로세스나 드라이버가 발견되면 무조건 종료되며 더 이상 검색되지 않을 때까지 실행되지 않습니다. 반면에 서비스는 시작 초기화를 제어하고 명시적으로 중지되지 않는 레지스트리 값을 설정하여 비활성화됩니다. 따라서 차단 목록에 있는 서비스는 맬웨어가 나중에 서비스 검사를 수행할 때 계속 실행될 수 있습니다. 이런 이유로 차단 목록에 있는 서비스가 실행되는 동안 피해자 시스템이 감염될 수 있습니다. 또한, SUNBURST는 서비스를 한 번만 비활성화하고 해당 구성을 업데이트하여 서비스를 비활성화한 된 것으로 표시합니다. 구성이 업데이트되면 서비스는 후속 실행 중에 차단 목록 항목으로 처리되지 않습니다.

Q: 하나의 DGA 인코딩을 다른 인코딩과 비교 관찰하면 사고 대응 정보를 얻을 수 있을까요?

어디를 보아야 하는지 힌트를 얻을 수 있습니다. 네트워크 로그에서 DGA 인코딩 변경 사항을 확인하는 것은 맬웨어가 New에서 Append 또는 Append에서 New로 전환했다는 힌트입니다. 이렇게 되면 HTTP C2가 시작될 수 있는 모드가 됩니다. 사고 대응은 DGA 인코딩에 전적으로 집중하는 대신 성공적으로 리졸브 되는 CNAME 레코드를 식별하는 데 중점을 두어야 합니다.

Q: "killswitch"는 무엇입니까?

SUNBURST를 비활성화하는 것입니다. 파이어아이는 특정 DNS 응답으로 인해 악성 코드가 자체적으로 비활성화되고 추가 네트워크 활동이 중지된다는 사실을 발견했습니다. 파이어아이는 GoDaddy 및 마이크로소프트 위협 인텔리전스 센터 도움으로 DGA 도메인을 리졸브 하는 데 사용되는 도메인의 경우 마이크로소프트가 제어하는 싱크 홀 서버를 가리키도록 재구성하였습니다.

Q: C2 통신이 발생하면 CNAME 레코드가 필요합니까?

CNAME 레코드는 HPPT C2 비커닝이 발생하는 데 필요한 C2 코디네이터가 최종 C2 서버를 지정하기 위해 제공합니다. C2 활동은 CNAME 레코드를 통해 제공된 도메인 이름을 통해 발행해야 합니다. 원시 IP를 통해 직접 발행할 수 없습니다. C2 비커닝을 초기화하기 위해 백도어는 먼저 특수 NetBios 서브넷 중 하나에 A 레코드 응답을 찾은 다음 CNAME 레코드를 수신하는, 것으로 예상합니다.

Q: DGA 도메인이 회사 도메인 이름으로 디코딩 되면 해당 회사가 침해를 당하는 건가요?

백도어나 "passive" 모드에 있을 때 피해자 액티브 디렉토리 도메인 이름을 포함하는 DGA 인코딩을 사용합니다. 즉, 백도어가 있는 모든 시스템이 DNS 서버에 연결을 시도했을 수 있으며, 공격자가 백도어를 활성화하여 활성 C2 통신을 시작할 수 있습니다. 대부분이 경우 이런 일이 발생하지 않았습니다. 단지 백도어 코드가 존재하고 활성화될 수 있다는 표시라 보면 됩니다.