SOC Analyst 101 Part 1: Security Models & Logs

This is part 1 of the SOC Analyst 101 blog series. If you have not, please make sure to read the previous primer post “SOC Analyst 101 Part 0: Overview & Prerequisites”. At this point you have determined that you would like to further pursue a career as a SOC Analyst. You might have gained a few certifications, made a network HomeLab, and/or worked through some other educational resources. You should have a solid understanding of Windows, Linux, networking, Active Directory, security concepts, and malware triage. This includes knowing what defense in depth means and how common attacks are conducted, like phishing and payloads. Now with this foundational understanding, we can move onto what a SOC Analyst will be doing.

Security Models

Cybersecurity includes many conceptual models that help provide a clearer understanding of the given topic. Below are some of the most useful models for a SOC Analyst to understand. Some of these models like the Kill Chain, are beneficial to keep in mind when triaging detections. These models will be referred to through the rest of the blog series.

Incident Response Lifecycle

The incident response lifecycle has 4 main phases that break down what the acts of incident response entails. As a SOC analyst, you will mostly be focusing on the “Detection and Analysis” phase and the “Containment Eradication & Recovery” phase in day-to-day work. I recommend reading the PDF below from NIST as it explained this in detail.

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf

(Page 21)

CIA Triad

CIA Triad (Source: Black Kite)

The CIA Triad as pictured above, is a key concept in information security. The CIA Triad contains 3 attributes that is your main objective of maintaining as a SOC Analyst. Let’s break these concepts down with some examples-

Confidentiality

Confidentiality is that information that should be protected or kept private, remains so. Going back to our metaphor from the previous post where we are tasked with protecting Jewels at “Crown Jewels Inc.”, one example is that we must protect our database that stores all the customers that have their jewels stored at our facility. If this database was to be compromised, a jewel thief could try to login and request a customer’s jewels to be transferred. A real-world example of this could be a threat actor exfiltrating sensitive data.

Integrity

Integrity is the practice of maintaining the accuracy and completeness of data. Let’s say on our website for “Crown Jewels Inc.”, a jewel thief was able to modify the pricing of a diamond to be $0 when purchasing it. A real-world example of this could be a threat actor wiping logs that could have helped an analyst with identifying an attack.

Availability

Availability is maintaining access to information or systems when they are needed. For our job of protecting the jewels, an example would be that our customers can access their jewel vaults when they desire. A real-world example of this is the use of Ransomware, which is a malware type that locks down systems and the company is extorted for the systems to be unlocked.

IOCs

IOC is an acronym for “Indicator of Compromise”. These can be various artifacts but are commonly associated with known malicious IP addresses, URLs, and hash values. An analyst can use this information to conduct searches across the environment. For example, let’s say malware is executing on a system and we are fortunate enough to see it using PowerShell to contact a URL, such as “badmalware[.]com”. We can then search for this URL to see if any devices have connected to it and determine those systems to be compromised. There are 3 main types of IOCs-

Atomic

This IOC cannot be broken down further and is a static indicator, such as an IP address, filename, email address, or domain name.

Computed

This IOC is derived from computed data, such as a hash value or regex.

Behavioral

This is pairing logic with a collection of one or more Computed or Atomic IOCs. An example could be “the threat actor sent an email containing an attachment with the hash value of dfe64f658a94da5cd2e96c20b23b4471 that when executed contacted the domain badmalware[.]com”. This contains the hash value that is a computed indicator and the domain which is an atomic indicator.

Pyramid of Pain

Pyramid of pain

The pyramid of pain is a conceptual model that aids in identifying malicious activity, the higher up the pyramid is the more “pain” it causes the adversary. In the end, cyber-attacks are caused by people and people are creatures of habit, especially when a desired outcome is achieved. This means that behavior is much harder to change as it requires time, money, and training. Compared to something like a hash value or an IP address which is much easier to change. For example, let’s say a jewel thief breaks into our building and we see them dressed in black clothes with a ski mask, it is much easier to identify them as a threat but is easier for the thief to change. Now let’s say the thief is known for picking locks on doors to gain entry, but we have an alarm that goes off when a door is opened when armed. This now forces the thief to learn how to break into our building in a different manner.

Kill Chain

Kill Chain (Source: Lockheed Martin)

