
New Brazilian Banking Trojan Uses Windows PowerShell Utility - vezycash
https://threatpost.com/new-brazilian-banking-trojan-uses-windows-powershell-utility/120016/
======
joshstrange
It's not clear from the article (or maybe I'm missing it) but this isn't a
vulnerability with PS right? The article would be the same if it "New
Brazilian Banking Trojan Uses PHP", it's just a language/style that is new not
what it is doing or how it's doing it AFAICT.

~~~
Arnavion
Yes. It seems the user executes an attachment that's a PIF file (a type of
shortcut file) that writes out a PS script to the temp directory and executes
powershell.exe to run it. The point of highlighting PS in the article appears
to be that previous distribution of this malware used a different mechanism,
not anything wrong with PS itself.

~~~
nacos
As a "corporate" sysadmin using Powershell everyday, I was always surprised
that PS is not so used in the malware industry.

By the way, I find that this article[0] linked in the original post is much
more interesting if you want to know more about how brazilian malwares work
(BHO injection, 2FA bypass, etc.)

[0] [https://securelist.com/blog/research/74325/the-evolution-
of-...](https://securelist.com/blog/research/74325/the-evolution-of-brazilian-
malware/)

~~~
user5994461
It took a while for powershell to be installed on most computers. It's still
certainly missing on many computers (i.e. the oldest and most vulnerable).

I actually don't know whether it is installed as default in the latest
Microsoft OS and patches.

That and the very easy way to analyse/reverse engineer scripts don't make a
great candidate for malware.

Anyway, the windows shell is enough for trivial scripts, and one might as well
write software in a real programming language for the rest.

~~~
contextfree
It's been installed by default since Windows 7 and PS v2. The only version
that wasn't installed by default with a Windows release was PS v1 (introduced
at the same time as Vista).

------
coding123
Just a guess... But probably wrote the article to get billions of ad views
specifically from HN this week.

------
graycat
So, how the heck does a PIF file from an e-mail attachment get written
somewhere it might get executed and then how the heck does it get executed?
For lots of details on e-mail to illustrate how hard or at least awkward such
a position and execution of such a file would be, see my long, detailed
discussion of the internals of common Internet e-mail. Net, just because
someone sends me a PIF file, I can see no way they could hope that I would
execute it.

------
graycat
I'm having trouble understanding what the OP is describing:

It looks like the OP did not make clear just how receiving the malicious
e-mail could lead to a malware infection ( _computer virus_ ).

So, in more detail, the OP wrote

> The banking Trojan is being delivered via a phishing campaign where emails
> are masquerading as a receipt from a mobile carrier. A malicious .PIF
> (Program Information File) attachment is used to attack the target’s PC. PIF
> files tell MS-DOS applications how to run in Windows environments and can
> contain hidden BAT, EXE or COM programs that automatically execute after the
> host file is run.

So, below I go step by step through how standard Internet e-mail works and,
thereby, show that it's not easy to get a computer virus infection just from
receiving malicious e-mail. In particular, for the OP, I don't see how there
could have been a virus infection. So, it appears that the OP omitted one or
more operations or steps taken by a user and necessary to get such an
infection. For better understanding of system security, I want to know what
those steps could be.

=== Getting Started

So, someone receives some e-mail with an e-mail attachment that is a .PIF
file. Okay.

=== E-Mail 101

Early in my use of the Internet and e-mail, which was also early in the growth
of the commercial Internet, I read several of the more important standards
documents. So I was reading some of the Requests for Comments (RFCs) of the
Internet Engineering Task Force (IETF). So I read some RFCs for Simple Mail
Transfer Protocol (SMTP). For e-mail attachments, I read about the Multimedia
Internet Mail Extensions (MIME).

The e-mail software I had was awful, e.g., it put a separate icon on my screen
for each e-mail message sent or received! Outrageous! So, long before 33,000
e-mails, say, to pick a random number, the screen would become relatively
full! So, I just wrote my own e-mail software.

Writing such e-mail software is actually surprisingly easy to do: Basically in
such software are just using the standards in the RFCs for Post Office
Protocol 3 (POP3). So, to do this, it's enough to write some relatively simple
software that communicates over the Internet the usual way, that is, using the
RFCs for Transmission Control Protocol/Internet Protocol (TCP/IP).

And as an alternative and without writing any software at all, it's possible
to be even simpler: Just use the standard, interactive, command line, TCP/IP
application program Telnet to send or receive a file, the file having the
e-mail.

With such approaches to sending/receiving e-mail, most possibilities for
mystery about e-mail disappear. In a word, that approach, POP3, to e-mail is
_simple_. In two words, it's _dirt simple_. In the sense of computer security,
it should be about as safe as anything could be; if there is a security
problem, then it is not from the little TCP/IP or Telenet usage but would have
to be in other hard/software.

=== E-Mail 102

So, in particular, with attachments or not, that is, with MIME _parts_ or not,
an e-mail message as sent or received is just a string of bytes, 8-bit bytes,
just bytes. Computers do well handling strings of bytes, just any bytes at
all, safely, that is, without getting infected with a computer virus.

=== My DIY E-Mail Software

For the e-mail software I wrote, I had a file on my hard disk for receiving
e-mail. As my e-mail software received an e-mail message, the software just
wrote (appended) the bytes of the e-mail message to the end of that file. Then
to read the e-mail, I could just use my favorite text editor to read the file.

