LOLBAS: Log-Oriented Leakage Breaking Advanced Security

Introduction

In today’s digital age, where the computational power of computers continues to increase, using complex passwords is essential to prevent them from being cracked by brute-force attacks. However, managing such passwords can be a daunting task. In this context, password managers have become indispensable tools for securely storing and generating strong passwords. They also protect against the risks of storing passwords in a simple text file on the desktop, which could easily be compromised by an attacker. By handling password management for us, these tools ensure our security and allow us to use strong, difficult-to-guess passwords without the need to remember them, as the password manager takes on this responsibility for us.

Nowadays, the laziness is highly valued. This is where clipboard managers come into play, offering great utility for everyday tasks by storing a history of copied items, making it easy to retrieve frequently used data such as text snippets, links, or files. However, in prioritizing convenience, we often overlook a crucial aspect: passwords are also stored in the clipboard. While this reduces the effort of copying and pasting passwords repeatedly, it can also introduce potential security risks, as sensitive information may become vulnerable to unauthorized access.

In this exploration, we’ll examine how the combination of clipboard managers and log files used mainly for troubleshooting problem can simplify the process of compromising passwords. By capturing the stored data, attackers can bypass the complexities of brute-force attacks, as the passwords are already exposed through clipboard logs, eliminating the need for guessing or cracking them.

Background and Preliminaries

To fully grasp the interplay between clipboard managers, password managers, and readily accessible sources, it’s essential to first understand the distinct roles each of these tools plays.

Password manager

Password managers have long been a fundamental tool in maintaining digital security, offering users the ability to generate, store, and autofill complex passwords. These tools provide a critical layer of protection in a digital environment where managing multiple, unique passwords is increasingly important but practically impossible to do manually. In scenarios where users frequently log in to different services, update passwords regularly, or need to retrieve login credentials quickly, remembering a multitude of complex passwords becomes unfeasible.

To address these challenges, we have chosen to use Bitwarden, a highly regarded password manager. According to its official website, Bitwarden is described as “the best password manager for securely storing, managing, and sharing sensitive online data such as passwords, passkeys, and credit cards”. This tool offers an ideal balance of security and convenience, enabling users to store and organize their passwords in a way that simplifies daily use while ensuring their sensitive information is protected from unauthorized access. Bitwarden not only helps generate strong, unique passwords but also allows for seamless password sharing when necessary, making it a versatile solution for both personal and organizational needs. Through the use of Bitwarden, we aim to streamline password management while maintaining the highest level of security for all sensitive data.

Clipboard manager

Clipboard managers, widely utilized to enhance productivity, allow users to maintain a history of copied items such as passwords, authentication codes, or other sensitive data. These tools are particularly useful in reducing the repetitive task of copying and pasting information, but when used in conjunction with password managers, clipboard managers can further streamline the process of managing credentials. Instead of repeatedly accessing the password manager interface to retrieve stored passwords, users can quickly access previously copied credentials, simplifying workflows significantly.

For this work, we opted to use Ditto, one of the most popular clipboard managers available for both Windows and MacOS environments. Ditto stores the history of copied data in a SQLite database file, allowing users to easily retrieve past entries. To identify the exact location where Ditto saves this database, the Procmon (Process Monitor) application for Windows can be used. However, by default, the database file is typically stored in the directory: C:\Users\%username%\AppData\Local\Packages\*ditto*\LocalCache\Local\Ditto_WindowsApp\Ditto.db.

By understanding how Ditto handles and stores copied data, users can better evaluate the potential security implications of storing sensitive information, such as passwords, in the clipboard history. While this can enhance convenience, it also introduces potential risks, as sensitive data stored in the SQLite database could be accessed if security measures are not properly implemented.

Log sources

Logs are an essential component in the realm of computing and system management, acting as detailed records of events, activities, or system behaviors over time. They serve as a chronological record of actions taken by users, applications, or the system itself, capturing critical information such as system errors, user logins, file access, and application performance. Logs are generated by various components within a system, such as operating systems, applications, servers, and security tools, and are typically stored in plain text or structured file formats for easy access and analysis.

