Monthly Archives: June 2013

FTP Brute Force Attacks?

Hacking websites using FTP access has been one of the most popular attack vectors during the last few year. I can still see many massive site infections done via FTP.

In most cases, the first step of such attacks is stealing FTP credentials from local computers of webmasters. Back in 2009, I described how PC malware stole passwords saved in popular FTP clients such as FileZilla, CuteFTP, SmartFTP and many more. This is still a prevailing vector. More exotic password theft methods include keyloggers, FTP traffic sniffing, and stealing user databases of hosting providers who prefer convenience over security and store actual client passwords in plain text or slightly encrypted (instead of storing only hashes of passwords).

If you ask regular webmasters how hackers can break into their server via FTP, many of them will answer that hackers could guess the password (hence the need to have hard-to-guess passwords). Of course, it is hard to guess whatever password at the first attempt, so one might expect to see multiple such attempts (so-called brute force attacks) before a password is cracked and hackers get access to a server. However in real life, I haven’t come across such FTP brute force attacks. Until this month…

FTP log analysis

I helped a webmaster of a hacked site and, as always, requested recent access and FTP logs to figure out how the site was hacked. The FTP logs clearly showed that someone used a valid username and passwords to upload infected files to the server. This happened several times a day (constant reinfections) from different IPs in different countries. Quite a typical picture.

What was untypical were requests that looked like a brute force attack. They came from different IPs and each IP tried to login using many invalid usernames.

Choice of usernames in brute force attacks.

Here are just a few such sessions and the usernames they tried. (Canada Montreal Ovh Hosting Inc) – 165 login attempts within 70 seconds.


where <second_level_domain> should be replaced with a real second level domain of a site. E.g. in case of “” the second_level_domain will be example.

This attack used the <domain name> as a username and webmaster as an alternative (supposedly default) username, and tried multiple popular passwords from some dictionary. (United States Lombard Deepak Mehta Fie) – 9 login attempts at a rate of 2 a second:


In this case, the attacker used domain name derivatives (appending words like ftp, admin, user) as usernames, and the passwords probably matched the usernames (e.g. exampleftp/exampleftp). A few times they re-tried the same usernames. Probably with slightly different passwords.,,, (all from China Fuzhou Chinanet Fujian Province Network) — 76 login attempts in less than 5 minutes from 4 IPs.


Distributed attack

The last one was obviously a distributed brute force attack where bots from 4 different IPs worked simultaneously and in sync. E.g. one checked “111111” then another checked “112233“, then third checked “222222” and “333333“, then fourth checked “444444“, and so on. Most likely this attack also assumed that some sites may use the same words both as a username and a password.

The above three attack took place within 26 hours. Each of them used different approach to choosing usernames and passwords, and they came from different parts of the Internet. It means that there is a real interest in FTP brute force attacks among cyber criminals.

Why didn’t I come across such attacks before?

After all, brute-force attacks on WordPress and Joomla admin interfaces proved to be very efficient. What makes them so efficient is the fact that there are many millions of WP and Joomla sites out there, and out of those millions there will always be enough sites whose admins were thoughtless enough to choose weak passwords. That’s why I see hundreds or even thousands of login attempts per day in access logs of almost every WordPress and Joomla site I work with. And unfortunately, some of those site were hacked as a results of the brute force attacks.

One might think that FTP is an even better target for brute force attacks since almost every site has FTP access so the number of victims with weak FTP passwords should be substantially larger than the number of WP an Joomla sites with crackable passwords. However it’s not that easy. You should not forget than in case of WP and Joomla, hackers assume that site administrators use the CMS default usernames (admin for WP and administrator for Joomla) so they only need to guess their passwords. But in case of FTP, the username is not known. There is no default FTP username. This is especially true for shared hosting environments where every client must use a unique username. So you need to guess both username and password in order to get access to a site, which dramatically reduces efficiency of brute force attacks (don’t forget the network latency of each FTP request which prevents from testing millions of variants per seconds that one might expect in a latency-free environment).

In order to try the brute force approach, hackers need to narrow down their attack to the simplest cases and hope that the Internet is so big that even a tiny fraction of sites with hackable FTP credentials will worth the effort. And the Internet is really big (there are more than 100,000,000 .com domains alone) and to have better results one needs to attacks as many of them as possible, so the set of username/password pairs should be kept as tight as possible to provide results in reasonable time. Based on the above FTP log analysis, the current approach is to target:

  • sites that use their domain name or some easy derivative from a domain name as a username along with a weak password.
  • sites that use the same simple words for both usernames and passwords.

Another reason why FTP brute-force attacks are not popular is the FTP logins can be tracked by server administrators who can, for example limit number of consecutive failed login attempts per IP address and then block the offending IPs (for example, using the fail2ban tool).

I also guess that many server and client bots might simply lack the FTP brute force functionality…

Do you have any better explanation?

Why did I see the FTP brute force attacks on that particular site?

I have two hypothesis:

