Cool EK

[Kahu Security] Kore Exploit Kit

카후 시큐리티에서 최근에 공개한 Kore Exploit Kit 입니다. 이전에 사쿠라 킷과 비슷하게 디코딩을 하지만 각각의 Value 마다 디코딩 되는 위치가 다릅니다. 국내에서는 아직 등장하지 않는것으로 추정 되지만 사쿠라 킷처럼 국내에도 등장 할 수 있는 가능성이 있으므로 적어 놓습니다. 추후 샘플이 발견시 자세히 글을 쓰도록 하겠습니다.

링크 : http://www.kahusecurity.com/2013/kore-exploit-kit/

Recently, a reader passed on to me a very active TDS link that redirected users to one of four exploit packs. These packs led to some form of ransomware being installed on the victim’s machine. Analysis of these packs have been covered elsewhere but I wanted to document the analysis here in case there are changes. Since there’s a lot to go through, I’ll only cover the important bits.

Exploit Pack #1
hxxp://cats.dogamusement. com/wp-admin/board.php?connect=17
hxxp://cats.dogamusement. com/wp-admin/5BB9I
hxxp://cats.dogamusement. com/wp-admin/cCLP4ceJ
hxxp://cooks.lustrength. com/backend.php?cars=697&macos=66&main=4&deals=45&energy=171&crime=272&site=479&left=555&click=645&outdoors=571

Here’s the landing page which shows calls to two applets:

If you de-base64 the value of the first applet’s parameter, you’ll end up with this which is the same as the second applet. The values are encoded which we’ll come back to in a bit.

Both applets are similar so we’ll just look at one of them. Here’s the routine to convert those above encoded values.

So the long parameter value above:

505c5c58601b596260615f525b5461551b505c5a1c4f4e5058525b511b5d555d2c504e5f602a2
32624135a4e505c602a2323135a4e565b2a211351524e59602a212213525b525f54662a1e241e
13505f565a522a1f241f13605661522a21242613595253612a2222221350595650582a232122

Becomes:

cooks.lustrength. com/backend.php?cars=697&macos=66&main=4&deals=45&energy=171&crime=272&site=479&left=555&click=645

And the value for the “BzIkzF” parameter:

5c6261515c5c5f60

Becomes:

outdoors

This value then becomes the XOR key to decrypt the payload file. This is not a straightforward XOR decryption, however. It uses some math to determine whether to skip the decryption step for a particular byte which you can see below. To decode the payload, you would need to replicate the routine using Python, Perl, Javascript, etc.

This exploit pack is “Sweet Orange”.

Exploit Pack #2
hxxp://blog.jiwok. com/blog/?p=5579
hxxp://blog.jiwok. com/blog/9xa.nfs
hxxp://blog.jiwok. com/blog/qte.nfs
hxxp://blog.jiwok. com/blog/contacts.asp
hxxp://blog.jiwok. com/download.asp?p=1

The call to the Java exploit is broken into a couple of webpages. The top file calls the second and so on until the Java applet on the contacts.asp page loads. The landing page contains the string “LOLOLO”.

The applet contains this routine which decodes the value from the landing page:

If you enter those into Converter’s Secret Decoder Ring, you can see that this is the URL to the payload:

The payload is obfuscated and here’s the decryption routine which uses the key found in the applet, “binkey”, to decrypt it.

I believe some are calling this an updated version of RedKit and it very well may be but it seems like it took a step backwards. This is too simple and amateurish. Maybe we should call this the “LOL Exploit Pack” since it refers to the text on the landing page and makes me laugh when I think it’s RedKit v2.

Exploit Pack #3
hxxp://21sdtrnbrdbre8.flnet. org/j6SM5F9fIkJKjySnhXID19a
hxxp://21sdtrnbrdbre8.flnet. org/jquery.js
hxxp://21sdtrnbrdbre8.flnet. org/j6SM5F9fIkJKjySnhXID19a2.zip
hxxp://21sdtrnbrdbre8.flnet. org/j6SM5F9fIkJKjySnhXID19a?id=2&text=958

Here’s the landing page:

Here’s what the base64-encoded string looks like after being decoded. Note the parameter value is a string of encoded hex characters.

First thing I noticed when the applet was opened was an embedded object. Also, its degree of obfuscation is higher than most. You can see two arguments are being passed to a decryption routine.

This function here pulls in the string of encoded hex characters from the landing page which I mention above.

This is its internal decryption routine. First it takes the first argument passed to it and XORs it with the array of decimal values from the top and then XORs it again with the second argument.

We can replicate that in Converter by making two passes. And here’s the result which is semicolon-delimited (note the second value).

And finally this routine takes the embedded object and deXORs it using the key, sSvWQqw63DtE, that we got from the prior step. The payload then gets written to disk and executed.

This exploit pack is being referred to as “Sibhost” but thanks to an excellent researcher (you know who you are), a more fitting and accurate name is “Kore Exploit Kit”.

Exploit Pack #4
The fourth exploit pack the TDS redirected users to looks like this:

