Fortifying the Chain: A Proven Strategy for Supply Chain Defense
The post Fortifying the Chain: A Proven Strategy for Supply Chain Defense appeared first on Horizon3.ai.
TL;DR (really?): Members of Distributed COM Users or Performance Log Users Groups can trigger from remote and relay the authentication of users connected on the target server, including Domain Controllers. #SilverPotato
Remember my previous article? My insatiable curiosity led me to explore the default DCOM permissions on Domain Controllers during a quiet evening…
Using some custom Powershell scripts, I produced an Excel sheet with all the information I needed.
You can’t imagine the shock I felt when I discovered these two Application Id’s
The first one, sppui with ID: {0868DC9B-D9A2-4f64-9362-133CEA201299}, seemed very interesting because it was impersonating the Interactive user. Combined with the permissions granted to Everyone for activating this application from remote, this could potentially lead to some unexpected privilege escalation, don’t you think?
The output of the DCOMCNFG tool confirmed my analysis:
But wait, this does not mean Everyone can activate this DCOM Application remotely. We have to look also at the default limits for Everyone:
Everyone can only activate and launch locally… but… there are these two interesting groups, Distributed COM Users and Performance Log Users who can launch and activate the application remotely:
Combined with Everyone’s permission this sounds really interesting! But before going further, what is this application sspui?
With the magic Oleview tool, we can get much more information:
This app has the following CLSID F87B28F1-DA9A-4F35-8EC0-800EFCF26B83 – SPPUIObjectInteractive Class, and runs as a Local Server :
slui.exe is related to the License Activation Service and exposes some interfaces:
At first glance, the methods implemented seem not very interesting from an Attacker perspective.
However, we have this DCOM object running in the context of the interactive user, accessible remotely by members of these two groups. So, why not attempt coercing authentication using our *potato exploit? If successful, we could intercept the authentication of the user connected to the Domain Controller, who should theoretically be a Domain Admin, correct ?
This is very similar to what I did in ADCCoercePotato, except for the fact that we may need to implement also the cross-session activation if we want to specify a specific session ID where the user is logged in.
I won’t go too much into the details; @splinter_code and I have discussed this argument so many times
The key point is that there are two authentication processes: the first occurs during the oxid resolve call, while the second takes place when the victim attempts to contact the malicious endpoint.
I obviously tried the first one, and without too much effort, was able to trigger and intercept the NTLM authentication of a Domain Admin connected to the target Domain Controller.
For testing purposes, I impersonated my user “simple”, a regular domain user and member of the “Performance Log Users” domain group:
I used my new “SilverPotato” tool, a modified version of ADCSCoercePotato:
In this case, with -m, I specified the IP address of the target domain controller, and with -k, the IP of the Linux box where the socat redirector and ntlmrelayx were running:
And yes, it worked! I got the authentication of Administrator connected on the first session (I did not specify the session ID).
I decided to relay the authentication to the SMB service of the ADCS server (but it’s just an example…), which by default has no signing enabled, and dumped the local SAM database:
With the NT hash of the local Administrator, I could access the ADCS Server via Pass The Hash, backup the Private/Public key of the CA, and the get CRL configuration.
Side note: Of course, there are other methods to achieve remote code execution on the target server. For instance, I utilized ntlmrelay to copy my malicious wbemcomn.dll file with a reverse shell into the c:\windows\system32\wbem directory. This file was subsequently loaded under different conditions, granting me a shell with SYSTEM, Network Service, or logged-in User privileges
After this, with ForgeCert tool, I was able to request a certificate on behalf Domain Administrator with the backup file of the CA.
Finally, request a TGT with Rubeus and logon to the Domain Controller as Administrator
Afterward, I attempted to exploit the second authentication, which is more or less what we implemented in our RemotePotato0.
However, to my surprise, the resulting impersonation level in this case was limited to Identify, which is useless against SMB or HTTP, and unusable against LDAP/LDAPS because of the sign flag…
Otherwise, it could have presented a great opportunity to use Kerberos relay instead of NTLM, given that the Service Principal Name (SPN) was within the attacker’s control.
In theory, you could specify the Service Principal Name (SPN) in the first call in the security bindings strings of the “dualstring” array of the Marshalled Interface Pointer:
typedef struct tagSECURITYBINDING
{
unsigned short wAuthnSvc; // Must not be 0
unsigned short wAuthzSvc; // Must not be 0
unsigned short aPrincName; // NULL terminated
} SECURITYBINDING
I specified the SPN with the -y switch:
But my tests were unsuccessful, I always got back the SPN: RPCSS/IP in the NTLM3 message:
A few days ago, James Forshaw pointed out to me the potential for Kerberos relay via OXID resolving, by exploiting the marshaled target info trick detailed in his post under the “Marshaled Target Information SPN” section.
I attempted some tests but quickly gave up, using the excuse that I’m just too lazy .. so I’ll leave it up to you!
At this point, I know I have to answer the fateful question: Did you report this to MSRC?
Obviously, yes! I’ll spare you the disclosure timeline. In short, MSRC confirmed the vulnerability and initially marked it as a critical fix. However, about a month later, they downgraded it to moderate severity. Their final verdict was: After careful investigation, this case has been assessed as moderate severity and does not meet MSRC’s bar for immediate servicing.
So, I feel free to publish this finding
I’m not going to release the source code for now, but crafting your own should be a breeze, wouldn’t you agree?
This “vulnerability” has been probably around for years, and it’s surprising that nobody has made it public.
So how dangerous is it?
Hard to say, especially since membership in groups like “Distributed COM Users” and “Performance Log Users” isn’t exactly commonplace, especially domain-wide. Also, the “Distributed COM Users” group is sometimes considered a tier 0 asset
But think about it: the ability to coerce and relay the (NTLM) authentication of highly privileged accounts from remote, is incredibly risky. It’s another valid reason to include privileged accounts in the Protected Users group!
Another point to consider is that this method applies to the local “Distributed COM Users” and “Performance Log Users” groups too. So, it really depends on who is logged into the server at the time…
I would recommend carefully reviewing the memberships of these and until MS won’t fix this vulnerability, definitely consider these groups tier 0!
What’s next after SilverPotato? Well, there’s another interesting one, but this was classified as an Important Privilege Escalation so I have to wait for the fix…
Last but not least, as usual, thanks to James Forshaw @tiraniddo and Antonio Cocomazzi @splinter_code for their precious help.
That’s all
Infromations Web Application Security
sudo apt install python3 python3-pip
pip3 install termcolor
pip3 install google
pip3 install optioncomplete
pip3 install bs4
pip3 install prettytable
git clone https://github.com/Matrix07ksa/HackerInfo/
cd HackerInfo
chmod +x HackerInfo
./HackerInfo -h
python3 HackerInfo.py -d www.facebook.com -f pdf
[+] <-- Running Domain_filter_File ....-->
[+] <-- Searching [www.facebook.com] Files [pdf] ....-->
https://www.facebook.com/gms_hub/share/dcvsda_wf.pdf
https://www.facebook.com/gms_hub/share/facebook_groups_for_pages.pdf
https://www.facebook.com/gms_hub/share/videorequirementschart.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_hi_in.pdf
https://www.facebook.com/gms_hub/share/bidding-strategy_decision-tree_en_us.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_es_la.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_ar.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_ur_pk.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_cs_cz.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_it_it.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_pl_pl.pdf
h ttps://www.facebook.com/gms_hub/share/fundraise-on-facebook_nl.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_pt_br.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_id_id.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_fr_fr.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_tr_tr.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_hi_in.pdf
https://www.facebook.com/rsrc.php/yA/r/AVye1Rrg376.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_ur_pk.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_nl_nl.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_de_de.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_de_de.pdf
https://www.facebook.com/gms_hub/share/creative-best-practices_cs_cz.pdf
https://www.facebook.com/gms_hub/share/fundraise-on-facebook_sk_sk.pdf
https://www.facebook.com/gms _hub/share/creative-best-practices_japanese_jp.pdf
#####################[Finshid]########################
sudo python setup.py install
pip3 install hackinfo
Free to use IOC feed for various tools/malware. It started out for just C2 tools but has morphed into tracking infostealers and botnets as well. It uses shodan.io/">Shodan searches to collect the IPs. The most recent collection is always stored in data
; the IPs are broken down by tool and there is an all.txt
.
The feed should update daily. Actively working on making the backend more reliable
Many of the Shodan queries have been sourced from other CTI researchers:
Huge shoutout to them!
Thanks to BertJanCyber for creating the KQL query for ingesting this feed
And finally, thanks to Y_nexro for creating C2Live in order to visualize the data
If you want to host a private version, put your Shodan API key in an environment variable called SHODAN_API_KEY
echo SHODAN_API_KEY=API_KEY >> ~/.bashrc
bash
python3 -m pip install -r requirements.txt
python3 tracker.py
I encourage opening an issue/PR if you know of any additional Shodan searches for identifying adversary infrastructure. I will not set any hard guidelines around what can be submitted, just know, fidelity is paramount (high true/false positive ratio is the focus).
Specially crafted Javascript inside an HTML page can trigger a type confusion bug in Microsoft Edge that allows accessing a C++ object as if it was a BSTR string. This can result in information disclosure, such as allowing an attacker to determine the value of pointers to other objects and/or functions. This information can be used to bypass ASLR mitigations. It may also be possible to modify arbitrary memory and achieve remote code execution, but this was not investigated.
A specially crafted style sheet inside an HTML page can trigger a NULL pointer dereference in Microsoft Internet Explorer 10 and 11. The pointer in question is assumed to point to a function, and the code attempts to use it to execute this function, which normally leads to an access violation when attempting to execute unmapped memory at address 0. In some cases, Control Flow Guard (CFG) will attempt to check if the address is a valid indirect call target. Because of the way CFG is implemented, this can lead to a read access violation in unmapped memory at a seemingly arbitrary address.
A specially crafted Javascript inside an HTML page can trigger a use-after-free
bug in Tree::ANode::IsInTree
or a breakpoint in
Abandonment::InduceAbandonment
in Microsoft Edge. The use-after-free bug is
mitigated by MemGC: if MemGC is enabled (which it is by default) the memory
is never freed. This effectively prevents exploitation of the issue. The
Abandonment appears to be triggered by a stack exhaustion bug; the Javascript
creates a loop where an event handler triggers a new event, which in turn
triggers the event handler, etc.. This consumes a stack space until there is no
more stack available. Edge does appear to be able to handle such a situation
gracefully under certain conditions, but not all. It is easy to avoid those
conditions to force triggering the Abandonment.
The interesting thing is that this indicates that the assumption that "hitting Abandonment means a bug is not a security issue" may not be correct in all cases.
A specially crafted Javascript inside an HTML page can trigger a use-after-free
bug in the CTreePosGap::PartitionPointers
function of edgehtml.dll in
Microsoft Edge. This use-after-free bug is mitigated by MemGC by default:
with MemGC enabled the memory is never actually freed. This mitigation is
considered sufficient to make this a non-security issue as explained by
Microsoft SWIAT in their blog post Triaging the exploitability of IE/Edge
crashes.
Since this is not considered a security issue, I have the opportunity to share details about the issue with you before the issue has been fixed. And since Microsoft are unlikely to provide a fix for this issue on short notice, you should be able to reproduce this issue for some time after publication of this post. I will try to explain how I analyzed this issue using BugId and EdgeDbg, so that you can reproduce what I did and see for yourself.
While working independently has many advantages, it does have one major drawback: no one to bounce ideas off or help you solve problems. So, in order to address this, I am now looking for opportunities to work closer with other researchers again.
With MS16-063 Microsoft has patched CVE-2016-0199: a memory corruption bug in the garbage collector of the JavaScript engine used in Internet Explorer 11. By exploiting this vulnerability, a website can causes this garbage collector to handle some data in memory as if it was an object, when in fact it contains data for another type of value, such as a string or number. The garbage collector code will use this data as a virtual function table (vftable) in order to make a virtual function call. An attacker has enough control over this data to allow execution of arbitrary code.
Software components such as memory managers often use magic values to mark memory as having a certain state. These magic values have often (but not always) been chosen to coincide with addresses that fall outside of the user-land address space on 32-bit versions of the Operating System. This ensures that if a vulnerability in the software allows an attacker to get the code to use such a value as a pointer, this results in an access violation. However, on 64-bit architectures the entire 32-bit address space can be used for user-land allocations, allowing an attacker to allocate memory at all the addresses commonly used as magic values and exploit such a vulnerability.
In my previous blog post I wrote about "magic values" that were originally chosen to help mitigate exploitation of memory corruption flaws and how this mitigation could potentially be bypassed on 64-bit Operating Systems, specifically Windows. In this blog post, I will explain how to create a heap spray (of sorts) that can be used to allocate memory in the relevant address space range and fill it with arbitrary data for use in exploiting such a vulnerability.
A specially crafted web-page can cause Microsoft Internet Explorer 9 to reallocate a memory buffer in order to grow it in size. The original buffer will be copied to newly allocated memory and then freed. The code continues to use the freed copy of the buffer.
(The fix and CVE number for this bug are not known)
A specially crafted web-page can cause Microsoft Internet Explorer 11 to free a memory block that contains information about an image. The code continues to use the data in freed memory block immediately after freeing it. It does not appear that there is enough time between the free and reuse to exploit this issue.
(The fix and CVE number for this bug are not known)
A specially crafted web-page can cause Microsoft Internet Explorer 10 to read data out-of-bounds. This issue was fixed before I was able to analyze it in detail, hence I did not determine exactly what the root cause was.
(The fix and CVE number for this bug are not known)
A specially crafted web-page can cause Microsoft Internet Explorer 9 to access data before the start of a memory block. An attack that is able to control what is stored before this memory block may be able to disclose information from memory or execute arbitrary code.
(MS14-080 and MS14-084, CVE-2014-6363)
A specially crafted script can cause the VBScript engine to access data before initializing it. An attacker that is able to run such a script in any application that embeds the VBScript engine may be able to control execution flow and execute arbitrary code. This includes all versions of Microsoft Internet Explorer.
(The fix and CVE number for this bug are not known)
A specially crafted script can cause the VBScript engine to read data beyond a memory block for use as a regular expression. An attacker that is able to run such a script in any application that embeds the VBScript engine may be able to disclose information stored after this memory block. This includes all versions of Microsoft Internet Explorer.
A specially crafted web-page can cause Microsoft Internet Explorer 9-11 to
assume a CSS value stored as a string can only be "true"
or "false"
. To
determine which of these two values it is, the code checks if the fifth
character is an 'e'
or a '\0'
. An attacker that is able to set it to a
smaller string can cause the code to read data out-of-bounds and is able to
determine if a WCHAR
value stored behind that string is '\0'
or not.
Accelerate your DevOps journey with OffSec. Build secure, scalable, and efficient software delivery pipelines through real-world training.
The post Infrastructure Automation and Defense: Introducing DevSecOps Essentials appeared first on OffSec.
Adam Rawnsley has spent the past decade reporting in-depth on Iran’s UAV industry and paying particular attention to the IRGC drone company Mado and its CEO Yousef Aboutalebi. One day in 2021, a self-professed “hacktivist” popped into Adam’s direct messages, told him his “group” had noticed Adam had done the most work on Mado, and dumped videos and documents allegedly hacked from the company’s network and CEO.
The material—painstakingly verified with the help of colleagues—fleshes out a portrait of the company Adam had been sketching out for years. Thanks to the additional sourcing and some help from colleagues at the Middlebury Institute of International Studies (MIIS) and work by others, we can now confirm that Mado engines are powering the Iranian drones raining down on Ukraine and are likely used in some of the cruise missiles Iran and its proxies have launched against Saudi Arabia and the United Arab Emirates.
Using the hacked documents and videos along with court records, web registration information, business records, and other open sources, Adam traces the rise of a key Iranian drone company from late 2000s aviation forum posts to contracts with some of the highest ranking generals in the Islamic Revolutionary Guard Corps. Mado’s trail starts in Iran but moves through China, Germany, Saudi Arabia, an Iranian motorcycle company, and finally Russia and Ukraine.
Adam Rawnsley is a reporter at Rolling Stone. He spent his career in journalism covering national and cybersecurity, primarily through the lens of open source reporting. He has written for Bellingcat, Foreign Policy, Wired, and The Daily Beast and guest lectured on open source and security issues at CyberWarCon (2022), John Hopkins University, Georgetown University, and Middlebury College.
This presentation was featured live at LABScon 2023, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLabs.
Keep up with all the latest on LABScon 2024 here.
By Joey Chen, Chetan Raghuprasad and Alex Karkins.
The campaign affects victims across multiple countries, including the U.S., Nigeria, Pakistan, Ecuador, Germany, Egypt, the U.K., Poland, the Philippines, Norway, Japan, Syria and Turkey, based on our telemetry data and OSINT information. Our telemetry also disclosed that some affected users were from Japan’s computer service call center organizations and civil defense service organizations in Syria. The affected users were downloading files masquerading as movie files through the browser, indicating the possibility of a widespread attack on users across various business verticals and geographies.
We observe that this threat actor is using a Content Delivery Network (CDN) cache to store the malicious files on their network edge host in this campaign, avoiding request delay. The actor is using the CDN cache as a download server to deceive network defenders.
CDN edge URLs | Information Stealer |
hxxps[://]techsheck[.]b-cdn[.]net/Zen90 | Cryptbot |
hxxps[://]zexodown-2[.]b-cdn[.]net/Peta12 | Cryptbot |
hxxps[://]denv-2[.]b-cdn[.]net/FebL5 | Cryptbot, Rhadamanthys |
hxxps[://]download-main5[.]b-cdn[.]net/BSR_v7IDcc | Rhadamanthys |
hxxps[://]dashdisk-2[.]b-cdn[.]net/XFeb18 | Cryptbot |
hxxps[://]metrodown-3[.]b-cdn[.]net/MebL1 | Cryptbot |
hxxps[://]metrodown-2[.]b-cdn[.]net/MebL1 | Cryptbot, LummaC2 |
hxxps[://]metrodown-2[.]b-cdn[.]net/SAq2 | LummaC2 |
Talos discovered that the actor is using multiple C2 domains in the campaign. The DNS requests for the domains during our analysis period are shown in the graph, indicating the campaign is ongoing.
Talos assesses with moderate confidence that threat actor CoralRaider is likely operating this campaign based on several overlaps in the TTPs used and the targeted victims’ geography of this campaign with that of the CoralRaider’s Rotbot campaign. We spotted that the PowerShell scripts used in the attack chain of this campaign to decrypt the PowerShell scripts of further stages and the downloader PowerShell script are similar to those employed in the Rotbot’s campaign.
PowerShell decryptor script of Rotbot campaign (left) and new unknown campaign (right). |
String decrypt and download routine of Rotbot campaign (Left) and new unknown campaign (right). |
The Powershell script did not appear in any public repository or article, indicating the threat actor likely developed these PowerShell scripts. Pivoting on the PowerShell argument embedded in the LNK file showed us that such arguments are not popular and likely specific to the actor and the campaign.
.(gp -pa 'HKLM:\SOF*\Clas*\Applications\msh*e').('PSChildName') |
The infection chain starts when a victim opens the malicious shortcut file from a ZIP file downloaded using the drive-by download technique, according to our telemetry. The threat actor is likely delivering malicious links to victims through phishing emails.
The Windows shortcut file has an embedded PowerShell command running a malicious HTA file on attacker-controlled CDN domains. HTA file executes an embedded Javascript, which decodes and runs a PowerShell decrypter script. PowerShell decrypter script decrypts the embedded PowerShell Loader script and runs it in the victim’s memory. The PowerShell Loader executes multiple functions to evade the detections and bypass UAC, and finally, it downloads and runs one of the payloads, Cryptbot, LummaC2 or Rhadamanthys information stealer.
Windows shortcut file runs a PowerShell command to download and run an HTML application file on the victim’s machine. The threat actor has used “gp,” a PowerShell command alias for Get-ItemProperty, to read the registry contents of the application classes registry key and gets the executable name “mshta.exe.” Using mshta.exe, the PowerShell instance executes the remotely hosted malicious HTA file on the victim’s machine.
The malicious HTML application file is heavily obfuscated and has a Javascript that decodes and executes a function using the String fromCharCode method. The decoded function then executes an embedded PowerShell decryptor script.
The decryptor PowerShell script has a block of AES-encrypted string. Using the AES decryptor function, it generates an AES key of 256 bytes from a base64 encoded string “RVRVd2h4RUJHUWNiTEZpbkN5SXhzUWRHeFN4V053THQ=” and the IV “AAAAAAAAAAAAAAAA.” With the key and IV, it decrypts and executes the next stage of the PowerShell Loader script.
The PowerShell loader script is modular and has multiple functions to perform a sequence of activities on the victim’s machine. Initially, it executes a function that drops a batch script in the victim machine’s temporary folder and writes its contents, which includes the PowerShell command to add the folder “ProgramData” of the victim machine to the Windows Defender exclusion list.
The dropped bath script is executed through a living-off-the-land binary (LoLBin) “FoDHelper.exe” and a Programmatic Identifiers (ProgIDs) registry key to bypass the User Access Controls (UAC) in the victim’s machine. Fodhelper is a Windows feature, an on-demand helper binary that runs by default with high integrity. Usually, when the FodHelper is run, it checks for the presence of the registry keys listed below. If the registry keys have commands assigned, the FodHelper will execute them in an elevated context without prompting the user.
HKCU:\Software\Classes\ms-settings\shell\open\command
HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute
HKCU:\Software\Classes\ms-settings\shell\open\command\(default)
Windows Defender, by default, detects if there are attempts to write to the registry keysHKCU:\Software\Classes\ms-settings\shell\open\command
and to evade this detection, the threat actor uses the programmatic identifier (ProgID). In Windows machines, a programmatic identifier (ProgID ) is a registry entry that can be associated with a Class ID (CLSID ), which is a globally unique serial number that identifies a COM (Component Object Model) class object. The Windows Shell uses a default ProgID registry key called CurVer
, which is used to set the default version of a COM application.
In this campaign, the threat actor abuses the “CurVer” registry key feature by creating a custom ProgID “ServiceHostXGRT” registry key in the software classes registry and assigns the Windows shell to execute a command to run the batch script.
Registry Key | "HKCU\Software\Classes\ServiceHostXGRT\Shell\Open\command" |
Value | %temp%\r.bat |
The script configures the ProgID ServiceHostXGRT
in the CurVer registry subkey of HKCU\Software\Classes\ms-settings\CurVer
, which will get translated to HKCU:\Software\Classes\ms-settings\shell\open\command
. After modifying the registry settings, the PowerShell script runs FoDHelper.exe, executing the command assigned to the registry key HKCU:\Software\Classes\ms-settings\shell\open\command
and executing the dropped batch script. Finally, it deletes the configured registry keys to evade detection.
The batch script adds the folder “C:\ProgramData” to the Windows Defender exclusion list. The PowerShell loader script downloads the payload and saves it in the “C:\ProgramData” folder as “X1xDd.exe.”
After downloading the payload to the victim’s machine, the PowerShell loader executes another function that overwrites the previously dropped batch file with the new instructions to run the downloaded payload information stealer through the Windows start command. It again uses the same FoDHelper technique to run the batch script’s second version, which we explained earlier in this section.
Talos discovered that the threat actor delivered three famous information stealer malware as payloads in this campaign, including CryptBot, LummaC2 and Rhadamanthys. These information stealers target victims’ information, such as system and browser data, credentials, cryptocurrency wallets and financial information.
CryptBot is a typical infostealer targeting Windows systems discovered in the wild in 2019 by GDATA. It is designed to steal sensitive information from infected computers, such as credentials from browsers, cryptocurrency wallets, browser cookies and credit cards, and creates screenshots of the infected system.
Talos has discovered a new CryptBot variant distributed in the wild since January 2024. The goal of the new CryptBot is the same, with some new innovative functionalities. The new CryptBot is packed with different techniques to obstruct malware analysis. A few new CryptBot variants are packed with VMProtect V2.0.3-2.13; others also have VMProtect, but with unknown versions. The new CryptBot attempts to steal sensitive information from infected machines and modifies the configuration changes of the stolen applications. The list of targeted browsers, applications and cryptocurrency wallets by the new variant of CryptBot is shown below.
We observed the new CryptBot variant also includes password manager application databases and authenticator application information in its stealing list to steal the cryptocurrency wallets that have two-factor authentication enabled.
CryptBot is aware that the target applications in the victim’s environment will have different versions, and their database files will have different file extensions. It scans the victim’s machine for database files’ extensions of the targeted applications for harvesting credentials.
Talos discovered that the actor is delivering a new variant of LummaC2 malware as an alternative payload in this campaign. LummaC2 is a notorious information stealer that attempts to harvest information from victims’ machines. Based on the report posted by outpost24 and other external security reports, LummaC2 has already been confirmed to be sold on the underground market for years.
The threat actor has modified LummaC2’s information stealer capability and obfuscated the malware with a custom algorithm. The obfuscation algorithm is saved in another section inside the malware shown below.
The new version of LummaC2 also presents the same signature of the alert message displayed to the user during its execution.
The C2 domains are encrypted with a symmetric algorithm, and we found that the actor has nine C2 servers that the malware will attempt to connect to one by one. Analyzing various samples of the new LummaC2 variant, we spotted that each will use a different key to encrypt the C2.
Talos has compiled the list of nine C2 domains the new LummaC2 variant attempts to connect in this campaign.
Encrypted strings | Decrypted Strings |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB+VXagKwrRr7BjLA71GNEZ8E8/0K2otQ== | peasanthovecapspll[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBpVXqwOAHAo75nPQT3Hc4I6EZ+x+u0rVjB | gemcreedarticulateod[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB9VXShLxDMqLFmPATgC8Ma+U14zKy0oBnC/kf0 | secretionsuitcasenioise[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBtXHa6JwfKqbxwOh79B8wb+UF0jbavqkc= | claimconcessionrebe[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBiWXaxIwjMs6Z0Ox/1BsUM8UZ/2qyz60TZ+Vg= | liabilityarrangemenyit[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBjX3O2ORDAtKx0MAjiDcwE9U9mxq7ptl/e5g== | modestessayevenmilwek[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB6Qn6yJAPJoqxwKB77BsAM8kB51K/ptl/e5g== | triangleseasonbenchwj[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBtRXunPxbAtLRwPQ78DssH/U1yyqSrqRnC/kf0 | culturesketchfinanciall[.]shop |
DjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB9X3GyIhHLs7Z7Lh74AcYM+Ep/xuu0rVjB | sofahuntingslidedine[.]shop |
LummaC2’s first step in its exfiltration phase is its connection to the C2 server. The malware will exit the process if it does not receive the “OK” message as a response from any of the nine C2 servers. The second step will be exfiltrating information from infected machines. The basic stealing functionality is the same as the previous version, with the addition of victims’ discord credentials to exfiltrate.
The last payload we found in this campaign is Rhadamanthys malware, a famous infostealer appearing in the underground forum advertisement in September 2022. The Rhadamanthys malware has been evolving till now, and its authors have released a new version, V0.6.0, on Feb. 15, 2024. However, the Rhadamanthys variant we found in this campaign is still v0.5.0.
The threat actor uses a Python executable file as a loader to execute the Rhadamanthys malware into memory. After decompiling the Python executable file, Python scripts load the Rhadamanthys malware in two stages. The first stage is a simple Python script that replaces the binary code from 0 to 9 and decodes the second stage.
In the second stage, the Python script uses the Windows API to allocate a memory block and inject Rhadamanthys malware into the process. We spotted that the threat actor is developing the Python script with the intention of including the functionality of executing a shellcode.
Analyzing the final executable file showed us that the malware unpacks the loader module with the custom format having the magic header “XS” and performs the process injection. The custom loader module in XS format is similar to that of a Rhadamanthys sample analyzed by the researcher at Check Point. The malware selects one of the listed processes as the target process for process injection from a hardcoded list in the binary:
Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.
Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.
Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.
Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.
Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.
Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.
Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.
Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.
Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.
Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort SID for this threat is 63218 - 63225 and 300867 - 300870.
ClamAV detections are also available for this threat:
Lnk.Downloader.CoralRaider-10027128-0
Txt.Tool.CoralRaider-10027140-0
Html.Downloader.CoralRaider-10027220-0
Win.Infostealer.Lumma-10027222-0
Win.Infostealer.Rhadamanthys-10027293-0
Win.Infostealer.Rhadamanthys-10027294-0
Win.Infostealer.Cryptbot-10027295-0
Win.Infostealer.Cryptbot-10027296-0
Win.Infostealer.Cryptbot-10027297-0
Win.Infostealer.Cryptbot-10027298-0
Win.Infostealer.Cryptbot-10027299-0
Win.Infostealer.Cryptbot-10027300-0
Win.Infostealer.Cryptbot-10027301-0
Win.Infostealer.Cryptbot-10027302-0
Win.Infostealer.Cryptbot-10027303-0
Win.Infostealer.Cryptbot-10027305-0
Indicators of Compromise associated with this threat can be found here.
We’ve been tracking a curious one here. Firstly, GuptiMiner is a highly sophisticated threat that uses an interesting infection chain along with a couple of techniques that include performing DNS requests to the attacker’s DNS servers, performing sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.
The main objective of GuptiMiner is to distribute backdoors within big corporate networks. We’ve encountered two different variants of these backdoors: The first is an enhanced build of PuTTY Link, providing SMB scanning of the local network and enabling lateral movement over the network to potentially vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands from the attacker to install more modules as well as focusing on scanning for stored private keys and cryptowallets on the local system.
Interestingly, GuptiMiner also distributes XMRig on the infected devices, which is a bit unexpected for such a thought-through operation.
The actors behind GuptiMiner have been capitalizing on an insecurity within an update mechanism of Indian antivirus vendor eScan to distribute the malware by performing a man-in-the-middle attack. We disclosed this security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.
GuptiMiner is a long-standing malware, with traces of it dating back to 2018 though it is likely that it is even older. We have also found that GuptiMiner has possible ties to Kimsuky, a notorious North Korean APT group, by observing similarities between Kimsuky keylogger and parts of the GuptiMiner operation.
In this analysis, we will cover the GuptiMiner’s features and its evolution over time. We will also denote in which samples the particular features are contained or introduced to support the overall comprehension in the vast range of IoCs.
It is also important to note that since the users rarely install more than one AV on their machine, we may have limited visibility into GuptiMiner’s activity and its overall scope. Because of this, we might be looking only at the tip of the iceberg and the true scope of the entire operation may still be subject to discovery.
To illustrate the complexity of the whole infection, we’ve provided a flow chart containing all parts of the chain. Note that some of the used filenames and/or workflows can slightly vary depending on the specific version of GuptiMiner, but the flowchart below illustrates the overall process.
The whole process starts with eScan requesting an update from the update server where an unknown MitM intercepts the download and swaps the update package with a malicious one. Then, eScan unpacks and loads the package and a DLL is sideloaded by eScan clean binaries. This DLL enables the rest of the chain, following with multiple shellcodes and intermediary PE loaders.
Resulted GuptiMiner consists of using XMRig on the infected machine as well as introducing backdoors which are activated when deployed in large corporate networks.
GuptiMiner has been active since at least 2018. Over the years, the developers behind it have improved the malware significantly, bringing new features to the table. We will describe the specific features in detail in respective subsections.
With that said, we also wanted to illustrate the significant IoCs in a timeline representation, how they changed over time – focusing on mutexes, PDBs, and used domains. These timelines were created based on scanning for the IoCs over a large sample dataset, taking the first and last compilation timestamps of the samples, then forming the intervals. Note that the scanned dataset is larger than listed IoCs in the IoC section. For more detailed list of IoCs, please visit our GitHub.
In general, GuptiMiner uses the following types of domains during its operations:
Malicious DNS
– GuptiMiner hosts their own DNS servers for serving true destination domain addresses of C&C servers via DNS TXT responses Requested domains
– Domains for which the malware queries the DNS servers for PNG download
– Servers for downloading payloads in the form of PNG files. These PNG files are valid images (a logo of T-Mobile) that contain appended shellcodes at their end Config mining pool
– GuptiMiner contains two different configurations of mining pools. One is hardcoded directly in the XMRig config which is denoted in this group Modified mining pool
– GuptiMiner has the ability to modify the pre-defined mining pools which is denoted in this group Final C&C
– Domains that are used in the last backdoor stage of GuptiMiner, providing additional malware capabilities in the backdoored systems Other
– Domains serving different purposes, e.g., used in scripts Note that as the malware connects to the malicious DNS servers directly, the DNS protocol is completely separated from the DNS network. Thus, no legitimate DNS server will ever see the traffic from this malware. The DNS protocol is used here as a functional equivalent of telnet. Because of this, this technique is not a DNS spoofing since spoofing traditionally happens on the DNS network.
Furthermore, the fact that the servers for which GuptiMiner asks for in the Requested domain
category actually exist is purely a coincidence, or rather a network obfuscation to confuse network monitoring tools and analysts.
From this timeline, it is apparent that authors behind GuptiMiner realize the correct setup of their DNS servers is crucial for the whole chain to work properly. Because of this, we can observe the biggest rotation and shorter timeframes are present in the Malicious DNS
group.
Furthermore, since domains in the Requested domain
group are irrelevant (at least from the technical viewpoint), we can notice that the authors are reusing the same domain names for longer periods of time.
Mutexes help ensure correct execution flow of a software and malware authors often use these named objects for the same purpose. Since 2018, GuptiMiner has changed its mutexes multiple times. Most significantly, we can notice a change since 2021 where the authors changed the mutexes to reflect the compilation/distribution dates of their new versions.
An attentive reader can likely observe two takeaways: The first is the apparent outliers in usage of MIVOD_6
, SLDV15
, SLDV13
, and Global\Wed Jun 2 09:43:03 2021
. According to our data, these mutexes were truly reused multiple times in different builds, creating larger timeframes than expected.
Another point is the re-introduction of PROCESS_
mutex near the end of last year. At this time, the authors reintroduced the mutex with the string in UTF-16 encoding, which we noted separately.
With regard to debugging symbols, the authors of GuptiMiner left multiple PDB paths in their binaries. Most of the time, they contain strings like MainWork
, Projects
, etc.
Everyone should update their software, right? Usually, the individual either downloads the new version manually from the official vendor’s site, or – preferably – the software itself performs the update automatically without much thought or action from the user. But what happens when someone is able to hijack this automatic process?
Our investigation started as we began to observe some of our users were receiving unusual responses from otherwise legitimate requests, for example on:
http://update3[.]mwti[.]net/pub/update/updll3.dlz
This is truly a legitimate URL to download the updll3.dlz
file which is, under normal circumstances, a legitimate archive containing the update of the eScan antivirus. However, we started seeing suspicious behavior on some of our clients, originating exactly from URLs like this.
What we uncovered was that the actors behind GuptiMiner were performing man-in-the-middle (MitM) to download an infected installer on the victim’s PC, instead of the update. Unfortunately, we currently don’t have information on how the MitM was performed. We assume that some kind of pre-infection had to be present on the victim’s device or their network, causing the MitM.
c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3
(version.dll, 2018-04-19 09:47:41 UTC)
Throughout the analysis, we will try to describe not just the flow of the infection chain, malware techniques, and functionalities of the stages, but we will also focus on different versions, describing how the malware authors developed and changed GuptiMiner over time.
The first GuptiMiner sample that we were able to find was compiled on Tuesday, 2018-04-19 09:47:41 and it was uploaded to VirusTotal the day after from India, followed by an upload from Germany:c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3
This file was named C:\Program Files\eScan\VERSION.DLL
which points out the target audience is truly eScan users and it comes from an update package downloaded by the AV.
Even though this version lacked several features present in the newer samples, the installation process is still the same, as follows:
updll62.dlz
is downloaded and unpacked by eScan updater version.dll
) that is sideloaded by eScan. Because of the sideloading, the DLL runs with the same privileges as the source process – eScan – and it is loaded next time eScan runs, usually after a system restart Mutex_ONLY_ME_V1
), the malware searches for services.exe
process and injects its next stage into the first one it can find The malicious DLL contains additional functions which are not present in the clean one. Thankfully the names are very verbose, so no analysis was required for most of them. The list of the functions can be seen below.
Some functions, however, are unique. For example, the function X64Call
provides Heaven’s gate, i.e., it is a helper function for running x64 code inside a 32-bit process on a 64-bit system. The malware needs this to be able to run the injected shellcode depending on the OS version and thus the bitness of the services.exe
process.
To keep the original eScan functionality intact, the malicious version.dll
also needs to handle the original legacy version.dll
functionality. This is done by forwarding all the exported functions from the original DLL. When a call of the legacy DLL function is identified, GuptiMiner resolves the original function and calls it afterwards.
After the shellcode is injected into services.exe
, it serves as a loader of the next stage. This is done by reading an embedded PE file in a plaintext form.
This PE file is loaded by standard means, but additionally, the shellcode also destroys the PE’s DOS header and runs it by calling its entry point, as well as it removes the embedded PE from the original location memory altogether.
Across the entire GuptiMiner infection chain, every shellcode which is loading and injecting PE files also manipulates the command line of the current process. This is done by manipulating the result of GetCommandLineA/W
which changes the resulted command line displayed for example in Task Manager.
After inspecting this functionality, we believe it either doesn’t work as the authors intended or we don’t understand its usage. Long story short, the command line is changed in such a way that everything before the first --parameter
is skipped, and this parameter is then appended to the process name.
To illustrate this, we could take a command:notepad.exe param1 --XX param2
which will be transformed into:notepad.exeXX param2
However, we have not seen a usage like power --shell.exe param1 param2
that would result into:powershell.exe param1 param2
nor have we seen any concealment of parameters (like usernames and passwords for XMRig), a type of behavior we would anticipate when encountering something like this. In either case, this functionality is obfuscating the command line appearance, which is worth mentioning. An interested reader can play around with the functionality at the awesome godbolt.org here.
7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6
(version.dll, 2018-06-12 03:30:01)
Another version with a mutex ONLY_ME_V3
introduced a code virtualization. This can be observed by an additional section in the PE file called .v_lizer
. This section was also renamed a few times in later builds.
Thankfully the obfuscation is rather weak, provided the shellcode as well as the embedded PE file are still in the plaintext form.
Furthermore, the authors started to distinguish between the version.dll
stage and the PE file loaded by the shellcode by additional mutex. Previously, both stages used the shared mutex ONLY_ME_Vx
, now the sideloading uses MTX_V101
as a mutex.
3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c
(2021-03-28 14:41:07 UTC)
The installation process has undergone multiple improvements over time, and, since it is rather different compared to older variants, we decided to describe it separately as an intermediary Stage 0.9. With these improvements, the authors introduced a usage of scheduled tasks, WMI events, two differently loaded next stages (Stage 1 – PNG loader), turning off Windows Defender, and installing crafted certificates to Windows.
There are also multiple files dropped at this stage, enabling further sideloading by the malware. These files are clean and serve exclusively for sideloading purposes. The malicious DLLs that are being sideloaded, are two PNG loaders (Stage 1):
de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 *atiadlxx.dll
e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee *BrLogAPI.dll
de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739
(atiadlxx.dll, 2021-03-28 14:30:11 UTC)
At this stage, WMI events are used for loading the first of the PNG loaders. This loader is extracted to a path:C:\PROGRAMDATA\AMD\CNext\atiadlxx.dll
Along with it, additional clean files are dropped, and they are used for sideloading, in either of these locations (can be both): C:\ProgramData\AMD\CNext\slsnotif.exe
C:\ProgramData\AMD\CNext\msvcr120.dll
orC:\Program Files (x86)\AMD\CNext\CCCSlim\slsnotify.exe
C:\Program Files (x86)\AMD\CNext\CCCSlim\msvcr120.dll
The clean file slsnotify.exe
is then registered via WMI event in such a way that it is executed when these conditions are met:
In other words, the sideloading is performed on a workday in either January, July, or November. The numbers represented by %d
are randomly selected values. The two possibilities for the hour are exactly two hours apart and fall within the range of 11–16 or 13–18 (inclusive). This conditioning further underlines the longevity of GuptiMiner operations.
e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee
(BrLogAPI.dll, 2021-03-28 14:10:27 UTC)
Similarly to the WMI events, GuptiMiner also drops a clean binary for sideloading at this location:C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe
The malicious PNG loader is then placed in one (or both) of these locations:C:\Program Files (x86)\Brother\Brmfl14c\BrLogAPI.dll
C:\Program Files\Brother\Brmfl14c\BrLogAPI.dll
The scheduled task is created by invoking a Task Scheduler. The scheduled task has these characteristics:
C:\Windows\System32\Tasks\Microsoft\Windows\Brother\Brmfl14c
C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe
C:\Program Files (x86)\Brother\Brmfl14c\
TASK_TRIGGER_BOOT
) with SYSTEM
privileges 3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c
(2021-03-28 14:41:07 UTC)
Let’s now look at how all these files, clean and malicious, are being deployed. One of GuptiMiner’s tricks is that it drops the final payload, containing PNG loader stage, only during the system shutdown process. Thus, this happens at the time other applications are shutting down and potentially not protecting the user anymore.
From the code above, we can observe that only when the SM_SHUTTINGDOWN
metric is non-zero, meaning the current session is shutting down, as well as all the supporting clean files were dropped successfully, the final payload DLL is dropped as well.
An engaged reader could also notice in the code above that the first function that is being called disables Windows Defender. This is done by standard means of modifying registry keys. Only if the Defender is disabled can the malware proceed with the malicious actions.
Most of the time, GuptiMiner uses self-signed binaries for their malicious activities. However, this time around, the attackers went a step further. In this case, both of the dropped PNG loader DLLs are signed with a custom trusted root anchor certification authority. This means that the signature is inherently untrusted since the attackers’ certification authority cannot be trusted by common verification processes in Windows.
However, during the malware installation, GuptiMiner also adds a root certificate to Windows’ certificate store making this certification authority trusted. Thus, when such a signed file is executed, it is understood as correctly signed. This is done by using CertCreateCertificateContext
, CertOpenStore
, and CertAddCertificateContextToStore
API functions.
The certificate is present in a plaintext form directly in the GuptiMiner binary file.
During our research, we found three different certificate issuers used during the GuptiMiner operations:
GTE Class 3 Certificate Authority
VeriSign Class 3 Code Signing 2010
DigiCert Assured ID Code Signing CA
Note that these names are artificial and any resemblance to legitimate certification authorities shall be considered coincidental.
8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049
(upgradeshow.dll, 2023-11-23 16:41:34 UTC)
At later development stages, authors behind GuptiMiner started to integrate even better persistence of their payloads by storing the payloads in registry keys. Furthermore, the payloads were also encrypted by XOR using a fixed key. This ensures that the payloads look meaningless to the naked eye.
We’ve discovered these registry key locations to be utilized for storing the payloads so far:
SYSTEM\CurrentControlSet\Control\Nls\Sorting\Ids\en-US
SYSTEM\CurrentControlSet\Control\PnP\Pci\CardList
SYSTEM\CurrentControlSet\Control\Wdf\DMCF
SYSTEM\CurrentControlSet\Control\StorVSP\Parsers
ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297
(2018-04-19 09:45:25 UTC)
When the entry point of the PE file is executed by the shellcode from Stage 0, the malware first creates a scheduled task to attempt to perform cleanup of the initial infection by removing updll62.dlz
archive and version.dll
library from the system.
Furthermore, the PE serves as a dropper for additional stages by contacting an attacker’s malicious DNS server. This is done by sending a DNS request to the attacker’s DNS server, obtaining the TXT record with the response. The TXT response holds an encrypted URL domain of a real C&C server that should be requested for an additional payload. This payload is a valid PNG image file (a T-Mobile logo) which also holds a shellcode appended to its end. The shellcode is afterwards executed by the malware in a separate thread, providing further malware functionality as a next stage.
Note that since the DNS server itself is malicious, the requested domain name doesn’t really matter – or, in a more abstract way of thinking about this functionality, it can be rather viewed as a “password” which is passed to the server, deciding whether the DNS server should or shouldn’t provide the desired TXT answer carrying the instructions.
As we already mentioned in the Domains timeline section, there are multiple of such “Requested domains” used. In the version referenced here, we can see these two being used:
ext.peepzo[.]com
crl.peepzo[.]com
and the malicious DNS server address is in this case:
ns1.peepzo[.]com
Here we can see a captured DNS TXT response using Wireshark. Note that Transaction ID = 0x034b
was left unchanged during all the years of GuptiMiner operations. We find this interesting because we would expect this could get easily flagged by firewalls or EDRs in the affected network.
The requests when the malware is performing the queries is done in random intervals. The initial request for the DNS TXT record is performed in the first 20 minutes after the PNG loader is executed. The consecutive requests, which are done for the malware’s update routine, wait up to 69 hours between attempts.
This update mechanism is reflected by creating separate mutexes with the shellcode version number which is denoted by the first two bytes of the decrypted DNS TXT response (see below for the decryption process). This ensures that no shellcode with the same version is run twice on the system.
After the DNS TXT record is received, GuptiMiner decodes the content using base64 and decrypts it with a combination of MD5 used as a key derivation function and the RC2 cipher for the decryption. Note that in the later versions of this malware, the authors improved the decryption process by also using checksums and additional decryption keys.
For the key derivation function and the decryption process, the authors decided to use standard Windows CryptoAPI functions.
Interestingly, a keen eye can observe an oversight in this initialization process shown above, particularly in the CryptHashData
function. The prototype of the CryptHashData API function is:
BOOL CryptHashData(
[in] HCRYPTHASH hHash,
[in] const BYTE *pbData,
[in] DWORD dwDataLen,
[in] DWORD dwFlags
);
The second argument of this function is a pointer to an array of bytes of a length of dwDataLen
. However, this malware provides the string L"POVO@1"
in a Unicode (UTF-16) format, represented by the array of bytes *pbData
.
Thus, the first six bytes from this array are only db 'P', 0, 'O', 0, 'V', 0
which effectively cuts the key in half and padding it with zeroes. Even though the malware authors changed the decryption key throughout the years, they never fixed this oversight, and it is still present in the latest version of GuptiMiner.
At this point, we would like to demonstrate the decrypted TXT record and how to parse it. In this example, while accessing the attacker’s malicious DNS server ns.srnmicro[.]net
and the requested domain spf.microsoft[.]com
, the server returned this DNS TXT response:
VUBw2mOgagCILdD3qWwVMQFPUd0dPHO3MS/CwpL2bVESh9OnF/Pgs6mHPLktvph2
After fully decoding and decrypting this string, we get:
This result contains multiple fields and can be interpreted as:
Name | Value |
Version 1 | 1 |
Version 2 | 5 |
Key size | \r (= 0xD ) |
Key | Microsoft.com |
C&C URL | http://www.deanmiller[.]net/m/ |
Checksum | \xde |
The first two bytes, Version 1 and Version 2, form the PNG shellcode version. It is not clear why there are two such versions since Version 2 is actually never used in the program. Only Version 1 is considered whether to perform the update – i.e., whether to download and load the PNG shellcode or not. In either case, we could look at these numbers as a major version and a minor version, and only the major releases serve as a trigger for the update process.
The third byte is a key size that denotes how many bytes should be read afterwards, forming the key. Furthermore, no additional delimiter is needed between the key and the URL since the key size is known and the URL follows. Finally, the two-byte checksum can be verified by calculating a sum of all the bytes (modulo 0xFF
).
After the DNS TXT record is decoded and decrypted, the malware downloads the next stage, from the provided URL, in the form of a PNG file. This is done by using standard WinINet
Windows API, where the User-Agent
is set to contain the bitness of the currently running process.
The C&C server uses the User-Agent
information for two things:
After the downloaded file is a valid PNG file which also contains a shellcode appended at the end. The image is a T-Mobile logo and has exactly 805
bytes. These bytes are skipped by the malware and the rest of the file, starting at an offset 0x325
, is decrypted by RC2 using the key provided in the TXT response (derived using MD5). The reason of using an image as this “prefix” is to further obfuscate the network communication where the payload looks like a legitimate image, likely overlooking the appended malware code.
After the shellcode is loaded from the position 0x325
, it proceeds with loading additional PE loader from memory to unpack next stages using Gzip.
294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a
(2023-11-09 14:19:45 UTC)
In late 2023, the authors decided to ditch the years-long approach of using DNS TXT records for distributing payloads and they switched to IP address masking instead.
This new approach consists of a few steps:
gethostbyname
API function 23.195.
as the first two octets The de-masking process is done by XORing each octet of the IP address by 0xA
, 0xB
, 0xC
, 0xD
, respectively. The result is then taken, and a hardcoded constant string is added to the URL path.
As an example, one such server we observed was www.elimpacific[.]net
. It was, at the time, returning:
The address 23.195.101[.]1
denotes a version and if it is greater than the current version, it performs the update by downloading the PNG file with the shellcode. This update is downloaded by requesting a PNG file from the real C&C server whose address is calculated by de-masking the 179.38.204[.]38
address:
The request is then made, along with the calculated IP address 185.45.192[.]43
and a hardcoded constant elimp
. Using a constant like this serves as an additional password, in a sense:185.45.192[.]43/elimp/
When the PNG file is downloaded, the rest of the process is the same as usual.
We’ve discovered two servers for this functionality so far:
Queried server | URL path constant |
www.elimpacific[.]net | elimp |
www.espcomp[.]net | OpenSans |
294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a
(2023-11-09 14:19:45 UTC)
Along with other updates described above, we also observed an evolution in using anti-VM and anti-debugging tricks. These are done by checking well known disk drivers, registry keys, and running processes.
GuptiMiner checks for these disk drivers by enumeratingHKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Disk\Enum
:
vmware
qemu
vbox
virtualhd
Specifically, the malware also checks the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Cylance
for the presence of Cylance AV.
As other anti-VM measures, the malware also checks whether the system has more than 4GB available RAM and at least 4 CPU cores.
Last but not least, the malware also checks the presence of these processes by their prefixes:
Process name prefix | Tool name |
wireshar | Wireshark |
windbg. | WinDbg |
tcpview | TCPView |
360 | 360 Total Security |
hips | Huorong Internet Security (hipsdaemon.exe ) |
proce | Process Explorer |
procm | Process Monitor |
ollydbg | OllyDbg |
6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414
(2023-02-22 14:03:04 UTC)
Similarly to Storing Payloads in Registry, in later stages of GuptiMiner, the authors also started to save the downloaded PNG images (containing the shellcodes) into registry as well. Contrary to storing the payloads, the images are not additionally XORed since the shellcodes in them are already encrypted using RC2 (see DNS TXT Record Decryption section for details).
We’ve discovered these registry key locations to be utilized for storing the encrypted images containing the shellcodes so far:
SYSTEM\CurrentControlSet\Control\Arbiters\Class
SYSTEM\CurrentControlSet\Control\CMF\Class
SYSTEM\CurrentControlSet\Control\CMF\CORE
SYSTEM\CurrentControlSet\Control\CMF\DEF
SYSTEM\CurrentControlSet\Control\CMF\Els
SYSTEM\CurrentControlSet\Control\CMF\ASN
SYSTEM\CurrentControlSet\Control\MSDTC\BSR
357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b
(2019-04-02 07:30:21 UTC)
This stage is the shortest, the Gzip loader, which is extracted and executed by the shellcode from the PNG file, is a simple PE that decompresses another shellcode using Gzip and executes it in a separate thread.
This thread additionally loads Stage 3, which we call Puppeteer, that orchestrates the core functionality of the malware – the cryptocurrency mining as well as, when applicable, deploying backdoors on the infected systems.
Throughout the GuptiMiner operations, Gzip loader has not been changed with later versions.
364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65
(2019-03-15 10:07:36 UTC)
Let’s now look at the biggest Stage 3, the Puppeteer. It pulls its strings everywhere across the infected system, manipulating the GuptiMiner components to do its bidding, hence the name we’ve chosen. It orchestrates further actions and deploys two core components of the malware – an XMRig coinminer and two types of backdoors that target devices present in large corporate networks. Of course, Puppeteer also introduces additional tricks to the arsenal of the whole GuptiMiner operation.
This stage also uses one of the many Global\SLDV
mutexes which we described in the Mutex timeline. For example, this particular sample uses SLDV01
as its mutex.
Puppeteer performs several steps for a proper setup. Firstly, it adds a new power scheme in Windows so the PC does not go to sleep. If the CPU has only one core (anti-VM) or the mutex already exists, the malware ceases to function by going to infinite sleep.
In the next phase, the malware kills all the processes with a name msiexec.exe
, cmstp.exe
, or credwiz.exe
. After that, it creates a separate thread that injects XMRig into a credwiz.exe process freshly created by the malware. The malware also disables Windows Defender by setting its service start status to disabled.
For the persistence, Puppeteer chose an interesting approach. Firstly, it creates a scheduled task with the following configuration:
rundll32.exe
file is copied and renamed into C:\ProgramData\Microsoft\Crypto\Escan\dss.exe
and this file is executed from the scheduled task C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3
and this file is loaded by dss.exe
(exported function ValidateFile
) TASK_TRIGGER_BOOT
) and TASK_RUNLEVEL_HIGHEST
priority C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade
With that, the malware copies the content of updll3.dll3
into memory and deletes the original file from disk. Puppeteer then waits for a system shutdown (similarly to Stage 0.9) by waiting for SM_SHUTTINGDOWN
metric to be set to non-zero value, indicating the shutdown. This is checked every 100 milliseconds. Only when the shutdown of the system is initiated, the malware reintroduces the updll3.dll3
file back onto disk.
Putting the malicious DLL back just before the system restart is really sneaky but also has potentially negative consequences. If the victim’s device encounters a crash, power outage, or any other kind of unexpected shutdown, the file won’t be restored from memory and Puppeteer will stop working from this point. Perhaps this is the reason why authors actually removed this trick in later versions, trading the sophistication for malware’s stability.
The repetitive loading of updll3.dll3
, as seen in the code above, is in fact Puppeteer’s update process. The DLL will ultimately perform steps of requesting a new PNG shellcode from the C&C servers and if it is a new version, the chain will be updated.
During the setup, Puppeteer created a separate thread for injecting an XMRig coinminer into credwiz.exe
process. Before the injection takes place, however, a few preparation steps are performed.
The XMRig configuration is present directly in the XMRig binary (standard JSON config) stored in the Puppeteer binary. This configuration can be, however, modified to different values on the fly. In the example below, we can see a dynamic allocation of mining threads depending on the robustness of the infected system’s hardware.
The injection is standard: the malware creates a new suspended process of credwiz.exe
and, if successful, the coinmining is injected and executed by WriteProcessMemory
and CreateRemoteThread
combo.
Puppeteer continuously monitors the system for running process, by default every 5 seconds. If it encounters any of the monitoring tools below, the malware kills any existing mining by taking down the whole credwiz.exe
process as well as it applies a progressive sleep, postponing another re-injection attempt by additional 5 hours.
taskmgr.exe
autoruns.exe
wireshark.exe
wireshark-gtk.exe
tcpview.exe
Furthermore, the malware needs to locate the current updll3.dll3
on the system so its latest version can be stored in memory, removed from disk, and dropped just before another system restart. Two approaches are used to achieve this:
HKEY_LOCAL_MACHINE\SOFTWARE\AVC3
download.exe
, which is a legitimate eScan binary, it obtains the file location to discover the folder. The output can look like this:
\Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe
The check for download.exe
serves as an alternative for locating eScan installation folder and the code seems heavily inspired by the example code of Obtaining a File Name From a File handle on MSDN.
Finally, Puppeteer also continuously monitors the CPU usage on the system and tweaks the core allocation in such a way it is not that much resource heavy and stays under the radar.
4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21
(2019-06-29 03:38:24 UTC)
The backdoor is set up by the previous stage, Puppeteer, by first discovering whether the machine is operating on a Windows Server or not. This is done by checking a DNS Server registry key (DNS Server service is typically running on a Windows Server edition):SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server
After that, the malware runs a command to check and get a number of computers joined in a domain:net group “domain computers” /domain
The data printed by the net group
command typically uses 25 characters per domain joined computer plus a newline (CR+LF
) per every three computers, which can be illustrated by the example below:
In this version of the backdoor setup, Puppeteer checks whether the number of returned bytes is more than 100. If so, Puppeteer assumes it runs in a network shared with at least five computers and downloads additional payloads from a hardcoded C&C (https://m.airequipment[.]net/gpse/
) and executes it using PowerShell command.
Note that the threshold for the number of returned bytes was different and significantly higher in later versions of GuptiMiner, as can be seen in a dedicated section discussing Modular Backdoor, resulting in compromising only those networks which had more than 7000 computers joined in the same domain!
If the checks above pass, Puppeteer uses a PowerShell command for downloading and executing the payload and, interestingly, it is run both in the current process as well as injected in explorer.exe
.
Furthermore, regardless of whether the infected computer is present in a network of a certain size or not, it tries to download additional payload from dl.sneakerhost[.]com/u
as well. This payload is yet another PNG file with the appended shellcode. We know this because the code uses the exact same parsing from the specific offset 0x325
of the PNG file as described in Stage 1. However, during our analysis, this domain was already taken down and we couldn’t verify what kind of payload was being distributed here.
The Puppeteer’s backdoor setup process was improved and tweaked multiple times during its long development. In the upcoming subsections, we will focus on more important changes, mostly those which influence other parts of the malware or present a whole new functionality.
In later versions, the attackers switched to the datetime mutex paradigm (as illustrated in Mutexes in Time section) and also introduced additional process monitoring of more Sysinternals tools like Process explorer, Process monitor, as well as other tools like OllyDbg, WinDbg, and TeamViewer.
487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd
(2023-11-21 18:05:43 UTC)
Additionally, the GuptiMiner authors also started to modify pool addresses in XMRig configurations with a new approach. They started using subdomains by “r
” and “m
” depending on the available physical memory on the infected system. If there is at least 3 GB of RAM available, the malware uses:m.domain.tld
with auto
mode and enabled huge pages.
If the available RAM is lesser than 3 GB, it uses:r.domain.tld
with light
mode and disabled huge pages.
In order to not keep things simple, the authors later also started to use “p
” as a subdomain in some versions, without any specific reason for the naming convention (perhaps just to say it is a “pool”).
The usage of all such domains in time can be seen in the Domains timeline.
Puppeteer used many different names and locations of DLLs over the years for sideloading or directly loading using scheduled tasks. For example, these might be:
C:\Program Files (x86)\eScan\updll3.dll3
C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL
C:\ProgramData\AMD\CNext\atiadlxx.dll
C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3
C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll
1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe
(2020-03-09 00:57:11 UTC)
We’ve also seen “cleaner” Puppeteers, meaning they didn’t contain the setup process for backdoors, but they were able to delete the malicious DLLs from the system when a running monitoring tool was detected.
1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4
(2021-03-01 10:43:27 UTC)
In this particular version, the deployment of the backdoor was performed once every 3 months, indicating a per-quarter deployment.
Since no one who puts such an effort into a malware campaign deploys just coinminers on the infected devices, let’s dig deeper into additional sets of GuptiMiner’s functionalities – deploying two types of backdoors on the infected devices.
07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d
(2021-03-01 10:31:33 UTC)E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb
One of the backdoors deployed by GuptiMiner is based on a custom build of PuTTY Link (plink
). This build contains an enhancement for local SMB network scanning, and it ultimately enables lateral movement over the network to potentially exploit Windows 7
and Windows Server 2008
machines by tunneling SMB traffic through the victim’s infected device.
First, the plink binary is injected into netsh.exe process by Puppeteer with the Deploy per-quarter approach. After a successful injection, the malware discovers local IP ranges by reading the IP tables from the victim’s device, adding those into local and global IP range lists.
With that, the malware continues with the local SMB scanning over the obtained IP ranges: xx.yy.zz.1-254
. When a device supporting SMB is discovered, it is saved in a dedicated list. The same goes with IPs that don’t support SMB, effectively deny listing them from future actions. This deny list is saved in specific registry subkeys named Sem
and Init
, in this location:HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class
where Init
contains the found IP addresses and Sem
contains their total count.
There are conditions taking place when such a scan is performed. For example, the scan can happen only when it is a day in the week (!)
, per-quarter deployment, and only at times between 12 PM and 18 PM. Here, we denoted by (!)
a unique coding artefact in the condition, since checking the day of the week is not necessary (always true).
Finally, the malware also creates a new registry key HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF
three hours after a successful scan. This serves as a flag that the scanning should be finished, and no more scanning is needed.
An even more interesting datetime-related bug can be seen in a conditioning of RNG\FFFF
registry removal. The removal is done to indicate that the malware can perform another SMB scan after a certain period of time.
As we can see in the figure below, the malware obtains the write time of the registry key and the current system time by SystemTimeToVariantTime
API function and subtracts those. The subtraction result is a floating-point number where the integral part means number of days.
Furthermore, the malware uses a constant 60*60*60*24=5184000
seconds (60 days) in the condition for the registry key removal. However, the condition is comparing VariantTime
(days) with seconds. Thus, the backdoor can activate every 51.84
days instead of the (intended?) 60 days. A true blessing in disguise.
After the local SMB scan is finished, the malware checks from the received SMB packet results whether any of the IP addresses that responded are running Windows 7
or Windows Server 2008
. If any such a system is found on the local network, the malware adds these IP addresses to a list of potential targets.
Furthermore, GuptiMiner executes the main()
legacy function from plink with artificial parameters. This will create a tunnel on the port 445
between the attacker’s server gesucht[.]net
and the victim’s device.
This tunnel is used for sending SMB traffic through the victim’s device to the IP addresses from the target list, enabling lateral movement over the local network.
Note that this version of Puppeteer, deploying this backdoor, is from 2021. We also mentioned that only Windows 7
and Windows Server 2008
are targeted, which are rather old. We think this might be because the attackers try to deploy an exploit for possible vulnerabilities on these old systems.
To orchestrate the SMB communication, the backdoor hand-crafts SMB packets on the fly by modifying TID
and UID
fields to reflect previous SMB communication. As shown in the decompiled code below, the SMB packet 4
, which is crafted and sent by the malware, contains both TID
and UID
from the responses of the local network device.
Here we provide an example how the SMB packets look like in Wireshark when sent by the malware. After the connection is established, the malware tries to login as anonymous and makes requests for \IPC$
and a named pipe.
Interested reader can find the captured PCAP on our GitHub.
f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4
(2023-10-10 15:08:36 UTC)
Another backdoor that we’ve found during our research being distributed by Puppeteer is a modular backdoor which targets huge corporate networks. It consists of two phases – the malware scans the devices for the existence of locally stored private keys and cryptocurrency wallets, and the second part is an injected modular backdoor, in the form of a shellcode.
This part of the backdoor focuses on scanning for private keys and wallet files on the system. This is done by searching for .pvk
and .wallet
files in these locations:
C:\Users\*
D:\*
E:\*
F:\*
G:\*
If there is such a file found in the system, its path is logged in a newly created file C:\Users\Public\Ca.txt
. Interestingly, this file is not processed on its own by the code we have available. We suppose the data will be stolen later when further modules are downloaded by the backdoor.
The fact that the scan was performed is marked by creating a registry key:HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG
If some private keys or wallets were found on the system or the malware is running in a huge corporate environment, the malware proceeds with injecting the backdoor, in a form of a shellcode, into the mmc.exe
process.
The size of the corporate environment is guessed by the same approach as Puppeteer’s backdoor setup with the difference in the scale. Here, the malware compares the returned list of computers in the domain with 200,000 characters. To recapitulate, the data printed by the net group
command uses 25 characters per domain joined computer plus a newline (CR+LF
) per every three computers.
This effectively means that the network in which the malware operates must have at least 7781 computers joined in the domain, which is quite a large number.
8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34
This shellcode is a completely different piece of code than what we’ve seen so far across GuptiMiner campaign. It is designed to be multi-modular with the capability of adding more modules into the execution flow. Only a networking communication module, however, is hardcoded and available by default, and its hash is 74d7f1af69fb706e87ff0116b8e4fa3a9b87275505e2ee7a32a8628a2d066549 (2022-12-19 07:31:39 UTC)
.
After the injection, the backdoor decrypts a hardcoded configuration and a hardcoded networking module using RC4. The RC4 key is also hardcoded and available directly in the shellcode.
The configuration contains details about which server to contact, what ports to use, the length of delays that should be set between commands/requests, among others. The domain for communication in this configuration is www.righttrak[.]net:443
and an IP address 185.248.160[.]141
.
The network module contains seven different commands that the attacker can use for instructing the backdoor about what to do. A complete list of commands accepted by the network module can be found in the table below. Note that each module that can be used by the backdoor contains such a command handler on its own.
Command | Description |
3.0 | Connect |
3.1 | Read socket |
3.2 | Write socket |
3.3 | Close socket |
4 | Close everything |
6 | Return 1 |
12 | Load configuration |
The modules are stored in an encrypted form in the registry, ensuring their persistence:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB
The backdoor also uses an import by hash obfuscation for resolving API functions. The hashing function is a simple algorithm that takes each byte of the exported function name, adds 1 to it, and then multiplies the previously calculated number (calculated_hash
, starts with 0) by 131 and adds it to the byte:
The server www.righttrak[.]net:443
had, at the time, a valid certificate. Note for example the not-at-all-suspicious email address the authors used.
af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b
During our research, we have also found a 7zip SFX executable containing two files:
ms00.dat
notepad.exe
notepad.exe
is a small binary that decrypts ms00.dat
file using RC4 with a key V#@!1vw32
. The decrypted ms00.dat
file is the same Modular Backdoor malware as described above.
However, we have not seen this SFX executable being distributed by GuptiMiner. This indicates that this backdoor might be distributed by different infection vectors as well.
We’ve also observed other more or less related samples during our research.
Interestingly, we’ve found the C&C domain from the backdoor setup phase (in Puppeteer) in additional scripts as well which were not distributed by traditional GuptiMiner operation as we know it. We think this might be a different kind of attack sharing the GuptiMiner infrastructure, though it might be a different campaign. Formatted PowerShell script can be found below:
In this case, the payload is downloaded and executed from the malicious domain only when an antivirus is installed, and its name has more than 4 letters and starts with eS
. One does not have to be a scrabble champion to figure out that the malware authors are targeting the eScan AV once again. The malicious code is also run when the name of the installed AV has less than 5 letters.
We’ve found this script being run via a scheduled task with a used command:"cmd.exe" /c type "\<domain>\SYSVOL\<domain>\scripts\gpon.inc" | "\<domain>\SYSVOL\<domain>\scripts\powAMD64.dat" -nop -
where powAMD64.dat
is a copy of powershell.exe
. The task name and location was C:\Windows\System32\Tasks\ScheduledDefrag
We have found two stolen certificates used for signing GuptiMiner payloads. Interestingly, one of the used stolen certificates originates in Winnti operations. In this particular sample, the digital signature has a hash: 529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56
This certificate is the same as mentioned by Kaspersky more than 10 years ago. However, we’ve also seen this certificate to be used in multiple malware samples than just GuptiMiner, though, indicating a broader leak.
A complete list of stolen certificates and their usage can be found in the table below:
Stolen certificate SHA1 | Signed GuptiMiner sample |
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 | 31dfba1b102bbf4092b25e63aae0f27386c480c10191c96c04295cb284f20878 |
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 | 8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049 |
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B | b0f94d84888dffacbc10bd7f9983b2d681b55d7e932c2d952d47ee606058df54 |
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B | f656a418fca7c4275f2441840faaeb70947e4f39d3826d6d2e50a3e7b8120e4e |
7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d
(2021-03-06 20:13:32 UTC)
During our research, we’ve also found an information stealer which holds a rather similar PDB path as was used across the whole GuptiMiner campaign (MainWork
):F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb
However, we haven’t seen it distributed by GuptiMiner and, according to our data, it doesn’t belong to the same operation and infection chain. This malware performs stealing activities like capturing every keystroke, harvesting HTML forms from opened browser tabs, noting times of opened programs, etc., and stores them in log files.
What is truly interesting, however, is that this information stealer might come from Kimsuky operations. Also known as Black Banshee, among other aliases, Kimsuky is a North Korean state-backed APT group.
It contains the similar approach of searching for AhnLab real-time detection window class name 49B46336-BA4D-4905-9824-D282F05F6576
as mentioned by both AhnLab as well as Cisco Talos Intelligence in their Information-gathering module section. If such a window is found, it will be terminated/hidden from the view of the infected user.
Furthermore, the stealer contains an encrypted payload in resources, having a hash: d5bc6cf988c6d3c60e71195d8a5c2f7525f633bb54059688ad8cfa1d4b72aa6c (2021-02-19 19.02.2021 15:00:47 UTC)
and it has this PDB path:F:\PROTECT\Real\startW-2008\HTTPPro\Release\HTTPPro.pdb
This module is decrypted using the standard RC4 algorithm with the key messi.com
. The module is used for downloading additional stages. One of the used URLs are:http://stwu.mygamesonline[.]org/home/sel.php
http://stwu.mygamesonline[.]org/home/buy.php?filename=%s&key=%s
The domain mygamesonline[.]org
is commonly used by Kimsuky (with variety of subdomains).
The keylogger also downloads next stage called ms12.acm
:
With this, we see a possible pattern with the naming convention and a link to Modular Backdoor. As described in the Other Infection Vectors section, the 7z SFX archive contains an encrypted file called ms00.dat
with which we struggle to ignore the resemblance.
Last but not least, another strong indicator for a possible attribution is the fact that the Kimsuky keylogger sample dddc57299857e6ecb2b80cbab2ae6f1978e89c4bfe664c7607129b0fc8db8b1f
, which is mentioned in the same blogpost from Talos, contains a section called .vlizer
, as seen below:
During the GuptiMiner installation process (Stage 0), we wrote about the threat actors introducing Code Virtualization in 2018. This was done by using a dedicated section called .v_lizer
.
In this analysis, we described our findings regarding a long-standing threat we called GuptiMiner, in detail. This sophisticated operation has been performing MitM attacks targeting an update mechanism of the eScan antivirus vendor. We disclosed the security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.
During the GuptiMiner operation, the attackers were deploying a wide chain of stages and functionalities, including performing DNS requests to the attacker’s DNS servers, sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.
Two different types of backdoors were discovered, targeting large corporate networks. The first provided SMB scanning of the local network, enabling lateral movement over the network to potentially exploit vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands on background to install more modules as well as focusing on stealing stored private keys and cryptowallets.
Interestingly, the final payload distributed by GuptiMiner was also XMRig which is a bit unexpected for such a thought-through operation.
We have also found possible ties to Kimsuky, a notorious North Korean APT group, while observing similarities between Kimsuky keylogger and fragments discovered during the analysis of the GuptiMiner operation.
We have shared our findings and our research with eScan prior to publishing this analysis. For the sake of completeness, we are including their statement on this topic:
“I would also like to highlight some key points:
1. Our records indicate that the last similar report was received towards the end of the year 2019.
2. Since 2020, we have implemented a stringent checking mechanism that utilizes EV Signing to ensure that non-signed binaries are rejected.
3. Multiple heuristic rules have been integrated into our solution to detect and block any instances of legitimate processes being used for mining, including the forking of unsigned binaries.
4. While our internal investigations did not uncover instances of the XRig miner, it is possible that this may be due to geo-location factors.
5. Our latest solution versions employ secure (https) downloads, ensuring encrypted communication when clients interact with our cloud-facing servers for update downloads.”
According to our telemetry, we continue to observe new infections and GuptiMiner builds within our userbase. This may be attributable to eScan clients on these devices not being updated properly.
In this section, we would like to summarize the Indicators of Compromise mentioned in this analysis. As they are indicators, it doesn’t automatically mean the mentioned files and/or domains are malicious on their own.
For more detailed list of IoCs of the whole GuptiMiner campaign, please visit our GitHub.
Domain |
_spf.microsoft[.]com |
acmeautoleasing[.]net |
b.guterman[.]net |
breedbackfp[.]com |
crl.microsoft[.]com |
crl.peepzo[.]com |
crl.sneakerhost[.]com |
desmoinesreg[.]com |
dl.sneakerhost[.]com |
edgesync[.]net |
espcomp[.]net |
ext.microsoft[.]com |
ext.peepzo[.]com |
ext.sneakerhost[.]com |
gesucht[.]net |
gesucht[.]net |
globalsign.microsoft[.]com |
icamper[.]net |
m.airequipment[.]net |
m.cbacontrols[.]com |
m.gosoengine[.]com |
m.guterman[.]net |
m.indpendant[.]com |
m.insomniaccinema[.]com |
m.korkyt[.]net |
m.satchmos[.]net |
m.sifraco[.]com |
ns.bretzger[.]net |
ns.deannacraite[.]com |
ns.desmoinesreg[.]com |
ns.dreamsoles[.]com |
ns.editaccess[.]com |
ns.encontacto[.]net |
ns.gravelmart[.]net |
ns.gridsense[.]net |
ns.jetmediauk[.]com |
ns.kbdn[.]net |
ns.lesagencestv[.]net |
ns.penawarkanser[.]net |
ns.srnmicro[.]net |
ns.suechiLton[.]com |
ns.trafomo[.]com |
ns.trafomo[.]com |
ns1.earthscienceclass[.]com |
ns1.peepzo[.]com |
ns1.securtelecom[.]com |
ns1.sneakerhost[.]com |
p.bramco[.]net |
p.hashvault[.]pro |
r.sifraco[.]com |
spf.microsoft[.]com |
widgeonhill[.]com |
www.bascap[.]net |
Mutex |
ESOCESS_ |
Global\Fri Aug 13 02:17:49 2021 |
Global\Fri Aug 13 02:22:55 2021 |
Global\Mon Apr 19 06:03:17 2021 |
Global\Mon Apr 24 07:19:54 2023 |
Global\Mon Feb 27 08:11:25 2023 |
Global\Mon Jun 14 03:22:57 2021 |
Global\Mon Mar 13 07:29:11 2023 |
Global\Mon Mar 22 09:16:00 2021 |
Global\Sun Jun 13 08:22:07 2021 |
Global\Thu Aug 10 03:25:11 2023 |
Global\Thu Aug 12 02:07:58 2021 |
Global\Thu Feb 23 08:37:09 2023 |
Global\Thu Mar 25 02:03:14 2021 |
Global\Thu Mar 25 09:31:19 2021 |
Global\Thu Nov 2 08:21:56 2023 |
Global\Thu Nov 9 06:19:40 2023 |
Global\Tue Apr 25 08:32:05 2023 |
Global\Tue Mar 23 02:37:32 2021 |
Global\Tue Oct 10 08:07:11 2023 |
Global\Wed Aug 11 09:16:37 2021 |
Global\Wed Jan 5 09:15:56 2022 |
Global\Wed Jun 2 09:43:03 2021 |
Global\Wed Mar 1 01:29:48 2023 |
Global\Wed Mar 23 08:56:01 2022 |
Global\Wed Mar 23 09:06:36 2022 |
Global\Wed May 10 06:38:46 2023 |
Global1 |
GlobalMIVOD_V4 |
GMCM1 |
MIVOD_6 |
MTX_EX01 |
Mutex_ONLY_ME_V1 |
Mutex_ONLY_ME_V2 |
Mutex_ONLY_ME_V3 |
PROCESS_ |
SLDV014 |
SLDV02 |
SLDV024 |
SLDV04 |
SLDV10 |
SLDV11 |
SLDV13 |
SLDV15 |
SLDV17 |
SLDV22 |
SLDV26 |
PDB path |
E:\projects\projects\RunCompressedSC\x64\Release\RunCompressedSC.pdb |
E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb |
F:\CODE-20221019\Projects\RunCompressedSC\x64\Release\RunCompressedSC.pdb |
F:\Pro\MainWork\Release\MainWork.pdb |
F:\Pro\MainWork\x64\Release\MainWork.pdb |
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-IPHLPAPI\Release\MainWork.pdb |
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-IPHLPAPI\x64\Release\MainWork.pdb |
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-nvhelper\Release\MainWork.pdb |
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-nvhelper\x64\Release\MainWork.pdb |
F:\Projects\RunCompressedSC\x64\Release\RunCompressedSC.pdb |
F:\V202102\MainWork-VS2017 – Monitor\Release\MainWork.pdb |
F:\V202102\MainWork-VS2017 – Monitor\x64\Release\MainWork.pdb |
H:\projects\MainWork\Release\MainWork.pdb |
IoC | Note |
http://update3[.]mwti[.]net/pub/update/updll3.dlz | |
c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3 | C:\Program Files\eScan\VERSION.DLL |
7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6 | updll65.dlz |
IoC | Note |
ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297 | |
ext.peepzo[.]com | |
crl.peepzo[.]com | |
ns1.peepzo[.]com | |
http://www.deanmiller[.]net/m/ | |
294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a | |
185.45.192[.]43/elimp/ | |
6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414 | |
SYSTEM\CurrentControlSet\Control\Arbiters\Class | Registry |
SYSTEM\CurrentControlSet\Control\CMF\Class | Registry |
SYSTEM\CurrentControlSet\Control\CMF\CORE | Registry |
SYSTEM\CurrentControlSet\Control\CMF\DEF | Registry |
SYSTEM\CurrentControlSet\Control\CMF\Els | Registry |
SYSTEM\CurrentControlSet\Control\CMF\ASN | Registry |
SYSTEM\CurrentControlSet\Control\MSDTC\BSR | Registry |
IoC | Note |
357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b |
Ioc | Note |
364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65 | |
C:\ProgramData\Microsoft\Crypto\Escan\dss.exe | |
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 | |
C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade | Scheduled task |
HKEY_LOCAL_MACHINE\SOFTWARE\AVC3 | Registry |
\Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe | |
4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21 | |
SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server | Registry |
net group ”domain computers” /domain | Command |
https://m.airequipment[.]net/gpse/ | |
487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd | |
C:\Program Files (x86)\eScan\updll3.dll3 | |
C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL | |
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL | |
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL | |
C:\ProgramData\AMD\CNext\atiadlxx.dll | |
C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll | |
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll | |
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 | |
C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll | |
1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe | |
1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4 |
IoC | Note |
07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d | |
E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb | PDB |
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class | Registry |
HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF | Registry |
gesucht[.]net | |
f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4 | |
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG | Registry |
8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34 | Shellcode |
74D7F1AF69FB706E87FF0116B8E4FA3A9B87275505E2EE7A32A8628A2D066549 | |
www.righttrak[.]net:443 | |
185.248.160[.]141 | |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB | Registry |
af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b |
IoC | Note |
“cmd.exe” /c type “\<domain>\SYSVOL\<domain>\scripts\gpon.inc” | “\<domain>\SYSVOL\<domain>\scripts\powAMD64.dat” -nop – | Command |
C:\Windows\System32\Tasks\ScheduledDefrag | Scheduled task |
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 | Certificate SHA1 |
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B | Certificate SHA1 |
31dfba1b102bbf4092b25e63aae0f27386c480c10191c96c04295cb284f20878 | |
8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049 | |
b0f94d84888dffacbc10bd7f9983b2d681b55d7e932c2d952d47ee606058df54 | |
f656a418fca7c4275f2441840faaeb70947e4f39d3826d6d2e50a3e7b8120e4e | |
7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d | |
F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb | PDB |
The post GuptiMiner: Hijacking Antivirus Updates for Distributing Backdoors and Casual Mining appeared first on Avast Threat Labs.
Last Week in Security is a summary of the interesting cybersecurity news, techniques, tools and exploits from the past week. This post covers 2024-04-16 to 2024-04-22.
This section is for news, techniques, write-ups, tools, and off-topic items that weren't released last week but are new to me. Perhaps you missed them too!
Techniques, tools, and exploits linked in this post are not reviewed for quality or safety. Do your own research and testing.
Microsoft Exchange 2019 prior to March 2024 used the Oracle Outside-In libraries to parse specific file types when attached to emails if an attachment inspection mail flow was configured. By default, Exchange has no mail flow rules configured. Several file types were identified to be processed by the server using the Outside-In SDK. Specifically, the following libraries loaded after using the sample Outside-In files as test attachments.
vspdf.dll
vshtml.dll
vseshr.dll
vsw97.dll
vspp12.dll
vsviso.dll
vspp97.dll
vsw12.dll
vsxl5.dll
These libraries are built to parse files and return any plaintext data they can. They live in a folder labelled TE_vXXX in the Exchange installation directory. However, they are repackaged Oracle Outside-In Content Access libraries. You can readily download the Content Access SDK and demo applications from Oracle directly. Other applications integrate this SDK as well, such as Oracle SQL Server and Oracle WebCenter Content Server.
Previous research into Outside-In by Joshua Drake and Will Dorman a decade ago showed that more digging into the framework could be fruitful. Atredis has identified several files that caused the Exchange file scanner to crash when using the OutsideInModule.dll library to parse attachments.
Exchange itself is configured to prefer Outside-In for some filetypes.
-<TypeList Name="PreferOutsideIn" ListType="Allowed">
<Type Name="Pdf"/>
<Type Name="Html"/>
</TypeList>
-<TypeList Name="OutsideInOnly" ListType="Allowed">
<Type Name="AutoCad"/>
<Type Name="Jpeg"/>
<Type Name="Tiff"/>
</TypeList>
However, we were unable to reproduce jpg and tiff vulnerabilities we found in the Outside-In libraries through Exchange. We also noticed that jpg and tiff were removed from the file types supported by file inspection by Exchange mail flows sometime after 2021. These configurations relative to tiff and jpg could be old and useless.
In order to fuzz the libraries, we used two different methods. One method was statically instrumenting the Linux version of the Outside-In Content Access libraries, then fuzzing with AFL. The other option chosen was to dynamically instrument and fuzz with Jackalope on Windows.
In order to fuzz with AFL, we used afl-dyninst. We used an older version of AFL and dyninst in these examples because it's what we've used in the past and knew it worked. However, a coworker has shown that AFL++ has pretty good dyninst support too. In the future, we'll certainly give it a try. To get things running quickly, we will instrument a simple binary shipped with Outside-In as a demo application called memoryio. It simply accepts a file as an argument and spits out any plaintext contents.
DYNINSTAPI_RT_LIB=libdyninstAPI_RT.so afl-dyninst -m 8 -i ../sdk/demo/memoryio -r libvs_viso.so -r libvs_w12.so -r libvs_eshr.so -r libvs_pp12.so -r libvs_pp97.so -o test
Note the -m 8 in the above command. It was found that instrumenting every basic block caused serious instability. Instead, we are instrumenting any basic blocks 8 bytes or larger. During testing, we also noticed that the library will actively write to ~/.oit while running for no useful reason. Creating the directory, but making it read-only, effectively bypassed this. Otherwise it caused stuttering and hangs.
After copying the instrumented libraries into the correct spots, we can run afl-fuzz. We use AFL_SKIP_BIN_CHECK because we used afl-dyninst to instrument an already-compiled utility called memoryio, rather than compiling our own harness.
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -M mainA:1/3 -- ./test @@
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -M mainB:2/3 -- ./test @@
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -M mainC:3/3 -- ./test @@
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -S subX -- ./test @@
We started 3 main fuzzers in parallel, each running on different deterministic phases. In general, running multiple main fuzzers is a bad idea since they will all perform the same work. However, in the configuration we set up, each fuzzer focuses on different deterministic stages. We then set up 10 sub fuzzers. These fuzzers perform a different kind of strategy than the deterministic main fuzzers. They make random changes to the inputs and just see what happens.
The machine we are fuzzing the Linux libraries on has 32 cores, so we have a bit more leg room. After those fuzzers were set up, a slightly different AFL configuration was used for spice.
AFL_SHUFFLE_QUEUE=1 AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -S subXX -- ./test @@
The AFL_SHUFFLE_QUEUE option was added onto 10 more sub fuzzers. This option takes the queue and randomizes the order of the inputs. In general, you shouldn't need to do this. However, we have so many fuzzers running that it's not going to hurt us in this particular instance and could easily help us.
After that, we get about 100 executions per second per fuzzer across 23 fuzzers. It's not amazing, but it'll do. If we wanted to speed things up in the future, we could implement our own harness with AFL persistent mode.
>>> sub4 (0 days, 20 hrs) <<<
cycle 61, lifetime speed 98 execs/sec, path 825/2389 (34%)
Preparing an environment to fuzz with Jackalope was straight forward. This was done by first cloning the most up to date Jackalope repository and following the build instructions. The fuzzing corpus used for most file formats was acquired from strongcourage's fuzzing-corpus repository. Additional corpus for the `xl5` format was also acquired from the internet with google dorks (Ex:?index.of? xls 1999
). The batch file used to execute the fuzzer can be seen below:
C:\Users\ali.ahmad\source\repos\Jackalope\build\Release\fuzzer.exe^
-in IN\pdf ^
-out Out\pdf^
-t 5000^
-nthreads 9^
-delivery shmem^
-nargs 2^
-instrument_module vspdf.dll^
-target_module memoryio_sharedmem.exe^
-target_offset 0x2900^
-dump_coverage^
-persist^
-loop^
-max_sample_size 0x100000^
-iterations 3000^
-cmp_coverage^
instrument_modules_on_load^
-dict "C:\Users\ali.ahmad\source\repos\AFLplusplus\dictionaries\pdf.dict"^
-- "D:\test\TE_v.8.5.3.0\memoryio_sharedmem.exe" @@
Shared memory sample delivery was also used improve fuzzer performance as can be seen by the -delivery shmem flag option. The memoryio sample program provided by Oracle as part of its Outside In library was modified to accept shared memory as input. In addition to shared memory delivery, persistent fuzzing was utilized as can be seen by the -persist flag to fuzz in persistent mode for an added performance boost.
We reported to Microsoft three crashes through our vector on Exchange. However, since the issues were in Oracle’s software, Oracle issued the vulnerability ID CVE-2024-21118.
Exchange will not try to use Outside-In on every file type the library itself supports. These crashes were reproduced by sending an email to the Exchange server with the malicious file attached. As stated previously, a mail flow inspection rule must be configured.
Microsoft subsequently disabled the Outside-In libraries in Exchange in the March 2024 Patch Tuesday updates. You can read more about the patches and advisory here. Atredis would specifically like to thank Lisa Olson and the whole Microsoft Security team for their heroic efforts in working through the disclosure.
Be sure to catch Ali talking more in-depth about our bug hunting and debugging process at RVAsec this summer.
This crash was a use-after-free.
# Child-SP RetAddr Call Site
00 000000ea`70d5c610 00007ffc`74141366 vshtml!HTMLWToF+0x11773
01 000000ea`70d5c790 00007ffc`74125204 vshtml!HTMLWToF+0x11726
02 000000ea`70d5c7c0 00007ffc`74130bb0 vshtml+0x5204
03 000000ea`70d5cbe0 00007ffc`74139070 vshtml!HTMLWToF+0xf70
04 000000ea`70d5ce30 00007ffc`74148eb5 vshtml!HTMLWToF+0x9430
05 000000ea`70d5cfe0 00007ffc`399db1c2 vshtml!VwStreamRead+0x305
06 000000ea`70d5d180 00007ffc`399d34fb sccch!CHUnpackageRemoteData+0x7ab2
07 000000ea`70d5d240 00007ffc`399d3048 sccch!CHReadAhead+0xfb
08 000000ea`70d5d2a0 00007ffc`4b634e20 sccch!CHNextItemId+0x158
09 000000ea`70d5d2f0 00007ffc`3cf589dc sccca!CAReadNext+0x1fe0
0a 000000ea`70d5d730 00007ffc`3cf5a111 OutsideInModule!CreateTextExtractorModule+0x775c
0b 000000ea`70d5e7d0 00007ffc`3d1a9b4a OutsideInModule!CreateTextExtractorModule+0x8e91
0c 000000ea`70d5e810 00007ffc`3d1a9630 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x7842a
0d 000000ea`70d5e8d0 00007ffc`3d1ab361 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x77f10
0e 000000ea`70d5e990 00007ffc`3d159d47 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x79c41
0f 000000ea`70d5e9d0 00007ffc`3d15e194 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x28627
10 000000ea`70d5ec20 00007ffc`3d15f2db Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2ca74
11 000000ea`70d5ed60 00007ffc`3d15efc2 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2dbbb
12 000000ea`70d5eec0 00007ffc`3d15e775 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d8a2
13 000000ea`70d5f000 00007ffc`3d13bcbf Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d055
14 000000ea`70d5f1c0 00007ffc`3d13c8c9 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xa59f
15 000000ea`70d5f200 00007ffc`3d133757 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xb1a9
16 000000ea`70d5f3b0 00007ffc`3d133455 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2037
17 000000ea`70d5f4f0 00007ff6`d60a5379 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x1d35
18 000000ea`70d5f5b0 00007ff6`d6092d7f scanningprocess+0x15379
19 000000ea`70d5f920 00007ffc`936c91ca scanningprocess+0x2d7f
1a 000000ea`70d5f950 00007ffc`9366bb26 ntdll!TppWorkpExecuteCallback+0x13a
1b 000000ea`70d5f9a0 00007ffc`92c84de0 ntdll!TppWorkerThread+0x686
1c 000000ea`70d5fc90 00007ffc`936dec4b KERNEL32!BaseThreadInitThunk+0x10
1d 000000ea`70d5fcc0 00000000`00000000 ntdll!RtlUserThreadStart+0x2b
This crash was an invalid write.
# Child-SP RetAddr Call Site
00 0000003a`a65bcb00 00007ff9`e845621e vsxl5!PutPrintArea+0x2ab8
01 0000003a`a65bcb60 00007ff9`e8455798 vsxl5!PutPrintArea+0x20ce
02 0000003a`a65bcc00 00007ff9`e844bd4e vsxl5!PutPrintArea+0x1648
03 0000003a`a65bcd70 00007ff9`e845c501 vsxl5+0x1bd4e
04 0000003a`a65bced0 00007ff9`c214af8b vsxl5!VwStreamSection+0x7e1
05 0000003a`a65bcfa0 00007ff9`c21434fb sccch!CHUnpackageRemoteData+0x787b
06 0000003a`a65bd060 00007ff9`c21420de sccch!CHReadAhead+0xfb
07 0000003a`a65bd0c0 00007ff9`d25b2cc4 sccch!CHGetItemId+0x5e
08 0000003a`a65bd100 00007ff9`e9148a07 sccca!CAReadFirst+0xd4
09 0000003a`a65bd200 00007ff9`e914a111 OutsideInModule!CreateTextExtractorModule+0x7787
0a 0000003a`a65be2a0 00007ff9`ba939b4a OutsideInModule!CreateTextExtractorModule+0x8e91
0b 0000003a`a65be2e0 00007ff9`ba939630 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x7842a
0c 0000003a`a65be3a0 00007ff9`ba93b361 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x77f10
0d 0000003a`a65be460 00007ff9`ba8e9d47 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x79c41
0e 0000003a`a65be4a0 00007ff9`ba8ee194 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x28627
0f 0000003a`a65be6f0 00007ff9`ba8ef2db Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2ca74
10 0000003a`a65be830 00007ff9`ba8eefc2 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2dbbb
11 0000003a`a65be990 00007ff9`ba8ee775 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d8a2
12 0000003a`a65bead0 00007ff9`ba8cbcbf Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d055
13 0000003a`a65bec90 00007ff9`ba8cc8c9 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xa59f
14 0000003a`a65becd0 00007ff9`ba8c3757 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xb1a9
15 0000003a`a65bee80 00007ff9`ba8c3455 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2037
16 0000003a`a65befc0 00007ff7`12465379 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x1d35
17 0000003a`a65bf080 00007ff7`12452d7f scanningprocess+0x15379
18 0000003a`a65bf3f0 00007ffa`0fc091ca scanningprocess+0x2d7f
19 0000003a`a65bf420 00007ffa`0fbabb26 ntdll!TppWorkpExecuteCallback+0x13a
1a 0000003a`a65bf470 00007ffa`0f5c4de0 ntdll!TppWorkerThread+0x686
1b 0000003a`a65bf760 00007ffa`0fc1ec4b KERNEL32!BaseThreadInitThunk+0x10
1c 0000003a`a65bf790 00000000`00000000 ntdll!RtlUserThreadStart+0x2b
This crash was an invalid read.
# Child-SP RetAddr Call Site
00 000000b2`54e7c070 00007ffc`21288e30 vspdf+0x9a1a
01 000000b2`54e7c160 00007ffc`2127b467 vspdf+0x18e30
02 000000b2`54e7c2b0 00007ffc`2127e596 vspdf+0xb467
03 000000b2`54e7c2e0 00007ffc`21290c3c vspdf+0xe596
04 000000b2`54e7c8a0 00007ffb`e4f9b1c2 vspdf!PDFSpecialTell+0x5dc
05 000000b2`54e7cdb0 00007ffb`e4f934fb sccch!CHUnpackageRemoteData+0x7ab2
06 000000b2`54e7ce70 00007ffb`e4f93048 sccch!CHReadAhead+0xfb
07 000000b2`54e7ced0 00007ffb`f7964e20 sccch!CHNextItemId+0x158
08 000000b2`54e7cf20 00007ffb`eb9689dc sccca!CAReadNext+0x1fe0
09 000000b2`54e7d360 00007ffb`eb96a111 OutsideInModule!CreateTextExtractorModule+0x775c
0a 000000b2`54e7e400 00007ffb`e9ac9b4a OutsideInModule!CreateTextExtractorModule+0x8e91
0b 000000b2`54e7e440 00007ffb`e9ac9630 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x7842a
0c 000000b2`54e7e500 00007ffb`e9acb361 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x77f10
0d 000000b2`54e7e5c0 00007ffb`e9a79d47 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x79c41
0e 000000b2`54e7e600 00007ffb`e9a7e194 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x28627
0f 000000b2`54e7e850 00007ffb`e9a7f2db Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2ca74
10 000000b2`54e7e990 00007ffb`e9a7efc2 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2dbbb
11 000000b2`54e7eaf0 00007ffb`e9a7e775 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d8a2
12 000000b2`54e7ec30 00007ffb`e9a5bcbf Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d055
13 000000b2`54e7edf0 00007ffb`e9a5c8c9 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xa59f
14 000000b2`54e7ee30 00007ffb`e9a53757 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xb1a9
15 000000b2`54e7efe0 00007ffb`e9a53455 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2037
16 000000b2`54e7f120 00007ff6`9fbd5379 Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x1d35
17 000000b2`54e7f1e0 00007ff6`9fbc2d7f scanningprocess+0x15379
18 000000b2`54e7f550 00007ffc`41a091ca scanningprocess+0x2d7f
19 000000b2`54e7f580 00007ffc`419abb26 ntdll!TppWorkpExecuteCallback+0x13a
1a 000000b2`54e7f5d0 00007ffc`412b4de0 ntdll!TppWorkerThread+0x686
1b 000000b2`54e7f8c0 00007ffc`41a1ec4b KERNEL32!BaseThreadInitThunk+0x10
1c 000000b2`54e7f8f0 00000000`00000000 ntdll!RtlUserThreadStart+0x2b
Today on Cyber Work, we are talking operational technology, or OT, security with guest, Robin Berthier of Network Perception. From his earliest studies to his time as an academic researcher, Berthier has dedicated his career to securing the intersection between operational technology and network security, with some pretty imaginative solutions to show for it. In today’s episode, Berthier explains why modern OT security means thinking more about the mechanics of the machinery than the swiftness of the software solutions, the big conversation that infrastructure and ICS Security need to have about nation-state attackers (and finally are having!) and Berthier's best piece of career advice turns into some excellent thoughts on the importance of maintaining your network… and I don’t mean routing and switching!
0:00 - Industrial control systems cybersecurity
1:54 - How Robin Berthier got into tech
3:38 - Majoring in cybersecurity
4:55 - Intrusion detection systems
9:18 - Mechanical and cybersecurity tools
12:33 Launching Network Perception
17:03 - Current state of ICS and OT infrastructure
20:24 - Cyberattacks on industrial control systems
28:35 -Skills needed to work in industrial control systems
35:19 - Where are ICS security jobs?
36:39 - Getting into local OT systems
37:55 - Skills gaps in ICS
39:21 - Best piece of career advice
41:01 - Cultivating a work network
43:28 - What is Network Perception?
45:27 - Learn more about Robin Berthier
45:58 - Outro
– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast
About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.
Organizations are increasingly turning to cloud computing for IT agility, resilience and scalability. Amazon Web Services (AWS) stands at the forefront of this digital transformation, offering a robust, flexible and cost-effective platform that helps businesses drive growth and innovation.
However, as organizations migrate to the cloud, they face a complex and growing threat landscape of sophisticated and cloud-conscious threat actors. Organizations with ambitious digital transformation strategies must be prepared to address these security challenges from Day One. The potential threat of compromise underscores the critical need to understand and implement security best practices tailored to the unique challenges of cloud environments.
Central to understanding and navigating these challenges is the AWS shared responsibility model. AWS is responsible for delivering security of the cloud, including the security of underlying infrastructure and services. Customers are responsible for protecting their data, applications and resources running in the cloud. This model highlights the importance of proactive security measures at every phase of cloud migration and operation and helps ensure businesses maintain a strong security posture.
In this blog, we cover five best practices for securing AWS resources to help you gain a better understanding of how to protect your cloud environments as you build in the cloud.
Cloud assets are not limited to compute instances (aka virtual machines) — they extend to all application workloads spanning compute, storage, networking and an extensive portfolio of managed services.
Understanding and maintaining an accurate inventory of your AWS assets is foundational to securing your cloud environment. Given the dynamic nature of cloud computing, it’s not uncommon for organizations to inadvertently lose track of assets running in their AWS accounts, which can lead to risk exposure and attacks on unprotected resources. In some cases, accounts created early in an organization’s cloud journey may not have the standard security controls that were implemented later on. In another common scenario, teams may forget about and unintentionally remove mitigations put in place to address application-specific exceptions, exposing those resources to potential attack.
To maintain adequate insight and awareness of all AWS assets in production, organizations should consider implementing the following:
CrowdStrike Falcon® Cloud Security makes it easy to implement these practices by offering a consolidated platform that integrates with AWS features to maintain coverage across a customer’s entire multi-account environment. Falcon Cloud Security offers CSPM, which leverages AWS EventBridge, IAM cross-account roles and CloudTrail API audit telemetry to provide continuous asset discovery, scan for misconfigurations and suspicious behavior, improve least-privilege controls and deploy runtime protection on EC2 and EKS clusters as they’re provisioned. It guides customers on how to secure their cloud environments to accelerate the learning of cloud security skills and the time-to-value for cloud initiatives. Cloud Operations teams can deploy AWS Security Hub with the CrowdStrike Falcon® Integration Gateway to view Falcon platform detections and trigger custom remediations inside AWS. AWS GuardDuty leverages CrowdStrike Falcon® Adversary Intelligence indicators of compromise and can provide an additional layer of visibility and protection for cloud teams.
Stolen credentials pose a severe threat — whether they are user names and passwords or API key IDs and secrets — allowing adversaries to impersonate legitimate users and bypass identity-based access controls. This risk is exacerbated by scenarios where administrator credentials and hard-coded passwords are inadvertently stored in public-facing locations or within code repositories accessible online. Such exposures give attackers the opportunity to intercept live access keys, which they can use to authenticate to cloud services, posing as trusted users.
In cloud environments, as well as on-premises, organizations should adopt identity security best practices such as avoiding use of shared credentials, assigning least-privilege access policies and using a single source of truth through identity provider federation and single sign-on (SSO). AWS services such as IAM, Identity Center and Organizations can facilitate secure access to AWS services by supporting the creation of granular access policies, enabling temporary session tokens, and reporting on cross-account trusts and excessively permissive policies, thus minimizing the likelihood and impact of access key exposure. By implementing MFA in conjunction with SSO, role-based access and temporary sessions, organizations make it much harder for attackers to steal credentials and, more importantly, to effectively use them.
Falcon Cloud Security includes cloud infrastructure entitlement management (CIEM), which evaluates whether IAM roles are overly permissive and provides the visibility to make changes with awareness of which resources will be impacted. Additionally, Falcon Cloud Security conducts pre-runtime scanning of container images and infrastructure-as-code (IaC) templates to uncover improperly elevated Kubernetes pod privileges and hard-coded credentials to prevent credential theft and lateral movement. Adding the CrowdStrike Falcon® Identity Protection module delivers strong protection for Active Directory environments, dynamically identifying administrator and service accounts and anomalous or malicious use of credentials, and allowing integration with workload detection and response actions.
The inadvertent public exposure and misconfiguration of cloud resources such as EC2 instances, Relational Database Service (RDS) and containers on ECS and EKS through overly permissive network access policies pose a risk to the security of cloud workloads. Such lapses can accidentally open the door to unauthorized access to vulnerable services, providing attackers with opportunities to exploit weaknesses for data theft, launching further attacks and moving laterally within the cloud environment.
To mitigate these risks and enhance cloud security posture, organizations should:
Falcon Cloud Security continuously monitors AWS service configurations for best practices, both in live environments and in pre-runtime IaC templates as part of a CI/CD or GitOps pipeline. Overly permissive network security policies are dynamically discovered and recorded as indicators of misconfiguration (IOMs), which are automatically correlated with all other security telemetry in the environment, along with insight into how the misconfiguration can be mitigated by the customer or maliciously used by the adversary.
Adversaries are becoming more skilled in attacking cloud environments, as evidenced by a 75% increase in cloud intrusions year-over-year in 2023. They are also growing faster: The average breakout time for eCrime operators to move laterally from one breached host to another host was just 62 minutes in 2023. The rise of new technologies, such as generative AI, has the potential to lower the barrier to entry for less-skilled adversaries, making it easier to launch sophisticated attacks. Amid these evolving trends, effective alert management is paramount.
Cloud services are built to deliver a constant stream of API audit and service access logs, but sifting through all of this data can overwhelm security analysts and detract from their ability to focus on genuine threats. While some logs may indicate high-severity attacks that demand immediate response, most tend to be informational and often lack direct security implications. Generating alerts based on this data can be imprecise, potentially resulting in many false positives, each of which require SecOps investigation. Alert investigations can consume precious time and scarce resources, leading to a situation where noisy security alerts prevent timely detection and effective response.
To navigate this complex landscape and enhance the effectiveness of cloud security operations, several best practices can be adopted to manage and prioritize alerts efficiently:
AWS Services like AWS GuardDuty, which is powered in part by CrowdStrike Falcon Adversary Intelligence indicators of compromise (IOCs), help surface and alert on suspicious and malicious activity within AWS accounts, prioritizing indicators of attack (IOAs) and IOCs based on risk severity.
Falcon Cloud Security is a complete cloud security platform that unifies world-class threat intelligence and elite threat hunters. Falcon Cloud Security correlates telemetry and detections across IOMs, package vulnerabilities, suspicious behavior, adversary intelligence and third-party telemetry ingested through a library of data connectors to deliver a context-based risk assessment, which reduces false positives and automatically responds to stop breaches.
Adversaries that gain access to a compromised account can operate virtually undetected, limited only by the permissions granted to the account they used to break in. This stealthiness is compounded by the potential for log tampering and manipulation, where malicious actors may alter or delete log files to erase evidence of their activities. Such actions make it challenging to trace the adversary’s movements, evaluate the extent of data tampering or theft, and understand the full scope of the security incident. The lack of a comprehensive audit trail due to disabled or misconfigured logging mechanisms hinders the ability to maintain visibility over cloud operations, making it more difficult to detect and respond to threats.
In response, organizations can:
Falcon Cloud Security integrates with over 50 AWS services to deliver effective protection at every stage of the cloud journey, combining multi-account deployment automation, sensor-based runtime protection, agentless API attack and misconfiguration detection, and pre-runtime scanning of containers, Lambda functions and IaC templates.
CrowdStrike leverages real-time IOAs, threat intelligence, evolving adversary tradecraft and enriched telemetry from across vectors such as endpoint, cloud, identity and more. This not only enhances threat detection, it also facilitates automated protection, remediation and elite threat hunting, aligned closely with understanding AWS assets, enforcing strict access control and authentication measures, and ensuring meticulous monitoring and management of cloud resources.
You can try Falcon Cloud Security through a Cloud Security Health Check, during which you’ll engage in a one-on-one session with a cloud security expert, evaluate your current cloud environment, and identify misconfigurations, vulnerabilities and potential cloud threats.
CrowdStrike Falcon® Next-Gen SIEM unifies data, AI, automation and intelligence in one AI-native platform to stop breaches. Falcon Next-Gen SIEM extends CrowdStrike’s industry-leading detection and response and expert services to all data, including AWS logs, for complete visibility and protection. Your team can detect and respond to cloud-based threats in record time with real-time alerts, live dashboards and blazing-fast search. Native workflow automation lets you streamline analysis of cloud incidents and say goodbye to tedious tasks.
For the first time ever, your analysts can investigate cloud-based threats from the same console they use to manage cloud workload security and CSPM. CrowdStrike consolidates multiple security tools, including next-gen SIEM and cloud security, on one platform to cut complexity and costs. Watch a 3-minute demo of Falcon Next-Gen SIEM to see it in action.