옷.. 저에게 첫 트랙백을 날려주셔서 감사합니다.
세상에는 정말 뛰어난 사람이 무척 많은것 같습니다.
chp님처럼 독학으로 알아내시는 분들도 계시고, ,,
저는 남이 발견한것을 따라하는 따라쟁이일뿐이지요.. ㅋㅋ

까마구이님.. 반갑습니다.
운영체제에 대해서 조예가 깊으신 분이 허접한 제
홈피에 와주셔서 영광입니다 ^^
RSS리더에 추가해서 자주 방문할게요~

debuglab.com 스터디 잘 참석하고 있습니다
제가 절대적을 도움을 받고 있지요 :-)

dll 인젝 션 때문에 요즘 골치가 아픕니다

Dll 인젝션은 세 가지 방법중 하나로 보통 시도되던데요...

CreateRemoteThread-LoadLibrary 방법과, SetWindowsHookEx를 이용한 방법, 그리고 SetThreadContext를 이용해서 스레드의 레지스터를 강제로 바꾸는 방법도 있습니다.

우선,CreateRemoteThread()로 생성한 스레드는 BaseThreadStartThunk() 내장 함수가 실행될 것이고,

SetWindowsHookEx()로 Dll을 주입하는 경우에는 ClientLoadLibrary() 내장 함수가 호출됩니다.

위 두 방법은 유저 모드에서 차단할 수 있지만, 아쉽게도 컨텍스트를 이용한 것은 커널 레벨 후킹을 필요로 할 것 같네요... :-(

네.. 멋지게 막을수있는 방법...
생각중이에요..

생각해보니, SetThreadConext와 Code Injection을 이용한 DLL 인젝션은 LoadLibraryA, LoadLibraryW, NTDLL.LdrLoadDll 과 같은 핵심적인 함수를 후킹한 후 caller address가 Private Memory인지 체크하는 방법( VirtualQuery() 이용 )이 있을 수 있겠네요...^^;

커널단으로 내려가면 좋긴 하지만... 기존 보안 제품과 충돌할 여지가 있어서 좀 꺼려지는 편이죠;;
말씀해주신 방법은 디버거와 dll 속이는걸 제외하고 후킹으로 전부 차단할 수 있습니다. 디버거를 이용한 것은 anti-debugger 루틴을 삽입하면 되고(단 이 루틴을 제거하게 되면 계속 공방이 발생하겠죠? ^^), dll을 속이는것은 글쎄요...(애시당초 윈도우 dll만 쓰면 문제는 없을거라고 봅니다. 그리고 이렇게 되면 다른 app에서도 문제가 생길 가능성이 농후하죠.)
물론 말씀하신 것처럼 커널단으로 내려가면 못하는 것이 거의 없죠... 보안 제품과 충돌하는게 안좋을 뿐이지...
그래서 유저 모드에서 막는겁니다. (그리고 커널단에서 막는다고 하면 공격자도 커널단으로 내려가면 뚫릴수밖에 없고요...(참고적으로 Rustock 루트킷은 커널 레벨에서 KeAttachProcess/KeInsertQueueApc로 dll 인젝션을 하기 때문에 핸들을 막는것은 의미가 없습니다.) 그래서 완전 방어는 없다고 봅니다.)

그리고 핸들을 못 구하게 막는다고 하셨는데, 그렇게 할 경우에는 SetWindowsHookEx를 이용해서 dll을 주입시키면 손쉽게 우회됩니다.(뿐만 아니라 직접 KeAttachProcess/KeInsertQueueApc를 이용해서 주입해도 뚫리고요.) (직접 실험해보세요.)
이런 경우 까지 고려하면, SetWindowsHookEx API인 NtUserSetWindowsHookExAW를 서비스 or 코드를 후킹하는 것보다는 유저 모드에서 깔끔하게 막는것이 더 좋을 것 같기도 하네요.

위에서 말한것 말고도 AppInit_DLLs를 이용하거나 등등 방법은 정말 다양합니다. 애초에 ntoskrnl.exe를 패치해서 프로세스 생성시 바로 집어넣어버리는 기법도 존재할 수 있고요.

전에 Dll 인젝션을 거의 완벽하게 차단하고자 해서 간단하게 만들어놓은 DLL이 있습니다. 제 블로그에 있으니 한번 가서 구경해보세요.

전역일경우를 생각안했네요..ㅎㄷㄷ 그림님 블로그에 좋은 정보가 엄청 많군요.. 많이 배워갑니다~