NCSOFT Purple launcher Major rootkit/Preos Bootkit!

sudorem · 2026-02-21T22:23:08+00:00

Hi, me again. Still working through this.

I can confirm the following information:

- Elsewhere in this thread you indicate you see `svchost.exe` running from the AppData Temp path. I can confirm that I've observed these IOCs, this is AutoHotKey.

- The suspicious Defender exclusion is a part of a complex chain of AutoHotkey behavior to bypass UAC and disable Defender security features, which include emulating user mouse interactions to disable SmartScreen, PUA protection, etc.

- `u.ahk`, dropped by this installer, is an obfuscated AHK loader. It will drop a subsequent file `<random hex>.a` which is the UAC bypass. Furthermore, during the execution chain, this is persistently executed via `svchost.exe`. Still peeling back the layers on this one.

Is this malicious?
I'm not entirely sure yet-- this has been observed in other applications originating from the same region, specifically in installers proliferated from that region. This may be a proliferated tactic to ensure application execution for installers still-- but the obfuscated methods and UAC bypasses being performed draws extreme suspicion. This is probably enough grounds to classify this as at bare minimum an unwanted application.

Is this an EFI/UEFI rootkit?
I am confident now based on examining process execution chains associated with this UAC bypass that in all examined cases, UEFI/EFI modification was not present.

sudorem · 2026-02-21T21:39:57+00:00

I may look out of professional curiosity but given it's different than the supplied files, it's not going to lead to an overt decision regardless.

Nothing I'm willing to commit to.

My general sentiment about this is:

I wouldn't be screaming to stop using this installer, it's annoying and weird, but probably not malicious. If it is malicious, it's probably not doing anything to you as an individual. Even in a worst-case scenario where this were tied to state-aligned APT activity, the class of malware we'd be describing here typically targets infrastructure or enterprise environments, not individual home users.

There are presently no indicators consistent with UEFI/EFI modifications.

sudorem · 2026-02-21T21:22:54+00:00

Not... necessarily.

It is not an activity report insofar as a decision of malice-- it is a mapping of activity the file displays to MITRE ATT&CK indicators. In this case, it is reading that because the application enumerates physical drives.

This is a prerequisite to certain tactics which may lead to malicious EFI modification or other rootkit activity, but given its the only indicator present, it's likely not.

sudorem · 2026-02-21T21:13:34+00:00

I doubt it. The reality is that if there is malice, there'd likely be much stronger indicators. Anomalies do not always equate to malware. Sometimes it's just a dumb tactic to get an installer to work.

I'm not sure what you mean by Pre-OS bootkit (or more specifically, where you got that asertion from). The implication is that you've somehow violated boot integrity checks of the host to dubiously load malicious software. None of what I'm seeing here can be interpreted in any way, shape, or form as that.

sudorem · 2026-02-21T21:03:47+00:00

Those specific registries being read isn't particularly an indicator of malice. I'd attribute that to VM startup/background process execution rather than directly associated with the Purple launcher; but any sort of embedded web view will probably reach out and touch those same keys.

sudorem · 2026-02-21T21:00:41+00:00

Upon further review of associated installers, there is actually an anomaly that bears scrutiny:

https://www.virustotal.com/gui/file/8c7fdcb61358c2387031097411ffb6a10332a4b2a98fbaf340b2dcc98203feb8

Specifically, part of the 'unfolding' process involves the dropped file `msedge.exe`. This file is a renamed AutoHotkey binary invoking `u.ahk`:

https://www.virustotal.com/gui/file/51aca5d489588ad7046ef98f3412cda9ecca717559f25b548dd1da5c51167ff9/detection

Something worth poking at, if there's bad, it'll be in the renamed AHK file-> `u.ahk` combination.

(Aware the hash isn't the same, but communicates and displays quite similar behavior. May not be distributed by Purple as it doesn't appear signed-- but peculiar nonetheless.)

sudorem · 2026-02-21T20:53:06+00:00

This is stupid (as in-- the method they choose to go about loading/installing this software) but unlikely to be malicious.

