Search

vulnerablelife

Vulnerable Life by Vulneraman | Cyber Security Blog

Free Online Tools for Looking up Potentially Malicious Websites

Several organizations offer free online tools for looking up a potentially malicious website. Some of these tools provide historical information; others examine the URL in real time to identify threats:

Any on-line tools that should be on this list, but are missing? Let me know. My other lists of on-line security resources outline Automated Malware Analysis Services and Blocklists of Suspected Malicious IPs and URLs.

Advertisements

Best Onion Links – Deep Web

Best Onion Links - Deep Web

 

Introduction Points

  • Ahmia.fi – Clearnet search engine for Tor Hidden Services
  • EasyONIONs – EasyONIONS is the easiest way to access a hidden service
  • The Tor Dark Wiki – Latest links from Tor Dark Wiki
  • The Uncensored Hidden Wiki – This wiki is a community project aimed at collecting and cataloging anything and everything
  • Light Hidden Wiki -Light version of original Hidden Wiki
  • All Your Wiki – Mostly just a mirror of the directories without linking to CP.
  • Tor Directory – 50 000+ Sources.
  • The Hidden Wiki – Wiki style link list of TOR, most links there are SCAMS!
  • OnionList Onion Link List and Vendor Reviews.
  • DuckDuckGo – A Hidden Service that searches the clearnet.
  • Bitcoin Fog – Bitcoin anonymization taken seriously.
  • Torch – Tor Search Engine. Claims to index around 1.1 Million pages.
  • Torlinks – Directory for .onion sites, moderated.
  • Grams – Search Darknet Markets and more.
  • Hidden Wiki – The Hidden Wiki more orderly and updated!
  • The Uncensored Hidden Wiki – A censorship-free mirror of The Hidden Wiki!
  • The Hidden Wiki – A mirror of the Hidden Wiki. 2 days old users can edit the main page.
  • The Liberty Wiki – A 100% community editable wiki that welcomes all users. Allows a variety of uses. Now recruiting Admins. [Back up]
  • Hidden Links – Directory for hidden services, daily verified for availability. Anybody can add new links. [Down 2015/5]
  • Hidden Answers – a site for asking questions and receiving answers on TOR.
  • The Matrix – Very nice to read.
  • How to Exit the Matrix – Learn how to Protect yourself and your rights, online and off.
  • Verifying PGP signatures – A short and simple how-to guide.
  • In Praise Of Hawala – Anonymous informal value transfer system
  • MatrixDirectory -New and Fresh Onion Links Everyday! Nov. 2016. Matrix Directory

 

Financial Services

  • Torads – TorAds is an advertising network for both advertisers and publishers dedicated for use on hidden services behind Tor.
  • EasyCoin – Bitcoin Wallet with free Bitcoin Mixer.
  • WeBuyBitcoins – Sell your Bitcoins for Cash (USD), ACH, WU/MG, LR, PayPal and more.
  • OnionWallet – Anonymous Bitcoin Wallet and Bitcoin Laundry.
  • ccPal – CCs, CVV2s, Ebay, Paypals and more.
  • HQER – High quality euro bills replicas / counterfeits
  • USD Counterfeits – High quality USD counterfeits.
  • The Green Machine! – Forum type marketplace with some of the oldest and most experienced vendors around. Get your paypals, CCs, etc, here!
  • The PaypalCenter – Live Paypal accounts with good balances – buy some, and fix your financial situation for awhile.
  • Premium Cards – Oldest cc vendor, Top quality Us & Eu credit cards!
  • Hack Masters Trust – Risk Free Pre-Paid cards for sale.
  • Unique Opportunities Offering a couple of high quality products for a great deal!
  • Hidden Wallet – Tor Anonymous Hidden Bitcoin Wallet
  • Paypal Baazar – paypal accounts for sale
  • Cash Machine – Phished PayPal, Neteller, Skrill, BoA, Wells fargo bank Accounts, Paysafecard’s, US & EU Credit cards are available here.
  • Shadow Wallet – An Anonymous user Friendly Bitcoin Wallet/Mixer – Highly Regarded Service
  • Card Store – Bank card store, сс, paypal, dump+pin. Free shipiing
  • BitBlender – Bitcoin mixer.
  • Shared Coin – Free, fast and privacy-oriented Darknet Bitcoin Mixer, any amount from 0.0001 to 50 BTC.
  • SOL’s USD Counterfeits – High Quality 20 USD Counterfeit Notes – Trusted Service.
  • The Queen of Cards – #1 Female Carding Forum for CCs, Pre-Paid, WU, MG, Bank & PayPal Transfers, Since 2011!
  • OnionWallet – Anonymous Bitcoin Wallet and Bitcoin Laundry.
  • Wall Street – Paypal accounts, credit cards, we have everything!!
  • Cheap Euros – 20€ Counterfeit bills. Unbeatable prices!!
  • Paypal-Coins – Buy a paypal account and receive the balance in your bitcoin wallet.
  • Bitiply! Multiply Your Bitcoins Through Bitcoin Malleability Exploit!
  • Clone CC Crew – No.1 Trusted onion site for Cloned Credit Card. $2000/$5000 balance available
  • EasyCoin – Bitcoin Wallet with free Bitcoin Mixer.
  • SOL’s Euro Counterfeits – 50€ Counterfeit notes. Quality + Best Prices
  • Double your Bitcoins – Service that doubles your Bitcoins.
  • Credit Cards – Credit Cards, from the most Trusted Vendor in the union.Fast shipping.
  • Your C.Card Shop – Physical credit cards with High balance available to order. Paypal or bitcoins as payment methods
  • Skimmed Cards Oldest seller on old HW. Fresh stock. 99.9% safe. Worldwide cashout! Express shipping.
  • BtcLowen Sell your Bitcoins for 10% more than the market value!
  • 7YearsinTibet Fully automated PayPal & Credit card market site. Fresh stock every 2 days. Best deals.
  • USJUD Counterfeits – EUR || USD Counterfeit money, any trusted escrow accepted, the most trusted seller.
  • Dexters Bank – One-Stop shop for Western Union and Bank Transfers on the Deep Web.Amazing Service. Bitcoins/Litecoins only –
  • AnonCoin – Clean your coins 100% anonymously! For a 0.1% fixed fee.
  • Fake Bills – Fake bills in Euro/dollar. Cheap price, shipping worldwide.
  • Instabit – Get bitcoins instantly
  • Buy and sell Bitcoin Anonymous and safe purchase and sale of bitcoins.
  • TOR Wallet – Bitcoin Wallet with integrated Bitcoin Mixer.

 

 

Commercial Services

 

Domain Services

 

Hosting / Web / File / Image

  • Fuck You Hosting Completely free hosting service for onion websites
  • Prometheus_Hidden_Services – Payed hosting, provides Virtual Private Server (VPS) with Linux
  • Image Hosting – Free image hosting site, anything goes
  • Freedom Hosting II – Anonymous Freehosting with PHP/MySQL Support
  • Free imageboard – apply here for free board on this forum, with basic janitor priveleges
  • Web Hosting — Web Hosting PHP5, MySQL, SFTP Access, .onion Domain. 24 hours free hosting.
  • TorShops – Get your own .onion store with full bitcoin integration.
  • Bittit – Host and sell your original pictures for Bitcoins.
  • Liberty’s Hackers – Service and Hosting Provider in onionland php5/mysql support request considered on a case by case.
  • CYRUSERV – Hosting service with an emphasis on security, open for business again.
  • TorVPS Shells — Free torified shell accounts, can be used for .onion hosting, IRC, etc.

 

 

Blogs / Essays

 

Social Networks

  • BlackBook – Social media site (The facebook of TOR)
  • Galaxy 2 – A revival of the old Galaxy community.
  • Facebook – The real Facebook’s Onion domain. Claim not to keep logs. Trust them at your peril.
  • MultiVerse Social Network – Social Network with anonymous IRC chat services as well as other features.
  • Friendica The friend network

 

Forums / Boards / Chans

  • Torchan – /b/, /i/, programming, revolution, tons of other boards
  • Torduckin0 #1st – Citadel BBS with chat and IM to support Torduckin.
  • InserTor – Tor pastebin clone. Create new paste, share code, share news. Public and Private pastes. Create encrypted paste (encrypted button only with java on) or paste with time limit (also burn on reading!)
  • Wall Street – Paypal accounts, credit cards, we have everything!!
  • Dark Nexus – Deep chat

 

