Malware News Free Games, Costly Consequences: HijackLoader spread via Pivigames - analysis based on reddit post by GData

[Khushal]

Content source

https://blog.gdatasoftware.com/2026/02/38373-pivigames-spreads-hijackloader

PiviGames, a popular Spanish gaming platform is well-known in the gaming community for providing download links to pirated PC games. Such a platform offers attractive content and it has built a reputation within the gaming community over the years. However, PiviGames has become more than just a source of free entertainment; it has evolved into a full-blown malware distribution hub, allowing malicious actors to compromise unsuspecting users.

Free Games, Costly Consequences, and Loads of Malware

The Spanish games platform PiviGames is being abused as a malware distribution hub. This was discovered after someone looked for help on Reddit.

blog.gdatasoftware.com

 

[Parkinsond]

Can be blocked by SAC/WDAC, and definitely preventable if the user checked the the file properties of the setup.exe file before execution.

 

[Sorrento]

I have very little concern for users that get an infected by using pirated products, I would say that is life...

 

[Parkinsond]

I have very little concern for users that get an infected by using pirated products, I would say that is life...

It's like not refusing to treat injured cirminals coming to ER

 

[Victor M]

and definitely preventable if the user checked the the file properties of the setup.exe file before execution.

why ?

 

[Parkinsond]

why ?

Will find it not an exe file; why should the user run any file other than exe file?

 

[Parkinsond]

why ?

Yes, you are right, could not be distinguished.
Only SAC/WDAC will protect you.

 

[Parkinsond]

why ?

But how is the python file is going to run after renaming it with .exe at the end; it is now recognized by Windows as an executable, not a script file!

 

[Divergent]

Can be blocked by SAC/WDAC, and definitely preventable if the user checked the the file properties of the setup.exe file before execution.

Because the telemetry explicitly identifies setup.exe as a clean file, its digital signature and metadata would appear benign. Therefore, a user inspecting the properties of setup.exe would see no indicators of compromise. The malicious execution occurs only when the clean executable automatically loads the trojanized Conduit.Broker.dll residing in the same directory.

Regarding SAC/WDAC. Windows Defender Application Control (WDAC) and Smart App Control (SAC) can theoretically block this attack if they are configured to enforce strict DLL trust policies (UMCI). However, if the policy only checks the primary executable, the attack would still succeed.

 

[Parkinsond]

Smart App Control (SAC) can theoretically block this attack if they are configured to enforce strict DLL trust policies (UMCI)

As far as I know, SAC has no configuration, only "on", "off", and "evaluation".

 

[Divergent]

As far as I know, SAC has no configuration, only "on", "off", and "evaluation".

That is precisely why the word 'theoretically' was used, in theory, if Windows 11 gave you the option to manually alter SAC's underlying User Mode Code Integrity (UMCI) policy, you could block this attack natively. Because it does not offer that configuration, you are left relying on Microsoft's cloud heuristics.

Regardless of which UI restrictions you are dealing with, the core issue remains, your advice that this is 'definitely preventable if the user checked the file properties of the setup.exe' is dangerously incorrect. HijackLoader explicitly relies on DLL sideloading (MITRE T1574.002). The setup.exe in this chain is a perfectly legitimate, clean binary. Its file properties, metadata, and digital signature will look completely benign to any user inspecting them. The infection occurs because that clean .exe automatically calls for a dependency, loading the malicious Conduit.Broker.dll from the same directory into memory.

To actually stop this execution flow locally, the OS requires a strict policy alteration that mandates all loaded DLLs be cryptographically signed by a trusted publisher. Since you cannot manually configure SAC to enforce this granular rule, and visual inspection of the parent .exe is actively deceptive, home users remain highly vulnerable to this specific staging mechanism.

 

[Parkinsond]

you are left relying on Microsoft's cloud heuristics

Most side-loding dll files are unknown to MS cloud, unlike the initial exe which might be signed, and will be blocked.

 

[Divergent]

Most side-loding dll files are unknown to MS cloud, unlike the initial exe which might be signed, and will be blocked.

I phrased those previous points specifically to test the baseline understanding of OS trust models in this thread, and you took the bait exactly as expected.

