Mailing List Archive

Office phish
Hi,
Would anyone like to help me block this office phish? It includes an
HTML file that presents an O365 login page:

https://pastebin.com/JMSrY6KU

More javascript in an HTML file.
Re: Office phish [ In reply to ]
SpamAssassin has plugins for PhishTank and OpenPhish. I would suggest
you submit the link to them.
You can also reach out to the domain provider, hosting provider(s) and
other companies involved.


On 30/06/2021 21:51, Alex wrote:
> Hi,
> Would anyone like to help me block this office phish? It includes an
> HTML file that presents an O365 login page:
>
> https://pastebin.com/JMSrY6KU
>
> More javascript in an HTML file.
Re: Office phish [ In reply to ]
Hi,

> SpamAssassin has plugins for PhishTank and OpenPhish. I would suggest
> you submit the link to them.
> You can also reach out to the domain provider, hosting provider(s) and
> other companies involved.

> > https://pastebin.com/JMSrY6KU

We've got to do better than that. These O365 phishing attacks are
significant and severe and constant.

I modified the ExtractText plugin to also process HTML files

extracttext_external htmlcat /usr/bin/cat {}
extracttext_use htmlcat .htm .html

then created the following rule to look for <script> in the data
stream, and combined it with a few existing rules that identify
malformed HTML.

body __LOC_HTML_SCRIPT /\<script\>/i
meta LOC_HTML_BAD_SCRIPT (__LOC_HTML_SCRIPT && (T_HTML_ATTACH
|| T_OBFU_HTML_ATTACH || HTML_MIME_NO_HTML_TAG))
score LOC_HTML_BAD_SCRIPT 5.00
describe LOC_HTML_BAD_SCRIPT HTML with bad javascript

Someone with a better ability to identify what's bad and unique about
this javascript would probably be able to do better.

Unless javascript in an HTML attachment is never a good thing, and can
always be blocked?

I'm surprised it took them this long to start doing this, or at least
reaching my systems.
Re: Office phish [ In reply to ]
On Wed, Jun 30, 2021 at 05:41:56PM -0400, Alex wrote:
>
> I modified the ExtractText plugin to also process HTML files
>
> extracttext_external htmlcat /usr/bin/cat {}
> extracttext_use htmlcat .htm .html
>

Quite horrible hack, as the result should be _rendered_ text. Inserting raw
HTML for all body rules is probably breaking more things than fixing.

But yeah a "mimebody" ruletype would probably be useful..
Re: Office phish [ In reply to ]
Hi,

> > I modified the ExtractText plugin to also process HTML files
> >
> > extracttext_external htmlcat /usr/bin/cat {}
> > extracttext_use htmlcat .htm .html
> >
>
> Quite horrible hack, as the result should be _rendered_ text. Inserting raw
> HTML for all body rules is probably breaking more things than fixing.
>
> But yeah a "mimebody" ruletype would probably be useful..

Would you explain a bit further? Until such a ruletype exists, how do
you propose we solve this javascript issue? How do we search through
MIME attachments without using ExtractText?

Block the resulting URI in the javascript body? I was hoping for
something more generic.

I realize blocking all javascript is prone to error, but what about
blocking all "location.href" attempts? Or "document.write"?

Am I really the only one seeing these attacks?
Re: Office phish [ In reply to ]
On 30.06.21 23:05, Bert Van de Poel wrote:
>SpamAssassin has plugins for PhishTank and OpenPhish. I would suggest
>you submit the link to them.
>You can also reach out to the domain provider, hosting provider(s) and
>other companies involved.

don't you mean clamav instead?

>On 30/06/2021 21:51, Alex wrote:
>>Would anyone like to help me block this office phish? It includes an
>>HTML file that presents an O365 login page:
>>
>>https://pastebin.com/JMSrY6KU
>>
>>More javascript in an HTML file.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
Re: Office phish [ In reply to ]
On Thu, 1 Jul 2021 08:42:01 -0400
Alex wrote:


> I realize blocking all javascript is prone to error,

