Something we often hear within the cybersecurity community, and particularly within digital forensics and incident response (DFIR), is that “threat actors are always changing their tactics.” If you’re just responding to incidents and putting out fires, it might seem like that, but if you’re really looking into incidents and tracking indicators and threat actor tactics, techniques, and procedures (TTPs), you’re very likely going to see that without some significant external stimulus, such as significant differences in infrastructure design and tooling, there’s really no need for a threat actor to change their tactics.
Huntress analysts and researchers recently published information regarding two vulnerabilities. On 4 April 2025, the CrushFTP CVE-2025-31161 Auth Bypass and Post-Exploitation blog was published, and on 14 April 2025, the CVE-2025-30406 - Critical Gladinet CentreStack & Triofox Vulnerability Exploited in the Wild blog was published. Looking closely at both blog posts, in particular at their Indicators of Compromise (IOC) sections, an astute reader will notice some commonalities between the two; specifically, IOCs such as the 2.58.56[.]16 IP address, installation of the Mesh Agent RMM, and the d3d11.dll file.
Huntress analysts and researchers have observed similar TTPs across incidents that began by different vulnerabilities being exploited. Once initial access was obtained, the threat actor used very similar TTPs. Notably, some incidents were stopped much earlier in the attack cycle than others. In one incident, the initially compromised endpoint did not have a Huntress agent installed. In others, installed security tools detected and quarantined the threat actor’s files, alerting the Huntress SOC and resulting in the endpoints quickly being isolated.
Early in April 2025, Huntress SOC analysts detected multiple incidents found to have started via the exploitation of the CrushFTP vulnerability as the means of initial access.
On those incidents, the CrushFTP application logs illustrated connections from the 2.58.56[.]16 IP address that resulted in files d3d11.dll and mesch.exe (Mesh Agent installer) being transferred to the endpoints. CrushFTP log entries illustrating the transfer of the d3d11.dll to the endpoint appear as follows:
In both incidents, the d3d11.dll file was detected and quarantined by Windows Defender, as illustrated in Figure 1.
In neither incident was there any activity observed indicating that the DLL had been loaded, nor launched in any way. This was likely due to the fact that the DLL was identified and quarantined quickly. Based on previous analysis, this DLL was identified as an “implementation of the open source library TgBot.”
Several of the CrushFTP incidents involved the threat actor installing Mesh Agent, installed from the C:\Windows\Temp folder, and configured to connect to hxxps[://]rtb[.]mftadsrvr[.]com:2087.
On 12 and 13 April 2025, Huntress reported several incidents that involved the exploitation of the Gladinet CentreStack & Triofox vulnerability as a means of initial access. During these incidents, IIS web server logs indicated that initial access to the /portal/loginpage.aspx web page occurred from the 2.58.56[.]16 IP address.
During these incidents, the threat actor did not have access to a managed file transfer (MFT) tool, as with the CrushFTP incidents, and therefore had to resort to a different means of getting files transferred to the endpoints. As illustrated in Figure 2, the threat actor opted to use base64-encoded PowerShell commands to download their files to the endpoints.
During the observed incidents, the file Centre.exe was also downloaded to the endpoint via the same means and from the same source as d3d11.dll. When launched by the threat actor, as illustrated in Figure 3, the resulting process was detected by Windows Defender as Cobalt Strike, and quarantined.
File version information included within the Centre.exe file indicates that it’s the Wallpaper Engine Launcher, originally named “launcher.exe”. A review of the Centre.exe file illustrated that the d3d11.dll file was referenced in the import table of the executable, indicating that the executable was intended to side-load the malicious DLL. Given this information, it seems clear that the CrushFTP incidents were responded to and endpoints were isolated before the threat actor was able to transfer a suitable executable file to the endpoint, and they may have modified their approach for the subsequent attacks.
During one incident, the threat actor gained initial access to the infrastructure after exploiting the CentreStack & Triofox vulnerability on an endpoint on which the Huntress agent was not installed. Web server logs from this endpoint indicated that the vulnerability was likely first exploited from 2.58.56[.]16 IP address. After moving to another endpoint that did have the Huntress agent installed, the threat actor was able to reach the point in their attack cycle where they were able to install Mesh Agent, configured to connect to the rtb[.]mftadsrvr[.]com endpoint, before the endpoint was isolated.
Even with an admittedly limited aperture, the consistency in indicators across incidents involving markedly different initial means of access really goes to show that, perhaps absent some significant external stimulus, threat actors will continue to use TTPs that work.
Huntress recommends that organizations start with an asset inventory, including physical and virtual systems, as well as installed applications, and their versions. Once this inventory has been established, perform attack surface reduction, removing unneeded and unnecessary applications, patching and properly configuring those that are needed, and installing monitoring, detection, and response capabilities on all endpoints.
2.58.56[.]16 - threat actor source IP address
196.251.85[.]31 - threat actor source of tool downloads
rtb[.]mftadsrvr[.]com - endpoint Mesh Agent was configured to connect to
d3d11.dll - Malicious DLL
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