1. Massive FTP brute force attacks are in the proof of concept stage. A few years ago WordPress brute force attacks were quite rare too, but once criminals figured out that they could be very successful if you had enough resources to attack a large number of site, such attacks went mainstream. So maybe if FTP brute force attacks eventually prove to deliver good results, we’ll see a flood of login attempts in FTP logs of most sites (I hope not).

2. In the beginning of the post, I forgot to mention about one more failed login attempt. It used the “anonymous” username and the IP address. The thing is the IP address belongs to Google, more specifically to Googlebot. This means that there are some FTP links (e.g. ) to that site on the web and Googlebot tries to crawl them using the default anonymous username which normally doesn’t require a password and is used for public FTP sites. Here is the explanation from John Mueller (Webmaster Trends Analyst at Google):

When we find links to FTP content, we’ll generally attempt to crawl those URLs. If they’re publicly accessible and return normal content, we may choose to index them as well. While it’s not that common, there are occasionally queries where a file on an FTP server is a good result.

So my guess is such attacks may be limited to the sites that have direct FTP links to them on the web.

Do you have any better explanation?

Just in case. No, the original successful FTP hack that I investigated was not a result of a brute force attack. The username was not obvious and the password was strong. The attackers used the tried-and-true credential theft approach.

To webmasters

Regardless of the chances to see massive FTP brute force attacks in future, the described example should be considered as yet another lesson to all webmasters, who should realize all risks associated with FTP.

  1. Carefully choose both username and password.
    • They should not be the same
    • The username shoudn’t be easy to guess (e.g. your site domain name is not the best choice)
    • The password should be strong.
  2. Don’t save passwords in FTP programs. Configure them so that they ask for a password every time you connect to your site. If you work with multiple sites and/or don’t like the idea of memorizing many passwords, consider using password managers like KeePass or LastPass — they save your passwords much more securely.
  3. Consider using SFTP instead of FTP that sends your passwords in plain text (they can be easily intercepted, for example, when you use public Wi-Fi). Most popular FTP programs support SFTP, so the switch should be painless. If you manage your own server, consider not installing an FTP server altogether (or uninstalling it now if there are no others users who can’t use SFTP).
  4. If you manage a server, consider blocking multiple consecutive failed login attempts at a firewall level (tools like fail2ban may help). Moving FTP to a custom port may also help.
  5. Minimize risks of infecting your local computer (which brings you a step closer to password theft). Make sure that all software on your computer is up-to-date. This includes all OS security updates, all browser updates and all browser plugin updates. Here you can check whether your browser is vulnerable:

Related posts:

Trojan.APT.Seinup Hitting ASEAN

1. Executive Summary

The FireEye research team has recently identified a number of spear phishing activities targeting Asia and ASEAN. Of these, one of the spear phishing documents was suspected to have used a potentially stolen document as a decoy. The rich and contextual details (body and metadata) which are not available online lead us to believe this was stolen. This decoy document mentioned countries such as Brunei, Cambodia, Indonesia, Laos, Malaysia, Myanmar, Philippines, Singapore, Thailand, and Vietnam, which leads us to suspect that these countries are targeted. As the content of this decoy document is suspected to be a stolen sensitive document, the details will not be published.

This malware was found to have used a number of advance techniques which makes it interesting:

  1. The malware leverages Google Docs to perform redirection to evade callback detection. This technique was also found in the malware dubbed “Backdoor.Makadocs” reported by Takashi Katsuki (Katsuki, 2012).
  2. It is heavily equipped with a variety of cryptographic functions to perform some of its functions securely.
  3. The malicious DLL is manually loaded into memory which hides from DLL listing.

As depicted in the diagram below, the spear phishing document (which exploits CVE-2012-0158) creates a decoy document and a malware dropper named exp1ore.exe. This dropper will then drop wab.exe (Address Book Application) and wab32res.dll (malicious DLL) inside the temp folder. By running wab.exe, the malicious DLL named wab32res.dll (located within the same folder) will be loaded using DLL side-loading technique. This will in turn install a copy of wab32res.dll as msnetrsvw.exe inside the windows directory to be registered as Windows service. By registering as a Windows service, it allows the malware to survive every reboot and persist on the network.


Figure 1 Infection Flow

This malware is named “Trojan.APT.Seinup” because one of its export functions is named “seinup”. This malware was analysed to be a backdoor that allows the attacker to remote control the infected system.


Figure 2 Exported Functions

2. Related APT Domain and MD5

Based on our threat intelligence and reverse-engineering effort, below are some related domain and MD5 sums. Please note that some of the domain/IP association may change.

2.1. Related Domain


2.2. Associated Files

