{
	"id": "b9808c2d-e0ef-46ff-a320-c10f8dc6ab0d",
	"created_at": "2026-04-06T00:06:29.186302Z",
	"updated_at": "2026-04-10T13:12:54.217305Z",
	"deleted_at": null,
	"sha1_hash": "169c0795d26e4ba15b020135de8a671bd4bcb855",
	"title": "Zeus Panda Webinjects: Don't trust your eyes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 256405,
	"plain_text": "Zeus Panda Webinjects: Don't trust your eyes\r\nArchived: 2026-04-05 15:17:28 UTC\r\nIn our last blog article Zeus Panda Webinjects: a case study, we described the functionality of current Zeus Panda\r\nwebinject stages and gave some insight into the corresponding administration panel. As we only scratched the\r\nsurface of the target specific second webinject attack stage (in the following we reference this as 2nd attack stage),\r\nwe would like to share more details about this part.\r\nBasically, the 2nd attack stage already includes the complete code needed for the attack. The different code\r\nbranches are triggered by setting status variables, especially the branch variable already introduced in our\r\nprevious article on that topic. Last time we also introduced the send() function, which is used to exfiltrate data.\r\nsend() isn’t entirely unidirectional: the HTTP response of this request includes further code that is evaluated as\r\nJavaScript. Thereby the backend is able to set the different status variables to trigger the existing code branches of\r\nthe 2nd attack stage. Let’s dive into the details of this communication protocol:\r\nCommunication protocol and status variables\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 1 of 7\n\nFigure 1: Communication protocol\r\nFigure 1 illustrates the communication protocol between the 2nd attack stage and the backend server. We see the\r\ndifferent steps of the communication, the branches triggered, and the website on which the step occurs. Before\r\ngoing into details, the concept behind the communication is the following:\r\n1. The current attack state is sent from the client to the backend server.\r\n2. The backend checks for the current attack state and sets the right response parameters to initiate the next\r\nattack stage.\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 2 of 7\n\n3. The backend response contains variables to notify the 2nd attack stage (client), which attack branch should\r\nbe executed next.\r\n4. The 2nd attack stage evaluates the response variables and triggers the next branch.\r\n5. This procedure is repeated until the final state of the protocol is reached.\r\nTime to branch\r\nLet’s take a detailed look into the different branches now.\r\nStep Action\r\n1\r\nThe SL branch is triggered at the beginning of the attack, when an infected victim\r\naccesses the login page of the targeted online banking, inserts the login credentials and\r\nclicks on the submit button. (NOTE: The low level Trojan functions need to trigger an\r\nthe initial webinject (generic loader) on that website and therefore the URL of the\r\nonline banking website has to be listed in the trojan config file). The submitted login\r\ncredentials are intercepted, exfiltrated to the backend (see previous blog post), then the\r\n2nd stage code calls the original login function of the banking or payment website. The\r\nbackend now registers the new victim, identified by the botid. It returns an empty\r\nresponse to the webinject.\r\n2\r\nAt this point, the victim has successfully logged in and has been redirected to the\r\naccount balance overview page. This triggers the 2nd branch: CP. The CP branch is\r\ncalled multiple times during the attack and transmits general status information of the\r\nvictim to the attacker. The response of the backend contains status flags to trigger the\r\nnext step of the attack. At this point here, the backend signals to initiate the attack.\r\n3\r\nThe attack signal triggers the 3rd step shown in Figure 1: The TL branch. This branch is\r\nused to collect details from all available accounts by using the grabber module.\r\nFurthermore, a flag is set to indicate a page reload after the response of the send\r\nfunction has been received. The collected data is then exfiltrated again. The botid is\r\nused to correlate transmitted data to existing victim entries in the backend and therefore\r\nworks as unique identifier for the victim. The server response is empty, but the\r\npreviously set reload flag now triggers the CP branch again.\r\n4\r\nThe CP branch now sends the some information to the backend as  described in Step 2.\r\nAs the backend has stored a different state for the botid already, the response is\r\ndifferent now. It signals the 2nd attack stage that the grabber module has finished and\r\nthe ats module should start now. This module is used to manipulate account details like\r\nthe account balance or transaction details. Also some status flags are set to trigger the\r\nnext branch.\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 3 of 7\n\nStep Action\r\n5\r\nThe GD branch: This branch is used to collect and exfiltrate account details of the\r\nvictim. As already described in step 3, the reload flag is used to trigger the CP branch\r\nagain.\r\n6\r\nThe CP branch again submits status information, and the backend now triggers the next\r\nstep of the attack. Besides some status flags, details about the target account and some\r\nfake data is provided. The data is used by the CP branch to display a fake overlay with\r\na message and/or images, to trick the victim into starting a transaction. To that end, the\r\nfake overlay is used like in a normal phishing attack. We could observe different kinds\r\nof messages, which could be categorized into different modi operandi. (see below). If\r\nthe victim fell for the scam, the previously provided data is used to pre-fill the\r\ntransaction form. Naturally, this data contains a target account for the transaction. This\r\naccount will be controlled by the attacker somehow, i.e., it most likely belongs to a\r\nmoney-mule. Additionally, the response from the backend contains fake information to\r\nbe displayed. Depending on the modus operandi, this information is used to display\r\ndifferent transaction details to the victim, then the ones used for the transaction in\r\nbackground.\r\n7\r\nNow the victim is redirected to the overview page for a successful transaction. In\r\ncombination with the current flag state, this page visit triggers the TL branch of the 2nd\r\nstage code. The TL branch is used to collect details from the transaction overview page\r\nand exfiltrates them to the backend. This indicates a successful transaction to the\r\nattacker. The backend response is empty. The webinject transits into the next state,\r\nwithout the need for further communication with the backend.\r\n8\r\nThe last triggered branch is called CG. It creates a copy of the complete DOM of the\r\nsuccessful transaction overview page and exfiltrates it to the backend. There is no\r\nindication that this data is displayed in the admin panel, thus we assume it is\r\ntransmitted for debug purposes only.\r\nTable 1: Branches\r\nModi Operandi\r\nIn the following we detail two different exemplary modi operandi, which we could observe during our analysis.\r\nThe real visible appearance is different, as the webinject makes heavy use of the style-sheets provided by the\r\ntarget website. This is a very straight-forward way to properly brand fraudulent content to match the corporate\r\ndesign of target banks or payment providers. We focus on the content shipped to banking customers.\r\nCharity Fraud: SOS-Kinder\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 4 of 7\n\nThe victim is asked to donate 1€ to an non-profit organization, in this case for SOS children. This mimics the well\r\nknow internationally active “SOS-Kinderdorf” organization. The German text is well written and does not contain\r\nthe obvious indications for phishing that we all love and know from the occasional phishing mail, like contorted\r\ngrammar and a more than flowery vocabulary. No Google Translate in sight, here. To leverage this scam vector,\r\nthe webinject makes use of the data provided by the backed in Step 6 as detailed above. Using an overlay, the\r\nvictim is made believe he/she is transferring 1€, but under the hood the amount is change to a much higher value.\r\nThe attackers follow a very classic social engineering approach for our part of the world and appeal to the victims\r\nhelpfulness: Who doesn’t want to help children in need by spending 1€? We refer to this kind of attack as charity\r\nfraud.\r\nRefund Fraud: Finanzpolizei\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 5 of 7\n\nThe overlay presents a message to the victim, indicating a transaction has been made to their account. As the\r\nvictim sees a manipulated version of his account balance, he really believes the transaction has had happen.\r\nFurthermore the text indicates a preliminary investigation by the “Finanzpolizei” against the initiator of the\r\ntransaction. If the victim is not transferring the money back, the text threatens with prosecution by law\r\nenforcement for participating in a money laundering scheme.\r\nFinally, all the Google Translate and contextual cluelessness we came to love in the scams out there! Regrettably\r\nfor the attacker, not all German-speaking countries are actually Germany. (We tried that once, partially, and it was\r\na horrible idea.) An institution called “Finanzpolizei” does indeed exist – but not in Germany. The valid target\r\naudience for this scam is thus supposedly to be found in Austria, however, the scam is also actively used in\r\nGermany. The German text includes some mistakes and is not as well written as the first modus operandi we have\r\nshown above.\r\nIn the case at hand, the attackers try to make the victim follow through with a classic refund scam, by threatening\r\nlegal consequences. As the story works without the need to manipulate the transferred amount under the hood, the\r\nfake data needed in the first described modus operandi is not used in this kind of attack. Nevertheless the attack is\r\nkind enough to prefill the transaction form with the correct details to ease the transaction for the victim.\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 6 of 7\n\nReturn of the victim\r\nNow let’s assume the victim has been tricked into initiating a transaction by themselves to send their money to the\r\nattacker. What happens, if the victim takes a look into his online banking account some time later? As expected,\r\nthe 2nd attack stage is also prepared for that case: The user is presented the “temporarily unavailable” notification\r\n(see Figures 1 and 2 from our previous post) and the login function of the target website is disabled. As long as the\r\nstatus variables are set to the finale state of the described communication protocol, the victim is thus unable to\r\naccess their account again as long as the backend server is reachable. Even when disabling this blocking\r\nfunctionality, account information like transaction details and total balance are still manipulated. As this\r\nmanipulations use the originally provided style cheets (CSS) from the target institute, a victim has no way to\r\nvisibility distinguish between a fake entry and an original one.\r\nConclusion\r\nNowadays almost all financial institutes make use of two-factor authentication to protect their users from fraud.\r\nThe modi operandi used by current banking trojan attacks successfully circumvent this by using social engineering\r\ntechniques. The victim is tricked into initiating the transaction willingly and happily provides all information\r\nneeded to confirm the transaction. This is achieved by visible modifications of the website that are\r\nindistinguishable from the original website content. The success rate of these attacks is still quite high.\r\nBy using a multi-layered attack, it’s also cumbersome for analysts to get an complete insight into the technical\r\ndetails. As soon as the backend server is not available anymore, only the 1st stage of a webinject is accessible on\r\nan infected machine. Without the backend server, most of the attack code is not available and therefore some\r\npieces of the puzzle are missing.\r\nThese kind of multi-layered attacks have become more and more complex and sophisticated. However, beyond the\r\nvisual appearance, the code of the original website is modified heavily to make this attacks work and these\r\nmodifications necessarily leave a footprint. In our fraud detection solutions, we provide our customers with instant\r\nvisibility into these modification symptoms so they can fare better at protecting their customers’ assets.\r\nSource: https://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nhttps://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://cyber.wtf/2017/03/13/zeus-panda-webinjects-dont-trust-your-eyes/"
	],
	"report_names": [
		"zeus-panda-webinjects-dont-trust-your-eyes"
	],
	"threat_actors": [],
	"ts_created_at": 1775433989,
	"ts_updated_at": 1775826774,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/169c0795d26e4ba15b020135de8a671bd4bcb855.pdf",
		"text": "https://archive.orkl.eu/169c0795d26e4ba15b020135de8a671bd4bcb855.txt",
		"img": "https://archive.orkl.eu/169c0795d26e4ba15b020135de8a671bd4bcb855.jpg"
	}
}