I Got 99 Problems But a Log Ain’t One

1.1 Introduction

Here at TrustedSec, one of the goals of the Tactical Awareness & Countermeasures (TAC) team is to assess and enhance our partners' security posture. Every organization benefits from improving and maintaining what could be considered security basics, such as centralized logging and user environment monitoring. Once collected, logs should invariably serve a purpose. The main goal for anyone logging for security should be to create logs that generate either a detection or an alert. Ideally, the logging should aid in investigations, enriching the responder’s understanding of the incident through the lens of collected data. This way, the logs will not only enable initial triage but also serve as indicators for incident response and content for threat hunting. I encourage you to check out the webinar hosted by Director of Security Intelligence Carlos Perez and Practice Lead of Attack Simulation & Detection Megan Nilsen that addressed some real-world examples of why and how to log for security. I’d also like to thank Carlos for offering his incident response knowledge in this post.

Personally, when seeking information about user activity, I prefer to collect logs from the system that is hosting that activity, such as Windows event logs and/or Sysmon logs. A popular choice for organizations that deploy endpoint detection and response (EDR) platforms is to use the telemetry collected from that platform as a substitute for the collection of endpoint logging. However, keep in mind that the data a security tool automatically collects is primarily for the benefit of the product and not necessarily the investigator. Further, the data that’s represented may not be as clear or as linear as it may first appear.

1.2 The Basics

A multitude of logs can be collected from various applications, systems, and devices. With vast amounts of data easily accessible, it can be tempting to collect all the logs and store them indefinitely, but this will undoubtedly end up being cumbersome and unsustainable. While the cost of collecting, storing, and querying logs in a SIEM varies by vendor, there is always a cost associated with logging even with homegrown solutions. As a matter of choice, we have to strategically collect logs to ensure that the benefits outweigh the cost associated with their collection and maintenance. Typically, the value to teams comes from the ratio of usage within collected events. While some logs may be used directly with correlation and logic to produce an alert/detection, others may provide investigative enrichment.

Endpoint-centric logs are not often collected. This is sometimes due to efforts being placed on critical servers and application environments.

As a user, you are the main threat vector for any attacker whose goal is to infiltrate a target network. Focusing your telemetry to be centered around looking for anomalous user activity can place you in a position to generate detections early in the attack chain, giving you a chance to disrupt an attacker.

Collected logs should focus on activity of users and even machines. This focus could be on authentication logs, file access, or even network traffic logs. The goal of logging should be to alert you swiftly whenever there might be anomalous activity in your environment. Subsequently, a defender should be able to use the logs to recreate the activity and movement in an investigation; this level of logging will benefit initial triage of an alert.

Collecting pertinent logs:

• Authentication
  • Success - 4624
  • Fail - 4625
• Activity
  • Process Execution
    • Windows - 4688
    • Sysmon - 1
  • Command or Script Invocation
    • PowerShell - 4104

1.3 Evolve

Being able to scale our visibility into user activity is a necessity in our goal of achieving the next level of defense capability. This can be achieved by looking for events such as file access logs, registry changes, and Kerberos logs allowing us to fill out the rest of a subject’s activity. Gathering further logs is not only a way to enrich investigations, but it can also benefit forensic reporting post-incident. These logs can further expand your alerting and detection capabilities, including anomalous scheduled task creations, user interactions with sensitive files, and suspicious service manipulation. You may be able detect this type of activity using process execution logs, but that would be more of a periphery detection than logging specifically for the actions being performed. However, the perspective of that detection would be that an attempt was made to perform that action through a command, which would not specifically tell you if the action was successful.

The goal of the logging with this particular perspective is primarily to recreate a user’s session on a machine solely on the available logging data. This can aid Incident Responders while they are working to discover the scope of the intrusion. In turn, the Incident Response team can report on this activity, perform forensics, and conduct remediation where needed.

Pertinent Logs:

• Local services manipulated
  • Windows
    • 4698 - Scheduled Task Created
    • 7040 - Service Changed
    • 7045 - Service Installed
  • Sysmon
    • 14 - Value set
    • 15 - Key/Value change
• Account Manipulation
  • 4720 - Account creation
  • 4735 - Security group modified
• Network Operations
  • 4768 - Kerberos TGT Request (DC Only)
  • 4769 - Kerberos Ticket Request (DC Only)
  • 4771 - Kerberos Pre-Auth Fail (DC Only)
  • 5145 - A network share object was checked for access
• Local file access
  • 4656 - Object handle requested

1.4 Ascend

Now that we can recreate what a user was doing on a system, we begin to fill out their entire behavior on the network. This would include network flow logging and web browsing activity. We can look at an entire user session and rebuild their activity in its entirety, including data transfers. This is a high maturity and intensive level of telemetry, and it is extremely easy to get buried in the amount of logs generated from the network traffic. However, forensically, they can be highly valuable and generate internal intelligence. As with any level or perspective of logging, anomaly detection and alerting can be instantiated with these logs as well. With network and web logging, early indicators of compromise (IOCs) can be discovered and give your security teams a head start on investigating potential incidents.

Using intelligence for malware domains and compromised sites, web logging can be used to alert on potentially risky web activity. From a network perspective, using an intrusion detection system (IDS) or intrusion prevention system (IPS) can help you discover potentially malicious data throughout your network. Outside of specific data, connections between machines can highlight anomalous or otherwise suspicious machine behavior, much like we discussed earlier with regard to anomalous authentication.

Pertinent logs:

• Firewall logs
• Netflow
• Web filter
• Application logs

Conclusion

With the abundance of options, technologies, and various solutions available for monitoring and detection, protecting your systems can seem complicated. However, implementing, strengthening, and maintaining the basics can go a long way! Implementing the basic activity monitoring in this blog will bolster capabilities and will enable teams to be effective across monitoring and detection, incident response, and even threat hunting.