McAfee » Peter Szor http://blogs.mcafee.com Blog Central Mon, 22 Sep 2014 19:57:08 +0000 en-US hourly 1 Emerging ‘Stack Pivoting’ Exploits Bypass Common Security http://blogs.mcafee.com/mcafee-labs/emerging-stack-pivoting-exploits-bypass-common-security http://blogs.mcafee.com/mcafee-labs/emerging-stack-pivoting-exploits-bypass-common-security#comments Mon, 06 May 2013 20:38:18 +0000 http://blogs.mcafee.com/?p=24435 [This blog was primarily written by Xiaoning Li of Intel Labs, with assistance from Peter Szor of McAfee Labs.] In February 2013, the Adobe Product Security Incident Response Team (PSIRT) released security advisory APSA13-02. In that report they listed two vulnerabilities (CVE-2013-0640 and CVE-2013-0641) that were widely exploited. At Intel Labs and McAfee Labs we […]

The post Emerging ‘Stack Pivoting’ Exploits Bypass Common Security appeared first on McAfee.

]]>
[This blog was primarily written by Xiaoning Li of Intel Labs, with assistance from Peter Szor of McAfee Labs.]

In February 2013, the Adobe Product Security Incident Response Team (PSIRT) released security advisory APSA13-02. In that report they listed two vulnerabilities (CVE-2013-0640 and CVE-2013-0641) that were widely exploited. At Intel Labs and McAfee Labs we ran some further analysis of these exploits and want to share some of the interesting details we discovered.

Based on information from the PSIRT, both vulnerabilities will impact all versions of Adobe Reader from 9.x to 11.x. (Some Acrobat versions are also vulnerable.) We verified this claim and found the sample affected all of them.

Szor ROP1

Attack Path

The exploit is spread by a malicious PDF file. When Reader opens the PDF file, it will trigger the vulnerability and start the exploit. This PDF file delivers a very complex attack, bypassing the current Adobe sandbox mechanism to launch the malware.

This flow shows the basic steps for the attack path:

Szor ROP2

The files D.T and L2P.T are DLLs in a sandboxed temp path, as in the following:

Szor ROP3

A new PDF is created in the normal temp path:

Szor ROP4

The new PDF, Visaform Turkey, will appear to hide the exploitation. The exploit uses a lot of memory in the background.

Szor ROP5

 

First Exploit

The PDF’s first exploit uses a heap overflow to overwrite a virtual function pointer, and also uses a memory information leak to bypass the address space layout randomization (ASLR) protection in Windows. Return-oriented programming is used to bypass data execution prevention (DEP).

Let’s sidetrack for a moment and look at two definitions: Return-oriented programming (ROP) is an exploit technique in which an attacker controls the call stack to indirectly execute arbitrary intended or unintended code to deliver an attack, thereby bypassing security features such as DEP. Stack pivoting is a common technique used by ROP-based exploits. Pointing the stack pointer to an attacker-owned buffer, such as the heap, will provide more flexibility for the attacker to carry out a complex ROP exploit.

Here’s how the exploit works from the first trigger point. The vulnerability is in AcroForm.api. After the exploit prepares customized stack data on the heap, the data triggers the exploit via following instructions in AcroForm.api.

Szor ROP6

With a modified virtual function pointer, the instruction calls into a special ROP gadget, which will start pivoting.

The address for the first gadget is 0x209b9f50. Here’s the original code:

Szor ROP7

But if we decode from 0x209b9f50, the code piece looks like what follows. This is the ROP gadget for stack pivoting:

Szor ROP8

Now the stack points to a fake stack in the heap. The code log in a debugger at runtime looks like this:

Szor ROP9

Once the customized stack works, it will start more ROP gadgets. When the next Ret instruction is called, the stack looks like this:

Szor ROP10

What’s the instruction for 0x6acc1049? It is offset 0×1049 from AcroForm.api because 0x6acc00 is the base address for the target module. Here is the unintended ROP gadget again:

Szor ROP11

The decoded ROP gadget is just a Ret instruction:

Szor ROP12

