Anatomy of Paypal Phishing Attack

The phishing email

The email header

 Delivered-To: xxx@gmail.com
Received: by 10.202.71.131 with SMTP id u125csp1210882oia;
 Fri, 29 Jul 2016 04:32:30 -0700 (PDT)
X-Received: by 10.28.45.69 with SMTP id t66mr661693wmt.41.1469791950832;
 Fri, 29 Jul 2016 04:32:30 -0700 (PDT)
Return-Path: <sh198725@atena21.gdn-superhost.pl>
Received: from mailGW-1.gdn-superhost.pl (mailGW-1.gdn-superhost.pl. [178.250.47.101])
 by mx.google.com with ESMTP id v66si3080759wmf.69.2016.07.29.04.32.30
 for <xxx@gmail.com>;
 Fri, 29 Jul 2016 04:32:30 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of sh198725@atena21.gdn-superhost.pl designates 178.250.47.101 as permitted sender) client-ip=178.250.47.101;
Authentication-Results: mx.google.com;
 spf=pass (google.com: best guess record for domain of sh198725@atena21.gdn-superhost.pl designates 178.250.47.101 as permitted sender) smtp.mailfrom=sh198725@atena21.gdn-superhost.pl
Received: by mailGW-1.gdn-superhost.pl (Postfix, from userid 500)
 id 77A34104353; Fri, 29 Jul 2016 13:32:30 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
 mailGW-1.gdn-superhost.pl
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,HTML_FONT_SIZE_HUGE,
 HTML_MESSAGE,MIME_HTML_ONLY,NO_RELAYS,URIBL_BLOCKED autolearn=no version=3.3.2
X-Spam-Languages: en
Received: by atena21.gdn-superhost.pl (Postfix, from userid 35301)
 id 8681717C0278; Fri, 29 Jul 2016 13:32:23 +0200 (CEST)
To: xxx@gmail.com
Subject: Unusual activity in your account
X-PHP-Script: andrea.lattari.eu/modules/blog/ml.php for 197.3.225.82
From: Security Team <ppl@jacob-broom.dreamhost.com>
MIME-Version: 1.0
Content-Type: text/html
Message-Id: <20160729113223.8681717C0278@atena21.gdn-superhost.pl>
Date: Fri, 29 Jul 2016 13:32:23 +0200 (CEST)

The phishing Paypal site

Without https of course, my firefox shows that hosting in Germary

fake_paypal_02

The phishing IP information

fake_paypal_11

The phishing site registration information

fake_paypal_12

Try to login the phishing site

fake_paypal_03

Login failed. However the “My Paypal” and “Log out” button at right top corner don’t work

fake_paypal_04

After press the Continue button, it will brings you to update credit/debit card

fake_paypal_05

The phisher wants all your information, have to add billing address to next step

fake_paypal_06

The billing address page

fake_paypal_07

The phisher will ask for remaining information of you

fake_paypal_08

Congratulations! You have submitted all necessary information to phisher

fake_paypal_09

Finally, the phisher will bring you back to the real Paypal website.

fake_paypal_10

Final Thought:

The phishing campaign website design and quality is good. Phisher looking for high quality of data, many fields with validation, the data collection flow is nice.

To avoid trap by those kind of phishing email is easy, the website without https, and the domain name is very easy to identify.

Researchers find over 100 spying Tor nodes that attempt to compromise darknet sites

800px-Red_onion_closeup_2

When it comes to accessing public websites, Tor has an intrinsic security problem: though the nodes between your computer and the public internet are unable to see where the traffic is coming from or going to, the final hop in the network (known as an exit node) gets to know what webserver you are connecting to.

If that final hop isn’t protected by an HTTPS connection — if it takes place without encryption — then all the traffic between you and the webserver are an open book to the exit node. It can see what you send and what you receive, and it can tamper with the connection (for example, it can inject malicious code that exploits bugs in your browser to take it over). If your session includes identifying information — your Google cookie, say, or a login and password — then someone running a spying exit node can figure out who you are without having to poison your session. This was much more of a problem when HTTPS connections were more rare, but now, thanks to the Snowden revelations and projects like Let’s Encrypt, much of the web is encrypted by default. That means that a spying exit node will only be able to see which server is being accessed, but not which page, and will not be able to inject code into the session, and will not be able to see the data going to and from the server.

