{
	"id": "31c56c11-8cb9-4f15-b27c-32680979304d",
	"created_at": "2026-04-06T00:11:00.517765Z",
	"updated_at": "2026-04-10T13:12:01.439044Z",
	"deleted_at": null,
	"sha1_hash": "134422f11ca88c87155544d61c64f00e1b87d2c7",
	"title": "Second Google Chrome Extension Banker Malware in Two Weeks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1793177,
	"plain_text": "Second Google Chrome Extension Banker Malware in Two Weeks\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 20:27:23 UTC\r\n1. Introduction\r\nIt seems that Google Chrome extensions have become quite the tool for banking malware fraudsters. Two weeks\r\nago, an offender phoned a victim and asked him to install a supposedly new bank security module that, instead,\r\nwas a malicious extension hosted at the Google Chrome app store aimed to steal victim’s banking credentials [1].\r\nThis week I received a report about a targeted email phishing campaign against another company with a\r\nsuspicious attachment. The attachments, after the analysis detailed in today’s diary, revealed itself to be another\r\nGoogle Chrome extension prepared to steal banking credentials, credit card, CVV numbers and fraud\r\n“compensation tickets” (a popular and particular Brazilian payment method; we call it “boleto”) to divert\r\npayments.\r\nTo increase the success rate and entice the victim’s attention to the message, scammers used a previously hijacked\r\ncompany email account to threaten employees with a fake layoff list attached to the message in a “zip” file that\r\ncontained the first part of the malware. I named it IDKEY due to the name of the extension it deploys.\r\n2. Threat Analysis\r\nAfter analyzing many different malware parts and lots of obfuscated code, it was possible to understand the\r\nthreat’s flow, since the phishing e-mail to the malicious actions, as seen in Figure 1. A textual description can be\r\nseen below:\r\nThe e-mail attachment “zip” file contains a “.vbs” obfuscated script that, once executed, collects system\r\ninformation and send to a C\u0026C server;\r\nBased on the received information, the C\u0026C server decides whether the victim machine is a virtual\r\nmachine (VM). If so, returns an URL to a non-malicious JPEG file. Otherwise, returns an URL to the\r\nsecond part of the malware;\r\nThe second file, supposedly another “zip”, is, in fact, an obfuscated VBE script, that is downloaded and\r\nexecuted;\r\nThe VBE script makes additional system checks and downloads a “zip” file (a real one this time) which\r\ncontains a “Chrome” directory and a DLL;\r\nThe DLL is deployed and configured to load during user login;\r\nThe Google Chrome Extension is programmatically loaded into Google Chrome using the parameter “--\r\nload-extension”;\r\nThe malicious extensions, called IDKEY STOR (very suggestive name in English) starts to monitor all\r\nvisited websites to identify sensitive information. When it matches specific strings, the fraud begins;\r\nCredentials and credit card numbers are snatched and sent to the C\u0026C server;\r\nhttps://isc.sans.edu/diary/22766\r\nPage 1 of 9\n\nWhen the victim generates a compensation ticket (the “boleto” we talked earlier) which has a barcode, the\r\nmalware intercepts the page loading, communicates with C\u0026C and asks for a fraudulent barcode number. It\r\nthen communicates with an open API on another financial institution in Brazil and has it generate a barcode\r\nimage and overwrites the original one. As result, the payment will be diverted to an account chosen by\r\nfraudsters.\r\nhttps://isc.sans.edu/diary/22766\r\nPage 2 of 9\n\nhttps://isc.sans.edu/diary/22766\r\nPage 3 of 9\n\nFigure 1 – IDKEY Malware Analysis\r\n3. Sandbox detection\r\nOne of the first malware actions done by the VBS attached to the phishing e-mail is collecting a bunch of machine\r\ninformation and sending it to the C\u0026C server, as shown in Figures 2 and 3.\r\nFigure 2 – Machine information collection\r\nFigure 3 – Machine information being posted to the C\u0026C server\r\nThe result for this HTTP Post request was the URL “hxxp://cdn.ahnegao.com.br/2017/07/casa.jpg” which points\r\nto a regular JPEG file – a clear strategy to mislead sandboxes. To bypass this control, it was enough to replace\r\n“VMWare” terms in the request to something else, as shown in Figure 4. This time, C\u0026C returned us a URL to the\r\nnext piece of malware.\r\nhttps://isc.sans.edu/diary/22766\r\nPage 4 of 9\n\nFigure 4 – Bypassing sandbox detection\r\n4. JavaScript [de]obfuscation\r\nAnother part of the malware that caught my attention was how the Google Chrome Extension JavaScript code was\r\nobfuscated. It uses an array of strings in hexadecimal followed by a function that reorders the array. The array is\r\nthen used all over the code, as seen in Figure 5. I saw this approach other times, but now I had to decode the\r\nsource before advancing. It was not possible to read it otherwise.\r\nFigure 5 – Malicious Google Extension snippet\r\nUsing the “nicefier” service JSNice [2], it was possible to better understand the source, as seen in Figure 6.\r\nhttps://isc.sans.edu/diary/22766\r\nPage 5 of 9\n\nFigure 6 – After JSNice deobfuscation\r\nAlas, reading the code is still far from easy because of the array reference approach used. To overcome this, it was\r\nnecessary to create a “decode” function to map and replace all ‘array[“position”]’ references (like\r\n‘_0xb33d[“0x0”]’), to their respective array position, as seen in Figure 7.\r\nFigure 7 – JavaScript decoder\r\nhttps://isc.sans.edu/diary/22766\r\nPage 6 of 9\n\nLoading this code, we had the decoded JavaScript printed to the console, as seen in Figure 8; it was finally\r\npossible to understand the malicious intentions prepared and described in this article.\r\nFigure 8 – Source decoded\r\n5. Final words\r\nWhile it is extremely necessary for developers, the option of manually loading Google Chrome extensions may\r\npose a risk to the regular user who should be aware of browser warnings about extensions in developer mode, as\r\nin Figure 9. And again [1], in my opinion, Chrome should restrict extensions access to sensitive form fields, like\r\npasswords, unless it is explicitly consented by the user.\r\nShould Google Chrome team be more explicit about the dangers posed by programmatically loaded extensions in\r\ntheir warning?\r\nhttps://isc.sans.edu/diary/22766\r\nPage 7 of 9\n\nFigure 9 – Google Chrome Extension in developer mode warning\r\n6. IOCs\r\nFiles\r\nMalicious Google Chrome Extension Files\r\nMD5 (1.js) = 1d91e021e5989029ff0ad6dd595c7eb1\r\nMD5 (2.js) = d996bdc411c936ac5581386506e79ff4\r\nMD5 (3.js) = 59352276c38d85835b61e933da8de17b\r\nMD5 (manifest.json) = c6157953f44bba6907f4827a1b3b4d0a\r\nOther files\r\nMD5 (myinside.dll) = 574322a51aee572f60f2d87722d75056\r\nMD5 (uia.zip) = bae703565b4274ca507e81d3b623c808\r\nNetwork\r\nhxxp://cdn.ahnegao.com.br/2017/07/casa.jpg?1491404962\r\nhxxp://storage.googleapis.com/fogoreal/uia.zip                       \r\nhxxp://storate.googleapis.com/fogoreal/top019.zip                       \r\nhxxps://tofindanotherrace.com/\r\nhxxp://insidevx.net/log5.php?logins=did\u0026s=ch\r\nhxxp://insidevx.net/log5.php?logins=did\u0026s=b\r\nFile System\r\n%userprofile%\\appdata\\roaming\\microsoft\\windows\\start menu\\programs\\startup\\\u003crandomname\u003e.vbs\r\n%userprofile%\\myinside.dll\r\n%userprofile%\\ext\\[Chrome|1.9.6]\r\nhttps://isc.sans.edu/diary/22766\r\nPage 8 of 9\n\nGoogle Chrome\r\nIDKEY STOR malicious extension deployed\r\n7. References\r\n[1] https://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\n[2] http://jsnice.org/\r\n--\r\nRenato Marinho\r\nMorphus Labs| LinkedIn|Twitter\r\nSource: https://isc.sans.edu/diary/22766\r\nhttps://isc.sans.edu/diary/22766\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://isc.sans.edu/diary/22766"
	],
	"report_names": [
		"22766"
	],
	"threat_actors": [],
	"ts_created_at": 1775434260,
	"ts_updated_at": 1775826721,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/134422f11ca88c87155544d61c64f00e1b87d2c7.pdf",
		"text": "https://archive.orkl.eu/134422f11ca88c87155544d61c64f00e1b87d2c7.txt",
		"img": "https://archive.orkl.eu/134422f11ca88c87155544d61c64f00e1b87d2c7.jpg"
	}
}