Archive

Archive for the ‘Zero-Day Exploit’ Category

Analyzing attacks that exploit the CVE-2021-40444 MSHTML vulnerability

September 15th, 2021 No comments

In August, Microsoft Threat Intelligence Center (MSTIC) identified a small number of attacks (less than 10) that attempted to exploit a remote code execution vulnerability in MSHTML using specially crafted Microsoft Office documents. These attacks used the vulnerability, tracked as CVE-2021-40444, as part of an initial access campaign that distributed custom Cobalt Strike Beacon loaders. These loaders communicated with an infrastructure that Microsoft associates with multiple cybercriminal campaigns, including human-operated ransomware.

The observed attack vector relies on a malicious ActiveX control that could be loaded by the browser rendering engine using a malicious Office document. Customers who enabled attack surface reduction rules to block Office from creating child processes are not impacted by the exploitation technique used in these attacks. While these attacks used a vulnerability to access entry point devices and run highly-privileged code, the secondary actions taken by the attackers still rely on stealing credentials and moving laterally to cause organization-wide impact. This illustrates the importance of investing in attack surface reduction, credential hygiene, and lateral movement mitigations. Customers are advised to apply the security patch for CVE-2021-40444 to fully mitigate this vulnerability.

This blog details our in-depth analysis of the attacks that used the CVE-2021-40444, provides detection details and investigation guidance for Microsoft 365 Defender customers, and lists mitigation steps for hardening networks against this and similar attacks. Our colleagues at RiskIQ conducted their own analysis and coordinated with Microsoft in publishing this research.

Exploit delivery mechanism

The initial campaigns in August 2021 likely originated from emails impersonating contracts and legal agreements, where the documents themselves were hosted on file-sharing sites. The exploit document used an external oleObject relationship to embed exploitative JavaScript within MIME HTML remotely hosted content that results in (1) the download of a CAB file containing a DLL bearing an INF file extension, (2) decompression of that CAB file, and (3) execution of a function within that DLL. The DLL retrieves remotely hosted shellcode (in this instance, a custom Cobalt Strike Beacon loader) and loads it into wabmig.exe (Microsoft address import tool.)

Screenshot of code showing the original exploit vector

Figure 1. The original exploit vector: an externally targeted oleObject relationship definition bearing an MHTML handler prefix pointed at an HTML file hosted on infrastructure that has similar qualities to the Cobalt Strike Beacon infrastructure that the loader’s payload communicates with.

Content that is downloaded from an external source is tagged by the Windows operating system with a mark of the web, indicating it was downloaded from a potentially untrusted source. This invokes Protected Mode in Microsoft Office, requiring user interaction to disable it to run content such as macros. However, in this instance, when opened without a mark of the web present, the document’s payload executed immediately without user interaction – indicating the abuse of a vulnerability.

diagram showing attack chain of DEV-0413 campaign that used CVE-2021-40444

Figure 2. Attack chain of DEV-0413 campaign that used CVE-2021-40444

DEV-0413 observed exploiting CVE-2021-40444

As part of Microsoft’s ongoing commitment to tracking both nation state and cybercriminal threat actors, we refer to the unidentified threat actor as a “development group” and utilize a threat actor naming structure with a prefix of “DEV” to indicate an emerging threat group or unique activity during the tracking and investigation phases before MSTIC reaches high confidence about the origin or identity of the actor behind an operation. MSTIC tracks a large cluster of cybercriminal activity involving Cobalt Strike infrastructure under the name DEV-0365.

The infrastructure we associate with DEV-0365 has several overlaps in behavior and unique identifying characteristics of Cobalt Strike infrastructure that suggest it was created or managed by a distinct set of operators. However, the follow-on activity from this infrastructure indicates multiple threat actors or clusters associated with human-operated ransomware attacks (including the deployment of Conti ransomware). One explanation is that DEV-0365 is involved in a form of command- and-control infrastructure as a service for cybercriminals.

Additionally, some of the infrastructure that hosted the oleObjects utilized in the August 2021 attacks abusing CVE-2021-40444 were also involved in the delivery of BazaLoader and Trickbot payloads — activity that overlaps with a group Microsoft tracks as DEV-0193. DEV-0193 activities overlap with actions tracked by Mandiant as UNC1878.

Due to the uncertainty surrounding the nature of the shared qualities of DEV-0365 infrastructure and the significant variation in malicious activity, MSTIC clustered the initial email campaign exploitation identified as CVE-2021-40444 activity separately, under DEV-0413.