Name MD5 Comments
Spear-phishing document and decoy document Spear-phishing document and decoy document CONFIDENTIAL CONFIDENTIAL CONFIDENTIAL CONFIDENTIAL
iexp1ore.exe iexp1ore.exe 137F3D11559E9D986D510AF34CB61FBC 137F3D11559E9D986D510AF34CB61FBC Dropper Dropper
wab.exe wab.exe CE67AAA163A4915BA408B2C1D5CCC7CC CE67AAA163A4915BA408B2C1D5CCC7CC Benign Address Book Application Benign Address Book Application
wab32res.dll wab32res.dll FB2FA42F052D0A86CBDCE03F5C46DD4D FB2FA42F052D0A86CBDCE03F5C46DD4D Malware to be side loaded when wab.exe is launched. Malware to be side loaded when wab.exe is launched.
msnetrsvw.exe msnetrsvw.exe FB2FA42F052D0A86CBDCE03F5C46DD4D FB2FA42F052D0A86CBDCE03F5C46DD4D Malware to be installed as a service. Note: This is the same as wab32res.dll. Malware to be installed as a service. Note: This is the same as wab32res.dll.
    baf227a9f0b21e710c65d01f2ab01244 baf227a9f0b21e710c65d01f2ab01244 Calls to Calls to
    0845f03d669e24144df785ee54f6ad74 0845f03d669e24144df785ee54f6ad74 Calls to Calls to
    d64a22ea3accc712aebaa047ab818b07 d64a22ea3accc712aebaa047ab818b07 Calls to Calls to
    56e6c27f9952e79d57d0b32d16c26811 56e6c27f9952e79d57d0b32d16c26811 Calls to Calls to
    cdd969121a2e755ef3dc1a7bf7f18b24 cdd969121a2e755ef3dc1a7bf7f18b24 Calls to Calls to
    709c71c128a876b73d034cde5e3ec1d3 709c71c128a876b73d034cde5e3ec1d3 Calls to Calls to

3. Interesting Technical Observations

3.1. Redirection Using Google Docs

By connecting the malicious server via Google Docs, the malicious communication is protected by the legitimate SSL provided by Google Docs (see Figure below). One possible way to examine the SSL traffic is to make use of a hardware SSL decrypter within an organisation. Alternatively, you may want to examine the usage pattern of the users. Suppose a particular user accesses Google Docs multiple times a day, the organization’s Incident Response team may want to dig deeper to find out if the traffic is triggered by a human or by malware.

Retrieve Command

Figure 3 Retrieve Command via Google Docs

Below is the code that is used to construct a URL that retrieves command via Google Docs. First, the malicious URL is constructed and then encoded. Next, the malware simply leverages the Google Docs viewer to retrieve the command from the malicious server (see Figure below). 4.GoogleDocs

Figure 4 View Command via GoogleDocs

3.2. Zero-Skipping XOR Encryption

The shellcode encryption technique is fairly standard. The shellcode has a decryption stub which decrypts its body using the XOR key 0x9E, and this shellcode is used to extract exp1ore.exe(malware) and Wor.doc (benign document).

The exp1ore.exe and Wor.doc were found within the spear phishing document encrypted using the same key (0xFC) and technique. The XOR key decrypts only a non-zero byte (see Figure 5). This prevents statistical methods of recovering the XOR key. The encrypted executable file and benign document were identified to be located inside the spear phishing document at offsets 0x2509 and 0x43509 respectively.


Figure 5 Zero Skipping XOR Encryption

Even though statistical methods may not be useful in identifying the XOR key as the zero bytes are not encrypted, we could use some of the “known” strings below to hunt for the XOR key in this situation. By sliding the known string across the array of bytes to perform a windowed XOR, the key would be revealed when the encoded data is XORed with the known string.

  • “This program cannot be run in DOS mode”
  • “KERNEL32.dll”
  • “LoadLibraryA”

3.3. Deployment of Various Cryptographic Functions

3.3.1. Secure Callback

The malware performs the callback in a secure manner. It uses a custom Base64 map to encode its data, and creates a salted digital thumbprint to allow validation of data.

Below describes the steps to validate a callback using an example of the following URL:

hxxp:// 5P &wDq= 6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk== &k4fJdSp7= cc3237bc79192a096440faca0fdae10 &GvQF2lotIr5bT2= 349118df672db38f9e65659874b60b27

The URL could be generalised as follows:

Domain/<PHP>?<rand 11-13 char>= <A'>&<rand 3-5 char>= <B'>&<rand 7-9 char>= <C'>&<rand 14-16 chars>= <D'>

The definition of A’, B’, C’ and D’ are as follows:

Let H be the function which encodes binary into hexadecimal characters prepend with “%”, if it is not alphanumeric, dash, underscore or dot.

Let B64 be the base 64 encoder using the following custom map, "URPBnCF1GuJwH2vbkLN6OQ/5S9TVxXKZaMc8defgiWjmo7pqrAstyz0D+El3I4hY".

Let PT be the plain text which is in the form of "<HostName>[<RunType>]:<IPAddress>{1}", where HostName and IPAddress are string, and RunType is a character.

Let A be the random of 3 to 7 characters, and A' = H(A)

Let B be B64 (PT), and B' = H(B)

Let C be 32 char deliminator, and C' = H(C)

Let D be H( MD5 ( salt  + MD5 ( B64(PT) + A + C )  )   ), salt = "%^^*HFH)*$FJK)234sd2N@C(JGl2z94cg23"  , and D' = H(D)

Hence, in this case, the specific malicious URL could be applied as follows:

Domain/<PHP>  =

A’ = “5Pb

