{
	"id": "81e7781e-5c89-43a9-986c-8b79c9e4e219",
	"created_at": "2026-04-06T00:18:35.969914Z",
	"updated_at": "2026-04-10T13:12:00.715285Z",
	"deleted_at": null,
	"sha1_hash": "56f18d7bea6dcbb304f1eae9f12506f29ac9ee63",
	"title": "Supply Chain Trojan sc_trojan_jwjf",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 14160397,
	"plain_text": "Supply Chain Trojan sc_trojan_jwjf\r\nArchived: 2026-04-05 19:47:33 UTC\r\nutkonos\r\nIOCs: Gist\r\nOn July 18th, Socket published research on a phishing campaign which led to a compromise of a set of NPM\r\npackages which were related to the Prettier code formatting tool. The DLL trojan found in this attack as well other\r\nsamples as investigated below is designated as sc_trojan_jwjf .\r\nUpdate: Twitter user cyb3rjerry located the name of the malware, scavenger , according to parts of the PDB path\r\nfound in this sample:\r\nc3536b736c26cd5464c6f53ce8343d3fe540eb699abd05f496dcd3b8b47c5134\r\nYou can read all about it in the excellent blog here.\r\nPackage got-fetch\r\nIn addition to this part of the campaign, two versions of the got-fetch NPM package were compromised by the\r\nsame adversary:\r\nPackage Name Version\r\ngot-fetch 5.1.11\r\ngot-fetch 5.1.12\r\nPackage 5.1.11\r\nPackage: 3ca29a4036491bfb1cce9ddd2f355bb3cec80cc0dcd2915c456c25ca103cd273\r\nJavascript: fc1420c8e74cc15292e9d443b1aa04f697ecafc4e0b1c5d4794594717232c3b2\r\nFilename: install.cjs\r\nDLL: c4504c579025dcd492611f3a175632e22c2d3b881fda403174499acd6ec39708\r\nFilename: crashreporter.dll\r\nPackage 5.1.12\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 1 of 27\n\nPackage: af54ae60e996322a0f099b6e57fe32cc9fc07c12288c333904adf3cebf11d8dd\r\nJavascript: fc1420c8e74cc15292e9d443b1aa04f697ecafc4e0b1c5d4794594717232c3b2\r\nFilename: install.cjs\r\nDLL: 30295311d6289310f234bfff3d5c7c16fd5766ceb49dcb0be8bc33c8426f6dc4\r\nFilename: crashreporter.dll\r\nMalicious Javascript\r\nThe part of the malicious Javascript that executes the next stage DLL is identical in both files.\r\nMalicious DLL\r\nThe two DLLs collected from the got-fetch packages are almost identical to the DLLs found in the Prettier\r\ntoolchain packages. Here are the exported main functions side by side. The one on the right is from the Prettier\r\npackages.\r\nNote: The Binary Ninja plugin used to clean up annotations temporarily for nice screenshot is CleanShot. It isn’t a\r\nformal community plugin yet, and is still under development. If you have suggestions, please do share.\r\nAnalysis Focus: DLL\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 2 of 27\n\nThis part of the writeup will focus on the DLL found in the Prettier toolchain packages. These samples don’t run\r\neasily in most sandboxes due to an array of anti-analysis trickery.\r\nDLL: c68e42f416f482d43653f36cd14384270b54b68d6496a8e34ce887687de5b441\r\nFilename: node-gyp.dll\r\nAPI Hashing\r\nTo perform API hashing, the malware must access and parse the Process Environment Block (PEB). In the next\r\nfigure we can see the linear address of the PEB being read from gs:[0x60] . This is the first step towards\r\nclandestinely resolving APIs via hashes.\r\nThe API hashes used by this malware family are of two kinds. First, are the DLL name hashes. In the next figure,\r\nwe can see the API hash used to find ntdll.dll : 0xcd8fc5c4 . This hash does not appear in HashDB yet.\r\nIsolation of the algorithm and reporting of the hashes found in this malware family are on the todo list.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 3 of 27\n\nThe API hash is shown in the red highlight at the top of the figure above. And the red highlight at the bottom is the\r\nPE headers from ntdll.dll being copied onto the stack. This is where the export table address is accessed and\r\nthen used to resolve more API hashes.\r\nDetection Opportunity: Ntdll API Hash\r\nThe API hash used to locate ntdll.dll provides a nice detection opportunity. The following is a YARA rule that\r\nincorporates the instructions that use the API hash. This rule matches a number of other DLLs from this same\r\nmalware family outside of the ones from the Prettier and got-fetch NPM package. This is just an image of the first\r\ndraft YARA rule. You can access the current version with any revisions in the Gist that goes with this research.\r\nYou will also find updates lists of IOCs like file hashes and more.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 4 of 27\n\nHere are the results of ongoing YARA hunting using this rule. If you want fresh data, please look at the gist linked\r\nabove.\r\n0254abb7ce025ac844429589e0fec98a84ccefae38e8e9807203438e2f387950\r\n1aeab6b568c22d11258fb002ff230f439908ec376eb87ed8e24d102252c83a6e\r\n30295311d6289310f234bfff3d5c7c16fd5766ceb49dcb0be8bc33c8426f6dc4\r\n5bed39728e404838ecd679df65048abcb443f8c7a9484702a2ded60104b8c4a9\r\n75c0aa897075a7bfa64d8a55be636a6984e2d1a5a05a54f0f01b0eb4653e9c7a\r\n80c1e732c745a12ff6623cbf51a002aa4630312e5d590cd60e621e6d714e06de\r\n877f40dda3d7998abda1f65364f50efb3b3aebef9020685f57f1ce292914feae\r\n8c8965147d5b39cad109b578ddb4bfca50b66838779e6d3890eefc4818c79590\r\n90291a2c53970e3d89bacce7b79d5fa540511ae920dd4447fc6182224bbe05c5\r\n9ec86514d5993782d455a4c9717ec4f06d0dfcd556e8de6cf0f8346b8b8629d4\r\nc3536b736c26cd5464c6f53ce8343d3fe540eb699abd05f496dcd3b8b47c5134\r\nc4504c579025dcd492611f3a175632e22c2d3b881fda403174499acd6ec39708\r\nc68e42f416f482d43653f36cd14384270b54b68d6496a8e34ce887687de5b441\r\nd845688c4631da982cb2e2163929fe78a1d87d8e4b2fe39d2a27c582cfed3e15\r\ndd4c4ee21009701b4a29b9f25634f3eb0f3b7f4cc1f00b98fc55d784815ef35b\r\nNote: The Binary Ninja plugin I used to make the YARA rules is copy_yara_format_bytes.py. It doesn’t have a\r\nformal name yet and is under development. Feedback welcome! And hopefully it can mature into a community\r\nplugin.\r\nCast a Wider Net\r\nThe specific rule shown above hunts for how this malware family implements this particular API hash. However,\r\nto find other potential usages of this hash outside of this malware family or other potentially related malware\r\nfamilies, the bytes that the rule is looking for need to be more generalized. Therefore, adding a wildcard to the\r\nright nibble of the REX prefix on the cmp instruction and dropping the ModR/M byte completely make the\r\nsecond instruction more generalized. Then dropping the opcode entirely from the first instruction leaving the API\r\nhash immediate value alone makes it even more generalized. Interestingly, a number of different samples match\r\nthis generalized rule. Triage of these additional samples is on the todo list.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 5 of 27\n\nHere are the preliminary results of hunting using this generalized rule. These are not yet traiged and may contain\r\nsome false positives.\r\n102e68f5cfe15a1c9197f3684b5c1ab4335a3048e1f61661c29c885707933947\r\n437f5fa47b3249ca1927ae0e84840153281ce276daa568dc23a0ae8f48cdfd64\r\n4b65a3043f2ff69ecf250327c1ae98a362e37151b42ecab31a7f690a66bc317e\r\n638d6dce0d74f510f578616514ad836668834939024d4e61f6ad1a97f492a136\r\n6a01de1654da642537e46c917e7c5561360045964469ced616b2ab8191c95249\r\nccfc206bf555cd4500b0c4047ad4cd40a053bb9e18371ae7dd8fcb2433ae9a1b\r\nd594fcc51c7453ca5699d511143887268b1a7648202d08108b472b0996115c09\r\ne3a4bfc68cc89d340c19da35a73624e84c861c0b5c27a6c97bbd8a2c2985d2ad\r\nFunction Name API Hashes\r\nThe other type of API hash found in this malware family is a function name hash. These are used to resolve API\r\nfunctions and then store the address of the function in a variable on the stack that is used to call the function. The\r\nfirst one after the hash of ntdll.dll is ZwClose . This next figure shows the API hash at the top and the\r\nfunction address in rax at the bottom. The instruction pointer in the middle of the image shows the location on\r\nthe stack where the function address is about to be stored.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 6 of 27\n\nMalware Behavior Catalog: API Hashing\r\nThe Malware Behavior Catalog code for API Hashing is B0032.001. This is a type of anti-static analysis used for\r\nevasion and executable code obfuscation.\r\nAnti-Debugging Traps\r\nThere are quite a few anti-analysis, anti-debugging, and anti-vm techniques used in this malware family. If you\r\nfall into many of them, they lead to a null pointer trap. Each of the null pointer traps starts with an API hash of\r\nGetACP . The hash is 0xf330068a , but I have made an enum in Binary Ninja similar to ones that cxiao’s\r\nawesome plugin makes based on HashDB. I can then display the hash in a more readable form. The first\r\ninstruction near the bottom in yellow is the call to GetACP . This is a junk call that doesn’t do anything real.\r\nFinally, a data variable that I have named nullptr_trap is read from. This data variable is always null. Finally,\r\nthe instruction that attempts to dereference the pointer is at the bottom highlighted in red. This instruction raises\r\nan exception: C0000005 EXCEPTION_ACCESS_VIOLATION .\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 7 of 27\n\nYou can see the locations of the other debugger traps if you select the null data variable and check for other code\r\nreferences.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 8 of 27\n\nIsDebuggerPresent\r\nOne of the early traps can be hit if the debugger has not been hidden. The API hash for IsDebuggerPresent is\r\n0xc3da4ec4 and is shown in the next figure. The DLL name hash used along with this function name hash is\r\n0x1819ae87 and represents kernel32.dll .\r\nEncoded Configuration Strings\r\nThe malware hides its configuration in a series of quad word stack strings. The next figure shows the first example\r\nwhich encodes the string \\SCVNGR_VM . This string is later appended to the user’s temp directory path and stored\r\nfor later use.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 9 of 27\n\nBeingDebugged Flag\r\nThe next anti-debugging check is shown in the next figure. The address of the PEB is again read from gs:[0x60]\r\nat the top highlighted in yellow. Then the BeingDebugged boolean flag from the PEB structure is checked. If the\r\nflag is present, control flow takes you to an instance of the null pointer trap described above. To avoid this one,\r\njust use the hide command in x64dbg if you’re using that particular debugger.\r\nThe following figure shows the location of the BeingDebugged member of the _PEB struct.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 10 of 27\n\nThread Hide-and-Seek\r\nThe next anti-analysis trick has a number of different stages to it. First, it gets the handle for the current thread via\r\na call to GetCurrentThread located at 0x18000d136 . This call is shown in the next figure.\r\nNext the API hash for NtSetInformationThread , 0x96c7b422 is resolved at 0x18000d649 as shown in the next\r\nfigure.\r\nNext the API hash for ZwAllocateVirtualMemory , 0x95dd2b8c is resolved at 0x18000dc0b as shown in the\r\nnext figure.\r\nThis next figure is fairly complex. At the top highlighted in red is the call to ZwAllocateVirtualMemory located\r\non the stack. In green above it are the function call parameters. Then in the middle of this figure are a series of\r\nhard-coded immediate values which comprise the bytes of the function that makes the indirect syscall. The three\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 11 of 27\n\ninstructions highlighted in yellow are the two bytes of the syscall and then 0xc3 which is ret . Below, we will\r\nuse these instructions to hunt for other malware that uses this same technique. Finally, at the bottom highlighted in\r\nred is the call to the location where the syscall function was constructed in the allocated memory.\r\nIndirect Syscall\r\nTo really get a good look at the syscall in addition to analyzing it in the debugger, you need to dump the allocated\r\nmemory via the debugger, and then create a memory map segment in Binary Ninja. The next figure shows the\r\nconfiguration used for this new segment. The exact base address for the segment as found in the debugger is used\r\nhere as the segment start address. And the memory dump from the debugger is used as a file backing this mapped\r\nsegment.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 12 of 27\n\nThis next figure shows the function as it appears in the debugger.\r\nThe next figure shows the core of the anti-debugging technique used here. The input parameter shown in rdx is\r\n0x11 which is ThreadHideFromDebugger . If this call is made, your debugging session is over and everything\r\ngoes poof.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 13 of 27\n\nAnd then this next figure shows the function as it appears in Binary Ninja after creating a function in the newly\r\nmapped segment.\r\nTo make it easier to navigate between the mapped segment and the call in the malware DLL, you can create a\r\ncross reference manually. This cross reference is shown in the next figure.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 14 of 27\n\nAnti-Debugging Circumvention\r\nThis anti-debugging syscall can be circumvented by replacing the syscall opcode with two nop , 0x90 ,\r\ninstructions. However, this is not the optimal method for circumvention. According to Microsoft’s documentation\r\nfor NtSetInformationThread , the return value for this function when it succeeds is STATUS_SUCCESS or 0x0 . In\r\ncase the return value is checked or used elsewhere, replacing the two bytes for syscall with xor eax, eax is\r\nbetter. The instruction bytes for this are the same length as syscall , two bytes, 31C0 . Using this alternative\r\ninstruction means the STATUS_SUCCESS value of 0x0 is set in eax and the return value of the function is\r\ncorrect. The resulting modified function is shown in the next figure as seen in the debugger.\r\nHowever, because this function is dynamically generated, the above patching would need to be performed on the\r\nfly in the debugger. If you want to patch the file in advance so that the change is permanent, you must change the\r\ntwo bytes in the caller function. The two immediate values that represent the syscall instruction are where this\r\npatch needs to happen. The next figure shows those two locations patched apropriately as seen in the debugger.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 15 of 27\n\nDetection Opportunity: Indirect Syscall Immediate Obfuscation\r\nThe technique of hiding a syscall function as bytes hard-coded in immediate values presents a nice opportunity for\r\ndetection. This technique is reminiscent of stack strings where the characters of the string are obfuscated in\r\nimmediate values before being written to the stack. However, in this case, the immediate values are written to\r\nallocated memory and become a function. The following figure shows a YARA rule that targets this technique.\r\nThe actual rule rather than a PNG is provided in the gist linked to earlier.\r\nThe hunting results have not been fully triaged yet. This is on the todo list. However, a spot check shows that the\r\nrule is matching malware files that are outside of the malware family we’re analyzing here. The next figure shows\r\nthe match location as seen in Binary Ninja with the syscall bytes located in immediate values.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 16 of 27\n\nIncomplete Cleanup Loop\r\nAfter the syscall function returns, there is a curious little loop. It tries to cover the tracks left in the allocated\r\nmemory by overwriting the syscall function’s bytes with null values. What is interesting is the malware author\r\nappears to have not counted from zero. This leaves the 0xc3 return byte sitting around in the allocated memory\r\nafter the cleanup loop has done its work. The cleanup loop with the incorrect syscall function length is shown in\r\nthe next figure.\r\nThis next figure shows the contents of the allocated memory after the loop has completed. You can see the ret\r\nstill sitting there not overwritten.\r\nAnti-VM: Checking System Firmware Table\r\nAfter the cleanup loop, the malware allocates memory via a call to malloc . This call is located at 0x18000ddde\r\nand the memory is then zeroed out at 0x18000de2f . These are both shown in the next figure.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 17 of 27\n\nNext an API hash for GetSystemFirmwareTable is resolved from 0x2af0b331 . This function is called with the\r\ninput parameter RSMB which requests the raw SMBIOS table. This is later searched for various strings such as\r\nVMware, qemu, and QEMU. Modifying the contents of the allocated memory to obscure any of these strings\r\ncircumvents this technique. As the malware checks for strings it makes calls to IsBadReadPtr which it resolved\r\nfrom the API hash 0x5aee4c2d .\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 18 of 27\n\nIn addition to checking the firmware table. The malware also checks for the presence of a series of DLL names\r\nthat correspond to security software, Windows SDK, and Windows Server.\r\nDLL Name Software\r\nSbieDll.dll Sandboxie\r\nSxIn.dll Qihoo 360\r\nSf2.dll AVG/Avast\r\nsnxhk.dll Avast\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 19 of 27\n\nDLL Name Software\r\ncmdvrt32.dll COMODO\r\nwinsdk.dll Windows SDK\r\nwinsrv_x86.dll Windows Server\r\nOHarmony.dll Lib.Harmony\r\nDumper.dll Unknown\r\nvehdebug-x86_64.dll VEH Debugger for CoSMOS\r\nThese strings can be seen in the next figure as shown in the debugger.\r\nAnti-VM: Advanced Vector Extensions (AVX) Instructions\r\nThe last dll name in the list above is stored in an obfuscated string like the rest. However, the last two instructions\r\nas shown in this next figure lead to Advanced Vector Extensions (AVX) instructions. These can raise an illegal\r\ninstruction exception if the sandbox or VM being used is not configured to allow them. The instructions are\r\nhighligted at the bottom in red and use registers such as ymm0 .\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 20 of 27\n\nDecoding Configuration Strings\r\nAfter slogging through all the anti-analysis trickery, I noticed that basically each capability and each encoded\r\nstring is totally context independent. The malware is not keeping score in any way to force you to jump through\r\nall the hoops. Therefore, one way to decode the strings is just to go straight to them and execute in the debugger\r\nfrom the start of the encoded string to the location where it stores the decoded string on the stack for later use. In\r\nthe next figure we’re at the first jump at the start of the big function where everything happens. The first set of\r\nencoded strings is at address 0x18000c20d and encodes the \\SCVNGR_VM string. Therefore, we modify the\r\ninstruction pointer to move directly to the start of the encoded string. Finally, we execute until the location where\r\nthe string is stored for later use.\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 21 of 27\n\nDecoding Configuration Strings - Another Method\r\nI started watching a YouTube video by JershMagersh about making a Binary Ninja emulation plugin. I got a few\r\nminutes into the video when he describes the core concept: using the vstack unit in Binary Refinery. I will have to\r\ngo back and watch the rest of the video some time, but that provided the inspiration for the following inelegant\r\nkludge that doesn’t work in all cases. I made a Binary Ninja plugin called BinjaDump a bit ago that lets me dump\r\nbytes from different locations and functions in different ways to stuff like HexFiend, 010editor, DogBolt, and\r\nSpectra Analyze. Why not test the concept of using Binary Refinery on these encoded strings? After all the bits of\r\ncode were dumped to little files, I used the following Binary Refinery command line incantation. I would call the\r\nresults not awesome, and not terrible.\r\nemit binjadump*.dat [ | vstack -a x64 -S 0x25000 [ | scope 2 | terminate | terminate H:86 | peek -Qr ]]\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 22 of 27\n\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 23 of 27\n\nThe blanks can be filled in using the debugger method from earlier. In the next figure is the first of the next stage\r\npayload hosting strings. cyb3rjerry grabbed all the next stage hosting and c2 hostnames from all the files I was\r\nable to find. Please go fetch the complete set of network IOCs from that blog linked up at the top here.\r\nOdds and Ends\r\nThe following is a ZIP archive collected from a GTA gamer website on 2025-07-03. This is supposed to be a game\r\nmod called “Visual Car Spawner”. The filename of the scavenger DLL inside the archive is umpdc.dll . This is\r\npresumably masquerading as some game cheat/mod DLL. The following figure shows the file heirarchy inside of\r\nthe archive.\r\nZIP: e131d7ac201384552c90a8a45aea68d7fa9825fecfe0fb0b98668cf1c6e331ac\r\nFilename: 1743451692_Visual%20Car%20Spawner%20v3.4.zip\r\nURL: hxxps[://]fileservice[.]gtainside[.]com/fileservice/downloads/ftpk/1743451692_Visual%20Car%20Spawner%20v3.4\r\nDLL: 90291a2c53970e3d89bacce7b79d5fa540511ae920dd4447fc6182224bbe05c5\r\nFilename: umpdc.dll\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 24 of 27\n\nPivoting on the PDB path string that cyb3rjerry found in one payload, I stripped it down to just the folder named\r\nX on the adversary’s desktop: C:\\\\Users\\\\user\\\\Desktop\\\\X\\\\ . There were quite a few files with this in the\r\nPDB strings. One is called RanHax(Farel)Multi-Tool.exe and the rest have the same filename as the sample\r\ncollected from the GTA game/mod website: umpdc.dll . The figure below shows these files all together.\r\nEXE: d5a665f83eb6d52950bd79818b002e1a46bd849ac67a1f68499f6f86c25eab75\r\nFilename: RanHax(Farel)Multi-Tool.exe\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\RanHax(Farel) Multi-Tool\\RanHax(Farel)Multi-Tool\\Release\\RanHax(Farel)\r\nDLL: 0a5b89f76f0a811da90fbc2d7f98cf8d055285062eca4e69f6af08f9056213f5\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: 0c893e41a710c952619715a99f55dbf12773f681e44a8a569ad7f0f706f853e6\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: 28b561d965b3a9af95619537c94d27899a8b777f6eb1f8afd01c348e4a56c5e3\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: 40f9d13ef565f54ea5e3e4d01097435de308a781206e08746cac49435ce4dd18\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: 70853fc94ba445245cb2a7f52dea42756347e29d04ad8391941760cb39b38c95\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 25 of 27\n\nDLL: 93638e3b79c8d5bb278af76f1d48918332f56e14565851ad160f3bc8d443bb9c\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: b518f295977bf944ad57ee220eac6a6e35a02e05af760962a8d1b9a6eaf3a2ec\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: bbf2261adf8e2bdbed9d8899f416f31ae1fe9f190f695220f36f4c24ff3d2f86\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\TRAINER\\INTERNAL C++ FAREL AUTO UPDATE\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\\r\nDLL: ea8dff6054830d0cf7423c132f94bd74445f49037a20170b3f1e240ecb6a6ecc\r\nFilename: umpdc.dll\r\nPDB Path: C:\\Users\\User\\Desktop\\x\\INTERNAL C++ FAREL AUTO UPDATE\\Release\\umpdc.pdb\r\nInfrastructure Analysis: Domains\r\nPivoting on the known next stage and command and control domain indicators, the following additional indicators\r\nwere found. First is an @yandex[.]ru email address found in the WHOIS data for datalytica[.]su . Next, are\r\nthree domains that are related in multiple ways: npnjs[.]com , prod01-npmjs[.]com , and dieorsuffer[.]com .\r\nAdditionally, npnjs[.]com is known to have been used in the NPM phishing attack. This indicates that prod01-\r\nnpmjs[.]com may also be related to the phishing attack. They are related by:\r\n1. Sharing the same Cloudflare DNS pair indicating they may be under the same user account:\r\nCASH.NS.CLOUDFLARE[.]COM \u0026 NELCI.NS.CLOUDFLARE[.]COM\r\n2. Registered with NameSilo\r\n3. Contain the string npm\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 26 of 27\n\ndieorsuffer[.]com\r\nnpnjs[.]com\r\nprod01-npmjs[.]com\r\nThe following domains are related by the Cloudflare DNS server pair carlane.ns.cloudflare[.]com \u0026\r\nruben.ns.cloudflare[.]com as well as being registered with NameSilo. These are all various phishing domains\r\nwith a postal service nexus. These domains are related to scavenger at very low confidence.\r\nanpost-ie[.]top\r\nbiz-itapost[.]top\r\nie-anpost[.]top\r\nitaliane-poste[.]top\r\nmypost-gob[.]top\r\nposte-italiane[.]top\r\nuspsmypost[.]top\r\nInfrastructure Analysis: IP Address\r\nMost of the IP addresses used in this campaign are behind Cloudflare except for one: 45.9.149[.]210 . This IP is\r\nrelated to the following hostnames via passive DNS resolutions that are contemporaneous with the campaign.\r\nfirebase[.]su\r\ndieorsuffer[.]com\r\ntmpl.rdntocdns[.]com\r\nSource: https://utkonos.github.io/sc_trojan_jwjf/\r\nhttps://utkonos.github.io/sc_trojan_jwjf/\r\nPage 27 of 27\n\ncode were results not dumped to awesome, little files, I used the and not terrible. following Binary Refinery command line incantation. I would call the\nemit binjadump*.dat [ | vstack-a x64 -S 0x25000 [ | scope 2 | terminate | terminate H:86 | peek-Qr ]]\n  Page 22 of 27",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://utkonos.github.io/sc_trojan_jwjf/"
	],
	"report_names": [
		"sc_trojan_jwjf"
	],
	"threat_actors": [
		{
			"id": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434715,
	"ts_updated_at": 1775826720,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/56f18d7bea6dcbb304f1eae9f12506f29ac9ee63.pdf",
		"text": "https://archive.orkl.eu/56f18d7bea6dcbb304f1eae9f12506f29ac9ee63.txt",
		"img": "https://archive.orkl.eu/56f18d7bea6dcbb304f1eae9f12506f29ac9ee63.jpg"
	}
}