Lockshell Devlog 1 - Logs

2023-12-10
 Lockshell Devlog #1

Currently working on revamping (really just implementing) the logs and the logging functonality on lockshell. There are a couple of things that make this task not trivial: time zones and handling both signals and user inputs. (Spoiler Alert: One had some successes, One is still (kinda) on the Scrum Board)

Time (Time Zones)

The reason time zones typically throw a wrench in plans, is because if you have 9:30, what does that mean exactly? AM or PM (for non-military US-based folks)? Then where it is 9:30, a 9:30 Eastern is not equal to a 9:30 Pacific. Leading us to time zones! If I see 9:30am ET, and 8:30am PT, surely I know that the 9:30am ET is before 8:30am PT. But if there is some mix-up with regard to how those logs are ingested, there could be a potential where the logs erroneously suggested that an instance of lockshell was triggered in the Pacific before the East. While this seems like an arbitrary thing to be cognizant about, the veracity of data and information is paramount when talking Security (or god-forbid an incident).

The fix here is to make one format this is synchronzied between all times zones. I decided it would be prudent to use the Unix epoch. Using the Unix epoch makes time diference calculations relatively trivial as well as having a ‘builtin’ time zone.

Logging Organization

While trying to create a completely robust logging system with signal handling and user input, it seemed prudent to split it into a 2 part system:

Session Logging (Little Picture)

Sessions being the where the replays are done. (So what are replays) If I were to type ls and then remove it before pressing enter the logs will have memory of it. Simply replay and session and voila! Threat Intelligence can be gleaned from the watching and learning about how the adversary functions.

General Logging (Big Picture)

General Logging is more for learning about multiple sessions, specifically when they started and where they are located on the system for replay.

Why?

Hypothetically, if I wanted to create a good feasibility study into the effectiveness of this experimental honeypot then I would need to create numerous geographically-diverse (and ip-diverse) deployments of lockshell. To add to the complexity, if I wanted to also ingest these logs on a SIEM or log aggregator and ensure the veracity of this data, preventing timezone conflicts and mucking up of analytics.

While an MVP has yet to be created when it comes to signal handling and user input, I think the current solutions works decently. It lists general logging (losh.log) and session logging (playback-<ID>-<TIME>.log). The 2 improvements that can be made to make it more robust are:

Resources