Security, et al

The Art of Detecting Malicious Activity with Logs

Sun, 21 Aug 2011 16:50:57 GMT

Security standards and auditors make much of reviewing logs
for malicious activity and I am constantly asked for event signatures
indicative of intrusions or even more simplistically some ask “What are the top
Event IDs for intrusion detection?”Ah,
if it was only that easy.Movies make it
look that way, the protagonist furiously defends the network while a computer
voice stridently calls out “intruder, intruder”.

But in the real world, if the computer can detect an
intruder it takes immediate preventive steps instead of simply logging the
intrusion or helplessly calling out “intruder”.For instance if an attacker tries to discover an account’s password
through repeated logon attempts, the system locks out the account.On the other hand, if a disgruntled employee
copies sensitive data to flash drive, to the operating system it looks like any
other day of normal usage.An authentic
user accessing authorized data.If the
system is logging anything at all, there will just be an audit trail of
successful access attempts.

It’s not impossible to use logs to detect some intrusions
and malicious activity but the first and foremost return on investment from
logging is an audit trail that can be used to detect high impact changes in
security stance, investigate incidents, perform impact analysis, take action
against offenders and learn how to prevent repeat attacks in the future.Moreover, a properly deployed audit system
serves as an effective deterrent control against insider abuse.All of this can be accomplished by enabling
logging on monitored systems and implementing a log management solution with
high integrity deployment characteristics.

But to get more than change detection and audit trail usage
from your logs you must go upstream from the logging function and get the
cooperation from system administrators to configure and operate systems in such
a way that certain foreseeable types of malicious activity will recognizable to
your log management solution.

Take security log integrity in Windows as a simple
example.Windows provides strong
protection against tampering with the security log.Unless the operating system is down and you
have physical access to the system you basically have to be an administrator to
erase the security log.(It’s very
difficult even with administrator authority to modify event records in the
security log – you need a program like the old WinZapper.)Windows graciously logs a specific event ID (517
on Win2003 and 1102
on Win2008) whenever the log is cleared so it makes sense to generate an alert
whenever security logs are cleared as a deterrent to rogue administrators
trying to cover their tracks or as a way of detecting an intruder doing the
same.But if your administrators are in
the habit of clearing the log when diagnosing system problems, your alert rule will
generate false positives.Therefore, in
addition to reactive log management you must proactively get administrators to
comply with a policy to never clear security logs and allow old events to die a
natural death as records are purged.

While the previous case demonstrated an example of
procedural measures implemented upstream from the log management process,
detecting the spread of file based malware requires you to work with system
administrators to setup system objects ahead of time for the purpose of helping
the log management solution distinguish between normal file access and
malicious.Here’s the premise: you want
to detect malware that has made it through your preventive controls like
antivirus.Most malware either spreads
by injecting itself into files of affected file types (i.e. word documents or
image files) or looks for files that it can send back to its nefarious
operator.

So, we set up the equivalent of a trip wire for unsuspecting
malware or outside intruders to trigger. (In this example I’ll stick with the Windows
and Active Directory environment but the concepts would be applicable to other
platforms.) To do this we work with various system administrators to create
“honeypot” folders on servers throughout the network.In these folders we put a collection of files
with all the common file types including Office documents, image files (e.g.
JPG, GIF), PDFs and others that have been targeted by malware.Ideally we name these honeypot folders with
just one or a few easily recognizable folder names.We grant everyone access to these folders and
enable file system auditing so no matter what user is the victim, the malware
will have access to folder in order to trigger the tripwire.If we want to detect malware that is
spreading itself or simply corrupting data, we limit file system auditing to
WriteData and AppendData.On the other
hand if we also hope to detect malware that is stealing data we would also
enable auditing of ReadData. Then back at our log management solution we would
enable alert rules when file system audit events (event ID 560
on Windows 2003 and 4663
on Windows 2008) arrive which identify
one of our honeypot folders as having activity.To prevent false positives some training and reminders may be necessary
for end-users so that they understand these folders (especially those on file
server shares) have nothing useful for them and are there for “system”
purposes.

These 2 examples demonstrate you can take a foreseeable type
of malicious activity and implement procedures or system objects that make it
possible to detect activity that would normally blend in with the background
noise of everyday, legitimate usage.The
downside of course is that you require cooperation from folks who are upstream
from the log management solution.Depending
on the capabilities of your log management solution, you may be able to
discover malicious activity without implementing upstream tripwires using a
final method: anomalous changes in activity levels.

Some types of malicious activity cause a spike in audit
events that can be detected if your log management solution has sufficient
real-time analysis capabilities.My
favorite example is the disgruntled insider who intends to post thousands of
documents to a site like Wikileaks.The
user likely already has access to the sensitive documents in question so there
may be little or no failed access attempts to alert you to what is
happening.Instead, file system
auditing, if enabled, will generate successful read attempt events for each
file accessed.However, if a typical day
in the life of the angry employ involves accessing just a handful of documents
and now he or she suddenly accesses many times that amount, a feature rich log
management solution should be able to keep a rolling average of normal Read
events on sensitive folders for each user and detect a spike like this.At that point there is sufficient cause to
generate and alert and devote some security staff time to determining the
cause.With anomalous activity level
detection, some thresholds can be generalized and baked into the log management
solution but others would need at least some amount of customization by the
organization such defining folders or servers that are considered
sensitive.

As you can see, detecting intrusions and abuse with logs is
possible but it requires a variety of analysis techniques.Likely you will need the cooperation of
system administrators upstream from your log management system in order to
setup procedural or system level tripwires.Finally your log management solution’s ability to analyze large amounts
of data detect sudden changes in activity levels for a given system or user can
be very effective in alerting you that something is afoot.

Hello Randy, in an environment with "Audit access to global system objects", we have millions of 560 errors in the Security log. In looking at the fields, it appears that it is services.exe that is querying (every 10 seconds or so), for a CurrentControlServices\...\ObjectName.

The sub-key ObjectName does not exist! Any access attempt generates a 560 event. It's not a authorization failure, but a existential failure.