The other month I read enigma0x3’s excellent post on using MMC20.Application for lateral movement. The MMC20.Application class allows for the interaction and automation of MMC. In enigma0x3’s post he leverages the MMC20.Application class using one of the ActiveView View methods to execute a shell command of his choosing, calc.exe in this instance. This got me thinking how would I spot this lateral movement method on one of my networks. Clearly, it doesn’t stand out like psexec or some odd service or scheduled task starting up for the first time or at a strange time. So I figured I would test it out myself and see what artifacts I can see.

So let’s poke around and see what we can see. For my testing, I have 3 boxes running, a Windows 10 system named Baluur, a Windows 7 named Arthros and then a Domain Controller aptly named TheCrossRoadsOfInfinity. All machine are part of thenegative.zone domain. All boxes are also remotely logging sysmon to an ELK stack. For the scenario, we are going to pretend the attacker has a foothold on the Windows 10 system and is now looking to pivot off their newly found access to another machine. In this case, the Windows 7 system is the target.

So first I’ll ensure calc.exe isn’t already running on the Windows 7 endpoint.

PS C:\Windows\system32> gwmi Win32_Process -filter "name='calc.exe'" -credential thenegative.zone\Administrator -ComputerName 172.20.64.130 | select ExecutablePath, ProcessId, ParentProcessId, CommandLine|format-list

Just to be clear there are no instances running we use PS to look for calc.exe

C:\Windows\system32>wmic /node:172.20.64.130 /user:administrator process where name="calc.exe" list
Enter the password :************
No Instance(s) Available.


MMC20.Application’s Lateral Movement PoC Calc Execution

The next steps will actually perform the MMC20.Application execution of calc.exe via PowerShell. First we create an instance of MMC20.Application and then utilize the ExecuteShellCommand method. So we are going to open a command window as Administrator (RunAsAdministrator) and then execute powershell and type the following:

PS C:\Windows\system32> $comobj = [Activator]::CreateInstance([Type]::GetTypeFromProgID("MMC20.Application","172.20.64.130"));

PS C:\Windows\system32> $comobj.Document.ActiveView.ExecuteShellCommand("C:\Windows\System32\calc.exe",$null,$null,"9")

Okay, so let’s check for calc. Yup, evil calc.exe is running as PID 3728.

gwmi Win32_Process -filter "name='calc.exe'" -credential thenegative.zone\Administrator -ComputerName 172.20.64.130 | select ExecutablePath, ProcessId, ParentProcessId, CommandLine|format-list

ExecutablePath  : C:\Windows\System32\calc.exe
ProcessId       : 3728
ParentProcessId : 196
CommandLine     : "C:\Windows\System32\calc.exe"

So what artifacts could would use to recognize this behavior and these actions? Let’s take a lookie loo and see what we can see. In this case, your auditing configuration and/or internal visibility will determine how much you can see in terms of artifacts. On my endpoints, I am running sysmon and I pipe these events to an ELK stack for review. To narrow down and weed out the noise, I performed the normal process of eliminating the known goods and honing in on the unknowns and clear evil that occurred during a small timeframe.

The analysis below is broken down into sections the reflect different components of the whole event. I broke it down into what events would you see if someone did a RunAsAdministrator on the cmd.exe, the execution of PowerShell, the MMC20.Application COM instantiation and execution of a process on a remote host.

Analysis of CMD.exe Execution as an Administrator

For my own education I figured I would take the time to see what exactly happens when a user does a RunAsAdministrator on cmd.exe on a Windows 10 machine. The following represents those actions:

On the Windows 10 machine (the one the attacker already has a foothold on), we see a trickle of events from S-1-5-18(Administrator)

  • Enumeration of the Administrators Group with the callerprocessname of consent.exe. EventID 4799
  • Execution of consent.exe (ParentProcess is svchost) by S-1-5-18(Administrator)
  • AUDIT_SUCCESS (EventID 4799) event regarding a security-enabled local group membership was enumerated by the consent.exe process.


