Bogus Claim: Google Doc Phishing Worm Student Project

According to internet sources, Eugene Pupov is not a student at Coventry University.

Since the campaign’s recent widespread launch, security experts and internet sleuths have been scouring the internet to discover the actor responsible for yesterday’s “Google Doc” phishing worm. As parties continued their investigations into the phishing scam, the name “Eugene Popov” has consistently popped up across various blogs that may be tied to this campaign.

A blog post published yesterday by endpoint security vendor Sophos featured an interesting screenshot containing a string of tweets from the @EugenePupov Twitter handle claiming the Google Docs phishing campaign was not a scam, but rather a Coventry University graduate student’s final project gone awry.

Source: Sophos News. https://nakedsecurity.sophos.com/2017/05/04/student-claims-google-docs-blast-was-a-test-not-a-phishing-attempt/

Several folks on Twitter, including Twitter verified Henry Williams (@Digitalhen) have pointed out a serious flaw in the @EugenePupov profile.

Source: Twitter, Inc. httpstwitter.com/digitalhen/status/860006167715643392

This twitter account, which fraudulently used a profile image portraying molecular biologist Danil Vladimirovich Pupov from the Institute of Molecular Genetics at the Russian Academy of Sciences, has since been deactivated.

Coventry University’s communications team quickly responded on social media denying all claims that anyone named Eugene Pupov is a current or former student.

Source: Twitter, Inc. httpstwitter.com/CoventryUniNews/status/860120215216148481

Something clearly is “phishy” about this situation.

Despite the university’s recent announcement discrediting claims of enrollment for a Eugene Popov, I would like to hypothetically explore the theory that yesterday’s campaign was a result of a student phishing research project that went terribly viral. Our PhishMe Intelligence teams identified and obtained the campaign source code and noticed that the most notable aspect of this phishing campaign was its uncanny ability to self-replicate and spread. From our vantage, there is no outward evidence indicating data was stolen or manipulated as previously alleged.

The list of domains created for this alleged “student demonstration” stinks like rotten phish.

googledocs[.]gdocs[.]download

googledocs[.]docscloud[.]download

googledocs[.]gdocs[.]win

googledocs[.]gdocs[.]pro

googledocs[.]g-2Dcloud[.]win

googledocs[.]g-2Ddocs[.]win

googledocs[.]g-2Dcloud[.]pro

googledocs[.]g-2Ddocs[.]pro

googledocs[.]docscloud[.]win

As a career-wide security researcher and current leader of phishing intelligence research teams, this list of domains is concerning. Typically, when a researcher is creating proof-of-concept code for a white paper or presentation, the naming conventions adjust the URLs to showcase their malicious or fraudulent nature for education purposes, examples being:

  • “foo-example.com”
  • “evil-mitm-site.com”
  • “hacker.foo.example.com

If the party responsible intended to showcase educational materials that had any potential to unintentionally mislead a victim, they would typically create one, possibly two, examples to help avoid such scenario. A similar example of this would be the puny code phishing sample recently covered in WIRED where the researcher created one puny code example domain.

What’s most concerning here is the number of googledoc look-alike domains. In most best practice scenarios, a legitimate security researcher would not typically register 9 domains to illustrate a point or to educate on a threat vector. This behavior pattern is most noticeably tied to malicious actors with real nefarious motivations behind their actions.

It may be some time before the true motives of the phishing worm author are revealed, however we are inclined to believe there is a very good chance that malicious intent was in development during this campaign, the execution of which snowballed quickly beyond the author’s desired scope.

Off-the-shelf Zyklon Botnet Malware Utilized to Deliver Cerber Ransomware

Recent, large-scale distributions of the Zyklon botnet malware mark a continuing trend of off-the-shelf malware use. This multipurpose trojan, capable of supporting numerous criminal activities, has been identified in phishing attacks more and more frequently through the month of April. The bulk of these campaign have leveraged resume- and job-applicant-themed messaging as in the phishing narrative. The most recent analyses of this distribution have shown that the threat actors are attempting to leverage the malware’s full feature set by not only using it as an information stealer, but also as a downloader used to obtain and deploy the Cerber ransomware to infected endpoints. This technique demonstrates threat actor resourcefulness as well as the increasing commodification and democratization of malware utilities once reserved for only the most-technically-capable threat actors.

Locky Stages Comeback Borrowing Dridex Delivery Techniques

The ransomware that defined much of the phishing threat landscape in 2016 raged back into prominence on April 21, 2017 with multiple sets of phishing email messages. Harkening back to narratives used throughout 2016, these messages leveraged simple, easily-recognizable, but perennially-effective phishing lures to convince recipients to open the attached file.

