Ayoi’s

not this Brute Force

This is the big question when we try to categorized this type of attacks. Whether this SSH Brute Force attack falls under reconnaissance/scanning/information gathering or already at the exploitation phase which can be categorized as Attempted Unauthorized Access. Some said it should be categorized under Reconnaissance, while others preferred it to be categorized as Attempted Unauthorized Attempt.

In my opinion, both of these category can be used, however it depends on how this brute force attack was launched or performed. In other words, IF tools like Hydra, GuessWho was used then for this type of attack can be categorized as Reconnaissance/Information Gathering/Scanning.

Why?

Let do some simulation on this. The tool that I use is Hydra 5.4 running on Redhat 9. So the attacker machine is using 10.10.3.126 as its IP Address. For the target, I have to install OpenSSH for windows on my Windows 2003 Enterprise machine as I have problem with my FreeBSD’s snapshot file. Oh yes, as I need to run this simulation in controlled environment, so this simulation will be performed by my Virtual Machines in my Virtual Network. So the target (win2k3) will has 10.10.4.128 as its IP Address.

Also for clarity purpose, I’ve created a user (ayoi) with the password set to “kambing” while for attacking purpose, the Hydra will use a password list created by me where it has only 3 password that are “password, password1 and kambing”. If I want to use John The Ripper password list (3107 entries for JTR 1.7), Hydra will perform 3107 login tries, with 194 tries for each of the 16 tasks (by default) and will generate 27330 packets. So with my own password list, Hydra will only perform 3 tasks,  3 login tries with 1 try per task and will only generate 76 packets which is kewl for us

First as we want to capture the packet as well, we run our all time favourite sniffing tool;tcpdump on the attacker machine

[root@t4linux root]# tcpdump -s 0 -nn -i eth0 -w “`date +%Y-%m-%d-%H:%M`.`hostname`.pcap” host 10.10.4.128 and tcp port 22 &

Then we can execute Hydra;

[root@t4linux tools]# hydra -l ayoi -P password1.lst 10.10.4.128 ssh2
Hydra v5.4 (c) 2006 by van Hauser / THC - use allowed only for legal purposes.
Hydra (http://www.thc.org) starting at 2008-07-22 16:39:48

Ok now is the interesting part. Remember that I said for brute force/dictionary/password guessing attacks performed via this kind of tools can be categorized as Information Gathering/Reconnaissance/Scanning? As in Hydra case, that’s what it does. It just perform (I might call it dictionary attack as well) brute force by trying to logon to the system using the combination of users and passwords listed in the defined password file. Once this tool identified the right combination of the username and password to access the system, it will disconnect itself and prompt the result either to the attacker’s console or to any defined output file.

Just like the example below:

[DATA] 3 tasks, 1 servers, 3 login tries (l:1/p:3), ~1 tries per task
[DATA] attacking service ssh2 on port 22
[STATUS] attack finished for 10.10.4.128 (waiting for childs to finish)
[22][ssh2] host: 10.10.4.128   login: ayoi   password: kambing
Hydra (http://www.thc.org) finished at 2008-07-22 16:39:48

Let’s analyse based on the packets generated by this activity

For the sake of the space in my blog, I’ll post the packets that performed successful password guessing. How do I know which one? As in the traffics, there are 3 connections initiated by the attacker where the 1st one is to test the 1st password, the second for the second password and the third one meant for the correct password (based on the password list I’ve supplied to Hydra that is).

Oh yeah, I will post the last 5 packets to show how Hydra will disconnecting itself when either correct or incorrect password guessed.

So these are the traffic tail end.

16:39:49.812628 IP 10.10.3.126.33569 > 10.10.4.128.22: P 3690477673:3690477757(84) ack 1946435082 win 7904 <nop,nop,timestamp 952831 14984>

16:39:49.830210 IP 10.10.4.128.22 > 10.10.3.126.33569: P 1946435082:1946435166(84) ack 3690477757 win 63671 <nop,nop,timestamp 14985 952831>

16:39:49.850464 IP 10.10.3.126.33569 > 10.10.4.128.22: F 3690477757:3690477757(0) ack 1946435166 win 7904 <nop,nop,timestamp 952835 14985>

16:39:49.850698 IP 10.10.4.128.22 > 10.10.3.126.33569: . ack 3690477758 win 63671 <nop,nop,timestamp 14985 952835>

16:39:49.860120 IP 10.10.4.128.22 > 10.10.3.126.33569: F 1946435166:1946435166(0) ack 3690477758 win 63671 <nop,nop,timestamp 14985 952835>

16:39:49.860196 IP 10.10.3.126.33569 > 10.10.4.128.22: . ack 1946435167 win 7904 <nop,nop,timestamp 952836 14985>

Can you see that in fact the connection terminated gracefully? Also another interesting thing is take note on the window size. Compared to normal SSH access, the default 65K size will be used especially from the requestor but in this case also similar with other scanning tools, the window size would be smaller as they don’t have any intention to establish only one session <!– /* Font Definitions */ @font-face {font-family:”Cambria Math”; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:”"; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:”Times New Roman”; mso-bidi-theme-font:minor-bidi;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:”Times New Roman”; mso-bidi-theme-font:minor-bidi;} .MsoPapDefault {mso-style-type:export-only; margin-bottom:10.0pt; line-height:115%;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} –>

. So they need to perhaps use as small as possible available buffer and this enable them to create as many sessions as possible (not only SSH sessions)

Just like Nessus scanning tools from Tenable Security. It will perform vulnerability scanning activities on the systems, try to find any possible flaws and bugs that can be exploited BUT the moment it discovers any vulnerability, does Nessus continue with exploitation phase or it stopped and record the findings for the final report? So when your IDS screaming about Nessus activities, under which category these alerts will fall? Reconnaissance/Information Gathering/Scanning or Attempted Unauthorized Access?

However if you try to guess a system password manually, the moment you eventually managed to guess the correct combination of username and password, are you going to disconnect your self, write down the information and reconnect back later OR, you just continue using that access?

What category for this kind of activity will be?

Comments RSS