There aren’t many exit nodes out there. Many people fear that running an exit node will put them in police crosshairs if it gets used in the commission of a crime. For the record, Boing Boing runs a very high-capacity exit node, and though we’ve received multiple contacts from US law enforcement, we’ve just explained that this is a Tor node that runs with logging switched off, and thus we have no information that’ll be relevant to any investigations, and the officers involved have thanked us and gone away without further trouble.

The lack of exit nodes means that if you run an exit node and want to spy on people, you can see an appreciable fraction of all the Tor traffic that goes to and from the public internet. Many governments, including the Chinese government, are understood to be running high-availability exit nodes that snoop on and log all the traffic they can see.

One answer to this problem is Tor “hidden services.” These are servers that have no public internet address; rather, they are accessed directly through the Tor network, without traffic ever being routed through an exit node. Because all this traffic takes place in the Tor network, without the intermediate nodes ever getting access to decrypted information, the sessions are considered very secure. Notorious darknet sites like The Silk Road ran as hidden services, and many sites maintain hidden service versions of their public offerings: for example, Facebook can be accessed on the Tor network via https://www.facebookcorewwwi.onion/, which resolves to a machine in one of Facebook’s data centers in Oregon, which is then bridged into the rest of Facebook’s system. By accessing Facebook over a .onion hidden service, you can disguise the fact that you’re visiting Facebook at all, and bypass censoring firewalls, like those used by schools, employers and governments.

However, hidden services are not without their own security issues. A pair of security researchers from Northeastern University have announced a paper(to be delivered at this summer’s Def Con hacker convention in Las Vegas) that reveals over 100 spying Tor nodes that were shown to be targeting hidden services.

These nodes — ordinary nodes, not exit nodes — sorted through all the traffic that passed through them, looking for anything bound for a hidden service, which allowed them to discover hidden services that had not been advertised. These nodes then attacked the hidden services by making connections to them and trying common exploits against the server-software running on them, seeking to compromise and take them over.

The researchers used “honeypot” .onion servers to find the spying computers: these honeypots were .onion sites that the researchers set up in their own lab and then connected to repeatedly over the Tor network, thus seeding many Tor nodes with the information of the honions’ existence. They didn’t advertise the honions’ existence in any other way and there was nothing of interest at these sites, and so when the sites logged new connections, the researchers could infer that they were being contacted by a system that had spied on one of their Tor network circuits.

This attack was already understood as a theoretical problem for the Tor project, which had recently undertaken a rearchitecting of the hidden service system that would prevent it from taking place.

No one knows who is running the spying nodes: they could be run by criminals, governments, private suppliers of “infowar” weapons to governments, independent researchers, or other scholars (though scholarly research would not normally include attempts to hack the servers once they were discovered).

“We create what we call ‘honey onions’ or ‘honions.’ These are onion addresses that we don’t share with anyone,” Noubir said. If someone visits the sites, it’s a good indication that their service has been picked up by a malicious HSDir.

At any one time, the pair ran 4,500 honey onions over 72 days, and found at least 110 HSDirs spying on hidden services. Some of the actors behind these weren’t just passive observers; many came back and then aggressively probed the hidden services.

“They’re looking for vulnerabilities in the web server,” Sanatinia said. Those attackers might look for cross-site scripting attacks, SQL-injection vulnerabilities, or just try to find the server’s status page, which can reveal lots of interesting, and potentially identifying, information about the site.

Most of the dodgy HSDirs the researchers found were hosted in the US, followed by Germany, France, and then other European countries. Of course, that doesn’t necessarily mean their operators are based in the same country; anyone can whip up a remote server from pretty much anywhere in the world. And because over half of the 110 nodes were hosted on cloud infrastructure, it’s not easy to immediately pin down who’s behind them.

Honey Onions: Exposing Snooping Tor HSDir Relays [Guevara Noubir and Amirali Sanatinia/Def Con]

Over 100 Snooping Tor Nodes Have Been Spying on Dark Web Sites[Joseph Cox/Motherboard]

