Security, et al

Randy's Blog on Infosec and Other Stuff

5 Indicators of Endpoint Evil

Mon, 19 Sep 2016 16:16:12 GMT

With so much focus on security these days, you’d think IT would be winning the battle against malware and other threats. But all too often, a lack of focus on certain areas of the network leads to a decrease in an organization’s security posture and an increase in risk.

The endpoint is such an area. Endpoints have more than the ability to reach beyond the protective layers of internal security—they’re allowed to do so. End user behaviors such as working from outside the office, connecting to unsecured WiFi networks, visiting potentially dangerous websites, and opening email with malicious attachments or links all make endpoints a particularly vulnerable attack vector with access to your organization’s network.

According to a recent Ponemon report 80 percent of organizations are seeing web-born malware attacks. Sixty-five percent have experienced rootkit attacks and 55 percent have encountered spear phishing—all on a frequent basis.

And when malware and endpoints mix, the attack doesn’t stop with a single infected machine. Rather, that first infection turns the machine into what is commonly known as a beachhead. From there, malware is designed to spread laterally throughout your network, in an effort to maximize the chances of obtaining valuable credentials or data.

Although your thoughts might immediately go to attack mitigation and prevention, most organizations—a whopping 70 percent, according to the Ponemon study—have difficulty enforcing endpoint security policies. Rather, detection is a key aspect of any strategy. The best approach is to use the endpoint as a sensor, collecting state information, understanding which behavior is normal, and identifying what isn’t.

In this whitepaper, we focus on five trouble indicators, each of which provides additional context around what to look for on your endpoints:

  1. Rogue processes
  2. Evidence of persistence
  3. Suspicious traffic Activity and user-role mismatches
  4. Unusual OS artifacts

For each indicator, we tell you what to look for, as well as which tools you can use to identify and gather intelligence around the malicious code that might be lurking within your endpoints.

Indicator #1: Rogue Processes

Successful attackers depend on their malware to go undetected. After all, malicious remote administration tools (RATs) are designed to provide access to the command prompt, file system, registry, hardware, remote control, and more, with the purpose of providing many ways to find, extract, hold hostage, or destroy your organization’s critical information. If RATs were easy to find, the attack wouldn’t stand a chance—so attackers use several methods to obfuscate their presence.

Evil Methods

  • Process looks good … on the surface. The process name (such as explorer.exe) is right, but the parent process, logon user, or file path is incorrect. You need to look not just at the process in question, but also at the process that started it. If that process is not standard, it could indicate that the child process is a rogue process. Another method that attackers use is a clever misspelling of the file name. For example, a rogue file might be named scvhost.exe instead of svchost.exe—a spelling that is so close, you would probably need to compare file names to confirm the misspelling.
  • Suspicious DLL execution. Dynamic Link Libraries (DLLs) contain modular code to help support a main application. Attackers often take advantage of the fact that parts of the core Windows OS heavily utilize DLLs:
    • rundll32.exe. Known as a command line utility program, rundll32.exe is responsible for running DLLs by invoking a function that is exported from a specific 16-bit or 32-bit DLL module.
    • svchost.exe. Svchost is a generic Windows OS program that hosts approved Windows services. Malicious applications can be formed as DLLs specifically made to work with svchost.exe and trick it into running them.
    • Other legitimate processes. The use of DLLs is common, so rogue DLLs can also be loaded into an otherwise benign application.
  • Rootkits. These are nasty stuff. By definition, they take advantage of administrative (root) access, embed themselves into an OS, and then intelligently evade detection.

Regardless of the tactic used, the goal of rogue processes is either to make the process look legitimate or to use a legitimate process to launch a malicious DLL, making it more difficult to identify and track via the security log.

Detecting Rogue Processes

Ideally, you have a centralized way to collect relevant process information across your network and automatically identify rogue processes—capabilities that are available via solutions like EventTracker. Here is the kind of analysis required to catch rogue processes.

  • Analyze event ID 4688. This event is generated each time a new process is created. The event provides relevant information that you can use to identify rogue processes. As Figure 1 shows, this information includes the name of the user account that launched the process, the date and time the program started, the process ID, the parent (creator) process ID, and the full path of the process executable. 
  • Note: Although this event shows the Creator Process ID, there is no associated name or a full path to that process, which is an important piece in determining whether a process is rogue. The parent (creator)process can be determined by manually searching for an earlier 4688 event with a New Process ID that matches this Creator Process ID value.

    After enabling Audit process events via Group Policy, your endpoints will log a massive number of events, so although this is a valuable way to get information, you’ll also need to wade through a sea of data. Furthermore, the event is not generated when DLLs are loaded, only when new processes are started. So if the rogue process is a DLL hiding in a file such as svchost.exe, the event logs won’t contain any clue that it was invoked. However, after you identify something amiss on a given machine, memory forensics tools such as those from the Volatility Foundation can help provide further forensics detail when DLLs are injected or rootkits installed.

  • Check for unsigned code/Malware and viruses are often attached to legitimate executables from known or somewhat known entities. Program files that are signed declare the publisher and confirms that has not been modified by an attacker. Since unsigned files don’t have this assurance, unsigned code might indicate potential malware – you just can’t tell. Note that Windows 8 and earlier default to allowing unsigned code to run.

    Several tools can audit and analyze running processes on a machine. Although not enterprise-caliber tools, these can be useful in tracking down issues on a per-machine basis:

  • Check programs against the National Software Reference Library (NSRL). This library (available at http://www.nsrl.nist.gov) is a joint effort between the U.S. Department of Homeland Security; federal, state, and local law enforcement; and the National Institute of Standards and Technology (NIST) to collect software from various sources and incorporate file profiles into a reference library to be used in the investigation of crimes involving computers.

    At the end of the day, the trick to detecting rogue processes is to know what should and should not be running on your Windows endpoints. If you’re using a golden image, this exercise should be relatively simple: compare the running processes with a known list. But if every machine is somewhat different, you might need to start with a basic list of what should be running and then use the methods here to detect what falls out of the norm.

Detecting Rogue Processes with EventTracker

Even with the appropriate auditing policies turned on, you will need to do a fair amount of detective work to get a complete picture of which processes are running and whether they are rogue. EventTracker’s sensor collects pertinent information—including process, file, creator, hash, and signer details—and intelligently present it as a single event, as shown in Figure 2. This approach creates centralized details that are easily available for security information and event management (SIEM) solutions to digest and act on. 

In addition, other events, such as Exchange message tracking, provide critical details. In the example that Figure 3 shows, you can use the originating IP address, email subject, sender and recipient addresses, and more to identify how rogue processes might be entering the organization.

Moreover, EventTracker automatically compares program files against the National Software Reference Library, looks for unsigned code and alerts you to these and other suspicious indicators.

Indicator #2: Evidence of Persistence

An attacker doesn’t want to retain control of your endpoints for a short period; their malicious code needs ample time to permeate your network to give them the greatest chance of finding just the right credentials and give them access to valuable information. Attackers need to ensure that their code can live on so that they can resume control even after the closing of a process, a logoff, or a reboot.

Evil Methods

This list, though not exhaustive, represents many ways that attackers ensure their malicious code remains actively running and in existence on the endpoint.

  • Tasks. Use of the AT command or scheduling tasks to run every minute or at logon, can cause an endpoint to continually relaunch a malicious process.
  • Tampering with services. Replacing service path settings in the registry or replacing a service executable can launch malicious processes at boot up. In addition, new services are created with generic but official-looking names such as Windows Services Update, to throw you off the scent. MSInfo is a good starting point to identify those services that aren’t required.
  • Auto-run registry settings. The Run and RunOnce settings found in several locations in the registry are perfect places to nestle a reference to a malicious executable. MSInfo can play a role in identifying what is configured to launch at bootup and logon.
  • DLL tampering or interception. The basic premise is either to modify the DLL’s import table to reference a malicious function or to modify the DLL code itself to detour to your code and then return it to its normal function.
  • PowerShell background jobs. A PowerShell process is spawned in the background and runs the code necessary to keep the malicious process resident.
  • Local Group Policy. Group Policy contains a place to configure both startup scripts and logon scripts.
  • Browser add-ins and plug-ins. Browsers have the potential for a lot of local access to the endpoint, giving a browser the ability to re-infect a machine every time it is opened.

Detecting Persistence

Look to the same methods that attackers use der to find entries that are designed to guarantee persistence. Note: Many malicious processes use more than one method to redundantly ensure their survival. Finding references to a rogue process in any of these locations is a indicator that it might be malicious.

Indicator #3: Suspicious traffic

Malicious code on an endpoint doesn’t exist simply to sit there. It’s designed to replicate itself within the network and to ultimately exfiltrate information from the network. Therefore, traffic monitoring is another way to identify the existence of malicious code.

You might think that you can simply use your network monitoring sensors to pick up suspicious traffic. However, the reality is that you need additional context only available on the endpoint, such as the executable that is used to generate traffic, to ensure proper identification of suspicious activity.

Evil Methods

If you find the following on your endpoints, they could equate to suspicious network traffic:

  • Use of browser ports by non-browsers. Ports 80, 443, or 8080 should represent web services. Attackers use these ports to update code and exfiltrate data because the ports are always left open on your firewall. Network packets show you only which endpoint sent traffic over which port to which IP address; they won’t show that the traffic was a rogue DLL called by svchost.exe that was used to send data.
  • Use of browsers over non-standard ports. Any browser not using standard ports, such as 80, 443, or 8080, could indicate a valid process (your browsers) with a malicious purpose.
  • Unexpected traffic. Traffic might seem normal but become suspect when you consider either the source or the target. A few examples include web traffic to an IP address instead of a fully qualified domain name (FQDN); Remote Desktop Protocol (RDP), FTP (File Transfer Protocol), or Secure Shell (SSH) sessions from abnormal endpoints; and even outbound Simple Mail Transfer Protocol (SMTP) sessions to an external host.

Detecting Suspicious Traffic

As mentioned earlier, just using a network sensor lacks context. You need to know not only from which endpoint traffic originated, but also from which process. There are a few steps you can take to investigate suspicious traffic:

  • Monitor events 5154, 5155, 5156, and 5157. These events come from the Windows Filtering Platform (WFP) and help to document the permitting and blocking of inbound and outbound TCP or UDP connections. In each of these events, the process ID, application path, source and destination IP addresses, ports, and protocol are all documented, providing you context around whether the combination of processes and ports adds up to malicious or appropriate traffic.
  • Monitor outbound DNS requests for unusual domain names. What determines “unusual”? Use of a reputation service might be a good fit to help provide guidelines around appropriate domain names.
  • The overarching goal is to use the combination of traffic patterns, the processes that generate them and the type of endpoint to establish suspicion. Without a third-party solution, you’ll need to look granularly at specific endpoints, searching for these mismatches of processes and traffic patterns.

Indicator #4: Activity and User-Role Mismatches

An attacker will use any means necessary to spread malicious code laterally throughout the organization and exfiltrate data—even if it means doing so in a way that doesn’t fit the normal mode of operation for the user of the endpoint. Therefore, look for anomalies in which activity doesn’t align with the user’s role in the organization. For example, consider traffic for a given type of endpoint, such as an RDP session coming from the desktop of a user in Accounting. If their workstation has never started an RDP session in the past but suddenly does so now, you have a potential candidate for an infected endpoint.

Evil Methods

As suspicious traffic can be indicative of malicious code, so can the use of tools that are rarely, if ever, used by non-IT users:

  • Utilities. Many of the tools that IT considers foundational to configuring and supporting endpoints and networks are all but a foreign language to regular users. This list includes (but is not limited to) cmd.exe, rar.exe, at.exe, schtasks.exe, wmic.exe, powershell.exe, winrm.vbs, net.exe, reg.exe, sc.exe, netstat.exe, and route.exe
  • Remote sessions. We’ve talked about RDP from a traffic standpoint, but you should also watch for it from an activity standpoint. Normal users (except thin client and VDI users) usually have no need to connect to a server via RDP.
  • Unique mismatches in your environment. You should devote some time to comparing the usage difference between end-user and admin endpoints to determine which applications (via processes) they normally run to create a profile.

Detecting Activity and User-Role Mismatches

The simplest distinction to make is whether an endpoint is normally used by a user or someone in IT. But in your organization, the issue might be more complex than that; a user might be responsible for initiating managed file transfers as part of their job, so an FTP session might be in order. No matter the complexity of roles within your organization, identifying roles and their corresponding profile of activity is the first step.

Next, identify which applications are being used. This step is much more difficult to accomplish without at least a simple tool, such as the old Process Monitor from Systernals with output to a CSV file.

Indicator #5: Unusual OS Artifacts

It’s very difficult for attackers not leave some kind of trace in Windows of their presence. Knowing what to look for can help you catchattackers at any point in the process.

The point here is to search out things not normally found on end-user workstations. Here are a few examples:

  • Scripts. If PowerShell, VB Script, or even a command prompt was used to execute a command script, scripts might be left over, leaving clues as to what was executed.
  • RDP files. If RDP sessions have been used, files that define connection configurations might exist.
  • Shared folders on an endpoint. Because exfiltration of data is a large part of these attacks, simple shared folders might be used to centralize obtained files so that they can be exfiltrated from a single machine.
  • Shared folders access by an endpoint. Looking at the previous artifact from the other perspective, a given endpoint might have been used to connect to a central share. A review in the registry of the following key can provide more detail on which shares have been accessed: KEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Shining the Spotlight on Endpoint Evil

Endpoints are here to stay for most organizations and will continue to be a major risk area. Using the endpoint itself as a security sensor—one that can provide information, detail, and context of attempted breaches—can provide IT with the intelligence it requires to properly detect and respond to attacks.

Much of the work highlighted in this paper requires a massive amount of effort once you move past just a few endpoints. The only way to catch attackers using these methods is to automate and EventTracker is leading the way. EventTracker’s mature SIEM engine provides the centralized analysis and point of management needed to handle thousands of endpoints. Moreover, on the endpoint, EventTracker has advanced beyond the traditional SIEM agent. EventTracker empowers your endpoints as security sensors where you need them the most. Instead of just forwarding event logs, EventTrackers sensor-agent watches system activity in real-time on each and every endpoint looking for the indicators discussed in this paper. With EventTracker you get visibility and alerting to a depth and currency only possible with by leveraging agents on the endpoint.

ABOUT EVENTTRACKER

EventTracker offers a dynamic suite of award winning products for SIEM and event log management. SC Magazine BestBuy EventTracker Enterprise processes hundreds of millions of discrete log messages to deliver vital and actionable information, enabling organizations to identify and address security risks, improve IT security, and maintain regulatory compliance requirements with simplified audit functionality. Security Center offers instant security alerts and a real-time dashboard for viewing every incident in the infrastructure, and Compliance Center is a monitoring and early threat detection tool.

Complementing these products is SIEM Simplified(SM), our award winning services offering to augment IT resources in smaller enterprises. Our experienced staff assume responsibility for all SIEM-related tasks including daily incident reviews, daily/weekly log reviews, configuration assessments, incident investigation support and audit support.

Our customers span multiple sectors including financial, communications, scientific, healthcare, banking and government, with solutions currently deployed at over 850 global customer sites.

EventTracker was founded in 1999 and is privately funded and held. Our corporate headquarters are located in Columbia, Maryland in the Baltimore-Washington high tech corridor, with research and development facilities located in both Columbia and Bangalore, India. www.eventtracker.com

ABOUT RANDY FRANKLIN SMITH

Randy Franklin Smith is an internationally recognized expert on the security and control of Windows and AD security. Randy publishes www.UltimateWindowsSecurity.com and wrote The Windows Server 2008 Security Log Revealed—the only book devoted to the Windows security log. Randy is the creator of LOGbinder software, which makes cryptic application logs understandable and available to log-management and SIEM solutions. As a Certified Information Systems Auditor, Randy performs security reviews for clients ranging from small, privately held firms to Fortune 500 companies, national, and international organizations. Randy is also a Microsoft Security Most Valuable Professional.

DISCLAIMER & COPYRIGHT

Monterey Technology Group, Inc. and EventTracker make no claim that use of this white paper will assure a successful outcome. Readers use all information within this document at their own risk. Ultimate Windows Security is a division of Monterey Technology Group, Inc. ©2006-2016 Monterey Technology Group, Inc. All rights reserved.

This article by Randy Smith was originally published by EventTracker

http://www.eventtracker.com/webinars/top-5-indicators-of-evil-on-windows-hosts-endpoint-threat-detection-and-response/

email this digg reddit dzone
comments (0)references (0)

Related:
5 Indicators of Endpoint Evil
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
Live with Dell at RSA 2015

Detecting Ransomware: The Same as Detecting Any Kind of Malware?

Mon, 05 Sep 2016 13:02:22 GMT

Ransomware has burst onto the scene with high profile attacks against hospitals and other organizations. How do you detect ransomware? Ransomware is just another kind of malware and there’s nothing particularly advanced about ransomware compared to other malware.

Ransomware uses the same methods to initially infect an endpoint such as drive-by-downloads, phishing emails, etc. Then it generates necessary encryption keys, communicates with command and control servers and gets down to business encrypting every file on the compromised endpoint. Once that’s done it displays the ransom message and waits for the user to enter an unlock code purchased from the criminals. So at the initial stages of attack, trying to detect ransomware is like any other end-point based malware. You look for new EXEs and DLLs and other executable content like scripts. For this level of detection check out my earlier webinars with EventTracker

As criminals begin to move from consumer attacks to targeting the enterprise, we are going to see more lateral movement between systems as the attackers try to either encrypt enough endpoints or work their way across the network to one or more critical servers. In either case their attacks will take a little longer before they pull the trigger and display the ransom message because they need to encrypt enough end-user endpoints or at least one critical server to bring the organization to its knees. These attacks begin to look similar to a persistent data theft (aka APT) attack.

Detecting lateral movement requires watching for unusual connections between systems that typically don’t communicate with each other. You also want to watch for user accounts attempting to logon to systems they normally never access. Pass-the-Hash indicators tie in closely with later movement and that one of the things discussed in “Spotting the Adversary with Windows Event Log Monitoring: An Analysis of NSA Guidance”.

So much of monitoring for Ransomware is covered by the monitoring you do for any kind of malware as well as persistent data theft attacks. But what is different about Ransomware? Basically 2 things

  1. Detonation: The actually detonation of ransomware (file encryption) is a very loud and bright signal. There’s no way to miss it if you are watching.
  2. Speed: Enterprise ransomware attacks can potentially proceed much faster than data theft attacks.

Detonation

When ransomware begins encrypting files it’s going to generate a massive amount of file i/o – both read and write. It has to read every file and write every file back out in encrypted format. The write activity may occur on the same file if directly being re-written, the ransomware can delete the original file after writing out an encrypted copy. In addition, if you watch which files ransomware is opening you’ll see every file in each folder being opened one file after another for at least read access. You will also see that read activity in bytes should be matched by write activity.

Of course there are potential ways ransomware could cloak this activity by either going low and slow, encrypting files over many days or by scattering its file access between many different folders instead of following an orderly process of all files in one folder after another. But I think it will a long time before enough attacks are getting foiled by such detection techniques that the attackers go to this extra effort.

How prone to false positives is this tactic? Well, what other legitimate applications have a similar file i/o signature? I can't think of any. Backup and indexing programs would have a nearly identical file read signature but would lack the equal amount of write activity.

The downside to ransomware detonation monitoring is that detection means a ransomware attack is well underway. This is late stage notification.

Speed

Ransomware attacks against an enterprise may proceed much faster than persistent data theft attacks because data thieves have to find and gain access to the data that is not just confidential but also re-saleable or otherwise valuable to the attacker. That may take months. On the other hand, ransomware criminals just need to either:

  1. Lockdown at least one critical server – without which the organization can’t function. The server doesn’t necessarily need any confidential data nor need it be re-saleable. On a typical network there’s many more such critical servers than there are servers with data that’s valuable to the bad guy for re-sale or other exploitation.
  2. Forget servers and just spread to as many end-user endpoints as possible. If you encrypt enough endpoints and render them useless you can ransom the organization without compromising and servers at all. Endpoints are typically much easier to compromise because of their intimate exposure and processing of untrusted content and usage by less security savvy end-users among other reasons.

So beefing up your ransomware monitoring means doing what you hopefully are already doing: monitoring for indicators of any type of malware on your network and watching for signs of lateral movement between systems. But for ransomware you can also possibly detect late stage ransomware attacks by watching for signature file i/o by unusual processes. So you need to be fast in responding.

And that’s the other way that ransomware differentiates itself from data theft attacks: the need for speed. Ransomware attacks can potentially reach detonation much faster than data thieves can find, gain access and exfiltrate data worth stealing. So, while the indicators of compromise might be the same for most of all ransomware or persistent data theft attack, reducing your time-to-response is even more important with ransomware.

This article by Randy Smith was originally published by EventTracker

http://www.eventtracker.com/newsletters/detecting-ransomware/

email this digg reddit dzone
comments (0)references (0)

Related:
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Live with Dell at RSA 2015
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond

Cloud Security Starts at Home

Tue, 30 Aug 2016 10:28:14 GMT

Cloud security is getting attention and that’s as it should be. But before you get hung up on techie security details like whether SAML is more secure than OpenID Connect and the like, it’s good to take a step back. One of the tenets of information security is to follow the risk. Risk is largely a measure of damage and likelihood. When you are looking at different threats to the same cloud-based data then it becomes a function of the likelihood of those risks.

In the cloud we worry about the technology and the host of the cloud. Let’s focus on industrial-strength infrastructure and platform-as-a-service clouds like AWS and Azure. And let’s throw in O365 – it’s not infrastructure or platform but it’s scale and quality of hosting fits our purposes in terms of security and risk. I don’t have any special affection for any of the cloud providers but it’s a fact that they have the scale to do a better, more comprehensive, more active job on security that my little company does and I’m far from alone. This level of cloud doesn’t historically get hacked because of stupid operational mistakes or flimsy coding practices with cryptography and password handling. Or because of obscure vulnerabilities in standards like SAML and OpenID Connect (they are present). It’s because of tenant-vectored risks. Either poor security practices by the tenant’s admins or vulnerabilities in the tenant’s technology which the cloud is exposed to or on which it is reliant.

Here are just a few scenarios of cloud intrusions with a tenant origin vector

 

Tenant Vulnerability

Cloud Intrusion

1

Admin’s PC infected with malware

Cloud tenant admin password stolen

2

Tenant’s on-prem network penetrated

VPN connection between cloud and on-prem network

3

Tenant’s Active Directory unmonitored

Federation/synchronization with on-prem AD results in an on-prem admin’s account having privileged access to the cloud.


I’m going to focus on the latter scenario. The point is that most organizations integrate their cloud with their on-prem Active Directory and that’s as it should be. We hardly want to go back to the inefficient and insecure world of countless user accounts and passwords per person. We were able to largely reduce that of the years by bringing more and more on-prem apps, databases and systems online with Active Directory. Let’s not lose ground on that with the cloud.

But your greatest risk in the cloud might just be right under your nose here in AD on your local network. Do you monitor changes in Active Directory? Are you aware when there are failed logons or unusual logons to privileged accounts? And I’m not just talking about admin accounts. Really, just as important, are those user accounts who have access to the data that your security measures are all about. So that means identifying not just the IT groups in AD but also those groups which are used to entitle users to that important data. Very likely some of those groups are re-used in the cloud to entitle users there as well. Of course the same goes for the actual user accounts.

Even for those of us who can say our network isn’t connected by VPN or any direct connections (like ExpressRoute for Azure/O365) and there’s no federation or sync between our on-prem and cloud directories your on-prem, internal security efforts will make or break your security in the cloud and that’s simply because of #1. At some point your cloud admin has to connect to the cloud from some device. And if that device isn’t secure or the cloud admin’s credential handling is lax you’re in trouble.

That’s why I say that for most of us in the cloud need to first look inward for risks. Monitoring as always is key. The detective control you get with a well implemented and correctly used SIEM is incredible and often the only control you can deploy at key points, technologies or processes in your network.

"This article by Randy Smith was originally published by EventTracker."

 http://www.eventtracker.com/newsletters/cloud-security-starts-at-home/ 

email this digg reddit dzone
comments (0)references (0)

Related:
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
Live with Dell at RSA 2015

The Leftovers: A Data Recovery Study

Thu, 18 Aug 2016 08:17:08 GMT

I did a webinar a while back with Paul Henry on “What One Digital Forensics Expert Found On Hundreds of Hard Drives, iPhones and Android Devices” which was sponsored by Blancco Technology Group who makes really cool data erasure software for the enterprise.

Blancco has released a whitepaper, The Leftovers: A Data Recovery Study, based on the same work that Paul did. To demonstrate just how easy, common and dangerous it is when data is improperly removed before used electronics are resold, Blancco Technology Group purchased a total of 200 used hard disk drives and solid state drives from eBay and Craigslist in the first quarter of 2016.

Here are the top findings from their study:

  • 67 percent of the used hard disk drives and solid state drives hold personally identifiable information and 11 percent contain sensitive corporate data.
  • Upon analyzing the 200 used drives, company emails were recovered on 9 percent of the drives, followed by spreadsheets containing sales projections and product inventories (5 percent) and CRM records (1 percent).
  • 36 percent of the used HDDs/SSDs containing residual data had data improperly deleted from them by simply dragging files to the ‘Recycle Bin’ or using the basic delete button.

Check out the paper at  http://info.blancco.com/en-rs-leftovers-a-data-recovery-study?utm_source=ultimatewindowssecurity&utm_medium=blog&utm_campaign=UWS

email this digg reddit dzone
comments (0)references (0)

Related:
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
Live with Dell at RSA 2015

Keeping An Eye on Your Unix & Linux Privileged Accounts

Mon, 06 Jun 2016 10:27:03 GMT

With sudo you can give admins the authority they need without giving away root and all the security risks and compliance problems caused by doing so. But once you carefully delegate limited, privileged authority with sudo you still need an audit trail of what admins are doing. A privileged user audit trail is irreplaceable as a deterrent and detective control over admins and in terms of implementing basic accountability. But in today’s environment of advanced and persistent attackers you also need the ability to actively monitor privileged user activity for quick detection of suspicious events.

In this webinar, I'll dive into the logging capabilities of sudo. Sudo provides event auditing for tracking command execution by sudoers – both for successful and denied sudo requests as well as errors. I'll show you how to enable sudo auditing and how to control where it’s logged, if syslog is used and more importantly: what do sudo logs looks like and how do you interpret them?

But sudo also offers session auditing (aka the iolog) which allows you to capture entire sudo sessions including both input and output of commands executed through sudo whether in an interactive shell or via script. I'll demonstrate how to configure sudo session logging and how to view recorded sessions with sudoreplay.

After, BeyondTrust Product Manager, Paul Harper will walk you through how to augment sudo for complete control and auditing over Unix and Linux user activity.

Click here to register now!

email this digg reddit dzone
comments (0)references (0)

Related:
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
5 Indicators of Endpoint Evil
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond
Live with Dell at RSA 2015

Secure, Fast and Efficient Password Management

Mon, 23 May 2016 14:33:37 GMT

All the way back in the late 90’s I realized that passwords, even for myself, were a big vulnerability. With more websites requiring logins I realized that my multiplying “Post-It Note” situation was not going to work. This left me two options:

  1. A password protected word doc full of usernames and passwords.
  2. A unique username with one password used for all accounts.

You can easily see that neither of those two options were secure or viable. At that time especially, document encryption was either easy but way weak or strong but highly inconvenient. Besides who wants to copy and paste all the time? And then worry about your password sitting around in your clipboard? The risks go on and on. So as most InfoSec techies would do – I turned to Google. In those days a google search of “password manager” turned up much less results than the 48,000,000+ results you will get today.

After a bit of research, I decided to test a password manager product by RoboForm. Little did I know that 17 years later; using RoboForm would be a de facto standard at my company. I remember one of our contractors had his web-based email compromised and it took him half a day to login into each of his online accounts and change all his passwords since he was using one password for all accounts. He is now a RoboForm user.

RoboForm allows you to use unique usernames and unique passwords for each web login you have. It will actually help generate unique passwords using the character limits you specify and then save these complex passwords to your system under “lock and key”.

Fig 1. - Password requirement options

You only need to remember one unique master password to gain access to all of your RoboForm complex passwords. When you visit the logon page of a website, RoboForm automatically senses it and allows you to fill in your credentials with a single click. If your device is lost or stolen or malware compromises your computer, the files containing your credentials are encrypted with a key derived from your master password.

Fig 2. - A single click on the login named “Dev” will fill and submit the login

Of course we’ve seen over and over again that encryption is complex and programmers often do it wrong. I trust RoboForm’s encryption. They take a no compromise approach to security. The master password is not stored anywhere except your head; not locally and not on RoboForm’s servers. “RoboForm’s servers?” you ask? Yes, if you choose to use the feature, RoboForm uploads all your usernames and passwords to their server which then allows all your devices with RoboForm to share up-to-date credentials. This is called RoboForm Everywhere and it works awesome. Whether I’m on my desktop, Surface, smartphone or tablet I always have my passwords without sacrificing security.

You are probably asking, and rightly so, “How good is the protection in RoboForm’s ‘cloud’?” Well, first, you have a password on your RoboForm everywhere account – different than your master password which is used for encryption. But even if the RoboForm cloud is compromised (and we’ve already seen this happen to other password managers repeatedly) your credentials are still protected. RoboForm’s no-compromise approach on security means that they simply do not have your master password. Your credentials stored in the cloud are encrypted with the same key derived from your master password just like the files on your local Windows or mobile device. So memorize a good master password and don’t use it for anything else than RoboForm.

If you have a compatible finger-print reader and trust Windows security you can protect your master password with your fingerprint. To unlock RoboForm, you provide your fingerprint and avoid entering even your master password. Are their risks to that? Yes, but it’s up to you. You don’t have to use it.

RoboForm has a few products but everyone at my company uses RoboForm Everywhere which gives you the added benefit of syncing these passwords across multiple systems, mobile devices and tablets. RoboForm also has a built in browser which means no cumbersome copying and pasting of passwords on your mobile devices.

In 1980, password management wouldn’t have been an issue but nowadays, if you’re like me, you have a plethora of online user accounts, not to mention Windows Security popups which RoboForm also manages. Personally I have 500+ unique logins and this is only in my “Personal” folder (I keep my logins organized so I also have a “Work” folder).


Fig 3. – Roboform also manages Windows Security popups

I should also mention that RoboForm can manage identities if you choose to use it as well as financial info like banking details and credit card data which makes every merchant site payment process almost as user friendly and fast as Amazon. The Safenote feature is also very useful allowing you to secure and lockdown your virtual “Post-It Notes”.

I recommend that you give RoboForm a try.  You can get it completely free with a 10 saved login limit. If you are still in college you can actually get RoboForm completely free with unlimited logins. You can get the 1st year of RoboForm Everywhere 50% off by clicking here.

Stay tuned for another blog next month where I go in depth on a unique use case using RoboForm and some isolated servers we use for high security functions in our organization.

email this digg reddit dzone
comments (0)references (0)

Related:
Live with Dell at RSA 2015
5 Indicators of Endpoint Evil
Live with LogRhythm at RSA
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure

Get rid of QuickTime as Quickly and Efficiently – For FREE!

Mon, 25 Apr 2016 12:53:01 GMT

Hi folks.  If you are wondering how many computers on your network have QuickTime installed and how to get rid of it, I’ve got some help for you in the form of a video, PowerShell script, AppLocker policy and free tools from SolarWinds.  If you don’t already know why it’s urgent to uninstall QuickTime, be aware that Apple has announced it’s no longer supporting QuickTime for Windows even though TrendMicro has announced 2 zero-day heap corruption vulnerabilities that allow remote code execution.  According to my understanding of this, Apple never provided any warning that they’d stop patching their software.  That’s really lame.  You have to say this for Microsoft, they give you warning.  So every Windows endpoint with QuickTime installed is a sitting duck.  Even the Department of Homeland Security is warning folks to kill QuickTime before the bad guys exploit it against you and your network.

Barry and I have put together 2 videos:

1.  How to spend about 15 minutes with a trial download of SolarWinds Patch Manager to

a.  Quickly inventory all the endpoints with QuickTime installed

i.  We got the folks at SolarWinds to post a report on Thwack that reports all computers with QuickTime installed.

b.  Remotely un-install QuickTime from those PCs

c.  Without installing any agents!

2.  Or you can use AppLocker to block QuickTime from executing on PCs where it is installed

I recommend using the SolarWinds Patch Manager option because it’s fast, easy and free and it eliminates the risk by uninstalling QuickTime.  My alternative AppLocker procedure only blocks QuickTime; it doesn’t install it and it doesn’t address malware that knows how to bypass the Application Identity service.

If you are going to the 30-day trial of SolarWinds Patch Manager to remove QuickTime please use this URL to download it because that helps us keep the lights on here at UltimateWindowsSecurity.  And don’t worry, the good folks at SolarWinds are good with you using the eval to solve this problem.  You might want to keep Patch Manager once you see it.  After explaining how to use it to get rid of QuickTime I’ll explain why I like Patch Manager.

Download PatchManager and install it.  Watch Barry’s video to help you save time.  It only takes Barry 11 minutes to install Patch Manager, find all the PCs with QuickTime and uninstall it.  Follow along with Barry and you’ll be done in time to take the rest of the morning off. 

If you are interested in my alternative (and less secure) AppLocker method, watch this video.

Download Randy's Powershell Script here: http://tinyurl.com/ze2okye

Both methods work without agents!  But only Patch Manager actually eliminates the risk.  And the no agent thing is what I love about Patch Manager.  It provides software inventory and 3rd party patching (Adobe, Java, Apple, etc) without requiring you to install yet another agent.  How does it do it?  It’s pretty cool. Patch Manager uses WMI for querying PCs but then it leverages the already existing Windows Update agent baked into every Windows computer to push 3rd party patches and of course Microsoft patches too.  It does this through a really cool integration with WSUS. 

So you get the best of both worlds.  Leverage the built-in infrastructure Windows already provides for patching Microsoft products to patch 3rd party products too!  Brilliant.  Again, if you want to use Patch Manager for getting rid of QuickTime for free or just want to try it out, please use this URL.  It helps fund our research and real training for free we provide nearly each week.

email this digg reddit dzone
comments (0)references (0)

Related:
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Live with Dell at RSA 2015
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond

Certificates and Digitally Signed Applications: A Double Edged Sword

Mon, 11 Apr 2016 11:28:31 GMT

Windows supports the digitally signing of EXEs and other application files so that you can verify the provenance of software before it executes on your system. This is an important element in the defense against malware. When a software publisher like Adobe signs their application they use the private key associated with a certificate they’ve obtained from one of the major certification authorities like Verisign.

Later when you attempt to run a program Windows can check the file’s signature and verify that it was signed by Adobe and that its bits haven’t been tampered with such as by the insertion of malicious code.

Windows doesn’t enforce digital signatures or limit which publisher’s programs can execute by default but you can enable with AppLocker. As powerful as AppLocker potentially is, it is also complicated to set up except for environments with a very limited and standardized set of applications. You must create rules for at least every publisher whose code runs on your system.

The good news however is that AppLocker can also be activated in audit mode. And you can quickly set up a base set of allow rules by having AppLocker scan a sample system. The idea with running AppLocker in audit mode is that you then monitor the AppLocker event log for warnings about programs that failed to match any of the allow rules. This means the program has an invalid signature, was signed by a publisher you don’t trust or isn’t signed at all. The events you look for are 8003, 8006, 8021 and 8024 and these events are in the logs under AppLocker as shown here:

These events are described here https://technet.microsoft.com/en-us/library/ee844150(v=ws.10).aspx which is part of the AppLocker Technical Reference.

If you are going to use AppLocker in audit mode for detecting untrusted software remember that Windows logs these events on teach local system. So be sure you are using a SIEM with an efficient agent like EventTracker to collect these events or use Windows Event Forwarding.

There are some other issues to be aware of though with digitally signed applications and certificates. Certificates are part of a very complicated technology called Public Key Infrastructure (PKI). PKI has so many components and ties together so many different parties there is unfortunately a lot of room for error. Here’s a brief list of what has gone wrong in the past year or so with signed applications and the PKI that signatures depend on:

  1. Compromised code-signing server

    I’d said earlier that code signing allows you to make sure a program really came from the publisher and that it hasn’t been modified (tampered). But depends on how well publisher protects their private key. And unfortunately Adobe is a case in point. A while back some bad guys broke into Adobe’s network and eventually found their way to the very server Adobe uses to sign applications like Acrobat. They uploaded their own malware and signed it with Adobe’s code signing certificate’s private key and then proceeded to deploy that malware to target systems that graciously ran the program as a trusted Adobe application. How do you protect against publishers that get hacked? There’s only so much you can do. You can create stricter rules that limit execution to specific versions of known applications but of course that makes your policy much more fragile.

  2. Fraudulently obtained certificates

    Everything in PKI depends on the Certification Authority only issuing certificates after rigorously verifying the party purchasing the certificate is really who they way the are. This doesn’t always work. A pretty recent example is Spymel a piece of malware signed by a certificate DigiCert issued to a company called SBO Invest. What can you do here? Well, using something like AppLocker to limit software to known publishers does help in this case. Of course if the CA itself is hacked then you can’t trust any certificate issued by it. And that brings us to the next point.

  3. Untrustworthy CAs

    I’ve always been amazed at all the CA Windows trusts out of the box. It’s better than it used to be but at one time I remember that my Windows 2000 system automatically trusted certificates issued by some government agency of Peru. But you don’t have trust every CA Microsoft does. Trusted CAs are defined in the Trusted Root CAs store in the Certificates MMC snap-in and you can control the contents of this store centrally via group policy

  4. Insecure CAs from PC Vendors

    Late last year Dell made the headlines when it was discovered that they were shipping PCs with their own CA’s certificate in the Trusted Root store. This was so that drivers and other files signed by Dell would be trusted. That might have been OK but they mistakenly broke The Number One Rule in PKI. They failed to keep the private key private. That’s bad with any certificate let alone a CA’s root certificate. Specifically, Dell included the private key with the certificate. That allowed anyone that bought an affected Dell PC to sign their own custom malware with Dell’s private key and then once deployed on other affected Dell systems to run it with impunity since it appeared to be legit and from Dell.

So, certificates and code signing is far from perfect show me any security control that is. I really encourage you to try out AppLocker in audit mode and monitor the warnings it produces.  You won’t break any user experience, the performance impact hardly measurable and if you are monitoring those warnings you might just detect some malware the first time it executes instead of the 6 months or so that it takes on average.

This article by Randy Smith was originally published by EventTracker

http://www.eventtracker.com/newsletters/certificates-and-digitally-signed-applications-a-double-edged-sword/

email this digg reddit dzone
comments (0)references (0)

Related:
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
Live with Dell at RSA 2015

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:

  1. Aren’t found in logs
  2. 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
Live with Dell at RSA 2015
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Catching Hackers Living of the Land Requires More than Just Logs

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:
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
Live with Dell at RSA 2015

previous | next

powered by Bloget™

Search


Categories
Recent Blogs
Archive