B’ = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S%2Bw8npH5oAZk==

C’ = “cc3237bc79192a096440faca0fdae107

D’ = “ 349118df672db38f9e65659874b60b27  (This is the digital signature)

The hash could be verified as follow:

B64(PT) + A + C = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk==” +  “5Pb” + “cc3237bc79192a096440faca0fdae107”

MD5 (B64(PT) + A + C) = “766cf9e96c1a508c59f7ade1c50ecd28”

MD5 (salt + MD5(B64(PT) + A + C))   = MD5 ( “%^^*HFH)*$FJK)234sd2N@C(JGl2z94cg23” + “766cf9e96c1a508c59f7ade1c50ecd28”)

= 349118df672db38f9e65659874b60b27 (This equals to D’, which means verified)

The encoded plain text (B) could be recovered:

B64(PT) = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk==”;

PT = “MY_COMPUTER_NAME[F]:{1}”, where “MY_COMPUTER_NAME” is the hostname, ‘F’ is the run type, “” is the IP address.

Note: This example is mocked up using a dummy computer name and IP address.

The python code below could be used to decode the custom encoded string (see Figure below).


Figure 6 Python to Decode a Custom Base 64

3.3.2. Random Generator Using Mersenne Twister Algorithm

The malware was found to perform a callback at random intervals so as to evade network investigation when looking for network connections that are performed in a regular interval. Additionally, even the name of the parameters in the get string have a random length and name, which makes it hard to create a fix signature to detect such callbacks (see ‎3.3.1 to understand how a callback is created).


Figure 7 Mersenne Twister Algorithm Seeding function

 3.4. In-Memory Only Malicious Code

On the disk, the malicious code is either encrypted or compressed to evade scanning using signature rules. Only upon being loaded into memory, does the malicious code (that appears to be in the form of a DLL) get manually loaded without the use of Windows 32 API. In this way, when an investigation is performed, the malicious DLL is not revealed. Additionally, it makes it much harder for analysis to be performed.


Figure 8 Segments in the memory which contains the malicious code

Taking a deeper look at the decrypted malicious code, this malware was found to contain at least the following functions:

  • Download file
  • Download and execute or load library
  • Change sleep duration
  • Open and close interactive sessions

4. Conclusion

Malware is increasingly becoming more contextually advanced. It attempts to appear as much as possible like legitimate software or documents. In this example, we would conclude the following.

  1. A potentially stolen document was used as a decoy document to increase its credibility. It is also a sign that the compromised organisations could be used as a soft target to compromise their business partners and allies.
  2. It is important to put a stop to the malware infection at the very beginning, which is the exploitation phase. Once a network is compromised, it is increasingly harder to detect such threats.
  3. Anti-incident response/forensic techniques are increasingly used to evade detection. It would require a keen eye on details and a wealth of experience to identify all these advance techniques.

5. Works Cited

Carnegie Mellon University. (n.d.). Retrieved from

Katsuki, T. (19 Nov, 2012). Malware Targeting Windows 8 Uses Google Docs. Retrieved from

I would like to thank several colleagues for their significant contributions on this post: Darien Kindlund, Ned Moran, Nart Villeneuve, and Thoufique Haq.



Episode #167: Big MAC

Hal checks into Twitter:

So there I was, browsing my Twitter timeline and a friend forwarded a link to Jeremy Ashkenas' github site. Jeremy created an alias for changing your MAC address to a random value. This is useful when you're on a public WiFi network that only gives you a small amount of free minutes. Since most of these services keep track by noting your MAC address, as long as you keep cycling you MAC, you can keep using the network for free.

Here's the core of Jeremy's alias:

sudo ifconfig en0 ether `openssl rand -hex 6 | sed "s/\(..\)/\1:/g; s/.$//"`

Note that the syntax of the ifconfig command varies a great deal between various OS versions. On my Linux machine, the syntax would be "sudo ifconfig wlan0 hw ether..."-- you need "hw ether" after the interface name and not just "ether".

Anyway, this seemed like a lot of code just to generate a random MAC address. Besides, what if you didn't have the openssl command installed on your Linux box? So I decided to try and figure out how to generate a random MAC address in fewer characters and using commonly built-in tools.

What does a MAC address look like? It's six pairs of digits with colons between. "Pairs of digits with colons between" immediately made me think of time values. And this works:

$ date +00:11:22:%T

Just print three pairs of fixed digits followed by "hh:mm:ss". I originally tried "date +%T:%T". But in my testing, the ifconfig command didn't always like the fake MAC addresses that were generated this way. So specifying the first few octets was the way to go.

The only problem is that this address really isn't all that random. If there were a lot of people on the same WiFi network all using this trick, MAC address collisions could happen pretty easily. Though if everybody chose their own personal sequence for the first three octets, you could make this a lot less likely.

The Linux date command lets you output a nine-digit nanoseconds value with "%N". I could combine that with a few leading digits to generate a pseudo-random sequence of 12 digits:

$ date +000%N

But now we need to use the sed expression in Jeremy's original alias to put the colons in. Or do we?