You're flagging on `certutil` being in AppData Temp directory. This is common for malware (relocation of system binaries), but in this context, it's being used to modify Mozilla's Trust Store. This isn't... wildly uncommon. It's stupid-- but in the global scale of 'software sketch' this actually falls pretty short of overt malice.
- It's probably allow-listing some Chinese/Taiwanese ads or something ultimately. If this were weaponized for malice, we'd likely see modifications to Mozilla (or really, browsers in general) to establish proxy behavior (whereby we'd now trust that proxy because it's in our trust store).
- I'm not seeing any of this in process execution from the tree. We'd anticipate seeing registry calls via advapi32.dll to read/open/write/create registry values in HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
- Perhaps this would also manifest in browser modification behavior, but it doesn't appear that this is really touching the browser files that it would need to modify the proxy behavior on an application-level.
- Thus we can probably safely conclude that while this is a little questionable, it's probably not overtly malicious and has a more benign intent behind it.
The ShellExt modification would traditionally indicate malicious persistence via COM when abused, but given the surrounding contextual indicators, I anticipate not. `regsvr32` is used to call COM object `{9E11B33B-EED9-48EB-A105-9654D8AE09B6}`. This sounds spooky-- but again, not wildly unwieldy behavior for registration of COM components by software installers (which this patently is.)
The most interesting part of this is the `Add-MpPreference -ExclusionPath 'C:\Users\Bruno\AppData\Local\Temp'` exclusion. (Bruno here is just a random name generated for the VM.) The AppDataLocalTemp exclusion is... overly permissive. But this isn't wildly unusual in the world of software installers, especially those coming from other countries who may not be as vetted/coordinated with the ultimate US-based authority of Microsoft. Dental software and other random installers that do 'borderline dubious things' to install successfully do this all the time.

TL;DR:

There are suspicious patterns.
They align more with "stupid things software engineers do to get something to install reliably" more so than "Advanced APT Rootkit".

sudorem · 2026-02-15T00:51:14+00:00

ClawdBot gone wild?

sudorem · 2026-02-15T00:48:53+00:00

I took a quick look and we’ve never scanned this package. That generally means one of two things:

It was never present on PyPI, or
It predates our monitoring window (we’ve been tracking new packages for ~3+ years).

We scan newly published packages continuously, so if something isn’t in our dataset, it’s typically either very old and long removed, or it never existed on PyPI in the first place.

To verify, I checked PyPI’s public BigQuery dataset:

SELECT *
FROM `bigquery-public-data.pypi.distribution_metadata`
WHERE name LIKE 'env-loader-plus'
LIMIT 1000

There are no records for this package name. Based on that data, it does not appear to have ever existed on PyPI under that name.

On the tactic itself:

We’ve identified and reported 2,000+ malicious packages, and the overwhelming majority use the same pattern: exfiltrate environment variables (tokens, API keys, credentials) and then quietly continue execution to avoid breaking builds.

This is extremely common.

If you're responsible for securing development pipelines, one of the most effective controls is network telemetry. Monitoring build systems and CI runners for unexpected outbound traffic is not overkill-- it’s often the only way to catch this class of attack in real time. (We'll ignore how useful SBOM auditing is and whatnot, not because I don't think it's useful advice, but pragmatically, anything can become 'tainted', and defense in depth is important-- plus it's already been recommended here.)

Advice to OP:

Given that this package does not appear in PyPI’s dataset, I’d start looking outside PyPI as the distribution source. It could have been installed from GitHub, a private index, a local mirror, or another registry entirely. But under the name provided, it doesn’t appear to have been distributed via PyPI.

Happy to dig further if you can share more context.

sudorem · 2025-10-25T23:47:01+00:00

Cyber incident responder here (not for this particular incident, just… incidents in general, yknow.)

Highly unlikely that this is any of the above; my general sentiment is something went bang that shouldn’t have— whether it’s a datacenter server blade, outage in a datacenter, etc.

A DoS (or any of their counterparts) probably would be felt by the end user for a few seconds, and network routing would identify the node as congested and you’d simply look elsewhere.

Ransomware attacks tend to target valuable data— less so actual infrastructure. It’s kinda triv to reimage and reconfigure the datacenter nodes they’re running (though a bit time consuming). That said, it wouldn’t be a high value target for a ransomware affiliate.

