"Sensitive Privilege Use" in Windows security auditing

[Bill de Haan]

Hi;

I'm running TCC 18.00.18 in a Windows 7 corporate environment.

I run an overnight cron job (scheduled task) of a BTM script every night at 2am. This script does simple housekeeping tasks - runs a WinAudit of the PC, backs up various directories to an external USB, and on the weekends, runs a defrag of the disk.

I got a new PC recently, and our IT is reporting that I'm generating millions of security hits in their logs. Looking in my own Windows Event security log, I see over 1.2 million event today, with 2,812 events in a single second.

The script is started with user privileges, not elevated. The script takes about an hour to run, during with it's generating thousands of log events every second. Running the script manually does not create the same issue.

I can't really imagine why it does this. Has anyone had a similar issue? Or have any idea why this is happening?

I've put an example event log entry below, if that helps.

-

System

- Provider [ Name] Microsoft-Windows-Security-Auditing [ Guid] {54849625-5478-4994-A5BA-3E3B0328C30D}

EventID 4674

Version 0

Level 0

Task 13056

Opcode 0

Keywords 0x8020000000000000

- TimeCreated [ SystemTime] 2019-04-04T07:45:13.027495300Z

EventRecordID 1511047749

Correlation

- Execution [ ProcessID] 980 [ ThreadID] 996

Channel Security

Computer <corporate name redacted>

Security

-

EventData

SubjectUserSid

S-1-5-21-1959627124-635220436-521931719-3883

SubjectUserName

<corporate name redacted>

SubjectDomainName

<corporate name redacted>

SubjectLogonId

0x17d6e0

ObjectServer

Security

ObjectType

Semaphore

ObjectName

\Sessions\1\BaseNamedObjects\TCMonitorSemaphore

HandleId

0x338

AccessMask

%%1537 %%1538 %%1539 %%1540 %%1541 %%4528 %%4529

PrivilegeList

SeTakeOwnershipPrivilege

ProcessId

0x3f08

ProcessName

C:\Program Files (x86)\Take Command\tcc.exe

 

[rconn]

TCC will (for a few specific cases) attempt to get a privilege -- for example, if you're attempting to query the owner of a file, or for TASKEND. But it never tries for "SeTakeOwnershipPrivilege".

 

[Bill de Haan]

That's what confuses me. This script is quite innocuous. For the most part, it calls ROBOCOPY.EXE, FREEFILESYNC.EXE, WINAUDIT.EXE, and Beyond Compare v3, none of which should be doing anything that requires any elevation.

The only Take Command calls I can see are
set RC=%@exec[cmp PREVIOUS.TXT CURRENT.TXT]
iff [%@execstr[tasklist Slimjet]] == [] then
if [%DIR%] == [] set DIR="%@unquote[%_CWD%]"
iff not %@label[%DST%:] == %LABEL% then
iff %@ready[%DST%:] == 0 then

Given what you said about TASKEND, could the TASKLIST potentially do anything?

What I don't understand is that I've run this command at the command shell and not had any issues, so why it would be raising security alerts when run as a scheduled task makes no sense to me.

 

[vefatica]

What about the ObjectName (\Sessions\1\BaseNamedObjects\TCMonitorSemaphore)? Is that common to all the log entries?

 

[Rodolfo]

That's what confuses me. This script is quite innocuous. For the most part, it calls ROBOCOPY.EXE, FREEFILESYNC.EXE,
...
What I don't understand is that I've run this command at the command shell and not had any issues, so why it would be raising security alerts when run as a scheduled task makes no sense to me.

Is it possible that as a scheduled task it is run as a different user, for example a service account?
What happens if You change the settings so that the task is run as You?
And if You log-in as that service account and then run that command?

Regards

Rodolfo Giovanninetti

 

[Bill de Haan]

Hi all;

I wish I'd read Rudolfo's comment before now. I got an email when Rexx posted, but not the other two. On Friday, I managed to trace it down, and was just coming here to update it with the solution.

Yes, Rudolfo was correct. It was running as a different user. I log in as CORPORATEDOMAN/USERID, but the scheduled task was created with the default credentials of USERID. Specifically, it was created as MACHINENAME/USERID. Of course, my script was checking %USERNAME%, which returns USERID, regardless of whether it was in the corporate domain or not.

The script worked, but because I was accessing domain resources without the proper domain credentials, every access was flagged by our security monitor as a security violation. And since the backup scans over a million files, that meant over a million hits on the security.

Thanks for the help, guys.

 

[gentzel]

"Rexx" is a language, "Rex" is a person.

 

[TEA-Time]

I got an email when Rexx posted, but not the other two.

You have to visit the thread after each post to renew getting a notification for subsequent posts.