Yes read about it, this is quite scary stuff because it's such a sophisticated attack. The good news is that security companies were able to block this via behavior blocking, very cool stuff! However, CrowdStrike claims that it could block this attack pro actively, but with Sophos it's not so clear. Which would be surprising since Sophos Intercept X is build to block this stuff, it's also based on HitmanPro.Alert, so I guess I should ask about this. https://www.crowdstrike.com/blog/cr...n-campaign-targeting-3cxdesktopapp-customers/ https://news.sophos.com/en-us/2023/03/29/3cx-dll-sideloading-attack/
This attack exploited a know Windows vulnerability and it's not the first time it has been deployed. It was used in the Solarwinds and other high-profile supply chain attacks: Why hasn't Microsoft patched this vulnerability? Errr .......... some legit apps use it: https://www.bleepingcomputer.com/ne...-bug-with-opt-in-fix-exploited-in-3cx-attack/ Registry fix given in the bleepingcomputer.com article. Apply it at your own discretion. -EDIT- I forgot to mention the reg. fix is wiped on Win 11 upgrade. Must be reapplied afterwards.
Thanks for this info, I didn't even notice this attack was exploiting a Windows vulnerability. But I wonder if this was enough to stop such an attack? Because DLL sideloading also seems to be a huge issue, Windows could really use a complete redesign.
On this regard, read this posting: https://forum.eset.com/topic/35798-trojan-dropper-remcos/ . Attacker dropped legit version of VLC Player .exe on a device. Then exploited it to run malicious Python .dlls; the device did not have Python installed previously. -EDIT- Also, steganography was used in this attack illustrating its use has gone mainstream. Of note here is VLC Player is one of a number of popular apps that have this dll side loading vulnerability.
FYI - Microsoft updated its CVE-2013-3900 documentation in Jan., 2022 and is located here: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2013-3900 .
Well, so much the Microsoft reg. fix as a "full" mitigation to this issue. Why am I not surprised by this ............... A recent comment in the above referenced bleepingcomputer.com article references this article: https://vcsjones.dev/authenticode-stuffing-tricks/ that dates to 2016: -EDIT-
I didn't read the full thread, but I believe it's described over here, and I wonder why MS still hasn't come up with a way to protect against DLL sideloading and hijacking. I believe HitmanPro.Alert is currently the only tool that is focused on this, but I'm not sure how it works in practice. https://www.bleepingcomputer.com/ne...se-vlc-media-player-to-launch-malware-loader/
The problem is that some installers need this like Google Chrome and that would be the reason for not fixing this, from the Bleeping Computer article: https://www.bleepingcomputer.com/ne...-bug-with-opt-in-fix-exploited-in-3cx-attack/
More info on this attack over here, according to Kaspersky, the main goal was to drop the Gopuram backdoor on machines in order to steal crypto's since mostly crypto companies were targeted. But a behavior blocker should be able to spot suspicious behavior performed by both the trojanized 3CXDesktopApp and also the Gopuram backdoor. Just like CrowdStrike, SentinelOne also claims it could spot the attack via its behavior blocking component, see second link. I suppose Sophos could do the same, although that's not clear to me yet. But AV's would most likely be blind to this stuff, so that's why I have always been an advocate of behavior blockers. https://securelist.com/gopuram-backdoor-deployed-through-3cx-supply-chain-attack/109344/ https://www.sentinelone.com/blog/sm...3cx-software-in-software-supply-chain-attack/
Other security solutions also initially detected it. Per the original bleepingcomputer.com article: Get off the behavior blocking baloney. Most of these blobs are encrypted. They won't manifest until loaded in memory. The above solutions have advanced memory scanning (AMS) and detected the malware payload by existing signature after it was decrypted by whatever loaded it. -EDIT- Actually, the security solutions which initially detected this attack were doing behavioral monitoring; sort of that is. These solutions were monitoring signed binaries; .exe, .dll, etc., certificates at time of creation and/or execution to determine if free space existed at the end of the cert. and if data was present in that area. As noted previously, malware usually deploys an encrypted blob there. As such, the code can't be analyzed at this point. What they most likely did at this point was flag the binary for deep behavior inspection. When the binary was executed, they set a hook in it to monitor activities. The primary activity being monitored is when something accessed the encrypted blob in the hacked cert., loaded it into memory, and decrypted it.
I'm not sure what you mean with this. To me there is a difference between blocking malicious .exe and .dll files by signature or by blocking them after seeing certain suspicious behavior, either by cloud scanning or endpoint behavior blocking. From what I understood, most of these companies like CrowdStrike and SentinelOne claim they could block malicious activity from the trojanized app via behavior blocker, without any signature. So you don't believe them? Only then can you call it baloney.
In this article it's also mentioned that this known Windows vulnerability was exploited. But what's more interesting to me is something else, namely that MS Defender can detect all domains and files used in this attack, but not a word on if they could block it via behavior blocking LOL. This doesn't give me great confidence in MS Defender ATP. https://www.darkreading.com/attacks-breaches/3cx-breach-cyberattackers-second-stage-backdoor BTW, also make sure to check this out. According to Checkpoint, Harmony Endpoint could block this advanced ransomware attack that made use of DLL sideloading, via behavior blocking. Do you still think it's baloney? https://www.wilderssecurity.com/thr...ach-believed-to-be-fastest-encryption.451070/
As I posted, Eset also detected the attack initially: https://www.bleepingcomputer.com/ne...ise-3cx-desktop-app-in-a-supply-chain-attack/ and folks here and at malwaretips.com are always ranting it doesn't have any behavior blocking capability. It does. Behavior blocking is really a generic term for various malware detection methods deployed by security vendors. None of those vendors rely exclusively on static full signature methods these days.
That stinks imho. I get that they don't release a patch for current Windows versions but they could have fixed this in a new major Windows release like 10 or 11. Chrome and others would then have time enough to change their behavior and maybe find an alternative.
It detected the ransomware activites; not the dll sideloading activities: BTW - cydump.exe abuse is not new. It has been used in past lsass.exe credential dumping and stealing attacks.
OK, but then why did you call it baloney? To me it's important that they could detect this attack without any signatures, so purely by behavioral monitoring and without even using the cloud. It's not clear to me if this was the case. I wish someone could test this stuff, the problem is that nobody is going to do this for free, so in the end you will get a sponsored test, which probably isn't that trustworthy. This might indeed be true that they didn't spot the DLL sideloading, but it's important that they at least could spot the encryption and were able to rollback files. Of course, we have to take their word for it, there is no way to verify this stuff.
Here some more info, seems like SentinelOne really detected this attack via behavioral monitoring, but not sure if this was done via cloud or not. That's why I keep saying that relying only on AV's isn't good enough, although most AV's are nowadays cloud based and should in theory pick this up. https://arstechnica.com/information...d-as-malicious-but-took-no-action-for-7-days/
The significant posting in the arstechnica.com article is: This is a favorite tactic of the pentest tools; 1. Create a sub-directory in Users\**USERNAME**\AppData\Local\Programs 2. Copy legit .exe to that directory. 3. Inject shellcode into that .exe A good example for zero trust policy when it comes to .exe's running from Users\**USERNAME**\AppData\* directories. Now in regards to this example, the question is if in the case of the 3CXDesktopApp installer, it was expected behavior for the sub-directory and .exe to be created/updated in Users\**USERNAME**\AppData\Local\Programs\ directory? If it was, it's a "sloppy" design for the 3CXDesktopApp .exe to be running from that location.
From what I understood, the TAXHAUL and COLDCAT (Windows) and SIMPLESEA (macOS) malware was used to get control of the 3CX network in order to carry out this attack. Which also means that built-in defense of both Windows and macOS were most likely blind to this attack, which is quite interesting. I did notice that TAXHAUL used the svchost.exe process for sideloading of the malicious DLL file. But I assume a good behavior blocker/EDR should pick up suspicous behavior from at least the COLDCAT downloader. https://www.helpnetsecurity.com/202...etails-about-the-breach-new-pwa-app-released/
3CX supply chain attack was the result of a previous supply chain attack, Mandiant says https://cyberscoop.com/3cx-supply-chain-north-korea/
Linux malware strengthens links between Lazarus and the 3CX supply‑chain attack https://www.welivesecurity.com/2023...gthens-links-lazarus-3cx-supply-chain-attack/
Wow, so first some 3CX employee was infected with a trojanized version of X-Trader which is a legitimate tool. And this malware was used to eventually get control over 3CX's network and eventually trojanized the 3CXDesktop app. These supply chain attacks are getting more widespread, so it's best to trust no app, which has always been the slogan of Sandboxie LOL. Yup, a good reminder that even on Linux and macOS you should still take security seriously, and don't think you're immune to attacks.
Apparently, 3CX wasn't the only one who was hacked via this supply chain attack. Seriously, companies should really beef up their security. https://www.bleepingcomputer.com/ne...hit-by-supply-chain-attack-behind-3cx-breach/
