Blogs
All Blogs
Greg Hoglund
Rich Cummings
Jim Butterworth
Chris Harrison
Jeremy Flessing
Charles Copeland
Michael Snyder
Martin Pillion
Jim Richards
Shawn Bracken
Scott Pease
Page 1 of 8

APT and the Oil Industry

At HBGary, we have been tracking numerous APT groups that are above and beyond the “dirty dozen” -- the dozen or so code-named APT groups that focus on the defense industrial base. In particular, we have been tracking two organized groups that are focused entirely on the Oil and Gas sector.  The commonly–held belief is that these groups are in fact state-sponsored and mission-oriented to support an emerging country’s global energy growth.  We began tracking one of these groups before the Night Dragon attack was made public.  The second group came to light in the months that followed, perhaps as a result of the Night Dragon report causing many organizations to take a closer internal look.  Surprising (or not), a new APT group did emerge, with the investigation revealing they had enjoyed firm entrenchment for quite some time.  Both of these groups are confined entirely to the energy space, but not to any particular region.  They have command-and-control access into many transnational corporations, some of which are headquartered here in the United States and some as far away as the Middle East.


One could only presume what they are after.  The layered defensive ring topology of a critical infrastructure does afford some basic isolation, but not until you discover which ring the attacker has penetrated can you determine what it is they are in pursuit of.  Make no mistake: it is information that you would not want otherwise disclosed.   The motives behind the attacker’s operation run the “FUD” gamut from creating rolling blackouts along the Eastern Seaboard during a harsh winter, obtaining user manuals, schematic diagrams, to plant operations configurations. 


A disturbing recent trend, however, has been the shift in the selected target set from high-level executives to entire departments.  One exponentially targeted more than others.  If you are puzzled which, simply ask yourself which department is involved in every future endeavor, all contractual negotiations, all ongoing litigation …if you guessed Legal, you would be correct.


Stuxnet and Duqu definitely garnered a lot of press.  I believe, however, the more insidious threat are the undetected APT groups quietly and contently residing within your network.    
Posted by Jim Butterworth on February 21, 2012 at 10:44am

APT and the Five Eyes Nations

Discussions around APT tend to focus on its impact to the manufacturing and defense contractors which comprise the U.S. Defense Industrial Base.  HBGary currently monitors about 18 APT groups, and trends in our data suggest that APT is not just a U.S.-centric problem. Late last year HBGary discovered that at least one APT group we track is now attacking Military Industrial Complex targets in the U.K. and New Zealand whose profiles are similar to its U.S. targets. This APT group is one of the more prolific we track and has a long history of intrusions into U.S. defense contractors.

 Until recently, this APT group has focused only on U.S. targets; all told, the group currently has more than 40 government and defense victims. They have brought online new command and control channels, allowing them to attack many new U.S. targets, as well as at least one government facility in the UK and a defense-related corporation operating in New Zealand. This may indicate an expansion in their mission objectives to include Defense Industrial Base targets within all of the “Five Eyes” nations (Australia, New Zealand, Canada, United Kingdom, and United States). As we see global companies acquire the interests of other global companies, this globalization of the APT threat will only accelerate.  

Posted by Scott Pease on February 9, 2012 at 10:14am

Further investigation of the Zero Access rootkit

In a previous blog I explored the methods and techniques that Zero Access uses to hook kernel functions.  One of the functions I mentioned was IoIsOperationSynchronous, which caught the eye of an astute reader.  Why does Zero Access hook IoIsOperationSynchronous? 

Hooked IoIsOperationSynchronous:

804EE549   loc_804EE549:
804EE549       call 0xF78D40F5   // call Hook_Implementation
 
804EE54E   Subroutine IoIsOperationSynchronous:
804EE54E       jmp 0x804EE549    // Jump to Hook call
 
804EE550   loc_804EE550:
804EE550       push ebp
804EE551       mov ebp,esp

Initially, I thought it was because IoIsOperationSynchronous is called by many system threads and would provide a method to obtain consistent time slices from the system without creating a new system thread.  However, there are many kernel functions that would serve the same purpose, so why hook IoIsOperationSynchronous?  

IoIsOperationSynchronous does have the added benefit of providing access to many of the system's IRPs, especially file system IRPs.  When I examined the code run by the hook, Zero Access uses the IRP passed into IoIsOperationSynchronous.