Email / Messaging

  • Sigaint – Darknet email service that allows you to send and receive email without revealing your location or identity.
  • Mail2Tor – New Tor Mail Server to clear web. (Not working properly, delayed emails)
  • AnonMail – Anonymous premium email service like lavabit. (Not free).
  • TorBox – TOR only secure and private email service.
  • Lelantos Free @lelantos.org account.
  • MailTor – Free @mailtor.net account (webmail, smtp, pop3 and imap access).

 

Political Advocacy

 

WikiLeaks

 

Other

 

Audio – Music / Streams

 

Books

 

Drugs

 

Physical Goods

 

Digital GoodsCommercial Links

  • ccPal – CCs, CVV2s, Ebay, Paypals and more

Original Post: https://n0where.net/best-onion-links-deep-web/

How to Create a Virus Using the Assembly Language

The art of virus creation seems to be lost. Let’s not confuse a virus for malware, trojan horses, worms, etc. You can make that garbage in any kiddie scripting language and pat yourself on th…

Source: How to Create a Virus Using the Assembly Language

Ten Process Injection Techniques: A Technical Survey Of Common And Trending Process Injection Techniques

Process Injection

Process injection is a widespread defense evasion technique employed often within malware and fileless adversary tradecraft, and entails running custom code within the address space of another process. Process injection improves stealth, and some techniques also achieve persistence. Although there are numerous process injection techniques, in this blog I present ten techniques seen in the wild that run malware code on behalf of another process. I additionally provide screenshots for many of these techniques to facilitate reverse engineering and malware analysis, assisting detection and defense against these common techniques.

1. CLASSIC DLL INJECTION VIA CREATEREMOTETHREAD AND LOADLIBRARY

This technique is one of the most common techniques used to inject malware into another process. The malware writes the path to its malicious dynamic-link library (DLL) in the virtual address space of another process, and ensures the remote process loads it by creating a remote thread in the target process.

DLL Injection

 

The malware first needs to target a process for injection (e.g. svchost.exe). This is usually done by searching through processes by calling a trio of Application Program Interfaces (APIs): CreateToolhelp32Snapshot, Process32First, and Process32Next. CreateToolhelp32Snapshot is an API used for enumerating heap or module states of a specified process or all processes, and it returns a snapshot. Process32First retrieves information about the first process in the snapshot, and then Process32Next is used in a loop to iterate through them. After finding the target process, the malware gets the handle of the target process by calling OpenProcess.

As shown in Figure 1, the malware calls VirtualAllocEx to have a space to write the path to its DLL. The malware then calls WriteProcessMemory to write the path in the allocated memory. Finally, to have the code executed in another process, the malware calls APIs such as CreateRemoteThread, NtCreateThreadEx, or RtlCreateUserThread. The latter two are undocumented. However, the general idea is to pass the address of LoadLibrary to one of these APIs so that a remote process has to execute the DLL on behalf of the malware.

CreateRemoteThread is tracked and flagged by many security products.  Further, it requires a malicious DLL on disk which could be detected.  Considering that attackers are most commonly injecting code to evade defenses, sophisticated attackers probably will not use this approach. The screenshot below displays a malware named Rebhip performing this technique.

 

rebhip worm

Figure 1: Rebhip worm performing a typical DLL injection
Sha256: 07b8f25e7b536f5b6f686c12d04edc37e11347c8acd5c53f98a174723078c365

 

2. PORTABLE EXECUTABLE INJECTION (PE INJECTION)

Instead of passing the address of the LoadLibrary, malware can copy its malicious code into an existing open process and cause it to execute (either via a small shellcode, or by calling CreateRemoteThread). One advantage of PE injection over the LoadLibrary technique is that the malware does not have to drop a malicious DLL on the disk. Similar to the first technique, the malware allocates memory in a host process (e.g. VirtualAllocEx), and instead of writing a “DLL path” it writes its malicious code by calling WriteProcessMemory. However, the obstacle with this approach is the change of the base address of the copied image. When a malware injects its PE into another process it will have a new base address which is unpredictable, requiring it to dynamically recompute the fixed addresses of its PE. To overcome this, the malware needs to find its relocation table address in the host process, and resolve the absolute addresses of the copied image by looping through its relocation descriptors.

 

process injection

 

This technique is similar to other techniques, such as reflective DLL injection and memory module, since they do not drop any files to the disk. However, memory module and reflective DLL injection approaches are even stealthier. They do not rely on any extra Windows APIs (e.g., CreateRemoteThread or LoadLibrary), because they load and execute themselves in the memory. Reflective DLL injection works by creating a DLL that maps itself into memory when executed, instead of relying on the Window’s loader. Memory Module is similar to Reflective DLL injection except the injector or loader is responsible for mapping the target DLL into memory instead of the DLL mapping itself. In a previous blog post, these two in memory approaches were discussed extensively.

When analyzing PE injection, it is very common to see loops (usually two “for” loops, one nested in the other), before a call to CreateRemoteThread.  This technique is quite popular among crypters (softwares that encrypt and obfuscate malware). In Figure 2, the sample unit test is taking advantage of this technique. The code has two nested loops to adjust its relocation table that can be seen before the calls to WriteProcessMemory and CreateRemoteThread. The “and 0x0fff” instruction is also another good indicator, showing that the first 12 bits are used to get the offset into the virtual address of the containing relocation block. Now that the malware has recomputed all the necessary addresses, all it needs to do is pass its starting address to CreateRemoteThread and have it executed.

 

unit test

Figure 2: Example structure of the loops for PE injection prior to calls to CreateRemoteThread
Sha256: ce8d7590182db2e51372a4a04d6a0927a65b2640739f9ec01cfd6c143b1110da

3. PROCESS HOLLOWING (A.K.A PROCESS REPLACEMENT AND RUNPE)

Instead of injecting code into a host program (e.g., DLL injection), malware can perform a technique known as process hollowing. Process hollowing occurs when a malware unmaps (hollows out) the legitimate code from memory of the target process, and overwrites the memory space of the target process (e.g., svchost.exe) with a malicious executable.

process hallowing

 

The malware first creates a new process to host the malicious code in suspended mode. As shown in Figure 3, this is done by calling CreateProcess and setting the Process Creation Flag to CREATE_SUSPENDED (0x00000004). The primary thread of the new process is created in a suspended state, and does not run until the ResumeThread function is called. Next, the malware needs to swap out the contents of the legitimate file with its malicious payload. This is done by unmapping the memory of the target process by calling either ZwUnmapViewOfSection or NtUnmapViewOfSection. These two APIs basically release all memory pointed to by a section. Now that the memory is unmapped, the loader performs VirtualAllocEx to allocate new memory for the malware, and uses WriteProcessMemory to write each of the malware’s sections to the target process space. The malware calls SetThreadContext to point the entrypoint to a new code section that it has written. At the end, the malware resumes the suspended thread by calling ResumeThread to take the process out of suspended state.

 

process hollowing

Figure 3: Ransom.Cryak performing process hollowing
Sha256: eae72d803bf67df22526f50fc7ab84d838efb2865c27aef1a61592b1c520d144

4. THREAD EXECUTION HIJACKING (A.K.A SUSPEND, INJECT, AND RESUME (SIR))

This technique has some similarities to the process hollowing technique previously discussed. In thread execution hijacking, malware targets an existing thread of a process and avoids any noisy process or thread creations operations. Therefore, during analysis you will probably see calls to CreateToolhelp32Snapshot and Thread32First followed by OpenThread.

thread execution

 

After getting a handle to the target thread, the malware puts the thread into suspended mode by calling SuspendThread to perform its injection. The malware calls VirtualAllocEx and WriteProcessMemory to allocate memory and perform the code injection. The code can contain shellcode, the path to the malicious DLL, and the address of LoadLibrary.

Figure 4 illustrates a generic trojan using this technique. In order to hijack the execution of the thread, the malware modifies the EIP register (a register that contains the address of the next instruction) of the targeted thread by calling SetThreadContext. Afterwards, malware resumes the thread to execute the shellcode that it has written to the host process. From the attacker’s perspective, the SIR approach can be problematic because suspending and resuming a thread in the middle of a system call can cause the system to crash. To avoid this, a more sophisticated malware would resume and retry later if the EIP register is within the range of NTDLL.dll.

generic trojan