It will repeat from stack 0x11849a34 to stack 0x1184beb4, a whopping 9,344 (0×2480) times!

Let’s see what the stack content is now:

Szor ROP13

The next gadget will move the esp register to esi. It will control the stack itself.

Szor ROP14

The gadget still includes lots of return addresses with repeated patterns, such as these:

Szor ROP15

With related code pieces:

Szor ROP16

Szor ROP17

Szor ROP18

So the logic will write target memory with values in the ecx register. The same pattern will repeat many times to modify 0x6b55e001, which is the beginning of the data section of AcroForm.api.

Szor ROP19

The data from 0x6b55e001 to 0x6b55e04e is modified and writes several API/DLL names into the area of 0x6b55e001:

  • GetTempPathA
  • Fwrite
  • Wb
  • CryptStringToBinaryA
  • Ntdll
  • RtlDecompressBuffer
  • Wcsstr

These strings are later used as parameters, during ROP-based API calls. After writing these strings into the data section, the ROP code continues with the following gadgets:

Szor ROP20

We can list the first piece of an ROP gadget step by step. The following code moves [esp] to ecx:

                                                                  6b218551

1184c074  cccc0240 6b022c74 6b19567b 6ad6ed72

1184c084  6b19567b 6b237664

 

6b218551 58              pop     eax

6b218552 c3              ret

 

6b022c74 0fb7c0       movzx   eax,ax

6b022c77 c3              ret

 

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

 

6ad6ed72 01f7           add     edi,esi

6ad6ed74 c3              ret

 

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

 

6b237664 91              xchg    eax,ecx

6b237665 c3              ret

The following code moves the pointer to eax, and then writes [eax] with the previous value in ecx:

                                                    6b218551 cccc023c

1184c094  6b022c74 6b19567b 6ad6ed72 6b1d943b

1184c0a4  6b16d51a

 

6b218551 58              pop     eax

6b218552 c3              ret

 

6b022c74 0fb7c0       movzx   eax,ax

6b022c77 c3              ret

 

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

 

6ad6ed72 01f7           add     edi,esi

6ad6ed74 c3              ret

 

6b1d943b 57              push    edi

6b1d943c 58              pop     eax

6b1d943d c3              ret

 

6b16d51a 8908          mov     dword ptr [eax],ecx

6b16d51c c3              ret

The following code gets the LoadLibraryA() API pointer from the import table:

1184c0a4                                                        6b218551 6b32b234 6b1d92ac

6b218551 58              pop     eax

6b218552 c3              ret

6b1d92ac ff10            call    dword ptr [eax]

6b1d92ae c3               ret

At this point, the stack keeps the parameter for LoadLibraryA(). This is actually a string for MSVCR100.dll in the “idata” section.

Once the MSVCR100.dll handle is available via LoadLibraryA(), the following code writes the handle to the target address in the heap (actually the fake stack), which is used to call GetProcAddress() as the first parameter. The address is 0x1184c0e4.

1184c0b4                   6b237664 6b218551 cccc022c

1184c0c4  6b022c74 6b19567b 6ad6ed72 6b1d943b

1184c0d4  6b16d51a

 

6b237664 91              xchg    eax,ecx

6b237665 c3              ret

 

6b218551 58              pop     eax

6b218552 c3              ret

 

6b022c74 0fb7c0       movzx   eax,ax

6b022c77 c3              ret

 

6b19567b 97              xchg    eax,edi

6b19567c c3              ret

 

6ad6ed72 01f7           add     edi,esi

6ad6ed74 c3              ret

 

6b1d943b 57              push    edi

6b1d943c 58              pop     eax

6b1d943d c3              ret

 

6b16d51a 8908          mov     dword ptr [eax],ecx

6b16d51c c3              ret

Next the process calls the following gadgets to get function pointers for the wcsstr function. The first parameter is a DLL handle received from previous gadgets.

1184c0d4                    6b218551 6b32b1ec 6b1d92ac

 

6b218551 58              pop     eax

6b218552 c3              ret

 

6b1d92ac ff10            call    dword ptr [eax]

6b1d92ae c3              ret

Now it’s time to call the function with the jmp eax gadget.

