Auditing feature in Windows

Thought of sharing my experience around auditing feature available in Windows, which helped me solve a critical issue that affected many users.

The issue was that the users started reporting that every day they were receiving an automatic update notification to install a specific patch. The user installs the patch and the next day he again gets notification to install the same patch.

The patch that was repeatedly being offered was MS10-026 (KB977816). This patch updates the following files.

On the problem machines I observed that the file L3codeca.acm was getting reverted back to the previous version (1.9.0.305).The scenario is that the user installs the patch, the file gets updated to 1.9.0.306 and then after some time, something is replacing the file with the older 1.9.0.305 version. The subsequent scan by the automatic update agent detects the required file version at a lower level and offers the patch to the machine. This loop continued and users had every reason to get frustrated.


Now, how to determine who is replacing the file l3codeca.acm with the previous version?


I decided to use the Audit feature available in Windows XP that allows an administrator to audit user access to files, folders, printers, registry etc.

Steps to Enable Auditing for the file l3codeca.acm

You can enable auditing through the group policy console.

1. Start Run, type gpedit.msc and press Enter.
2. Under Computer Configuration, look in Windows Settings Security Settings Local Policies Audit Policy, and enable Audit object access on both Success and Failure.

Once we have enabled auditing through policy, we can specify the file that needs to be audited by the following steps

1. In Windows Explorer, locate the file or folder you want to audit (C:\WINDOWS\system32\ l3codeca.acm).
2. Right-click the file and then click Properties.
3. Click the Security tab, and then click Advanced.
4. Click the Auditing tab, and then click Add.
5. In the Enter the object name to select box, type the name of the user or group whose access you want to audit. You can browse the computer for names by clicking Advanced, and then clicking Find Now in the Select User or Group dialog box.
6. Click OK.
7. Select the Successful or Failed check boxes for the actions you want to audit, and then click OK.
8. Click OK, and then click OK.

Okay, now we have everything ready to isolate the process/user trying to change the file.

After few days I got the event logs from the problem machine.
I analyzed the Security event log to search for the accesses to the file l3codeca.acm and following is what I found. At around 10:49 PM the process msiexec has accessed the file in question.

After analyzing the Application event logs to identify the application that triggered msiexec process, it was observed that at around the same time during which the above object access failure occurred, an msi instance of the application Audio_codec was triggered.




From the above analysis, it was pretty clear that the application Audio_codec is the culprit.

From all these data, it turned out that once the automatic update installs the patch and update the l3codeca.acm file, the Audio_Codec application does an msi repair when it finds the file to be not at the expected version, and reverts the file back to an older version. The next automatic update scan will detect the file to be at a vulnerable version and re offers the patch. This cycle continues in a loop.

The users were requested to uninstall the Audio_codec application and this solved thier annoying issue.