Figure 4: A generic trojan is performing thread execution hijacking
Sha256: 787cbc8a6d1bc58ea169e51e1ad029a637f22560660cc129ab8a099a745bd50e

5. HOOK INJECTION VIA SETWINDOWSHOOKEX

Hooking is a technique used to intercept function calls. Malware can leverage hooking functionality to have their malicious DLL loaded upon an event getting triggered in a specific thread. This is usually done by calling SetWindowsHookEx to install a hook routine into the hook chain. The SetWindowsHookEx function takes four arguments. The first argument is the type of event. The events reflect the range of hook types, and vary from pressing keys on the keyboard (WH_KEYBOARD) to inputs to the mouse (WH_MOUSE), CBT, etc. The second argument is a pointer to the function the malware wants to invoke upon the event execution.The third argument is a module that contains the function. Thus, it is very common to see calls to LoadLibrary and GetProcAddress before calling SetWindowsHookEx. The last argument to this function is the thread with which the hook procedure is to be associated. If this value is set to zero all threads perform the action when the event is triggered. However, malware usually targets one thread for less noise, thus it is also possible to see calls CreateToolhelp32Snapshot and Thread32Next before SetWindowsHookEx to find and target a single thread. Once the DLL is injected, the malware executes its malicious code on behalf of the process that its threadId was passed to SetWindowsHookEx function. In Figure 5, Locky Ransomware implements this technique.

locky hook

Figure 5: Locky Ransomware using hook injection
Sha256: 5d6ddb8458ee5ab99f3e7d9a21490ff4e5bc9808e18b9e20b6dc2c5b27927ba1

6. INJECTION AND PERSISTENCE VIA REGISTRY MODIFICATION (E.G. APPINIT_DLLS, APPCERTDLLS, IFEO)

Appinit_DLL, AppCertDlls, and IFEO (Image File Execution Options) are all registry keys that malware uses for both injection and persistence. The entries are located at the following locations:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls
HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls
HKLM\Software\Microsoft\Windows NT\currentversion\image file execution options

AppInit_DLLs
Malware can insert the location of their malicious library under the Appinit_Dlls registry key to have another process load their library. Every library under this registry key is loaded into every process that loads User32.dll. User32.dll is a very common library used for storing graphical elements such as dialog boxes. Thus, when a malware modifies this subkey, the majority of processes will load the malicious library. Figure 6 demonstrates the trojan Ginwui relying on this approach for injection and persistence. It simply opens the Appinit_Dlls registry key by calling RegCreateKeyEx, and modifies its values by calling RegSetValueEx.

 

appint dll injection

Figure 6: Ginwui modifying the AppIniti_DLLs registry key
Sha256: 9f10ec2786a10971eddc919a5e87a927c652e1655ddbbae72d376856d30fa27c

 

AppCertDlls
This approach is very similar to the AppInit_DLLs approach, except that DLLs under this registry key are loaded into every process that calls the Win32 API functions CreateProcess, CreateProcessAsUser, CreateProcessWithLogonW, CreateProcessWithTokenW, and WinExec.

 

Image File Execution Options (IFEO)
IFEO is typically used for debugging purposes. Developers can set the “Debugger Value” under this registry key to attach a program to another executable for debugging. Therefore, whenever the executable is launched the program that is attached to it will be launched. To use this feature you can simply give the path to the debugger, and attach it to the executable that you want to analyze. Malware can modify this registry key to inject itself into the target executable. In Figure 7, Diztakun trojan implements this technique by modifying the debugger value of Task Manager.

 

dizkatun trojan

Figure 7: Diztakun trojan modifying IFEO registry key
Sha256: f0089056fc6a314713077273c5910f878813fa750f801dfca4ae7e9d7578a148

7. APC INJECTION AND ATOMBOMBING

Malware can take advantage of Asynchronous Procedure Calls (APC) to force another thread to execute their custom code by attaching it to the APC Queue of the target thread. Each thread has a queue of APCs which are waiting for execution upon the target thread entering alterable state. A thread enters an alertable state if it calls SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx, or WaitForSingleObjectEx functions. The malware usually looks for any thread that is in an alterable state, and then calls OpenThread and QueueUserAPC to queue an APC to a thread. QueueUserAPC takes three arguments: 1) a handle to the target thread; 2) a pointer to the function that the malware wants to run; 3) and the parameter that is passed to the function pointer. In Figure 8, Amanahe malware first calls OpenThread to acquire a handle of another thread, and then calls QueueUserAPC with LoadLibraryA as the function pointer to inject its malicious DLL into another thread.

AtomBombing is a technique that was first introduced by enSilo research, and then used in Dridex V4. As we discussed in detail in a previous post, the technique also relies on APC injection. However, it uses atom tables for writing into memory of another process.

 

alamanahe apc injection

Figure 8: Almanahe performing APC injection
Sha256: f74399cc0be275376dad23151e3d0c2e2a1c966e6db6a695a05ec1a30551c0ad

8. EXTRA WINDOW MEMORY INJECTION (EWMI) VIA SETWINDOWLONG

EWMI relies on injecting into Explorer tray window’s extra window memory, and has been used a few times among malware families such as Gapz and PowerLoader. When registering a window class, an application can specify a number of additional bytes of memory, called extra window memory (EWM). However, there is not much room in EWM. To circumvent this limitation, the malware writes code into a shared section of explorer.exe, and uses SetWindowLong and SendNotifyMessage to have a function pointer to point to the shellcode, and then execute it.

The malware has two options when it comes to writing into a shared section. It can either create a shared section and have it mapped both to itself and to another process (e.g., explorer.exe), or it can simply open a shared section that already exists. The former has the overhead of allocating heap space and calling NTMapViewOfSection in addition to a few other API calls, so the latter approach is used more often. After malware writes its shellcode in a shared section, it uses GetWindowLong and SetWindowLong to access and modify the extra window memory of “Shell_TrayWnd”. GetWindowLong is an API used to retrieve the 32-bit value at the specified offset into the extra window memory of a window class object, and SetWindowLong is used to change values at the specified offset. By doing this, the malware can simply change the offset of a function pointer in the window class, and point it to the shellcode written to the shared section.

Like most other techniques mentioned above, the malware needs to trigger the code that it has written. In previously discussed techniques, malware achieved this by calling APIs such as CreateRemoteThread, QueueUserAPC, or SetThreadContext. With this approach, the malware instead triggers the injected code by calling SendNotifyMessage. Upon execution of SendNotifyMessage, Shell_TrayWnd receives and transfers control to the address pointed to by the value previously set by SetWindowLong. In Figure 9, a malware named PowerLoader uses this technique.

 

get window long

 

powerloader

Figure 9: PowerLoader injecting into extra window memory of shell tray window
Sha256: 5e56a3c4d4c304ee6278df0b32afb62bd0dd01e2a9894ad007f4cc5f873ab5cf

 

9. INJECTION USING SHIMS

Microsoft provides Shims to developers mainly for backward compatibility. Shims allow developers to apply fixes to their programs without the need of rewriting code. By leveraging shims, developers can tell the operating system how to handle their application. Shims are essentially a way of hooking into APIs and targeting specific executables. Malware can take advantage of shims to target an executable for both persistence and injection. Windows runs the Shim Engine when it loads a binary to check for shimming databases in order to apply the appropriate fixes.

There are many fixes that can be applied, but malware’s favorites are the ones that are somewhat security related (e.g., DisableNX, DisableSEH, InjectDLL, etc). To install a shimming database, malware can deploy various approaches. For example, one common approach is to simply execute sdbinst.exe, and point it to the malicious sdb file. In Figure 10, an adware,  “Search Protect by Conduit”,  uses a shim for persistence and injection. It performs an “InjectDLL” shim into Google Chrome to load vc32loader.dll. There are a few existing tools for analyzing sdb files, but for the analysis of the sdb listed below, I used python-sdb.

 

shim DLL

Figure10: SDB used by Search Protect for injection purposes
Sha256: 6d5048baf2c3bba85adc9ac5ffd96b21c9a27d76003c4aa657157978d7437a20

10. IAT HOOKING AND INLINE HOOKING (A.K.A USERLAND ROOTKITS)

IAT hooking and inline hooking are generally known as userland rootkits. IAT hooking is a technique that malware uses to change the import address table. When a legitimate application calls an API located in a DLL, the replaced function is executed instead of the original one. In contrast, with inline hooking, malware modifies the API function itself. In Figure 11, the malware FinFisher, performs IAT hooking by modifying where the CreateWindowEx points.

 

