{
	"id": "e40f8c53-b3df-48fb-ad2d-84c8c617095f",
	"created_at": "2026-04-06T00:14:31.849447Z",
	"updated_at": "2026-04-10T03:24:16.970249Z",
	"deleted_at": null,
	"sha1_hash": "de5de75f895b37a4d39d4f9dde1b29f741a0446a",
	"title": "RisePro stealer targets Github users in “gitgub” campaign",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 385040,
	"plain_text": "RisePro stealer targets Github users in “gitgub” campaign\r\nBy G DATA Security Center\r\nPublished: 2025-04-09 · Archived: 2026-04-05 20:56:01 UTC\r\n03/13/2024\r\nReading time: 7 min (1802 words)\r\nRisePro resurfaces with new string encryption and a bloated MSI installer that crashes reversing tools like IDA. The\r\n\"gitgub\" campaign already sent more than 700 archives of stolen data to Telegram.\r\nFollowing Arstechnica’s story about malicious Github repositories, we wrote a threat hunting tool to identify abused\r\nrepositories. What caught our attention weren’t forks of existing repositories as described by Arstechnica, but newly created\r\nrepos that lead to the same download link.\r\nGithub repositories\r\nWe identified at least 13 such repositories belonging to a RisePro stealer campaign that was named “gitgub” by the threat\r\nactors. The repositories look similar, featuring a README.md file with the promise of free cracked software. Green and red\r\ncircles are commonly used on Github to display the status of automatic builds. Gitgub threat actors added four green\r\nUnicode circles to their README.md that pretend to display a status alongside a current date and provide a sense of\r\nlegitimacy and recency. \r\nThe following repositories belong(ed) to the gitgub campaign:\r\nandreastanaj/AVAST\r\nandreastanaj/Sound-Booster \r\naymenkort1990/fabfilter \r\nBenWebsite/-IObit-Smart-Defrag-Crack \r\nFaharnaqvi/VueScan-Crack \r\njavisolis123/Voicemod  \r\nlolusuary/AOMEI-Backupper \r\nlolusuary/Daemon-Tools \r\nlolusuary/EaseUS-Partition-Master \r\nlolusuary/SOOTHE-2 \r\nmostofakamaljoy/ccleaner \r\nrik0v/ManyCam \r\nRoccinhu/Tenorshare-Reiboot \r\nRoccinhu/Tenorshare-iCareFone \r\nTrue-Oblivion/AOMEI-Partition-Assistant \r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 1 of 9\n\nvaibhavshiledar/droidkit \r\nvaibhavshiledar/TOON-BOOM-HARMONY  \r\nThe download link is the same for all repositories, namely: \r\nhxxps://digitalxnetwork[.]com/INSTALLER%20PA$$WORD%20GIT1HUB1FREE.rar \r\nInstaller_Mega_v0.7.4t.msi in Orca.exe (click to enlarge)\r\nThe unsuspecting user must unpack several layers of archives using the password \"GIT1HUB1FREE\" before they reach the\r\nfirst executable file named Installer_Mega_v0.7.4t.msi[2].\r\nOrca.exe shows that this MSI unpacks the next stage by applying the password \"LBjWCsXKUz1Gwhg\". The resulting file\r\nis named Installer-Ultimate_v4.3e.9b.exe[3].\r\nInstaller-Ultimate_v4.3e.9b.exe\r\nTo complicate analysis, this file[3] is bloated to 699 MB which causes IDA and ResourceHacker to crash. The visualization\r\nof the sample by PortexAnalyzer shows that the bloat is non-trivial. While many bloated files feature appended zero bytes,\r\nthis file has high entropy and no overlay. \r\nPortexAnalyzer visualization of bloated Installer-Ultimate_v4.3e.9b.exe\r\nKnowing that the self-extracting archive from which we unpacked the sample compressed this file to 70 MB, we suspected a\r\nrepeating pattern. Additionally, the visualization of PortexAnalyzer (see image above) shows a ripple in the high entropy\r\narea, which suggests the same. \r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 2 of 9\n\nAfter inspecting the area, we identified a repeating block of 0x1C0 bytes, followed by a unique byte block of size 0x2d. This\r\nrepeating byte block allows the file to be compressed when archived while keeping the entropy of the unpacked, bloated file\r\nhigh. \r\n17 53 18 2F 9F FC 12 BD 1A E9 7B 4A EB 53 CC 6A D3 05 E6 B3 9A FE 7C AF 05 52 05 73 2E 1D EB 14\r\n56 12 84 56 BD DA E8 46 6A 7C 60 8C B3 8F 70 DE E8 70 F1 C2 71 C3 53 6E C8 F0 EB B0 12 32 86 00\r\n88 5F D7 B2 66 F4 F4 80 22 28 45 12 62 08 D3 CB BE 49 CE CD 60 12 BA 6F 17 A0 0F B4 C2 2C D5 08\r\nDF 3F F9 2E BA A0 C9 64 E3 AF 69 99 1D 5C E6 20 4D 1A 77 01 03 08 94 43 28 F3 F7 47 8D F7 55 FD\r\n4E A7 65 99 D4 10 66 F9 8A D7 29 D2 76 24 F1 BA 60 3B BA 4F C5 8B 06 AB ED 3E C4 94 A7 FE 96 59\r\n9B 6E 33 A1 EE 6D 47 66 F6 E2 F4 8C 41 89 1A 34 AD 0C 10 64 0C BA 27 AC 91 77 F4 08 B7 FF 5D AE\r\nC5 D1 1A 8B 7B 12 93 64 B4 05 C0 2F 6F 49 F1 11 19 13 83 E1 0D D0 64 75 75 D6 5A E8 AA 42 C9 BE\r\nA6 CD 16 27 2E 08 01 9E 3B 69 6F 27 D9 9B C1 62 A4 14 58 6F 45 00 44 5D 22 2A 29 1A DE 7E 1E 18\r\n4A 95 AB 1F 26 97 07 97 2B 16 6E 54 E2 50 AB F2 24 99 6D 80 93 2C 9F DC 3A F5 08 37 BE C4 7B 4A\r\nE1 BC 49 47 79 16 53 C5 9E 44 F1 7B AD 21 ED 7F 4E AF 17 2F 4C 6B 4C 5B 37 B2 74 80 0B 41 F8 F7\r\n69 94 F0 E5 CE D8 01 DF B0 75 CB 39 84 50 7F E5 B5 87 3E E8 D6 DD F3 AB 3F B8 C9 0E 47 61 81 C8\r\n1C 72 92 4F DE 19 00 96 AB FB 4C EA 51 47 9B 31 3F 42 1C 2A DF 90 DC CC 96 69 37 D5 BE B8 80 1C\r\nF4 CA FC D0 8D 98 E2 81 16 D1 46 B7 C1 C4 36 AA C2 23 8E 08 9A 06 18 37 16 6E A2 D4 09 E9 DF D0\r\nF2 8F 39 BA EC BB A2 77 20 C2 C6 16 2C 49 19 21 95 E5 1A 59 78 D8 61 64 9F 3E 11 76 CF 37 14 64\r\n(the hexadecimal values of the repeating block)\r\nThe bloat data resides in an RC_DATA PE resource named MICROSOFTVISUALSTUDIODEBUGGERI, which has a size\r\nof 0x2b85418f bytes. By removing this resource with CFF Explorer we successfully slimmed the file from 699 MB down to\r\n3.43 MB.\r\nDetect-it-Easy identifies an InnoSetup signature in this file, however, this signature turns out to be fake. The file is a .NET\r\nassembly. \r\nThe .NET streams are unusual: Firstly, there are two #Blob and #Strings streams even though there can only be one\r\naccording to the Common Language Infrastructure (CLI) specification (see II.24.2.2, page 272). Secondly, there is a\r\n#Schema stream, which is not part of the CLI (see II.24.2.2, page 272). The three faulty streams have an invalid size of one\r\nbyte and point to the same offset. This is likely an attempt to break or confuse .NET parsers.\r\nOutput of PortexAnalyzer CLI showing the invalid .NET streams of Installer-Ultimate_v4.3e.9b.exe (click to\r\nenlarge)\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 3 of 9\n\nOutput by PortexAnalyzer CLI shows the ModuleRef table with 727 references to DLLs\r\nThe ModuleRef table references 727 DLL files (see image on the right) which all seem to consist of two arbitrary dictionary\r\nwords appended to each other, except for the last entry, which is kernel32.\r\nThe file is obfuscated with a version of .NET Reactor 6 and has virtualization enabled, which means deobfuscation of the\r\nloader’s code requires to write a disassembler for the virtualized instructions.\r\nDuring execution, the loader connects to hxxp://176.113.115(dot)227:56385/31522 and injects its payload[4] into either\r\nAppLaunch.exe or RegAsm.exe. \r\nInjected RisePro payload\r\nWe identified the payload[4] as RisePro stealer version 1.6. The version number stems from the stealer’s logs. We assume\r\nthat this is the latest version of RisePro, as within the malware authors' publicly accessible Telegram channel, the most\r\nrecent server updates are referred to as version 1.6. \r\nThe sample resolves its imports dynamically using import hashing with Fowler–Noll–Vo hash 1A.\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 4 of 9\n\nImport hash comparison for LoadLibraryA using FNV-1A\r\nRisePro uses XOR obfuscated stack strings. A previous RisePro report by OALabs states that xorstr library has been used for\r\nRisePro's string obfuscation in the past, but it seems the encryption scheme has been changed in the meantime.\r\nThe library xorstr features \"heavily vectorized compile time string encryption\" and uses vpxor/pxor instructions to perform\r\nthe XOR operations. A yara rule in the aforementioned OALabs report searches for pxor patterns in the binary. RisePro\r\ndevelopers may have reacted to that public rule.\r\nThe new stack string decryption scheme uses one hardcoded decryption function for every string length that the stealer\r\nneeds. All of these functions use the same underlying decryption algorithm but the length is hardcoded in the decryption\r\nloop.\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 5 of 9\n\nRisePro's string decryption function for strings of length 12\r\nWe decrypted the strings with a Binary Refinery snippet, which prints the decrypted strings and their offsets in a format\r\nusable for Python dictionaries.\r\nemit sample |\r\nrex \"\\xC7(\\x85|\\x45).{4,8}\\xC7(\\x85|\\x45).{50}\" [|\r\nput o offset |\r\nrex \"\\xC7(\\x85....|\\x45.)(.{4})\" {2} [|\r\nnop ]|\r\nalu -s \"0-101\" --inc \"B^S\" |\r\ncarve -n 4 printable |\r\nresub \\\\ \\\\ |\r\nresub \\\" \\\\\\\" |\r\ncfmt {o} : \\\"{}\\\", ]]\r\nThe snippet's regular expression matches a few unintended values, but it is not detrimental to set these as comments in the\r\nIDA database. We added the the output to the following IDAPython script.\r\nimport idc\r\ndecrypted_strings_dict = { ... }\r\nfor k, v in decrypted_strings_dict.items():\r\n base = 0x400000\r\n addr = k + base\r\n comment = '\"' + v + '\"'\r\n idc.set_cmt(addr, comment, 0)\r\n print(\"comment\", comment, \"set at\", addr)\r\nAddress translation is not necessary here because the file offset and virtual addresses in the .text section are the same.\r\nNetwork communication and configuration\r\nThe sample communicates with a C2 server in a manner similar to what was discovered in November 2023 by the Any.Run\r\nteam.\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 6 of 9\n\nWe used a Python script that was developed by an Any.Run researcher to decrypt network data. The threat actors have not\r\nchanged their approach and are still using primarily TCP port 50500.  \r\nThe configuration packet was especially interesting, as it contains information about grabber components, Telegram bot API\r\ntoken, and a Telegram message template. \r\nTCP packet with JSON encoded configuration data\r\nAnother packet contained base64 encoded data that after decoding turned out to be a .zip archive with information from our\r\nanalysis machine.  \r\nTCP packet with stolen data\r\nThe data is exfiltrated to two Telegram channels. At the time of writing, both contained more than 700 messages with zip\r\narchives of stolen data. The combination of Telegram channel names and C2 IP addresses indicates a Russia-based\r\noperation.\r\nTelegram channel with exfiltrated data archives\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 7 of 9\n\nThe malware collects a variety of valuable information. All unique passwords are stored in a file named “brute.txt”. In the\r\nfile “password.txt” we discovered a big RISEPRO banner and the link to the public Telegram channel.  \r\nIndicators of compromise\r\nDescription File name SHA-256 / IP / URL\r\n[1] original\r\nRAR archive\r\nINSTALLER PA$$WORD\r\nGIT1HUB1FREE.rar\r\nf52ba7d8a820d32c502c4aaef4bf9690fc0ca97b97c683b43057d82c06294257\r\n[2] MSI\r\nunpacked from\r\n[1]\r\nInstaller_Mega_v0.7.4t.msi 0ff1e4724b5b02a034789e328531f04a660fd1bade2ad9e73c8b748e5f3e0753 \r\n[3] bloated file\r\nunpacked from\r\n[2]\r\nInstaller-Ultimate_v4.3e.9b.exe\r\n492a71bf56d2e89d0b9c5d70ed6c37acea89c8134fa5ba623bce74b3f0fb189e\r\n[4] RisePro\r\npayload\r\ninjected to\r\nRegAsm.exe or\r\nAppLaunch.exe\r\nmemory only b0e194ed54bafa753bda5761c1264b67a5c438ee7a9ed624a83be913f037dcbb\r\n[5] manually\r\ndebloated from\r\n[3]\r\nInstaller-Ultimate_v4.3e.9b.exe\r\n059067376a6271fdead553b471ec899dec3662ec09bd5c3833911c87ea062e92\r\n[6] contacted\r\nIP\r\n  176[.]113[.]115[.]227\r\n[7] contacted\r\nIP\r\n  193[.]233[.]132[.]32 \r\n[8] download\r\nlink of RAR\r\narchive [1]\r\n  hxxps://digitalxnetwork[.]com/INSTALLER%20PA$$WORD%20GIT1HUB1FREE\r\nRelated articles:\r\n Content\r\nGithub repositories\r\nInstaller-Ultimate_v4.3e.9b.exe\r\nInjected RisePro payload\r\nNetwork communication and configuration\r\nIndicators of compromise\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 8 of 9\n\nRelated articles\r\nSource: https://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nhttps://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.gdatasoftware.com/blog/2024/03/37885-risepro-stealer-campaign-github"
	],
	"report_names": [
		"37885-risepro-stealer-campaign-github"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "dfee8b2e-d6b9-4143-a0d9-ca39396dd3bf",
			"created_at": "2022-10-25T16:07:24.467088Z",
			"updated_at": "2026-04-10T02:00:05.000485Z",
			"deleted_at": null,
			"main_name": "Circles",
			"aliases": [],
			"source_name": "ETDA:Circles",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434471,
	"ts_updated_at": 1775791456,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/de5de75f895b37a4d39d4f9dde1b29f741a0446a.pdf",
		"text": "https://archive.orkl.eu/de5de75f895b37a4d39d4f9dde1b29f741a0446a.txt",
		"img": "https://archive.orkl.eu/de5de75f895b37a4d39d4f9dde1b29f741a0446a.jpg"
	}
}