Catching Hackers Living of the Land Requires More than Just Logs
Mon, 21 Dec 2015 13:56:30 GMT
If attackers can deploy a remote administration tool (RAT)
on your network, it makes it so much easier for them. RATs make it luxurious for bad guys; it’s like
being there on your network. RATs can
log keystrokes, capture screens, provide RDP-like remote control, steal
password hashes, scan networks, scan for files and upload them back to
home. So if you can deny attackers the use of RATs
you’ve just made life a lot harder for them.
And we are getting better at catching so-called advanced
persistent threats by detecting the malware they deploy on compromised
systems. We can say this because experts
are seeing more attackers “living off the land”. Living off the land means for an attacker to
go malware free and instead rely on the utilities, scripting engines, command
shells and other native resources available on systems where they gain an entry
point.
By living off the land, they keep a much lower profile. They aren’t stopped as much by application
control and whitelisting controls. There’s no malware for antivirus to detect.
And Windows provides plenty of native resources for this
kind of attacker. (Linux and UNIX do
too, but I’m focusing on Windows since client endpoints initially targeted by
today’s attackers mostly run Windows.) You
might be surprised how much you can do with just simple batch files. Let alone PowerShell. And then there’s WMI. Both PowerShell and WMI provide a crazy
amount of functionality. You can access
remote systems and basically interface with any API of the operating
system. You can open up network
connections for “phoning home” to command and control servers and more. This is all stuff that in years past required
an EXE or DLL. Now you can basically do
anything that a custom built EXE can do but without touching the file system
which so much of our current security technology is based on.
How do you prevent attacks like this? PowerShell has optional security restrictions
you can implement for preventing API access and limiting script execution to
signed script files. With WMI it’s not
as clear. Obviously all the normal
endpoint security technologies have a part to play.
But let’s focus on detection. It’s impossible to prevent everything and
mitigate every vulnerability. So we
can’t neglect detection. The challenge
with detecting attackers living off the land is 2 fold. The activities you need to monitor:
- Aren’t found in logs
- Are happening on client endpoints
Both of these create big challenges. Let’s talk about #1
first. A.N. Ananth and I describe the types
of activities that are clues to possible attacker living off the land in 5
Indicators of Evil on Windows Hosts using Endpoint Threat Detection and
Response and I encourage you to watch that session which is full of good
technical tips. But the point is that
the thing you need to watch for aren’t in the Windows security log or other
logs. Instead detection requires a
combination of file scanning, configuration checks, querying of running
processes and so on. All stuff that
requires code running on the local system or very powerful and complex remote
access. If we were only talking about servers
we could consider deploying an agent. But to catch todays threats you need to be monitoring where they begin
which is on client endpoints – the desktops and laptops of your employees. And there’s no way to remotely reach into
that many systems in real time even if you overcame the technical hurdles of
that kind of remote access. So that
leaves agents which always causes a degree of pushback.
But it’s time to stop calling them agents. Today what we need on endpoints are
sensors. It’s a subtle but important
shift in mindset. In the physical world,
everyone understand the need for sensors and that sensors have to deployed
where the condition is being monitored. If you want to know when someone enters your building at night you need
sensor on every door. Likewise, if you
want the earliest possible warning that your organizations have been
compromised you need a sensor on every endpoint.
So I encourage you to start thinking and speaking in terms
of leveraging your endpoints as a sensor rather than yet another system that
requires an agent. And look for
security vendors that get this. EventTracker has done a great job of evolving their agent into a
powerful and irreplaceable endpoint security agent that “see” things that are
just impossible any other way.
“This article by Randy Smith was originally published by EventTracker”
http://www.eventtracker.com/newsletters/catching-hackers-living-off-the-land-requires-more-than-just-logs/
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
Live with Dell at RSA 2015
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
How to Detect Low Level Permission Changes in Active Directory
Wed, 16 Dec 2015 09:26:50 GMT
We hear a lot about tracking privileged access today because
privileged users like Domain Admins can do a lot of damage but more importantly
if there accounts are compromised the attacker gets full control of your
environment.
In line with this concern, many security standards and
compliance documents recommend tracking changes to privileged groups like
Administrators, Domain Admins and Enterprise Admins in Windows and related
groups and roles in other applications and platforms.
But in some systems you can also granularly delegate
privileged access – ultimately giving someone the same level of authority as a
Domain Admins but “underneath the radar”. This is especially true in AD. This
capability is a double edged sword because it’s necessary if you are going to
implement least privilege but it also creates a way for privileged access to be
granted inadvertently or even maliciously in such a way that will go unnoticed
unless you are specifically looking for it. Here’s how:
First you need to enable “Audit Directory Service Changes”
on your domain controllers – probably using the Default Domain Controllers
Policy GPO.
Then open Active Directory Users and Computers and enable
Advanced Features under View. Next
select the root of the domain and open Properties. Navigate the Audit tab of the domain’s Advanced Security Settings dialog shown
below.
Add an entry for Everyone that audits “Modify permissions”
on all objects like the entry highlighted above. At this point domain controllers will record Event
ID 5136 whenever someone delegates authority of any object in the domain –
whether an entire OU or a single user account. Here’s an example event:
A directory service object was modified.
Subject:
Security ID: MTG\pad-rsmith
Account Name: pad-rsmith
Account Domain: MTG
Logon ID: 0x5061582
Directory
Service:
Name: mtg.local
Type: Active
Directory Domain Services
Object:
DN: OU=scratch,DC=mtg,DC=local
GUID: OU=scratch,DC=mtg,DC=local
Class: organizationalUnit
Attribute:
LDAP Display Name: nTSecurityDescriptor
Syntax (OID): 2.5.5.15
Value: …
Operation:
Type: Value Added
Correlation ID: {29fbbb83-5567-4935-9593-73496cc98461}
Application Correlation ID: -
This event tells you that a MTG\pad-rsmith (that’s me)
modified the permissions on the Scratch organizational unit in the MTG.local
domain. nTSecurityDescriptor and “Value Added” tell us
it was a permissions change. The Class
field tells the type of object and DN gives us the distinguished name of the
object whose permissions were changed. Subject tells us who made the change. I removed the lengthy text for Attribute Value because it’s too long to
display and it’s in SDDL format which isn’t really human readable without a
significant amount of effort. Technically it does provide you with the full content of the OU’s new
access control list (aka Security Descriptor) but it’s just not practical to
try to decode it. It’s probably going to
be faster to actually find the object in Active Directory Users and Computers
and view its security settings dialog via the GUI.
So the Security Log isn’t perfect but this method does give
you a comprehensive audit trail of all permission changes and delegation within
Active Directory. If you combine this
with group membership auditing you’ll have a full picture of all changes that
could impact privileged access in AD which is a key part of security and
compliance.
email this
•
digg
•
reddit
•
dzone
comments (0)
•
references (0)
Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
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™