Lastline v. Evil Keylogger -- UPDATED with Lastline's analysis 5-29-14

Python Keylogger

Violent Python Book Last semester I used the book "Violent Python" in my Advanced Ethical Hacking class, and I was amazed at how effective these techniques were at defeating antivirus software.

As a demonstration for my Layer One talk, I made this thing:

EVIL APT TOOL

This thing is absurdly simple, 64 lines of Python, half of it ASCII art, and the rest copied and pasted from a 4-year-old keylogger and the Pastebin API demo code. I have done absolutely nothing to obfuscate or conceal this keylogger's code or actions. It captures keystrokes and posts them on Pastebin. That seems mighty suspicious to me, but not to any antivirus product I can find.

Another sample, which used a Metasploit payload, also defeated every AV product I tested, but Lastline correctly detected it. And today, Lastline gave me a 90-day free trial of their product, so I tested it against two versions of the EVIL APT TOOL.

It failed utterly, as shown below.

Lastline v. Evil (Private Version)

First I tested the keylogger that posts keystrokes onto my own server.

As you can see below, this file is seen as "Benign":

Lastline v. Evil (Public Version)

Then I tested the keylogger that posts keystrokes to Pastebin, which I published for everyone to use.

The result is the same--this file is seen as "Benign".

Conclusion

I think Lastline needs to adjust their testing process. If posting keystrokes on Pastebin isn't suspicious, what is?

Appeal to FireEye

I'd sure like to test other modern anti-APT products with this stuff. If anyone using FireEye, or anything else that claims to protect you, would like to test it, you can get it here:

EVIL APT TOOL

Please send me a screen shot of the results, either by Twitter @sambowne or email to sbowne@ccsf.edu


Lastline's Analysis of my Python Keylogger

We found your Python keylogger very interesting - but of course I was a bit disappointed that we didn't catch it right away :) After looking through the sample, we were able to find out quite quickly what was the issue, and came up with the analysis you can see at the end of this mail.

I was looking through your recent tweets and was excited to see that you seem to be testing quite a lot of different sandboxes and functionalities, and Lastline seems to be coming out decently well :) Getting people in touch with our technology was exactly the reason we started giving out trial accounts, so I'm happy to see that people are picking up on this idea!

When I looked at your blog-post http://samsclass.info/124/proj14/lastline-v-python.htm , on the other hand, it sounded somewhat different.

Do you think it would be possible you link back to our post and/or amend your conclusion with the new findings? I think this way we can give both posts a lot more hits from interested readers.

I would love to get your feedback on the text below or to discuss what you think on this topic in general. As you can see, we reference your code, page, and name a few times. Please let me know if you don't feel comfortable with this, I'm happy to adapt the text accordingly.

Thank you,
Clemens

Analyzing an "Ultra-Advanced APT Tool" Using High-Resolution Dynamic Analysis

Earlier this week, Sam Bowne (@sambowne) posted a nice example of how to write a simple keylogger in a few lines of Python. He used this code to evaluate a few sandboxes, including Lastline. The full code can be found on Sam's blog, but the essential lines can be seen in the following snippet of code:

As one can see, the code uses the Windows API for registering callbacks to invoke on key-press events, as we describe in our recent blog-post on the internals of keylogging malware. The recorded key-press events are collected and sent to the attacker (in this case, they are uploaded to pastebin) as soon as the return key (or enter key with key-code 13) is pressed (see the highlighted code regions).

High Resolution Dynamic Analysis

As we described in the previous blog-post, the Lastline high-resolution dynamic analysis engine recognizes when programs under analysis attempt to steal sensitive information of the user using keylogging activity.

Below, one can see the report of an analysis run in our system. The analysis sandbox identifies that the program is hooking the key-press events and instruments a virtual user to start behaving in a way that could trigger interesting behavior in the malware program.

Analysis report overview - Keylogging behavior detected

Analysis subject overview highlighting interesting keyboard activity in Analysis subject 2 Since this sample is not looking for any specific data (such as credit card information or account credentials), our system uses data that seems generally attractive to an attacker as can be seen in the screenshot below.

Report showing captured keyboard data

Network traffic showing upload of the stolen data

"Evil APT Tool"

An attentive reader might have noticed that the code shown above slightly differs from the code posted by @sambowne originally.

The main difference is that we decided to make the "evil APT tool" (as Sam calls it) slightly more realistic/real-world applicable:

The original program assumes users will follow instructions (and start the tool using the return key) and confirm inputs using the same return key. However, most of today's interfaces (such as web-forms in browsers, or GUI applications) do not make much use of this key any longer, but instead use "submit" buttons that can be triggered using the mouse or many other ways through the keyboard. Therefore, our modified program simply uploads data whenever enough has been captured, as shown in the highlighted code regions.

At this point, we should address that Sam originally posted that the Lastline system fails to identify this sort of attack (which inspired us to look into the sample and write this short post). The main difference between the two outcomes is the modified return-key behavior mentioned above and not requiring user-confirmation to start the actual payload. Sam's proof-of-concept code illustrates nicely how to write the keylogger in Python, but a real-world attack would not make these assumption. We acknowledge, however, that we should identify this sort of activity and extend our virtual user to follow the instructions accordingly.

Conclusion

Sam did a great job showing how easy it has become for attackers to quietly steal an unsuspecting victims personal data. Traditional sandboxes fail at analyzing this type of threat despite that many of today's advanced malware families contain this sort of behavior. The Lastline high-resolution malware analysis engine, on the other hand, correctly identifies and detects this sort of behavior as shown in the example analysis report.

My Reply to Lastline

I'm happy to add this information to my post, and further talks. But many AV products can detect this malware when you omit this line at the start:

x = raw_input(" ")

That line is there to cause a time delay. Delaying the malicious action for a few seconds fools Norton's heuristic checks, and perhaps Lastline's too.

Reply from Lastline

yeah, that makes sense. We already have various delay avoidance in place (and are extending them all them time as we come across new ways malware does this).

Did you see that we actually mention this in the post as well? I just found that it's somewhat unrealistic, as it not only delays the activity, but completely disables it until the user clicks RETURN.

My Reply to Lastline

It may be unrealistic; I'm not sure. I think it's just a matter of social engineering; tell people they are winnng a free iPad and tell them they have to press Enter to get it.

Anyway, I added your analysis here; please let me know if there's anything further you want to add to it.

http://samsclass.info/124/proj14/lastline-v-python.htm

Thanks for your response! I'm very impressed with the quality of your product and the way you stand behind it.


Originally posted 11:51 am 5-27-14 by Sam Bowne
Analysis by LastLine added 4:49 PM 5-29-14