This demo is a continuation of the previous one,
where we configured file processing rules in Snort to detect
executable files from Microsoft or Linux machines.
Let's head over to our Kali Linux VM and create a couple of payloads
for Snort to detect. Instead of sending generic,
executables to test this,
we can use MSFvenom to quickly generate a couple of reverse shell payloads
as standalone executables for both Windows and Linux.
To generate the Windows payload,
we can use msfvenom ‑p windows/shell_reverse_tcp, and then specify
our localhost using LHOST and the port to connect back using LPORT.
We'll set the file format to EXE using the ‑f and output this to a
file called payload.exe.
Once that generates,
we're ready to create the next one. Linux payloads are very similar.
We just need to adjust the payload value to
linux/x86/shell/reverse_tcp, the format to ELF, and output to a
different file name. I'll add a .elf to make it easier to differentiate.
One last step is to make these files executable. Once that is
ready, we're set to make the transfers.
One of the supporter protocols for this transfer is
open on Metasploitable, FTP again.
We can send our Linux exploit to that host using an FTP transfer. We can
initiate an FTP session with Metasploitable by IP.
We can then use the user account to access the service,
which as a reminder has a username, user, and a password is also user.
Once you gain access,
you can transfer the file using the command put
followed by the file name, in this case,
payload.elf. After the transfer completes, just close the
session with quit. For our payload.exe file,
let's use a different supported protocol, HTTP. We can transfer
this to Morning Catch using their web browser.
To do that,
you just need to install Apache if it's not already on your system and then
copy the file to /var/www/html. Then we just need to start Apache using
systemctl start apache2. I already have Apache running,
so I won't actually enter this command. Now we just need to log into Morning
Catch as Richard Bourne to simulate the Windows environment.
We'll go ahead and open up our Firefox browser, and we'll navigate to our
Kali Linux IP /payload.exe. Then we just click to save the file, which
initiates the transfer, and it's already complete.
Now that we transferred both of these files, we're ready to
check our Snort VM and see what we got.
Strange.
There are no alerts as we might have expected.
Don't panic.
You didn't do anything wrong.
File detection is actually logged to a separate file.
We can stop Snort and check our logs.
Now that we've configured file processing,
you'll notice a new field down here at the bottom of your statistics.
We have our file type stats by files with a total download of
1 EXE and upload of 1 ELF. That's correct. We have the total
bytes downloaded and uploaded, and we have our final signature statistics.
We captured file signatures for one download and one upload.
Now, where are those files, and where are the logs?
Well, I did not configure Snort to log in any other directory,
so all of my items should be here in my home directory.
You'll notice in my home directory two rather long
strings of letters and numbers.
These are actually the captured files.
What Snort did was take a SHA256 value of the file itself and then
store the file it captured with that format.
We'll actually leverage this value in a moment to create a file blacklist.
You'll also notice this other file called file.log.
That is where the file detection logs are stored.
We can take a quick look at it to see what we have,
and we have only one entry in this file,
but it shows our EXE file, the name of it, payload.exe, our verdict,
which was Log, and the type, MSEXE.
Before we move on to leveraging SHA values,
let's do a quick recap of what we covered over these two demos.
We started the first demo by configuring Snort to process files.
Next, we wrote two rules to detect the files by type specified in filemagic.lua.
We then started Snort and tested our rules.
We successfully captured the files and logged the activity in file.log.
In the next demo, we'll use these SHA values to block known malicious payloads,
preventing future transmission.