Figure 11: FinFisher performing IAT hooking by changing where CreateWindowEx points to
Sha256: f827c92fbe832db3f09f47fe0dcaafd89b40c7064ab90833a1f418f2d1e75e8e

CONCLUSION

In this post, I covered ten different techniques that malware uses to hide its activity in another process. In general, malware either directly injects its shellcode into another process or it forces another process to load its malicious library. In Table 1, I have classified the various techniques and provided samples to serve as a reference for observing each injection technique covered in this post. The figures included throughout the post will help the researcher recognize the various techniques when reversing malware.

process injection techniques

Table1: Process injection can be done by directly injecting code into another process, or by forcing a DLL to be loaded into another process

Attackers and researchers regularly discover new techniques to achieve injection and provide stealth. This post detailed ten common and emerging techniques, but there are others, such as COM hijacking. Defenders will never be “done” in their mission to detect and prevent stealthy process injection because adversaries will never stop innovating.

At Endgame, we constantly research advanced stealth techniques and bring protections into our product. We layer capabilities which detect malicious DLLs that load on some persistence (like AppInit DLLs, COM Hijacks, and more), prevent many forms of code injection in real-time via our patented shellcode injection protection, and detect malicious injected payloads running in memory delivered through any of the above techniques through our patent-pending fileless attack detection techniques. This approach allows our platform to be more effective than any other product on the market in protecting against code injection, while also maximizing resiliency against bypass due to emerging code injection techniques.

Original Post: https://www.endgame.com/blog/technical-blog/ten-process-injection-techniques-technical-survey-common-and-trending-process

Apk Downloader from CNET.com containing malware

Apk Downloader from CNET

http://download.cnet.com/archive/3000-20432_4-15802255.html 

2017_07_16_14_41_21_Apk_Downloader_Free_download_and_software_reviews_CNET_Download.com

The publisher as below:

2017_07_16_14_42_03_Apk_Downloader_Free_download_and_software_reviews_CNET_Download.com

After you download, unzip and execute the Apk Downloader, apkserver.exe will be created in c:\windows\

VirusTotal result:

2017_07_16_14_49_48_Antivirus_scan_for_869e36efd53483bef92cf5671a406d290d65bce63be63be390270f20e677e

Payload Security result:

2017_07_16_14_53_40_Free_Automated_Malware_Analysis_Service_powered_by_VxStream_Sandbox_Viewing_

Anlyz result:

2017_07_16_14_54_47_anlyz_REM

Reported to CNET just now, waiting for there reply. Will keep you guy update.

Basic Malware Analysis Tools

In the upcoming 6 hacking tutorials we will be talking about basic malware analysis and we will start with discussing the many different Basic Malware Analysis Tools which are available. A Malware Analyst is someone highly skilled in reverse engineering malware to get a deep understanding about what a certain piece of malware does and how it does it. To become a malware analyst it is important to have a good understanding of operating systems, software, networking, programming in general, malware in general and assembly language. Assembly language is the low level programming code between the high level programming code and the machine instructions. In other words: it translates the high level language into machine instructions which will be processed by your computers hardware.

 

In this tutorial we will be looking at simple but popular tools for basic static malware analysis like: PEiD to detect packers, Dependency Walker to view dynamically linked functions, Resource Hacker to view the malware’s resources and PEview and FileAlyzer to examine the PE file headers and sections. These tools are used for basic static malware analysis to try to determine the kind of malware and it’s function without actually running the malware. Running and analysing the malware will be covered in laters tutorials. After this we will be looking at the malware analysis advanced tools available for advanced static analysis and advanced dynamic malware analysis in the next article: Dynamic Malware Analysis Tools. Note that we will be discussing the tools in general first and get into detailed tutorials later. In the upcoming tutorials we will be using them on sample malware in detailed step-by-step hacking tutorials.

For now the Malware Analysis Tutorials will be divided in 6 subjects and will be released the upcoming few weeks:

  1. Basic Malware Analysis Tools
  2. Dynamic Malware Analysis Tools
  3. Malware Types Explained
  4. Basic Malware Analysis
  5. Advanced Static Malware Analysis
  6. Advanced Dynamic Malware Analysis

Basic Malware Analysis Tools

As promised we’ll be looking at the following basic malware analysis tool: PEiD, Dependency Walker, Resource Hacker, PEview and FileAlyzer. For your convenience we will supply a download link for the tools as well so you can get your malware analysis toolbox ready for the upcoming tutorials. Be sure to subscribe to our newsletter as we will be updating this list and our toolbox along the upcoming tutorials.

PEiD

Basic Malware Analysis Tools - PEiD

PEiD is a small application which is used to detect common packers, cryptors and compilers. Malware writers often attempt to pack or obfuscate their malware to make it harder to detect and to analyse. The current version of PEiD can detect over 470 different signatures in PE files which are loaded from a txt file called userdb. The official PEiD website is not active anymore but you can download PEiD-0.95-20081103 from Hacking Tutorials using the following download link: PEiD-0.95-20081103.zip (7946 downloads)

You need to replace the userdb.txt file with the following file to add the signatures; PEiD Userdb (6807 downloads)

Dependency Walker

Basic Malware Analysis Tools - Dependency Walker

Another great basic malware analysis tool is Dependency Walker. Dependency Walter is a free application which can be used to scan 32 and 64 bit Windows modules (.exe, .dll, .ocx, etc.) and is used to list all the imported and exported functions of a module. Dependency Walker also displays the dependencies of the file which will result in a minimum set of required files. Depency Walker also displays detailed information about those files including the filepath, version number, machine type, debug information etc.

Dependency Walker can be downloaded here.

Resource Hacker

Basic Malware Analysis Tools - Resource Hacker

Resource Hacker, or sometimes called ResHackers, is a free application used to extract resources from Windows binaries. Resource Hacker can extract, add and modify most resources like strings, images, menus, dialogs, VersionInfo, Manifest resources etc. The latest version of Resource Hacker, which is version 4.2.4, was release in July 2015.

Resource Hacker can be downloaded using the following link: Resource Hacker

PEview

Basic Malware Analysis Tools - PEview

PEview is a free and easy to use application to browse through the information stored in Portable Executable (PE) file headers and the different sections of the file. In the following tutorials we will be learning how to read those headers when we’re examining real malware.

PEview can be downloaded using the following link: PEview.

FileAlyzer

Basic Malware Analysis Tools - FileAlyzer

FileAlyzer is also a free tool to read information stored in PE file headers and sections but offers slightly more features and functionality than PEview. Nice features are the VirusTotal tab which can be used to submit malware to VirusTotal for analysis and the functionality to unpack UPX and PECompact packed files. And yes, Filealyzer is a typo but the developer decided to stick with the name which is kinda cool in our opinion.

FileAlyzer can be downloaded using the following link: FileAlyzer.

More Basic Malware Analysis Tools

Needless to say is that we’ve covered only  a very small portion of the Basic Malware Analysis Tools available. In the upcoming few days we will be adding more tools for you to download and explore so be sure to subscribe to Hacking Tutorials to stay informed about updates. If you have any questions regarding the tools we encourage you to ask them here. Also let us know when you have suggestions for other tools. You can do so by replying to this post.

Thanks for reading and see you in the next chapter: Dynamic Malware Analysis Tools

Original Post: http://www.hackingtutorials.org/malware-analysis-tutorials/basic-malware-analysis-tools/

Gartner Top Technologies for Information Security 2017 vs 2016

Gartner Top Technologies 2017 vs 2016

Gartner Identifies the Top Technologies for Security in 2017

http://www.gartner.com/newsroom/id/3744917

OpenPuff – Professional Steganography Tool

OpenPuff is a professional steganography tool, with unique features you won’t find among any other free or commercial software. OpenPuff is 100% free and suitable for highly sensitive data covert transmission.

OpenPuff - Professional Steganography Tool

The tool contains deniable steganography, carrier chains, unique layers of security and obfuscation, multiple carrier formats, is portable and is freeware (ad-free).

Features

 

  • Carrier chains – Data is split among many carriers. Only the correct carrier sequence enables unhiding. Moreover, up to 256Mb can be hidden, if you have enough carriers at disposal. Last carrier will be filled with random bits in order to make it undistinguishable from others.
  • Supported formats – Images, audios, videos, flash, adobe.
  • Layers of security – Data, before carrier injection, is encrypted (1), scrambled (2), whitened (3) and encoded (4).
  • Extra security (Deniable steganography) – Top secret data can be protected using less secret data as a decoy.
  • Source code – This program relies on the libObfuscate system-independent open-source library.

