I can't release the info I have yet, and I'm not trying to tease anyone...honest. However, I can say this...the method I'm using to retrieve event records from an Event Log file is very interesting. In my single-minded simplicity, I've found a way to locate "hidden" event records!
Seriously. I have a test Event Log file from a system, and using the MS API (ie, Event Viewer, psloglist.exe, and the Perl Win32::EventLog module), I can "see" 2363 total event records, running from 11239 to 13601, inclusive. However, using my Perl script, and verifying it by hand, I can also "see" event number 11238, which wasn't over written yet...the header information for the Event Log file simply tells the MS API to start with event ID 11239 (by giving not only the event ID number, but the offset where it's located within the file).
Very interesting stuff.
20 comments:
Hmmm, What are your Overwrite or MaxLogSize settings set to?
SAL,
There is no "Overwrite" setting associated with the Event Logs that I know of.
I don't have access to the full system, but I don't need it...the Retention and MaxSize settings in the file header are 7 days and 512KB, respectively.
"There is no "Overwrite" setting associated with the Event Logs that I know of."
How is that? The Overwrite setting specifies how to handle writing to the event logs when the set size of the log is reached. Options are 'Overwrite as needed', 'Overwrite events older than X days' or 'Do not overwrite, (clear log manually)
John,
Do those words within the GUI translate to the "Retention" value in the Registry?
Yes. 0x0 = Overwrite events as needed, 0xffffffff = Do not overwrite events (clear manually). Overwrite events greater than X days will vary depending on the number of days set.
Well, one should not trust anything obtained from a compromised system.
If I get that right, you manipulated a log's header record in order to hide the first event record(s) from the Windows API. If you've attained the privileges to edit the log file, you can remove any event record at will. You just have to fix the header and cursor records and move the remaining event records to fill the gap. For proof of concept please see WinZapper by Arne Vistrom: http://www.ntsecurity.nu/toolbox/winzapper/
That clearly shows that Arne does understand some, possibly all, parts of the file format. But at the best of my knowledge he didn't release a description. I released one in March in ISBN 3-00-015369-1 pp. D1-D16. Tim of Sentinelchicken.org, the author of GrokEVT, is also working on a spec. So this should be considered public knowledge and one should expect attackers to make use of it.
Btw, another way to fool the API (and an investigator trusting the API on a compromised box) would be to manipulate the message files. The invariant parts of the string you see in the log viewer applet are stored in DLLs called message files (see the EventMessageFile values in the registry).
One could edit the messagetable resource of a message file to verbally "downplay" a warning message or replace a message with some misleading text (e.g. swap "logon" and "logoff" message texts). Possibly one would have to defeat Windows File Protection to replace the original file with the manipulated one. Also filename+hash wouldn't match against a list of known-good hashes.
To overcome Windows File Protection an attacker could copy the original message file(s), mess with their messagetable resources and make EventMessageFile, CategoryMessageFile, ParameterMessageFile and the like to point to the manipulated files.
good comments Andreas,
one note on this topic is that I was of the opinion that Harlan's perl script was avoiding using the event logging API altogether and just parsing the eventrecord structure.....correct me if Im wrong Harlan?
Andreas,
To be honest, I'm really at a loss as to how you came to your conclusions, but I'll try to clear them up.
First off, the event log file in question was burned to CD and handed to me by another analyst. I read the .evt from the CD.
Second, I manipulated nothing whatsoever...I simply parsed and read, nothing more. When I saw that the end of the most recent record and the beginning of the oldest record were separated by 268 bytes, according to the header information, I confirmed this by hand, w/ a hex editor.
Again...I have not made any changes to the binary contents of the Event Log file at all. I have not modified one bit of the file.
Regarding WinZapper, I think Arne takes the wrong approach...it's far too complicated. Why not simply alter the Event ID field, and overwrite the strings section of the event records in question with nulls? No rearranging of the file required, and far less likely to leave you with a corrupted Event Log...and you achieve the same result.
Regarding the rest of your comments, I agree...and they are good comments. It just seems as if you made a lot of assumptions with regards to what I was talking about...I hope I've cleared that up.
WRT public knowledge...yes, I agree, which is why I'm trying to get it out there...but you really have to understand how corporations work...
Harlan,
sorry, I blatantly misunderstood your original post. I thought you were trying to "trick" the Windows API. Thanks for the clarification.
Were you able to decide whether the file was manipulated by an attacker or by Windows itself? I'm asking because the attackers I've seen so far either didn't bother to clean up the logs at all or brutally deleted the logs (after crashing the service, that is).
Oh, and a word regarding the "corporate environment". I feel with you. I experienced the same while I was working as a consultant. Finally I was able to change my job from a profit center into a cost center ;) That makes a big difference.
All the best!
Andreas
just one question: what does the dword at file offset 0x24 read?
Andreas...
No problem. I hope I clarified the issue a bit, and I apologize if it wasn't clear enough from the beginning...
Were you able to decide whether the file was manipulated by an attacker or by Windows itself?
There's nothing that leads me to believe that this was the case. Looking at the other Event Log files from the case, I can get a view of the services that were installed, logins/logouts, etc., but to be honest, I don't know the nature of the case...break-in, fraud, etc. However, looking at the file itself, there's nothing to suggest that it was manipulated by anything other than the operating system itself. In fact, what I found goes right along with what I understand to be how the system functions.
The DWORD at 0x024 reads "0x02".
Thanks for the info. That "0x02" means the log
- is clean (so the header can be expected to reflect the log's state)
- has been wrapped (in accordance with the record numbers you gave in your original post)
- is a backup.
So most likely this copy has been created by AutoBackupLogFiles (or rather the associated handler routine).
Unfortunately Microsoft decided to include three different functions to export logs in eventlog.dll: one in BackupEventLog, one in ClearEventLog and the AutoBackup routine. Each one affects the flags in a different way, each one might be error-prone in its own way.
I wasn't able to reproduce the error yet. I'll try again as soon as time permits. Indeed, this is very intersting stuff.
Andreas,
Is this documented anywhere?
Harlan
Harlan,
the flags are documented in my paper. Fortunately their usage appears to be constant over the time.
The side effects (below the API) of some functions are not documented to the best of my knowledge - and probably never will. If decompilation is prohibited by law, and it is in large parts of the western world, one would have to run an extensive suite of tests against every version of services.exe and eventlog.dll. I did that once, for one particular version, to better understand the service. I'd do it again only if it would be essential for a case, not for the mere joy of aggregating arcane knowledge. ;)
Regards, Andreas
Andreas,
Any chance of getting a copy of that paper? In English?
Harlan
In English? Maybe after the weekend. I'll keep you informed.
Andreas
Andreas,
I went back to the 'Net and located your presentation from earlier this year, and cut-n-pasted portions into Babelfish so I could see/understand what you were saying.
However, I'm still not able to find any documentation regarding the flags in the EVT file header.
Harlan,
please have a look at slide no. 27. I'm going to send you the preprint of my paper, hope that'll help.
Greetings, Andreas
Andreas,
Did that yesterday, my friend...and used pen to write in the Babelfish translations.
Is this content based on experimentation? How did you determine this information?
Thanks.
Harlan,
Yes, at first there was a pilot study on logs collected from 33 different systems over the years, ranging from NT 4 to Windows Server 2003. Most of them originated from W2k, however. Again, most were the usual app, sec and sys logs. One turned out to be a DNS log and some were application specific logs.
I ran some correlation on the files to seperate changing from constant parts. That was sufficient to write some rough templates for my favourite hex editor (010 by Sweetscape).
Next step were some tests to find out details about the header. I needed a controlled environment for that. I created a dedicated log to prevent from unwanted messages. A small perl script helped me to generate batches of log entries with predictable size.
Most of the testing was boring routine: adjust settings, clear log, submit some messages of suitable size, save log, reboot into Linux, save log again, reboot into Windows, ... compare logs. Ad nauseam. This procedure allowed to narrow in on one field after the other.
Of course decompilation would be the definitive source of information. But it's illegal...
That's it in brief.
Regards, Andreas
Post a Comment