What legitimate email uses javascript?
Re: Office phish [ In reply to ]
On Thu, Jul 01, 2021 at 08:42:01AM -0400, Alex wrote:
> Hi,
>
> > > I modified the ExtractText plugin to also process HTML files
> > >
> > > extracttext_external htmlcat /usr/bin/cat {}
> > > extracttext_use htmlcat .htm .html
> > >
> >
> > Quite horrible hack, as the result should be _rendered_ text. Inserting raw
> > HTML for all body rules is probably breaking more things than fixing.
> >
> > But yeah a "mimebody" ruletype would probably be useful..
>
> Would you explain a bit further? Until such a ruletype exists, how do
> you propose we solve this javascript issue? How do we search through
> MIME attachments without using ExtractText?

If it works for you, then use it. Just making a point that it's _very_
blunt tool for the job that can mess other rules..

John's already done something that hits:

mimeheader T_OBFU_HTML_ATTACH Content-Type =~ m,\bapplication/octet-stream\b.+\.html?\b,i

Maybe that along with checking for very short body etc.
Re: Office phish [ In reply to ]
On 2021-07-01 17:03, RW wrote:

>> I realize blocking all javascript is prone to error,
> What legitimate email uses javascript?

and what mua will show html attachment as default ?
Re: Office phish [ In reply to ]
On 2021-07-01 17:42, Henrik K wrote:

> John's already done something that hits:
>
> mimeheader T_OBFU_HTML_ATTACH Content-Type =~
> m,\bapplication/octet-stream\b.+\.html?\b,i
>
> Maybe that along with checking for very short body etc.

add htmltidy to extract text plugin would also solve it, perl tidy is
already done, so external shell commands is not needed in extract text
for that part of it, save copy io time for another scanner
Re: Office phish [ In reply to ]
On 2021-06-30 21:51, Alex wrote:
> Hi,
> Would anyone like to help me block this office phish? It includes an
> HTML file that presents an O365 login page:
>
> https://pastebin.com/JMSrY6KU
>
> More javascript in an HTML file.

# put this content into a file name "local_html.cdb" in clamav database
dir
Sanesecurity.Foxhole.Mail_html:CL_TYPE_MAIL:*:(?i)\.html$:*:*:0:0:0:0
Sanesecurity.Foxhole.Mail_htm:CL_TYPE_MAIL:*:(?i)\.htm$:*:*:0:0:0:0

it blocks all html attachment, but allow still html mail from real mua

this is a trigger happy signature, but i dont care :=)
Re: Office phish [ In reply to ]
On Thu, 2021-07-01 at 18:59 +0200, Benny Pedersen wrote:
> On 2021-07-01 17:03, RW wrote:
>
> > > I realize blocking all javascript is prone to error,
> > What legitimate email uses javascript?
>
> and what mua will show html attachment as default ?

Evolution is as configurable as any MUA I've used:
 
- Whether it defaults to showing plain text or the HTML attachment(s) is
configurable (I use it defaulted to plain text).
- If showing plain text is configured, HTML, if any, appears as
clickable attachments. 
- Animation scan be suppressed
- Remote content will only be loaded and displayed if the sender is in
your contacts list
- It prompts you about sending HTML text to contacts who don't want it.

Evolution was developed as part of the Linux Gnome Desktop toolset, but
rapidly spread to other Linux desktops (I use XFCE) and is also a free
download for Windows.

Martin
Re: Office phish [ In reply to ]
On Thu, 01 Jul 2021 18:40:04 +0100
Martin Gregorie wrote:

> On Thu, 2021-07-01 at 18:59 +0200, Benny Pedersen wrote:
> > On 2021-07-01 17:03, RW wrote:
> >
> > > > I realize blocking all javascript is prone to error,
> > > What legitimate email uses javascript?
> >
> > and what mua will show html attachment as default ?
>
> Evolution is as configurable as any MUA I've used:
>  
> - Whether it defaults to showing plain text or the HTML attachment(s)
> is configurable (I use it defaulted to plain text).