On the Domain Controller, we see the following:

  • A new special privileges logon request from S-1-5-18 with an EventType of AUDIT_SUCCESS (EventID 4672, Logon ID 0x9E1C7)
    • A Message containing:
      • Privileges:
        SeSecurityPrivilege
        SeBackupPrivilege
        SeRestorePrivilege
        SeTakeOwnershipPrivilege
        SeDebugPrivilege
        SeSystemEnvironmentPrivilege
        SeLoadDriverPrivilege
        SeImpersonatePrivilege
        SeDelegateSessionUserImpersonatePrivilege
        SeEnableDelegationPrivilege
  • We then see the logon session (0x9E1C7) destroyed. I have to be honest here, I am unsure why it is created and then destroyed within a fraction of a second.
  • We then see an impersonation LogonType 3(Network) Kerberos authentication


Back on the Win10 box we see:

  • A Negotiate Logon AUDIT_SUCCESS (EventID 4624) event for Administrator with Impersonation Level = Impersonation, from process consent and Logon Process CredPro
  • A security-enabled local group membership was enumerated by the consent.exe process
  • Special Privileges were assigned to the new logon
  • The consent.exe process was terminated
  • Now we see the cmd.exe process created under the user Administrator with a ParentProcess of RunTimeBroker.exe -Embedding
  • We then see the conhost.exe process created with the parent process being cmd.exe

Consent Image

I haven’t dug into it but I am not 100% sure in what circumstances RunTimeBroker isn’t the ParentProcess but for standard GUI actions, RunTimeBroker seems to be the ParentProcess.

PowerShell Execution

When PowerShell executes we see a handful of events. These events were from a standard Windows 10 install with no modifications to PowerShell or its providers. See the following PowerShell Providers Info:

  • The PowerShell Registry Provider Class is started with the HostApplication being PowerShell and HostName of ConsoleHost within the PowerShell Event Logs.
  • The C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe process is created with a ParentProcess of cmd.exe
    • ProcessId: 3372
  • The PowerShell Alias Provider Class is started with the HostApplication being PowerShell and HostName of ConsoleHost within the PowerShell Event Logs.
  • The PowerShell process creates a temp file
    • C:\Users\administrator\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations.
    • In my case it wrote -> C:\Users\administrator\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations\UCE6FW0FI2TZT8PEYOD9.temp
  • The PowerShell FileSystem Provider Class is started with the HostApplication being PowerShell and HostName of ConsoleHost within the PowerShell Event Logs.
  • The PowerShell Environment Provider Class is started with the HostApplication being PowerShell and HostName of ConsoleHost within the PowerShell Event Logs.
  • The PowerShell Function Provider Class is started with the HostApplication being PowerShell and HostName of ConsoleHost within the PowerShell Event Logs.
  • You see within the PowerShell Event Logs that the PowerShell EngineState is changed from None to Available. The HostApplication still set to PowerShell and HostName to ConsoleHost.
    • NewEngineState=Available
      PreviousEngineState=None
      SequenceNumber=13
      HostName=ConsoleHost
      HostVersion=5.0.10240.17146
      HostId=53a3334d-c0bf-4209-b9cd-acbe0a334542
      HostApplication=powershell
      EngineVersion=5.0.10240.17146
      RunspaceId=03909b1a-0fdf-4734-a28f-9c27b7f2f9cb
      PipelineId=
      CommandName=
      CommandType=
      ScriptName=
      CommandPath=
      CommandLine=
  • The PowerShell Variable Provider Class is started with the HostApplication being PowerShell and HostName of ConsoleHost within the PowerShell Event Logs.
  • PowerShell starts an IPC listening thread from the PowerShell PID. “Windows PowerShell has started an IPC listening thread on process: 3372 in AppDomain: DefaultAppDomain.” OpCode of Open(async)
  • At this point the PowerShell console logs itself as starting. “PowerShell console is starting up”
  • The PowerShell console logs itself as ready for user input

PowerShell Startup Image

MMC20.Application COM Object Remote Execution

To get to the meat and potatoes of post, what artifacts and events could an analyst be aware of when they are keeping an eye out for suspicious or malicious activity on a host or across an enterprise.

On the Domain Controller, we see the following:

  • At 22:06:15.251, it receives an attempt to validate credentials for an account:
    • An AUDIT_SUCCESS with an EventID of 4776 from the Windows 10 endpoint
      Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
      Logon Account: Administrator
      Source Workstation: BALUUR
      Error Code: 0x0