Then, for security, the text editor was just reading a file of bytes, just
bytes, just 8-bit bytes, and trying to display them.

Yes, when the file got too big, I started another one. Actually, I still have
that old e-mail software and those old e-mail files. So, looking at that old
work, I got 234 such e-mail files from about 4/1997 to 8/2005\. The average
file size was 1,137,251 bytes. The total number of e-mail messages was 29,978
(not quite the famous 33,000). So, I used my little e-mail software for 8
years. It worked quite well.

=== A Nice Feature

There was a nice feature: Each e-mail message sent or received could be
identified by just the file and a time-date stamp within the file. So,
elsewhere in my work, that pair served as a link or pointer to individual
e-mail messages. Then, given such a link, anywhere on my system, in my
favorite editor I could give just one keystroke and see the e-mail message.
Nice.

=== My DIY E-Mail Security

For more on security, I very much doubt that there exists a stream of bytes
that, when read by my favorite text editor, will result in a virus infection.
So, so far, when receiving e-mail with the software I wrote, I see no way my
computer could get a virus infection. That is, sure, maybe there is a lot of
malicious software in attachments in some e-mail I received, but that software
would just be written as bytes to that file my e-mail software appended to.
There those malicious bytes would be and remain, harmlessly. The malicious
bytes could be read by my favorite editor, all with full safety.

=== My DIY E-Mail and MIME

Okay, there is more we should understand: In the RFC for MIME, an _attachment_
can be a file of some image, some sounds, some video, from a spreadsheet, an
Adobe Portable Document Format (PDF) file, some quadruple encrypted, triple
tricky, official Sky Captain National Security Protocol, total secrets of the
universe file. But with the MIME standards, each such attachment, as sent or
received, is just a very non threatening, essentially harmless, really
innocuous, string of total gibberish characters in the long standard 7-bit
American Standard Code for Information Interchange (ASCII) printable
characters.

Exercise: Look up the exact list and see that exactly 65 such printable
characters are used.

Answer: The characters are:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

abcdefghijklmnopqrstuvwxyz

0123456789

+/

So, there are exactly 64 characters. The character '=' not in that list is
used at the end of an encoding to handle the situation that the number of bits
in the input data is a multiple of 8 while the number of bits represented by
the 64 characters is a multiple of 6.

Right, to send an e-mail attachment, take the string of bytes of the
attachment and convert it to those 64 printable characters followed possibly
by one or two '=' characters. Right, just how to do this is called _base 64
encoding_. And in the exercise, we saw where the 64 comes from.

So, in e-mail, as it is received, each attachment is just a gibberish string
of these 64 printable ASCII characters with possibly some characters '=' at
the end.

So, all those characters, being so simple, are easy to view with common text
editors with, yes, lots of ASCII gibberish but no risks or dangers. And, for
the users' viewing pleasure, the gibberish is formatted into separate lines
with, <= 76 characters per line.

Then, sure, if have received e-mail with a MIME attachment, can do a base 64
_decode_ to get back to the string of bytes for an image, audio recording,
video clip, PDF file, etc.

To convert to/from base 64 encoding is easy; writing the software is an easy,
elementary programming exercise. Long ago I wrote such software in the old IBM
interpretive language Rexx.

=== My DIY E-Mail, MIME, and Security

So, so far in our handling of e-mail, we have done nothing dangerous or risky;
really, there is no reasonable way that receiving e-mail could get our
computer a virus infection.

Well, eventually attachments became more common in e-mail. So, right, for such
attachments, with my home-brew e-mail software, I could receive e-mail, use my
editor to put the base 64 gibberish of each attachment in its own file, on
each such file run my little Rexx software for base 64 decoding, and do what I
was willing to do, what risks I was willing to take, with the resulting
decoded files.

So, for an example, if the e-mail claimed that some attachment was intended to
have file extension JPG, then I could make the extension of the file JPG and
give the file to, say, the standard Windows Picture and FAX Viewer. If the
file was really a JPG file, then the viewer should so confirm and just display
the image. Else the viewer should report that the file was not a legal JPG
file. In either case, there should be no harm done, no matter what the heck
was really in the file. Here, of course we would have to trust the Windows
Viewer -- hopefully we could do that.

=== E-Mail is Risky?

Yes, long early in the commercial Internet and e-mail, there were claims that
receiving a malicious e-mail could easily result in a virus infection.
Considering my understanding of e-mail as above and hearing such virus claims,
I was ready to scream HOW? How the heck could receiving e-mail be risky?

That is, according to the e-mail standards as above, e-mail received is just a
string of bytes. The bytes are all printable. Attachments are also printable
because they are in base 64 encoding as above.

So, such e-mail received is just harmless. Put that e-mail and/or its
attachments in some files, and they are still harmless.

=== The OP

So, from the e-mail standards reviewed above, it appears that the OP omitted
one or more operations or steps taken by a user and necessary to get such an
infection.

Any ideas what those operations or steps were?

------
erikb
I'm so happy that we can have PowerShell on Linux as well now. Thanks,
Microsoft!

~~~
charonn0
Your comment makes no sense in the context of this article.

~~~
Sylos
It's sarcasm...