The Kill Chain is a concept that was developed by Lockheed Martin and aids in identifying an attack and at what stage the attack is at. Most cyber-attacks have a goal in mind (some are just done out of curiosity) and this model can help us understand how close to the goal the adversary is and give us a clue to what may happened prior. Let’s break this down with our example or protecting a bank that houses expensive jewels-

Recon

The jewel thief performs a “stake out” and observes what our security looks like such as guard patrols or what types of security products we use (passive recon). The thief may try to see what doors are locked, which are open, and which he could exploit (active recon).

This is like an attacker utilizing tools such as Shodan, Google Dorking, and NMAP.

Weaponization

The thief will gather necessary tools to exploit vulnerable doors or other openings. The thief may try to create his own custom tools.

This stage is how an adversary will determine which malware type and payloads to utilize, this can also include what exploits to use on a public facing application.

Delivery

The thief uses his determined method of transportation to get to our facility to begin the attack, whether it be by car, bike, or maybe a helicopter.

This stage is the actual transportation and delivery of the attacker payload. This could be by phishing, web attack, USB, or some other protocol.

Exploitation

This stage involves the thief performing the exploitation to gain entry to our facility. Examples of this could be social engineering an employee or picking a vulnerable lock.

This stage involves the payload exploitation or social engineering tactic being conducted. An example of this could be calling a help desk person to reset an accounts password to gain access or delivering a malicious payload over email that executes when the recipient downloads the attachment and runs it.

Installation

This stage is the thief gaining a foothold to the facility and securing his/her position. This could be making sure the door they picked does not lock again so they can maintain access.

Once a malicious payload is executed, this is the installation of the “backdoor” for the attacker to maintain access. Whether it is a public exploit that calls back to the attacker infrastructure or the phishing payload downloading a second stage payload that then performs the connection (see staged vs stageless payloads).

Command and Control

Once a thief has secured access to the facility, the stage is the communication channels with accomplices for the heist to continue the exploitation of our facility until the goal of gaining access to our “crown jewels” vault is achieved.

This stage of exploitation is also referred to “hands on keyboard” (HOK) activity. This means that the payload that executed connected to the attacker’s infrastructure and now allows access to the target machine. The next actions performed at this stage is usually conducting enumeration of the system that was exploited and other machines it is connected to. An attacker will then try to conduct lateral movement to transverse a network to other hosts the compromised machine has direct access to and/or conduct pivoting to gain access to segmented networks.

Actions on Objective

Once the thief has gained access to the vault, the thief then steals our crown jewels.

Once an adversary has gained access to the desired information; a user’s host or a server with sensitive information, the adversary will then exfiltrate this information.

It is very useful for an analyst to know which part of the kill chain he/she is investigating as it can provide insight of what may have occurred prior and will occur next. Then an analyst can conduct forecasting to search for this previous or next step of the kill chain (this will be covered more later). You may also hear the term “detect left”, this means the act of setting up detections that can catch malicious activity earlier in the kill chain before exploitation has occurred.

MITRE ATT&CK

https://attack.mitre.org/

The MITRE ATT&CK framework contains adversary tactics, techniques, and procedures (TTPs) in relation to the kill chain. The tactics are mapped across the top of the matrix and represent the adversary’s goal (I.e initial access). The technique is below the tactic and is a method of how to accomplish this goal (I.e drive by compromise). The procedure is the steps conducted to execute this technique (I.e exploiting known safe sites to host malware). This framework allows an analyst to research further at what point a detection occurred on the kill chain and understand the conducted technique. This also allows an analyst to easier communicate what has been observed in a report as MITRE ATT&CK contains IDs for each of the TTPs, but this will be covered more Indepth later.

Logs Explained

Computer Logging

(Source: Pearson)

Logging is the act of “keeping log” of events that have occurred or have been observed by a system. This can include login events, process executions, network logs, and more. These logs are then forwarded to a SIEM (Security Information and Event Management) server that normalizes and correlates these logs. These logs can then be matched to rules within the SIEM that creates an alert when the rule logic is matched. A SOC analyst can then conduct searches within the SIEM to view logs to search for malicious behavior.

The ability to determine malicious behavior from logs is a skill on its own. There is no log that will clearly say “This is malicious!” or “This is a false positive!”, this is determined by the analyst from the available information. There are many SIEM solutions available, but a SIEM is only as good as the analyst who is using it. Later we will cover this skill in detail but for now we will cover a few available log sources an analyst will use. It is also important to note that logs can only be used to find information if they are available; meaning the system is set up to perform logging and forwarding or a logging service is present to begin with. An example of this is a network could be logging firewall events, but a host of interest is not setup to generate and forward logs which causes a gap in our visibility.