1184c0e4                     6acce598

 

6acce598 ffe0            jmp     eax {MSVCR100!wcsstr (6c5f20f1)}

Here the code searches for the string “MODULE” from the heap or the fake stack. There is a long string in the heap following the “MODULE” signature. This is the encoded and compressed DLL D.T. With more gadgets, the code calls CryptStringToBinaryA() to convert this string to binary, and then calls RtlDecompressBuffer() to decompress the binary to the real D.T binary code in memory.

Similar ROP gadgets get ntdll.dll and related API addresses, for example, RtlDecompressBuffer() and CryptStringToBinaryA(). Finally, the ROP gadget calls GetTempPathA() to get the current temp path, the sandboxed path. It will create D.T under this path and call LoadLibraryA() to run the D.T. module.

D.T creates two threads. One shows error messages. The second creates and loads the DLL L2P.T, which exploits the second vulnerability to load L2P.T into a nonsandboxed acrord32 process. Finally this process terminates.

Szor ROP21

 

Second Exploit

The second exploit triggers the vulnerability at acrord32.exe:

Szor ROP22

Due to a heap overflow, the eax register calls to the stack-pivoting ROP gadget.

Szor ROP23

A few more ROP gadgets after stack pivoting load L2P.T in the same process. L2P.T creates another DLL, langbar.dll, which downloads the rest of the malware.

No Shell

After we reviewed all of the exploit code and corresponding ROP, we found that this exploit does not use any traditional shellcode. All API calls use the fake stack from the stack pivoting.

Mitigation

Stack pivoting is a very common technique to allow an exploit to run powerful gadgets with a fake stack. For this kind of complex case, it’s very hard to create a customized stack within the real stack instead of within a fake stack. Once an exploit can do stack pivoting, it can bypass different defense mechanisms. Evolving security solutions need to address this attack pattern. Stack pivoting creates a very complex ROP attack and is a good example of how exploitation techniques continue to evolve. This successful exploit bypasses both Adobe client security features and basic Windows DEP and ASLR defenses.

We thank our colleagues Haifei Li, Bing Sun, Xiaobo Chen, and Chong Xu for their help with this analysis.

 

 

The post Emerging ‘Stack Pivoting’ Exploits Bypass Common Security appeared first on McAfee.

]]>
http://blogs.mcafee.com/mcafee-labs/emerging-stack-pivoting-exploits-bypass-common-security/feed 0
Spreading the Flame: Skywiper Employs ‘Windows Update’ http://blogs.mcafee.com/mcafee-labs/spreading-the-flame-skywiper-employs-windows-update http://blogs.mcafee.com/mcafee-labs/spreading-the-flame-skywiper-employs-windows-update#comments Mon, 04 Jun 2012 21:42:42 +0000 http://blogs.mcafee.com/?p=16627 Microsoft has issued Security Advisory 2718704, in which the company disclosed that it recently became aware of the Flamer/Skywiper threat, which uses certificates derived from the Microsoft Certificate Authority. The actual certificate in question was used to sign at least one of the attack components associated with the module in the Skywiper framework. This is […]

The post Spreading the Flame: Skywiper Employs ‘Windows Update’ appeared first on McAfee.

]]>
Microsoft has issued Security Advisory 2718704, in which the company disclosed that it recently became aware of the Flamer/Skywiper threat, which uses certificates derived from the Microsoft Certificate Authority.

The actual certificate in question was used to sign at least one of the attack components associated with the module in the Skywiper framework.

This is how the digital certificate looks like on the module:

The certificate was valid between February 19, 2010 to February 19, 2012, in the Pacific time zone. (Other certificates might have been issued in a similar manner.)

Clearly, the certificate has been valid for the last two years. In an earlier blog, we hinted that this attack might involve digital certificates on some of its components. It is possible that other components also used digital signatures to carry out variations of this attack.

Further investigation of the downloader component shows that it was compiled on December 27, 2010, also Pacific time.

File Header:

Machine: 014C (i386)

Number of Sections: 0004

TimeDateStamp:      4D1894AE -> Mon Dec 27 07:29:18 2010