How Dridex Threat Actors Craft Phishing Attacks, No Exploits Necessary

Threat actors using the Dridex botnet malware received a great deal of attention recently for their purported utilization of content exploiting a previously un-patched vulnerability in Microsoft Word. This exploit, which took advantage of unexpected behavior in the handling of certain document types, was reportedly used to deliver the Dridex botnet malware via documents attached to phishing emails. However, the bulk of Dridex campaigns leverage far more common delivery techniques that abuse the functionality that already exists in Microsoft Office and Adobe Reader rather than deploying some complex exploit content. This serves as a reminder that threat actors don’t always rely on exploit content because exploits of un-patched vulnerabilities are no longer required to break into an enterprise; simple phishing messages can accomplish this same goal.

Malware Delivery OLE Packages Carve Out Market Share in 2017 Threat Landscape

In the first quarter of 2017, PhishMe Intelligence has noted an increase in malware distributors utilizing OLE packages in order to deliver malware content to victims. This current trend was first noted in December 2016 with close association to the delivery of the Ursnif botnet malware. This technique abuses Microsoft Office documents by prompting the victim to double-click an embedded icon to access some content. These objects are used to write a script application to disk that facilitates the download and execution of a malware payload. This method adds to another iteration of techniques threat actors use to evade anti-analysis and sandbox environments and to successfully infect the intended recipient.

Dridex Threat Actors Reinvigorate Attacks with Sizable, Concurrent Campaigns

One of the most historically effective techniques for gaining new infections for the powerful Dridex botnet malware has been sizable sets of widely-distributed phishing email. While these large campaigns have been intermittent for several months, the past week’s Dridex distributions have shown a renewed vigor with several larger campaigns being launched both concurrently and repeatedly. Many of these campaigns return to well-used and previously-successful email templates and malware delivery tools that had seen earlier utilization in conjunction with both Dridex deliveries and the delivery of other malware tools.

On March 30, 2017 three distinct sets of phishing emails were identified as delivering the Dridex malware. Each was a rehashing of a previously-used phishing narrative. The emails analyzed for Threat ID 8692 pretended to represent communication from a travel agency based in the United Kingdom confirming the recipient’s vacation travel has been booked. Other emails, delivered concurrently, purposed to deliver a vaguely- described “confirmation” as analyzed in Threat ID 8693. Furthermore, Threat ID 8700 documents a set of messages purporting to deliver a notice that an image attachment was ready for sending in yet another vague phishing narrative. Examples of these messages can be seen in Figure 1.

Figure 1 – Examples of Dridex phishing emails from March 30, 2017

The message narrative used in these campaigns should be familiar to information security professionals following Dridex as they represent similar themes to earlier Dridex campaigns. The impersonation of small- and medium-sized firms based in the United Kingdom was previously a common theme among Dridex delivery emails. This preference in content may serve to indicate a preference for a population with which those emails are meant to have disproportionate appeal. However, it appears that these emails were still delivered globally. The other repeated narrative seen once again today is a vague informational message about the status of an image attachment that has been readied for sending. Similar narratives have been used a half-dozen times in the delivery of Dridex since July 2015.

While the Dridex botnet malware’s users are launching phishing campaigns with renewed vigor, their stories and tools have stayed the same. This provides a distinct advantage to threat intelligence users who have access to repositories of information on the tactics, techniques, and procedures related to earlier attacks. It also provides an advantage to organizations whose email users are prepared and empowered to identify and report suspicious emails. Empowered recipients of messages like these are able to recognize the lure and instead of becoming victims, can make a difference for their organization by reporting the email.

Emails based on the threats shown in this blog post are also available as templates in PhishMe Simulator.

For further information on the Threat ID’s mentioned in this post, PhishMe Intelligence customers can log into https://www.threathq.com.

For more information on PhishMe’s human vetted, phishing-specific threat intelligence request a demo today.

The Rise of RaaS: Satan

RaaS, or Ransomware as a Service, enables threat actors that lack the skillset to write their own malware the capacity to infect people’s computers with ransomware through a service, holding the victims’ files hostage for Bitcoin payments. One of the latest RaaS offerings is Satan, a ransomware variant that is easily accessible on a hidden website when browsing with the TOR browser. The website allows anyone to create a ransomware sample which in turn takes a cut of the ransom proceeds from its victims’ payments.

Builder

