Holy crap, I just traced an infection with Sysmon and the killchain was it trying to launch a .js file with PowerShell, but we remapped .JS to notepad.exe
I detected the beginning of the infection with centralized PowerShell logging that puts the transcripts in a fileshare. I go through it time to time seeing what our systems are doing.
A REAL-LIFE threat against a user, traced from inception with Sysmon (free), detected with PowerShell logging with Win7 WMF5 upgrade (free), ultimately defeated with simple defense-in-depth computer configuration in Group Policy (free). @markrussinovich @jsnover @Lee_Holmes
Every single part of this I configured and deployed myself to over 1000 desktops and laptops across the United States.
--RESOURCE LINKS TO DO THIS ALL YOURSELF FOR FREE--
- Sysmon configuration: https://github.com/SwiftOnSecurity/sysmon-config …
- PowerShell logging: https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html …
- Windows Event Forwarding: https://aka.ms/WEF
- Remap malicious script files to Notepad:
==SYSMON-CONFIG VERSION 60 RELEASED==
Lots of improvements in detection, Win10 exclusions, refinements, and more helpful comments. Deployed on 1000+ clients, with extra private changes. Requires Sysmon 7.01.
Will now start going through the pull requests.
This just goes to show that "worst-case scenarios" in computer security are rarely "real-world scenarios." They didn't evade or turn off logging. They didn't use BITSADMIN. They didn't do a lot of things. Don't be a defeatist. This is 99.9% of the crap on the Internet.
"Couldn't the threat authors have done -x-?"
Yes, but doing -x- is a signal itself. Turning off PowerShell logging? Disabling Sysmon? I'm sure antivirus firms would love it if everyone made it that easy to detect malicious software.
This is something @jepayneMSFT says a lot, and I learned it from her. Being subversive is its own signal, and often threats TRY to be as plain-looking as possible. Because 99% of the time it doesn't matter. Because 99% of the time, nobody is looking.
You should start looking.
Actually, it's possible they purposely don't explicitly reference wscript.exe inside the dropper file, because that would be a pretty easy way to detect the threat. So it's possible they won't even fix this. It not working might be on purpose.
As you can see, this infection was from a malicious ad about a Flash update. The user is corporate, who don't get our adblocking configuration deployed to Internet Explorer. If they were using Chrome, they wouldn't have seen the ad, downloaded the file, or much less run it.
You don’t need to project an aura of aloof despondency to be seen as competent.
I run the most popular IT Professional Twitter account in the world and tweet about remapping attacker scripts to open with Notepad as a security control. It’s stupid, unimpressive, and fucking works
Now ask yourself:
Are you more interested in the kind of people who want to improve, or the people too cool to try?
You can follow @SwiftOnSecurity.