CrowdStrike

Empowering Information Sharing: Release of pyNSSFClient

2013-01-23T18:23:00.004-05:00

Pat Winkler, Sr. Research Engineer

Malware is one of the common tools used by adversaries, whether they're getting a foothold in your network, moving laterally through your systems, or exfiltrating sensitive data. Having access to new malware samples can be key to understanding what trespassers are doing on your systems and how they got there. By gathering many thousands of new samples a day, we can see the evolution of these tools as well as investigate how they work.

One of the lesser-known facts about the computer security business is that vendors exchange malware samples with each other, often through mutual sharing arrangements. Unfortunately, despite this practice existing for many years, there isn't a lot of standardization on how this process should happen. One of the attempts to solve many of the problems related to sample sharing is the Norman Sample Sharing Framework (NSSF), obviously written by folks at Norman. In order to interact with companies using this framework, you must have an NSSF client that supports the NSSF API. Norman has links to their PHP implementation (which has both client and server code) as well as a Perl implementation written by Mario Bono at Ikarus Security Software. We use Python extensively at CrowdStrike for our automated malware analysis work, so we have written a Python implementation of the NSSF client code and made the source code available at our GitHub at: https://github.com/CrowdStrike/pyNSSFClient.

Assuming you have credentials to access an NSSF server (or have set up one yourself), this code allows you to simply interact with that server to get lists of new file hashes and/or download samples.
The key functionality is all within the SampleShare class in sample_share.py. This class has basic command line support for testing purposes, which can be used to get lists of hashes or download samples.

You may notice that we use Doxygen-style code documentation instead of Python docs. We use a variety of languages at CrowdStrike, and Doxygen lets us have a common code documentation format and tooling.

Feel free to fork the code on Github and add your contributions. Or send us your resume and work on it at CrowdStrike -- we're hiring.

I/O You Own: Windows 8 Update

2013-01-09T14:18:00.000-05:00

Aaron LeMasters, Sr. Research Engineer

At SyScan 2012 last year, I debuted research on how to bypass the Operating System’s normal input/output (I/O) disk driver path and use the crash dump driver stack (i.e., “crash dump I/O path”) to read the master boot record (MBR). This technique subverted the TDL4 rootkit and would be effective against any traditional I/O hooking rootkit/malware.

I recently presented an overhauled version of this presentation at BSides Jackson in Jackson, MS. For this updated presentation, I focused on interesting new changes to the Windows 8 crash dump stack and hinted at a new technique to manipulate this crash dump stack. This blog post will cover technical details of the new Windows 8 technique.

Background: Original Bypass Technique

The Windows operating system maintains two separate I/O paths to the boot device – one for normal system operation, the normal I/O path, which consists of components such as the file system, volume manager, partition manager, and so on; and a second path, the crash dump I/O path, which is used exclusively for writing a crash dump file to the boot device when the system crashes and for writing hibernation data to the hiberfil.sys file when the system hibernates. These two I/O paths are illustrated in Figure 1 below.

Each of these paths consists of a series of layered drivers (or “driver stack”) that pass I/O requests back and forth to complete operations. The crash dump driver stack consists of a dump port driver, a dump miniport driver, one or more crash dump filter drivers, and a special driver named crashdmp.sys that serves as a crash state manager for the kernel (technically, it lives outside the driver stack).

As shown in Figure 1, the crash dump driver stack is almost a mirror copy of the lowest portion of the normal path’s driver stack, with a few twists. The crash dump port driver, provided by Microsoft as part of the operating system, is a special copy of the normal I/O path’s disk port driver, altered to completely bypass the normal I/O path during a system crash. The crash dump miniport driver, provided by the manufacturer, is pre-programmed to operate in conjunction with this special dump port driver in a restricted crash dump environment. These two low-level drivers, in conjunction with the kernel and the crashdmp.sys driver, work together to operate the crash dump I/O path completely separate from the normal I/O path.

Only the operating system uses this special “backdoor” path to disk, but I discovered it was possible to use the crash dump driver stack to arbitrarily read or write to disk via a driver that implements a bypass technique. Despite the fact that this bypass technique worked, it involved a few “hackish” feats that made the proof of concept driver less than ideal. As discussed in the SyScan presentation and accompanying whitepaper, the general steps in the technique are:

Identify the Crash Dump Port and Miniport Drivers – Walk the list of memory-resident kernel modules to locate the dump port and miniport drivers. Once located, call their entry points with special arguments to initialize them.
Get Boot Device Information – Send special IO control codes to the normal I/O path drivers to get information about the boot disk, which we will use when sending our own I/O request.
Find StartIo() or DispatchCrb()Routines – Scan the dump port driver’s text section for “magic bytes” that allow us to identify these routines that carry out I/O in crash dump mode.
Find and Initialize the Dump Port Driver’s Device Extension – Locate a pointer to this dump port driver’s internal structure and initialize some fields in it to set up our I/O request.
Instantiate a SCSI/IDE Request Block – Using the boot device information obtained in Step 2, fill in a SCSI_REQUEST_BLOCK (SRB) or IDE_REQUEST_BLOCK (IRB) structure that instructs the disk to read 512 bytes from the first sector on disk.
6. Call StartIo() or DispatchCrb() – Pass the SRB/IRB from Step 5 to the I/O routine.

This technique worked sufficiently well for SCSI transport devices in Windows 2000 through Windows 7, but it could cause stability issues. A similar version of the technique tailored to IDE drives was able to transmit I/O requests, but the requests were not successfully completed. Since this was just a side project at the time, I was not able to devote the time and resources necessary to debug the issues with this technique.

Windows 8 has introduced drastic changes to both the crashdmp.sys driver and the dump port driver itself (a very rare alteration) that break the original technique described above and render many aspects of it unnecessary. The changes in Windows 8 integrate a read capability into the crash dump stack that can be used in a stable way. Before discussing a new technique to use these features, it is necessary to briefly explore some of the important changes to the crash dump stack in Windows 8.

New Crash Dump Features in Windows 8

To decrease system startup time, Windows 8 introduces a new feature called “hybrid boot.” Hybrid boot is a startup method for quickly resuming the operating system after the system goes into sleep/hibernation mode. It is a hybrid between traditional cold boot and resuming from hibernation.

As opposed to normal hibernation, where all user sessions are hibernated to disk, hybrid boot only hibernates the system session. This means that all system drivers, services, plug-and-play devices, and so on, don’t have to be shut down and restarted, providing a much faster resume operation. If you’d like to learn more about hybrid boot, check out this article on the Building Windows 8 blog.

So what does this have to do with the crash dump stack? As previously mentioned, the crash dump stack is responsible not only for writing a crash dump file when a system error occurs, but it also has the task of managing the hibernation file (hiberfil.sys) in conjunction with the kernel and the power manager. Therefore, any changes to how the system hibernates (such as the new hybrid boot feature) will require modifications to the crash dump stack drivers.

Along with extensive changes to the kernel itself and the power manager, the dump port driver and the crashdmp.sys driver were modified to support this new hybrid boot feature. Most importantly, both drivers contain new functions that issue read requests to the boot device when the system is resuming from hibernation. The power manager uses these new read routines when resuming from hibernation to restore hiber context information:

Nt!PopRestoreHiberContext()

Nt!PopRequestRead()

Crashdmp.sys!CrashdmpReadRoutine()

Diskdump.sys!DiskDumpRead()

Prior to Windows 8, the hibernation context information was not retrieved from disk in this manner. Rather, the power manager handled the entire process. Integrating this aspect of the new hybrid boot feature at the dump port driver level results in an extremely fast resume operation.

For the purposes of this research and proof of concept driver, this is an important departure from the crash dump stack in prior versions of Windows, which was only capable of writing to disk (either a crash dump file or hiberfil.sys). In Windows 8, it can now read from disk as well, consequently obsoleting the original bypass technique previously described.

So, how do we use the new read feature in the Windows 8 dump port driver for our own purposes? Keep reading.

Toward a Windows 8 Proof of Concept

With the new read capabilities in the dump stack, Microsoft had to expose it to driver developers so that things like whole-disk encryption software would work properly. Whole-disk encryption software typically includes a crash dump filter driver so that when a dump file is written to disk, the software has an opportunity to encrypt its contents.

Now that data can be additionally read by the crash dump mechanism, Microsoft extended their existing crash dump filter callback API to include a read routine callback. Unfortunately, such a callback has no control over what data is actually being read, so using this approach for our purposes would not work.

The other option is to use one of the new read routines directly, whose prototypes are shown below:

Crashdmp.sys!CrashdmpReadRoutine(Type, Offset, Mdl)
Diskdump.sys!DumpRead(Type, Offset, Mdl)

As it turns out, the first function is simply a wrapper around the second one with additional code to update the dump state context, which we don’t care about. Therefore, the best option seems to be to attempt to use the second function. Further investigation of this function reveals it is also a wrapper around another internal dump port driver function, DiskDumpIoIssue():

DiskDumpIoIssue() kindly handles all of the aspects of issuing I/O requests to the dump miniport, which the original technique had to hack prior to Windows 8:

Initializing a SCSI_REQUEST_BLOCK (SRB) structure to describe the request
Mapping an MDL to describe the SRB data buffer, if required
Calling the dump port internal I/O function, StartIo(), which calls the dump miniport HwStartIo() routine to actually program the device for the operation
Polling to wait on result
Retrying failed/pending requests

As is the case with the bypass technique, it is still necessary to do some initialization prior to calling this new function. In addition to initializing the dump stack drivers ourselves, the dump port driver’s device extension must be located and initialized. Since this structure changed significantly in Windows 8, it had to be manually reverse engineered and the initialization techniques changed accordingly.

At this point, there is enough information to piece together the steps required to use the DiskDumpIoIssue() function in Windows 8 (some of the concepts mentioned here will be covered in detail shortly):

Locate and initialize the crash dump miniport driver
Locate, patch and initialize the crash dump port driver
Locate the dump port driver’s new read routine, DiskDumpIoIssue()
Disable the normal I/O path
Call DiskDumpIoIssue() with a disk offset and an MDL that describes the buffer to store the result.
Enable the normal I/O path
Unpatch the dump port driver

Putting the System into Crash Dump Mode

As previously mentioned, the system operates in a restricted environment (“crash dump mode”) when a crash is in progress. This environment, setup by the kernel after a bug check has occurred, severely restricts what operations can be performed on the system and what features are available. In effect, the system is reduced to a single processor running one uninterruptible thread at the highest possible interrupt request level (IRQL). Any I/O that might take place is done synchronously and interrupts are disabled. There are documented mechanisms available to replicate this environment, the most useful of which is Interprocessor Interrupt (IPI) broadcasts. Each of the steps mentioned above that interact with a driver in the crash dump stack must momentarily “enable” crash dump mode using an IPI broadcast. This includes calling the dump port and miniport DriverEntry() routines when initializing the drivers and just before sending the I/O request to the dump port driver.

Disabling/Re-enabling the Normal I/O Path

An issue not addressed in the original bypass technique, using two separate driver stacks that operate on the same underlying hardware is problematic at best, since doing so will almost certainly lead to race conditions. Furthermore, arbitrarily initiating I/O through the crash dump stack will trash any I/O already in progress on the device (initiated from the normal I/O path), which can have a range of possible outcomes, from working without issue to deadlocking the system. Fortunately, it is possible to send a special I/O control code to the normal I/O path port driver, instructing it to flush and lock its internal queue. This mechanism makes it possible to halt the normal I/O path, after which, the system can be placed into restricted crash dump mode and I/O can be issued through the crash dump I/O path.

Patching the Dump Port Driver

Another challenge to overcome was the integration of new hibernation features into the dump port driver. Specifically, the dump port driver’s DriverEntry() calls an internal function MarkHiberBootPhase(), which marks certain memory pages to be included in the hibernation file via nt!PoSetHiberRange().

Unfortunately there is no way to sidestep this function call from within the dump port driver’s DriverEntry(), and attempts to trick the operating system into thinking it is in a hibernation state before calling it failed (it can almost be accomplished via nt!ZwPowerInformation() with the SystemReserveHiberFile information type).

The issue here is that a special hibernation context structure internal to the kernel must be allocated before any hiber functions (such as nt!PoSetHiberRange()) are called, and the only way to trigger this allocation is to actually set the system into a hibernation state by calling nt!NtSetSystemPowerState(). This is not an acceptable solution, as we want to make as few changes to the system as possible.

There are two ways to get around this unfortunate restriction. The first option is to not call DriverEntry() at all. This means more upfront work before it is possible to send I/O to the dump port driver. It also means the solution is less portable to future operating systems, because of the need to use static structure offsets which are painstakingly cherry-picked from reverse engineering various drivers.

The other option is to simply patch the dump port driver’s DriverEntry() function to disable the call to MarkHiberBootPhase(). Despite my abhorrence of anything patching/hooking related (I can see all of my teammates cringing in disgust), this turned out to be a simple 0x15-byte patch that could be immediately restored after sending the I/O request. And since the system is manually forced into crash dump mode (single processor, single thread, uninterruptible, synchronous I/O, high IRQL), there are no synchronization issues.