By positing a 'theoretical' configuration of SAC and stating the obvious, that a modified DLL unknown to MS cloud will be blocked, I was stress-testing whether this discussion was actually accounting for the environmental reality of the attack vector, or just reciting Microsoft documentation.

You passed the architectural test, but you completely missed the environmental context. Yes, SAC blocks unknown DLLs. Yes, the initial .exe might be signed. But look at the vector we are analyzing: PiviGames. This is a game piracy infection chain. In the real world, what is the very first thing users do when they download a cracked game or keygen? They intentionally disable Smart App Control and Windows Defender because cracks are inherently flagged by UMCI.

The attackers don't care that MS cloud blocks unknown DLLs, because they rely on the social engineering of the piracy ecosystem to get the user to drop their own shields. I wanted to see if anyone here would bridge the gap between OS architecture and human behavior. Your advice to check the .exe properties remains dangerous precisely because it gives a false sense of security to users operating in degraded, self-compromised environments.

 

[Jonny Quest]

I phrased those previous points specifically to test the baseline understanding of OS trust models in this thread, and you took the bait exactly as expected.

By positing a 'theoretical' configuration of SAC and stating the obvious, that a modified DLL unknown to MS cloud will be blocked, I was stress-testing whether this discussion was actually accounting for the environmental reality of the attack vector, or just reciting Microsoft documentation.

You passed the architectural test, but you completely missed the environmental context. Yes, SAC blocks unknown DLLs. Yes, the initial .exe might be signed. But look at the vector we are analyzing: PiviGames. This is a game piracy infection chain. In the real world, what is the very first thing users do when they download a cracked game or keygen? They intentionally disable Smart App Control and Windows Defender because cracks are inherently flagged by UMCI.

The attackers don't care that MS cloud blocks unknown DLLs, because they rely on the social engineering of the piracy ecosystem to get the user to drop their own shields. I wanted to see if anyone here would bridge the gap between OS architecture and human behavior. Your advice to check the .exe properties remains dangerous precisely because it gives a false sense of security to users operating in degraded, self-compromised environments.

That's kinda what I was thinking when reading this thread, not the bait, part but why this even turned into a "serious" discussion on what should or shouldn't be blocked etc.

Were talking about an article of "users who want stuff" pirated PC games, of course they're going to click and tick and allow. I don't think they're going to go through all the steps or consider the concepts mentioned here?

 

[Parkinsond]

Were talking about an article of "users who want stuff" pirated PC games, of course they're going to click and tick and allow. I don't think they're going to go through all the steps or consider the concepts mentioned here?

You will be surprised how educated are some users who use pirated software currently

 

[Jonny Quest]

You will be surprised how educated are some users who use pirated software currently

Maybe not enough? I don't know or keep up with the gaming community enough to know, other than those who like gaming and post here.

 

[Parkinsond]

Maybe not enough? I don't know or keep up with the gaming community enough to know, other than those who like gaming and post here.

Check for the nationality gradually replacing the American citizens in US-based tech companies, and check again the piracy rates in their homeland; they are well-educated.

 

[Jonny Quest]

Check for the nationality gradually replacing the American citizens in US-based tech companies, and check again the piracy rates in their homeland; they are well-educated.

I would never think to check that, I have better things to do Rock on, Parkinsond

 

[Divergent]

That's kinda what I was thinking when reading this thread, not the bait, part but why this even turned into a "serious" discussion on what should or shouldn't be blocked etc.

Were talking about an article of "users who want stuff" pirated PC games, of course they're going to click and tick and allow. I don't think they're going to go through all the steps or consider the concepts mentioned here?

You have accurately identified the fundamental paradox of analyzing consumer-targeted malware, the human element is the ultimate bypass. The reason we have a 'serious discussion' about these technical mechanisms isn't to save the user from clicking 'allow', it's because once the human firewall falls, the underlying architecture of the OS is the only thing left to stop the payload.

My earlier baiting on OS mechanics was entirely necessary here, as there is far too much regurgitating of Microsoft documentation taking place by members who clearly do not understand the actual intricacies of this attack chain.

 

[Halp2001]

What looks like free fun is really just bait: behind those 'gifts' lies the real cost, and even though I'm not a gamer, I know that misdirected curiosity is exactly what attackers exploit.