F78D40F5   Subroutine Hook_Implementation:
F78D40F5       pushad
F78D40F6       mov ecx,dword ptr [esp+0x28]  // obtain pIrp passed into IoIsOperationSynchronous
F78D40FA       call 0xF78CF940               // call IrpHandler
 
F78D40FF   loc_F78D40FF:
F78D40FF       popad
F78D4100       add dword ptr [esp],0x2       // Increment the return address by 2 so we skip over the hook jmp code
F78D4104       ret

What is located at [esp+0x28]?  Let's examine the stack after the pushad instruction::

esp+00 [edi]
esp+04 [esi]
esp+08 [ebp]
esp+0c [esp]
esp+10 [ebx]
esp+14 [edx]
esp+18 [ecx]
esp+1c [eax]
esp+20 [804EE54E]   // ret address to IoIsOperationSynchronous
esp+24 [xxxxxxxx]   // ret address to caller of IoIsOperationSynchronous
esp+28 [pIRP]       // arg0 = pIrp

There is the IRP.  Just glancing at the IrpHandler() function, the use of "%u.exe" and string comparison stand out immediately.  Is it checking the process name?

F78CF940   Subroutine IrpHandler
F78CF940       mov eax,dword ptr [ecx+0x60]  // pIrp->Tail.Overlay.CurrentStackLocation
F78CF943       sub esp,0x50                  // make space on the stack for some local variables
F78CF946       cmp byte ptr [eax],0x0
F78CF949       jne 0xF78CF9C2

ECX is the IRP pointer passed into IoIsOperationSynchronous.  ECX+60 is the offset for pIrp->Tail.Overlay.CurrentStackLocation, so this initial block of code is behaving like IoGetCurrentIrpStackLocation().

F78CF94B   loc_F78CF94B:
F78CF94B       push esi
F78CF94C       mov esi,dword ptr [eax+0x18]  // obtain IoStackLocation->FileObject
F78CF94F       test esi,esi
F78CF951       je 0xF78CF9C1

The FileObject member of the stack location is retrieved.

F78CF953   loc_F78CF953:
F78CF953       mov eax,dword ptr [0xF78D9984]   // data_F78D9984
F78CF958       not eax
F78CF95A       push eax
F78CF95B       lea ecx,[esp+0x18]
F78CF95F       push 0xF78D74A8                  // %u.exe
F78CF964       push ecx
F78CF965       call dword ptr [0xF78D7084]      // __ptr_ntoskrnl.exe!swprintf[80536BA5]

Zero Access creates a wide string buffer with "%u.exe" formatting.  The parameter supplied to printf for the %u is a dword equivalent for the usermode component's name.  For example: 

NOT 0xA0B8A151
= 0x5F475EAE
= 1598512814 in decimal, so the zero Access usermode component's process (and file) name is 1598512814.exeA5]
 
This could be used as a file name or a process name comparison. 

F78CF96B   loc_F78CF96B:
F78CF96B       movzx ecx,word ptr [esi+0x30] // length of target filename from FileObject->FileName.Length
F78CF96F       add eax,eax
F78CF971       add esp,0xC
F78CF974       lea edx,[esp+0x14]            // ptr to swprintf dest buffer
F78CF978       mov word ptr [esp+0xC],ax     // set length
F78CF97D       mov word ptr [esp+0xE],ax     // set max length
F78CF982       mov dword ptr [esp+0x10],edx  // set ptr
F78CF986       cmp cx,ax                     // Is caller target filename long enough?
F78CF989       jb 0xF78CF9C1

Obtains the FileObject->FileName.Length field and uses that to validate the string lengths before doing the actual string comparison.  The block also sets up a UNICODE_STRING on the local stack.

F78CF98B   loc_F78CF98B:
F78CF98B       mov edx,dword ptr [esi+0x34]  // ptr to target filename buffer
F78CF98E       mov word ptr [esp+0x4],ax
F78CF993       mov word ptr [esp+0x6],ax
F78CF998       movzx eax,ax
F78CF99B       sub edx,eax
F78CF99D       movzx eax,cx
F78CF9A0       add edx,eax
F78CF9A2       push 0x1
F78CF9A4       lea ecx,[esp+0x8]
F78CF9A8       mov dword ptr [esp+0xC],edx
F78CF9AC       push ecx
F78CF9AD       lea edx,[esp+0x14]
F78CF9B1       push edx
F78CF9B2       call dword ptr [0xF78D7028]   // __ptr_ntoskrnl.exe!RtlEqualUnicodeString[805D67A2]