$ sudo ifconfig wlan0 hw ether $(date +000%N)
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:02:80:12:43:53

I admit that I was a little shocked when I tried this and it actually worked! I can't guarantee that it will work across all Unix-like operating systems, but it allows me to come up with a much shorter bit of fu compared to Jeremy's solution.

What if you were on a system that didn't have openssl installed and didn't have a date command that had nanosecond resolution? If your system has a /dev/urandom device (and most do) you could use the trick we used way back in Episode #85:

$ sudo ifconfig wlan0 hw ether 00$(head /dev/urandom | tr -dc a-f0-9 | cut -c1-10)
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:7a:5f:be:a2:ca

Again I'm using two literal zeroes at the front of the MAC address, so that I create addresses that don't cause ifconfig to error out on me.

The expression above is not very short, but at least it uses basic commands that will be available on pretty much any Unix-like OS. If your ifconfig needs colons between the octets, then you'll have to add a little sed like Jeremy did:

$ sudo ifconfig wlan0 hw ether \
00$(head /dev/urandom | tr -dc a-f0-9 | sed 's/\(..\)/:\1/g;' | cut -c1-15)

$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:d9:3e:0d:80:57

Jeremy's sed is more complicated because he takes 12 digits and adds colons after each octet, but leaves a trailing colon at the end of the address. So he has a second substitution to drop the trailing colon. I'm using cut to trim off the extra output anyway, so I don't really need the extra sed substitution. Also, since I'm specifying the first octet outside of the "$(...)", my sed expression puts the colons in front of each octet.

So there you have it. There's a very short solution for my Linux box that has a date command with nanosecond resolution and a very forgiving ifconfig command. And a longer solution that should work on pretty much any Unix-like OS. But even my longest solution is surely going to look great compared to what Tim's going to have to deal with.

Tim wishes he hadn't checked into Twitter:

I'm so jealous of Hal. I think his entire command is shorter than the name of my interface. This command is painful, quite painful. I would very much suggest something like Technitium's Mac Address Changer, but since Hal set me up here we go...

To start of, we need to get the name of our target interface. Sadly, the names of the interfaces aren't as simply named as they are on a *nix box. Not only is the name 11 times longer, but it is not easy to type. If you run "ipconfig /all" you can find the name and copy/paste it. (By the way, I'm only going to use PowerShell here, the CMD.EXE version would be ugly^2).

PS C:\> $ifname = "Intel(R) 82574L Gigabit Network Connection"

The MAC address for each interface is stored somewhere in the registry under this even-less-easy-to-type Key:
HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\[Some 4 digit number]\

First, a bit of clarification. Many people (erroneously) refer to Keys as the name/value pairs, but those pairs are actually called Values. A key is the container object (similar to a directory). How about that for a little piece of trivia?

With PowerShell we can use Get-ChildItem (alias dir, ls, gci) to list all the keys and then Get-ItemProperty (alias gp) to list the DriverDesc values. A simple Where-Object filter (alias where, ?) will find the key we need.

PS C:\> Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Control\Class\`{4D36E972-E325-
11CE-BFC1-08002bE10318`}\[0-9]*\ | Get-ItemProperty -Name DriverDesc |
? DriverDesc -eq "Intel(R) 82574L Gigabit Network Connection"

DriverDesc : Intel(R) 82574L Gigabit Network Connection
PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SY...0318}\0010
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SY...0318}
PSChildName : 0010
PSProvider : Microsoft.PowerShell.Core\Registry

Note: the curly braces ({}) need to be prefixed with a back tick (`) so they are not interpreted as a script block.

So now we have the Key for our target network interface. Next, we need to generate a random MAC address. Fortunately, Windows does not requires the use of colons (or dots) in the MAC address. This is nice as it makes our command a little easier to read (a very very little, but we'll take any win we can). The acceptable values are between 000000000000 and fffffffffffe (ffffffffffff is the broadcast address and should be avoided). This is the range between 0 and 2^48-2 ([Math]::Pow(2,8*6)-2 = 281474976710654). The random number is then formatted as a 12 digit hex number.

PS C:\> [String]::Format("{0:x12}", (Get-Random -Minimum 0 -Maximum 281474976710655))
PS C:\> [String]::Format("{0:x12}", (Get-Random -Minimum 0 -Maximum 281474976710655))

We have a random MAC address value and we know the Key, now we need to put those two pieces together to actually change the MAC address. The New-ItemProperty cmdlet will create the value if it doesn't exist and the -Force option will overwrite it if it already exists. This results in the final version of our ugly command. We could shorten the command a little (very little) bit, but this is the way it's mother loves it, so we'll leave it alone.

PS C:\> ls HKLM:\SYSTEM\CurrentControlSet\Control\Class\`{4D36E972-E325-11CE-BFC1-
08002bE10318`}\0*\ | Get-ItemProperty -Name DriverDesc | ? DriverDesc -eq
"Intel(R) 82574L Gigabit Network Connection" | New-ItemProperty -Name
NetworkAddress -Value ([String]::Format("{0:x12}", (Get-Random -Minimum 0
-Maximum 281474976710655))) -PropertyType String -Force