A SigCheck from the SysInternals suite shows the following information on the attack component:

Verified:       Signed

Signers:

MS

Microsoft LSRA PA

Microsoft Enforced Licensing Registration Authority CA

Microsoft Enforced Licensing Intermediate PCA

Microsoft Root Authority

Signing date:   8:54 AM 12/28/2010

Publisher:      n/a

Description:    n/a

Product:        n/a

Version:        n/a

File version:   n/a

The certificate used to sign this file was originally issued by a Terminal Server Licensing Intermediate Certificate Authority. That means the certificate was supposed to be used only to authenticate users connecting to the Terminal Server but, due to a mistake in the CA configuration, it could be used to sign code, too.

Further research from Microsoft says the digital certificate used in the Windows Update attack required a forged certificate to be accepted by Windows Vista and later versions. The configuration error allows the certificate to be used for code signing only in versions prior to Vista. The attacker must to perform a chosen prefix collision attack targeting an MD5 hash to create a forged certificate and make it acceptable for Vista and later. Years ago a paper titled “MD5 Considered Harmful Today” authored by Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik and Benne de Weger described a very similar attack on x.509 certificates. However in a new presentation on the subject there appear to be key differences in this implementation and is possibly an entirely different work.

Microsoft’s revocation of this Intermediate CA does not affect the trustworthiness of any other certificate issued by Microsoft itself. Only certificates issued to users of Terminal Server would need to have their certificates reissued by their system admins.

To pull off this attack, the worm module creates a server called MSHOME-F3BE293C on the infected machine, and intercepts Windows update requests from nearby machines if the network settings allow a Windows update “proxy” using the Web Proxy Auto-Discovery Protocol. The server supplies a signed executable within CAB packages for Windows Update on the local network. (Such redirection attack opportunities have been discussed publicly, many times.) This step facilitates the infection of the local network, with a very silent, “below the radar” distribution mechanism.

An updated map of Skywiper infections based on our current information looks like this:

The targeted attacks of this threat are limited to a few individuals, organizations, and institutions, with the largest infection numbers reported from Iran.

The post Spreading the Flame: Skywiper Employs ‘Windows Update’ appeared first on McAfee.

]]>
http://blogs.mcafee.com/mcafee-labs/spreading-the-flame-skywiper-employs-windows-update/feed 0
Jumping Into the Flames of Skywiper http://blogs.mcafee.com/mcafee-labs/jumping-in-to-the-flames-of-skywiper http://blogs.mcafee.com/mcafee-labs/jumping-in-to-the-flames-of-skywiper#comments Wed, 30 May 2012 02:13:17 +0000 http://blogs.mcafee.com/?p=16493 There has been quite a bit of analysis and speculation about the Flamer/Skywiper threat. As we started to analyze this threat, we knew from the very beginning that this was going to be a giant undertaking and potentially very long term. Now we want to pause to help the people we protect visualize the kind […]

The post Jumping Into the Flames of Skywiper appeared first on McAfee.

]]>
There has been quite a bit of analysis and speculation about the Flamer/Skywiper threat. As we started to analyze this threat, we knew from the very beginning that this was going to be a giant undertaking and potentially very long term. Now we want to pause to help the people we protect visualize the kind of task at hand when dealing with the level of complexity and encryption that this threat presents.

Here are some quick facts about this threat: The main module has been decompiled to about 650,000 lines of C code.

Yes, you read that number right.

All indications are that this is not all the code in the malware and that it possibly extends to a good 750,000 lines of C code. It is fair to say that we are looking at a long-term analysis to determine its full set of functionality and features.

Here is a diagram that illustrates the relationships of the code up to this point of analysis:

(If you see a twister hovering, your eyes are not deceiving you! This threat has some complex relationships.)

There is a lot of code to this threat, and IDA (a pro disassembler and decompiler we use) does a decent job of keeping up, and helped us create the graph above. And this is not all the code but simply the main module! This module alone has about 4,400+ calls to string deobfuscator routines. Essentially, when the code has an interesting string such as “flame::beetlejuice::BeetleJuiceDataCollector,” or “flame::gator::GatorCmdFetcher,” it encapsulates the information in a sealed function. This adds extra “fat” to the already monstrous code, and makes it a lot more challenging to read. Not that it wasn’t big enough already!