The DEV-0413 campaign that used CVE-2021-40444 has been smaller and more targeted than other malware campaigns we have identified leveraging DEV-0365 infrastructure. We observed the earliest exploitation attempt of this campaign on August 18. The social engineering lure used in the campaign, initially highlighted by Mandiant, aligned with the business operations of targeted organizations, suggesting a degree of purposeful targeting. The campaign purported to seek a developer for a mobile application, with multiple application development organizations being targeted. In most instances, file-sharing services were abused to deliver the CVE-2021-40444-laden lure.

It is worth highlighting that while monitoring the DEV-0413 campaign, Microsoft identified active DEV-0413 infrastructure hosting CVE-2021-40444 content wherein basic security principles had not been applied. DEV-0413 did not limit the browser agents able to access the server to their malware implant or known targets, thereby permitting directory listing for their web server. In doing so, the attackers exposed their exploit to anyone who might have gained interest based on public social media discussion.

Screenshot of content of email in DEV-0413 campaign that used CVE-2021-40444

Figure 3. Content of the original DEV-0413 email lure seeking application developers

At least one organization that was successfully compromised by DEV-0413 in their August campaign was previously compromised by a wave of similarly-themed malware that interacted with DEV-0365 infrastructure almost two months before the CVE-2021-40444 attack. It is currently not known whether the retargeting of this organization was intentional, but it reinforces the connection between DEV-0413 and DEV-0365 beyond sharing of infrastructure.

In a later wave of DEV-0413 activity on September 1, Microsoft identified a lure change from targeting application developers to a “small claims court” legal threat.

Screenshot of another email lure used in the campaigns

Figure 4. Example of the “Small claims court” lure utilized by DEV-0413 

Vulnerability usage timeline

On August 21, 2021, MSTIC observed a social media post by a Mandiant employee with experience tracking Cobalt Strike Beacon infrastructure. This post highlighted a Microsoft Word document (SHA-256: 3bddb2e1a85a9e06b9f9021ad301fdcde33e197225ae1676b8c6d0b416193ecf) that had been uploaded to VirusTotal on August 19, 2021. The post’s focus on this document was highlighting the custom Cobalt Strike Beacon loader and did not focus on the delivery mechanism.

MSTIC analyzed the sample and determined that an anomalous oleObject relationship in the document was targeted at an external malicious HTML resource with an MHTML handler and likely leading to abuse of an undisclosed vulnerability. MSTIC immediately engaged the Microsoft Security Response Center and work began on a mitigation and patch. During this process, MSTIC collaborated with the original finder at Mandiant to reduce the discussion of the issue publicly and avoid drawing threat actor attention to the issues until a patch was available. Mandiant partnered with MSTIC and did their own reverse engineering assessment and submitted their findings to MSRC.

On September 7, 2021, Microsoft released a security advisory for CVE-2021-40444 containing a partial workaround. As a routine in these instances, Microsoft was working to ensure that the detections described in the advisory would be in place and a patch would be available before public disclosure. During the same time, a third-party researcher reported a sample to Microsoft from the same campaign originally shared by Mandiant. This sample was publicly disclosed on September 8. We observed a rise in exploitation attempts within 24 hours.

Line graph showing volume of observed exploitation attempts

Figure 5. Graphic showing original exploitation on August 18 and attempted exploitation increasing after public disclosure

Microsoft continues to monitor the situation and work to deconflict testing from actual exploitation. Since the public disclosure, Microsoft has observed multiple threat actors, including ransomware-as-a-service affiliates, adopting publicly disclosed proof-of-concept code into their toolkits. We will continue to provide updates as we learn more.

Mitigating the attacks

Microsoft has confirmed that the following attack surface reduction rule blocks activity associated with exploitation of CVE-2021-40444 at the time of publishing:

  • ​Block all Office applications from creating child processes

Apply the following mitigations to reduce the impact of this threat and follow-on actions taken by attackers.

  • Apply the security updates for CVE-2021-40444. Comprehensive updates addressing the vulnerabilities used in this campaign are available through the September 2021 security updates.
  • Run the latest version of your operating systems and applications. Turn on automatic updates or deploy the latest security updates as soon as they become available.
  • Use a supported platform, such as Windows 10, to take advantage of regular security updates.
  • Turn on cloud-delivered protectionin Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants.
  • Turn on tamper protectionin Microsoft Defender for Endpoint, to prevent malicious changes to security settings.
  • Run EDR in block modeso that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
  • Enable investigation and remediationin full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
  • Use device discoveryto increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.

