Moving further to another topic.
After a system has been compromised,
attackers will maintain control via command and control communications channel,
also known as a C2.
The backdoor installed on the compromised system will
periodically check in for additional commands with the
server controlled by the attacker.
This is also known as beaconing.
Command and control can be established over legitimate protocols and services,
so detecting this efficiently is not an easy task.
To form a better idea, let's consider the following beacon characteristics.
When we take into account normal traffic, this is irregular.
High quantities of data are transferred when the user
visits websites or watches online content.
When the user doesn't do that,
there isn't much traffic generated apart from the background services.
Beaconing will make connections at regular intervals.
These connections are consistent in terms of size;
and depending on the protocol,
all of the heartbeats may be part of a single connection.
There is also the concept of jitter.
For more advanced backdoors, in order to prevent detection,
there is a random delay introduced after each beacon.
The proposed approach to detect possible beaconing
activity is based on two numbers.
The first one is the duration of the connection,
as some backdoors will keep a TCP connection open for a long
period of time until it receives more commands.
The second number that we're looking for is the number of HTTP requests.
And while this may be difficult to extract from HTTPS traffic,
organizations may have in place SSL termination proxies,
which might capture this data for unknown domains.
While this is not a definitive solution,
it's meant to generate some high‑quality data where a
security analyst might investigate it further to give him
or her the right tools for hunting.
Zeek log files are quite interesting mainly due to
the existence of the UID field.
This can be used to correlate the activity between the
connection log and the other log files.
For example, for a DNS request logged into the dns.log file,
there'll be one entry in the conn log which identifies the connection
between the source and destination on port 53 UDP.
To identify the number of HTTP requests between the
compromised machine and the attacker machine we need to
aggregate HTTP logs based on the UID.
An important data structure that we'll be making use of is a Counter dictionary.
This is part of the collections module.
A counter will essentially keep a count of how many
times a key exists in an array.
In this example, aws.com appears twice, while google.com appears only once,
so the counter values will reflect this.
We'll be making use of this Counter dictionary in multiple demos.
One important aspect is that even for updating the counter with a single key,
this has to be passed as a one item array.
In case a string is passed directly to the update function,
this will be treated as an array in itself and the occurrence
for each letter will be calculated instead.