On the Windows 10 host, we the following:

  • The PowerShell Event Logs record:
    • Category: “Execute a Remote Command” This category entry is definitely noteworthy and worthy of event recording
    • A Message containing:
      • Creating Scriptblock text (1 of 1):
        $comobj = [Activator]::CreateInstance([Type]::GetTypeFromProgID(“MMC20.Application”,”172.20.64.130”));
        ScriptBlock ID: 684e0b39-d5ad-498c-a64a-5b029b23fafe
        Path:

MMC20.Application Image

On the Windows 7 target, we see the following:

  • At 22:06:15.550 there is a Special Logon in the Security Event Logs
  • An AUDIT_SUCCESS event with an EventID of 4672 from the DC as the Source IP
  • Message containing:
    • Special privileges assigned to new logon.
      Subject:
      Security ID: S-1-5-21-1923566281-4131265335-1104240599-500
      Account Name: Administrator
      Account Domain: THENEGATIVE
      Logon ID: 0xa0292
      Privileges: SeSecurityPrivilege
      SeBackupPrivilege
      SeRestorePrivilege
      SeTakeOwnershipPrivilege
      SeDebugPrivilege
      SeSystemEnvironmentPrivilege
      SeLoadDriverPrivilege
      SeImpersonatePrivilege


Then at 22:06:15.555, we then see another Special Logon in the Security Event Logs that shows the same exact thing but a different Logon ID: The Logon ID is a semi-unique (unique between reboots) number that identifies the logon session just initiated. Any events logged subsequently during this logon session will report the same Logon ID through to the logoff event 4647 or 4634.

  • An AUDIT_SUCCESS event with an EventID of 4672 from the DC as the Source IP
  • Message containing:
    • Special privileges assigned to new logon.
      Subject:
      Security ID: S-1-5-21-1923566281-4131265335-1104240599-500
      Account Name: Administrator
      Account Domain: THENEGATIVE
      Logon ID: 0xa0294
      Privileges: SeSecurityPrivilege
      SeBackupPrivilege
      SeRestorePrivilege
      SeTakeOwnershipPrivilege
      SeDebugPrivilege
      SeSystemEnvironmentPrivilege
      SeLoadDriverPrivilege
      SeImpersonatePrivilege


We then finally see the successful login from the Windows 10 host on the Windows 7 host at 22:06:15.555:

  • An AUDIT_SUCCESS event with an EventID of 4624 with NTLM Authentication
  • LogonProcessName of NTLMSSP. Since this was a Windows 7 box it defaulted to NTLM / NTLMSSP. If it was Vista or higher it would show Kerberos
  • LogonType 3 (Network)
  • A Message containing:
    • An account was successfully logged on.
      Subject:
      Security ID: S-1-0-0\ Null/Nobody SID Account Name: -
      Account Domain: -
      Logon ID: 0x0
      Logon Type: 3
      New Logon:
      Security ID: S-1-5-21-1923566281-4131265335-1104240599-500
      Account Name: Administrator
      Account Domain: THENEGATIVE
      Logon ID: 0xa0294
      Logon GUID: {00000000-0000-0000-0000-000000000000}
      Process Information:
      Process ID: 0x0
      Process Name: -
      Network Information:
      Workstation Name: BALUUR
      Source Network Address: 172.20.64.135
      Source Port: 49461
      Detailed Authentication Information:
      Logon Process: NtLmSsp
      Authentication Package: NTLM
      Transited Services: -
      Package Name (NTLM only): NTLM V2
      Key Length: 128

On the Windows 10 host at 22:06:16.422, we four network events: Microsoft’s DCE RPC Locator Service/epmap initiates a TCP connection on behalf of the DCOM object to the Windows 7 host:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\svchost.exe
  • Protocol: TCP
  • Destination Port: 135
  • Destination IP: 172.20.64.130
  • Destination Hostname: Arthros
  • User: NT AUTHORITY\NETWORK SERVICE
  • Source Port: 49460
  • Source Hostname: Baluur.thenegative.zone
  • Source IP: 172.20.64.135