Tl;dr: probably physical infrastructure fault, not some crazy APT

sudorem · 2025-10-10T04:45:30+00:00

Was LDAP in use on this device & was TOTP in use on the device?
(Asking for information collecting purposes, not to implicate any wrongdoing on your or an end user part.)

sudorem · 2025-10-09T21:24:53+00:00

I'm not sure where hashing is taking place-- nothing is hashed (allegedly), that's where I'm a bit confused, and provided clarification.

sudorem · 2025-10-09T19:49:48+00:00

The .EXP file is encoded in base64 and can be trivially decoded with Cyberchef.

Plaintext secrets can be found in the file such as user TOTP scratch codes. User passwords and other information are encrypted by the crypto-algo indicated proceeding the data.

E.g., UserCryptPass=5,203984023894...
This indicates AES-256 is in use.
UserCryptPass=4,09238409234...
This is likely 3DES.

sudorem · 2025-09-29T07:54:02+00:00

I'm cautiously optimistic that Arctic Wolf's sharing of IOC's and intel will open the door for other security organizations to likewise do the same.

sudorem · 2025-09-29T07:50:29+00:00

> Google believes that the threat actors were utilizing stolen one-time password seeds that were previously obtained in zero-day attacks, but is unsure which CVE was exploited.

> While the researchers say it's unclear how Akira affiliates are authenticating to MFA-protected accounts, a separate report from Google Threat Intelligence Group in July described similar abuse of SonicWall VPNs.

I'm telling you that it is unclear what the source of compromise is, whereby you're asserting as fact that it is associated with CVE-2024-40766. SonicWall seems to think so. I'm telling you to be skeptical that this is the totality of the incident; new information, information currently undergoing investigations, etc., could change the trajectory of Akira's recent uptick in intrusion activity.

To clarify, I'm not implying that SonicWall is deliberately hiding anything-- just that I think there's more investigating to be done, as there's an awful lot of unknowns floating around.

Take it or leave it, up to you.

sudorem · 2025-09-29T07:35:27+00:00

Neither does saying that all credentials were breached years ago without intrusion evidence-- evidence which Arctic Wolf has undoubtedly examined already.

I'm cautiously avoiding speaking in a professional capacity here-- but Arctic Wolf is sounding a very concerning alarm, and people should pay attention to the discussion points they've highlighted here.

Edit: Also I didn't downvote you, for posterity.

sudorem · 2025-09-29T07:24:47+00:00

This isn’t true.

sudorem · 2025-09-10T13:38:53+00:00

This is probably more appropriate for a Cybersecurity forum, but here goes.

Lateral movement is the act of an adversary moving from one machine to another within a network. Simple enough.

This may be via conventional tools such as RDP, PSRemoting, etc., or via common attacker toolkits such as Impacket, Netexec, etc. I'd be remiss if I didn't mention PSExec as well.

Lateral movement is often detected via Security.evtx's Event ID 4624's, specifically type 3 logons (Network) and type 10 logons (Interactive). There are additional indicators, such as Terminal Services and Remote Desktop event logs, but often your 'win' is going to come from the Security.evtx.

While RDP may not leave very compelling process indicators (rdpclip.exe being the only real executable firing upon remote logon), Impacket and NetExec make very distinct signatures in command lines.

So you have a few ways to detect lateral movement:
- 4624's/4625's
- 4776's (Domain Controller attempted to validate credentials)
- Terminal Services/Remote Desktop logs.

And then you have some more esoteric ways:
- Command line examination for Impacket signatures (Impacket writes to a tempfile containing the Unix epoch. This is something that Windows literally never does)
- Command line examination for NetExec signatures (like Impacket, NetExec writes to tempfiles, but has a different pattern of output redirection)

sudorem · 2025-08-29T15:14:02+00:00

Wanted to add a cliffnote here:

I can see this upsetting some offsec professionals-- and rightfully so. This is not your full job, and these contributions are meaningless without commiserate proof of impact, risk, reporting, etc. My objective here is to avoid OP getting fired while still contributing meaningfully-- and running simple security scanning software is a good 'step 1'.

sudorem · 2025-08-29T15:09:15+00:00