The primary purpose of logs is to provide visibility into the inner workings of a system. System administrators, developers, and security professionals rely on logs to troubleshoot issues, optimize performance, and detect potential security threats. For example, error logs help identify software bugs or hardware malfunctions, while access logs track user activity and can be crucial for investigating unauthorized access attempts. In addition, logs are used for auditing and compliance, ensuring that systems adhere to regulatory standards by documenting user actions and system events.

Logs also play a vital role in incident response and forensics. In the event of a security breach or system failure, logs can be analyzed to trace the source of the problem, reconstruct events, and determine the extent of the damage. By offering an in-depth look at system activity, logs enable proactive monitoring and help organizations maintain the security, stability, and efficiency of their IT infrastructure.

However, in some cases, logs can also introduce potential security concerns. For instance, logs may be used to correlate specific events, such as the exact time of a user login, with sensitive data copied using a clipboard manager. If a log entry aligns with a timestamp when sensitive information, like a password from Bitwarden, was copied, this correlation could expose critical information to an attacker. By cross-referencing these logs with clipboard history, there’s a risk of revealing not only the timing of the activity but also the sensitive data involved. This highlights the need for careful log management and security to avoid unintended data exposure.

For the work we use 3 different free and available sources by look at their logs:

• Google Chrome History
• RDP Connection
• VPN Connection

Google Chrome History

Chrome stores its browsing history in a file that uses the SQLite database format. This file holds a detailed log of the websites you’ve visited, along with various associated data points such as timestamps, page titles, and additional metadata related to your browsing activity. These records help track and catalog your browsing sessions for future reference or retrieval.

The exact location of the browsing history file depends on the operating system you’re using. Below are the default locations for Chrome’s browsing history on different platforms:

• Windows: C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default
• MacOS: /Users/%username%/Library/Application Support/Google/Chrome/Default
• Linux: /home/%username%/.config/google-chrome/Default

The data that is typically stored in the browsing history file includes the URL of each visited website, the title of the page, the number of times you’ve visited the site, the last time the page was accessed, and any URLs you’ve manually typed into the address bar. For the purposes of this explanation, we are focusing solely on a single user profile in Chrome, and we are not accounting for scenarios where multiple profiles are in use or where alternative search engines have been utilized. However, the process for retrieving and analyzing this data remains largely the same across different setups.

RDP Connection

Logs for outgoing RDP (Remote Desktop Protocol) connections can be accessed on the client computer. In fact, every Windows client stores detailed RDP connection logs within the Event Viewer. You can locate these logs by navigating to the following path in the Event Viewer:

Application and Services Logs > Microsoft > Windows > TerminalServices-ClientActiveXCore > Microsoft-Windows-TerminalServices-RDPClient / Operational

When a user initiates an RDP session to connect to a remote Windows Server RDS host or a Windows 10/11 computer, specific events are logged to capture details about the connection. One notable log entry is Event ID 1102, which occurs each time a user successfully establishes a remote connection. This event provides critical information about the session, such as the time of the connection and the identity of the user.

By accessing these logs, administrators can monitor outgoing RDP connections, analyze connection histories, and potentially troubleshoot issues related to remote sessions. These logs are an essential resource for understanding the behavior of RDP connections from the client-side, allowing for auditing and security checks as needed.

For instance, you can observe how an RDP connection was made to the remote host with the IP address 192.168.1.3 by reviewing the above screen. Specifically, the log entry with Event ID 1102 will show the details of this connection, such as the time of the session initiation and the destination IP.

Additionally, around the same timestamp, you will typically find another log entry with Event ID 1029, which contains the username of the individual who initiated the RDP session. This event provides valuable context by linking the connection details with the specific user account that was used.

By correlating these events (1102 and 1029), administrators can piece together a clear picture of who connected to which host, when the connection occurred, and other essential details, enabling effective monitoring and auditing of RDP sessions.

In any case, identifying which account was used for an RDP connection can be relatively straightforward, especially with access to tools like PowerShell. For example, if someone gains access to the account of Mike Peter and performs a basic PowerShell query on the domain, such as Get-ADUser -Filter *. This query will return a list of users in the domain, including entries like adm.mp, which might correspond to an administrative account associated with Mike Peter. Based on this, it’s reasonable to infer that adm.mp could have been the account used for the RDP session, especially if the connection was to a critical server, such as a Domain Controller or another server.