Details

  • HW seeded random number generator (CSPRNG)
  • Deniable steganography
  • Carrier chains (up to 256Mb of hidden data)
  • Carrier bits selection level
  • Modern multi-cryptography (16 algorithms)
  • Multi-layered data obfuscation (3 passwords)
  • X-squared steganalysis resistance
  • 256bit+256bit symmetric-key cryptography (with KDF4 password extension)
  • 256bit symmetric-key data scrambling (CSPRNG-based shuffling)
  • 256bit symmetric-key data whitening (CSPRNG-based noise mixing)
  • Adaptive non-linear carrier bit encoding
  • Images (BMP, JPG, PCX, PNG, TGA)
  • Audio support (AIFF, MP3, NEXT/SUN, WAV)
  • Video support (3GP, MP4, MPG, VOB)
  • Flash-Adobe support (FLV, SWF, PDF)
  • Native portable structure (no installation, registry keys, .ini files)
  • Runs in user mode with DEP on
  • Multithread support (up to 16 CPUs) = Faster processing
  • Spyware/adware-free
  • Fully redistributable
  • OpenSource core crypto-library (libObfuscate)

You can download OpenPuff here:

OpenPuff.zip

Or read more here.

Original Post: https://www.darknet.org.uk/2017/07/openpuff-professional-steganography-tool/

Deep Dive into a Custom Malware Packer

Introduction

In this article we will look in depth at a Custom Packer used by a Malware that was recently found in the wild. This packer is interesting for several reasons. It uses several layers of packers including the well-known UPX Packer which is only used to mask the underlying custom packers.

It also uses a clever way of injecting code into a remote process and resuming its execution from there. I have included necessary screenshots with snippets of assembly language code sections along with comments, stack parameters for API calls and views of memory dump. This will help in following the article while the unpacking method is described.

An Overview

Since the unpacking method is described in depth and there are several layers, I am giving a high level overview of the algorithm at first before going in depth.

  1. It uses a UPX packer which is used only for the purpose of masking the underlying custom packers. UPX packers as we know can be easily unpacked.
  2. The first layer of a custom packer uses a lot of code which has been placed only to increase the size of code we have to go through while reversing. With the help of few example code snippets, this has been explained. It’s used to deter reverse engineering.
  3. It stores the encrypted subroutine at a particular offset within itself. This subroutine is later decrypted and executed.
  4. In the second stage, the decrypted subroutine performs another level of unpacking. There is an encrypted malicious executable embedded inside the main image which is decrypted in two phases.
  5. After the decryption of the malicious executable, it proceeds to modify the header of the main image. It copies the various sections of the malicious executable like PE Header.text.rsrc.reloc to the start of main image.
  6. It then calls the AddressOfEntry point of the malicious executable. This code will spawn a new process, svchost.exe in a suspended state.
  7. It then proceeds to inject the malicious code in svchost.exe process and resume its execution.

Unpack the UPX

This executable uses a clever way of packing. It uses a well-known packer called UPX which is detected by most automated sandboxes and packer identifiers like PEiDand ProtectorID.

So, we start by unpacking the UPX packer. As already known, UPX packers can be unpacked using the ESP + hardware breakpoint trick. So, let us unpack it using this method.

This is how the Original Entry Point of a UPX packed binary looks:

We step over the PUSHAD instruction which will save the contents of all the registers on the stack.

Once we step over PUSHAD, we will follow ESP in memory dump and set a Hardware Breakpoint at the WORD present at that memory location. The reason this is done is: once the unpacking completes, POPAD instruction will be executed that will restore the contents of registers.

As a result, this memory location will be accessed and modified. So, we set the hardware breakpoint as shown in the screenshot below:

Once we run the executable after setting the hardware breakpoint, we break at the following memory location:

Next, we set a breakpoint at 0x004170B4 to skip over the loop.

Once we step over this, we reach the Original Entry Point at 0x00402690.

In most cases, this is the unpacked executable and now you can start stepping through the code to understand the malware. So, let’s continue with that.

Identification of Unnecessary Code Sections

This is how our Original Entry Point at 0x00402690 looks like after unpacking UPX:

This looks good, so let’s continue.

After tracing the code further from OEP, we reach a CALL to the subroutine at address, 0x00401020.

In most cases, you would reach the code corresponding to malware after this. So, let’s see:

This subroutine contains a lot of code which has been placed to deter reverse engineering. For instance, if you check the section of code below:

1
2
3
MOV DWORD PTR SS:[EBP-58],F47117C3
CMPDWORD PTR SS:[EBP-58],F8EC0A77
JNZSHORT Shipment.0040108F     ; this jump will always be taken

It moves a constant DWORD into a memory location, [EBP-58] and then compares it with another constant DWORD, followed by a check for whether they are unequal. Since they will always be unequal, the Jump will be taken.

Similar lines of code were observed in multiple places in the subroutine which were added only to increase the size of code that we have to go through while reversing.

Similarly, another section of code:

1
2
3
4
5
MOV DWORD PTR SS:[EBP-54],F498C7E5
MOV EDX,DWORD PTR SS:[EBP-54]
IMUL EDX,DWORD PTR SS:[EBP-54]
ADD EDX,DWORD PTR SS:[EBP-54]
MOV DWORD PTR SS:[EBP-54],EDX

It moves a constant DWORD into [EBP-54], and then moves it to EDX, multiplies with itself, and then adds it to the result and stores back in the memory address.

However, this value is not relevant to us for reversing.

Decryption of Custom Unpacking Subroutine

Proceeding in this way and skipping over sections of code that use code similar to above, we reach a CALL to VirtualAlloc with the stack parameters as shown below:

It allocates a new memory with a size of 0x1830 bytes.

It is important to note that, VirtualAlloc is a good way of locating the Original Entry Point of an executable. The reason being, while unpacking it’s common to see a CALL to VirtualAlloc which allocates a new memory region. Encrypted data is copied to this memory location and then decrypted.

If the data at this memory location is executed later on, then it means we have unpacked it or reached the original entry point (it’s possible that there is more code obfuscation later).

In our case, the call to VirtualAlloc() allocates a new memory region at base address, 0x00C50000

Tracing the code further we reach a CALL to subroutine at 0x004016F0 as shown below:

Tracing this subroutine further, we locate our first decryption routine:

The encrypted data is stored at memory address, 0x405028as shown below:

Here is a high level overview of the decryption subroutine:

  1. It reads one DWORD at a time from the encrypted data.
  2. It modifies the DWORD by passing it to a subroutine at 0x00401A80
  3. The DWORD modified above is passed to a second subroutine at 0x004014E0
  4. The final modified DWORD is written to the newly allocated memory region at 0x00C50000
  5. There is a counter which is used to keep track of the number of DWORDs read from the Encrypted Data section. A total of 0x12A DWORDs are read, modified and written to the newly allocated memory region.

Below is the code explanation with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
MOV EDX,DWORD PTR SS:[EBP-C]; counter
MOV EAX,DWORD PTR DS:[EDX*4+405028]; read a DWORD from the encrypted data stored at 0x0405028
MOV DWORD PTR SS:[EBP-54],EAX
MOV ECX,DWORD PTR SS:[EBP-54]
PUSH ECX; pass the DWORD to the subroutine
CALL Shipment.00401A80  ; First DWORD modification routine
ADD ESP,4
MOV DWORD PTR SS:[EBP-54],EAX; modified DWORD is stored in [EBP-54]
MOV DWORD PTR SS:[EBP-58],0AB6C
LEA EDX,DWORD PTR SS:[EBP-58]
MOV DWORD PTR SS:[EBP-5C],EDX
MOV EAX,DWORD PTR SS:[EBP-58]
OR EAX,9E2F; OR 0AB6C with 9E2F
MOV ECX,DWORD PTR SS:[EBP-5C]
MOV EDX,DWORD PTR DS:[ECX]
AND EDX,DWORD PTR SS:[EBP-58]
IMUL EAX,EDX
ADD EAX,DWORD PTR SS:[EBP-58]
MOV DWORD PTR SS:[EBP-58],EAX
MOV EAX,DWORD PTR SS:[EBP-54]
PUSH EAX; pass the modified DWORD to the subroutine
CALL Shipment.004014E0
ADDESP,4
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
XOR EAX,DWORD PTR DS:[EDX+ECX*4]
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
MOV DWORD PTR DS:[EDX+ECX*4],EAX
MOV EAX,DWORD PTR SS:[EBP-C]; get the previous value of counter
ADD EAX,1; increment the counter
MOV DWORD PTR SS:[EBP-C],EAX
MOV ECX,DWORD PTR SS:[EBP-C]
CMP ECX,DWORD PTR SS:[EBP-1C]; check if counter <= 0x12A (total size of the data to be decrypted)
JB SHORT Shipment.004017F2
MOV DWORD PTR SS:[EBP-8],F4617F55
MOV EDX,DWORD PTR SS:[EBP-8]
IMUL EDX,DWORD PTR SS:[EBP-8]
MOV DWORD PTR SS:[EBP-20],EDX
MOV ESP,EBP
POP EBP
RETN

