The Challenge: Detect Threat Actors Who Already Have Network Access
Suppose you wanted to find threat actors lurking on your network—probably a good idea, right? To do this, you need to devise a way to be notified of strange activity. The steps in this post will further assist you in detecting malicious users who are already on your network.
The Solution: Create a Honeypot to Detect Cyber Attackers
By setting up a honeypot to catch cyber attackers, you can detect (or deflect) attempts to gain unauthorized access to your systems. When you create a simple honeypot with fake financial, medical or other industry records, you can alert whenever the file is accessed, modified, read or the permissions are changed.
Because no one should ever be on this device/network share, you can use it to identify the intruders quickly, because you can assume any actions are threats.
The Setup
First, you need to confirm a few things in preparation of enticing someone who is snooping on your network.
Step 1: Set Up a Network Share with Fake Records
You will want to think about what fake data you can create that will stand out to an attacker. For example, if you work for a hospital, you might want to create false documents around medical records. If your organization processes cardholder data, you ought to create a fake list of credit card numbers, and so on. For this example, I created the following:
Step 2: Make the Data Look Legit
You will want to ensure there are a few more bogus items in the folder so it looks legitimate—but here’s the fun part. I populated the Travel and Expense Credit Cards.txt file with the below information.
This way, if an attacker wants to use the stolen fake credit card information, they first need to obtain the CCID number from our “Travel Management” team. Luckily, we gave them the workflow with the appropriate contact information.
You will need to make sure the items highlighted in red are configured to match your organization. If the attacker does attempt contact, then this will add to your evidence. But even if they don’t reach out, you will still have the proper information in your logs to see who tried to access the server and documents.
In this example, I am using a file path located on the desktop for the sake of the example, but you would want to place the fake files on a network share that is publicly accessible. For this to work correctly, your server hosting the network share will need a system monitor agent installed on it.
Step 3: Configure FIM Policy
Configure both a Monitoring Configuration and a Monitored Items inside of the File Integrity Monitor Policy Properties based on the false information you created in the previous step.
Step 4: Install a System Monitor Agent
Install a System Monitor Agent on the network share host, and enable File Integrity Monitor with either Standard or Real-Time Mode. Then select your Policy that you created in the previous step.
If this is an existing system, you will need to navigate to Programs and Features first, and Change/Modify the current LogRhythm System Monitor Service. In the setup, select the drop-down to make sure the FIM/RIM Driver is installed:
Step 5: Test that the Setup is Functional
Now, any time that your file is accessed, read, modified, or permissions are changed, you will see this come up as an event under Log Sources and WinFileMon (Log Source Name). You can then tail the log source and test that it is functional once you open the file.
You can see in the tail that the FIM detected that this file was accessed:
From here, you can make a catch-all AI Engine Rule that will alert you to any LogRhythm File Monitor activity as seen below:
Now sit back and relax. This is an important step, as the files navigate to your “Venus fly trap of doom.” You can see you were tailing the log source for WinFileMon for verification (figure below on the right), but simultaneously, you received your AI Engine alarm in the WebConsole (figure below on the left).
The Value
By leveraging LogRhythm File Integrity Monitoring, you can get context around what user account accessed a honeypot file on a network share or standalone device.