Microsoft 365 Defender detection details

Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

Endpoint detection and response (EDR)

Alerts with the following titles in the security center can indicate threat activity on your network:

  • Possible exploitation of CVE-2021-40444 (requires Defender Antivirus as the Active AV)

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity and are not monitored in the status cards provided with this report.

  • Suspicious Behavior By Office Application (detects the anomalous process launches that happen in exploitation of this CVE, and other malicious behavior)
  • Suspicious use of Control Panel item

Microsoft Defender for Office365

Signals from Microsoft Defender for Office 365 informs Microsoft 365 Defender, which correlates cross-domain threat intelligence to deliver coordinated defense, that this vulnerability has been detected when a document is delivered via email when detonation is enabled.

The following alerts in your portal will indicate that a malicious attachment has been blocked,  although these alerts are also used for many different threats:

  • Malware campaign detected and blocked
  • Malware campaign detected after delivery
  • Email messages containing malicious file removed after delivery

Advanced hunting

To locate possible exploitation activity, run the following queries.

Relative path traversal (requires Microsoft 365 Defender)

Use the following query to surface abuse of Control Panel objects (.cpl) via URL protocol handler path traversal as used in the original attack and public proof of concepts at time of publishing:

DeviceProcessEvents
| where (FileName in~(“control.exe”,”rundll32.exe”) and ProcessCommandLine has “.cpl:”)
or ProcessCommandLine matches regex @'\".[a-zA-Z]{2,4}:\.\.\/\.\.'

 

The post Analyzing attacks that exploit the CVE-2021-40444 MSHTML vulnerability appeared first on Microsoft Security Blog.

Protecting customers from a private-sector offensive actor using 0-day exploits and DevilsTongue malware

July 15th, 2021 No comments

The Microsoft Threat Intelligence Center (MSTIC) alongside the Microsoft Security Response Center (MSRC) has uncovered a private-sector offensive actor, or PSOA, that we are calling SOURGUM in possession of now-patched, Windows 0-day exploits (CVE-2021-31979 and CVE-2021-33771).

Private-sector offensive actors are private companies that manufacture and sell cyberweapons in hacking-as-a-service packages, often to government agencies around the world, to hack into their targets’ computers, phones, network infrastructure, and other devices. With these hacking packages, usually the government agencies choose the targets and run the actual operations themselves. The tools, tactics, and procedures used by these companies only adds to the complexity, scale, and sophistication of attacks. We take these threats seriously and have moved swiftly alongside our partners to build in the latest protections for our customers.

MSTIC believes SOURGUM is an Israel-based private-sector offensive actor. We would like to thank the Citizen Lab, at the University of Toronto’s Munk School, for sharing the sample of malware that initiated this work and their collaboration during the investigation. In their blog, Citizen Lab asserts with high confidence that SOURGUM is an Israeli company commonly known as Candiru. Third-party reports indicate Candiru produces “hacking tools [that] are used to break into computers and servers”.  

As we shared in the Microsoft on the Issues blog, Microsoft and Citizen Lab have worked together to disable the malware being used by SOURGUM that targeted more than 100 victims around the world including politicians, human rights activists, journalists, academics, embassy workers, and political dissidents. To limit these attacks, Microsoft has created and built protections into our products against this unique malware, which we are calling DevilsTongue. We have shared these protections with the security community so that we can collectively address and mitigate this threat. We have also issued a software update that will protect Windows customers from the associated exploits that the actor used to help deliver its highly sophisticated malware.

SOURGUM victimology

Media reports (1, 2, 3) indicate that PSOAs often sell Windows exploits and malware in hacking-as-a-service packages to government agencies. Agencies in Uzbekistan, United Arab Emirates, and Saudi Arabia are among the list of Candiru’s alleged previous customers. These agencies, then, likely choose whom to target and run the cyberoperations themselves.

Microsoft has identified over 100 victims of SOURGUM’s malware, and these victims are as geographically diverse as would be expected when varied government agencies are believed to be selecting the targets. Approximately half of the victims were found in Palestinian Authority, with most of the remaining victims located in Israel, Iran, Lebanon, Yemen, Spain (Catalonia), United Kingdom, Turkey, Armenia, and Singapore. To be clear, the identification of victims of the malware in a country doesn’t necessarily mean that an agency in that country is a SOURGUM customer, as international targeting is common.