hxxp://evoquninu. pl/gnjamrr1xab0zq9jvyu
hxxp://evoquninu. pl/c1fb4f5b7.jar
hxxp://evoquninu. pl/40de2a7ced9.jar
hxxp://evoquninu. pl/b9b47e2ea8c9
hxxp://ihifumiku. pl/FlP-QnhpaGt1LHFsaWhpZnVAaWt1LnBsaWg=

The landing page is simply a mess:

After deobfuscating the script, it looks more readable. Here, we can make out calls to two applets:

The Java applets are nearly the same as Kore EK but contain a little more obfuscation. The routine you see here is the internal decoder which is identical to Kore. If you look at the class files on the left, you’ll see an embedded object at the bottom. This object gets deobfuscated and executed as an .exe file in the same way as the above kit.

The good folks over at EmergingThreats have been calling this “FlimKit”. The striking similarities between Kore EK and Flimkit makes me think there’s a strong connection.

암호화된 쉘코드에서 다운로드 받는 악성 URL 찾는 방법

최근 언론사 및 학교 등등의 웹페이지가 변조되어서 난독화된 악성 스크립트가 삽입된 경우가 많습니다.

해당 스크립트는 취약점에 의해서 쉘코드(ShellCode)를 실행하여 악성 URL에서 파일을 다운로드 및 실행함으로 악성코드를 감염시킵니다.

여기서 사용된 쉘코드는 보통 16진수 유니코드로 작성되었습니다.

자바 스크립트에서는 16진수 유니코드를 "%u" 다음에 16진수가 덧붙이는 방식으로 표현합니다. 이렇게 표현된 쉘코드는 XOR 연산 방식으로 암호화되었습니다. 이점은 악성 코드 대응하는 입장에서 신속히 악성 URL을 확인할 수 없게 합니다.

따라서 이번 글에서는 XOR 연산 방식으로 암호화된 16진수 유니코드 쉘코드에서 악성 URL을 찾는 방법을 소개합니다.

먼저 방법을 소개하고 자바 스크립트로 구현해보겠습니다.

원리는 간단합니다. 쉘코드에는 악성 URL이 하드 코딩되어 있습니다. 말그대로 http://악성url 이런형식으로 쉘코드에 들어있다는 얘기입니다.

따라서 0x00 ~ 0xFF 까지 값과 각 바이너리(2byte)를 XOR 연산해준 값의 전체에서 http 문자열이 존재하는지 찾는 것입니다.
예를 들어, 0xBF로 XOR 연산하였을 때 해당 쉘코드에서 http 문자열이 발견되면, 그 값이 암호화 키값이 되는것입니다.

이제부터 소개된 방법을 자바스크립트로 작성하면서 보여주겠습니다.

1) "%u%" 형식으로 표기된 쉘코드가 있습니다.

2) 해당 쉘코드를 실제로 사용되는 코드로 변경해야합니다.
즉, "%u"를 제거하고 리틀-엔디안 방식으로 표기해야합니다.
예를 들면, "%uE1D9" -> "D9E1" 이렇게 변경되어야 합니다.

3) 리틀-엔디안 방식으로 표기된 쉘코드의 각 바이너리 2Byte를 0x00 ~ 0xFF 값과 XOR 연산한 다음 http 문자열이 존재하는지 찾습니다. 찾으면 악성 URL을 출력해줍니다. 관련 코드는 다음과 같습니다.

decode = function(shellcode, key) // 해당 함수에서 xor 연산한다.
{
s = "";
for (var i=0; i<shellcode.length; i+=2){   // 문자 2자리씩 For 루프가 돈다.
str = code.charAt(i) + code.charAt(i+1);  // 문자 2자리씩 가져와서 str 변수에 담는다.
c = String.fromCharCode(parseInt(shellcode, 16) ^ key); // 문자열 2자리씩 가져와서 유니코드를 일반 문자열로 변환한다.
s += c;     // 변환된 문자열을 s 변수에 담는다.
}
return s;}

findKey = function(code) // 해당 함수에서 XOR 암호화에 사용된 키를 찾는다.
{
for(var key = 0 ; key <= 255 ; key++) // 0x00 ~ 0xFF 값과 XOR 연산을 한다.
{
sh = escape(decode(shellcode, key));
if(isKeyMatch(sh)) // 어떤 키 값에 http 문자열이 존재하는지 찾는다.
{
return key;
}
}
}

isKeyMatch = function(shellcode) { // 해당 함수는 쉘코드에서 http 문자열 존재 여부를 확인한다.
re = /http%3A\/{0,3}[\/0-9.\-A-Za-z]+\+/gm;
url = re.test(shellcode); // 정규표현식을 사용하여 쉘코드에서 http 문자열 존재 여부를 확인한다.
}

urlFilter = function (shellcode, key) { // 해당 함수는 쉘코드에서 http 문자열을 파싱한다.
re = /http%3A\/{0,3}[\/0-9.\-A-Za-z]+\+/gm;
url = escape(decode(key, shellcode));
url = unescape(re.exec(url));
return url;
}

위에 작성된 코드는 다음과 같은 순서로 동작합니다.

urlFilter -> findKey -> decode -> isKeyMatch

실제로 소개된 쉘코드의 악성 URL을 다음과 같이 확인할 수 있었습니다.

그럼 해당 글을 읽어주셔서 감사합니다.