{
	"id": "009af70d-c54f-40fc-a759-013e2465d2b1",
	"created_at": "2026-04-06T00:06:49.759683Z",
	"updated_at": "2026-04-10T03:21:19.950255Z",
	"deleted_at": null,
	"sha1_hash": "701cc0bb3d5ff1fa3aa377828e41b97e040bd1d9",
	"title": "Extracting Indicators from a Packed Mirai Sample",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 58728,
	"plain_text": "Extracting Indicators from a Packed Mirai Sample\r\nPublished: 2022-01-04 · Archived: 2026-04-05 22:24:59 UTC\r\nPacking is really commonly used by adversary to stump analysis, so in this post I’m going to look at a sample that is really\r\neasy to unpack and get indicators from. In this case the sample is Mirai packed with UPX. If you want to follow along at\r\nhome, the sample is in MalwareBazaar here:\r\nhttps://bazaar.abuse.ch/sample/ef11393108bed5f3753d054514b2dddb1a534f3623244ab485c0ed6e2d5ded9e/\r\nWhy Just Indicators?\r\nMalware analysis should serve a purpose. In my dayjob on the Red Canary Intelligence team I sometimes have to assess\r\nmalware for indicators as parts of incidents. Not every adventure ends in assembly code and not every adventure requires\r\na 50-page report.\r\nIdentifying UPX Packing\r\nFor this Mirai sample, it’s easy to detect the UPX packing with Detect It Easy .\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\nremnux@remnux:~/cases/mirai$ diec mirai.elf\r\nfiletype: ELF32\r\narch: 386\r\nmode: 32-bit\r\nendianess: LE\r\ntype: EXEC\r\n packer: UPX(3.96)[NRV,brute]\r\nTo verify it’s packed with standard UPX, we can look for UPX! ( 55 50 58 21 ) in the first few bytes:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\nremnux@remnux:~/cases/mirai$ hexdump -C mirai.elf | head\r\n00000000 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 |.ELF............|\r\n00000010 02 00 03 00 01 00 00 00 08 ba 04 08 34 00 00 00 |............4...|\r\n00000020 00 00 00 00 00 00 00 00 34 00 20 00 03 00 28 00 |........4. ...(.|\r\n00000030 00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 |................|\r\n00000040 00 80 04 08 e6 42 00 00 e6 42 00 00 05 00 00 00 |.....B...B......|\r\n00000050 00 10 00 00 01 00 00 00 00 00 00 00 00 d0 04 08 |................|\r\n00000060 00 d0 04 08 00 00 00 00 20 3c 00 00 06 00 00 00 |........ \u003c......|\r\n00000070 00 10 00 00 51 e5 74 64 00 00 00 00 00 00 00 00 |....Q.td........|\r\nhttps://forensicitguy.github.io/extracting-indicators-from-packed-mirai/\r\nPage 1 of 3\n\n10\r\n11\r\n00000080 00 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 |................|\r\n00000090 04 00 00 00 4c 15 8d 50 55 50 58 21 ec 08 0d 0c |....L..PUPX!....|\r\nAlso, we can verify with YARA:\r\n1\r\n2\r\n3\r\nremnux@remnux:~/cases/mirai$ yara-rules -s mirai.elf\r\nUPXProtectorv10x2 mirai.elf\r\n0x3a2a:$a0: EB 0E 90 90 90 90 8A 06 46 88 07 47 01 DB 75 07 8B 1E 83 EE FC 11 DB\r\nIt’s not unheard of for adversaries to overwrite artifacts of UPX packing or use custom packers, so when you find a\r\nsample with standard UPX it’s always time for celebration!\r\nUnpacking The Sample\r\nIn this case it’s simple to unpack the sample. We’re using upx on REMnux, but we also need to remember that the\r\ncommand will overwrite the original executable. First, we need to create a backup copy.\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\nremnux@remnux:~/cases/mirai$ cp mirai.elf mirai.elf.bak\r\nremnux@remnux:~/cases/mirai$ upx -d mirai.elf\r\n Ultimate Packer for eXecutables\r\n Copyright (C) 1996 - 2020\r\nUPX 3.96 Markus Oberhumer, Laszlo Molnar \u0026 John Reiser Jan 23rd 2020\r\n File size Ratio Format Name\r\n -------------------- ------ ----------- -----------\r\n 30908 \u003c- 17376 56.22% linux/i386 mirai.elf\r\nUnpacked 1 file.\r\nWe can verify the result is executable with file and then get our hashes to look up in VT or other sources.\r\n1\r\n2\r\n3\r\n4\r\n5\r\nremnux@remnux:~/cases/mirai$ file mirai.elf\r\nmirai.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped\r\nremnux@remnux:~/cases/mirai$ diec mirai.elf\r\nfiletype: ELF32\r\nhttps://forensicitguy.github.io/extracting-indicators-from-packed-mirai/\r\nPage 2 of 3\n\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\narch: 386\r\nmode: 32-bit\r\nendianess: LE\r\ntype: EXEC\r\nremnux@remnux:~/cases/mirai$ md5sum mirai.elf\r\n3c246e3a6c146dd823268920918c9b48 mirai.elf\r\nLooking for Indicators\r\nThe quick and easy triage for indicators can happen with strings . Remember, by default it just looks for ASCII and not\r\nUnicode, so you need two passes.\r\n1\r\n2\r\nremnux@remnux:~/cases/mirai$ strings mirai.elf \u003e mirai-strings.txt\r\nremnux@remnux:~/cases/mirai$ strings -eL mirai.elf \u003e\u003e mirai-strings.txt\r\nExamining the strings output, we can find a couple interesting things:\r\n35.197.127[.]250\r\n/dev/null\r\nFrom here, we can pivot on that IP address as an indicator to see where it leads. We can also possibly look for sandbox\r\nreports or execute the malware in a controlled environment. To save some time, I looked into a Joe Sandbox report for the\r\nsample. The report included the IP address above plus a few more to try and pivot around. Depending on the requirements\r\nfor your incident you might also look for obfuscated strings using Ghidra or other tools, but we don’t need to for this case.\r\nThanks for reading!\r\nThis post is licensed under CC BY 4.0 by the author.\r\nSource: https://forensicitguy.github.io/extracting-indicators-from-packed-mirai/\r\nhttps://forensicitguy.github.io/extracting-indicators-from-packed-mirai/\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://forensicitguy.github.io/extracting-indicators-from-packed-mirai/"
	],
	"report_names": [
		"extracting-indicators-from-packed-mirai"
	],
	"threat_actors": [],
	"ts_created_at": 1775434009,
	"ts_updated_at": 1775791279,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/701cc0bb3d5ff1fa3aa377828e41b97e040bd1d9.pdf",
		"text": "https://archive.orkl.eu/701cc0bb3d5ff1fa3aa377828e41b97e040bd1d9.txt",
		"img": "https://archive.orkl.eu/701cc0bb3d5ff1fa3aa377828e41b97e040bd1d9.jpg"
	}
}