Any Microsoft 365 Defender and Microsoft Defender for Endpoint alerts containing detection names for the DevilsTongue malware name are signs of compromise by SOURGUM’s malware. We have included a comprehensive list of detection names below for customers to perform additional hunting in their environments.

Exploits

SOURGUM appears to use a chain of browser and Windows exploits, including 0-days, to install malware on victim boxes. Browser exploits appear to be served via single-use URLs sent to targets on messaging applications such as WhatsApp.

During the investigation, Microsoft discovered two Windows 0-day exploits for vulnerabilities tracked as CVE-2021-31979 and CVE-2021-33771, both of which have been fixed in the July 2021 security updates. These vulnerabilities allow privilege escalation, giving an attacker the ability to escape browser sandboxes and gain kernel code execution. If customers have taken the July 2021 security update, they are protected from these exploits.

CVE-2021-31979 fixes an integer overflow within Windows NT-based operating system (NTOS). This overflow results in an incorrect buffer size being calculated, which is then used to allocate a buffer in the kernel pool. A buffer overflow subsequently occurs while copying memory to the smaller-than-expected destination buffer. This vulnerability can be leveraged to corrupt an object in an adjacent memory allocation. Using APIs from user mode, the kernel pool memory layout can be groomed with controlled allocations, resulting in an object being placed in the adjacent memory location. Once corrupted by the buffer overflow, this object can be turned into a user mode to kernel mode read/write primitive. With these primitives in place, an attacker can then elevate their privileges.

CVE-2021-33771 addresses a race condition within NTOS resulting in the use-after-free of a kernel object. By using multiple racing threads, the kernel object can be freed, and the freed memory reclaimed by a controllable object. Like the previous vulnerability, the kernel pool memory can be sprayed with allocations using user mode APIs with the hopes of landing an object allocation within the recently freed memory. If successful, the controllable object can be used to form a user mode to kernel mode read/write primitive and elevate privileges.

DevilsTongue malware overview

DevilsTongue is a complex modular multi-threaded piece of malware written in C and C++ with several novel capabilities. Analysis is still on-going for some components and capabilities, but we’re sharing our present understanding of the malware so defenders can use this intelligence to protect networks and so other researchers can build on our analysis.

For files on disk, PDB paths and PE timestamps are scrubbed, strings and configs are encrypted, and each file has a unique hash. The main functionality resides in DLLs that are encrypted on disk and only decrypted in memory, making detection more difficult. Configuration and tasking data is separate from the malware, which makes analysis harder.  DevilsTongue has both user mode and kernel mode capabilities. There are several novel detection evasion mechanisms built in. All these features are evidence that SOURGUM developers are very professional, have extensive experience writing Windows malware, and have a good understanding of operational security.

When the malware is installed, a first-stage ‘hijack’ malware DLL is dropped in a subfolder of C:\Windows\system32\IME\; the folders and names of the hijack DLLs blend with legitimate names in the \IME\ directories. Encrypted second-stage malware and config files are dropped into subfolders of C:\Windows\system32\config\ with a .dat file extension. A third-party legitimate, signed driver physmem.sys is dropped to the system32 folder. A file called WimBootConfigurations.ini is also dropped; this file has the command for following the COM hijack. Finally, the malware adds the hijack DLL to a COM class registry key, overwriting the legitimate COM DLL path that was there, achieving persistence via COM hijacking.

From the COM hijacking, the DevilsTongue first-stage hijack DLL gets loaded into a svchost.exe process to run with SYSTEM permissions. The COM hijacking technique means that the original DLL that was in the COM registry key isn’t loaded. This can break system functionality and trigger an investigation that could lead to the discovery of the malware, but DevilsTongue uses an interesting technique to avoid this. In its DllMain function it calls LoadLibrary on the original COM DLL so it is correctly loaded into the process. DevilsTongue then searches the call stack to find the return address of LoadLibraryExW (i.e., the function currently loading the DevilsTongue DLL),  which would usually return the base address of the DevilsTongue DLL.

Once the LoadLibraryExW return address has been found, DevilsTongue allocates a small buffer with shellcode that puts the COM DLL’s base address (imecfmup.7FFE49060000 in Figure 1) into the rax register and then jumps to the original return address of LoadLibraryExW (svchost.7FF78E903BFB in Figures 1 and 2). In Figure 1 the COM DLL is named imecfmup rather than a legitimate COM DLL name because some DevilsTongue samples copied the COM DLL to another location and renamed it.

