Tag Archives: technical

Local PayPal Phishing – and why we need a CERT

This just came in the mail: (twice – at two different mailboxes – I must be a high value target for these guys)

A classic phishing email, with the only exception that it seems highly targeted at the Israeli market! (yeah – I know, I sound a little excited, but this is the first one I ever got…). Obviously, I am not the new owner of a BROWN denim jeans (eeewww!), so as I am very interested in who may want my PayPal details, a bit of digging brought this up:


  1. The phishing site (the one led to by the obvious “CANCEL TRANSACTION” link) is hosted on al3abnt.com.
  2. al3abnt.com is obviously not related to PayPal, and in a very unusual turn of events it is actually registered to a person, or at least something that may lead closer to a person than most phishing sites (that use whois anonymizing).
  3. The Whois registration (see below) also leads to a website on anasblog.me. This seems a personal blog from a local village called Salfit in Israel (I knew it reminded me of something… been around there a couple of times :-)).

  5. The blog (see screenshot below) seems pretty anti-Israeli (note the “we are with the third intifada” button on the top-left corner) – thus explaining the interest in local Israeli PayPal accounts.
  6. Obviously – there’s no-one to send the notification to… no CERT would handle this, and the police is almost comical in the way they reacted to calls of this nature…

I’m guessing that a CERT would have done the following:

  1. Publish a warning notification on the offending site, and the email template.
  2. Coordinate with ISP the takedown of the offending site and law-enforcement work to apprehend the scammer (A phone number is listed on the whois information – feel free to try it out 🙂 ).

Be safe out there!

Defining Penetration Testing

I have been fortunate enough to be working with a group of peers from the security industry over the past few months (since November 2010) on finally creating a solid definition of what a penetration testing is.

It has been a topic that has been abused, cannibalized, and lowered to a level where we (as in people in the industry) could not relate to it anymore. It was time to get the fake stuff out, and focus on content. We were all getting tired of “penetration tests” that were nothing more than a Nessus scan printed out and slapped on with the “security consultancy” logo.

Enter – the Penetration Testing Execution Standard.

This is our attempt to define what a penetration test should include – both from the tester side (vendors) as well as from the client side (the business/organization being tested).

It is the fruit of a huge collaborative effort from people who I consider to be some of the best in the industry. Getting together people who on their day-jobs often compete with each other, and come from different areas of the industry, all together and working on something as big as this has been a humbling experience. For that – you guys all ROCK!

Onwards to the content – remember that this is pre-alpha, and is aimed mainly to get feedback from everyone. A lot of branches do not appear in their full glory there, and some will surely not make it to the final edition. We welcome everyone to take a close look at this, contribute, criticize, assist, comment and generally get involved. Some of you may have been watching this and thinking we are holding back – could not have been further from the truth… In order to get to something as big as this we had to cap the number of participants in this revision in order to keep things somewhat organized, so this is a chance to get back in and offer your assistance – we promise to keep this as open as possible.

This is really exciting – for me at least. Hope some of you will be able to share this enthusiasm and weed out the industry from the bad form we got into.

the art of not thinking about elephants

We have been quite busy here at Security Art in the last few weeks (as the blog posting frequency suggests), but I figured I would provide a quick preview of some of the elements we have been working on in terms of risk management.

Now, I suppose you have read Yoram’s earlier post about risk informed decision making, so I won’t elaborate on this for too long, nevertheless, we are often posed with the question “so how does this apply to my organization”. this usually comes form someone who did spend a lot of time and resources on the technical aspects of their network security. The answer is usually “let’s take a look at how you do your business”, which is what we usually do anyways…

Having that in mind, we set off to investigate in a few recent engagements how would some of our clients actually fare against an informed and skilled attacker that has been commissioned to break into the organization. These engagements have been prompted by a few incidents in which the organization in questions was basically left in the dark as they were basing their forensics on the tools that commercial security vendors provided them with, and nothing much more than that (remember the ever expressive “generic” detection from your AV vendor… Ever wonder what it really means?).

With that in mind, and a network to steal data from as a target we accepted the challenge. The only caveat is that the network was disconnected. For real. No Internets…

But (and there’s always a “but”), there was a voice network that went out through PSTN to provide the office with telephony connectivity. Bingo. Ever seen a complete separation of the VOIP network and the internal network? yeah, neither have I. To make a long story short, we managed to get the data in the most old fashioned way possible… we beeped it away (actually transmitted over a VOIP connection using a custom written simulated trojan that encoded the data into audible voice signals and left them as a message on one of our voice mailboxes). Done deal. (and the PoC code can be found here if you’d like to play with some of the conecpts).

Bottom line – always remember that when you think of solutions, you should not be “blinded” by what’s available out there and the accompanying marketing materials. That’s basically the “pink elephant” that vendors tell you not to think about when pitching their solutions. You usually end up thinking about it (and buying the product thinking that you’ll never see that elephant again as you just bought the best “anti-elephant” solutions…).

Always challenge the way you think of networks and processes (we did have to get the code INTO the network somehow… but that’s for another post 🙂 ), and ALWAYS test your assumptions and protections. You’d be surprised how easy it mat be to out-compartmentalize you just because you were boxed in to take care of just a single aspect of the security 9and yes – that even applies to CIO’s, CISO’s, etc…).

Stuxnet Analysis Report

So, after quite some time of working behind the scenes, and making an effort to focus on essence rather than buzz, the CSFI have published their official report on Stuxnet.

I have had the opportunity to assist (just a bit… work has been taking its toll) in the report writing – mostly inCSFI Logo terms of countermeasures for a threat like this, and some basic analysis.

Feel free to download the report form here:CSFI_Stuxnet_Report_V1

As well as watch the demonstration video on the CSFI website: http://csfi.us/?page=stuxnet

Kudos to all the great contributions from the CSFI-CWD (Cyber Security Forum Initiative – Cyber Warfare Division)  fellows!

The Botnet Wars – industry Q&A

I was approached recently by Bart P from Panda security in order to participate in an industry expert Q&A about the botnet wars (apparently he did his homework as he got quite the lineup to participate in this, guessed he can count me as a close miss :-)…).

He managed to compile a great Q&A where you can read some of the views and opinions on the current state of business at the Botnet (including exploit kits and crimeware kits) marketplace.

The full article is available at: http://bartblaze.blogspot.com/2010/10/botnet-wars-q.html