[Agent Tesla 분석 (1)] .NET 분석, 난독화 해제하기(Deobfucator)

그동안의 게시글에서는 C/C++로 작성된 PE 바이너리를 분석했었습니다.

이번에는 처음으로 .NET 악성코드를 포스팅해보겠습니다.

샘플 해시(SHA256)는 ed22dd68fd9923411084acc6dc9a2db1673a2aab14842a78329b4f5bb8453215입니다.

 

 

 

○ 샘플 정보 수집

먼저 패킹 및 난독화 확인을 위해 DiE를 사용해보니 .NET Reactor로 프로텍트 되어 있는 것으로 보입니다.

DiE를 통한 샘플 정보 수집

 

 

dnSpy로도 확인해보면,

dnSpy 첫 화면을 통해 얻은 정보는 다음과 같습니다.

• 5개의 임베디드된 리소스
• Entry point (WaitCallb.Filter.GlobalValueFilter.MapVisitor)
• Type References에서 확인할 수 있는 정보들: class, enumeration, structure, delegation
• 어셈블리 이름: WaitCallb
• 모듈 이름: WaitCallb.exe
• 2개의 모듈

 

 

가볍게 얻을 수 있는 정보들을 대강 확인했고 이제 EP로 진입해보겠습니다.

○ (stage 1) Entry Point  분석

Entry point 메서드: MapVistior

 

EP 메서드에서는 4개의 메서드를 확인해볼 수 있고 변수 num에 따라 실행되는 메서드가 달라집니다.

처음 설정되어 있는 num이 4이므로 case 4의 Application.EnableVisualStyles()가 실행됩니다.

EnableVisualStyles 메서드

 

EnableVisualStyles 메서드는 자체 로드된 어셈블리의 전체 경로를 가져옵니다. 또한 마지막에 Application.EnableVisualStylesInternal()을 호출합니다.

EnableVisualStyleInternal 메서드

 

이를 통해 EnableVisualStylesInternal 첫 번째 인수는 어셈블리 파일 이름이고,
두 번째 인수인 네이티브 리소스 ID가 101인 것과,
UnsafeNativeMethods 클래스의 CreateActivationContext 메서드를 호출하고 있다는 것을 알 수 있습니다.

 

• UnsafeNativeMethods 클래스
  • 네이티브 메서드를 호출하고 액세스하는데 사용
    
    
  • 네이티브 코드와의 상호작용을 위한 내부 클래스
    
    
  • .NET에서는 안전한 코드(safe code)와 안전하지 않은 코드(unsafe code)가 구분됩니다. 네이티브 코드는 unmanaged code로, 관리되지 않아 안전하지 않은 코드로 분류됩니다. managed code인 .NET 코드에서 네이티브 코드를 불안전한 방법이더라도 호출하기 위해 사용되는 클래스입니다.
    
    
• CreateActivationContext 메서드
  • 애플리케이션의 실행 컨텍스트를 생성하는데 사용되는 API
    
    
  • 애플리케이션 실행과 관련된 정보를 설정하고 실행 환경을 준비하는데 중요한 역할을 합니다. 일반적으로 COM 객체나 애플리케이션의 활성화 컨텍스트를 설정하는데 사용됩니다.
    
    
  • COM 또는 .NET 환경에서 애플리케이션 실행을 위한 매니페스트 및 어셈블리와 관련된 데이터를 설정합니다.

 

 

CreateActivationContext 메서드를 통해 구체적인 DLL 모듈 또는 COM 객체 인스턴스 로드를 위한 정보를 저장하기 위한 데이터 구조체를 설정하고 있습니다.

이렇게 EnableVisualStyles 메서드가 호출되고 나면, num 변수는 3으로 설정되고 2개의 메서드 Application.SetCompatibleTextRenderingDefault()와 RecordParam.SelectConfig()가 호출됩니다.

MapVistior 메서드에서 호출되는 SetCompatibleTextRenderingDefault와 SelectConfig 메서드

 

 

이를 끝으로 swtich 문이 종료되면 Application.Run(new ReponseListState())를 호출합니다.

MapVistior 메서드에서 Run에 의해 호출되는 ReponseListState

ReponseListState 메서드

 

ReponseListState 메서드도 switch-case문과 상태 변수 num을 통해 실행될 코드를 결정합니다.

처음 설정된 num=6을 기반으로 가장 먼저 RecordParam.SelectConfig()와 ReponseListState.PostProcess() 메서드를 호출합니다.

 

ReponseListState에서 호출되는 SelectConfig 및 PostProcess 메서드