Figure 1. DevilsTongue return address modification shellcode

DevilsTongue then swaps the original LoadLibraryExW return address on the stack with the address of the shellcode so that when LoadLibraryExW returns it does so into the shellcode (Figures 2 and 3). The shellcode replaces the DevilsTongue base address in rax with the COM DLL’s base address, making it look like LoadLibraryExW has returned the COM DLL’s address. The svchost.exe host process now uses the returned COM DLL base address as it usually would.

Figure 2. Call stack before stack swap, LoadLibraryExW in kernelbase returning to svchost.exe (0x7FF78E903BFB)

Figure 3. Call stack after stack swap, LoadLibraryExW in kernelbase returning to the shellcode address (0x156C51E0000 from Figure 1)

This technique ensures that the DevilsTongue DLL is loaded by the svchost.exe process, giving the malware persistence, but that the legitimate COM DLL is also loaded correctly so there’s no noticeable change in functionality on the victim’s systems.

After this, the hijack DLL then decrypts and loads a second-stage malware DLL from one of the encrypted .dat files. The second-stage malware decrypts another .dat file that contains multiple helper DLLs that it relies on for functionality.

DevilsTongue has standard malware capabilities, including file collection, registry querying, running WMI commands, and querying SQLite databases. It’s capable of stealing victim credentials from both LSASS and from browsers, such as Chrome and Firefox. It also has dedicated functionality to decrypt and exfiltrate conversations from the Signal messaging app.

It can retrieve cookies from a variety of web browsers. These stolen cookies can later be used by the attacker to sign in as the victim to websites to enable further information gathering. Cookies can be collected from these paths (* is a wildcard to match any folders):

  • %LOCALAPPDATA%\Chromium\User Data\*\Cookies
  • %LOCALAPPDATA%\Google\Chrome\User Data\*\Cookies
  • %LOCALAPPDATA%\Microsoft\Windows\INetCookies
  • %LOCALAPPDATA%\Packages\*\AC\*\MicrosoftEdge\Cookies
  • %LOCALAPPDATA%\UCBrowser\User Data_i18n\*\Cookies.9
  • %LOCALAPPDATA%\Yandex\YandexBrowser\User Data\*\Cookies
  • %APPDATA%\Apple Computer\Safari\Cookies\Cookies.binarycookies
  • %APPDATA%\Microsoft\Windows\Cookies
  • %APPDATA%\Mozilla\Firefox\Profiles\*\cookies.sqlite
  • %APPDATA%\Opera Software\Opera Stable\Cookies

Interestingly, DevilsTongue seems able to use cookies directly from the victim’s computer on websites such as Facebook, Twitter, Gmail, Yahoo, Mail.ru, Odnoklassniki, and Vkontakte to collect information, read the victim’s messages, and retrieve photos. DevilsTongue can also send messages as the victim on some of these websites, appearing to any recipient that the victim had sent these messages. The capability to send messages could be weaponized to send malicious links to more victims.

Alongside DevilsTongue a third-party signed driver is dropped to C:\Windows\system32\physmem.sys. The driver’s description is “Physical Memory Access Driver,” and it appears to offer a “by-design” kernel read/write capability. This appears to be abused by DevilsTongue to proxy certain API calls via the kernel to hinder detection, including the capability to have some of the calls appear from other processes. Functions capable of being proxied include CreateProcessW, VirtualAllocEx, VirtualProtectEx, WriteProcessMemory, ReadProcessMemory, CreateFileW and RegSetKeyValueW.

Prevention and detection

To prevent compromise from browser exploits, it’s recommended to use an isolated environment, such as a virtual machine, when opening links from untrusted parties. Using a modern version of Windows 10 with virtualization-based protections, such as Credential Guard, prevents DevilsTongue’s LSASS credential-stealing capabilities. Enabling the attack surface reduction rule “Block abuse of exploited vulnerable signed drivers” in Microsoft Defender for Endpoint blocks the driver that DevilsTongue uses. Network protection blocks known SOURGUM domains.

Detection opportunities

This section is intended to serve as a non-exhaustive guide to help customers and peers in the cybersecurity industry to detect the DevilsTongue malware. We’re providing this guidance with the expectation that SOURGUM will likely change the characteristics we identify for detection in their next iteration of the malware. Given the actor’s level of sophistication, however, we believe that outcome would likely occur irrespective of our public guidance.

File locations