Another plausible indicator of the account used for the RDP connection is the actual user currently logged into the machine. If Mike Peter was logged in, there’s a good chance his associated administrative account could be used for any RDP sessions initiated from that machine. This further strengthens the likelihood that the administrative account was involved, particularly when RDP connections target essential domain resources.

VPN Connection

For this particular task, FortiClient is utilized. FortiClient is an advanced endpoint security solution developed by Fortinet, designed to provide robust protection across computers, mobile devices, and networks. It offers a range of integrated security functionalities, including antivirus, VPN, endpoint detection and response (EDR), and web filtering, all packaged into a single, lightweight client. This makes it a powerful tool for safeguarding endpoints in both individual and enterprise environments.

FortiClient logs play a crucial role in monitoring security events, diagnosing potential issues, and auditing user activities, which is particularly important in larger enterprise networks. These logs can capture a variety of activities, including VPN connection details, antivirus scans, web filtering operations, detected threats, and general user actions on the network. These logs are indispensable for maintaining network security and ensuring compliance with security policies.

FortiClient generates and stores logs locally on the endpoint where it is installed, ensuring that administrators can retrieve them for analysis when necessary. The location of these logs varies based on the operating system in use. Typically, logs are stored in the following locations:

• Windows: C:\Program Files\Fortinet\FortiClient\logs\ or C:\ProgramData\Fortinet\FortiClient\logs\
• MacOS: /Library/Application Support/Fortinet/FortiClient/logs/
• Linux: /var/log/forticlient

In addition, by utilizing Procmon from the Sysinternals suite, it is possible to monitor how FortiClient stores critical data within the Windows Registry. Specifically, for saved VPN connections, FortiClient saves important configuration details in the following registry locations: HKLM\SOFTWARE\Fortinet\FortiClient\Sslvpn\Tunnels and HKCU\SOFTWARE\Fortinet\FortiClient\Sslvpn\Tunnels.

These registry entries contain information about the VPN connections that have been saved by the user, such as server addresses and possibly other configuration settings related to SSL VPN connections. Saving VPN connections is a common practice to enhance convenience, allowing users to quickly reconnect to VPN servers without having to manually re-enter connection details each time.

While this makes remote access more practical, it also highlights the importance of securing access to the machine and its registry, as these stored VPN configurations could potentially expose sensitive network information if accessed by unauthorized individuals. Monitoring these registry entries, especially in an enterprise setting, can provide insight into VPN usage and help ensure the integrity of the connection settings.

Proposed Solution

In the proposed solution, we will outline a procedure that leverages the combination of information from the clipboard manager (in this case, Ditto) and system logs to potentially steal passwords stored in the password manager. By correlating the timestamps between the clipboard history and various system logs, an attacker could piece together when a password was copied and match it to a specific login event. This method demonstrates how sensitive data, like passwords stored in a password manager, can be compromised through simple time-based correlation of events. It’s important to note that this scenario focuses solely on a Windows environment, where such a vulnerability could be exploited. Last but not least, in our scenario let’s assume we are using Bitwarden to manage and store only complex passwords.

Ditto

To understand how clipboard data may be leveraged, we turn our attention to Ditto, a clipboard manager that stores copied items for later use. By default, Ditto saves its data in the path C:\Users\%username%\AppData\Local\Packages\60145ScottBrogden.ditto-cp_n6b029mg40na2\LocalCache\Local\Ditto_WindowsApp. Ditto uses a SQLite database named Ditto.db to store the clipboard history. Of particular interest to us is a table within this database called Main which holds critical information.

The Main table contains records of text that was copied, along with the exact timestamp of when each item was last copied. This combination of clipboard content and timing allows us to explore the potential of correlating this data with other system events, such as login attempts or password retrievals from Bitwarden.

By analyzing the timestamps of copied text from Ditto’s database and matching them to log events, an attacker could potentially reconstruct sensitive information, like a Bitwarden-stored password, creating a serious security risk if not properly monitored or secured.

To detect strong passwords that meet the common security criteria (at least one lowercase letter, one uppercase letter, one number, and one special symbol), we can write a Python script that connects to the Ditto SQLite database, extracts copied text and uses a regular expression (regex) to find strings that match the password complexity policy. Here an example:

^(?=.*[a-z])(?=.*[A-Z])(?=.*[^a-zA-Z0-9])(?=.*[0-9])\S{8,32}$

