{
	"id": "18448718-cb18-481d-8f11-bc188fd3e087",
	"created_at": "2026-04-06T00:08:07.56848Z",
	"updated_at": "2026-04-10T03:20:37.991645Z",
	"deleted_at": null,
	"sha1_hash": "9a25c2fde0dce8cc65ebda2dfeed4b1f970a4c9e",
	"title": "Your Facebook connection is now secured! Thank you for your support!",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 260201,
	"plain_text": "Your Facebook connection is now secured! Thank you for your\r\nsupport!\r\nBy Jaromír Hořejší 19 Jun 2013\r\nArchived: 2026-04-05 13:27:23 UTC\r\nYour Facebook connection is now secured! Thank you for your support!\r\nThe title of this blog post may make you think that we will discuss the security of your Facebook account. Not this\r\ntime. However, I will analyze an attack which starts with a suspicious email sent to the victim's email account.\r\nThe incoming email has the following subject, 'Hey \u003cname\u003e your Facebook account has been closed!' or 'Hi\r\n\u003cname\u003e your Facebook account is blocked!'. The email has a ZIP file attachment with name \u003cname\u003e.zip, which\r\ncontains a downloader file named \u003cname\u003e.exe. \u003cname\u003e stands for a random user name. After a user downloads\r\nand executes the executable file, he is presented with the message saying that \"Your Facebook connection is now\r\nsecured! Thank you for your support!\" It tries to convince you that there was a problem with your Facebook\r\naccount, which was later successfully solved by executing the application from the email attachment.\r\nLet's look inside the executable file!\r\nUnlike many other malware samples, which use various malware cryptors ( see an article about the interesting\r\none), this malware sample does not use any cryptor. Instead, when observing the instruction flow, we notice many\r\nuseless registry computations and memory operations, which make it harder to analyze the sample. All text strings\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 1 of 12\n\nand names are encrypted in the malicious file and decrypted on the fly, when needed. In the figure below, you can\r\nsee many registry and memory operations from address 0x408a8c to 0x408aca, whose purpose is to make it\r\ndifficult to understand the original function of the code.\r\nWhenever I get a suspicious file, I start OllyDbg and begin analyzing the file. In the case of this sample, I loaded\r\nit in OllyDbg, made it run and the following error message box appeared.\r\nThen I tried to figure out what could be wrong with the sample I just started to analyze. In the beginning, there is a\r\nloop with 0x109 = 265 iterations. In each iteration, a new thread is created.\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 2 of 12\n\nEach thread executes its own thread function, in which it creates a manual-reset event object ( CreateEventA ),\r\nwhich requires the use of functions ResetEvent or SetEvent to change the event state. Later on, the function\r\nWaitForSingleObject with timeout 0x2710 = 10000 ms = 10 seconds makes the thread wait for setting the state of\r\nthe event manually. If the state of the event is set or if its timeout expires, a DWORD value at addressOfProcedure\r\nis XORed with a certain value unique for each thread. These per-thread unique values are taken from\r\narrayOfDwords table, which starts at address 0x422488 ( file offset 0x20a88 ).\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 3 of 12\n\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 4 of 12\n\nAn application then sets events for the four given threads, which causes function WaitForSingleObject to end\r\nimmediately. DWORD at addressOfProcedure is then XORed with the four corresponding values from\r\narrayOfDwords. After these four XOR operations, addressOfProcedure contains the address of function which will\r\nbe called by the main program.\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 5 of 12\n\nIn our situation, the thread to be woken up are 0xbf, 0xd4x 0xd3x 0xf5. In arrayOfDwords, the thread unique\r\nvalues are stored at addresses\r\n0x20a88 + 0xbf*4 = 0x20d84\r\n0x20a88 + 0xd4*4 = 0x20dd8\r\n0x20a88 + 0xd3*4 = 0x20dd4\r\n0x20a88 + 0xf5*4 = 0x20e5c\r\nfrom where we can get per-thread unique values, which after being XORed give us the following result:\r\n0x9329c591 XOR 0xc3b12028 XOR 0x732eb78b XOR 0x23f618f2 = 0x00404ac0\r\nTherefore the next address of execution will be 0x404ac0.\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 6 of 12\n\nWhile 261 out of 265 created threads are still sleeping (and waiting for the event being set or timeout interval to\r\nelapse) just four threads are woken up, and these threads compute the function address which will be called.\r\nOllyDbg cannot handle this situation correctly, computes the wrong destination address and therefore displays the\r\nabove mentioned error message. After 10 seconds, timeouts of all threads will elapse and addressOfProcedure will\r\nbe modified to an invalid address value, however, it will happen after the program already jumped to address\r\n0x404ac0 and DWORD value at addressOfProcedure is no longer important.\r\nAfter executing the procedure from address 0x404ac0, the main program body begins. The program flow can be\r\nsplit into three main branches. At first, the program tries to find out, if it was executed with a command line\r\nparameter containing string WATCHDOGPROC. If yes, the left (red) branch is chosen. If not, the right (green)\r\nbranch is executed.\r\nIf WATCHDOGPROC string in command line parameters was not found, then there is another branch asking if\r\nthe name of the current executable is usfqvololjv.exe. If not, we take the left (red) branch.\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 7 of 12\n\nIn this (left) branch, the file copies itself into %APPDATA%\\ltrhborczvnt\\usfqvololjv.exe, executed itself,\r\nestablishes persistence via registry key, displays the message \"Your Facebook connection is now secured! Thank\r\nyou for your support! Facebook\" and terminates.\r\nThe whole process is repeated again, but now the condition where the current program name is compared with\r\nusfqvololjv.exe is satisfied. We can see that usfqvololjv.exe copies itself under another name tjsotyw.exe and\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 8 of 12\n\nexecutes it with commandline parameter \"WATCHDOGPROC usfqvololjv.exe\".\r\nNow it becomes clear that usfqvololjv.exe is a master process and tjsotyw.exe is a slave process.\r\nThe master process (usfqvololjv.exe) then continues into an internet communication loop, which generates traffic\r\nto seemingly legitimate websites. The URL address is always in format \u003cWORD1\u003e\r\n\u003cWORD2\u003e.net/forum/search.php?email=\u003cEMAIL_ADDRESS\u003e\u0026method=post\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 9 of 12\n\nThe only task of the slave process is to check if the master process is running. If not, it restarts the master process.\r\nSimilarly, if the master process finds out that the slave process is not running, it restarts the slave process, so both\r\nprocesses keep running all the time, keeping an eye one on another.\r\nDomain names are generated by an algorithm, which uses the value of the current time. It starts with obtaining the\r\ncurrent Unix epoch time, which is a system for describing time, defined as the number of seconds that have\r\nelapsed since 00:00:00 Coordinated Universal Time (UTC), 1 January 1970. This number is then divided by\r\n0x200 = 512. Time is then divided into 512 seconds = 8 minutes 32 seconds long time chunks.\r\nLet's look at a particular example. For the time interval between \"Fri, 07 Jun 2013 12:45:52 GMT\" and \"Fri, 07\r\nJun 2013 12:54:23 GMT\", we get Unix epoch times between 0x51B1D600 and 0x51B1D7FF. After dividing any\r\nof the numbers between previously mentioned borders by 0x200 = 512, we get the following result.\r\nThe result (0x28d8eb) is then converted to its binary form and its last 15 binary digits are reordered (LSB bit of\r\n0x28d8eb goes to the 3rd position, the second LSB bit goes to 9th position, etc...). From the newly reordered 15\r\nbinary digits, the first 7 binary digits form a number, which gives us an index of the first word in the table of\r\nwords. The last 8 digits form another number, which gives us an index of the second word in the table of words.\r\nThese two words are then concatenated and a generic top-level domain .net is appended. The following picture\r\nillustrates how this domain-generation algorithm works.\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 10 of 12\n\nThe table of words is constant and encrypted in the original file. There are exactly 384 words in this table. As I\r\nmentioned above, from the current time stamp, a 15 digit number is generated. From this number, the first 7 digits\r\ngive us 128 possibilities (2^7), last 8 digits give us 256 possibilities (2^8), which makes a total of 128 + 256 = 384\r\nwords. If we choose one word from the first group and one word from the second group, it gives us a total count\r\nof 128 * 256 = 32768 possible domains, which may be contacted.\r\nHowever, the domain-generation algorithm does not try to connect to only one website withing a given 8.5 minute\r\ntime chunk. It tries 0x55 = 85 domains for numbers following 0x28d8eb, i.e. 0x28d8eb, 0x28d8ec, 0x28d8ed,\r\n0x28d8ee ... 0x28D93f. When all 85 possibilities are tried, then the time stamp is taken again and the whole\r\nprocess repeats.\r\nWhen a payload is downloaded after a successful connection to the generated domain, it is then written to\r\n%TEMP% directory, named g52\u003crandom\u003earg.exe and executed.\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 11 of 12\n\nConclusion:\r\nObfuscation does not need to be done with a cryptor. Filling the code with many useless registry and memory\r\ninstructions can do the same job.\r\nMalware authors often use domain-generation algorithms. If malware connects to just a few websites to get\r\nupdates or payloads, it is easy to block these domains and make malware ineffective. However, in the case of\r\ngenerating many domain names via domain-generation algorithms, it is often impossible to block all the randomly\r\ngenerated domains, either because of their huge number or because of the fact, that some of these domains may be\r\nlegitimate websites.\r\nSHAs:\r\nEC8B88A96D1B4917334BDAD7F2E580EAD4D9B71D111A1591BB5B965DA3E27CF6\r\nSource: https://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nhttps://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.avast.com/2013/06/18/your-facebook-connection-is-now-secured/"
	],
	"report_names": [
		"your-facebook-connection-is-now-secured"
	],
	"threat_actors": [],
	"ts_created_at": 1775434087,
	"ts_updated_at": 1775791237,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9a25c2fde0dce8cc65ebda2dfeed4b1f970a4c9e.pdf",
		"text": "https://archive.orkl.eu/9a25c2fde0dce8cc65ebda2dfeed4b1f970a4c9e.txt",
		"img": "https://archive.orkl.eu/9a25c2fde0dce8cc65ebda2dfeed4b1f970a4c9e.jpg"
	}
}