FreeBSD Security Advisory FreeBSD-SA-16:14.openssh
FreeBSD Security Advisory FreeBSD-SA-16:15.sysarch
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This is a guest post submitted byIsmaelValenzuela.

Learning how adversaries compromise our systems and, more importantly, what are the techniques they use after the initial compromise is one of the activities that we, Incident Responders and Forensic/Malware investigators, dedicate most of our time to. As Lenny Zeltser students know, this typically involves reverse engineering the samples we find on the field by means of static and dynamic analysis, as for the majority of incidents we encounter, we end up examining a compiled Windows executable for which we have no source code.

However it seems that its not us only, fellow readers of the SANS ISC, that are huge fans of Mark Baggets posts and his Python classes. It turns out that malware authors are too! Why would attackers use Python to write malware? One of the reasons may be that it is easier to reuse blocks of code across different malware samples, and even platforms. As I always say, attackers are lazy too, and they will certainly reuse as much code as they can. However one of the most powerful reasons is probably the fact that AV detection rates on binaries built with Python packers (like Pyinstaller) tend to be quite low.

This method represents a huge opportunity for us though, since reversing these binaries is a straightforward exercise. Lets take as an example a binary that I first captured on the field a few months ago, and that it can still be seen today in different variants.

This binary is named servant.exe:

MD5 (servant.exe) = 9d39cfab575a162695386d7e518e3b5e

And was found under the users %APPDATA% directory on a system that exhibited some suspicious behavior, including connections to servers hosted in Turkey that already had a dubious reputation (I assume that youre looking at your outbound traffic too, right?)

Lets have a look at the binary now. A simple strings on servant.exe reveals the presence of many python related libraries:


Also, one of the indicators that caught my attention when looking at this system was that the file python27.dll (along with other .pyd and .dlls like sqlite3.dll) was unpacked on the same directory as the executable.

This is somewhat expected. If servant.exe is built with Python, it would require all the external binary modules to be in the same directory in order to run successfully. Alternatively, these files can be built also into the same self-contained binary, running without any external dependencies. One of the most popular tools used for this purpose is Pyinstaller, a tool that can freeze Python code into an executable, and that will prove very useful in our next step.

How difficult is to reverse (rather unpacking really) this sample? As difficult as using one of the command line tools included with the Pyinstaller package, pyi-archive_viewer. The following command allows you to interactively inspect the contents of an archive file built with Pyinstaller:

c:\Python27\Scriptspyi-archive_viewer.exe servant.exe

After listing all the contents of the archive, you can extract any file using the command x filename" />

The resultant file, servant-code, will contain the source code for this malware sample. Alternatively, there are several scripts available that will automatically extract all the files for us. One of them is ArchiveExtractor from @DhiruKholia https://github.com/kholia/exetractor-clone/blob/unstable/ArchiveExtractor.py. Its usage is simple too:

  $ python ArchiveExtractor.py servant.exe

In a matter of seconds, ArchiveExtractor will extract all files into the output folder. Easy, right?

Want to take a sneak peak at the source code? In the end its not everyday that we have the opportunity to see some original malware code!! You can find a copy of both the binary and the source for this sample on my GitHub account. Go through the code, analyze it, play with it (play safe!) and leave us your comments on this interesting piece of malware:

  • What does it do?
  • What is the attackers goal?
  • How does it communicate with the command and control infrastructure?
  • Does it use any obfuscation or encryption?
  • How does it achieve persistence?
  • How is having access to this code useful to you, as a defender?

Ill be analyzing some aspects of this sample in detail in coming diaries as we look at the opportunities we have as defenders to detect and react to the artifacts created both on the endpoint and on the network. In the meantime, have fun with it. Happy analysis!


Ismael Valenzuela, GSE #132 (@aboutsecurity)

SANS Instructor Incident Response/Digital Forensics Practice Manager at Intel Security (Foundstone Services)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Re: [FD] [CORE-2016-0005] - FreeBSD Kernel amd64_set_ldt Heap Overflow
[CORE-2016-0005] - FreeBSD Kernel amd64_set_ldt Heap Overflow

Enlarge / By default, Mac OS X allows applications to run only if they are signed with a valid certificate.

There are lots of ways to ensure the success of an advanced hacking operation. For a gang called Suckfly, one of the keys is having plenty of stolen code-signing certificates on hand to give its custom malware the appearance of legitimacy.

Since 2014, the group has used no fewer than nine separate signing certificates from nine separate companies to digitally sign its hacking wares, according to a blog post published Tuesday by security firm Symantec. Company researchers first came upon the group last year when they identified a brute-force server message-block scanner that was signed with a certificate belonging to a South Korean mobile software developer. When the researchers searched for other executable files that used the same credential, they eventually uncovered three more custom tools from the same group of black-hat hackers.

After tracing the hacking group's traffic to IP addresses in Chengdu, China, Symantec researchers ultimately identified a much larger collection of custom-developed backdoors and hacking tools that were signed by nine different certificates from nine different companies. Curiously, all nine of the compromised companies are located within a few miles of each other in Seoul. While the physical proximity is suspicious, the researchers ultimately speculated the certificate thefts weren't the result of any physical attack and were most likely the result of the owners being infected with malware that had the ability to search for and extract signing certificates.

Read 5 remaining paragraphs | Comments

[security bulletin] HPSBGN03558 rev.1 - ArcSight ESM and ESM Express, Remote Disclosure of Sensitive Information
[SECURITY] [DSA 3518-1] spip security update
Reflected Cross-Site Scripting (XSS) Vulnerability in Litecart CMS
Internet Storm Center Infocon Status