But just to be sure it was impractical, I actually tried sidestepping DriverEntry()completely. It turned into a half day’s exercise of shoving pointers into various fields in an undocumented device extension structure to learn their purposes, in between system crashes. Clearly the tedium and uncertainty involved in that approach were not worth it, so patching out the call made the most sense.

Conclusion

This blog post has covered a new technique to read arbitrary data from a storage device using the new crash dump stack in Windows 8, which includes an inherent read capability. Several other critical steps necessary for a reliable proof of concept were discussed, such as crash dump mode and toggling the normal I/O path.

I would like to give special thanks to Alex Ionescu for his assistance in making this research possible and to my colleagues on the review team for taking the time to critique this post.

I/O, You Own: Regaining Control of Your Disk in the Presence of Bootkits from CrowdStrike

HTTP iframe Injecting Linux Rootkit

2012-11-19T03:00:00.000-05:00

Georg Wicherski, Senior Security Researcher

On Tuesday, November 13, 2012, a previously unknown Linux rootkit was posted to the Full Disclosure mailing list by an anonymous victim. The rootkit was discovered on a web server that added an unknown iframe into any HTTP response sent by the web server.

The victim has recovered the rootkit kernel module file and attached it to the mailing list post, asking for any information on this threat. Until today, nobody has replied on this email thread. CrowdStrike has performed a brief static analysis of the kernel module in question, and these are our results. Our results seem to be in line with Kaspersky's findings; they also already added detection.

Key Findings

The rootkit at hand seems to be the next step in iframe injecting cyber crime operations, driving traffic to exploit kits. It could also be used in a Waterhole attack to conduct a targeted attack against a a specific target audience without leaving much forensic trail.
It appears that this is not a modification of a publicly available rootkit. It seems that this is contract work of an intermediate programmer with no extensive kernel experience.
Based on the Tools, Techniques, and Procedures employed and some background information we cannot publicly disclose, a Russia-based attacker is likely.

Functional Overview

The kernel module in question has been compiled for a kernel with the version string 2.6.32-5. The -5 suffix is indicative of a distribution-specific kernel release. Indeed, a quick Google search reveals that the latest Debian squeeze kernel has the version number 2.6.32-5.

The module furthermore exports symbol names for all functions and global variables found in the module, apparently not declaring any private symbol as static in the sources. In consequence, some dead code is left within the module: the linker can't determine whether any other kernel module might want to access any of those dead-but-public functions, and subsequently it can't remove them.

The module performs 6 different tasks during start-up:

Resolution of a series of private kernel symbols using a present System.map file or the kernel's run-time export of all private symbols through /proc/kallsyms
Initialization of the process and file hiding components using both inline hooks and direct kernel object manipulation
Creating an initial HTTP injection configuration and installing the inline function hook to hijack TCP connection contents
Starting a thread responsible for updating the injection configuration from a command and control server (hereafter "C2")
Ensuring persistence of the rootkit by making sure the kernel module is loaded at system startup
Hiding the kernel module itself using direct kernel object manipulation

The remainder of this blog post describes those tasks and the components they initialize in detail.

Ghetto Private Symbol Resolution

The rootkit hijacks multiple private kernel functions and global variables that don't have public and exported symbols. To obtain the private addresses of these symbols, the rootkit contains code to scan files containing a list of addresses and private symbols. Those System.map called files are usually installed together with a kernel image in most Linux distributions. Alternatively, the kernel exports a pseudo-file with the same syntax via procfs at /proc/kallsyms to userland.

The code contains the function search_export_var that receives one parameter: the symbol name to resolve. This function merely wraps around the sub-function search_method_export_var that receives an integer parameter describing the method to use for symbol resolution and the symbol name. It first attempts method 0 and then method 1 if the previous attempt failed.

search_method_export_var then is a simple mapping of 1 to search_method_exec_command or 2 to search_method_find_in_file. Any other method input will fail. The attentive reader will notice that therefore the rootkit will always attempt to resolve symbols using search_method_exec_command, because method 0 is not understood by search_method_export_var and 2 is never supplied as input.

search_method_exec_command uses the pseudo-file /proc/kallsyms to retrieve a list of all symbols. Instead of accessing these symbols directly, it creates a usermode helper process with the command line "/bin/bash", "-c", "cat /proc/kallsyms > /.kallsyms_tmp" to dump the symbol list into a temporary file in the root directory. It then uses a function shared with search_method_find_in_file to parse this text representation of addresses and symbols for the desired symbol. Due to the layout of the call graph, this will happen for every symbol to be resolved.

Symbol Resolution Method Identifier Confusion

The alternative (but effectively dead) function search_method_find_in_file is, unfortunately, as ugly. Despite the fact that the System.map file is a regular file that could be read without executing a usermode helper process, the author found an ingenious way to use one anyway.

Since multiple kernels might be installed on the same system, the System.map file(s) (generated at kernel build time) include the kernel version as a suffix. Instead of using a kernel API to determine the currently running kernel version, the rootkit starts another usermode helper process executing "/bin/bash", "-c", "uname -r > /.kernel_version_tmp". uname is a userland helper program that displays descriptive kernel and system information.

So instead of using the kernel version this module is built for at build time (it's hardcoded in other places, as we'll see later), or at least just calling the same system call that uname uses to obtain the kernel version, they start a userland program and redirect its output into a temporary file.

The kernel version obtained in this way is then appended to the System.map filename so that the correct file can be opened. Recall that this code path is never taken due to a mistake at another place, though.

When starting up, the rootkit first iterates over a 13-element array of fixed-length, 0-padded symbol names and resolves them using the previously described functions. The name of the symbol and its address are then inserted into a linked list. Once a symbol's address needs to be used, the code iterates over this linked list, searching for the right symbol and returning its address.

Berserk Inline Code Hooking

To hook private functions that are called without indirection (e.g., through a function pointer), the rootkit employs inline code hooking. In order to hook a function, the rootkit simply overwrites the start of the function with an e9 byte. This is the opcode for a jmp rel32 instruction, which, as its only operand, has 4 bytes relative offset to jump to.

The rootkit, however, calculates an 8-byte or 64-bit offset in a stack buffer and then copies 19 bytes (8 bytes offset, 11 bytes unitialized) behind the e9 opcode into the target function. By pure chance the jump still works, because amd64 is a little endian architecture, so the high extra 4 bytes offset are simply ignored.

To facilitate proper unhooking at unload time, the rootkit saves the original 5 bytes of function start (note that this would be the correct jmp rel32 instruction length) into a linked list. However, since in total 19 bytes have been overwritten, unloading can't work properly:

.text:000000000000A32E       xor     eax, eax
.text:000000000000A330       mov     ecx, 0Ch
.text:000000000000A335       mov     rdi, rbx
.text:000000000000A338       rep stosd
.text:000000000000A33A       mov     rsi, rbp
.text:000000000000A33D       lea     rdi, [rbx+8]
.text:000000000000A341       lea     rdx, [rbx+20h]
.text:000000000000A345       mov     cl, 5
.text:000000000000A347       rep movsd
.text:000000000000A349       mov     [rbx], rbp
.text:000000000000A34C       mov     esi, 14h
.text:000000000000A351       mov     rdi, rbp
.text:000000000000A354       mov     rax, cs:splice_func_list
.text:000000000000A35B       mov     [rax+8], rdx
.text:000000000000A35F       mov     [rbx+20h], rax
.text:000000000000A363       mov     qword ptr [rbx+28h], offset splice_func_list
.text:000000000000A36B       mov     cs:splice_func_list, rdx
.text:000000000000A372       call    set_addr_rw_range
.text:000000000000A377       lea     rax, [rbp+1]
.text:000000000000A37B       mov     byte ptr [rbp+0], 0E9h
.text:000000000000A37F       lea     rsi, [rsp+38h+target_offset]
.text:000000000000A384       mov     ecx, 19
.text:000000000000A389       mov     rdi, rax
.text:000000000000A38C       rep movsb
.text:000000000000A38E       mov     rdi, rax

To support read-only mapped code, the rootkit contains page-table manipulation code. Since the rootkit holds the global kernel lock while installing an inline hook, it could simply have abused the write-protect-enable-bit in cr0 for the sake of simplicity, though.

Since the rootkit trashes the hooked function beyond repair and is not considering instruction boundaries, it can never call the original function again (a feature that most inline hooking engines normally posses). Instead, the hooked functions have all been duplicated (one function even twice) in the sourcecode of the rootkit.

File and Would-be Process Hiding

Unlike many other rootkits, this rootkit has a rather involved logic for hiding files. Most public Linux rootkits define a static secret and hide all files and directories, where this secret is part of the full file or directory name. This rootkit maintains a linked list of file or directory names to hide, and it hides them only if the containing directory is called "/" or "sound" (the parent directory of temporary files and the module file, respectively).

The actual hiding is done by inline hooking the vfs_readdir function that's called for enumerating directory contents. The replacement of that function checks if the enumerated directory's name is either "/" or "sound" as explained above.

If that's the case, the function provides an alternative function pointer to the normally used filldir or filldir64 functions. This alternative implementation checks the linked list of file names to hide and will remove the entry if it matches.

Interestingly, it will also check a linked list of process names to hide, and it will hide the entry if it matches, too. That, however, doesn't make sense, since the actual directory name to hide would be the process id. Also, the parent directory for that would be "/proc", which isn't one of the parent directories filtered. Therefore, the process hiding doesn't work at all:

Improperly Hidden Kernel Threads

The list of hidden files is:

sysctl.conf
module_init.ko (the actual rootkit filename)
zzzzzz_write_command_in_file
zzzzzz_command_http_inject_for_module_init

The real module's name gets added to the linked list of file names to hide by the module hiding code.

Interestingly, the rootkit also contains a list of parent path names to hide files within. However, this list isn't used by the code:

/usr/local/hide/first_hide_file
/ah34df94987sdfgDR6JH51J9a9rh191jq97811

Since only directory listing entries are being hidden but access to those files is not intercepted, it's still possible to access the files when an absolute path is specified.

Command and Control Client

As part of module initialization, the rootkit starts a thread that connects to a single C2 server. The IP address in question is part of a range registered to Hetzner, a big German root server and co-location provider.

The rootkit uses the public ksocket library to establish TCP connections directly from the Linux kernel. After the connection has been successfully initiated, the rootkit speaks a simple custom protocol with the server. This very simple protocol consists of a 1224-byte blob sent by the rootkit to the server as an authentication secret. The blob is generated from "encrypting" 1224 null bytes with a 128-byte static password, the C2 address it's talking to, and, interestingly, an IP address registered to Zattoo Networks in Zurich, Switzerland, that is not otherwise used throughout the code.

C2 Connection Attempt

The server is then expected to respond with the information about whether an iframe or a JavaScript snippet should be injected, together with the code to be injected. The server's response must contain a similarily generated authentication secret for the response to be accepted. If this check passes, the rootkit then copies the injection information into a global variable.

This protocol is obviously vulnerable to simply generating the secret blob once using dynamic analysis and replaying it, and therefore it merely serves for a little obfuscation. We didn't invest further time investigating this specific "encryption" algorithm.

TCP Connection Hijacking

In order to actually inject the iframes (or JavaScript code references) into the HTTP traffic, the rootkit inline hooks the tcp_sendmsg function. This function receives one or multiple buffers to be sent out to the target and appends them to a connections outgoing buffer.

The TCP code will then later retrieve data from that buffer and encapsulate it in a TCP packet for transmission. The replacement function is largely a reproduction of the original function included in the kernel sources due to the inline hooking insufficiencies explained above.

A single call to the function formation_new_tcp_msg was added near the head of the original function; if this function returns one, the remainder of the original function is skipped and internally a replacement message is sent instead. This function always considers only the first send buffer passed, and we'll implicitly exclude all further send buffers passed to a potential sendmsg call in the following analysis.

The formation_new_tcp_msg function invokes a decision function that contains 4 tests, determining whether injection on the message should be attempted at all:

An integer at +0x2f0 into the current configuration is incremented. Only if its value modulo the integer at +0x2e8 in the current configuration is equal to zero, this test passes. This ensures that only on every n-th send buffer an injection is attempted.
Ensure that the size of all the send buffers to be sent is below or equal to 19879 bytes.
Verify that originating port (server port for server connections) is :80.
Ensure that the destination of this send is not 127.0.0.1.
Make sure that none of the following three strings appears anywhere in the send buffer:

"403 Forbidden"
"304 Not Modified"
" was not found on this server."

Make sure the destination of this send is not in a list of 1708 blacklisted IP addresses, supposedly belonging to search engines per the symbol name search_engines_ip_array.

There are several shortcomings in the design of these tests that ultimately led to the discovery of this rootkit as documented in the Full Disclosure post. Since the check to only attempt an inject once every n-th send buffer is not performed per every m-th connection and before all other tests, it will trigger on more valid requests than one might expect when defining the modulus.

Also, doing a negative check on a few selected error messages instead of checking for a positive "200" HTTP status led to the discovery, when an inject in a "400" HTTP error response was found.