The hijack DLLs are in subfolders of \system32\ime\ with names starting with ‘im’. However, they are blended with legitimate DLLs in those folders. To distinguish between the malicious and benign, the legitimate DLLs are signed (on Windows 10) whereas the DevilsTongue files aren’t. Example paths:

  • C:\Windows\System32\IME\IMEJP\imjpueact.dll
  • C:\Windows\system32\ime\IMETC\IMTCPROT.DLL
  • C:\Windows\system32\ime\SHARED\imecpmeid.dll

 The DevilsTongue configuration files, which are AES-encrypted, are in subfolders of C:\Windows\system32\config\ and have a .dat extension. The exact paths are victim-specific, although some folder names are common across victims. As the files are AES-encrypted, any files whose size mod 16 is 0 can be considered as a possible malware config file. The config files are always in new folders, not the legitimate existing folders (e.g., on Windows 10, never in \Journal, \systemprofile, \TxR etc.). Example paths:

  • C:\Windows\system32\config\spp\ServiceState\Recovery\pac.dat
  • C:\Windows\system32\config\cy-GB\Setup\SKB\InputMethod\TupTask.dat
  • C:\Windows\system32\config\config\startwus.dat

Commonly reused folder names in the config file paths:

  • spp
  • SKB
  • curv
  • networklist
  • Licenses
  • InputMethod
  • Recovery

The .ini reg file has the unique name WimBootConfigurations.ini and is in a subfolder of system32\ime\. Example paths:

  • C:\Windows\system32\ime\SHARED\WimBootConfigurations.ini
  • C:\Windows\system32\ime\IMEJP\WimBootConfigurations.ini
  • C:\Windows\system32\ime\IMETC\WimBootConfigurations.ini

The Physmem driver is dropped into system32:

  • C:\Windows\system32\physmem.sys

Behaviors

The two COM keys that have been observed being hijacked for persistence are listed below with their default clean values. If their default value DLL is in the \system32\ime\ folder, the DLL is likely DevilsTongue.

  • HKLM\SOFTWARE\Classes\CLSID\{CF4CC405-E2C5-4DDD-B3CE-5E7582D8C9FA}\InprocServer32 = %systemroot%\system32\wbem\wmiutils.dll (clean default value)
  • HKLM\SOFTWARE\Classes\CLSID\{7C857801-7381-11CF-884D-00AA004B2E24}\InProcServer32 = %systemroot%\system32\wbem\wbemsvc.dll (clean default value)

File content and characteristics

This Yara rule can be used to find the DevilsTongue hijack DLL:

import "pe"
rule DevilsTongue_HijackDll
{
meta:
description = "Detects SOURGUM's DevilsTongue hijack DLL"
author = "Microsoft Threat Intelligence Center (MSTIC)"
date = "2021-07-15"
strings:
$str1 = "windows.old\\windows" wide
$str2 = "NtQueryInformationThread"
$str3 = "dbgHelp.dll" wide
$str4 = "StackWalk64"
$str5 = "ConvertSidToStringSidW"
$str6 = "S-1-5-18" wide
$str7 = "SMNew.dll" // DLL original name
// Call check in stack manipulation
// B8 FF 15 00 00   mov     eax, 15FFh
// 66 39 41 FA      cmp     [rcx-6], ax
// 74 06            jz      short loc_1800042B9
// 80 79 FB E8      cmp     byte ptr [rcx-5], 0E8h ; 'è'
$code1 = {B8 FF 15 00 00 66 39 41 FA 74 06 80 79 FB E8}
// PRNG to generate number of times to sleep 1s before exiting
// 44 8B C0 mov r8d, eax
// B8 B5 81 4E 1B mov eax, 1B4E81B5h
// 41 F7 E8 imul r8d
// C1 FA 05 sar edx, 5
// 8B CA    mov ecx, edx
// C1 E9 1F shr ecx, 1Fh
// 03 D1    add edx, ecx
// 69 CA 2C 01 00 00 imul ecx, edx, 12Ch
// 44 2B C1 sub r8d, ecx
// 45 85 C0 test r8d, r8d
// 7E 19    jle  short loc_1800014D0
$code2 = {44 8B C0 B8 B5 81 4E 1B 41 F7 E8 C1 FA 05 8B CA C1 E9 1F 03 D1 69 CA 2C 01 00 00 44 2B C1 45 85 C0 7E 19}
condition:
filesize < 800KB and
uint16(0) == 0x5A4D and
(pe.characteristics & pe.DLL) and
(
4 of them or
($code1 and $code2) or
(pe.imphash() == "9a964e810949704ff7b4a393d9adda60")
)
}

