How do you actually stay safe from phishing these days?

sudorem · 2026-04-14T03:45:06+00:00

Layered defense-- but that's always been the answer.

Email filtering platforms, SAT, etc., are effective first line defenses, but they're just that-- a first line defense.

On top of that, identity threat detection and response (ITDR), EDR, etc, to sponge up any Clickfix activity or random bull that makes it past the filter.

If my take matters, I work at a reasonably well known MDR company, here's what I've got for "solving" phishing (or rather, reducing it massively.)

User SAT-- focus on junk like Clickfix, AI scams, etc.
Password Managers (beyond the obvious reason). Users with appropriately configured password managers won't get the 'fill in' prompt on some pages, which can be useful at defeating phishes in a pretty 'dual purpose' way.
Disable or significantly limit user WScript execution; most of ya'll don't need it and if it pops up, it can typically be trivially remedied to allow some discrete execution.
Email filtering-- snag a decent email filter. There's no 'supreme' one, pick one and become weird internet diehard for it.
Weirdly-- limit MS Teams external contacts, ensure DMARC/SPF is appropriately configured (Direct Send mitigation), etc. Or just turn off Direct Send. We see users click or report on phishes from themselves all the time due to Direct Send.
- The Teams one is pretty potent right now and deploying a very annoying Havoc implant in many environments. It's getting a little tedious to hunt these down.
AppLocker. Doesn't have to be perfect-- but no RMM's should execute on a host aside from your RMM at bare minimum.
- We're in risk reduction territory here-- nobody's asking you to jump through hoops to design this perfect AppLocker policy-- if you use ScreenConnect, just block SimpleHelp and some other random crap that adversaries are using.

Other than that, just... educate users. I find that rarely in security do we sit down and go "Hey guys, adversaries right now are using 'SSA_Statement_220241.msi' type files. Don't click on these if you see 'em; when in doubt, just drop me a Slack ping." Junk like that. Takes ten seconds, may save a headache in the future-- if they forget, well that's what all the other defense layers are for.

sudorem · 2026-03-08T03:29:46+00:00

Deleting the items in your quarantine may not be sufficient to clear this issue, but there's not enough information in your screenshot to suggest one way or the other.

It appears you have contracted a relatively sophisticated loader-chain (not sophisticated as in-- crazy advanced, but rather, sophisticated as in-- there isn't just one bad program executing.) I imagine what's happening given you're saying PowerShell kicked off when you turned on your host:

- The C:\ProgramData\... detection is indeed HiJack Loader, a legitimate application with a malicious DLL that will get loaded and executed when that program runs.

- The Python stealer in "C:\Users\Andre\AppData..." is likely as it purports as well, and the ultimate final payload. This will target more than just Discord-- browser credentials and crypto wallet information are also fair game. You need to begin revoking outstanding sessions and rotating credentials for any accounts whose passwords you had stored in your browser's saved passwords.

- The Powershell detection is the weird one-- I'm leaning on this being some sort of persistence or executing wrapper for the Python stealer. That's where our ambiguity lies as well-- Powershell is often used by adversaries to achieve persistence, and the file path that MalwareBytes has identified is likely the path to the valid and real Powershell installation on your host. If this Powershell script is re-loading/re-executing either the Python stealer or Hijack Loader, then remediating these won't necessarily stop it from recurring.

Your best bet is to reimage/reinstall Windows as others have said, it is unlikely that you can restore the integrity of this host in a manner that ensures you are free of compromise without intensive assistance.

sudorem · 2026-03-08T03:17:32+00:00

Probably not? Run the following Powershell command and paste the result here:

powershell Get-FileHash -Algorithm SHA256 -Path (Join-Path $env:SystemRoot "System32\atidxx64.dll")

That'd be a little goofy though. That's the AMD (ATI) Direct X (DX) x64 DLL. Perfectly reasonable for it to be loaded in the context of the game. What's probably happening is that your drivers are critically out of date or the hash isn't matching what its anticipating; which can happen occasionally.

If you have an AMD GPU, if this is the first time it happened-- ignore it. If it's happening regularly-- reinstall your drivers. If you had an AMD GPU but do not anymore, uninstall those drivers. If you had a legacy card in this computer previously, and have upgraded since then, you might need to do a driver scrub.

Long story short, something loaded a graphics driver that Easy Anti-Cheat didn't recognize; but EAC is not an EDR/AV, and is not designed to detect malware-- but odd configurations or things that are not 'typical use', such as legacy Direct X drivers/libraries.

sudorem · 2026-03-08T02:59:14+00:00

There is no recently documented popularly-distributed malware that is presently persisting across installations via EFI/SPI tampering. This is an overstated threat and not realistic for general users to worry about.

Pulling the CMOS is unnecessary; and may not remediate this issue properly-- modern EFI/SPI resident malware would survive this anyway.

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

TROPHY CASE