where:

• ^: Marks the start of the string.
• (?=.*[a-z]): A positive lookahead. It checks if there is at least one lowercase letter ([a-z]) anywhere in the string. The lookahead does not consume characters but just ensures this condition is met.
• (?=.*[A-Z]): A positive lookahead. It checks if there is at least one uppercase letter ([A-Z]).
• (?=.*[0-9]): A positive lookahead. It checks if there is at least one number ([0-9]).
• (?=.*[^a-zA-Z0-9]): A lookahead that checks if there is at least one non-alphanumeric character (anything that is not a letter or number). This ensures that there is at least one special character or symbol.
• \S{8,32}: This part specifies that the string should contain between 8 and 32 non-whitespace characters. \S matches any character that is not a space, tab, or other whitespace. In my experience, this range covers more or less all complex passwords for both domain and password manager. To have fewer false positives we could reduce the upper bound to 20–25 chars, but for this scenario we keep 32 chars.
• $: Marks the end of the string.

In the following screen, we can clearly distinguish that the second, third, and several other strings appear to meet the characteristics of complex passwords, adhering to the expected mix of lowercase, uppercase letters, numbers, and special characters. Meanwhile, the final string seems to represent a file path rather than a password.

At this point, it’s essential to save these identified strings for further analysis. The next step will be to explore how we can correlate the information from the clipboard logs with other data sources, such as system logs or application logs, to potentially reconstruct the sequence of events or interactions — particularly focusing on password usage.

Ditto — Google Chrome

To begin analyzing the first log source, Google Chrome, the goal is to correlate Chrome’s browsing history with the passwords we’ve identified from the clipboard manager. By aligning the timestamps of Chrome’s browsing activity with the times the passwords were copied, we can infer whether a password is likely associated with a specific website. If a website was visited within a close range of time to when a password was copied, it’s reasonable to suspect that the password may have been used for that website.

Google Chrome stores its browsing history in a SQLite database located at C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\History. The History database contains a table that’s highly relevant for this analysis: the urls table. This table records the URLs of websites visited by the user along with the corresponding visit timestamps.

In this scenario, we aim to combine the data from Ditto’s clipboard history and Google Chrome’s browsing history to establish a likely association between the passwords copied from Ditto and the websites visited in Google Chrome. The daily login routine involves a few steps that typically occur within a short time window, which we’ll use as a threshold to correlate these two data sources:

1. Navigate to the website using Google Chrome.
2. Enter the username on the login form.
3. Open Bitwarden, search for the password, and copy it.
4. Paste the password into the website’s login form.
5. Submit the login form to authenticate and access the site.

In most cases, there is a small delay between visiting the website and copying the password from Bitwarden using Ditto (or vice versa, copying the password first and then visiting the website). Based on this routine, we estimate that up to 15 seconds may pass between these events, which is a reasonable approximation to detect real associations between passwords and websites while minimizing false positives. One important consideration is the “absolute time difference”: sometimes the order of actions can vary, and a user may copy the password before navigating to the website. Thus, the absolute difference in time between the website visit and the password copy action should be checked, rather than assuming a strict sequence. For example, if the password is copied before the website is visited, the difference could still fall within the 15-second threshold. Therefore, if the absolute time difference between a password being copied and a site being visited is within 15 seconds, we consider it a valid match.

Let’s try to navigate to 192.168.1.9.

In this case, we have the Wazuh login webpage, and luckily, we didn’t copy and paste the username during the process. Otherwise, finding the exact username-password pair to gain access would have been much easier. However, even without the username, we can still try to brute force our way in by using a common list of usernames — starting with something typical like “admin”. To perform this, we can leverage a tool like Burp Suite, which is widely used for web application penetration testing. Burp Suite allows us to automate the process of testing various username-password combinations, helping identify potential security flaws.

We attempt the discovered password with the username “admin,” and we successfully gain access to the Wazuh login page! By simply combining clipboard logs (Ditto) and Chrome history data, we were able to crack what would normally be considered a strong and complex password — a task that could have taken thousands of years to brute force without this clever log correlation.