The rootkit then tries to parse a HTTP header being sent out by looking for the static header strings "Content-Type", "Content-Encoding", "Transfer-Encoding" and "Server". It matches each of the values of these headers against a list of known values, e.g., for Content-Type:

text/html
text/css
application/x-javascript

The Content-Type of the response and the attacker specified Content-Type of the inject have to match for injection to continue. The code then searches for an attacker-specified substring in the message and inserts the inject after it.

What is notable is the support for both chunked Transfer-Encoding and gzip Content-Encoding. The chunked encoding handling is limited to handling the first chunk sent because the HTTP headers parsed need to present in the same send buffer. However, it will adjust the length of the changed chunk correctly.

When encountering a gzip Content-Encoding, the rootkit will use the zlib kernel module to decompress the response, potentially patch it with the inject, and then recompress it. While this is a technically clever way to make sure your inject ends up in even compressed responses, it will potentially severely degrade the performance of your server.

Reboot Persistence

After running most of the other initialization tasks, the rootkit creates a kernel thread that continously tries to modify /etc/rc.local to load the module at start-up. The code first tries to open the file and read it it all into memory. Then it searches for the loading command in the existing file.

If it's not found, it appends the loading command "insmod /lib/modules/2.6.32-5-amd64/kernel/sound/module_init.ko" by concatenating the "insmode" command with the directory path and filename. However, all those 3 parts are hardcoded (remember that the kernel version now hardcoded was determined dynamically for symbol resolution earlier?).

If opening the file fails, the thread will wait for 5 seconds. After successfully appending the new command, the thread will wait for 3 minutes before checking for the command and potentially re-adding it again.

Additionally, the rootkit installs an inline hook for the vfs_read function. If the read buffer (no matter which file it is being read from) contains the fully concatenated load command, the load command is removed from the read buffer by copying the remainder of the buffer over it and adjusting the read size accordingly. Thereby, the load command is hidden from system administrators if the rootkit is loaded.

Successful Persistence Command Hiding

The screenshot above showcases a problem already with this technique of persistence: since the command is appended to the end of rc.local, there might actually be shell commands that result in the command not being executed as intended. On a default Debian squeeze install, /etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded.

Module Hiding

Hiding itself is achieved by simple direct kernel object manipulation. The rootkit iterates about the kernel linked list modules and removes itself from the list using list_del. In consequence, the module will never be unloaded and there will be no need to remove the inline hooks installed earlier. In fact, the remove_splice_func_in_memory function is unreferenced dead code.

Conclusion

Considering that this rootkit was used to non-selectively inject iframes into nginx webserver responses, it seems likely that this rootkit is part of a generic cyber crime operation and not a targeted attack. However, a Waterhole attack, where a site mostly visited from a certain target audience is infected, would also be plausible. Since no identifying strings yielded results in an Internet search (except for the ksocket library), it appears that this is not a modification of a publicly available rootkit. Rather, it seems that this is contract work of an intermediate programmer with no extensive kernel experience, later customized beyond repair by the buyer.

Although the code quality would be unsatisfying for a serious targeted attack, it is interesting to see the cyber-crime-oriented developers, who have partially shown great skill at developing Windows rootkits, move into the Linux rootkit direction. The lack of any obfuscation and proper HTTP response parsing, which ultimately also led to discovery of this rootkit, is a further indicator that this is not part of a sophisticated, targeted attack.

Based on the Tools, Techniques, and Procedures employed and some background information we cannot publicly disclose, a Russia-based attacker is likely. It remains an open question regarding how the attackers have gained the root privileges to install the rootkit. However, considering the code quality, a custom privilege escalation exploit seems very unlikely.

New Chinese Leadership: How it Impacts Cyber Security

2012-11-16T13:46:00.000-05:00

by Lindsey Novom, Senior Intelligence Analyst

The CrowdStrike Intelligence Team is excited to showcase some of the non-technical analysis that we conduct every day. This analysis provides our customers with up-to-date information on strategic issues that might impact the adversaries that target their critical systems. Ten days ago, when all eyes were on the U.S. Presidential election, CrowdStrike Intelligence Analysts were consumed with another electoral process.

On November 15, 2012, the 18th National People’s Congress (NPC) completed its 10-day long conclave, which traditionally meets every 5 years in Beijing to usher in the next top leader of China. The next president of China, who is also the General Secretary of the Chinese Communist Party (CCP) and Chairman of the Central Military Commission, is Xi Jinping (习近平).

Chinese Politics

Before diving deep into a biographical analysis of the new President to dissect his personality and political views, it's imperative to first understand how China operates as a political entity to understand the big picture of China’s politics.

Despite the fact that China is a one-party state controlled by the CCP, the CCP is not homogenous in its politics. The saying in China is, “one party, two coalitions.” The CCP is comprised of two distinct factions: the populists and the princelings.

The populist faction reflects strong allegiance to the CCP and additionally represents the disadvantaged social groups in China (e.g., farmers, migrant workers, urban poor). Some of the top leaders of the populist faction got their start in the Chinese Communist Youth League and became labeled tuanpai, which means "league faction.”

Former President Hu Jintao continues to lead the populist faction alongside of former Premier Wen Jiabao. Conversely, a princeling is a child of China’s first generation of revolution heroes and leaders. The princelings primarily start their careers in China’s economically advanced coastal cities.

As a result of their privileged aristocratic lifestyles, the princelings typically promote economic reform and represent entrepreneurs’ interests. Former President Jiang Zemin formed this elitist faction with the help of the following two leaders: Wu Bangguo, former chairman of the national legislature, and Jia Qinglin, former head of a national political advisory body.

The Politburo Standing Committee is the sole decision-making body of the CCP, housing the top 7 to 9 leaders of China. In the eyes of the CCP, the president is seen as an equal amongst the Standing Committee members.

China’s current political system is a collective leadership as reflected in the Standing Committee, preventing one leader from usurping too much power as historically reflected during the Mao Zedong era. The president must build consensus amongst the Standing Committee members in order to set policy agendas and reach policy solutions.

How are the president and Standing Committee members selected? Backroom negotiations. A select group of elite party elders and outgoing party leaders handpick the president, as well as the 7 to 9 Standing Committee members who will then be appointed to serve on the upcoming 5-year term.

Each Standing Committee member is appointed based on his close patron relationship to a current or past leader. It's an unspoken rule that each appointed Standing Committee member pays tribute to his patron by promoting the patron’s political ideology and policy stance. These patrons are primarily made up of the aforementioned party “elders,” Mr. Jiang, Mr. Wu, Mr. Jia, Mr. Wen, and Mr. Hu, all of whom battle to maintain political power within the CCP.

During Hu Jintao’s leadership, the Standing Committee was split 5-4, with 4 seats representing the populist coalition and the remaining 5 reflecting the elitist faction. With the completion of the 10-day conclave of the new 18th NPC, China announced the shift from 9 to 7 seats, which suggests reining in power and eliminating threatening actors, including Liu Yuanchao and Wang Yang, who were proponents of political reform and change.

The Standing Committee

The newest lineup of the 7 Standing Committee members only includes two members who are tuanpai, although one of them is a close comrade of Jiang Zemin, which creates a 6-1 princeling to tuanpai split.

Below are the the 7 Standing Committee members who will lead China for the next five years:

Xi Jinping (President, General Secretary, Chairman) 习近平

Princeling: Xi’s father, Xi Zhongxun, was a revolutionary leader under Mao Zedong. Xi Jinping has experience running both rural and metropolitan regions. He experienced rural politics as county deputy secretary in Zhengding, Hebei province, as well as led economically advanced regions, including Fujian, Zhejiang, and Shanghai. Xi Jinping is expected to support policies that develop the private sector, including liberalizing foreign investment, trade, and China’s financial system.

Li Keqiang (Premier of the NPC)李克强

Populist: Li was a member of the Communist Youth League and is considered part of President Hu Jintao's tuanpai faction.

Zhang Dejiang, 张德江, Princeling

Yu Zhengshen, 俞正声, Princeling

Liu Yunshan, 刘云山, Tuanpai

Wang Qishan, 王岐山, Princeling

Zhang Gaoli, 张高丽, Tuanpai (however, Jiang Zemin’s protégé)

Did the change in leadership affect China’s national cybersecurity and espionage policies? At this time it’s hard to say because China’s cyber information agencies and organizations are cloaked in secrecy. Equally as important, what is known about China’s cyber espionage programs? The PLA, Ministry of Science and Technology, National Crypto Management Center, State Secrecy Bureau, Ministry of Public Security, certain state-owned information security companies, and universities help wage China’s cyber espionage campaign.

Cyber Espionage and the State

According to the Project 2049 Institute, the State Informatization Leading Group (SILG, 网络与信息安全组), comprised of senior representatives of the CCP Central Committee, Politburo, State Council, and PLA, advises senior political leaders on computer network operations policies.

Specifically, the Second Bureau of the General Staff Department’s Third Department within the People’s Liberation Army (PLA) in Shanghai primarily targets and exploits U.S. computer networks, which is comparable to the U.S.’s National Security Agency (NSA). The PLA wages cyber warfare and espionage through its “Third Department” that houses high-level computer programmers, linguists, and code breakers.

The Third Department’s central electronic intelligence unit within the Chinese military is the Beijing North Computing Center (BNCC), which is the Chinese equivalent to the Pentagon’s U.S. Cyber Command. The BNCC is involved in exploitation of foreign networks and denying an adversary access to his networks.

The PLA and aforementioned Chinese government entities leverage relationships with regional universities with strong information security programs to acquire sensitive data and local talent for its national agenda in the cyber arena. For example, Sichuan University’s Institute of Information Security supports the Chengdu information security base and Shanghai Jiaotong University’s School of Information Security supports the Shanghai base. There's active cooperation between Peking University’s department of Computer Science Laboratory of Information Security and the security unit of the General Staff of the Ministry of Public Security and the Ministry of Security and Secrecy Bureau.

Conclusion

China is waging a consolidated cyber warfare effort against the U.S. government, certain U.S. industries, think tanks, media outlets, and academic institutions. The web of China’s cyber espionage network is elaborate, intricate, and prosperous.

It's imperative for the U.S. to engage China’s new leadership on cyber espionage. It will not only take the U.S. government to fight against China’s cyber espionage at the national policy level, but it's also imperative for the private sector to lead the fight against foreign cyber adversaries.

To that end, one of the most effective ways to arm your organization is to leverage intelligence in a cyber defense strategy. At CrowdStrike, intelligence powers everything we do. For information on how you can leverage the CrowdStrike Intelligence Team to power your business decisions and enterprise defense, please contact us at intelligence@CrowdStrike.com.

CrowdStrike would like to acknowledge the incredible work by the Project 2049 Institute and we encourage you to read their reporting if you are interested in the Chinese strategic agenda.

HUNT or BE HUNTED

2012-11-08T11:10:00.000-05:00

IDENTIFY: NEW Offerings from CrowdStrike Services

by Christopher Scott, Principal Consultant

In my former life as Principal Cyber Security Systems Engineer for a DoD contractor, I was witness to many targeted attacks. During my tenure, we enlisted the help of another "well known" player that focuses on dealing with targeted attacks and provides incident response services. After extensive research, I believed that we were using the latest and greatest technology and intelligence.

Then I met George Kurtz, who introduced me to cutting-edge technology powered by real-time intelligence. I immediately saw the unprecedented capabilities and understood how this view of security will fundamentally change the threat landscape. After one meeting, I knew that CrowdStrike was going to become the answer to securing businesses and protecting intellectual property. Without question, it was time to follow Shawn Henry's lead and join the mission.

Six months ago, Shawn enthusiastically took the reins of the newly formed CrowdStrike Services with the intention of building it into the world-class organization that exists today. The team has significantly increased in size and has evolved capabilities across three offerings: IDENTIFY, RESPOND, and STRIKE.

The division has recruited top talent in the areas of targeted attack detection, mitigation and remediation, as well as professional services delivery. With a wide breadth of knowledge across the security spectrum, the team can be rapidly deployed to address many aspects of incident response and threat identification.

So, what differentiates CrowdStrike Services from other companies that offer similar capabilities?

Behind CrowdStrike Services lies a government-quality Intelligence team that powers everything we do, from Services to Technology. During every engagement, CrowdStrike uses real-time adversary intelligence to enhance IR operations and proactive defense. The day has now arrived when we can tell you more than the 'what'. We focus on linking the WHO, WHAT, and WHY. This key differentiator empowers CrowdStrike Services to protect your intellectual property and go beyond the malware to IDENTIFY targeted attackers.

With the power and mission of the Intelligence team behind us, we're pleased to offer a full range of IDENTIFY services offerings to both the public and private sector. Focusing on the who, what, and why, the IDENTIFY offerings leverage proactive security to hunt adversaries who bypass defense in depth. Over the course of the three-part HUNT or BE HUNTED blog series we'll provide a detailed look into each service offering and walk through scenarios to show them in action.

Here's a look at what's to come.

IDENTIFY: SHAPE (Strategic Hunting and Pursuit of the Enemy) Assessment

CrowdStrike's SHAPE Assessment helps IDENTIFY existing compromised systems, while providing counterintelligence and recommendations to help mitigate future targeted attacks. Through hunting operations, which leverage targeted host and network-based visibility as well as victim threat profiling, we identify the adversary and find out what they're after.