The extraordinary amount of obfuscation in the code ensures that the functionality of the executable is not only hard to understand but also helps reduce the risk that one could capture the code and easily use it for one’s own needs.

The code carries all the library code it needs: SSH, ZLib routines, web server code, etc. At this point, there are more than two dozen encryption functions–such as Blowfish routines, MD5/MD4, and others.

Skywiper seems to focus on accessing information meaningful to professional surveillance needs and operations. Some of these functions include::

- It has low-level disk-access parsing, for file system parsing and access
- It supports ZIP file parsing
- It supports parsing multiple documents formats such as PDF, Microsoft Word, and other Office formats
- It is interested in notes, and searches even hidden places within the OS
- It is curious about what is on the target’s desktop
- It has functionality to remotely spread itself within a domain
- The malware is also very careful to get this information back to the control server: It does this by silently firing up extra instances of Internet Explorer, and injects code into them. This way it can be part of a “trusted” process on the machine, allowing it to circumvent personal firewalls.
- Maybe most important, it is interested in mobile devices. This is what the Beetlejuice module does. This “ghost in the machine” discovers Bluetooth devices, and shows interest in the target’s social network, by looking for contacts. It also does this locally, as device information can be found in files, or on the host when the information is synched to it. As of this analysis, it targets Sony and Nokia device contacts. And certainly there could be more here than quickly meets the eye!

Other routines and calls include:

FLAME – Handles AutoRun-infection routines
WEASEL – Handles disk-parsing routines
JIMMY – File parsing support
TELEMETRY – Control server reporting and handling
SUICIDE – Self-termination routine
EUPHORIA – Various exploit modules
BEETLEJUICE – Interface and control for Bluetooth devices
BUNNY – Research continues…
PLATYPUS – Research continues…
CLAN – Lua Module, possibly related to remote target exploits
FROG – Password-stealer module
CRUISE – Handles NT domain-parsing routines
DRILLER – Research continues…
AUDITION – Process termination, AV/security product processes
GATOR – Handles control server communication
LIMBO – Research continues…
MICROBE – Microphone/Audio capture and recording
SNACK – research continues….
MUNCH – Handles network-related tasks; appears to be sniffing
VIPER – Screenshot module
HEADACHE – Research continues…

That is a long list, and there is still more to come. Certainly, Skywiper shows significant development. We still need to dig into these modules some more; but one thing is certain, this analysis will be long term.

In the early 1990s, virus analysis became a “100 meter tournament,” as we jokingly used to call it. By that we mean looking at assembly printouts of the actual code took about 100 meters of printer paper. In the case of Flamer/Skywiper, this would be a mile-long walk!

This will keep us in shape for some time.

The post Jumping Into the Flames of Skywiper appeared first on McAfee.

]]>
http://blogs.mcafee.com/mcafee-labs/jumping-in-to-the-flames-of-skywiper/feed 0
Skywiper – Fanning the ‘Flames’ of Cyberwarfare http://blogs.mcafee.com/business/security-connected/skywiper-fanning-the-flames-of-cyber-warfare http://blogs.mcafee.com/business/security-connected/skywiper-fanning-the-flames-of-cyber-warfare#comments Mon, 28 May 2012 17:30:10 +0000 http://blogs.mcafee.com/?p=16413 A few weeks ago, Iran reported intensified cyberattacks on its energy sector that they observed as a direct continuation of the Stuxnet and Duqu attacks. Over the weekend, the IR Cert (Iran’s emergency response team) published a new report that describes this attack as Flame and/or Flamer. Some other news agencies also called  the attack […]

The post Skywiper – Fanning the ‘Flames’ of Cyberwarfare appeared first on McAfee.

]]>
A few weeks ago, Iran reported intensified cyberattacks on its energy sector that they observed as a direct continuation of the Stuxnet and Duqu attacks.