Here is the first DWORD modification routine:

Here is an explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
PUSH EBP
MOV EBP,ESP
SUB ESP,14
ROL DWORD PTR SS:[EBP+8],6; the encrypted DWORD is rotated left by 6 positions
MOV DWORD PTR SS:[EBP-8],96
MOV DWORD PTR SS:[EBP-4],FFCE4D33
MOV EAX,DWORD PTR SS:[EBP-8]
CMP EAX,DWORD PTR SS:[EBP-4]
JNZ SHORT Shipment.00401AAC ; this jump will always take place
.....
MOV EAX,DWORD PTR SS:[EBP+8]; the encrypted DWORD is moved back in EAX
MOV ESP,EBP
POP EBP
RETN

The result of the first DWORD modification routine is passed to the second subroutine at: 0x004014E0

Here is the second DWORD modification routine:

Here is the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
PUSH EBP
MOV EBP,ESP
SUB ESP,38
MOV DWORD PTR SS:[EBP-8],6375; this is the XOR key used to modify the DWORD
MOV DWORD PTR SS:[EBP-10],FBCA85D0
MOV EAX,DWORD PTR SS:[EBP-10]
AND EAX,7D; 0xFBCA85D0 AND 0x7D
MOV ECX,DWORD PTR SS:[EBP-10]
AND ECX,0D4; 0xFBCA85D0 AND 0x0D4
SUB EAX,ECX
IMUL EAX,DWORD PTR SS:[EBP-10]
MOV DWORD PTR SS:[EBP-10],EAX
MOV DWORD PTR SS:[EBP-18],6D
MOV EDX,DWORD PTR SS:[EBP-10]
IMUL EDX,DWORD PTR SS:[EBP-18]
ADD EDX,DWORD PTR SS:[EBP-18]
MOV DWORD PTR SS:[EBP-18],EDX
MOV EAX,DWORD PTR SS:[EBP+8]; value of the first modified DWORD
XOR EAX,DWORDPTR SS:[EBP-8]; XOR the first modified DWORD with 0x6375
MOV DWORD PTR SS:[EBP+8],EAX; store it back in memory
MOV DWORD PTR SS:[EBP-4],5

After returning from the second subroutine, it will write this modified DWORD in the newly allocated memory region:

Here is an explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
ADD ESP,4
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
XOR EAX,DWORDPTRDS:[EDX+ECX*4]
MOV ECX,DWORD PTR SS:[EBP-C]
MOV EDX,DWORD PTR SS:[EBP+8]
MOV DWORDPTRDS:[EDX+ECX*4],EAX
MOV EAX,DWORD PTR SS:[EBP-C]; get the previous value of counter
ADD EAX,1; increment the counter
MOV DWORD PTR SS:[EBP-C],EAX
MOV ECX,DWORD PTR SS:[EBP-C]
CMP ECX,DWORD PTR SS:[EBP-1C]; check if counter <= 0x12A (total size of the data to be decrypted)
JB SHORT Shipment.004017F2
MOV DWORD PTR SS:[EBP-8],F4617F55
MOV EDX,DWORD PTR SS:[EBP-8]
IMUL EDX,DWORD PTR SS:[EBP-8]
MOV DWORD PTR SS:[EBP-20],EDX
MOV ESP,EBP
POP EBP
RETN

Once the decryption has completed, we have the decrypted data present at 0x00C50000 as shown below:

Now, it calls the decrypted subroutine at 0x00C50000 as shown below:

Unpacking the Custom Packer – Stage 1

Once we step into this subroutine we are the first decrypted subroutine as shown below:

Here is an explanation of the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
NOP
NOP
NOP
NOP
NOP
PUSH EBP
MOV EBP, ESP
SUB ESP,18
PUSH EBX
PUSH ESI
PUSH EDI
CALL00C50013
POP EBX
SUB EBX,13; EBX points to the start of decrypted subroutine, 00C50000
CALL 00C501FA; Get kernel32.dll base address and API addresses
OR EAX,EAX
JE 00C50143
CALL DWORDPTRDS:[EBX+491]; kernel32.GetProcessHeap
MOV DWORD PTR SS:[EBP-4],EAX
PUSH DWORD PTR SS:[EBP+10]; 0x5244
PUSH8
PUSH DWORD PTR SS:[EBP-4]; base address of the heap
CALL DWORDPTRDS:[EBX+495]; Allocate the heap
OR AX,EAX
JE 00C50143
MOV DWORD PTR SS:[EBP-18],EAX

We will step into the first subroutine at 0x00C501FA which is used to get the address of different APIs:

Here is explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
PUSH EBP
MOV EBP, ESP
SUB ESP,4
CALL00C502BF; Get base address of kernel32.dll
MOV DWORD PTR SS:[EBP-4],EAX
PUSH EAX; Base address of kernel32.dll
CALL00C5030E; Get address of GetProcAddress
MOV DWORDPTRDS:[EBX+48D],EAX; Store this address in memory
LEA EAX,DWORDPTRDS:[EBX+426]; Pointer to LoadLibrary
PUSH EAX
PUSH DWORD PTR SS:[EBP-4]
CALL DWORDPTRDS:[EBX+48D]; Get Address of LoadLibrary
MOV DWORDPTRDS:[EBX+489],EAX
LEA EAX,DWORDPTRDS:[EBX+442]; Pointer to HeapAlloc in the image
PUSH EAX
PUSH DWORD PTR SS:[EBP-4]
CALL DWORDPTRDS:[EBX+48D]; GetAddress of HeapAlloc
....
MOV DWORDPTRDS:[EBX+491],EAX
MOV EAX,1
JMP SHORT00C502BD
XOR EAX,EAX
LEAVE
RETN

It uses the subroutine at 0x00C502BF to get the base address of kernel32.dll by parsing the PEB structure. This is a common method used by shellcodes and various malwares to dynamically find the base address of kernel32.dll:

The next subroutine at address, 00C5030Eis used to get the address of GetProcAddress API which will later be used to get the address of different APIs.

It proceeds to find the address of different APIs using GetProcAddress as shown below:

All these function pointers are stored in memory, as shown below:

Now that it has retrieved the pointers to some APIs, it starts with another decryption routine.

The code of malicious executable is located at memory address, 0x004054D0

First, let’s take a look at this encrypted data:

If you look at this encrypted data, you will observe a pattern. After every DWORD, we have the WORDs 0x0050 or 0x0051 corresponding to ASCII values P. or Q.respectively.

Now, let’s check the decryption routine. It is mentioned below with comments:

1
2
3
4
5
6
7
8
9
10
MOV ESI,DWORD PTR SS:[EBP+C]; points to encrypted data (0x004054d0)
MOV EDI,DWORD PTR SS:[EBP-18]; points to the newly allocated heap
MOV ECX,DWORD PTR SS:[EBP+10]; size of the encrypted data
ADD ESI,2; skip the WORDs 0x0050 or 0x0051
LODS DWORDPTRDS:[ESI]; read the encrypted DWORD into EAx
ROL EAX,6; rotate left by 6
XOR EAX,DWORD PTR SS:[EBP+14]; XOR with 0x278C
STOS DWORDPTRES:[EDI]; store the result in destination
SUB ECX,6; decrement counter by 6 (4 for the DWORD and 2 to skip over the WORDs, 0x0050 or 0x0051)
JNZ SHORT00C5004

This subroutine is easy to understand. It reads a DWORD from the encrypted data, rotates it left by 6 bit positions and XORs it with the XOR key 0x278C.