I don't know evolution, but in other clients that kind of option is
typically about choosing between text/html and text/plain mime sections
within multipart/alternate.

The email quoted has an empty text/html section with a separate
attachment of type application/octet-stream with filename=.htm.

It probably relies on the attachment being opened in a separate
browser, so the javascript can run.
Re: Office phish [ In reply to ]
>> I realize blocking all javascript is prone to error,
> What legitimate email uses javascript?
And more important: which email clients do actually process Javascript
that comes within an email? Thunderbird doesn't since 10 or 20 years
ago. I don't know of any other as well. This phish is probably targeted
to inferior web-based email readers who don't filter Javascript well.
Are there any?
Re: Office phish [ In reply to ]
Hi,

> >> I realize blocking all javascript is prone to error,
> > What legitimate email uses javascript?
> And more important: which email clients do actually process Javascript
> that comes within an email? Thunderbird doesn't since 10 or 20 years
> ago. I don't know of any other as well. This phish is probably targeted
> to inferior web-based email readers who don't filter Javascript well.
> Are there any?

It's not a matter of processing/rendering javascript by default in an
email, but someone clicking the ".htm" file, even in Thunderbird,
which then renders the HTML/javascript in the browser.

In this case, the ".htm" file is a rogue O365 login page.
Re: Office phish [ In reply to ]
Alex wrote:
> Hi,
> Would anyone like to help me block this office phish? It includes an
> HTML file that presents an O365 login page:
>
> https://pastebin.com/JMSrY6KU
>
> More javascript in an HTML file.
Yes, there's something going on.

I had some trouble yesterday, and found a message sent from a valid
...protection.outlook.com server, with an Octet-Stream, Base64
attachment entitled "message.html".

SeaMonkey did render the HTML in the message window, but (Correctly) did
not execute any JavaScript.

Encrypted message
From
address@munged
To
address@munged
To view the message, sign in with a Microsoft account, your work or
school account, or use a one-time passcode.


Message encryption by Microsoft Office 365



When clicking on the html message, all the JavaScript seems to do is an
"onload" JavaScript "Loading..." message that then switches to give the
user the option to log on with their Email or get a one-time passcode. 
The link takes you to a valid https://login.live.com login.

I never would've caught this except it hit an old header rule I use for
certain Hotmail Porn detection.

Content-Type: multipart/mixed;
boundary="_c23d8b80-2b40-49d4-8897-08b0026dddfb_"

I called my customer to see if they opened it as it was in their Junk
mailbox.  They didn't recognize the sender so no, they didn't.

Interesting, indeed.

-- Jared Hall
Re: Office phish [ In reply to ]
On Fri, 2021-07-02 at 21:25 -0400, Jared Hall wrote:
> I never would've caught this except it hit an old header rule I use
> for certain Hotmail Porn detection.
>
> Content-Type: multipart/mixed;
>         boundary="_c23d8b80-2b40-49d4-8897-08b0026dddfb_"
>
> Thanks for that: added it to a private rule I use to test for
> potentially dodgy extension types.

Martin
Re: Office phish [ In reply to ]
>On Thursday, July 1, 2021, 05:03:50 PM GMT+2, RW <rwmaillists@googlemail.com> wrote:

> What legitimate email uses javascript?
Pretty common! many people copy and paste from webs.. and of course these are important mails! :-(

Pedreter
Re: Office phish [ In reply to ]
On Mon, 5 Jul 2021 08:01:25 +0000 (UTC)
Pedro David Marco wrote:

>
>
> >On Thursday, July 1, 2021, 05:03:50 PM GMT+2, RW
> ><rwmaillists@googlemail.com> wrote:
>
> > What legitimate email uses javascript?
> Pretty common! many people copy and paste from webs.. and of course
> these are important mails! :-(

I'm not sure what you are referring to there. If you copy and paste a
web page into an HTML email, are you not just copying the formatting?
Re: Office phish [ In reply to ]
On 2021-07-05 23:45, RW wrote:

>> > What legitimate email uses javascript?
>> Pretty common! many people copy and paste from webs.. and of course
>> these are important mails! :-(
>
> I'm not sure what you are referring to there. If you copy and paste a
> web page into an HTML email, are you not just copying the formatting?

https://www.w3resource.com/javascript/introduction/html-documents.php

embeeded javascript is possible
Re: Office phish [ In reply to ]
On Tue, 06 Jul 2021 00:16:00 +0200
Benny Pedersen wrote:

> On 2021-07-05 23:45, RW wrote:
>
> >> > What legitimate email uses javascript?
> >> Pretty common! many people copy and paste from webs.. and of course
> >> these are important mails! :-(
> >
> > I'm not sure what you are referring to there. If you copy and paste
> > a web page into an HTML email, are you not just copying the
> > formatting?
>
> https://www.w3resource.com/javascript/introduction/html-documents.php
>
> embeeded javascript is possible


It's a question of whether a simple copy and paste from a web page to
an email body copies any javascript. I don't see why it would.
Re: Office phish [ In reply to ]
On Tue, 2021-07-06 at 00:16 +0200, Benny Pedersen wrote:
> On 2021-07-05 23:45, RW wrote:
>
> > >
>
> https://www.w3resource.com/javascript/introduction/html-documents.php
>
> embeeded javascript is possible
>
Yes, but it may well depend on how the e-mail was assembled.

A message Cut&Paste from a web page formatted with both
<table>..</table> and <ol>...</ol> formatting and displayed using Brave
to construct a new e-mail written, sent and received using Evolution
with the message composer set to use plaintext gave a single block of
body text that didn't contain any HTML formatting.

However, with composer preferences set to use HTML formatting, Evolution
restructured the HTML that was cut and pasted in as an attachment with

Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="attachment.html"
Content-Type: text/html; charset="utf-8"; name="attachment.html"

as a preamble. and all the HTML formatting pretty much rewritten from
scratch and formatted as a block rather that keeping the original page's
indent structure. The plaintext section again had all HTML formatting
stripped out.

So, it would be interesting to know how similar the output of other
browser/MUA combos is to what Brave+Evolution generates. I would not be
surprised if the e-mail content has a close dependence on what MUA is
used and how its composer preferences are set - and possibly which
browser is being used as well.

Martin
Re: Office phish [ In reply to ]
On 2021-07-06 00:32, RW wrote:

> It's a question of whether a simple copy and paste from a web page to
> an email body copies any javascript. I don't see why it would.

diffrent mail programs will give diffrent results of embedded, i dont
know if javascript in noscript html tag is even ignored or not, the only
safe way to read mails is ignore scripting, unlees the js is just a
hello world :=)

--

Before the script...

...After the script.
Re: Office phish [ In reply to ]
On Monday, July 5, 2021, 11:45:42 PM GMT+2, RW <rwmaillists@googlemail.com> wrote:
>I'm not sure what you are referring to there. If you copy and paste a
>web page into an HTML email, are you not just copying the formatting?

Agree RW, but... 
copy and paste from web source to MUA works!
----------Pedreter.
Re: Office phish [ In reply to ]
On Tue, 6 Jul 2021 07:58:15 +0000 (UTC)
Pedro David Marco wrote:

>
>
>
> On Monday, July 5, 2021, 11:45:42 PM GMT+2, RW
> <rwmaillists@googlemail.com> wrote:
> >I'm not sure what you are referring to there. If you copy and paste a
> >web page into an HTML email, are you not just copying the
> >formatting?
>
> Agree RW, but... 
> copy and paste from web source to MUA works!

My presumption is that when you do that the browser puts a static
representation of a snapshot of the page into the clipboard.

Copying across the full page, including javascript, so another
application could reproduce the page from scratch wouldn't work.

For example, if I go to an order in my Amazon account and hit ^A ^C and
then go to the windows mail app and paste the the clipboard into the
compose window, I get something that looks vaguely like the web page.
But the mail app isn't authenticated into Amazon and doesn't have
access to the cookies and other internal state within Chrome. The
personal information displayed must have come in the clipboard rather
than by running the javascript and getting it from Amazon.