You would think that after all of this mess we would be good to go, but you would be wrong. As with most things Windows, you could reboot the system to have this take affect, but that's no fun. We can accomplish the same goal by disabling and enabling the connection. This syntax isn't too bad, but we need to use a different long name here.

PS C:\> netsh set interface name="Wired Ethernet Connection" admin=DISABLED
PS C:\> netsh set interface name="Wired Ethernet Connection" admin=ENABLED

At this point you should be running with the new MAC address.

And now you can see why I recommend a better tool to do this...and why I envy Hal.

Andres Elliku wrote in and reminded me of the new NetAdapter cmdlets in version 3. Here is his response.

This is directed mainly to Tim as a suggestion to decrease his pain. :) (Tim's comment: for this I'm thankful!)

Powershell has included at least since version 2.0 the NetAdapter module. This means that in Powershell you could set the mac aadress with something like:

PS C:\> Set-NetAdapter -Name "Wi-Fi" -MacAddress ([String]::Format("{0:x12}", 
(Get-Random -Minimum 0 -Maximum 281474976710655))) | Restart-NetAdapter

NB! The adapter name might vary, but usually they are still pretty short.

The shorter interface names is one of my favorite features of Windows 8 and Windows 2012. Also, with these cmdlets we don't need the name if the device (Intel blah blah blah) but the newly shortened interface name. Great stuff Andres. Thanks for writing in! -Tim


@PowerShellGuy tweeted an even shorted version using the format operator and built-in byte conversion:

PS C:\> Set-NetAdapter "wi-fi" -mac ("{0:x12}" -f (get-random -max (256tb-1))) | 

Well done for really shortening the command -Tim

How we go deeper to protect you from new threats

Read our whitepaper about F-Secure DeepGuard, our proactive protection against new and emerging threats. Read it here.

You may know that F-Secure won the Best Protection Award – twice in a row. But if you’ve ever wondered about how we actually go about protecting our customers from malware, this post is for you. We do it by going deeper. Let me explain.

Traditional antivirus software looks at the outward characteristics of files to see if the characteristics match those of previously seen malware files. If they match, the antivirus program knows to block the file.

For this system to work, antivirus labs need to have a sample of the malware file in order to analyze its characteristics so they know exactly what they need to block.

This is a very effective method for blocking most malware seen to date, and this is how F-Secure protects you from existing malware we already know about.

Of course, it takes time for antivirus labs to receive a malware sample and analyze it so we can effectively block it. That means brand new malware created just in the past few days or weeks that we haven’t yet had a chance to analyze, can get past traditional scanning systems.

Complicating the issue, cybercriminals who create malware nowadays are very clever at avoiding detection by antivirus programs. One way they do this is by creating new, different variants of their malware. These variants are still the same malware at the core, but they appear new and different on the outside. Like a criminal who dresses in disguise to avoid being recognized, the malware file is disguised to avoid detection by antivirus software. There are automated malware creation kits that do this for the cybercriminals, making it easy to spit out thousands of new variants.

To be able to protect from brand new malware, then, and to protect from all the new variants of existing malware, it is crucial for F-Secure’s software to be able to detect a malware file even before our Labs have ever received a sample of it.

So how do we block malware strains we’ve never seen? We examine not just a file’s outward characteristics, but we also monitor its behavior for suspicious activity. Like I said, malware can change in appearance and characteristics. But one thing never changes: Malware always does malicious things. So if we’re not sure if a file is malicious or not, we watch to see how the program behaves.

We call our behavioral analysis technology DeepGuard. DeepGuard observes a program’s behavior and prevents potentially harmful actions from successfully completing. This way, we can block even brand new malware files that haven’t yet been analyzed. And we can stop malicious files that are disguised as something else.

When the user opens a file, any file, DeepGuard instantaneously checks for suspicious behavior, and if it finds something, it will block the program from launching. Since some malware hide their malicious behavior until after the program launches, DeepGuard still continues monitoring programs while they are running, watching for and blocking suspicious actions.

DeepGuard is a feature of F-Secure’s products, working in tandem with our other protection layers (browsing protection, traditional signature scanning, file reputation analysis, and prevalence rate checking) to provide the very best protection. Our newest version, DeepGuard 5 with exploit protection, has already been rolled out, so customers with the latest versions of F-Secure products are already benefiting from the latest technology.

And that’s how we protect you.

Looking Through the Cloudy PRISM

As you have no doubt heard, a lot of fuss has been made over the past couple days involving both NSA, Verizon, and Facebook, as well as several other companies and governments. Here, we want to provide a concise overview of the information available at this point, along with some links to additional reading about the program that is known as “PRISM”.

On June 6, 2013, the Guardian published an article that suggested a classified order was issued on April 25, 2013 that allowed the United States government to collect data until July 19, 2013 and then hand it over to the NSA. This order was issued to Verizon, and it’s existence was not allowed to be spoken of. Currently, the documents revealed only cover Verizon, but there may have been similar orders involving other companies, not just ones that provide phone service. PRISM, a program allowing the NSA access to company data, was originally enabled in December of 2007 by President Bush under a U.S. surveillance law and then renewed by President Obama in December of 2012. This program was started to aid anti-terrorism efforts and there are claims by the government that it has already prevented a terrorist plot in Colorado.