Microsoft Defender Antivirus detections

Microsoft Defender Antivirus detects DevilsTongue malware with the following detections:

  • Trojan:Win32/DevilsTongue.A!dha
  • Trojan:Win32/DevilsTongue.B!dha
  • Trojan:Script/DevilsTongueIni.A!dha
  • VirTool:Win32/DevilsTongueConfig.A!dha
  • HackTool:Win32/DevilsTongueDriver.A!dha

Microsoft Defender for Endpoint alerts

Alerts with the following titles in the security center can indicate DevilsTongue malware activity on your network:

  • COM Hijacking
  • Possible theft of sensitive web browser information
  • Stolen SSO cookies 

Azure Sentinel query

To locate possible SOURGUM activity using Azure Sentinel, customers can find a Sentinel query containing these indicators in this GitHub repository.

Indicators of compromise (IOCs)

No malware hashes are being shared because DevilsTongue files, except for the third part driver below, all have unique hashes, and therefore, are not a useful indicator of compromise.

Physmem driver

Note that this driver may be used legitimately, but if it’s seen on path C:\Windows\system32\physmem.sys then it is a high-confidence indicator of DevilsTongue activity. The hashes below are provided for the one driver observed in use.

  • MD5: a0e2223868b6133c5712ba5ed20c3e8a
  • SHA-1: 17614fdee3b89272e99758983b99111cbb1b312c
  • SHA-256: c299063e3eae8ddc15839767e83b9808fd43418dc5a1af7e4f44b97ba53fbd3d

Domains

  • noc-service-streamer[.]com
  • fbcdnads[.]live
  • hilocake[.]info
  • backxercise[.]com
  • winmslaf[.]xyz
  • service-deamon[.]com
  • online-affiliate-mon[.]com
  • codeingasmylife[.]com
  • kenoratravels[.]com
  • weathercheck[.]digital
  • colorpallatess[.]com
  • library-update[.]com
  • online-source-validate[.]com
  • grayhornet[.]com
  • johnshopkin[.]net
  • eulenformacion[.]com
  • pochtarossiy[.]info

The post Protecting customers from a private-sector offensive actor using 0-day exploits and DevilsTongue malware appeared first on Microsoft Security Blog.

Microsoft releases Security Advisory 2963983

April 27th, 2014 No comments

Today, we released Security Advisory 2963983 regarding an issue that impacts Internet Explorer. At this time, we are only aware of limited, targeted attacks. This issue allows remote code execution if users visit a malicious website with an affected browser. This would typically occur by an attacker convincing someone to click a link in an email or instant message.

Our initial investigation has revealed that Enhanced Protected Mode, on by default for the modern browsing experience in Internet Explorer 10 and Internet Explorer 11, as well as Enhanced Mitigation Experience Toolkit (EMET) 4.1 and EMET 5.0 Technical Preview, will help protect against this potential risk. We also encourage you to follow the "Protect Your Computer" guidance of enabling a firewall, applying all software updates and installing anti-virus and anti-spyware software. Additionally, we encourage everyone to exercise caution when visiting websites and avoid clicking suspicious links, or opening email messages from unfamiliar senders. Additional information can be found at www.microsoft.com/protect.

We are monitoring the threat landscape very closely and will continue to take appropriate action to help protect customers.

Thank you,

Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

ActiveX Control issue being addressed in Update Tuesday

November 11th, 2013 No comments

Late last Friday, November 8, 2013, a vulnerability, CVE-2013-3918, affecting an Internet Explorer ActiveX Control was publically disclosed. We have confirmed that this vulnerability is an issue already scheduled to be addressed in “Bulletin 3”, which will be released as MS13-090, as listed in the November Advanced Notification Service (ANS). The security update will be distributed to customers tomorrow via Windows Update at approximately 10:00 AM PDT. Customers who have Automatic Updates enabled will not need to take any action to receive the update. 

While we are in the process of finalizing the security update to address this issue, we encourage Internet Explorer customers concerned with this vulnerability to follow the following mitigations:

  • Set Internet and local intranet security zone settings to “High” to block ActiveX Controls and Active Scripting in these zones
    This action will help prevent exploitation but may affect usability; therefore, trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Configure Internet Explorer to prompt before running Active Scripting or disable Active Scripting in the Internet and local intranet security zones
    This action will help prevent exploitation but can affect usability, so trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
    This will help prevent exploitation by providing mitigations to help protect against this issue and should not affect usability of websites.

