{
	"id": "a6d98a21-1c51-48cd-8f6e-4692d726dfdf",
	"created_at": "2026-04-06T00:14:54.045285Z",
	"updated_at": "2026-04-10T03:21:11.628821Z",
	"deleted_at": null,
	"sha1_hash": "d68c3cbb7e77f95b4df407c1308a6a52bde9138b",
	"title": "Virus Bulletin :: Bird's nest",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 195528,
	"plain_text": "Virus Bulletin :: Bird's nest\r\nBy Raul AlvarezFortinet, CanadaEditor: Martijn Grooten\r\nArchived: 2026-04-05 21:20:33 UTC\r\n2014-07-18\r\nAbstract\r\nUsually, prepending viruses are relatively easy to clean and remove – just cut off the prepended virus and, in\r\ntheory, the host file should be restored. However, in the case of prepending file infector Neshta, simply cutting the\r\nvirus off will not do the job. Raul Alvarez takes a close look at Neshta, and at why it can't be removed as simply as\r\nother prepending infectors.\r\nCopyright © 2014 Virus Bulletin\r\nTable of contents\r\nOne of the ways in which file infectors are categorized is by how they attach themselves to the host file. The\r\ncategories are: cavity, appending and prepending. A cavity virus infects a file by attaching itself to the available\r\nspaces in the host file, while an appending virus attaches its code at the end of the file, and of course, a prepending\r\nvirus can be seen at the beginning of the victim file.\r\nUsually, prepending viruses are easier to clean and remove from the infected file than the other types – just cut off\r\nthe prepended virus and, in theory, the host file should be restored.\r\nHowever, in the case of prepending file infector Neshta, simply cutting the virus off will not do the job. In this\r\narticle, we will take a closer look at Neshta, and at why it can’t be removed as simply as other prepending\r\ninfectors. Neshta is not new, yet we are still finding samples of it in the wild.\r\nSimple decryption\r\nBefore we go into the details of how Neshta prepends its code to a host file, let’s look into some of its\r\ninitialization routines.\r\nNeshta decrypts some of its encrypted data using a simple decryption algorithm. The algorithm has a loop that\r\ndecrypts each byte using the following routine:\r\nA variable is multiplied by 0x8088405 using signed integer multiplication. (The initial value of the variable\r\nis the counter, which is the number of bytes to decrypt.)\r\nThe product of the multiplication, plus 1, is saved as the next value of the variable for the next itera-tion.\r\nThe same product is multiplied by 0xFF to produce the decrypted byte, which is in the DL register.\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 1 of 7\n\nThe byte in the DL register is copied into the AL register, then it is XORed to the encrypted byte to get the\r\nequivalent decrypted version (see Figure 1).\r\nThe decryption algorithm is used several times to obtain the following relevant strings: ‘3582-490’, ‘exe’ and\r\n‘*.*’.\r\nFigure 1. Decryption.\r\n(Click here to view a larger version of Figure 1.)\r\nPreparing the %temp% folder\r\nThe malware opens a copy of itself using a combination of the GetModuleFileNameA and CreateFileA APIs. Note\r\nthat the file consists of the virus component and the host file. Then, Neshta extracts 41,472 (0xA200) bytes of the\r\nvirus component by reading it into memory using the ReadFile API.\r\nThis is followed by getting the size of the infected file using the FindFirstFileA API. This is an unusual method,\r\nsince the malware could just use a simple call to the GetFileSize API. Although the method works, the resulting\r\nWIN32_FIND_DATA structure contains the size of the file as well as other information.\r\nNext, Neshta gets the %temp% folder name using a call to the GetTempPathA API. This is followed by\r\nconcatenating one of the decrypted strings, ‘3582-490’, to the temporary folder, producing the pathname\r\n‘%temp%\\3582-490’. The malware checks if the pathname exists by calling the GetFileAttributesA API. If it\r\ndoesn’t, it creates the pathname using the CreateDirectoryA API.\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 2 of 7\n\nThis is followed by concatenating another decrypted string, ‘*.*’, producing ‘%temp%\\3582-490\\*.*’. Using a\r\ncombination of the FindFirstFileA and FindNextFileA APIs, the malware attempts to list all the files found in the\r\n‘%temp%\\3582-490\\’ folder, and tries to delete them one by one, using the DeleteFileA API.\r\nRestoring the host file\r\nAfter deleting all possible files that can be found in the ‘%temp%\\3582-490\\’ folder, the malware extracts the\r\nfilename of the current module from the result of the call to the GetModuleFileNameA API. The extracted\r\nfilename, such as ‘calc.exe’, is concatenated to the ‘%temp%\\3582-490\\’ folder, producing ‘%temp%\\3582-\r\n490\\calc.exe’. (Assuming that the current module is the infected version of the file, calc.exe.)\r\nThis is followed by creating ‘%temp%\\3582-490\\calc.exe’ using the CreateFileA API with GENERIC_WRITE\r\naccess in preparation for restoring the clean version of the host file.\r\nFocusing back on the infected module, Neshta gets the file size of the infected calc.exe using the GetFileSize API,\r\nand subtracts 41,472 (0xA200) bytes from it. The difference is used to set the file pointer to the last 41,472 bytes\r\nof the infected file. This is followed by reading 41,472 (0xA200) bytes of data from the file into the stack\r\nmemory.\r\nUsing the same decryption algorithm as discussed earlier, the malware decrypts the first 1,000 (0x3E8) bytes of\r\nthe recently read data. Instead of using the counter, the malware uses the value 0x5A4D77D7 as a seed (see Figure\r\n1).\r\nIt is worth mentioning that the first 1,000 (0x3E8) bytes are the only encrypted data in the host file. These bytes\r\ncomprise the MZ/PE header of the original host file.\r\nAfter the decryption, Neshta writes the 41,472 (0xA200) bytes to the ‘%temp%\\3582-490\\calc.exe’ file, including\r\nthe decrypted header.\r\nTo read the second block, the malware sets the file pointer 41,472 bytes from the beginning of the infected file\r\nusing the SetFilePointer API (basically skipping over the virus component). Then it calculates the size of the\r\nremaining content of the host file (calc.exe), and reads it into an allocated section of virtual memory using the\r\nReadFile API. Finally, it writes the second block to the ‘%temp%\\3582-490\\calc.exe’ file. Then the handles for\r\nboth files – infected and restored – are closed using the CloseHandle API.\r\nThe restored ‘%temp%\\3582-490\\calc.exe’ file is an exact copy of the original clean file (calc.exe). Note that\r\ncalc.exe is just one example of a file infected by Neshta. If another infected file, such as notepad.exe, is executed,\r\nit will also be restored in the ‘%temp%\\3582-490\\’ folder for this variant of the malware.\r\nNeshta executes the host file from the ‘%temp%\\3582-490\\’ folder to avoid raising suspicion that the file is\r\ninfected, using a call to the ShellExecuteA API.\r\nHosting svchost\r\nAfter restoring and executing the host file, Neshta gets the ‘%windows%’ folder name by calling the\r\nGetWindowsDirectoryA API. Then, using the same decryption algorithm, the malware generates the string\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 3 of 7\n\n‘svchost.com’ and concatenates it to the Windows folder name, producing ‘%windows%\\svchost.com’. Then, it\r\nchecks whether ‘%windows%\\svchost.com’ exists using the GetFileAttributesA API. If it does, the malware\r\ndeletes the file using the DeleteFileA API.\r\nAfter making sure that the ‘%windows%\\svchost.com’ file does not exist, the malware creates it using a call to the\r\nCreateFileA API with GENERIC_WRITE access.\r\nThe malware reads the virus component of the infected file into memory, as discussed earlier. These bytes are\r\nwritten to the ‘%windows%\\svchost.com’ file using the WriteFile API. Then, to finalize the routine, the malware\r\ncloses the handle of the file using the CloseHandle API.\r\nThe file ‘%windows%\\svchost.com’ is now an exact copy of the virus.\r\nModifying the shell key\r\nAfter dropping the virus component as svchost.com, the malware generates the string\r\n‘exefile\\shell\\open\\command’ using the same decryption algorithm. Then it opens the registry key\r\n‘HKEY_CLASSES_ROOT\\exefile\\shell\\open\\command’ using the RegOpenKeyExA API. Afterwards, another\r\nstring, ‘\"%1\" %*’, is generated using the same decryption algorithm.\r\nThis is followed by setting the registry key ‘HKEY_CLASSES_ROOT\\exefile\\shell\\open\\command’ with\r\n‘C:\\WINDOWS\\svchost.com \"%1\" %*’ as the data value using the RegSetValueExA API.\r\nIn a normal system installation, if the key ‘HKEY_CLASSES_ROOT\\exefile\\shell\\open\\command’ is missing or\r\ncorrupted, any attempt to execute an application will not work, and an error message will be displayed, as shown\r\nin Figure 2.\r\nFigure 2. In a normal system installation, an error message will be displayed when attempting to execute an\r\napplication if the ‘HKEY_CLASSES_ROOT\\exefile\\shell\\open\\command’ key is corrupted or missing.\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 4 of 7\n\nHowever, a system infected with Neshta will have the modified registry key\r\n‘HKEY_CLASSES_ROOT\\exefile\\shell\\open\\command’ with ‘C:\\WINDOWS\\svchost.com \"%1\" %*’. Since\r\nC:\\WINDOWS\\svchost.com is the virus itself, an application will run, with the virus becoming the parent process\r\nand the .exe file the child process. This is a unique method to make sure that the malware will run even after\r\nrestarting the system.\r\nCreating a mutex\r\nAnother pass to the decryption algorithm reveals the string ‘MutexPolesskayaGlush*.*’, which is used as the\r\nname of a mutex created using a call to the CreateMutexA API. This is used to avoid running multiple instances of\r\nthe malware.\r\nInfecting removable drives\r\nAfter creating the mutex, Neshta searches for available drives for infection. It lists the available logical drives in\r\nthe system using the GetLogicalDriveStringsA API. Using the GetDriveTypeA API, it skips the infection routine\r\nfor the CD-ROM drive, drive ‘A’ and drive ‘B’.\r\nWith the exception of the list of drives to avoid, the malware tries to infect the executable files found on any\r\nattached removable drives (such as USB flash drives), all connected hard disks, and mapped network shared\r\nfolders.\r\nThe malware traverses each folder in each drive searching for executable files for possible infection.\r\nSkipping unwanted folders\r\nIf an executable file with the ‘.exe’ extension name is found, Neshta gets its equivalent short path name using the\r\nGetShortPathNameA API. The short path name is the MS DOS-style naming convention. It has 8:3 form, where\r\neight is the number of characters in the filename and three is the number of characters in the extension name.\r\nThis is followed by getting the ‘%windows%’ folder name using the GetWindowsDirectoryA API. The malware\r\nskips the infection routine if the current short path name of the victim file contains the ‘%windows%’ folder name.\r\nIt also skips the infection routine if the victim file is inside the ‘%temp%’ folder and if the path name of the victim\r\nfile contains ‘PROGRA~1’ (the short name for ‘Program Files’).\r\nWhen the path name has passed the filtering, it gets the size of the victim file using the FindFirstFileA API. The\r\nfile size is taken from the resulting WIN32_FIND_DATA structure. Considering the file size, Neshta also skips the\r\ninfection routine if the size is less than or equal to 41,472 (0xA200) bytes, or greater than 10,000,000 (0x989680)\r\nbytes.\r\nThe following section discusses how the malware determines whether the victim is already infected or not.\r\nAvoiding reinfection\r\nInitially, Neshta opens the victim file using the CreateFileA API. Then it sets the file pointer 1,000 (0x3E8) bytes\r\nfrom the beginning of the file. Afterwards, it reads 256 (0x100) bytes into memory using the ReadFile API, and\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 5 of 7\n\ncloses the file using the CloseHandle API.\r\nTo avoid reinfection, the malware compares the 256 (0x100) bytes of the data read from the victim file against the\r\nvirus component’s data from the memory. If these bytes match, the malware will skip the infection routine.\r\nInfection routine\r\nOnce the victim file has passed through all the necessary filtering, it is ready for infection. The first thing the\r\nmalware does is to get the attributes of the victim file using the GetFileAttributesA API. If the file has an attribute\r\nof FILE_ATTRIBUTE_READONLY, the malware sets it back to 0, using the SetFileAttributesA API.\r\nUsing a series of calls to the ExtractIconA, GetIconInfo, GetObjectA, and DeleteObject APIs, the malware copies\r\nthe icon used by the victim file into memory as part of the virus component.\r\nSince Neshta is a prepending file infector, the first 41,472 (0xA200) bytes of each infected file belongs to the\r\nvirus. A different block of data near the end of the virus component is a copy of the icon of the infected host file.\r\nThis is followed by opening the victim file with GENERIC_READ | GENERIC_WRITE access using the\r\nCreateFileA API. The malware reads the first two bytes and checks whether the file is a valid executable file by\r\nchecking for the string ‘MZ’. Then, it sets the file pointer to the beginning of the file using the SetFilePointer API.\r\nThen, Neshta reads the first 41,472 (0xA200) bytes of the victim file using the ReadFile API. Using the\r\nencryption/decryption algorithm discussed earlier, the malware encrypts the first 1,000 (0x3E8) bytes of the\r\nrecently read data, with the constant value 0x5A4D77D7 as a seed. Note that this is the same seed as was used to\r\nrestore the original host file from the previous infection.\r\nA regular prepending virus pushes the content of the victim file down to the end of the file, and places the virus\r\ncomponent at the very beginning. However, instead of pushing the original bytes down, Neshta overwrites the first\r\n41,472 (0xA200) bytes of the victim file with the virus component, using a combination of the SetFilePointer (to\r\nmove the pointer to the beginning of the victim file) and WriteFile APIs.\r\nAfterwards, the malware sets the file pointer to the end of the victim file and writes another 41,472 (0xA200)\r\nbytes of data, once again using a combination of the SetFilePointer (to move the pointer to the end of the victim\r\nfile) and WriteFile APIs.\r\nThe data written at the end of the host file includes the newly encrypted 1,000 header bytes and the rest of the first\r\n41,472 (0xA200) bytes of the victim file. These bytes are the original content taken from the beginning of the file\r\nwhich were overwritten with the virus component.\r\nTo finalize the infection routine, the malware closes the handle of the now infected file.\r\nFinally, the malware traverses each folder in every selected drive to look for executable files to infect. After\r\ninfecting all possible files, the malware terminates the current process. Note that the restored host executable file\r\nis still running, thus the malware only terminates the virus component’s execution.\r\nWrap up\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 6 of 7\n\nAt first glance, Neshta looks like a simple prepending file infector. Detection of this malware is fairly easy since it\r\nis not polymorphic or metamorphic. In terms of cleaning, the encrypted header should be restored first and copied\r\nto the beginning of the infected file.\r\nHowever, closer inspection of its malicious code reveals that Neshta is tricky in nature. It has embedded garbage\r\ncode that works as a normal collection of instructions that are used throughout the virus body. It also uses several\r\nlinked function calls that only perform simple tasks.\r\nAs simple as it looks, one of the goals of the malware is to deter researchers from performing code analysis. In\r\nthis regard, even a piece of malware with a strong encryption algorithm may seem easier to analyse than Neshta,\r\nas once the algorithm is broken down, analysis is straightforward.\r\nIn the end, as the old adage says, ‘Patience is a virtue’.\r\nSource: https://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nhttps://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2014/08/bird-s-nest"
	],
	"report_names": [
		"bird-s-nest"
	],
	"threat_actors": [],
	"ts_created_at": 1775434494,
	"ts_updated_at": 1775791271,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d68c3cbb7e77f95b4df407c1308a6a52bde9138b.pdf",
		"text": "https://archive.orkl.eu/d68c3cbb7e77f95b4df407c1308a6a52bde9138b.txt",
		"img": "https://archive.orkl.eu/d68c3cbb7e77f95b4df407c1308a6a52bde9138b.jpg"
	}
}