IDENTIFY: DNS Monitoring

Supported by CrowdStrike Intelligence, DNS Monitoring allows for CrowdStrike Services to IDENTIFY intrusions into our clients' networks. By tracking DNS changes worldwide, we are able to successfully detect and mitigate targeted attacks.

IDENTIFY: Email Monitoring

Consuming CrowdStrike Intelligence, Email Monitoring provides an additional layer of security to IDENTIFY the commonly used attack vector of spear phishing. Using techniques different from SPAM or AV technology, this service is able to quickly IDENTIFY common attack methods without disruption to business process.

Blending our real-world experience with the above offerings, CrowdStrike Services fundamentally change how organizations IDENTIFY advanced attackers on their networks. The CrowdStrike team has an unmatched ability to hunt the adversary, remove them from the network, and proactively keep them out.

For more information on CrowdStrike Services or any of our IDENTIFY offerings, please contact us at services@crowdstrike.com or 888.512.8906 x 700.

**********

LIVE Webcast: REGISTER NOW!

For an in-depth and interactive look into a current threat actor, REGISTER NOW for our upcoming live webcast featuring Adam Meyers, Director of Intelligence, and Jeff Wilson, Principal Security Consultant.

Invasion of the Adversary: HUNT or BE HUNTED

Tuesday, November 27th | 2pm EST / 11am PST

Former Air Force Information Ops Commander joins CrowdStrike as Senior Director for Strategic Operations

2012-10-29T17:33:00.003-04:00

by George Kurtz, President & CEO

I am proud to announce that Colonel Mike Convertino, USAF (Retired), has joined CrowdStrike as the Senior Director for Strategic Operations where he will focus on planning and executing offensive/active defense and information operations strategies for our customers. Mike is an ardent and vocal advocate of taking the cyber fight to the adversary and co-authored a paper while at Air War College in 2007 calling for adding cyber capabilities and strategies to the Air Force to ‘fly and fight’ in cyberspace. As Commander of the 318th Information Operations Group, the premier information warfare group within the Air Force, Mike established a consistent track record of taking the lead in developing information operations techniques, tactics, and procedures (TTPs) and the tools to execute them for use by the combat air forces and other agencies.

During Mike’s tenure in the military and in the private sector he has seen firsthand the economic and national security devastation from intrusions from a multitude of adversaries and understands what needs to be done to turn the tables on them. The nation suffers from a plethora of complex national cyber security policy issues, and our core belief is that the private sector can provide invaluable help to the government in addressing the adversary problem. At CrowdStrike we believe that industry can’t rely on the government alone to address targeted intrusions and continued theft of our intellectual property. Our key mission is to use our advanced technology and the best intelligence professionals handpicked from government and private sector to deny, deceive, and disrupt adversary intrusion operations while increasing their costs and assisting our customers in responding, mitigating and providing attribution of targeted attacks and intrusions. Adversaries change their tactics on a daily basis; however, CrowdStrike provides our customers with the most detailed and comprehensive adversary threat intelligence to stay one step ahead of our enemies.

We are honored to have Mike on our team, and we know that he believes deeply in our company’s important mission. Mike’s addition to our team will help us refine and expand our capability and evolve our focus on identifying and disrupting adversary operations. Our mission has always been to provide government-quality intelligence, active defense, and aggressive attribution options to the private sector. While Adam Meyers continues to build out a world class Intelligence offering, Mike will focus on assisting customers in leveraging CrowdStrike's proprietary technology to hunt for adversaries on their networks and strike back as appropriate.

Currently, we are in the process of hiring additional consultants that have deep experience with strategic and tactical intelligence analysis, malware reverse engineering, intrusion analysis, incident response and forensic investigations, and conducting information operations against nation-state adversaries. If you are interested in joining CrowdStrike and working with an exemplary team, please submit your resume to mission@crowdstrike.com.

Thank you again for your support and positive feedback as we try to move the security industry forward. If you would like to keep up with the latest news on CrowdStrike please follow us on Twitter @CrowdStrike or @George_Kurtz. Or you can also reach me on LinkedIn.

About Mike Convertino:

Mike holds degrees in electrical engineering, information systems management, and international security studies and has over 26 years of experience leading large IT operations and security organizations. He was assigned to the Joint Staff where he oversaw negotiations on technical standards for the rapid electronic sharing of intelligence between the military and the intelligence community after 9/11.

Mike was highly decorated for his long career in cyber defense and beyond, earning the Nation Medal for his work in the Bosnia conflict, several Meritorious Service Medals, and the Legion of Merit at retirement.

After the Air Force, Mike joined Microsoft as the Senior Director of Network Security. While at Microsoft, he was responsible for all Microsoft internal cyber forensic investigations worldwide, as well as live security monitoring of all Microsoft networks including online services such as Hotmail, Office 365, Xbox Live, Azure, and Dynamics CRM as well as Microsoft’s corporate network.

Unpacking Dynamically Allocated Code

2012-10-29T09:50:00.000-04:00

by Jason Geffner, Sr. Security Researcher

Background

Today, most malware is obfuscated to make it more difficult for traditional antivirus engines to detect the malicious code and to make it more arduous for analysts to understand the malware's functionality. Although many automated tools exist for deobfuscating (or "unpacking") malware, they have their limitations and analysts often need to manually unpack malware.

Analysts typically follow three steps when unpacking malware:

Trace to the malware's Original Entry Point (OEP)
Dump the process's memory
Reconstruct the Import Table