The TOR hidden service website allows for anyone to create a Satan loader sample after registering for a free account. The front page encourages visitors to register accounts, create a new virus and download it. Although the site handles the building of the initial ransomware loader, it is up for the RaaS user to distribute the malware. Bitcoin payments made by victims are then credited to the RaaS user’s account and the service takes a thirty percent cut for facilitating this cybercrime. The website requires the user to correctly solve CAPTCHAs for any form submitted as a precaution against automated web vulnerability scanners. Below is a screenshot of the front that explains how the service functions:

Dropper

Although the RaaS requires its users to distribute the malware themselves, it also provides a dropper service to assist the user in the initial infection process. By utilizing a dropper, malware actors are able to bypass antivirus email scanners by creating malicious CHM or Office documents that download the ransomware loader once these files are opened by a duped victim who perceived these email attachments to be legit. This dropper service contains helper scripts, pictured below, that encrypt the ransomware loaders with a static XOR key, further bypassing virus detection if the system is solely looking for executables in network traffic. The RaaS user is also able to enter a URL where they host the encrypted ransomware loader that the generated droppers will download, decrypt, and execute the ransomware loader.

Once this information is entered, the user is then able to copy & paste either a CHM (Windows executable help file) or a malicious DOC macro. Although these malicious scripts are not obfuscated, they still have relatively low AV detection.

Per the instructions provided by the dropper service, the CHM generator creates an HTML file which can then be compiled to the Windows executable CHM file using the chmProcessor application, pictured below. The generated HTML file spawns a command shell and executes PowerShell to download, decrypt and execute the ransomware payload.

The generated, executable CHM file only had a detection with one of the fifty-four scanning engines in Virus Total when we tested this dropper method in lab. It would appear that script obfuscation is not required to bypass antivirus defenses for these initial, malicious droppers.

Loader Analysis

The Satan RaaS malware employs a number of anti-analysis techniques in order to prevent automated or manual analysis of a sample. A review of the malware Hash:  b70622bf5192b5a254932451814cc4a1 Version:  1.0.0.13 shows ~20 different checks which are done in order for the malware to continue running and unpack the payload.

Cylance has already done  a great analysis which covers the majority of these techniques, so this report doesn’t review all of them in detail won’t review all of them in detail.

  1. Calls BlockInput to block user interaction with the system
  2. Checks for known AVG modules
  3. Checks for a known Debugger windows using FindWindow
  4. Checks for KernelDebugger

The malware uses an interesting trick where it loads the KdDebuggerEnabled field directly and compare the value.

  1. Check for attached debuggers calling Checks for a debugger calling isDebuggerPresent and CheckRemoteDebuggerPresent
  2. Check for a blacklisted analysis modules by calling the GetModuleHandle
  3. Check for blacklisted analysis Processes by calling FindWindow
  4. Check if the method wine_get_unix_file_name is exported by kernel32.dll to detect the presence of wine
  5. Call NTClose and CloseHandle with Invalid handles as an anti-debugging method.
  6. Create a VEH handler and calls int 3 as an anti-debugging method.
  7. Hooking Check

It checks for possible Jump hooks (0xff, 0x25) or (0xe9) in CreateProcess, DeleteFile, ldrLoadDll & NTQueryInformationProcess functions.

  1. Debugger Check with csrss handle

The process attempts to open a handle to csrss.exe to detect the presence of a debugger. If the request succeeds and a valid handle is opened this can indicate that a debugger is actively running on the system or that the user has sufficient access to debug a system process.

  1. Create top level exception handler and trigger by popping a divide by 0 exception as an anti-debugging technique
  2. Check the OS Version to determine if the sample should run. (No XP support)
  3. Call NTQueryInformationProcess

The sample makes a number of calls to determine if the process is being debugged, by checking the ProcessDebugPort, ProcessDebugObjectHandle & ProcessDebugFlags.

And an additional check for the process devenv.exe the name commonly associated with Visual Studio.

  1. Check for HW BreakPoints

The Process will check for hardware breakpoints by getting the thread context by calling GetThreadContext and then checking the context debug registers.

  1. Check that the filename does not include a blacklisted term
  2. Check that the username doesn’t contain a blacklisted term
  3. Check that the path does not contain a blacklisted term.

Although the loader includes so many anti-analysis techniques they are all contained within a single function call, which makes it easy to bypass all of the techniques with a single hop.


The number of implemented checks and techniques indicate that many of these may have been copied from OSS projects and added to the list of anti-analysis checks. The two main projects with either similar or identical checks are:

  • al-khaser – “PoC malware with good intentions that aims to stress your anti-malware system..”
  • Pafish – “A demonstration tool that employs several techniques to detect sandboxes and virtualization environments..”

