DLL 사이드로딩이란?

About this offer

DLL 사이드로딩이란? 1. DLL 사이드로딩을 정리하게 된 이유 이번에 EDR/MDR을 활용한 위협 행위 분석 및 대응 프로젝트를 진행하면서 여러 악성코드 샘플을 분석해볼 기회가 있었다. 프로젝트에서는 팀원들이 각자 샘플 하나씩을 맡아 동적 분석과 EDR 로그 분석을 진행했고, 나는 그중 USB를 통해 확산되는 코인마이너 악성코드를 담당했다. 분석하면서 여러 행위를 확인했는데, 그중 하나가 DLL Side-Loading(DLL 사이드로딩) 이었다. 정상 프로그램을 이용해 악성 DLL을 실행할 수 있다는 특징 때문에 다양한 공격에서 활용되고 있었고, 한 번 제대로 정리해두면 좋겠다는 생각이 들었다. 이번 글에서는 당시 분석했던 내용을 바탕으로 DLL 사이드로딩이 어떤 방식으로 동작하는지, 그리고 분석할 때 어떤 부분을 확인해야 하는지 정리해보려고 한다. 2. DLL이란? DLL은 Dynamic Link Library 의 약자로, 프로그램에서 사용할 함수나 리소스를 모아놓은 파일이다. Windows 프로그램은 필요한 기능을 전부 실행 파일 안에 넣기보다 DLL로 분리해두고, 실행 중 필요한 DLL을 불러와 사용하는 경우가 많다. 예를 들면 아래와 같은 형태다. program.exe ├─ A.dll ├─ B.dll └─ C.dll 프로그램이 DLL을 사용하려면 해당 DLL을 찾아 메모리에 올리는 과정이 필요한데, DLL 사이드로딩은 이 과정을 악용한다. 3. DLL 사이드로딩이란? DLL 사이드로딩은 정상 실행 파일이 원래 불러와야 할 DLL 대신, 공격자가 준비한 DLL을 불러오도록 만드는 기법 이다. 예를 들어 program.exe 가 실행될 때 example.dll 이 필요한 경우, 정상적인 경우라면 아래처럼 정상 DLL을 불러온다. program.exe ↓ 정상 example.dll 그런데 공격자가 프로그램이 DLL을 찾는 위치에 같은 이름의 악성 DLL을 넣어두면, 프로그램이 그 DLL을 불러올 수 있다. 특정 디렉터리 ├─ program.exe ← 정상 실행 파일 └─ example.dll ← 악성 DLL 이 경우 program.exe 자체에는 문제가 없어도, 실행 과정에서 악성 example.dll 이 로드되면서 악성 코드가 실행된다. 정상 EXE + 악성 DLL ↓ 악성 코드 실행 DLL 사이드로딩이 헷갈리는 이유도 이 부분이다. 실행된 EXE만 보면 정상 파일이고, 전자서명도 정상일 수 있다. 그래서 파일 하나만 보고 판단하면 이상 징후를 놓칠 수 있다. 결국 중요한 건 실행 파일 자체가 정상인지보다 어디에서 실행됐는지, 어떤 DLL을 불러왔는지를 같이 보는 것 이다. 4. DLL 사이드로딩은 왜 가능한가? 프로그램이 DLL을 불러올 때 항상 DLL의 전체 경로를 직접 지정하는 것은 아니다. 경우에 따라서는 DLL 이름만 지정하고, Windows가 정해진 방식에 따라 해당 DLL을 찾는다. 공격자는 이 점을 이용해 정상 프로그램이 찾을 만한 이름의 DLL을 만들어 정상 EXE와 같은 위치에 두기도 한다. 공격자가 준비한 디렉터리 │ ├─ 정상 program.exe └─ 악성 example.dll 이 상태에서 프로그램이 실행되면 공격자가 준비한 DLL이 함께 로드될 수 있다. 다만 같은 폴더에 DLL이 있다고 해서 무조건 DLL 사이드로딩이 발생하는 것은 아니다. 프로그램이 DLL을 어떤 방식으로 불러오는지에 따라 달라지기 때문에 실제 분석에서는 해당 프로세스가 어떤 DLL을 어떤 경로에서 로드했는지 를 직접 확인해야 한다. 5. 실제 분석한 샘플에서의 DLL 사이드로딩 먼저 전체 공격 흐름을 보면, DLL 사이드로딩은 초기 스크립트 실행 이후 정상 printui.exe 와 악성 DLL을 위장 경로에 배치하고 실행하는 과정에서 발생했다. 분석한 샘플의 전체 공격 흐름 이 중 DLL 사이드로딩이 발생한 부분을 자세히 보면, 정상 printui.exe 를 위장 경로에 복사한 뒤 악성 파일을 printui.dll 로 변경하고 printui.exe 를 실행하는 흐름을 확인할 수 있었다. printui.exe 와 printui.dll 이 배치되고 실행되는 과정 이 과정에서 사용된 printui.exe 는 Microsoft에서 서명한 정상 Windows 실행 파일이었다. Process Explorer에서 확인한 printui.exe 의 정상 서명 정보 그런데 실행 위치를 확인해보니 일반적인 System32 경로가 아니라, C:\Windows \System32 처럼 후행 공백이 포함된 위장 경로에 파일이 복사돼 있었다. 같은 디렉터리에는 printui.dll 도 함께 존재했다. 위장 디렉터리 │ ├─ printui.exe ← 정상 실행 파일 └─ printui.dll ← 악성 DLL 이후 printui.exe 가 실행되면서 같은 위치의 printui.dll 을 로드했고, 여기서부터 악성 행위가 이어졌다. printui.exe 실행 ↓ printui.dll 로드 ↓ DLL Side-Loading ↓ 후속 악성 행위 printui.exe 자체만 보면 Microsoft에서 서명된 정상 파일이기 때문에 크게 이상해 보이지 않았다. 하지만 실행 경로를 확인해보니 정상 System32가 아닌 위장 경로에서 실행되고 있었고, 같은 위치의 악성 printui.dll 을 로드한 뒤 추가 행위까지 이어지고 있었다. 즉, printui.exe 하나만 봤을 때보다 비정상 실행 경로 + 악성 DLL + 실제 DLL 로드 를 함께 봐야 전체 흐름을 파악할 수 있었다. 6. DLL 사이드로딩 분석 시 확인한 부분 Procmon에서 전체 실행 흐름을 확인해보면 DLL 사이드로딩 앞뒤로 여러 이벤트가 연결되어 있었다. Procmon에서 확인한 DLL 사이드로딩 전후의 프로세스 흐름 1) 실행 경로 이번 샘플에서는 printui.exe 가 정상 System32가 아닌 위장 경로에서 실행되고 있었기 때문에, 먼저 실행 경로를 확인했다. 정상 Windows 파일이라도 평소와 다른 경로에서 실행됐다면 확인해볼 필요가 있다. 특히 아래와 같은 위치에서 실행된다면 한 번 더 확인해볼 필요가 있다. Temp AppData Downloads 이동식 저장장치 정상 시스템 경로와 비슷하게 만든 폴더 파일 이름이 정상이어도 실행 경로까지 같이 확인해야 한다. 2) 로드된 DLL 다음으로 실제 어떤 DLL을 불러왔는지 확인했다. 특히 아래와 같은 부분을 같이 확인했다. 실행 파일과 같은 비정상 경로의 DLL 서명되지 않은 DLL 정상 DLL과 이름은 같지만 경로나 해시가 다른 경우 실행 직전에 생성된 DLL 여기서 중요한 건 같은 폴더에 DLL이 있다는 사실만으로 판단하지 않는 것이다. 실제로 해당 프로세스가 그 DLL을 로드했는지까지 확인해야 한다. 3) DLL 생성·변경 시점 DLL이 언제 생겼는지도 같이 봤다. 예를 들어 아래처럼 짧은 시간 안에 이어진다면 흐름을 의심해볼 수 있다. 스크립트 실행 ↓ 정상 printui.exe 복사 ↓ 악성 파일 복사 ↓ printui.dll로 이름 변경 ↓ printui.exe 실행 ↓ 악성 DLL 로드 EDR에서 이런 이벤트를 시간 순서대로 따라가면, 개별 이벤트만 봤을 때는 놓치기 쉬운 흐름을 확인할 수 있다. 4) 이후 행위 DLL 사이드로딩 자체가 끝은 아니다. 내가 분석한 샘플에서도 이후 추가 파일 생성, 서비스 등록, 예약 작업 등록 같은 행위가 이어졌다. 그래서 DLL 로드까지만 보고 끝내기보다는 이후 어떤 프로세스가 실행됐고, 어떤 설정이 추가됐는지까지 같이 확인하는 게 필요했다. 7. 마무리 이번 프로젝트에서 DLL 사이드로딩을 분석하면서 가장 인상 깊었던 건 정상 파일도 공격에 이용될 수 있다는 점 이었다. printui.exe 자체는 정상 파일이었지만, 실행된 위치와 함께 로드한 DLL을 같이 보면 정상적인 실행이라고 보기 어려웠다. 결국 DLL 사이드로딩을 볼 때는 파일 하나만 정상/악성으로 나누기보다, 어디에서 실행됐는지, 어떤 DLL을 불러왔는지, 그리고 이후 어떤 행위가 이어졌는지를 함께 보는 게 중요했다. 이번 분석을 통해 EDR 로그에서도 개별 이벤트 하나만 보기보다, 여러 이벤트를 시간 순서와 프로세스 관계로 연결해서 보는 게 더 중요하다는 점을 다시 느꼈다.