However, analysts' tools for dumping memory and reconstructing a module's Import Table are only designed to work when the unpacked code is written to an existing PE section in memory. In rare cases where an unpacking stub writes the unpacked content to a dynamically allocated region of memory (especially when that region is before the module's Base Address), common memory dumping and Import Table reconstruction tools fail.

This blog post discusses a method to fully unpack a malware sample whose unpacking stub writes the unpacked code and Import Address Table to dynamically allocated memory.

Problem

For this blog post, we'll be working with a file with MD5 hash 65EE9D8CB2ACB1F95CDA5F66F4591918; it's a rogue antivirus program packed with ASProtect.

Although tracing to the OEP for this sample is out of the scope of this blog post, suffice it to say that on a given run of this sample, the OEP was found to be at Virtual Address 0x011B1038. However, this OEP address is below the executable module's base address of 0x03000000:

Since the DOS header for our module begins 0x01E4EFC8 bytes after the OEP, even if we could reconstruct the Import Table, we can't just dump the unpacked code to create a working binary. Furthermore, since the unpacking stub has already applied relocations, we can't just copy & paste the OEP's memory region after the main module's sections, dump it all, and hope to get a working executable even after PE header patching.

Note that although some packers' stubs such as MEW's will leave the original DOS header and PE header in-place at the beginning of the unpacked code's dynamically allocated memory region, ASProtect does not persist this information; as such, we cannot simply dump just the OEP's memory region to create a working executable.

How then can we dump this process's unpacked memory to create a valid executable?

Solution

As mentioned above, most unpacking tools expect the code to be unpacked into an existing PE section. Therefore, we'd ideally like to "trick" the unpacking stub to unpack the malware's code into an existing PE section instead of into dynamically allocated memory. Let's start by creating such a section in the malware's executable.

We can use a tool such as LordPE to create the new section. We begin by opening a copy of the file in LordPE's PE Editor:

We then click the Sections button to open the Section Table window:

We then right-click anywhere in the Section Table window and choose "add section header":

The new section header will be added at the end of the Section Table as ".NewSec". We scroll down to it, right click on it, and choose "edit section header...":

Note that LordPE set the Relative Virtual Address of the section to be 0x003CB000; we'll need to use that address later. If we refer to the OllyDbg screenshot earlier in this blog post, we see that the size of the OEP's memory region (beginning at Virtual Address 0x01170000) is 0x0005A000 bytes. Since our goal is to get the OEP's code unpacked into this new section we're creating, we set the Virtual Size of ".NewSec" to 0x0005A000 bytes:

LordPE already set the characteristics ("Flags") of ".NewSec" to 0xE00000E0 (readable, writable, executable), so we click OK to apply the section size changes. We then close the Section Table window and in the main PE Editor window we set the Size of Image field to (0x003CB000 + 0x0005A000) = 0x00425000, in order to account for our newly added section:

We now click the Save button to save our changes.

Now that we've modified the file such that that we have an existing PE section into which the unpacking stub can unpack the malware's code, we need to trick the malware to unpack into this section.

If we look at the OEP's memory region (beginning at Virtual Address 0x1170000) with VMMap, we can see that its Type is "Private Data":

According to VMMap's help file, "Private memory is memory allocated by VirtualAlloc and not suballocated either by the Heap Manager or the .NET run time." This indicates that the OEP's memory region was allocated by the process's unpacking stub via VirtualAlloc(...). Additionally, we know from our analysis above that the size of this allocated region is 0x0005A000 bytes. We can thus run the new version of our target with the added section in a debugger, set a breakpoint on VirtualAlloc(...), and wait for it to be called with a requested size of 0x0005A000 bytes.

If we set a logging breakpoint on VirtualAlloc(...), we see it called twice with a size of 0x0005A000 bytes:

If we track the returned value from these two VirtualAlloc(...) calls, we see that the malware's code is unpacked into the memory allocated by the second call to VirtualAlloc(...).

We now restart the process, set a breakpoint on VirtualAlloc(...), and the second time it's called with an allocation size of 0x0005A000 bytes we change the return value in EAX to actually point to the Virtual Address of our new section:

This causes the unpacking stub to treat our new section as the 0x0005A000 bytes that would have been returned by VirtualAlloc(...), causing the unpacking stub to unpack the malware's code into our new section instead of a dynamically allocated region of memory. We can now trace to the OEP, successfully dump the memory, and reconstruct the Import Table:

We can now analyze the unpacked file.

Conclusion

This blog post demonstrates that reverse engineering is not just a reliance on tools. A professional reverse engineer requires knowledge of the hardware, the underlying operating system, and a good deal of creativity in order to solve challenging problems.

No matter what the bad guys do to make our work more difficult, we will always persevere, outsmart them, and in the end, use our skills to bring pain to the adversary.

Want to make reverse engineering easier? Try CrowdRE!

FinSpy Mobile: iOS and Apple UDID leak

2012-09-04T16:43:00.001-04:00

by Alex Radocea, Sr. Engineer

Last week, Morgan Marquis-Boire and Bill Marczak from The Citizen Lab published a fascinating glance at real-world mobile espionage tool created by Gamma International under its 'FinFisher' product line. The report covers the mobile component of FinFisher dubbed 'FinSpy Mobile' which supports iOS, Android, Windows, Blackberry, and Symbian phones. Gamma International in response to the article, issued a press release stating that FinFisher's "information was stolen from its sales demonstration server at an unknown time by unknown methods."

CrowdStrike analyzed the iOS version of FinSpy to identify details of any attacks against the iOS platform itself which would facilitate the installation of the FinSpy tool. The technical overview from The Citizen Lab identifies some notable attributes which imply either a bypass or exploit of the iOS security architecture.

One of the first points to catch our attention was that the applications in the FinSpy package use Ad-hoc distribution. Ad-hoc distribution is typically used for testing, and one of the three application distribution methods available from Apple, the second being In-House apps and the most well-known distribution method being through the iTunes App Store (which also includes Business-to-Business a.k.a B2B apps). Ad-hoc distribution requires that the individual target device's Unique Device Identifier (UDID) must be known when the Ad-hoc distribution profile is created, long before execution/installation time. This makes Ad-hoc distribution less than ideal for in-the-wild exploitation and would seem to support Gamma International's statement regarding the sales demonstration server. That is of course until the recent 'anti-sec' leak of over a million UDIDs with customer name/device name correlation.

While the limitation of knowing the UDID in advance points to some other distribution channel, the FinSpy installation mechanism writes to a number of files that are not directly accessible from within the third-party application container. The third-party application container is a sandbox that is part of iOS which enables the device to run third party applications safely and separately from each other and the operating system, this is a security feature of iOS. This indicates some form of security bypass or exploit is required to install the package by reaching outside of the sandbox. Additionally, these files are not writable using the 'mobile' user privileges, with which third-party applications execute. Lastly, these files are located in the read-only portion of the filesystem, the system partition, requiring the remounting of the partition with read/write privileges requiring superuser access. In essence, the Ad-hoc distributed apps run in the third-party App container and without kernel code execution, there is no way to directly bypass the App sandbox. Even if somehow one managed to get around the filesystem permissions, there would still be no way from the sandbox to directly use system calls to write to those file paths.

The trojan application which exfiltrates data, named 'SyncData.app', runs persistently and silently while exfiltrating information from data sources not reachable by third-party Apps.

Payload Expansion

The FinSpy Mobile 'installation' begins by instantiating the install_manager.app, which contains a routine which decodes and drops four additional binaries.

Specifically, the application bundle of the install_manager.app contains a 'data' file which has been obfuscated with a simple fixed-key XOR loop. Once decoded, the data file is actually a zip compressed file which expands into four more applications, and a LaunchDaemon configuration.

In the pseudocode that follows throughout this post, "${suid_tmpcache}" refers to a path generated as follows:

On a jailbroken device, running this as the mobile user would result in the path "/var/mobile/Library/Caches". On a non-jailbroken device, where the user partition is mounted "nosuid" to ignore setuid executables, this results in "/tmp/" as the destination path, which is writeable from the third-party app container.

The '_im_expandPayload()' routine which decodes the binaries also marks the executable bit of each of the decompressed App bundle's binary files and attempts to set their ownership to the root user. NSFileManager fails gracefully if not running with root privileges and will still mark the files as executable.

Privilege Escalation Mechanism?

So how does the trojan break out of the sandbox? Is there a kernel exploit inside? After extraction, the trampoline App is executed, followed by the the execution of the installer App.

The infrastructure points at trampoline as a privilege escalation exploit, specifically the arguments which are supplied to the trampoline.app are redundant and unnecessary unless a privilege escalation is occurring.

Install Manager Running Trampoline

Trampoline

As is turns out, the trampoline in this sample is a no-op 'placeholder', there is nothing inside and the App has no effect. Checking the standard control flow techniques, including clever ones, shows no alternate entry points. No interposers, no interesting relocation entries, initializers, constructors, destructors, dyld exploits, or other tricks.

The following is the pseudocode for the main routine, the argc comparison is off by one, causing a non-exploitable NULL pointer dereference.

Installer

The installer app copies over the payloads to their final paths in "/Applications", "/System/Library/LaunchDaemons", and "/System/Library/CoreServices/".

Files Copied

.../org.logind.ctp.archive/SyncData.app to /Applications/SyncData.app

.../org.logind.ctp.archive/com.apple.logind.plist to
/System/Library/LaunchDaemons/com.apple.logind.plist

.../org.logind.ctp.archive/logind.app to /System/Library/CoreServices/logind.app

Followed by the execution of the 'login' App with "/bin/launchctl" /System/Library/LaunchDaemons/com.apple.logind.plist

Due to the usage of getuid() and geteuid() in 'installer', it seems that 'installer' is expected to be run as a setuid root binary. A weaponized version of the trampoline App would likely exploit the system to make 'installer' a setuid root binary. Supporting evidence for this is mentioned later, which shows how the temporary directory lookup checks if the Caches directory is mounted nosuid. The /tmp directory is also part of the user partition, and would be also be mounted nosuid on a standard non-jailbroken device.

What's important to note is that setuid root privileges on 'installer' won't be sufficient. The exploit must remount the filesystem. Even then, the sandbox container would prevent the writes to these filepaths, the kernel exploit in trampoline would also need to modify the sandbox container for the already-running 'Install Manager' App, or patch the kernel sandboxing code. On a jailbroken device from the iPhone Dev Team, kernel sandboxing code is already hot-patched so this is not necessary.

Persistence mechanism?

As outlined by The Citizen Lab post, Logind will launch SyncData on every new device boot. In this manner persistence is established, SyncData will run without any restrictions to data available on the device. Launchd runs the logind App with full root privileges and the SyncData App will run without a sandbox profile. No additional exploit is necessary for persistence on a jailbroken device, and Ad-hoc distribution would take care of code-signing on a standard install.

Takeaways

The FinSpy Mobile iOS sample contains no exploit or security bypass of iOS, since 'trampoline' is incomplete. The installation mechanism in this sample is consistent with what would be used in a demonstration. However portions of it could easily be weaponized with an existing jailbreak for out of date devices or a new kernel exploit. The architecture of the FinSpy demo package is consistent with a commercial grade implant which supports interchangeable exploits.

Although this sample is not fully weaponized, the exfiltration payloads are dangerous and can be trivially distributed onto a jailbroken or a non-jailbroken 'paired device' using Mobile Device Management (MDM). The missing components would be the command and control and SMS backend, which may have also been on the sales demonstration server, and thus compromised.

In the wild, this demonstration code can already trivially run on a jailbroken device. A paired jailbroken device can have the logind and SyncData Apps dropped directly on the system to later exfiltrate data, making this sample sufficiently dangerous.

It is entirely likely that FinSpy has been used in support of non-demonstrative exploitation and collection. CrowdStrike is currently looking for such samples, and will report if any are found, if anyone knows of such samples we would love to hear about them. It is also noteworthy that with the release of the alleged UDIDs today, if those do prove to be legitimate devices, there are now over one million targets which can be targeted using the FinSpy Ad-Hoc distribution mechanism coupled with an existing or new exploit/jailbreak.

As mentioned previously, annotations are available on CrowdRE.

Update September 4th, 2012 7:43 PST:
Two astute readers correctly point out that NSTask fails inside the third-party sandbox, since NSTask uses the fork system call which is filtered. This is true on both standard installs and jailbroken installs for any Apps that do not have the backgrounding entitlement. Install Manager does not use the entitlement.

install_manager.app entitlements

I will also join George Kurtz and my colleague Georg Wicherski at an upcoming Hacking Exposed: Mobile Targeted Threats webinar held next Wednesday September 12 at 11am PT/ 2pm ET. I will be discussing this threat and mitigation strategies in more detail as a guest speaker. Register for it now at www.hackingexposed7.com

CrowdRE: Alpha++ Release

2012-08-08T10:31:00.000-04:00

by Adam Meyers, Director of Intelligence

Alpha++ Release

Since CrowdStrike released our free Crowdsourced Reverse Engineering (CrowdRE) service in June, the team has been hard at work building new features that we were very excited to unveil at Black Hat USA 2012. The new features are a direct result of some of the great feedback that the community provided and we encourage more feedback on these new features. In an effort to lead by example the CrowdStrike Intelligence Team has committed nearly all of our current annotations to CrowdRE, you can immediately benefit from our reverse engineering efforts. We just created and posted the video below that demonstrates some of the latest features and how to set up the CrowdRE environment.

Mac/Linux Versions

When CrowdRE was released at REcon in June the immediate feedback was to provide a Linux and Mac versions of the plugin, Jason Geffner during the presentation surveyed the audience and it was a mixed result of what version to focus on. Since there was interest for Mac and Linux, we decided to release both versions! To access the newest plugin visit http://crowd.re and you will see the following page:

Groups

The other feedback we received was that users did not want to share their annotations with everyone, and while CrowdRE was built to share reversing intelligence with as many people as possible, we understand that sometimes this data does need to be compartmentalized. The group feature is a way to limit the distribution of your annotations to a limited subset of CrowdRE users. This feature is simple to use and you may have seen the place holder for it in the CrowdRE UI over the last few weeks. The way this works is to:

Create a group
Add/invite friends to the group to share annotations with
Crowd Reverse annotations with your group

CrowdRE users can create different groups for different projects and share annotations to those groups; this allows for example the formulation of working groups for particular malware families. An example might be to create a Zeus working group, in this situation members of that group may share annotations exclusively amongst themselves from Zeus reverse engineering projects to ensure all participants have the latest analysis.

Private Commits

CrowdStrike built CrowdRE to encourage sharing in the reverse engineering community, however we understand that sometimes the annotations or functions we are reversing are something that users do not wish to share. As a result of lots of feedback about the usefulness of fuzzy hashing but the reluctance to share this sensitive data to the community, we are also introducing private commits in this version. Private commits can be useful both for sharing annotations between different machines, or to take advantage of fuzzy hashing without publicizing what is being reversed. Using private commits the user can keep annotated functions to themselves and not share them into the CrowdRE community.

Karma

The new release of CrowdRE also introduces what we have dubbed a 'Karma' rating. Historically the problem with sharing in a community setting is that people will take without giving. With this release of CrowdRE we set out to recognize those members of the community who are contributing the greatest and most usable annotations. We chose Karma based on the concepts associated with Karma in eastern philosophies, typically deed or action - committing annotations is a good action in CrowdRE and quality annotations are even better. As such users will build a Karma score based on their commits and as we progress as a community we will look at interesting ways to award and recognize high Karma scores. Personally I was just unseated as the highest Karma score and I am working on some new annotations to reclaim the crown!

CrowdStrike would like to pay special thanks to Ilfak Guilfanov and his Hex-Rays team for all the support they provided to the CrowdRE team to help navigate some of the unique challenges of building a portable IDA Pro plugin.

Please provide feedback, we are still really excited about CrowdRE and looking to build in the features that the community requests. We loved all the feedback we have received already and can't wait to start working on new features! Join the CrowdRE community here, and we look forward to sharing with you! Please see this helpful video to get started with CrowdRE.

Upcoming Black Hat USA 2012: Android 4.0.1 Exploitation

2012-07-20T13:00:00.004-04:00

by Georg Wicherski, Senior Security Researcher

This February in the "Hacking Exposed: Mobile RATs" talk at the RSA conference, we released a demonstration of an end to end compromise of an Android 2.2 phone using a vulnerability in Webkit that we had weaponized. The demo consisted of sending a spearphish SMS message to the device with a link to a website hosting the exploit. Once the user clicked on the link, we stealthily compromise the browser through the Webkit vulnerability and then used another root privilege escalation exploit to gain root access to the device. Afterwards, we installed a Chinese RAT we had commandeered that would proceed to track the user's real-time location and intercept phone calls and text messages. All that was done without any end-user interaction or awareness, beyond having clicked on the original spearphish link.

At the time, the demo only worked on Android Froyo phones because in later versions of Android, Google had introduced partial Address Space Layout Randomization (ASLR) and No Execute (NX) exploit mitigations. However, after a few weeks of additional effort in collaboration with Accuvant LABS' Joshua "jduck" Drake, we are pleased to announce that a new Webkit exploit will be discussed at BlackHat USA 2012. Using the same vulnerability, we successfully circumvented all extra security protections present on Android 4.0.1 (Ice Cream Sandwich). The fix for the vulnerability at hand has been merged into Android since 4.0.2 and our exploit would not work on Android 4.1 (Jelly Bean), since Google completed ASLR work to include randomization of dynamic linker in that version.

Reverse Shell initiated by the Browser on Android 4.0.1

Since the bug is hard to turn into an information leak, we do Return Oriented Programming within the dynamic linker, which is located at a fixed address, and subsequently execute shellcode from executable memory allocated by the ROP chain. This allows us to do anything that the browser has privileges to do on Android 4.0.1 (e.g. track the location without user interaction) or chain a local root exploit / "Jailbreak" allowing us to take 100% control of the phone.

The details of our linker ROP and how we solved this seemingly hard challenge to pivot from this insanely hard bug will be presented by CrowdStrike's Georg Wicherski as a guest feature in Stephen Ridley's and Stephen Lawler's "Advanced ARM Exploitation" (on a "Lackluster Hackcluster") at 10:15am on July 25th at Black Hat. The actual demo will also be a surprise in another talk!

Streamlining the Reverse Engineering Process with CrowdRE

2012-06-22T15:20:00.001-04:00

by Jason Geffner, Senior Security Researcher

Background

As is commonly known in the industry, and as evident from recent high-profile malware samples such as Stuxnet and Flame, malicious binaries are continuing to increase in complexity and grow in size. While a single analyst can statically reverse engineer a small downloader or dropper in a matter of minutes, it can take weeks or even months of man-hours to analyze a massive binary developed by a well-funded adversary. To streamline the reverse engineering process, CrowdStrike has developed CrowdRE, a platform that allows analysts around the world to perform collaborative reverse engineering. This post will focus on the CrowdRE plugin for IDA Pro, which allows analysts to leverage the power of the cloud to analyze a given binary.

We'll demonstrate the functionality of CrowdRE on a malware sample from a Chinese-based intrusion set that we at CrowdStrike call "Comment Panda" (the group is also known in the industry as "Comment Team" or "Comment Group"). This adversary was responsible for the Shady RAT intrusions that were revealed by our co-founder and CTO Dmitri Alperovitch last year, and is known to encode Command-and-Control (C2) commands inside of HTML comment tags. In this CrowdStrike Services scenario, a customer finds this malware sample on their network and needs it analyzed immediately, so CrowdStrike assigns two analysts to concurrently reverse engineer the sample. Both analysts disassemble the sample in IDA on their own computers. The first analyst is told to focus on functions related to auto-start-execution-points (ASEPs) and cryptography, while the second analyst agrees to focus on functions related to network communications.

First Analyst's Workflow

The first analyst notices a function that writes an entry into HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows. He names the local stack variables, writes descriptive comments for the function, and names the function RegisterASEP():

He then finds what appears to be a numeric constant related to the generation of AES tables. Upon further investigation, the analyst determines that this malware in fact uses Gladman's implementation of the AES/Rijndael decryption algorithm with a fixed 128-bit decryption key. As above, the analyst annotates the AES functions:

He then uploads his work to the CrowdRE cloud by pressing Ctrl-F2 to load the CrowdRE plugin, and then pressing the "Upload annotations..." button. This brings up a dialog of all the functions in the IDB, allowing the analyst to choose which functions' annotations to upload to the CrowdRE cloud. The analyst chooses gen_tabs(), set_key(...), rEncrypt(...), rDecrypt(...), AESDecrypt(...), RegisterASEP(), and ConstructAesKey(...) (several of those function names based on the AES library code used by the malware), and presses "Upload annotations":

Second Analyst's Workflow

Meanwhile, the second analyst is busy at work. He spots two functions in the malware that call API functions such as HttpSendRequestA(...) and InternetReadFile(...). The analyst reviews the first function, names the local stack variables, makes some comments in the disassembly, and names the function DownloadFileFromWebServer():

He then analyzes the second function and finds that it downloads a file, appears to call a function to decrypt or deobfuscate the downloaded file, and saves the output to disk. This decryption/deobfuscation function is highlighted in yellow below:

Given that the first analyst was tasked with analyzing cryptographic functions, the second analyst now queries the CrowdRE cloud to see if any annotations are available for sub_404814(...). He navigates to sub_404814(...) in his IDB and presses Ctrl-F2 to bring up the CrowdRE Function History for that function:

The Function History pane above shows that the first analyst has already analyzed sub_404814(...) and submitted annotations for it twice, with the most recent one showing that the input arguments to the function are actually pointers, not ints. This Function History pane can be moved around like any other IDA window pane -- it can be docked into a chosen location in IDA, or dropped into IDA's window tab bar to create a new tab, or even popped out into its own floating window. Whenever the user navigates to a different function in IDA's disassembly view, the pane's content is automatically updated to show the Function History of the current function being analyzed.

The second analyst can simply double-click on the annotation of his choice (or press "Import annotation...") to see the details of what was previously uploaded for this function:

In the Download Annotations window above, the second analyst can now choose what to import from the CrowdRE cloud, such as the function's name and prototype, comments, stack variable names and types, and register variable names and types. Notice that not only are the standard variable types available, but even the user-defined variable types are found in the cloud and can be imported into the second analyst's IDB. When the first analyst uploaded his annotations to the CrowdRE cloud, the plugin detected that he had created and was using user-defined structs such as GAesKey and uploaded those struct definitions to the cloud automatically during the annotation upload. In fact, the plugin recursively uploads all dependencies of every variable type used in an uploaded function.

Once the desired options are checked and "Import" is pressed, the changes are applied to the second analyst's IDB:

However, as can be seen above, there are several other functions remaining for analysis, so the second analyst decides to do a batch import of annotations for multiple functions in his IDB. He presses the "Batch import annotations..." button to see what's available from the CrowdRE cloud for all of the functions in his IDB:

When performing a batch import, the most recent annotations for each checked function are imported into the user's IDB. To cherry-pick specific annotations from a function's history of all uploaded annotations, the user can follow the previous steps above of navigating to a specific function in the IDB to see every uploaded annotation in that function's history in the Function History window pane.

In this case, the second analyst sees that the most recent annotations are all from the first analyst, and since he's a trusted source, the second analyst simply imports all functions from the CrowdRE cloud that were previously analyzed and uploaded by the first analyst. (Note in the screenshot above that AesDecrypt(...) is the current name of the function at 0x00404814 since its annotations were imported in the steps above.)

Now the second analyst can continue reverse engineering this malware with the first analyst's function annotations propagated throughout the second analyst's IDB.

Conclusion

Although still pre-beta, CrowdRE has some other great features as well, such as fuzzy-matching of functions (for matching functions across different variants of a given malware family for malware analysis, or matching functions between an older version and a newer version of the same DLL for vulnerability analysis) and type conflict resolution.

We're very excited about the new features that we're developing and looking to share with the community soon, such as support for Linux and Mac OS, social ratings of other users' annotations in the cloud (so you can see what other people think is reliable), access control lists (to allow only specific people to see your annotations), better fuzzy matching of functions, and much more!

If you have any questions or feature requests, we'd love to hear from you! You can e-mail us at crowdre@crowdstrike.com.

P.S. The functions discussed above are already in the CrowdRE cloud, so if you come across a Comment Panda variant, you'll be able to use the CrowdRE IDA plugin to import the annotations above via fuzzy matching functionality!

REcon CrowdRE Presentation

2012-06-22T12:28:00.000-04:00

Be Social. Use CrowdRE.

Join the Crowd!

2012-06-15T10:19:00.002-04:00

by Georg Wicherski, Senior Security Researcher

Reversing complex software quickly is challenging due to the lack of professional tools that support collaborative analysis. The CrowdRE project aims to fill this gap. Rather than using a live distribution of changes to all clients, which has proven to fail in the past, it leverages the architecture that is being used with success to organize source code repositories: a system that manages a history of changesets as commit messages. The central component is a cloud based server that keeps track of commits in a database. Each commit covers one or more functions of an analyzed binary and contains information like annotations, comments, prototype, struct and enum definitions and the like. Clients can search the database for commits of functions by constructing a query of the analyzed binary's hash and the function offset. Different concurring commits for a function are possible; in such cases it is up to the user to decide which commit is better.

This basic concept is sufficient for a collaborative workflow on a per-function basis for a shared binary. One exciting feature is a similarity hashing scheme that considers the basic block boundaries of a function. Each function is mapped on a similarity preserving hash of fixed size. A database query for such a functions similarity hash returns a set of functions sorted by their similarity value, and the analyst can choose amongst them. This is extremely helpful when analyzing variants based on the same code or generations of a malware family, for example.

Another interesting feature is the synchronization of used types. It is customary for reversers to document C++ class structures and vtables in IDA structs. This also greatly enhances the Hex-Rays decompiler output. CrowdRE will automatically identify all referenced types from a function (being it function parameter types or local variable types). Those types are then bundled with your commit. When annotations are pulled from the cloud, it will automatically also offer to pull the referenced types of that specific commit (with the definition at the time of the commit). If you already have a local type with a colliding name and its definition differs, CrowdRE will offer you various conflict resolution strategies.

The CrowdRE client is now freely available as an IDA Pro plugin. CrowdStrike maintains a central cloud for the community to share their commits amongst each other. It is our goal to help build a public database of known, well annotated functions to speed up the analysis of standard components, somewhat similar to what BinCrowd (which is offline nowadays) offered but with support for multiple co-existing commits for the same function. We will also support list-based commit visibility to give users control over who else can see and import their contributions. In the coming days we will release a series of how-to blog posts and videos to explain different use cases of CrowdRE. CrowdRE continues to be used heavily by the CrowdStrike Intelligence and Services Teams and we look forward to sharing out our commits to help the community reverse as a crowd! Please contact CrowdRE@crowdstrike.com for more information or to provide us feedback. This is an alpha version and we'd love your comments on how we can improve upon it!

We originally developed CrowdRE for internal use but decided to release it for free when we realized that the broader security community can benefit from it as well. In addition, we think it's important to encourage information sharing and collaboration among the security industry. Our adversaries are collaborating, shouldn't the security community do the same?

CrowdRE is now available at crowd.re

CrowdStrike Intelligence - Adversary-based Approach

2012-06-12T07:19:00.002-04:00

by Adam Meyers, Director of Intelligence.

Treating the problem, not the symptoms

Having spent the better part of the last 10 years dealing with various cyber adversaries, it is frustrating to see so many organizations focus on the symptoms of what at CrowdStrike we like to call the adversary problem. An adversary is so much more than the most recent spearphish that drops a Remote Access Tool (RAT) such as Poison Ivy, or a new dynamic DNS hostname that is being used for Command and Control (C2). The adversary is a culmination of all his tools used for exploitation and post-exploitation, the techniques used to laterally propagate across the network, and the procedures that he runs through once he has a firm foothold on the enterprise. These components individually treated are the proverbial whack-a-mole that has frustrated so many of us in the cyber security space for years. Whack - mitigate a malware instance on a workstation on one side of the network. Whack - block a C2 IP or domain at the gateway. Whack - change all the users on a domains passwords because the adversary compromised a domain controller. You can play this game all day, and for years we have. This is a war - and taking a step back to view the battlefield the way a modern commander would engage an enemy can give us some interesting perspective.

Intelligence Enhanced Security

Breaking the vicious cycle of Whack-a-Mole requires changing the approach we use in combating adversaries - we must train ourselves to think proactively. Most organizations are focused on playing defense - and defense by nature tends to be a response driven approach. Something bad happens and we do something about it - if we are there in time. Proactively looking at security requires intelligence - using intelligence to understand not only where the adversary is today but where he has been and what his objectives are. Understanding the adversaries intent will allow us to determine where he wants to be, and we can use this information in creative ways. To this end CrowdStrike focuses on incorporating intelligence collection and analysis into every aspect of our work, the more intelligence we have, the better we are positioned to defend our clients today and those we will have tomorrow.

Global View

Today's military commanders can step as far back as outer space, looking at the battlefield from the aerial or satellite based perspective to get a better understanding of their situation. The fog of war can confuse the situation on the ground in the cyber domain as in any other. Using the global intelligence team, CrowdStrike Services teams have the ability to utilize a view of the battlefield from 50,000 feet - this provides them with intelligence relative to other customers and incidents occurring across the globe. During proactive defense this intelligence allows various CrowdStrike service teams to coordinate across sectors and customers to take impactful actions to disrupt the adversaries ability to observe, orient, decide, and act.

Adversary Differentiation

In terms of the adversary being the sum of all of the malware, C2 infrastructure, tools, and techniques the CrowdStrike Intelligence team spends a lot of time focusing in on and differentiating the adversaries we see. We categorize the adversary by a term pretty commonly used in intelligence circles - Tactics, Techniques, and Procedures (TTPs). During extensive investigation and reverse engineering the CrowdStrike team focuses in on a very unique set of attributes that allow us an extremely granular view of an adversary. Minute differences in code flow and other proprietary indicators provide the team a wealth of intelligence to group into TTP's. These TTP's are additive to the intelligence provided to the CrowdStrike Services teams in the field allowing them an unprecedented ability to conduct proactive incident response.

In the coming months I look forward to unveiling some of the ongoing operations we are running right now to, as my colleague Shawn Henry likes to say, "bring pain to the adversary." We have developed some innovative techniques to level the playing field and make the adversary earn every bit, nibble, and if he's lucky byte. It is a supreme honor to lead Intelligence, one of the three gems along with Technology (lead by Dmitri Alperovitch) and Services (lead by Shawn Henry) in the CrowdStrike "Triple Crown". Together the CrowdStrike team goes into battle every day against unremitting and unflinching adversaries who will stop at nothing to compromise the informational crown jewels of businesses, governments, and those who put their personal safety on the line to speak out against inhumane regimes. If you are motivated to do good and think you have what it takes to join the CrowdStrike Intelligence Team, we would love to hear from you at mission@crowdstrike.com.

Intelligence as a Service

The CrowdStrike Intelligence Team generates in-depth technical analysis that provide organizations with unprecedented insight of the adversary's TTP's. Our intelligence reports are geared towards all levels of an organization from the executive who needs to understand the threat, to the front line technician struggling to fight through an adversary attack against the enterprise. Our existing customers who are already part of the CrowdStrike mission and have access to our detailed intelligence reports reap immediate tactical and strategic benefits from the level of depth and perspective we provide regarding the adversary. For inquires regarding subscribing to the CrowdStrike Intelligence Service, please contact intelligence@crowdstrike.com.

If you are interested in more information about CrowdStrike's Intelligence Team, please watch the Q&A video with me seen below

CrowdStrike Services Bolsters Services Leadership With The Addition of Wendi Rafferty, VP of Services

2012-06-08T07:40:00.002-04:00

by Shawn Henry, President CrowdStrike Services, Inc.

It’s been an exciting couple of months!

The heart and breadth of any organization is the quality of its leadership, and I am delighted to announce we recently added an icon to our executive team. Wendi Rafferty, who was formerly responsible for managing Mandiant’s Western Region operations, has joined CrowdStrike as Vice President of the Services Division and will be reporting directly to me.

Wendi is a technical leader with over ten years of diverse experience in Information Security, Incident Response, and Network Intrusion Investigations. She also served active duty in the United States Air Force as a Special Agent performing computer crime investigations for the Air Force Office of Special Investigations. People with those credentials make us infinitely better, and for that I am grateful.

What’s happened since I started?

On April 2, 2012, I started my career at CrowdStrike after 24 years with the FBI. The decision to move here wasn’t something I took lightly. I thought about it for several months before I finally pulled the trigger. After all, it was a start-up, with a few dozen employees, a handful of engagements, and a $26 million dollar investment. I was a top-level executive in an organization with 36,000 people, an $8 Billion dollar annual budget, and one of the world’s most recognized brands. What could possibly happen at CrowdStrike everyday to keep me interested? Surely I’d be bored to tears and maybe I should have chosen one of those larger firms post my tenure at the FBI that was promising me top-level control along with some excitement?

Well, I’ve been here eight weeks now, and much of it has been a blur. There have been a lot of strategy sessions, conversations, and meetings with Fortune 500 companies, a Board of Directors' meeting, coordination with international partners, domestic and international travel, and a ton of media coverage. We’ve not only talked about what we’re doing, though, we’ve actually executed on it. Be careful what you wish for, as it has been one wild ride after another!

Reinforcing the mission and a sense of pride - I’m still in the fight!

While CrowdStrike is different from the FBI in many ways, I still find so many similarities. Everyday, for example, we’re engaged against our adversary, helping those who are facing the difficult challenge of protecting their network. It is the part of the FBI mission that I enjoyed the best and was most concerned about losing, but I continue to live it every single day.

Take last night, for example, when I was talking to three of our consultants, each in a different part of the country. One was analyzing a victim’s network real-time; another was forensically dissecting one of their hard-drives, and a third was tearing through the malware. Together they identified adversary TTPs, each building on intelligence from the other two. Together they strategized on the best method to dismember the adversary’s infrastructure, to raise the cost to the enemy, and to harden the victim’s network.

The team is only as good as its players - and we have some athletes!

The sense of confidence I had while listening to this team was exceptional, they’re extremely talented, and have many years of experience. They are indicative of the tremendous expertise and ability CrowdStrike has attracted in just the past two months. Just what is it we’ve attracted?

Resume after resume of people interested in joining our mission continue to stream in on a daily basis. There has been an outpouring of incredibly skilled incident responders, malware reverse engineers, cyber analysts, and network engineers. Many come with military, government, and Fortune 500 experience. Many of the interested are amazingly technical and specialized applicants, others not so much.

The emergency room nurse who wanted to join our team heartened me. She had no technical skills, but she was motivated by our vision of protecting the innocent, and wanted to see if there was a role for her to help. Then there was the US government contractor stationed in Afghanistan who wanted to come to CrowdStrike to support our mission in anyway possible and help bring the pain to the adversary. Hey, maybe we do need that emergency room nurse after all?!

Fortunately, the technological resumes far outnumber the others. But they all seem to have one thing in common and that is the remarkable desire to contribute to the CrowdStrike mission, protecting the resiliency of computer networks, and using offensive methods to turn the tables on our opponents. All of that passion inspires me, and reinforces the decision I made just a couple of months ago.

And so it continues - what’s next?

Probably the best part of the journey thus far has been watching this institution grow. Some days slowly, other days fast, but always-moving forward. I get to see the innovation, listen to the strategy, participate in the execution, and I like that - a lot!

Our enemies continue their vicious assault, and we stand shoulder-to-shoulder with the victims, providing resiliency and confidence. I see the CrowdStrike crescendo rising, a steep ascent, and I get to be there at another front row seat to a slice of history. Wow, I can only imagine what the next few months hold?!

If you are up for the challenge of bringing pain to the adversary, please send your resumes to mission@crowdstrike.com.

If you are interested in more information about CrowdStrike, please watch the Q&A video with me seen below

ARMv7/Thumb2 Inline Code Hooking

2012-05-02T16:31:00.000-04:00

by Georg Wicherski, Senior Security Researcher

At Hackito Ergo Sum 2012, I presented about Exploitation of the RenderArena allocator in WebKit (PDF) with a focus on the Android Mobile platform. Since one of the techniques for hijacking a vtable (and subsequently achieve code execution) requires careful heap massaging, we developed an internal tool to hook the various heap allocation functions inline and log all allocations and frees in memory with as minimal overhead as possbile. Since the gist of the talk was the reliable exploitation of this specific bug class, I did not go to deep on how we built this tool. Since some people asked about its internals, the basic ideas are presented here.

The general idea was to log all heap (de-)allocations while maintaining allocation order in a multi-threaded environment (such as the Android Browser) by introducing as little per allocation overhead as possible. Since using a debugger to set a breakpoint on the respective heap functions does incur too much such overhead, I decided for a different approach:

To log every allocation in a timely manner, each such function is hot-patched at runtime with a non-intrusive call to a helper function that logs information about the caller to a memory buffer. Only when this memory buffer is full, it escapes to the analysis software for flushing the buffer over the network to an analysts computer. This method adds so little overhead to memory allocation that the program under analysis remains interactively usable, i.e. we can still use the Browser normally. Of course this approach is extensible to hot-patching other functions besides the normal system heap allocator and, in fact, for the talk we also instrumented a special Webkit sub-allocator (please refer to the slides for more information).

The code to log information is generic in the sense that we can sample one arbitrary register at any point to be hooked. This is usually sufficient for capturing function parameters and return values at the beginning / end of certain functions or arbitrary. If you know a little bit more of the function you are looking at, you can even sample arbitrary values (because ARM is a RISC architecture, which requires any value to be processed to be loaded into a register at some point). The native code to log a single register sample collected looks like this:

Native Code to Log a Single Sample

Besides logging the desired register value (passed in R0) and the calling function, it logs a user defined tag (that is useful for distinguishing multiple hooked locations) and the current thread id (obtained from the TLS, which in turn is located by a call to a magic location defined by the EABI). If your ARM assembly is a little bit rusty, here is IDA's correspondending decompilate (note that ldrex and strex denote race-condition-safe memory loads and stores respectively — the strex instruction will fail if the memory location has been accessed since the correspondending ldrex, hence the surrounding loop):

Decompilation of Log Code

Note that the original code was done in hand-written assembly, but with sufficient manual added type and pseudo-calling-convention information added, IDA is doing a good job of reconstructing equivalent C code.

Unfortunately for us, there typically is no slack space in real-world code that would allow us to insert simple branches to our logging functions. Therefore for inline hooking, typically the code at the desired location to be probed is overwritten with a branch to a trampoline. This trampoline then needs to compensate for the overwritten instruction, so it usually consists of:

A call to the desired hook (the logging function in our case) with potentially required state saving and restoring to preserve the expected state of the original code
Semantically equivalent code to the code overwritten, often just a potentially fixed up copy of the original instructions
A branch to the code following the overwritten instructions to continue the original code

An example of two such trampolines that have been generated is depicted below. All this code is generated at runtime by disassembling the original code, determining necessary fix-up steps and of course generating code to sample the desired register by copying it into R0 for the log function. The instructions in cyan are the original instrucions copied over.

These trampolines highlight some of the caveats one encounters when dealing with hooking RISC code. The first trampoline contains only arithmetic instructions that do not require any modification and were just copied over as they were (based on a simple length disassembly, as thumb2 supports mixing of 16bit and 32bit instruction lengths). However the branch to the original code is so far that it cannot be performed by a regular jump but must be done by a full 32bit load into the program counter.

The second trampoline highlights some necessary fix-ups to copied instructions: because the constant loads it performs are relative to the PC register and again too far away to be addressed by these instructions, the values have been copied to the new trampoline and the instructions have been adjusted to reference these copies.

Example JIT'ed Probe Trampolines

The code for generating these trampolines grew a little more complex than anticipated to cover the corner-cases encountered. It now consists of three passes:

Disassemble the original to-be-overwritten code and look for special instructions (thankfully the Thumb2 instruction set is very regular)
Length Reassembly of original code to calculate relative addresses and offsets
Actual reassembly of original code, fixing relative references and adding branches to original code

The decompilation of this code then looks very trivial, as the semantics of that code are indeed simple:

Decompilation of Example Trampoline

This tool has proven extremely valuable in prototyping attacks by whitehat researchers as we used existing visualization tools to render a view of the heap at any given point in time. It can however be leveraged for benign purposes as well, e.g. some Windows malware analysis sandboxes are based on the same inline hooking approach on the x86 architecture. Although at first looking simple when designed on paper, this project has been difficult to implement due to all the corner cases encountered.

CrowdStrike Services: My New Mission

2012-04-18T00:37:00.000-04:00

by Shawn Henry, President CrowdStrike Services, Inc.

The world has changed...and I've had a front row seat.

I started with the FBI 24 years ago. It was a different time and a different place; things seemed much simpler then. Whether we were investigating street gangs, organized crime groups, or foreign spies, we often knew who the bad guys were. Identifying them was the easy part; the difficulty was determining exactly what they were doing and how they were doing it. What a difference a couple of decades makes.

Times have dramatically changed. Technology has made the world a much smaller place. Twenty years ago when I investigated a bank robbery the pool of suspects was limited to the number of people in the general vicinity of the bank at the time it was robbed. Logical, right? If someone took the money, they had to BE THERE! Now, not so much. Banks are robbed electronically everyday, and the suspect pool is a little larger, limited only by the number of people on planet Earth with a computing device and an Internet connection. According to internetworldstats, that number is close to 2.3 billion. So much for "canvassing the neighborhood."

So now what?

Today's most successful thieves don't carry guns, and they don't slip through basement windows in the middle of the night with a satchel. The successful thieves of today are running rampant through your computer networks, unfettered, every single day. They watch what you do, and they know what you know. Your "secrets" are not. If all they do is steal your most sensitive information, consider yourself lucky. We used to say a burglar who came into your home while you were there was one step away from being a murderer; likewise, today's cyber thieves are just one step away from being saboteurs. Their presence on and access within your networks often means they've got total control...the ability to alter, delete, or even destroy your data and your communications network.

Sometimes they make a lot of noise, oftentimes not. Regardless, they are there....or were....or will be shortly. They work for foreign governments, criminal syndicates, and....coming soon to a network near you....terrorist organizations. As their tactics have changed over the years, so must ours.

Why the move to the private sector?

I was part of the US government cyber strategy and operations for a long time. There are brilliant minds and dedicated people serving society with passion and commitment to securing our digital future. I was proud to be associated with them, and consider many my friends. Too often, though, WHAT we do is not able to keep up with what we MUST do. You can only be punched in the face so many times before you fall to your knees.

So I retire from the FBI and I'm excited to move to the next phase of my life with CrowdStrike. Not due to animosity toward any government agency and not because I don't have the will to fight any longer. On the contrary, this fight is my passion. I am dedicated to the mission. I have always said the private sector needs to be a bigger part of the solution, and with CrowdStrike I'll have more flexibility and opportunity to make a difference from this side of the fence.

CrowdStrike

Why CrowdStrike? Because they BELIEVE in the mission; their idea of protecting the innocent through relentless identification and pursuit of the enemy runs parallel to what I've done for the past 24 years. Smart people with energy and enthusiasm, a stable of subject-matter technical experts, and leadership in the C-suite with a strategic vision. I can continue to hunt the adversary, though from a new perspective and with different mates at my side. That's an opportunity I wasn't certain I'd have post-Bureau...but I think I've found it. I get to work with "meat-eaters" again, not vegetarians! (Not that there's anything wrong with that)