This scenario illustrates the potential risks of clipboard managers and logs when sensitive information like passwords is involved. Even strong, complex passwords can become vulnerable when combined with accessible logs from other sources, emphasizing the importance of secure handling and management of sensitive data across systems. To further assess the potential risk of the password we discovered through the clipboard manager and log correlation, we decided to upload the extracted password and any relevant files to VirusTotal, a popular online service for analyzing suspicious files and URLs for malware and other threats. The result came back as UNDETECTED.

Ditto — VPN

To further enhance our goal of associating log data with sensitive information, let’s explore another potential avenue: correlating VPN connection logs with clipboard history and password data. In this scenario, we’ll use FortiClient VPN as our VPN client.

FortiClient VPN is a robust security solution by Fortinet, commonly used in corporate environments to provide secure, encrypted remote access to internal networks. It integrates VPN services with endpoint security features, and like most VPN clients, it generates detailed log files, which are typically used for troubleshooting connection issues. FortiClient logs two key files that store VPN connection activity: C:\Users\%username%\AppData\Roaming\FortiClient\logs\trace\guimessenger_1.log and C:\Users\%username%\AppData\Roaming\FortiClient\logs\trace\sslvpnlib_1.log. These logs contain valuable information, such as: VPN name (as registered in the FortiClient application), IP address and port used for the connection, timestamp indicating when the VPN connection attempt was made, and the username used for the connection.

Imagine the following situation:

1. A user opens a VPN connection using FortiClient.
2. Around the same time, they also copy a password from their password manager (like Bitwarden) using Ditto.
3. If we have access to both the VPN logs and the clipboard history, we can attempt to correlate the VPN connection attempt with the time the password was copied.

By aligning the timestamp of the “OnConnect is called” event in FortiClient’s VPN logs with the time when the password was copied from Ditto, we can deduce that the copied password could be linked to the VPN connection.

Up to this point, we can explain how we created the script used in this experiment, which involved correlating the timestamp of the “OnConnect” event found in the VPN logs with the timestamps recorded in Ditto’s clipboard history. This process allowed us to uncover potential vulnerabilities in how sensitive data is handled during VPN connections.

The procedure we followed mirrors what we did earlier. When a user attempts to connect to the VPN, they typically open the VPN client, search for the appropriate VPN password within Bitwarden, copy it using Ditto, and paste it into the VPN client to establish the connection. Recognizing this consistent pattern, we decided to apply a threshold of 15 seconds between copying the password and initiating the VPN connection to avoid generating an excess of false positives.

The script we created automates the extraction of timestamps from both the VPN logs and Ditto’s clipboard history. It compares the absolute time difference between these events, identifying instances where a VPN connection attempt and a password copy action occurred within the set 15-second window. This approach allowed us to establish a connection between the VPN name, username, password, and the gateway address used during the session.

The result, as shown in the screenshot below, reveals a clear correlation between the VPN name, username, password, and gateway. The script successfully identified the exact moment the VPN connection attempt took place and matched that with the time the password was copied. This method demonstrates how logs from seemingly unrelated sources can be combined to extract sensitive information, even when using highly secure password managers like Bitwarden.

Let’s try to combine the pair of username and password and… we are in!

Ditto — RDP

Lastly, it’s worth noting that it’s also possible to correlate passwords with RDP (Remote Desktop Protocol) connections made by the user. This technique can be incredibly powerful, especially in a corporate environment where the user is a domain administrator. In such cases, obtaining credentials can enable privilege escalation with minimal noise or suspicion.

As observed in the previous sections, the focus here is on Event ID 1102, which logs information about RDP connections. This event can be found under Application and Services Logs > Microsoft > Windows > TerminalServices-ClientActiveXCore > Microsoft-Windows-TerminalServices-RDPClient / Operational. By leveraging a PowerShell or Python script, it’s easy to extract these logs and identify when an RDP connection was initiated.

As with the previous experiments, we can correlate the timestamp of the RDP initialization with the time the password was copied from the clipboard manager. This provides another opportunity to link the RDP session to the credentials used, making it easier to track down the login details. The outcome of this analysis confirms that correlating RDP events with copied passwords can lead to the discovery of valuable credentials without raising any alarms.

Now, let’s take the same approach as before by correlating the time of the RDP connection with the timestamps from Ditto to see if there’s a password linked to those RDP sessions. To simplify this process, we converted the timestamps into Unix format, making it easier to compare the clipboard history (Ditto) with the logs.