SelectConfig 메서드는 아무 작업 하지 않고 PostProcess는 false만 반환해줍니다. 그리고 num은 2로 설정됩니다.

 

case 2는 IL_0C 레이블로 이동합니다.

ReponseListState 메서드의 IL_0C

 

IL_0C에서는 ctor, CompareVisitor, PostProcess 메서드가 호출되고 있습니다.

 

그중 CompareVisitor 메서드에 들어가보면 258번째 줄에서 this.Text = "Form 1" 라는 명령어를 발견할 수 있습니다.

CompareVisitor 메서드의 Text 속성 호출

 

여기서 "Text" 속성은 접근자/변경자(accessor/mutator)와 연결되어 있고, 아래 그림의 292번째 줄에서 다른 접근자/변경자로 오버라이드됩니다.

 

• 접근자(accessor)
  • 클래스 내부의 필드 값을 읽는 메서드로, 필드의 값을 외부에서 조회할 수 있도록 제공하는 메서드
  • 클래스의 private 필드에 대해 외부에서 값을 읽을 수 있게 해줌
  • get 접근자를 사용하여 정의되며 getter라고도 불림
    
    
• 변경자(mutator)
  • 클래스 내부의 필드 값을 수정하는 메서드로, 필드의 값을 변경할 수 있도록 제공하는 메서드
  • 클래스의 private 필드에 대해 외부에서 값을 변경할 수 있게 해줌
  • set 접근자를 사용하여 정의되며 setter라고도 불림
    
    
• 오버라이드(override)
  • 부모 클래스에서 정의된 메서드를 자식 클래스에서 재정의하는 것
  • 같은 메서드 호출에 대해 자식 클래스마다 다르게 동작하게 할 수 있는 다형성(polymorphism)을 지원하고, 코드 유연성을 높여줌

 

오버라이딩된 접근자 내부에서 호출된 ResetVistior 메서드

 

오버라이딩된 접근자 내부에서는 ResetVisitor 메서드가 호출됩니다.

 

 

ResetVisitor 메서드: 리소스 로드

ResetVisitor()가 호출되면 5로 세팅된 상태 변수에 의해 case 5가 실행되어 먼저ResourceManager 클래스가 인스턴스화되고, (case 3) Vargo 리소스가 array 변수에 로드됩니다. 해당 array 변수에는 로드되어 실행될 인코딩된 .NET 모듈을 포함하고 있습니다. 또한 text 변수에 XOR 키를 설정하고 case 2로 이동하여 리소스 크기(num2)를 설정합니다.

 

로드된 리소스(.NET 모듈)와 설정한 키, 리소스 크기를 기반으로 디코딩 과정을 수행합니다.

ResetVisitor 메서드: 디코딩 과정

 

 

이제 실행하여 생성되는 모듈을 확인해보겠습니다.

해당 메서드 과정을 모두 마치면 array 변수에 디코딩된, 4D5A(MZ)로 시작하는 바이트들이 저장됩니다.

디코딩된 PE 바이너리

 

 

그리고 모듈 목록을 확인해보면 새로운 모듈 SharpStructures가 로드되었습니다.

로드된 모듈 SharpStructures

 

 

추출된 모듈을 DiE를 통해 확인해보면 Smart Assembly Obfuscator로 난독화되어 있음을 확인할 수 있습니다.

DiE로 확인한 SharpStructures

 

 

또한 dnSpy를 통해서 유니코드 표기(\u)와 SmartAssembly 관련 속성들이 확인된 것으로도 난독화되었음을 알 수 있습니다.

dnSpy를 통한 SharpStructures

 

 

 

○ (stage 2) SharpStructures 분석

- 난독화 해제하여 로드하기

추출한 SharpStructures 모듈을 난독화 해제해서 실행되던 .NET 바이너리에 돌아가서 메모리에 올려보겠습니다.

해당 모듈을 de4dot을 통해 .NET 바이너리의 난독화를 해제합니다.

de4dot을 통한 난독화 해제

 

 

그리고 다시 실행해서 Assembly.Load(arrary) (370번째 줄)가 실행되기 전에서 멈추고, array 배열에 대해 memory 탭(Memory 1)을 선택합니다. 

변수 array 메모리에서 보기

메모리에서의 변수 array 데이터

 

난독화 해제한 바이너리를 복사하여 해당 메모리 위치에 덮어써주면, 난독화 해제된 모듈로 교체해주는 작업 완료입니다.

 

 

GetMethod() 함수를 통해 SharpSturctures 모듈의 InvalidCast 메서드를 가져오려고 시도하고 있으니 해당 메서드 시작 부분에 breakpoint를 걸고 실행해보겠습니다. 