The way forward

Five years ago we set up the National Cyber Investigative Joint Task Force (NCIJTF) because I felt we were not effectively sharing information across the government on the cyber threat. I saw the need to bring together the capabilities, responsibilities, and authorities of multiple US government agencies. The main purpose was to share intelligence, in an expeditious way that was actionable and would provide an advantage against our adversaries; all the agency-partners had a common mission and focus, so it worked. I see a future where the adoption of that type of model in the private sector will be a new innovation in cybersecurity, and one of my many personal missions.

While we consider these types of cyber intelligence models interesting, today I am focused on building out a world-class services organization dedicated to helping enterprises respond to the incidents that are beating them down daily by enabling them to be proactive, predictive, and preventative in nature. This new offering is the last gem in CrowdStrike’s “Triple Crown” of Technology, Intelligence, and now Services that George Kurtz mentioned in his latest blog post. Our goals for the services organization at the outset are simple; to provide our customers with a sense of trust when they are at their most vulnerable, and to instill in them the confidence that their most sensitive information will be protected to the fullest extent possible. Our initial offerings are focused on Incident Response Services, Enterprise Adversary & Malware Assessment, and Response and Recovery, with more to come.

CrowdStrike provides me the opportunity to continue this fight, from "the other side", using intelligence and technology to get in FRONT of the problem rather than merely reacting to it. I’m looking for sophisticated cyber warriors to join me. If you’ve got the skill, the energy, and the passion for a compelling and highly important mission, contact us at mission@crowdstrike.com. The stakes are high...our economic and national security is at stake...and I'm proud to say, "I'm all in!"

