Tale of the misconfigured script

This attack attempt made me laugh a bit. I see the following event from my Sguil instance running on Security Onion that is monitoring my honeypot:

I pull the transcript and find the following:

I thought that was a very odd password to attempt. I wanted to a transcript of all the attempts the attacker tried, so I used tcpdump to carve out the session between my honeypot and the attacker with the following commands:

 cd /nsm/sensor_data/jbc-eth0/dailylogs/2013-02-24/
 tcpdump -r snort.log.1361664061 -w ~/ftpbruteforce-pcap-20130224.pcap ip and host 61.129.71.42 and host 192.168.1.20 and port 21 and proto 6

 Securityonion will log full pcap's to /nsm/sensor_data/<sensor-name>/dailylogs/<date>. The tcpdump command is pretty much the same command that sguil issues to the sensor to generate transcripts. The -r is to read in a pcap file, -w is to write the results to a pcap file. After that is the BPF (Berkley Packet Filter) filter which defines what traffic we want to carve out.

I opened ftpbruteforce-pcap-20130224.pcap in wireshark and started looking at the sessions and found this one:

Turns out, there are multiple attempts of using %username% and some other strings. It seems our attacker forgot to configure this field. Logically, I assume it's supposed to try different variations of Administrator and a string such as:

Administrator1
Administrator12
Administrator123
Administrator1234

If anyone knows the FTP brute forcing tool that was likely used, please let us know. My Google-fu is failing as Google drops punctuations from searches.

Brief NSM Analysis of FTP Dictionary Attack

On the 15th I saw an event in Sguil I had been waiting for: "ET POLICY FTP Login Successful". The credentials are Administrator/password. I was surprised how long it took.

I ran an event query on the destination IP (this traffic is flipped from the true src/dst):

You'll see PADS registering a new asset as the attacker's IP is first observed, an alert that the attacker is trying at least 5 unsuccessful attempts to log in as Administrator, then finally a successful login:

Since FTP is in cleartext, we can easily inspect the traffic by right clicking the Successful Login event and selecting "Transcript". I'm pasting the traffic instead of using a screen shot:

DST: 220-FileZilla Server version 0.9.41 beta
DST:
DST: 220-FileZilla Server version 0.9.41 beta
DST:
DST: 220-written by Tim Kosse (Tim.Kosse@gmx.de)
DST:
DST: 220-written by Tim Kosse (Tim.Kosse@gmx.de)
DST:
DST: 220 Please visit http://sourceforge.net/projects/filezilla/
DST:
DST: 220 Please visit http://sourceforge.net/projects/filezilla/
DST:
SRC: USER Administrator
SRC:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST:
SRC: USER Administrator
SRC:
SRC: USER Administrator
SRC: USER Administrator
SRC:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST: 331 Password required for administrator
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST: 331 Password required for administrator
DST: 331 Password required for administrator
DST:
SRC: PASS
SRC:
DST: 530 Login or password incorrect!
DST:
DST: 530 Login or password incorrect!
DST:
SRC: USER Administrator
SRC:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST:
SRC: PASS abc123
SRC:
DST: 530 Login or password incorrect!
DST:
DST: 530 Login or password incorrect!
DST:
SRC: USER Administrator
SRC:
DST: 331 Password required for administrator
DST:
DST: 331 Password required for administrator
DST:
SRC: PASS password
SRC:
DST: 230 Logged on
DST:
DST: 230 Logged on
DST:
SRC: RMD sarcaxxo
SRC:
DST: 550 Permission denied
DST:
DST: 550 Permission denied
DST:
SRC: QUIT
SRC:
DST: 221 Goodbye
DST:
DST: 221 Goodbye
DST:

We see the attacker used Administrator as the username in all the attempts and iterated through a couple of guesses for the password: abc123, password. What I was curious about was the "RMD sarcaxxo" command the attacker issued after logging in which is attempting to remove the directory (RMD) named "sarcaxxo", which did not exist on my honeypot. After searching Google, it seems this is a command issued by a tool "Multi-thread FTP scanner v0.2.5" by Inode. If someone wanted to create an alert for the use of this tool, they could use something like the following Snort rule (not tested):

alert tcp any any -> $HOME_NET 21 (msg:"Multi-thread FTP scanner v0.2.5 by Inode - Successful Login and Attempted Directory Removal"; flow:from_client,established; content:"RMD sarcaxxo"; classtype:misc-activity; sid:5001990; rev:1;)

While there were no more alerts, it does not mean the attacker did nothing else. I right click on the Dst IP part of the FTP Successful login event again and select Quick Query -> Query Sancp Table -> Query DstIP/1 Hour.

The results show us that he attacker connected on port 3389 but unlike his connection on port 21, there is no byte count. You can confirm the lack of interesting traffic by pulling the transcript. Since the end times for the traffic on 3389 were before the end time of the FTP traffic, we can guess that the attacker did not have the credentials yet and therefore is likely to be part of a port scan.