Windows Logs

This logging is at the host level, meaning that the machine itself is logging what is occurring. For example, the Windows event ID 4624 is for the event “An account was successfully logged on” and the event ID 4625 “An account failed to log on”. Information of programs being executed can be observed with the event ID 4688 “A new process has been created”. With this information we can look for behavior occurring on the host itself or how the host is interacting with other machines in the environment. An example of what a SOC Analyst will be reading-

A new process has been created.
Creator Subject:

Security ID: SYSTEM

Account Name: RFSH$

Account Domain: LAB

Logon ID: 0x3E7

Target Subject:

Security ID: LAB\rsmith

Account Name: rsmith

Account Domain: LAB

Logon ID: 0x2C9D82

Process Information:

New Process ID: 0x2e0e4

New Process Name: C:\Windows\System32\RuntimeBroker.exe

Token Elevation Type: %%1938

Mandatory Label: Mandatory Label\Medium Mandatory Level

Creator Process ID: 0x268

Creator Process Name: C:\Windows\System32\svchostt.exe

Process Command Line:

Resources

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-auditing-faq

Linux Logs

SOC Analysts should also know about Nix operating system’s; including command lines, access control, and more. This is because an analyst will also be utilizing logs from these systems to determine if the behavior is malicious and if an analyst does not know about these operating systems, then this will be very difficult to understand, especially since Nix logs can be sparse.

An example log an analyst will be reading-

Jun 4 22:14:15 server1 sshd[41458] : Failed password for root from 10[.]0[.]2[.]2 port 22 ssh2

Resources

https://www.crowdstrike.com/guides/linux-logging/

https://linuxhandbook.com/syslog-guide/

https://docs.secureauth.com/0903/en/how-to-read-a-syslog-message.html

Firewall Logs

Firewall logs can be intimidating at first since they can contain a large amount of information in one log message. These logs are very useful for observing the network behavior of an endpoint and can be leveraged when an IOC is found to search for connections that have occurred. Below is a example log message in Palo Alto format-

2023-10-19 16:45:22,TRAFFIC,ethernet1/1,192[.]168[.]1[.]100,203[.]0[.]113[.]45,ethernet1/2,Allowed,,web-browsing,2921,5147,7777,0x20,tcp,allow,200,144,72,10,2023-10-19 16:45:21,1178,1,2,445864586,0x80,US,DefaultTrust-L3-In,web-server,2,203[.]0[.]113[.]45,1[.]2[.]3[.]4,0,0,0,0,,0,0,0,0,,<Not Applicable>,<Not Applicable>,0,0,0,0,,0,0,0,192[.]168[.]1[.]100,203[.]0[.]113[.]45,0,DefaultTrust,0,1145,0,0,,,0,,web-browsing,

Resources

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslog-field-descriptions

https://www.ciscopress.com/articles/article.asp?p=424447&seqNum=4

https://support.checkpoint.com/results/sk/sk144192

Web Proxy Logs

Web proxy logs collect web browsing information from a system. This is useful to determine the source of a malicious download or when command and control is conducted over HTTP/S. Here is a Palo Alto URL filtering log example-

2023-10-19 14:30:45,TRAFFIC,ethernet1/1,192.168.1.100,example.com,ethernet1/2,Allowed,URL Filtering,web-browsing,2921,5147,7777,0x20,tcp,allow,200,144,72,10,2023-10-19 14:30:44,1178,1,2,445864586,0x80,US,DefaultTrust-L3-In,web-server,2,example.com,1.2.3.4,0,0,0,0,,0,0,0,0,,Clean,NameOfURLCategory,0,0,0,0,,0,0,0

Resources

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/monitoring/use-syslog-for-monitoring/syslog-field-descriptions/url-filtering-log-fields

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm5hCAC

https://www.websense.com/content/support/library/deployctr/v76/dic_ds_work_w_prxs.aspx

Other Log Types

IDS/IPS

These logs will create signatures dependent on behavior. These signatures can be signs of malicious activity occurring. Snort log example-

[**] [1:2023:4] ICMP PING NMAP [**]

[Classification: (Potentially Bad Traffic)] [Priority: 2] 10/19-14:30:45.678901 192[.]168.1.100 -> 203[.]0.113.45 ICMP TTL:128 TOS:0x0 ID:1234 IpLen:20 DgmLen:84 DF Type:8 Code:0 ID:1234 Seq:5678 ECHO