By doing so, we were able to uncover a matching set of credentials that could be used to access the target machine. Given that we are operating within a work environment, there’s a strong likelihood that the password discovered is the same one the user utilizes to log in to their account. At this point, we can check whether the machine associated with the IP address is a domain controller. If it turns out to be one, the implications could be severe, opening the door to significant privilege escalation.

With this knowledge in hand, we attempted to log into the machine using the identified username, and — success! We successfully gained access, demonstrating how easily one can break into a system by simply correlating clipboard history with RDP logs.

In addition to the previous findings, there’s another crucial log to consider: Event ID 1029, which can reveal valuable information about the username associated with a particular session. This event log provides detailed insights that could help narrow down the identity of the user involved in specific activities, adding another layer to our investigation.

To further explore this, you can use tools such as CyberChef to decode or hash certain values. For example, by following this CyberChef recipe, it’s possible to match the usernames found in the Active Directory to their corresponding hashes. In our case, the username “user” was successfully matched to its hashed version, verifying the identity and confirming the link between the logs and the associated credentials.

This additional step enhances the process by not only correlating timestamps but also identifying specific user accounts, providing a comprehensive view of the security landscape.

Remember that in most corporate environments, domain accounts are consistently used for logging in. This makes it possible to extract a list of all usernames using a simple PowerShell command and try to crack them offline.

Username

If we don’t know the exact username, as it wasn’t copied, we can still make educated guesses based on common username patterns typically found in corporate environments. For online services, the username is the email around 90% of the time, which is very easy to obtain. Anyway, some of the most frequent formats include:

• Email-based usernames, such as mike.peter@test.it or m.peter@test.it. More likely, if we have access to the domain, it is possible to query the domain controller to obtain all the emails in AD.
• Name and surname combinations, like mike.peter.
• Initial of the first name followed by the surname, such as m.peter or mpeter.
• For VPNs, the pattern often extends to include additional elements, such as name.surname.ext, mike.peter.ext, or similar variations like m.peter.ext or mpeter.ext. For FortiClient we don’t need to guess it, since the username is already written in its logs.

Moreover, many software systems fail to implement lockout mechanisms that prevent multiple login attempts with the same username, but different passwords. This leaves room for a password spray attack, where a limited number of commonly used passwords are tested across many usernames. Such attacks are particularly stealthy because they don’t trigger traditional brute force alarms, making them a potential vulnerability in many corporate environments.

Countermeasures

The issue, as we’ve discussed, revolves around the improper use of clipboard managers, which can inadvertently store passwords. If a company permits the use of clipboard managers, it’s essential to highlight the associated risks. However, there are several countermeasures that can be implemented to mitigate the risk of password discovery:

1. Enable Bitwarden’s clipboard cleanup: in Bitwarden’s settings, you can configure it to periodically clear the clipboard after a set time, such as 1–2 minutes. This strikes a good balance between usability and security, ensuring sensitive information isn’t stored longer than necessary.
2. Limit the clipboard history in Ditto: configure Ditto to store only a limited number of copied items, reducing the amount of sensitive data that could be exposed if the clipboard history is accessed.
3. Implement two-factor authentication (2FA): even if an attacker uncovers a username-password pair, they won’t be able to access the account without the second authentication factor.
4. Use the Bitwarden browser extension: by utilizing Bitwarden’s extension to autofill passwords and usernames directly into web forms, you can significantly reduce the risk of these credentials being copied to the clipboard.
5. Manually enter the username: avoid copying usernames to the clipboard. If only the password is stored, it becomes much harder for an attacker to discover both credentials.

Another effective countermeasure is to always use Bitwarden’s browser extension in Chrome, though it doesn’t always work perfectly across all sites.

Summary

In this experiment, we outlined the risks associated with using a clipboard manager when combined with other logs, demonstrating how it can lead to serious vulnerabilities, including the discovery of even complex passwords. We walked through the process of extracting passwords stored in Bitwarden and correlating them with Google Chrome history, VPN logs, and RDP sessions. It’s crucial to emphasize that these methods, when combined, can create a highly effective attack strategy.

This guide is NOT intended to inspire the creation of any kind of infostealing tool. Instead, it aims to raise awareness about the potential risks of using clipboard managers in a corporate environment, stressing the importance of taking proper precautions.

---

Originally published on Medium.