Why are there more and more cyber attacks on software development environments and how is software company security becoming a key issue in the supply chain?
Recently, an interesting latent malware infection was found on a newly onboarded machine at one of our clients (Client). Microsoft Defender for Endpoint (MDE) reported anomalies about the computer shortly after onboarding, but uncovering the inner workings of the malware and the infection methods required thorough investigation We present the second part of the investigation in this article with the Client’s approval.
Continuing on, we loaded the extension standalone into a clean browser inside a virtual machine (VM) to inspect the related network connections and communication. For the investigation, the VM internet connection was proxied over Burp Proxy.
The extension was loaded into a fresh, up-to-date Edge browser. After the initial loading, the extension showed the attributes of small size, clean icon, and empty name:
The extension in the toolbar gave nothing as depicted below:
After the installation of the extension, the malware started communicating with the “de.withtls[.]net” domain to register itself and obtained the configuration in JSON structure (see Appendix 1).
For example, in this JSON, there are various advertising-related German domain entries to keep track of:
The extension can inject arbitrary externally hosted JS file as well into any visited webpage:
Another aspect of the extension is that it is proxying any search term over the malicious actor infrastructure. Here the tested search term was “How to download more RAM” in Google, and a response communication came back with a yahoo search term:
Furthermore, the extension has a Google-Analytics identifier, giving the ability to the attacker to further track the victim trough the visited sites, in addition it injects standard Google trackers into any page that the user opens to keep the tracking ability up.
Reverse engineering the hijacker dll
Since we used Edge browser in our lab environment, the malware installed the fake cryptbase.dll at the following path:
The static analysis presented the main functionalities and apparent goals of the executable, leading us to look after any thread injection, as it manipulates memory page protection to change it to a Read-Write-Execute and suspend – inject – resume thread:
We loaded the sample in disassembler to follow the execution flow. At first, it loaded the legitimate cryptbase.dll from the System32 folder.
The target thread is specified in the code that will be injected. In our case, it was the so-called NetGetJoinInformation’s thread, in which the shellcode has been injected.
After that, it enumerates the threads in the snapshot created by CreateToolhelp32Snapshot API, injects its shellcode and changes the protection of the targeted memory page to RWX.
Here is the thread injection itself in the code. At the middle, it updates the target thread’s instruction pointer (RIP register) to point to the shellcode, which was written into the target process’ memory:
Regarding this thread injection technique, we highly recommend the following article which gives information from the perspective of red teams in detail:
Vulnerable official Node.js end-of-life version in default location: node-v6.10.3-x86.msi SHA256:d4000be1329737bd2f4c2e54abc939ca249c11cbcc8898240fece37cb74cf09f
Recently, an interesting latent malware infection was found on a newly onboarded machine at one of our clients (Client). Microsoft Defender for Endpoint (MDE) reported anomalies about the computer shortly after onboarding, but uncovering the inner workings of the malware [...]
Why are there more and more cyber attacks on software development environments and how is software company security becoming a key issue in the supply chain?
Recently, an interesting latent malware infection was found on a newly onboarded machine at one of our clients (Client). Microsoft Defender for Endpoint (MDE) reported anomalies about the computer shortly after onboarding, but uncovering the inner workings of the malware and the infection methods required thorough investigation We present the second part of the investigation ...