These documents reveal that the NSA is performing massive data mining covering millions of U.S. citizens. Wired reported the collected data includes phone numbers of both parties involved in the phone call, the time and duration of the call, the calling card numbers used in the call, and the International Mobile Subscriber Identity (IMSI) number which applies to mobile callers. The location of the calls may have been recording using cell tower data. Data that was NOT collected includes names, addresses, account information, and recordings of call content. There is heated debate whether this metadata is sensitive or not. On the one hand, no names or call content suggests that your fundamental privacy is intact. On the other hand, consider that the government knows you “spoke with an HIV testing service, then your doctor, then your health insurance company in the same hour. But they don’t know what was discussed.”

Edward Snowden has been identified as the whistleblower who released the documents that exposed this classified order. He had access to these documents as an employee for the NSA, which he had been working for over last four years as a contractor from outside organizations, including Booz Allen and Dell. When Snowden released the documents he stated, “I can’t allow the US to destroy privacy and Internet freedom.”

This article by the Guardian highlights multiple comments made by President Obama about the issue. He called this a “very limited issue” when discussing these disclosures of the NSA accessing phone data. In an attempt to deflect criticism, the President also stated that he had privacy concerns regarding private corporations as they collect more data than the government.

Both Facebook and Google denied any previous knowledge of the PRISM surveillance program after concerns they may have been part of the program. Many other technology companies thought be be part of PRISM issued similar statements saying that they did not allow the government “direct access” to their systems. However, theNY Times reports that Google, Microsoft, Apple, Facebook, Yahoo, AOL, and Paltalk all negotiated with the government and were required to share information due to theForeign Intelligence Surveillance Act (FISA). The Guardian also states that Microsoft has been a part of this information sharing program since the beginning in December of 2007 and was joined by Yahoo in 2008, Google, Facebook and PalTalk in 2009, YouTube in 2010, Skype and AOL in 2011, and Apple in 2012. At this point, it is a game of “who do you trust?” The government who finds such data incredibly valuable, or the corporations that sometimes rely on such data for their business model (e.g. Facebook).

In an article by Mark Jaquith, he mentions how important the details are in this situation. There are two different reports on how PRISM actually works; one says the government can directly and unilaterally access company servers to take data and the other is just an easier way to transfer data requested by court orders. The majority of reports are pointing toward the second method describing the way that PRISM works. If this is true, the transfer of data is moderated and indirect making it basically a lock box to securely pass information through. Now, that this has been brought to light we hope more details will continue come to the surface to provide clarity.

As with many big information leaks, the emotions and politics quickly take hold and begin to dominate the argument. Veterans of the Internet are largely not surprised by the PRISM news, due to fleeting memory of ECHELON, Carnivore, and likely other initiatives that never came to light. Regardless, the PRISM program represents a serious threat to individual privacy and every citizen should be concerned.

Written by eabsetz

Make your own DIY surveillance system

image from
image from

When talking IT and security we often just think of securing the computers, and our valuable personal information. But the digital revolution can help us secure other things as well. It is surprisingly easy to make sure you know what’s happening at home when you are away. Yes, there are fine extensive surveillance systems on the market complete with installation service and all. But you may not be willing to pay big bucks, or you like this kind of DIY-challenge. If that’s the case, read on.

I’m going to describe an easy way to get camera surveillance for just a couple of hundred bucks. You also need to be a little bit computer savvy, but you do definitively not need to be an expert. With this system you can have any number of cameras at home and receive an e-mail when something moves in front of them. With a smartphone you can receive these mail wherever you are.

Ok, let’s first check the requirements for this to work.

  • You must have an Internet connection at home.
  • You must have a wireless network at home.
  • Have you ever used the browser to open the configuration screen of a router or other similar network component? If you have, then you know what kind of work you will be doing here. You can of course also call in a nerdy friend if this sounds scary.

Next select the places to put the cameras:

  • The entrances to your home is naturally critical places if you for example want to catch burglars.
  • Make sure you have the face of visitors towards the cameras. Filming backs is of little use.
  • Avoid filming against the light. All you get is dark silhouettes.
  • Try to get the camera as near the objects as possible. Especially cheap cameras have limited resolution and persons may not be recognizable if they are far away.
  • Avoid moving objects in the picture, like bushes that sway in the wind. (They will trigger the movement detection.)
  • Do not point the camera through a window. It may work in daylight but reflections will ruin the pictures at night.
  • You need to route electricity to the cameras. Note that most power supplies aren’t made for outdoor use even if the camera is, leave them inside and bring the low-voltage outside.
  • Your wireless network need to be strong enough where you place the cameras.
  • It’s OK to use cameras in your own home, but be careful if you plan to place the cameras so that they can see a public place. Check the law in your country if you plan to do this. Also check if you need to post warning signs about the CCTV system.

Now is the right time to select the cameras. Here are the requirements:

  • They must have support for wireless networks (WLAN, WiFi).
  • They must have support for “Motion detection alert via email”, or whatever the vendor has selected to call that feature.
  • Select wide-angle or tele-cameras depending or their location. The wide-angle models tend to be more useful.
  • Select outdoor or indoor cameras depending on their planned location.
  • Prefer models with night vision. They have integrated infrared LEDs and can film in complete darkness.
  • Prefer models with a 12V power supply, rather than 5V, if you need to extend the power cable. The higher voltage is less sensitive to voltage drops.

Foscam FI9801W is an example of a suitable wide-angle outdoor model. Cameras like this may sell for around $200 but there are cheaper models too. Shop around on the net and you will have no problem finding the right model, if your local dealer doesn’t happen to have suitable cameras.

Ok, time for the installation procedure:

  1. Create a mail account at some free mail provider, like Gmail or Microsoft Live (former Hotmail). This account will receive pictures from the camera. Do not use your ordinary mail account as the volume may get quite high.
  2. Configure the camera(s) to work with your wireless network at home. Follow instructions in their manual. Note that the initial setup often need to be done with a network cable connected to the camera. The wireless connection will not work before you have done the initialization.
  3. Install the cameras in their final locations and connect electricity.
  4. Use the browser to log into the camera’s control panel. (Again, see the manual.) Look for the settings controlling “Alarm settings”, “Motion alarm” or “Motion detection”. Here you need to make the following settings:
    1. Select to send mail when motion is detected.
    2. Configure the server address that receives outbound mail. This info is provided by your Internet service provider and may be something like “”. You may also have to specify a port number, try 25 unless the service provider instructs you to use something else.
    3. Configure the e-mail address that alerts are sent to. Use the address that you created in step 1 above. Specify the address that appears as sender in the mails, this can be your own address.
    4. Adjust the sensitivity. This is the threshold that decides how much movement must be detected before a mail is sent. Start somewhere in the middle of the scale. Log in and adjust later if needed, decrease sensitivity if you get false alerts, increase if people can walk by without triggering a mail.
    5. Note that the alert- and e-mail-settings may be located under different headings in the configuration utility. You may also have to turn on motion detection before the e-mail settings become visible, or vice versa.
    6. Check the mail account via webmail or add it to your mail program, like MS Outlook for example. See the instructions provided by the mail provider and the vendor of your mail program. Google is also an excellent source of instructions. Try for example “Gmail Outlook”, or whatever combination you use, and you will find plenty of instructions on-line.
    7. Add the new mail account to your smartphone and you will be able to get alerts immediately wherever you are. See the smartphone’s instructions if needed.

That’s it. Now you should get a mail message with a couple of still pictures every time there is movement in front of one of your cameras. And a nice plus is that the data is transmitted offsite immediately. Cutting the power to your property will naturally neutralize the cameras. But its futile for burglars to look for the video server once they have been captured, their pictures are already in your inbox.

Yes, this requires a little bit of understanding about how network components are configured. If you feel uncertain you can always talk to a tech-savvy friend and ask for help. And remember that this isn’t a full-fledged security system. Valuable properties should have proper security systems rather than hacks of this kind. But even a simple system like this can prove very valuable if something happens. Not to mention that just a visible camera and CCTV-sign can prevent crime.

Safe surfing,

PS. But what if I want to watch live video? That’s easy when at home, but doesn’t provide much value. It is usually possible to make the cameras accessible from other places too. But this is more complicated and depends on how your service provider handles inbound connections. I will not cover that here, but if you call in that nerdy friend to help, you might have a good opportunity to get it set up at the same time.

Get Set Null Java Security

Java, being widely used by the applications, has also been actively targeted by malware authors. One of the most common techniques to exploit Java applications, is to disable the security manager. This blog provides widely used logic used by malware authors to disable the security manager.

Per the Java tutorial:

‘A security manager is an object that defines a security policy for an application. This policy specifies actions that are unsafe or sensitive. Any actions not allowed by the security policy cause a SecurityException to be thrown. An application can also query its security manager to discover which actions are allowed.’

Once an application has a reference to the security manager object, it can request permission to do specific things. For example, System.exit, which terminates the Java virtual machine with an exit status, invokes SecurityManager.checkExit to ensure that the current thread has permission to shut down the application.

One very common technique used by malware authors to exploit Java is to disable the security manager. Once the security manager has been disabled, the next steps may involve loading a malicious executable or connecting to a malicious website.

One of the common calls which generally appear in a malicious jar to disable security manager is SetSecurityManager(null). Besides making a direct call to SetSecurityManager, there can be other approaches for example locating the address of  java/lang/system and using it to disable the security manager. Basically, once the address has been located, memory is traversed until the address of getSecurityManager() is located.  wrmMem() function is then called and null is written directly to the address of getSecurityManager(), thus disabling the security manager.

For more information regarding the pseudo code and exploitation of a vulnerability to disable a security manager, we encourage our readers to refer to recently published article in Virus Bulletin June 2013 issue.