Kelihos.C: Same Code, New Botnet

2012-03-29T12:04:00.002-04:00

by Tillmann Werner, Senior Security Researcher

Last week, CrowdStrike took control over the Kelihos.B botnet in a joint effort with other security experts. The infected machines are since trapped on our sinkhole and the botnet cannot be commanded anymore.

In a blog post that was published earlier today, IT security firm Seculert claims that the Kelihos.B botnet is still under control of the criminal who created it and that it is even possible for these criminals to regain access to the sinkholed bots.

CrowdStrike researchers continue to monitor the comand-and-control infrastructure, which is partially live again after having been down for some days, and confirmed that the servers do not speak the Kelihos.B protocol anymore. We are aware of a new version of the bot, Kelihos.C, that has been released shortly after we started the sinkholing operation, and which is spreading via social networks. This new version introduces slight changes to the message format used to propagate peer information and commands. We believe that the modifications are so minimal that the new version is still likely to get detected by anti-virus software with signatures for Kelihos.B. However, as a result of these changes, the new botnet is incompatible to and thus completely separate from the Kelihos.B version sinkholed by us.

Since both Kelihos.B and Kelihos.C are dropped by a third-party installer, it is possible that the capability to update infected machines via this dropper might exist, however thorough analysis of the dropper revealed no way to remotely command it. Bottom line: There is no known means for the attacker to regain control over the sinkholed Kelihos.B machines at this point.

Figure 1: Fall-back domain in Kelihos.C