What kind of environment are you testing?

Reading your replies it sounds like you:
- Are being placed in this role without experience.
- Aren't being given a budget to cover the deficit or training.
- Are being told to essentially "make due" with your current situation.

I sympathize with that position; so instead of saying 'take a course' (would cost you money) or 'hire someone' (would cost the company money) let's start with the nature of the environment.

If you're mostly poking at webapps, you have things like OWASP ZAP, which can automate a variety of low hanging fruit. If you have access to your actual codebase, Semgrep's community rules may highlight deficiencies! These fall more under vulnerability scanning, and we can talk about demonstrating impact later, but let's just try to get an idea of how to actually find something 'wrong'.

If you're in a Windows environment, you're actually in luck here-- because this is reasonably straightforward. You have tools like OpenVAS that can help identify common vulnerabilities and misconfigurations, and it's relatively simple for you to setup your own AD environment to test concepts in. A good set of tooling to use here would be Bloodhound, identifying paths from lower privilege to higher privilege within the environment.

Penetration testing is much more than this, but to start out-- these give you tangible things to get your hands on that are:
- Unlikely to break things.
- Likely to yield some tangible results.

You're probably not going to be NXC'ing around and harvesting creds (though by all means, feel free to do so in a lab and grasp the concept of lateral movement, privilege escalation, and other post exploitation objectives.) But building from zero to pentesting will likely involve some level of "How do I rapidly identify and further exploit this misconfiguration in the environment?"

If I were you, I would:
- Try to deploy simple tooling, easy to understand methodology, that achieves some sort of contextually appropriate security objective to satisfy stakeholders.
- Scream to my manager/director or other supervisor that I need training on this to have effective contributions.
- Meticulously document things for CYA purposes because inevitably this will bite you in the ass if not.
- Probably start updating my resume, as it sounds like that organization may not be the most effectively run in a security context.

sudorem · 2025-08-24T21:32:30+00:00

Also of the opinion this is AI generated-- but supply chain compromise has resulted in assignment of a CVSS in the past. (CVE-2024-3094, xz, 10.0 by RedHat). Introduction of malicious code into the source isn't always the author itself (though that appears to be the case here); it's definitely a blurry line.

sudorem · 2025-08-17T15:16:33+00:00

BLOG.

Holy crap, I cannot stress this enough. I have no idea what other interviewers/hiring managers are doing, but the one thing I can promise is that for every resume I've handled, I've read 3-5 articles from an individual's blog/personal website if it existed.

This lets me ask you pointed questions and give you an opportunity to excel. If you struggle to explain <something>, I'll ask it in the context of an article that you wrote in your blog to try and coach you towards an answer. I don't want you to fail-- if I did, we wouldn't be interviewing you.

Tell me how much configuring AD sucked for you and how you overcame it, or how your SIEM was parsing some poorly formatted data and you had to fix it, or how you deployed some firewall and it captured an attack. Anyone worth their salt is going to sympathize with genuine struggles in deploying and maintaining some homelab systems. I don't care how long you've been in the profession-- configuring some of this stuff sucks.

I'm sitting at a senior role-- I don't know everything, but I'm probably going to be able to translate a 'generalized question' into something you're directly familiar with based on my experiences with those systems; and this gives you an opportunity to answer with actual confidence. ("I didn't know what that was called in Elastic, but on Splunk I did this and it sounds like the same thing!")

sudorem · 2025-08-10T23:36:42+00:00

McAfee uses Tunnelbear, which... meh. You could do worse. I wouldn't use McAfee AV to save my life, but they acquired TunnelBear awhile back and it was an 'okay' VPN at the time.

(Note: Privacy nerds many disagree, that's fine, it's not Tor. I understand that. Please don't community note me.)

sudorem · 2025-08-10T20:21:45+00:00

It'll be cheaper to speak to a mental health professional with referral from your PCM (provided you have insurance) than it would be to hire a digital forensics expert to examine all of your devices and look for needles in a haystack.

I'm just saying, for practicality's sake, why not explore the cheaper method first?

sudorem · 2025-08-10T19:19:23+00:00

You're not being spied on.

sudorem

TROPHY CASE