Hackers Are Now Hiding Malware In Windows Event Logs (bleepingcomputer.com) 49
Security researchers have noticed a malicious campaign that used Windows event logs to store malware, a technique that has not been previously documented publicly for attacks in the wild. BleepingComputer reports: The method enabled the threat actor behind the attack to plant fileless malware in the file system in an attack filled with techniques and modules designed to keep the activity as stealthy as possible. [...] The dropper copies the legitimate OS error handling file [...] and then drops an encrypted binary resource to the 'wer.dll' (Windows Error Reporting) in the same location, for DLL search order hijacking to load malicious code. DLL hijacking is a hacking technique that exploits legitimate programs with insufficient checks to load into memory a malicious Dynamic Link Library (DLL) from an arbitrary path.
[Denis Legezo, lead security researcher at Kaspersky] says that the dropper's purpose is to loader on the disk for the side-loading process and to look for particular records in the event logs (category 0x4142 - 'AB' in ASCII. If no such record is found, it writes 8KB chunks of encrypted shellcode, which are later combined to form the code for the next stager. "The dropped wer.dll is a loader and wouldn't do any harm without the shellcode hidden in Windows event logs," says Legezo. The new technique analyzed by Kaspersky is likely on its way to becoming more popular as Soumyadeep Basu, currently an intern for Mandiant's red team, has created and published on GitHub source code for injecting payloads into Windows event logs.
[Denis Legezo, lead security researcher at Kaspersky] says that the dropper's purpose is to loader on the disk for the side-loading process and to look for particular records in the event logs (category 0x4142 - 'AB' in ASCII. If no such record is found, it writes 8KB chunks of encrypted shellcode, which are later combined to form the code for the next stager. "The dropped wer.dll is a loader and wouldn't do any harm without the shellcode hidden in Windows event logs," says Legezo. The new technique analyzed by Kaspersky is likely on its way to becoming more popular as Soumyadeep Basu, currently an intern for Mandiant's red team, has created and published on GitHub source code for injecting payloads into Windows event logs.
Finally, something useful for Windows Event Logs (Score:4, Insightful)
I can't believe it's 2022, and opening the Windows Event Viewer still takes forever. And then it almost certainly never has the details you're looking for as to why your Windows PC just bluescreened and restarted.
I for one celebrate the innovation here to find a useful (albeit malicious) purpose for the Windows Event Viewer
Re: (Score:3)
I have seen absolutely no useful information in the event log in many many cases.
But, in other cases, the contents of the event log have been absolutely indispensable, with clear information, error descriptions, and it led directly to an actionable solution.
Windows event logging is only as good as the software logging the events.
Re: (Score:1)
More accurately, the software is only as good as the programmer who designed it.
Most programmers, especially app developers, don't bother putting in good error handling or logging methods. Let alone ones that can provide actionable information to end-users. Their goal is to get the code out the door as fast as possible. The result is errors that look like random character dumps. Assuming any error is caught at all. I've seen plenty of software that just crashes to desktop / the home screen without so much a
Re:Finally, something useful for Windows Event Log (Score:5, Informative)
From a technical perspective, the biggest and ONLY advantage of the Windows Event Logs is that they naturally loop. Log files on other platforms have to be regularly rotated to keep their size from ballooning out of control and consuming all storage space on the system.
From a performance perspective when viewing the log, the MMC snap in interface is the culprit. The entire log has to be read into memory and parsed and dumped into the list view in the MMC snap in before anything can be displayed. The MMC snap in interface allows a system administrator to remotely access the logs but the design doesn't afford any sort of sensible efficiency to be applied (e.g. load just the rows currently in the visible portion of the window). MMC is either "load everything" or "load nothing." Partial loading isn't an option. Command-line tools and other GUI tools could easily outperform MMC when accessing the logs.
From a usefulness perspective, the Windows Event logging system is pretty awful. Very few applications outside of Windows itself actually use it. And the reason for that is that the Window Event logging APIs are about as good as you expect Windows APIs to be: That is, not very good. But to make matters worse, there's a really ugly XML-based interface that is linked to each specific application's DLL/EXE for handling the actual display of event log entries. Microsoft ruined what would have otherwise been a probably okay logging interface and made it worse than useless. In short, system logging exists on Windows but almost no one uses it outside of Microsoft because the API is stupid.
Re: (Score:1)
event logs were from a time before the presentation/application layer flood gate breaking. if all you are going to do is mount a presentation layer service on a device (virtual) that reads to/from the physical layer....then stack applications on top of that....
Re: (Score:2)
And the Windows 7 event viewer does not have this problem. If you grab the eventvwr.exe from a Windows 7 machine and run it on a Windows 10 machine, it works and is super fast. I don't even think the new event viewer has any benefits over the old one.
Re: (Score:2)
From a technical perspective, the biggest and ONLY advantage of the Windows Event Logs is that they naturally loop. Log files on other platforms have to be regularly rotated to keep their size from ballooning out of control and consuming all storage space on the system.
Have you heard the good news about dmesg and a ring buffer?
Re: (Score:3)
log.txt.exe (Score:4)
- me and millions of others until 7 or 8 years ago
systemd-journal is binary format (Score:2)
systemd-journal is binary format
Re: (Score:2)
He knows. Read the next line.
Re: (Score:2)
Re: (Score:2)
The binary log files always seemed like an odd decision to me, too. I read a list of reasons why a while back, and none of them were actually good reasons. The only one that made any sense at all had to do with packing more information into each log entry as discrete fields, but that can easily be done with text as well, in ways that grep could easily parse out.
I know that systemd haters hate other aspects of it with tremendous passion, and consider the binary log files to be a tiny little quirk by compar
Re: (Score:2)
sysvinit, among many other candidates, will fix that.
Re: (Score:2)
Or just install rsyslog, disable the permanent journal, and get back to life as normal. That's the way CentOS is set up. Works fine that way. Even my Fedora 35 is outputting to syslog. Not sure if I installed rsyslog a few versions back, or if Fedora did it by default.
Re:log.txt.exe (Score:4, Funny)
I wonder if someone will ever fix that.
Yes. By following the philosophy of UNIX. You hate binary logs but like everything else. Each component of systemd generates it's own hate and does it very well. When assembled, each component's hate will result in a robust system of incredible outrage.
Re: (Score:3)
I wasn't a fan of the binary format of journald either when I first heard about the plans, but over time I have seen the benefits of the actual implementation. For one it enables structured logging where more than just the text is logged (and this is not possible with the older syslog since it has a very limited length) and this for example why one can find logs by both grepping for the app that wrote them, select if they where written by a specific service file or even see if they where written by a specif
Re: (Score:1)
then call inter-process-communications a quirk as well. or remote procedure calls or tcp. even if outdated binary outputs to a user are still possible.
Re: (Score:3)
Thank god Linux uses plain text logs for almost everything and knows better than to ever change that. - me and millions of others until 7 or 8 years ago
Slackware says "Hi".
Could not resist, and there are a few others still using txt logs. I hope that remains true for a long time for these distros.
Re: (Score:2)
Yes, thank god for archaic formats that are not indexed and have no support for structured logging, has no support for validating logs are consistent and has no way to seal logs when passing to a remote server.
And I mean, it's not like it's possible to store arbitrary content that can be used for nefarious purposes in text-based log formats. Storing text in a text file? Hah! Surely that's impossible.
Re: (Score:2)
This time the target is obvious (Score:3)
Way too often on these "ohmygod a new vulnerability" articles, you have to really dig to find out what operating systems/environments are vulnerable. This one starts by naming "Windows" and then identifies DLLs as the attack vector.
Re: (Score:1)
Also, wer.dll lives in System32. If an attacker has write access there, forget worrying about error logs. You already need to do a complete wipe and OS reinstall. Assuming they haven't also tried overwriting the UEFI.
Re: (Score:2)
Which means it's not a vulnerability, but yet another example of people vilifying the OS for doing what it was designed to do. ...
I'm sure this will be a great comfort to all those impacted by Microsoft's poor design...
Re: (Score:2)
Which means it's not a vulnerability, but yet another example of people vilifying the OS for doing what it was designed to do. ...
I'm sure this will be a great comfort to all those impacted by Microsoft's poor design...
He sounds like the Russians describing the ships that have been destroyed recently
Windows is... (Score:1)
Re: (Score:2)
Re: (Score:2, Funny)
No.
Malware is well maintained, updated almost on a daily base by its maker, generally has a very small footprint and tries to have as little impact on the normal operation of the system as it can have to avoid detection.
Windows is bloated, interferes with your productivity, gets more and more obtrusive as time progresses and whenever you think you finally have reined it in, some new and unexpected problem happens and you start all over again.
It's more like a bug.
Re: Windows is... (Score:1)
Re: (Score:2)
Erh... so was the reply?
Re: Windows is... (Score:1)
Re: (Score:1)
No.
Malware is well maintained, updated almost on a daily base by its maker, generally has a very small footprint and tries to have as little impact on the normal operation of the system as it can have to avoid detection.
Windows is bloated, interferes with your productivity, gets more and more obtrusive as time progresses and whenever you think you finally have reined it in, some new and unexpected problem happens and you start all over again.
It's more like a bug.
Saddest absolute truth I've heard all week.
Kaspersky = Boycott (Score:2)
Windows error reporting (Score:2)
In other words, if Windows didn't call the mothership, this wouldn't happen.
Re: (Score:1)
Re: (Score:3)
Yes it does: if Windows didn't report errors, there would be no WER DLL to abuse with a stupid path attack.
Or in the case of errors, if you really do want reporting (not sure why: who in his right mind is interested in helping Microsoft for free or give them details about their machine?), then at least I would expect the functionality to be statically linked.
Re: (Score:2)
Its not really Microsoft only. As a dev you can also access WER entries for your application. Back when we had a native application we used it a few times to find and fix some crashes that were unreported by the users or hard to reproduce.
Re: (Score:1)
Yes it does: if Windows didn't exist, there would be no abuse with a stupid path attack.
FTFY.
Wer.dll isn't the only DLL in the System32 directory. As I've already said, if an attacker has write access in System32. You are already hosed. The fact that Windows phones home has nothing to do with the fact that an attacker already had administrative access to the OS.
Re: (Score:1)
we ALWAYS HID MALE WARE in stupid places windows has that is easy to use for scripting from text
You should wear pants to hide your MALE WARE
Re: (Score:2)
Apple Computers (Score:2)
Re: (Score:1)
Now, more than ever... (Score:2)
Everything Microsoft ends in tears.
Comment (Score:2)