Compare the FileObject Name from the IRP to the manually constructed string.

F78CF9B8   loc_F78CF9B8:
F78CF9B8       test al,al
F78CF9BA       je 0xF78CF9C1     // jmp if RtlEqualUnicodeString returned 0 (strings are not equal)
 
F78CF9BC   loc_F78CF9BC:
F78CF9BC       call 0xF78CD650   // call Handle_ZeroAccess_UserModeComponent_IRP
 
F78CF9C1   loc_F78CF9C1:
F78CF9C1       pop esi
 
F78CF9C2   loc_F78CF9C2:
F78CF9C2       add esp,0x50
F78CF9C5       ret

If the strings match,  Handle_ZeroAccess_UserModeComponent_IRP is called.  Otherwise the function returns without doing anything.
 
So now the question is, what does Handle_ZeroAccess_UserModeComponent_IRP do?  Is it trying to block file access to the user mode component's file?  Is it using this as a usermode->kernelmode communication mechanism?  Or is it returning false data for file reads to prevent AV detection?
 
To be continued in my next blog...

Posted by Martin Pillion on February 7, 2012 at 5:53pm

The Benefits of SIEM for the CISO

A few years ago, the way companies dealt with malware threats was reactive. Once malware was discovered, they would simply re-image the infected machine. These days that approach is not effective. Once the attacker is able to escalate his privilege, he no longer needs the malware he used to gain access to the network. Wiping the machine just provides a false sense of security.

A more proactive approach is to have several point solutions for network security – an intrusion prevention system protecting the network and an anti-virus solution protecting your servers and end-nodes. A drawback of all these point products is that incident responders are forced to view the intelligence they gather within the context of each individual product – there is no consolidated view. This is where Security Information and Event Management (SIEM) systems are useful.

At their most basic, SIEMs present a summary view of events from various hardware and applications throughout the enterprise. The newest incarnations not only collect log events, but also perform analysis on the data, allow for reporting, and track compliance with government regulations. The advantage of the SIEM solution to the CISO is that if their security applications have created a connector to the SIEM, his team can see summary events and logs from multiple security products. This means that it takes less time to collect the threat intelligence they need. In addition, they can correlate events from multiple sources and see connections that may have been impossible to spot with separate logs.

HBGary recently integrated its flagship product, Active Defense™, with HP Enterprise Security’s ArcSight Security Information and Event Management (SIEM) solutions. Active Defense monitors physical memory for compromise by malware on hosts throughout the enterprise. It analyzes the memory image using HBGary’s Digital DNA™ and assigns each running binary a score based on the sequence of behavioral traits the binary exhibits. For example, a trait could be the ability of the binary to survive reboot, or examine details of another running process. Each of these traits on their own may be legitimate behaviors, but taken together, they could be a security threat. Active Defense™ is able to send all of its system- and user-events to ArcSight.

Active Defense™ logs every action a user takes on the server, such as scheduling a new scan job. It also logs system events such as scan kick-off and completion. For example, a system event might show that a particular Digital DNA™ scan ran against a set of monitored nodes and the highest scoring machine was “JDOE_Laptop,” with a score of 55.0. An ArcSight user can take the threat intelligence gathered by Active Defense™ and couple it with additional information. For example, extracted command-and-control information can be cross-referenced against DNS logs or the intrusion detection systems. From this, they can potentially determine when the suspicious binary was added to the system and where it came from. This ability to connect third-party products through easy-to-implement connectors clearly benefits the SIEM’s end-user.

There are a lot of vendors in the market with deep experience in small segments of the security space. Being able to bring that varied threat intelligence together in one central view has the potential to vastly speed up the process of kicking the attackers out of the network and at the same time provides an improved ROI for all the products in your arsenal.

For more information on how HP Enterprise Security and HBGary can help your organization detect the latest advanced persistent threats (APT), check out our recent announcement regarding our partnership at http://bit.ly/mUPz8p.

Posted by Scott Pease on January 31, 2012 at 9:23am
Page 1 of 8