How to Use Process Tracking Events in the Windows Security Log
Mon, 13 May 2013 12:18:05 GMT
This
article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/how-to-use-process-tracking-events-in-the-windows-security-log/
I think one of the most underutilized features of Windows
Auditing and the Security Log are Process Tracking events.
In Windows 2003/XP you get these events by simply enabling
the Process Tracking audit policy. In
Windows 7/2008+ you need to enable the Audit Process Creation and, optionally,
the Audit Process Termination subcategories which you’ll find under Advanced
Audit Policy Configuration in group policy objects.
These events are incredibly valuable because they give a
comprehensive audit trail of every time any executable on the system is started
as a process. You can even determine how
long the process ran by linking the process creation event to the process
termination event using the Process ID found in both events. Examples of both events are shown below.
Process Start
|
WinXP/2003
|
592
|
A new process has been
created.
Subject:
Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23
Process Information:
New Process ID: 0xed0
New Process Name: C:\Windows\System32\notepad.exe
Token Elevation Type: TokenElevationTypeDefault (1)
Creator Process ID: 0x8c0
|
Win7/2008
|
4688
|
Process End
|
WinXP/2003
|
593
|
A process has exited.
Subject:
Security ID: WIN-R9H529RIO4Y\Administrator
Account Name: Administrator
Account Domain: WIN-R9H529RIO4Y
Logon ID: 0x1fd23
Process Information:
Process ID: 0xed0
Process Name: C:\Windows\System32\notepad.exe
Exit Status: 0x0
|
Win7/2008
|
4689
|
Trying to determine what a user did after logging on to
Windows can be difficult to piece together.
These events are valuable on workstations because they are often the
most granular trail of activity left by end-users. You can tell for instance that Bob opened
Outlook, a few minutes later opened Word, opened Excel and then closed
Word.
As you can see the process start event tells you the name of
the program and when it started. It also
tells you who ran the program and the ID of their logon session with which you
can correlate backwards to the logon event and thus further determine what kind
of logon session in which the program was run and where the user (if remote)
was on the network using the IP address and/or workstation name provided in the
logon event.
Process start events also document the process that started
them using Creator Process ID which can be correlated backwards to the process
start event for the parent process. This
can be invaluable when you are trying to figure out how a suspect process was
started. If the Creator Process ID
points to Explorer.exe, after tracking down the process start event, then it’s
likely that the user simply started the process from the start menu.
These same events, when logged on servers, also provide a
degree of auditing over privileged users but be aware that many Windows
administrative functions will all show up as process starts for mmc.exe since
all Microsoft Management Console apps run within mmc.exe.
But beyond privileged and end-user monitoring, process
tracking events help you track possible change control issues and to trap
advanced persistent threats. When new
software is executed for the first time on a given system it’s important to know
that, since it implies a significant change to the system or it could alert you
to a new unauthorized and even malicious program running for the first time.
The key to this seeing this kind of activity is to compare
the executable name in a recent event 592/4688 to executable names in a
whitelist - and thereby recognizing new executables.
Of course this method isn’t full proof because someone could
replace an existing executable (on your whitelist) with a new program but with
the same name and path as the old. Such
a change would “fly under the radar” with process tracking. But my experience with unauthorized changes
that bypass change control and APTs indicates that while certainly possible,
the methods described here-in will catch their share of offenders and
attackers.
Of course to do this kind of correlation you need to enable
process tracking on applicable systems (all systems if possible, including
workstations) and then you need a SIEM solution that can compare the executable
name in the current event to a “whitelist” of executables.
How you build that whitelist is important because it
determines if your criteria for a new executable is unique to “that” system, or
if it is based on a “golden” system, or your entire environment. Of course the more unique your whitelist is
to each system or type of system the better.
You can build the whitelist by either scanning for all the EXE files on
a given system or by analyzing the 592/4688 events over some period of time. I prefer the latter because there are many
EXE files on Windows computers that are never actually executed and I’d like to
know the first time any new EXE is run – whether it came with Windows and
installed applications out of the box or whether it is a new EXE recently
dropped onto the system. On the other
hand if you only want to detect when EXEs run which were not present on system
at the time the whitelist was created, then a list built from simply running
“dir *.exe /s” will suffice.
If you opt to analyze a period of system activity make sure
that the period is long enough cover the full usage profile and business
process profile for that system – usually a month will do it. Take some time to
experiment with Process Tracking events and I think you’ll find that they are
valuable for knowing what running on your system and who’s running it.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
9 Mistakes APT Victims Make
Mon, 13 May 2013 12:06:56 GMT
This article was first published at Lumension’s
Optimal Security blog: http://blog.lumension.com/6588/9-mistakes-apt-victims-make/
A couple years ago, Bruce Schneier said that against an APT
attacker, “the absolute level of your security is what's important. It doesn't
matter how secure you are compared to your peers; all that matters is whether
you're secure enough to keep him out.” Those words have proven true over and
over again. APT attackers don’t move on to the next target as soon as they see
your security is a little above average.
In this age, when you have to do everything right to protect
your network, it pays to look at what other people do wrong and learn from
their mistakes. Based on public and unpublished APT incidents, I’ve gathered a
list of 9 different things that show up repeatedly:
1.
Allowing open attack surfaces without securing
configurations
A system’s attack surface comprises the started services,
enabled features and installed software.
Stopping all unneeded services, disabling each and every feature that
isn’t needed and removing all non-essential software is how you reduce your
attack surface.
This includes all those elements that might seem innocuous
and have no known risks. Time and again
innocent little features have proven to harbor nasty vulnerabilities that the
bad guys find and leverage. Case in
point is Internet Explorer’s automatic proxy server detection which is enabled
by default. A recent weaponized malware exploited
this feature to fool computers trying to download Windows security updates.
While group policy is part of the solution you need
configuration management and centralized remediation capabilities so that you
can obtain ongoing assurance that all systems on the network are secure and
presenting the smallest possible target to the enemy.
2.
Permitting unlocked ports and unfettered device
usage
Allowing USB drives and other removable storage devices to
connect to your PCs is reckless. USA
Today details how an infected USB drive idled a power plant for 3
weeks. This Slashdot
article tells how one study found 2/3 of lost USB drives carry
malware. Think you can’t be singled out
and targeted USB drives? Think again. The bad guys go to tradeshows of target
industries and pass them out as swag.
They drop them in Starbucks near target businesses.
Windows features native removable storage restrictions that
can be implemented in group policy but if you need enterprise management and
compliance features like reporting and better control over different classes of
devices look to your endpoint security vendor.
3.
Failing to use centralized vulnerability
remediation
There are too many tweaks and security fixes that can’t be
made via group policy including de-registering unsafe DLLs, setting the kill
bit, configuring BitLocker, power shell security and changing the local
administrator password to name just a few.
You need a way to run commands, remediation scripts and other fixes on all your PCs automatically and be able to
track the success of such remediation steps.
Startup and logon scripts in group policy don’t provide this crucial
reporting capability so you need to look at your system management capabilities
or end point security technologies.
4.
Allowing untrusted software to execute
This is the single most effective way to stop APTs. You might be able to use Windows 7
AppLocker or you may need a modern
enterprise application whitelisting solution but either way, stop unknown,
unauthorized software from executing on your systems. Enough said.
5.
Failing to follow existing security
policies/procedures and use at-hand technology consistently
Not eating your own dog food is a painful reason to fall
victim to an APT but it happens. All it
takes is one neglected computer or one person who fails to follow policy. Case in point: Adobe allowed a critical
code-signing server to function while noncompliant with their corporate security
standards. It lead to malware being
signed to look like valid Adobe software and resulted in a huge security
incident affecting Adobe customers.
6.
Permitting open policies for privileged user
authority
The RSA SecureID incident involved lateral movement between
systems and users resulting in privilege escalation. This typically means that a privileged user
was logged on interactively on a system where they also read email, browse the
web or open document files. Best
practices and privileged user technologies exist to keep admin level
credentials sacrosanct; APTs show their value.
7.
Not engaging in consistent end-user security
awareness
RSA SecurID incident occurred when 3 users were sent an
infected spreadsheet, it went into their Junk email, and a single user opened
it. One corporation sent a spear-phishing
email to its users as part of a security awareness program. It took 3 campaigns before they got the open
rate below 20%. Lesson: security
awareness needs to be more than a poster in the break room. Make your program constant and trackable so
that you can verify that you are changing behavior.
8.
Failing to leverage logging and to set up traps
Most organizations do not monitor process start events to
discover new EXEs. Nor do most
organizations deploy decoy folders with bait files on production systems and
audit access to these files. Both are
effective ways to detect malicious outsiders.
9.
Permitting
Malware beaconing and exfiltration
In most cases, malware must be installed and permitted to
run for an APT to be persistent. When activated, most APT-ware must beacon back
to command and control servers. At some
point data is exfiltrated. It is
challenging, but there are techniques for recognizing outbound traffic that
could be malware. Here’s a couple
examples: Look for strange packet patterns inconsistent with normal web
browsing like more data going up than down.
Look for mysterious domain names like ibiz.3387.org.
Each of these measures is a single layer of defense and you
need them all. Because it only takes
one: one user, one PC, one setting or vulnerability that lets the bad guy get a
foothold. It comes down to
defense-in-depth, doing everything right and not allowing untrusted code to
execute.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
9 Mistakes APT Victims Make
Live with Dell at RSA 2015
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
previous | next
powered by Bloget™