For the past several years I have operated a variety of deception operations, including several flavours of honeypot. I've always struggled with being able to find an off-the-shelf solution that meets my analytic requirements, or have found potential solutions having flaws that - over time - deemed them impractical.

During the NZ lockdown I was faced an opportunity to learn more about Azure Sentinel to meet growing customer demand for it, so I began my learnings by onboarding several hosts to my Sentinel instance where I'd set up the parser, workbooks and analytics rules from the Sentinel ATT&CK project. It was this project that very quickly inspired me to migrate my honeypots from a basic ELK stack to Sentinel.

What it does

The solution consists of two main components:

  • Windows honeypot workbook: this ingests Windows security, IIS and sysmon logs to report on authentication, user and system events.
  • Linux honeypot workbook: this ingests JSON logs from the Cowrie SSH+telnet honeypot and access logs from a Dockerised Apache server via custom parsers to report on authentication, user, system and web activity.

Key data points can be further analysed via parameters in the workbook, meaning analysts don't need to jump between several workbooks to make multiple queries to answer questions.

Build documentation accompanies both workbooks to ensure that honeypots are set up and managed in a safe manner, so not to expose their operator to any undue risk.

How I built it

Workbooks: I began by listing the insights I wanted to make (e.g. geographic trends, new RDP and web exploits) and what data that would serve as valuable intelligence. Based on this I determined what event types had to be collected, what the relationships between event types were and what workflow could be developed. For example: a successful authentication involves an account signing on and therefore that account name is a parameter that can be used to filter sysmon events.

Parser: Once I discovered how to ingest the Cowrie JSON log I generated a spectrum of events by interacting with the honeypot. I gathered one of each event type and mapped out their key values, resulting in a list of required event definitions. I certainly ran into some challenges with this one that I'll describe below.

Challenges I ran into

I faced two main challenges:

  • Escaping backslashes in usernames so they can be passed as a value from multi-select dropdowns. While a single value can be easily escaped in the destination query by defining it as a literal (i.e. preceding it with an @ symbol), when multiple values are passed the query is broken if the username is of the format username\domain. This was resolved by escaping the names in the dropdown (as seen in this commit).
  • I wasn't aware that the OMS agent could be configured to tail any log on a system, so spent several hours writing regex to form a parser for Cowrie syslog output. After struggling to consistently parse the logs I turned to Microsoft documentation and learned of the custom log, making parsing much, much easier by allowing me to tail the Cowrie JSON log.

Accomplishments that I'm proud of

I'm very proud that I've achieved what I set out to do in such a short space of time (~1 month), and am yet to encounter something that I've wanted to do that I can't be done. Honeypot reporting is potentially something that Microsoft didn't specifically have in mind when Sentinel was conceived, and I definitely believe this speaks to the flexibility and capability of Azure Sentinel.

What I learned

Prior to this project I had a very loose understanding of how the various components of Sentinel can work together to help develop extremely efficient analyst workflows. Now I have far more confidence to speak to the capability of Sentinel and support this with experience.

What's next for Sentinel Honeypot Reporting

Like most of my projects, both honeypot workbooks will be continually developed. Next I plan to develop accompanying analytics rules and Logic Apps to automatically push custom indicators to:

  • MISP.
  • Firewall and Defender ATP blocklists.

Built With

  • azure-sentinel
  • cowrie
  • sysmon
Share this project: