Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: Internet Storm Center Diary 2007-11-01 InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

DNS changer Trojan for Mac (!) in the wild

Published: 2007-11-01
Last Updated: 2007-11-02 02:36:39 UTC
by Bojan Zdrnja (Version: 2)
1 comment(s)

We received some reports of various companies ( reporting about a Mac DNS changer Trojan in the wild. As I happened to receive a sample of it, I decided to analyze it quickly.

The whole Trojan is relatively simple and works almost exactly the same as its brother for Windows  operating systems . In case of execution, the Trojan changes the DNS settings on the machine and reports back to the C&C server.

While the Trojan is relatively simple and not a big threat, two things came to my mind immediately: the bad guys are taking Mac now seriously – this is a professional attempt at attacking Mac systems (and they could have been much more damaging really). The second thing that folks at Sunbelt noticed ( is that when they sent a sample to VirusTotal there were 0 (zero, nada, nilch) products that detected this.

So, let’s see what really happens here. The “social engineering” part has been seen million times – an unsuspecting user visits a web site with a movie on it, however, he needs to download a new codec in order to view it. On Windows, that new codec is typically a PE executable, for Mac the bad guys prepared a DMG archive (DMG files are like ISOs). The user is then prompted to install the package and during this process he will have to supply the administrator credentials. Yep, it’s game over from this point in time (and the attack is exactly the same as on Windows – keep in mind that these users *will* willingly supply these credentials.

Mac installer

Now that we know what happens, let’s see how this whole thing works. I analyzed this on a Linux machine so I first had to convert the DMG file into something Linux can read (an ISO). There is a simple dmg2img utility available from that does the job perfectly.

Once you converted the file to an ISO image, you can mount it and see what’s going on. The most important directory is Resources which contains scripts that are executed before and after the installation. The files that get installed are kept in the Archive.pax.gz file – it’s a gzip compressed cpio file.

The preinstall/preupgrade files from the Resources directory get executed immediately after the installation starts (and they do the main job). These two files are just shell scripts which change the DNS server settings on the machine by using the scutil utility. Here’s what they set the DNS servers to:



path="/Library/Internet Plug-Ins"

(Yes, the IP addresses are familiar). The scripts also create a new cronjob that gets executed every minute. The cron job executes a file called plugins.settings, which is just a copy of the preinstall/preupgrade files – it makes sure that the DNS servers stay as those above and that the cronjob is not removed.

Finally, the postinstall/postupgrade scripts execute a Perl script called sendreq. This Perl script collects some information about the local machine (uname –p and hostname), Base64 encodes them and sends the information to the C&C server ( An interesting thing is that this gets submitted as the Accept-Language: header so it should be easy to write a Snort signature to catch this.

As I said, although the Trojan is really simple, it could have done much worst things (once the installer script has root privileges, it is game over anyway). This malware shows that we must not ignore Mac machines and that Mac users should not think they are invulnerable just by using a Mac and that they can click on absolutely everything.

From the network point of view – pay attention to DNS traffic as any requests that leave your network, and are not from your DNS servers are either coming from infected or misconfigured machines.


Matt Jonkman at released a Snort signature that will detect infected Mac machines reporting to the C&C server by checking the Accepted-Language header. I’m pasting the signature below:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”BLEEDING-EDGE CURRENT_EVENTS Mac Trojan HTTP Checkin (accept-language violation)”; flow:established,to_server; content:”GET “; depth:4; content:” HTTP/1.1|0d 0a|Accept-Language\: “; pcre:”/Accept-Language\: [a-zA-Z0-9]{20}/”; classtype:trojan-activity; sid:2007650; rev:1;)

More info at



1 comment(s)

Digital cartographers

Published: 2007-11-01
Last Updated: 2007-11-01 09:38:36 UTC
by Maarten Van Horenbeeck (Version: 1)
0 comment(s)

Mankind has always had a desparate need to identify its environment. Only by studying our surroundings, we’ve been able to make changes that help us live better. This is also valid for the virtual world we ourselves created.

Complicating matters though, there are multiple parallel maps which essentially cover the same infrastructure, but from different points of view. There are network diagrams, huge maps of the internet and those showing how individual cities interconnect.

At another layer, there are now maps that try to chart how people interrelate – social networks, as we call them. Other maps identify how suspected criminal networks operate or how they structure domains used in specific attacks.

One major issue with maps is that we tend to consider them accurate. When we use maps in our daily lives, they generally show us the way from point A to point B, and they are always right. This is because of a fundamental feedback loop. When I cross from point A to point B, others have likely crossed from point C to point D while meeting the same road. If the map is inaccurate, errors get reported and fixed very smoothly. There’s a lot of traffic, after all.

Our network maps however compare much better to those built hundreds of years ago. They were created by a single person visiting a new region or continent, and contained errors. From 1605 to 1722, for example California was regularly painted on maps as an island.

In addition, maps are often used to sell beliefs. They aren’t necessarily wrong, they just present the world as it exists in the cartographer’s mind. Try grabbing maps of the Spratly Islands from various East Asian countries, or maps of the Middle East from Israel and Syria.

As security professionals, we all meet organizations maintaining network diagrams that do not fully match reality. Their perimeter is not where they thought it was, or various hosts are exposed in ways not fully realized. Making good risk management decisions starts with great asset management, and this requires you to keep your maps up to date. From experience, it appears to me that smaller organizations have problems keeping smaller diagrams up-to-date, while larger organizations have really good detail diagrams for individual solutions, but are lacking insight in their overall, distributed network environment.

Some ways to remediate this:

  • Recognize that diagrams may not be accurate by assigning a confidence rating to each of them, and then work to increase confidence through verification;
  • Use vulnerability management such as scanning to identify assets. However, always take into account their limitations (discovery can be slow, is always incomplete – even when you scan 65535 ports on a variety of protocols);
  • Network IDS can sometimes contribute if you're looking beyond the individual alerts but at overall flows.

I'm very interested in hearing from you on measures you've taken to deal with these issues.

Maarten Van Horenbeeck

0 comment(s)

Cyber Security Awareness Month - Summary and Links

Published: 2007-11-01
Last Updated: 2007-11-01 03:21:11 UTC
by Marcus Sachs (Version: 1)
0 comment(s)

On behalf of the volunteer handlers of the SANS Internet Storm Center, I'd like to pass along our deep appreciation to all of the readers who sent in hundreds of comments and ideas during the past month!  As promised, below is an index to all of the Cyber Security Awareness Month diaries that were published over the past 31 days.  We are working on producing a full document that has all of the submissions (cleaned up, reformatted, and sanitized if needed) that were received.  As you can imagine it will be a while before it's ready for downloading due to the volume of information that was sent to us.  If you have any final thoughts or want to add some additional tips to the subjects, please send send them to us via our contact form.

1. Establishing a User Awareness Training Program
  1 Penetrating the "This Does Not Apply To Me" Attitude
  2 Multimedia Tools, Online Training, and Useful Websites
  3 Getting the Boss Involved
  4 Enabling the Road Warrior
  5 Social Engineering and Dumpster Diving Awareness
  6 Developing and Distributing Infosec Policies

2. Best Practices
  7 Host-based Firewalls and Filtering
  8 Anti-Virus, Anti-Spyware, and Other Protective Software
  9 Access Controls, Including Wireless, Modems, VPNs, and Physical Access
 10 Authentication Mechanisms (Passwords, Tokens, Biometrics, Kerberos, NTLM, Radius)
 11 File System Backups
 12 Managing and Understanding Logs on the Desktop or Laptop (AV, Firewall, or System Logs)
 13 Patching and Updates

3. Hardware/Software Lockdown
 14 Data Encryption
 15 Protecting Laptops
 16 Protecting Portable Media like USB Keys, iPods, PDAs, and Mobile Phones
 17 Windows XP/Vista Tips
 18 Mac Tips
 19 Linux Tips
 20 Software Authenticity (Digital Signatures, MD5, etc.)

4. Safe Internet Use
 21 Understanding Online Threats, Phishing, Fraud, Keystroke Loggers
 22 Detecting and Avoiding Bots and Zombies
 23 Using Browsers, SSL, Domain Names
 24 Not All Patches Are Released on a Tuesday
 25 Using Email, PGP, X509 Certs, Attachments, Instant Messaging and IRC
 26 Safe File Swapping
 27 Online Games and Virtual Worlds

5. Privacy and Protection of Intellectual Property
 28 Cookies
 29 Insider Threats
 30 Blogging and Social Networking
 31 Legal Awareness (Regulatory, Statutory, etc.)

Marcus H. Sachs
Director, SANS Internet Storm Center

0 comment(s)
Diary Archives