Over the weekend, the IR Cert (Iran’s emergency response team) published a new report that describes this attack as Flame and/or Flamer. Some other news agencies also called  the attack Viper. The complex functionality of the malware is controlled by command servers, of which there are possibly dozens. The malware is also capable of slowly spreading via USB drives.

CrySys Lab, a Hungarian security team, noticed that a complex threat it had been analyzing for weeks was clearly the same threat as Flamer. They published a large, preliminary document, several dozen pages in size, that described the complex malware. The report shows that a lot more work has to be done to analyze the full details of this malware, as it has some extraordinary complexity.

Previously, other cyberthreats such as Stuxnet and Duqu required months of analysis; this threat is clearly a magnitude more complex. Just to give an idea of the complexity, one of its smallest encrypted modules is more than 70,000 lines of C decompiled code, which contains over 170 encrypted “strings”!

Evidently, the threat has been developed over many years, possibly by a large group or dedicated team.

We found publicly available reports from antispyware companies, and log files in public help forums that could indicate infections of early variants of Skywiper in Europe and Iran several years ago (for example, in March 2010). Skywiper appears to be more wildly spread than Duqu, with similarly large numbers of variants.

Skywiper is a modular, extendable, and updateable threat. It is capable of, but not limited to, the following key espionage functions:

- Scanning network resources
- Stealing information as specified
- Communicating to control servers over SSH and HTTPS protocols
- Detecting the presence of over 100 security products (AV, antispyware, FW, etc)
- Using both kernel- and user-mode logic
- Employing complex internal functionality using Windows APC calls and and threads start manipulation, and code injections to key processes
- Loading as part of Winlogon.exe and then injecting itself into Internet Explorer and services
- Concealing its presence as ~ named temp files, just like Stuxnet and Duqu
- Capable of attacking new systems over USB flash memory and local network (spreading slowly)
- Creating screen captures
- Recording voice conversations
- Running on Windows XP, Windows Vista, and Windows 7 systems
- Containing known exploits, such as the print spooler and lnk exploits found in Stuxnet
- Using SQLite database to store collected information
- Using a custom database for attack modules (this is very unusual, but shows the modularity and extendability of the malware)
- Often located on nearby systems: a local network for both control and target infection cases
- Using PE-encrypted resources

To summarize, the threat shows great similarity to Stuxnet and Duqu in some of its ways of operation, yet its code base and implementation are very different, and much more complex and robust in its basic structure.

Skywiper’s main executable files:

Windows\System32\mssecmgr.ocx – Main module
Windows\System32\msglu32.ocx
Windows\System32\nteps32.ocx
Windows\System32\advnetcfg.ocx
Windows\System32\soapr32.ocx

Misleading Program Information Blocks

According to its program information block, the main module pretends to be written by Microsoft Corporation. It claims to be a “Windows Authentication Client” for Microsoft Windows Version 5.1 (2600 Build). Several other modules also claim to be Microsoft Windows components. However, none of the files analyzed so far are signed with a valid (or even possibly stolen) key, as it was the case with Duqu and Stuxnet.

Further key filenames of the threat can include:

~dra52.tmp
target.lnk
zff042
urpd.ocx
ccalc32.sys
boot32drv.sys
Pcldrvx.ocx
~KWI
guninst32
~HLV
~DEB93D.tmp
~DEB83C.tmp
~dra53.tmp
cmutlcfg.ocx
~DFL983.tmp
~DF05AC8.tmp
~DFD85D3.tmp
~a29.tmp
dsmgr.ocx
~f28.tmp
~dra51k.tmp
~d43a37b.tmp
~dfc855.tmp
Ef_trace.log
contents.btr
wrm3f0
scrcons.exe
wmiprvse.exe
wlndh32
mprhlp
kbdinai
~ZLM0D1.ocx
~ZLM0D2.ocx
sstab
~rcf0
~rcj0

Mutex usage

The threat files also use the TH_POOL_SHD_PQOISNG_#PID#SYNCMTX Mutex name to identify already infected systems, a common technique in modern malware. The #PID# is the process ID of the process in which the injection of the threat occurred.

I change my name; I change my extension

