{
	"id": "158f180f-d1ef-4859-b110-24701257fd5d",
	"created_at": "2026-04-06T00:06:38.776415Z",
	"updated_at": "2026-04-10T03:21:55.946739Z",
	"deleted_at": null,
	"sha1_hash": "a5f4bd986d93923dd4d1bd0727a1d569872c5044",
	"title": "(Banker(GoogleChromeExtension)).targeting(",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1617707,
	"plain_text": "(Banker(GoogleChromeExtension)).targeting(\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 14:38:31 UTC\r\nIntroduction\r\nA new day, a new way to steal bank data in Brazil. Scammers are calling and urging victims to install a supposed\r\nupdate of the bank's security module. In fact, it is a malicious extension of Google Chrome capable of capturing the\r\ninformation entered by the user during access to the bank account.\r\nUnlike the traditional campaigns involving this type of malware, shot randomly betting on the scale, this seems to be\r\nfocused on a few but promising corporate targets. As a result, this campaign malware that runs away from the noisy\r\nbinary code pattern seems to be flying under the radar. At the time of writing, the files that make up the malware in\r\nquestion, developed in JavaScript, have a detection rate of 0 (zero) in VirusTotal [1]. See Figure 1.\r\nFigure 1 - Zero Detection Rate in VirusTotal\r\nThe Phone Call\r\nThis is not the first time we have noticed the use of telephone calls as a social engineering tool by fraudsters [2].\r\nGenerally, they map the company and people involved in the financial sector via social networks and contact them as if\r\nthey were bank employees.\r\nThis time, they called the person in charge of the financial sector of a company and informed that a new version of the\r\nbank's security module would be available. If the installation was not done at that time, the company could lose access\r\nto the account.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 1 of 10\n\nIn the sequence, they provided the address for installing the alleged module. In Figure 2, a screenshot of the site\r\nprovided by the criminals.\r\nFigure 2 – “Security Module” update\r\nBy clicking \"Install,\" the user is directed to the installation page for a Chrome extension, as shown in Figure 3. Note\r\nthat the extension is properly hosted in the official browser app store, which helps to give credibility to the procedure.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 2 of 10\n\nFigure 3 - Chrome malicious extension install screen\r\nOnce the victim has followed the guidelines and installed the fake module, the fraudster guides the victim to a test\r\naccess to the company’s bank account. It is at this moment that the information is stolen, as detailed in the next session.\r\nMalware Analysis\r\nIn this section I will deal with some more technical aspects of the malicious activity of capturing and sending the\r\nbank's data of the victim performed by the malicious extension. The following steps were taken in a controlled and\r\nmonitored environment.\r\nAs can be seen in Figure 4, the newly installed extension can read and change all data on the websites visited by the\r\nuser. This obviously includes agency, account, and password data used in bank account authentication.\r\nFigure 4 - Malware extension permissions details\r\nAfter installation, the malicious extension will then monitor in the background all web accesses made with Google\r\nChrome. The malware activation trigger happens when a specific URL of the database is accessed, as seen in Figure 5.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 3 of 10\n\nFigure 5 - Monitoring the bank URL\r\nUsing a lab computer with the extension installed, I started with dynamic analysis. I visited the bank's website and\r\nentered some fictitious data while monitoring network traffic, filesystem, Windows registry records, and so on. After a\r\nfew attempts, nothing suspicious was identified. I wasn’t certainly triggered the malware in the right way. Time to\r\nmigrate to static analysis.\r\nWhen I looked at the source code of the extension, I identified that the malware, developed in JavaScript, was waiting\r\nfor an access to the corporate login page (PJ) to start capturing data.\r\nI then accessed the expected address while monitoring the malicious extension action again. When I entered the\r\nusername and password, I verified that the \"window.top.Dummy.document.forms[0].G4\" (G4) field was being fed with\r\na coded value, according to Figure 6.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 4 of 10\n\nFigure 6 - Creation of a coded value as user and password were entered\r\nComparing the behavior of this same procedure in an environment without the malicious extension, I realized that this\r\nvalue was not changed, indicating that the malicious code had come into action.\r\nAnalyzing the code in Figure 7, I verify that the encoding of this value is done through the \"window.btoa\" function,\r\nwhich converts text content to base64 - a function widely used for serializing data that needs to be transmitted over the\r\nnetwork, for example. Note that the function is applied twice - perhaps with the goal of disguising the base64 value\r\nthat could easily be converted to its original value during a preliminary analysis.\r\nFigure 7 - Capturing bank access data\r\nBy doing the inverse encoding path, I find that the encoded value contains the credentials (username and password) to\r\nthe dummy account typed earlier, as shown in Figure 8.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 5 of 10\n\nFigure 8 - Decoding the value created by malware\r\nSo far, I have identified the malware's intent to collect the information, but I had not yet identified the theft of the\r\ninformation, I mean, sending it to the attacker.\r\nReturning to the extension source code, I identified a connection routine that is triggered under two conditions: when\r\nthe contents of a given variable have a number of characters greater than 10 (ten) and when the value of variable G4 is\r\ndifferent from \" Ok1 \", as shown in Figure 9.\r\nFigure 9 - Condition for sending information\r\nI note that the variable that is expected to have a size greater than 10 is exactly the one that stores the password entered\r\nby the user at the time of login \"document.forms [0] .pwd\" (pwd). Since the password input field on the login page\r\nonly supports 8 characters, I had just found out why the data send function had not been triggered.\r\nIt is very likely that the value of the pwd variable will actually have a length greater than 10 characters after a\r\nsuccessful login. Maybe it's converted into a password hash value. If our suspicion is correct, the objective of the\r\nfraudsters with this is to avoid receiving information from failed authentication attempts.\r\nTo bypass this restriction, I manipulated the value of the password field size to accommodate a larger number of\r\ncharacters. To do this, I use Chrome's own inspection module that allows you to make changes to the content of the\r\npage locally, as seen in Figure 10.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 6 of 10\n\nFigure 10 - Changing the maximum size of the password field\r\nAfter this changing, when I submitted the form, I finally identified the outgoing connection of the collected data to an\r\naddress contained in the malware code, as seen in Figures 11 and 12.\r\nFigure 11 - URL for receiving the data\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 7 of 10\n\nFigure 12 – DNS name resolution\r\nAfter the name resolution, an HTTPS outgoing connection to the address embedded in the malware code for sending\r\nthe data occurs was seen. As the connection as done using SSL encryption, I had to use a well-known attack strategy in\r\nthis scenario called man-in-the-middle or MITM. It allowed me to intercept the contents of the connection in plain text,\r\nas can be seen in Figure 13.\r\nFigure 13 – Information theft\r\nNote: By doing this type of attack, by default Google Chrome does not allow unrestricted access to secure content\r\n(SSL) - especially when the site uses HSTS. To bypass this control, I use the \"- ignore-certificate-errors\" Google\r\nChrome parameter.\r\nBy decoding the value (2 x base64-decoding) posted by the malware over the SSL connection, I obtained exactly the\r\nuser credentials used in the experiments, as shown in Figure 14.\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 8 of 10\n\nFigure 14 – Decoding sent data\r\nIn addition to username and password data, malware sends out two session variables (sessionStorage.pm_fp and\r\nsessionStorage.ksc). They are likely to be used by attackers to authenticate into the bank portal.\r\nFinal words\r\nThe analysis of this case led me to some reflections and final considerations:\r\nCriminals increasingly take advantage of people's confidence in large institutions to increase the success rate of\r\ntheir malicious campaigns. This time it was on Google and last month, on Uber [3];\r\nInformation theft happens while the user accesses the real site of the financial institution. All security checks,\r\nsuch as watching the digital certificate, if the address is correct, URL filters and so on, will not be enough to\r\navoid the problem this time;\r\nJust as the malware collected the login information, it could also manipulate, for example, the data from a\r\ntransfer transaction by changing the destination of that transaction;\r\nDuring the experiments, when I tried to monitor Google Chrome connections with a proxy (Burp), I noticed that\r\nthe malicious extension did not follow the system proxy settings. The connections were established directly with\r\nthe scam server via an HTTPS connection. Should a browser extension have this permission level?\r\nAlthough the user consented to allow the extension access to all information on the websites accessed, it would\r\nbe interesting for Google Chrome to monitor and block access sensitive information such as passwords. The\r\nuser should be asked to give additional authorization in these cases;\r\nFrom the point of view of antimalware solutions, the challenge is to identify the malicious action performed by\r\na code that uses legitimate function calls. There is no attempt to escalate privileges or access to improper\r\nmemory areas, for example;\r\nIn a quick search on Google, I found a few cases of malicious code in extensions of Google Chome [4] [5].\r\nMaybe we are just at the beginning of this new wave?\r\nFinally, remember to include this scenario to your threat model and train the employees;\r\nIndicator of Compromise (IOCs)\r\nFiles\r\nMD5 (background.min.js) = f87aea66b827630ce34ee96d009503c5\r\nMD5 (content.min.js) = a33f4b130040634cdea39693d3781082\r\nMD5 (manifest.json) = 8d3688f3d4305d188107526ad84beddf\r\nHosts/IP addresses\r\nsuporteinfo.zapto.org\r\n200.98.142.67\r\nReferences:\r\n[1]https://www.virustotal.com/#/file/ac1eaa92ac1116a7224ee161e0e3099ad2b5a06231058871ce870c7f76140ca9/detection\r\n[2] https://morphuslabs.com/a-very-convincing-typosquatting-social-engineering-campaign-is-targeting-santander-corporate-8de402e9c574\r\n[3] https://isc.sans.edu/forums/diary/Uber+drivers+new+threat+the+passenger/22626/1\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 9 of 10\n\n[4] https://blog.malwarebytes.com/threat-analysis/2016/01/rogue-google-chrome-extension-spies-on-you/\r\n[5] https://www.welivesecurity.com/2013/03/13/how-theola-malware-uses-a-chrome-plugin-for-banking-fraud/\r\n--\r\nRenato Marinho\r\nMorphus Labs| LinkedIn|Twitter\r\nSource: https://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nhttps://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/"
	],
	"report_names": [
		"22722"
	],
	"threat_actors": [],
	"ts_created_at": 1775433998,
	"ts_updated_at": 1775791315,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a5f4bd986d93923dd4d1bd0727a1d569872c5044.pdf",
		"text": "https://archive.orkl.eu/a5f4bd986d93923dd4d1bd0727a1d569872c5044.txt",
		"img": "https://archive.orkl.eu/a5f4bd986d93923dd4d1bd0727a1d569872c5044.jpg"
	}
}