FuillName 속성에서 얻은 InvalidCast 메서드 정보

SharpStructures.Sorting.SortHelper 클래스의 InvalidCast 메서드

 

 

Invoke 메서드를 통해 InvalidCast 메서드로 전환을 수행합니다.

InvalidCast 메서드로 전환을 수행

InvalidCast 메서드로 전환됨

 

 

이제 전환된 모듈을 분석해보겠습니다.

 

- SharpStructures(stage2) 분석하기

InvalidCast 메서드에서 많이 호출되는 Class0 클래스를 분석해보겠습니다.

 

smethod_0과 smethod_1 메서드

smethod_0과 smethod_1은 배열 조작(manipulating)하는 동일한 메서드입니다.

 

 

smethod_2와 smethod_4 메서드

smethod_2와 smethod_4은 메서드를 호출(Invoke)하는 동일 메서드입니다.

 

 

smethod_3과 smethod_6 메서드

smethod_3과 smethod_6은 어셈블리를 로드(Assembly.Load)하는 동일 메서드입니다.

 

 

smethod_5와 smethod_7 메서드

smethod_5와 smethod_7은 문자열을 생성하는 동일 메서드입니다.

 

총 8개의 메서드가 있지만 동일한 코드의 메서드가 중복되어 있기 때문에 기능적으로는 4가지가 존재합니다.

 

 

다시 InvalidCast 메서드로 돌아오면 25번째 줄에 DemandedResources 메서드를 호출하고 있습니다.

DemandedResources 메서드

DemandedResources 메서드는 ResourcesManager 클래스를 인스턴스화하여 리소스에 접근하고 smethod_5에서 생성되어 주어진 리소스 이름을 읽습니다. 그리고 리소스 파일에서 해당 리소스 객체를 반환합니다.

 

 

또한 InvalidCast 메서드 26번째 줄의 ConstructionResponse 메서드를 살펴보면

ConstructionResponse 메서드

 

smethod_1에서 바이트 배열 bytes을 받아 빅 엔디안 순서 형식(UTF-16)으로 덮어씁니다. 그리고 bytes의 마지막 바이트와 숫자 112를 사용하여 XOR 연산을 수행합니다.

새로 할당한 바이트 배열 array에 두 번의 XOR 연산을 수행한 bytes를 저장합니다. 결과 바이트 배열 array의 크기를 조정한 후 최종 배열을 반환합니다.

ConstructionResponse 메서드는 XOR 연산을 통한 디코딩을 수행하고 있습니다.

 

 

InvalidCast 메서드 내용을 정리해보겠습니다.

InvalidCast 메서드

 

[line 26]

리소스에서 바이트 시퀀스를 읽어오고(smethod_5), 그 리소스의 이름은 smethod_1 반환값으로 주어집니다.
ConstructionResponse 메서드를 통해 디코딩하면 결과 배열의 콘텐츠는 또 하나의 모듈입니다.

[line 27]

또한 결과 배열은 smethod_6(Assembly.Load)에 의해 로드됩니다.
모든 유형은 로드된 어셈블리에 의해 반환되고 그들 중 하나가 선택됩니다.

[line 28-29]

GetTypes()로 반환된 타입에 대해 모든 public 메서드가 GetMethods()를 사용해 반환되고 그 중 하나가 선택됩니다.

[line 30]

마지막으로 선택된 메서드는 smethod_4(Invoke)를 통해 호출됩니다.

 

 

InvalidCast 메서드 통해서 새로운 모듈을 로드하는 것 같습니다. 아까랑 똑같이 실행하면서 따라가보니 byte_에 PE 바이너리가 로드되었습니다.

byte_ 배열에 로드된 PE 바이너리

 

한 번 더 실행하여 smethod_6(Assembly.Load) 메서드로 로드하면 모듈 목록에서도 새 모듈을 볼 수 있습니다.

로드된 DotNetZipAdditionalPlatforms 모듈

 

2번째로 로드된 DotNetZipAdditionalPlatforms 모듈의 클래스 및 메서드의 이름이 각 LajJueXX7RvrQwTLPl.XcuCxUwDbNNwbx89AI, RrRUhxJmfM인 것과, DiE를 통해 확인한 .NET Reactor 사용으로 보아 해당 모듈은 난독화되어 있습니다.

DiE로 본 DotNetZipAdditionalPlatforms 모듈

 

 

 

포스팅이 너무 길어져서 다음번에 이어서 분석해보겠습니다.

 

 

Ref. "Malware Analysis Series(MAS) – Article 4", Alexandre Borges