For example pulling the list of blacklisted processes, we find the same list within the al-kahser source file process.cpp.

Or the blacklisted user and directory names as found in the pafish project file gensandbox.c:

Additionally, the inclusion of checking for the “devenv.exe” process in relation to checking the ProcessDebug flags can be found to within sample code on anti-debugging and protection techniques. https://www.codeproject.com/Articles/1090943/Anti-Debug-Protection-Techniques-Implementation-an.

Looking at a previous version of the ransomware (v1.0.0.1) we see that the anti-analysis checks have been evolving. Within this older sample (hash) we find several checks for virtualization artifacts that no longer exist within the newer version of the loader.

For example the registry and process checks for virtualization artifacts.


Or the inspection of the physical drive to ensure that the user can obtain an valid handle and that the disk size is > 50G.


The removal of some of these checks could indicate that the author(s) have found some issues with the checks or found them to be ineffective. Since many these anti-analysis checks appear to be copied from OSS projects we can assume that new techniques are likely to be added as the ransomware evolves.

Payload

After the anti-analysis checks are passed, the sample spawns a child process of itself and uses Process Hollowing to write the unpacked executable into the spawned process.

This follows the standard Process Holllowing technique of:

Once the injected process is launched the parent loader process exits.

The injected process then melts a modified version of the loader into the directory:

%appdata%/<generated_dir_name>/<generated_file_name>.exe

and creates an entry within the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run for persistence. In previous versions of the loader this would also include the –t switch, but this option is no long available within the new analyzed version 1.0.0.13.

The malware then executes the melted version which drops and runs a batch script in %temp% to delete the initial loader executable and script files.

Target Files

An initial analysis of the payload shows that over 375 file types are targeted for encryption. Once the file is encrypted it is renamed and the extension is replaced with ‘.stn’

One interesting feature of the payload observed during the initial analysis was the support of a couple of command line switches (-i and -r)

Analyzing the -i path produces a debug window which includes what appears to be the payload version (1.00.13) and the uinque id assigned at the time of download. This Id can be seen within the download ULR of a generated sample satan6dll23napb5[.]onion/malwares/{uniquie_id}

Conclusion

We can see that the Custom Loader used by the ransomware continues to evolve as the author(s) add and remove functionality. As the ransomware uses a custom loader it can be used to identify and cluster samples. This is uncommon with most malware so we would expect that another stage would be added to the execution chain by actors using this:

  • Stage_1 (generic packer) à Stage_2 (custom loader à Stage 3 (payload)

This would make it much more difficult to statically cluster samples as the initial executable file wouldn’t exhibit any identifying characteristics. Searching for both artifacts of the dropper scripts a user can generate on the panel and for other loaders, we have been unable to find evidence that this is being used as a payload within any large scale e-mail campaigns. This may be due to any number of factors:

  • The method being used within the infection vector are using obfuscated versions of the provided .chm and macro droppers or writing custom scripts to be used for infection.
  • This is being used in low volume campaigns targeting primarily home users.
  • Potential operators need to share profits (30%) with the original author(s) and also trust that they would get their cut of ransom for targets.
  • Potential operators need to trust the site operators

Reference

AVG Modules

  • avghookx.dll
  • avghooka.dll

Blacklisted Debug Windows

  • OLLYDBG
  • WinDbgFrameClass
  • Zeta Debugger
  • Rock Debugger
  • ObsidianGUI
  • Blacklisted Modules
  • SbieDll.dll
  • dbghelp.dll
  • snxhk.dll
  • api_log.dll
  • dir_watch.dll
  • vmcheck.dll
  • wpespy.dll
  • pstorec.dll

Blacklisted Process Names

  • ollydbg.exe
  • ProcessHacker.exe
  • tcpview.exe
  • autoruns.exe
  • autorunsc.exe
  • filemon.exe
  • Procmon.exe
  • Procexp.exe
  • idaq.exe
  • idaq64.exe
  • ImmunityDebugger.exe
  • WireShark.exe
  • dumpcap.exe
  • HookExplorer.exe
  • ImportRec.exe
  • PeTools.exe
  • LordPE.exe
  • SysInspector.exe
  • Proc_analyzer.exe
  • sysAnalyzer.exe
  • sniff_hit.exe
  • windbg.exe
  • joeboxcontrol.exe
  • joeboxserver.exe

Name Blacklist

  • sample.exe
  • c:\InsideTM
  • Username Blacklist
  • SANDBOX
  • VIRUS
  • MALWARE
  • MALTEST
  • TEQUILABOOMBOOM
  • Directory Blacklist
  • SAMPLE
  • VIRUS
  • SANDBOX

Macro Based Anti-Analysis

Over the past several months PhishMe research has noticed an increase with Anti-Analysis techniques being included within Office macro and script files. This is the first post in a series where we look at the inclusion and effectiveness of these methods. Although the use of Anti-Analysis techniques is not new, they are generally observed within the packed payload in an effort to avoid detection by endpoint security solutions.

Most recently we came across a campaign of emails which included a malicious Microsoft Word document. The document contains a standard lure using an image instructing the user to enable active content as it was authored with a newer version of Microsoft Office.

figure 1

Once macros are enabled during analysis we generally see activity as the execution is triggered when the document is opened or an object is initialized and the script begins extracting or downloading a malicious payload, but we noticed with samples from this campaign that there was no activity when the macro was enabled.

Using oletools to quickly scan the document we see that the hook to trigger the macro code is using the Document_Close event instead of an event triggered using document open or object initialization. Running the sample in a sandbox further confirmed that dynamic analysis results were not available as the session timed out and the macro code was never executed.

figure 2

Visualizing the call-graph shows that the macro is composed of one main function and a de-obfuscation routine which allows us to quickly focus on the calls within the ijPql function. Analysis led us to find additional anti-analysis checks within the Macro before the payload was downloaded and executed.

figure 3

The macro first checks that the current username is not ‘USER’ and then checks that the RecentFiles count is > 3

figure 4

The macro then makes a HTTP GET request to https://www.maxmind.com/geoip/v2.1/city/me with the following custom headers:

  • Referer: ‘https://www.maxmind.com/en/locate-my-ip-address’
  • User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0)