The threat files can change both filenames and extensions, according to specific control server requests, as well as configuration usage. In some cases, Skywiper detects specific antivirus software. The malware might then change the extension of the executable files (DLLs) from OCX to TMP, for example. However, we have not always seen this functionality on affected systems, especially if the threat has been installed prior to the security product in question.

Skywiper’s main module is over 6MB in size, while the completely deployed set is close to 20MB. Yes, this is a lot of code for malware, but this is necessary to carry the complex libraries such as Zlib, LUA interpreter, SQLite support, custom database support code, and so on.

Encryption includes simple obfuscation like XOR with a byte value. The XOR key, 0xAE, has appeared in some other cases–showing a potential relationship to Duqu and Stuxnet, as they also used this value. However, Stuxnet and Duqu always used other values in conjunction with this byte, which included dates of possible meaning.

Other than the above, Skywiper does not show a direct relationship in its code to Stuxnet or Duqu at this point. It uses a similar yet more complex structure, which in many ways reminds researchers of these attacks. In some ways it could be a parallel project, as the early date may suggest. The attack files showed recent development in January and August 2011, according to some of the leftover date values in its files. The dates in the file headers have been purposely changed (claiming to be from 1994, etc.), but export-table date values and dates elsewhere in the files indicate 2011.

The main module of Skywiper starts via the registry, over an exported function:

HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Authentication Packages
- mssecmgr.ocx

Initial infections gathered by our network sensors are shown on the map below:

Generally, attackers try to conceal their presence by infecting locations unrelated to the main targets, possibly to further conceal their identity, and then use these locations as control servers. Continuing research will certainly need to take this into consideration.

McAfee antivirus products will detect and clean the threat as W32/Skywiper from infected systems. Our initial data indicates that there are multiple variants of this threat in the field.

The post Skywiper – Fanning the ‘Flames’ of Cyberwarfare appeared first on McAfee.

]]>
http://blogs.mcafee.com/business/security-connected/skywiper-fanning-the-flames-of-cyber-warfare/feed 0
‘Hacktivity 2011′ Keynote Examines 25 Years of Malware http://blogs.mcafee.com/mcafee-labs/hacktivity-2011-keynote-examines-25-years-of-malware http://blogs.mcafee.com/mcafee-labs/hacktivity-2011-keynote-examines-25-years-of-malware#comments Fri, 09 Dec 2011 17:10:55 +0000 http://blogs.mcafee.com/?p=12835 In September, I had the pleasure of giving the keynote speech at “Hacktivity 2011″ in Budapest, Hungary. I was very excited to see the large audience, about 1,000 visitors, among them very serious and well-known security professionals, instructors, and security enthusiasts. It was also exciting for me because I made the presentation in my native […]

The post ‘Hacktivity 2011′ Keynote Examines 25 Years of Malware appeared first on McAfee.

]]>
In September, I had the pleasure of giving the keynote speech at “Hacktivity 2011″ in Budapest, Hungary. I was very excited to see the large audience, about 1,000 visitors, among them very serious and well-known security professionals, instructors, and security enthusiasts. It was also exciting for me because I made the presentation in my native Hungarian. I very much enjoyed the conference and was able to meet a lot of talented young security researchers.

The presentation was translated during the talk and the speech is also available in English. Do not be surprised by the fact that the introduction will be made by a male voice, followed by several translators in real time who had to put complex security terms in plain English, while I talked very fast!

The presentation covers several important developments and the history of the last 25 years of computer malware. It has been an exiting journey for me to dedicate a large part of my life to the problems of computer threats. The presentation also details industry control system attacks, their history, Stuxnet, and recent interesting fake AV and rootkit developments. Many of the techniques were not publicly discussed prior to my talk. Enjoy!

The English version:

And for those of you who would like to listen in Hungarian, the talk is available here:

Hacktivity 2011 – Szőr Péter: Küzdelem a kártékony kódok ellen

The post ‘Hacktivity 2011′ Keynote Examines 25 Years of Malware appeared first on McAfee.

]]>
http://blogs.mcafee.com/mcafee-labs/hacktivity-2011-keynote-examines-25-years-of-malware/feed 0