As a best practice, we always encourage customers to follow the “Protect Your Computer” guidance of enabling a firewall, applying all software updates and installing anti-virus and anti-spyware software. We also encourage customers to exercise caution when visiting websites and avoid clicking suspicious links or opening email messages from unfamiliar senders. Additional information can be found at www.microsoft.com/protect.

We will continue to monitor the threat landscape very closely and take appropriate action to help protect our customers.

Thank you,
Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

 

ActiveX Control issue being addressed in Update Tuesday

November 11th, 2013 No comments

Late last Friday, November 8, 2013, a vulnerability, CVE-2013-3918, affecting an Internet Explorer ActiveX Control was publically disclosed. We have confirmed that this vulnerability is an issue already scheduled to be addressed in “Bulletin 3”, which will be released as MS13-090, as listed in the November Advanced Notification Service (ANS). The security update will be distributed to customers tomorrow via Windows Update at approximately 10:00 AM PDT. Customers who have Automatic Updates enabled will not need to take any action to receive the update. 

While we are in the process of finalizing the security update to address this issue, we encourage Internet Explorer customers concerned with this vulnerability to follow the following mitigations:

  • Set Internet and local intranet security zone settings to “High” to block ActiveX Controls and Active Scripting in these zones
    This action will help prevent exploitation but may affect usability; therefore, trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Configure Internet Explorer to prompt before running Active Scripting or disable Active Scripting in the Internet and local intranet security zones
    This action will help prevent exploitation but can affect usability, so trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
    This will help prevent exploitation by providing mitigations to help protect against this issue and should not affect usability of websites.

As a best practice, we always encourage customers to follow the “Protect Your Computer” guidance of enabling a firewall, applying all software updates and installing anti-virus and anti-spyware software. We also encourage customers to exercise caution when visiting websites and avoid clicking suspicious links or opening email messages from unfamiliar senders. Additional information can be found at www.microsoft.com/protect.

We will continue to monitor the threat landscape very closely and take appropriate action to help protect our customers.

Thank you,
Dustin Childs
Group Manager, Response Communications
Trustworthy Computing

 

Microsoft Releases Security Advisory 2794220

December 29th, 2012 No comments

Today, we released Security Advisory 2794220 regarding an issue that impacts Internet Explorer 6, 7, and 8. We are only aware of a very small number of targeted attacks at this time. This issue allows remote code execution if users browse to a malicious website with an affected browser. This would typically occur by an attacker convincing someone to click a link in an email or instant message.

Internet Explorer 9 and 10 are not affected by this issue, so upgrading to these versions will help protect you from this issue.

While we are actively working to develop a security update to address this issue, we encourage customers using affected versions of Internet Explorer to deploy the following workarounds and mitigations included in the advisory to help protect themselves: 

  • Set Internet and local intranet security zone settings to “High” to block ActiveX Controls and Active Scripting in these zones
    This will help prevent exploitation but may affect usability; therefore, trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and local intranet security zones
    This will help prevent exploitation but can affect usability, so trusted sites should be added to the Internet Explorer Trusted Sites zone to minimize disruption.
  • Deploy the Enhanced Mitigation Experience Toolkit (EMET)
    This will help prevent exploitation by providing mitigations to protect against this issue and should not affect usability of websites. An easy guide for EMET installation and configuration is available in
    KB2458544.

Over on the SRD blog, MSRC’s own Jonathan Ness and Cristian Craioveanu go over some of the issue details. We are also actively working to package an easy, one-click Fix it solution that will help protect your computer. In their blog, Jonathan and Cristian describe the shim that will be included in the Fix it, and how it will be able to be used to help prevent the exploit from succeeding. We expect the Fix it will be available in the next few days and will update this blog when it is ready.

As always, we encourage people to follow the “Protect Your Computer” guidance of enabling a firewall, applying all software updates and installing anti-virus and anti-spyware software. We also encourage folks to exercise caution when visiting websites and avoid clicking suspicious links, or opening email messages from unfamiliar senders. Additional information can be found at www.microsoft.com/protect.

We are monitoring the threat landscape very closely and if the situation changes, we will post updates here on the MSRC blog and on Twitter at @MSFTSecResponse.

Thank you,

Dustin Childs
Group Manager, Response Communications
Trustworthy Computing