A successful request returns a JSON object which includes a traits structure containing information about the ISP, Orgainization and ASN.

figure 5

The result is then checked if any of the following strings exist within the JSON string.

“AMAZON”, “ANONYMOUS”, “BITDEFENDER”, “BLUE COAT”, “CISCO SYSTEMS”, “CLOUD”, “DATA CENTER”, “DATACENTER”, “DATACENTRE”, “DEDICATED”, “ESET, SPOL”, “FIREEYE, “FORCEPOINT”, “FORTINET”, “HETZNER”, “HOSTED”, “HOSTING”, “LEASEWEB”, “MICROSOFT”, “NFORCE”, “OVH SAS”, “PROOFPOINT”, “SECURITY”,”SERVER”, “STRONG TECHNOLOGIES”, “TREND MICRO”, “TRUSTWAVE”, “NORTH AMERICA”, “BLACKOAKCOMPUTERS”, “MIMECAST”, “TRENDMICRO”

If any of the checks fail, the macro will exit and not download the configured payload.

Conclusion

We see another example of attackers migrating anti-analysis techniques that are traditionally seen included within a packed payload, up the stack into the initial infection script. The use of a finalization event (on_close) to trigger execution, demonstrates that attackers understand the default capabilities of sandboxes and are implementing techniques to bypass automated analysis. Additionally, the inclusion of network source checks focusing on security and hosting infrastructure further indicates awareness of cloud based services being leveraged by researchers and security companies.

Although the checks are easily bypassed by researchers and analysts because they are implemented in a scripting language. They have been observed to be effective in circumventing dynamic analysis in common sandbox deployments.

Document Samples  

  • 683154fa03f494bd368042b3546f7b04
  • 3bb6807d88a7ee359d7d813e01700001
  • 4c59ccbc0c524069e46ad8d92e65a14c

2016 Q1 Malware Review – Available Now

Today, our research team released our 2016 Q1 Malware Review, detailing more than 600 Active Threat Reports and the waves of phishing emails that delivered malware to victims across the globe each day last quarter. Among the sea of threats reported, the proliferation of ransomware stood out as one of the most common types of malware used through soft targeting and massively distributed attacks.

Awareness isn’t the goal, it’s just the beginning

When people refer to PhishMe as the awareness company, we smile and nod. I want to correct them, but the label ‘security awareness’ is comfortable and relatable. One of the activities that organizations commonly believe will help reduce risk is mandatory security awareness computer-based training (CBT) lessons.  The hope is that if we enroll our humans in online courses about how the bad guys hack us, they will walk away with a wealth of new-found awareness and avoid being victimized.  (Try to visualize how far in the back of my head my eyes are rolling…)