Attackers Use Event Logs to Hide Fileless Malware:
Researchers have discovered a malicious campaign utilizing a never-before-seen technique for quietly planting fileless malware on target machines.
The technique involves injecting shellcode directly into Windows event logs. This allows adversaries to use the Windows event logs as a cover for malicious late stage trojans, according to a Kaspersky research report released Wednesday.
Researchers uncovered the campaign in February and believe the unidentified adversaries have been active for the past month.
"We consider the event logs technique, which we haven't seen before, the most innovative part of this campaign," wrote Denis Legezo, senior security researcher with Kaspersky's Global Research and Analysis Team.
[...] The first stage of the attack involves the adversary driving targets to a legitimate website and enticing the target to download a compressed .RAR file boobytrapped with the network penetration testing tools called Cobalt Strike and SilentBreak. Both tools are popular among hackers who use them as a vehicle for delivering shellcode to target machines.
[...] Next, attackers are then able to leverage Cobalt Strike and SilentBreak to "inject code into any process" and can inject additional modules into Windows system processes or trusted applications such as DLP.
[...] What is new is new, however, is how the encrypted shellcode containing the malicious payload is embedded into Windows event logs. To avoid detection, the code "is divided into 8 KB blocks and saved in the binary part of event logs."
Legezo said, "The dropper not only puts the launcher on disk for side-loading, but also writes information messages with shellcode into existing Windows KMS event log."
[...] Next, a launcher is dropped into the Windows Tasks directory. "At the entry point, a separate thread combines all the aforementioned 8KB pieces into a complete shellcode and runs it," the researcher wrote.
"Such attention to the event logs in the campaign isn't limited to storing shellcodes," the researchers added. "Dropper modules also patch Windows native API functions, related to event tracing (ETW) and anti-malware scan interface (AMSI), to make the infection process stealthier.
In all, with their "ability to inject code into any process using Trojans, the attackers are free to use this feature widely to inject the next modules into Windows system processes or trusted applications."
(Score: 0) by Anonymous Coward on Friday May 06 2022, @03:26AM
At least we don't hyperventilate over Windows logging vulns like we do log4j.
It must be trivial to toggle off the obscure event log capability that makes this possible right?
(Score: 3, Interesting) by Barenflimski on Friday May 06 2022, @03:48AM (1 child)
How could that be true? I've talked to people about this vector before. We went over it at a SANS event one day even. The teachers were talking about it to students.
(Score: 2, Interesting) by Anonymous Coward on Friday May 06 2022, @04:26AM
Glad it isn't just me. I swear I'd heard the exact thing before. I did a quick search and all three search engines had show older articles talking about using the event viewer to hide your payload. A couple even specifically mention packing it in this way.
(Score: 1, Troll) by Anonymous Coward on Friday May 06 2022, @04:11AM (3 children)
systemd has made this same vulnerability available there too!
(Score: 2) by janrinok on Friday May 06 2022, @08:24AM (2 children)
No, no it hasn't.
The second line actually says:
Oh, it was meant to be a joke perhaps, a poor attempt at humour?
(Score: 1, Insightful) by Anonymous Coward on Friday May 06 2022, @08:47AM (1 child)
text logs will never hide malicious payloads more effectively and efficiently than binary ones, a binary log format reader may let payloads go completely undetected. has systemd been secured againt this?
dunno, don't care.
The whole concept of a domain specific language for boot is contrary to the idea of programmability.
- Learn bash, instantly decode everything about sysvinit and similar, perform whatever boot sequence according to whatever factors.
- Learn systemd, do whatever systemd lets you perform as boot, else you gotta instruct systemd to launch an executable which brings you to step 1 with an added layer of complexity.
Can you spot the difference? The whole discussion about systemd can end here. Systemd makes you learn a DSL for simple things and adds a layer of complexity for custom things. systemd bad, scripts gud
(Score: 2) by digitalaudiorock on Friday May 06 2022, @01:54PM
Bingo. Add this to the other thousand reasons to use text logs unlike the idiots at MS as well as LP & Co. Reason #1 of course is that I should NEVER need anything but a mounted file system to read logs...period. Anyone who continues to defend binary logging is a fucking idiot.
(Score: 2) by MIRV888 on Friday May 06 2022, @11:00AM (3 children)
I am certainly not a coding expert, but wouldn't logs growing by specific amounts at specific times be a tell? Wouldn't viewing a log that has periodic gibberish / code be pretty obvious?
(Score: 2, Informative) by organgtool on Friday May 06 2022, @05:00PM
Honest question: who ever looks in their event logs? I don't know of any users that review them, even when they're actively troubleshooting an issue. From what I can tell, most troubleshooting of Microsoft software boils down to blowing away the offending OST/PST file, reg keys, profile folder, reinstall Windows, etc. It's spaghetti-against-the-wall tactics from least destructive to most destructive but rarely is there ever any attempt at diagnosing the underlying problem. With that in mind, I can't think of a better place to hide malware than the event logs. And if the data is chunked randomly in the event logs, it could be that much more difficult for AV software to detect.
(Score: 0) by Anonymous Coward on Friday May 06 2022, @07:14PM
That works with text logs but not with binary databases that Windows and systemd use. Think of a MS Access database file. When you compact it, the file gets smaller (sometimes by a lot) without losing data because not all parts of the file contain current information, and if you open it in another program most of it looks like gibberish.
(Score: 0) by Anonymous Coward on Friday May 06 2022, @11:29PM
TFA says they have a specific signature. You can use that signature to scan your logs for problems. You can even use your text or hex editor to do so instead of any of the EVT parsers. People here are complaining about binary logs, but the fact is that the files have structure and most of the information in them are in text anyway.
(Score: 2) by ewk on Friday May 06 2022, @01:32PM
So no server of value is affected by this.
Cool :-)
I don't always react, but when I do, I do it on SoylentNews
(Score: 1, Interesting) by Anonymous Coward on Friday May 06 2022, @07:28PM (2 children)
binary part of event logs??
Just how insane is that?!
And if systemd does it too, then Linux is truly dead... BSD is still safe, right?
(Score: 1, Interesting) by Anonymous Coward on Saturday May 07 2022, @06:07AM
This is why so many people hate systemd. The whole thing is build from bad implementations of Microsoft design concepts. The only reason it has any traction is because RedHat is pushing it as a dependency for other critical systems that they control.
(Score: 3, Insightful) by hendrikboom on Saturday May 07 2022, @11:11PM
Please stop blaming Linux when the fault is systemd.
The systemd-free distros, such as devuan and its derivatives, are not dead.
(Score: 0) by Anonymous Coward on Friday May 06 2022, @10:27PM
The only 10 I can use is the AME version. I still have to run it through NTlite. At this point I've disabled most services, workstation, server, apps, update, xbox, etc
Now you're telling me I have to disable the event recording service too? At least windows flies when it's free of bloat :)