Erro 4673 falha de auditoria preenchendo logs de segurança

Question

Eu tenho um computador desktop isolado no meu escritório em que executo auditorias semanais de segurança. Eu verifico os logs em busca de comportamentos estranhos e exporto-os e limpe-os.

Os logs são preenchidos com "Falha de auditoria na ID de evento de auditoria de segurança do Microsoft Windows 4673"

A privileged service was called

Subject:

 Security ID:          System

 Account Name:         Standalone_System_2$

 Account Domain:       WORKGROUP

 Logon ID:             0x307

Service:

 Server:               Security Account Manager

 Service Name:         Security Account Manager

Process:

 Process ID:           0x208

 Process Name:         C:\Windows\System32\lsass.ese

Service Request Information:

 Privileges:           SeTcbPrivilege

Eu encontrei esta postagem do Technet que avisou que eu desative o "Uso de privilégios de auditoria" ... Não o caminho que preciso seguir.

Alguns sugeriram que poderia ser o antivírus que causava essas entradas de log ... Não sei como identificar a conta ou serviço ofensivo. Eu verifiquei os serviços no sistema e vejo um serviço chamado "Gerenciador Contas Gerenciador", no entanto este serviço não é chamado "Gerente Conta " .

Não tenho certeza para onde ir, mas quero manter esse registro de auditoria sob controle! Todas essas entradas inúteis tornam quase impossível encontrar eventos reais.

    

Answer 1

A última entrada deste tópico fala sobre o uso de uma ferramenta específica para determinar o usuário em questão para este erro (ID de login é único desde a inicialização, mas depois de uma reinicialização muda, então você precisa ver qual conta está conectada a essa solicitação) e validar se eles devem ter permissões para fazer o que eles estão usando: link

Reproduzido aqui porque o fórum é um pouco difícil de ler:

I noticed that I was getting a BUNCH of these from LSASS. (like about 17k in ~ 2 hours... couldn't figure out why the event logger was requiring so much I/O... (it was logging alot of fails)...SeTCBPriv fails.

I used 'process hacker2', (a sup'ed up version of process explorer, now that procexp is controlled by MS, (sorta like letting the foxes own your tools for watching fox in your hen-house!)..

Then I could look at what account lsass(samss) was using to run under.(either in services or in process hacker2 -- on sourceforge.net, BTW).

Then using the Local security policy panel in the admin tools, and looking under the "User Rights Assignment", I could make sure all of the required privileges needed to run, (as stated on the service ACL were permitted (if they aren't, it won't run, so that's usually not an issue), BUT, ALSO make sure the account LSASS was running under had the "Act as part of the operating system' (trusted computing base/tcb) privilege.

Same goes for any other Service -- that is generating lots of audit fails... verify it has the privileges it needs on its ACL (something incredibly cryptic to do w/o a GUI...). If you aren't sure.... research it on the net and see if it should have that priv..if it is signed and certified by MS, then likely your system is misconfigured (at least from that service's perspective ;-)) Then you just need to give it the privs it needs -- ALSO a neat thing in PH2, you can just click an option as to whether or not the service runs with a bunch of other services or not. So far, have been been able to split out interactive stuff (audio/video/desktop) from background services so I could effectively prioritize them -- before this recent discovery, no way of turning down priority on some lower prior services w/o affecting audio and/or desktop...

Anyway, after making sure LSASS had the tcb privs.. the messages went away...