An admin is investigating an unusual amount of traffic originating from a 2016 Server to the internet. The first event log was ID 1102. The outbound traffic is traversing over ports commonly associated with DNS. These symptoms are known as what?

An admin is investigating an unusual amount of traffic originating from a 2016 Server to the internet. The first event log was ID 1102. The outbound traffic is traversing over ports commonly associated with DNS. These symptoms are known as what?

• Vulnerability
• Threat
• Risk
• Indicator of Comprimise (IoC) 

EXPLANATION

Yet another event type worth monitoring is related to event log clearing. Checking for event ID 104 in the System log whether it is cleared, while searching for 1102 in the Audit log does the same. But clearing the application log puts nothing in the application event log?  

Although the application log clear does not result in a log clear entry in the actual application log, it does write an entry to the system log which was previously mentioned.  Is clearing event logs considered a normal activity? Granted, the act may not always result from malicious intent, but it should be considered enough of a non-standard event that it warrants closer examination. When log clears are performed in conjunction with other events, it is clearly a great way to cover your tracks if you were previously creating services, making firewall rules changes, etc. In some cases, if a system is functioning on an island without log forwarding or any other outside communication, this singular event might be your only indication of a much larger issue.  But wait... There are several ways to clear out the log files. Let us examine several of them to see how they work and ensure our monitoring will detect them. Obviously using the Windows native method of clearing event logs (Figure 9) is going to generate the event IDs we are looking for above. Event ID 104 is created just as expected when clearing out the System log.