Additionally it is interesting to note that all of the fast-flux domains used by Kelihos.B are no longer maintained and do not resolve. The new botnet (Kelihos.C) has two fast-flux domains as fall-back handles associated with it, namely coyluhbehim.com and tiffavo.com blocking these domains at the perimeter is advisable.

P2P Botnet Kelihos.B with 100.000 Nodes Sinkholed

2012-03-28T09:00:00.000-04:00

This past Wednesday, CrowdStrike has teamed up with security experts from Dell SecureWorks, the Honeynet Project and Kaspersky to take out a peer-to-peer botnet which we believe is the newest offspring of a family that has been around since 2007: Kelihos.B, a successor of Kelihos, Waledac and the Storm Worm. Traditionally, the botnets in this family are known for spamming, but the newest version is also capable of stealing bitcoin wallets from infected computers. There is an infographic at the bottom of this post that contains the most important facts and numbers at one glance.

Just like its brothers, Kelihos.B relies on a self-organizing, dynamic peer-to-peer topology to make its infrastructure more resilient against takedown attempts. It further uses a distributed layer of command-and-control servers with hosts registered in countries like Sweden, Russia, and Ukraine that are in turn controlled by the botmaster. These systems can easily be replaced by others by announcing a different list of job servers to the bots. Figure 1 shows a scheme of this architecture.

Figure 1: Architecture of the Kelihos.B Botnet

But peer-to-peer botnets are fairly complex distributed systems - and complex systems are usually hard to secure. We identified some flaws in the architecture that allow us to inject specially crafted messages into the botnet. We used this technique to propagate our own peer entries in a way such that it ruled out all others and effectively redirected all bots to a CrowdStrike controlled sinkhole. In addition, the team took proactive measures to prevent the adversary from regaining control. The botnet is since trapped in our sinkhole system, as shown in figure 2.

Figure 2: Sinkholed Botnet

We are currently working with our partners to inform affected ISPs around the world about infections on their networks so they can take appropriate actions. So far we have identified over 110.000 different machines. This number is almost three times larger than the previous version of the Kelihos botnet. What is interesting is that we counted less unique IP addresses than bot IDs in the beginning of the operation. This is due to multiple infected machines with Internet access over a common gateway. As expected, the ID/IP address relation changes after some time as dial-up hosts change their addresses whereas the bot ID remains the same.

Figure 3 shows how the numbers develop over time. The blue graph displays the total number of IP addresses seen on the sinkhole. Green is the number of bot IDs. The number of job requests per hour is depicted in red; the graph shows a typical pattern which results from computers being turned off over night.

Figure 3: IP count, ID count, job request per hour

The graph in figure 4 illustrates how effective the takeover was. It displays the number of bots (per hour) we have seen for the first time. The steep start is proof that our injected peer entries propagated rapidly within the botnet.

Figure 4: New bots on the sinkhole per hour

The geographic distribution of the infected machines is somewhat unusual. With almost one quarter, Poland has by far the most infections.:

Figure 5: Infection distribution

To our knowledge, Kelihos.B was mostly spread via so-called pay-per-install services (PPI). Since the bots report the version of the operating system they are running on to the sinkhole, we can track these as well. Surprisingly enough, 84% of all systems run Windows XP. Here are the numbers:

     91950  Windows XP
      9428  Windows 7
      5335  Windows 7 with Service Pack 1
      1307  Windows Vista with Service Pack 2
      1100  Windows Vista with Service Pack 1
       671  Windows Vista
       253  Windows Server 2003

It seems like there were different versions of the bot coexisting in the botnet. One possible explanation is that the operators partitioned their resources and rented them out to different affiliates for spam campaigns and the like, but had the bots share the network infrastructure as it becomes less likely for a bot to get disconnected from the peer-to-peer network the bigger its size is. We have found as much as 18 different version numbers in our sinkhole logs.

We are working with our partners to inform ISPs about infections in their network and make sure that Kelihos.B remains safely sinkholed. The command-and-control infrastructure has been abandoned by the gang that was operating the botnet two days after we started our operation. One down, many more to go...

Figure 6: Kelihos.B Infographic

CrowdStrike Launch

2012-02-22T10:55:00.000-05:00

by George Kurtz, President & CEO

CrowdStrike launches in stealth-mode with $26 million Series A round led b Warburg Pincus

As I mentioned in a previous post, I was delighted to announce that I had joined Warburg Pincus, a leading global private equity firm focused on growth investing, as an Executive in Residence. So far my time as an EIR at Warburg has been fantastic. The past few months have exposed me to many new companies and technologies that really got my creative juices flowing and pushed me to get back into the start-up game with Warburg Pincus as my partner.

Today, I am proud to announce the stealth-mode launch of my newest venture that I co-founded with Dmitri Alperovitch (CTO) and Gregg Marston (CFO) – CrowdStrike. CrowdStrike is a security technology company focused on helping enterprises and governments protect their most sensitive intellectual property and national security information. Utilizing Big-Data technologies, CrowdStrike is developing a new and innovative approach to solving today’s most demanding cyber-security challenges. CrowdStrike’s core mission is to fundamentally change how organizations implement and manage security in their environment.

Why CrowdStrike:

The seemingly daily barrage of disclosures about companies that have had their crown jewels stolen in recent years reinforced a key principle for us – these companies don’t have a malware problem, they have an adversary problem. Many just don’t know it. Today’s attacks are sophisticated, targeted, and long ranging in scope. Unfortunately, almost every security solution focuses on the tens of thousands of pieces of malware, exploits, and vulnerabilities that are seen in the wild every day. Yet, those are just the interchangeable and, in many cases, disposable tools that the adversaries use to achieve their ultimate objective – theft of intellectual property, trade secrets, and other business proprietary information.

As many of you know the security industry is building “Maginot-line” style of defenses – attempting to prevent all adversaries from getting inside the perimeter of the network or host system. More importantly, a well-financed, trained, and highly determined attacker will always get in. More than likely, they are already in. There is no silver bullet that will stop a determined adversary, so while the security industry attempts to build bigger fences, the enemy is bringing higher ladders to the fight. Moreover, the industry continues to focus on the malware or exploits which is akin to focusing on the gun as opposed to the shooter committing the crime. The person or organization pulling the trigger (or deploying the malware) is the one that you ultimately need to focus on. The type of gun or ammunition they may be using is interesting, but in most cases not strategically relevant.

Based upon investigations we have led, such as Operation Aurora, Night Dragon, and Shady RAT, and knowing the limitations of existing technologies, we are horrified at the amount of IP being stolen and financial damage inflicted every day. It is evident that we are dealing with economic predators who are systematically destroying value in countries around the world. Even worse, we may very well see the enemy engage in destructive and disruptive attacks designed to take down critical infrastructure or modify key processes and data in a covert undetectable fashion.

The Missing Link: Attribution & Raising the Costs to the Adversary

Attribution is the key strategic piece missing from all existing security technologies – providing the answer to the “who?” vs. the “what?” Knowing who is after your IP is critical in determining what assets you want to protect and how. Protecting everything is impossible – you may as well be protecting nothing. However, knowing the enemy is the first step in the process of determining the priority of allocation of scarce resources to defend the key assets and tailoring your response to the Tactics, Techniques and Procedures (TTPs) of the adversary. Knowing their capabilities, objectives, and the way they go about executing on them is the missing piece of the puzzle in today’s defensive security technologies. The key to success is raising adversary’s costs to exceed the value of the data they may be trying to exfiltrate and the only way to accomplish that is by forcing them to change the way they conduct the human-led parts of their intrusions, such as reconnaissance, lateral movement, identification of valuable assets, and exfiltration. Other parts of the operation, such as vulnerability weaponization, malware delivery, and command and control can be mass-produced and changed at will with little cost. However, attackers are creatures of habit and while they are fast to change their weapons, they are slow to change their methods. By identifying the adversary and revealing their unique TTPs (i.e. modus operandi), we can hit them where it counts – at the human-dependent and not easily scalable parts of their operations.

The CrowdStrike Mission:

As the President and CEO of CrowdStrike, one of the most exciting aspects of this new venture for me is assembling a “dream team” of security visionaries to address this important mission and challenge. Our team is comprised of people who are “big thinkers” that have the technical prowess to execute and carry out our mission goals without the encumbrances that face legacy security solutions. Our team of visionaries are the rebels who believe the current state of security is fundamentally broken and want to do something about it. More importantly, these are the patriots who are tired of seeing our intellectual property and competitive advantage wiped away under the thinly veiled cover of an Internet address. The recent stories surrounding Nortel provide a shinning example of how the adversaries can embed themselves into a multi-national organization for the better part of a decade without detection while systematically accessing their most coveted intellectual property. If we sit back idly and do nothing about these types of attacks, we certainly face a crisis of epic proportions and economic consequences that we have yet to fully comprehend. CrowdStrike does not accept the status quo, and we intend to do something about it. If you share our passion and vision about this crisis, and believe you have what it takes to join our fight then please send an email to mission@crowdstrike.com. We are looking for kick ass coders, consultants, and experts who like us have been fighting and responding to nation-state targeted intrusions.

I will leave you with one final thought. The ancient Chinese military strategist Sun Tzu in his teachings emphasized the need to “know your enemy”. For if “you know your enemy and know yourself,” he wrote, “you need not fear the result of a hundred battles.” Isn’t it time we apply these simple time honored lessons in the cyber security battlefield of the twenty-first century?

If you would like to keep up with the latest news on CrowdStrike please follow us on Twitter @CrowdStrike.

If you are attending the RSA conference next week, you can look for us at the following events we are speaking at:

Monday February 27: America’s Growth Capital 8th Annual Information Security Conference

10:15-11:00 am Mobile Security The Changing Threat and Remediation Landscape (panel with George Kurtz)

3:30-4:15 pm Combating State-Sponsored Adversaries (panel with Dmitri Alperovitch)

Wednesday February 29: RSA Conference

8:00-9:10 am Cyber Battlefield: The Future of Conflict

10:40-11:30 am Hacking Exposed: Mobile RAT Edition

CrowdStrike

Empowering Information Sharing: Release of pyNSSFClient

Pat Winkler, Sr. Research Engineer

I/O You Own: Windows 8 Update

Aaron LeMasters, Sr. Research Engineer

HTTP iframe Injecting Linux Rootkit

Georg Wicherski, Senior Security Researcher

Key Findings

Functional Overview

Ghetto Private Symbol Resolution

Berserk Inline Code Hooking

File and Would-be Process Hiding

Command and Control Client

TCP Connection Hijacking

Reboot Persistence

Module Hiding

Conclusion

New Chinese Leadership: How it Impacts Cyber Security

by Lindsey Novom, Senior Intelligence Analyst

Chinese Politics

The Standing Committee

Xi Jinping (President, General Secretary, Chairman) 习近平

Li Keqiang (Premier of the NPC)李克强

Zhang Dejiang, 张德江, Princeling

Liu Yunshan, 刘云山, Tuanpai

Zhang Gaoli, 张高丽, Tuanpai (however, Jiang Zemin’s protégé)

Cyber Espionage and the State

Conclusion

HUNT or BE HUNTED

IDENTIFY: *NEW* Offerings from CrowdStrike Services

by Christopher Scott, Principal Consultant

Former Air Force Information Ops Commander joins CrowdStrike as Senior Director for Strategic Operations

by George Kurtz, President & CEO

Unpacking Dynamically Allocated Code

by Jason Geffner, Sr. Security Researcher

Background

Problem

Solution

Conclusion

FinSpy Mobile: iOS and Apple UDID leak

by Alex Radocea, Sr. Engineer

Privilege Escalation Mechanism?

Persistence mechanism?

Takeaways

CrowdRE: Alpha++ Release

by Adam Meyers, Director of Intelligence

Alpha++ Release

Mac/Linux Versions

Groups

Private Commits

Karma

Upcoming Black Hat USA 2012: Android 4.0.1 Exploitation

by Georg Wicherski, Senior Security Researcher

Streamlining the Reverse Engineering Process with CrowdRE

by Jason Geffner, Senior Security Researcher

Background

First Analyst's Workflow

Second Analyst's Workflow

Conclusion

REcon CrowdRE Presentation

Be Social. Use CrowdRE.

Join the Crowd!

by Georg Wicherski, Senior Security Researcher

CrowdStrike Intelligence - Adversary-based Approach

by Adam Meyers, Director of Intelligence.

Treating the problem, not the symptoms

Intelligence Enhanced Security

Global View

Adversary Differentiation

Intelligence as a Service

CrowdStrike Services Bolsters Services Leadership With The Addition of Wendi Rafferty, VP of Services

ARMv7/Thumb2 Inline Code Hooking

by Georg Wicherski, Senior Security Researcher

CrowdStrike Services: My New Mission

Kelihos.C: Same Code, New Botnet

by Tillmann Werner, Senior Security Researcher

P2P Botnet Kelihos.B with 100.000 Nodes Sinkholed

CrowdStrike Launch

by George Kurtz, President & CEO

CrowdStrike launches in stealth-mode with $26 million Series A round led b Warburg Pincus

IDENTIFY: NEW Offerings from CrowdStrike Services