The problems of PUA (Potentially Unwanted Alerts)

Recently we had a client call us about a problem on their network.  Rendition Infosec runs a 24×7 security monitoring service and had a client call about an antivirus alert for PUA (potentially unwanted application).  This class of alert is often difficult to tune out since attackers and administrators often use the same software tools.

Frequent examples of this are netcat (nc.exe) and psexec from SysInternals.  These tools are like the infamous “dual use technology” we hear so much about when sanctioning oppressive regimes.  When we receive an alert like this, we most frequently find that the alert can be attributed to the activity of a systems administrator.  However, there is a possibility that the alert represents the activities of an attacker.

Given the frequency with which the tools are attributed to systems administrators, we have started to reclassify PUA as “Potentially Unwanted Alerts.”  This is not to say that it’s not important to investigate these alerts.  It is critically important to always investigate alerts received unless we know for sure that the alerts are false positive, in which case SIEM tuning can usually be used to tune them out.  Giving in to alert fatigue is one of the “Seven deadly sins of incident response” that Rendition Founder Jake Williams briefs at conferences regularly.

Enter winexesvc.exe

Recently Rendition received alerts for a file called winexesvc.exe.  We know that both Trend Micro and Symantec began alerting on this file in the past few weeks.  But what is it?  We recognized the executable name as a psexec-like installer run from Linux.  One of our partners (AlienVault) uses winexesvc.exe to install OSSEC agents on endpoints.

Is winexesvc.exe a risk?

In short, no.  In order for an attacker to use this software they would have to possess administrator credentials to the remote machine.  But if you have administrator credentials to the remote machine you could use any number of other techniques to run code remotely.  You don’t need winexesvc.exe in that case.  In short, even though a number of remote installers use winexesvc.exe, there’s no benefit to the attacker if the service binary is left behind.

How should I respond to winexesvc alerts?

It depends.  While the presence of this file likely indicates that someone has remotely installed software on a machine, it is important to understand the context.  Ask yourself who might have performed the installation and why?  Additional research by qualified incident response personnel is definitely needed if a systems administrator can’t remember using winexesvc.exe to remotely install software. Note that the installation probably would have come from Linux, so if you don’t use Linux in your environment, it is much more likely to require investigation.

Closing thoughts

While we certainly don’t want to get in the habit of summarily ignoring alerts, it is important to understand the context of the events that you are seeing.  If you see alerts that you can’t fully understand, engaging qualified forensics and incident response personnel to unravel the mystery is always advisable.

In Cliff Stoll’s book “The Cuckoo’s Egg” he describes how he found East German hackers in the Berkley computer lab.  His initial indication that attackers were in the network wasn’t an obvious security alert.  It was a $.25 accounting discrepancy in billed computer use time.  Cliff could have easily ignored this, but instead persevered to find hackers laterally moving through Berkley to compromise US DoD systems.  Throughout the investigation, Cliff involved the people with the right qualifications to help him track the attackers back to East Germany.