The resulting data is stored at the newly allocated heap at address, 0x0018F520:

As can be seen in the screenshot above, it is the MZ header of the malicious executable. However, it is not completely decrypted.

Unpacking the Custom Packer – Stage 2

Once the first decryption routine has completed, it proceeds to allocate a new heap, which will be used to store the final decrypted malicious executable:

1
2
3
4
5
6
7
8
9
10
PUSH DWORD PTR SS:[EBP+18]; 0x8C00
PUSH 8
PUSH DWORD PTR SS:[EBP-4]
CALL DWORDPTRDS:[EBX+495]; Allocate a new Heap
OR EAX,EAX
JE 00C50143
MOV DWORD PTR SS:[EBP-14],EAX
PUSH DWORD PTR SS:[EBP-14]; pointer to newly allocated heap
PUSH DWORD PTR SS:[EBP-18]; pointer to first stage of decrypted data
CALL 00C5036E; second decryption routine

Let’s check the second decryption routine at address, 0x00C5036E:

Here is an explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
PUSHAD
MOV ESI,DWORD PTR SS:[ESP+24]; source points to first stage of decryption
MOV EDI,DWORD PTR SS:[ESP+28]; points to newly allocated heap
CLD
MOV DL,80
XOR EBX,EBX
MOVS BYTEPTRES:[EDI],BYTEPTRDS:[ESI]; move one byte from source to destination
MOV BL,2
CALL 00C503F1
JNB SHORT00C5037C
XOR ECX,ECX
CALL 00C503F1
JNB SHORT00C503AB
XOR EAX,EAX
CALL00C503F1
JNB SHORT00C503BB
MOV BL,2
INC ECX
MOV AL,10
CALL00C503F1
ADC AL,AL
JNB SHORT00C5039D
JNZ SHORT00C503E7
STOS BYTEPTRES:[EDI]
JMP SHORT00C5037F
CALL00C503FD
SUB ECX,EBX
JNZ SHORT00C503C4
CALL00C503FB
JMP SHORT00C503E3
LODS BYTEPTRDS:[ESI]; move the byte from source into EAX
SHR EAX,1; shift right the value in EAX by one position
JE SHORT00C5040D exit the decryption routine ifthis value inEAX is 0
ADC ECX,ECX
JMP SHORT00C503E0
XCHG EAX,ECX

After this subroutine has completed, we will have the decrypted malicious executable at address, 0x00194780

This decrypted malicious executable is located at the address, 0x00194780

Self-Modification of Main Image Header

It is followed by a call to VirtualProtect to modify the protection of the first 0xC000bytes at 0x400000 (ImageBaseAddress) to 0x40 which corresponds to PAGE_EXECUTE_READWRITE as shown below:

The stack parameters are:

Now it sets the first 0xC000 bytes at the ImageBaseAddress to null bytes (0x00). This is done because it will be overwritten with the contents of the decrypted malicious executable.

1
2
3
4
XOR AL,AL; AL stores the nullbyte
MOV EDI,DWORD PTR SS:[EBP+8]; EDI points to the ImageBaseAddress, 0x400000
MOV ECX,DWORD PTR SS:[EBP-8]; 0xC000
REP STOS BYTE PTR ES:[EDI]; repeatedly store 0xC000 null bytes at 0x400000

After this, it will copy the sections of the decrypted executable to the ImageBaseAddress one by one (PE header, .text, .rsrc, .reloc and so on):

1
2
PUSH DWORD PTR SS:[EBP-14]; pointer to new decrypted image
CALL 00C5016F

Using the below Subroutine, it will get the SizeOfHeaders of the decrypted executable.

1
2
3
4
5
6
7
8
PUSH EBP
MOV EBP, ESP
MOV EAX,DWORD PTR SS:[EBP+8]
MOV EAX,DWORDPTRDS:[EAX+3C]
ADD EAX,DWORD PTR SS:[EBP+8]; pointer to PE header of new decrypted image
MOV EAX,DWORDPTRDS:[EAX+54]; SizeOfHeaders, 0x400
LEAVE
RETN4

It then proceeds to copy the PE header from the decrypted executable to the ImageBaseAddress:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PUSH EAX; 0x400
PUSH DWORD PTR SS:[EBP-14]; pointer to decrypted image
PUSH DWORD PTR SS:[EBP+8]; pointer to base address of image of main module
CALL 00C50157
PUSH EBP
MOV EBP, ESP
PUSH ECX
PUSH ESI
PUSH EDI
MOV ECX,DWORD PTR SS:[EBP+10]
MOV EDI,DWORD PTR SS:[EBP+8]
MOV ESI,DWORD PTR SS:[EBP+C]
REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]; copy 0x400 bytes from decrypted executable to Image Base Address
POP EDI
POP ESI
POP ECX
LEAVE
RETN0C

It proceeds in this way to copy the .text.rsrc and .reloc sections one by one to the Image Base Address:

  1. Copy 0x8400 bytes of .text section from the decrypted image to 0x401000
  2. Copy 0x200 bytes of .rsrc section from the decrypted image to 0x40A000
  3. copy 0x200 bytes of .reloc section from the decrypted image to 0x40B000

Decrypted Malicious Executable

It then calls the AddressOfEntryPoint of the malicious executable:

1
2
3
4
MOV EAX,DWORD PTR SS:[EBP-10]; pointer to PE header
MOV EAX,DWORDPTRDS:[EAX+28]; address of entry point
ADD EAX,DWORD PTR SS:[EBP+8]
CALL EAX; 0x408D60

Let’s now trace the code inside the malicious executable:

This section of code will first retrieve the addresses of following APIs:

NtQueryInformationProcess

ZwReadVirtualMemory

ZwMapViewofSection

NtCreateSection

ZwResumeThread

It then proceeds to create a new process called svchost.exe in Suspended State (Process Creation Flag is set to 0x4):

Stack parameters:

Code Injection into New Process

This virus uses an interesting way to inject the malicious code in the newly created process and later resume the execution of it. Unlike most malwares which make use of WriteProcessMemory() to inject the code in the Process Address Space of a remote process, it does not call WriteProcessMemory() at all.

It also helps in bypassing certain security mechanisms where system drivers detect the code injection by monitoring WriteProcessMemory API invocations in user mode.

Once the new process is created, it queries the remote process to retrieve Process Information by calling ZwQueryInformationProcess API as shown below:

The stack parameters are:

The output will be stored at the memory address 0x0012FD9C. It uses this to get the Process Environment Block address of the remote process as shown below:

In this case, PEB of svchost.exe is at the address, 0x7FFDA000

It then proceeds to find the ImageBaseAddress of svchost.exe by reading the value at offset 0x8 in PEB

1
2
3
4
5
6
7
8
9
10
11
12
13
14
MOV DWORD PTR SS:[EBP-AC],EAX
MOV EDX,DWORD PTR SS:[EBP-14]; pointer to PEB base address of new process
ADD EDX,8; PEB + 8 has the ImageBaseAddress of svchost.exe
MOV DWORD PTR SS:[EBP-DC],EDX
LEA EAX,DWORD PTR SS:[EBP-9C]
PUSH EAX
PUSH 4
LEA ECX,DWORD PTR SS:[EBP-8C]
PUSH ECX
MOV EDX,DWORD PTR SS:[EBP-DC]
PUSH EDX
MOV EAX,DWORD PTR SS:[EBP-A8]
PUSH EAX
CALL DWORD PTR SS:[EBP-B4]; ZwReadVirtualMemory

Stack parameters:

It reads 0x4 bytes from the address 0x7FFDA008 in the process address space of the svchost.exe process and stores it at 0x0012FD28 as shown below:

The ImageBaseAddress of svchost.exe is 0x10000000

It then proceeds to create a new section within itself using ZwCreateSection API:

Stack parameters:

The handle of the new section is stored at the address 0x0012FD94:

After this, it calls ZwMapViewOfSection to map the newly created section (handle, 0x150) in itself.

Stack parameters:

The base address of the mapped view of Section is stored at 0x0012FD30:

The address of the mapped view of section is: 0x00A20000. The size of mapped view is 0x7CA0.

It then proceeds to copy 0x7CA0 bytes from 0x004010B0 to the mapped view at 0x00A20000:

1
2
3
4
5
6
7
8
9
10
11
12
13
MOV EDX,DWORD PTR SS:[EBP-7C]
ADD EDX,1
MOV DWORD PTR SS:[EBP-7C],EDX
MOV EAX,DWORD PTR SS:[EBP-7C]
CMP EAX,DWORD PTR SS:[EBP-2C]; check if counter <= 0x7CA0
JNBSHORT Shipment.00408F88
MOV ECX,Shipment.004010B0
ADD ECX,DWORD PTR SS:[EBP-7C]
MOV EDX,DWORD PTR SS:[EBP-84]
ADD EDX,DWORD PTR SS:[EBP-7C]
MOV AL,BYTEPTRDS:[ECX]; read one byte at a time from 0x004010B0
MOV BYTEPTRDS:[EDX],AL; store it in the view
JMP SHORT Shipment.00408F60

Once this is done, the mapped view contains the code of malicious subroutine:

It uses another call to ZwMapViewofSection to map its section (that has the code of malicious subroutine) into svchost.exe process:

Stack parameters:

Here, 0x150 is the handle of the section object and 0x154 is the handle of svchost.exe process.

The base address of the newly mapped view will be present at 0x0012FD30:

Our malicious subroutine has been mapped at the address 0x000C0000 in svchost.exe process address space.

In this way, even without using a call to WriteProcessMemory it was able to inject the code of malicious subroutine in process address space of svchost.exe.

It then calls VirtualAlloc to allocate memory in its own Process Address Space:

Stack parameters:

The new memory region is allocated at address, 0x00C60000

Modification of Original Entry Point in Remote Process

It proceeds with a call to ZwReadVirtualMemory to read the PE Header of svchost.exe process and store it at the newly allocated memory region, 0x00C60000

Stack parameters:

Once it has the PE Header of svchost.exe at address, 0x00C60000, it parses that to find the size of Image of svchost.exe process:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
MOV DWORD PTR SS:[EBP-AC],EAX
MOV ECX,DWORD PTR SS:[EBP-80]
MOV EDX,DWORD PTR SS:[EBP-80]
ADD EDX,DWORDPTRDS:[ECX+3C]; EDX points to PE Header of svchost.exe
MOV DWORD PTR SS:[EBP-88],EDX
MOV EAX,DWORD PTR SS:[EBP-88]
MOV ECX,DWORDPTRDS:[EAX+50]; At offset 0x50 in the PE Header we have the SizeOfImage.
MOV DWORD PTR SS:[EBP-30],ECX
MOV EDX,DWORD PTR SS:[EBP-88]
MOV EAX,DWORDPTRDS:[EDX+28]; AddressOfEntry point of svchost.exe
MOV DWORD PTR SS:[EBP-B8],EAX
LEA ECX,DWORD PTR SS:[EBP-9C]
PUSH ECX
MOV EDX,DWORD PTR SS:[EBP-30]
PUSH EDX
MOV EAX,DWORD PTR SS:[EBP-80]
PUSH EAX
MOV ECX,DWORD PTR SS:[EBP-8C]
PUSH ECX
MOV EDX,DWORD PTR SS:[EBP-A8]
PUSH EDX
CALL DWORD PTR SS:[EBP-B4];ntdll.ZwReadVirtualMemory

Stack parameters:

It reads 0x6000 bytes (SizeOfImage of svchost.exe) from the ImageBaseAddress of svchost.exe and stores at 0x00C60000 in its Process Address Space.

The original entry point was located previously and stored in [EBP-88]. The RVA of AddressOfEntryPoint of svchost.exe is 0x2509.

Let’s look at the disassembly of the code at Original Entry Point in svchost.exe at present:

It is important to note here. Most malwares in the recent past used GetThreadContext() and SetThreadContext() to modify the Original Entry Point of the Primary Thread which will be executed in the remote process to trigger the malicious code execution. In this case, it does not use calls to GetThreadContext()and SetThreadContext() APIs to modify the Original Entry Point at all.

It then proceeds to modify the code at original entry point using the code below:

Here is the explanation of the code with comments:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
MOV DWORD PTR SS:[EBP-AC],EAX
MOV ECX,DWORD PTR SS:[EBP-80]
ADD ECX,DWORD PTR SS:[EBP-B8]; Original Entry Point of svchost.exe
MOV BYTE PTR DS:[ECX],90; opcode of NOP
MOV EDX,DWORD PTR SS:[EBP-80]
ADD EDX,DWORD PTR SS:[EBP-B8]
MOV BYTE PTR DS:[EDX+1],68; opcode of PUSH Memory Address
MOV EAX,DWORD PTR SS:[EBP-80]
ADD EAX,DWORD PTR SS:[EBP-B8]
MOV ECX,DWORD PTR SS:[EBP-28]
MOV DWORDPTRDS:[EAX+2],ECX; pointer to code of subroutine which was already mapped into new process
MOV EDX,DWORD PTR SS:[EBP-80]
ADD EDX,DWORD PTR SS:[EBP-B8]
MOV BYTE PTR DS:[EDX+6],0C3; opcode of RET
MOV DWORD PTR SS:[EBP-7C],0
JMP SHORT Shipment.00409131

After modification, the disassembly of the code at the Original Entry Point looks like shown below:

As can be seen, the OEP is modified so that it jumps to the subroutine at address 0x0C0000 and executes it. 0xC0000 is the location at which the malicious subroutine was injected previously in svchost.exe process.

It then makes another call to ZwCreateSection to create a new section within itself with the section handle, 0xEC.

Then it calls ZwMapViewOfSection and maps this newly created section at the address, 0x00A30000.

Once this is done, it will copy the bytes from the previously modified PE header of svchost.exe to this location.

It then calls ZwMapViewOfSection once again to map the bytes at 0x00A30000 to the ImageBaseAddress of svchost.exe process as shown below:

Stack parameters:

Now, the modified PE header has been written to the process address space of svchost.exe

It then calls ZwResumeThread to resume the execution of primary thread in svchost.exe.

This Primary Thread executes from the Original Entry Point of svchost.exe. Since that was modified previously to redirect the execution to malicious injected subroutine, it proceeds to successfully execute the malicious code within the context of svchost.exe

Debugging the Remote Process

Once it calls ZwResumeThread the execution of malicious subroutine is resumed in the context of svchost.exe process. To be able to debug it we need to modify the Original Entry Point before the code is injected in svchost.exe process.

This is how the code can be patched.

Please note that the memory addresses in the steps below may differ from the analysis done before because this was a new debugging session. The algorithm remains the same.

  1. It calls VirtualAlloc()to allocate a new memory region at 0x00C90000
  2. It calls ZwReadVirtualMemory to read 0x1000 bytes from the svchost.exe process into the newly allocated memory region.
  3. It then calls ZwReadVirtualMemory again to read SizeOfImage (0x6000) bytes from svchost.exe process into the newly allocated memory region at 0x00C90000.
  4. It then creates a new section within itself by calling ZwCreateSection.
  5. It maps the view of the newly created section by calling ZwMapViewOfSection which is mapped at the base address 0x01190000.
  6. It then proceeds to modify the Original Entry Point in the newly allocated memory region.
  7. After this, it copies 0x6000 bytes from the newly allocated memory region at 0x00C90000 to the mapped view at 0x01190000
  8. We need to patch the bytes in the mapped view which will be mapped to the Original Entry Point in remote process. In our case, it will be the bytes at 0x01192509.

    At present we have at address, 0x01192509

    1
    2
    3
    01192509 90         NOP
    0119250A 68 00000C00     PUSH 0C0000
    0119250F C3         RETN

    We will patch with EB FE which is a short relative cyclic jump as shown below:

  9. It again calls ZwMapViewOfSection to map the section object to the remote process.
  10. It then resumes the thread in remote process by calling ZwResumeThread.The original entry point in remote process will be 0x01002509. Since we patched the bytes before, the code execution will pause at the Original Entry Point.

    We will now be able to attach our Debugger to svchost.exe process. Let us now patch the bytes at the Original Entry Point in remote process and restore them:

    After patching, we set a breakpoint at the OEP and run, so that we break at the OEP:

    Now we can proceed with debugging the malicious subroutine in svchost.exe process.

Conclusion

After reading this article you should be able to unpack malwares which use a similar technique to pack their code and prevent debugging.

It also allows us to see the new ways in which malware authors are trying to bypass the AV and prevent analysis of malwares.

Original Post: http://resources.infosecinstitute.com/deep-dive-into-a-custom-malware-packer/

Up ↑