Sorry for the repost, but one of the list moderator asked for only a resume,so I thought the other lists might be the same. You can get the full paper at one of my websites. ComLog.pl, a WIN32 command prompt logger by Floydman, floydian_99at_private August 13th 2002 This paper is available online at www.geocities.com/floydian_99 and http://securit.iquebec.com This paper can be freely distributed and reproduced, as long as correct credentials are maintained, and that no modifications are made to this file. For corrections, suggestions or comments, please send me an e-mail. Abstract The goal of this paper is to present a new Perl tool that I made to monitor DOS sessions on Windows NT/2K (should also work on XP, but cannot try it). This tool can be used by administrator to keep a history of commands typed in the DOS command prompt and the associated output, for example on an IIS server. This can help admins to figure out what the attacker has done after compromising the machine via one of the numerous vulnerabilities this software present. Of course, like any keylogger out there, it can also be use for malicious purpose, but I think other programs out there make better spying tools. Preface I started writing about my own experiences in the security field after reading Lance Spitzner's whitepapers, way back before the HoneyNet Project grew into the multi-disciplinary team that has now joined him and make the project as we know it today. I also wanted to inspire myself of what was being done on the UNIX platform (making your own tools when they don't exists) to transpose it in the Windows world, where I am more comfortable. This paper follows these traditions, as the idea for it came to me while reading the HoneyNet Project recent book, Know your ennemy. In the book, one passage relate to how the HoneyNet is designed to sniff all the traffic that passes into it since all of this traffic is suspicious by nature. This worked great for capturing what the attackers were doing on the systems, up to the day when someone was using cryptcat to hide his session. To circumvent this problem, the team made a modification in the source code of bash to log the session and recompiled it for the next attack. However, the book says, since we can not do the same with Microsoft code, they didn't bother to make an equivalent solution for Windows. ComLog fills that gap. Special thanks to Lance Spitzner for his comments and ideas during the improvement of the pre-release. Targeted audience This document is presented to anyone who has interests in computer security, honeynets, trojan horse, keyloggers, network administration and computing in general. 1. Introduction 2. Purpose of the program 3. How it works 4. Things you need to know 5. To Install 6. Conclusion Appendix A. Source code Appendix B. Sample session history (console) Appendix C. Sample session history (history.txt) 1. Introduction One of the most common ways that Windows machines are hacked is through the command prompt. This is not surprising, since this is the shell environment on the Win32 platform, it permits the execution of commands without the need of a GUI, and is easily accessed by executing one single file, either command.com on Win 9x/Me, or cmd.exe on Win NT/2K. While this file in itself is not a problem, the thing is that it can be accessed by many ways by anyone who can guess where is located this file, and most of the time, it is always in the same places, because the installations were made by default. This is how most of IIS exploits work, they rely on a Unicode encoding or a special format string to fool the server into accessing files outside of the web directory and make a renamed copy of cmd.exe (because IIS filters commands sent directly to cmd.exe, thanks Microsoft for the great security), and then simply issues command to this copy via a URL in their web browser. Code Red and Nimda were doing that automatically. Also, admins may want to keep an eye on what's going on in the DOS prompts on their users workstations, as the inside threat remains the greatest concern for computer security. I mean, what could secretaries, accountants and other office employees be doing in a DOS prompt that is related to their job? I wouldn't go as far as to remove their access to the command prompt, besides it may be needed from time to time by support people. But right now, how can you tell if one of the employees on your network is not doing a ping scan or is netcating his way to the restricted file server and making password dumps? ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Aug 15 2002 - 05:01:47 PDT