Artifact Elements in an Alert

What it is

An alert is a bundle of artifacts, which are the small facts about an event, and reading them well tells you whether the alert matters.

Network artifacts include addresses, ports and web addresses. Host artifacts include processes, files, registry entries, system calls and hashes.

No single artifact decides the case. You combine them to describe who did what, to which system, and how.

How it works

Read each artifact for what it says, then check that the pieces agree.

IP addresses

An alert has a source address and a destination address. The source started the traffic, and the destination received it.

Check whether each address is internal or external, and whether it is on a threat intelligence list. An internal source talking to a known bad external destination suggests a compromised host. An external source probing an internal server suggests scanning or attack.

Remember that NAT and proxies can hide the real address, so the alert may show the translated one.

Client and server ports

The server port is the well known service port, such as 80, 443, 53 or 22. The client port is a high number that the client picks for that connection.

The server port tells you what service was used. A service on an unexpected port, such as web traffic on a high port, or a connection to a rarely used port, deserves a look. Direction matters, since the server port is normally on the destination side.

Process, file or registry

On a host, the key question is what program caused the activity.

A suspicious pattern is an unexpected parent and child relationship. A word processor that starts a command shell is far more worrying than a shell started by an administrator. A program running from a temporary folder, or named like a system file but in the wrong folder, is also suspect.

System API calls

Programs ask the operating system to do things through API calls. Some call patterns point to malicious intent.

• Writing code into another process suggests injection.
• Creating a remote thread or changing memory permissions can suggest an exploit or shellcode.
• Hooking keyboard input suggests a keylogger.
• Creating files in startup locations suggests persistence.
• Opening many files and writing encrypted copies suggests ransomware.

Sandboxes and endpoint tools list these calls. An analyst reads them as a summary of behaviour.

Hashes

A file hash identifies a file. Check it against threat intelligence, and search for it on other hosts. A known bad hash is a strong indicator, and an unknown hash needs more work, because a small change to a file gives a new hash.

URI and URL

A URL is a full web address. A URI identifies a resource, and in practice the path and query part of the request is often called the URI.

Host: files.example.test
Request URI: /download/update.exe?id=4821

Look at the host, the path and the file type. A download of an executable from an unfamiliar host is a concern. Random looking names, very long query strings and encoded characters can show an attack or a command and control address.

Putting it together

Take an alert that shows host 10.1.1.25 contacting 203.0.113.50 on port 8080. The host log shows a process called svchost.exe running from a user temporary folder, with a parent of winword.exe. The URL requested was an executable file, and its hash matches a known malware sample.

The artifacts agree. An internal host contacted an external server, a document opened a disguised program, and the file is known bad. This is a confirmed compromise, so the host should be isolated.