"Sensitive Privilege Use" in Windows security auditing

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}

EventID4674

Version0

Level0

Task13056

Opcode0

Keywords0x8020000000000000

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

EventRecordID1511047749

Correlation

-Execution
[ ProcessID] 980
[ ThreadID] 996

ChannelSecurity

Computer<corporate name redacted>

Security

-EventData

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

SubjectUserName<corporate name redacted>

SubjectDomainName<corporate name redacted>

SubjectLogonId0x17d6e0

ObjectServerSecurity

ObjectTypeSemaphore

ObjectName\Sessions\1\BaseNamedObjects\TCMonitorSemaphore

HandleId0x338

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

PrivilegeListSeTakeOwnershipPrivilege

ProcessId0x3f08

ProcessNameC:\Program Files (x86)\Take Command\tcc.exe
 
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.
 
May 20, 2009
258
2
54
ITALY
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
 
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.