We’re excited to announce the release of a new beta version of Event Log Explorer Forensic Edition (5.6), featuring a game-changing update: native 64-bit support!
This upgrade significantly enhances Event Log Explorer’s capabilities, especially for users working with large event log datasets. Here’s why:
Breaking the Memory Barrier
While Event Log Explorer efficiently loads event logs into a temporary local database, it still requires memory to display each event. Previous 32-bit versions were limited by the Windows architecture, allowing a maximum of 3GB of addressable memory on 64-bit systems (or 2GB on 32-bit). This restricted the number of events you could display to around 4-5 million.
Expanding Your Horizons
To address this limitation, we introduced a feature to display only a specific number of events, providing a manageable experience even with large datasets.
However, some users desired to see all events without restrictions.
With the new 64-bit version, these limitations are a thing of the past. 64-bit Event Log Explorer can access up to 8TB of virtual address space, allowing you to analyze vast event logs without encountering memory constraints.
Experience the Difference
We encourage you to try out this new beta version and let us know your feedback.
Approximately 10 years ago, we introduced custom columns in Event Log Explorer. This feature allows users to extract event details from the event description or event XML. Custom columns have significantly enhanced our customers’ ability to get more information from events, and we have continuously improved it across different versions. Previously, Event Log Explorer treated custom column values as text, which sometimes was insufficient for in-depth analysis. For example, in my article about tracking printer usage, it was impossible to sort events by the number of pages.
Since version 5.5, Event Log Explorer allows users to specify the type of custom values.
Let’s take the same printer usage problem and solve it using this new power.
Make sure that logging of Microsoft-Windows-PrintService/Operational log is enabled on your print server and open it.
Set filter to Event ID = 307
Optionally hide unnecessary columns like Type, Event Id, Source, Category, User
Set custom columns as follows:
Column 1:
Column title: Printer user
Value: {DATA[3]}
Treat value as : Text
Column 2:
Column title: Printer
Value: {DATA[5]}
Treat value as: Text
Column 3:
Column title: Pages
Value: {DATA[8]}
Treat value as: Integer
As seen, you only need to set “Treat value as” to Integer for the last custom column. This will display events like the previous versions displayed, but now the Pages column is shown as an integer column.
This means that you can now sort by this column from lowest to highest value (or vice versa), not just alphabetically. You can also filter by this value (e.g., greater than or less than).
Furthermore, you can now create a summary table and calculate the total number of pages by every user. To do so, you will need to generate a new analytical report.
Select Advanced->Analytical reports from the main menu.
Then select Field List and move “Printer user” to the left area.
Select Field List again and move Pages to the central area.
Next, move Measures (1) into the top area.
This will create a summary table that looks like this:
Note that Event Log Explorer automatically calculates the sum of pages for each user because Sum is the default aggregative function for integer fields. However, you can change it to any other aggregative function if needed. For instance, if you want to get the average number of pages every user prints at once, expand Measures (1), right-click on Pages, select Properties, and in the Measure Editor dialog, change Sum to Average, then click OK.
As you can see, custom columns now offer enhanced capabilities for analyzing Windows event logs.
Starting from version 5.1 Event Log Explorer comes with scripting support (scripting is implemented in the forensic and enterprise editions). Scrips help you automate many routine tasks and improve your performance.
Scripting lets you can open logs, set filters, scan event views, remove specific events from a log view, export events and many more.
The scripting language we use in Event Log Explorer is PascalScript (FastScript by FastReports). It is similar to Pascal language with some limitation. You can download our scripting reference at https://eventlogxp.com/download/elex_scripting.pdf
Some sample scripts are available in folder “C:\ProgramData\Event Log Explorer\Scripts\Samples\”.
In this article we will write a script that merges security event log files located in one folder and displays only Audit Failure events.
Let’s start. First you need to start Event Log Explorer (Forensic or Enterprise edition) 5.2 or higher.
From the main menu select Script -> Script Console. Now you can type your script.
Consider that your log files are stored in C:\LogList folder and security log file names start with ‘Sec’, e.g. ‘security-08-2022.evtx’.
We have procedure GetFileList which returns list of files matching the specified mask. It copies the list into TStringList.
To run this procedure, we have to create TStringList object first:
var
FileList : TStringList;
begin
//create object FileList of TStringList class
FileList := TStringList.Create;
// fill FileList with file names from C:\LogList
// which start with 'sec' and have evtx file extension
GetFileList('C:\LogList\sec*.evtx', FileList);
// display the content of FileList in the debug console
DebugOut(FileList.Text);
// always free objects you created
FileList.Free;
end.
Since you have a list of logs to merge, you can use function CreateLogFileMerger to open your files in a merger. This function is a method of TSApp class. When you start Event Log Explorer, it automatically creates an TheApp object which is a single instance of TSApp class (you cannot create TSApp instances manually).
You can use TheApp properties and methods to manage Event Log Explorer application.
CreateLogFileMerger creates an event log view contain events from all event log files in the list and returns a new TSLogView object associated with the log view.
The first parameter of this function is FileNames of TStringList class. It is the same list we got by GetFileList function, but CreateLogFileMerger requires full path of file names. So, we need to add ‘C:\LogList\’ before every name in the list.
Modifying the script as follows:
var
FileList : TStringList;
i : Integer;
begin
//create object FileList of TStringList class
FileList := TStringList.Create;
// fill FileList with file names from C:\LogList
// which start with 'sec' and have evtx file extension
GetFileList('C:\LogList\sec*.evtx', FileList);
// Converting every name to full path name for i := 0 to FileList.Count-1 do FileList[i] := 'C:\LogList\'+FileList[i];
// display the content of FileList in the debug console
DebugOut(FileList.Text);
// always free objects you created
FileList.Free;
end.
It’s time to create the merger. Add Merger declaration:
The second parameter of CreateLogFileMerger defines if the script waits until all the logs are loaded or not. Since we want to filter the merger, we should wait.
To filter the log view, we can access the EventFilter property of the TSLogView and call EventFilterApply method to apply the filter:
// Clear current filter first
Merger.EventFilter.Clear;
// Set filter to display Audit Failure events only
Merger.EventFilter.EVT_AUDIT_FAILURE := True;
// Apply the filter
Merger.EventFilterApply;
The final script:
var
Merger : TSLogView;
FileList : TStringList;
i : Integer;
begin
FileList := TStringList.Create;
GetFileList('C:\LogList\sec*.evtx', FileList);
for i := 0 to FileList.Count-1 do
FileList[i] := 'C:\LogList\'+FileList[i];
Merger := TheApp.CreateLogFileMerger(FileList, True);
FileList.Free;
Merger.EventFilter.Clear;
Merger.EventFilter.EVT_AUDIT_FAILURE := True;
Merger.EventFilterApply;
end.
Taking snapshots is one of the great new features in the Forensic Edition. Whenever you need to save a set of events for future analysis, you can take a snapshot and then load it without access to the original log or log file. Snapshots are like event log backups, but there are some differences.
While backups work with the entire event log (or in some cases with event logs, filtered by an XML query), you can take a snapshot from a log view or even from separate events. Backing up from remote computers could be painful because it’s linked with extra administration tasks like sharing resources and granting permissions. Unlike backups, you can take snapshots much easy. It’s just like event export, but you can load the snapshot and work with it as you work with an event log file. Also, you can optionally save the current time zone and custom fields into the snapshot. Note that the snapshots contain the rendered descriptions and task category name. You don’t need to have specific components (dll or exe files) on your computer to display the text correctly.
Some situations when snapshots may help you:
You connected to a remote computer, opened an event log and want to save it locally.
You opened a large log file, filtered events and you want to continue working with these events only. It is always easier to work with smaller files — filtering and sorting operations are faster.
You opened an event log and have concerns about some events. You can bookmark these events and save them as a snapshot. Then you can send this snapshot to another person for research.
You merged different logs from different computers in one log view and want to save it as one file for further exploring.
It is very easy to take and load snapshots with Event Log Explorer.
To take snapshot from the active log view, select Forensics->Take snapshot from the main menu and click OK button.
To load snapshot, select Forensics->Load snapshot from the main menu.
That’s it
In this article, I will show how to work with damaged event log files. Event Log Explorer forensic edition can extract events from damaged files.
Let’s take a log file (e.g. a security log file) and open it with Event Log Explorer using File-> Open Log File.
Event Log Explorer opens this file as it always does.
Now we will intentionally corrupt this log. I will modify several bytes (commonly, it’s enough to change only 1 bit) with any hex editor. It is not necessary that someone may damage an event log – it’s not easy, but such issues may occur because of technical defects like hardware failures, driver errors, etc.
Now if you try to open this event log file, Event Log Explorer will display zero events:
You can see a red sign near the navigation buttons. If you hover your mouse over this sign, you will see a message “The event log file is corrupted”.
A similar problem occurs if you open this log in Windows Event Viewer:
Event Viewer cannot open the event log or custom view. Verify Event Log service is running or query is too long. The event log file is corrupted (1500).
However, it’s still possible to read events from this log file!
Select Forensics->Forensic Open File and change File Access Method to Direct Access Method.
This feature will open your log file!
Note that in my case, it displays fewer events than it displayed for the original event log, but this is better than 0 events anyway.
Let’s make more changes to the log and fill the first 8K with random bytes.
If you try to open it using Direct method as before, Event Log Explorer will fail to open it. However, you can use Deep Scan option. Open Forensic->Deep Scan, select your file and press OK.
Event Log Explorer will scan your files for events.
You can use deep scan not only for event log files. You can scan disk images including virtual disks or even physical or logical disks.
Deep scan may help you to find more events even if you have undamaged event log files. E.g. if a log was cleared, you can still find cleared events on the disk if they were not overwritten.
Although Standard Edition of Event Log Explorer works with event log files perfectly, you may need more functionality when analyzing damaged or intentionally modified event log files. I’m starting a series of articles about the advanced use of Event Log Explorer Forensic Edition with files.
Let’s imagine that you examine an event log with removed events. If you believe that it’s impossible to remove events from an event log, I will show how to do it.
I will remove logon events from Security event log as follows:
Start Windows Event Viewer.
Open a log file (I take Security.evtx from my old archive, but you can use it even with the live Security log).
Set Filter in Event Viewer to exclude events 4624 (of course you can set any filter you want).
Click “Save Filtered Log File As” and save it as EVTX file.
Voila, you have a new event log file with removed events. You can open it with Event Viewer or Event Log Explorer and don’t even expect that it’s not an authentic event log. Of course, a real malefactor should replace a live event log with the forged one, but it’s not an impossible task. If s/he has a physical access to the computer, it’s possible to replace C:\Windows\System32\WinEvt\Logs\Security.evtx by loading the computer in recovery console. It’ much harder to forge the log remotely, but still possible by exploiting system vulnerabilities (e.g “Vault 7” hacking tool set lets you exploit such vulnerabilities and remove events).
And how can we detect if the examined event log file misses events? We discovered that Event Viewer (more accurately Event Log API) just copies the events into a new file as is. So, all events in the new log file will have the same record number as they had in the original event log. If we scan all the events, we can easily detect missed record numbers.
This functionality is implemented in Event Log Explorer Forensic Edition. Select Forensics from the main menu, click Forensic Open File, add your files by clicking Add button and enable option “Check log files for deleted events”. You will have the list of potentially deleted events.
You may be wondering if it is possible to forge an event log in such a way that it will fix the record numbers making it indistinguishable from non-edited log. It was easy for legacy evt logs, but very hard for the modern evtx event logs. I cannot state that it’s impossible, however I never seen any tools or a sample code that can do such tricks. That’s why I believe that Event Log Explorer can detect events deletion in event logs.
Now I will explain how Event Log Explorer works with disk images. If you have a disk image from an examined computer, you should mount it as a disk. If you have a real disk, you can just connect it to your PC.
Let’s consider that you already mounted a disk that contains Windows folder of the examined PC. Now you can create a virtual (“imaged”) computer in Event Log Explorer. Select Forensics->Add Imaged Computer from the main menu. Event Log Explorer will try to detect your disk, but you can input the path to Windows folder manually. You should also type a friendly name of this computer in the Tree and press Ok.
The computer will be added to the tree as a general computer, and you can use Event Log Explorer with this virtual computer exactly like you work with the real computers!
You may think that Event Log Explorer just opens files from \Windows\System32\winevt\Logs\, but it does much more. When you just open a foreign even log file, you can often see the description rendering issues (The description for Event ID (Event) from source (Source) cannot be found). These issues occur because the event log file doesn’t contain the description messages. Even descriptions are rendered based on the installed components, and if the required component is missing, you will see the “description not found” message.
Event Log Explorer tries to emulate the live system. It reads the registry files (\Windows\System32\config\SOFTWARE and \Windows\System32\config\SYSTEM), builds a log tree, detects the location of the required description components, and then reads log files and renders descriptions messages. From the user’s point of view, you are just working with the local event logs.
Recently we released a new edition of Event Log Explorer – Forensic Edition. Currently it has a beta version status – the final release will appear after we complete the documentation and add extra forensic features.
Here I will describe the difference between the standard and forensic editions.
The program keeps all features of the Standard Edition, and you commonly don’t need to use the Standard Edition if you have the Forensic one. Anyway, if you have a license key to Forensic Edition, you can use it with Standard Edition. However, if you have a license key to Standard Edition, it will work only with the current beta version of Forensic Edition but won’t work with the final release. You will be able to upgrade from Standard to Forensic by paying the price difference.
New program doesn’t require elevation when you run it. So, if you don’t have the admin rights, you can still run this program. The standard edition requires elevation to access the Security log and to manage event logs (e.g., clear them). Forensic users commonly work with log files, so it is not necessary to start it elevated. However, if you need to access the Security log, you may run it as Admin manually.
When you start the program, you can find the major difference between the editions in the user interface. There are two new menu items in the main menu: Forensics and Script.
Script lets you create and run your own scripts (written in Pascal script) which helps you to automate some operations or create complex filters. We will add scripting to the Enterprise Edition of Event Log Explorer as well.
Forensics menu opens access to the forensic features of the program.
Add imaged computer lets you create a virtual computer in the Objects tree and access its log files as “live” logs.
Forensic open file lets you open event log files using a “forensic” method. This includes opening files without Windows API and allows you to open damaged files.
Deep scan lets you scan an event log file, a disk image or even a whole disk for events. This lets you extract events from highly damaged log files or unmounted or damaged disk images.
Take and Load snapshot let you save your current event log view into a file for future analysis.
I will write several articles about each new forensic feature soon, but now you can download and try the new forensic edition yourself:
Reading event logs from remote computers is crucial for network audit. Both Event Log Explorer and Windows Event Viewer applications allow the system administrators to read event logs remotely. However sometimes (mainly in no Active Directory environment) sysadmins have problems with accessing remote event logs. In this article, I’ll explain how to setup Windows to make event logs accessible over a network.
As a rule, you don’t need to change anything on your client computer (the computer on which you run Event Log Explorer or Windows Event Viewer). All the changes should be done on the audited computer.
First, you need to set up the firewall.
Run Windows application: Windows Defender Firewall with Advanced Security.
Select Inbound rules for your profile
Enable the following inbound rules:
Remote Event Log Management (RPC)
Remote Event Log Management (RPC-EPMAP)
Remove Event Monitor (RPC)
Remote Event Monitor (RPC-EPMAP)
Note that these settings are applied locally. If you run Active Directory and want to change these settings globally, you can do it in a similar way using Group Policy Management Editor.
Next, if you have a serverless network, you should check sharing and security model for local accounts. Open Local Security Policy, select Local Policies->Security Options in the left pane and make sure that the policy “Network access: Sharing and security model for local accounts” is set to Classic – local users authenticate as themselves.
Finally, you should grant permission to read event logs to your users. In no Active Directory environment, you can use Computer Management. In AD use Active Directory Users and Computers console.
Select the user under Local Users and Groups (or under your domain users). Double click on it to display Properties and select Member Of. Click Add and type Event Log Readers.
That’s all. If you modified Group Policy settings, you should apply your changes (e.g. by using gpupdate command).
Now you can start Event Log Explorer or Windows Event Viewer and open remote event logs.
Several years ago, I wrote an article about generating weekly reports about network issues. The main drawback of that method was the requirement to have Event Log Explorer running all the time (or at least running by the time when the scheduled task should be started). Since that time, we released new versions and editions of Event Log Explorer and now we can get the same result in a smarter way.
Let’s take the same task – getting reports about non-informational events in Application and System logs from different servers.
First, you need to install Event Log Explorer Enterprise Edition since Logexport utility is not available in Standard Edition.
After running Event Log Explorer, we should create a task which collects all non-informational events for the last 7 days. We can make this task from scratch, but we have template for this task (Admin events).
In the Objects tree browse for Task templates->Administrative and double click on Admin events.
Create task from template window will appear.
You can change the task name and task folder, but I will leave the default values.
Click Next and on Computer tab add your servers to the list
I will add only 2 servers, you can add any number of them.
You can optionally click Test connectivity button to check if the servers are accessible.
Click Next to proceed to the Logs page. Application and System logs are already in the list, but you can add extra logs. Click Next to proceed to the Filter page.
I will not change the filter setting taken from template, but you can modify them as you wish (e.g. change time interval to 1 day or exclude Waring events).
Click Next to review the column settings and then click Next again for the last step.
Now you should export your task into a file.
Consider that you have C:\Tasks folder for the task and exported documents, click Save button to save your task as “C:\Tasks\Admin Events.xml”.
Click Finish button – this will also create the task in the Objects tree.
Doubleclick on the task in the tree to review the events.
Open Command Prompt (or Windows Power Shell) and export task events to Excel
That’s it, the task is scheduled to 8:00 every Monday. You can use Windows Task Scheduler to modify or verify the task.
It is important to specify the username and password using /RU and /RP parameters since the task should be started even if no user logged on your OC. Alternatively you can start the task under System account, but provide the credentials as command-line parameters for logexport.exe. In this case you can use the following command to create the task:
Note that since you scheduled the task to start under the System account, you should run this command elevated (start Command Prompt or PowerShell as Admin).
Now you can run the task e.g. using Task Scheduler to make sure that it works correctly.