We then see a second epmap DCOM connection initiated at 22:06:16.426:
Currently, I am unsure why there are two paired connects instead of one epmap and then one powershell. It needs further vetting but it may be due to the two COMObj calls, followed subsequently by two PowerShell calls. Nonetheless, if investigating this activity or you see similar activity you would see an svchost NetworkConnect followed by a PowerShell NetworkConnect

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\svchost.exe
  • Protocol: TCP
  • Destination Port: 135
  • Destination IP: 172.20.64.130
  • Destination Hostname: Arthros
  • User: NT AUTHORITY\NETWORK SERVICE
  • Source Port: 49461
  • Source Hostname: Baluur.thenegative.zone
  • Source IP: 172.20.64.135


We then see PowerShell initiate a connection at 22:06:16.428:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • ProcessId: 3372
  • Protocol: TCP
  • Destination Port: 49189
  • Destination IP: 172.20.64.130
  • Destination Hostname: Arthros
  • User: THENEGATIVE\Administrator
  • Source Port: 49462
  • Source Hostname: Baluur.thenegative.zone
  • Source IP: 172.20.64.135


We then see PowerShell initiate another connection at 22:06:16.432:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • ProcessId: 3372
  • Protocol: TCP
  • Destination Port: 49189
  • Destination IP: 172.20.64.130
  • Destination Hostname: Arthros
  • User: THENEGATIVE\Administrator
  • Source Port: 49463
  • Source Hostname: Baluur.thenegative.zone
  • Source IP: 172.20.64.135

On the Windows 7 endpoint at 22:06:16.577: We finally see the COM Object Process Create event spawn:

  • Process: C:\Windows\System32\mmc.exe -Embedding
  • ProcessId: 1312
  • ThreadID: 1496
  • ParentProcess: C:\Windows\system32\svchost.exe -k DcomLaunch
  • ParentProcessId: 584
  • User: THENEGATIVE\Administrator
  • LogonId: 0xa0292


We then see the first epmap network connections from the Windows 10 host at 22:06:16.578:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\svchost.exe
  • ProcessId: 680
  • Protocol: TCP
  • User: NT AUTHORITY\NETWORK SERVICE
  • Source Port: 135
  • Source Hostname: Arthros
  • Source IP: 172.20.64.130
  • Destination IP: 172.20.64.135
  • Destination Hostname: Baluur
  • Destination Port: 49460


Then the second epmap connection at 22:06:16.579:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\svchost.exe
  • ProcessId: 680
  • Protocol: TCP
  • User: NT AUTHORITY\NETWORK SERVICE
  • Source Port: 135
  • Source Hostname: Arthros
  • Source IP: 172.20.64.130
  • Destination IP: 172.20.64.135
  • Destination Hostname: Baluur
  • Destination Port: 49461


We then see the first MMC connection from PowerShell at 22:06:16.580:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\mmc.exe
  • ProcessId: 196
  • Protocol: TCP
  • User: THENEGATIVE\Administrator
  • Source Port: 49189
  • Source Hostname: Arthros
  • Source IP: 172.20.64.130
  • Destination IP: 172.20.64.135
  • Destination Hostname: Baluur
  • Destination Port: 49462


We then see the second MMC connection from PowerShell at 22:06:16.581:

  • Event Record from Sysmon states: Network connection detected
  • Process: C:\Windows\System32\mmc.exe
  • ProcessId: 196
  • Protocol: TCP
  • User: THENEGATIVE\Administrator
  • Source Port: 49189
  • Source Hostname: Arthros
  • Source IP: 172.20.64.130
  • Destination IP: 172.20.64.135
  • Destination Hostname: Baluur
  • Destination Port: 49463 MMC NetworkConnect Image


Low and behold, we finally see Calc spawn at 22:06:30.771:

  • Process: C:\Windows\System32\calc.exe
  • ProcessId: 3728
  • ThreadID: 1496
  • ParentProcess: C:\Windows\system32\mmc.exe -Embedding
  • ParentProcessId: 196
  • User: THENEGATIVE\Administrator
  • LogonId: 0xa0292 Evil Calc Image


Clearly this type of movement can be hard to spot and it blends in with the normal noise but there are some indicators to recognize. Of course, this is dependent on how deeply you log/audit or how much visibility you may have in some other form or fashion. If you utilize SysMon or a similar product, it can definitely help recognize tactics like unauthorized PowerShell executions, MMC remote executions along with their network attributes, recognizing processes with their ParentProcess being MCC and of course any use of calc.exe is clearly pure evil.