(Image: Red onion closeup , Ogre, Public Domain)

Original Post: https://boingboing.net/2016/07/01/researchers-find-over-100-spyi.html

Process Hallowing

In this article, we will learn what process hallowing is, how is it done, and how we can detect it while performing memory analysis.

Process Hallowing

It is a technique by which malware will replace a legitimate process with a duplicate process but with malicious code. The process helps the malware to hide among other legitimate processes. The new malicious process looks so similar to the original legitimate process that even the image name, path and command lines remain unchanged. Below are the steps usually followed for process hallowing:

  • First, target process is created in a suspended state using CreateProcess with CREATE_SUSPENDED option. After the process is created, its memory space can be altered with the handle provided. This handle will be referenced in all the subsequent function calls. Note that at this point malicious process is loaded but not yet executed because it was created in a suspended state.
  • Next step is to find the Process Environment Block (PEB section) for this malicious process which can be done using ReadRemotePEB helper function. After this is acquired, image base address is read to locate the NT headers.
  • Next step is to hollow the legitimate code from memory in the hosted process. For this NtUnmapViewOfSection is used. Because it is a kernel function, malware usually resolves the function at runtime using GetProcAddress.
  • Next step is to allocate a new block of memory to host malicious code. Malware usually makes the entire block PAGE_EXECUE_READWRITE for simplicity otherwise permissions can be set for each section as well.
  • Since space has been allocated for a new image, WriteProcessMemory is used to write the new image code in place of original image code. In the optional header structure, the base address will be changed to that of the new memory image. If however the image base of the new image does not match up with image base of original image then the image base of the new image need to be rebased.
  • SetThreadContext function is used to set the context of this process.
  • The last step is just to resume the process using ResumeThread.

Detection of Process Hallowing Using Volatility

Using Volatility plugin malfind

As discussed above, if the malware author forgot to fix the RWX protection on his malicious spawned process, then that can be detected by Volatility plugin ‘malfind’. Malfind looks for memory section that has PAGE_EXECUTE_READWRITE privileges and cannot be mapped onto the disk. It also dumps the assembly code at that memory section and final check to look at whether there is an executable code in the dump code is left for the analysts.

We first run the malfind plugin on a sample image and got following output

There is some clear process hallowing happened here. Multiple instances of lsass.exe are running where under normal circumstances only 1 should be running. To compare these with a normal lsass.exe we ran pslist plugin and got following output

Now process 680 has parent 624 and process 868 & 1928 has parent 668. Running a pstree will give us a good indication of parent-child relationship.

From above we can conclude that process 680 looks legitimate since it has a valid parent winlogon.exe and it was not present in malfind output. To further illustrate this, we will look at the dumped memory sections from process 868,1928.

        

Here we can see that both these has MZ header but cannot be mapped to disk (pre-requisite for malfind). However this MZ header can be easily manipulated by malware authors. To overcome this malfind gives you all the possible hallowed/injected section which Redline miss if the memory section does not have a MZ header.

It is worth to note that while performing memory analysis process hallowing and code injection looks very same.

Comparing the size of multiple instances of same process

We can even look at the sizes of all lsass process. First we will dump these lsass process using Volatility’s procdump plugin. Then we do a ls on the directory where we dumped all the 3 lsass processes. We can clearly see a difference in the size of the 680 vs. 1928 & 868.

After dumping these devices, I plugged it into a machine which has antivirus installed on it. McAfee recognized 1928 as a malicious process and as per set up policies as below

For other process i.e. 868 I submit it to virus total and it confirms that the process is malicious (39/54)

Comparing the processes with fuzzy hashing

We can even use fuzzy hashing to see how much of these processes match each other. With hashing like md5 we can only see whether an output matches or not but with fuzzy hashing we can see how different files are close to being the same. We will use tool ssdeep over the dumped processes in volatility.

Below is the ssdeep tool running over the executables dumped from volatility in above step.

Below we can see that process 680 has 0 match with process 868 & 1928.

So in this article we see how process hallowing is done and how we can detect it with volatility plugins and fuzzy hashing.

Original Post: http://resources.infosecinstitute.com/process-hallowing/

Up ↑