Snort

https://www.snort.org/rule_docs?utf8=%E2%9C%93&search_type=standard&simple_search%5Bsid_or_explanation_or_message_or_cves_cve_key_i_cont%5D=&submit_rule_search=

(search keywords like malware)

Suricata

https://docs.suricata.io/en/suricata-6.0.0/rules/intro.html

Zeek

https://docs.zeek.org/en/master/frameworks/signatures.html

Email

These logs are useful for an analyst to extract artifacts from to determine the scope of the phish event by determining total recipients. Proofpoint log example-

2023-10-19 09:45:30, email-security, Proofpoint Protection Server, Inbound, Clean, Pass, smtp.inbound.example[.]com, recipient@example[.]com, sender@external.com, Subject: Important Document, File: attachment.pdf

ProofPoint

https://help.proofpoint.com/Proofpoint_Essentials/Administrator_Topics/110_logs/Understanding_Email_Logs

These are some of the logging tools available for a SOC analyst. Remember that you can only search on information that is available, meaning that the logging is set up, a device creates the log, and it is being collected or a device is sitting between hosts (such as an IDS/IPS).

Using Logs Example

Combining all the information from above, let’s go over a quick example. Let’s say we get an alert for a malicious email with ProofPoint-

2023-10-19 14:50:12, email-security, Proofpoint Protection Server, Inbound, Malicious, Blocked, smtp.inbound.example[.]com, recipient@example[.]com, sender@malicious[.]com, Subject: Urgent Invoice, File: malicious_attachment.exe, Threat Type: Malware

From the log above we know to investigate the context of the log further, including the sender domain and attachment. Sometimes the log will contain a hash value of the attachment that we can look up on Virus Total as well. From here we can pivot onto the host logs for observations of the executable “malicious_attachment.exe” running. We find the following Windows Log by searching on for process execution events with the attachment-

Log Name: Security  

Source: Microsoft-Windows-Security-Auditing

Date: 2023-10-19 14:56:15

Event ID: 4688

Task Category: Process Creation

Level: Information

Keywords: Audit Success

User: N/A

Computer: MyComputer.example.com

Description:

A new process has been created.

Creator Subject:

Security ID: NT AUTHORITY\SYSTEM

Account Name: SYSTEM

Account Domain: NT AUTHORITY

Logon ID: 0x3E7

New Process:

Security ID: NT AUTHORITY\SYSTEM

Account Name: SYSTEM

Account Domain: NT AUTHORITY

Logon ID: 0x3E7

Process ID: 0x1234

Image File Name: C:\Path\To\malicious\_attachment.exe

Command Line: "C:\Path\To\malicious\_attachment.exe"

From the log above we can say that the user downloaded the file and ran the executable (at SYSTEM level!). From here we searched with the hostname for network and web proxy events within minutes after the process execution and observed the following-

2023-10-19 14:56:15,TRAFFIC,ethernet1/1,192.168.1.100,fake-malicious-site[.]com,ethernet1/2,Allowed,URL Filtering,web-browsing,2921,5147,7777,0x20,tcp,deny,418,0,0,0,2023-10-19 16:20:14,1178,1,2,445864586,0x80,US,DefaultTrust-L3-In,web-server,2,fake-malicious-site[.]com,1.2.3.4,0,0,0,0,,0,0,0,0,,Malicious URL,Command and Control,0,0,0,0,,0,0,0,192.168.1.100,fake-malicious-site[.]com,0,DefaultTrust,0,1145,0,0,,,0,,web-browsing,

Finding the log above we determined that the file was executed successfully, and an outbound connection was made to the URL fake-malicious-site[.]com. Now at this point we have enough evidence to determine this to be a true positive event and can move to the remediation step of the IR lifecycle. We can also move onto the lessons learned step and try to use security controls to mitigate this from happening again. This can be asking questions like “Why was the email not blocked?”, “How did the file execute successfully?”, “Can we educate our users on this?”, “How can we make sure domains like this are blocked?”. These questions can then be used as an avenue to make sure security controls are set up properly to prevent this from occurring again. This is the art of creating a story from plain text log messages and as a SOC Analyst you will be doing daily.

Your Homework

Your homework is to dive into the use of security tools like logging and using a SIEM. Your objective is to be able to read logs and know what the event means. This is vital in determining if something is false positive or true positive which we will cover in the future.