AMSI(맬웨어 방지 검사 인터페이스)가 맬웨어 방어를 돕는 방법
AMSI(Windows 맬웨어 방지 검사 인터페이스)에 대한 간략안내는 다음을 참조하세요. AMSI(맬웨어 방지 검사 인터페이스)
애플리케이션 개발자로서 당신은 맬웨어 방어에 적극적으로 힘을 실어 줄 수 있습니다. 특히 동적 스크립트 기반 맬웨어와 같은 기존과 다른 방식의 사이버 공격으로부터 당신의 고객을 보호할 수 있습니다.
예를 들어 스크립팅이 가능한 애플리케이션이라고 가정해 보겠습니다. 즉, 임의의 스크립트를 수락하고 스크립팅 엔진을 통해 실행합니다. 스크립트를 스크립팅 엔진에 보낼 준비가 되면 애플리케이션에서 Windows AMSI API를 호출하여 콘텐츠 검사를 요청할 수 있습니다. 이렇게 하면 스크립트를 계속 실행하기 전에 스크립트가 악의적인지 여부를 안전하게 확인할 수 있습니다.
스크립트가 런타임에 생성된 경우에도 마찬가지입니다. 스크립트(악성 또는 기타)는 여러 번의 난독화 풀이 과정을 반복할 수 있습니다. 그러나 궁극적으로는 스크립팅 엔진에 난독 처리되지 않은 일반 코드를 제공해야 합니다. 그리고 그곳이 바로 AMSI API의 능력을 일깨우는 지점입니다.
다음은 당신의 애플리케이션이 "다른 애플리케이션" 상자 중 하나로 표현될때의 AMSI 아키텍처 일러스트입니다.
Windows AMSI 인터페이스가 실행중 입니다. 즉, 모든 애플리케이션에서 적용될 수 있고; 등록된 모든 맬웨어 방어 엔진은 제출된 콘텐츠를 검사할 수 있습니다.
스크립팅 엔진만으로 활용 영역을 제한할 필요또한 없습니다. 애플리케이션이 대화앱인 경우 인스턴트 메시지는 바이러스 검사 후 고객의 화면에 표시됩니다. 또는 당신의 소프트웨어가 플러그 인을 설치하기 전에 유효성을 검사하는 게임일 수도 있습니다. AMSI를 사용할 수 있는 기회와 시나리오는 무궁무진합니다.
AMSI 실사용 예시
AMSI가 실사용시 어떻게 작동되는지 살펴보도록 하겠습니다. 이 예제에서 Windows Defender가 AMSI API를 호출하는 애플리케이션인 상황을 가정 해 보겠습니다. 그러나 사용자 고유의 애플리케이션 내에서도 동일한 API를 활용할 수 있습니다.
다음은 XOR 인코딩 기술을 사용하여 본래의 의도를 숨기는 샘플 스크립트 입니다 (의도 유무해성 관계없음). 당 일러스트레이션에선 이 스크립트가 인터넷에서 다운로드되었다는 가정이 가능합니다.
보다 흥미로운 점은, 모니터할 실제 파일이 없도록 명령줄에서 수동으로 이 스크립트를 수동으로 입력할 수 있다는 것입니다. "파일리스 위협"이라고 알려진 형태와 흡사합니다. 디스크에서 파일을 스캔하는 것만큼 간단하지는 않습니다. 위협은 컴퓨터의 메모리에만 존재하는 백도어일 수 있습니다.
아래에서 우리는 Windows PowerShell에서 스크립트를 실행한 결과를 확인할 수 있습니다. 이런 복잡한 시나리오에서도 표준 AMSI 테스트 샘플 서명을 사용하는 것만으로도 Windows Defender가 AMSI 테스트 샘플을 찾아내는걸 볼 수 있습니다.
AMSI 와 JavaScript/VBA 통합
아래 워크플로 일러스트레이션은 다른 예시인 AMSI가 Microsoft Office 내에서 매크로 실행과 통합되었을때의 엔드 투 엔드 흐름을 설명합니다.
- 사용자는 난독 처리, 암호 보호 같은 기술을 사용하여 정적 바이러스 백신 소프트웨어 검사를 회피하는 (악성) 매크로가 포함된 문서를 수신합니다.
- 그런 다음 사용자가 (악성) 매크로가 포함된 문서를 엽니다. 문서가 제한된 보기에서 열리면 사용자는 편집 사용 을 클릭하여 제한된 보기를 종료할 수 있습니다.
- 사용자가 매크로 사용 을 클릭하여 매크로를 실행할 수 있도록 합니다.
- 매크로가 실행되면 VBA 런타임은 순환 버퍼를 사용하여 Win32, COM 및 VBA API 호출과 관련된 [1] 데이터 및 매개 변수를 기록합니다.
- 위험 수준이 높은 것으로 간주되는 특정 Win32 또는 COM API (트리거))[2]가 관찰되면 매크로 실행이 중지되고 순환 버퍼의 내용이 AMSI에 전달됩니다.
- 등록된 AMSI 맬웨어 방지 서비스 공급자는 매크로 동작이 악의적인지 여부를 나타내기 위해 판정을 내놓습니다.
- 동작이 악의적이 아닌 경우 매크로 실행이 계속 진행됩니다.
- 그렇지 않고 동작이 악의적인 경우 Microsoft Office는 경고 [3]에 대한 응답으로 세션을 닫고 AV는 파일을 격리할 수 있습니다.
무슨 의미인가요?
Windows의 기본 제공 스크립팅 호스트에 난독 처리 및 회피 기술을 사용하는 악성 소프트웨어는 자동으로 전보다 더 심도있게 검사되어 Windows 사용자에게 더욱 강화된 보안수준을 제공합니다.
애플리케이션 개발자는 애플리케이션이 Windows AMSI 인터페이스를 호출하게 하여 잠재적으로 악의적인 콘텐츠에 대한 추가 검사 및 분석을 활용하여 고객을 보호하는것을 고려할 수 있습니다.
바이러스 백신 소프트웨어 공급업체는 AMSI 인터페이스에 대한 지원을 고려할 수 있습니다. 이렇게 하면 엔진은 애플리케이션(Windows의 기본 제공 스크립팅 호스트 포함)이 잠재적으로 악의적인 것으로 간주하는 데이터에 대해 훨씬 더 심층적인 통찰력을 갖게 됩니다.
파일리스 위협에 대한 자세한 배경 정보
Windows AMSI가 방어시 도움을 줄수 있도록 설계된 파일리스 위협의 종류에 대한 자세한 배경 정보가 궁금할 수 있습니다. 이 섹션에서는 맬웨어 생태계에서 진행되고 있는 유서깊은 고양이-쥐 게임을 살펴보겠습니다.
PowerShell을 사용하는 예시를 들어보겠습니다. 하지만 VBScript, Perl, Python, Ruby 등 모든 동적 언어로 시연할 동일한 기술과 프로세스를 활용할 수 있습니다.
악성 PowerShell 스크립트의 예는 다음과 같습니다.
이 스크립트는 단순히 화면에 메시지를 작성하지만 맬웨어는 보통 더 사악합니다. 그러나 간단하게 서명을 입력하여 이를 감지할 수 있습니다. 예를 들어 서명은 사용자가 여는 어느 파일에서건 "Write-Host 'pwnd!'" 문자열을 검색할 수 있습니다. 대단합니다: 첫 맬웨어를 발견했습니다!
첫 번째 서명으로 발견 된 후이지만 맬웨어 작성자가 응답할겁니다. 그들은 이 예제와 같은 동적 스크립트를 만들어 응답합니다.
이 시나리오에서 맬웨어 작성자는 PowerShell 스크립트를 가장한 스트링을 만듭니다. 그러나 간단한 스트링 연속 기술을 사용하여 우리의 첫 서명을 무력화 합니다. 광고 기반 웹 페이지의 원본을 본 적이 있는 경우 광고 차단 소프트웨어를 회피하기 위해 이 기술이 사용되는 것을 자주 볼 수 있습니다.
마지막으로, 맬웨어 작성자는 이 연속된 스트링을 런타임에 작성되거나 생성된 스크립트를 평가하는 PowerShell의 메커니즘인 Invoke-Expression cmdlet에 전달합니다.
이에 대한 대응으로 맬웨어 방지 소프트웨어는 기본 언어 에뮬레이션을 수행하기 시작합니다. 예를 들어 두 스트링이 연속되어 있는 경우 해당 두 스트링의 연속성을 에뮬레이트한 결과에 우리의 서명을 실행합니다. 아쉽게도 언어는 스트링을 표현하고 연속할 수 있는 많은 방법이 있기 때문에 이는 매우 취약한 해결 방식입니다.
따라서 이 서명에 의해 발각된 후 맬웨어 작성자는 다음 예제와 같이 Base64에서 스크립트 콘텐츠를 인코딩하는 등 한층 더 복잡한 방법을 사용하게 됩니다.
리소스가 풍부하기 때문에 대부분의 맬웨어 방지 엔진은 Base64 디코딩 에뮬레이션도 구현합니다. 따라서 저희 역시 Base64 디코딩 에뮬레이션을 구현하므로, 우리가 한발 앞서가고 있습니다.
이에 대한 대응으로 맬웨어 작성자는 실행하는 스크립트의 간단한 XOR 인코딩 메커니즘과 같은 알고리즘 난독 처리를 활용합니다.
이 시점에서는 일반적으로 바이러스 백신 엔진이 에뮬레이트하거나 찾아내야할 내용이 없으므로 이 스크립트가 수행하는 작업을 반드시 감지하지는 않습니다. 그러나 우리는 난독 처리 및 인코딩 기술에 대한 서명작업을 시작할 수 있습니다. 실제로 이것이 스크립트 기반 맬웨어에 대항하는 서명의 대부분을 차지하는 종류입니다.
그러나 난독 분석기가 너무 성능이 저조해서 잘 작동하는 많은 착한 스크립트처럼 보인다면 어떨까요? 이런것을 위한 서명은 허용되지 않는 수준의 너무 많은 허위양성 값을 생성합니다. 다음은 너무 유순해 보여 자체적으로 감지하기 어려운 스테이저 스크립트 샘플입니다.
이 예제에서는 웹 페이지를 다운로드하고 일부 콘텐츠를 실행합니다. Visual Basic 스크립트에 해당될수 있는 항목은 다음과 같습니다.
두 예제에서 백신 엔진이 사용자가 여는 파일을 검사한다는 것은 상황을 더 악화시킵니다. 악의적인 콘텐츠가 메모리에만 있는 경우 공격이 감지되지 않을 수도 있습니다.
이 섹션에서는 기존의 전통적인 서명을 사용하는 검색의 제한 사항을 보여 줍니다. 그러나, 여러 번의 난독화 복구 과정을 거치면서도, 악의적인 스크립트는 궁극적으로 스크립팅 엔진에 난독 처리되지 않은 일반 코드를 제공해야 합니다. 위의 첫 번째 섹션에서 설명한 대로 이 시점에서 Windows의 기본 제공 스크립팅 호스트는 AMSI API를 호출하여 보호되지 않는 이 콘텐츠의 검사를 요청합니다. 당신의 애플리케이션도 동일한 작업을 수행할 수 있습니다.